From philippe.hanrigou at gmail.com  Wed May  1 00:21:54 2013
From: philippe.hanrigou at gmail.com (Philippe)
Date: Tue, 30 Apr 2013 21:21:54 -0700
Subject: [OmniOS-discuss] Recommended way to keep Zones up to date?
Message-ID: <C09AE7C6-9D2B-4767-A6BF-69C7D1CC355D@gmail.com>

Hi,

<noob question>
What is the recommended way to update the packages in the global and non global zones? 
</noob question>

I have a bunch of vanilla OmniOS zones defined ala:

# zonecfg -z personal
# zonecfg:personal> create
# zonecfg:personal> set zonepath=/Zones/personal
# zonecfg:personal> set autoboot=true
# zonecfg:personal> add net
# zonecfg:personal:net> set address=X.X.X.X/Y
# zonecfg:personal:net> set physical=bge0
# zonecfg:personal:net> end

I used to just run 'pkg update' in the global zone and then in each of the non-global zones. Since it is cumbersome, and the non global zones would always complain about not being able to update the boot environment, I googled around and decided to try the 'zoneadm -z my-zone detach' / 'zoneadm -z my-zone attach -u' strategy described in http://www.oracle.com/technetwork/articles/servers-storage-dev/updatesoftwarezones-450942.html#Upgrading. Not only it seemed non ideal to have to bring the zone offline, but once I detached it my zone would never attach again due to some incorporation problem that I could not troubleshoot due to my limited IPS understanding.

So my question is what is the best practice here? What should I have been doing all along (ideally without taking downtime)?

Thanks in advance,
- Philippe

  

From skiselkov.ml at gmail.com  Wed May  1 03:50:36 2013
From: skiselkov.ml at gmail.com (=?UTF-8?B?U2HFoW8gS2lzZWxrb3Y=?=)
Date: Wed, 01 May 2013 09:50:36 +0200
Subject: [OmniOS-discuss] Trouble getting Supermicro board to see all
	its PCI-e slots
In-Reply-To: <517F9A19.7030707@gmail.com>
References: <517F9A19.7030707@gmail.com>
Message-ID: <5180C94C.9020305@gmail.com>

Just a follow up on this: this appears to be an Illumos bug, though I
haven't figured out how to resolve it yet. The problem appears to be
that Illumos doesn't recognize any PCI bridges beyond those attached to
CPU1. Notably, nothing on CPU2 appears to work. I've tested with Linux
3.5 and that works flawless, attached are the lspci -vvvv outputs.

The problem appears to be that Illumos stops after PCI address 0b:00.0
(on-board MegaRAID SAS 2208). After that the scan should proceed with
the QPI inter-processor links, but doesn't.

The full lspci should look something like this:

00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI..
00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
00:02.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
00:02.3 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
00:03.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
00:04.0 System peripheral: Intel Corporation Xeon E5/Core ..
00:04.1 System peripheral: Intel Corporation Xeon E5/Core ..
00:04.2 System peripheral: Intel Corporation Xeon E5/Core ..
00:04.3 System peripheral: Intel Corporation Xeon E5/Core ..
00:04.4 System peripheral: Intel Corporation Xeon E5/Core ..
00:04.5 System peripheral: Intel Corporation Xeon E5/Core ..
00:04.6 System peripheral: Intel Corporation Xeon E5/Core ..
00:04.7 System peripheral: Intel Corporation Xeon E5/Core ..
00:05.0 System peripheral: Intel Corporation Xeon E5/Core ..
00:05.2 System peripheral: Intel Corporation Xeon E5/Core ..
00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (r..
00:11.0 PCI bridge: Intel Corporation C600/X79 series chip..
00:16.0 Communication controller: Intel Corporation C600/X..
00:16.1 Communication controller: Intel Corporation C600/X..
00:1a.0 USB controller: Intel Corporation C600/X79 series ..
00:1d.0 USB controller: Intel Corporation C600/X79 series ..
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (re..
00:1f.0 ISA bridge: Intel Corporation C600/X79 series chip..
00:1f.2 SATA controller: Intel Corporation C600/X79 series..
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset S..
00:1f.6 Signal processing controller: Intel Corporation C6..
02:00.0 Serial Attached SCSI controller: Intel Corporation..
03:00.0 SCSI storage controller: LSI Logic / Symbios Logic..
05:00.0 Ethernet controller: Intel Corporation 82599EB 10-..
05:00.1 Ethernet controller: Intel Corporation 82599EB 10-..
07:00.0 PCI bridge: Tundra Semiconductor Corp. Device 8113..
08:01.0 VGA compatible controller: Matrox Electronics Syst..
09:00.0 Ethernet controller: Intel Corporation I350 Gigabi..
09:00.1 Ethernet controller: Intel Corporation I350 Gigabi..
0b:00.0 RAID bus controller: LSI Logic / Symbios Logic Meg..
     <<< Illumos gives up here, Linux continues >>>
7f:08.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:08.3 System peripheral: Intel Corporation Xeon E5/Core ..
7f:08.4 System peripheral: Intel Corporation Xeon E5/Core ..
7f:09.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:09.3 System peripheral: Intel Corporation Xeon E5/Core ..
7f:09.4 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0e.1 Performance counters: Intel Corporation Xeon E5/Co..
7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core ..
7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core ..
7f:10.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:10.1 System peripheral: Intel Corporation Xeon E5/Core ..
7f:10.2 System peripheral: Intel Corporation Xeon E5/Core ..
7f:10.3 System peripheral: Intel Corporation Xeon E5/Core ..
7f:10.4 System peripheral: Intel Corporation Xeon E5/Core ..
7f:10.5 System peripheral: Intel Corporation Xeon E5/Core ..
7f:10.6 System peripheral: Intel Corporation Xeon E5/Core ..
7f:10.7 System peripheral: Intel Corporation Xeon E5/Core ..
7f:11.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:13.0 System peripheral: Intel Corporation Xeon E5/Core ..
7f:13.1 Performance counters: Intel Corporation Xeon E5/Co..
7f:13.4 Performance counters: Intel Corporation Xeon E5/Co..
7f:13.5 Performance counters: Intel Corporation Xeon E5/Co..
7f:13.6 System peripheral: Intel Corporation Xeon E5/Core ..
80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2..
80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
80:02.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
80:03.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
80:04.0 System peripheral: Intel Corporation Xeon E5/Core ..
80:04.1 System peripheral: Intel Corporation Xeon E5/Core ..
80:04.2 System peripheral: Intel Corporation Xeon E5/Core ..
80:04.3 System peripheral: Intel Corporation Xeon E5/Core ..
80:04.4 System peripheral: Intel Corporation Xeon E5/Core ..
80:04.5 System peripheral: Intel Corporation Xeon E5/Core ..
80:04.6 System peripheral: Intel Corporation Xeon E5/Core ..
80:04.7 System peripheral: Intel Corporation Xeon E5/Core ..
80:05.0 System peripheral: Intel Corporation Xeon E5/Core ..
80:05.2 System peripheral: Intel Corporation Xeon E5/Core ..
80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (r..
83:00.0 SCSI storage controller: LSI Logic / Symbios Logic..

See http://217.75.71.10/MB.png for the system interconnection diagram.
Can somebody please recommend how to debug this issue?

Cheers,
--
Saso

From contact at aakashsaini.com  Wed May  1 05:51:20 2013
From: contact at aakashsaini.com (Aakash Saini)
Date: Wed, 1 May 2013 02:51:20 -0700
Subject: [OmniOS-discuss] [developer] Re: Trouble getting Supermicro
 board to see all its PCI-e slots
In-Reply-To: <5180C94C.9020305@gmail.com>
References: <517F9A19.7030707@gmail.com> <5180C94C.9020305@gmail.com>
Message-ID: <CAEBSS5QfO0Bf+O9MAUWCsuG0Q49+_zMeSQJWTfrC5pXUpfrJPw@mail.gmail.com>

use 'prtpicl' instead.



------------------------------------------------------------
Aakash Saini | (+91) 997.101.4477


On Wed, May 1, 2013 at 12:50 AM, Sa?o Kiselkov <skiselkov.ml at gmail.com>wrote:

> Just a follow up on this: this appears to be an Illumos bug, though I
> haven't figured out how to resolve it yet. The problem appears to be
> that Illumos doesn't recognize any PCI bridges beyond those attached to
> CPU1. Notably, nothing on CPU2 appears to work. I've tested with Linux
> 3.5 and that works flawless, attached are the lspci -vvvv outputs.
>
> The problem appears to be that Illumos stops after PCI address 0b:00.0
> (on-board MegaRAID SAS 2208). After that the scan should proceed with
> the QPI inter-processor links, but doesn't.
>
> The full lspci should look something like this:
>
> 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI..
> 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:02.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:02.3 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:03.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:04.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.5 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.7 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:05.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:05.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (r..
> 00:11.0 PCI bridge: Intel Corporation C600/X79 series chip..
> 00:16.0 Communication controller: Intel Corporation C600/X..
> 00:16.1 Communication controller: Intel Corporation C600/X..
> 00:1a.0 USB controller: Intel Corporation C600/X79 series ..
> 00:1d.0 USB controller: Intel Corporation C600/X79 series ..
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (re..
> 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chip..
> 00:1f.2 SATA controller: Intel Corporation C600/X79 series..
> 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset S..
> 00:1f.6 Signal processing controller: Intel Corporation C6..
> 02:00.0 Serial Attached SCSI controller: Intel Corporation..
> 03:00.0 SCSI storage controller: LSI Logic / Symbios Logic..
> 05:00.0 Ethernet controller: Intel Corporation 82599EB 10-..
> 05:00.1 Ethernet controller: Intel Corporation 82599EB 10-..
> 07:00.0 PCI bridge: Tundra Semiconductor Corp. Device 8113..
> 08:01.0 VGA compatible controller: Matrox Electronics Syst..
> 09:00.0 Ethernet controller: Intel Corporation I350 Gigabi..
> 09:00.1 Ethernet controller: Intel Corporation I350 Gigabi..
> 0b:00.0 RAID bus controller: LSI Logic / Symbios Logic Meg..
>      <<< Illumos gives up here, Linux continues >>>
> 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Co..
> 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:13.1 Performance counters: Intel Corporation Xeon E5/Co..
> 7f:13.4 Performance counters: Intel Corporation Xeon E5/Co..
> 7f:13.5 Performance counters: Intel Corporation Xeon E5/Co..
> 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2..
> 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:02.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:03.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:04.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.5 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.7 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:05.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:05.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (r..
> 83:00.0 SCSI storage controller: LSI Logic / Symbios Logic..
>
> See http://217.75.71.10/MB.png for the system interconnection diagram.
> Can somebody please recommend how to debug this issue?
>
> Cheers,
> --
> Saso
>
>
> -------------------------------------------
> illumos-developer
> Archives: https://www.listbox.com/member/archive/182179/=now
> RSS Feed:
> https://www.listbox.com/member/archive/rss/182179/24096868-ef9d90b8
> Modify Your Subscription:
> https://www.listbox.com/member/?member_id=24096868&id_secret=24096868-8ac1a962
> Powered by Listbox: http://www.listbox.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130501/ba8a4286/attachment-0001.html>

From garrett at damore.org  Wed May  1 09:54:31 2013
From: garrett at damore.org (Garrett D'Amore)
Date: Wed, 1 May 2013 06:54:31 -0700
Subject: [OmniOS-discuss] [discuss] Trouble getting Supermicro board to
	see all its PCI-e slots
In-Reply-To: <5180C94C.9020305@gmail.com>
References: <517F9A19.7030707@gmail.com> <5180C94C.9020305@gmail.com>
Message-ID: <4155DA97-43D5-4AC9-8178-2F9235B9DF8C@damore.org>

Check the value of pci_bios_maxbus.

I have a sneaking feeling that the problem may be related to acpi enumeration of the bus.  We are limited to seeing the busses that ACPI properly enumerates.  Take a look at the code in pci_boot.c for more details.  You should especially note the call sites for create_pcie_root_bus.

I'd love to help further, but lack of access to hardware that exhibits this problem prevents me from doing any active debug myself.

	- Garrett

On May 1, 2013, at 12:50 AM, Sa?o Kiselkov <skiselkov.ml at gmail.com> wrote:

> Just a follow up on this: this appears to be an Illumos bug, though I
> haven't figured out how to resolve it yet. The problem appears to be
> that Illumos doesn't recognize any PCI bridges beyond those attached to
> CPU1. Notably, nothing on CPU2 appears to work. I've tested with Linux
> 3.5 and that works flawless, attached are the lspci -vvvv outputs.
> 
> The problem appears to be that Illumos stops after PCI address 0b:00.0
> (on-board MegaRAID SAS 2208). After that the scan should proceed with
> the QPI inter-processor links, but doesn't.
> 
> The full lspci should look something like this:
> 
> 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI..
> 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:02.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:02.3 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:03.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 00:04.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.5 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:04.7 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:05.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:05.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (r..
> 00:11.0 PCI bridge: Intel Corporation C600/X79 series chip..
> 00:16.0 Communication controller: Intel Corporation C600/X..
> 00:16.1 Communication controller: Intel Corporation C600/X..
> 00:1a.0 USB controller: Intel Corporation C600/X79 series ..
> 00:1d.0 USB controller: Intel Corporation C600/X79 series ..
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (re..
> 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chip..
> 00:1f.2 SATA controller: Intel Corporation C600/X79 series..
> 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset S..
> 00:1f.6 Signal processing controller: Intel Corporation C6..
> 02:00.0 Serial Attached SCSI controller: Intel Corporation..
> 03:00.0 SCSI storage controller: LSI Logic / Symbios Logic..
> 05:00.0 Ethernet controller: Intel Corporation 82599EB 10-..
> 05:00.1 Ethernet controller: Intel Corporation 82599EB 10-..
> 07:00.0 PCI bridge: Tundra Semiconductor Corp. Device 8113..
> 08:01.0 VGA compatible controller: Matrox Electronics Syst..
> 09:00.0 Ethernet controller: Intel Corporation I350 Gigabi..
> 09:00.1 Ethernet controller: Intel Corporation I350 Gigabi..
> 0b:00.0 RAID bus controller: LSI Logic / Symbios Logic Meg..
>     <<< Illumos gives up here, Linux continues >>>
> 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Co..
> 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 7f:13.1 Performance counters: Intel Corporation Xeon E5/Co..
> 7f:13.4 Performance counters: Intel Corporation Xeon E5/Co..
> 7f:13.5 Performance counters: Intel Corporation Xeon E5/Co..
> 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2..
> 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:02.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:03.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> 80:04.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.1 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.3 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.4 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.5 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.6 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:04.7 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:05.0 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:05.2 System peripheral: Intel Corporation Xeon E5/Core ..
> 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (r..
> 83:00.0 SCSI storage controller: LSI Logic / Symbios Logic..
> 
> See http://217.75.71.10/MB.png for the system interconnection diagram.
> Can somebody please recommend how to debug this issue?
> 
> Cheers,
> --
> Saso
> 
> 
> -------------------------------------------
> illumos-discuss
> Archives: https://www.listbox.com/member/archive/182180/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182180/22003744-9012f59c
> Modify Your Subscription: https://www.listbox.com/member/?member_id=22003744&id_secret=22003744-e9cd8436
> Powered by Listbox: http://www.listbox.com


From esproul at omniti.com  Wed May  1 11:35:27 2013
From: esproul at omniti.com (Eric Sproul)
Date: Wed, 1 May 2013 11:35:27 -0400
Subject: [OmniOS-discuss] Recommended way to keep Zones up to date?
In-Reply-To: <C09AE7C6-9D2B-4767-A6BF-69C7D1CC355D@gmail.com>
References: <C09AE7C6-9D2B-4767-A6BF-69C7D1CC355D@gmail.com>
Message-ID: <CA+QY2RSmdq8DjF7F=GSfBXkZfobx7TZ36RDL2P5O4y0HudJqdg@mail.gmail.com>

On Wed, May 1, 2013 at 12:21 AM, Philippe <philippe.hanrigou at gmail.com> wrote:
> Hi,
>
> <noob question>
> What is the recommended way to update the packages in the global and non global zones?
> </noob question>

A perfectly legitimate question, regardless of experience. :)

> I used to just run 'pkg update' in the global zone and then in each of the non-global zones. Since it is cumbersome, and the non global zones would always complain about not being able to update the boot environment, I googled around and decided to try the 'zoneadm -z my-zone detach' / 'zoneadm -z my-zone attach -u' strategy described in http://www.oracle.com/technetwork/articles/servers-storage-dev/updatesoftwarezones-450942.html#Upgrading. Not only it seemed non ideal to have to bring the zone offline, but once I detached it my zone would never attach again due to some incorporation problem that I could not troubleshoot due to my limited IPS understanding.

Using detach/'attach -u' is the recommended way to move zones between
stable releases of OmniOS.  Within a given stable release, a simple
'pkg update' from within the zone will suffice.  We try very hard not
to introduce breaking changes in core within a single release cycle.

Your issue with reattaching sounds like the attaching zone has a
different version of the 'entire' package than the global zone (you'll
see this in the output of the attach operation, and it also goes into
the attach log).  Did you upgrade the global at some point after the
zone in question was created?  If you could paste a copy of the attach
log where you see the failure, that would help.

>
> So my question is what is the best practice here? What should I have been doing all along (ideally without taking downtime)?

You should be able to run 'pkg update' within the zone for most
updates.  Only when moving between releases will you need to
detach/attach.

Eric

From contact at aakashsaini.com  Wed May  1 14:36:45 2013
From: contact at aakashsaini.com (Aakash Saini)
Date: Wed, 1 May 2013 11:36:45 -0700
Subject: [OmniOS-discuss] [developer] Re: [discuss] Trouble getting
 Supermicro board to see all its PCI-e slots
In-Reply-To: <4155DA97-43D5-4AC9-8178-2F9235B9DF8C@damore.org>
References: <517F9A19.7030707@gmail.com> <5180C94C.9020305@gmail.com>
	<4155DA97-43D5-4AC9-8178-2F9235B9DF8C@damore.org>
Message-ID: <CAEBSS5R3=KiwW1D5RYXLFzYT72ExLN9p_6=tP9erB-waaJoksg@mail.gmail.com>

>..."Strangely, however, prtdiag sees the slots as populated:"...

I don't understand how it could be pci_boot/create_bus issues; cause pci_boot
is functioning and allocating the buses *correctly* to relevant slots. As
stated, Left-hand has 4::x8-PCI-e slots (2-cpu1, 2-cpu2) and right-hand has
2::x8-PCI-e slots (2-cpu2), which we see through prtdiag details about
slots (1-to-6) assignments.

..which means socket 00 is working correctly, and socket 01 has some
fault!!. surprising, very much nailed correctly relating to QPI
interconnect issues. i guess PCH/C6xxx-chipset and motherboard specs need
to be reviewed.

prtpicl should display correctly details to resource addressing, cause
slots are assigned.

>..."The problem appears to be that Illumos doesn't recognize any PCI
bridges beyond those attached to CPU1.

yes, maybe its a PCIe-PCI bridging issue, even i doubt. try kdb debug
state...
::bp pcieb`pcieb_attach
:c
pcieb`pcieb_dbg_print/W 0x1    --- this should display basic
debugged information
:c

also. try with disabled (both) MSI and workaround patch to 41210/chipset
individually.
pcieb`pcieb_enable_msi/W 0x1
pcieb_disable_41210_wkarnd/W 0x1

i'm not sure if there is any resource conflict issue; mdb -k | ::interrupts
as obviously, h/w is remote!



-----------------------------------
Aakash Saini


On Wed, May 1, 2013 at 6:54 AM, Garrett D'Amore <garrett at damore.org> wrote:

> Check the value of pci_bios_maxbus.
>
> I have a sneaking feeling that the problem may be related to acpi
> enumeration of the bus.  We are limited to seeing the busses that ACPI
> properly enumerates.  Take a look at the code in pci_boot.c for more
> details.  You should especially note the call sites for
> create_pcie_root_bus.
>
> I'd love to help further, but lack of access to hardware that exhibits
> this problem prevents me from doing any active debug myself.
>
>         - Garrett
>
> On May 1, 2013, at 12:50 AM, Sa?o Kiselkov <skiselkov.ml at gmail.com> wrote:
>
> > Just a follow up on this: this appears to be an Illumos bug, though I
> > haven't figured out how to resolve it yet. The problem appears to be
> > that Illumos doesn't recognize any PCI bridges beyond those attached to
> > CPU1. Notably, nothing on CPU2 appears to work. I've tested with Linux
> > 3.5 and that works flawless, attached are the lspci -vvvv outputs.
> >
> > The problem appears to be that Illumos stops after PCI address 0b:00.0
> > (on-board MegaRAID SAS 2208). After that the scan should proceed with
> > the QPI inter-processor links, but doesn't.
> >
> > The full lspci should look something like this:
> >
> > 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI..
> > 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 00:02.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 00:02.3 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 00:03.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 00:04.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:04.1 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:04.2 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:04.3 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:04.4 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:04.5 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:04.6 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:04.7 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:05.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:05.2 System peripheral: Intel Corporation Xeon E5/Core ..
> > 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (r..
> > 00:11.0 PCI bridge: Intel Corporation C600/X79 series chip..
> > 00:16.0 Communication controller: Intel Corporation C600/X..
> > 00:16.1 Communication controller: Intel Corporation C600/X..
> > 00:1a.0 USB controller: Intel Corporation C600/X79 series ..
> > 00:1d.0 USB controller: Intel Corporation C600/X79 series ..
> > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (re..
> > 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chip..
> > 00:1f.2 SATA controller: Intel Corporation C600/X79 series..
> > 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset S..
> > 00:1f.6 Signal processing controller: Intel Corporation C6..
> > 02:00.0 Serial Attached SCSI controller: Intel Corporation..
> > 03:00.0 SCSI storage controller: LSI Logic / Symbios Logic..
> > 05:00.0 Ethernet controller: Intel Corporation 82599EB 10-..
> > 05:00.1 Ethernet controller: Intel Corporation 82599EB 10-..
> > 07:00.0 PCI bridge: Tundra Semiconductor Corp. Device 8113..
> > 08:01.0 VGA compatible controller: Matrox Electronics Syst..
> > 09:00.0 Ethernet controller: Intel Corporation I350 Gigabi..
> > 09:00.1 Ethernet controller: Intel Corporation I350 Gigabi..
> > 0b:00.0 RAID bus controller: LSI Logic / Symbios Logic Meg..
> >     <<< Illumos gives up here, Linux continues >>>
> > 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Co..
> > 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 7f:13.1 Performance counters: Intel Corporation Xeon E5/Co..
> > 7f:13.4 Performance counters: Intel Corporation Xeon E5/Co..
> > 7f:13.5 Performance counters: Intel Corporation Xeon E5/Co..
> > 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2..
> > 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 80:02.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 80:03.2 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO ..
> > 80:04.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:04.1 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:04.2 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:04.3 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:04.4 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:04.5 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:04.6 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:04.7 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:05.0 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:05.2 System peripheral: Intel Corporation Xeon E5/Core ..
> > 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (r..
> > 83:00.0 SCSI storage controller: LSI Logic / Symbios Logic..
> >
> > See http://217.75.71.10/MB.png for the system interconnection diagram.
> > Can somebody please recommend how to debug this issue?
> >
> > Cheers,
> > --
> > Saso
> >
> >
> > -------------------------------------------
> > illumos-discuss
> > Archives: https://www.listbox.com/member/archive/182180/=now
> > RSS Feed:
> https://www.listbox.com/member/archive/rss/182180/22003744-9012f59c
> > Modify Your Subscription: https://www.listbox.com/member/?&
> > Powered by Listbox: http://www.listbox.com
>
>
>
> -------------------------------------------
> illumos-developer
> Archives: https://www.listbox.com/member/archive/182179/=now
> RSS Feed:
> https://www.listbox.com/member/archive/rss/182179/24096868-ef9d90b8
> Modify Your Subscription:
> https://www.listbox.com/member/?member_id=24096868&id_secret=24096868-8ac1a962
> Powered by Listbox: http://www.listbox.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130501/a60ae93d/attachment.html>

From natxo.asenjo at gmail.com  Wed May  1 15:47:10 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Wed, 1 May 2013 21:47:10 +0200
Subject: [OmniOS-discuss] nfs server with kerberos
In-Reply-To: <20130501012406.GQ30773@bender.unx.csupomona.edu>
References: <CAHBEJzWmwvufCOsD=EN0jLCzn3sLz0uzhSFjHq6knxovGx5u+Q@mail.gmail.com>
	<CAHBEJzWX6x2+GTGMurOt2CqKUtNS0wh6fVT=x0y2SFBoGq=emg@mail.gmail.com>
	<20130501012406.GQ30773@bender.unx.csupomona.edu>
Message-ID: <CAHBEJzUsn941XaGw-TCQXzsWUsrBOPnaNEovwrS6MWhpc3xK9A@mail.gmail.com>

On Wed, May 1, 2013 at 3:24 AM, Paul B. Henson <henson at acm.org> wrote:

> On Fri, Apr 12, 2013 at 12:21:33PM +0200, Natxo Asenjo wrote:
>
> > is nfs with sec=krb5 (krb5i/krb5p, whatever), supposed to work with
> omnios?
> [...]
> > root at testomnios:~# share -F nfs -o sec=krb5 -d "homedirs" /export/home/
> > Could not share: /export/home: invalid security type
>
> Not sure if you've sorted this out yet, but a similar issue recently
> came up on the zfs mailing list for a user using OI:
>
>
> http://www.listbox.com/member/archive/182191/2013/04/sort/time_rev/page/1/entry/24:310/20130428222753:627B968C-B074-11E2-9F3A-95773EE4A36F/
>
> I haven't tested it, but I assume the solution (install a non-default
> krb5 package) would probably also fix the issue for omnios.
>
> Indeed it does! Thanks for the tip

# share
rpool_export_h  /export/home   sec=krb5   ""

-- 
groet,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130501/dfd12b42/attachment-0001.html>

From philippe.hanrigou at gmail.com  Wed May  1 16:35:03 2013
From: philippe.hanrigou at gmail.com (Philippe)
Date: Wed, 1 May 2013 13:35:03 -0700
Subject: [OmniOS-discuss] Recommended way to keep Zones up to date?
In-Reply-To: <CA+QY2RSmdq8DjF7F=GSfBXkZfobx7TZ36RDL2P5O4y0HudJqdg@mail.gmail.com>
References: <C09AE7C6-9D2B-4767-A6BF-69C7D1CC355D@gmail.com>
	<CA+QY2RSmdq8DjF7F=GSfBXkZfobx7TZ36RDL2P5O4y0HudJqdg@mail.gmail.com>
Message-ID: <F4117F5F-87F4-46AC-B54B-0E7A29E50C33@gmail.com>

Thanks for the clear explanation Eric. I makes me feel better about having the right procedure in place. The Solaris docs are great, but sometimes it is difficult to know for sure whether you are missing an important step or not?

My problem was indeed about the 'entire' package. Not sure where to find the logs now though. I ended up recreating the zones from scratch, which ended up surprisingly quick and simple since I had automation for it and the zones do enforce a clean separation between O.S. install and user data. Thank you OmniOS ;-)

Thanks again Eric,
- Philippe

On May 1, 2013, at 8:35 AM, Eric Sproul wrote:

> On Wed, May 1, 2013 at 12:21 AM, Philippe <philippe.hanrigou at gmail.com> wrote:
>> Hi,
>> 
>> <noob question>
>> What is the recommended way to update the packages in the global and non global zones?
>> </noob question>
> 
> A perfectly legitimate question, regardless of experience. :)
> 
>> I used to just run 'pkg update' in the global zone and then in each of the non-global zones. Since it is cumbersome, and the non global zones would always complain about not being able to update the boot environment, I googled around and decided to try the 'zoneadm -z my-zone detach' / 'zoneadm -z my-zone attach -u' strategy described in http://www.oracle.com/technetwork/articles/servers-storage-dev/updatesoftwarezones-450942.html#Upgrading. Not only it seemed non ideal to have to bring the zone offline, but once I detached it my zone would never attach again due to some incorporation problem that I could not troubleshoot due to my limited IPS understanding.
> 
> Using detach/'attach -u' is the recommended way to move zones between
> stable releases of OmniOS.  Within a given stable release, a simple
> 'pkg update' from within the zone will suffice.  We try very hard not
> to introduce breaking changes in core within a single release cycle.
> 
> Your issue with reattaching sounds like the attaching zone has a
> different version of the 'entire' package than the global zone (you'll
> see this in the output of the attach operation, and it also goes into
> the attach log).  Did you upgrade the global at some point after the
> zone in question was created?  If you could paste a copy of the attach
> log where you see the failure, that would help.
> 
>> 
>> So my question is what is the best practice here? What should I have been doing all along (ideally without taking downtime)?
> 
> You should be able to run 'pkg update' within the zone for most
> updates.  Only when moving between releases will you need to
> detach/attach.
> 
> Eric


From nsmith at careyweb.com  Wed May  1 17:08:02 2013
From: nsmith at careyweb.com (Nate Smith)
Date: Wed, 01 May 2013 17:08:02 -0400
Subject: [OmniOS-discuss] =?iso-8859-1?q?Newbie_Help=2E__Where=27s_my_netw?=
	=?iso-8859-1?q?ork_interface=3F?=
Message-ID: <20130501210802.fa6fd1af@mail.careyweb.com>

I just did a new install of OmniOS off the 

OmniOS_Text_r151004n.iso

I have been using systems and hardware that worked with openindiana, but my network interface is nowhere to be found.
I am using an intel Pro 1000P pci-e card on an Dell Poweredge 610.  I
It is listed as Intel Corporation 82546GB Gigabit Ethernet Controller in the illumian compatibility list
When I do an ifconfig -a, I only get the loopback interfaces.

I can use the network card in another OS, so I know nothing is wrong with it.  

Any help would be appreciated.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130501/b780d35f/attachment.html>

From henson at acm.org  Wed May  1 17:18:32 2013
From: henson at acm.org (Paul B. Henson)
Date: Wed, 1 May 2013 14:18:32 -0700
Subject: [OmniOS-discuss] Newbie Help.  Where's my network interface?
In-Reply-To: <20130501210802.fa6fd1af@mail.careyweb.com>
References: <20130501210802.fa6fd1af@mail.careyweb.com>
Message-ID: <20130501211832.GS30773@bender.unx.csupomona.edu>

On Wed, May 01, 2013 at 05:08:02PM -0400, Nate Smith wrote:

> When I do an ifconfig -a, I only get the loopback interfaces.

How about 'dladm show-phys'? The installer doesn't do any network
configuration, so until you do a 'ipadm create-if' the device won't show
up with ifconfig. To configure a static IP on a box with an Intel e1000
nic, you'd need to:

ipadm create-if e1000g0
ipadm create-addr -T static -a 1.2.3.4/24 e1000g0/v4
route -p add default 1.2.3.1


From dswartz at druber.com  Wed May  1 17:21:27 2013
From: dswartz at druber.com (Dan Swartzendruber)
Date: Wed, 1 May 2013 17:21:27 -0400
Subject: [OmniOS-discuss] Newbie Help.  Where's my network interface?
In-Reply-To: <20130501210802.fa6fd1af@mail.careyweb.com>
References: <20130501210802.fa6fd1af@mail.careyweb.com>
Message-ID: <64fd35e3922065f8ff7f8cf01abebd1f.squirrel@webmail.druber.com>

> I just did a new install of OmniOS off the
>
> OmniOS_Text_r151004n.iso
>
> I have been using systems and hardware that worked with openindiana, but
> my network interface is nowhere to be found.
> I am using an intel Pro 1000P pci-e card on an Dell Poweredge 610.  I
> It is listed as Intel Corporation 82546GB Gigabit Ethernet Controller in
> the illumian compatibility list
> When I do an ifconfig -a, I only get the loopback interfaces.

I believe you have to set it up yourself.  From here:

http://omnios.omniti.com/wiki.php/GeneralAdministration


From skiselkov.ml at gmail.com  Wed May  1 20:28:25 2013
From: skiselkov.ml at gmail.com (=?UTF-8?B?U2HFoW8gS2lzZWxrb3Y=?=)
Date: Thu, 02 May 2013 02:28:25 +0200
Subject: [OmniOS-discuss] [developer] Re: [discuss] Trouble getting
 Supermicro board to see all its PCI-e slots
In-Reply-To: <CAEBSS5R3=KiwW1D5RYXLFzYT72ExLN9p_6=tP9erB-waaJoksg@mail.gmail.com>
References: <517F9A19.7030707@gmail.com> <5180C94C.9020305@gmail.com>
	<4155DA97-43D5-4AC9-8178-2F9235B9DF8C@damore.org>
	<CAEBSS5R3=KiwW1D5RYXLFzYT72ExLN9p_6=tP9erB-waaJoksg@mail.gmail.com>
Message-ID: <5181B329.8020905@gmail.com>

Hi Aakash,

First of all, thanks for the many pointers here, I cannot begin to
describe the gratitude for your help. My responses to your suggestions
below.

On 05/01/2013 08:36 PM, Aakash Saini wrote:
>> ..."Strangely, however, prtdiag sees the slots as populated:"...
> 
> I don't understand how it could be pci_boot/create_bus issues; cause pci_boot
> is functioning and allocating the buses *correctly* to relevant slots. As
> stated, Left-hand has 4::x8-PCI-e slots (2-cpu1, 2-cpu2) and right-hand has
> 2::x8-PCI-e slots (2-cpu2), which we see through prtdiag details about
> slots (1-to-6) assignments.
> 
> ..which means socket 00 is working correctly, and socket 01 has some
> fault!!. surprising, very much nailed correctly relating to QPI
> interconnect issues. i guess PCH/C6xxx-chipset and motherboard specs need
> to be reviewed.
> 
> prtpicl should display correctly details to resource addressing, cause
> slots are assigned.

Attached, both the short and verbose version.

>> ..."The problem appears to be that Illumos doesn't recognize any PCI
> bridges beyond those attached to CPU1.
> 
> yes, maybe its a PCIe-PCI bridging issue, even i doubt. try kdb debug
> state...
> ::bp pcieb`pcieb_attach
> :c
> pcieb`pcieb_dbg_print/W 0x1    --- this should display basic
> debugged information
> :c

Compiled a debug version of the pcieb module and attached the output
from this. Strangely enough, the output stopped for considerable time
between lines 21 and 22 in the output, so between lines:

pcieb(0): pwrINITCHILD: config regs setup for pci15d9,690 at 0

and

pcieb(1): pwrpcieb_pwr_disable: disabling PM

after which lots of output proceeded quickly. Could it be that the
probing code is getting stuck on and then giving up on probing a bridge
here?

> also. try with disabled (both) MSI and workaround patch to 41210/chipset
> individually.
> pcieb`pcieb_enable_msi/W 0x1
> pcieb_disable_41210_wkarnd/W 0x1

Neither setting changed anything.

> i'm not sure if there is any resource conflict issue; mdb -k | ::interrupts
> as obviously, h/w is remote!

Here's the output of that:

# echo ::interrupts | mdb -k
CPU/Vect  IRQ IPL Bus    Trg Type   Share APIC/INT# ISR
1/0x20    9   9   PCI    Lvl Fixed  1     0x0/0x9   acpi_wrapper_isr
2/0x20    11  14  PCI    Lvl Fixed  1     0x0/0xb   hpet_isr
3/0x20    -   7   PCI    Edg MSI    1     -         pcieb_intr_handler
4/0x20    -   5   PCI    Edg MSI-X  1     -         mrsas_isr
7/0x20    1   5   ISA    Edg Fixed  1     0x0/0x1   i8042_intr
8/0x20    12  5   ISA    Edg Fixed  1     0x0/0xc   i8042_intr
8/0x22    -   5   PCI    Edg MSI    1     -         mpt_intr
12/0x20   3   12  ISA    Edg Fixed  1     0x0/0x3   asyintr
13/0x20   -   4   PCI    Edg MSI    1     -         pcieb_intr_handler
14/0x20   -   7   PCI    Edg MSI    1     -         pcieb_intr_handler
15/0x20   -   4   PCI    Edg MSI    1     -         pcieb_intr_handler
16/0x20   -   7   PCI    Edg MSI    1     -         pcieb_intr_handler
17/0x20   -   4   PCI    Edg MSI    1     -         pcieb_intr_handler
18/0x20   16  9   PCI    Lvl Fixed  1     0x0/0x10  ehci_intr
19/0x20   23  9   PCI    Lvl Fixed  1     0x0/0x17  ehci_intr
20/0x20   -   6   PCI    Edg MSI-X  1     -         igb_intr_tx_other
21/0x20   -   6   PCI    Edg MSI-X  1     -         igb_intr_rx
all/0xf0  -   15  -      Edg IPI    1     -         xc_serv
all/0xf1  -   11  -      Edg IPI    0     -         poke_cpu
all/0xf2  -   14  -      Edg IPI    1     -         kcpc_hw_overflow_intr
all/0xf3  -   15  -      Edg IPI    1     -         apic_error_intr
all/0xf4  -   2   -      Edg IPI    1     -         cmi_cmci_trap
all/0xf5  -   14  -      Edg IPI    1     -         cbe_fire
all/0xf6  -   14  -      Edg IPI    1     -         cbe_fire

Hope this provides more insight. If it helps, I can arrange for direct
access to the machine (both to the OS and the BMC).

Cheers,
--
Saso
-------------- next part --------------
  / (picl, f900000001)
     platform (upa, f900000005)
         scsi_vhci (devctl, f90000005c)
         pci (pciex, f900000079)
             pci15d9,720 (obp-device, f90000008e)
             pci8086,3c02 (pciex, f9000000af)
                 pci15d9,690 (obp-device, f9000000d6)
                     sd (block, f900000108)
             pci8086,3c04 (pciex, f900000126)
                 pci15d9,10fb (obp-device, f90000014e)
                 pci15d9,10fb (obp-device, f900000179)
             pci8086,3c06 (pciex, f9000001a3)
                 pci10e3,8113 (pci, f9000001ca)
                     display (display, f9000001ee)
             pci8086,3c07 (pciex, f900000214)
                 pci15d9,1521 (obp-device, f90000023b)
                 pci15d9,1521 (obp-device, f900000266)
             pci8086,3c08 (pciex, f900000290)
                 pci103c,322d (obp-device, f9000002b8)
             pci8086,3c0a (pciex, f9000002f6)
             pci15d9,720 (obp-device, f90000031a)
             pci15d9,720 (obp-device, f90000033c)
             pci15d9,720 (obp-device, f90000035e)
             pci15d9,720 (obp-device, f900000380)
             pci15d9,720 (obp-device, f9000003a2)
             pci15d9,720 (obp-device, f9000003c4)
             pci15d9,720 (obp-device, f9000003e6)
             pci15d9,720 (obp-device, f900000408)
             pci15d9,720 (obp-device, f90000042a)
             pci15d9,720 (obp-device, f90000044a)
             pci15d9,720 (obp-device, f90000046a)
             pci8086,1d3e (pciex, f900000487)
                 pci15d9,720 (obp-device, f9000004ad)
             pci15d9,720 (obp-device, f9000004cf)
             pci15d9,720 (obp-device, f9000004ee)
             pci15d9,720 (obp-device, f90000050d)
                 hub (obp-device, f900000537)
                     device (obp-device, f900000563)
                         mouse (obp-device, f900000583)
                         keyboard (obp-device, f90000059b)
             pci15d9,720 (obp-device, f9000005b3)
                 hub (obp-device, f9000005dd)
                     storage (obp-device, f900000609)
                         disk (block, f900000637)
             pci8086,244e (pci, f900000657)
             isa (isa, f900000679)
                 motherboard (obp-device, f90000069c)
                 i8042 (obp-device, f9000006a6)
                     mouse (obp-device, f9000006b1)
                 asy (serial, f9000006c0)
                 asy (serial, f9000006cf)
                 motherboard (obp-device, f9000006de)
                 motherboard (obp-device, f9000006e8)
             pci15d9,720 (obp-device, f9000006f2)
             pci15d9,720 (obp-device, f900000723)
             pci15d9,720 (obp-device, f900000742)
         pci (pciex, f900000778)
             pci15d9,720 (obp-device, f90000078b)
             pci15d9,720 (obp-device, f9000007a7)
             pci15d9,720 (obp-device, f9000007c7)
             pci15d9,720 (obp-device, f9000007e7)
             pci15d9,720 (obp-device, f900000803)
             pci15d9,720 (obp-device, f900000823)
             pci15d9,720 (obp-device, f900000843)
             pci15d9,720 (obp-device, f90000085f)
             pci15d9,720 (obp-device, f90000087b)
             pci15d9,720 (obp-device, f900000897)
             pci15d9,720 (obp-device, f9000008b3)
             pci15d9,720 (obp-device, f9000008cf)
             pci15d9,720 (obp-device, f9000008eb)
             pci15d9,720 (obp-device, f900000907)
             pci15d9,720 (obp-device, f900000923)
             pci15d9,720 (obp-device, f90000093f)
             pci15d9,720 (obp-device, f90000095b)
             pci15d9,720 (obp-device, f900000977)
             pci15d9,720 (obp-device, f900000993)
             pci15d9,720 (obp-device, f9000009af)
             pci15d9,720 (obp-device, f9000009cb)
             pci15d9,720 (obp-device, f9000009e7)
             pci15d9,720 (obp-device, f900000a03)
             pci15d9,720 (obp-device, f900000a1f)
             pci15d9,720 (obp-device, f900000a3f)
             pci15d9,720 (obp-device, f900000a5f)
             pci15d9,720 (obp-device, f900000a7f)
             pci15d9,720 (obp-device, f900000a9f)
             pci15d9,720 (obp-device, f900000abf)
             pci15d9,720 (obp-device, f900000adf)
             pci15d9,720 (obp-device, f900000afb)
             pci15d9,720 (obp-device, f900000b1b)
             pci15d9,720 (obp-device, f900000b3b)
             pci15d9,720 (obp-device, f900000b5b)
             pci15d9,720 (obp-device, f900000b7b)
             pci15d9,720 (obp-device, f900000b9b)
             pci15d9,720 (obp-device, f900000bbb)
             pci15d9,720 (obp-device, f900000bdb)
             pci8086,0 (obp-device, f900000bfb)
             pci15d9,720 (obp-device, f900000c17)
             pci15d9,720 (obp-device, f900000c33)
             pci15d9,720 (obp-device, f900000c4f)
             pci15d9,720 (obp-device, f900000c6b)
             pci15d9,720 (obp-device, f900000c87)
         pci (pciex, f900000ca3)
             pci8086,3c01 (pciex, f900000cb3)
             pci8086,3c02 (pciex, f900000cd6)
             pci8086,3c04 (pciex, f900000cf9)
                 pci103c,322d (obp-device, f900000d1d)
             pci8086,3c06 (pciex, f900000d40)
             pci8086,3c08 (pciex, f900000d64)
             pci8086,3c0a (pciex, f900000d88)
             pci15d9,720 (obp-device, f900000dac)
             pci15d9,720 (obp-device, f900000dce)
             pci15d9,720 (obp-device, f900000df0)
             pci15d9,720 (obp-device, f900000e12)
             pci15d9,720 (obp-device, f900000e34)
             pci15d9,720 (obp-device, f900000e56)
             pci15d9,720 (obp-device, f900000e78)
             pci15d9,720 (obp-device, f900000e9a)
             pci15d9,720 (obp-device, f900000ebc)
             pci15d9,720 (obp-device, f900000edc)
             pci15d9,720 (obp-device, f900000efc)
         fw (acpirootnex, f900000f19)
             sb (acpidevice, f900000f2f)
                 socket (acpicontainer, f900000f45)
                     cpu (cpu, f900000f5d)
                     cpu (cpu, f900000f9c)
                     cpu (cpu, f900000fdb)
                     cpu (cpu, f90000101a)
                     cpu (cpu, f900001059)
                     cpu (cpu, f900001098)
                     cpu (cpu, f9000010d7)
                     cpu (cpu, f900001116)
                     cpu (cpu, f900001155)
                     cpu (cpu, f900001194)
                     cpu (cpu, f9000011d3)
                     cpu (cpu, f900001212)
                 socket (acpicontainer, f900001251)
                     cpu (cpu, f900001269)
                     cpu (cpu, f9000012a8)
                     cpu (cpu, f9000012e7)
                     cpu (cpu, f900001326)
                     cpu (cpu, f900001365)
                     cpu (cpu, f9000013a4)
                     cpu (cpu, f9000013e3)
                     cpu (cpu, f900001422)
                     cpu (cpu, f900001461)
                     cpu (cpu, f9000014a0)
                     cpu (cpu, f9000014df)
                     cpu (cpu, f90000151e)
         agpgart (agpgart, f900001580)
         pseudo (devctl, f900001593)
             zconsnex (devctl, f90000159c)
             fct (admin, f9000015a5)
             stmf (admin, f9000015ad)
             stmf_sbd (admin, f9000015b5)
             ppm (ppm, f9000015be)
             power (power_button, f90000164e)
     obp (picl, f900000059)
         ioapics (ioapics, f900000760)
             ioapic (ioapic, f900000766)
             ioapic (ioapic, f90000076f)
         used-resources (used-resources, f90000155d)
         iscsi (iscsi, f900001567)
         options (options, f900001589)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prtpicl-v.txt.gz
Type: application/x-gzip
Size: 18878 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130502/f75eca5c/attachment-0001.bin>
-------------- next part --------------
Loading kmdb...

Welcome to kmdb
kmdb: unable to determine terminal type: assuming `vt100'
Loaded modules: [ unix krtld genunix ]
[0]> ::bp pcieb`pcieb_attach
[0]> :c
SunOS Release 5.11 Version omnios-bc85f2d 64-bit
Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved.
Loaded modules: [ scsi_vhci mac uppc zfs apix specfs pcplusmp cpu.generic ]
kmdb: stop at pcieb`pcieb_attach
kmdb: target stopped at:
pcieb`pcieb_attach:     pushq  %rbp
[0]> pcieb`pcieb_dbg_print/W 0x1
pcieb`pcieb_dbg_print:          0               =       0x1
[0]> ::delete 1
[0]> :c
pcieb(0): pwrpcieb_pwr_disable: disabling PM
pcieb(0): attachpcieb_intr_init: Attaching MSI handler
pcieb(0): attachbdf 0xf7ad82a9: ddi_intr_get_nintrs: nintrs 8pcieb(0): attachVID:0x8086 DID:0x3c02 RID:0x7 bdf=0x8
pcieb(0): pwrINITCHILD: config regs setup for pci15d9,690 at 0
pcieb(1): pwrpcieb_pwr_disable: disabling PM
pcieb(1): attachpcieb_intr_init: Attaching MSI handler
pcieb(1): attachbdf 0xf7ad82a9: ddi_intr_get_nintrs: nintrs 16pcieb(1): attachVID:0x8086 DID:0x3c04 RID:0x7 bdf=0x10
pcieb(2): pwrpcieb_pwr_disable: disabling PM
pcieb(2): attachpcieb_intr_init: Attaching MSI handler
pcieb(2): attachbdf 0xf7ad82a9: ddi_intr_get_nintrs: nintrs 18pcieb(2): attachVID:0x8086 DID:0x3c06 RID:0x7 bdf=0x12
pcieb(3): pwrpcieb_pwr_disable: disabling PM
pcieb(3): attachpcieb_intr_init: Attaching MSI handler
pcieb(3): attachbdf 0xf7ad82a9: ddi_intr_get_nintrs: nintrs 19pcieb(3): attachVID:0x8086 DID:0x3c07 RID:0x7 bdf=0x13
pcieb(4): pwrpcieb_pwr_disable: disabling PM
pcieb(4): attachpcieb_intr_init: Attaching MSI handler
pcieb(4): attachbdf 0xf7ad82a9: ddi_intr_get_nintrs: nintrs 24pcieb(4): attachVID:0x8086 DID:0x3c08 RID:0x7 bdf=0x18
pcieb(6): pwrpcieb_pwr_disable: disabling PM
pcieb(6): attachpcieb_intr_init: Attaching MSI handler
pcieb(6): attachbdf 0xf7ad82a9: ddi_intr_get_nintrs: nintrs 136pcieb(6): attachVID:0x8086 DID:0x1d3e RID:0x6 bdf=0x88
pcieb(2): pwrINITCHILD: config regs setup for pci10e3,8113 at 0
pcieb(7): pwrpcieb_pwr_disable: disabling PM
pcieb(7): attachpcieb_intr_init: Attaching INTx handler
pcieb(7): attachVID:0x10e3 DID:0x8113 RID:0x1 bdf=0x700
pcieb(7): pwrINITCHILD: config regs setup for display at 1
pcieb(3): pwrINITCHILD: config regs setup for pci15d9,1521 at 0
Hostname: head2
pcieb(3): pwrINITCHILD: config regs setup for pci15d9,1521 at 0,1
pcieb(1): pwrINITCHILD: config regs setup for pci15d9,10fb at 0
pcieb(1): pwrINITCHILD: config regs setup for pci15d9,10fb at 0,1
pcieb(4): pwrINITCHILD: config regs setup for pci103c,322d at 0

head2 console login: 

From skiselkov.ml at gmail.com  Thu May  2 03:13:15 2013
From: skiselkov.ml at gmail.com (=?windows-1252?Q?Sa=9Ao_Kiselkov?=)
Date: Thu, 02 May 2013 09:13:15 +0200
Subject: [OmniOS-discuss] [developer] Re: [discuss] Trouble getting
 Supermicro board to see all its PCI-e slots
In-Reply-To: <CAEBSS5Rh4SwS+1PefYWZp3ZKoqpy+rkXzce=iOL-rQKNHNf1bg@mail.gmail.com>
References: <517F9A19.7030707@gmail.com> <5180C94C.9020305@gmail.com>
	<4155DA97-43D5-4AC9-8178-2F9235B9DF8C@damore.org>
	<CAEBSS5R3=KiwW1D5RYXLFzYT72ExLN9p_6=tP9erB-waaJoksg@mail.gmail.com>
	<5181B329.8020905@gmail.com>
	<CAEBSS5Rh4SwS+1PefYWZp3ZKoqpy+rkXzce=iOL-rQKNHNf1bg@mail.gmail.com>
Message-ID: <5182120B.8010605@gmail.com>

On 05/02/2013 08:56 AM, Aakash Saini wrote:
> I don't know what system is doing.. if its PSM probing issue, could you
> check it following
> option edited/entered in file /etc/system and reboot.
> 
> set apix_enable = 0x0

Unfortunately, that didn't help.

> sorry, my typing error. it should have been zero not one;
> pcieb`pcieb_enable_msi/W 0x0

No problem, I figured that out and tried that already.

> handlers look ok here... let see if things workout with basic options,
> else would require access to h/w.

I'm gonna put the machine on the net for you to access and I'll send you
the access credentials over private email.

Again, many thanks for helping me out with this!

Cheers,
--
Saso

From contact at aakashsaini.com  Thu May  2 02:56:14 2013
From: contact at aakashsaini.com (Aakash Saini)
Date: Wed, 1 May 2013 23:56:14 -0700
Subject: [OmniOS-discuss] [developer] Re: [discuss] Trouble getting
 Supermicro board to see all its PCI-e slots
In-Reply-To: <5181B329.8020905@gmail.com>
References: <517F9A19.7030707@gmail.com> <5180C94C.9020305@gmail.com>
	<4155DA97-43D5-4AC9-8178-2F9235B9DF8C@damore.org>
	<CAEBSS5R3=KiwW1D5RYXLFzYT72ExLN9p_6=tP9erB-waaJoksg@mail.gmail.com>
	<5181B329.8020905@gmail.com>
Message-ID: <CAEBSS5Rh4SwS+1PefYWZp3ZKoqpy+rkXzce=iOL-rQKNHNf1bg@mail.gmail.com>

Hi Saso,
Please see reply within email.

 > prtpicl should display correctly details to resource addressing, cause
> > slots are assigned.
>
> Attached, both the short and verbose version.
>
I will check that.


>  >> ..."The problem appears to be that Illumos doesn't recognize any PCI
> > bridges beyond those attached to CPU1.
> >
> > yes, maybe its a PCIe-PCI bridging issue, even i doubt. try kdb debug
> > state...
> > ::bp pcieb`pcieb_attach
> > :c
> > pcieb`pcieb_dbg_print/W 0x1    --- this should display basic
> > debugged information
> > :c
>
> Compiled a debug version of the pcieb module and attached the output
> from this. Strangely enough, the output stopped for considerable time
> between lines 21 and 22 in the output, so between lines:
>
> pcieb(0): pwrINITCHILD: config regs setup for pci15d9,690 at 0
>
> and
>
> pcieb(1): pwrpcieb_pwr_disable: disabling PM



> after which lots of output proceeded quickly. Could it be that the
> probing code is getting stuck on and then giving up on probing a bridge
> here?
>

I don't know what system is doing.. if its PSM probing issue, could you
check it following
option edited/entered in file /etc/system and reboot.

set apix_enable = 0x0



>  > also. try with disabled (both) MSI and workaround patch to 41210/chipset
> > individually.
> > pcieb`pcieb_enable_msi/W 0x1
> > pcieb_disable_41210_wkarnd/W 0x1
>
> Neither setting changed anything.
>

sorry, my typing error. it should have been zero not one;
pcieb`pcieb_enable_msi/W 0x0



 > i'm not sure if there is any resource conflict issue; mdb -k |
> ::interrupts
> > as obviously, h/w is remote!
>
> Here's the output of that:
>
> # echo ::interrupts | mdb -k
> CPU/Vect  IRQ IPL Bus    Trg Type   Share APIC/INT# ISR
> 1/0x20    9   9   PCI    Lvl Fixed  1     0x0/0x9   acpi_wrapper_isr
> 2/0x20    11  14  PCI    Lvl Fixed  1     0x0/0xb   hpet_isr
> 3/0x20    -   7   PCI    Edg MSI    1     -         pcieb_intr_handler
> 4/0x20    -   5   PCI    Edg MSI-X  1     -         mrsas_isr
> 7/0x20    1   5   ISA    Edg Fixed  1     0x0/0x1   i8042_intr
> 8/0x20    12  5   ISA    Edg Fixed  1     0x0/0xc   i8042_intr
> 8/0x22    -   5   PCI    Edg MSI    1     -         mpt_intr
> 12/0x20   3   12  ISA    Edg Fixed  1     0x0/0x3   asyintr
> 13/0x20   -   4   PCI    Edg MSI    1     -         pcieb_intr_handler
> 14/0x20   -   7   PCI    Edg MSI    1     -         pcieb_intr_handler
> 15/0x20   -   4   PCI    Edg MSI    1     -         pcieb_intr_handler
> 16/0x20   -   7   PCI    Edg MSI    1     -         pcieb_intr_handler
> 17/0x20   -   4   PCI    Edg MSI    1     -         pcieb_intr_handler
> 18/0x20   16  9   PCI    Lvl Fixed  1     0x0/0x10  ehci_intr
> 19/0x20   23  9   PCI    Lvl Fixed  1     0x0/0x17  ehci_intr
> 20/0x20   -   6   PCI    Edg MSI-X  1     -         igb_intr_tx_other
> 21/0x20   -   6   PCI    Edg MSI-X  1     -         igb_intr_rx
> all/0xf0  -   15  -      Edg IPI    1     -         xc_serv
> all/0xf1  -   11  -      Edg IPI    0     -         poke_cpu
> all/0xf2  -   14  -      Edg IPI    1     -         kcpc_hw_overflow_intr
> all/0xf3  -   15  -      Edg IPI    1     -         apic_error_intr
> all/0xf4  -   2   -      Edg IPI    1     -         cmi_cmci_trap
> all/0xf5  -   14  -      Edg IPI    1     -         cbe_fire
> all/0xf6  -   14  -      Edg IPI    1     -         cbe_fire
>
> Hope this provides more insight. If it helps, I can arrange for direct
> access to the machine (both to the OS and the BMC).
>

handlers look ok here... let see if things workout with basic options,
else would require access to h/w.

Cheers,




> Cheers,
> --
> Saso
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130501/f770e0c2/attachment.html>

From omnios at citrus-it.net  Fri May  3 05:29:53 2013
From: omnios at citrus-it.net (Andy)
Date: Fri, 3 May 2013 09:29:53 +0000 (GMT)
Subject: [OmniOS-discuss] Customising a kayak build image.
Message-ID: <alpine.GSO.2.00.1305030918190.25758@areb.pvgehf-vg.arg>


I saw a question in the mailing list archives from last month on how to
customise a kayak build image - it was before I joined the list  so I can't
reply to that thread, but this is how I have customised the current stable
image for us. Hope it's useful to somebody:

#!/bin/sh

# This script takes an OmniOS ZFS install image and creates a Citrus IT
# image from it. It:
#	Updates the image with latest packages from the repository;
#	Installs additional OmniOS packages;
#	Adds the Citrus repository to the package framework;
#	Installs Citrus packages;
# The resulting image is created in the current directory and called
# omnios-citrus.zfs.bz2

image="${1}"
img=rpool/img

if [ -n "$image" ]; then
	if [ ! -r "$image" ]; then
		echo "Cannot open image '$image'"
		exit 1
	fi
	echo "Destroying old image filesystem..."
	zfs destroy -r $img
	bzip2 -dc $image | pv -B 128m | zfs recv $img || exit 1
	shift
elif ! zfs list $img > /dev/null 2>&1; then
	echo "No existing image."
	exit 1
fi

zfs destroy $img at kayak

# Install additional packages

echo "+ Installing additional packages..."

pkg -R /$img install \
	developer/gcc46 \
	developer/object-file \
	developer/linker \
	developer/library/lint \
	developer/build/gnu-make \
	system/header \
	system/library/math/header-math \
	pciutils \
	rsync \
	compress/xz \
	driver/ipmi \
	system/management/ipmitool \
	system/library/pcap \
	developer/parser/bison  \


echo "+ Updating build..."

# Update build
pkg -R /$img update

echo "+ Installing Citrus IT Packages..."

pkg -R /$img set-publisher -g https://ips.citrus-it.net/ citrus

# Install Citrus Packages

pkg -R /$img install \
	citrus/postinstall \
	developer/versioning/svn \
	citrus/smtp/sendmail \
	system/library/bdb  \
	system/utility/cmake \
	... elided ...


# Install newer BNX driver
cp /kernel/drv/amd64/bnx /$img/kernel/drv/amd64/bnx

# Create new image

zfs snapshot $img at kayak || exit 1

zfs send $img at kayak | bzip2 -9c | pv -B 128m > omnios-citrus.zfs.bz2




-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From natxo.asenjo at gmail.com  Sat May  4 09:36:18 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sat, 4 May 2013 15:36:18 +0200
Subject: [OmniOS-discuss] 4k sectors on a kvm guest
Message-ID: <CAHBEJzWRdDdgLjptrPMW9JZ-ZTC8z5t6cGyZO9VE4RdiS8qSVQ@mail.gmail.com>

hi,

before running a real hardware omnios host I am learning how to use it in a
kvm vm running on centos.

The disk performance is quite poor, this is partly due to omnios not using
virtio hard drives but ide drives. But I think the root zpool is not
properly aligned either:

root at testomnios:~# zdb -C rpool | grep ashift
                ashift: 9

this should be 12 to be aligned to 4k sectors I understand. Is there a way
to change this?

TIA,
--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130504/df1425ff/attachment.html>

From natxo.asenjo at gmail.com  Mon May  6 14:36:33 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Mon, 6 May 2013 20:36:33 +0200
Subject: [OmniOS-discuss] trouble mirroring the zpool rpool
Message-ID: <CAHBEJzXQSW+Bhp0A-uVy8VJx-TWbA9LD=Lw0q+EUFTAFTGAgvw@mail.gmail.com>

hi,

I have installed omnios with a 32GiB usb stick as the rpool. I have two of
those sticks, so I would like to mirror them.

rmformat tells me this about the usb sticks:

# rmformat
Looking for devices...
     1. Logical Node: /dev/rdsk/c14t0d0p0
        Physical Node: /pci at 0,0/pci103c,1609 at 12,2/storage at 3/disk at 0,0
        Connected Device:          Patriot Memory   PMAP
        Device Type: Removable
        Bus: USB
        Size: 30.2 GB
        Label: <None>
        Access permissions: Medium is not write protected.
     2. Logical Node: /dev/rdsk/c15t0d0p0
        Physical Node: /pci at 0,0/pci103c,1609 at 12,2/storage at 4/disk at 0,0
        Connected Device:          Patriot Memory   PMAP
        Device Type: Removable
        Bus: USB
        Size: 30.2 GB
        Label: <None>
        Access permissions: Medium is not write protected.

The sticks are exactly the same brand and model, so they should be exactly
equal.

In order to mirror the rpool I followed the instructions in
http://wiki.openindiana.org/oi/2.1+Post-installation

This is rpool now:

# zpool status rpool
  pool: rpool
 state: ONLINE
  scan: none requested
config:

        NAME         STATE     READ WRITE CKSUM
        rpool        ONLINE       0     0     0
          c14t0d0s0  ONLINE       0     0     0

errors: No known data errors

But when I try the procedure in the openindiana wiki I get this:

# fdisk -B c15t0d0p0
# prtvtoc /dev/rdsk/c14t0d0s2 | fmthard -s - /dev/rdsk/c15t0d0s2
fmthard: Partition 2 specifies the full disk and is not equal
full size of disk.  The full disk capacity is 61705665 sectors.
fmthard: Partition 2 specified as 61737795 sectors starting at 0
        does not fit. The full disk contains 61705665 sectors.
fmthard:  New volume table of contents now in place.
# zpool attach rpool c14t0d0s0 c15t0d0s0
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c15t0d0s0 overlaps with /dev/dsk/c15t0d0s2

So apparently the 2 sticks are not exactly the same. Now I got brave (haha)
and used the -f swith and it works:

# zpool attach -f rpool c14t0d0s0 c15t0d0s0
Make sure to wait until resilver is done before rebooting.

# zpool status
  pool: rpool
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon May  6 20:33:17 2013
    53.2M scanned out of 7.13G at 1.06M/s, 1h53m to go
    51.0M resilvered, 0.73% done
config:

        NAME           STATE     READ WRITE CKSUM
        rpool          ONLINE       0     0     0
          mirror-0     ONLINE       0     0     0
            c14t0d0s0  ONLINE       0     0     0
            c15t0d0s0  ONLINE       0     0     0  (resilvering)

errors: No known data errors

Is this expected behaviour?
--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130506/874527d9/attachment.html>

From jmsrinivas at yahoo.com  Tue May  7 08:17:21 2013
From: jmsrinivas at yahoo.com (srinivas jonn)
Date: Tue, 7 May 2013 20:17:21 +0800 (SGT)
Subject: [OmniOS-discuss] omnios stable r151006
Message-ID: <1367929041.60105.YahooMailNeo@web190805.mail.sg3.yahoo.com>

Hello,

is there a ISO package available for new stable build r151006? Could not find any on website

the release notes are interesting:

Highlights:
	* LZ4 compression is available for ZFS filesystems and is supported by GRUB 
	* Allow operator setting of TCP initial congestion window (OmniOS ticket #52) 
	* GNU automake packages developer/build/automake-111 and developer/build/automake-19 deprecated and replaced by developer/build/automake 
	* Packages runtime/perl-5142 and runtime/perl-5161 are deprecated, and the Perl package has been renamed to runtime/perl based on Perl 5.16.1 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130507/ea308b9f/attachment.html>

From jesus at omniti.com  Tue May  7 09:45:25 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Tue, 7 May 2013 09:45:25 -0400
Subject: [OmniOS-discuss] omnios stable r151006
In-Reply-To: <1367929041.60105.YahooMailNeo@web190805.mail.sg3.yahoo.com>
References: <1367929041.60105.YahooMailNeo@web190805.mail.sg3.yahoo.com>
Message-ID: <CACLsApsHg4TgSoXAkXSVtcLemEZ15jQ5THCx2qum6rWkoqwQiQ@mail.gmail.com>

There's no release date because it isn't released yet.  There will be
announcement soon.


On Tue, May 7, 2013 at 8:17 AM, srinivas jonn <jmsrinivas at yahoo.com> wrote:

> Hello,
>
> is there a ISO package available for new stable build r151006? Could not
> find any on website
>
> the release notes are interesting:
>
> Highlights:
>
>    - LZ4 compression is available for ZFS filesystems and is supported by
>    GRUB
>    - Allow operator setting of TCP initial congestion window (OmniOS
>    ticket #52 <http://omnios.omniti.com/ticket.php/52>)
>    - GNU automake packages developer/build/automake-111 and
>    developer/build/automake-19 deprecated and replaced by
>    developer/build/automake
>    - Packages runtime/perl-5142 and runtime/perl-5161 are deprecated, and
>    the Perl package has been renamed to runtime/perl based on Perl 5.16.1
>
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>


-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130507/c1f39692/attachment.html>

From natxo.asenjo at gmail.com  Tue May  7 17:27:34 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Tue, 7 May 2013 23:27:34 +0200
Subject: [OmniOS-discuss] trouble mirroring the zpool rpool
In-Reply-To: <CAHBEJzXQSW+Bhp0A-uVy8VJx-TWbA9LD=Lw0q+EUFTAFTGAgvw@mail.gmail.com>
References: <CAHBEJzXQSW+Bhp0A-uVy8VJx-TWbA9LD=Lw0q+EUFTAFTGAgvw@mail.gmail.com>
Message-ID: <CAHBEJzVPFZhhgagbR3SW1BWaKZhBxyDN_iWX31TxvVFXAhAVvA@mail.gmail.com>

hi,

fwiw, it worked:

# zpool status rpool
  pool: rpool
 state: ONLINE
  scan: resilvered 7.14G in 0h26m with 0 errors on Mon May  6 20:59:19 2013
config:

        NAME           STATE     READ WRITE CKSUM
        rpool          ONLINE       0     0     0
          mirror-0     ONLINE       0     0     0
            c14t0d0s0  ONLINE       0     0     0
            c15t0d0s0  ONLINE       0     0     0

errors: No known data errors

strange though (for me at least, if I see such an error as 'use '-f' to
override the following errors:
/dev/dsk/c15t0d0s0 overlaps with /dev/dsk/c15t0d0s2' it makes me nervous).

-- 
groet,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130507/6d1daee6/attachment.html>

From lotheac at iki.fi  Tue May  7 18:07:54 2013
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 8 May 2013 01:07:54 +0300
Subject: [OmniOS-discuss] trouble mirroring the zpool rpool
In-Reply-To: <CAHBEJzXQSW+Bhp0A-uVy8VJx-TWbA9LD=Lw0q+EUFTAFTGAgvw@mail.gmail.com>
References: <CAHBEJzXQSW+Bhp0A-uVy8VJx-TWbA9LD=Lw0q+EUFTAFTGAgvw@mail.gmail.com>
Message-ID: <20130507220754.GD27945@lotheac.fi>

On Mon, May 06 2013 20:36:33 +0200, Natxo Asenjo wrote:
> But when I try the procedure in the openindiana wiki I get this:
> 
> # fdisk -B c15t0d0p0
> # prtvtoc /dev/rdsk/c14t0d0s2 | fmthard -s - /dev/rdsk/c15t0d0s2
> fmthard: Partition 2 specifies the full disk and is not equal
> full size of disk.  The full disk capacity is 61705665 sectors.
> fmthard: Partition 2 specified as 61737795 sectors starting at 0
>         does not fit. The full disk contains 61705665 sectors.
> fmthard:  New volume table of contents now in place.
> # zpool attach rpool c14t0d0s0 c15t0d0s0
> invalid vdev specification
> use '-f' to override the following errors:
> /dev/dsk/c15t0d0s0 overlaps with /dev/dsk/c15t0d0s2

Those devices refer to disk slices (hence the 's' at the end), and slice
number two refers to the entire disk by convention (but not necessarily;
for more information see
http://docs.oracle.com/cd/E19082-01/819-2723/disksconcepts-20068/index.html),
so it will overlap any other slice.

zpool is correct in warning you about this, but in many cases you might
just want to use the entire disk ('c15t0d0' should work). I'm not sure
whether you can do that with rpool disks though, since they need to boot
from somewhere.

-- 
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet

From richard.palo at baou.fr  Wed May  8 03:31:12 2013
From: richard.palo at baou.fr (Richard PALO)
Date: Wed, 08 May 2013 09:31:12 +0200
Subject: [OmniOS-discuss] some problems with last update to bloody
	omnios-8d266aa 64-bit
Message-ID: <kmcuvs$jmu$1@ger.gmane.org>

Hi, yesterday I did a pkg update on bloody and came across this:
> richard at omni1:~$ svcs -xv
> svc:/system/intrd:default (interrupt balancer)
>  State: maintenance since  7 mai 2013 20:56:19 CEST
> Reason: Restarting too quickly.
>    See: http://illumos.org/msg/SMF-8000-L5
>    See: man -M /usr/share/man -s 1M intrd
>    See: /var/svc/log/system-intrd:default.log
> Impact: This service is not running.
> richard at omni1:~$ tail /var/svc/log/system-intrd:default.log
> [ mai  7 20:56:19 Method "start" exited with status 0. ]
> Can't locate Sun/Solaris/Kstat.pm in @INC (@INC contains: /usr/perl5/site_perl/5.16/i86pc-solaris-thread-multi-64int /usr/perl5/site_perl/5.16 /usr/perl5/vendor_perl/5.16/i86pc-solaris-thread-multi-64int /usr/perl5/vendor_perl/5.16 /usr/perl5/lib/i86pc-solaris-thread-multi-64int /usr/perl5/lib .) at /usr/lib/intrd line 66.
> [ mai  7 20:56:19 Stopping because all processes in service exited. ]
> [ mai  7 20:56:19 Executing stop method (:kill). ]
> [ mai  7 20:56:19 Executing start method ("/lib/svc/method/svc-intrd"). ]
> [ mai  7 20:56:19 Method "start" exited with status 0. ]
> Can't locate Sun/Solaris/Kstat.pm in @INC (@INC contains: /usr/perl5/site_perl/5.16/i86pc-solaris-thread-multi-64int /usr/perl5/site_perl/5.16 /usr/perl5/vendor_perl/5.16/i86pc-solaris-thread-multi-64int /usr/perl5/vendor_perl/5.16 /usr/perl5/lib/i86pc-solaris-thread-multi-64int /usr/perl5/lib .) at /usr/lib/intrd line 66.
> [ mai  7 20:56:19 Stopping because all processes in service exited. ]
> [ mai  7 20:56:19 Executing stop method (:kill). ]
> [ mai  7 20:56:19 Restarting too quickly, changing state to maintenance. ]



From ben at fluffy.co.uk  Wed May  8 09:50:23 2013
From: ben at fluffy.co.uk (Ben Summers)
Date: Wed, 8 May 2013 14:50:23 +0100
Subject: [OmniOS-discuss] Trust and OmniOS installs
Message-ID: <65CFF923-0D4C-401A-966E-480D0065DF5B@fluffy.co.uk>


Hello,

I'm rebuilding our infrastructure based on OmniOS, migrating away from Solaris 10. It's great to have a modern and minimal Solarish OS for which you can buy a support contract. (And that vendor not be Oracle.)

We do have one slight problem in our environment, that we have to trust the network to be able to use the OmniTI repos since they're served over plain HTTP.

Obviously we have to trust our OS vendor, but I suspect the requirement to trust the network would cause problems with audits from our customers. And besides, we're a security focused company offering a "secure" service, so I like to do things properly.

Unless OmniTI are kind enough enable https on pkg.omniti.com, is there a way to minimise the number of third parties we are trusting?

Could we create a mirror somehow over our relatively trusted network in the colo? Or would a simple https proxy work?

Many thanks for any suggestions,

Ben



--
http://bens.me.uk


From daleg at omniti.com  Wed May  8 16:22:16 2013
From: daleg at omniti.com (Dale Ghent)
Date: Wed, 8 May 2013 16:22:16 -0400
Subject: [OmniOS-discuss] New stable release: r151006
Message-ID: <28A636E8-7E62-4A5A-8782-A6613B653875@omniti.com>


The number 6 is considered to be a harmonious number, one which brings with it caring, healing, and protection. OmniOS r151006 also embodies these traits, and as such we are announcing its availability.

r151006 release notes may be found here:
* https://src.omniti.com/omnios-private/wiki.php/ReleaseNotes

Upgrade instructions may be found here:
* https://src.omniti.com/omnios-private/wiki.php/Upgrade_r151004_r151006

Installation media links:
* http://omnios.omniti.com/media/OmniOS_Text_r151006.iso (CD ISO)
* http://omnios.omniti.com/media/OmniOS_Text_r151006.usb-dd (USB image)
* http://omnios.omniti.com/media/r151004.zfs.bz2 (ZFS image, for use with Kayak)

The omnios release pkg repo has been updated with 151006 packages
* http://pkg.omniti.com/omnios/release/

Enjoy
/dale

From kajtzu at a51.org  Wed May  8 16:26:18 2013
From: kajtzu at a51.org (Kaj Niemi)
Date: Wed, 8 May 2013 20:26:18 +0000
Subject: [OmniOS-discuss] New stable release: r151006
In-Reply-To: <28A636E8-7E62-4A5A-8782-A6613B653875@omniti.com>
References: <28A636E8-7E62-4A5A-8782-A6613B653875@omniti.com>
Message-ID: <D8AE9578-EF8C-4DE2-B611-B1A0478BFBC5@a51.org>

Hi,


I think you meant https://src.omniti.com/omnios/wiki.php/ReleaseNotes and not the one below (which requires login).. right?




Kaj




On May 8, 2013, at 23:22, Dale Ghent <daleg at omniti.com> wrote:

> 
> r151006 release notes may be found here:
> * https://src.omniti.com/omnios-private/wiki.php/ReleaseNotes
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4383 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130508/396b3b6a/attachment.bin>

From daleg at omniti.com  Wed May  8 16:26:42 2013
From: daleg at omniti.com (Dale Ghent)
Date: Wed, 8 May 2013 16:26:42 -0400
Subject: [OmniOS-discuss] UPDATED New stable release: r151006
In-Reply-To: <28A636E8-7E62-4A5A-8782-A6613B653875@omniti.com>
References: <28A636E8-7E62-4A5A-8782-A6613B653875@omniti.com>
Message-ID: <C82BAA68-4480-43FE-B7A8-A21F9A1C2AD6@omniti.com>


Let's try this again, with links people can actually read *blames release fever*

The number 6 is considered to be a harmonious number, one which brings with it caring, healing, and protection. OmniOS r151006 also embodies these traits, and as such we are announcing its availability.

r151006 release notes may be found here:
* http://omnios.omniti.com/wiki.php/ReleaseNotes

Upgrade instructions may be found here:
* http://omnios.omniti.com/wiki.php/Upgrade_r151004_r151006

Installation media links:
* http://omnios.omniti.com/media/OmniOS_Text_r151006.iso (CD ISO)
* http://omnios.omniti.com/media/OmniOS_Text_r151006.usb-dd (USB image)
* http://omnios.omniti.com/media/r151006.zfs.bz2 (ZFS image, for use with Kayak)

The omnios release pkg repo has been updated with 151006 packages
* http://pkg.omniti.com/omnios/release/

Enjoy
/dale


From ctordtor at yahoo.fr  Thu May  9 10:28:26 2013
From: ctordtor at yahoo.fr (Matthieu Paindavoine)
Date: Thu, 9 May 2013 15:28:26 +0100 (BST)
Subject: [OmniOS-discuss] cannot remove temp dir
Message-ID: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>

Hello,

I am new to OmniOS. I am trying to setup a Haskell development environment and ran against a bump that's preventing me from completing the task. I mentioned this problem yesterday on IRC and got some help, but no definitive solution.

The Haskell build tool is cabal, and after successfully installing the Haskell compiler (ghc-7.4.2) I want to update the build tool. But this step fails, and the log indicates that it cannot remove a temporary directory it created.

I tried to remove it manually (rm -fr /tmp/foo as root) but it fails:
rm: cannot remove '/tmp/foo': File exists
but there is nothing in that directory.

Here is the /tmp directory

total 8126
drwxr-xr-x 23 root root      25 May  8 22:55 ..
drwx------  3 root root     117 May  9 13:23 cabal-install-1.16.0.2-21814
[...]
drwxrwxrwt  8 root sys      925 May  9 16:07 . 
and here is the /tmp/cabal-install-1.16.0.2-21814

total 8
drwx------ 3 root root 117 May  9 13:23 .
drwxrwxrwt 8 root sys  985 May  9 16:10 ..
Some funny facts!
If I try (as it was kindly suggested to me on IRC #omnios) unlink, then this works fine.
If I try to zpool scrub, there is no problem.
If I try to mkdir -m 0700 /tmp/bar; cd /tmp/bar; touch baz; cd /tmp; rm -fr bar
?it runs fine...
If I reboot, /tmp dir is emptied fine.

Below you'll find 

1: the steps I used:
2: the output of the build log, with the error at the end
3: the output of truss when i execute rm -fr /tmp/foo

Thanks for your help

Matthieu

Install a 'bloody' OmniOS from DVD.
Update system with pkg refresh and image-update
Install developer packages
pfexec pkg install \ developer/gcc47 \ developer/object-file \ developer/linker \ developer/library/lint \ developer/build/gnu-make \ system/header \ system/library/math/header-math \ archiver/gnu-tar
update path to include /opt/gcc-4.7.2
download binary distribution of ghc-7.0.3 and install in /opt/ghc-7.0.3
update path and ld_library_path
download source distribution of ghc-7.4.2 and install in /opt/ghc-7.4.2
update path and ld_library_path
download cabal-install and execute bootstrap.sh
update path and ld_library_path
execute cabal install --global cabal-install 
searching for ghc in path.
found ghc at /opt/ghc-7.4.2/bin/ghc
("/opt/ghc-7.4.2/bin/ghc",["--numeric-version"])
/opt/ghc-7.4.2/bin/ghc is version 7.4.2
[...]
Downloading cabal-install-1.16.0.2...
[...]
Downloaded to
/root/.cabal/packages/hackage.haskell.org/cabal-install/1.16.0.2/cabal-install-1.16.0.2.tar.gz
Extracting
/root/.cabal/packages/hackage.haskell.org/cabal-install/1.16.0.2/cabal-install-1.16.0.2.tar.gz
to /tmp/cabal-install-1.16.0.2-21814...
[...]
Using internal setup method with build-type Simple and args:
["install","--verbose=3"]
directory dist/doc/html/cabal-install does exist: False
creating /usr/local/share/doc/cabal-install-1.16.0.2
Installing LICENSE to /usr/local/share/doc/cabal-install-1.16.0.2/LICENSE
Installing executable(s) in /usr/local/bin
creating /usr/local/bin
Installing executable dist/build/cabal/cabal to /usr/local/bin/cabal
("/usr/bin/strip",["/usr/local/bin/cabal"])
World file is already up to date.
cabal: Error: some packages failed to install:
cabal-install-1.16.0.2 failed while downloading the package. The exception was:
/tmp/cabal-install-1.16.0.2-21814: removeDirectory: already exists (File exists)


truss rm -fr /tmp/cabal-install-1.16.0.2-21814 2>&1 | tee /tmp/truss:

execve("/usr/gnu/bin/rm", 0x08047D24, 0x08047D34)  argc = 3
sysinfo(SI_MACHINE, "i86pc", 257)		= 6
mmap(0x00000000, 32, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFB0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFA0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF90000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF80000
memcntl(0xFEFB6000, 47484, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
memcntl(0x08050000, 24204, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
resolvepath("/usr/lib/ld.so.1", "/lib/ld.so.1", 1023) = 12
resolvepath("/usr/gnu/bin/rm", "/usr/gnu/bin/rm", 1023) = 15
sysconfig(_CONFIG_PAGESIZE)			= 4096
stat64("/usr/gnu/bin/rm", 0x080479B8)		= 0
open("/var/ld/ld.config", O_RDONLY)		Err#2 ENOENT
stat64("/usr/local/lib/libc.so.1", 0x080471D8)	Err#2 ENOENT
stat64("/opt/ghc-7.4.2/lib/libc.so.1", 0x080471D8) Err#2 ENOENT
stat64("/opt/ghc-7.0.2/lib/libc.so.1", 0x080471D8) Err#2 ENOENT
stat64("./libc.so.1", 0x080471D8)		Err#2 ENOENT
stat64("/lib/libc.so.1", 0x080471D8)		= 0
resolvepath("/lib/libc.so.1", "/lib/libc.so.1", 1023) = 14
open("/lib/libc.so.1", O_RDONLY)		= 3
mmapobj(3, MMOBJ_INTERPRET, 0xFEFA0CA8, 0x08047244, 0x00000000) = 0
close(3)					= 0
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEE20000
memcntl(0xFEE30000, 244676, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
mmap(0x00010000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEE10000
getcontext(0x080477F8)
getrlimit(RLIMIT_STACK, 0x080477F0)		= 0
getpid()					= 22973 [22971]
lwp_private(0, 1, 0xFEE12A40)			= 0x000001C3
setustack(0xFEE12AA0)
sysi86(SI86FPSTART, 0xFEF7DF8C, 0x0000133F, 0x00001F80) = 0x00000001
brk(0x0808C1E0)					= 0
brk(0x0808E1E0)					= 0
ioctl(0, TCGETA, 0x08047C4E)			= 0
getprivimplinfo(0x080473B0, 2076)		= 0
mmap(0x00010000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDF0000
sysconfig(_CONFIG_NGROUPS)			= 16
zone_lookup(0x00000000)				= 0
zone_getattr(0, ZONE_ATTR_PRIVSET, 0xFEE10248, 12) = 12
getppriv(PRIV_EFFECTIVE, {ffffffffffffffffffffffff}) = 0
setppriv(PRIV_SET, PRIV_EFFECTIVE, {fffffffffffffbffffffffff}) = 0
sysconfig(_CONFIG_PAGESIZE)			= 4096
lstat64("/", 0x08047BF0)			= 0
lstat64("cabal-install-1.16.0.2-21814", 0x0808D684) = 0
open64("cabal-install-1.16.0.2-21814", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_NOFOLLOW) = 3
fcntl(3, F_SETFD, 0x00000001)			= 0
fstat64(3, 0x08047A20)				= 0
getdents64(3, 0xFEE14000, 8192)			= 48
getdents64(3, 0xFEE14000, 8192)			= 0
close(3)					= 0
rmdir("cabal-install-1.16.0.2-21814")		Err#17 EEXIST
open64("/usr/gnu/lib/charset.alias", O_RDONLY|O_NOFOLLOW) Err#2 ENOENT
fcntl(1, F_GETFL)				= 2
fstat64(2, 0x08046B90)				= 0
rm: write(2, " r m :  ", 4)				= 4
cannot remove 'cabal-install-1.16.0.2-21814'write(2, " c a n n o t   r e m o v".., 44)	= 44
: write(2, " :  ", 2)				= 2
File existswrite(2, " F i l e   e x i s t s", 11)		= 11 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130509/4998f545/attachment-0001.html>

From henson at acm.org  Thu May  9 15:01:03 2013
From: henson at acm.org (Paul B. Henson)
Date: Thu, 09 May 2013 12:01:03 -0700
Subject: [OmniOS-discuss] cannot remove temp dir
In-Reply-To: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
References: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
Message-ID: <518BF26F.1050500@acm.org>

On 5/9/2013 7:28 AM, Matthieu Paindavoine wrote:

> I am new to OmniOS. I am trying to setup a Haskell development
> environment and ran against a bump that's preventing me from completing
> the task. I mentioned this problem yesterday on IRC and got some help,
> but no definitive solution.
[...]
> execve("/usr/gnu/bin/rm", 0x08047D24, 0x08047D34)  argc = 3
[...]
> rmdir("cabal-install-1.16.0.2-21814")		Err#17 EEXIST

Out of curiosity, does it behave any differently if you use the native 
illumos rm rather than the gnu variant?

If I get a minute, I'll try to reproduce this. What exactly are you 
doing? Install ghc (ghc-7.6.3-src.tar.bz2), and then the platform 
(haskell-platform-2012.4.0.0.tar.gz)? I didn't see a standalone package 
just for cabal after a quick look.


From ctordtor at yahoo.fr  Thu May  9 16:50:39 2013
From: ctordtor at yahoo.fr (Matthieu Paindavoine)
Date: Thu, 9 May 2013 21:50:39 +0100 (BST)
Subject: [OmniOS-discuss] cannot remove temp dir
In-Reply-To: <518BF26F.1050500@acm.org>
References: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
	<518BF26F.1050500@acm.org>
Message-ID: <1368132639.12656.YahooMailNeo@web172803.mail.ir2.yahoo.com>

The behavior with /usr/bin/rm is the same (the error message is different:
rm: Unable to remove directory cabal-install-1.16.0.2-21814: Directory not empty)


I am trying to install a Haskell environment. I initially set my goal, like you mentioned, on the haskell-platform. But it depends on OpenGL, and I can't find it available. So I decided to just install ghc-7.4.2 and cabal.

I used the ghc-7.0.3 binary distribution available on www.haskell.org to bootstrap the ghc-7.4.2 source distribution, and it compiled successfully.
I then installed cabal with the bootstrap.sh (--global) script found in the cabal-install source, and it installed fine too, and suggested I upgrade to the latest version available with 'cabal install --global cabal-install', that's when it started turning sour (the build log I included in my previous mail).

Thanks for your help.

Matthieu


________________________________
 De?: Paul B. Henson <henson at acm.org>
??: omnios-discuss at lists.omniti.com 
Envoy? le : Jeudi 9 mai 2013 21h01
Objet?: Re: [OmniOS-discuss] cannot remove temp dir
 

On 5/9/2013 7:28 AM, Matthieu Paindavoine wrote:

> I am new to OmniOS. I am trying to setup a Haskell development
> environment and ran against a bump that's preventing me from completing
> the task. I mentioned this problem yesterday on IRC and got some help,
> but no definitive solution.
[...]
> execve("/usr/gnu/bin/rm", 0x08047D24, 0x08047D34)? argc = 3
[...]
> rmdir("cabal-install-1.16.0.2-21814")??? ??? Err#17 EEXIST

Out of curiosity, does it behave any differently if you use the native illumos rm rather than the gnu variant?

If I get a minute, I'll try to reproduce this. What exactly are you doing? Install ghc (ghc-7.6.3-src.tar.bz2), and then the platform (haskell-platform-2012.4.0.0.tar.gz)? I didn't see a standalone package just for cabal after a quick look.

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130509/4cfa0c74/attachment.html>

From peter.tribble at gmail.com  Thu May  9 16:57:38 2013
From: peter.tribble at gmail.com (Peter Tribble)
Date: Thu, 9 May 2013 21:57:38 +0100
Subject: [OmniOS-discuss] Redistribution
Message-ID: <CAEgYsbGb_yKFUcpsqkwsfwu0dTW4mu9eweOgZLW4d2bpnnPhNg@mail.gmail.com>

Is OmniOS, and all its packages, completely redistributable?

For my own distro (Tribblix) I repackage a chunk of userland
from OI, but need to update large parts of that. Now, I could
attempt to bootstrap replacements just like was done for
OmniOS, but that's duplicate effort (and there's always the
danger that I do it wrong); besides, sharing binaries with
another distro ensures binary compatibility. So, am I safe
to repackage OmniOS binaries?

Thanks,

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130509/8b9990bf/attachment.html>

From jesus at omniti.com  Thu May  9 17:33:05 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Thu, 9 May 2013 17:33:05 -0400
Subject: [OmniOS-discuss] Redistribution
In-Reply-To: <CAEgYsbGb_yKFUcpsqkwsfwu0dTW4mu9eweOgZLW4d2bpnnPhNg@mail.gmail.com>
References: <CAEgYsbGb_yKFUcpsqkwsfwu0dTW4mu9eweOgZLW4d2bpnnPhNg@mail.gmail.com>
Message-ID: <CACLsAptP45uz5VhoizCZp0KO-j0po7On6mRs5zJgTH9nEAWDpA@mail.gmail.com>

Sadly, this is only a question that could be answer by your counsel.

The licenses are clearly marked on all the packages, but the vary wildly.

OmniTI feels safe redistributing them, but that should not be taken as
legal advice.


On Thu, May 9, 2013 at 4:57 PM, Peter Tribble <peter.tribble at gmail.com>wrote:

> Is OmniOS, and all its packages, completely redistributable?
>
> For my own distro (Tribblix) I repackage a chunk of userland
> from OI, but need to update large parts of that. Now, I could
> attempt to bootstrap replacements just like was done for
> OmniOS, but that's duplicate effort (and there's always the
> danger that I do it wrong); besides, sharing binaries with
> another distro ensures binary compatibility. So, am I safe
> to repackage OmniOS binaries?
>
> Thanks,
>
> --
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>


-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130509/764aaf62/attachment.html>

From jesus at omniti.com  Thu May  9 17:33:53 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Thu, 9 May 2013 17:33:53 -0400
Subject: [OmniOS-discuss] cannot remove temp dir
In-Reply-To: <1368132639.12656.YahooMailNeo@web172803.mail.ir2.yahoo.com>
References: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
	<518BF26F.1050500@acm.org>
	<1368132639.12656.YahooMailNeo@web172803.mail.ir2.yahoo.com>
Message-ID: <CACLsApvWy-=-vatg44FYKis0pCSDuJMUyVY5qRMAoNJf3XaFXQ@mail.gmail.com>

And the output of:

find /tmp/<dir> is?


On Thu, May 9, 2013 at 4:50 PM, Matthieu Paindavoine <ctordtor at yahoo.fr>wrote:

> The behavior with /usr/bin/rm is the same (the error message is different:
> rm: Unable to remove directory cabal-install-1.16.0.2-21814: Directory not
> empty)
>
> I am trying to install a Haskell environment. I initially set my goal,
> like you mentioned, on the haskell-platform. But it depends on OpenGL, and
> I can't find it available. So I decided to just install ghc-7.4.2 and cabal.
>
> I used the ghc-7.0.3 binary distribution available on www.haskell.org to
> bootstrap the ghc-7.4.2 source distribution, and it compiled successfully.
> I then installed cabal with the bootstrap.sh (--global) script found in
> the cabal-install source, and it installed fine too, and suggested I
> upgrade to the latest version available with 'cabal install --global
> cabal-install', that's when it started turning sour (the build log I
> included in my previous mail).
>
> Thanks for your help.
>
> Matthieu
>   ------------------------------
>  *De :* Paul B. Henson <henson at acm.org>
> *? :* omnios-discuss at lists.omniti.com
> *Envoy? le :* Jeudi 9 mai 2013 21h01
> *Objet :* Re: [OmniOS-discuss] cannot remove temp dir
>
> On 5/9/2013 7:28 AM, Matthieu Paindavoine wrote:
>
> > I am new to OmniOS. I am trying to setup a Haskell development
> > environment and ran against a bump that's preventing me from completing
> > the task. I mentioned this problem yesterday on IRC and got some help,
> > but no definitive solution.
> [...]
> > execve("/usr/gnu/bin/rm", 0x08047D24, 0x08047D34)  argc = 3
> [...]
> > rmdir("cabal-install-1.16.0.2-21814")        Err#17 EEXIST
>
> Out of curiosity, does it behave any differently if you use the native
> illumos rm rather than the gnu variant?
>
> If I get a minute, I'll try to reproduce this. What exactly are you doing?
> Install ghc (ghc-7.6.3-src.tar.bz2), and then the platform
> (haskell-platform-2012.4.0.0.tar.gz)? I didn't see a standalone package
> just for cabal after a quick look.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>


-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130509/2d258692/attachment-0001.html>

From omnios at citrus-it.net  Thu May  9 18:16:19 2013
From: omnios at citrus-it.net (Andy)
Date: Thu, 9 May 2013 22:16:19 +0000 (GMT)
Subject: [OmniOS-discuss] SSL certificate problem with pkgrecv in r151006
Message-ID: <alpine.GSO.2.00.1305092215210.12799@areb.pvgehf-vg.arg>

Not sure where to report issues but after updating to r151006, I can no
longer use pkgrecv against HTTPS repositories:

    # pkgrecv --newest -s https://ips.citrus-it.net/
    pkgrecv: Unable to locate a CA directory: /etc/openssl/certs
    Secure connection is not available.

I'm aware that the certificate directory was changed between
r151004 and r151006 so it just looks like the pkg tools need updating.
(Also, thankfully, /usr/ssl/certs now links properly :))

Creating a symbolic link from /etc/ssl -> /etc/openssl resolves the
problem in the short term.

-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From henson at acm.org  Thu May  9 18:58:49 2013
From: henson at acm.org (Paul B. Henson)
Date: Thu, 09 May 2013 15:58:49 -0700
Subject: [OmniOS-discuss] cannot remove temp dir
In-Reply-To: <1368132639.12656.YahooMailNeo@web172803.mail.ir2.yahoo.com>
References: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
	<518BF26F.1050500@acm.org>
	<1368132639.12656.YahooMailNeo@web172803.mail.ir2.yahoo.com>
Message-ID: <518C2A29.2050302@acm.org>

On 5/9/2013 1:50 PM, Matthieu Paindavoine wrote:

> I used the ghc-7.0.3 binary distribution available on www.haskell.org to
> bootstrap the ghc-7.4.2 source distribution, and it compiled successfully.
> I then installed cabal with the bootstrap.sh (--global) script found in
> the cabal-install source, and it installed fine too, and suggested I
> upgrade to the latest version available with 'cabal install --global
> cabal-install', that's when it started turning sour (the build log I
> included in my previous mail).

I didn't see a solaris binary distribution on the site at first glance, 
nor a separate tarball for cabal.

Would you mind posting a step-by-step list of how to get to the point 
where you had the problem so I could try and reproduce it? Something 
along the lines of "download http://xxxxx/, run yyyy, download 
http:/zzzzz, run wwww", etc? I'm sure I could work it out, but while I 
am curious about the underlying filesystem problem you're encountering, 
I must confess I'm not particularly interested in haskell :).


From ctordtor at yahoo.fr  Thu May  9 19:11:26 2013
From: ctordtor at yahoo.fr (Matthieu Paindavoine)
Date: Fri, 10 May 2013 00:11:26 +0100 (BST)
Subject: [OmniOS-discuss] cannot remove temp dir
In-Reply-To: <518C2A29.2050302@acm.org>
References: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
	<518BF26F.1050500@acm.org>
	<1368132639.12656.YahooMailNeo@web172803.mail.ir2.yahoo.com>
	<518C2A29.2050302@acm.org>
Message-ID: <1368141086.91170.YahooMailNeo@web172802.mail.ir2.yahoo.com>

Sure,
here are the steps:

Install a 'bloody' OmniOS from DVD.
Update system with pkg refresh and image-update
Install developer packages
pfexec pkg install \ developer/gcc47 \ developer/object-file \ developer/linker \ developer/library/lint \ developer/build/gnu-make \ system/header \ system/library/math/header-math \ archiver/gnu-tar
update path to include /opt/gcc-4.7.2
download binary distribution of ghc-7.0.3 and install in /opt/ghc-7.0.3:

#> wget http://www.haskell.org/ghc/dist/7.0.3/maeder/ghc-7.0.3-i386-unknown-solaris2.tar.bz2
#> gtar jxvpf ghc-7.0.3-i386-unknown-solaris2.tar.bz2
#> mkdir /opt/ghc-7.0.3
#> cd ghc-7.0.3
#> ./configure --prefix=/opt/ghc-7.0.3
#> make install

update path and ld_library_path
download source distribution of ghc-7.4.2 and install in /opt/ghc-7.4.2:

#> wget http://www.haskell.org/ghc/dist/7.4.2/ghc-7.4.2-src.tar.bz2
#> gtar jxvpf ghc-7.4.2-src.tar.bz2
#> mkdir /opt/ghc-7.4.2
#> cd ghc-7.4.2
#> ./configure --prefix=/opt/ghc-7.4.2
#> make install

update path and ld_library_path
download cabal-install and execute bootstrap.sh:

#> wget http://www.haskell.org/cabal/release/cabal-install-0.14.0/cabal-install-0.14.0.tar.gz
#> gtar zxvpf cabal-install-0.14.0.tar.gz 
#> cd cabal-install-0.14.0
#> chmod u+x bootstrap.sh
#> ./bootstrap.sh --global

update path and ld_library_path 
#> cabal install --global cabal-install => Fail




________________________________
 De?: Paul B. Henson <henson at acm.org>
??: Matthieu Paindavoine <ctordtor at yahoo.fr> 
Cc?: "omnios-discuss at lists.omniti.com" <omnios-discuss at lists.omniti.com> 
Envoy? le : Vendredi 10 mai 2013 0h58
Objet?: Re: [OmniOS-discuss] cannot remove temp dir
 

On 5/9/2013 1:50 PM, Matthieu Paindavoine wrote:

> I used the ghc-7.0.3 binary distribution available on www.haskell.org to
> bootstrap the ghc-7.4.2 source distribution, and it compiled successfully.
> I then installed cabal with the bootstrap.sh (--global) script found in
> the cabal-install source, and it installed fine too, and suggested I
> upgrade to the latest version available with 'cabal install --global
> cabal-install', that's when it started turning sour (the build log I
> included in my previous mail).

I didn't see a solaris binary distribution on the site at first glance, 
nor a separate tarball for cabal.

Would you mind posting a step-by-step list of how to get to the point 
where you had the problem so I could try and reproduce it? Something 
along the lines of "download http://xxxxx/, run yyyy, download 
http:/zzzzz, run wwww", etc? I'm sure I could work it out, but while I 
am curious about the underlying filesystem problem you're encountering, 
I must confess I'm not particularly interested in haskell :).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130510/cfd75c70/attachment.html>

From henson at acm.org  Thu May  9 20:50:51 2013
From: henson at acm.org (Paul B. Henson)
Date: Thu, 09 May 2013 17:50:51 -0700
Subject: [OmniOS-discuss] cannot remove temp dir
In-Reply-To: <518BF26F.1050500@acm.org>
References: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
	<518BF26F.1050500@acm.org>
Message-ID: <518C446B.70502@acm.org>

> On 5/9/2013 7:28 AM, Matthieu Paindavoine wrote:
>
>> I am new to OmniOS. I am trying to setup a Haskell development
>> environment and ran against a bump that's preventing me from completing
>> the task. I mentioned this problem yesterday on IRC and got some help,
>> but no definitive solution.
> [...]
>> execve("/usr/gnu/bin/rm", 0x08047D24, 0x08047D34)  argc = 3
> [...]
>> rmdir("cabal-install-1.16.0.2-21814")        Err#17 EEXIST

Matthieu provided remote access to the system he was working on, and I 
took a look at this.

On the one hand, it's fairly clear why the directory can't be deleted:

# ls -ld cabal-install-1.16.0.2-21814
drwx------ 3 root root 117 May 10 02:00 cabal-install-1.16.0.2-21814
           ^^^

It's got a link count of 3, and per the tmpfs code:

tmp_rmdir(
[...]
         if (self->tn_nlink > 2) {
                 mutex_exit(&self->tn_tlock);
                 error = EEXIST;

If a directory has a link count greater than two, it returns EEXIST.

It's also fairly easy to replicate the scenario:

# mkdir test
# ls -ld test
drwxr-xr-x 2 root root 117 May 10 02:27 test

# link test test2
# ls -ld test test2
drwxr-xr-x 3 root root 117 May 10 02:27 test
drwxr-xr-x 3 root root 117 May 10 02:27 test2

# rmdir test
rmdir: failed to remove 'test': File exists

# unlink test2
# rmdir test

What's not so obvious is where the other link to the directory 
cabal-install-1.16.0.2-21814 is. For my simple test:

# ls -lid test*
2675840857 drwxr-xr-x 3 root root 117 May 10 02:28 test
2675840857 drwxr-xr-x 3 root root 117 May 10 02:28 test2

The two links of course have the same inode, and if you search by inode:

# find . -inum 267584085
./test
./test2

They are both found. On the other hand, for the cabal directory:

# ls -lid cabal-install-1.16.0.2-21814
2677295311 drwx------ 3 root root 117 May 10 02:00 
cabal-install-1.16.0.2-21814

# find . -inum 2677295311
./cabal-install-1.16.0.2-21814

There appears to only be one link with that inode on the file system. 
This is all in /tmp, mounted on tmpfs:

# mount | grep tmp
/tmp on swap read/write/setuid/devices/xattr/dev=83c0002 on Thu May  9 
09:37:34 2013

So I don't really see that there's any other place a link could exist, 
it won't allow you to link across devices. Just for fun I tried a search 
starting at the root:

# find / -inum 2677295311
/tmp/cabal-install-1.16.0.2-21814

Just the one link.

So I'm a bit stumped. What I would probably do next is run whatever 
process generates the cabal directory under truss -f and see what's 
calling the link syscall. Matthieu, perhaps you could do that and make 
the output available?

I think I might post this to the developer list, and see if anybody has 
any idea where that other link disappeared to. Matthieu, I'd also be 
curious to see what would happen if you unmounted /tmp from tmpfs and 
used just a regular zfs filesystem, perhaps the build is doing something 
weird that's poking a bug in tmpfs resulting in a dangling reference?


From jesus at omniti.com  Thu May  9 23:25:30 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Thu, 9 May 2013 23:25:30 -0400
Subject: [OmniOS-discuss] SSL certificate problem with pkgrecv in r151006
In-Reply-To: <alpine.GSO.2.00.1305092215210.12799@areb.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1305092215210.12799@areb.pvgehf-vg.arg>
Message-ID: <CACLsAptewvfAoRFM9G35v9pDT4L7sp+_1rs6DE_wJVagcfnQ0g@mail.gmail.com>

Hi Andy,

I've fixed this in bloody.  The URL you provided tosses:

; pkgrecv --newest -s https://ips.citrus-it.net/
pkgrecv: https protocol error: code: 401 reason: Unauthorized
URL: 'https://ips.citrus-it.net/versions/0/'.

So, I'm not certain it completely works.  If you've got a bloody install
somewhere and do a 'pkg update pkg' you can test it.

Best regards,

Theo

On Thu, May 9, 2013 at 6:16 PM, Andy <omnios at citrus-it.net> wrote:

> Not sure where to report issues but after updating to r151006, I can no
> longer use pkgrecv against HTTPS repositories:
>
>     # pkgrecv --newest -s https://ips.citrus-it.net/
>     pkgrecv: Unable to locate a CA directory: /etc/openssl/certs
>     Secure connection is not available.
>
> I'm aware that the certificate directory was changed between
> r151004 and r151006 so it just looks like the pkg tools need updating.
> (Also, thankfully, /usr/ssl/certs now links properly :))
>
> Creating a symbolic link from /etc/ssl -> /etc/openssl resolves the
> problem in the short term.
>
> --
> Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
> Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
> Registered in England and Wales | Company number 4899123
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130509/f121eb7f/attachment-0001.html>

From natxo.asenjo at gmail.com  Fri May 10 08:22:38 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 10 May 2013 14:22:38 +0200
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
Message-ID: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>

hi,

maybe (probably) not really on topic for the omnios list.

I have a zfs dataset shared both for cifs as for nfs. On the data set I use
this:

# zfs get aclinherit tank/testshare
NAME            PROPERTY    VALUE          SOURCE
tank/testshare  aclinherit  passthrough    local

Next I applied this acl to the /tank/testshare filesystem:

# /bin/ls -vd /tank/testshare/
drwxrwxrwx+ 12 root     root          13 May 10 13:16 /tank/testshare/
     0:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow

So basically anyone may do whatever they want to the content of the dataset.

Windows clients respect the acl, I can copy files and dirs from other
disks/shares and the acl on the dataset is respected.

Now, linux nfs4 clients respect the acl when creating files or dirs but
when copying files/dirs they ignore the acl inheritance and use the umask
setting, so I wind up with unusable files for the windows clients.

This issue was discussed in some length in the zfs-discuss list (
http://www.mentby.com/Group/zfs-discuss/who-is-using-zfs-acls-in-production.html).
Unfortunately, no solution appears on the thread.

Is this a linux client problem that should be fixed on the linux client
side? Are there any settings per dataset to make the server ignore the
umask request of the client to enforce the dataset acl like the cifs
implemention does?

TIA,
--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130510/5b6de056/attachment.html>

From sigbjorn at nixtra.com  Fri May 10 09:47:35 2013
From: sigbjorn at nixtra.com (Sigbjorn Lie)
Date: Fri, 10 May 2013 15:47:35 +0200
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
Message-ID: <518CFA77.6060403@nixtra.com>

Hi,

Did you set aclmode to passthrough too?



Regards,
Siggi


On 05/10/2013 02:22 PM, Natxo Asenjo wrote:
> hi,
>
> maybe (probably) not really on topic for the omnios list.
>
> I have a zfs dataset shared both for cifs as for nfs. On the data set 
> I use this:
>
> # zfs get aclinherit tank/testshare
> NAME            PROPERTY    VALUE          SOURCE
> tank/testshare  aclinherit  passthrough    local
>
> Next I applied this acl to the /tank/testshare filesystem:
>
> # /bin/ls -vd /tank/testshare/
> drwxrwxrwx+ 12 root     root          13 May 10 13:16 /tank/testshare/
>      0:everyone@:list_directory/read_data/add_file/write_data
> /add_subdirectory/append_data/read_xattr/write_xattr/execute
> /delete_child/read_attributes/write_attributes/delete/read_acl
> /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
>
> So basically anyone may do whatever they want to the content of the 
> dataset.
>
> Windows clients respect the acl, I can copy files and dirs from other 
> disks/shares and the acl on the dataset is respected.
>
> Now, linux nfs4 clients respect the acl when creating files or dirs 
> but when copying files/dirs they ignore the acl inheritance and use 
> the umask setting, so I wind up with unusable files for the windows 
> clients.
>
> This issue was discussed in some length in the zfs-discuss list 
> (http://www.mentby.com/Group/zfs-discuss/who-is-using-zfs-acls-in-production.html). 
> Unfortunately, no solution appears on the thread.
>
> Is this a linux client problem that should be fixed on the linux 
> client side? Are there any settings per dataset to make the server 
> ignore the umask request of the client to enforce the dataset acl like 
> the cifs implemention does?
>
> TIA,
> --
> Groeten,
> natxo
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130510/2d304665/attachment.html>

From natxo.asenjo at gmail.com  Fri May 10 10:17:00 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 10 May 2013 16:17:00 +0200
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <518CFA77.6060403@nixtra.com>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
Message-ID: <CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>

hi Siggi,

On Fri, May 10, 2013 at 3:47 PM, Sigbjorn Lie <sigbjorn at nixtra.com> wrote:

>  Hi,
>
> Did you set aclmode to passthrough too?
>
>
no but I just tried it and the linux nfsv4 client still ignores the
inheritance:

# zfs get all tank/testshare | grep acl
tank/testshare  aclmode               passthrough             local
tank/testshare  aclinherit            passthrough             local

Thanks for the suggestion.

-- 
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130510/9cd059a4/attachment.html>

From natxo.asenjo at gmail.com  Fri May 10 11:08:13 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 10 May 2013 17:08:13 +0200
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
Message-ID: <CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>

On Fri, May 10, 2013 at 4:17 PM, Natxo Asenjo <natxo.asenjo at gmail.com>wrote:

> hi Siggi,
>
>
> On Fri, May 10, 2013 at 3:47 PM, Sigbjorn Lie <sigbjorn at nixtra.com> wrote:
>
>>  Hi,
>>
>> Did you set aclmode to passthrough too?
>>
>>
> no but I just tried it and the linux nfsv4 client still ignores the
> inheritance:
>
> # zfs get all tank/testshare | grep acl
> tank/testshare  aclmode               passthrough             local
> tank/testshare  aclinherit            passthrough             local
>
>
following up, I found this: https://www.illumos.org/issues/3571

and setting

# zfs set aclmode=restricted tank/testshare

seems to do the trick from the linux client side.

I need to test it a bit further.

--
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130510/53c5cf10/attachment.html>

From sigbjorn at nixtra.com  Fri May 10 12:01:08 2013
From: sigbjorn at nixtra.com (Sigbjorn Lie)
Date: Fri, 10 May 2013 18:01:08 +0200
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
	<CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
Message-ID: <518D19C4.5050403@nixtra.com>

On 05/10/2013 05:08 PM, Natxo Asenjo wrote:
> On Fri, May 10, 2013 at 4:17 PM, Natxo Asenjo <natxo.asenjo at gmail.com 
> <mailto:natxo.asenjo at gmail.com>> wrote:
>
>     hi Siggi,
>
>
>     On Fri, May 10, 2013 at 3:47 PM, Sigbjorn Lie <sigbjorn at nixtra.com
>     <mailto:sigbjorn at nixtra.com>> wrote:
>
>         Hi,
>
>         Did you set aclmode to passthrough too?
>
>
>     no but I just tried it and the linux nfsv4 client still ignores
>     the inheritance:
>
>     # zfs get all tank/testshare | grep acl
>     tank/testshare  aclmode               passthrough local
>     tank/testshare  aclinherit            passthrough local
>
>
> following up, I found this: https://www.illumos.org/issues/3571
>
> and setting
>
> # zfs set aclmode=restricted tank/testshare
>
> seems to do the trick from the linux client side.
>
> I need to test it a bit further.
>

Hi,

I was testing this a while back and had similiar issues to you. I ended 
up setting both aclmode and aclinherit to passtrough, and setting a 
different ACL than what you've done.  I have pasted my setup below. This 
allows access from both Linux and Windows to the same files, with access 
mainly controlled by the LDAP group "ldap_group". Files created by nfs 
clients also generate the owner@ group@ and everyone@, this has not been 
an issue for me. Files can still be accessed from both Linux and Windows.

This is on NexentaStor, which is still not having support for 
aclmode=restricted. It seem like aclmode=restricted would also do the 
trick, from what I can read about aclmode=restricted.

NAME        PROPERTY    VALUE          SOURCE
p00/public  aclmode     passthrough    local
p00/public  aclinherit  passthrough    local


ls -lvd p00/public/
drwx--S---+ 12 root     root          21 May 10 17:38 p00/public/
      0:group:ldap_group:list_directory/read_data/add_file/write_data
/add_subdirectory/append_data/read_xattr/write_xattr/execute
/read_attributes/write_attributes/delete/read_acl/synchronize
          :file_inherit/dir_inherit:allow
      1:user:root:list_directory/read_data/add_file/write_data
/add_subdirectory/append_data/read_xattr/write_xattr/execute
/delete_child/read_attributes/write_attributes/delete/read_acl
/write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
      2:user:nfs:read_attributes/synchronize:allow




/usr/sun/bin/ls -lvd p00/public/created_linux.txt
-rw-r--r--+  1 sigbjorn root           0 May 10 17:40 
p00/public/created_linux.txt
      0:group:ldap_group:read_data/write_data/append_data/read_xattr
/write_xattr/execute/read_attributes/write_attributes/delete
          /read_acl/synchronize:inherited:allow
1:user:root:read_data/write_data/append_data/read_xattr/write_xattr
/execute/delete_child/read_attributes/write_attributes/delete
          /read_acl/write_acl/write_owner/synchronize:inherited:allow
2:owner@:read_data/write_data/append_data/read_xattr/write_xattr
/read_attributes/write_attributes/read_acl/write_acl/write_owner
          /synchronize:allow
3:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
4:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
          :allow


/ls -lvd p00/public/created_windows.txt
----------+  1 sigbjorn root           0 May 10 17:41 
p00/public/created_windows.txt
      0:group:ldap_group:read_data/write_data/append_data/read_xattr
/write_xattr/execute/read_attributes/write_attributes/delete
          /read_acl/synchronize:inherited:allow
1:user:root:read_data/write_data/append_data/read_xattr/write_xattr
/execute/delete_child/read_attributes/write_attributes/delete
          /read_acl/write_acl/write_owner/synchronize:inherited:allow



Regards,
Siggi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130510/20cf8c96/attachment.html>

From ctordtor at yahoo.fr  Fri May 10 15:48:27 2013
From: ctordtor at yahoo.fr (Matthieu Paindavoine)
Date: Fri, 10 May 2013 20:48:27 +0100 (BST)
Subject: [OmniOS-discuss] cannot remove temp dir
In-Reply-To: <518C446B.70502@acm.org>
References: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
	<518BF26F.1050500@acm.org> <518C446B.70502@acm.org>
Message-ID: <1368215307.34324.YahooMailNeo@web172804.mail.ir2.yahoo.com>


Hello,

Following Paul's suggestion, I did the following:
#> cd /tmp
#> unlink cabal-install ...
#> ls (-> nothing)
#> cd ..
#> umount /tmp
#> zfs create rpool/export/tmp
#> zfs set mountpoint=/tmp rpool/export/tmp
#> cd /tmp; touch foo (-> ok, foo is there)
#> cd ~; cabal install --global cabal-install
tada! It's working

It's probably a problem with tmpfs then...

Hope this helps.

Matthieu


________________________________
 De?: Paul B. Henson <henson at acm.org>
??: omnios-discuss at lists.omniti.com 
Envoy? le : Vendredi 10 mai 2013 2h50
Objet?: Re: [OmniOS-discuss] cannot remove temp dir
 

> On 5/9/2013 7:28 AM, Matthieu Paindavoine wrote:
>
>> I am new to OmniOS. I am trying to setup a Haskell development
>> environment and ran against a bump that's preventing me from completing
>> the task. I mentioned this problem yesterday on IRC and got some help,
>> but no definitive solution.
> [...]
>> execve("/usr/gnu/bin/rm", 0x08047D24, 0x08047D34)? argc = 3
> [...]
>> rmdir("cabal-install-1.16.0.2-21814")? ? ? ? Err#17 EEXIST

Matthieu provided remote access to the system he was working on, and I 
took a look at this.

On the one hand, it's fairly clear why the directory can't be deleted:

# ls -ld cabal-install-1.16.0.2-21814
drwx------ 3 root root 117 May 10 02:00 cabal-install-1.16.0.2-21814
? ? ? ? ?  ^^^

It's got a link count of 3, and per the tmpfs code:

tmp_rmdir(
[...]
? ? ? ?  if (self->tn_nlink > 2) {
? ? ? ? ? ? ? ?  mutex_exit(&self->tn_tlock);
? ? ? ? ? ? ? ?  error = EEXIST;

If a directory has a link count greater than two, it returns EEXIST.

It's also fairly easy to replicate the scenario:

# mkdir test
# ls -ld test
drwxr-xr-x 2 root root 117 May 10 02:27 test

# link test test2
# ls -ld test test2
drwxr-xr-x 3 root root 117 May 10 02:27 test
drwxr-xr-x 3 root root 117 May 10 02:27 test2

# rmdir test
rmdir: failed to remove 'test': File exists

# unlink test2
# rmdir test

What's not so obvious is where the other link to the directory 
cabal-install-1.16.0.2-21814 is. For my simple test:

# ls -lid test*
2675840857 drwxr-xr-x 3 root root 117 May 10 02:28 test
2675840857 drwxr-xr-x 3 root root 117 May 10 02:28 test2

The two links of course have the same inode, and if you search by inode:

# find . -inum 267584085
./test
./test2

They are both found. On the other hand, for the cabal directory:

# ls -lid cabal-install-1.16.0.2-21814
2677295311 drwx------ 3 root root 117 May 10 02:00 
cabal-install-1.16.0.2-21814

# find . -inum 2677295311
./cabal-install-1.16.0.2-21814

There appears to only be one link with that inode on the file system. 
This is all in /tmp, mounted on tmpfs:

# mount | grep tmp
/tmp on swap read/write/setuid/devices/xattr/dev=83c0002 on Thu May? 9 
09:37:34 2013

So I don't really see that there's any other place a link could exist, 
it won't allow you to link across devices. Just for fun I tried a search 
starting at the root:

# find / -inum 2677295311
/tmp/cabal-install-1.16.0.2-21814

Just the one link.

So I'm a bit stumped. What I would probably do next is run whatever 
process generates the cabal directory under truss -f and see what's 
calling the link syscall. Matthieu, perhaps you could do that and make 
the output available?

I think I might post this to the developer list, and see if anybody has 
any idea where that other link disappeared to. Matthieu, I'd also be 
curious to see what would happen if you unmounted /tmp from tmpfs and 
used just a regular zfs filesystem, perhaps the build is doing something 
weird that's poking a bug in tmpfs resulting in a dangling reference?

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130510/8ec81c0f/attachment.html>

From daleg at omniti.com  Fri May 10 18:29:05 2013
From: daleg at omniti.com (Dale Ghent)
Date: Fri, 10 May 2013 18:29:05 -0400
Subject: [OmniOS-discuss] SSL certificate problem with pkgrecv in r151006
In-Reply-To: <alpine.GSO.2.00.1305092215210.12799@areb.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1305092215210.12799@areb.pvgehf-vg.arg>
Message-ID: <D5493167-6471-40D3-9128-4B460663B1A0@omniti.com>


Per Theo's earlier mail, a fix for this has been pushed to bloody. It is now in the release repo for 151006.

# pkg update pkg 

/dale

On May 9, 2013, at 6:16 PM, Andy <omnios at citrus-it.net> wrote:

> Not sure where to report issues but after updating to r151006, I can no
> longer use pkgrecv against HTTPS repositories:
> 
>    # pkgrecv --newest -s https://ips.citrus-it.net/
>    pkgrecv: Unable to locate a CA directory: /etc/openssl/certs
>    Secure connection is not available.
> 
> I'm aware that the certificate directory was changed between
> r151004 and r151006 so it just looks like the pkg tools need updating.
> (Also, thankfully, /usr/ssl/certs now links properly :))
> 
> Creating a symbolic link from /etc/ssl -> /etc/openssl resolves the
> problem in the short term.
> 
> -- 
> Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
> Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
> Registered in England and Wales | Company number 4899123
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From henson at acm.org  Fri May 10 19:23:18 2013
From: henson at acm.org (Paul B. Henson)
Date: Fri, 10 May 2013 16:23:18 -0700
Subject: [OmniOS-discuss] cannot remove temp dir
In-Reply-To: <1368215307.34324.YahooMailNeo@web172804.mail.ir2.yahoo.com>
References: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
	<518BF26F.1050500@acm.org> <518C446B.70502@acm.org>
	<1368215307.34324.YahooMailNeo@web172804.mail.ir2.yahoo.com>
Message-ID: <518D8166.9020709@acm.org>

On 5/10/2013 12:48 PM, Matthieu Paindavoine wrote:

> It's probably a problem with tmpfs then...

I reviewed the truss output you supplied, nothing really stood out as 
odd or unusual. As I have the time, I will try to reproduce it using the 
steps you provided for the haskell installation and see if I can track 
down this bug and stomp it out...



From henson at acm.org  Fri May 10 19:28:16 2013
From: henson at acm.org (Paul B. Henson)
Date: Fri, 10 May 2013 16:28:16 -0700
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
	<CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
Message-ID: <518D8290.8070204@acm.org>

On 5/10/2013 8:08 AM, Natxo Asenjo wrote:

> # zfs set aclmode=restricted tank/testshare
>
> seems to do the trick from the linux client side.

The only possible problem with that is if a client is unhappy about the 
error returned when trying to chmod.

It's on my to do list to add another mode (perhaps ignore) that behaves 
exactly the same as restricted except that it does not generate errors, 
it will nop the chmod and return success.

Is the Linux client explicitly calling chmod/setattr? There's an 
unrelated issue with NFS where a client using exclusive open will result 
in a broken ACL because of the way the mode bits are overloaded in the 
NFS protocol for that operation. It's fixed in NFS 4.1, but there's no 
4.1 support in illumos yet...


From natxo.asenjo at gmail.com  Sat May 11 03:12:43 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sat, 11 May 2013 09:12:43 +0200
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <518D8290.8070204@acm.org>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
	<CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
	<518D8290.8070204@acm.org>
Message-ID: <CAHBEJzVG==Wh2s5OFNocqnsQHTayADigtNHjn9kO6XtCham-9g@mail.gmail.com>

On Sat, May 11, 2013 at 1:28 AM, Paul B. Henson <henson at acm.org> wrote:

> On 5/10/2013 8:08 AM, Natxo Asenjo wrote:
>
>  # zfs set aclmode=restricted tank/testshare
>>
>> seems to do the trick from the linux client side.
>>
>
> The only possible problem with that is if a client is unhappy about the
> error returned when trying to chmod.
>
> It's on my to do list to add another mode (perhaps ignore) that behaves
> exactly the same as restricted except that it does not generate errors, it
> will nop the chmod and return success.
>
> Is the Linux client explicitly calling chmod/setattr? There's an unrelated
> issue with NFS where a client using exclusive open will result in a broken
> ACL because of the way the mode bits are overloaded in the NFS protocol for
> that operation. It's fixed in NFS 4.1, but there's no 4.1 support in
> illumos yet...
>

I have straced the cp -r command with discard and restricted aclmode
settings (see attachments).

Unfortunately I am no programmer so I am not really sure if chmod/settr are
explicitly called - those strings are in any case not there when grepping
the file).

In my use case as long as the acl is respected, it is enough. The clients
should not be changing it.

Thanks,
-- 
groet,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130511/189e546a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace_discard.out
Type: application/octet-stream
Size: 22088 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130511/189e546a/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace_restricted.out
Type: application/octet-stream
Size: 22088 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130511/189e546a/attachment-0003.obj>

From henson at acm.org  Sat May 11 16:35:13 2013
From: henson at acm.org (Paul B. Henson)
Date: Sat, 11 May 2013 13:35:13 -0700
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <CAHBEJzVG==Wh2s5OFNocqnsQHTayADigtNHjn9kO6XtCham-9g@mail.gmail.com>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
	<CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
	<518D8290.8070204@acm.org>
	<CAHBEJzVG==Wh2s5OFNocqnsQHTayADigtNHjn9kO6XtCham-9g@mail.gmail.com>
Message-ID: <20130511203513.GC30773@bender.unx.csupomona.edu>

On Sat, May 11, 2013 at 09:12:43AM +0200, Natxo Asenjo wrote:

> I have straced the cp -r command with discard and restricted aclmode
> settings (see attachments).

open("/net/zfstank.ipa.asenjo.nx/tank/testshare/bin/parsetable.pl",
O_WRONLY|O_CREAT|O_EXCL, 0664) = 4

Yeah, you're getting bit by the NFS exclusive open issue. Basically, NFS
up to v4 overloads the mode bits to store a verifier to check on whether
the exclusive part of the open succeeded, and then does a separate
setattr afterwards to set the actual mode. So what happens is the
initial open results in a file with the right inherited ACL, and the
subsequent setattr results in the same change as an explicit chmod,
typically breaking the ACL. This is fixed in the NFS v4.1 spec, but
that's not really in use yet. Theoretically it should be possible to
keep some state on the server side and work around this issue, but I've
never had the time to dig into it.

Does the linux nfs client complain at all when you do the copy with
aclmode=restricted? The client would get a success for the open, but the
following setattr op would fail, and I wasn't sure how the nfs client
would deal with that. From the strace output it looks like the
underlying nfs setattr failure isn't passed back up to the userland
code, it looks like the open just succeeds as normal. Cool.


I'm glad somebody's finding aclmode=restricted useful :).

From natxo.asenjo at gmail.com  Sun May 12 04:00:49 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sun, 12 May 2013 10:00:49 +0200
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <20130511203513.GC30773@bender.unx.csupomona.edu>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
	<CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
	<518D8290.8070204@acm.org>
	<CAHBEJzVG==Wh2s5OFNocqnsQHTayADigtNHjn9kO6XtCham-9g@mail.gmail.com>
	<20130511203513.GC30773@bender.unx.csupomona.edu>
Message-ID: <CAHBEJzXSxpKTc8sP8mXLcFT5SZnBJvqZBmsDNSOgzqrY7cqfdA@mail.gmail.com>

On Sat, May 11, 2013 at 10:35 PM, Paul B. Henson <henson at acm.org> wrote:

> On Sat, May 11, 2013 at 09:12:43AM +0200, Natxo Asenjo wrote:
>
> > I have straced the cp -r command with discard and restricted aclmode
> > settings (see attachments).
>
> open("/net/zfstank.ipa.asenjo.nx/tank/testshare/bin/parsetable.pl",
> O_WRONLY|O_CREAT|O_EXCL, 0664) = 4
>
> Yeah, you're getting bit by the NFS exclusive open issue. Basically, NFS
> up to v4 overloads the mode bits to store a verifier to check on whether
> the exclusive part of the open succeeded, and then does a separate
> setattr afterwards to set the actual mode. So what happens is the
> initial open results in a file with the right inherited ACL, and the
> subsequent setattr results in the same change as an explicit chmod,
> typically breaking the ACL. This is fixed in the NFS v4.1 spec, but
> that's not really in use yet. Theoretically it should be possible to
> keep some state on the server side and work around this issue, but I've
> never had the time to dig into it.
>
>
ok, thanks for your explanation. I had indeed seen all those 0664 that
pointed in that direction.

I see the illumos nfs 4.1 project is a bti 'inactive' ;-), but it'll come
one day I guess.


> Does the linux nfs client complain at all when you do the copy with
> aclmode=restricted? The client would get a success for the open, but the
> following setattr op would fail, and I wasn't sure how the nfs client
> would deal with that. From the strace output it looks like the
> underlying nfs setattr failure isn't passed back up to the userland
> code, it looks like the open just succeeds as normal. Cool.
>
>
no, it does when moving a file though :

$ mv testmove /net/zfstank.ipa.asenjo.nx/tank/testshare/
mv: preserving permissions for
`/net/zfstank.ipa.asenjo.nx/tank/testshare/testmove': Operation not
permitted

but that is not really a showstopper. The file gets copied and the
permissions are applied:

$ nfs4_getfacl /net/zfstank.ipa.asenjo.nx/tank/testshare/testmove
A::EVERYONE@:rwadxtTnNcCoy

I had not noticed it until yesterday because I am used to copying first and
removing later (lost some files once because of a hardware failure and got
used to doing that since then).


> I'm glad somebody's finding aclmode=restricted useful :).
>

I'm surprised that not more people are using this! Thanks for implementing
it.

-- 
groet,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130512/b7c23fde/attachment.html>

From skiselkov.ml at gmail.com  Sun May 12 10:40:38 2013
From: skiselkov.ml at gmail.com (=?UTF-8?B?U2HFoW8gS2lzZWxrb3Y=?=)
Date: Sun, 12 May 2013 16:40:38 +0200
Subject: [OmniOS-discuss] Trouble getting Supermicro board to see all
	its PCI-e slots
In-Reply-To: <517F9A19.7030707@gmail.com>
References: <517F9A19.7030707@gmail.com>
Message-ID: <518FA9E6.6070800@gmail.com>

Just wanted to create a full-up on this for people to know: I haven't
been able to resolve this issue in time, and have to put the machine
into production as-is (with 4 out of the 6 PCI-e slots non-functional).

So an important heads-up for anybody considering buying Intel
C602J-based boards, especially those from Supermicro: any PCI-e slots
attached to CPU socket 02 may not work with current Illumos-based OSes.
Keep this in mind when making purchasing decisions.

Cheers,
-- 
Saso

From skiselkov.ml at gmail.com  Sun May 12 12:49:42 2013
From: skiselkov.ml at gmail.com (=?windows-1252?Q?Sa=9Ao_Kiselkov?=)
Date: Sun, 12 May 2013 18:49:42 +0200
Subject: [OmniOS-discuss] [discuss] Re: Trouble getting Supermicro board
 to see all its PCI-e slots
In-Reply-To: <5EC16CFE-3289-4AE6-ACC5-2CDDD51E3F39@damore.org>
References: <517F9A19.7030707@gmail.com> <518FA9E6.6070800@gmail.com>
	<5EC16CFE-3289-4AE6-ACC5-2CDDD51E3F39@damore.org>
Message-ID: <518FC826.1040201@gmail.com>

On 05/12/2013 06:25 PM, Garrett D'Amore wrote:
> Thanks Saso.
> 
> Perhaps at some point we'll buy one and I'll be able to find some cycles to work on it directly? that hasn't been possible in the past couple of weeks due to other priorities.

Sooner or later this needs to be addressed. Intel C602J is a new and
very popular chipset and Supermicro makes some pretty fine hardware at a
reasonable price point. People will buy them and we cannot afford not to
have support.

Cheers,
-- 
Saso

From skiselkov.ml at gmail.com  Sun May 12 15:07:22 2013
From: skiselkov.ml at gmail.com (=?UTF-8?B?U2HFoW8gS2lzZWxrb3Y=?=)
Date: Sun, 12 May 2013 21:07:22 +0200
Subject: [OmniOS-discuss] Where to file bugs?
Message-ID: <518FE86A.5040000@gmail.com>

Just wanted to report a bug against OmniOS ntp and noticed that there
isn't a go-to place for that (or my searched turned up dry). Is there a
way to do this?

Cheers,
-- 
Saso

From skiselkov.ml at gmail.com  Sun May 12 15:10:26 2013
From: skiselkov.ml at gmail.com (=?UTF-8?B?U2HFoW8gS2lzZWxrb3Y=?=)
Date: Sun, 12 May 2013 21:10:26 +0200
Subject: [OmniOS-discuss] Where to file bugs?
In-Reply-To: <518FE86A.5040000@gmail.com>
References: <518FE86A.5040000@gmail.com>
Message-ID: <518FE922.6010105@gmail.com>

On 05/12/2013 09:07 PM, Sa?o Kiselkov wrote:
> Just wanted to report a bug against OmniOS ntp and noticed that there
> isn't a go-to place for that (or my searched turned up dry). Is there a
> way to do this?

Should have thought this question through a bit more... I just found
omnios-build on Github. Is this the proper place?

Cheers,
-- 
Saso

From natxo.asenjo at gmail.com  Sun May 12 16:21:32 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sun, 12 May 2013 22:21:32 +0200
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <CAHBEJzXSxpKTc8sP8mXLcFT5SZnBJvqZBmsDNSOgzqrY7cqfdA@mail.gmail.com>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
	<CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
	<518D8290.8070204@acm.org>
	<CAHBEJzVG==Wh2s5OFNocqnsQHTayADigtNHjn9kO6XtCham-9g@mail.gmail.com>
	<20130511203513.GC30773@bender.unx.csupomona.edu>
	<CAHBEJzXSxpKTc8sP8mXLcFT5SZnBJvqZBmsDNSOgzqrY7cqfdA@mail.gmail.com>
Message-ID: <CAHBEJzW5FE8eFhiVAdgYL5ZXnAQmgFnQf5dqh=WVnydeEWEG+Q@mail.gmail.com>

On Sun, May 12, 2013 at 10:00 AM, Natxo Asenjo <natxo.asenjo at gmail.com>wrote:

> On Sat, May 11, 2013 at 10:35 PM, Paul B. Henson <henson at acm.org> wrote:
>
>> On Sat, May 11, 2013 at 09:12:43AM +0200, Natxo Asenjo wrote:Does the
>> linux nfs client complain at all when you do the copy with
>>
> aclmode=restricted? The client would get a success for the open, but the
>> following setattr op would fail, and I wasn't sure how the nfs client
>> would deal with that. From the strace output it looks like the
>> underlying nfs setattr failure isn't passed back up to the userland
>> code, it looks like the open just succeeds as normal. Cool.
>>
>>
> no, it does when moving a file though :
>

mm, when using scp it bypasses the acl as well ..., grrr.

So far I have seen that copying the files *after* the the files have been
copied from the remote client, then the acl is preserverd.

I guess this will have to do until nfs4.1 is in illumos (is there a roadmap
on that)?


> --
> groet,
> natxo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130512/8e197303/attachment.html>

From henson at acm.org  Sun May 12 16:25:24 2013
From: henson at acm.org (Paul B. Henson)
Date: Sun, 12 May 2013 13:25:24 -0700
Subject: [OmniOS-discuss] Where to file bugs?
In-Reply-To: <518FE86A.5040000@gmail.com>
References: <518FE86A.5040000@gmail.com>
Message-ID: <20130512202524.GD30773@bender.unx.csupomona.edu>

On Sun, May 12, 2013 at 09:07:22PM +0200, Sa?o Kiselkov wrote:
> Just wanted to report a bug against OmniOS ntp and noticed that there
> isn't a go-to place for that (or my searched turned up dry). Is there a
> way to do this?

The wiki doesn't allow anonymous users to open tickets, or for
self-registration, you need to request an account, then you can update
the wiki or open tickets. You can see the open tickets at:

http://omnios.omniti.com/report.php/1

I'll let an official omnios representative follow up with details...


From skiselkov.ml at gmail.com  Sun May 12 16:36:04 2013
From: skiselkov.ml at gmail.com (=?UTF-8?B?U2HFoW8gS2lzZWxrb3Y=?=)
Date: Sun, 12 May 2013 22:36:04 +0200
Subject: [OmniOS-discuss] Where to file bugs?
In-Reply-To: <20130512202524.GD30773@bender.unx.csupomona.edu>
References: <518FE86A.5040000@gmail.com>
	<20130512202524.GD30773@bender.unx.csupomona.edu>
Message-ID: <518FFD34.1040204@gmail.com>

On 05/12/2013 10:25 PM, Paul B. Henson wrote:
> On Sun, May 12, 2013 at 09:07:22PM +0200, Sa?o Kiselkov wrote:
>> Just wanted to report a bug against OmniOS ntp and noticed that there
>> isn't a go-to place for that (or my searched turned up dry). Is there a
>> way to do this?
> 
> The wiki doesn't allow anonymous users to open tickets, or for
> self-registration, you need to request an account, then you can update
> the wiki or open tickets. You can see the open tickets at:
> 
> http://omnios.omniti.com/report.php/1
> 
> I'll let an official omnios representative follow up with details...

Ouch, that's sort of bummer. How does one request an account then,
officially?

Cheers,
-- 
Saso

From henson at acm.org  Sun May 12 17:02:01 2013
From: henson at acm.org (Paul B. Henson)
Date: Sun, 12 May 2013 14:02:01 -0700
Subject: [OmniOS-discuss] Where to file bugs?
In-Reply-To: <518FFD34.1040204@gmail.com>
References: <518FE86A.5040000@gmail.com>
	<20130512202524.GD30773@bender.unx.csupomona.edu>
	<518FFD34.1040204@gmail.com>
Message-ID: <20130512210201.GE30773@bender.unx.csupomona.edu>

On Sun, May 12, 2013 at 10:36:04PM +0200, Sa?o Kiselkov wrote:

> Ouch, that's sort of bummer. How does one request an account then,
> officially?

Typically somebody asks, like you just did, how to update the wiki or
open a bug, and then somebody from omnios offers to make them an
account. Dunno how official that process is ;). It would be more end
user friendly to have a self-registration bugzilla/trouble ticket
system, but we're already getting a sweet OS for free, so can't complain
:)...


From skiselkov.ml at gmail.com  Mon May 13 05:14:49 2013
From: skiselkov.ml at gmail.com (=?UTF-8?B?U2HFoW8gS2lzZWxrb3Y=?=)
Date: Mon, 13 May 2013 11:14:49 +0200
Subject: [OmniOS-discuss] Where to file bugs?
In-Reply-To: <20130512210201.GE30773@bender.unx.csupomona.edu>
References: <518FE86A.5040000@gmail.com>
	<20130512202524.GD30773@bender.unx.csupomona.edu>
	<518FFD34.1040204@gmail.com>
	<20130512210201.GE30773@bender.unx.csupomona.edu>
Message-ID: <5190AF09.5050809@gmail.com>

On 05/12/2013 11:02 PM, Paul B. Henson wrote:
> It would be more end
> user friendly to have a self-registration bugzilla/trouble ticket
> system, but we're already getting a sweet OS for free, so can't complain
> :)...

Yep, and that's why I want to return the favor by reporting bugs and
fixes. Fortunately, it appears that the guys at OmniTI are watching the
issue tracker on Github, plus, as you suggested, they will create a
bugtracker account upon request.

Cheers,
-- 
Saso

From garrett at damore.org  Sun May 12 12:25:00 2013
From: garrett at damore.org (Garrett D'Amore)
Date: Sun, 12 May 2013 09:25:00 -0700
Subject: [OmniOS-discuss] [discuss] Re: Trouble getting Supermicro board
	to see all its PCI-e slots
In-Reply-To: <518FA9E6.6070800@gmail.com>
References: <517F9A19.7030707@gmail.com> <518FA9E6.6070800@gmail.com>
Message-ID: <5EC16CFE-3289-4AE6-ACC5-2CDDD51E3F39@damore.org>

Thanks Saso.

Perhaps at some point we'll buy one and I'll be able to find some cycles to work on it directly? that hasn't been possible in the past couple of weeks due to other priorities.

	- Garrett

On May 12, 2013, at 7:40 AM, Sa?o Kiselkov <skiselkov.ml at gmail.com> wrote:

> Just wanted to create a full-up on this for people to know: I haven't
> been able to resolve this issue in time, and have to put the machine
> into production as-is (with 4 out of the 6 PCI-e slots non-functional).
> 
> So an important heads-up for anybody considering buying Intel
> C602J-based boards, especially those from Supermicro: any PCI-e slots
> attached to CPU socket 02 may not work with current Illumos-based OSes.
> Keep this in mind when making purchasing decisions.
> 
> Cheers,
> -- 
> Saso
> 
> 
> -------------------------------------------
> illumos-discuss
> Archives: https://www.listbox.com/member/archive/182180/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182180/22003744-9012f59c
> Modify Your Subscription: https://www.listbox.com/member/?member_id=22003744&id_secret=22003744-e9cd8436
> Powered by Listbox: http://www.listbox.com


From carlopmart at gmail.com  Mon May 13 14:55:10 2013
From: carlopmart at gmail.com (C. L. Martinez)
Date: Mon, 13 May 2013 18:55:10 +0000
Subject: [OmniOS-discuss] Omnios as a zfs storage server under esxi 5.1
Message-ID: <CAEjQA5+fVF3kWFWrRXS5A_UnfELW7Fw7Bu99k3XMR+LTPVQwxA@mail.gmail.com>

Hi all,

Next month, we need to deploy an omnios virtual machine to act as storage
server under esxi 5.1. We can not use bare metal server, and I know that is
a problem.

We are thinking in disable zil. Is it recommended when omnios is installed
as a vm?? And we can not use pci passthrough esxi feature due to vmotion
and HA features enabled in these esxi servers.

Any recommendations about how to configure this vm?

At first stage we can allocate 8 gb of ram and 4 vcpus. And wr need to
manage 5 tb of data with snapshots and maybr compression in certain zfs
volumes.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130513/689e333d/attachment.html>

From dswartz at druber.com  Mon May 13 15:15:36 2013
From: dswartz at druber.com (Dan Swartzendruber)
Date: Mon, 13 May 2013 15:15:36 -0400
Subject: [OmniOS-discuss] Omnios as a zfs storage server under esxi 5.1
In-Reply-To: <CAEjQA5+fVF3kWFWrRXS5A_UnfELW7Fw7Bu99k3XMR+LTPVQwxA@mail.gmail.com>
References: <CAEjQA5+fVF3kWFWrRXS5A_UnfELW7Fw7Bu99k3XMR+LTPVQwxA@mail.gmail.com>
Message-ID: <1227872da05be316c38e8d0d60c6c8b6.squirrel@webmail.druber.com>

> Hi all,
>
> Next month, we need to deploy an omnios virtual machine to act as storage
> server under esxi 5.1. We can not use bare metal server, and I know that
> is
> a problem.
>
> We are thinking in disable zil. Is it recommended when omnios is installed
> as a vm?? And we can not use pci passthrough esxi feature due to vmotion
> and HA features enabled in these esxi servers.
>
> Any recommendations about how to configure this vm?
>
> At first stage we can allocate 8 gb of ram and 4 vcpus. And wr need to
> manage 5 tb of data with snapshots and maybr compression in certain zfs
> volumes.

I'm not sure I understand your comment about HA/vmotion.  If this is going
to be a storage appliance, it will be locked to one host anyway, so the
pci passthrough restrictions should not concern you.  Or am I
misunderstanding something?  On the other note, if you are running a ZFS
virtual appliance, I would not worry about disabling sync, since the
likelihood of a bug that only crashes the appliance as opposed to the
entire host seems small.  I am willing to take that chance, since I do
hourly replications of my guests.


From alka at hfg-gmuend.de  Mon May 13 15:21:18 2013
From: alka at hfg-gmuend.de (=?ISO-8859-1?Q?G=FCnther_Alka?=)
Date: Mon, 13 May 2013 21:21:18 +0200
Subject: [OmniOS-discuss] Omnios as a zfs storage server under esxi 5.1
In-Reply-To: <CAEjQA5+fVF3kWFWrRXS5A_UnfELW7Fw7Bu99k3XMR+LTPVQwxA@mail.gmail.com>
References: <CAEjQA5+fVF3kWFWrRXS5A_UnfELW7Fw7Bu99k3XMR+LTPVQwxA@mail.gmail.com>
Message-ID: <51913D2E.5030009@hfg-gmuend.de>

First of all, a virtualized SAN is not a problem but a good idea on a 
lot of use cases unless you can supply the same CPU, RAM and disk 
recommendations like you would do on on real hardware. It is also not a 
problem, that you cannot do vmotion with your SAN-VM (How would you 
vmotion your physical disks??)

But you must provide:
- real hardware access to controller and disks (needs pass-through/vt-d) 
for your SAN VM OmniOS
- assign enough RAM for caching (Arc-cache), the more the faster
- be not CPU limited

If you need a ZIL or better disable sync write depends on use case.
If you build an All-In-One (ESXi with virtualized SAN), all your guests 
go down together with your SAN,
so mostly a ZIL costs money and performance but cannot improve security.

You should also trythe ESXI highspeed VMXnet3 network drivers (unless 
you find problems with them like some others)
If you intend to use compression, use LZ4 (with newest OmnoOS stable 
with bugfixes for LZ4)

Have you read my manuals (hope they are helpful)?
http://www.napp-it.org/doc/downloads/all-in-one.pdf and
http://napp-it.org/doc/ESXi-OmniOS_Installation_HOWTO_en.pdf

Gea


On 13.05.2013 20:55, C. L. Martinez wrote:
> Hi all,
>
> Next month, we need to deploy an omnios virtual machine to act as 
> storage server under esxi 5.1. We can not use bare metal server, and I 
> know that is a problem.
>
> We are thinking in disable zil. Is it recommended when omnios is 
> installed as a vm?? And we can not use pci passthrough esxi feature 
> due to vmotion and HA features enabled in these esxi servers.
>
> Any recommendations about how to configure this vm?
>
> At first stage we can allocate 8 gb of ram and 4 vcpus. And wr need to 
> manage 5 tb of data with snapshots and maybr compression in certain 
> zfs volumes.
>
> Thanks
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


-- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130513/3b726c29/attachment.html>

From carlopmart at gmail.com  Tue May 14 02:01:55 2013
From: carlopmart at gmail.com (C. L. Martinez)
Date: Tue, 14 May 2013 06:01:55 +0000
Subject: [OmniOS-discuss] Omnios as a zfs storage server under esxi 5.1
In-Reply-To: <51913D2E.5030009@hfg-gmuend.de>
References: <CAEjQA5+fVF3kWFWrRXS5A_UnfELW7Fw7Bu99k3XMR+LTPVQwxA@mail.gmail.com>
	<51913D2E.5030009@hfg-gmuend.de>
Message-ID: <CAEjQA5KtfxGam3btQ52bU-b5rdffFjv92ugvmm5m0fg+XoMtkQ@mail.gmail.com>

On Mon, May 13, 2013 at 7:21 PM, G?nther Alka <alka at hfg-gmuend.de> wrote:
> First of all, a virtualized SAN is not a problem but a good idea on a lot of
> use cases unless you can supply the same CPU, RAM and disk recommendations
> like you would do on on real hardware. It is also not a problem, that you
> cannot do vmotion with your SAN-VM (How would you vmotion your physical
> disks??)
>
> But you must provide:
> - real hardware access to controller and disks (needs pass-through/vt-d) for
> your SAN VM OmniOS
> - assign enough RAM for caching (Arc-cache), the more the faster
> - be not CPU limited
>
> If you need a ZIL or better disable sync write depends on use case.
> If you build an All-In-One (ESXi with virtualized SAN), all your guests go
> down together with your SAN,
> so mostly a ZIL costs money and performance but cannot improve security.
>
> You should also trythe ESXI highspeed VMXnet3 network drivers (unless you
> find problems with them like some others)
> If you intend to use compression, use LZ4 (with newest OmnoOS stable with
> bugfixes for LZ4)
>
> Have you read my manuals (hope they are helpful)?
> http://www.napp-it.org/doc/downloads/all-in-one.pdf and
> http://napp-it.org/doc/ESXi-OmniOS_Installation_HOWTO_en.pdf
>
> Gea
>
>

Many thanks G?nther and Dan for your answers. But still I have some doubts:

a) I can't assign real hardware access to this VM, but i can assign
disks using RDM.
b) How can I calculate how many Arc-cache do I need??
c) Is it safe to use vmxnet3 nic driver for this production
environment?? I prefer to use e1000 driver f the performance does not
goes down.

I have read your manuals G?nther, and they are very clear to
accomplish an OmniOS install and some performance tips. However, I am
very concerned about the issue of calculating the Arc-cache and if it
is safe (from a point of view of data integrity) to disable the ZIL in
a virtualization environment.

From dswartz at druber.com  Tue May 14 08:27:08 2013
From: dswartz at druber.com (Dan Swartzendruber)
Date: Tue, 14 May 2013 08:27:08 -0400
Subject: [OmniOS-discuss] Omnios as a zfs storage server under esxi 5.1
In-Reply-To: <CAEjQA5KtfxGam3btQ52bU-b5rdffFjv92ugvmm5m0fg+XoMtkQ@mail.gmail.com>
References: <CAEjQA5+fVF3kWFWrRXS5A_UnfELW7Fw7Bu99k3XMR+LTPVQwxA@mail.gmail.com>
	<51913D2E.5030009@hfg-gmuend.de>
	<CAEjQA5KtfxGam3btQ52bU-b5rdffFjv92ugvmm5m0fg+XoMtkQ@mail.gmail.com>
Message-ID: <dfdc45158b0c3325c43533cc7682773c.squirrel@webmail.druber.com>


> Many thanks G??nther and Dan for your answers. But still I have some
> doubts:
>
> a) I can't assign real hardware access to this VM, but i can assign
> disks using RDM.
> b) How can I calculate how many Arc-cache do I need??
> c) Is it safe to use vmxnet3 nic driver for this production
> environment?? I prefer to use e1000 driver f the performance does not
> goes down.
>
> I have read your manuals G??nther, and they are very clear to
> accomplish an OmniOS install and some performance tips. However, I am
> very concerned about the issue of calculating the Arc-cache and if it
> is safe (from a point of view of data integrity) to disable the ZIL in
> a virtualization environment.

Maybe I am wrong but if you have physical disks connected to host X and
map RDMs to a specific guest, that guest will not be vmotion-capable
either (how could it?  the resources are fixed to host X, no?)  Also, to
reiterate, unless the OS on the storage appliance crashes, most any crash
will be the entire host, in which case zil does not matter.  AFAIK,
vmxnet3 drive works, but you can use e1000, which is very reliable.


From natxo.asenjo at gmail.com  Tue May 14 13:30:47 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Tue, 14 May 2013 19:30:47 +0200
Subject: [OmniOS-discuss] server spontanously reboots on cifs action
Message-ID: <CAHBEJzXjUupmPc9JNUuun6_CMm9W-K6q_nc5rG9=qxJbJGNW8Q@mail.gmail.com>

hi,

today twice I have experimented this while removing a (largish) folder
infrastructure with plenty of pictures. I was removing the folder first
with the windows explorer and then with the command rd /s /q in a cmd.exe
prompt.

This does not happen when removing the same folder directly on the server.
The user has no administrative privileges.

The hardware is a microserver HP N40L, with the rpool on 2 usb sticks.
Could this be the problem? The data pool where the files where is a raidz
pool with 4 3TiB disks (wd red).

Where can I find more info on this? /var/adm/messages shows nothing
relevant. My solaris knowlegde is too limitied yet.

TIA,
--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130514/9ad54684/attachment.html>

From henson at acm.org  Wed May 15 17:37:11 2013
From: henson at acm.org (Paul B. Henson)
Date: Wed, 15 May 2013 14:37:11 -0700
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <CAHBEJzXSxpKTc8sP8mXLcFT5SZnBJvqZBmsDNSOgzqrY7cqfdA@mail.gmail.com>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
	<CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
	<518D8290.8070204@acm.org>
	<CAHBEJzVG==Wh2s5OFNocqnsQHTayADigtNHjn9kO6XtCham-9g@mail.gmail.com>
	<20130511203513.GC30773@bender.unx.csupomona.edu>
	<CAHBEJzXSxpKTc8sP8mXLcFT5SZnBJvqZBmsDNSOgzqrY7cqfdA@mail.gmail.com>
Message-ID: <51940007.8080703@acm.org>

On 5/12/2013 1:00 AM, Natxo Asenjo wrote:

> I see the illumos nfs 4.1 project is a bti 'inactive' ;-), but it'll
> come one day I guess.

I think Nexenta was working on it back when Garrett was employed there, 
I remember he told me it was under development but they weren't sure 
when it would be integrated upstream. I'm not sure what's going on with 
nexenta lately, the deb-based distribution illumian seems to be 
stillborn, and I don't think even their commercial product has been 
updated to be based on illumos (other than maybe a beta) rather than 
opensolaris with various things backported.

Hopefully nexenta or one of the commercial illumos vendors will get that 
going, that's probably a big project. As it becomes available in other 
options, it's going to start turning into a requirement to be competitive.

> no, it does when moving a file though :
>
> $ mv testmove /net/zfstank.ipa.asenjo.nx/tank/testshare/
> mv: preserving permissions for
> `/net/zfstank.ipa.asenjo.nx/tank/testshare/testmove': Operation not
> permitted

Yes, the move does a separate open and then chmod, so the direct call to 
chmod gets a failure.

From henson at acm.org  Wed May 15 17:47:41 2013
From: henson at acm.org (Paul B. Henson)
Date: Wed, 15 May 2013 14:47:41 -0700
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <CAHBEJzW5FE8eFhiVAdgYL5ZXnAQmgFnQf5dqh=WVnydeEWEG+Q@mail.gmail.com>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
	<CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
	<518D8290.8070204@acm.org>
	<CAHBEJzVG==Wh2s5OFNocqnsQHTayADigtNHjn9kO6XtCham-9g@mail.gmail.com>
	<20130511203513.GC30773@bender.unx.csupomona.edu>
	<CAHBEJzXSxpKTc8sP8mXLcFT5SZnBJvqZBmsDNSOgzqrY7cqfdA@mail.gmail.com>
	<CAHBEJzW5FE8eFhiVAdgYL5ZXnAQmgFnQf5dqh=WVnydeEWEG+Q@mail.gmail.com>
Message-ID: <5194027D.8010002@acm.org>

On 5/12/2013 1:21 PM, Natxo Asenjo wrote:

> mm, when using scp it bypasses the acl as well ..., grrr.

Even with aclmode=restricted?



From ben at fluffy.co.uk  Thu May 16 06:17:12 2013
From: ben at fluffy.co.uk (Ben Summers)
Date: Thu, 16 May 2013 11:17:12 +0100
Subject: [OmniOS-discuss] Trust and OmniOS installs
In-Reply-To: <65CFF923-0D4C-401A-966E-480D0065DF5B@fluffy.co.uk>
References: <65CFF923-0D4C-401A-966E-480D0065DF5B@fluffy.co.uk>
Message-ID: <19B2A92A-44CF-4D8A-993F-D986A3B6A3F4@fluffy.co.uk>


On 8 May 2013, at 14:50, Ben Summers <ben at fluffy.co.uk> wrote:

> 
> Hello,
> 
> I'm rebuilding our infrastructure based on OmniOS, migrating away from Solaris 10. It's great to have a modern and minimal Solarish OS for which you can buy a support contract. (And that vendor not be Oracle.)
> 
> We do have one slight problem in our environment, that we have to trust the network to be able to use the OmniTI repos since they're served over plain HTTP.
> 
> Obviously we have to trust our OS vendor, but I suspect the requirement to trust the network would cause problems with audits from our customers. And besides, we're a security focused company offering a "secure" service, so I like to do things properly.
> 
> Unless OmniTI are kind enough enable https on pkg.omniti.com, is there a way to minimise the number of third parties we are trusting?
> 
> Could we create a mirror somehow over our relatively trusted network in the colo? Or would a simple https proxy work?


To reply to my own message, after discussing with the OmniTI chaps on IRC, and doing a bit of research, it looks like the best solution (that _I_ can implement) is to run a mirror and sign the packages, rather than using an https proxy: https will make it go really slowly.

I had a bit of a play with mirroring and package signing. My notes are below.

In summary, it works well, but I had to make a small patch to the IPS tools because there's a version mismatch with the python M2Crypto library.

So a plan to minimise trust on the network would be to:

 * Run our own mirror of the OmniOS repo in our colo.

 * Write a small script to use pkgrecv to fetch new packages, then pkgsign to sign them.

 * Add our CA certificate to our OmniOS install and change the policy and publisher URL.

Note that this is easy because pkgsign works independently of package creation. IPS' enterprisey roots help here, as it's intended for things like QA signing off on packages before they get deployed.

This isn't a full solution, as there's still trust on the network between OmniTI and our colo network and it complicates disaster recovery, but it's a reasonable workaround, and if we're happy with a set of packages, we can be sure they never change.


If OmniTI wanted to sign their packages and eliminate the problem for everyone, they would need to:

 * Add a CA root to their distribution, and set signature-policy=require-signatures for their IPS publisher

 * After building new packages and sending them to the repo, sign them as a separate step

 * Make available over a separate trusted channel the digest of the ISO image containing the CA root, to start the chain of trust.

This would add maybe 850 bytes to each manifest, but otherwise have no impact on performance. Reasons for OmniTI not doing this are practical issues around running a CA and the extra step in the release process.

Ben




# Get a copy of the OmniOS repo

zfs create -o mountpoint=/export/repos rpool/repos
pkgrepo create /export/repos/omnios
pkgrecv -s http://pkg.omniti.com/omnios/release/ -d /export/repos/omnios '*'
zfs snapshot rpool/repos at after-pkgrecv

# (running pkgrecv again will fetch new packages)


# Get list of all package FMRIs in the repo:

pkgrepo list -s /export/repos/omnios -H -F tsv | awk -F $'\t' 'BEGIN {OFS = FS} {print $8}' > all_pkgs


# Remove one package from the list, for testing

vi all_pkgs
  ... delete the rsync line


# Make a CA and a signing certificate with a hacky CA script (copy at end)

python repo_ca_tool.py repo-test-ca ca
python repo_ca_tool.py repo-test-ca signer "Test Signer"


# Sign all the packages

xargs pkgsign -s /export/repos/omnios/ -a rsa-sha384 -k repo-test-ca/test_signer.key -c repo-test-ca/test_signer.crt -i repo-test-ca/ca.crt < all_pkgs


# Output the the CA cert for use later

cat repo-test-ca/ca.crt 


# Make a repo server config file

vi pkg_depotd.cfg 

------------------
[pkg]
port = 80
inst_root = /export/repos/omnios

[omnios]
feed_description = OmniOS mirror
  update log
------------------

# Run a repo server

/usr/lib/pkg.depotd --cfg pkg_depotd.cfg 


# Visit in web browse to check:

   http://192.168.84.147/omnios/

(view a manifest, note it as a signature line at the very bottom. Look at the rsync manifest, note it doesn't.)


# Change a manifest to break a signature

cd /export/repos/omnios/publisher/omnios/pkg/developer%2Fbuild%2Fautoconf
vi   2.69%2C5.11-0.151006%3A20130506T182715Z
(change a single byte somewhere)


-----------------------------------------------------

# Install OmniOS into a virtual machine, create user...

groupadd ben
useradd -g ben -s /bin/bash -d /export/home/ben -c "Ben Summers" -P "Primary Administrator" -m ben
passwd ben
ipadm create-if e1000g0
ipadm create-addr -T dhcp e1000g0/v4dhcp
init 6

# Log into new VM with ssh.

# Replace the URL of the omnios publisher

pfexec pkg set-publisher -g http://192.168.84.147/omnios/ -G http://pkg.omniti.com/omnios/release/ omnios

# Copy and paste the CA certificate from above into a file

vi /tmp/ca.crt
  ... paste cert... 

# Then set it, and delete the file

pfexec pkg set-publisher --approve-ca-cert /tmp/ca.crt omnios
rm /tmp/ca.crt


# Tell pkg we only want signed packages on this system

pfexec pkg set-property signature-policy require-signatures


# And also for the publisher, for good measure (not sure it's required)

pfexec pkg set-publisher --set-property signature-policy=require-signatures omnios


# Do a pkg update

pkg update

   ... which fails, because there appears to be a version mismatch with the python m2 library.

pfexec vi /usr/lib/python2.6/vendor-packages/pkg/actions/signature.py

edit line 319 -> 
                pub_key = cert.get_pubkey()
                pub_key.reset_context(md=self.hash_alg)
(removing argument, adding extra line)

# Now it works

pfexec pkg update
pfexec pkg install pkg:/package/pkg

# And let's install a signed package

pfexec pkg install gnu-tar

# But rsync can't be installed, because we didn't sign it.

pfexec pkg install rsync

Creating Plan \               
pkg install: The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/network/rsync at 3.0.9,5.11-0.151006:20130506T190016Z.

# And autoconf can't be installed, because we changed the manifest

pfexec pkg install autoconf

Creating Plan \               
Errors were encountered while attempting to retrieve package or file data for
the requested operation.
Details follow:

Invalid content: manifest hash failure: fmri: pkg://omnios/developer/build/autoconf at 2.69,5.11-0.151006:20130506T182715Z 
expected: 1bd3c48103a369222daba31ec3b9a3214273769c computed: 29cc39b07f5c988b2114fec6477299329d86dc35. (happened 4 times)





------------------------------------------------------------------
#!/usr/bin/env python

import os, sys, subprocess, re

def fatal_error(msg):
    sys.stderr.write(msg+"\n")
    exit(1)

if len(sys.argv) < 3:
    print "usage: ca_tools <dir> <action> [<common name>]"
    print "  action = ca or signer"
    print "  cert requires common name for cert"
    fatal_error("Bad command line args")
    exit(1)

ca_dir = sys.argv[1]
action = sys.argv[2]
common_name = None
if action == 'signer':
    if len(sys.argv) < 4:
        fatal_error("No common name")
    common_name = sys.argv[3]

def make_key(filename):
    if 0 != os.system("openssl genrsa -out "+filename+" 2048"):
        fatal_error("Failed to create key "+filename)

def make_cert(filename, key, common_name, signextra = ''):
    cmd = ["openssl", "req", "-new", "-key", key, "-out", filename+'.csr']
    crt = subprocess.Popen(cmd, stdin=subprocess.PIPE)
    crt.stdin.write(".\n.\n.\n.\n.\n"+common_name+"\n.\n\n\n")
    crt.wait()
    sign_cmd = "openssl x509 -req -sha1 "+signextra+" -days 3650 -in "+filename+'.csr -out '+filename+'.crt'
    if not "CAkey" in sign_cmd:
        sign_cmd = sign_cmd + " -signkey "+key
    if 0 != os.system(sign_cmd):
        fatal_error("Failed to sign cert")

if action == 'ca':
    if os.path.isdir(ca_dir):
        fatal_error(ca_dir + " already exists")
    os.makedirs(ca_dir)
    make_key(ca_dir + '/ca.key')
    make_cert(ca_dir + '/ca', ca_dir + '/ca.key', "PKG CA", "-extensions v3_ca")
    with open(ca_dir + '/ca.srl', "w") as f:
        f.write("10\n")

elif action == 'signer':
    basename = ca_dir+'/'+re.sub(r'[^a-z0-9]', '_', common_name.lower())
    if os.path.isfile(basename+'.key'):
        fatal_error("Already made certs for "+common_name)
    make_key(basename+'.key')
    make_cert(basename, basename+'.key', common_name, "-extensions usr_crt -CA "+ca_dir+"/ca.crt -CAkey "+ca_dir+"/ca.key -CAserial "+ca_dir+"/ca.srl")

else:
    fatal_error("Unknown action "+action)

------------------------------------------------------------------










--
http://bens.me.uk


From a.shvayakov at gmail.com  Thu May 16 12:19:11 2013
From: a.shvayakov at gmail.com (Shvayakov A.)
Date: Thu, 16 May 2013 19:19:11 +0300
Subject: [OmniOS-discuss] Limits for the NSF and iSCSI
Message-ID: <519506FF.5000901@gmail.com>

Hi,

My storage server provides the NSF and COMSTAR iSCSI.
Can you tell about  a better ways to limiting this resources?
Need to avoid the situation that one client with a large appetite 
couldn't do other clients hungry.

Is there a means to limit the activity of I/O for a each LUN or dataset?

I think that better do these limits  at the network level (IP QoS). 
Isn't it?

Best regards,
Alexander Shvayakov

From natxo.asenjo at gmail.com  Thu May 16 16:10:27 2013
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Thu, 16 May 2013 22:10:27 +0200
Subject: [OmniOS-discuss] nfsv4 acls wtf moment
In-Reply-To: <5194027D.8010002@acm.org>
References: <CAHBEJzX=qSNMPnA=i14x4CWgRStqm-46V53TVw2tWk8p+nhJYw@mail.gmail.com>
	<518CFA77.6060403@nixtra.com>
	<CAHBEJzUwBwCLfN=kbpBi5LFyt9mVPUs-pbj9AihqQcqMyfzmBg@mail.gmail.com>
	<CAHBEJzX7sj1RPBwucWnRbWB5pB807FDaLsfG3Q7Z6dPOfeHwbw@mail.gmail.com>
	<518D8290.8070204@acm.org>
	<CAHBEJzVG==Wh2s5OFNocqnsQHTayADigtNHjn9kO6XtCham-9g@mail.gmail.com>
	<20130511203513.GC30773@bender.unx.csupomona.edu>
	<CAHBEJzXSxpKTc8sP8mXLcFT5SZnBJvqZBmsDNSOgzqrY7cqfdA@mail.gmail.com>
	<CAHBEJzW5FE8eFhiVAdgYL5ZXnAQmgFnQf5dqh=WVnydeEWEG+Q@mail.gmail.com>
	<5194027D.8010002@acm.org>
Message-ID: <CAHBEJzVr3H4HC=g=+s2bKqN5ETpYFWHBJvMk9MuStTEH6CxZ0w@mail.gmail.com>

On Wed, May 15, 2013 at 11:47 PM, Paul B. Henson <henson at acm.org> wrote:

> On 5/12/2013 1:21 PM, Natxo Asenjo wrote:
>
>  mm, when using scp it bypasses the acl as well ..., grrr.
>>
>
> Even with aclmode=restricted?
>

strangely enough, on one share yes, the other no. The difference is the
share root dir permissions

# /bin/ls -vd /tank/testshare/
drwxrwxrwx+ 10 root     root          10 May 16 07:31 /tank/testshare/
     0:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow

# bin/ls -vd /tank/fotos/
d---------+289 root     root         290 May 16 07:32 /tank/fotos/
     0:user:username:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow

on the /tank/fotos, when I scp as root the root umask sets extra aces, on
the /tank/testshare dir when I scp as root the ace is respected

root at zfstank:~# zfs get all tank/testshare | grep acl
tank/testshare  aclmode               restricted              local
tank/testshare  aclinherit            passthrough             local
root at zfstank:~# zfs get all tank/fotos | grep acl
tank/fotos  aclmode               restricted             local
tank/fotos  aclinherit            passthrough            local

$ scp -r dosbox/ root at zfstank:/tank/testshare/testdir

# /bin/ls -vd /tank/testshare/testdir/
drwxrwxrwx+  4 root     root           5 May 16 22:03
/tank/testshare/testdir/
     0:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit
         /inherited:allow

$ scp -r dosbox/ root at zfstank:/tank/fotos/testdir

# /bin/ls -vd /tank/fotos/testdir
drwxr-xr-x+  4 root     root           5 May 16 22:03 /tank/fotos/testdir/
     0:user:username:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit
         /inherited:allow
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     2:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

strange. I am going to open a bug with redhat to see if they can get to fix
coreutils and the ssh client to respect nfsv4 aces instead of bypassing the
stuff. We'll see.

-- 
groet,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130516/180fd199/attachment.html>

From esproul at omniti.com  Thu May 16 17:03:01 2013
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 16 May 2013 17:03:01 -0400
Subject: [OmniOS-discuss] Updated release: r151006c
Message-ID: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>

The first weekly release of the r151006 cycle brings a kernel update,
ntp scheduler priority fix and more:
http://omnios.omniti.com/wiki.php/ReleaseNotes#r151006c

From skiselkov.ml at gmail.com  Thu May 16 19:02:23 2013
From: skiselkov.ml at gmail.com (=?windows-1252?Q?Sa=9Ao_Kiselkov?=)
Date: Fri, 17 May 2013 01:02:23 +0200
Subject: [OmniOS-discuss] Updated release: r151006c
In-Reply-To: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
References: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
Message-ID: <5195657F.1060507@gmail.com>

On 05/16/2013 11:03 PM, Eric Sproul wrote:
> The first weekly release of the r151006 cycle brings a kernel update,
> ntp scheduler priority fix and more:
> http://omnios.omniti.com/wiki.php/ReleaseNotes#r151006c

Running latest stable (r151006), I'm getting:

# pkg update
Creating Plan \
pkg update: No solution was found to satisfy constraints
Plan Creation: Package solver has not found a solution to update to
latest available versions.
This may indicate an overly constrained set of packages are installed.

latest incorporations:


pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130514T014154Z

The following indicates why the system cannot update to the latest version:

  No suitable version of required package
pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130514T014154Z
found:
    Reject:
pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130514T014154Z
    Reason:  All versions matching 'incorporate' dependency
pkg:/SUNWcs at 0.5.11,5.11-0.151007 are rejected
      Reject:  pkg://omnios/SUNWcs at 0.5.11,5.11-0.151007:20130514T014157Z
      Reason:  A version for 'require' dependency on
pkg:/runtime/perl at 5.16.1,5.11-0.151006 cannot be found

Any ideas what I'm doing wrong?

Cheers,
-- 
Saso

From daleg at omniti.com  Thu May 16 23:10:11 2013
From: daleg at omniti.com (daleg at omniti.com)
Date: Thu, 16 May 2013 23:10:11 -0400
Subject: [OmniOS-discuss] Updated release: r151006c
In-Reply-To: <5195657F.1060507@gmail.com>
References: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
	<5195657F.1060507@gmail.com>
Message-ID: <9788AD83-C359-4E8F-8AE5-C42F8B5ADE5F@omniti.com>



151007 is Bloody. What is your publisher set to?

/dale

On May 16, 2013, at 7:02 PM, Sa?o Kiselkov <skiselkov.ml at gmail.com> wrote:

> On 05/16/2013 11:03 PM, Eric Sproul wrote:
>> The first weekly release of the r151006 cycle brings a kernel update,
>> ntp scheduler priority fix and more:
>> http://omnios.omniti.com/wiki.php/ReleaseNotes#r151006c
> 
> Running latest stable (r151006), I'm getting:
> 
> # pkg update
> Creating Plan \
> pkg update: No solution was found to satisfy constraints
> Plan Creation: Package solver has not found a solution to update to
> latest available versions.
> This may indicate an overly constrained set of packages are installed.
> 
> latest incorporations:
> 
> 
> pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130514T014154Z
> 
> The following indicates why the system cannot update to the latest version:
> 
>  No suitable version of required package
> pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130514T014154Z
> found:
>    Reject:
> pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130514T014154Z
>    Reason:  All versions matching 'incorporate' dependency
> pkg:/SUNWcs at 0.5.11,5.11-0.151007 are rejected
>      Reject:  pkg://omnios/SUNWcs at 0.5.11,5.11-0.151007:20130514T014157Z
>      Reason:  A version for 'require' dependency on
> pkg:/runtime/perl at 5.16.1,5.11-0.151006 cannot be found
> 
> Any ideas what I'm doing wrong?
> 
> Cheers,
> -- 
> Saso
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From richard.palo at baou.fr  Fri May 17 00:39:36 2013
From: richard.palo at baou.fr (Richard PALO)
Date: Fri, 17 May 2013 06:39:36 +0200
Subject: [OmniOS-discuss] some problems with last update to bloody
	omnios-8d266aa 64-bit
In-Reply-To: <kmcuvs$jmu$1@ger.gmane.org>
References: <kmcuvs$jmu$1@ger.gmane.org>
Message-ID: <kn4ca3$148$1@ger.gmane.org>

Hi, just did an update of bloody, but the problem remains.
Guess I'd like an account as well in order to file eventual problem reports.



From skiselkov.ml at gmail.com  Fri May 17 02:19:56 2013
From: skiselkov.ml at gmail.com (=?windows-1252?Q?Sa=9Ao_Kiselkov?=)
Date: Fri, 17 May 2013 08:19:56 +0200
Subject: [OmniOS-discuss] Updated release: r151006c
In-Reply-To: <9788AD83-C359-4E8F-8AE5-C42F8B5ADE5F@omniti.com>
References: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
	<5195657F.1060507@gmail.com>
	<9788AD83-C359-4E8F-8AE5-C42F8B5ADE5F@omniti.com>
Message-ID: <5195CC0C.8040907@gmail.com>

On 05/17/2013 05:10 AM, daleg at omniti.com wrote:
> 
> 
> 151007 is Bloody. What is your publisher set to?

Right, damn, I originally installed bloody a few months back and assumed
that with the release of r151006 I will have switched to the stable
release train. My bad.

Cheers,
-- 
Saso

From sk at kram.io  Fri May 17 06:36:00 2013
From: sk at kram.io (Steffen Kram)
Date: Fri, 17 May 2013 12:36:00 +0200
Subject: [OmniOS-discuss] Updated release: r151006c
In-Reply-To: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
References: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
Message-ID: <931A1612-58F3-4AD8-A239-87D3A86BD2E5@kram.io>

Hi,

maybe I'm doing it wrong, but I'm not able to pkg update my non-global zones after upgrading the global zone to r151006c. As stated on the release notes page, I shut down my non-global zones, updated the global-zone, went through a reboot, stared the non-global zones again and tried to update them as well:

# pkg update
            Packages to update:   5
       Create boot environment: Yes
Create backup boot environment:  No

DOWNLOAD                                  PKGS       FILES    XFER (MB)
Completed                                  5/5     334/334    14.9/14.9

pkg: Unable to clone the current boot environment.

I then tried to prevent pkg update from cloning the boot environment:

# pkg update --no-backup-be --deny-new-be

pkg update: The proposed operation cannot be performed on a live image.

As you see, this did not work either. Any suggestions what I'm doing wrong and how I can update my non-global zones?

Cheers, Steffen



Am 16.05.2013 um 23:03 schrieb Eric Sproul <esproul at omniti.com>:

> The first weekly release of the r151006 cycle brings a kernel update,
> ntp scheduler priority fix and more:
> http://omnios.omniti.com/wiki.php/ReleaseNotes#r151006c
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 


From skiselkov.ml at gmail.com  Fri May 17 06:51:04 2013
From: skiselkov.ml at gmail.com (=?windows-1252?Q?Sa=9Ao_Kiselkov?=)
Date: Fri, 17 May 2013 12:51:04 +0200
Subject: [OmniOS-discuss] Updated release: r151006c
In-Reply-To: <931A1612-58F3-4AD8-A239-87D3A86BD2E5@kram.io>
References: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
	<931A1612-58F3-4AD8-A239-87D3A86BD2E5@kram.io>
Message-ID: <51960B98.3060801@gmail.com>

On 05/17/2013 12:36 PM, Steffen Kram wrote:
> Hi,
> 
> maybe I'm doing it wrong, but I'm not able to pkg update my non-global zones after upgrading the global zone to r151006c. As stated on the release notes page, I shut down my non-global zones, updated the global-zone, went through a reboot, stared the non-global zones again and tried to update them as well:
> 
> # pkg update
>             Packages to update:   5
>        Create boot environment: Yes
> Create backup boot environment:  No
> 
> DOWNLOAD                                  PKGS       FILES    XFER (MB)
> Completed                                  5/5     334/334    14.9/14.9
> 
> pkg: Unable to clone the current boot environment.
> [snip..]
> 

Certain upgrades cannot be performed on non-global zones while they are
booted, especially ones which require creating new BEs. You need to halt
the zone, detach and reattach it with the "-u" option. Have a read
through here: http://omnios.omniti.com/wiki.php/Upgrade_r151004_r151006
(the recommended steps apply to any non-global zone update which
requires a new BE)

Cheers,
-- 
Saso

From esproul at omniti.com  Fri May 17 09:35:56 2013
From: esproul at omniti.com (Eric Sproul)
Date: Fri, 17 May 2013 09:35:56 -0400
Subject: [OmniOS-discuss] Updated release: r151006c
In-Reply-To: <51960B98.3060801@gmail.com>
References: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
	<931A1612-58F3-4AD8-A239-87D3A86BD2E5@kram.io>
	<51960B98.3060801@gmail.com>
Message-ID: <CA+QY2RRFr=d_-tsoexRZ5YiLaryvxqmxPid-TaBK1E1XMziYKA@mail.gmail.com>

On Fri, May 17, 2013 at 6:51 AM, Sa?o Kiselkov <skiselkov.ml at gmail.com> wrote:
> On 05/17/2013 12:36 PM, Steffen Kram wrote:
>> Hi,
>>
>> maybe I'm doing it wrong, but I'm not able to pkg update my non-global zones after upgrading the global zone to r151006c. As stated on the release notes page, I shut down my non-global zones, updated the global-zone, went through a reboot, stared the non-global zones again and tried to update them as well:

Steffen,
I assume the zones were already updated to r151006 or were created
post-upgrade?  Try shutting down the zone and doing the update from
the global, using the -R option to direct the operation into the zone
root, e.g.

pkg -R /zones/myzone/root update

I'll double check the process.  I swear I did the update from within
the zone in my testing, but I could be wrong.

Eric

From esproul at omniti.com  Fri May 17 10:58:25 2013
From: esproul at omniti.com (Eric Sproul)
Date: Fri, 17 May 2013 10:58:25 -0400
Subject: [OmniOS-discuss] some problems with last update to bloody
 omnios-8d266aa 64-bit
In-Reply-To: <kn4ca3$148$1@ger.gmane.org>
References: <kmcuvs$jmu$1@ger.gmane.org>
	<kn4ca3$148$1@ger.gmane.org>
Message-ID: <CA+QY2RQHQH2qXGa-vTUVWOm5t=C7tvKaPEitji6RjBU1fC-nQA@mail.gmail.com>

Richard,
Email me privately and I'll get you set up.

On Fri, May 17, 2013 at 12:39 AM, Richard PALO <richard.palo at baou.fr> wrote:
> Hi, just did an update of bloody, but the problem remains.
> Guess I'd like an account as well in order to file eventual problem reports.
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From sk at kram.io  Fri May 17 12:07:30 2013
From: sk at kram.io (Steffen Kram)
Date: Fri, 17 May 2013 18:07:30 +0200
Subject: [OmniOS-discuss] Updated release: r151006c
In-Reply-To: <CA+QY2RRFr=d_-tsoexRZ5YiLaryvxqmxPid-TaBK1E1XMziYKA@mail.gmail.com>
References: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
	<931A1612-58F3-4AD8-A239-87D3A86BD2E5@kram.io>
	<51960B98.3060801@gmail.com>
	<CA+QY2RRFr=d_-tsoexRZ5YiLaryvxqmxPid-TaBK1E1XMziYKA@mail.gmail.com>
Message-ID: <4B7000FA-633A-4FBF-9964-8729699C905C@kram.io>

Eric,

yes, the zones were already upgraded to r151006. It's the update to 6c that's failing. I just tried to detach and re-attach one of the zones using the "-u" flag, that gives me a "No updates necessary for this image.". So next I'll give the "pkg -R" a try ?

Steffen


Am 17.05.2013 um 15:35 schrieb Eric Sproul <esproul at omniti.com>:

> On Fri, May 17, 2013 at 6:51 AM, Sa?o Kiselkov <skiselkov.ml at gmail.com> wrote:
>> On 05/17/2013 12:36 PM, Steffen Kram wrote:
>>> Hi,
>>> 
>>> maybe I'm doing it wrong, but I'm not able to pkg update my non-global zones after upgrading the global zone to r151006c. As stated on the release notes page, I shut down my non-global zones, updated the global-zone, went through a reboot, stared the non-global zones again and tried to update them as well:
> 
> Steffen,
> I assume the zones were already updated to r151006 or were created
> post-upgrade?  Try shutting down the zone and doing the update from
> the global, using the -R option to direct the operation into the zone
> root, e.g.
> 
> pkg -R /zones/myzone/root update
> 
> I'll double check the process.  I swear I did the update from within
> the zone in my testing, but I could be wrong.
> 
> Eric
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From sk at kram.io  Fri May 17 12:17:51 2013
From: sk at kram.io (Steffen Kram)
Date: Fri, 17 May 2013 18:17:51 +0200
Subject: [OmniOS-discuss] Updated release: r151006c
In-Reply-To: <4B7000FA-633A-4FBF-9964-8729699C905C@kram.io>
References: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
	<931A1612-58F3-4AD8-A239-87D3A86BD2E5@kram.io>
	<51960B98.3060801@gmail.com>
	<CA+QY2RRFr=d_-tsoexRZ5YiLaryvxqmxPid-TaBK1E1XMziYKA@mail.gmail.com>
	<4B7000FA-633A-4FBF-9964-8729699C905C@kram.io>
Message-ID: <D56EA59A-8778-47A9-8118-169D1D8B387C@kram.io>

Ok, just for the record. "pkg -R /zones/[zone]/root update" did the trick. My zones are now all up and running (r151006c).

Thanks!
Steffen


Am 17.05.2013 um 18:07 schrieb Steffen Kram <sk at kram.io>:

> Eric,
> 
> yes, the zones were already upgraded to r151006. It's the update to 6c that's failing. I just tried to detach and re-attach one of the zones using the "-u" flag, that gives me a "No updates necessary for this image.". So next I'll give the "pkg -R" a try ?
> 
> Steffen
> 
> 
> Am 17.05.2013 um 15:35 schrieb Eric Sproul <esproul at omniti.com>:
> 
>> On Fri, May 17, 2013 at 6:51 AM, Sa?o Kiselkov <skiselkov.ml at gmail.com> wrote:
>>> On 05/17/2013 12:36 PM, Steffen Kram wrote:
>>>> Hi,
>>>> 
>>>> maybe I'm doing it wrong, but I'm not able to pkg update my non-global zones after upgrading the global zone to r151006c. As stated on the release notes page, I shut down my non-global zones, updated the global-zone, went through a reboot, stared the non-global zones again and tried to update them as well:
>> 
>> Steffen,
>> I assume the zones were already updated to r151006 or were created
>> post-upgrade?  Try shutting down the zone and doing the update from
>> the global, using the -R option to direct the operation into the zone
>> root, e.g.
>> 
>> pkg -R /zones/myzone/root update
>> 
>> I'll double check the process.  I swear I did the update from within
>> the zone in my testing, but I could be wrong.
>> 
>> Eric
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 


From esproul at omniti.com  Fri May 17 12:22:47 2013
From: esproul at omniti.com (Eric Sproul)
Date: Fri, 17 May 2013 12:22:47 -0400
Subject: [OmniOS-discuss] Updated release: r151006c
In-Reply-To: <D56EA59A-8778-47A9-8118-169D1D8B387C@kram.io>
References: <CA+QY2RT8GFyBtMbnv9OLNFLsqiCn8=gvM=1h11-BDvORSdpXkg@mail.gmail.com>
	<931A1612-58F3-4AD8-A239-87D3A86BD2E5@kram.io>
	<51960B98.3060801@gmail.com>
	<CA+QY2RRFr=d_-tsoexRZ5YiLaryvxqmxPid-TaBK1E1XMziYKA@mail.gmail.com>
	<4B7000FA-633A-4FBF-9964-8729699C905C@kram.io>
	<D56EA59A-8778-47A9-8118-169D1D8B387C@kram.io>
Message-ID: <CA+QY2RQ9vzPBtj9-CAsZmyiFh-QtqyjfrPUM5E6sPDNEmpujFA@mail.gmail.com>

Steffen,
Good, and I apologize for the incorrect instructions.  I've just
updated http://omnios.omniti.com/wiki.php/ReleaseNotes#r151006c with
the working procedure.

Eric

On Fri, May 17, 2013 at 12:17 PM, Steffen Kram <sk at kram.io> wrote:
> Ok, just for the record. "pkg -R /zones/[zone]/root update" did the trick. My zones are now all up and running (r151006c).
>
> Thanks!
> Steffen
>
>
> Am 17.05.2013 um 18:07 schrieb Steffen Kram <sk at kram.io>:
>
>> Eric,
>>
>> yes, the zones were already upgraded to r151006. It's the update to 6c that's failing. I just tried to detach and re-attach one of the zones using the "-u" flag, that gives me a "No updates necessary for this image.". So next I'll give the "pkg -R" a try ?
>>
>> Steffen
>>
>>
>> Am 17.05.2013 um 15:35 schrieb Eric Sproul <esproul at omniti.com>:
>>
>>> On Fri, May 17, 2013 at 6:51 AM, Sa?o Kiselkov <skiselkov.ml at gmail.com> wrote:
>>>> On 05/17/2013 12:36 PM, Steffen Kram wrote:
>>>>> Hi,
>>>>>
>>>>> maybe I'm doing it wrong, but I'm not able to pkg update my non-global zones after upgrading the global zone to r151006c. As stated on the release notes page, I shut down my non-global zones, updated the global-zone, went through a reboot, stared the non-global zones again and tried to update them as well:
>>>
>>> Steffen,
>>> I assume the zones were already updated to r151006 or were created
>>> post-upgrade?  Try shutting down the zone and doing the update from
>>> the global, using the -R option to direct the operation into the zone
>>> root, e.g.
>>>
>>> pkg -R /zones/myzone/root update
>>>
>>> I'll double check the process.  I swear I did the update from within
>>> the zone in my testing, but I could be wrong.
>>>
>>> Eric
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>

From hakansom at ohsu.edu  Fri May 17 13:10:18 2013
From: hakansom at ohsu.edu (Marion Hakanson)
Date: Fri, 17 May 2013 10:10:18 -0700
Subject: [OmniOS-discuss] X11 application support
Message-ID: <201305171710.r4HHAIxk014234@kyklops.ohsu.edu>

Greetings,

We often use X11 tunnelling over SSH connections in order to run various
X11 applications on remote servers.  An example might be to run a web
browser on such a server in order to access the management functions
of an appliance in the datacenter, or maybe a vendor-supplied Java GUI
app to manage a component, perhaps a RAID HBA.  Yes, we generally can
find a command-line tool for accomplishing most of these tasks, but
it's not always feasible.

I've been looking at OmniOS for a role in our datacenter environment, and
it looks to me like out of the box, OmniOS cannot host such applications.
I didn't find any X client shared libraries in the IPS repo, for example.

Before I head off to solve this problem on my own, I thought I'd ask:
Is anyone already using OmniOS to run X11 apps in this manner (displaying
to a remote X server), and if so, how do you accomplish it?

Thanks and regards,

Marion



From oesterwind at web4work.de  Fri May 17 13:16:19 2013
From: oesterwind at web4work.de (oesterwind at web4work.de)
Date: Fri, 17 May 2013 19:16:19 +0200
Subject: [OmniOS-discuss] problem installing gnu-binutils
Message-ID: <519665E3.3090205@web4work.de>

I have problems installing gnu-binutils. It starteted about 1 week ago 
while trying to install gcc and its dependencies. Other packages are o.k.
While doing a "pkg install gnu-binutils" I allways get the following 
messages at about 70% of the download ...


pkg install gnu-binutils
            Packages to install:  1
        Create boot environment: No
Create backup boot environment: No

DOWNLOAD                                  PKGS       FILES    XFER (MB)
developer/gnu-binutils                     0/1      95/247 2.9/9.1

Errors were encountered while attempting to retrieve package or file 
data for
the requested operation.
Details follow:

1: Framework error: code: 28 reason: Operation too slow. Less than 1024 
bytes/sec transferred the last 30 seconds
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/0d0cf902c11200d75626974a63ff54e6202aa64f'.
2: Framework error: code: 18 reason: transfer closed with 109055 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/9410ce2a428fb680b5c73b2713876c8cdb30ff17'.
3: Framework error: code: 18 reason: transfer closed with 86284 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/95658b2b202f5402822ba18b8dcfe9edc551deb0'.
4: Framework error: code: 18 reason: transfer closed with 232168 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/8277a7d57c35c8f0ced166ae5b5e2e79e188d3d4'.
5: Framework error: code: 18 reason: transfer closed with 98539 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/9410ce2a428fb680b5c73b2713876c8cdb30ff17'.
6: Framework error: code: 18 reason: transfer closed with 80928 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/95658b2b202f5402822ba18b8dcfe9edc551deb0'.
7: Framework error: code: 18 reason: transfer closed with 96415 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/3d0edafd1e5adc73dd34f8b156a92e4d68a83531'.
8: Framework error: code: 18 reason: transfer closed with 67960 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/95658b2b202f5402822ba18b8dcfe9edc551deb0'.
9: Framework error: code: 18 reason: transfer closed with 87223 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/9410ce2a428fb680b5c73b2713876c8cdb30ff17'.
10: Framework error: code: 18 reason: transfer closed with 94955 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/3d0edafd1e5adc73dd34f8b156a92e4d68a83531'.
11: Framework error: code: 18 reason: transfer closed with 234760 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/8277a7d57c35c8f0ced166ae5b5e2e79e188d3d4'.
12: Framework error: code: 18 reason: transfer closed with 213133 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/0d0cf902c11200d75626974a63ff54e6202aa64f'.
13: Framework error: code: 18 reason: transfer closed with 252553 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/0d0cf902c11200d75626974a63ff54e6202aa64f'.
14: Framework error: code: 18 reason: transfer closed with 84232 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/95658b2b202f5402822ba18b8dcfe9edc551deb0'.
15: Framework error: code: 18 reason: transfer closed with 92035 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/3d0edafd1e5adc73dd34f8b156a92e4d68a83531'.
16: Framework error: code: 18 reason: transfer closed with 230380 bytes 
remaining to read
URL: 
'http://pkg.omniti.com/omnios/release/omnios/file/1/8277a7d57c35c8f0ced166ae5b5e2e79e188d3d4'.

Is it a problem with the package, or I'm doing something wrong?
  Its the first time I'm using this interesting distribution to get used 
to zfs ...

Otto






From jesus at omniti.com  Fri May 17 13:21:34 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Fri, 17 May 2013 13:21:34 -0400
Subject: [OmniOS-discuss] X11 application support
In-Reply-To: <201305171710.r4HHAIxk014234@kyklops.ohsu.edu>
References: <201305171710.r4HHAIxk014234@kyklops.ohsu.edu>
Message-ID: <CACLsApuqk5SwH_gG1s0ce8yVY5qe9FUxf=TpN9kqRKh2dDDm0A@mail.gmail.com>

A few things that might help you our

1) this is not in core by design.
2) using a browser remotely sounds painful... try ssh options to either
forward a port (-L) or act as a SOCKS proxy (-D) both *super* useful.
3) this does not solve your "I can only manage an HBA with a Java GUI
issue"... you should burn that vendor's offices down*.
4) There are people using Joyent's pkgsrc work to build X libs.

* please don't actually burn anything down, just vote with your budget and
buy products that don't suffer this way

What I'd really love to see is someone start a desktop IPS repo on top of
OmniOS.  Build X11 stuff and publish it there.  Once that happens, the
whole community can benefit.  Another awesome option that would likely be
much more fruitful would be to hack pkgsrc to publish IPS artifacts.  That
said, I have no desire to build or maintain anything related to X11, so it
shan't be me that does it.

Best regards,

Theo



On Fri, May 17, 2013 at 1:10 PM, Marion Hakanson <hakansom at ohsu.edu> wrote:

> Greetings,
>
> We often use X11 tunnelling over SSH connections in order to run various
> X11 applications on remote servers.  An example might be to run a web
> browser on such a server in order to access the management functions
> of an appliance in the datacenter, or maybe a vendor-supplied Java GUI
> app to manage a component, perhaps a RAID HBA.  Yes, we generally can
> find a command-line tool for accomplishing most of these tasks, but
> it's not always feasible.
>
> I've been looking at OmniOS for a role in our datacenter environment, and
> it looks to me like out of the box, OmniOS cannot host such applications.
> I didn't find any X client shared libraries in the IPS repo, for example.
>
> Before I head off to solve this problem on my own, I thought I'd ask:
> Is anyone already using OmniOS to run X11 apps in this manner (displaying
> to a remote X server), and if so, how do you accomplish it?
>
> Thanks and regards,
>
> Marion
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130517/8c52eea8/attachment.html>

From bfriesen at simple.dallas.tx.us  Fri May 17 13:34:22 2013
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 17 May 2013 12:34:22 -0500 (CDT)
Subject: [OmniOS-discuss] X11 application support
In-Reply-To: <CACLsApuqk5SwH_gG1s0ce8yVY5qe9FUxf=TpN9kqRKh2dDDm0A@mail.gmail.com>
References: <201305171710.r4HHAIxk014234@kyklops.ohsu.edu>
	<CACLsApuqk5SwH_gG1s0ce8yVY5qe9FUxf=TpN9kqRKh2dDDm0A@mail.gmail.com>
Message-ID: <alpine.GSO.2.01.1305171225110.18974@freddy.simplesystems.org>

On Fri, 17 May 2013, Theo Schlossnagle wrote:

> A few things that might help you our
> 1) this is not in core by design.
> 2) using a browser remotely sounds painful... try ssh options to either forward a port (-L) or act as a SOCKS proxy (-D) both
> *super* useful.
> 3) this does not solve your "I can only manage an HBA with a Java GUI issue"... you should burn that vendor's offices down*.

I have some mission-critical software here from Sun which uses an 
"Install Shield" type installer on Solaris.  I am not sure if the 
installer is x86/SPARC binaries, or based on Java.  Once installed, 
the software runs headless on a server.

There is other software (useful on servers) where use of X11 is 
optional at run-time yet the binaries will fail to run if the X11 
libraries are missing.  If the X11 libraries are missing, then it is 
necessary to create a special build of the software and 
commonly-available pre-compiled binaries won't work.

Basic X11 client libraries and support files (all highly-portable 
stuff) seems like a basic requirement.  This is quite different than 
an X11 server, which has substantial hardware dependencies.

> 4) There are people using Joyent's pkgsrc work to build X libs.

That sounds helpful.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From jesus at omniti.com  Fri May 17 13:51:32 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Fri, 17 May 2013 13:51:32 -0400
Subject: [OmniOS-discuss] X11 application support
In-Reply-To: <alpine.GSO.2.01.1305171225110.18974@freddy.simplesystems.org>
References: <201305171710.r4HHAIxk014234@kyklops.ohsu.edu>
	<CACLsApuqk5SwH_gG1s0ce8yVY5qe9FUxf=TpN9kqRKh2dDDm0A@mail.gmail.com>
	<alpine.GSO.2.01.1305171225110.18974@freddy.simplesystems.org>
Message-ID: <CACLsApvsdZjzKH1PRPboCyyLMQMaU+g5DqbcDHFJhn4FDx+Djw@mail.gmail.com>

We don't package X11 libs in code, because nothing in core needs them to
run or build.  The core is the smallest self sustainable set of packages.

We encourage the "layered-cake" approach using multiple repos.

We take that stance because the problem is deeper and more complex than you
elude to.

Your vendor ships something that needs X11 libs.  But they don't ship
OmniOS binaries (if they didn't they'd have no X11 deps). So, what you have
instead are likely Solaris binaries.  Now, while Solaris 10 and earlier
binaries will run on OmniOS, we only guarantee that the system ABIs are
stable. X11 is not that.  So, in order to run those Solaris 10 binaries
that need X11 client libs we have a possible ABI issue.  If we were to ship
X11 client libs, we may not ship the same ones as with Solaris 10 (we are
newer after all), so that binary might explode if you convince it to link
against the ones we would have provided.  The only way to make sure it
works is to copy over the libs from a Solaris 10 box and LD_LIBRARY_PATH
them for your app.  This has the highest probability of working.

I can share our approach to such things, it may or may not help.  I have a
private IPS repo for my junk.  Without own private IPS repo, I concern
myself less with the redistribution rights of what I place in there.  We
take an IPS-or-nothing approach.  If I find myself with a piece of software
that doesn't have an IPS (tar, installer, etc. etc.).  I take a machine and
install it, I find all files it provided and create an IPS manifest, I SMF
it if it hasn't been and put that int he manifest. I run it, if it doesn't
work due to missing libraries, I create a private directory somewhere
reasonable and relative to the install path and place the missing shared
libraries in there.  I add that to the LD_LIBRARY_PATH in the SMF manifest
and add the libs to the package manifest.... once it works, I pkgsend the
manifest to my server and voila.  I know how said piece of software
installable via IPS in non-snowflake fashion.

I would say, this process is required once in a blue moon.

While I'm sure we all find the need to hack up a piece of software to run
on a foreign OS, I'll caveat that hacking a piece of mission critical
software to run on OmniOS that isn't shipped for OmniOS is likely easier
than hacking your EULA to allow you to do so or hacking your support
contract for said software to be valid or useful.

Best regards,

Theo

On Fri, May 17, 2013 at 1:34 PM, Bob Friesenhahn <
bfriesen at simple.dallas.tx.us> wrote:

> On Fri, 17 May 2013, Theo Schlossnagle wrote:
>
>  A few things that might help you our
>> 1) this is not in core by design.
>> 2) using a browser remotely sounds painful... try ssh options to either
>> forward a port (-L) or act as a SOCKS proxy (-D) both
>> *super* useful.
>> 3) this does not solve your "I can only manage an HBA with a Java GUI
>> issue"... you should burn that vendor's offices down*.
>>
>
> I have some mission-critical software here from Sun which uses an "Install
> Shield" type installer on Solaris.  I am not sure if the installer is
> x86/SPARC binaries, or based on Java.  Once installed, the software runs
> headless on a server.
>
> There is other software (useful on servers) where use of X11 is optional
> at run-time yet the binaries will fail to run if the X11 libraries are
> missing.  If the X11 libraries are missing, then it is necessary to create
> a special build of the software and commonly-available pre-compiled
> binaries won't work.
>
> Basic X11 client libraries and support files (all highly-portable stuff)
> seems like a basic requirement.  This is quite different than an X11
> server, which has substantial hardware dependencies.
>
>
>  4) There are people using Joyent's pkgsrc work to build X libs.
>>
>
> That sounds helpful.
>
> Bob
> --
> Bob Friesenhahn
> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/**
> users/bfriesen/ <http://www.simplesystems.org/users/bfriesen/>
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>



-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130517/5b2d1ed2/attachment.html>

From hakansom at ohsu.edu  Fri May 17 16:55:00 2013
From: hakansom at ohsu.edu (Marion Hakanson)
Date: Fri, 17 May 2013 13:55:00 -0700
Subject: [OmniOS-discuss] X11 application support
In-Reply-To: Message from Theo Schlossnagle <jesus@omniti.com> of "Fri,
	17 May 2013 10:21:34 PDT."
	<CACLsApuqk5SwH_gG1s0ce8yVY5qe9FUxf=TpN9kqRKh2dDDm0A@mail.gmail.com>
Message-ID: <201305172055.r4HKt0NR014659@kyklops.ohsu.edu>

Hi Theo,

Thanks for your comments, I found them helpful.  Thanks also for
making OmniOS available to the rest of us.


jesus at omniti.com said:
> A few things that might help you our
> 
> 1) this is not in core by design.

No complaints here.


> 2) using a browser remotely sounds painful... try ssh options to either
> forward a port (-L) or act as a SOCKS proxy (-D) both *super* useful.

Perhaps painful is in the eye of the beholder.  Using "ssh -X" or "ssh -Y"
and running firefox on the remote server "just works".  Maybe I'm missing
something, but "ssh -L" for connecting to a Dell server's DRAC-Enterprise
or other embedded webserver takes a fair amount of trial and error to suss
out what ports, URL's, and/or hostnames their developers require in order
to work.  E.g. the DRAC-Enterprise, or SuperMicro BMC's often have some
kind of remote KVM java app built into them, and those have their own
obscure assumptions about connectivity, too.


> 3) this does not solve your "I can only manage an HBA with a Java GUI
> issue"... you should burn that vendor's offices down*.
> . . .
> * please don't actually burn anything down, just vote with your budget and
> buy products that don't suffer this way

Been there, done that, have a collection of T-shirts from companies
that have gone out of business as a result (:-).  Still have some of
their products in use, though, and plenty of stuff that I had no say
about purchasing.


> 4) There are people using Joyent's pkgsrc work to build X libs.

This is one avenue I'm working on.  A fall-back is using OpenIndiana
for this type of light remote/virtual desktop stuff.  Or maybe a Mac,
or a Linux box, etc.  Shame to need a whole box for it, though.


> What I'd really love to see is someone start a desktop IPS repo on top of
> OmniOS. ?Build X11 stuff and publish it there. ?Once that happens, the whole
> community can benefit. ?Another awesome option that would likely be much more
> fruitful would be to hack pkgsrc to publish IPS artifacts. ?That said, I have
> no desire to build or maintain anything related to X11, so it shan't be me
> that does it. 

Me too (for all of the above paragraph)!


> I can share our approach to such things, it may or may not help. ?I have a
> private IPS repo for my junk. ?Without own private IPS repo, I concern myself
> less with the redistribution rights of what I place in there. ?We take an
> IPS-or-nothing approach. ?If I find myself with a piece of software that
> doesn't have an IPS (tar, installer, etc. etc.). ?I take a machine and
> install it, I find all files it provided and create an IPS manifest, I SMF it
> if it hasn't been and put that int he manifest. I run it, if it doesn't work
> due to missing libraries, I create a private directory somewhere reasonable
> and relative to the install path and place the missing shared libraries in
> there. ?I add that to the LD_LIBRARY_PATH in the SMF manifest and add the
> libs to the package manifest.... once it works, I pkgsend the manifest to my
> server and voila. ?I know how said piece of software installable via IPS in
> non-snowflake fashion. 

Good to know.

I've taken this approach in the past -- been doing this long enough to have
used three or four different automatic build/package/install frameworks.
It's turned out to not be sustainable given the resources our organization
has had available in recent years.  Not that that stops me from trying....

Again, thanks to everyone for their comments.

Regards,

Marion



From jesus at omniti.com  Fri May 17 17:07:17 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Fri, 17 May 2013 17:07:17 -0400
Subject: [OmniOS-discuss] X11 application support
In-Reply-To: <201305172055.r4HKt0NR014659@kyklops.ohsu.edu>
References: <jesus@omniti.com>
	<CACLsApuqk5SwH_gG1s0ce8yVY5qe9FUxf=TpN9kqRKh2dDDm0A@mail.gmail.com>
	<201305172055.r4HKt0NR014659@kyklops.ohsu.edu>
Message-ID: <CACLsApvHP-=nON_PhyUTEOyEKW8Xy51w5ppTrFZ-dj9h-xdcbQ@mail.gmail.com>

On Fri, May 17, 2013 at 4:55 PM, Marion Hakanson <hakansom at ohsu.edu> wrote:

>
> jesus at omniti.com said:
> > 2) using a browser remotely sounds painful... try ssh options to either
> > forward a port (-L) or act as a SOCKS proxy (-D) both *super* useful.
>
> Perhaps painful is in the eye of the beholder.  Using "ssh -X" or "ssh -Y"
> and running firefox on the remote server "just works".  Maybe I'm missing
> something, but "ssh -L" for connecting to a Dell server's DRAC-Enterprise
> or other embedded webserver takes a fair amount of trial and error to suss
> out what ports, URL's, and/or hostnames their developers require in order
> to work.  E.g. the DRAC-Enterprise, or SuperMicro BMC's often have some
> kind of remote KVM java app built into them, and those have their own
> obscure assumptions about connectivity, too.


You should look at -D

Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
as a SOCKS server.

Makes ssh super for desktop apps (more than just browsers) to act as if
they are in the DC.

-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130517/d9bc5403/attachment.html>

From richard.palo at baou.fr  Sat May 18 05:22:44 2013
From: richard.palo at baou.fr (Richard PALO)
Date: Sat, 18 May 2013 11:22:44 +0200
Subject: [OmniOS-discuss] some problems with last update to bloody
	omnios-8d266aa 64-bit
In-Reply-To: <CA+QY2RQHQH2qXGa-vTUVWOm5t=C7tvKaPEitji6RjBU1fC-nQA@mail.gmail.com>
References: <kmcuvs$jmu$1@ger.gmane.org> <kn4ca3$148$1@ger.gmane.org>
	<CA+QY2RQHQH2qXGa-vTUVWOm5t=C7tvKaPEitji6RjBU1fC-nQA@mail.gmail.com>
Message-ID: <kn7h8v$pmv$1@ger.gmane.org>

In the meanwhile, pkg seems to be fouled now...

> root at omni1:~# pkg update -v
> Creating Plan |
> pkg update: No solution was found to satisfy constraints
> Plan Creation: Package solver has not found a solution to update to latest available versions.
> This may indicate an overly constrained set of packages are installed.
>
> latest incorporations:
>
>   pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130514T014154Z
>
> The following indicates why the system cannot update to the latest version:
>
>   No suitable version of required package pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130514T014154Z found:
>     Reject:  pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130514T014154Z
>     Reason:  All versions matching 'incorporate' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151007 are rejected
>       Reject:  pkg://omnios/SUNWcs at 0.5.11,5.11-0.151007:20130514T014157Z
>       Reason:  All versions matching 'require' dependency pkg:/service/fault-management at 0.5.11,5.11-0.151007 are rejected
>         Reject:  pkg://omnios/service/fault-management at 0.5.11,5.11-0.151007:20130514T014227Z
>         Reason:  All versions matching 'require' dependency pkg:/system/library at 0.5.11,5.11-0.151007 are rejected
>           Reject:  pkg://omnios/system/library at 0.5.11,5.11-0.151007:20130514T014236Z
>           Reason:  A version for 'require' dependency on pkg:/library/security/openssl at 1.0.1.5,5.11-0.151006 cannot be found
>




From jesus at omniti.com  Sat May 18 09:22:16 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Sat, 18 May 2013 09:22:16 -0400
Subject: [OmniOS-discuss] some problems with last update to bloody
 omnios-8d266aa 64-bit
In-Reply-To: <kn7h8v$pmv$1@ger.gmane.org>
References: <kmcuvs$jmu$1@ger.gmane.org> <kn4ca3$148$1@ger.gmane.org>
	<CA+QY2RQHQH2qXGa-vTUVWOm5t=C7tvKaPEitji6RjBU1fC-nQA@mail.gmail.com>
	<kn7h8v$pmv$1@ger.gmane.org>
Message-ID: <CACLsApuiXqmPn+U9n+Ndpg_+9_DdVs3bz-zVfzhL6ELPN-tF-Q@mail.gmail.com>

You're on bloody?  Yeah stuffs all fouled as a part of being bloody ;-)
 I've got a relatively enormous package publish pending.

Bloody 151005 is EOL and bloody 151007 is in the process of being built...
so until it's all published, things'll be a mess.

I'll see if I can bump openssl for you, but I'm going to guess that will
simply reveal the next issue.


On Sat, May 18, 2013 at 5:22 AM, Richard PALO <richard.palo at baou.fr> wrote:

> In the meanwhile, pkg seems to be fouled now...
>
>  root at omni1:~# pkg update -v
>> Creating Plan |
>> pkg update: No solution was found to satisfy constraints
>> Plan Creation: Package solver has not found a solution to update to
>> latest available versions.
>> This may indicate an overly constrained set of packages are installed.
>>
>> latest incorporations:
>>
>>   pkg://omnios/consolidation/**osnet/osnet-incorporation at 0.5.**
>> 11,5.11-0.151007:**20130514T014154Z
>>
>> The following indicates why the system cannot update to the latest
>> version:
>>
>>   No suitable version of required package pkg://omnios/consolidation/**
>> osnet/osnet-incorporation at 0.5.**11,5.11-0.151007:**20130514T014154Z
>> found:
>>     Reject:  pkg://omnios/consolidation/**osnet/osnet-incorporation at 0.5.*
>> *11,5.11-0.151007:**20130514T014154Z
>>     Reason:  All versions matching 'incorporate' dependency
>> pkg:/SUNWcs at 0.5.11,5.11-0.**151007 are rejected
>>       Reject:  pkg://omnios/SUNWcs at 0.5.11,5.**
>> 11-0.151007:20130514T014157Z
>>       Reason:  All versions matching 'require' dependency
>> pkg:/service/fault-management@**0.5.11,5.11-0.151007 are rejected
>>         Reject:  pkg://omnios/service/fault-**management at 0.5.11,5.11-0.**
>> 151007:20130514T014227Z
>>         Reason:  All versions matching 'require' dependency
>> pkg:/system/library at 0.5.11,5.**11-0.151007 are rejected
>>           Reject:  pkg://omnios/system/library at 0.**5.11,5.11-0.151007:**
>> 20130514T014236Z
>>           Reason:  A version for 'require' dependency on
>> pkg:/library/security/openssl@**1.0.1.5 <openssl at 1.0.1.5>,5.11-0.151006
>> cannot be found
>>
>>
>
>
> ______________________________**_________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.**com <OmniOS-discuss at lists.omniti.com>
> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss<http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>



-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130518/f52a0efe/attachment-0001.html>

From richard.palo at baou.fr  Sat May 18 09:40:05 2013
From: richard.palo at baou.fr (Richard PALO)
Date: Sat, 18 May 2013 15:40:05 +0200
Subject: [OmniOS-discuss] some problems with last update to bloody
	omnios-8d266aa 64-bit
In-Reply-To: <CACLsApuiXqmPn+U9n+Ndpg_+9_DdVs3bz-zVfzhL6ELPN-tF-Q@mail.gmail.com>
References: <kmcuvs$jmu$1@ger.gmane.org> <kn4ca3$148$1@ger.gmane.org>
	<CA+QY2RQHQH2qXGa-vTUVWOm5t=C7tvKaPEitji6RjBU1fC-nQA@mail.gmail.com>
	<kn7h8v$pmv$1@ger.gmane.org>
	<CACLsApuiXqmPn+U9n+Ndpg_+9_DdVs3bz-zVfzhL6ELPN-tF-Q@mail.gmail.com>
Message-ID: <kn80bg$tmu$1@ger.gmane.org>

Perhaps I can brute force to the latest stable (using pkg incantations 
and not reinstalling, that is)?  Might you have a reasonable procedure?


From richard.palo at baou.fr  Sun May 19 04:40:09 2013
From: richard.palo at baou.fr (Richard PALO)
Date: Sun, 19 May 2013 10:40:09 +0200
Subject: [OmniOS-discuss] some problems with last update to bloody
	omnios-8d266aa 64-bit
In-Reply-To: <kn80bg$tmu$1@ger.gmane.org>
References: <kmcuvs$jmu$1@ger.gmane.org> <kn4ca3$148$1@ger.gmane.org>
	<CA+QY2RQHQH2qXGa-vTUVWOm5t=C7tvKaPEitji6RjBU1fC-nQA@mail.gmail.com>
	<kn7h8v$pmv$1@ger.gmane.org>
	<CACLsApuiXqmPn+U9n+Ndpg_+9_DdVs3bz-zVfzhL6ELPN-tF-Q@mail.gmail.com>
	<kn80bg$tmu$1@ger.gmane.org>
Message-ID: <kna355$2j0$1@ger.gmane.org>

Le 18/05/13 15:40, Richard PALO a ?crit :
> Perhaps I can brute force to the latest stable (using pkg incantations
> and not reinstalling, that is)?  Might you have a reasonable procedure?
>
Well, the last update didn't help either...
But after a bit of a look, I believe that there was an omission during 
the perl 5.6.3 update concerning kstats.
> Can't locate loadable object for module Sun::Solaris::Kstat in @INC (@INC contains: /usr/perl5/site_perl/5.16/i86pc-solaris-thread-multi-64int /usr/perl5/site_perl/5.16 /usr/perl5/vendor_perl/5.16/i86pc-solaris-thread-multi-64int /usr/perl5/vendor_perl/5.16 /usr/perl5/lib/i86pc-solaris-thread-multi-64int /usr/perl5/lib .) at /usr/lib/intrd line 66.
> Compilation failed in require at /usr/lib/intrd line 66.

> root at omni1:~# find /usr/perl5/ -name Kstat*
> /usr/perl5/site_perl/5.16/i86pc-solaris-thread-multi-64int/Sun/Solaris/Kstat.pm
> /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int/auto/Sun/Solaris/Kstat
> /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int/auto/Sun/Solaris/Kstat/Kstat.bs
> /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int/auto/Sun/Solaris/Kstat/Kstat.so
> /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int/Sun/Solaris/Kstat.pm
> /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64/Sun/Solaris/Kstat.pm
> /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64/auto/Sun/Solaris/Kstat
> /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64/auto/Sun/Solaris/Kstat/Kstat.so
> /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64/auto/Sun/Solaris/Kstat/Kstat.bs

doing the following seems to help for the time being:

> root at omni1:~# cd /usr/perl5/site_perl/5.16/i86pc-solaris-thread-multi-64int/
> root at omni1:/usr/perl5/site_perl/5.16/i86pc-solaris-thread-multi-64int# cp -R ../../../5.16.1/lib/i86pc-solaris-thread-multi-64int/* .
> root at omni1:/usr/perl5/site_perl/5.16/i86pc-solaris-thread-multi-64int# cd
> root at omni1:~# svcadm clear svc:/system/intrd:default
> root at omni1:~# svcs  svc:/system/intrd:default
> STATE          STIME    FMRI
> online         10:30:35 svc:/system/intrd:default



From jesus at omniti.com  Sun May 19 10:29:18 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Sun, 19 May 2013 10:29:18 -0400
Subject: [OmniOS-discuss] some problems with last update to bloody
 omnios-8d266aa 64-bit
In-Reply-To: <kna355$2j0$1@ger.gmane.org>
References: <kmcuvs$jmu$1@ger.gmane.org> <kn4ca3$148$1@ger.gmane.org>
	<CA+QY2RQHQH2qXGa-vTUVWOm5t=C7tvKaPEitji6RjBU1fC-nQA@mail.gmail.com>
	<kn7h8v$pmv$1@ger.gmane.org>
	<CACLsApuiXqmPn+U9n+Ndpg_+9_DdVs3bz-zVfzhL6ELPN-tF-Q@mail.gmail.com>
	<kn80bg$tmu$1@ger.gmane.org> <kna355$2j0$1@ger.gmane.org>
Message-ID: <CACLsAps+R84Vi+QLwXbx-ODhLYw01nVqypFy1onyfYafh=BHaA@mail.gmail.com>

5.16.3?  I've only got 5.16.1 here.  OmniOS and bloody public repos both
show 5.16.1.

Can you provide details on your 5.16.3 package?


On Sun, May 19, 2013 at 4:40 AM, Richard PALO <richard.palo at baou.fr> wrote:

> Le 18/05/13 15:40, Richard PALO a ?crit :
>
>  Perhaps I can brute force to the latest stable (using pkg incantations
>> and not reinstalling, that is)?  Might you have a reasonable procedure?
>>
>>  Well, the last update didn't help either...
> But after a bit of a look, I believe that there was an omission during the
> perl 5.6.3 update concerning kstats.
>
>> Can't locate loadable object for module Sun::Solaris::Kstat in @INC (@INC
>> contains: /usr/perl5/site_perl/5.16/**i86pc-solaris-thread-multi-**64int
>> /usr/perl5/site_perl/5.16 /usr/perl5/vendor_perl/5.16/**
>> i86pc-solaris-thread-multi-**64int /usr/perl5/vendor_perl/5.16
>> /usr/perl5/lib/i86pc-solaris-**thread-multi-64int /usr/perl5/lib .) at
>> /usr/lib/intrd line 66.
>> Compilation failed in require at /usr/lib/intrd line 66.
>>
>
>  root at omni1:~# find /usr/perl5/ -name Kstat*
>> /usr/perl5/site_perl/5.16/**i86pc-solaris-thread-multi-**
>> 64int/Sun/Solaris/Kstat.pm
>> /usr/perl5/5.16.1/lib/i86pc-**solaris-thread-multi-64int/**
>> auto/Sun/Solaris/Kstat
>> /usr/perl5/5.16.1/lib/i86pc-**solaris-thread-multi-64int/**
>> auto/Sun/Solaris/Kstat/Kstat.**bs
>> /usr/perl5/5.16.1/lib/i86pc-**solaris-thread-multi-64int/**
>> auto/Sun/Solaris/Kstat/Kstat.**so
>> /usr/perl5/5.16.1/lib/i86pc-**solaris-thread-multi-64int/**
>> Sun/Solaris/Kstat.pm
>> /usr/perl5/5.16.1/lib/i86pc-**solaris-thread-multi-64/Sun/**
>> Solaris/Kstat.pm
>> /usr/perl5/5.16.1/lib/i86pc-**solaris-thread-multi-64/auto/**
>> Sun/Solaris/Kstat
>> /usr/perl5/5.16.1/lib/i86pc-**solaris-thread-multi-64/auto/**
>> Sun/Solaris/Kstat/Kstat.so
>> /usr/perl5/5.16.1/lib/i86pc-**solaris-thread-multi-64/auto/**
>> Sun/Solaris/Kstat/Kstat.bs
>>
>
> doing the following seems to help for the time being:
>
>  root at omni1:~# cd /usr/perl5/site_perl/5.16/**i86pc-solaris-thread-multi-*
>> *64int/
>> root at omni1:/usr/perl5/site_**perl/5.16/i86pc-solaris-**thread-multi-64int#
>> cp -R ../../../5.16.1/lib/i86pc-**solaris-thread-multi-64int/* .
>> root at omni1:/usr/perl5/site_**perl/5.16/i86pc-solaris-**thread-multi-64int#
>> cd
>> root at omni1:~# svcadm clear svc:/system/intrd:default
>> root at omni1:~# svcs  svc:/system/intrd:default
>> STATE          STIME    FMRI
>> online         10:30:35 svc:/system/intrd:default
>>
>
>
> ______________________________**_________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.**com <OmniOS-discuss at lists.omniti.com>
> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss<http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>



-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130519/01f53b76/attachment.html>

From richard.palo at baou.fr  Sun May 19 11:13:31 2013
From: richard.palo at baou.fr (Richard PALO)
Date: Sun, 19 May 2013 17:13:31 +0200
Subject: [OmniOS-discuss] some problems with last update to bloody
	omnios-8d266aa 64-bit
In-Reply-To: <CACLsAps+R84Vi+QLwXbx-ODhLYw01nVqypFy1onyfYafh=BHaA@mail.gmail.com>
References: <kmcuvs$jmu$1@ger.gmane.org> <kn4ca3$148$1@ger.gmane.org>
	<CA+QY2RQHQH2qXGa-vTUVWOm5t=C7tvKaPEitji6RjBU1fC-nQA@mail.gmail.com>
	<kn7h8v$pmv$1@ger.gmane.org>
	<CACLsApuiXqmPn+U9n+Ndpg_+9_DdVs3bz-zVfzhL6ELPN-tF-Q@mail.gmail.com>
	<kn80bg$tmu$1@ger.gmane.org> <kna355$2j0$1@ger.gmane.org>
	<CACLsAps+R84Vi+QLwXbx-ODhLYw01nVqypFy1onyfYafh=BHaA@mail.gmail.com>
Message-ID: <knaq6m$eh5$1@ger.gmane.org>

Le 19/05/13 16:29, Theo Schlossnagle a ?crit :
> 5.16.3?  I've only got 5.16.1 here.  OmniOS and bloody public repos both
> show 5.16.1.
>
> Can you provide details on your 5.16.3 package?
>

wow, maybe I should be worried...

> root at omni1:~# perl -v
>
> This is perl 5, version 16, subversion 3 (v5.16.3) built for i86pc-solaris-thread-multi-64int
>
> Copyright 1987-2012, Larry Wall
>
> Perl may be copied only under the terms of either the Artistic License or the
> GNU General Public License, which may be found in the Perl 5 source kit.
>
> Complete documentation for Perl, including FAQ lists, should be found on
> this system using "man perl" or "perldoc perl".  If you have access to the
> Internet, point your browser at http://www.perl.org/, the Perl Home Page.
>
> root at omni1:~# pkg list -v perl
> FMRI                                                                         IFO
> pkg://omnios/runtime/perl at 5.16.3,5.11-0.151005:20130418T215804Z              i--



From jesus at omniti.com  Sun May 19 11:40:40 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Sun, 19 May 2013 11:40:40 -0400
Subject: [OmniOS-discuss] some problems with last update to bloody
 omnios-8d266aa 64-bit
In-Reply-To: <knaq6m$eh5$1@ger.gmane.org>
References: <kmcuvs$jmu$1@ger.gmane.org> <kn4ca3$148$1@ger.gmane.org>
	<CA+QY2RQHQH2qXGa-vTUVWOm5t=C7tvKaPEitji6RjBU1fC-nQA@mail.gmail.com>
	<kn7h8v$pmv$1@ger.gmane.org>
	<CACLsApuiXqmPn+U9n+Ndpg_+9_DdVs3bz-zVfzhL6ELPN-tF-Q@mail.gmail.com>
	<kn80bg$tmu$1@ger.gmane.org> <kna355$2j0$1@ger.gmane.org>
	<CACLsAps+R84Vi+QLwXbx-ODhLYw01nVqypFy1onyfYafh=BHaA@mail.gmail.com>
	<knaq6m$eh5$1@ger.gmane.org>
Message-ID: <CACLsApvXm1aYx1GxEduML4mRB2oDhAQzgFyZpSH1tgB1_jM5mA@mail.gmail.com>

I think eric might have played with 5.16.3 in bloody and then removed it.
 It is bloody after all.  Force install 5.16.1 and you'll be a happier
person.

We do intend to move the perl version forward, but there's stuff in gate
that has to happen first and we want to parameterize it instead of hacking
it for a 3rd time.


On Sun, May 19, 2013 at 11:13 AM, Richard PALO <richard.palo at baou.fr> wrote:

> Le 19/05/13 16:29, Theo Schlossnagle a ?crit :
>
>  5.16.3?  I've only got 5.16.1 here.  OmniOS and bloody public repos both
>> show 5.16.1.
>>
>> Can you provide details on your 5.16.3 package?
>>
>>
> wow, maybe I should be worried...
>
>  root at omni1:~# perl -v
>>
>> This is perl 5, version 16, subversion 3 (v5.16.3) built for
>> i86pc-solaris-thread-multi-**64int
>>
>> Copyright 1987-2012, Larry Wall
>>
>> Perl may be copied only under the terms of either the Artistic License or
>> the
>> GNU General Public License, which may be found in the Perl 5 source kit.
>>
>> Complete documentation for Perl, including FAQ lists, should be found on
>> this system using "man perl" or "perldoc perl".  If you have access to the
>> Internet, point your browser at http://www.perl.org/, the Perl Home Page.
>>
>> root at omni1:~# pkg list -v perl
>> FMRI
>>     IFO
>> pkg://omnios/runtime/perl at 5.**16.3,5.11-0.151005:**20130418T215804Z
>>          i--
>>
>
>
> ______________________________**_________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.**com <OmniOS-discuss at lists.omniti.com>
> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss<http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>



-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130519/8c73419f/attachment.html>

From ales.jagric at forum-racunalnistva.eu  Thu May 23 11:10:05 2013
From: ales.jagric at forum-racunalnistva.eu (=?iso-8859-2?Q?Ale=B9_Jagri=E8=2C_Fora_d=2Eo=2Eo=2E?=)
Date: Thu, 23 May 2013 17:10:05 +0200
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
Message-ID: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>

Hey,

We're testing a new hardware deployment and we're having some trouble with this server type.  The cpqary3 driver included with the omnios stable is obsolete, and I replaced it in the shell before the install.

The server is a HP DL 360 g8 with a P420i Smart array.

OmniOS installs just fine after replacing the driver but after the initial reboot the kernel panics, with the error message (see attachment for screenshot hopefully it's visible)

NOTICE: Can not read the pool label from '/pci at 0,0/..../sd at 0,0:a'
NOTICE: spa_import_rootpool: error 5
..
..
.

I've googled for similar errors but the fixes mentioned there had no effect (importing and exporting the pool from a live boot)

I've tested with OmniOS OmniOS_Text_r151004, OmniOS_Text_r151006 and OmniOS_Text_bloody_20130208. The same image and procedure to replace the driver works just fine on a DL380g5 with a P400 controler.

While the same procedure works just fine with openindiana 151a7. But I'm not willing to put openindiana in production.


Any pointers how to solve this or what might be causing this?

________________________________
This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. E-mail message is scanned by Anti-Virus Software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130523/c7e3f7d4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ilo.PNG
Type: image/png
Size: 17263 bytes
Desc: ilo.PNG
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130523/c7e3f7d4/attachment-0001.png>

From daleg at omniti.com  Thu May 23 11:33:00 2013
From: daleg at omniti.com (Dale Ghent)
Date: Thu, 23 May 2013 11:33:00 -0400
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
In-Reply-To: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
Message-ID: <1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>


The phys_path attribute in your disk label for your rpool needs to be updated, as it sounds like the rpool was created on different hardware which had different device paths than the machine you're trying to boot on here.

A quick way to fix this is to boot off the install CD or USB image and:

zpool import -R /a -f rpool

That action alone will update the attribute and you should then be able to boot normally.

/dale


On May 23, 2013, at 11:10 AM, Ale? Jagri?, Fora d.o.o. <ales.jagric at forum-racunalnistva.eu> wrote:

> Hey,
>  
> We're testing a new hardware deployment and we're having some trouble with this server type.  The cpqary3 driver included with the omnios stable is obsolete, and I replaced it in the shell before the install.
>  
> The server is a HP DL 360 g8 with a P420i Smart array.
>  
> OmniOS installs just fine after replacing the driver but after the initial reboot the kernel panics, with the error message (see attachment for screenshot hopefully it?s visible)
>  
> NOTICE: Can not read the pool label from '/pci at 0,0/?./sd at 0,0:a'
> NOTICE: spa_import_rootpool: error 5
> ..
> ..
> .
>  
> I?ve googled for similar errors but the fixes mentioned there had no effect (importing and exporting the pool from a live boot)
>  
> I've tested with OmniOS OmniOS_Text_r151004, OmniOS_Text_r151006 and OmniOS_Text_bloody_20130208. The same image and procedure to replace the driver works just fine on a DL380g5 with a P400 controler.
>  
> While the same procedure works just fine with openindiana 151a7. But I'm not willing to put openindiana in production.
>  
>  
> Any pointers how to solve this or what might be causing this?
> 
> This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. E-mail message is scanned by Anti-Virus Software.
> <ilo.PNG>_______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130523/f43cbc48/attachment.html>

From ales.jagric at forum-racunalnistva.eu  Thu May 23 12:30:00 2013
From: ales.jagric at forum-racunalnistva.eu (=?iso-8859-2?Q?Ale=B9_Jagri=E8=2C_Fora_d=2Eo=2Eo=2E?=)
Date: Thu, 23 May 2013 18:30:00 +0200
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
In-Reply-To: <1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
Message-ID: <28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>

Thanks for the input but that did not help, I have tried something similar before, the error message returned was the same.

P.S.
The rpool mounts perfectly fine with the live cd, this is a fresh install on this hardware, it's not ported from anywhere.

Unless I'm missing something.

From: Dale Ghent [mailto:daleg at omniti.com]
Sent: Thursday, May 23, 2013 5:33 PM
To: Ale? Jagri?, Fora d.o.o.
Cc: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] OmniOS install on HP DL360g8


The phys_path attribute in your disk label for your rpool needs to be updated, as it sounds like the rpool was created on different hardware which had different device paths than the machine you're trying to boot on here.

A quick way to fix this is to boot off the install CD or USB image and:

zpool import -R /a -f rpool

That action alone will update the attribute and you should then be able to boot normally.

/dale


On May 23, 2013, at 11:10 AM, Ale? Jagri?, Fora d.o.o. <ales.jagric at forum-racunalnistva.eu<mailto:ales.jagric at forum-racunalnistva.eu>> wrote:


Hey,

We're testing a new hardware deployment and we're having some trouble with this server type.  The cpqary3 driver included with the omnios stable is obsolete, and I replaced it in the shell before the install.

The server is a HP DL 360 g8 with a P420i Smart array.

OmniOS installs just fine after replacing the driver but after the initial reboot the kernel panics, with the error message (see attachment for screenshot hopefully it's visible)

NOTICE: Can not read the pool label from '/pci at 0,0/..../sd at 0,0:a'
NOTICE: spa_import_rootpool: error 5
..
..
.

I've googled for similar errors but the fixes mentioned there had no effect (importing and exporting the pool from a live boot)

I've tested with OmniOS OmniOS_Text_r151004, OmniOS_Text_r151006 and OmniOS_Text_bloody_20130208. The same image and procedure to replace the driver works just fine on a DL380g5 with a P400 controler.

While the same procedure works just fine with openindiana 151a7. But I'm not willing to put openindiana in production.


Any pointers how to solve this or what might be causing this?

________________________________
This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. E-mail message is scanned by Anti-Virus Software.
<ilo.PNG>_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com<mailto:OmniOS-discuss at lists.omniti.com>
http://lists.omniti.com/mailman/listinfo/omnios-discuss


________________________________
This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. E-mail message is scanned by Anti-Virus Software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130523/00691d58/attachment.html>

From esproul at omniti.com  Thu May 23 12:58:07 2013
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 23 May 2013 12:58:07 -0400
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
In-Reply-To: <28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
Message-ID: <CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>

Perhaps the cpqary3 driver update was only done to the installer's
ramdisk environment and not also to the installed pool?

On Thu, May 23, 2013 at 12:30 PM, Ale? Jagri?, Fora d.o.o.
<ales.jagric at forum-racunalnistva.eu> wrote:
> Thanks for the input but that did not help, I have tried something similar
> before, the error message returned was the same.
>
>
>
> P.S.
>
> The rpool mounts perfectly fine with the live cd, this is a fresh install on
> this hardware, it?s not ported from anywhere.
>
>
>
> Unless I?m missing something.
>
>
>
> From: Dale Ghent [mailto:daleg at omniti.com]
> Sent: Thursday, May 23, 2013 5:33 PM
> To: Ale? Jagri?, Fora d.o.o.
> Cc: omnios-discuss at lists.omniti.com
> Subject: Re: [OmniOS-discuss] OmniOS install on HP DL360g8
>
>
>
>
>
> The phys_path attribute in your disk label for your rpool needs to be
> updated, as it sounds like the rpool was created on different hardware which
> had different device paths than the machine you're trying to boot on here.
>
>
>
> A quick way to fix this is to boot off the install CD or USB image and:
>
>
>
> zpool import -R /a -f rpool
>
>
>
> That action alone will update the attribute and you should then be able to
> boot normally.
>
>
>
> /dale
>
>
>
>
>
> On May 23, 2013, at 11:10 AM, Ale? Jagri?, Fora d.o.o.
> <ales.jagric at forum-racunalnistva.eu> wrote:
>
>
>
> Hey,
>
>
>
> We're testing a new hardware deployment and we're having some trouble with
> this server type.  The cpqary3 driver included with the omnios stable is
> obsolete, and I replaced it in the shell before the install.
>
>
>
> The server is a HP DL 360 g8 with a P420i Smart array.
>
>
>
> OmniOS installs just fine after replacing the driver but after the initial
> reboot the kernel panics, with the error message (see attachment for
> screenshot hopefully it?s visible)
>
>
>
> NOTICE: Can not read the pool label from '/pci at 0,0/?./sd at 0,0:a'
> NOTICE: spa_import_rootpool: error 5
>
> ..
>
> ..
>
> .
>
>
>
> I?ve googled for similar errors but the fixes mentioned there had no effect
> (importing and exporting the pool from a live boot)
>
>
>
> I've tested with OmniOS OmniOS_Text_r151004, OmniOS_Text_r151006 and
> OmniOS_Text_bloody_20130208. The same image and procedure to replace the
> driver works just fine on a DL380g5 with a P400 controler.
>
>
>
> While the same procedure works just fine with openindiana 151a7. But I'm not
> willing to put openindiana in production.
>
>
>
>
>
> Any pointers how to solve this or what might be causing this?
>
>
>
> ________________________________
>
> This e-mail and any attachments may contain confidential and/or privileged
> information and is intended solely for the addressee. If you are not the
> intended recipient (or have received this e-mail in error) please notify the
> sender immediately and destroy this e-mail. Any unauthorized copying,
> disclosure or distribution of the material in this e-mail is strictly
> forbidden. E-mail message is scanned by Anti-Virus Software.
> <ilo.PNG>_______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
>
> ________________________________
> This e-mail and any attachments may contain confidential and/or privileged
> information and is intended solely for the addressee. If you are not the
> intended recipient (or have received this e-mail in error) please notify the
> sender immediately and destroy this e-mail. Any unauthorized copying,
> disclosure or distribution of the material in this e-mail is strictly
> forbidden. E-mail message is scanned by Anti-Virus Software.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From esproul at omniti.com  Thu May 23 14:55:52 2013
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 23 May 2013 14:55:52 -0400
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
In-Reply-To: <28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
Message-ID: <CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>

On Thu, May 23, 2013 at 2:47 PM, Ale? Jagri?, Fora d.o.o.
<ales.jagric at forum-racunalnistva.eu> wrote:
> I thought of that, but the driver on the rpool (at least the binary) is updated, however i don't know if it should be inside the boot_archive. I'm only guessing here but is there (should it be?) a driver inside the boot_archive?

Yes, if you update the driver in the rpool, then you must run 'bootadm
update_archive' (you'd need to suffix '-R /a' if you were doing this
from the ramdisk environment with rpool mounted at /a).

From esproul at omniti.com  Thu May 23 14:56:30 2013
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 23 May 2013 14:56:30 -0400
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
In-Reply-To: <CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>
Message-ID: <CA+QY2RS_gwgLzrsvScVjfx0nA4xYqfGEKtrrVneL9E2TyHa4zA@mail.gmail.com>

On Thu, May 23, 2013 at 2:55 PM, Eric Sproul <esproul at omniti.com> wrote:
> Yes, if you update the driver in the rpool, then you must run 'bootadm
> update_archive'

That should be "update-archive" (dash, not underscore)

From ales.jagric at forum-racunalnistva.eu  Thu May 23 14:47:27 2013
From: ales.jagric at forum-racunalnistva.eu (=?windows-1250?Q?Ale=9A_Jagri=E8=2C_Fora_d=2Eo=2Eo=2E?=)
Date: Thu, 23 May 2013 20:47:27 +0200
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
In-Reply-To: <CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>,
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
Message-ID: <28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>

I thought of that, but the driver on the rpool (at least the binary) is updated, however i don't know if it should be inside the boot_archive. I'm only guessing here but is there (should it be?) a driver inside the boot_archive?

I still do not understand why the process would work on openindiana and not on omnios. But I only have basic knowledge on how this works.

Any pointers on what i should check if the driver is everywhere is should be? It certainly looks like it's not getting updated somewhere.
________________________________________
From: omnios-discuss-bounces at lists.omniti.com [omnios-discuss-bounces at lists.omniti.com] On Behalf Of Eric Sproul [esproul at omniti.com]
Sent: Thursday, May 23, 2013 6:58 PM
To: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] OmniOS install on HP DL360g8

Perhaps the cpqary3 driver update was only done to the installer's
ramdisk environment and not also to the installed pool?

On Thu, May 23, 2013 at 12:30 PM, Ale? Jagri?, Fora d.o.o.
<ales.jagric at forum-racunalnistva.eu> wrote:
> Thanks for the input but that did not help, I have tried something similar
> before, the error message returned was the same.
>
>
>
> P.S.
>
> The rpool mounts perfectly fine with the live cd, this is a fresh install on
> this hardware, it?s not ported from anywhere.
>
>
>
> Unless I?m missing something.
>
>
>
> From: Dale Ghent [mailto:daleg at omniti.com]
> Sent: Thursday, May 23, 2013 5:33 PM
> To: Ale? Jagri?, Fora d.o.o.
> Cc: omnios-discuss at lists.omniti.com
> Subject: Re: [OmniOS-discuss] OmniOS install on HP DL360g8
>
>
>
>
>
> The phys_path attribute in your disk label for your rpool needs to be
> updated, as it sounds like the rpool was created on different hardware which
> had different device paths than the machine you're trying to boot on here.
>
>
>
> A quick way to fix this is to boot off the install CD or USB image and:
>
>
>
> zpool import -R /a -f rpool
>
>
>
> That action alone will update the attribute and you should then be able to
> boot normally.
>
>
>
> /dale
>
>
>
>
>
> On May 23, 2013, at 11:10 AM, Ale? Jagri?, Fora d.o.o.
> <ales.jagric at forum-racunalnistva.eu> wrote:
>
>
>
> Hey,
>
>
>
> We're testing a new hardware deployment and we're having some trouble with
> this server type.  The cpqary3 driver included with the omnios stable is
> obsolete, and I replaced it in the shell before the install.
>
>
>
> The server is a HP DL 360 g8 with a P420i Smart array.
>
>
>
> OmniOS installs just fine after replacing the driver but after the initial
> reboot the kernel panics, with the error message (see attachment for
> screenshot hopefully it?s visible)
>
>
>
> NOTICE: Can not read the pool label from '/pci at 0,0/?./sd at 0,0:a'
> NOTICE: spa_import_rootpool: error 5
>
> ..
>
> ..
>
> .
>
>
>
> I?ve googled for similar errors but the fixes mentioned there had no effect
> (importing and exporting the pool from a live boot)
>
>
>
> I've tested with OmniOS OmniOS_Text_r151004, OmniOS_Text_r151006 and
> OmniOS_Text_bloody_20130208. The same image and procedure to replace the
> driver works just fine on a DL380g5 with a P400 controler.
>
>
>
> While the same procedure works just fine with openindiana 151a7. But I'm not
> willing to put openindiana in production.
>
>
>
>
>
> Any pointers how to solve this or what might be causing this?
>
>
>
> ________________________________
>
> This e-mail and any attachments may contain confidential and/or privileged
> information and is intended solely for the addressee. If you are not the
> intended recipient (or have received this e-mail in error) please notify the
> sender immediately and destroy this e-mail. Any unauthorized copying,
> disclosure or distribution of the material in this e-mail is strictly
> forbidden. E-mail message is scanned by Anti-Virus Software.
> <ilo.PNG>_______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
>
> ________________________________
> This e-mail and any attachments may contain confidential and/or privileged
> information and is intended solely for the addressee. If you are not the
> intended recipient (or have received this e-mail in error) please notify the
> sender immediately and destroy this e-mail. Any unauthorized copying,
> disclosure or distribution of the material in this e-mail is strictly
> forbidden. E-mail message is scanned by Anti-Virus Software.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. E-mail message is scanned by Anti-Virus Software.

From esproul at omniti.com  Thu May 23 17:28:57 2013
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 23 May 2013 17:28:57 -0400
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
In-Reply-To: <28B6AD1E823631489A2CAF747DB9D60A010733031437@exchange>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031437@exchange>
Message-ID: <CA+QY2RT0OogDpBh6OskAb3pMVqRNoVHGJWhoz=gsgj-_oosbqA@mail.gmail.com>

On Thu, May 23, 2013 at 5:02 PM, Ale? Jagri?, Fora d.o.o.
<ales.jagric at forum-racunalnistva.eu> wrote:
> Ok, the boot_archive got updated, still panicking.
>
> I'll recap what i've done;
>
> Booted the latest stable OmniOS image and selected shell
>
> Then i did this
>
> rem_drv cpqary3
> rm -rf /var/sadm/pkg/CPQary3
> find /kernel -name cpqary\* -exec rm {} \+ pkgadd -d /root/CPQary3.pkg
>
> exited the shell and ran the installer, installed and rebooted. This panics on reboot.

It looks like you only installed CPQary3.pkg in the installer's
ramdisk environment.

>
> Then i booted agan with the live image
>
> Did zpool import -R /a -f rpool
>
> did beadm list an beadm mount omnios /b
>
> So i got to the root filesystem, then i executed the command below (or above ;) ) bootadm update_archive -v -R /b
>
> This did update the boot_archive in /platform but did not boot :/

If I'm not mistaken, you also need to install the CPQary3.pkg in the
installed root filesystem, i.e. after install but before rebooting.
You would then do the boot archive update to ensure the updated
cpqary3 driver binary is in there.

Eric

From esproul at omniti.com  Thu May 23 17:30:38 2013
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 23 May 2013 17:30:38 -0400
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
In-Reply-To: <28B6AD1E823631489A2CAF747DB9D60A010733031438@exchange>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031438@exchange>
Message-ID: <CA+QY2RTti3AVbqBTMW0hsB7q=vy-nQ+=wP+yed1-DeUa5v8z=Q@mail.gmail.com>

On Thu, May 23, 2013 at 5:20 PM, Ale? Jagri?, Fora d.o.o.
<ales.jagric at forum-racunalnistva.eu> wrote:
> Ok guys I did it :D poke me so we can grab a beer next time you're near my part of cyberspace, couldn't have done it without you.
>
> Just to recap what I did so it may help out some poor soul in the future.
>
> Basically I did the same as described below, but after the install and before updating the boot_archive I reinstalled the driver with pkgadd and alternative root with the -R switch addpkg -d cpqary3.pkg -R /j/b in my case, ran the update and tada! :D

Yep, I saw your message *just* after I posted my response, so yeah,
earlier you still had the original cpqary3 in the installed system.

From ales.jagric at forum-racunalnistva.eu  Thu May 23 17:02:06 2013
From: ales.jagric at forum-racunalnistva.eu (=?utf-8?B?QWxlxaEgSmFncmnEjSwgRm9yYSBkLm8uby4=?=)
Date: Thu, 23 May 2013 23:02:06 +0200
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
In-Reply-To: <CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>
Message-ID: <28B6AD1E823631489A2CAF747DB9D60A010733031437@exchange>

Ok, the boot_archive got updated, still panicking.

I'll recap what i've done;

Booted the latest stable OmniOS image and selected shell

Then i did this

rem_drv cpqary3
rm -rf /var/sadm/pkg/CPQary3
find /kernel -name cpqary\* -exec rm {} \+ pkgadd -d /root/CPQary3.pkg

exited the shell and ran the installer, installed and rebooted. This panics on reboot.

Then i booted agan with the live image

Did zpool import -R /a -f rpool

did beadm list an beadm mount omnios /b

So i got to the root filesystem, then i executed the command below (or above ;) ) bootadm update_archive -v -R /b

This did update the boot_archive in /platform but did not boot :/

I'll keep looking.

-----Original Message-----
From: omnios-discuss-bounces at lists.omniti.com [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Eric Sproul
Sent: Thursday, May 23, 2013 8:56 PM
To: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] OmniOS install on HP DL360g8

On Thu, May 23, 2013 at 2:47 PM, Ale? Jagri?, Fora d.o.o.
<ales.jagric at forum-racunalnistva.eu> wrote:
> I thought of that, but the driver on the rpool (at least the binary) is updated, however i don't know if it should be inside the boot_archive. I'm only guessing here but is there (should it be?) a driver inside the boot_archive?

Yes, if you update the driver in the rpool, then you must run 'bootadm update_archive' (you'd need to suffix '-R /a' if you were doing this from the ramdisk environment with rpool mounted at /a).
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. E-mail message is scanned by Anti-Virus Software.

From ales.jagric at forum-racunalnistva.eu  Thu May 23 17:20:08 2013
From: ales.jagric at forum-racunalnistva.eu (=?utf-8?B?QWxlxaEgSmFncmnEjSwgRm9yYSBkLm8uby4=?=)
Date: Thu, 23 May 2013 23:20:08 +0200
Subject: [OmniOS-discuss] OmniOS install on HP DL360g8
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com> 
Message-ID: <28B6AD1E823631489A2CAF747DB9D60A010733031438@exchange>

Ok guys I did it :D poke me so we can grab a beer next time you're near my part of cyberspace, couldn't have done it without you.

Just to recap what I did so it may help out some poor soul in the future.

Basically I did the same as described below, but after the install and before updating the boot_archive I reinstalled the driver with pkgadd and alternative root with the -R switch addpkg -d cpqary3.pkg -R /j/b in my case, ran the update and tada! :D

Now I can get some sleep and figure out how to integrate the damn thing in the iso :D

Thanks guys, you were great!

-----Original Message-----
From: Ale? Jagri?, Fora d.o.o.
Sent: Thursday, May 23, 2013 11:02 PM
To: 'Eric Sproul'; omnios-discuss at lists.omniti.com
Subject: RE: [OmniOS-discuss] OmniOS install on HP DL360g8

Ok, the boot_archive got updated, still panicking.

I'll recap what i've done;

Booted the latest stable OmniOS image and selected shell

Then i did this

rem_drv cpqary3
rm -rf /var/sadm/pkg/CPQary3
find /kernel -name cpqary\* -exec rm {} \+ pkgadd -d /root/CPQary3.pkg

exited the shell and ran the installer, installed and rebooted. This panics on reboot.

Then i booted agan with the live image

Did zpool import -R /a -f rpool

did beadm list an beadm mount omnios /b

So i got to the root filesystem, then i executed the command below (or above ;) ) bootadm update_archive -v -R /b

This did update the boot_archive in /platform but did not boot :/

I'll keep looking.

-----Original Message-----
From: omnios-discuss-bounces at lists.omniti.com [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Eric Sproul
Sent: Thursday, May 23, 2013 8:56 PM
To: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] OmniOS install on HP DL360g8

On Thu, May 23, 2013 at 2:47 PM, Ale? Jagri?, Fora d.o.o.
<ales.jagric at forum-racunalnistva.eu> wrote:
> I thought of that, but the driver on the rpool (at least the binary) is updated, however i don't know if it should be inside the boot_archive. I'm only guessing here but is there (should it be?) a driver inside the boot_archive?

Yes, if you update the driver in the rpool, then you must run 'bootadm update_archive' (you'd need to suffix '-R /a' if you were doing this from the ramdisk environment with rpool mounted at /a).
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. E-mail message is scanned by Anti-Virus Software.

From henson at acm.org  Fri May 24 16:07:33 2013
From: henson at acm.org (Paul B. Henson)
Date: Fri, 24 May 2013 13:07:33 -0700
Subject: [OmniOS-discuss] cannot remove temp dir
In-Reply-To: <1368141086.91170.YahooMailNeo@web172802.mail.ir2.yahoo.com>
References: <1368109706.65094.YahooMailNeo@web172802.mail.ir2.yahoo.com>
	<518BF26F.1050500@acm.org>
	<1368132639.12656.YahooMailNeo@web172803.mail.ir2.yahoo.com>
	<518C2A29.2050302@acm.org>
	<1368141086.91170.YahooMailNeo@web172802.mail.ir2.yahoo.com>
Message-ID: <20130524200733.GJ30773@bender.unx.csupomona.edu>

On Fri, May 10, 2013 at 12:11:26AM +0100, Matthieu Paindavoine wrote:

> Install a 'bloody' OmniOS from DVD.
[...]
> #> ./configure --prefix=/opt/ghc-7.0.3
> #> make install
> 
> update path and ld_library_path
[...]
> #> ./configure --prefix=/opt/ghc-7.4.2
> #> make install

I'm trying to reproduce this on the just released omnios stable.
Installing ghc gives me this error:

Installing library in /opt/ghc-7.4.2/lib/ghc-7.4.2/ghc-prim-0.2.0.0
ghc-cabal: Error: Could not find module: GHC.Classes with any suffix:
["p_hi"]
in the search path: ["dist-install/build"]
make[1]: *** [install_packages] Error 1
make: *** [install] Error 2

It's probably to do with updating LD_LIBRARY_PATH? It's obvious what
path should be changed to include, but I'm not sure what to change in
LD_LIBRARY_PATH? After installing the binary ghc 7.0.3, I added
/opt/ghc-7.0.3/lib/ghc-7.0.3. That dir includes a bunch of subdirs
though, do they all need to be added as well? Or?


From hakansom at ohsu.edu  Fri May 24 18:47:24 2013
From: hakansom at ohsu.edu (Marion Hakanson)
Date: Fri, 24 May 2013 15:47:24 -0700
Subject: [OmniOS-discuss] X11 application support
In-Reply-To: Message from Theo Schlossnagle <jesus@omniti.com> of "Fri,
	17 May 2013 10:51:32 PDT."
	<CACLsApvsdZjzKH1PRPboCyyLMQMaU+g5DqbcDHFJhn4FDx+Djw@mail.gmail.com>
Message-ID: <201305242247.r4OMlOMe027413@kyklops.ohsu.edu>

jesus at omniti.com said:
> . . .
> 4) There are people using Joyent's pkgsrc work to build X libs. 

Once I have done the above (sufficient to support whatever X11 apps
I need), will the core OmniOS sshd tunnel X11 to it?  Or do I need
to build my own sshd as well?

Thanks and regards,

Marion



From tim at multitalents.net  Fri May 24 21:27:42 2013
From: tim at multitalents.net (Tim Rice)
Date: Fri, 24 May 2013 18:27:42 -0700 (PDT)
Subject: [OmniOS-discuss] X11 application support
In-Reply-To: <201305242247.r4OMlOMe027413@kyklops.ohsu.edu>
References: <201305242247.r4OMlOMe027413@kyklops.ohsu.edu>
Message-ID: <Pine.UW2.4.64.1305241823380.22664@server01.int.multitalents.net>

On Fri, 24 May 2013, Marion Hakanson wrote:

> jesus at omniti.com said:
> > . . .
> > 4) There are people using Joyent's pkgsrc work to build X libs. 
> 
> Once I have done the above (sufficient to support whatever X11 apps
> I need), will the core OmniOS sshd tunnel X11 to it?  Or do I need
> to build my own sshd as well?

sshd will tunnel X11 fine.
sshd does not link to any X11 libs.

> Thanks and regards,
> 
> Marion

-- 
Tim Rice				Multitalents
tim at multitalents.net



From hakansom at ohsu.edu  Fri May 24 21:37:08 2013
From: hakansom at ohsu.edu (Marion Hakanson)
Date: Fri, 24 May 2013 18:37:08 -0700
Subject: [OmniOS-discuss] X11 application support
In-Reply-To: Message from Tim Rice <tim@multitalents.net> of "Fri,
	24 May 2013 18:27:42 PDT."
	<Pine.UW2.4.64.1305241823380.22664@server01.int.multitalents.net>
Message-ID: <201305250137.r4P1b8Rq027779@kyklops.ohsu.edu>

tim at multitalents.net said:
> sshd will tunnel X11 fine. sshd does not link to any X11 libs. 

Thanks for the note, Tim.

A bit of "truss" work makes it look like sshd stat()'s for the presence
of /usr/X11/bin/xauth, and then uses that to setup the X11 authentication
passed through from the remote system.  So my current hypothesis is that
once I've got an xauth binary somewhere, a symlink to it from /usr/X11/bin/
will be in order.

Regards,

Marion



From tim at multitalents.net  Fri May 24 22:41:01 2013
From: tim at multitalents.net (Tim Rice)
Date: Fri, 24 May 2013 19:41:01 -0700 (PDT)
Subject: [OmniOS-discuss] X11 application support
In-Reply-To: <201305250137.r4P1b8Rq027779@kyklops.ohsu.edu>
References: <201305250137.r4P1b8Rq027779@kyklops.ohsu.edu>
Message-ID: <Pine.UW2.4.64.1305241937450.22664@server01.int.multitalents.net>

On Fri, 24 May 2013, Marion Hakanson wrote:

> tim at multitalents.net said:
> > sshd will tunnel X11 fine. sshd does not link to any X11 libs. 
> 
> Thanks for the note, Tim.
> 
> A bit of "truss" work makes it look like sshd stat()'s for the presence
> of /usr/X11/bin/xauth, and then uses that to setup the X11 authentication
> passed through from the remote system.  So my current hypothesis is that
> once I've got an xauth binary somewhere, a symlink to it from /usr/X11/bin/
> will be in order.

Yes it will need xauth. But I expect you'll have that when you have all
the X11 bits you'll need for your software.

The point I was attempting to make is, no need to rebuild sshd.

> Regards,
> 
> Marion

-- 
Tim Rice				Multitalents
tim at multitalents.net



From richard.palo at baou.fr  Sun May 26 02:57:14 2013
From: richard.palo at baou.fr (Richard PALO)
Date: Sun, 26 May 2013 08:57:14 +0200
Subject: [OmniOS-discuss] bloody problems: pkg update: No solution was found
	to satisfy constraints
Message-ID: <knsbo4$cdo$1@ger.gmane.org>

> root at omni1:~# uname -a
> SunOS omni1 5.11 omnios-8d266aa i86pc i386 i86pc Solaris
> root at omni1:~# pkg refresh --full
> root at omni1:~# pkg update -v
> Creating Plan \
> pkg update: No solution was found to satisfy constraints
> Plan Creation: Package solver has not found a solution to update to latest available versions.
> This may indicate an overly constrained set of packages are installed.
>
> latest incorporations:
>
>   pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130516T041331Z
>   pkg://omnios/entire at 11,5.11-0.151007:20130518T132910Z
>   pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151007:20130516T112638Z
>
> The following indicates why the system cannot update to the latest version:
>
>   No suitable version of required package pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151007:20130516T112638Z found:
>     Reject:  pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151007:20130516T112638Z
>     Reason:  A version for 'incorporate' dependency on pkg:/crypto/ca-certificates at 0.5.11,5.11-0.151007 cannot be found
>   No suitable version of required package pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130516T041331Z found:
>     Reject:  pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130516T041331Z
>     Reason:  All versions matching 'incorporate' dependency pkg:/service/resource-pools/poold at 0.5.11,5.11-0.151007 are rejected
>       Reject:  pkg://omnios/service/resource-pools/poold at 0.5.11,5.11-0.151007:20130514T014229Z
>                pkg://omnios/service/resource-pools/poold at 0.5.11,5.11-0.151007:20130516T041406Z
>       Reason:  A version for 'require' dependency on pkg:/runtime/java at 0.5.11,5.11-0.151006 cannot be found
>   No suitable version of required package pkg://omnios/entire at 11,5.11-0.151007:20130518T132910Z found:
>     Reject:  pkg://omnios/entire at 11,5.11-0.151007:20130518T132910Z
>     Reason:  All versions matching 'require' dependency pkg:/service/resource-pools/poold at 0.5.11,5.11-0.151007 are rejected
>       Reject:  pkg://omnios/service/resource-pools/poold at 0.5.11,5.11-0.151007:20130514T014229Z
>                pkg://omnios/service/resource-pools/poold at 0.5.11,5.11-0.151007:20130516T041406Z
>       Reason:  A version for 'require' dependency on pkg:/runtime/java at 0.5.11,5.11-0.151006 cannot be found
>


From jesus at omniti.com  Sun May 26 08:22:54 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Sun, 26 May 2013 08:22:54 -0400
Subject: [OmniOS-discuss] bloody problems: pkg update: No solution was
 found to satisfy constraints
In-Reply-To: <knsbo4$cdo$1@ger.gmane.org>
References: <knsbo4$cdo$1@ger.gmane.org>
Message-ID: <CACLsApt-a1R-4NeDcH2iXgrJzBVA2xW1sMQfdnRBT3u+S8FuVw@mail.gmail.com>

151007 still isn't quite ready. We're missing java packages, for one. It'll
likely take a few weeks to sort all that out.
On May 26, 2013 3:01 AM, "Richard PALO" <richard.palo at baou.fr> wrote:

> root at omni1:~# uname -a
>> SunOS omni1 5.11 omnios-8d266aa i86pc i386 i86pc Solaris
>> root at omni1:~# pkg refresh --full
>> root at omni1:~# pkg update -v
>> Creating Plan \
>> pkg update: No solution was found to satisfy constraints
>> Plan Creation: Package solver has not found a solution to update to
>> latest available versions.
>> This may indicate an overly constrained set of packages are installed.
>>
>> latest incorporations:
>>
>>   pkg://omnios/consolidation/**osnet/osnet-incorporation at 0.5.**
>> 11,5.11-0.151007:**20130516T041331Z
>>   pkg://omnios/entire at 11,5.11-0.**151007:20130518T132910Z
>>   pkg://omnios/incorporation/**jeos/illumos-gate at 11,5.11-0.**
>> 151007:20130516T112638Z
>>
>> The following indicates why the system cannot update to the latest
>> version:
>>
>>   No suitable version of required package pkg://omnios/incorporation/**
>> jeos/illumos-gate at 11,5.11-0.**151007:20130516T112638Z found:
>>     Reject:  pkg://omnios/incorporation/**jeos/illumos-gate at 11,5.11-0.**
>> 151007:20130516T112638Z
>>     Reason:  A version for 'incorporate' dependency on
>> pkg:/crypto/ca-certificates at 0.**5.11,5.11-0.151007 cannot be found
>>   No suitable version of required package pkg://omnios/consolidation/**
>> osnet/osnet-incorporation at 0.5.**11,5.11-0.151007:**20130516T041331Z
>> found:
>>     Reject:  pkg://omnios/consolidation/**osnet/osnet-incorporation at 0.5.*
>> *11,5.11-0.151007:**20130516T041331Z
>>     Reason:  All versions matching 'incorporate' dependency
>> pkg:/service/resource-pools/**poold at 0.5.11,5.11-0.151007 are rejected
>>       Reject:  pkg://omnios/service/resource-**pools/poold at 0.5.11,5.11-0.
>> **151007:20130514T014229Z
>>                pkg://omnios/service/resource-**pools/poold at 0.5.11,5.11-0.
>> **151007:20130516T041406Z
>>       Reason:  A version for 'require' dependency on
>> pkg:/runtime/java at 0.5.11,5.11-**0.151006 cannot be found
>>   No suitable version of required package pkg://omnios/entire at 11,5.11-0.*
>> *151007:20130518T132910Z found:
>>     Reject:  pkg://omnios/entire at 11,5.11-0.**151007:20130518T132910Z
>>     Reason:  All versions matching 'require' dependency
>> pkg:/service/resource-pools/**poold at 0.5.11,5.11-0.151007 are rejected
>>       Reject:  pkg://omnios/service/resource-**pools/poold at 0.5.11,5.11-0.
>> **151007:20130514T014229Z
>>                pkg://omnios/service/resource-**pools/poold at 0.5.11,5.11-0.
>> **151007:20130516T041406Z
>>       Reason:  A version for 'require' dependency on
>> pkg:/runtime/java at 0.5.11,5.11-**0.151006 cannot be found
>>
>>
> ______________________________**_________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.**com <OmniOS-discuss at lists.omniti.com>
> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss<http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130526/cbad941d/attachment.html>

From sriram at belenix.org  Sun May 26 12:17:23 2013
From: sriram at belenix.org (Sriram Narayanan)
Date: Sun, 26 May 2013 21:47:23 +0530
Subject: [OmniOS-discuss] VirtIO drivers for OmniOS ?
Message-ID: <CANiY96aoySons2DjhE9p93A2p22P7LqkbxaH5jVZrPZUt_=VVw@mail.gmail.com>

Hi folks:

I'm running OmniOS on a Qemu VM on Linux Mint 15. I'm on a Dell XPS 13 with
8 GB RAM and an SSD drive.

Are there any virtio drivers that are available which I could install into
the OmniOS VM ?

-- Sriram
Belenix: www.belenix.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130526/e3a3182b/attachment.html>

From ramquick at gmail.com  Mon May 27 13:01:05 2013
From: ramquick at gmail.com (Ram Chander)
Date: Mon, 27 May 2013 22:31:05 +0530
Subject: [OmniOS-discuss] Mbuffer breaks
Message-ID: <CAMRGQbN=g-8_8aTpyWGgCSkVEja8ES67MsCY3CNV7v8zXJMbug@mail.gmail.com>

Hi,

Am transferring Zfs snapshot using mbuffer. But after sometime, it stalls
and breaks with below error.  I retried 3 times but breaks with same error
( happens randomly  after transferring 40G, 120G, etc ).

Please help in this.

At source :

#  zfs send   pool at snap   | /opt/csw/bin/pigz -p 16  |
/usr/local/bin/mbuffer -t -m 8G -O 10.75.70.12:9090
in @  0.0 KiB/s, out @  0.0 KiB/s, 42.0 GiB total, buffer 100% full
mbuffer: error: outputThread: error writing to 10.75.70.12:9090 at offset
0xa7eeef000: Broken pipe

summary: 42.0 GiByte in 3 h 25 min 3575 KiB/s
mbuffer: warning: error during output to 10.75.70.12:9090: Broken pipe


At destination:
 /usr/local/bin/mbuffer -t  -m 8G -I  9090 | /opt/csw/bin/pigz -p 16 -d |
zfs receive -F pool


# /usr/local/bin/mbuffer -V
mbuffer version 20130220
Copyright 2001-2011 - T. Maier-Komor
License: GPLv3 - see file LICENSE
This program comes with ABSOLUTELY NO WARRANTY!!!
Donations via PayPal to thomas at maier-komor.de are welcome and support this
work!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130527/79764471/attachment.html>

From jesus at omniti.com  Mon May 27 13:44:59 2013
From: jesus at omniti.com (Theo Schlossnagle)
Date: Mon, 27 May 2013 13:44:59 -0400
Subject: [OmniOS-discuss] Mbuffer breaks
In-Reply-To: <CAMRGQbN=g-8_8aTpyWGgCSkVEja8ES67MsCY3CNV7v8zXJMbug@mail.gmail.com>
References: <CAMRGQbN=g-8_8aTpyWGgCSkVEja8ES67MsCY3CNV7v8zXJMbug@mail.gmail.com>
Message-ID: <CACLsApvDfTrYdmP=GD=_Oe4hcVThdJueLvM9bXJLxKBKsi9x7g@mail.gmail.com>

Can you try 'pv' that ships with OmniOS?
On May 27, 2013 1:04 PM, "Ram Chander" <ramquick at gmail.com> wrote:

> Hi,
>
> Am transferring Zfs snapshot using mbuffer. But after sometime, it stalls
> and breaks with below error.  I retried 3 times but breaks with same error
> ( happens randomly  after transferring 40G, 120G, etc ).
>
> Please help in this.
>
> At source :
>
> #  zfs send   pool at snap   | /opt/csw/bin/pigz -p 16  |
> /usr/local/bin/mbuffer -t -m 8G -O 10.75.70.12:9090
> in @  0.0 KiB/s, out @  0.0 KiB/s, 42.0 GiB total, buffer 100% full
> mbuffer: error: outputThread: error writing to 10.75.70.12:9090 at offset
> 0xa7eeef000: Broken pipe
>
> summary: 42.0 GiByte in 3 h 25 min 3575 KiB/s
> mbuffer: warning: error during output to 10.75.70.12:9090: Broken pipe
>
>
> At destination:
>  /usr/local/bin/mbuffer -t  -m 8G -I  9090 | /opt/csw/bin/pigz -p 16 -d |
> zfs receive -F pool
>
>
> # /usr/local/bin/mbuffer -V
> mbuffer version 20130220
> Copyright 2001-2011 - T. Maier-Komor
> License: GPLv3 - see file LICENSE
> This program comes with ABSOLUTELY NO WARRANTY!!!
> Donations via PayPal to thomas at maier-komor.de are welcome and support
> this work!
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130527/f5c92af9/attachment.html>

From ales at ovca.be  Mon May 27 13:48:58 2013
From: ales at ovca.be (Ales)
Date: Mon, 27 May 2013 19:48:58 +0200
Subject: [OmniOS-discuss] Supermicro X9DR6-F and intel i350 addin NICs
In-Reply-To: <519E8329.3040002@forum-racunalnistva.eu>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>,
	<519E8329.3040002@forum-racunalnistva.eu>
Message-ID: <51A39C8A.6090304@ovca.be>

Hey guys,

I'm playing around with a new server and two of the NICS (one dual port 
and one quad) are using the i350 intel chipset.

This is where things get strange, I can see the onboard cards

prtconf -D | grep pci15d9,1521

             pci15d9,1521, instance #0 (driver name: igb)

             pci15d9,1521, instance #1 (driver name: igb)

  dladm show-phys
LINK         MEDIA                STATE      SPEED  DUPLEX    DEVICE
igb0         Ethernet             up         1000   full      igb0
igb1         Ethernet             up         1000   full      igb1

lspci | grep -i ethernet
02:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network 
Connection (rev 01)
02:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network 
Connection (rev 01)

But the two addin cards are nowhere to be seen.

This is a supermicro server with one intel xeon E5-2609 and X9DR6-F 
motherboard.

Any pointers?

-------
Had to resend the message, my client ate the previous one ;)

From henson at acm.org  Mon May 27 15:00:33 2013
From: henson at acm.org (Paul B. Henson)
Date: Mon, 27 May 2013 12:00:33 -0700
Subject: [OmniOS-discuss] Supermicro X9DR6-F and intel i350 addin NICs
In-Reply-To: <51A39C8A.6090304@ovca.be>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>
	<519E8329.3040002@forum-racunalnistva.eu>
	<51A39C8A.6090304@ovca.be>
Message-ID: <20130527190033.GN30773@bender.unx.csupomona.edu>

On Mon, May 27, 2013 at 07:48:58PM +0200, Ales wrote:

> But the two addin cards are nowhere to be seen.
> 
> This is a supermicro server with one intel xeon E5-2609 and X9DR6-F 
> motherboard.

Isn't that a dual proc board? Some boards need both processors installed
for all the slots to work. Are you sure the slots you're using work with
whichever socket you have your single processor in?

There was also a thread recently about a X9DRW-7TPF+ board on which the
four slots on CPU2 wouldn't work, 

http://lists.omniti.com/pipermail/omnios-discuss/2013-April/000732.html

the root cause there was that illumos wasn't recognizing the PCI bridge
on CPU2. As far as I know that issue has not yet been resolved. I don't
know if it applies to your board.


From skiselkov.ml at gmail.com  Mon May 27 16:10:42 2013
From: skiselkov.ml at gmail.com (=?windows-1252?Q?Sa=9Ao_Kiselkov?=)
Date: Mon, 27 May 2013 22:10:42 +0200
Subject: [OmniOS-discuss] Supermicro X9DR6-F and intel i350 addin NICs
In-Reply-To: <51A39C8A.6090304@ovca.be>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>,
	<519E8329.3040002@forum-racunalnistva.eu> <51A39C8A.6090304@ovca.be>
Message-ID: <51A3BDC2.1090303@gmail.com>

On 05/27/2013 07:48 PM, Ales wrote:
> Hey guys,
> 
> I'm playing around with a new server and two of the NICS (one dual port
> and one quad) are using the i350 intel chipset.
> 
> This is where things get strange, I can see the onboard cards
> 
> prtconf -D | grep pci15d9,1521
> 
>             pci15d9,1521, instance #0 (driver name: igb)
> 
>             pci15d9,1521, instance #1 (driver name: igb)
> 
>  dladm show-phys
> LINK         MEDIA                STATE      SPEED  DUPLEX    DEVICE
> igb0         Ethernet             up         1000   full      igb0
> igb1         Ethernet             up         1000   full      igb1
> 
> lspci | grep -i ethernet
> 02:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network
> Connection (rev 01)
> 02:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network
> Connection (rev 01)
> 
> But the two addin cards are nowhere to be seen.
> 
> This is a supermicro server with one intel xeon E5-2609 and X9DR6-F
> motherboard.
> 
> Any pointers?

Hi Ales,

Try moving the cards around in PCI-e slots to find the ones that are
attached to socket #1. Currently Illumos has issues working with slots
attached to socket #2.

Cheers,
-- 
Saso

From skiselkov.ml at gmail.com  Mon May 27 16:12:17 2013
From: skiselkov.ml at gmail.com (=?windows-1252?Q?Sa=9Ao_Kiselkov?=)
Date: Mon, 27 May 2013 22:12:17 +0200
Subject: [OmniOS-discuss] Supermicro X9DR6-F and intel i350 addin NICs
In-Reply-To: <20130527190033.GN30773@bender.unx.csupomona.edu>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>
	<519E8329.3040002@forum-racunalnistva.eu>
	<51A39C8A.6090304@ovca.be>
	<20130527190033.GN30773@bender.unx.csupomona.edu>
Message-ID: <51A3BE21.70507@gmail.com>

On 05/27/2013 09:00 PM, Paul B. Henson wrote:
> the root cause there was that illumos wasn't recognizing the PCI bridge
> on CPU2. As far as I know that issue has not yet been resolved.

Just a minor clarification to add, Illumos in fact *does* recognize all
the PCI-e topology, including all bridges and add-in cards. The trouble
happens later on when the DDI constructs its device tree - for some
reason, it ignores everything attached to socket #2.

Cheers,
-- 
Saso

From ales at ovca.be  Mon May 27 16:15:59 2013
From: ales at ovca.be (Ales)
Date: Mon, 27 May 2013 22:15:59 +0200
Subject: [OmniOS-discuss] Supermicro X9DR6-F and intel i350 addin NICs
In-Reply-To: <51A3BE21.70507@gmail.com>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>
	<519E8329.3040002@forum-racunalnistva.eu>
	<51A39C8A.6090304@ovca.be>
	<20130527190033.GN30773@bender.unx.csupomona.edu>
	<51A3BE21.70507@gmail.com>
Message-ID: <51A3BEFF.9050300@ovca.be>

Found your thread just after posting, mine is a single CPU machine but 
does have 2 sockets, I'll try moving them around.

Thanks for the tip.

BR
Ales

On 27.5.2013 22:12, Sa?o Kiselkov wrote:
> On 05/27/2013 09:00 PM, Paul B. Henson wrote:
>> the root cause there was that illumos wasn't recognizing the PCI bridge
>> on CPU2. As far as I know that issue has not yet been resolved.
> Just a minor clarification to add, Illumos in fact *does* recognize all
> the PCI-e topology, including all bridges and add-in cards. The trouble
> happens later on when the DDI constructs its device tree - for some
> reason, it ignores everything attached to socket #2.
>
> Cheers,


From richard.elling at richardelling.com  Mon May 27 17:41:08 2013
From: richard.elling at richardelling.com (Richard Elling)
Date: Mon, 27 May 2013 14:41:08 -0700
Subject: [OmniOS-discuss] Mbuffer breaks
In-Reply-To: <CAMRGQbN=g-8_8aTpyWGgCSkVEja8ES67MsCY3CNV7v8zXJMbug@mail.gmail.com>
References: <CAMRGQbN=g-8_8aTpyWGgCSkVEja8ES67MsCY3CNV7v8zXJMbug@mail.gmail.com>
Message-ID: <7C246F40-6189-4153-BA06-592C6C2D6B63@RichardElling.com>

On May 27, 2013, at 10:01 AM, Ram Chander <ramquick at gmail.com> wrote:

> Hi,
> 
> Am transferring Zfs snapshot using mbuffer. But after sometime, it stalls and breaks with below error.  I retried 3 times but breaks with same error ( happens randomly  after transferring 40G, 120G, etc ).
> 
> Please help in this.
> 
> At source :
> 
> #  zfs send   pool at snap   | /opt/csw/bin/pigz -p 16  |  /usr/local/bin/mbuffer -t -m 8G -O 10.75.70.12:9090
> in @  0.0 KiB/s, out @  0.0 KiB/s, 42.0 GiB total, buffer 100% full
> mbuffer: error: outputThread: error writing to 10.75.70.12:9090 at offset 0xa7eeef000: Broken pipe

mbuffer isn't broken, something in the pipeline quit unexpectedly. mbuffer is simply reporting the fact.
These can be tricky to debug, unless you've captured stderr somewhere.
 -- richard

> 
> summary: 42.0 GiByte in 3 h 25 min 3575 KiB/s
> mbuffer: warning: error during output to 10.75.70.12:9090: Broken pipe
> 
> 
> At destination:
>  /usr/local/bin/mbuffer -t  -m 8G -I  9090 | /opt/csw/bin/pigz -p 16 -d | zfs receive -F pool
> 
> 
> # /usr/local/bin/mbuffer -V
> mbuffer version 20130220
> Copyright 2001-2011 - T. Maier-Komor
> License: GPLv3 - see file LICENSE
> This program comes with ABSOLUTELY NO WARRANTY!!!
> Donations via PayPal to thomas at maier-komor.de are welcome and support this work!
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 

ZFS storage and performance consulting at http://www.RichardElling.com







From geoffn at gnaa.net  Tue May 28 02:23:15 2013
From: geoffn at gnaa.net (Geoff Nordli)
Date: Mon, 27 May 2013 23:23:15 -0700
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
Message-ID: <51A44D53.4020604@gnaa.net>

Anyone have any success installing vbox on omnios?

I just did the install and it says it is partially installed.

I know there were some errors because it tries to use the netbow 
(crossbow) network driver instead of the streams based one.

I am sure there are some other reasons it doesn't work as well.

thanks,

Geoff

From tlawrie.it at gmail.com  Sat May 25 12:15:17 2013
From: tlawrie.it at gmail.com (Travis Lawrie)
Date: Sat, 25 May 2013 09:15:17 -0700
Subject: [OmniOS-discuss] rpool is almost full, how to expand?
In-Reply-To: <CAGDMd1p8P-QtPGa908W8zyWCNL4QmAtCuvHjSTjtgDxexnOAEw@mail.gmail.com>
References: <CAGDMd1p8P-QtPGa908W8zyWCNL4QmAtCuvHjSTjtgDxexnOAEw@mail.gmail.com>
Message-ID: <CAGDMd1qs6Dn199YrWJX+LU6HiAvfhsu+zxfMux_JwMhmPtdciw@mail.gmail.com>

My omnios install is in esxi. I increased the 20gig drive to 40gig in esxi
but the rpool is still at 20gig.

Is there any way to expand the rpool to use the extra 20gb I added to the
virtual drive
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130525/088b466f/attachment.html>

From ales.jagric at forum-racunalnistva.eu  Mon May 27 05:02:15 2013
From: ales.jagric at forum-racunalnistva.eu (=?iso-8859-2?Q?Ale=B9_Jagri=E8=2C_Fora_d=2Eo=2Eo=2E?=)
Date: Mon, 27 May 2013 11:02:15 +0200
Subject: [OmniOS-discuss] OmniOS and i350 addin cards
Message-ID: <28B6AD1E823631489A2CAF747DB9D60A010733031457@exchange>

Hey guys,

I'm playing around with a new server and two of the NICS (one dual port and one quad) are using the i350 intel chipset.

This is where things get strange, I can see the onboard cards

prtconf -D | grep pci15d9,1521
            pci15d9,1521, instance #0 (driver name: igb)
            pci15d9,1521, instance #1 (driver name: igb)

dladm show-phys
LINK         MEDIA                STATE      SPEED  DUPLEX    DEVICE
igb0         Ethernet             up         1000   full      igb0
igb1         Ethernet             up         1000   full      igb1

lspci | grep -i ethernet
02:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
02:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

But the two addin cards are nowhere to be seen.

This is a supermicro server with one intel xeon E5-2609 and X9DR6-F motherboard.

Any pointers?


________________________________
This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. E-mail message is scanned by Anti-Virus Software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130527/d2164daf/attachment.html>

From ales.jagric at forum-racunalnistva.eu  Mon May 27 13:13:18 2013
From: ales.jagric at forum-racunalnistva.eu (=?iso-8859-2?Q?Ale=B9_Jagri=E8=2C_Fora_d=2Eo=2Eo=2E?=)
Date: Mon, 27 May 2013 19:13:18 +0200
Subject: [OmniOS-discuss] Supermicro X9DR6-F and intel i350 addin NICs
In-Reply-To: <519E8329.3040002@forum-racunalnistva.eu>
References: <28B6AD1E823631489A2CAF747DB9D60A010733031434@exchange>
	<1912E3F0-D1E2-44A5-937C-7889D69999B4@omniti.com>
	<28B6AD1E823631489A2CAF747DB9D60A010733031436@exchange>
	<CA+QY2RThM8aoi=sQhqfy3FpT1YswL=3_=U=NhzWVqVF==M7OXQ@mail.gmail.com>
	<28B6AD1E823631489A2CAF747DB9D60A0107331F92E2@exchange>
	<CA+QY2RTJcKiUgR10kkWbeRz+MVd-yqBTEnyNnBUm_eqehdHQQg@mail.gmail.com>,
	<519E8329.3040002@forum-racunalnistva.eu>
Message-ID: <28B6AD1E823631489A2CAF747DB9D60A0107331F92E6@exchange>

Hey guys,

I'm playing around with a new server and two of the NICS (one dual port and one quad) are using the i350 intel chipset.

This is where things get strange, I can see the onboard cards

prtconf -D | grep pci15d9,1521

            pci15d9,1521, instance #0 (driver name: igb)

            pci15d9,1521, instance #1 (driver name: igb)


dladm show-phys
LINK         MEDIA                STATE      SPEED  DUPLEX    DEVICE
igb0         Ethernet             up         1000   full      igb0
igb1         Ethernet             up         1000   full      igb1

lspci | grep -i ethernet
02:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
02:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

But the two addin cards are nowhere to be seen.

This is a supermicro server with one intel xeon E5-2609 and X9DR6-F motherboard.

Any pointers?

-------
Had to resend the message, my client ate the previous one ;)

This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. E-mail message is scanned by Anti-Virus Software.

From esproul at omniti.com  Tue May 28 09:52:12 2013
From: esproul at omniti.com (Eric Sproul)
Date: Tue, 28 May 2013 09:52:12 -0400
Subject: [OmniOS-discuss] rpool is almost full, how to expand?
In-Reply-To: <CAGDMd1qs6Dn199YrWJX+LU6HiAvfhsu+zxfMux_JwMhmPtdciw@mail.gmail.com>
References: <CAGDMd1p8P-QtPGa908W8zyWCNL4QmAtCuvHjSTjtgDxexnOAEw@mail.gmail.com>
	<CAGDMd1qs6Dn199YrWJX+LU6HiAvfhsu+zxfMux_JwMhmPtdciw@mail.gmail.com>
Message-ID: <CA+QY2RQMO9F9OOUvQZvgjvS7=GE=Z-z9mhNm8mJE0Gv79UqCXw@mail.gmail.com>

Travis,
See the "autoexpand" property in zpool(1M).  It defaults to off, so
turning it on should get you what you want.

Eric

On Sat, May 25, 2013 at 12:15 PM, Travis Lawrie <tlawrie.it at gmail.com> wrote:
> My omnios install is in esxi. I increased the 20gig drive to 40gig in esxi
> but the rpool is still at 20gig.
>
> Is there any way to expand the rpool to use the extra 20gb I added to the
> virtual drive
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From geoffn at gnaa.net  Tue May 28 11:57:30 2013
From: geoffn at gnaa.net (Geoff Nordli)
Date: Tue, 28 May 2013 08:57:30 -0700
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
In-Reply-To: <51A44D53.4020604@gnaa.net>
References: <51A44D53.4020604@gnaa.net>
Message-ID: <51A4D3EA.70703@gnaa.net>

On 13-05-27 11:23 PM, Geoff Nordli wrote:
> Anyone have any success installing vbox on omnios?
>
> I just did the install and it says it is partially installed.
>
> I know there were some errors because it tries to use the netbow 
> (crossbow) network driver instead of the streams based one.
>
> I am sure there are some other reasons it doesn't work as well.
>

I should have known this, you have to force the streams driver 
installation using:  touch /etc/vboxinst_vboxflt

As well, since OmniOS doesn't include X11, the VirtualBox GUI interface 
doesn't work, but I don't really care about the gui.

The last thing is an error with zoneaccess, but vbox still installs 
properly.

svcadm: svc:/system/svc/restarter:default is misconfigured (lacks 
"restarter" property group).
svcadm: Instance "svc:/application/virtualbox/zoneaccess:default" has 
unsatisfied dependencies.
    * Warning!! Loading Zone access service  ...FAILED.
    * Warning!! Refer 
/var/svc/log/application-virtualbox-zoneaccess:default.log for details.


Geoff









From jared at basho.com  Tue May 28 12:57:11 2013
From: jared at basho.com (Jared Morrow)
Date: Tue, 28 May 2013 10:57:11 -0600
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
In-Reply-To: <51A4D3EA.70703@gnaa.net>
References: <51A44D53.4020604@gnaa.net>
	<51A4D3EA.70703@gnaa.net>
Message-ID: <CACUSOvc75bvSEcTUGGt+68h56gPBVwYq3g8C-te6U9PLhqTbGw@mail.gmail.com>

Have you considered using kvm instead of vbox?  Joyent ported kvm to
illumos and use it for their hosting so I'm willing to be it has been
tested far more than vbox on illumos.  I personally use kvm on both SmartOS
and OmniOS.

-Jared


On Tue, May 28, 2013 at 9:57 AM, Geoff Nordli <geoffn at gnaa.net> wrote:

> On 13-05-27 11:23 PM, Geoff Nordli wrote:
>
>> Anyone have any success installing vbox on omnios?
>>
>> I just did the install and it says it is partially installed.
>>
>> I know there were some errors because it tries to use the netbow
>> (crossbow) network driver instead of the streams based one.
>>
>> I am sure there are some other reasons it doesn't work as well.
>>
>>
> I should have known this, you have to force the streams driver
> installation using:  touch /etc/vboxinst_vboxflt
>
> As well, since OmniOS doesn't include X11, the VirtualBox GUI interface
> doesn't work, but I don't really care about the gui.
>
> The last thing is an error with zoneaccess, but vbox still installs
> properly.
>
> svcadm: svc:/system/svc/restarter:**default is misconfigured (lacks
> "restarter" property group).
> svcadm: Instance "svc:/application/virtualbox/**zoneaccess:default" has
> unsatisfied dependencies.
>    * Warning!! Loading Zone access service  ...FAILED.
>    * Warning!! Refer /var/svc/log/application-**
> virtualbox-zoneaccess:default.**log for details.
>
>
> Geoff
>
>
>
>
>
>
>
>
> ______________________________**_________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.**com <OmniOS-discuss at lists.omniti.com>
> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss<http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130528/2f7ab980/attachment.html>

From geoffn at gnaa.net  Tue May 28 14:34:32 2013
From: geoffn at gnaa.net (Geoff Nordli)
Date: Tue, 28 May 2013 11:34:32 -0700
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
In-Reply-To: <CACUSOvc75bvSEcTUGGt+68h56gPBVwYq3g8C-te6U9PLhqTbGw@mail.gmail.com>
References: <51A44D53.4020604@gnaa.net> <51A4D3EA.70703@gnaa.net>
	<CACUSOvc75bvSEcTUGGt+68h56gPBVwYq3g8C-te6U9PLhqTbGw@mail.gmail.com>
Message-ID: <51A4F8B8.5030606@gnaa.net>

On 13-05-28 09:57 AM, Jared Morrow wrote:
> Have you considered using kvm instead of vbox?  Joyent ported kvm to 
> illumos and use it for their hosting so I'm willing to be it has been 
> tested far more than vbox on illumos.  I personally use kvm on both 
> SmartOS and OmniOS.
>
> -Jared

Hi Jared.

I have been using vbox on OpenIndiana and it has been working pretty well.

What are you using to auto manage the startup/shutdown of KVM 
instances.  I use
http://sourceforge.net/projects/vboxsvc/ with vbox.

Out of curiosity, are you using any Linux VMs in KVM that has high disk 
IO/network throughput?  All my vbox instances are low usage, but I have 
been thinking about virtualizing a GlusterFS, because there is no good 
DFS option on illumos today.

Geoff



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130528/9fce214e/attachment.html>

From jared at basho.com  Tue May 28 14:45:04 2013
From: jared at basho.com (Jared Morrow)
Date: Tue, 28 May 2013 12:45:04 -0600
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
In-Reply-To: <51A4F8B8.5030606@gnaa.net>
References: <51A44D53.4020604@gnaa.net> <51A4D3EA.70703@gnaa.net>
	<CACUSOvc75bvSEcTUGGt+68h56gPBVwYq3g8C-te6U9PLhqTbGw@mail.gmail.com>
	<51A4F8B8.5030606@gnaa.net>
Message-ID: <CACUSOvfCA0=Sv1mijo6Ri1b-YAkb01rop2hmaGNS2boPRwWDYQ@mail.gmail.com>

>
> What are you using to auto manage the startup/shutdown of KVM instances.
> I use
> http://sourceforge.net/projects/vboxsvc/ with vbox.


In SmartOS I use their vmadm tool, and on OmniOS I just started it up by
hand and haven't shut it down since.  There is a project that came up on
this list to replicate vmadm on OmniOS, but the name escapes me right now.

Regarding high performance, I do some testing of Riak (our distributed data
store) on SmartOS->KVM->Linux and as long as I use the virtio driver I get
pretty decent performance.  For reference, FreeBSD and Centos5 need a
little bit of work to get virtio to work, but it isn't that hard.

-Jared




On Tue, May 28, 2013 at 12:34 PM, Geoff Nordli <geoffn at gnaa.net> wrote:

>  On 13-05-28 09:57 AM, Jared Morrow wrote:
>
> Have you considered using kvm instead of vbox?  Joyent ported kvm to
> illumos and use it for their hosting so I'm willing to be it has been
> tested far more than vbox on illumos.  I personally use kvm on both SmartOS
> and OmniOS.
>
>  -Jared
>
>
> Hi Jared.
>
> I have been using vbox on OpenIndiana and it has been working pretty
> well.
>
> What are you using to auto manage the startup/shutdown of KVM instances.
> I use
> http://sourceforge.net/projects/vboxsvc/ with vbox.
>
> Out of curiosity, are you using any Linux VMs in KVM that has high disk
> IO/network throughput?  All my vbox instances are low usage, but I have
> been thinking about virtualizing a GlusterFS, because there is no good DFS
> option on illumos today.
>
> Geoff
>
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130528/a7570c71/attachment.html>

From geoffn at gnaa.net  Tue May 28 15:01:05 2013
From: geoffn at gnaa.net (Geoff Nordli)
Date: Tue, 28 May 2013 12:01:05 -0700
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
In-Reply-To: <CACUSOvfCA0=Sv1mijo6Ri1b-YAkb01rop2hmaGNS2boPRwWDYQ@mail.gmail.com>
References: <51A44D53.4020604@gnaa.net> <51A4D3EA.70703@gnaa.net>
	<CACUSOvc75bvSEcTUGGt+68h56gPBVwYq3g8C-te6U9PLhqTbGw@mail.gmail.com>
	<51A4F8B8.5030606@gnaa.net>
	<CACUSOvfCA0=Sv1mijo6Ri1b-YAkb01rop2hmaGNS2boPRwWDYQ@mail.gmail.com>
Message-ID: <51A4FEF1.4030009@gnaa.net>

On 13-05-28 11:45 AM, Jared Morrow wrote:
>
>     What are you using to auto manage the startup/shutdown of KVM
>     instances.  I use
>     http://sourceforge.net/projects/vboxsvc/ with vbox. 
>
>
> In SmartOS I use their vmadm tool, and on OmniOS I just started it up 
> by hand and haven't shut it down since.  There is a project that came 
> up on this list to replicate vmadm on OmniOS, but the name escapes me 
> right now.
>
> Regarding high performance, I do some testing of Riak (our distributed 
> data store) on SmartOS->KVM->Linux and as long as I use the virtio 
> driver I get pretty decent performance.  For reference, FreeBSD and 
> Centos5 need a little bit of work to get virtio to work, but it isn't 
> that hard.
>

That sounds encouraging.  Can you ballpark the performance numbers you 
are seeing ?

thanks,

Geoff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130528/df7cc199/attachment.html>

From jared at basho.com  Tue May 28 15:19:25 2013
From: jared at basho.com (Jared Morrow)
Date: Tue, 28 May 2013 13:19:25 -0600
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
In-Reply-To: <51A4FEF1.4030009@gnaa.net>
References: <51A44D53.4020604@gnaa.net> <51A4D3EA.70703@gnaa.net>
	<CACUSOvc75bvSEcTUGGt+68h56gPBVwYq3g8C-te6U9PLhqTbGw@mail.gmail.com>
	<51A4F8B8.5030606@gnaa.net>
	<CACUSOvfCA0=Sv1mijo6Ri1b-YAkb01rop2hmaGNS2boPRwWDYQ@mail.gmail.com>
	<51A4FEF1.4030009@gnaa.net>
Message-ID: <CACUSOvdJERpF5OmSiP7awqDooNmgzeVFUzZYh2weDF6=3jJG7w@mail.gmail.com>

The only performance numbers I really have lying around are from when I
changed over a centos 5 VM to the virtio driver. I just did a simple bonnie
test with a 2gb file and limited it to use 1gb of ram (on two cpu's). I
don't have numbers offhand for some other uses.

Here are the bonnie numbers from Centos 5 before virtio and after (and
centos 5 is fairly slow anyway, so your results may vary).
Before

[buildbot at riak-test-centos-5 ~]$ /usr/sbin/bonnie++ -d fstest/ -r 1000 -s 2000
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
riak-test-cen 2000M 24003  30 22200   3 10379   1 67092  15 3253044
99 159.1   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 18542  32 +++++ +++ +++++ +++ 21890   2 +++++ +++ +++++ +++
riak-test-centos-5,2000M,24003,30,22200,3,10379,1,67092,15,3253044,99,159.1,0,16,18542,32,+++++,+++,+++++,+++,21890,2,+++++,+++,+++++,+++

After

[buildbot at riak-test-centos-5 ~]$ /usr/sbin/bonnie++ -d fstest/ -r 1000 -s 2000
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
riak-test-cen 2000M 33582  64 66872   8 24244   3 75227  24 3723163
99 546.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 15421  26 +++++ +++ +++++ +++ 18583  55 +++++ +++ +++++ +++
riak-test-centos-5,2000M,33582,64,66872,8,24244,3,75227,24,3723163,99,546.8,0,16,15421,26,+++++,+++,+++++,+++,18583,55,+++++,+++,+++++,+++

As you can see, the change was quite dramatic.


Hope that helps at all,

-Jared


On Tue, May 28, 2013 at 1:01 PM, Geoff Nordli <geoffn at gnaa.net> wrote:

>  On 13-05-28 11:45 AM, Jared Morrow wrote:
>
>  What are you using to auto manage the startup/shutdown of KVM
>> instances.  I use
>> http://sourceforge.net/projects/vboxsvc/ with vbox.
>
>
>  In SmartOS I use their vmadm tool, and on OmniOS I just started it up by
> hand and haven't shut it down since.  There is a project that came up on
> this list to replicate vmadm on OmniOS, but the name escapes me right now.
>
>  Regarding high performance, I do some testing of Riak (our distributed
> data store) on SmartOS->KVM->Linux and as long as I use the virtio driver I
> get pretty decent performance.  For reference, FreeBSD and Centos5 need a
> little bit of work to get virtio to work, but it isn't that hard.
>
>
> That sounds encouraging.  Can you ballpark the performance numbers you are
> seeing ?
>
> thanks,
>
> Geoff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130528/828094f7/attachment-0001.html>

From daleg at omniti.com  Tue May 28 15:20:10 2013
From: daleg at omniti.com (Dale Ghent)
Date: Tue, 28 May 2013 15:20:10 -0400
Subject: [OmniOS-discuss] OmniOS r151006 AMIs now available on EC2
Message-ID: <94016A06-5BA0-46D1-9C34-097ECEA4C581@omniti.com>


I'm pleased to announce that Amazon EC2 AMIs of r151006 (generated from 151006c) are now available for public use in all EC2 regions!

These AMis include an updated GRUB which fully supports 006's inclusion of LZ4 compression in ZFS.

The r151006 AMI IDs are listed here:
http://omnios.omniti.com/wiki.php/Installation#IntheCloud

Note: The OmniOS AMI community page on AWS still mentions 004, however. A new page listing the 006 AMIs will be put up whenever Amazon gets around to approving the new page text, which could take some time given past experiences.

Special thanks goes to Andrzej Szeszo for his continued help by maintaining a pv-grub which keeps up with ZFS features. 

/dale

From geoffn at gnaa.net  Tue May 28 16:13:45 2013
From: geoffn at gnaa.net (Geoff Nordli)
Date: Tue, 28 May 2013 13:13:45 -0700
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
In-Reply-To: <CACUSOvdJERpF5OmSiP7awqDooNmgzeVFUzZYh2weDF6=3jJG7w@mail.gmail.com>
References: <51A44D53.4020604@gnaa.net> <51A4D3EA.70703@gnaa.net>
	<CACUSOvc75bvSEcTUGGt+68h56gPBVwYq3g8C-te6U9PLhqTbGw@mail.gmail.com>
	<51A4F8B8.5030606@gnaa.net>
	<CACUSOvfCA0=Sv1mijo6Ri1b-YAkb01rop2hmaGNS2boPRwWDYQ@mail.gmail.com>
	<51A4FEF1.4030009@gnaa.net>
	<CACUSOvdJERpF5OmSiP7awqDooNmgzeVFUzZYh2weDF6=3jJG7w@mail.gmail.com>
Message-ID: <51A50FF9.2070901@gnaa.net>

On 13-05-28 12:19 PM, Jared Morrow wrote:
>
> The only performance numbers I really have lying around are from when 
> I changed over a centos 5 VM to the virtio driver. I just did a simple 
> bonnie test with a 2gb file and limited it to use 1gb of ram (on two 
> cpu's). I don't have numbers offhand for some other uses.
>
>
> |[buildbot at riak-test-centos-5 ~]$ /usr/sbin/bonnie++ -d fstest/ -r 1000 -s 2000
> Writing with putc()...done
> Writing intelligently...done
> Rewriting...done
> Reading with getc()...done
> Reading intelligently...done
> start 'em...done...done...done...
> Create files in sequential order...done.
> Stat files in sequential order...done.
> Delete files in sequential order...done.
> Create files in random order...done.
> Stat files in random order...done.
> Delete files in random order...done.
> Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
>                      -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
> riak-test-cen 2000M 33582  64 66872   8 24244   3 75227  24*3723163*   99 546.8   0
>                      ------Sequential Create------ --------Random Create--------
>                      -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
>                files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>                   16 15421  26 +++++ +++ +++++ +++ 18583  55 +++++ +++ +++++ +++
> riak-test-centos-5,2000M,33582,64,66872,8,24244,3,75227,24,3723163,99,546.8,0,16,15421,26,+++++,+++,+++++,+++,18583,55,+++++,+++,+++++,+++|
>
> As you can see, the change was quite dramatic.
>

The 3,723,163 for reading is pretty good. It must be pulling that out of 
the ARC from the host machine.

Any ideas on network throughput?

thanks,

Geoff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130528/98bd1991/attachment.html>

From jared at basho.com  Tue May 28 16:26:03 2013
From: jared at basho.com (Jared Morrow)
Date: Tue, 28 May 2013 14:26:03 -0600
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
In-Reply-To: <51A50FF9.2070901@gnaa.net>
References: <51A44D53.4020604@gnaa.net> <51A4D3EA.70703@gnaa.net>
	<CACUSOvc75bvSEcTUGGt+68h56gPBVwYq3g8C-te6U9PLhqTbGw@mail.gmail.com>
	<51A4F8B8.5030606@gnaa.net>
	<CACUSOvfCA0=Sv1mijo6Ri1b-YAkb01rop2hmaGNS2boPRwWDYQ@mail.gmail.com>
	<51A4FEF1.4030009@gnaa.net>
	<CACUSOvdJERpF5OmSiP7awqDooNmgzeVFUzZYh2weDF6=3jJG7w@mail.gmail.com>
	<51A50FF9.2070901@gnaa.net>
Message-ID: <CACUSOvcucLwEMp+Ri5PxVfbDr2vb3bonazqydhV2rUSeh2-9Kg@mail.gmail.com>

Again, this is what I just have laying around with no tuning.  Again
switching from the terrible KVM e1000 driver to the KVM virtio driver with
FreeBSD as the guest.


   - Network Test
      - Test used: simple scp from machine on same rack
         - Old (e1000) = ubuntu-12.04.1-server-amd64.iso        100%
         657MB   6.4MB/s   01:42
         - New (virtio) = ubuntu-12.04.1-server-amd64.iso        100%
         657MB  34.6MB/s   00:19

I'm willing to bet someone has more extensive testing than me.  This was
just a stupid simple test I did to see if the change made a difference.
 For my general use in testing Riak I found that network/fs is way way
faster on illumos KVM than AWS even when untuned.  Also it is not so much
slower than the global zone that it affects general performance.  If I was
making a cluster dedicated to just writing files fast, then I'd personally
go with OmniOS or SmartOS directly, but if you have other linux needs
anyway, it is reasonable in my view.  Theo or Eric might have more
insightful answer since their job is run stuff like this in production.

FWIW, I used to run all this stuff on virtualbox and had so so so many
problems I couldn't take it anymore.

-Jared


On Tue, May 28, 2013 at 2:13 PM, Geoff Nordli <geoffn at gnaa.net> wrote:

>  On 13-05-28 12:19 PM, Jared Morrow wrote:
>
>  The only performance numbers I really have lying around are from when I
> changed over a centos 5 VM to the virtio driver. I just did a simple bonnie
> test with a 2gb file and limited it to use 1gb of ram (on two cpu's). I
> don't have numbers offhand for some other uses.
>
> [buildbot at riak-test-centos-5 ~]$ /usr/sbin/bonnie++ -d fstest/ -r 1000 -s 2000
> Writing with putc()...done
> Writing intelligently...done
> Rewriting...done
> Reading with getc()...done
> Reading intelligently...done
> start 'em...done...done...done...
> Create files in sequential order...done.
> Stat files in sequential order...done.
> Delete files in sequential order...done.
> Create files in random order...done.
> Stat files in random order...done.
> Delete files in random order...done.
> Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
>                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
> riak-test-cen 2000M 33582  64 66872   8 24244   3 75227  24 *3723163*  99 546.8   0
>                     ------Sequential Create------ --------Random Create--------
>                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
>               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>                  16 15421  26 +++++ +++ +++++ +++ 18583  55 +++++ +++ +++++ +++
> riak-test-centos-5,2000M,33582,64,66872,8,24244,3,75227,24,3723163,99,546.8,0,16,15421,26,+++++,+++,+++++,+++,18583,55,+++++,+++,+++++,+++
>
> As you can see, the change was quite dramatic.
>
>
> The 3,723,163 for reading is pretty good. It must be pulling that out of
> the ARC from the host machine.
>
> Any ideas on network throughput?
>
> thanks,
>
> Geoff
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130528/5f418ad9/attachment.html>

From geoffn at gnaa.net  Tue May 28 16:40:58 2013
From: geoffn at gnaa.net (Geoff Nordli)
Date: Tue, 28 May 2013 13:40:58 -0700
Subject: [OmniOS-discuss] virtualbox installed on omnios latest stable
In-Reply-To: <CACUSOvcucLwEMp+Ri5PxVfbDr2vb3bonazqydhV2rUSeh2-9Kg@mail.gmail.com>
References: <51A44D53.4020604@gnaa.net> <51A4D3EA.70703@gnaa.net>
	<CACUSOvc75bvSEcTUGGt+68h56gPBVwYq3g8C-te6U9PLhqTbGw@mail.gmail.com>
	<51A4F8B8.5030606@gnaa.net>
	<CACUSOvfCA0=Sv1mijo6Ri1b-YAkb01rop2hmaGNS2boPRwWDYQ@mail.gmail.com>
	<51A4FEF1.4030009@gnaa.net>
	<CACUSOvdJERpF5OmSiP7awqDooNmgzeVFUzZYh2weDF6=3jJG7w@mail.gmail.com>
	<51A50FF9.2070901@gnaa.net>
	<CACUSOvcucLwEMp+Ri5PxVfbDr2vb3bonazqydhV2rUSeh2-9Kg@mail.gmail.com>
Message-ID: <51A5165A.2080703@gnaa.net>

On 13-05-28 01:26 PM, Jared Morrow wrote:
> Again, this is what I just have laying around with no tuning.  Again 
> switching from the terrible KVM e1000 driver to the KVM virtio driver 
> with FreeBSD as the guest.
>
>   * Network Test
>       o Test used: simple scp from machine on same rack
>           + Old (e1000) = ubuntu-12.04.1-server-amd64.iso        100% 
>             657MB 6.4MB/s   01:42
>           + New (virtio) = ubuntu-12.04.1-server-amd64.iso       
>             100%  657MB 34.6MB/s   00:19
>
> I'm willing to bet someone has more extensive testing than me.  This 
> was just a stupid simple test I did to see if the change made a 
> difference.  For my general use in testing Riak I found that 
> network/fs is way way faster on illumos KVM than AWS even when 
> untuned.  Also it is not so much slower than the global zone that it 
> affects general performance.  If I was making a cluster dedicated to 
> just writing files fast, then I'd personally go with OmniOS or SmartOS 
> directly, but if you have other linux needs anyway, it is reasonable 
> in my view.  Theo or Eric might have more insightful answer since 
> their job is run stuff like this in production.
>
> FWIW, I used to run all this stuff on virtualbox and had so so so many 
> problems I couldn't take it anymore.
>
>

Thanks for sharing, it is fun to see what people are getting on their 
different setups.

Hopefully more people will post some performance numbers they are 
getting with KVM+Linux guest.

Have a great day!!

Geoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130528/2bfa20e4/attachment-0001.html>

From henson at acm.org  Wed May 29 19:11:28 2013
From: henson at acm.org (Paul B. Henson)
Date: Wed, 29 May 2013 16:11:28 -0700
Subject: [OmniOS-discuss] zpool/zfs settings optimization
Message-ID: <51A68B20.2070500@acm.org>

I'm getting down to the wire on the home storage server I've been 
working on building for altogether too long. Right now I'm trying to 
finalize the zpool/zfs settings I'm going to create the rpool and bulk 
storage pool with.

The rpool is going to be a mirror of the first partitions of two 256G 
SSDs (I haven't decided how big to make that, it looks like a default 
install of omnios takes up less than 1G, and I don't anticipate 
installing that much more at the OS level).

The storage pool is going to made up of 2 x 6 RAIDZ2 WD Red 3TB drives, 
with a partition of an Intel DC 3700 as log, and the remaining two 
partitions of the rpool SSDs as l2arc.

There's going to be a wide variety of stuff stored on the storage pool, 
from mp3/flac/aac music, to DVD/bluray rips, and basic home directory 
stuff like documents and pictures. A big chunk will be dedicated to my 
mythtv system and contain OTA ATSC mpeg2 transport streams.

For the rpool I plan to enable lz4 compression for the entire pool. For 
the storage pool I will probably disable it for filesystems containing 
mostly noncompressible stuff and enable it for home directory like 
filesystems containing documents and other things more likely to be 
compressible. I think I'm going to set atime=off globally on both pools, 
I can't think of any reason that data would be worth the extra write load.

While I'm going to leave it the default for rpool, I'm thinking I'm 
going to set failmode=continue on the storage pool.

If I understood correctly, there's really no value in changing the 
default recordsize unless you're using an application like a database 
that you know always reads in chunk sizes smaller and reading in the 
entire record would be a waste. I thought I remembered reading somewhere 
that one of the zfs forks had increased the maximum recordsize to 
something bigger, like 2M or 10M or something, but I can't seem to find 
a reference to it now. For filesystems which store only large files (OTA 
HD recordings are generally multi-gigabyte) it seems that would be more 
efficient. Is anybody looking at increasing the maximum record size in 
illumos zfs?

While I understand what the primarycache and secondarycache attributes 
control, I'm not really clear on when it might be desirable to change 
them. Are there any routine scenarios where you might want to configure 
them other than the default, or is that just limited to specific 
deployments such as databases where you want to avoid double buffering 
of data in memory?

I was planning on making the storage available to my mythv server over 
NFS. I was thinking about setting logbias=throughput for that file 
system, as intuitively that would seem a better tuning for multiple 
streams being written at once. Or, I could possibly set sync=disabled on 
that file system to completely avoid the overhead of NFS synchronous 
writes. If there's a failure during a recording and I lose five minutes 
of the end, oh well?

Moving on to kernel tunables, I was thinking of enabling l2arc 
prefetching (l2arc_noprefetch=0). I'm also thinking of increasing 
l2arc_write_max to better avail of more modern SSDs, but I'm not sure to 
what. At some point will the default zfs kernel tunables be updated to 
match currently available devices rather than the more limited flash 
devices of yesteryear?

Any thoughts on these mentioned settings/tunables, or recommendations of 
other things I might want to do?

Thanks much?

From radiomlodychbandytow at o2.pl  Thu May 30 16:51:41 2013
From: radiomlodychbandytow at o2.pl (=?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?=)
Date: Thu, 30 May 2013 22:51:41 +0200
Subject: [OmniOS-discuss] [zfs] zpool/zfs settings optimization
In-Reply-To: <51A68B20.2070500@acm.org>
References: <51A68B20.2070500@acm.org>
Message-ID: <51A7BBDD.5060901@o2.pl>

On 30/05/2013 01:11, Paul B. Henson wrote:
> There's going to be a wide variety of stuff stored on the storage pool,
> from mp3/flac/aac music, to DVD/bluray rips, and basic home directory
> stuff like documents and pictures. A big chunk will be dedicated to my
> mythtv system and contain OTA ATSC mpeg2 transport streams.
> 
> For the rpool I plan to enable lz4 compression for the entire pool. For
> the storage pool I will probably disable it for filesystems containing
> mostly noncompressible stuff and enable it for home directory like
> filesystems containing documents and other things more likely to be
> compressible. I think I'm going to set atime=off globally on both pools,
> I can't think of any reason that data would be worth the extra write load.

LZ4 runs GBytes/s/core on incompressible data, so it doesn't matter much
if you leave it or disable it. Sure, if you know it won't help, better
turn it off, but in case of doubt you can just have it running.

> If I understood correctly, there's really no value in changing the
> default recordsize unless you're using an application like a database
> that you know always reads in chunk sizes smaller and reading in the
> entire record would be a waste. I thought I remembered reading somewhere
> that one of the zfs forks had increased the maximum recordsize to
> something bigger, like 2M or 10M or something, but I can't seem to find
> a reference to it now.
Oracle added 1 MB blocks in zpool r32. Maybe there's something else, but
I haven't heard of it.
-- 
Twoje radio

From henson at acm.org  Thu May 30 20:56:37 2013
From: henson at acm.org (Paul B. Henson)
Date: Thu, 30 May 2013 17:56:37 -0700
Subject: [OmniOS-discuss] [zfs] zpool/zfs settings optimization
In-Reply-To: <51A7BBDD.5060901@o2.pl>
References: <51A68B20.2070500@acm.org> <51A7BBDD.5060901@o2.pl>
Message-ID: <51A7F545.1020903@acm.org>

On 5/30/2013 1:51 PM, Radio m?odych bandyt?w wrote:

> LZ4 runs GBytes/s/core on incompressible data, so it doesn't matter much
> if you leave it or disable it. Sure, if you know it won't help, better
> turn it off, but in case of doubt you can just have it running.

I'm not sure how well it would do on mpeg2 data, I guess I could leave 
it on for a while and see what the compress ratio is and go from there.

> Oracle added 1 MB blocks in zpool r32. Maybe there's something else, but
> I haven't heard of it.

Maybe I'm thinking of a discussion I saw from the FreeBSD or Linux forks 
rather than an actual implementation?

From jimklimov at cos.ru  Fri May 31 05:11:49 2013
From: jimklimov at cos.ru (Jim Klimov)
Date: Fri, 31 May 2013 11:11:49 +0200
Subject: [OmniOS-discuss] [zfs] zpool/zfs settings optimization
In-Reply-To: <51A7F545.1020903@acm.org>
References: <51A68B20.2070500@acm.org> <51A7BBDD.5060901@o2.pl>
	<51A7F545.1020903@acm.org>
Message-ID: <51A86955.5090507@cos.ru>

On 2013-05-31 02:56, Paul B. Henson wrote:
> On 5/30/2013 1:51 PM, Radio m?odych bandyt?w wrote:
>> Oracle added 1 MB blocks in zpool r32. Maybe there's something else, but
>> I haven't heard of it.
>
> Maybe I'm thinking of a discussion I saw from the FreeBSD or Linux forks
> rather than an actual implementation?

No, indeed there was a discussion in illumos community as well;
I believe Saso Kiselkov was working on such extension. I am not
sure if it was completed or integrated, however, given that he
now has many harder and somewhat higher-priority quests.

//Jim


From henson at acm.org  Fri May 31 15:38:07 2013
From: henson at acm.org (Paul B. Henson)
Date: Fri, 31 May 2013 12:38:07 -0700
Subject: [OmniOS-discuss] [zfs] zpool/zfs settings optimization
In-Reply-To: <51A86955.5090507@cos.ru>
References: <51A68B20.2070500@acm.org> <51A7BBDD.5060901@o2.pl>
	<51A7F545.1020903@acm.org> <51A86955.5090507@cos.ru>
Message-ID: <51A8FC1F.8020901@acm.org>

On 5/31/2013 2:11 AM, Jim Klimov wrote:

> No, indeed there was a discussion in illumos community as well;
> I believe Saso Kiselkov was working on such extension. I am not
> sure if it was completed or integrated, however, given that he
> now has many harder and somewhat higher-priority quests.

Ah, yes, I found it now:

http://comments.gmane.org/gmane.os.illumos.devel/11004

Hopefully one day Saso will get back to it, and it will be yet another 
cool feature he has contributed :) (Thanks Saso!).


From omnios at citrus-it.net  Fri May 31 16:00:52 2013
From: omnios at citrus-it.net (Andy)
Date: Fri, 31 May 2013 20:00:52 +0000 (GMT)
Subject: [OmniOS-discuss] Small bug in Kayak.
Message-ID: <alpine.GSO.2.00.1305311958430.18437@areb.pvgehf-vg.arg>


There's a small bug in the Ether routine in Kayak. If a MAC address has
two characters the same within an octet then it calculates the wrong
address. I just happen to be building a server with a MAC address like
that.

root at lime:/usr/share/kayak# ifconfig bnx0 | grep ether
        ether d4:ae:52:c9:f1:dd
root at lime:/usr/share/kayak# . net_help.sh
root at lime:/usr/share/kayak# Ether
D4AE52C9F10D

Fix:

31c31
<     /bin/tr -s '[:lower:]' '[:upper:]' | \
---
>     /bin/tr '[:lower:]' '[:upper:]' | \

Andy

-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


