From piers at mm.st Mon Dec 2 09:14:47 2013 From: piers at mm.st (Piers Dawson-Damer) Date: Mon, 2 Dec 2013 20:14:47 +1100 Subject: [OmniOS-discuss] Re-installing OmniOS after Crash In-Reply-To: References: Message-ID: <30CAB6F2-B6AF-4EC8-8263-35EF0A885FBD@mm.st> Any update on this error? I also cannot update my system. Have tried removing the OmniTi repositories Piers SunOS prod 5.11 omnios-ef9657e i86pc i386 i86pc piers at prod:~$ pfexec pkg update -v Creating Plan / pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority The package involved is:pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151007:20130926T213513Z On 27 Oct 2013, at 11:04 pm, Sam M wrote: > Hello all. > > After installing napp-it, OmniOS got hosed. Not sure what caused it, probably not napp-it, because I couldn't boot up my system with any of the boot images, including the original. > > Now, on a brand new installation, I'm getting the following error - > > # pkg update web/ca-bundle pkg > Creating Plan - > pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority > The package involved is:pkg://omnios/library/python-2/pybonjour at 1.1.1,5.11-0.151007:20130516T114553Z > > # uname -a > SunOS sequoia 5.11 omnios-df542ea i86pc i386 i86pc Solaris > > There were no errors earlier after the installation when updating packages. > > How can I fix this? Where can I find OmniTI's CA certificate? > > TIA. > > Sam > > > > _______________________________________________ > 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: From piers at mm.st Mon Dec 2 09:26:34 2013 From: piers at mm.st (Piers Dawson-Damer) Date: Mon, 2 Dec 2013 20:26:34 +1100 Subject: [OmniOS-discuss] Re-installing OmniOS after Crash In-Reply-To: References: Message-ID: Any update on this error? I also cannot update my system. Have tried removing the OmniTi repositories Piers SunOS prod 5.11 omnios-ef9657e i86pc i386 i86pc piers at prod:~$ pfexec pkg update -v Creating Plan / pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority The package involved is:pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151007:20130926T213513Z On 27 Oct 2013, at 11:04 pm, Sam M wrote: > Hello all. > > After installing napp-it, OmniOS got hosed. Not sure what caused it, probably not napp-it, because I couldn't boot up my system with any of the boot images, including the original. > > Now, on a brand new installation, I'm getting the following error - > > # pkg update web/ca-bundle pkg > Creating Plan - > pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority > The package involved is:pkg://omnios/library/python-2/pybonjour at 1.1.1,5.11-0.151007:20130516T114553Z > > # uname -a > SunOS sequoia 5.11 omnios-df542ea i86pc i386 i86pc Solaris > > There were no errors earlier after the installation when updating packages. > > How can I fix this? Where can I find OmniTI's CA certificate? > > TIA. > > Sam > > > > _______________________________________________ > 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: From rafibeyli at gmail.com Mon Dec 2 12:08:04 2013 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET) Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <135254751.57815.1385985560841.JavaMail.zimbra@cantekstil.com.tr> References: <135254751.57815.1385985560841.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <147167035.58244.1385986084129.JavaMail.zimbra@cantekstil.com.tr> Saso thank you for your fast reply, its ok about two ports(sas dp)I know it, but my question is about ,which disk adresses to use in my zfs mirror or zfs raid config? in my case: c4t500000E1168BB382d0 c4t500000E11693F232d0 c4t500000E11696D5A2d0 c4t500000E116974FB2d0 OR c6t500000E1168BB383d0 c6t500000E11693F233d0 c6t500000E11696D5A3d0 c6t500000E116974FB3d0 If I understand right,when use first adresses I will use 1st controller only,and when use second addresses 2nd controller only? regards Hafiz Message: 6 Date: Sat, 30 Nov 2013 11:26:57 +0000 From: Saso Kiselkov To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <5299CB81.7090101 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 11/30/13, 9:43 AM, Hafiz Rafibeyli wrote: > Hello, > > After adding 4 SAS dual port disks to my omnios system(omnios-b281e50+napp-it) ,I see number of disks 2x acctual quantity. > > I have dual controller backplane(supermicro) and 2 LSI 9211-8i, > > There is no any quantity problem with another disks,only with new added HP 300GB SAS DP. > > > c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 > c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 > c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 > c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 > c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 > c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 Hey Hafiz, What you're seeing are the two ports of the disks. Using "mpathadm list lu" you should be able to determine which SAS addresses correspond to which disks. You can also use something like diskmap.py from https://github.com/swacquie/DiskMap (it requires the sas2ircu utility from LSI). Cheers, -- Saso From skiselkov.ml at gmail.com Mon Dec 2 12:17:04 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 02 Dec 2013 12:17:04 +0000 Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <147167035.58244.1385986084129.JavaMail.zimbra@cantekstil.com.tr> References: <135254751.57815.1385985560841.JavaMail.zimbra@cantekstil.com.tr> <147167035.58244.1385986084129.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <529C7A40.2090300@gmail.com> On 12/2/13, 12:08 PM, Hafiz Rafibeyli wrote: > > Saso thank you for your fast reply, > > its ok about two ports(sas dp)I know it, > > but my question is about ,which disk adresses to use in my zfs mirror or zfs raid config? > > in my case: > > c4t500000E1168BB382d0 > c4t500000E11693F232d0 > c4t500000E11696D5A2d0 > c4t500000E116974FB2d0 > > OR > > c6t500000E1168BB383d0 > c6t500000E11693F233d0 > c6t500000E11696D5A3d0 > c6t500000E116974FB3d0 > > > If I understand right,when use first adresses I will use 1st controller only,and when use second addresses 2nd controller only? You should use neither. The underlying disk paths are automatically managed by the scsi_vhci driver. You need to consult "mpathadm list lu" and use the device names printed there as your ZFS device nodes, for example (using the example from http://docs.oracle.com/cd/E19253-01/820-1931/agkax/index.html): # mpathadm list lu /dev/rdsk/c4t60020F20000035AF4267CCCB0002CEE2d0s2 Total Path Count: 2 Operational Path Count: 2 ... Here, c4t60020F20000035AF4267CCCB0002CEE2d0 is the correct disk node, so you should use that. If you are getting "Total Path Count: 1" and twice the number of nodes in "mpathadm list lu", then scsi_vhci is not detecting your disks as multi-pathed and you need to tell it to do that. See http://docs.oracle.com/cd/E19253-01/820-1931/gfpva/index.html on how to do that. My guess is, however, that this should not be needed, since you're saying you've got two LSI 9211-8i HBAs, which use the mpt_sas driver, which is automatically multipath-enabled. Cheers, -- Saso From rafibeyli at gmail.com Mon Dec 2 14:19:50 2013 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Mon, 2 Dec 2013 16:19:50 +0200 (EET) Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <732695638.64830.1385993337033.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <310264256.65409.1385993990627.JavaMail.zimbra@cantekstil.com.tr> Saso ,I do not see my new added 4 disks in mpathadm list lu query. Here is my output, ~# mpathadm list lu /dev/rdsk/c1t5000C5005600A6B3d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517BB2747BE7d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517959627219d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50055A607E3d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517BB2AFB592d0s2 Total Path Count: 1 Operational Path Count: 1 /dev/rdsk/c1t5000C50041E9D9A7d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C5004253FF87d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50055A62F57d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517803D007D8d0s2 Total Path Count: 1 Operational Path Count: 1 /dev/rdsk/c1t5000C5005600B43Bd0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50041F1A5EFd0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50055A628EFd0s2 Total Path Count: 2 Operational Path Count: 2 These disks are from my 1st zfs pool which is now in production: NAME STATE READ WRITE CKSUM CAP Product zpool1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 c1t5000C50041E9D9A7d0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50041F1A5EFd0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C5004253FF87d0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50055A607E3d0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50055A628EFd0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50055A62F57d0 ONLINE 0 0 0 3 TB ST33000650SS logs mirror-1 ONLINE 0 0 0 c1t5001517959627219d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN c1t5001517BB2747BE7d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN cache c1t5001517803D007D8d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 c1t5001517BB2AFB592d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 spares c1t5000C5005600A6B3d0 AVAIL 3 TB ST33000650SS c1t5000C5005600B43Bd0 AVAIL 3 TB ST33000650SS Is multipath'ing disabled on my system?and after enable multipath'ing will I lose my pool?because disk naming will change? Will zfs import work with new disk naming to get back my zfs pool and data? regards Hafiz. You should use neither. The underlying disk paths are automatically managed by the scsi_vhci driver. You need to consult "mpathadm list lu" and use the device names printed there as your ZFS device nodes, for example (using the example from http://docs.oracle.com/cd/E19253-01/820-1931/agkax/index.html): # mpathadm list lu /dev/rdsk/c4t60020F20000035AF4267CCCB0002CEE2d0s2 Total Path Count: 2 Operational Path Count: 2 ... Here, c4t60020F20000035AF4267CCCB0002CEE2d0 is the correct disk node, so you should use that. If you are getting "Total Path Count: 1" and twice the number of nodes in "mpathadm list lu", then scsi_vhci is not detecting your disks as multi-pathed and you need to tell it to do that. See http://docs.oracle.com/cd/E19253-01/820-1931/gfpva/index.html on how to do that. My guess is, however, that this should not be needed, since you're saying you've got two LSI 9211-8i HBAs, which use the mpt_sas driver, which is automatically multipath-enabled. Cheers, -- Saso From skiselkov.ml at gmail.com Mon Dec 2 14:39:39 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 02 Dec 2013 14:39:39 +0000 Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <310264256.65409.1385993990627.JavaMail.zimbra@cantekstil.com.tr> References: <310264256.65409.1385993990627.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <529C9BAB.9050002@gmail.com> Can you please send me the output of format(1) when it lists the available disks? Cheers, -- Saso On 12/2/13, 2:19 PM, Hafiz Rafibeyli wrote: > Saso ,I do not see my new added 4 disks in mpathadm list lu query. > > Here is my output, > > ~# mpathadm list lu > /dev/rdsk/c1t5000C5005600A6B3d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517BB2747BE7d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517959627219d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50055A607E3d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517BB2AFB592d0s2 > Total Path Count: 1 > Operational Path Count: 1 > /dev/rdsk/c1t5000C50041E9D9A7d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C5004253FF87d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50055A62F57d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517803D007D8d0s2 > Total Path Count: 1 > Operational Path Count: 1 > /dev/rdsk/c1t5000C5005600B43Bd0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50041F1A5EFd0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50055A628EFd0s2 > Total Path Count: 2 > Operational Path Count: 2 > > These disks are from my 1st zfs pool which is now in production: > > > NAME STATE READ WRITE CKSUM CAP Product > zpool1 ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > c1t5000C50041E9D9A7d0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50041F1A5EFd0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C5004253FF87d0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50055A607E3d0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50055A628EFd0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50055A62F57d0 ONLINE 0 0 0 3 TB ST33000650SS > logs > mirror-1 ONLINE 0 0 0 > c1t5001517959627219d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN > c1t5001517BB2747BE7d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN > cache > c1t5001517803D007D8d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 > c1t5001517BB2AFB592d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 > spares > c1t5000C5005600A6B3d0 AVAIL 3 TB ST33000650SS > c1t5000C5005600B43Bd0 AVAIL 3 TB ST33000650SS > > Is multipath'ing disabled on my system?and after enable multipath'ing will I lose my pool?because disk naming will change? > Will zfs import work with new disk naming to get back my zfs pool and data? > > regards > > Hafiz. > > > You should use neither. The underlying disk paths are automatically > managed by the scsi_vhci driver. You need to consult "mpathadm list lu" > and use the device names printed there as your ZFS device nodes, for > example (using the example from > http://docs.oracle.com/cd/E19253-01/820-1931/agkax/index.html): > > # mpathadm list lu > /dev/rdsk/c4t60020F20000035AF4267CCCB0002CEE2d0s2 > Total Path Count: 2 > Operational Path Count: 2 > ... > > Here, c4t60020F20000035AF4267CCCB0002CEE2d0 is the correct disk node, so > you should use that. If you are getting "Total Path Count: 1" and twice > the number of nodes in "mpathadm list lu", then scsi_vhci is not > detecting your disks as multi-pathed and you need to tell it to do that. > See http://docs.oracle.com/cd/E19253-01/820-1931/gfpva/index.html on how > to do that. My guess is, however, that this should not be needed, since > you're saying you've got two LSI 9211-8i HBAs, which use the mpt_sas > driver, which is automatically multipath-enabled. > > Cheers, > From esproul at omniti.com Mon Dec 2 14:53:09 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 2 Dec 2013 09:53:09 -0500 Subject: [OmniOS-discuss] Re-installing OmniOS after Crash In-Reply-To: References: Message-ID: On Mon, Dec 2, 2013 at 4:26 AM, Piers Dawson-Damer wrote: > Any update on this error? This is because we are now signing packages in bloody, in preparation for the next stable release. If you're reasonably up to date with r151007 you should already have the OmniTI CA certificate, which is delivered by pkg:/web/ca-bundle into /etc/ssl/pkg. If you have this, you should be able to get going by setting your local image's trust-anchor-directory property so that the OmniTI cert can be located: # pkg set-property trust-anchor-directory etc/ssl/pkg Note that the value is a *relative* path (relative to the root of the image), so it does not have a leading '/'. If you do not have the OmniTI CA file, you can update to the version of ca-bundle that is not signed but *does* have the CA cert: # pkg update web/ca-bundle at 5.11,5.11-0.151007:20130823T212116Z This only works if you're already on some version of r151007. We are in the home stretch for the next release, so those wishing for the latest bits will have media containing signed packages and any new pkg images created will have the correct trust-anchor-directory by default. Eric From rafibeyli at gmail.com Mon Dec 2 14:55:57 2013 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Mon, 2 Dec 2013 16:55:57 +0200 (EET) Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: References: Message-ID: <1576695750.67960.1385996157208.JavaMail.zimbra@cantekstil.com.tr> Saso is this you are asking for? id part identify stat diskcap partcap error vendor product sn c1t5000C50041E9D9A7d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2934YB40000923 c1t5000C50041F1A5EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2937JC90000924 c1t5000C5004253FF87d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z294403Y0000C25 c1t5000C50055A607E3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2955HY80000931 c1t5000C50055A628EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z295857E0000931 c1t5000C50055A62F57d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2957MGA0000931 c1t5000C5005600A6B3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CNZ0000C32 c1t5000C5005600B43Bd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CF50000C32 c1t5001517803D007D8d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV249102HG120 c1t5001517959627219d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM130600KP032 c1t5001517BB2747BE7d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM1404005G032 c1t5001517BB2AFB592d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV245100J1120 c3t1d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681F1 c3t2d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681EE c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 c4t50000392C8008B7Ed0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FBDSP EB01PA9013TD103 c4t5000C5002BD75C05d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FAWHV 6SE134XX0000B10 c4t5000CCA0150597A5d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV32ANE c4t5000CCA01505A321d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV333BE c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EUJ7104 c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EY64104 c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F12G104 c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F1P5104 c6t50000392C8008B7Fd0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FBDSP EB01PA9013TD103 c6t5000C5002BD75C06d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FAWHV 6SE134XX0000B10 c6t5000CCA0150597A6d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV32ANE c6t5000CCA01505A322d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV333BE ----- Orijinal Mesaj ----- Kimden: omnios-discuss-request at lists.omniti.com Kime: omnios-discuss at lists.omniti.com G?nderilenler: 2 Aral?k Pazartesi 2013 16:39:43 Konu: OmniOS-discuss Digest, Vol 21, Issue 2 Send OmniOS-discuss mailing list submissions to omnios-discuss at lists.omniti.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.omniti.com/mailman/listinfo/omnios-discuss or, via email, send a message with subject or body 'help' to omnios-discuss-request at lists.omniti.com You can reach the person managing the list at omnios-discuss-owner at lists.omniti.com When replying, please edit your Subject line so it is more specific than "Re: Contents of OmniOS-discuss digest..." Today's Topics: 1. Re: Re-installing OmniOS after Crash (Piers Dawson-Damer) 2. 2x acctual disk quantity (Hafiz Rafibeyli) 3. Re: 2x acctual disk quantity (Saso Kiselkov) 4. 2x acctual disk quantity (Hafiz Rafibeyli) 5. Re: 2x acctual disk quantity (Saso Kiselkov) ---------------------------------------------------------------------- Message: 1 Date: Mon, 2 Dec 2013 20:26:34 +1100 From: Piers Dawson-Damer To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash Message-ID: Content-Type: text/plain; charset="us-ascii" Any update on this error? I also cannot update my system. Have tried removing the OmniTi repositories Piers SunOS prod 5.11 omnios-ef9657e i86pc i386 i86pc piers at prod:~$ pfexec pkg update -v Creating Plan / pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority The package involved is:pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151007:20130926T213513Z On 27 Oct 2013, at 11:04 pm, Sam M wrote: > Hello all. > > After installing napp-it, OmniOS got hosed. Not sure what caused it, probably not napp-it, because I couldn't boot up my system with any of the boot images, including the original. > > Now, on a brand new installation, I'm getting the following error - > > # pkg update web/ca-bundle pkg > Creating Plan - > pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority > The package involved is:pkg://omnios/library/python-2/pybonjour at 1.1.1,5.11-0.151007:20130516T114553Z > > # uname -a > SunOS sequoia 5.11 omnios-df542ea i86pc i386 i86pc Solaris > > There were no errors earlier after the installation when updating packages. > > How can I fix this? Where can I find OmniTI's CA certificate? > > TIA. > > Sam > > > > _______________________________________________ > 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: ------------------------------ Message: 2 Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET) From: Hafiz Rafibeyli To: omnios-discuss Subject: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <147167035.58244.1385986084129.JavaMail.zimbra at cantekstil.com.tr> Content-Type: text/plain; charset=windows-1254 Saso thank you for your fast reply, its ok about two ports(sas dp)I know it, but my question is about ,which disk adresses to use in my zfs mirror or zfs raid config? in my case: c4t500000E1168BB382d0 c4t500000E11693F232d0 c4t500000E11696D5A2d0 c4t500000E116974FB2d0 OR c6t500000E1168BB383d0 c6t500000E11693F233d0 c6t500000E11696D5A3d0 c6t500000E116974FB3d0 If I understand right,when use first adresses I will use 1st controller only,and when use second addresses 2nd controller only? regards Hafiz Message: 6 Date: Sat, 30 Nov 2013 11:26:57 +0000 From: Saso Kiselkov To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <5299CB81.7090101 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 11/30/13, 9:43 AM, Hafiz Rafibeyli wrote: > Hello, > > After adding 4 SAS dual port disks to my omnios system(omnios-b281e50+napp-it) ,I see number of disks 2x acctual quantity. > > I have dual controller backplane(supermicro) and 2 LSI 9211-8i, > > There is no any quantity problem with another disks,only with new added HP 300GB SAS DP. > > > c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 > c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 > c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 > c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 > c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 > c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 Hey Hafiz, What you're seeing are the two ports of the disks. Using "mpathadm list lu" you should be able to determine which SAS addresses correspond to which disks. You can also use something like diskmap.py from https://github.com/swacquie/DiskMap (it requires the sas2ircu utility from LSI). Cheers, -- Saso ------------------------------ Message: 3 Date: Mon, 02 Dec 2013 12:17:04 +0000 From: Saso Kiselkov To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <529C7A40.2090300 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 12/2/13, 12:08 PM, Hafiz Rafibeyli wrote: > > Saso thank you for your fast reply, > > its ok about two ports(sas dp)I know it, > > but my question is about ,which disk adresses to use in my zfs mirror or zfs raid config? > > in my case: > > c4t500000E1168BB382d0 > c4t500000E11693F232d0 > c4t500000E11696D5A2d0 > c4t500000E116974FB2d0 > > OR > > c6t500000E1168BB383d0 > c6t500000E11693F233d0 > c6t500000E11696D5A3d0 > c6t500000E116974FB3d0 > > > If I understand right,when use first adresses I will use 1st controller only,and when use second addresses 2nd controller only? You should use neither. The underlying disk paths are automatically managed by the scsi_vhci driver. You need to consult "mpathadm list lu" and use the device names printed there as your ZFS device nodes, for example (using the example from http://docs.oracle.com/cd/E19253-01/820-1931/agkax/index.html): # mpathadm list lu /dev/rdsk/c4t60020F20000035AF4267CCCB0002CEE2d0s2 Total Path Count: 2 Operational Path Count: 2 ... Here, c4t60020F20000035AF4267CCCB0002CEE2d0 is the correct disk node, so you should use that. If you are getting "Total Path Count: 1" and twice the number of nodes in "mpathadm list lu", then scsi_vhci is not detecting your disks as multi-pathed and you need to tell it to do that. See http://docs.oracle.com/cd/E19253-01/820-1931/gfpva/index.html on how to do that. My guess is, however, that this should not be needed, since you're saying you've got two LSI 9211-8i HBAs, which use the mpt_sas driver, which is automatically multipath-enabled. Cheers, -- Saso ------------------------------ Message: 4 Date: Mon, 2 Dec 2013 16:19:50 +0200 (EET) From: Hafiz Rafibeyli To: omnios-discuss Subject: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <310264256.65409.1385993990627.JavaMail.zimbra at cantekstil.com.tr> Content-Type: text/plain; charset=windows-1254 Saso ,I do not see my new added 4 disks in mpathadm list lu query. Here is my output, ~# mpathadm list lu /dev/rdsk/c1t5000C5005600A6B3d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517BB2747BE7d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517959627219d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50055A607E3d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517BB2AFB592d0s2 Total Path Count: 1 Operational Path Count: 1 /dev/rdsk/c1t5000C50041E9D9A7d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C5004253FF87d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50055A62F57d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517803D007D8d0s2 Total Path Count: 1 Operational Path Count: 1 /dev/rdsk/c1t5000C5005600B43Bd0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50041F1A5EFd0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50055A628EFd0s2 Total Path Count: 2 Operational Path Count: 2 These disks are from my 1st zfs pool which is now in production: NAME STATE READ WRITE CKSUM CAP Product zpool1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 c1t5000C50041E9D9A7d0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50041F1A5EFd0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C5004253FF87d0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50055A607E3d0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50055A628EFd0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50055A62F57d0 ONLINE 0 0 0 3 TB ST33000650SS logs mirror-1 ONLINE 0 0 0 c1t5001517959627219d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN c1t5001517BB2747BE7d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN cache c1t5001517803D007D8d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 c1t5001517BB2AFB592d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 spares c1t5000C5005600A6B3d0 AVAIL 3 TB ST33000650SS c1t5000C5005600B43Bd0 AVAIL 3 TB ST33000650SS Is multipath'ing disabled on my system?and after enable multipath'ing will I lose my pool?because disk naming will change? Will zfs import work with new disk naming to get back my zfs pool and data? regards Hafiz. You should use neither. The underlying disk paths are automatically managed by the scsi_vhci driver. You need to consult "mpathadm list lu" and use the device names printed there as your ZFS device nodes, for example (using the example from http://docs.oracle.com/cd/E19253-01/820-1931/agkax/index.html): # mpathadm list lu /dev/rdsk/c4t60020F20000035AF4267CCCB0002CEE2d0s2 Total Path Count: 2 Operational Path Count: 2 ... Here, c4t60020F20000035AF4267CCCB0002CEE2d0 is the correct disk node, so you should use that. If you are getting "Total Path Count: 1" and twice the number of nodes in "mpathadm list lu", then scsi_vhci is not detecting your disks as multi-pathed and you need to tell it to do that. See http://docs.oracle.com/cd/E19253-01/820-1931/gfpva/index.html on how to do that. My guess is, however, that this should not be needed, since you're saying you've got two LSI 9211-8i HBAs, which use the mpt_sas driver, which is automatically multipath-enabled. Cheers, -- Saso ------------------------------ Message: 5 Date: Mon, 02 Dec 2013 14:39:39 +0000 From: Saso Kiselkov To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <529C9BAB.9050002 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Can you please send me the output of format(1) when it lists the available disks? Cheers, -- Saso On 12/2/13, 2:19 PM, Hafiz Rafibeyli wrote: > Saso ,I do not see my new added 4 disks in mpathadm list lu query. > > Here is my output, > > ~# mpathadm list lu > /dev/rdsk/c1t5000C5005600A6B3d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517BB2747BE7d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517959627219d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50055A607E3d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517BB2AFB592d0s2 > Total Path Count: 1 > Operational Path Count: 1 > /dev/rdsk/c1t5000C50041E9D9A7d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C5004253FF87d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50055A62F57d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517803D007D8d0s2 > Total Path Count: 1 > Operational Path Count: 1 > /dev/rdsk/c1t5000C5005600B43Bd0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50041F1A5EFd0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50055A628EFd0s2 > Total Path Count: 2 > Operational Path Count: 2 > > These disks are from my 1st zfs pool which is now in production: > > > NAME STATE READ WRITE CKSUM CAP Product > zpool1 ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > c1t5000C50041E9D9A7d0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50041F1A5EFd0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C5004253FF87d0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50055A607E3d0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50055A628EFd0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50055A62F57d0 ONLINE 0 0 0 3 TB ST33000650SS > logs > mirror-1 ONLINE 0 0 0 > c1t5001517959627219d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN > c1t5001517BB2747BE7d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN > cache > c1t5001517803D007D8d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 > c1t5001517BB2AFB592d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 > spares > c1t5000C5005600A6B3d0 AVAIL 3 TB ST33000650SS > c1t5000C5005600B43Bd0 AVAIL 3 TB ST33000650SS > > Is multipath'ing disabled on my system?and after enable multipath'ing will I lose my pool?because disk naming will change? > Will zfs import work with new disk naming to get back my zfs pool and data? > > regards > > Hafiz. > > > You should use neither. The underlying disk paths are automatically > managed by the scsi_vhci driver. You need to consult "mpathadm list lu" > and use the device names printed there as your ZFS device nodes, for > example (using the example from > http://docs.oracle.com/cd/E19253-01/820-1931/agkax/index.html): > > # mpathadm list lu > /dev/rdsk/c4t60020F20000035AF4267CCCB0002CEE2d0s2 > Total Path Count: 2 > Operational Path Count: 2 > ... > > Here, c4t60020F20000035AF4267CCCB0002CEE2d0 is the correct disk node, so > you should use that. If you are getting "Total Path Count: 1" and twice > the number of nodes in "mpathadm list lu", then scsi_vhci is not > detecting your disks as multi-pathed and you need to tell it to do that. > See http://docs.oracle.com/cd/E19253-01/820-1931/gfpva/index.html on how > to do that. My guess is, however, that this should not be needed, since > you're saying you've got two LSI 9211-8i HBAs, which use the mpt_sas > driver, which is automatically multipath-enabled. > > Cheers, > ------------------------------ Subject: Digest Footer _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ------------------------------ End of OmniOS-discuss Digest, Vol 21, Issue 2 ********************************************* From skiselkov.ml at gmail.com Mon Dec 2 14:59:28 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 02 Dec 2013 14:59:28 +0000 Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <1576695750.67960.1385996157208.JavaMail.zimbra@cantekstil.com.tr> References: <1576695750.67960.1385996157208.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <529CA050.8080303@gmail.com> No, I need you to run "format" and hit Control-C to exit it. it will print a disk list up front, like so: # format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c3t0d0 /pci at 7b,0/pci1022,7458 at 11/pci1000,3060 at 2/sd at 0,0 1. c6t600D0230006B66680C50AB7821F0E900d0 /scsi_vhci/disk at g600d0230006b66680c50ab7821f0e900 2. c6t600D0230006C1C4C0C50BE5BC9D49100d0 /scsi_vhci/disk at g600d0230006c1c4c0c50be5bc9d49100 (..etc..) -- Saso On 12/2/13, 2:55 PM, Hafiz Rafibeyli wrote: > Saso is this you are asking for? > > id part identify stat diskcap partcap error vendor product sn > c1t5000C50041E9D9A7d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2934YB40000923 > c1t5000C50041F1A5EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2937JC90000924 > c1t5000C5004253FF87d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z294403Y0000C25 > c1t5000C50055A607E3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2955HY80000931 > c1t5000C50055A628EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z295857E0000931 > c1t5000C50055A62F57d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2957MGA0000931 > c1t5000C5005600A6B3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CNZ0000C32 > c1t5000C5005600B43Bd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CF50000C32 > c1t5001517803D007D8d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV249102HG120 > c1t5001517959627219d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM130600KP032 > c1t5001517BB2747BE7d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM1404005G032 > c1t5001517BB2AFB592d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV245100J1120 > c3t1d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681F1 > c3t2d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681EE > c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 > c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 > c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 > c4t50000392C8008B7Ed0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FBDSP EB01PA9013TD103 > c4t5000C5002BD75C05d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FAWHV 6SE134XX0000B10 > c4t5000CCA0150597A5d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV32ANE > c4t5000CCA01505A321d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV333BE > c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EY64104 > c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F12G104 > c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F1P5104 > c6t50000392C8008B7Fd0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FBDSP EB01PA9013TD103 > c6t5000C5002BD75C06d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FAWHV 6SE134XX0000B10 > c6t5000CCA0150597A6d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV32ANE > c6t5000CCA01505A322d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV333BE > > ----- Orijinal Mesaj ----- > Kimden: omnios-discuss-request at lists.omniti.com > Kime: omnios-discuss at lists.omniti.com > G?nderilenler: 2 Aral?k Pazartesi 2013 16:39:43 > Konu: OmniOS-discuss Digest, Vol 21, Issue 2 > > Send OmniOS-discuss mailing list submissions to > omnios-discuss at lists.omniti.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.omniti.com/mailman/listinfo/omnios-discuss > or, via email, send a message with subject or body 'help' to > omnios-discuss-request at lists.omniti.com > > You can reach the person managing the list at > omnios-discuss-owner at lists.omniti.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OmniOS-discuss digest..." > > > Today's Topics: > > 1. Re: Re-installing OmniOS after Crash (Piers Dawson-Damer) > 2. 2x acctual disk quantity (Hafiz Rafibeyli) > 3. Re: 2x acctual disk quantity (Saso Kiselkov) > 4. 2x acctual disk quantity (Hafiz Rafibeyli) > 5. Re: 2x acctual disk quantity (Saso Kiselkov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 Dec 2013 20:26:34 +1100 > From: Piers Dawson-Damer > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Any update on this error? > > I also cannot update my system. Have tried removing the OmniTi repositories > > Piers > > SunOS prod 5.11 omnios-ef9657e i86pc i386 i86pc > > piers at prod:~$ pfexec pkg update -v > Creating Plan / > pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority > The package involved is:pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151007:20130926T213513Z > > > > On 27 Oct 2013, at 11:04 pm, Sam M wrote: > >> Hello all. >> >> After installing napp-it, OmniOS got hosed. Not sure what caused it, probably not napp-it, because I couldn't boot up my system with any of the boot images, including the original. >> >> Now, on a brand new installation, I'm getting the following error - >> >> # pkg update web/ca-bundle pkg >> Creating Plan - >> pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority >> The package involved is:pkg://omnios/library/python-2/pybonjour at 1.1.1,5.11-0.151007:20130516T114553Z >> >> # uname -a >> SunOS sequoia 5.11 omnios-df542ea i86pc i386 i86pc Solaris >> >> There were no errors earlier after the installation when updating packages. >> >> How can I fix this? Where can I find OmniTI's CA certificate? >> >> TIA. >> >> Sam >> >> >> >> _______________________________________________ >> 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: > > ------------------------------ > > Message: 2 > Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET) > From: Hafiz Rafibeyli > To: omnios-discuss > Subject: [OmniOS-discuss] 2x acctual disk quantity > Message-ID: > <147167035.58244.1385986084129.JavaMail.zimbra at cantekstil.com.tr> > Content-Type: text/plain; charset=windows-1254 > > > Saso thank you for your fast reply, > > its ok about two ports(sas dp)I know it, > > but my question is about ,which disk adresses to use in my zfs mirror or zfs raid config? > > in my case: > > c4t500000E1168BB382d0 > c4t500000E11693F232d0 > c4t500000E11696D5A2d0 > c4t500000E116974FB2d0 > > OR > > c6t500000E1168BB383d0 > c6t500000E11693F233d0 > c6t500000E11696D5A3d0 > c6t500000E116974FB3d0 > > > If I understand right,when use first adresses I will use 1st controller only,and when use second addresses 2nd controller only? > > regards > > Hafiz > > > Message: 6 > Date: Sat, 30 Nov 2013 11:26:57 +0000 > From: Saso Kiselkov > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] 2x acctual disk quantity > Message-ID: <5299CB81.7090101 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/30/13, 9:43 AM, Hafiz Rafibeyli wrote: >> Hello, >> >> After adding 4 SAS dual port disks to my omnios system(omnios-b281e50+napp-it) ,I see number of disks 2x acctual quantity. >> >> I have dual controller backplane(supermicro) and 2 LSI 9211-8i, >> >> There is no any quantity problem with another disks,only with new added HP 300GB SAS DP. >> >> >> c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 >> c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 >> c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 >> c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 >> c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 >> c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 >> c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 >> c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 > > Hey Hafiz, > > What you're seeing are the two ports of the disks. Using "mpathadm list > lu" you should be able to determine which SAS addresses correspond to > which disks. You can also use something like diskmap.py from > https://github.com/swacquie/DiskMap (it requires the sas2ircu utility > from LSI). > > Cheers, > From rafibeyli at gmail.com Mon Dec 2 15:07:14 2013 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Mon, 2 Dec 2013 17:07:14 +0200 (EET) Subject: [OmniOS-discuss] OmniOS-discuss Digest, Vol 21, Issue 3 In-Reply-To: References: Message-ID: <1533107507.68342.1385996834663.JavaMail.zimbra@cantekstil.com.tr> after my fist post I added 4 x HP SAS 300 GB DP disks to system,actual HP disks quantity 8 now. AVAILABLE DISK SELECTIONS: 0. c1t5000C50041E9D9A7d0 /scsi_vhci/disk at g5000c50041e9d9a7 1. c1t5000C50041F1A5EFd0 /scsi_vhci/disk at g5000c50041f1a5ef 2. c1t5000C50055A62F57d0 /scsi_vhci/disk at g5000c50055a62f57 3. c1t5000C50055A607E3d0 /scsi_vhci/disk at g5000c50055a607e3 4. c1t5000C50055A628EFd0 /scsi_vhci/disk at g5000c50055a628ef 5. c1t5000C5004253FF87d0 /scsi_vhci/disk at g5000c5004253ff87 6. c1t5000C5005600A6B3d0 /scsi_vhci/disk at g5000c5005600a6b3 7. c1t5000C5005600B43Bd0 /scsi_vhci/disk at g5000c5005600b43b 8. c1t5001517BB2AFB592d0 /scsi_vhci/disk at g5001517bb2afb592 9. c1t5001517BB2747BE7d0 /scsi_vhci/disk at g5001517bb2747be7 10. c1t5001517803D007D8d0 /scsi_vhci/disk at g5001517803d007d8 11. c1t5001517959627219d0 /scsi_vhci/disk at g5001517959627219 12. c3t1d0 /pci at 0,0/pci15d9,100 at 1f,2/disk at 1,0 13. c3t2d0 /pci at 0,0/pci15d9,100 at 1f,2/disk at 2,0 14. c4t5000C5002BD75C05d0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w5000c5002bd75c05,0 15. c4t5000CCA01505A321d0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w5000cca01505a321,0 16. c4t5000CCA0150597A5d0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w5000cca0150597a5,0 17. c4t500000E1168BB382d0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w500000e1168bb382,0 18. c4t500000E11693F232d0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w500000e11693f232,0 19. c4t500000E11696D5A2d0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w500000e11696d5a2,0 20. c4t500000E116974FB2d0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w500000e116974fb2,0 21. c4t50000392C8008B7Ed0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w50000392c8008b7e,0 22. c6t5000C5002BD75C06d0 /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w5000c5002bd75c06,0 23. c6t5000CCA01505A322d0 /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w5000cca01505a322,0 24. c6t5000CCA0150597A6d0 /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w5000cca0150597a6,0 25. c6t500000E1168BB383d0 /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w500000e1168bb383,0 26. c6t500000E11693F233d0 /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w500000e11693f233,0 27. c6t500000E11696D5A3d0 /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w500000e11696d5a3,0 28. c6t500000E116974FB3d0 /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w500000e116974fb3,0 29. c6t50000392C8008B7Fd0 /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w50000392c8008b7f,0 ----- Orijinal Mesaj ----- Kimden: omnios-discuss-request at lists.omniti.com Kime: omnios-discuss at lists.omniti.com G?nderilenler: 2 Aral?k Pazartesi 2013 16:59:33 Konu: OmniOS-discuss Digest, Vol 21, Issue 3 Send OmniOS-discuss mailing list submissions to omnios-discuss at lists.omniti.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.omniti.com/mailman/listinfo/omnios-discuss or, via email, send a message with subject or body 'help' to omnios-discuss-request at lists.omniti.com You can reach the person managing the list at omnios-discuss-owner at lists.omniti.com When replying, please edit your Subject line so it is more specific than "Re: Contents of OmniOS-discuss digest..." Today's Topics: 1. Re: Re-installing OmniOS after Crash (Eric Sproul) 2. Re: 2x acctual disk quantity (Hafiz Rafibeyli) 3. Re: 2x acctual disk quantity (Saso Kiselkov) ---------------------------------------------------------------------- Message: 1 Date: Mon, 2 Dec 2013 09:53:09 -0500 From: Eric Sproul To: Piers Dawson-Damer Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 2, 2013 at 4:26 AM, Piers Dawson-Damer wrote: > Any update on this error? This is because we are now signing packages in bloody, in preparation for the next stable release. If you're reasonably up to date with r151007 you should already have the OmniTI CA certificate, which is delivered by pkg:/web/ca-bundle into /etc/ssl/pkg. If you have this, you should be able to get going by setting your local image's trust-anchor-directory property so that the OmniTI cert can be located: # pkg set-property trust-anchor-directory etc/ssl/pkg Note that the value is a *relative* path (relative to the root of the image), so it does not have a leading '/'. If you do not have the OmniTI CA file, you can update to the version of ca-bundle that is not signed but *does* have the CA cert: # pkg update web/ca-bundle at 5.11,5.11-0.151007:20130823T212116Z This only works if you're already on some version of r151007. We are in the home stretch for the next release, so those wishing for the latest bits will have media containing signed packages and any new pkg images created will have the correct trust-anchor-directory by default. Eric ------------------------------ Message: 2 Date: Mon, 2 Dec 2013 16:55:57 +0200 (EET) From: Hafiz Rafibeyli To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <1576695750.67960.1385996157208.JavaMail.zimbra at cantekstil.com.tr> Content-Type: text/plain; charset=windows-1254 Saso is this you are asking for? id part identify stat diskcap partcap error vendor product sn c1t5000C50041E9D9A7d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2934YB40000923 c1t5000C50041F1A5EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2937JC90000924 c1t5000C5004253FF87d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z294403Y0000C25 c1t5000C50055A607E3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2955HY80000931 c1t5000C50055A628EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z295857E0000931 c1t5000C50055A62F57d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2957MGA0000931 c1t5000C5005600A6B3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CNZ0000C32 c1t5000C5005600B43Bd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CF50000C32 c1t5001517803D007D8d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV249102HG120 c1t5001517959627219d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM130600KP032 c1t5001517BB2747BE7d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM1404005G032 c1t5001517BB2AFB592d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV245100J1120 c3t1d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681F1 c3t2d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681EE c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 c4t50000392C8008B7Ed0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FBDSP EB01PA9013TD103 c4t5000C5002BD75C05d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FAWHV 6SE134XX0000B10 c4t5000CCA0150597A5d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV32ANE c4t5000CCA01505A321d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV333BE c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EUJ7104 c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EY64104 c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F12G104 c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F1P5104 c6t50000392C8008B7Fd0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FBDSP EB01PA9013TD103 c6t5000C5002BD75C06d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FAWHV 6SE134XX0000B10 c6t5000CCA0150597A6d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV32ANE c6t5000CCA01505A322d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV333BE ----- Orijinal Mesaj ----- Kimden: omnios-discuss-request at lists.omniti.com Kime: omnios-discuss at lists.omniti.com G?nderilenler: 2 Aral?k Pazartesi 2013 16:39:43 Konu: OmniOS-discuss Digest, Vol 21, Issue 2 Send OmniOS-discuss mailing list submissions to omnios-discuss at lists.omniti.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.omniti.com/mailman/listinfo/omnios-discuss or, via email, send a message with subject or body 'help' to omnios-discuss-request at lists.omniti.com You can reach the person managing the list at omnios-discuss-owner at lists.omniti.com When replying, please edit your Subject line so it is more specific than "Re: Contents of OmniOS-discuss digest..." Today's Topics: 1. Re: Re-installing OmniOS after Crash (Piers Dawson-Damer) 2. 2x acctual disk quantity (Hafiz Rafibeyli) 3. Re: 2x acctual disk quantity (Saso Kiselkov) 4. 2x acctual disk quantity (Hafiz Rafibeyli) 5. Re: 2x acctual disk quantity (Saso Kiselkov) ---------------------------------------------------------------------- Message: 1 Date: Mon, 2 Dec 2013 20:26:34 +1100 From: Piers Dawson-Damer To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash Message-ID: Content-Type: text/plain; charset="us-ascii" Any update on this error? I also cannot update my system. Have tried removing the OmniTi repositories Piers SunOS prod 5.11 omnios-ef9657e i86pc i386 i86pc piers at prod:~$ pfexec pkg update -v Creating Plan / pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority The package involved is:pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151007:20130926T213513Z On 27 Oct 2013, at 11:04 pm, Sam M wrote: > Hello all. > > After installing napp-it, OmniOS got hosed. Not sure what caused it, probably not napp-it, because I couldn't boot up my system with any of the boot images, including the original. > > Now, on a brand new installation, I'm getting the following error - > > # pkg update web/ca-bundle pkg > Creating Plan - > pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority > The package involved is:pkg://omnios/library/python-2/pybonjour at 1.1.1,5.11-0.151007:20130516T114553Z > > # uname -a > SunOS sequoia 5.11 omnios-df542ea i86pc i386 i86pc Solaris > > There were no errors earlier after the installation when updating packages. > > How can I fix this? Where can I find OmniTI's CA certificate? > > TIA. > > Sam > > > > _______________________________________________ > 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: ------------------------------ Message: 2 Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET) From: Hafiz Rafibeyli To: omnios-discuss Subject: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <147167035.58244.1385986084129.JavaMail.zimbra at cantekstil.com.tr> Content-Type: text/plain; charset=windows-1254 Saso thank you for your fast reply, its ok about two ports(sas dp)I know it, but my question is about ,which disk adresses to use in my zfs mirror or zfs raid config? in my case: c4t500000E1168BB382d0 c4t500000E11693F232d0 c4t500000E11696D5A2d0 c4t500000E116974FB2d0 OR c6t500000E1168BB383d0 c6t500000E11693F233d0 c6t500000E11696D5A3d0 c6t500000E116974FB3d0 If I understand right,when use first adresses I will use 1st controller only,and when use second addresses 2nd controller only? regards Hafiz Message: 6 Date: Sat, 30 Nov 2013 11:26:57 +0000 From: Saso Kiselkov To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <5299CB81.7090101 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 11/30/13, 9:43 AM, Hafiz Rafibeyli wrote: > Hello, > > After adding 4 SAS dual port disks to my omnios system(omnios-b281e50+napp-it) ,I see number of disks 2x acctual quantity. > > I have dual controller backplane(supermicro) and 2 LSI 9211-8i, > > There is no any quantity problem with another disks,only with new added HP 300GB SAS DP. > > > c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 > c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 > c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 > c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 > c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 > c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 Hey Hafiz, What you're seeing are the two ports of the disks. Using "mpathadm list lu" you should be able to determine which SAS addresses correspond to which disks. You can also use something like diskmap.py from https://github.com/swacquie/DiskMap (it requires the sas2ircu utility from LSI). Cheers, -- Saso ------------------------------ Message: 3 Date: Mon, 02 Dec 2013 12:17:04 +0000 From: Saso Kiselkov To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <529C7A40.2090300 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 12/2/13, 12:08 PM, Hafiz Rafibeyli wrote: > > Saso thank you for your fast reply, > > its ok about two ports(sas dp)I know it, > > but my question is about ,which disk adresses to use in my zfs mirror or zfs raid config? > > in my case: > > c4t500000E1168BB382d0 > c4t500000E11693F232d0 > c4t500000E11696D5A2d0 > c4t500000E116974FB2d0 > > OR > > c6t500000E1168BB383d0 > c6t500000E11693F233d0 > c6t500000E11696D5A3d0 > c6t500000E116974FB3d0 > > > If I understand right,when use first adresses I will use 1st controller only,and when use second addresses 2nd controller only? You should use neither. The underlying disk paths are automatically managed by the scsi_vhci driver. You need to consult "mpathadm list lu" and use the device names printed there as your ZFS device nodes, for example (using the example from http://docs.oracle.com/cd/E19253-01/820-1931/agkax/index.html): # mpathadm list lu /dev/rdsk/c4t60020F20000035AF4267CCCB0002CEE2d0s2 Total Path Count: 2 Operational Path Count: 2 ... Here, c4t60020F20000035AF4267CCCB0002CEE2d0 is the correct disk node, so you should use that. If you are getting "Total Path Count: 1" and twice the number of nodes in "mpathadm list lu", then scsi_vhci is not detecting your disks as multi-pathed and you need to tell it to do that. See http://docs.oracle.com/cd/E19253-01/820-1931/gfpva/index.html on how to do that. My guess is, however, that this should not be needed, since you're saying you've got two LSI 9211-8i HBAs, which use the mpt_sas driver, which is automatically multipath-enabled. Cheers, -- Saso ------------------------------ Message: 4 Date: Mon, 2 Dec 2013 16:19:50 +0200 (EET) From: Hafiz Rafibeyli To: omnios-discuss Subject: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <310264256.65409.1385993990627.JavaMail.zimbra at cantekstil.com.tr> Content-Type: text/plain; charset=windows-1254 Saso ,I do not see my new added 4 disks in mpathadm list lu query. Here is my output, ~# mpathadm list lu /dev/rdsk/c1t5000C5005600A6B3d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517BB2747BE7d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517959627219d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50055A607E3d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517BB2AFB592d0s2 Total Path Count: 1 Operational Path Count: 1 /dev/rdsk/c1t5000C50041E9D9A7d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C5004253FF87d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50055A62F57d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5001517803D007D8d0s2 Total Path Count: 1 Operational Path Count: 1 /dev/rdsk/c1t5000C5005600B43Bd0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50041F1A5EFd0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c1t5000C50055A628EFd0s2 Total Path Count: 2 Operational Path Count: 2 These disks are from my 1st zfs pool which is now in production: NAME STATE READ WRITE CKSUM CAP Product zpool1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 c1t5000C50041E9D9A7d0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50041F1A5EFd0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C5004253FF87d0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50055A607E3d0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50055A628EFd0 ONLINE 0 0 0 3 TB ST33000650SS c1t5000C50055A62F57d0 ONLINE 0 0 0 3 TB ST33000650SS logs mirror-1 ONLINE 0 0 0 c1t5001517959627219d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN c1t5001517BB2747BE7d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN cache c1t5001517803D007D8d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 c1t5001517BB2AFB592d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 spares c1t5000C5005600A6B3d0 AVAIL 3 TB ST33000650SS c1t5000C5005600B43Bd0 AVAIL 3 TB ST33000650SS Is multipath'ing disabled on my system?and after enable multipath'ing will I lose my pool?because disk naming will change? Will zfs import work with new disk naming to get back my zfs pool and data? regards Hafiz. You should use neither. The underlying disk paths are automatically managed by the scsi_vhci driver. You need to consult "mpathadm list lu" and use the device names printed there as your ZFS device nodes, for example (using the example from http://docs.oracle.com/cd/E19253-01/820-1931/agkax/index.html): # mpathadm list lu /dev/rdsk/c4t60020F20000035AF4267CCCB0002CEE2d0s2 Total Path Count: 2 Operational Path Count: 2 ... Here, c4t60020F20000035AF4267CCCB0002CEE2d0 is the correct disk node, so you should use that. If you are getting "Total Path Count: 1" and twice the number of nodes in "mpathadm list lu", then scsi_vhci is not detecting your disks as multi-pathed and you need to tell it to do that. See http://docs.oracle.com/cd/E19253-01/820-1931/gfpva/index.html on how to do that. My guess is, however, that this should not be needed, since you're saying you've got two LSI 9211-8i HBAs, which use the mpt_sas driver, which is automatically multipath-enabled. Cheers, -- Saso ------------------------------ Message: 5 Date: Mon, 02 Dec 2013 14:39:39 +0000 From: Saso Kiselkov To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <529C9BAB.9050002 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Can you please send me the output of format(1) when it lists the available disks? Cheers, -- Saso On 12/2/13, 2:19 PM, Hafiz Rafibeyli wrote: > Saso ,I do not see my new added 4 disks in mpathadm list lu query. > > Here is my output, > > ~# mpathadm list lu > /dev/rdsk/c1t5000C5005600A6B3d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517BB2747BE7d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517959627219d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50055A607E3d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517BB2AFB592d0s2 > Total Path Count: 1 > Operational Path Count: 1 > /dev/rdsk/c1t5000C50041E9D9A7d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C5004253FF87d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50055A62F57d0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5001517803D007D8d0s2 > Total Path Count: 1 > Operational Path Count: 1 > /dev/rdsk/c1t5000C5005600B43Bd0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50041F1A5EFd0s2 > Total Path Count: 2 > Operational Path Count: 2 > /dev/rdsk/c1t5000C50055A628EFd0s2 > Total Path Count: 2 > Operational Path Count: 2 > > These disks are from my 1st zfs pool which is now in production: > > > NAME STATE READ WRITE CKSUM CAP Product > zpool1 ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > c1t5000C50041E9D9A7d0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50041F1A5EFd0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C5004253FF87d0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50055A607E3d0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50055A628EFd0 ONLINE 0 0 0 3 TB ST33000650SS > c1t5000C50055A62F57d0 ONLINE 0 0 0 3 TB ST33000650SS > logs > mirror-1 ONLINE 0 0 0 > c1t5001517959627219d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN > c1t5001517BB2747BE7d0 ONLINE 0 0 0 32 GB SSDSA2SH032G1GN > cache > c1t5001517803D007D8d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 > c1t5001517BB2AFB592d0 ONLINE 0 0 0 120 GB INTEL SSDSC2CW12 > spares > c1t5000C5005600A6B3d0 AVAIL 3 TB ST33000650SS > c1t5000C5005600B43Bd0 AVAIL 3 TB ST33000650SS > > Is multipath'ing disabled on my system?and after enable multipath'ing will I lose my pool?because disk naming will change? > Will zfs import work with new disk naming to get back my zfs pool and data? > > regards > > Hafiz. > > > You should use neither. The underlying disk paths are automatically > managed by the scsi_vhci driver. You need to consult "mpathadm list lu" > and use the device names printed there as your ZFS device nodes, for > example (using the example from > http://docs.oracle.com/cd/E19253-01/820-1931/agkax/index.html): > > # mpathadm list lu > /dev/rdsk/c4t60020F20000035AF4267CCCB0002CEE2d0s2 > Total Path Count: 2 > Operational Path Count: 2 > ... > > Here, c4t60020F20000035AF4267CCCB0002CEE2d0 is the correct disk node, so > you should use that. If you are getting "Total Path Count: 1" and twice > the number of nodes in "mpathadm list lu", then scsi_vhci is not > detecting your disks as multi-pathed and you need to tell it to do that. > See http://docs.oracle.com/cd/E19253-01/820-1931/gfpva/index.html on how > to do that. My guess is, however, that this should not be needed, since > you're saying you've got two LSI 9211-8i HBAs, which use the mpt_sas > driver, which is automatically multipath-enabled. > > Cheers, > ------------------------------ Subject: Digest Footer _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ------------------------------ End of OmniOS-discuss Digest, Vol 21, Issue 2 ********************************************* ------------------------------ Message: 3 Date: Mon, 02 Dec 2013 14:59:28 +0000 From: Saso Kiselkov To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] 2x acctual disk quantity Message-ID: <529CA050.8080303 at gmail.com> Content-Type: text/plain; charset=windows-1254 No, I need you to run "format" and hit Control-C to exit it. it will print a disk list up front, like so: # format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c3t0d0 /pci at 7b,0/pci1022,7458 at 11/pci1000,3060 at 2/sd at 0,0 1. c6t600D0230006B66680C50AB7821F0E900d0 /scsi_vhci/disk at g600d0230006b66680c50ab7821f0e900 2. c6t600D0230006C1C4C0C50BE5BC9D49100d0 /scsi_vhci/disk at g600d0230006c1c4c0c50be5bc9d49100 (..etc..) -- Saso On 12/2/13, 2:55 PM, Hafiz Rafibeyli wrote: > Saso is this you are asking for? > > id part identify stat diskcap partcap error vendor product sn > c1t5000C50041E9D9A7d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2934YB40000923 > c1t5000C50041F1A5EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2937JC90000924 > c1t5000C5004253FF87d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z294403Y0000C25 > c1t5000C50055A607E3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2955HY80000931 > c1t5000C50055A628EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z295857E0000931 > c1t5000C50055A62F57d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2957MGA0000931 > c1t5000C5005600A6B3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CNZ0000C32 > c1t5000C5005600B43Bd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CF50000C32 > c1t5001517803D007D8d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV249102HG120 > c1t5001517959627219d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM130600KP032 > c1t5001517BB2747BE7d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM1404005G032 > c1t5001517BB2AFB592d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV245100J1120 > c3t1d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681F1 > c3t2d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681EE > c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 > c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 > c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 > c4t50000392C8008B7Ed0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FBDSP EB01PA9013TD103 > c4t5000C5002BD75C05d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FAWHV 6SE134XX0000B10 > c4t5000CCA0150597A5d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV32ANE > c4t5000CCA01505A321d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV333BE > c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EY64104 > c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F12G104 > c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F1P5104 > c6t50000392C8008B7Fd0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FBDSP EB01PA9013TD103 > c6t5000C5002BD75C06d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FAWHV 6SE134XX0000B10 > c6t5000CCA0150597A6d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV32ANE > c6t5000CCA01505A322d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV333BE > > ----- Orijinal Mesaj ----- > Kimden: omnios-discuss-request at lists.omniti.com > Kime: omnios-discuss at lists.omniti.com > G?nderilenler: 2 Aral?k Pazartesi 2013 16:39:43 > Konu: OmniOS-discuss Digest, Vol 21, Issue 2 > > Send OmniOS-discuss mailing list submissions to > omnios-discuss at lists.omniti.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.omniti.com/mailman/listinfo/omnios-discuss > or, via email, send a message with subject or body 'help' to > omnios-discuss-request at lists.omniti.com > > You can reach the person managing the list at > omnios-discuss-owner at lists.omniti.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OmniOS-discuss digest..." > > > Today's Topics: > > 1. Re: Re-installing OmniOS after Crash (Piers Dawson-Damer) > 2. 2x acctual disk quantity (Hafiz Rafibeyli) > 3. Re: 2x acctual disk quantity (Saso Kiselkov) > 4. 2x acctual disk quantity (Hafiz Rafibeyli) > 5. Re: 2x acctual disk quantity (Saso Kiselkov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 Dec 2013 20:26:34 +1100 > From: Piers Dawson-Damer > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Any update on this error? > > I also cannot update my system. Have tried removing the OmniTi repositories > > Piers > > SunOS prod 5.11 omnios-ef9657e i86pc i386 i86pc > > piers at prod:~$ pfexec pkg update -v > Creating Plan / > pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority > The package involved is:pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151007:20130926T213513Z > > > > On 27 Oct 2013, at 11:04 pm, Sam M wrote: > >> Hello all. >> >> After installing napp-it, OmniOS got hosed. Not sure what caused it, probably not napp-it, because I couldn't boot up my system with any of the boot images, including the original. >> >> Now, on a brand new installation, I'm getting the following error - >> >> # pkg update web/ca-bundle pkg >> Creating Plan - >> pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority >> The package involved is:pkg://omnios/library/python-2/pybonjour at 1.1.1,5.11-0.151007:20130516T114553Z >> >> # uname -a >> SunOS sequoia 5.11 omnios-df542ea i86pc i386 i86pc Solaris >> >> There were no errors earlier after the installation when updating packages. >> >> How can I fix this? Where can I find OmniTI's CA certificate? >> >> TIA. >> >> Sam >> >> >> >> _______________________________________________ >> 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: > > ------------------------------ > > Message: 2 > Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET) > From: Hafiz Rafibeyli > To: omnios-discuss > Subject: [OmniOS-discuss] 2x acctual disk quantity > Message-ID: > <147167035.58244.1385986084129.JavaMail.zimbra at cantekstil.com.tr> > Content-Type: text/plain; charset=windows-1254 > > > Saso thank you for your fast reply, > > its ok about two ports(sas dp)I know it, > > but my question is about ,which disk adresses to use in my zfs mirror or zfs raid config? > > in my case: > > c4t500000E1168BB382d0 > c4t500000E11693F232d0 > c4t500000E11696D5A2d0 > c4t500000E116974FB2d0 > > OR > > c6t500000E1168BB383d0 > c6t500000E11693F233d0 > c6t500000E11696D5A3d0 > c6t500000E116974FB3d0 > > > If I understand right,when use first adresses I will use 1st controller only,and when use second addresses 2nd controller only? > > regards > > Hafiz > > > Message: 6 > Date: Sat, 30 Nov 2013 11:26:57 +0000 > From: Saso Kiselkov > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] 2x acctual disk quantity > Message-ID: <5299CB81.7090101 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/30/13, 9:43 AM, Hafiz Rafibeyli wrote: >> Hello, >> >> After adding 4 SAS dual port disks to my omnios system(omnios-b281e50+napp-it) ,I see number of disks 2x acctual quantity. >> >> I have dual controller backplane(supermicro) and 2 LSI 9211-8i, >> >> There is no any quantity problem with another disks,only with new added HP 300GB SAS DP. >> >> >> c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 >> c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 >> c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 >> c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 >> c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 >> c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 >> c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 >> c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 > > Hey Hafiz, > > What you're seeing are the two ports of the disks. Using "mpathadm list > lu" you should be able to determine which SAS addresses correspond to > which disks. You can also use something like diskmap.py from > https://github.com/swacquie/DiskMap (it requires the sas2ircu utility > from LSI). > > Cheers, > ------------------------------ Subject: Digest Footer _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ------------------------------ End of OmniOS-discuss Digest, Vol 21, Issue 3 ********************************************* From skiselkov.ml at gmail.com Mon Dec 2 20:00:18 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 02 Dec 2013 20:00:18 +0000 Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <1576695750.67960.1385996157208.JavaMail.zimbra@cantekstil.com.tr> References: <1576695750.67960.1385996157208.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <529CE6D2.4070002@gmail.com> Ok, so in regards to multipath, looking at format(1) I can see that scsi_vhci doesn't have your drives whitelisted for multipath support, so that's why you're seeing lines such as: 14. c4t5000C5002BD75C05d0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w5000c5002bd75c05,0 in format(1) output. If scsi_vhci had detected your disks, the paths would start with "/scsi_vhci..." rather than "/pci...". No problem, you can manually whitelist the disks (here's the full manual): http://docs.oracle.com/cd/E19253-01/816-5177/6mbbc4gal/index.html In principle what you need to do is add a line like this: device-type-scsi-options-list = "HP EG0300FAWHV", "f_sym"; Please note that there are 6 spaces following 'HP' in the above identifier - copy it exactly as it appears here (scsi_vhci needs the vendor ID to be exactly 8 characters long, so we need to pad it with spaces). After you've done this you should be able to reload the driver configuration (via "update_drv scsi_vhci"), your drives should reappear in the "/scsi_vhci..." device path with the correct number (4 drives, not 8) and "mpathadm list lu" should display them and the paths to them. If update_drv is going to be giving you trouble, a reboot might be needed (haven't tested this in a while, so I don't remember). You can double-check the Vendor ID and Product ID that you need to enter in there by running "prtconf -v" and looking for the drive in the device tree. You should be able to see lines like these: name='inquiry-product-id' type=string items=1 value='EG0300FAWHV' name='inquiry-vendor-id' type=string items=1 value='HP' Cheers, -- Saso On 12/2/13, 2:55 PM, Hafiz Rafibeyli wrote: > Saso is this you are asking for? > > id part identify stat diskcap partcap error vendor product sn > c1t5000C50041E9D9A7d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2934YB40000923 > c1t5000C50041F1A5EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2937JC90000924 > c1t5000C5004253FF87d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z294403Y0000C25 > c1t5000C50055A607E3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2955HY80000931 > c1t5000C50055A628EFd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z295857E0000931 > c1t5000C50055A62F57d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2957MGA0000931 > c1t5000C5005600A6B3d0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CNZ0000C32 > c1t5000C5005600B43Bd0 (!parted) via dd ok 3 TB S:0 H:4 T:0 SEAGATE ST33000650SS Z2967CF50000C32 > c1t5001517803D007D8d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV249102HG120 > c1t5001517959627219d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM130600KP032 > c1t5001517BB2747BE7d0 (!parted) via dd ok 32 GB S:2 H:0 T:0 ATA SSDSA2SH032G1GN CVEM1404005G032 > c1t5001517BB2AFB592d0 (!parted) via dd ok 120 GB S:2 H:0 T:0 ATA INTEL SSDSC2CW12 CVCV245100J1120 > c3t1d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681F1 > c3t2d0 (!parted) via dd ok 50 GB S:2 H:0 T:0 ATA STEC MACH16 M STM0001681EE > c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 > c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 > c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 > c4t50000392C8008B7Ed0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FBDSP EB01PA9013TD103 > c4t5000C5002BD75C05d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FAWHV 6SE134XX0000B10 > c4t5000CCA0150597A5d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV32ANE > c4t5000CCA01505A321d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP DG0300FARVV PFV333BE > c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EUJ7104 > c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0EY64104 > c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F12G104 > c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FARTT D001PAB0F1P5104 > c6t50000392C8008B7Fd0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FBDSP EB01PA9013TD103 > c6t5000C5002BD75C06d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP EG0300FAWHV 6SE134XX0000B10 > c6t5000CCA0150597A6d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV32ANE > c6t5000CCA01505A322d0 (!parted) via dd ok 300 GB S:0 H:1 T:0 HP DG0300FARVV PFV333BE > > ----- Orijinal Mesaj ----- > Kimden: omnios-discuss-request at lists.omniti.com > Kime: omnios-discuss at lists.omniti.com > G?nderilenler: 2 Aral?k Pazartesi 2013 16:39:43 > Konu: OmniOS-discuss Digest, Vol 21, Issue 2 > > Send OmniOS-discuss mailing list submissions to > omnios-discuss at lists.omniti.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.omniti.com/mailman/listinfo/omnios-discuss > or, via email, send a message with subject or body 'help' to > omnios-discuss-request at lists.omniti.com > > You can reach the person managing the list at > omnios-discuss-owner at lists.omniti.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OmniOS-discuss digest..." > > > Today's Topics: > > 1. Re: Re-installing OmniOS after Crash (Piers Dawson-Damer) > 2. 2x acctual disk quantity (Hafiz Rafibeyli) > 3. Re: 2x acctual disk quantity (Saso Kiselkov) > 4. 2x acctual disk quantity (Hafiz Rafibeyli) > 5. Re: 2x acctual disk quantity (Saso Kiselkov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 Dec 2013 20:26:34 +1100 > From: Piers Dawson-Damer > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Any update on this error? > > I also cannot update my system. Have tried removing the OmniTi repositories > > Piers > > SunOS prod 5.11 omnios-ef9657e i86pc i386 i86pc > > piers at prod:~$ pfexec pkg update -v > Creating Plan / > pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority > The package involved is:pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151007:20130926T213513Z > > > > On 27 Oct 2013, at 11:04 pm, Sam M wrote: > >> Hello all. >> >> After installing napp-it, OmniOS got hosed. Not sure what caused it, probably not napp-it, because I couldn't boot up my system with any of the boot images, including the original. >> >> Now, on a brand new installation, I'm getting the following error - >> >> # pkg update web/ca-bundle pkg >> Creating Plan - >> pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority >> The package involved is:pkg://omnios/library/python-2/pybonjour at 1.1.1,5.11-0.151007:20130516T114553Z >> >> # uname -a >> SunOS sequoia 5.11 omnios-df542ea i86pc i386 i86pc Solaris >> >> There were no errors earlier after the installation when updating packages. >> >> How can I fix this? Where can I find OmniTI's CA certificate? >> >> TIA. >> >> Sam >> >> >> >> _______________________________________________ >> 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: > > ------------------------------ > > Message: 2 > Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET) > From: Hafiz Rafibeyli > To: omnios-discuss > Subject: [OmniOS-discuss] 2x acctual disk quantity > Message-ID: > <147167035.58244.1385986084129.JavaMail.zimbra at cantekstil.com.tr> > Content-Type: text/plain; charset=windows-1254 > > > Saso thank you for your fast reply, > > its ok about two ports(sas dp)I know it, > > but my question is about ,which disk adresses to use in my zfs mirror or zfs raid config? > > in my case: > > c4t500000E1168BB382d0 > c4t500000E11693F232d0 > c4t500000E11696D5A2d0 > c4t500000E116974FB2d0 > > OR > > c6t500000E1168BB383d0 > c6t500000E11693F233d0 > c6t500000E11696D5A3d0 > c6t500000E116974FB3d0 > > > If I understand right,when use first adresses I will use 1st controller only,and when use second addresses 2nd controller only? > > regards > > Hafiz > > > Message: 6 > Date: Sat, 30 Nov 2013 11:26:57 +0000 > From: Saso Kiselkov > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] 2x acctual disk quantity > Message-ID: <5299CB81.7090101 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/30/13, 9:43 AM, Hafiz Rafibeyli wrote: >> Hello, >> >> After adding 4 SAS dual port disks to my omnios system(omnios-b281e50+napp-it) ,I see number of disks 2x acctual quantity. >> >> I have dual controller backplane(supermicro) and 2 LSI 9211-8i, >> >> There is no any quantity problem with another disks,only with new added HP 300GB SAS DP. >> >> >> c4t500000E1168BB382d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 >> c4t500000E11693F232d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 >> c4t500000E11696D5A2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 >> c4t500000E116974FB2d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 >> c6t500000E1168BB383d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EUJ7104 >> c6t500000E11693F233d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0EY64104 >> c6t500000E11696D5A3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F12G104 >> c6t500000E116974FB3d0 (!parted) via dd ok 300 GB S:0 H:0 T:0 HP EG0300FARTT D001PAB0F1P5104 > > Hey Hafiz, > > What you're seeing are the two ports of the disks. Using "mpathadm list > lu" you should be able to determine which SAS addresses correspond to > which disks. You can also use something like diskmap.py from > https://github.com/swacquie/DiskMap (it requires the sas2ircu utility > from LSI). > > Cheers, > From henson at acm.org Mon Dec 2 20:42:22 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 2 Dec 2013 12:42:22 -0800 Subject: [OmniOS-discuss] ipmievd smf manifest in system/management/ipmitool Message-ID: <0a7a01ceef9f$024fdd30$06ef9790$@acm.org> The smf manifest for ipmievd in the ipmitool package has a hardcoded dependency on the default instance of system-log: # svcs -xv svc:/system/system-log:default (?) State: disabled since Mon Nov 18 18:13:14 2013 Reason: Disabled by an administrator. See: http://illumos.org/msg/SMF-8000-05 See: man -M /usr/share/man -s 1M syslogd Impact: 1 dependent service is not running: svc:/network/ipmievd:default I'm actually running syslog-ng on my box: # svcs | grep system-log online Nov_18 svc:/system/system-log:syslog-ng Shouldn't the dependency be on just the generic " svc:/system/system-log" service and not a specific instance of it? Thanks. From henson at acm.org Mon Dec 2 20:52:02 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 2 Dec 2013 12:52:02 -0800 Subject: [OmniOS-discuss] ipmievd smf manifest in system/management/ipmitool In-Reply-To: <0a7a01ceef9f$024fdd30$06ef9790$@acm.org> References: <0a7a01ceef9f$024fdd30$06ef9790$@acm.org> Message-ID: <0a7c01ceefa0$5c71c9d0$15555d70$@acm.org> > From: Paul Henson Paul B. Henson > Sent: Monday, December 02, 2013 12:42 PM > > The smf manifest for ipmievd in the ipmitool package has a hardcoded > dependency on the default instance of system-log: Oh, also, the startup script /lib/svc/method/svc-ipmievd looks for /dev/bmc, that needs to be /dev/ipmi0 now. Otherwise, you get into a confusing cycle of: # svcadm enable svc:/network/ipmievd:default # svcs -a | grep ipmi disabled 12:44:06 svc:/network/ipmievd:default # svcadm enable svc:/network/ipmievd:default # svcs -a | grep ipmi disabled 12:44:54 svc:/network/ipmievd:default I stared at that for a couple of minutes before I thought to look at the log ;): [ Dec 2 12:43:40 Executing start method ("/lib/svc/method/svc-ipmievd start").] /lib/svc/method/svc-ipmievd: No BMC device found: disabling. [ Dec 2 12:43:40 Method "start" exited with status 0. ] [ Dec 2 12:43:40 Stopping because all processes in service exited. ] [ Dec 2 12:43:40 Executing stop method (:kill). ] ;)... From geoffn at gnaa.net Tue Dec 3 07:05:54 2013 From: geoffn at gnaa.net (Geoff Nordli) Date: Mon, 02 Dec 2013 23:05:54 -0800 Subject: [OmniOS-discuss] Re-installing OmniOS after Crash In-Reply-To: References: Message-ID: <529D82D2.5080900@gnaa.net> On 13-12-02 06:53 AM, Eric Sproul wrote: > On Mon, Dec 2, 2013 at 4:26 AM, Piers Dawson-Damer wrote: >> Any update on this error? > This is because we are now signing packages in bloody, in preparation > for the next stable release. If you're reasonably up to date with > r151007 you should already have the OmniTI CA certificate, which is > delivered by pkg:/web/ca-bundle into /etc/ssl/pkg. If you have this, > you should be able to get going by setting your local image's > trust-anchor-directory property so that the OmniTI cert can be > located: > > # pkg set-property trust-anchor-directory etc/ssl/pkg > > Note that the value is a *relative* path (relative to the root of the > image), so it does not have a leading '/'. > > If you do not have the OmniTI CA file, you can update to the version > of ca-bundle that is not signed but *does* have the CA cert: > > # pkg update web/ca-bundle at 5.11,5.11-0.151007:20130823T212116Z > > This only works if you're already on some version of r151007. > > I am running bloody: omnios-df542ea (from the usb image on the web site) I am hitting the error: root at ma-back1:~# pkg update web/ca-bundle at 5.11,5.11-0.151007:20130823T212116Z Creating Plan / pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority The package involved is:pkg://omnios/system/library/mozilla-nss at 3.14.3,5.11-0.151007:20131008T151300Z Clues on how to get past this? thansk, Geoff From rafibeyli at gmail.com Tue Dec 3 08:13:07 2013 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Tue, 3 Dec 2013 10:13:07 +0200 (EET) Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <154455286.84861.1386058128380.JavaMail.zimbra@cantekstil.com.tr> References: <154455286.84861.1386058128380.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <1251946144.85273.1386058387233.JavaMail.zimbra@cantekstil.com.tr> Saso ,I will try edit /kernel/drv/scsi_vhci.conf as you described and will inform you. why these new disks not dedected by scsi_vhci automatically? is this because of settings in my /kernel/drv/mpt.conf and /kernel/drv/mpt_sas.conf files? /kernel/drv/mpt.conf ----------------------------------------------------------------------------------------------- # # Copyright 2008 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # # The mpt driver, as a pHCI driver, must specify the vHCI class it # belongs to(scsi_vhci). # ddi-vhci-class="scsi_vhci"; # # I/O multipathing feature (MPxIO) can be enabled or disabled using # mpxio-disable property. Setting mpxio-disable="no" will activate # I/O multipathing; setting mpxio-disable="yes" disables the feature. # # Global mpxio-disable property: # # To globally enable MPxIO on all mpt controllers set: # mpxio-disable="no"; # # To globally disable MPxIO on all mpt controllers set: # mpxio-disable="yes"; # # You can also enable or disable MPxIO on a per HBA basis. # Per HBA settings override the global setting for the specified HBAs. # To disable MPxIO on a controller whose parent is /pci at 7c0/pci at 0/pci at 9 # and the unit-address is "0" set: # name="mpt" parent="/pci at 7c0/pci at 0/pci at 9" unit-address="0" mpxio-disable="yes"; # mpxio-disable="yes"; # # SATA mpxio supported # # To disable SATA mpxio, set # disable-sata-mpxio="yes"; # When mpxio-disable="yes" is set, the disable-sata-mpxio property # takes no effect # disable-sata-mpxio="no"; --------------------------------------------------------------------------------------------------- /kernel/drv/mpt_sas.conf --------------------------------------------------------------------------------------------------- # # CDDL HEADER START # # The contents of this file are subject to the terms of the # Common Development and Distribution License (the "License"). # You may not use this file except in compliance with the License. # # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE # or http://www.opensolaris.org/os/licensing. # See the License for the specific language governing permissions # and limitations under the License. # # When distributing Covered Code, include this CDDL HEADER in each # file and include the License file at usr/src/OPENSOLARIS.LICENSE. # If applicable, add the following below this CDDL HEADER, with the # fields enclosed by brackets "[]" replaced with your own identifying # information: Portions Copyright [yyyy] [name of copyright owner] # # CDDL HEADER END # # # Copyright 2009 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # # # The mpt_sas driver, as a pHCI driver, must specify the vHCI class it # belongs to(scsi_vhci). # ddi-vhci-class="scsi_vhci"; # # I/O multipathing feature (MPxIO) can be enabled or disabled using # mpxio-disable property. Setting mpxio-disable="no" will activate # I/O multipathing; setting mpxio-disable="yes" disables the feature. # # Global mpxio-disable property: # # To globally enable MPxIO on all LSI MPT SAS 2.0 controllers set: # mpxio-disable="no"; # # To globally disable MPxIO on all LSI MPT SAS 2.0 controllers set: # mpxio-disable="yes"; # # You can also enable or disable MPxIO on a per HBA basis. # Per HBA settings override the global setting for the specified HBAs. # To disable MPxIO on a controller whose parent is /pci at 7c0/pci at 0/pci at 9 # and the unit-address is "0" set: # name="mpt_sas" parent="/pci at 7c0/pci at 0/pci at 9" unit-address="0" mpxio-disable="yes"; # mpxio-disable="no"; ------------------------------------------------------------------------------------------- Ok, so in regards to multipath, looking at format(1) I can see that scsi_vhci doesn't have your drives whitelisted for multipath support, so that's why you're seeing lines such as: 14. c4t5000C5002BD75C05d0 /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w5000c5002bd75c05,0 in format(1) output. If scsi_vhci had detected your disks, the paths would start with "/scsi_vhci..." rather than "/pci...". No problem, you can manually whitelist the disks (here's the full manual): http://docs.oracle.com/cd/E19253-01/816-5177/6mbbc4gal/index.html In principle what you need to do is add a line like this: device-type-scsi-options-list = "HP EG0300FAWHV", "f_sym"; Please note that there are 6 spaces following 'HP' in the above identifier - copy it exactly as it appears here (scsi_vhci needs the vendor ID to be exactly 8 characters long, so we need to pad it with spaces). After you've done this you should be able to reload the driver configuration (via "update_drv scsi_vhci"), your drives should reappear in the "/scsi_vhci..." device path with the correct number (4 drives, not 8) and "mpathadm list lu" should display them and the paths to them. If update_drv is going to be giving you trouble, a reboot might be needed (haven't tested this in a while, so I don't remember). You can double-check the Vendor ID and Product ID that you need to enter in there by running "prtconf -v" and looking for the drive in the device tree. You should be able to see lines like these: name='inquiry-product-id' type=string items=1 value='EG0300FAWHV' name='inquiry-vendor-id' type=string items=1 value='HP' Cheers, -- Saso From skiselkov.ml at gmail.com Tue Dec 3 10:41:26 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Tue, 03 Dec 2013 10:41:26 +0000 Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <1251946144.85273.1386058387233.JavaMail.zimbra@cantekstil.com.tr> References: <154455286.84861.1386058128380.JavaMail.zimbra@cantekstil.com.tr> <1251946144.85273.1386058387233.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <529DB556.3080605@gmail.com> On 12/3/13, 8:13 AM, Hafiz Rafibeyli wrote: > Saso ,I will try edit /kernel/drv/scsi_vhci.conf as you described and will inform you. > > why these new disks not dedected by scsi_vhci automatically? > > is this because of settings in my /kernel/drv/mpt.conf and /kernel/drv/mpt_sas.conf files? No, it has nothing to do with mpt.conf (which is a different configuration file for a different driver altogether). The reason is that scsi_vhci contains a whitelist of devices and associated failover modules (i.e. methods for implementing multipathing). If your device isn't whitelisted, then scsi_vhci doesn't know which failover module to use and instead, as a failsafe, decides to do nothing. You can find more info on the scsi_vhci man page: http://docs.oracle.com/cd/E19253-01/816-5177/6mbbc4gal/index.html Cheers, -- Saso From Ben.Kitching at Jigsaw24.com Tue Dec 3 13:21:36 2013 From: Ben.Kitching at Jigsaw24.com (Ben Kitching) Date: Tue, 3 Dec 2013 13:21:36 +0000 Subject: [OmniOS-discuss] Keep losing access to tape drive In-Reply-To: <529DB556.3080605@gmail.com> References: <154455286.84861.1386058128380.JavaMail.zimbra@cantekstil.com.tr> <1251946144.85273.1386058387233.JavaMail.zimbra@cantekstil.com.tr> <529DB556.3080605@gmail.com> Message-ID: Hi There, I?m hoping someone can help with a problem I have. I have a OmniOS r151006 box with a tape drive attached. I?m using the Supermicro 36 bay chassis with the X9DRD-7LN4F-JBOD motherboard. I have the drives for my zpools connected via the expander to the onboard LSI 2308, I then have an LSI 9207-8e which the tape drive is connected to, the drive is a HP Ultrium inside a Quantum Scalar i40 library. The drive was detected automatically but we had to add the library using SGEN via the following commands: root at XXXXXXX:/etc# rem_drv sgen root at XXXXXXX:/etc# add_drv -i 'scsiclass,08? sgen The tape drive appears to work, it is detected by our backup software (Presstore P5.0.6) along with the library. However it keeps hanging on us, Presstore and any other apps that try to probe it over the SAS bus just hang requiring me to reboot the box to restore access. Typically I?ll write an amount of data to it before the apps just lose access, seemingly waiting for a reply of some kind. I?m unable to kill these processes with -9 indicating that they are waiting on some kind of kernel call. When I run mt to check the status of the drive it acts a little strangely, here is the output from a freshly rebooted box: root at MAVEDITSAN02:~# mt -f /dev/rmt/0 config "HP Ultrium 6-SCSI", "HP Ultrium 6-SCSI ", "CFGHPULTRIUM6SCSI"; CFGHPULTRIUM6SCSI = 2,0x3B,0,0x1018619,4,0x58,0x58,0x5A,0x5A,3,60,1200,600,1200,600,600,18000; root at MAVEDITSAN02:~# mt -f /dev/rmt/0 status ^C Asking for the status more often than not makes it hang If I run the same commands after it has hung I get this: root at MAVEDITSAN02:~# mt -f /dev/rmt/0 status /dev/rmt/0: Device busy root at MAVEDITSAN02:~# mt -f /dev/rmt/0 config /dev/rmt/0: Device busy The output of what are hopefully some relevant commands are below, I have truncated the output to only show tape drive related stuff: root at MAVEDITSAN02:~# uname -a SunOS MAVEDITSAN02 5.11 omnios-b281e50 i86pc i386 i86pc root at XXXXXXX:/etc# dmesg Dec 2 10:00:04 MAVEDITSAN02 scsi: [ID 583861 kern.info] st1 at mpt_sas5: unit-address w500308c38dc02001,0: w500308c38dc02001,0 Dec 2 10:00:04 MAVEDITSAN02 genunix: [ID 936769 kern.info] st1 is /pci at 0,0/pci8086,3c02 at 1/pci1000,3040 at 0/iport at 8/tape at w500308c38dc02001,0 Dec 2 10:00:04 MAVEDITSAN02 scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,3c02 at 1/pci1000,3040 at 0/iport at 8/tape at w500308c38dc02001,0 (st1): Dec 2 10:00:04 MAVEDITSAN02 root at XXXXXXX:/etc# prtconf -v value='scsi_vhci' name='scsi-iports' type=string items=2 dev=none value='scsi_vhci' name='scsi-tag-age-limit' type=int items=1 name='scsi-selection-timeout' type=int items=1 name='scsi-watchdog-tick' type=int items=1 name='scsi-reset-delay' type=int items=1 name='scsi-options' type=int items=1 name='scsi-enumeration' type=int items=1 name='scsi-iport' type=string items=1 dev_path=/pci at 0,0/pci8086,3c02 at 1/pci1000,3040 at 0/iport at 8:scsi value='scsi' value='scsiclass,01R.vHP.pUltrium_6-SCSI.r32CZ' + 'scsiclass,01.vHP.pUltrium_6-SCSI.r32CZ' + 'scsiclass,01R.vHP.pUltrium_6-SCSI' + 'scsiclass,01.vHP.pUltrium_6-SCSI' + 'scsiclass,01R' + 'scsiclass,01' + 'scsiclass' value='scsi' value='scsiclass,08R.vQUANTUM.pScalar_i40-i80.r150G' + 'scsiclass,08.vQUANTUM.pScalar_i40-i80.r150G' + 'scsiclass,08R.vQUANTUM.pScalar_i40-i80' + 'scsiclass,08.vQUANTUM.pScalar_i40-i80' + 'scsiclass,08R' + 'scsiclass,08' + 'scsiclass' dev_link=/dev/scsi/changer/c0t500308C38DC02001d1 value='scsi_vhci' name='scsi-tag-age-limit' type=int items=1 name='scsi-selection-timeout' type=int items=1 name='scsi-watchdog-tick' type=int items=1 name='scsi-reset-delay' type=int items=1 name='scsi-options' type=int items=1 name='scsi-enumeration' type=int items=1 name='scsi-iport' type=string items=1 dev_path=/pci at 0,0/pci8086,3c02 at 1/pci1000,3040 at 0/iport at v0:scsi value='scsi_vhci' name='scsi-iports' type=string items=3 dev=none value='scsi_vhci' name='scsi-tag-age-limit' type=int items=1 name='scsi-selection-timeout' type=int items=1 name='scsi-watchdog-tick' type=int items=1 name='scsi-reset-delay' type=int items=1 name='scsi-options' type=int items=1 name='scsi-enumeration' type=int items=1 name='scsi-iport' type=string items=1 dev_path=/pci at 0,0/pci8086,3c06 at 2,2/pci15d9,691 at 0/iport at f0:scsi value='scsi' value='scsiclass,0d.vLSI.pSAS2X28.r0e12' + 'scsiclass,0d.vLSI.pSAS2X28' + 'scsiclass,0d' + 'scsiclass' value='scsi_vhci' name='scsi-tag-age-limit' type=int items=1 name='scsi-selection-timeout' type=int items=1 name='scsi-watchdog-tick' type=int items=1 name='scsi-reset-delay' type=int items=1 name='scsi-options' type=int items=1 name='scsi-enumeration' type=int items=1 name='scsi-iport' type=string items=1 dev_path=/pci at 0,0/pci8086,3c06 at 2,2/pci15d9,691 at 0/iport at f:scsi value='scsi' value='scsiclass,0d.vLSI.pSAS2X36.r0e12' + 'scsiclass,0d.vLSI.pSAS2X36' + 'scsiclass,0d' + 'scsiclass' value='scsi_vhci' name='scsi-tag-age-limit' type=int items=1 name='scsi-selection-timeout' type=int items=1 name='scsi-watchdog-tick' type=int items=1 name='scsi-reset-delay' type=int items=1 name='scsi-options' type=int items=1 name='scsi-enumeration' type=int items=1 name='scsi-iport' type=string items=1 dev_path=/pci at 0,0/pci8086,3c06 at 2,2/pci15d9,691 at 0/iport at v0:scsi name='scsi-binding-set' type=string items=1 name='scsi-tag-age-limit' type=int items=1 name='scsi-selection-timeout' type=int items=1 name='scsi-watchdog-tick' type=int items=1 name='scsi-reset-delay' type=int items=1 name='scsi-options' type=int items=1 name='scsi-enumeration' type=int items=1 value='scsi' value='scsiclass,00.vATA.pSamsung_SSD_840.r5B0Q' + 'scsiclass,00.vATA.pSamsung_SSD_840' + 'scsiclass,00' + 'scsiclass' value='scsi' value='scsi' value='scsiclass,00.vATA.pSamsung_SSD_840.r5B0Q' + 'scsiclass,00.vATA.pSamsung_SSD_840' + 'scsiclass,00' + 'scsiclass' value='scsi' value='scsi' value='scsiclass,00.vATA.pTOSHIBA_THNSNH06.rN102' + 'scsiclass,00.vATA.pTOSHIBA_THNSNH06' + 'scsiclass,00' + 'scsiclass' value='scsi' value='scsi' value='scsiclass,00.vATA.pTOSHIBA_THNSNH06.rN102' + 'scsiclass,00.vATA.pTOSHIBA_THNSNH06' + 'scsiclass,00' + 'scsiclass' value='scsi' iscsi, instance #0 name='scsi-tag-age-limit' type=int items=1 name='scsi-selection-timeout' type=int items=1 name='scsi-watchdog-tick' type=int items=1 name='scsi-reset-delay' type=int items=1 name='scsi-options' type=int items=1 name='scsi-enumeration' type=int items=1 dev_path=/iscsi:devctl Any help is much appreciated. -- Ben ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafibeyli at gmail.com Tue Dec 3 13:24:43 2013 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Tue, 3 Dec 2013 15:24:43 +0200 (EET) Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <1499014801.101107.1386076351199.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <840290310.103154.1386077083914.JavaMail.zimbra@cantekstil.com.tr> Saso I did as you said, but on my test 24x chassis(everything same with prod chassis,only difference test chassis has 1 LSI controller) I added following lines to /kernel/drv/scsi_vhci.conf(being careful with spaces) device-type-scsi-options-list = "HP EG0300FARTT", "f_sym", "HP EG0300FARTT", "f_sym", "HP EG0300FARTT", "f_sym", "HP EG0300FARTT", "f_sym"; after omnios reboot,format output was same as before. as you see last 4 HP disks(wich I added to test chassis for testing) starting with /pci@ am I doing something wrong? :~# format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c1t5000C5004FEB5CD4d0 /scsi_vhci/disk at g5000c5004feb5cd4 1. c1t5000C5004FEB205Ad0 /scsi_vhci/disk at g5000c5004feb205a 2. c1t5000C5004FEBCDA1d0 /scsi_vhci/disk at g5000c5004febcda1 3. c1t5000C5004FED9BE6d0 /scsi_vhci/disk at g5000c5004fed9be6 4. c1t5000C5004FF4A4AEd0 /scsi_vhci/disk at g5000c5004ff4a4ae 5. c1t5000C5004FF4E0F9d0 /scsi_vhci/disk at g5000c5004ff4e0f9 6. c1t50000393DB700B6Ad0 /scsi_vhci/disk at g50000393db700b6a 7. c1t50000393DB700B6Bd0 /scsi_vhci/disk at g50000393db700b6b 8. c1t50000393DB700B68d0 /scsi_vhci/disk at g50000393db700b68 9. c1t50000393DB700B69d0 /scsi_vhci/disk at g50000393db700b69 10. c1t500003944B703F9Bd0 /scsi_vhci/disk at g500003944b703f9b 11. c1t500003944B703F9Dd0 /scsi_vhci/disk at g500003944b703f9d 12. c1t500003944B703F9Fd0 /scsi_vhci/disk at g500003944b703f9f 13. c1t500003944B783D3Fd0 /scsi_vhci/disk at g500003944b783d3f 14. c1t500003944B80451Ed0 /scsi_vhci/disk at g500003944b80451e 15. c1t500003944B80451Fd0 /scsi_vhci/disk at g500003944b80451f 16. c1t500003944B704306d0 /scsi_vhci/disk at g500003944b704306 17. c1t500003944B804521d0 /scsi_vhci/disk at g500003944b804521 18. c1t500003944B804534d0 /scsi_vhci/disk at g500003944b804534 19. c3t0d0 /pci at 0,0/pci15d9,100 at 1f,2/disk at 0,0 20. c3t1d0 /pci at 0,0/pci15d9,100 at 1f,2/disk at 1,0 21. c4t500000E1168BB382d0 /pci at 0,0/pci8086,340e at 7/pci15d9,691 at 0/iport at f/disk at w500000e1168bb382,0 22. c4t500000E11693F232d0 /pci at 0,0/pci8086,340e at 7/pci15d9,691 at 0/iport at f/disk at w500000e11693f232,0 23. c4t500000E11696D5A2d0 /pci at 0,0/pci8086,340e at 7/pci15d9,691 at 0/iport at f/disk at w500000e11696d5a2,0 24. c4t500000E116974FB2d0 /pci at 0,0/pci8086,340e at 7/pci15d9,691 at 0/iport at f/disk at w500000e116974fb2,0 On 12/3/13, 8:13 AM, Hafiz Rafibeyli wrote: > Saso ,I will try edit /kernel/drv/scsi_vhci.conf as you described and will inform you. > > why these new disks not dedected by scsi_vhci automatically? > > is this because of settings in my /kernel/drv/mpt.conf and /kernel/drv/mpt_sas.conf files? No, it has nothing to do with mpt.conf (which is a different configuration file for a different driver altogether). The reason is that scsi_vhci contains a whitelist of devices and associated failover modules (i.e. methods for implementing multipathing). If your device isn't whitelisted, then scsi_vhci doesn't know which failover module to use and instead, as a failsafe, decides to do nothing. You can find more info on the scsi_vhci man page: http://docs.oracle.com/cd/E19253-01/816-5177/6mbbc4gal/index.html Cheers, -- Saso From esproul at omniti.com Tue Dec 3 15:02:16 2013 From: esproul at omniti.com (Eric Sproul) Date: Tue, 3 Dec 2013 10:02:16 -0500 Subject: [OmniOS-discuss] Re-installing OmniOS after Crash In-Reply-To: <529D82D2.5080900@gnaa.net> References: <529D82D2.5080900@gnaa.net> Message-ID: On Tue, Dec 3, 2013 at 2:05 AM, Geoff Nordli wrote: > I am running bloody: omnios-df542ea (from the usb image on the web site) > > I am hitting the error: > > root at ma-back1:~# pkg update > web/ca-bundle at 5.11,5.11-0.151007:20130823T212116Z > > Creating Plan / > pkg update: The certificate which issued this > certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151007 Release > Signing Certificate/emailAddress=omnios-support at omniti.com could not be > found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI > Certificate Authority > The package involved > is:pkg://omnios/system/library/mozilla-nss at 3.14.3,5.11-0.151007:20131008T151300Z > > Clues on how to get past this? The version of bloody currently linked on the website is actually r151005 (it sucks, I know-- we were not good about updating that through the last cycle). You have to somehow get to a version of r151007 so that you can install these packages (the 007 version of ca-bundle depends on an nss version that's likely higher than what you have, and the latest version of nss is signed). You might need to upgrade to r151006 (using the release publisher's URL temporarily) and then to r151007. r151006 has unsigned versions of package/pkg and web/ca-bundle that have the necessary bits to allow moving to signed packages. I've not actually tried this, but *in theory* it should work. Eric From henson at acm.org Tue Dec 3 20:31:15 2013 From: henson at acm.org (Paul B. Henson) Date: Tue, 3 Dec 2013 12:31:15 -0800 Subject: [OmniOS-discuss] ipmievd smf manifest in system/management/ipmitool In-Reply-To: <0a7c01ceefa0$5c71c9d0$15555d70$@acm.org> References: <0a7a01ceef9f$024fdd30$06ef9790$@acm.org> <0a7c01ceefa0$5c71c9d0$15555d70$@acm.org> Message-ID: <20131203203115.GB4044@bender.unx.csupomona.edu> On Mon, Dec 02, 2013 at 12:52:02PM -0800, Paul B. Henson wrote: > > > > The smf manifest for ipmievd in the ipmitool package has a hardcoded > > dependency on the default instance of system-log: > > Oh, also, the startup script /lib/svc/method/svc-ipmievd looks for /dev/bmc, > that needs to be /dev/ipmi0 now. Looks like the latter issue is already fixed in bloody, sorry for the noise. Any thoughts though on updating the manifest to remove the specific dependency on the default instance of syslog? I could submit a pull request, but given the diff is just --- ipmievd.xml.orig 2013-12-03 12:29:01.167969769 -0800 +++ ipmievd.xml 2013-12-02 12:42:50.933837276 -0800 @@ -61,7 +61,7 @@ restart_on='none' type='service'> + value='svc:/system/system-log'/> that seems more overhead than someone just changing it directly, assuming there are no objections. Thanks... From esproul at omniti.com Tue Dec 3 21:27:39 2013 From: esproul at omniti.com (Eric Sproul) Date: Tue, 3 Dec 2013 16:27:39 -0500 Subject: [OmniOS-discuss] ipmievd smf manifest in system/management/ipmitool In-Reply-To: <20131203203115.GB4044@bender.unx.csupomona.edu> References: <0a7a01ceef9f$024fdd30$06ef9790$@acm.org> <0a7c01ceefa0$5c71c9d0$15555d70$@acm.org> <20131203203115.GB4044@bender.unx.csupomona.edu> Message-ID: On Tue, Dec 3, 2013 at 3:31 PM, Paul B. Henson wrote: > --- ipmievd.xml.orig 2013-12-03 12:29:01.167969769 -0800 > +++ ipmievd.xml 2013-12-02 12:42:50.933837276 -0800 > @@ -61,7 +61,7 @@ > restart_on='none' > type='service'> > - value='svc:/system/system-log:default'/> > + value='svc:/system/system-log'/> > > > that seems more overhead than someone just changing it directly, > assuming there are no objections. Seems fairly innocuous. Just committed: https://github.com/omniti-labs/omnios-build/commit/bc4784e8d5911f4dbac3ff511383a4aff9bfbbb2 That will be in the r151008 release too. Thanks! Eric From skiselkov.ml at gmail.com Wed Dec 4 11:27:01 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Wed, 04 Dec 2013 11:27:01 +0000 Subject: [OmniOS-discuss] 2x acctual disk quantity In-Reply-To: <840290310.103154.1386077083914.JavaMail.zimbra@cantekstil.com.tr> References: <840290310.103154.1386077083914.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <529F1185.8090804@gmail.com> Just for the record and as a follow-up, I got the variable name wrong, the correct name should have been: scsi-vhci-failover-override = "HP EG0300", "f_sym", "HP DG0300", "f_sym"; With this setting, the disks got correctly discovered and set up by scsi_vhci. -- Saso From emunch at utmi.in Wed Dec 4 15:01:47 2013 From: emunch at utmi.in (Sam M) Date: Wed, 4 Dec 2013 20:31:47 +0530 Subject: [OmniOS-discuss] Fixing a Package With Errors Message-ID: Hello. I'm running OmniOS Bloody. I was getting an error with visudo so I tried to fix this by re-0nstalling the package in question. But I'm unable to. How can I fix this? How do I create/modify an alternate boot environment? BTW, I upgraded from Release to Bloody, so I booted into a Release boot envirnment, and I'm seeing the same error with libc.so.1 as in Bloody. TIA. Sam System *# uname -a* SunOS sequoia 5.11 omnios-e97fba8 i86pc i386 i86pc Error - *# visudo* ld.so.1: visudo: fatal: libc.so.1: version 'ILLUMOS_0.7' not found (required by file /usr/sbin/visudo) ld.so.1: visudo: fatal: libc.so.1: open failed: No such file or directory Killed pkg fix error - *# pkg fix pkg://omnios/system/library * Verifying: pkg://omnios/system/library ERROR file: lib/libc.so.1 Elfhash: c31add3bd373a101cb7aa14a2185beef9bd6ad61 should be 2f678d3e88ee49238a7c4b87dfdcc92837ea5814 Created ZFS snapshot: 2013-12-04-14:00:23 Repairing: pkg://omnios/system/library pkg: Requested "fix" operation would affect files that cannot be modified in live image. Please retry this operation on an alternate boot environment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Wed Dec 4 22:37:57 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 4 Dec 2013 14:37:57 -0800 Subject: [OmniOS-discuss] ipmievd smf manifest in system/management/ipmitool In-Reply-To: References: <0a7a01ceef9f$024fdd30$06ef9790$@acm.org> <0a7c01ceefa0$5c71c9d0$15555d70$@acm.org> <20131203203115.GB4044@bender.unx.csupomona.edu> Message-ID: <028601cef141$7ca43e70$75ecbb50$@acm.org> > From: Eric Sproul [mailto:esproul at omniti.com] > Sent: Tuesday, December 03, 2013 1:28 PM > > Seems fairly innocuous. Just committed: Excellent, thank you sir :). > That will be in the r151008 release too. Cool, looking forward to it. From esproul at omniti.com Thu Dec 5 22:00:18 2013 From: esproul at omniti.com (Eric Sproul) Date: Thu, 5 Dec 2013 17:00:18 -0500 Subject: [OmniOS-discuss] New stable release: r151008 Message-ID: >From the Better-Late-Than-Never department: r151008 is now available. * Highlights * All packages shipped as part of OmniOS r151008 are now cryptographically signed. * All package signatures will be verified by default, including on systems upgraded from r151006. * More strict policies regarding signatures are possible. See "signature-policy" under IMAGE PROPERTIES in the pkg(1) man page for details. * New ZFS pool features: spacemap_histogram, multi_vdev_crash_dump, extensible_dataset * see zpool-features(5) for details on what these features do. * Rewritten ZFS write throttle to produce more consistent delays under constant load * This supersedes the per-zone I/O throttle feature taken from illumos-joyent in r151006. We are investigating a compatible feature set. * ZFS L2ARC compression * Dump volumes may now be placed on multi-vdev pools such as raidz, striped mirrors * Oracle Java SE 6 replaced with OpenJDK 7 * GCC 4.8.1 * New, open source driver for HP SmartArray controllers: cpqary(7D) * IPD, the Internet Packet Disturber, is a new kernel facility for simulating pathological networks by inducing packet drops, delays and corruption. * available in pkg:/network/ipd and administered by ipdadm(1M). * usable by the global zone and zones with exclusive IP stacks. Release notes: http://omnios.omniti.com/wiki.php/ReleaseNotes#r151008 Upgrade instructions: http://omnios.omniti.com/wiki.php/Upgrade_r151006_r151008 Installation media: http://omnios.omniti.com/media/OmniOS_Text_r151008e.iso http://omnios.omniti.com/media/OmniOS_Text_r151008e.usb-dd http://omnios.omniti.com/media/r151008e.zfs.bz2 (ZFS image, for use with Kayak) Package catalog: http://pkg.omniti.com/omnios/release/en/catalog.shtml From mir at miras.org Fri Dec 6 00:59:46 2013 From: mir at miras.org (Michael Rasmussen) Date: Fri, 6 Dec 2013 01:59:46 +0100 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: References: Message-ID: <20131206015946.06867a39@sleipner.datanom.net> On Thu, 5 Dec 2013 17:00:18 -0500 Eric Sproul wrote: > > Release notes: > http://omnios.omniti.com/wiki.php/ReleaseNotes#r151008 > > Upgrade instructions: > http://omnios.omniti.com/wiki.php/Upgrade_r151006_r151008 > How does one upgrade from 15007? My bloody has not been updated for several month awaiting the release of 15008. Changing publisher to release resolves in the following: pkg update package/pkg at 0.5.11,5.11-0.151008:20131204T210233Z web/ca-bundle at 5.11,5.11-0.151008:20131204T025213Z Creating Plan \ pkg update: No matching version of package/pkg can be installed: Reject: pkg://omnios/package/pkg at 0.5.11,5.11-0.151008:20131204T210233Z Reason: All versions matching 'require' dependency pkg:/system/library at 0.5.11,5.11-0.151008 are rejected Reject: pkg://omnios/system/library at 0.5.11,5.11-0.151008:20131204T024825Z Reason: This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151007:20130930T235407Z This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151007:20130813T144617Z If I change back to bloody I also stuck due to missing certitficates so what to do? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- solaris is bsd, so it should work * Espy takes wichert's crack pipe away -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mir at miras.org Fri Dec 6 02:26:42 2013 From: mir at miras.org (Michael Rasmussen) Date: Fri, 6 Dec 2013 03:26:42 +0100 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: <20131206015946.06867a39@sleipner.datanom.net> References: <20131206015946.06867a39@sleipner.datanom.net> Message-ID: <20131206032642.158b351f@sleipner.datanom.net> On Fri, 6 Dec 2013 01:59:46 +0100 Michael Rasmussen wrote: > How does one upgrade from 15007? To answer myself: pkg set-publisher --approve-ca-cert /etc/ssl/pkg/OmniTI_CA.pem omnios But after upgrading and booting the new boot environment I get this error: [ Dec 6 01:17:25 Executing start method ("/lib/svc/method/svc-intrd"). ] ld.so.1: perl: fatal: libc.so.1: version 'ILLUMOS_0.6' not found (required by file /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int/CORE/libperl.so) ld.so.1: perl: fatal: libc.so.1: open failed: No such file or directory [ Dec 6 01:17:25 Method "start" exited with status 0. ] [ Dec 6 01:17:25 Stopping because all processes in service exited. ] [ Dec 6 01:17:26 Executing stop method (:kill). ] [ Dec 6 01:17:26 Restarting too quickly, changing state to maintenance. ] How can I resolve this? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- I am NOT a kludge! I am a computer! -- tts -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From cnehren+omnios-discuss at omniti.com Fri Dec 6 03:27:10 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Thu, 5 Dec 2013 22:27:10 -0500 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: <20131206032642.158b351f@sleipner.datanom.net> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> Message-ID: <20131206032710.GJ2078@eschaton.local> On Fri, Dec 06, 2013 at 03:26:42 +0100, Michael Rasmussen wrote: > On Fri, 6 Dec 2013 01:59:46 +0100 > Michael Rasmussen wrote: > > > How does one upgrade from 15007? > To answer myself: > pkg set-publisher --approve-ca-cert /etc/ssl/pkg/OmniTI_CA.pem omnios > > But after upgrading and booting the new boot environment I get this > error: > [ Dec 6 01:17:25 Executing start method ("/lib/svc/method/svc-intrd"). > ] ld.so.1: perl: fatal: libc.so.1: version 'ILLUMOS_0.6' not found > (required by > file /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int/CORE/libperl.so) > ld.so.1: perl: fatal: libc.so.1: open failed: No such file or directory > [ Dec 6 01:17:25 Method "start" exited with status 0. ] [ Dec 6 > 01:17:25 Stopping because all processes in service exited. ] [ Dec 6 > 01:17:26 Executing stop method (:kill). ] [ Dec 6 01:17:26 Restarting > too quickly, changing state to maintenance. ] We don't support upgrading from bloody*. It's very much an "if it breaks, you get to keep both pieces" system, much the way Debian sid or FreeBSD -CURRENT are. That said, I had that issue when I managed an incomplete upgrade on a personal box. You'll want to reboot into the previous BE and do a 'pkg update -nv' to see what's being upgraded. I'd guess that something is holding back a required package but need to see what you have installed and your publishers to be able to give more advice. * In fact we don't support bloody at all; there's a reason it has the name it does. -- Chris Nehren Site Reliability Engineer, OmniTI From henson at acm.org Fri Dec 6 03:35:12 2013 From: henson at acm.org (Paul B. Henson) Date: Thu, 5 Dec 2013 19:35:12 -0800 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: <20131206032710.GJ2078@eschaton.local> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> Message-ID: <057901cef234$2d82c890$888859b0$@acm.org> > From: Chris Nehren > Sent: Thursday, December 05, 2013 7:27 PM > > In fact we don't support bloody at all; there's a reason it has > the name it does. Because it's bloody awesome, right ;)? (I don't think there is an emoticon for "imagine that was spoken in a British accent" :) ). From skiselkov.ml at gmail.com Fri Dec 6 04:14:28 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Fri, 06 Dec 2013 04:14:28 +0000 Subject: [OmniOS-discuss] Bizarre zfs-related hang in omnios r151008 on 1-CPU VM Message-ID: <52A14F24.7080308@gmail.com> I'm investigating a bizarre hang situation which I noticed by accident on the latest stable omnios release. When I'm running in VMware Fusion on a 1-CPU VM and doing any significant write IO to the pool (e.g. just dd'ing something around is enough to trigger this), the VM will, with 100% certainty, hang. Console input works, but all userspace programs are stopped and nothing responds (e.g. attempting to telnet to sshd over the network establishes the socket, but then sshd doesn't print the version string). Using some dtrace foo and kmdb I was able to trace it (roughly, the exact stack trace changes between hangs, which is mighty weird in itself): atomic_dec_32_nv+8() dbuf_read+0x179(ffffff00d2393600, ffffff00c72f98f0, a) dmu_tx_check_ioerr+0x76(ffffff00c72f98f0, ffffff00d2279cf0, 0, 1e0) dmu_tx_count_write+0x395(ffffff00ce0536e0, 3c04000, 4000) dmu_tx_hold_write+0x5a(ffffff00d1a55300, 4009, 3c04000, 4000) zfs_write+0x3e3(ffffff00d09ef540, ffffff00028e7e60, 0, ffffff00cd511748, 0) fop_write+0x5b(ffffff00d09ef540, ffffff00028e7e60, 0, ffffff00cd511748, 0) write+0x250(1, 440660, 4000) sys_syscall+0x17a() (usually the trace is identical up to dmu_tx_hold_write) I can definitely confirm that this doesn't happen on omnios r151006 and it doesn't happen on my vanilla kernels either. My suspicion is that something got botched in the "OMNIOS#72 Integrate Joyent updated zone write throttle" commit, but I can't put my finger on it. Can somebody please confirm this? Cheers, -- Saso From Rob at Logan.com Fri Dec 6 05:39:12 2013 From: Rob at Logan.com (Rob Logan) Date: Fri, 6 Dec 2013 00:39:12 -0500 Subject: [OmniOS-discuss] [SPAM] Bizarre zfs-related hang in omnios r151008 on 1-CPU VM In-Reply-To: <52A14F24.7080308@gmail.com> References: <52A14F24.7080308@gmail.com> Message-ID: <8FBCE2ED-CD72-4008-A293-CAFD97AC4870@Logan.com> > on the latest stable omnios release. When I'm running in VMware Fusion > on a 1-CPU VM and doing any significant write IO to the pool (e.g. just > atomic_dec_32_nv+8() > dbuf_read+0x179(ffffff00d2393600, ffffff00c72f98f0, a) > dmu_tx_check_ioerr+0x76(ffffff00c72f98f0, ffffff00d2279cf0, 0, 1e0) > dmu_tx_count_write+0x395(ffffff00ce0536e0, 3c04000, 4000) > dmu_tx_hold_write+0x5a(ffffff00d1a55300, 4009, 3c04000, 4000) > zfs_write+0x3e3(ffffff00d09ef540, ffffff00028e7e60, 0, > ffffff00cd511748, 0) > fop_write+0x5b(ffffff00d09ef540, ffffff00028e7e60, 0, > ffffff00cd511748, 0) > write+0x250(1, 440660, 4000) > sys_syscall+0x17a() doing the normal re-write of root in r151008 three times into lz4 didn?t have any issues on my 2cpu 2G vbox root at OmniOS:~# lspci 00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter 00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service 00:05.0 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio Controller (rev 01) 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08) 00:11.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 02) 00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) 00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02) 00:1f.4 USB controller: Apple Inc. KeyLargo/Intrepid USB root at OmniOS:~# zfs get all | grep refcompressratio rpool refcompressratio 1.00x - rpool/ROOT refcompressratio 1.00x - rpool/ROOT/start refcompressratio 1.85x - rpool/ROOT/work refcompressratio 1.98x - rpool/ROOT/work at 2013-12-05-19:24:16 refcompressratio 1.85x - not sure how to reproduce. Rob From ci4 at outlook.com Fri Dec 6 06:59:12 2013 From: ci4 at outlook.com (outlook) Date: Fri, 6 Dec 2013 06:59:12 +0000 Subject: [OmniOS-discuss] New stable release: r151008 Message-ID: Just for the record - I updated my 'bloody' system almost without a problem overnight. It already had the latest 151007, I didn't need to update the certificates or pkg, just changed the publisher, refreshed and updated. Half way through it stopped due to some timeout, I guess (service not available, maybe the server at Omniti was restarted or it was overloaded). I then just repeated the command and all is well now. Chavdar Ivanov --- Original Message --- From: "Paul B. Henson" Sent: 6 December 2013 03:38 To: "'Chris Nehren'" Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] New stable release: r151008 > From: Chris Nehren > Sent: Thursday, December 05, 2013 7:27 PM > > In fact we don't support bloody at all; there's a reason it has > the name it does. Because it's bloody awesome, right ;)? (I don't think there is an emoticon for "imagine that was spoken in a British accent" :) ). _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From omnios at citrus-it.net Fri Dec 6 10:35:44 2013 From: omnios at citrus-it.net (Andy) Date: Fri, 6 Dec 2013 10:35:44 +0000 (GMT) Subject: [OmniOS-discuss] Problem upgrading to r151008 Message-ID: Hi, I did a test upgrade on one of our servers last night and hit problems. The upgrade process itself seemed to work fine but on reboot the new environment wasn't usable due to a version dependency on libc.. I didn't have much time to test so rolled back for now. Any thoughts on what might have gone wrong? Thanks, Andy pickle# (5) pkg update --no-backup-be package/pkg at 0.5.11,5.11-0.151006:20130731T192303Z web/ca-bundle at 5.11,5.11-0.151006:20130718T173831Z Packages to update: 1 Create boot environment: No Create backup boot environment: Yes DOWNLOAD PKGS FILES XFER (MB) Completed 1/1 2/2 0.1/0.1 PHASE ACTIONS Install Phase 1/1 Update Phase 3/3 PHASE ITEMS Package State Update Phase 2/2 Package Cache Update Phase 1/1 Image State Update Phase 2/2 PHASE ITEMS Reading Existing Index 8/8 Indexing Packages 1/1 pickle# (8) beadm list BE Active Mountpoint Space Policy Created r151006j - - 7.20M static 2013-07-09 21:11 r151006n NR / 3.16G static 2013-08-02 14:13 pickle# (10) pkg update --no-backup-be runtime/perl/manual at 5.16.1,5.11-0.151006 Packages to update: 1 Create boot environment: No Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) Completed 1/1 45/45 0.6/0.6 PHASE ACTIONS Update Phase 49/49 PHASE ITEMS Package State Update Phase 2/2 Package Cache Update Phase 1/1 Image State Update Phase 2/2 pkg list runtime/pe PHASE ITEMS Reading Existing Index 8/8r Indexing Packages 1/1 pickle# (11) pkg list runtime/perl-64 pkg list: no packages matching 'runtime/perl-64' installed pickle# (14) pkg update --be-name=r151008e Packages to update: 96 Create boot environment: Yes Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) Completed 96/96 8079/8079 185.6/185.6 PHASE ACTIONS Removal Phase 6338/6338 Install Phase 4145/4145 Update Phase 4827/4827 PHASE ITEMS Package State Update Phase 192/192 Package Cache Update Phase 96/96 Image State Update Phase 2/2 PHASE ITEMS Reading Existing Index 8/8 Indexing Packages 96/96 Optimizing Index... PHASE ITEMS Indexing Packages 467/467 A clone of r151006n exists and has been updated and activated. On the next boot the Boot Environment r151008e will be mounted on '/'. Reboot when ready to switch to this updated BE. .. one reboot later .. pickle console login: root Password: login: [ID 644210 auth.notice] ROOT LOGIN /dev/console Last login: Thu Dec 5 22:52:00 from 89.248.55.88 ld.so.1: zsh: fatal: libc.so.1: version 'ILLUMOS_0.6' not found (required by file /usr/bin/zsh) ld.so.1: zsh: fatal: libc.so.1: open failed: No such file or directory I did manage to use sftp to change root's shell back to /bin/sh but other tools are broken too. root at pickle:~# pkg list -u ld.so.1: python2.6: fatal: libc.so.1: version 'ILLUMOS_0.6' not found (required by file /usr/lib/amd64/libpython2.6.so.1.0) ld.so.1: python2.6: fatal: libc.so.1: open failed: No such file or directory Killed so I reverted to the previous boot environment which was successful. -- 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 skiselkov.ml at gmail.com Fri Dec 6 10:38:36 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Fri, 06 Dec 2013 10:38:36 +0000 Subject: [OmniOS-discuss] [zfs] Bizarre zfs-related hang in omnios r151008 on 1-CPU VM In-Reply-To: References: <52A14F24.7080308@gmail.com> Message-ID: <52A1A92C.8030900@gmail.com> On 12/6/13, 6:31 AM, Matthew Ahrens wrote: > Be sure you have the following fix; without it I recall seeing spins > from the ZPL similar to that stack trace. With only 1 cpu, if a kernel > thread spins, it can be very hard to get other threads to run. > > commit e722410c49fe67cbf0f639cbcc288bd6cbcf7dd1 > > Author: Matthew Ahrens > > > Date: Tue Nov 26 13:47:33 2013 -0500 > > > 4347 ZPL can use dmu_tx_assign(TXG_WAIT) > > Reviewed by: George Wilson > > > Reviewed by: Adam Leventhal > > > Reviewed by: Dan McDonald > > > Reviewed by: Boris Protopopov > > > Approved by: Dan McDonald > That sounds like pretty much exactly what I hit. Gonna ask the omnios maintainers to reroll a new zfs module and retest. All of my custom kernels are newer than this, so it's likely that that saved my bacon. Cheers, -- Saso From skiselkov.ml at gmail.com Fri Dec 6 10:40:45 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Fri, 06 Dec 2013 10:40:45 +0000 Subject: [OmniOS-discuss] [SPAM] Bizarre zfs-related hang in omnios r151008 on 1-CPU VM In-Reply-To: <8FBCE2ED-CD72-4008-A293-CAFD97AC4870@Logan.com> References: <52A14F24.7080308@gmail.com> <8FBCE2ED-CD72-4008-A293-CAFD97AC4870@Logan.com> Message-ID: <52A1A9AD.7030901@gmail.com> On 12/6/13, 5:39 AM, Rob Logan wrote: > >> on the latest stable omnios release. When I'm running in VMware Fusion >> on a 1-CPU VM and doing any significant write IO to the pool (e.g. just >> atomic_dec_32_nv+8() >> dbuf_read+0x179(ffffff00d2393600, ffffff00c72f98f0, a) >> dmu_tx_check_ioerr+0x76(ffffff00c72f98f0, ffffff00d2279cf0, 0, 1e0) >> dmu_tx_count_write+0x395(ffffff00ce0536e0, 3c04000, 4000) >> dmu_tx_hold_write+0x5a(ffffff00d1a55300, 4009, 3c04000, 4000) >> zfs_write+0x3e3(ffffff00d09ef540, ffffff00028e7e60, 0, >> ffffff00cd511748, 0) >> fop_write+0x5b(ffffff00d09ef540, ffffff00028e7e60, 0, >> ffffff00cd511748, 0) >> write+0x250(1, 440660, 4000) >> sys_syscall+0x17a() > > > doing the normal re-write of root in r151008 three times > into lz4 didn?t have any issues on my 2cpu 2G vbox > > root at OmniOS:~# lspci > 00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter > 00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service > 00:05.0 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio Controller (rev 01) > 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08) > 00:11.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 02) > 00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) > 00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) > 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) > 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02) > 00:1f.4 USB controller: Apple Inc. KeyLargo/Intrepid USB > > root at OmniOS:~# zfs get all | grep refcompressratio > rpool refcompressratio 1.00x - > rpool/ROOT refcompressratio 1.00x - > rpool/ROOT/start refcompressratio 1.85x - > rpool/ROOT/work refcompressratio 1.98x - > rpool/ROOT/work at 2013-12-05-19:24:16 refcompressratio 1.85x - > > not sure how to reproduce. You need a 1-CPU system. As Matt pointed out, the hang is most probably caused by a deadlock that was resolved in e722410. OmniTI: I believe rolling this into the next weekly patch cycle might be kind of important? Cheers, -- Saso From vab at bb-c.de Fri Dec 6 10:48:39 2013 From: vab at bb-c.de (Volker A. Brandt) Date: Fri, 6 Dec 2013 11:48:39 +0100 Subject: [OmniOS-discuss] Problem upgrading to r151008 In-Reply-To: References: Message-ID: <21153.43911.654272.678584@glaurung.bb-c.de> Andy writes: > root at pickle:~# pkg list -u > ld.so.1: python2.6: fatal: libc.so.1: version 'ILLUMOS_0.6' not found > (required by file /usr/lib/amd64/libpython2.6.so.1.0) > ld.so.1: python2.6: fatal: libc.so.1: open failed: No such file or > directory > Killed I had exactly the same problem... > so I reverted to the previous boot environment which was successful. ...and did exactly that, and the previous BE still works. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From jdg117 at elvis.arl.psu.edu Fri Dec 6 13:43:35 2013 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Fri, 06 Dec 2013 08:43:35 -0500 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: Your message of "Thu, 05 Dec 2013 22:27:10 EST." <20131206032710.GJ2078@eschaton.local> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> Message-ID: <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> In message <20131206032710.GJ2078 at eschaton.local>, Chris Nehren writes: >That said, I had that issue when I managed an incomplete upgrade >on a personal box. You'll want to reboot into the previous BE and >do a 'pkg update -nv' to see what's being upgraded. I'd guess >that something is holding back a required package but need to see >what you have installed and your publishers to be able to give >more advice. Upgraded with problem on one r151006 install, and fell over the incompatible libc in another. My pkg update below. John groenveld at acm.org # pkg update -nv Packages to update: 87 Estimated space available: 82.19 GB Estimated space to be consumed: 787.50 MB Create boot environment: No Create backup boot environment: Yes Rebuild boot archive: Yes Changed packages: omnios compress/bzip2 1.0.6,5.11-0.151006:20130506T182454Z -> 1.0.6,5.11-0.151008:20131204T022413Z compress/gzip 1.5,5.11-0.151006:20130506T182516Z -> 1.6,5.11-0.151008:20131204T022413Z compress/p7zip 9.20.1,5.11-0.151006:20130506T182553Z -> 9.20.1,5.11-0.151008:20131204T022414Z compress/unzip 6.0,5.11-0.151006:20130506T182558Z -> 6.0,5.11-0.151008:20131204T022424Z compress/xz 5.0.4,5.11-0.151006:20130506T182624Z -> 5.0.5,5.11-0.151008:20131204T022424Z compress/zip 3.0,5.11-0.151006:20130506T182629Z -> 3.0,5.11-0.151008:20131204T022426Z database/sqlite-3 3.7.14.1,5.11-0.151006:20130506T182707Z -> 3.8.0.2,5.11-0.151008:20131204T022429Z developer/build/gnu-make 3.82,5.11-0.151006:20130506T182730Z -> 3.82,5.11-0.151008:20131204T022435Z developer/build/make 0.5.11,5.11-0.151006:20130506T182754Z -> 0.5.11,5.11-0.151008:20131204T022437Z developer/gnu-binutils 2.23,5.11-0.151006:20130506T182831Z -> 2.23.2,5.11-0.151008:20131204T023046Z developer/lexer/flex 2.5.37,5.11-0.151006:20130506T182848Z -> 2.5.37,5.11-0.151008:20131204T023108Z developer/macro/cpp 0.5.11,5.11-0.151006:20130506T182852Z -> 0.5.11,5.11-0.151008:20131204T023116Z developer/macro/gnu-m4 1.4.16,5.11-0.151006:20130506T182916Z -> 1.4.17,5.11-0.151008:20131204T023116Z developer/parser/bison 2.6.4,5.11-0.151006:20130506T182944Z -> 2.7.1,5.11-0.151008:20131204T023120Z driver/virtualization/kvm 1.0.5,5.11-0.151006:20130703T183251Z -> 1.0.5.11,5.11-0.151008:20131204T024128Z editor/vim 7.3,5.11-0.151006:20130506T183209Z -> 7.4.45,5.11-0.151008:20131204T024131Z file/gnu-coreutils 8.20,5.11-0.151006:20130703T181901Z -> 8.21,5.11-0.151008:20131204T024139Z file/gnu-findutils 4.4.2,5.11-0.151006:20130506T183441Z -> 4.4.2,5.11-0.151008:20131204T024148Z library/c++/sigcpp 2.3.1,5.11-0.151006:20130506T183459Z -> 2.3.1,5.11-0.151008:20131204T024152Z library/expat 2.0.1,5.11-0.151006:20130506T183512Z -> 2.0.1,5.11-0.151008:20131204T024154Z library/glib2 2.34.1,5.11-0.151006:20130506T183645Z -> 2.34.1,5.11-0.151008:20131204T024155Z library/gmp 5.0.5,5.11-0.151006:20130506T183725Z -> 5.1.2,5.11-0.151008:20131204T024203Z library/libffi 3.0.11,5.11-0.151006:20130506T183805Z -> 3.0.11,5.11-0.151008:20131204T024207Z library/libidn 1.25,5.11-0.151006:20130506T183846Z -> 1.28,5.11-0.151008:20131204T024207Z library/libtool/libltdl 2.4.2,5.11-0.151006:20130506T183904Z -> 2.4.2,5.11-0.151008:20131204T024209Z library/libxml2 2.9.1,5.11-0.151006:20130814T194255Z -> 2.9.1,5.11-0.151008:20131204T024210Z library/libxslt 1.1.28,5.11-0.151006:20130506T212913Z -> 1.1.28,5.11-0.151008:20131204T024220Z library/ncurses 5.9,5.11-0.151006:20130719T203957Z -> 5.9,5.11-0.151008:20131204T024222Z library/nspr 4.9.3,5.11-0.151006:20130506T184208Z -> 4.10,5.11-0.151008:20131204T184425Z library/pcre 8.31,5.11-0.151006:20130506T184228Z -> 8.33,5.11-0.151008:20131204T024232Z library/python-2/cherrypy 3.2.2,5.11-0.151006:20130506T184236Z -> 3.2.2,5.11-0.151008:20131204T024235Z library/python-2/lxml-26 2.3.3,5.11-0.151006:20130506T184402Z -> 2.3.3,5.11-0.151008:20131204T024235Z library/python-2/m2crypto 0.21.1,5.11-0.151006:20130506T184429Z -> 0.21.1,5.11-0.151008:20131204T024238Z library/python-2/mako 0.6.2,5.11-0.151006:20130506T184435Z -> 0.6.2,5.11-0.151008:20131204T024241Z library/python-2/numpy-26 1.6.1,5.11-0.151006:20130506T184741Z -> 1.6.1,5.11-0.151008:20131204T024242Z library/python-2/ply 3.4,5.11-0.151006:20130506T184748Z -> 3.4,5.11-0.151008:20131204T024247Z library/python-2/pybonjour 1.1.1,5.11-0.151006:20130506T184750Z -> 1.1.1,5.11-0.151008:20131204T024247Z library/python-2/pycurl 7.19.0.1,5.11-0.151006:20130506T184757Z -> 7.19.0.1,5.11-0.151008:20131205T191236Z library/python-2/pyopenssl-26 0.11,5.11-0.151006:20130506T184807Z -> 0.11,5.11-0.151008:20131204T024249Z library/python-2/pyrex-26 0.9.9,5.11-0.151006:20130506T184811Z -> 0.9.9,5.11-0.151008:20131204T024250Z library/python-2/setuptools-26 0.6.11,5.11-0.151006:20130506T184815Z -> 0.6.11,5.11-0.151008:20131204T024251Z library/python-2/simplejson-26 2.3.2,5.11-0.151006:20130506T184820Z -> 2.3.2,5.11-0.151008:20131204T024251Z library/readline 6.2,5.11-0.151006:20130506T184836Z -> 6.2,5.11-0.151008:20131204T024252Z library/security/openssl 1.0.1.5,5.11-0.151006:20130506T185419Z -> 1.0.1.5,5.11-0.151008:20131204T024253Z library/security/trousers 0.3.8,5.11-0.151006:20130506T185456Z -> 0.3.8,5.11-0.151008:20131204T024309Z library/unixodbc 2.2.14,5.11-0.151006:20130506T185644Z -> 2.3.1,5.11-0.151008:20131204T024310Z library/zlib 1.2.7,5.11-0.151006:20130506T185652Z -> 1.2.8,5.11-0.151008:20131204T024312Z network/dns/bind 9.9.3.2,5.11-0.151006:20130731T155125Z -> 9.9.4,5.11-0.151008:20131204T024357Z release/name 0.5.11,5.11-0.151006:20130506T190207Z -> 0.5.11,5.11-0.151008:20131204T024419Z release/notices 0.5.11,5.11-0.151006:20130506T190209Z -> 0.5.11,5.11-0.151008:20131204T024419Z runtime/java 0.5.11,5.11-0.151006:20130423T194234Z -> 0.5.11,5.11-0.151008:20131204T201013Z runtime/perl 5.16.1,5.11-0.151006:20130507T191035Z -> 5.16.1,5.11-0.151008:20131204T203701Z runtime/perl-64 5.16.1,5.11-0.151006:20131204T214406Z -> 5.16.1,5.11-0.151008:20131204T204346Z runtime/perl/manual 5.16.1,5.11-0.151006:20131204T214328Z -> 5.16.1,5.11-0.151008:20131204T203725Z runtime/python-26 2.6.7,5.11-0.151006:20130506T192502Z -> 2.6.8,5.11-0.151008:20131204T024531Z security/sudo 1.8.6.7,5.11-0.151006:20130506T192540Z -> 1.8.7,5.11-0.151008:20131204T024550Z service/network/ntp 4.2.7.316,5.11-0.151006:20130516T193602Z -> 4.2.7.316,5.11-0.151008:20131204T024607Z shell/bash 4.2.45,5.11-0.151006:20130506T192652Z -> 4.2.45,5.11-0.151008:20131204T024624Z shell/pipe-viewer 1.3.9,5.11-0.151006:20130506T192656Z -> 1.4.12,5.11-0.151008:20131204T024626Z shell/tcsh 6.18.1,5.11-0.151006:20130506T192703Z -> 6.18.1,5.11-0.151008:20131204T024626Z shell/zsh 5.0.0,5.11-0.151006:20130506T192736Z -> 5.0.2,5.11-0.151008:20131204T024627Z system/kvm 1.0.5,5.11-0.151006:20130703T183337Z -> 1.0.5.11,5.11-0.151008:20131204T024816Z system/library/boot-management 0.5.11,5.11-0.151006:20130506T182432Z -> 0.5.11,5.11-0.151008:20131204T024854Z system/library/c++/sunpro 0.5.11,5.11-0.151006:20130506T193703Z -> 0.5.11,5.11-0.151008:20131204T024855Z system/library/dbus 1.6.8,5.11-0.151006:20130506T194223Z -> 1.6.8,5.11-0.151008:20131204T024858Z system/library/g++-4-runtime 4.7.2,5.11-0.151006:20130423T223017Z -> 4.8.1,5.11-0.151008:20131204T024859Z system/library/gcc-4-runtime 4.7.2,5.11-0.151006:20130423T223020Z -> 4.8.1,5.11-0.151008:20131204T024923Z system/library/libdbus 1.6.8,5.11-0.151006:20130506T194224Z -> 1.6.8,5.11-0.151008:20131204T025101Z system/library/libdbus-glib 0.100,5.11-0.151006:20130506T194240Z -> 0.100,5.11-0.151008:20131204T025102Z system/library/math 0.5.11,5.11-0.151006:20130809T154229Z -> 0.5.11,5.11-0.151008:20131204T025106Z system/library/math/header-math 0.5.11,5.11-0.151006:20130809T154237Z -> 0.5.11,5.11-0.151008:20131204T025108Z system/library/mozilla-nss 3.14.3,5.11-0.151006:20130506T214216Z -> 3.14.3,5.11-0.151008:20131204T025108Z system/library/pcap 1.3.0,5.11-0.151006:20130506T194708Z -> 1.4.0,5.11-0.151008:20131204T025114Z system/management/snmp/net-snmp 5.7.2,5.11-0.151006:20130703T173103Z -> 5.7.2,5.11-0.151008:20131204T025128Z system/prerequisite/gnu 0.5.11,5.11-0.151006:20130506T195015Z -> 0.5.11,5.11-0.151008:20131204T025142Z terminal/screen 4.0.3,5.11-0.151006:20130506T195051Z -> 4.0.3,5.11-0.151008:20131204T025155Z text/gawk 4.0.1,5.11-0.151006:20130506T195222Z -> 4.1.0,5.11-0.151008:20131204T025158Z text/gnu-diffutils 3.2,5.11-0.151006:20130506T195247Z -> 3.3,5.11-0.151008:20131204T025200Z text/gnu-gettext 0.18.1.1,5.11-0.151006:20130506T195433Z -> 0.18.3.1,5.11-0.151008:20131204T025201Z text/gnu-grep 2.14,5.11-0.151006:20130506T195459Z -> 2.14,5.11-0.151008:20131204T025207Z text/gnu-patch 2.7,5.11-0.151006:20130506T195518Z -> 2.7,5.11-0.151008:20131204T025208Z text/gnu-sed 4.2.1,5.11-0.151006:20130506T195530Z -> 4.2.2,5.11-0.151008:20131204T025209Z text/groff 1.21,5.11-0.151006:20130506T195558Z -> 1.22.2,5.11-0.151008:20131204T025209Z text/less 451,5.11-0.151006:20130506T195605Z -> 451,5.11-0.151008:20131204T025212Z web/ca-bundle 5.11,5.11-0.151006:20130718T173831Z -> 5.11,5.11-0.151008:20131204T025213Z web/curl 7.31.0,5.11-0.151006:20130703T175442Z -> 7.33.0,5.11-0.151008:20131205T191134Z web/wget 1.14,5.11-0.151006:20130506T195742Z -> 1.14,5.11-0.151008:20131204T025217Z From cnehren+omnios-discuss at omniti.com Fri Dec 6 14:48:49 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Fri, 6 Dec 2013 09:48:49 -0500 Subject: [OmniOS-discuss] Problem upgrading to r151008 In-Reply-To: References: Message-ID: <20131206144849.GK2078@eschaton.local> On Fri, Dec 06, 2013 at 10:35:44 +0000, Andy wrote: > > Hi, > > pickle# (11) pkg list runtime/perl-64 > pkg list: no packages matching 'runtime/perl-64' installed > > pickle# (14) pkg update --be-name=r151008e > Packages to update: 96 ^^ There should be far more packages than this. This means that something is being held back from being upgraded, which means... > ld.so.1: zsh: fatal: libc.so.1: version 'ILLUMOS_0.6' not found (required > by file /usr/bin/zsh) > ld.so.1: zsh: fatal: libc.so.1: open failed: No such file or directory that you get this. I had this issue on my hetzner box as well. Something that you've installed might be holding back other packages. -- Chris Nehren Site Reliability Engineer, OmniTI From esproul at omniti.com Fri Dec 6 15:01:32 2013 From: esproul at omniti.com (Eric Sproul) Date: Fri, 6 Dec 2013 10:01:32 -0500 Subject: [OmniOS-discuss] [zfs] Re: [SPAM] Bizarre zfs-related hang in omnios r151008 on 1-CPU VM In-Reply-To: <52A1A9AD.7030901@gmail.com> References: <52A14F24.7080308@gmail.com> <8FBCE2ED-CD72-4008-A293-CAFD97AC4870@Logan.com> <52A1A9AD.7030901@gmail.com> Message-ID: On Fri, Dec 6, 2013 at 5:40 AM, Saso Kiselkov wrote: > You need a 1-CPU system. As Matt pointed out, the hang is most probably > caused by a deadlock that was resolved in e722410. > > OmniTI: I believe rolling this into the next weekly patch cycle might be > kind of important? Yeah we will take a look at pulling that in and getting you something to test. Eric From cnehren+omnios-discuss at omniti.com Fri Dec 6 15:13:43 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Fri, 6 Dec 2013 10:13:43 -0500 Subject: [OmniOS-discuss] Problem upgrading to r151008 In-Reply-To: <20131206144849.GK2078@eschaton.local> References: <20131206144849.GK2078@eschaton.local> Message-ID: <20131206151343.GL2078@eschaton.local> On Fri, Dec 06, 2013 at 09:48:49 -0500, Chris Nehren wrote: > On Fri, Dec 06, 2013 at 10:35:44 +0000, Andy wrote: > > > > Hi, > > > > pickle# (11) pkg list runtime/perl-64 > > pkg list: no packages matching 'runtime/perl-64' installed > > > > pickle# (14) pkg update --be-name=r151008e > > Packages to update: 96 > ^^ > > There should be far more packages than this. This means that > something is being held back from being upgraded, which means... > > > ld.so.1: zsh: fatal: libc.so.1: version 'ILLUMOS_0.6' not found (required > > by file /usr/bin/zsh) > > ld.so.1: zsh: fatal: libc.so.1: open failed: No such file or directory > > that you get this. I had this issue on my hetzner box as well. > Something that you've installed might be holding back other > packages. Following up on this, could we see the list of packages you have installed right now, your configured publishers, and the output of `pkg update -nv --be-name=r151008 entire at 11-0.151008 omnios-userland illumos-gate osnet-incorporation`? This'll help us more usefully troubleshoot what's going on. -- Chris Nehren Site Reliability Engineer, OmniTI From jdg117 at elvis.arl.psu.edu Fri Dec 6 15:18:30 2013 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Fri, 06 Dec 2013 10:18:30 -0500 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: Your message of "Fri, 06 Dec 2013 08:43:35 EST." <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> Message-ID: <201312061518.rB6FIUYV024934@elvis.arl.psu.edu> In message <201312061343.rB6DhZ8B018901 at elvis.arl.psu.edu>, John D Groenveld wr ites: >Upgraded with problem on one r151006 install, and fell over the >incompatible libc in another. # pkg publisher PUBLISHER TYPE STATUS URI omnios origin online http://pkg.omniti.com/omnios/release/ My pkg list below. John groenveld at acm.org NAME (PUBLISHER) VERSION IFO SUNWcs 0.5.11-0.151006 i-- SUNWcsd 0.5.11-0.151006 i-- compatibility/ucb 0.5.11-0.151006 i-- compress/bzip2 1.0.6-0.151006 i-- compress/gzip 1.5-0.151006 i-- compress/p7zip 9.20.1-0.151006 i-- compress/unzip 6.0-0.151006 i-- compress/xz 5.0.4-0.151006 i-- compress/zip 3.0-0.151006 i-- consolidation/osnet/osnet-incorporation 0.5.11-0.151006 i-- database/sqlite-3 3.7.14.1-0.151006 i-- developer/build/gnu-make 3.82-0.151006 i-- developer/build/make 0.5.11-0.151006 i-- developer/debug/mdb 0.5.11-0.151006 i-- developer/dtrace 0.5.11-0.151006 i-- developer/gcc47 4.7.2-0.151006 i-- developer/gcc47/libgmp-gcc47 5.0.5-0.151006 i-- developer/gcc47/libmpc-gcc47 1.0.1-0.151006 i-- developer/gcc47/libmpfr-gcc47 3.1.1-0.151006 i-- developer/gnu-binutils 2.23-0.151006 i-- developer/lexer/flex 2.5.37-0.151006 i-- developer/library/lint 0.5.11-0.151006 i-- developer/linker 0.5.11-0.151006 i-- developer/macro/cpp 0.5.11-0.151006 i-- developer/macro/gnu-m4 1.4.16-0.151006 i-- developer/object-file 0.5.11-0.151006 i-- developer/parser/bison 2.6.4-0.151006 i-- diagnostic/cpu-counters 0.5.11-0.151006 i-- diagnostic/latencytop 0.5.11-0.151006 i-- diagnostic/powertop 0.5.11-0.151006 i-- driver/audio 0.5.11-0.151006 i-- driver/crypto/dca 0.5.11-0.151006 i-- driver/crypto/tpm 0.5.11-0.151006 i-- driver/firewire 0.5.11-0.151006 i-- driver/graphics/agpgart 0.5.11-0.151006 i-- driver/graphics/atiatom 0.5.11-0.151006 i-- driver/graphics/drm 0.5.11-0.151006 i-- driver/i86pc/fipe 0.5.11-0.151006 i-- driver/i86pc/ioat 0.5.11-0.151006 i-- driver/i86pc/platform 0.5.11-0.151006 i-- driver/network/afe 0.5.11-0.151006 i-- driver/network/amd8111s 0.5.11-0.151006 i-- driver/network/atge 0.5.11-0.151006 i-- driver/network/bfe 0.5.11-0.151006 i-- driver/network/bge 0.5.11-0.151006 i-- driver/network/bnx 0.5.11-0.151006 i-- driver/network/bnxe 0.5.11-0.151006 i-- driver/network/bpf 0.5.11-0.151006 i-- driver/network/chxge 0.5.11-0.151006 i-- driver/network/dmfe 0.5.11-0.151006 i-- driver/network/e1000g 0.5.11-0.151006 i-- driver/network/elxl 0.5.11-0.151006 i-- driver/network/emlxs 0.5.11-0.151006 i-- driver/network/eoib 0.5.11-0.151006 i-- driver/network/fcip 0.5.11-0.151006 i-- driver/network/fcp 0.5.11-0.151006 i-- driver/network/fcsm 0.5.11-0.151006 i-- driver/network/fp 0.5.11-0.151006 i-- driver/network/hermon 0.5.11-0.151006 i-- driver/network/hme 0.5.11-0.151006 i-- driver/network/hxge 0.5.11-0.151006 i-- driver/network/ib 0.5.11-0.151006 i-- driver/network/ibdma 0.5.11-0.151006 i-- driver/network/ibp 0.5.11-0.151006 i-- driver/network/igb 0.5.11-0.151006 i-- driver/network/iprb 0.5.11-0.151006 i-- driver/network/ixgb 0.5.11-0.151006 i-- driver/network/ixgbe 0.5.11-0.151006 i-- driver/network/mxfe 0.5.11-0.151006 i-- driver/network/myri10ge 0.5.11-0.151006 i-- driver/network/nge 0.5.11-0.151006 i-- driver/network/ntxn 0.5.11-0.151006 i-- driver/network/nxge 0.5.11-0.151006 i-- driver/network/ofk 0.5.11-0.151006 i-- driver/network/pcn 0.5.11-0.151006 i-- driver/network/platform 0.5.11-0.151006 i-- driver/network/qlc 0.5.11-0.151006 i-- driver/network/rds 0.5.11-0.151006 i-- driver/network/rdsv3 0.5.11-0.151006 i-- driver/network/rge 0.5.11-0.151006 i-- driver/network/rpcib 0.5.11-0.151006 i-- driver/network/rtls 0.5.11-0.151006 i-- driver/network/sdp 0.5.11-0.151006 i-- driver/network/sdpib 0.5.11-0.151006 i-- driver/network/sfe 0.5.11-0.151006 i-- driver/network/tavor 0.5.11-0.151006 i-- driver/network/usbecm 0.5.11-0.151006 i-- driver/network/vr 0.5.11-0.151006 i-- driver/network/xge 0.5.11-0.151006 i-- driver/network/yge 0.5.11-0.151006 i-- driver/pcmcia 0.5.11-0.151006 i-- driver/serial/pcser 0.5.11-0.151006 i-- driver/serial/usbftdi 0.5.11-0.151006 i-- driver/serial/usbsacm 0.5.11-0.151006 i-- driver/serial/usbser 0.5.11-0.151006 i-- driver/serial/usbser_edge 0.5.11-0.151006 i-- driver/serial/usbsksp 0.5.11-0.151006 i-- driver/serial/usbsksp/usbs49_fw 0.5.11-0.151006 i-- driver/serial/usbsprl 0.5.11-0.151006 i-- driver/storage/aac 0.5.11-0.151006 i-- driver/storage/adpu320 0.5.11-0.151006 i-- driver/storage/ahci 0.5.11-0.151006 i-- driver/storage/amr 0.5.11-0.151006 i-- driver/storage/arcmsr 0.5.11-0.151006 i-- driver/storage/ata 0.5.11-0.151006 i-- driver/storage/bcm_sata 0.5.11-0.151006 i-- driver/storage/blkdev 0.5.11-0.151006 i-- driver/storage/cpqary3 0.5.11-0.151006 i-- driver/storage/glm 0.5.11-0.151006 i-- driver/storage/lsimega 0.5.11-0.151006 i-- driver/storage/marvell88sx 0.5.11-0.151006 i-- driver/storage/mega_sas 0.5.11-0.151006 i-- driver/storage/mpt_sas 0.5.11-0.151006 i-- driver/storage/mr_sas 0.5.11-0.151006 i-- driver/storage/nv_sata 0.5.11-0.151006 i-- driver/storage/pcata 0.5.11-0.151006 i-- driver/storage/pmcs 0.5.11-0.151006 i-- driver/storage/sbp2 0.5.11-0.151006 i-- driver/storage/scsa1394 0.5.11-0.151006 i-- driver/storage/sdcard 0.5.11-0.151006 i-- driver/storage/ses 0.5.11-0.151006 i-- driver/storage/si3124 0.5.11-0.151006 i-- driver/storage/smp 0.5.11-0.151006 i-- driver/usb 0.5.11-0.151006 i-- driver/usb/ugen 0.5.11-0.151006 i-- driver/virtualization/kvm 1.0.5-0.151006 i-- driver/xvm/pv 0.5.11-0.151006 i-- editor/vim 7.3-0.151006 i-- entire 11-0.151006 i-- file/gnu-coreutils 8.20-0.151006 i-- file/gnu-findutils 4.4.2-0.151006 i-- incorporation/jeos/illumos-gate 11-0.151006 i-- install/beadm 0.5.11-0.151006 i-- library/c++/sigcpp 2.3.1-0.151006 i-- library/expat 2.0.1-0.151006 i-- library/glib2 2.34.1-0.151006 i-- library/gmp 5.0.5-0.151006 i-- library/libffi 3.0.11-0.151006 i-- library/libidn 1.25-0.151006 i-- library/libtecla 1.6.0-0.151006 i-- library/libtool/libltdl 2.4.2-0.151006 i-- library/libxml2 2.9.1-0.151006 i-- library/libxslt 1.1.28-0.151006 i-- library/ncurses 5.9-0.151006 i-- library/nspr 4.9.3-0.151006 i-- library/pcre 8.31-0.151006 i-- library/python-2/cherrypy 3.2.2-0.151006 i-- library/python-2/lxml-26 2.3.3-0.151006 i-- library/python-2/m2crypto 0.21.1-0.151006 i-- library/python-2/mako 0.6.2-0.151006 i-- library/python-2/numpy-26 1.6.1-0.151006 i-- library/python-2/ply 3.4-0.151006 i-- library/python-2/pybonjour 1.1.1-0.151006 i-- library/python-2/pycurl 7.19.0.1-0.151006 i-- library/python-2/pyopenssl-26 0.11-0.151006 i-- library/python-2/pyrex-26 0.9.9-0.151006 i-- library/python-2/setuptools-26 0.6.11-0.151006 i-- library/python-2/simplejson-26 2.3.2-0.151006 i-- library/readline 6.2-0.151006 i-- library/security/openssl 1.0.1.5-0.151006 i-- library/security/tcp-wrapper 7.6-0.151006 i-- library/security/trousers 0.3.8-0.151006 i-- library/unixodbc 2.2.14-0.151006 i-- library/zlib 1.2.7-0.151006 i-- locale/af 0.5.11-0.151006 i-- locale/ar 0.5.11-0.151006 i-- locale/as 0.5.11-0.151006 i-- locale/az 0.5.11-0.151006 i-- locale/be 0.5.11-0.151006 i-- locale/bg 0.5.11-0.151006 i-- locale/bg-extra 0.5.11-0.151006 i-- locale/bn 0.5.11-0.151006 i-- locale/bo 0.5.11-0.151006 i-- locale/bs 0.5.11-0.151006 i-- locale/ca 0.5.11-0.151006 i-- locale/ca-extra 0.5.11-0.151006 i-- locale/cs 0.5.11-0.151006 i-- locale/cs-extra 0.5.11-0.151006 i-- locale/da 0.5.11-0.151006 i-- locale/da-extra 0.5.11-0.151006 i-- locale/de 0.5.11-0.151006 i-- locale/de-extra 0.5.11-0.151006 i-- locale/el 0.5.11-0.151006 i-- locale/el-extra 0.5.11-0.151006 i-- locale/en 0.5.11-0.151006 i-- locale/en-extra 0.5.11-0.151006 i-- locale/es 0.5.11-0.151006 i-- locale/es-extra 0.5.11-0.151006 i-- locale/et 0.5.11-0.151006 i-- locale/fi 0.5.11-0.151006 i-- locale/fi-extra 0.5.11-0.151006 i-- locale/fil 0.5.11-0.151006 i-- locale/fr 0.5.11-0.151006 i-- locale/fr-extra 0.5.11-0.151006 i-- locale/ga 0.5.11-0.151006 i-- locale/gu 0.5.11-0.151006 i-- locale/he 0.5.11-0.151006 i-- locale/hi 0.5.11-0.151006 i-- locale/hr 0.5.11-0.151006 i-- locale/hr-extra 0.5.11-0.151006 i-- locale/hu 0.5.11-0.151006 i-- locale/hu-extra 0.5.11-0.151006 i-- locale/hy 0.5.11-0.151006 i-- locale/id 0.5.11-0.151006 i-- locale/ii 0.5.11-0.151006 i-- locale/is 0.5.11-0.151006 i-- locale/is-extra 0.5.11-0.151006 i-- locale/it 0.5.11-0.151006 i-- locale/it-extra 0.5.11-0.151006 i-- locale/ja 0.5.11-0.151006 i-- locale/ka 0.5.11-0.151006 i-- locale/kk 0.5.11-0.151006 i-- locale/km 0.5.11-0.151006 i-- locale/kn 0.5.11-0.151006 i-- locale/ko 0.5.11-0.151006 i-- locale/kok 0.5.11-0.151006 i-- locale/lt 0.5.11-0.151006 i-- locale/lt-extra 0.5.11-0.151006 i-- locale/lv 0.5.11-0.151006 i-- locale/lv-extra 0.5.11-0.151006 i-- locale/mk 0.5.11-0.151006 i-- locale/mk-extra 0.5.11-0.151006 i-- locale/ml 0.5.11-0.151006 i-- locale/mn 0.5.11-0.151006 i-- locale/mr 0.5.11-0.151006 i-- locale/ms 0.5.11-0.151006 i-- locale/mt 0.5.11-0.151006 i-- locale/nb 0.5.11-0.151006 i-- locale/ne 0.5.11-0.151006 i-- locale/nl 0.5.11-0.151006 i-- locale/nl-extra 0.5.11-0.151006 i-- locale/nn 0.5.11-0.151006 i-- locale/or 0.5.11-0.151006 i-- locale/pa 0.5.11-0.151006 i-- locale/pl 0.5.11-0.151006 i-- locale/pl-extra 0.5.11-0.151006 i-- locale/pt 0.5.11-0.151006 i-- locale/pt-extra 0.5.11-0.151006 i-- locale/ro 0.5.11-0.151006 i-- locale/ru 0.5.11-0.151006 i-- locale/ru-extra 0.5.11-0.151006 i-- locale/sa 0.5.11-0.151006 i-- locale/si 0.5.11-0.151006 i-- locale/sk 0.5.11-0.151006 i-- locale/sl 0.5.11-0.151006 i-- locale/sq 0.5.11-0.151006 i-- locale/sq-extra 0.5.11-0.151006 i-- locale/sr 0.5.11-0.151006 i-- locale/sv 0.5.11-0.151006 i-- locale/sv-extra 0.5.11-0.151006 i-- locale/ta 0.5.11-0.151006 i-- locale/te 0.5.11-0.151006 i-- locale/th 0.5.11-0.151006 i-- locale/th-extra 0.5.11-0.151006 i-- locale/tr 0.5.11-0.151006 i-- locale/tr-extra 0.5.11-0.151006 i-- locale/ug 0.5.11-0.151006 i-- locale/uk 0.5.11-0.151006 i-- locale/ur 0.5.11-0.151006 i-- locale/vi 0.5.11-0.151006 i-- locale/zh_cn 0.5.11-0.151006 i-- locale/zh_hk 0.5.11-0.151006 i-- locale/zh_mo 0.5.11-0.151006 i-- locale/zh_sg 0.5.11-0.151006 i-- locale/zh_tw 0.5.11-0.151006 i-- naming/ldap 0.5.11-0.151006 i-- network/bridging 0.5.11-0.151006 i-- network/dns/bind 9.9.3.2-0.151006 i-- network/ftp 0.5.11-0.151006 i-- network/ipfilter 0.5.11-0.151006 i-- network/iscsi/initiator 0.5.11-0.151006 i-- network/iscsi/iser 0.5.11-0.151006 i-- network/ssh 0.5.11-0.151006 i-- network/ssh/ssh-key 0.5.11-0.151006 i-- network/telnet 0.5.11-0.151006 i-- package/pkg 0.5.11-0.151006 i-- package/svr4 0.5.11-0.151006 i-- print/lp/print-client-commands 0.5.11-0.151006 i-- release/name 0.5.11-0.151006 i-- release/notices 0.5.11-0.151006 i-- runtime/java 0.5.11-0.151006 i-- runtime/perl 5.16.1-0.151006 i-- runtime/perl-5142 5.14.2-0.151006 i-r runtime/perl-5142/module/sun-solaris 5.14.2-0.151006 i-r runtime/perl-64 5.16.1-0.151006 i-- runtime/perl/manual 5.16.1-0.151006 i-- runtime/perl/module/sun-solaris 0.5.11-0.151006 i-- runtime/python-26 2.6.7-0.151006 i-- security/sudo 1.8.6.7-0.151006 i-- service/fault-management 0.5.11-0.151006 i-- service/file-system/nfs 0.5.11-0.151006 i-- service/file-system/smb 0.5.11-0.151006 i-- service/hal 0.5.11-0.151006 i-- service/network/dns/mdns 0.5.11-0.151006 i-- service/network/network-clients 0.5.11-0.151006 i-- service/network/ntp 4.2.7.316-0.151006 i-- service/network/ssh 0.5.11-0.151006 i-- service/picl 0.5.11-0.151006 i-- service/resource-pools 0.5.11-0.151006 i-- service/resource-pools/poold 0.5.11-0.151006 i-- service/security/gss 0.5.11-0.151006 i-- service/security/kerberos-5 0.5.11-0.151006 i-- service/storage/fibre-channel/fc-fabric 0.5.11-0.151006 i-- service/storage/removable-media 0.5.11-0.151006 i-- shell/bash 4.2.45-0.151006 i-- shell/pipe-viewer 1.3.9-0.151006 i-- shell/tcsh 6.18.1-0.151006 i-- shell/zsh 5.0.0-0.151006 i-- storage/stmf 0.5.11-0.151006 i-- storage/svm 0.5.11-0.151006 i-- system/accounting/legacy 0.5.11-0.151006 i-- system/boot/grub 0.97-0.151006 i-- system/boot/real-mode 0.5.11-0.151006 i-- system/boot/wanboot 0.5.11-0.151006 i-- system/boot/wanboot/internal 0.5.11-0.151006 i-- system/data/hardware-registry 0.5.11-0.151006 i-- system/data/keyboard/keytables 0.5.11-0.151006 i-- system/data/terminfo 0.5.11-0.151006 i-- system/data/zoneinfo 2011.13-0.151006 i-- system/extended-system-utilities 0.5.11-0.151006 i-- system/file-system/autofs 0.5.11-0.151006 i-- system/file-system/nfs 0.5.11-0.151006 i-- system/file-system/smb 0.5.11-0.151006 i-- system/file-system/udfs 0.5.11-0.151006 i-- system/file-system/zfs 0.5.11-0.151006 i-- system/flash/fwflash 0.5.11-0.151006 i-- system/fru-id 0.5.11-0.151006 i-- system/fru-id/platform 0.5.11-0.151006 i-- system/header 0.5.11-0.151006 i-- system/install 0.5.11-0.151006 i-- system/install/configuration 0.5.11-0.151006 i-- system/ipc 0.5.11-0.151006 i-- system/kernel 0.5.11-0.151006 i-- system/kernel/cpu-counters 0.5.11-0.151006 i-- system/kernel/dtrace/providers 0.5.11-0.151006 i-- system/kernel/dynamic-reconfiguration/i86pc 0.5.11-0.151006 i-- system/kernel/platform 0.5.11-0.151006 i-- system/kernel/power 0.5.11-0.151006 i-- system/kernel/secure-rpc 0.5.11-0.151006 i-- system/kernel/security/gss 0.5.11-0.151006 i-- system/kernel/suspend-resume 0.5.11-0.151006 i-- system/kernel/ultra-wideband 0.5.11-0.151006 i-- system/kvm 1.0.5-0.151006 i-- system/library 0.5.11-0.151006 i-- system/library/boot-management 0.5.11-0.151006 i-- system/library/c++/sunpro 0.5.11-0.151006 i-- system/library/dbus 1.6.8-0.151006 i-- system/library/g++-4-runtime 4.7.2-0.151006 i-- system/library/gcc-4-runtime 4.7.2-0.151006 i-- system/library/iconv/utf-8 0.5.11-0.151006 i-- system/library/install 0.5.11-0.151006 i-- system/library/libdbus 1.6.8-0.151006 i-- system/library/libdbus-glib 0.100-0.151006 i-- system/library/libdiskmgt 0.5.11-0.151006 i-- system/library/libfcoe 0.5.11-0.151006 i-- system/library/math 0.5.11-0.151006 i-- system/library/math/header-math 0.5.11-0.151006 i-- system/library/mozilla-nss 3.14.3-0.151006 i-- system/library/pcap 1.3.0-0.151006 i-- system/library/platform 0.5.11-0.151006 i-- system/library/policykit 0.5.11-0.151006 i-- system/library/processor 0.5.11-0.151006 i-- system/library/security/gss 0.5.11-0.151006 i-- system/library/security/gss/diffie-hellman 0.5.11-0.151006 i-- system/library/security/gss/spnego 0.5.11-0.151006 i-- system/library/security/libsasl 0.5.11-0.151006 i-- system/library/storage/fibre-channel/hbaapi 0.5.11-0.151006 i-- system/library/storage/fibre-channel/libsun_fc 0.5.11-0.151006 i-- system/library/storage/ima 0.5.11-0.151006 i-- system/library/storage/ima/header-ima 0.5.11-0.151006 i-- system/library/storage/libmpapi 0.5.11-0.151006 i-- system/library/storage/libmpscsi_vhci 0.5.11-0.151006 i-- system/library/storage/scsi-plugins 0.5.11-0.151006 i-- system/management/snmp/net-snmp 5.7.2-0.151006 i-- system/management/snmp/sea/sea-config 0.5.11-0.151006 i-- system/network 0.5.11-0.151006 i-- system/network/nis 0.5.11-0.151006 i-- system/network/routing 0.5.11-0.151006 i-- system/network/udapl 0.5.11-0.151006 i-- system/network/udapl/udapl-tavor 0.5.11-0.151006 i-- system/prerequisite/gnu 0.5.11-0.151006 i-- system/scheduler/fss 0.5.11-0.151006 i-- system/storage/fibre-channel/port-utility 0.5.11-0.151006 i-- system/storage/luxadm 0.5.11-0.151006 i-- system/xopen/xcu4 0.5.11-0.151006 i-- system/zones 0.5.11-0.151006 i-- system/zones/brand/ipkg 0.5.11-0.151006 i-- terminal/screen 4.0.3-0.151006 i-- text/doctools 0.5.11-0.151006 i-- text/gawk 4.0.1-0.151006 i-- text/gnu-diffutils 3.2-0.151006 i-- text/gnu-gettext 0.18.1.1-0.151006 i-- text/gnu-grep 2.14-0.151006 i-- text/gnu-patch 2.7-0.151006 i-- text/gnu-sed 4.2.1-0.151006 i-- text/groff 1.21-0.151006 i-- text/less 451-0.151006 i-- text/locale 0.5.11-0.151006 i-- web/ca-bundle 5.11-0.151006 i-- web/curl 7.31.0-0.151006 i-- web/wget 1.14-0.151006 i-- From omnios at citrus-it.net Fri Dec 6 15:30:29 2013 From: omnios at citrus-it.net (Andy) Date: Fri, 6 Dec 2013 15:30:29 +0000 (GMT) Subject: [OmniOS-discuss] Problem upgrading to r151008 In-Reply-To: <20131206151343.GL2078@eschaton.local> References: <20131206144849.GK2078@eschaton.local> <20131206151343.GL2078@eschaton.local> Message-ID: On Fri, 6 Dec 2013, Chris Nehren wrote: ; On Fri, Dec 06, 2013 at 09:48:49 -0500, Chris Nehren wrote: ; > On Fri, Dec 06, 2013 at 10:35:44 +0000, Andy wrote: ; > > ; > > Hi, ; > > ; > > pickle# (11) pkg list runtime/perl-64 ; > > pkg list: no packages matching 'runtime/perl-64' installed ; > > ; > > pickle# (14) pkg update --be-name=r151008e ; > > Packages to update: 96 ; > ^^ ; > ; > There should be far more packages than this. This means that ; > something is being held back from being upgraded, which means... ; > ; > > ld.so.1: zsh: fatal: libc.so.1: version 'ILLUMOS_0.6' not found (required ; > > by file /usr/bin/zsh) ; > > ld.so.1: zsh: fatal: libc.so.1: open failed: No such file or directory ; > ; > that you get this. I had this issue on my hetzner box as well. ; > Something that you've installed might be holding back other ; > packages. ; ; Following up on this, could we see the list of packages you have ; installed right now, your configured publishers, and the output ; of `pkg update -nv --be-name=r151008 entire at 11-0.151008 ; omnios-userland illumos-gate osnet-incorporation`? This'll help ; us more usefully troubleshoot what's going on. Pkg can't find 'omnios-userland' but the full list of installed packages is below. The lack of the userland incorporation might be the problem. Would the output of 'pkg update -nv' without the userland incorporation be useful? The output does include: No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z found: NAME (PUBLISHER) VERSION IFO SUNWcs 0.5.11-0.151006 i-- SUNWcsd 0.5.11-0.151006 i-- citrus/as/pyzor (citrus) 0.5 i-- citrus/as/razor (citrus) 2.84 i-- citrus/as/spamassassin (citrus) 3.3.2 i-- citrus/av/clam (citrus) 0.97.8 i-- citrus/av/fprot (citrus) 6.2.3 i-- citrus/av/sophos (citrus) 4.93 i-- citrus/legacy/rsync (citrus) 1.0 i-- citrus/mysql (citrus) 5.6.11 i-- citrus/netsnmp (citrus) 5.7.2 i-- citrus/perl (citrus) 1.0 i-- citrus/perl/crypt-openssl-random (citrus) 0.4 i-- citrus/perl/crypt-openssl-rsa (citrus) 0.28 i-- citrus/perl/db-file (citrus) 1.82.8 i-- citrus/perl/dbd-mysql (citrus) 4.0.23 i-- citrus/perl/dbi (citrus) 1.625 i-- citrus/perl/digest-hmac (citrus) 1.0.3 i-- citrus/perl/digest-sha1 (citrus) 2.13 i-- citrus/perl/encode-detect (citrus) 1.1 i-- citrus/perl/encode-locale (citrus) 1.3 i-- citrus/perl/error (citrus) 1.70.20 i-- citrus/perl/file-listing (citrus) 6.4 i-- citrus/perl/geography-countries (citrus) 13.4-9 i-- citrus/perl/html-parser (citrus) 3.70 i-- citrus/perl/html-tagset (citrus) 3.20 i-- citrus/perl/http-cookies (citrus) 6.1 i-- citrus/perl/http-daemon (citrus) 6.1 i-- citrus/perl/http-date (citrus) 6.2 i-- citrus/perl/http-message (citrus) 6.6 i-- citrus/perl/http-negotiate (citrus) 6.1 i-- citrus/perl/io-html (citrus) 1.0 i-- citrus/perl/ip-country (citrus) 2.27 i-- citrus/perl/lwp (citrus) 6.5 i-- citrus/perl/lwp-mediatypes (citrus) 6.2 i-- citrus/perl/mail-dkim (citrus) 0.4 i-- citrus/perl/mail-spf (citrus) 2.8.0 i-- citrus/perl/mail-tools (citrus) 2.12 i-- citrus/perl/net-dns (citrus) 0.72 i-- citrus/perl/net-dns-resolver-programmable (citrus) 0.3 i-- citrus/perl/net-http (citrus) 6.6 i-- citrus/perl/netaddr-ip (citrus) 4.0.68 i-- citrus/perl/time-date (citrus) 2.3 i-- citrus/perl/uri (citrus) 1.60 i-- citrus/perl/www-robotrules (citrus) 6.2 i-- citrus/postinstall (citrus) 1.0.0 i-- citrus/reci/milter (citrus) 5.0.3866 i-- citrus/smtp/sendmail (citrus) 8.14.7-0 i-- citrus/utility/bmc (citrus) 1.0 i-- citrus/utility/p0f (citrus) 2.0.8-0 i-- compatibility/ucb 0.5.11-0.151006 i-- compress/bzip2 1.0.6-0.151006 i-- compress/gzip 1.5-0.151006 i-- compress/p7zip 9.20.1-0.151006 i-- compress/unzip 6.0-0.151006 i-- compress/xz 5.0.4-0.151006 i-- compress/zip 3.0-0.151006 i-- consolidation/osnet/osnet-incorporation 0.5.11-0.151006 i-- cyrus/sasl (citrus) 2.1.26 i-- database/sqlite-3 3.7.14.1-0.151006 i-- developer/apptrace 0.5.11-0.151006 i-- developer/build/gnu-make 3.82-0.151006 i-- developer/build/make 0.5.11-0.151006 i-- developer/debug/gdb (citrus) 7.6 i-- developer/debug/mdb 0.5.11-0.151006 i-- developer/dtrace 0.5.11-0.151006 i-- developer/gcc47 4.7.2-0.151006 i-- developer/gcc47/libgmp-gcc47 5.0.5-0.151006 i-- developer/gcc47/libmpc-gcc47 1.0.1-0.151006 i-- developer/gcc47/libmpfr-gcc47 3.1.1-0.151006 i-- developer/gnu-binutils 2.23-0.151006 i-- developer/lexer/flex 2.5.37-0.151006 i-- developer/library/lint 0.5.11-0.151006 i-- developer/linker 0.5.11-0.151006 i-- developer/macro/cpp 0.5.11-0.151006 i-- developer/macro/gnu-m4 1.4.16-0.151006 i-- developer/object-file 0.5.11-0.151006 i-- developer/parser/bison 2.6.4-0.151006 i-- developer/versioning/git 1.8.1.3-0.151006 i-- developer/versioning/svn (citrus) 1.7.11 i-- diagnostic/cpu-counters 0.5.11-0.151006 i-- diagnostic/latencytop 0.5.11-0.151006 i-- diagnostic/powertop 0.5.11-0.151006 i-- driver/audio 0.5.11-0.151006 i-- driver/crypto/dca 0.5.11-0.151006 i-- driver/crypto/tpm 0.5.11-0.151006 i-- driver/firewire 0.5.11-0.151006 i-- driver/graphics/agpgart 0.5.11-0.151006 i-- driver/graphics/atiatom 0.5.11-0.151006 i-- driver/graphics/drm 0.5.11-0.151006 i-- driver/i86pc/fipe 0.5.11-0.151006 i-- driver/i86pc/ioat 0.5.11-0.151006 i-- driver/i86pc/platform 0.5.11-0.151006 i-- driver/ipmi 0.5.11-0.151006 i-- driver/network/afe 0.5.11-0.151006 i-- driver/network/amd8111s 0.5.11-0.151006 i-- driver/network/atge 0.5.11-0.151006 i-- driver/network/bfe 0.5.11-0.151006 i-- driver/network/bge 0.5.11-0.151006 i-- driver/network/bnx 0.5.11-0.151006 i-- driver/network/bnxe 0.5.11-0.151006 i-- driver/network/bpf 0.5.11-0.151006 i-- driver/network/chxge 0.5.11-0.151006 i-- driver/network/dmfe 0.5.11-0.151006 i-- driver/network/e1000g 0.5.11-0.151006 i-- driver/network/elxl 0.5.11-0.151006 i-- driver/network/emlxs 0.5.11-0.151006 i-- driver/network/eoib 0.5.11-0.151006 i-- driver/network/fcip 0.5.11-0.151006 i-- driver/network/fcp 0.5.11-0.151006 i-- driver/network/fcsm 0.5.11-0.151006 i-- driver/network/fp 0.5.11-0.151006 i-- driver/network/hermon 0.5.11-0.151006 i-- driver/network/hme 0.5.11-0.151006 i-- driver/network/hxge 0.5.11-0.151006 i-- driver/network/ib 0.5.11-0.151006 i-- driver/network/ibdma 0.5.11-0.151006 i-- driver/network/ibp 0.5.11-0.151006 i-- driver/network/igb 0.5.11-0.151006 i-- driver/network/iprb 0.5.11-0.151006 i-- driver/network/ixgb 0.5.11-0.151006 i-- driver/network/ixgbe 0.5.11-0.151006 i-- driver/network/mxfe 0.5.11-0.151006 i-- driver/network/myri10ge 0.5.11-0.151006 i-- driver/network/nge 0.5.11-0.151006 i-- driver/network/ntxn 0.5.11-0.151006 i-- driver/network/nxge 0.5.11-0.151006 i-- driver/network/ofk 0.5.11-0.151006 i-- driver/network/pcn 0.5.11-0.151006 i-- driver/network/platform 0.5.11-0.151006 i-- driver/network/qlc 0.5.11-0.151006 i-- driver/network/rds 0.5.11-0.151006 i-- driver/network/rdsv3 0.5.11-0.151006 i-- driver/network/rge 0.5.11-0.151006 i-- driver/network/rpcib 0.5.11-0.151006 i-- driver/network/rtls 0.5.11-0.151006 i-- driver/network/sdp 0.5.11-0.151006 i-- driver/network/sdpib 0.5.11-0.151006 i-- driver/network/sfe 0.5.11-0.151006 i-- driver/network/tavor 0.5.11-0.151006 i-- driver/network/usbecm 0.5.11-0.151006 i-- driver/network/vr 0.5.11-0.151006 i-- driver/network/xge 0.5.11-0.151006 i-- driver/network/yge 0.5.11-0.151006 i-- driver/pcmcia 0.5.11-0.151006 i-- driver/serial/pcser 0.5.11-0.151006 i-- driver/serial/usbftdi 0.5.11-0.151006 i-- driver/serial/usbsacm 0.5.11-0.151006 i-- driver/serial/usbser 0.5.11-0.151006 i-- driver/serial/usbser_edge 0.5.11-0.151006 i-- driver/serial/usbsksp 0.5.11-0.151006 i-- driver/serial/usbsksp/usbs49_fw 0.5.11-0.151006 i-- driver/serial/usbsprl 0.5.11-0.151006 i-- driver/storage/aac 0.5.11-0.151006 i-- driver/storage/adpu320 0.5.11-0.151006 i-- driver/storage/ahci 0.5.11-0.151006 i-- driver/storage/amr 0.5.11-0.151006 i-- driver/storage/arcmsr 0.5.11-0.151006 i-- driver/storage/ata 0.5.11-0.151006 i-- driver/storage/bcm_sata 0.5.11-0.151006 i-- driver/storage/blkdev 0.5.11-0.151006 i-- driver/storage/cpqary3 0.5.11-0.151006 i-- driver/storage/glm 0.5.11-0.151006 i-- driver/storage/lsimega 0.5.11-0.151006 i-- driver/storage/marvell88sx 0.5.11-0.151006 i-- driver/storage/mega_sas 0.5.11-0.151006 i-- driver/storage/mpt_sas 0.5.11-0.151006 i-- driver/storage/mr_sas 0.5.11-0.151006 i-- driver/storage/nv_sata 0.5.11-0.151006 i-- driver/storage/pcata 0.5.11-0.151006 i-- driver/storage/pmcs 0.5.11-0.151006 i-- driver/storage/sbp2 0.5.11-0.151006 i-- driver/storage/scsa1394 0.5.11-0.151006 i-- driver/storage/sdcard 0.5.11-0.151006 i-- driver/storage/ses 0.5.11-0.151006 i-- driver/storage/si3124 0.5.11-0.151006 i-- driver/storage/smp 0.5.11-0.151006 i-- driver/usb 0.5.11-0.151006 i-- driver/usb/ugen 0.5.11-0.151006 i-- driver/virtualization/kvm 1.0.5-0.151006 i-- driver/xvm/pv 0.5.11-0.151006 i-- editor/vim 7.3-0.151006 i-- entire 11-0.151006 i-- file/gnu-coreutils 8.20-0.151006 i-- file/gnu-findutils 4.4.2-0.151006 i-- group/citrus/cinode (citrus) 1.0 i-- incorporation/jeos/illumos-gate 11-0.151006 i-- install/beadm 0.5.11-0.151006 i-- library/c++/sigcpp 2.3.1-0.151006 i-- library/expat 2.0.1-0.151006 i-- library/glib2 2.34.1-0.151006 i-- library/gmp 5.0.5-0.151006 i-- library/libffi 3.0.11-0.151006 i-- library/libidn 1.25-0.151006 i-- library/libtecla 1.6.0-0.151006 i-- library/libtool/libltdl 2.4.2-0.151006 i-- library/libxml2 2.9.1-0.151006 i-- library/libxslt 1.1.28-0.151006 i-- library/ncurses 5.9-0.151006 i-- library/nspr 4.9.3-0.151006 i-- library/pcre 8.31-0.151006 i-- library/python-2/cherrypy 3.2.2-0.151006 i-- library/python-2/lxml-26 2.3.3-0.151006 i-- library/python-2/m2crypto 0.21.1-0.151006 i-- library/python-2/mako 0.6.2-0.151006 i-- library/python-2/numpy-26 1.6.1-0.151006 i-- library/python-2/ply 3.4-0.151006 i-- library/python-2/pybonjour 1.1.1-0.151006 i-- library/python-2/pycurl 7.19.0.1-0.151006 i-- library/python-2/pyopenssl-26 0.11-0.151006 i-- library/python-2/pyrex-26 0.9.9-0.151006 i-- library/python-2/setuptools-26 0.6.11-0.151006 i-- library/python-2/simplejson-26 2.3.2-0.151006 i-- library/readline 6.2-0.151006 i-- library/security/openssl 1.0.1.5-0.151006 i-- library/security/tcp-wrapper 7.6-0.151006 i-- library/security/trousers 0.3.8-0.151006 i-- library/unixodbc 2.2.14-0.151006 i-- library/zlib 1.2.7-0.151006 i-- locale/af 0.5.11-0.151006 i-- locale/ar 0.5.11-0.151006 i-- locale/as 0.5.11-0.151006 i-- locale/az 0.5.11-0.151006 i-- locale/be 0.5.11-0.151006 i-- locale/bg 0.5.11-0.151006 i-- locale/bg-extra 0.5.11-0.151006 i-- locale/bn 0.5.11-0.151006 i-- locale/bo 0.5.11-0.151006 i-- locale/bs 0.5.11-0.151006 i-- locale/ca 0.5.11-0.151006 i-- locale/ca-extra 0.5.11-0.151006 i-- locale/cs 0.5.11-0.151006 i-- locale/cs-extra 0.5.11-0.151006 i-- locale/da 0.5.11-0.151006 i-- locale/da-extra 0.5.11-0.151006 i-- locale/de 0.5.11-0.151006 i-- locale/de-extra 0.5.11-0.151006 i-- locale/el 0.5.11-0.151006 i-- locale/el-extra 0.5.11-0.151006 i-- locale/en 0.5.11-0.151006 i-- locale/en-extra 0.5.11-0.151006 i-- locale/es 0.5.11-0.151006 i-- locale/es-extra 0.5.11-0.151006 i-- locale/et 0.5.11-0.151006 i-- locale/fi 0.5.11-0.151006 i-- locale/fi-extra 0.5.11-0.151006 i-- locale/fil 0.5.11-0.151006 i-- locale/fr 0.5.11-0.151006 i-- locale/fr-extra 0.5.11-0.151006 i-- locale/ga 0.5.11-0.151006 i-- locale/gu 0.5.11-0.151006 i-- locale/he 0.5.11-0.151006 i-- locale/hi 0.5.11-0.151006 i-- locale/hr 0.5.11-0.151006 i-- locale/hr-extra 0.5.11-0.151006 i-- locale/hu 0.5.11-0.151006 i-- locale/hu-extra 0.5.11-0.151006 i-- locale/hy 0.5.11-0.151006 i-- locale/id 0.5.11-0.151006 i-- locale/ii 0.5.11-0.151006 i-- locale/is 0.5.11-0.151006 i-- locale/is-extra 0.5.11-0.151006 i-- locale/it 0.5.11-0.151006 i-- locale/it-extra 0.5.11-0.151006 i-- locale/ja 0.5.11-0.151006 i-- locale/ka 0.5.11-0.151006 i-- locale/kk 0.5.11-0.151006 i-- locale/km 0.5.11-0.151006 i-- locale/kn 0.5.11-0.151006 i-- locale/ko 0.5.11-0.151006 i-- locale/kok 0.5.11-0.151006 i-- locale/lt 0.5.11-0.151006 i-- locale/lt-extra 0.5.11-0.151006 i-- locale/lv 0.5.11-0.151006 i-- locale/lv-extra 0.5.11-0.151006 i-- locale/mk 0.5.11-0.151006 i-- locale/mk-extra 0.5.11-0.151006 i-- locale/ml 0.5.11-0.151006 i-- locale/mn 0.5.11-0.151006 i-- locale/mr 0.5.11-0.151006 i-- locale/ms 0.5.11-0.151006 i-- locale/mt 0.5.11-0.151006 i-- locale/nb 0.5.11-0.151006 i-- locale/ne 0.5.11-0.151006 i-- locale/nl 0.5.11-0.151006 i-- locale/nl-extra 0.5.11-0.151006 i-- locale/nn 0.5.11-0.151006 i-- locale/or 0.5.11-0.151006 i-- locale/pa 0.5.11-0.151006 i-- locale/pl 0.5.11-0.151006 i-- locale/pl-extra 0.5.11-0.151006 i-- locale/pt 0.5.11-0.151006 i-- locale/pt-extra 0.5.11-0.151006 i-- locale/ro 0.5.11-0.151006 i-- locale/ru 0.5.11-0.151006 i-- locale/ru-extra 0.5.11-0.151006 i-- locale/sa 0.5.11-0.151006 i-- locale/si 0.5.11-0.151006 i-- locale/sk 0.5.11-0.151006 i-- locale/sl 0.5.11-0.151006 i-- locale/sq 0.5.11-0.151006 i-- locale/sq-extra 0.5.11-0.151006 i-- locale/sr 0.5.11-0.151006 i-- locale/sv 0.5.11-0.151006 i-- locale/sv-extra 0.5.11-0.151006 i-- locale/ta 0.5.11-0.151006 i-- locale/te 0.5.11-0.151006 i-- locale/th 0.5.11-0.151006 i-- locale/th-extra 0.5.11-0.151006 i-- locale/tr 0.5.11-0.151006 i-- locale/tr-extra 0.5.11-0.151006 i-- locale/ug 0.5.11-0.151006 i-- locale/uk 0.5.11-0.151006 i-- locale/ur 0.5.11-0.151006 i-- locale/vi 0.5.11-0.151006 i-- locale/zh_cn 0.5.11-0.151006 i-- locale/zh_hk 0.5.11-0.151006 i-- locale/zh_mo 0.5.11-0.151006 i-- locale/zh_sg 0.5.11-0.151006 i-- locale/zh_tw 0.5.11-0.151006 i-- naming/ldap 0.5.11-0.151006 i-- network/bridging 0.5.11-0.151006 i-- network/dns/bind 9.9.3.2-0.151006 i-- network/dns/unbound (citrus) 1.4.20 i-- network/ftp 0.5.11-0.151006 i-- network/ipfilter 0.5.11-0.151006 i-- network/iscsi/initiator 0.5.11-0.151006 i-- network/iscsi/iser 0.5.11-0.151006 i-- network/netcat 0.5.11-0.151006 i-- network/rsync 3.0.9-0.151006 i-- network/ssh 0.5.11-0.151006 i-- network/ssh/ssh-key 0.5.11-0.151006 i-- network/telnet 0.5.11-0.151006 i-- package/pkg 0.5.11-0.151006 i-- package/svr4 0.5.11-0.151006 i-- print/lp/print-client-commands 0.5.11-0.151006 i-- release/name 0.5.11-0.151006 i-- release/notices 0.5.11-0.151006 i-- runtime/java 0.5.11-0.151006 i-- runtime/perl 5.16.1-0.151006 i-- runtime/perl-5142 5.14.2-0.151006 i-r runtime/perl-5142/module/sun-solaris 5.14.2-0.151006 i-r runtime/perl/manual 5.16.1-0.151006 i-- runtime/perl/module/sun-solaris 0.5.11-0.151006 i-- runtime/python-26 2.6.7-0.151006 i-- security/gnupg (citrus) 1.4.13-0 i-- security/sudo 1.8.6.7-0.151006 i-- service/fault-management 0.5.11-0.151006 i-- service/file-system/nfs 0.5.11-0.151006 i-- service/file-system/smb 0.5.11-0.151006 i-- service/hal 0.5.11-0.151006 i-- service/network/dns/mdns 0.5.11-0.151006 i-- service/network/network-clients 0.5.11-0.151006 i-- service/network/ntp 4.2.7.316-0.151006 i-- service/network/ssh 0.5.11-0.151006 i-- service/picl 0.5.11-0.151006 i-- service/resource-pools 0.5.11-0.151006 i-- service/resource-pools/poold 0.5.11-0.151006 i-- service/security/gss 0.5.11-0.151006 i-- service/security/kerberos-5 0.5.11-0.151006 i-- service/storage/fibre-channel/fc-fabric 0.5.11-0.151006 i-- service/storage/removable-media 0.5.11-0.151006 i-- shell/bash 4.2.45-0.151006 i-- shell/pipe-viewer 1.3.9-0.151006 i-- shell/tcsh 6.18.1-0.151006 i-- shell/zsh 5.0.0-0.151006 i-- storage/stmf 0.5.11-0.151006 i-- storage/svm 0.5.11-0.151006 i-- system/accounting/legacy 0.5.11-0.151006 i-- system/boot/grub 0.97-0.151006 i-- system/boot/real-mode 0.5.11-0.151006 i-- system/boot/wanboot 0.5.11-0.151006 i-- system/boot/wanboot/internal 0.5.11-0.151006 i-- system/data/hardware-registry 0.5.11-0.151006 i-- system/data/keyboard/keytables 0.5.11-0.151006 i-- system/data/terminfo 0.5.11-0.151006 i-- system/data/zoneinfo 2011.13-0.151006 i-- system/extended-system-utilities 0.5.11-0.151006 i-- system/file-system/autofs 0.5.11-0.151006 i-- system/file-system/nfs 0.5.11-0.151006 i-- system/file-system/smb 0.5.11-0.151006 i-- system/file-system/udfs 0.5.11-0.151006 i-- system/file-system/zfs 0.5.11-0.151006 i-- system/flash/fwflash 0.5.11-0.151006 i-- system/fru-id 0.5.11-0.151006 i-- system/fru-id/platform 0.5.11-0.151006 i-- system/header 0.5.11-0.151006 i-- system/install 0.5.11-0.151006 i-- system/ipc 0.5.11-0.151006 i-- system/kernel 0.5.11-0.151006 i-- system/kernel/cpu-counters 0.5.11-0.151006 i-- system/kernel/dtrace/providers 0.5.11-0.151006 i-- system/kernel/dynamic-reconfiguration/i86pc 0.5.11-0.151006 i-- system/kernel/platform 0.5.11-0.151006 i-- system/kernel/power 0.5.11-0.151006 i-- system/kernel/secure-rpc 0.5.11-0.151006 i-- system/kernel/security/gss 0.5.11-0.151006 i-- system/kernel/suspend-resume 0.5.11-0.151006 i-- system/kernel/ultra-wideband 0.5.11-0.151006 i-- system/kvm 1.0.5-0.151006 i-- system/library 0.5.11-0.151006 i-- system/library/bdb (citrus) 5.3.21-0 i-- system/library/boot-management 0.5.11-0.151006 i-- system/library/c++/sunpro 0.5.11-0.151006 i-- system/library/dbus 1.6.8-0.151006 i-- system/library/g++-4-runtime 4.7.2-0.151006 i-- system/library/gcc-4-runtime 4.7.2-0.151006 i-- system/library/iconv/utf-8 0.5.11-0.151006 i-- system/library/install 0.5.11-0.151006 i-- system/library/ldns (citrus) 1.6.16 i-- system/library/libdbus 1.6.8-0.151006 i-- system/library/libdbus-glib 0.100-0.151006 i-- system/library/libdiskmgt 0.5.11-0.151006 i-- system/library/libfcoe 0.5.11-0.151006 i-- system/library/math 0.5.11-0.151006 i-- system/library/math/header-math 0.5.11-0.151006 i-- system/library/mozilla-nss 3.14.3-0.151006 i-- system/library/opendkim (citrus) 2.8.2-0 i-- system/library/pcap 1.3.0-0.151006 i-- system/library/platform 0.5.11-0.151006 i-- system/library/policykit 0.5.11-0.151006 i-- system/library/processor 0.5.11-0.151006 i-- system/library/security/gss 0.5.11-0.151006 i-- system/library/security/gss/diffie-hellman 0.5.11-0.151006 i-- system/library/security/gss/spnego 0.5.11-0.151006 i-- system/library/security/libsasl 0.5.11-0.151006 i-- system/library/storage/fibre-channel/hbaapi 0.5.11-0.151006 i-- system/library/storage/fibre-channel/libsun_fc 0.5.11-0.151006 i-- system/library/storage/ima 0.5.11-0.151006 i-- system/library/storage/ima/header-ima 0.5.11-0.151006 i-- system/library/storage/libmpapi 0.5.11-0.151006 i-- system/library/storage/libmpscsi_vhci 0.5.11-0.151006 i-- system/library/storage/scsi-plugins 0.5.11-0.151006 i-- system/management/ipmitool 1.8.12-0.151006 i-- system/management/rsyslog (citrus) 7.2.7 i-- system/management/snmp/net-snmp 5.7.2-0.151006 i-- system/management/snmp/sea/sea-config 0.5.11-0.151006 i-- system/network 0.5.11-0.151006 i-- system/network/nis 0.5.11-0.151006 i-- system/network/routing 0.5.11-0.151006 i-- system/network/udapl 0.5.11-0.151006 i-- system/network/udapl/udapl-tavor 0.5.11-0.151006 i-- system/pciutils 3.2.0-0.151006 i-- system/pciutils/pci.ids 2.2.20130701-0.151006 i-- system/prerequisite/gnu 0.5.11-0.151006 i-- system/scheduler/fss 0.5.11-0.151006 i-- system/storage/fibre-channel/port-utility 0.5.11-0.151006 i-- system/storage/luxadm 0.5.11-0.151006 i-- system/utility/ipmitool (citrus) 1.8.11 i-- system/utility/re2c (citrus) 0.13.5 i-- system/xopen/xcu4 0.5.11-0.151006 i-- system/zones 0.5.11-0.151006 i-- system/zones/brand/ipkg 0.5.11-0.151006 i-- terminal/screen 4.0.3-0.151006 i-- text/doctools 0.5.11-0.151006 i-- text/gawk 4.0.1-0.151006 i-- text/gnu-diffutils 3.2-0.151006 i-- text/gnu-gettext 0.18.1.1-0.151006 i-- text/gnu-grep 2.14-0.151006 i-- text/gnu-patch 2.7-0.151006 i-- text/gnu-sed 4.2.1-0.151006 i-- text/groff 1.21-0.151006 i-- text/less 451-0.151006 i-- text/locale 0.5.11-0.151006 i-- web/ca-bundle 5.11-0.151006 i-- web/curl 7.31.0-0.151006 i-- web/wget 1.14-0.151006 i-- -- 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 cnehren+omnios-discuss at omniti.com Fri Dec 6 15:47:30 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Fri, 6 Dec 2013 10:47:30 -0500 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: <201312061518.rB6FIUYV024934@elvis.arl.psu.edu> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> <201312061518.rB6FIUYV024934@elvis.arl.psu.edu> Message-ID: <20131206154730.GM2078@eschaton.local> On Fri, Dec 06, 2013 at 10:18:30 -0500, John D Groenveld wrote: > In message <201312061343.rB6DhZ8B018901 at elvis.arl.psu.edu>, John D Groenveld wr > ites: > >Upgraded with problem on one r151006 install, and fell over the > >incompatible libc in another. You're missing omnios-userland, which is why you're having issues. Please install the latest version from 151006 (at time of writing this is incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z) which should get you to a point that you can upgrade successfully. -- Chris Nehren Site Reliability Engineer, OmniTI From cnehren+omnios-discuss at omniti.com Fri Dec 6 15:50:11 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Fri, 6 Dec 2013 10:50:11 -0500 Subject: [OmniOS-discuss] Problem upgrading to r151008 In-Reply-To: References: <20131206144849.GK2078@eschaton.local> <20131206151343.GL2078@eschaton.local> Message-ID: <20131206155011.GN2078@eschaton.local> On Fri, Dec 06, 2013 at 15:30:29 +0000, Andy wrote: > > On Fri, 6 Dec 2013, Chris Nehren wrote: > > ; On Fri, Dec 06, 2013 at 09:48:49 -0500, Chris Nehren wrote: > ; > On Fri, Dec 06, 2013 at 10:35:44 +0000, Andy wrote: > ; > > > ; > > Hi, > ; > > > ; > > pickle# (11) pkg list runtime/perl-64 > ; > > pkg list: no packages matching 'runtime/perl-64' installed > ; > > > ; > > pickle# (14) pkg update --be-name=r151008e > ; > > Packages to update: 96 > ; > ^^ > ; > > ; > There should be far more packages than this. This means that > ; > something is being held back from being upgraded, which means... > ; > > ; > > ld.so.1: zsh: fatal: libc.so.1: version 'ILLUMOS_0.6' not found (required > ; > > by file /usr/bin/zsh) > ; > > ld.so.1: zsh: fatal: libc.so.1: open failed: No such file or directory > ; > > ; > that you get this. I had this issue on my hetzner box as well. > ; > Something that you've installed might be holding back other > ; > packages. > ; > ; Following up on this, could we see the list of packages you have > ; installed right now, your configured publishers, and the output > ; of `pkg update -nv --be-name=r151008 entire at 11-0.151008 > ; omnios-userland illumos-gate osnet-incorporation`? This'll help > ; us more usefully troubleshoot what's going on. > > Pkg can't find 'omnios-userland' but the full list of installed > packages is below. The lack of the userland incorporation might be the > problem. Would the output of 'pkg update -nv' without the userland > incorporation be useful? > > The output does include: > > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z found: You'll want to install incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z as I suggested to John and try again. There was an issue with omnios-userland that we're going to be fixing soon. -- Chris Nehren Site Reliability Engineer, OmniTI From jdg117 at elvis.arl.psu.edu Fri Dec 6 16:12:44 2013 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Fri, 06 Dec 2013 11:12:44 -0500 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: Your message of "Fri, 06 Dec 2013 10:47:30 EST." <20131206154730.GM2078@eschaton.local> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> <201312061518.rB6FIUYV024934@elvis.arl.psu.edu> <20131206154730.GM2078@eschaton.local> Message-ID: <201312061612.rB6GCimQ028637@elvis.arl.psu.edu> In message <20131206154730.GM2078 at eschaton.local>, Chris Nehren writes: >You're missing omnios-userland, which is why you're having >issues. Please install the latest version from 151006 (at time of >writing this is >incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z) Still no go. John groenveld at acm.org 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.151008:20131204T022427Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z The following indicates why the system cannot update to the latest version: No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found From cnehren+omnios-discuss at omniti.com Fri Dec 6 16:44:42 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Fri, 6 Dec 2013 11:44:42 -0500 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: <201312061612.rB6GCimQ028637@elvis.arl.psu.edu> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> <201312061518.rB6FIUYV024934@elvis.arl.psu.edu> <20131206154730.GM2078@eschaton.local> <201312061612.rB6GCimQ028637@elvis.arl.psu.edu> Message-ID: <20131206164441.GO2078@eschaton.local> On Fri, Dec 06, 2013 at 11:12:44 -0500, John D Groenveld wrote: > In message <20131206154730.GM2078 at eschaton.local>, Chris Nehren writes: > >You're missing omnios-userland, which is why you're having > >issues. Please install the latest version from 151006 (at time of > >writing this is > >incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z) > > Still no go. > John > groenveld at acm.org Hi John, Sorry for that. We just pushed a new omnios-userland incorporation that should fix your issues. Please install incorporation/jeos/omnios-userland at 11,5.11-0.151006 (which should get you the latest version) and you should be able to continue. -- Chris Nehren Site Reliability Engineer, OmniTI From vab at bb-c.de Fri Dec 6 17:05:50 2013 From: vab at bb-c.de (Volker A. Brandt) Date: Fri, 6 Dec 2013 18:05:50 +0100 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: <20131206164441.GO2078@eschaton.local> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> <201312061518.rB6FIUYV024934@elvis.arl.psu.edu> <20131206154730.GM2078@eschaton.local> <201312061612.rB6GCimQ028637@elvis.arl.psu.edu> <20131206164441.GO2078@eschaton.local> Message-ID: <21154.1006.504199.548588@glaurung.bb-c.de> Chris Nehren writes: > Sorry for that. We just pushed a new omnios-userland > incorporation that should fix your issues. > > Please install > incorporation/jeos/omnios-userland at 11,5.11-0.151006 (which should > get you the latest version) and you should be able to continue. Refreshed the catalogs and installed that: 11,5.11-0.151006:20131030T205312Z PHASE ACTIONS Install Phase 134/134 PHASE ITEMS Package State Update Phase 1/1 Image State Update Phase 2/2 But then: References: <52A14F24.7080308@gmail.com> Message-ID: Be sure you have the following fix; without it I recall seeing spins from the ZPL similar to that stack trace. With only 1 cpu, if a kernel thread spins, it can be very hard to get other threads to run. commit e722410c49fe67cbf0f639cbcc288bd6cbcf7dd1 Author: Matthew Ahrens Date: Tue Nov 26 13:47:33 2013 -0500 4347 ZPL can use dmu_tx_assign(TXG_WAIT) Reviewed by: George Wilson Reviewed by: Adam Leventhal Reviewed by: Dan McDonald Reviewed by: Boris Protopopov Approved by: Dan McDonald On Thu, Dec 5, 2013 at 8:14 PM, Saso Kiselkov wrote: > I'm investigating a bizarre hang situation which I noticed by accident > on the latest stable omnios release. When I'm running in VMware Fusion > on a 1-CPU VM and doing any significant write IO to the pool (e.g. just > dd'ing something around is enough to trigger this), the VM will, with > 100% certainty, hang. Console input works, but all userspace programs > are stopped and nothing responds (e.g. attempting to telnet to sshd over > the network establishes the socket, but then sshd doesn't print the > version string). > > Using some dtrace foo and kmdb I was able to trace it (roughly, the > exact stack trace changes between hangs, which is mighty weird in itself): > > atomic_dec_32_nv+8() > dbuf_read+0x179(ffffff00d2393600, ffffff00c72f98f0, a) > dmu_tx_check_ioerr+0x76(ffffff00c72f98f0, ffffff00d2279cf0, 0, 1e0) > dmu_tx_count_write+0x395(ffffff00ce0536e0, 3c04000, 4000) > dmu_tx_hold_write+0x5a(ffffff00d1a55300, 4009, 3c04000, 4000) > zfs_write+0x3e3(ffffff00d09ef540, ffffff00028e7e60, 0, > ffffff00cd511748, 0) > fop_write+0x5b(ffffff00d09ef540, ffffff00028e7e60, 0, > ffffff00cd511748, 0) > write+0x250(1, 440660, 4000) > sys_syscall+0x17a() > > (usually the trace is identical up to dmu_tx_hold_write) > > I can definitely confirm that this doesn't happen on omnios r151006 and > it doesn't happen on my vanilla kernels either. My suspicion is that > something got botched in the "OMNIOS#72 Integrate Joyent updated zone > write throttle" commit, but I can't put my finger on it. > > Can somebody please confirm this? > > Cheers, > -- > Saso > > > ------------------------------------------- > illumos-zfs > Archives: https://www.listbox.com/member/archive/182191/=now > RSS Feed: > https://www.listbox.com/member/archive/rss/182191/21635000-ebd1d460 > Modify Your Subscription: > https://www.listbox.com/member/?member_id=21635000&id_secret=21635000-73dc201a > Powered by Listbox: http://www.listbox.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From esproul at omniti.com Fri Dec 6 20:19:15 2013 From: esproul at omniti.com (Eric Sproul) Date: Fri, 6 Dec 2013 15:19:15 -0500 Subject: [OmniOS-discuss] [zfs] Re: [SPAM] Bizarre zfs-related hang in omnios r151008 on 1-CPU VM In-Reply-To: References: <52A14F24.7080308@gmail.com> <8FBCE2ED-CD72-4008-A293-CAFD97AC4870@Logan.com> <52A1A9AD.7030901@gmail.com> Message-ID: Saso, Here is an updated zfs kernel module from a build with the "4347 ZPL can use dmu_tx_assign(TXG_WAIT)" fix applied: http://omnios.omniti.com/media/zfs-driver-with-txg_wait-fix.amd64.r151008 sha1 (zfs-driver-with-txg_wait-fix.amd64.r151008) = 06d9451ad6f157fd61877bf24d475b14f913e964 If you need additional files or anything else, just let us know. Eric From skiselkov.ml at gmail.com Fri Dec 6 21:01:35 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Fri, 06 Dec 2013 21:01:35 +0000 Subject: [OmniOS-discuss] [zfs] Re: [SPAM] Bizarre zfs-related hang in omnios r151008 on 1-CPU VM In-Reply-To: References: <52A14F24.7080308@gmail.com> <8FBCE2ED-CD72-4008-A293-CAFD97AC4870@Logan.com> <52A1A9AD.7030901@gmail.com> Message-ID: <52A23B2F.4060906@gmail.com> On 12/6/13, 8:19 PM, Eric Sproul wrote: > Saso, > Here is an updated zfs kernel module from a build with the "4347 ZPL > can use dmu_tx_assign(TXG_WAIT)" fix applied: > > http://omnios.omniti.com/media/zfs-driver-with-txg_wait-fix.amd64.r151008 > > sha1 (zfs-driver-with-txg_wait-fix.amd64.r151008) = > 06d9451ad6f157fd61877bf24d475b14f913e964 > > If you need additional files or anything else, just let us know. > Thanks Eric, the new module works like a charm. Here's the installation I did: root at omnios:~# beadm create -e omnios-r151008 omnios-r151008-fix Created successfully root at omnios:~# beadm mount omnios-r151008-fix Mounted successfully on: '/tmp/tmp.JAaqdb' root at omnios:~# cd /tmp/tmp.JAaqdb/ root at omnios:/tmp/tmp.JAaqdb# cp ~/zfs-driver-with-txg_wait-fix.amd64.r151008 kernel/fs/amd64/zfs root at omnios:/tmp/tmp.JAaqdb# cd root at omnios:~# bootadm update-archive -R /tmp/tmp.JAaqdb Creating boot_archive for /tmp/tmp.JAaqdb updating /tmp/tmp.JAaqdb/platform/i86pc/boot_archive updating /tmp/tmp.JAaqdb/platform/i86pc/amd64/boot_archive root at omnios:~# beadm umount omnios-r151008-fix Unmounted successfully root at omnios:~# reboot -p And here's the test: dd if=/dev/urandom of=test bs=1M count=128 ; sync On the original BE this hangs, on the new BE works without a hitch. I'd say ship it! Best wishes, -- Saso From esproul at omniti.com Fri Dec 6 21:18:48 2013 From: esproul at omniti.com (Eric Sproul) Date: Fri, 6 Dec 2013 16:18:48 -0500 Subject: [OmniOS-discuss] [zfs] Re: [SPAM] Bizarre zfs-related hang in omnios r151008 on 1-CPU VM In-Reply-To: <52A23B2F.4060906@gmail.com> References: <52A14F24.7080308@gmail.com> <8FBCE2ED-CD72-4008-A293-CAFD97AC4870@Logan.com> <52A1A9AD.7030901@gmail.com> <52A23B2F.4060906@gmail.com> Message-ID: On Fri, Dec 6, 2013 at 4:01 PM, Saso Kiselkov wrote: > On the original BE this hangs, on the new BE works without a hitch. > > I'd say ship it! Excellent! We'll plan to release r151008f with this fix next week. Thanks for the bug report and the testing! Eric From ask at apache.org Fri Dec 6 21:38:15 2013 From: ask at apache.org (=?windows-1252?Q?Ask_Bj=F8rn_Hansen?=) Date: Fri, 6 Dec 2013 13:38:15 -0800 Subject: [OmniOS-discuss] Staying on a release Message-ID: <2ED645DC-CB49-482A-AF25-4923362C24EA@apache.org> Hi everyone, On http://omnios.omniti.com/wiki.php/GeneralAdministration#StayingOnARelease there are two packages mentioned to ?freeze? to stay on a release: ? incorporation/jeos/illumos-gate ? incorporation/jeos/omnios-userland However in my fresh 151006 install I don?t have omnios-userland. Should it still be frozen? I did this (guessing at the version number of the package): pkg freeze -c "Stay on r151006" incorporation/jeos/illumos-gate at 11,5.11-0.151006 pkg freeze -c "Stay on r151006" incorporation/jeos/omnios-userland at 11,5.11-0.151006 .. but ?pkg update -n -v? still indicates that things will get updated to 151008: ? text/groff 1.21,5.11-0.151006:20130506T195558Z -> 1.22.2,5.11-0.151008:20131204T025209Z text/less 451,5.11-0.151006:20130506T195605Z -> 451,5.11-0.151008:20131204T025212Z web/ca-bundle 5.11,5.11-0.151006:20130718T173831Z -> 5.11,5.11-0.151008:20131204T025213Z web/curl 7.31.0,5.11-0.151006:20130703T175442Z -> 7.33.0,5.11-0.151008:20131205T191134Z ? Ask From esproul at omniti.com Fri Dec 6 21:44:11 2013 From: esproul at omniti.com (Eric Sproul) Date: Fri, 6 Dec 2013 16:44:11 -0500 Subject: [OmniOS-discuss] Staying on a release In-Reply-To: <2ED645DC-CB49-482A-AF25-4923362C24EA@apache.org> References: <2ED645DC-CB49-482A-AF25-4923362C24EA@apache.org> Message-ID: On Fri, Dec 6, 2013 at 4:38 PM, Ask Bj?rn Hansen wrote: > Hi everyone, > > On http://omnios.omniti.com/wiki.php/GeneralAdministration#StayingOnARelease there are two packages mentioned to ?freeze? to stay on a release: > > ? incorporation/jeos/illumos-gate > ? incorporation/jeos/omnios-userland > > However in my fresh 151006 install I don?t have omnios-userland. Should it still be frozen? This is a bug in 151006 that will be addressed next week with an update. The 'entire' package should require omnios-userland to be installed, but it doesn't, and that will be fixed in the update. You can `pkg install incorporation/jeos/omnios-userland at 11,5.11-0.151006` to actually get it on your system. > > I did this (guessing at the version number of the package): > > pkg freeze -c "Stay on r151006" incorporation/jeos/illumos-gate at 11,5.11-0.151006 > pkg freeze -c "Stay on r151006" incorporation/jeos/omnios-userland at 11,5.11-0.151006 > > .. but ?pkg update -n -v? still indicates that things will get updated to 151008: > > ? > text/groff > 1.21,5.11-0.151006:20130506T195558Z -> 1.22.2,5.11-0.151008:20131204T025209Z > text/less > 451,5.11-0.151006:20130506T195605Z -> 451,5.11-0.151008:20131204T025212Z > web/ca-bundle > 5.11,5.11-0.151006:20130718T173831Z -> 5.11,5.11-0.151008:20131204T025213Z > web/curl > 7.31.0,5.11-0.151006:20130703T175442Z -> 7.33.0,5.11-0.151008:20131205T191134Z Right, this is because omnios-userland isn't there to prevent them from upgrading past 151006. Eric From ask at apache.org Sat Dec 7 00:09:18 2013 From: ask at apache.org (=?windows-1252?Q?Ask_Bj=F8rn_Hansen?=) Date: Fri, 6 Dec 2013 16:09:18 -0800 Subject: [OmniOS-discuss] Staying on a release In-Reply-To: References: <2ED645DC-CB49-482A-AF25-4923362C24EA@apache.org> Message-ID: <63B9EDEA-572E-4881-9116-A9E9EC8FEF8D@apache.org> On Dec 6, 2013, at 13:44 , Eric Sproul wrote: >> However in my fresh 151006 install I don?t have omnios-userland. Should it still be frozen? > > This is a bug in 151006 that will be addressed next week with an > update. The 'entire' package should require omnios-userland to be > installed, but it doesn't, and that will be fixed in the update. > > You can `pkg install > incorporation/jeos/omnios-userland at 11,5.11-0.151006` to actually get > it on your system. Hmn, I think that?s too late. Trying installing the package now complains that there are some 008 packages installed already. Argh. I thought I?d only run ?pkg update -n -v? on this box. Does it do an upgrade automatically after installing? Ask From ask at apache.org Sat Dec 7 00:11:41 2013 From: ask at apache.org (=?windows-1252?Q?Ask_Bj=F8rn_Hansen?=) Date: Fri, 6 Dec 2013 16:11:41 -0800 Subject: [OmniOS-discuss] Staying on a release In-Reply-To: <63B9EDEA-572E-4881-9116-A9E9EC8FEF8D@apache.org> References: <2ED645DC-CB49-482A-AF25-4923362C24EA@apache.org> <63B9EDEA-572E-4881-9116-A9E9EC8FEF8D@apache.org> Message-ID: On Dec 6, 2013, at 16:09 , Ask Bj?rn Hansen wrote: > Hmn, I think that?s too late. Trying installing the package now complains that there are some 008 packages installed already. Argh. Ah, that was because I installed the kayak server. Uninstalling that let me install omnios-userland. Ask From esproul at omniti.com Sat Dec 7 03:48:38 2013 From: esproul at omniti.com (Eric Sproul) Date: Fri, 6 Dec 2013 22:48:38 -0500 Subject: [OmniOS-discuss] Staying on a release In-Reply-To: References: <2ED645DC-CB49-482A-AF25-4923362C24EA@apache.org> <63B9EDEA-572E-4881-9116-A9E9EC8FEF8D@apache.org> Message-ID: On Friday, December 6, 2013, Ask Bj?rn Hansen wrote: > > On Dec 6, 2013, at 16:09 , Ask Bj?rn Hansen > > wrote: > > > Hmn, I think that?s too late. Trying installing the package now > complains that there are some 008 packages installed already. Argh. > > Ah, that was because I installed the kayak server. Uninstalling that let > me install omnios-userland. > > Ask > You can also downgrade individual packages by specifying the old version, e.g. foo at 1.2.3-0.151006 Uninstalling works too. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Sat Dec 7 15:06:04 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Sat, 7 Dec 2013 16:06:04 +0100 (CET) Subject: [OmniOS-discuss] userland woes Message-ID: Following the latest instructions from your webpage, we tried this: pkg list incorporation/jeos/omnios-userland >/dev/null 2>&1 || pkg install incorporation/jeos/omnios-userland at 11,5.11-0.151006 now, if we run # pkg update -nv we get 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.151008:20131204T022427Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z Dependency analysis is unable to determine exact cause. Try specifying expected results to obtain more detailed error messages. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From robin at coraid.com Sat Dec 7 15:14:41 2013 From: robin at coraid.com (Robin P. Blanchard) Date: Sat, 7 Dec 2013 15:14:41 +0000 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: <21154.1006.504199.548588@glaurung.bb-c.de> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> <201312061518.rB6FIUYV024934@elvis.arl.psu.edu> <20131206154730.GM2078@eschaton.local> <201312061612.rB6GCimQ028637@elvis.arl.psu.edu> <20131206164441.GO2078@eschaton.local> <21154.1006.504199.548588@glaurung.bb-c.de> Message-ID: <4A0990C6-6C23-4F54-AA82-1E136B50972A@coraid.com> Similar woes here. Update attempted this morning: # pkg update -nv 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.151008:20131204T022427Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z The following indicates why the system cannot update to the latest version: No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found # pkg info omnios-userland Name: incorporation/jeos/omnios-userland Summary: Incorporation to constrain OmniOS user-land packages to same build Description: This package constrains OmniOS user-land packages to the same build as osnet-incorporation. State: Installed Publisher: omnios Version: 11 Build Release: 5.11 Branch: 0.151006 Packaging Date: October 30, 2013 08:53:12 PM Size: 0.00 B FMRI: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z # pkg info pcap Name: system/library/pcap Summary: libpcap - a packet capture library State: Installed Publisher: omnios Version: 1.3.0 (1.3.0) Build Release: 5.11 Branch: 0.151006 Packaging Date: May 6, 2013 07:47:08 PM Size: 754.10 kB FMRI: pkg://omnios/system/library/pcap at 1.3.0,5.11-0.151006:20130506T194708Z # pkg publisher PUBLISHER TYPE STATUS URI omnios origin online http://pkg.omniti.com/omnios/release/ ms.omniti.com origin online http://pkg.omniti.com/omniti-ms/ uulm.mawi origin online http://scott.mathematik.uni-ulm.de/release/ On Dec 6, 2013, at 09:05 AM, Volker A. Brandt wrote: > Chris Nehren writes: >> Sorry for that. We just pushed a new omnios-userland >> incorporation that should fix your issues. >> >> Please install >> incorporation/jeos/omnios-userland at 11,5.11-0.151006 (which should >> get you the latest version) and you should be able to continue. > > Refreshed the catalogs and installed that: > > Packages to install: 1 > Estimated space available: 6.49 GB > Estimated space to be consumed: 14.56 MB > Create boot environment: No > Create backup boot environment: No > Rebuild boot archive: No > > Changed packages: > omnios > incorporation/jeos/omnios-userland > None -> 11,5.11-0.151006:20131030T205312Z > PHASE ACTIONS > Install Phase 134/134 > > PHASE ITEMS > Package State Update Phase 1/1 > Image State Update Phase 2/2 > > > But then: > > 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.151008:20131204T022427Z > pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z > pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z > pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z > Dependency analysis is unable to determine exact cause. > Try specifying expected results to obtain more detailed error messages. > > > Is "11,5.11-0.151006:20131030T205312Z" the correct version of > "incorporation/jeos/omnios-userland"? Looks like it's more than a > month old... > > > Regards -- Volker > -- > ------------------------------------------------------------------------ > Volker A. Brandt Consulting and Support for Oracle Solaris > Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ > Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de > Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 > Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt > > "When logic and proportion have fallen sloppy dead" > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Robin P. Blanchard Coraid Solutions Engineer support.coraid.com 650.730.5140 From lotheac at iki.fi Sat Dec 7 16:52:59 2013 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Sat, 7 Dec 2013 18:52:59 +0200 Subject: [OmniOS-discuss] r151008 ipkg zone attach problems Message-ID: <20131207165258.GA7252@gutsman.lotheac.fi> I noticed that I could not attach my non-global zones under r151008 after upgrading from r151006. I made a couple VMs to reproduce, and it turns out that ipkg zone attach is broken on r151008 even on a fresh install - I can install a zone and it will work, but if I detach it, it cannot be reattached. It fails with: [December 7, 2013 05:53:03 PM UTC] Log File: /var/tmp/ngz.attach_log.WcaOqg [December 7, 2013 05:53:08 PM UTC] Attach Path: /zones/ngz/root [December 7, 2013 05:53:08 PM UTC] Attach ZFS Dataset: rpool/zones/ngz/ROOT/zbe [December 7, 2013 05:53:08 PM UTC] existing [December 7, 2013 05:53:08 PM UTC] Installing: Using pre-existing data in zonepath [December 7, 2013 05:53:08 PM UTC] Sanity Check: Passed. Looks like an OpenSolaris system. Unable to get preferred publisher information for zone 'global'. brand-specific usage: attach [-a archive] [-d dataset] [-n] [-r zfs-recv] [-u] The -a archive option specifies a tar file or cpio archive. The -d dataset option specifies an existing dataset. The -r zfs-recv option receives the output of a 'zfs send' command of an existing zone root dataset. The -u option indicates that the software should be updated to match the current host. [December 7, 2013 05:53:12 PM UTC] Result: Attach Failed. I was able to figure out the cause of this: the /usr/lib/brand/ipkg/attach script tries to get a 'preferred' publisher (seems to be called syspub in some places), but there are none. A little detective work then leads me to https://github.com/postwait/pkg5/commit/0675d74fa0a6bf32f714d7f8da8e980868ac73ae which places comments in the ipkg zone creation script indicating that 'preferred publisher' is not a concept in newer pkg5 (from diffing the ipkg brand directory it looks like this change was not in r151006, but is in r151008) So, blindly applying that knowledge to the attach script as well (remove the 'preferred' check; rudimentary patch attached), I am able to reattach an r151008 zone to a r151008 gz. However, trying to attach -u an r151006 zone to r151008 still fails: [December 7, 2013 06:12:39 PM UTC] Log File: /var/tmp/ngz.attach_log.spaWcf [December 7, 2013 06:12:45 PM UTC] Attach Path: /zones/ngz/root [December 7, 2013 06:12:45 PM UTC] Attach ZFS Dataset: rpool/zones/ngz/ROOT/zbe [December 7, 2013 06:12:45 PM UTC] existing [December 7, 2013 06:12:45 PM UTC] Installing: Using pre-existing data in zonepath [December 7, 2013 06:12:45 PM UTC] Sanity Check: Passed. Looks like an OpenSolaris system. [December 7, 2013 06:12:47 PM UTC] Preferred global publisher: omnios [December 7, 2013 06:12:48 PM UTC] Global zone version: entire at 11,5.11-0.151008:20131205T195242Z [December 7, 2013 06:12:48 PM UTC] Non-Global zone version: entire at 11,5.11-0.151006:20130507T204959Z [December 7, 2013 06:12:48 PM UTC] Cache: Using /var/pkg/publisher. [December 7, 2013 06:12:48 PM UTC] Updating non-global zone: Output follows pkg install: No matching version of entire can be installed: Reject: pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z Reason: All versions matching 'require' dependency pkg:/incorporation/jeos/omnios-userland are rejected Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151004:20121024T180535Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151004:20130208T215446Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151004:20130304T155348Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151004:20130321T181944Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151004:20130416T172708Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20130506T214442Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20130716T202721Z Reason: Excluded by proposed incorporation 'entire' Newer version pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z is already installed This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z Reason: Excluded by proposed incorporation 'entire' This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z [December 7, 2013 06:12:55 PM UTC] ERROR: Could not update attaching zone [December 7, 2013 06:13:00 PM UTC] Result: Attach Failed. Which looks like it's only trying to update entire, not omnios-userland. But it's weird, because entire has these dependencies: depend fmri=incorporation/jeos/omnios-userland at 11,5.11-0.151008 type=incorporate depend fmri=incorporation/jeos/omnios-userland type=require Just guessing here, but perhaps the require dependency needs to have an explicit branch version as well? An explicit 'pkg -R /zones/ngz/root update entire at latest omnios-userland at latest' before attaching works around this (but not the 'unable to get preferred publisher information' issue). -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet -------------- next part -------------- diff --git a/src/brand/attach b/src/brand/attach index e754c2c..a0e0abe 100644 --- a/src/brand/attach +++ b/src/brand/attach @@ -256,10 +256,8 @@ get_preferred_publisher() { for key in ${!publishers[*]}; do eval publisher="${publishers[$key]}" - if [[ ${publisher.preferred} == "true" ]]; then - print ${key} - return 0 - fi + print ${key} + return 0 done return 1 } From doug at will.to Sat Dec 7 17:39:58 2013 From: doug at will.to (Doug Hughes) Date: Sat, 07 Dec 2013 12:39:58 -0500 Subject: [OmniOS-discuss] some problems with kayak install of r151006 and r151008 Message-ID: <52A35D6E.6040304@will.to> I'm trying to do a kayak install and running into some problems. I've gotten as far as tftp loading the base miniroot, but when it comes time to curl down the release bundle for install, the amd64 curl is missing libidn and some other things. (I also tried with bloody, but that failed to boot all together) from the install environment: root at unknown:~# ldd /usr/bin/amd64/curl libcurl.so.4 => /usr/lib/amd64/libcurl.so.4 libidn.so.11 => (file not found) libssl.so.1.0.0 => /usr/lib/amd64/libssl.so.1.0.0 libcrypto.so.1.0.0 => /usr/lib/amd64/libcrypto.so.1.0.0 libldap.so.5 => /usr/lib/amd64/libldap.so.5 libz.so => (file not found) libsocket.so.1 => /usr/lib/amd64/libsocket.so.1 libnsl.so.1 => /usr/lib/amd64/libnsl.so.1 libc.so.1 => /usr/lib/amd64/libc.so.1 libidn.so.11 => (file not found) libz.so => (file not found) libz.so => (file not found) libsasl.so.1 => /usr/lib/64/libsasl.so.1 libmd.so.1 => /lib/64/libmd.so.1 libnspr4.so => /usr/lib/mps/64/libnspr4.so libplc4.so => /usr/lib/mps/64/libplc4.so libnss3.so => /usr/lib/mps/64/libnss3.so libssl3.so => /usr/lib/mps/64/libssl3.so libmp.so.2 => /lib/64/libmp.so.2 libpthread.so.1 => /lib/64/libpthread.so.1 librt.so.1 => /lib/64/librt.so.1 libdl.so.1 => /lib/64/libdl.so.1 libnssutil3.so => /usr/lib/mps/amd64/libnssutil3.so libplds4.so => /usr/lib/mps/amd64/libplds4.so libz.so => (file not found) libm.so.2 => /lib/64/libm.so.2 root at unknown:~# root at unknown:~# ls -l /usr/lib/amd64/libidn* lrwxrwxrwx 1 root root 17 Nov 25 21:59 /usr/lib/amd64/libidn.so.11 -> libidn.so.11.6.11 root at unknown:~# For some background, I downloaded 1008 release on ISO, installed it to get the miniroot, built the release image, and setup the dhcp parameters. All of that is working just fine. Is there a newer (or older) miniroot.gz package/build that is intact? Thanks, Doug From bdha at mirrorshades.net Sun Dec 8 00:28:05 2013 From: bdha at mirrorshades.net (Bryan Horstmann-Allen) Date: Sat, 7 Dec 2013 19:28:05 -0500 Subject: [OmniOS-discuss] Zones built on r151006 install as r151008, breakage. Message-ID: <20131208002805.GA2153@lab.pobox.com> I have the system pinned to r151006, but this doesn't appear to impact zone installation. https://gist.github.com/anonymous/7851777/raw/fdb2745ef15a9b00cdc89383e5b2f3f9bfe71ec7/gistfile1.txt Is this behavior expected? I'd personally expect that if you install a zone of a given release of the OS, the zone will be installed with that version. Cheers. -- bdha cyberpunk is dead. long live cyberpunk. From robin at coraid.com Sun Dec 8 01:16:29 2013 From: robin at coraid.com (Robin P. Blanchard) Date: Sun, 8 Dec 2013 01:16:29 +0000 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: <4A0990C6-6C23-4F54-AA82-1E136B50972A@coraid.com> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> <201312061518.rB6FIUYV024934@elvis.arl.psu.edu> <20131206154730.GM2078@eschaton.local> <201312061612.rB6GCimQ028637@elvis.arl.psu.edu> <20131206164441.GO2078@eschaton.local> <21154.1006.504199.548588@glaurung.bb-c.de> <4A0990C6-6C23-4F54-AA82-1E136B50972A@coraid.com> Message-ID: <7C8C2D53-7578-4D52-BEE2-1EDCD34F001E@coraid.com> iftop to blame. all fixed On Dec 7, 2013, at 07:14 AM, Robin P. Blanchard wrote: > Similar woes here. Update attempted this morning: > > > # pkg update -nv > 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.151008:20131204T022427Z > pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z > pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z > pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z > > The following indicates why the system cannot update to the latest version: > > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z found: > Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z > Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z found: > Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z > Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z found: > Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z > Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z found: > Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z > Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found > > > # pkg info omnios-userland > Name: incorporation/jeos/omnios-userland > Summary: Incorporation to constrain OmniOS user-land packages to same build > Description: This package constrains OmniOS user-land packages to the same > build as osnet-incorporation. > State: Installed > Publisher: omnios > Version: 11 > Build Release: 5.11 > Branch: 0.151006 > Packaging Date: October 30, 2013 08:53:12 PM > Size: 0.00 B > FMRI: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z > > > # pkg info pcap > Name: system/library/pcap > Summary: libpcap - a packet capture library > State: Installed > Publisher: omnios > Version: 1.3.0 (1.3.0) > Build Release: 5.11 > Branch: 0.151006 > Packaging Date: May 6, 2013 07:47:08 PM > Size: 754.10 kB > FMRI: pkg://omnios/system/library/pcap at 1.3.0,5.11-0.151006:20130506T194708Z > > # pkg publisher > PUBLISHER TYPE STATUS URI > omnios origin online http://pkg.omniti.com/omnios/release/ > ms.omniti.com origin online http://pkg.omniti.com/omniti-ms/ > uulm.mawi origin online http://scott.mathematik.uni-ulm.de/release/ > > > On Dec 6, 2013, at 09:05 AM, Volker A. Brandt wrote: > >> Chris Nehren writes: >>> Sorry for that. We just pushed a new omnios-userland >>> incorporation that should fix your issues. >>> >>> Please install >>> incorporation/jeos/omnios-userland at 11,5.11-0.151006 (which should >>> get you the latest version) and you should be able to continue. >> >> Refreshed the catalogs and installed that: >> >> > Packages to install: 1 >> Estimated space available: 6.49 GB >> Estimated space to be consumed: 14.56 MB >> Create boot environment: No >> Create backup boot environment: No >> Rebuild boot archive: No >> >> Changed packages: >> omnios >> incorporation/jeos/omnios-userland >> None -> 11,5.11-0.151006:20131030T205312Z >> PHASE ACTIONS >> Install Phase 134/134 >> >> PHASE ITEMS >> Package State Update Phase 1/1 >> Image State Update Phase 2/2 >> >> >> But then: >> >> > 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.151008:20131204T022427Z >> pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z >> pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z >> pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z >> Dependency analysis is unable to determine exact cause. >> Try specifying expected results to obtain more detailed error messages. >> >> >> Is "11,5.11-0.151006:20131030T205312Z" the correct version of >> "incorporation/jeos/omnios-userland"? Looks like it's more than a >> month old... >> >> >> Regards -- Volker >> -- >> ------------------------------------------------------------------------ >> Volker A. Brandt Consulting and Support for Oracle Solaris >> Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ >> Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de >> Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 >> Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt >> >> "When logic and proportion have fallen sloppy dead" >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -- > Robin P. Blanchard > Coraid Solutions Engineer > support.coraid.com > 650.730.5140 > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Robin P. Blanchard Coraid Solutions Engineer support.coraid.com 650.730.5140 From esproul at omniti.com Sun Dec 8 06:54:21 2013 From: esproul at omniti.com (Eric Sproul) Date: Sun, 8 Dec 2013 01:54:21 -0500 Subject: [OmniOS-discuss] Zones built on r151006 install as r151008, breakage. In-Reply-To: <20131208002805.GA2153@lab.pobox.com> References: <20131208002805.GA2153@lab.pobox.com> Message-ID: Your 006 install might be missing the omnios-userland incorporation. It was left out of the default install by mistake but wasn't apparent until the repo had post-006 packages. We'll be releasing a fix for that next, but you can just install it at 006 as noted in the 006->008 upgrade guide. On Saturday, December 7, 2013, Bryan Horstmann-Allen wrote: > I have the system pinned to r151006, but this doesn't appear to impact zone > installation. > > > https://gist.github.com/anonymous/7851777/raw/fdb2745ef15a9b00cdc89383e5b2f3f9bfe71ec7/gistfile1.txt > > Is this behavior expected? I'd personally expect that if you install a > zone of > a given release of the OS, the zone will be installed with that version. > > Cheers. > -- > bdha > cyberpunk is dead. long live cyberpunk. > _______________________________________________ > 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: From david.wachter at espros.ch Sun Dec 8 07:01:45 2013 From: david.wachter at espros.ch (David Wachter) Date: Sun, 8 Dec 2013 08:01:45 +0100 (CET) Subject: [OmniOS-discuss] NFS Datastore vmware esxi failover Message-ID: <2102898177.7271550.1386486105336.JavaMail.root@espros.ch> I would like to follow up on this matter. As I have followed the leads of Max(thanks) in this issue since having the same idea of building an active/active cluster with OMNIOS but with Proxmox instead. I am not shure yet - if we are following ghosts here. But ESXi and Netapp make such a ?transparent? failover without any problems. So I guess we are missing something here with ZFS. I did some further digging and found some other things - which I think haven?t been discussed here - yet. And I would like to throw them in discussion. INODE-Number: btw - I checked this, as it was mentioned somewhere. The inode stayed the same. FSID: I found this article: http://ben.timby.com/?p=109 "The first is that when you export a file system via NFS, a unique fsid is generated for that file system. The client machines that mount the exported file system use this id to generate handles to directories/files. This fsid is generated using the major/minor of the device being exported. This is a problem for me, as the device being exported is a DRBD volume with LVM on top of it. This means that when the LVM OCF RA fails over the LVM volgroup, the major/minor will change. In fact, the first device on my system had a minor of 4. This was true of both nodes. If a resource migrates, it receives the minor 4, as the existing volgroup already occupies 4. This means that the fsid will change for the exported file system and all client file handles are stale after failover.? to make it short - I was not able to set the fsid with the sharenfs property. "cannot be set to invalid options ? So after further digging I found those articles: https://github.com/zfsonlinux/zfs/issues/570 and this .. https://github.com/zfsonlinux/zfs/commit/d2e032ca9cd62fd0e80cdce30c6d1c40421bf754 They ask the that property should be enabled in ZFS source code. That just sounds somehow promising. Can this be added to sharenfs ? RMTAB: /etc/rmtab. from man: rmtab contains a table of filesystems that are remotely mounted by NFS clients. This file is maintained by mountd (1M), the mount daemon. The data in this file should be obtained only from mountd (1M) using the MOUNTPROC_DUMP remote procedure call. The file contains a line of information for each remotely mounted filesystem. There are number of lines of the form: hostname: fsname I checked the file on my install and the entries where there after the first switch. I did not try to inject lines here with the failover script. Need to solve FSID first. Summery: FSID to make ?transparent? failover with NFS working we need the FSID property in the sharenfs. (Well - I just assume that this will bring us forward.) Asking the omnios team: Can this be added ? /etc/rmtab: holds the client and mounted fs. Needs to be tested then as next issue. Thanks for reading and posting feedback on this ?> Dave --- Disclaimer: --- This email and contents is for use only by the intended recipient. If you are not the individual or entity to whom it is addressed, you are hereby formally notified that any use, copying or distribution of this email and attachments, in whole or in part, is strictly prohibited. If you have received this email in error, please notify the sender and delete the message and attachment(s) from your system. Any views, opinions or information, expressed or contained in this email, are those of the sender and not necessarily reflect those of ESPROS Photonics AG. To help protect our environment, please avoid printing out this information unnecessarily. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lotheac at iki.fi Sun Dec 8 11:01:35 2013 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Sun, 8 Dec 2013 13:01:35 +0200 Subject: [OmniOS-discuss] Zones built on r151006 install as r151008, breakage. In-Reply-To: References: <20131208002805.GA2153@lab.pobox.com> Message-ID: <20131208110135.GA11262@gutsman.lotheac.fi> On Sun, Dec 08 2013 01:54:21 -0500, Eric Sproul wrote: > Your 006 install might be missing the omnios-userland incorporation. It > was left out of the default install by mistake but wasn't apparent until > the repo had post-006 packages. We'll be releasing a fix for that next, > but you can just install it at 006 as noted in the 006->008 upgrade guide. I believe this isn't enough, since the zone install only installs entire. It would work if entire depended on omnios-userland, but in the meantime you could use 'zoneadm -z test1 install -e omnios-userland' which makes sure omnios-userland is also installed in the zone. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet From bdha at mirrorshades.net Sun Dec 8 12:33:16 2013 From: bdha at mirrorshades.net (Bryan Horstmann-Allen) Date: Sun, 8 Dec 2013 07:33:16 -0500 Subject: [OmniOS-discuss] Zones built on r151006 install as r151008, breakage. In-Reply-To: References: <20131208002805.GA2153@lab.pobox.com> Message-ID: <20131208123316.GA16385@lab.pobox.com> +------------------------------------------------------------------------------ | On 2013-12-08 01:54:21, Eric Sproul wrote: | | Your 006 install might be missing the omnios-userland incorporation. It | was left out of the default install by mistake but wasn't apparent until | the repo had post-006 packages. We'll be releasing a fix for that next, | but you can just install it at 006 as noted in the 006->008 upgrade guide. postwait also suggested I might be missing the entire incorporation, which was installed. I was missing the userland incorporation, but that does not seem to help much. The zone still installed with 151008: https://gist.github.com/bdha/7856769/raw/af8c8234fab069cec69835419f116848a5f4f9c5/gistfile1.txt Is this a brand bug, or pkg, or..? -- bdha cyberpunk is dead. long live cyberpunk. From bdha at mirrorshades.net Sun Dec 8 12:46:30 2013 From: bdha at mirrorshades.net (Bryan Horstmann-Allen) Date: Sun, 8 Dec 2013 07:46:30 -0500 Subject: [OmniOS-discuss] Zones built on r151006 install as r151008, breakage. In-Reply-To: <20131208110135.GA11262@gutsman.lotheac.fi> References: <20131208002805.GA2153@lab.pobox.com> <20131208110135.GA11262@gutsman.lotheac.fi> Message-ID: <20131208124630.GB16385@lab.pobox.com> +------------------------------------------------------------------------------ | On 2013-12-08 13:01:35, Lauri Tirkkonen wrote: | | I believe this isn't enough, since the zone install only installs | entire. It would work if entire depended on omnios-userland, but in the | meantime you could use 'zoneadm -z test1 install -e omnios-userland' | which makes sure omnios-userland is also installed in the zone. What's interesting here is... even if I'm very explict about which entire to install: # zoneadm -z test3 install -e entire at 11,5.11-0.151006:20130507T204959Z root at test3:~# cat /etc/release OmniOS v11 r151008 Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. However: # pkg -R /zones/test3/root list entire NAME (PUBLISHER) VERSION IFO entire 11-0.151006 i-- https://gist.github.com/bdha/7856878/raw/cb706c08cc6e9b2c89052c9de8a7df68df48c7a6/gistfile1.txt All three test zones (I only explicitly specified a version for test3) exihibit the same behavior: A mix of 151006 and 151008 packages. -- bdha cyberpunk is dead. long live cyberpunk. From lotheac at iki.fi Sun Dec 8 12:49:43 2013 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Sun, 8 Dec 2013 14:49:43 +0200 Subject: [OmniOS-discuss] Zones built on r151006 install as r151008, breakage. In-Reply-To: <20131208124630.GB16385@lab.pobox.com> References: <20131208002805.GA2153@lab.pobox.com> <20131208110135.GA11262@gutsman.lotheac.fi> <20131208124630.GB16385@lab.pobox.com> Message-ID: <20131208124943.GB11262@gutsman.lotheac.fi> On Sun, Dec 08 2013 07:46:30 -0500, Bryan Horstmann-Allen wrote: > +------------------------------------------------------------------------------ > | On 2013-12-08 13:01:35, Lauri Tirkkonen wrote: > | > | I believe this isn't enough, since the zone install only installs > | entire. It would work if entire depended on omnios-userland, but in the > | meantime you could use 'zoneadm -z test1 install -e omnios-userland' > | which makes sure omnios-userland is also installed in the zone. > > What's interesting here is... even if I'm very explict about which entire to > install: > > # zoneadm -z test3 install -e entire at 11,5.11-0.151006:20130507T204959Z entire is always installed matching the gz AFAIK, the -e option specifies extra packages to install, and you need omnios-userland. Try that. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet From bdha at mirrorshades.net Sun Dec 8 12:55:25 2013 From: bdha at mirrorshades.net (Bryan Horstmann-Allen) Date: Sun, 8 Dec 2013 07:55:25 -0500 Subject: [OmniOS-discuss] Zones built on r151006 install as r151008, breakage. In-Reply-To: <20131208124943.GB11262@gutsman.lotheac.fi> References: <20131208002805.GA2153@lab.pobox.com> <20131208110135.GA11262@gutsman.lotheac.fi> <20131208124630.GB16385@lab.pobox.com> <20131208124943.GB11262@gutsman.lotheac.fi> Message-ID: <20131208125525.GC16385@lab.pobox.com> +------------------------------------------------------------------------------ | On 2013-12-08 14:49:43, Lauri Tirkkonen wrote: | | entire is always installed matching the gz AFAIK, the -e option | specifies extra packages to install, and you need omnios-userland. Try | that. That sorts it # pkg -R /zones/test4/root list | grep 008 # Thanks, Lauri! -- bdha cyberpunk is dead. long live cyberpunk. From borising at gmail.com Sun Dec 8 21:19:36 2013 From: borising at gmail.com (Bo Agerskov Rising) Date: Sun, 8 Dec 2013 22:19:36 +0100 Subject: [OmniOS-discuss] New stable release: r151008 In-Reply-To: <7C8C2D53-7578-4D52-BEE2-1EDCD34F001E@coraid.com> References: <20131206015946.06867a39@sleipner.datanom.net> <20131206032642.158b351f@sleipner.datanom.net> <20131206032710.GJ2078@eschaton.local> <201312061343.rB6DhZ8B018901@elvis.arl.psu.edu> <201312061518.rB6FIUYV024934@elvis.arl.psu.edu> <20131206154730.GM2078@eschaton.local> <201312061612.rB6GCimQ028637@elvis.arl.psu.edu> <20131206164441.GO2078@eschaton.local> <21154.1006.504199.548588@glaurung.bb-c.de> <4A0990C6-6C23-4F54-AA82-1E136B50972A@coraid.com> <7C8C2D53-7578-4D52-BEE2-1EDCD34F001E@coraid.com> Message-ID: <2AF63816-756B-4B57-B8E4-6C40734D78C5@gmail.com> Hi all, For what its worth, I had the same issue as Robin, and fixed it by uninstalling the 2 packages I had installed from the ms.omniti.com repository: omniti/runtime/nodejs omniti/library/uuid After that I could upgrade my gz Regards, Bo Agerskov Rising borising at gmail.com On 08/12/2013, at 02.16, Robin P. Blanchard wrote: > iftop to blame. > > all fixed > > > On Dec 7, 2013, at 07:14 AM, Robin P. Blanchard wrote: > >> Similar woes here. Update attempted this morning: >> >> >> # pkg update -nv >> 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.151008:20131204T022427Z >> pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z >> pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z >> pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z >> >> The following indicates why the system cannot update to the latest version: >> >> No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z found: >> Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z >> Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found >> No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z found: >> Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z >> Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found >> No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z found: >> Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z >> Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found >> No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z found: >> Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z >> Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found >> >> >> # pkg info omnios-userland >> Name: incorporation/jeos/omnios-userland >> Summary: Incorporation to constrain OmniOS user-land packages to same build >> Description: This package constrains OmniOS user-land packages to the same >> build as osnet-incorporation. >> State: Installed >> Publisher: omnios >> Version: 11 >> Build Release: 5.11 >> Branch: 0.151006 >> Packaging Date: October 30, 2013 08:53:12 PM >> Size: 0.00 B >> FMRI: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z >> >> >> # pkg info pcap >> Name: system/library/pcap >> Summary: libpcap - a packet capture library >> State: Installed >> Publisher: omnios >> Version: 1.3.0 (1.3.0) >> Build Release: 5.11 >> Branch: 0.151006 >> Packaging Date: May 6, 2013 07:47:08 PM >> Size: 754.10 kB >> FMRI: pkg://omnios/system/library/pcap at 1.3.0,5.11-0.151006:20130506T194708Z >> >> # pkg publisher >> PUBLISHER TYPE STATUS URI >> omnios origin online http://pkg.omniti.com/omnios/release/ >> ms.omniti.com origin online http://pkg.omniti.com/omniti-ms/ >> uulm.mawi origin online http://scott.mathematik.uni-ulm.de/release/ >> >> >> On Dec 6, 2013, at 09:05 AM, Volker A. Brandt wrote: >> >>> Chris Nehren writes: >>>> Sorry for that. We just pushed a new omnios-userland >>>> incorporation that should fix your issues. >>>> >>>> Please install >>>> incorporation/jeos/omnios-userland at 11,5.11-0.151006 (which should >>>> get you the latest version) and you should be able to continue. >>> >>> Refreshed the catalogs and installed that: >>> >>> >> Packages to install: 1 >>> Estimated space available: 6.49 GB >>> Estimated space to be consumed: 14.56 MB >>> Create boot environment: No >>> Create backup boot environment: No >>> Rebuild boot archive: No >>> >>> Changed packages: >>> omnios >>> incorporation/jeos/omnios-userland >>> None -> 11,5.11-0.151006:20131030T205312Z >>> PHASE ACTIONS >>> Install Phase 134/134 >>> >>> PHASE ITEMS >>> Package State Update Phase 1/1 >>> Image State Update Phase 2/2 >>> >>> >>> But then: >>> >>> >> 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.151008:20131204T022427Z >>> pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z >>> pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z >>> pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z >>> Dependency analysis is unable to determine exact cause. >>> Try specifying expected results to obtain more detailed error messages. >>> >>> >>> Is "11,5.11-0.151006:20131030T205312Z" the correct version of >>> "incorporation/jeos/omnios-userland"? Looks like it's more than a >>> month old... >>> >>> >>> Regards -- Volker >>> -- >>> ------------------------------------------------------------------------ >>> Volker A. Brandt Consulting and Support for Oracle Solaris >>> Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ >>> Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de >>> Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 >>> Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt >>> >>> "When logic and proportion have fallen sloppy dead" >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> -- >> Robin P. Blanchard >> Coraid Solutions Engineer >> support.coraid.com >> 650.730.5140 >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -- > Robin P. Blanchard > Coraid Solutions Engineer > support.coraid.com > 650.730.5140 > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From esproul at omniti.com Mon Dec 9 14:59:01 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 9 Dec 2013 09:59:01 -0500 Subject: [OmniOS-discuss] userland woes In-Reply-To: References: Message-ID: On Sat, Dec 7, 2013 at 10:06 AM, Tobias Oetiker wrote: > Following the latest instructions from your webpage, we tried this: > > pkg list incorporation/jeos/omnios-userland >/dev/null 2>&1 || pkg install incorporation/jeos/omnios-userland at 11,5.11-0.151006 > > now, if we run > > # pkg update -nv > > we get > > 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. Hi Tobi, It's possible you have packages that are holding back the update. Do you use the ms.omniti.com publisher? Recent builds there incorporate on entire at the release on which they were built, to ensure they don't get installed on the wrong release. You can check to see if any unexpected incorporate dependencies exist with pkg search: pkg search -H -o pkg.fmri -l 'depend:incorporate:*@*-0.151006' | sort | uniq Under normal circumstances (that is, you use only packages from the omnios publisher) you should see only entire, illumos-gate and omnios-userland. If you see anything else, that's something to investigate. Eric From tobi at oetiker.ch Mon Dec 9 15:51:14 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 9 Dec 2013 16:51:14 +0100 (CET) Subject: [OmniOS-discuss] userland woes In-Reply-To: References: Message-ID: Hi Eric, Today Eric Sproul wrote: > On Sat, Dec 7, 2013 at 10:06 AM, Tobias Oetiker wrote: > > Following the latest instructions from your webpage, we tried this: > > > > pkg list incorporation/jeos/omnios-userland >/dev/null 2>&1 || pkg install incorporation/jeos/omnios-userland at 11,5.11-0.151006 > > > > now, if we run > > > > # pkg update -nv > > > > we get > > > > 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. > > Hi Tobi, > It's possible you have packages that are holding back the update. Do > you use the ms.omniti.com publisher? Recent builds there incorporate > on entire at the release on which they were built, to ensure they > don't get installed on the wrong release. > > You can check to see if any unexpected incorporate dependencies exist > with pkg search: > > pkg search -H -o pkg.fmri -l 'depend:incorporate:*@*-0.151006' | sort | uniq > > Under normal circumstances (that is, you use only packages from the > omnios publisher) you should see only entire, illumos-gate and > omnios-userland. If you see anything else, that's something to > investigate. ah, we are getting closer ... we have installed some packages from our own repository pkg.oetiker.ch and these packages themselfe have dependencies on ms.omniti.com stuff. namely the following: $ pkg uninstall -nv libgcrypt Creating Planpkg uninstall: Cannot remove 'pkg://ms.omniti.com/omniti/security/libgcrypt at 1.5.3,5.11-0.151006:20130810T181134Z' due to the following packages that depend on it: pkg://pkg.oetiker.ch/system/collectd at 5.4.0,5.11-0.151007:20131005T114950Z does this mean we have to rebuild the collectd package for 0.151008 because its dependency on ms.omniti.com is going away ? cheers tobi > > Eric > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From esproul at omniti.com Mon Dec 9 15:58:50 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 9 Dec 2013 10:58:50 -0500 Subject: [OmniOS-discuss] userland woes In-Reply-To: References: Message-ID: On Mon, Dec 9, 2013 at 10:51 AM, Tobias Oetiker wrote: > we have installed some packages from our own repository > pkg.oetiker.ch and these packages themselfe have dependencies on > ms.omniti.com stuff. > > namely the following: > > $ pkg uninstall -nv libgcrypt > Creating Planpkg uninstall: Cannot remove > 'pkg://ms.omniti.com/omniti/security/libgcrypt at 1.5.3,5.11-0.151006:20130810T181134Z' > due to the following packages that depend on it: > > pkg://pkg.oetiker.ch/system/collectd at 5.4.0,5.11-0.151007:20131005T114950Z > > does this mean we have to rebuild the collectd package for 0.151008 > because its dependency on ms.omniti.com is going away ? Assuming that you mean to eliminate the use of ms.omniti.com packages, yes, you'd need to rebuild collectd, either without the dependency on libgcrypt or to depend on a different libgcrypt that you supply. Eric From doug at will.to Mon Dec 9 16:11:14 2013 From: doug at will.to (Doug Hughes) Date: Mon, 9 Dec 2013 11:11:14 -0500 Subject: [OmniOS-discuss] missing shared libraries prevent automatic installation in release 1008 Message-ID: This may be AMD64 specific. I haven't checked in depth, but the following missing libraries (from miniroot.gz) prevent a successful pxe installation. Most of them are related to zfs either in creating the filesystem or in the implicit execution of share at the end of creating rootfs. In most cases it is just the final versioned .so.x.y that is missing from the miniroot.gz while the symlinks are present. I used wildcards to save time/space. Since this was an iterative process over the course of a couple of days, some of the non-amd64 libraries may not be strictly necessary. /usr/lib/libz.so* (may not be necessary) /usr/lib/libidn.so* (may not be necessary) /usr/lib/amd64/libz.so* (symlinks present but libraries not) /usr/lib/amd64/libidn.so* (") the following are necessary for the implicit share at the end of zpool create rootfs, or zpool exits with code 255 and install aborts: /usr/lib/libshare.so* /usr/lib/libxml2.so* /usr/lib/liblzma.so* (may not be necessary in favor of below) /usr/lib/amd64/liblzma.so* /usr/lb/amd64/libxml2.so* There may be the same problems in the 1006 release. Since it was failing and a newer one was available, I jumped to 1008 and skipped debugging 1006. I also added a few in for truss to see what was going on, but since they aren't germane to the final install, I'll skip those. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnehren+omnios-discuss at omniti.com Mon Dec 9 16:15:02 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Mon, 9 Dec 2013 11:15:02 -0500 Subject: [OmniOS-discuss] userland woes In-Reply-To: References: Message-ID: <20131209161502.GC67000@eschaton.local> On Mon, Dec 09, 2013 at 16:51:14 +0100, Tobias Oetiker wrote: > Hi Eric, > > Today Eric Sproul wrote: > > > You can check to see if any unexpected incorporate dependencies exist > > with pkg search: > > > > pkg search -H -o pkg.fmri -l 'depend:incorporate:*@*-0.151006' | sort | uniq > > > > Under normal circumstances (that is, you use only packages from the > > omnios publisher) you should see only entire, illumos-gate and > > omnios-userland. If you see anything else, that's something to > > investigate. > > ah, we are getting closer ... > > we have installed some packages from our own repository > pkg.oetiker.ch and these packages themselfe have dependencies on > ms.omniti.com stuff. > > namely the following: > > $ pkg uninstall -nv libgcrypt > Creating Planpkg uninstall: Cannot remove > 'pkg://ms.omniti.com/omniti/security/libgcrypt at 1.5.3,5.11-0.151006:20130810T181134Z' > due to the following packages that depend on it: > > pkg://pkg.oetiker.ch/system/collectd at 5.4.0,5.11-0.151007:20131005T114950Z > > does this mean we have to rebuild the collectd package for 0.151008 > because its dependency on ms.omniti.com is going away ? Depending on stuff in ms.omniti.com violates http://omnios.omniti.com/wiki.php/KYSTY. For reasons you're seeing here, it really is better to package your own libgcrypt. Yes, it's duplication of effort, but it means you have fewer issues overall. -- Chris Nehren Site Reliability Engineer, OmniTI From vab at bb-c.de Mon Dec 9 16:51:17 2013 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 9 Dec 2013 17:51:17 +0100 Subject: [OmniOS-discuss] userland woes In-Reply-To: <20131209161502.GC67000@eschaton.local> References: <20131209161502.GC67000@eschaton.local> Message-ID: <21157.62725.744647.328591@glaurung.bb-c.de> Chris Nehren writes: > > Today Eric Sproul wrote: > > > pkg search -H -o pkg.fmri -l 'depend:incorporate:*@*-0.151006' | > > >sort | uniq [...] This gives me: # pkg search -H -o pkg.fmri -l 'depend:incorporate:*@*-0.151006' | sort | uniq pkg: Search performance is degraded. Run 'pkg rebuild-index' to improve search speed. pkg:/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151006:20130506T161042Z pkg:/entire at 11,5.11-0.151006:20130507T204959Z pkg:/incorporation/jeos/illumos-gate at 11,5.11-0.151006:20130506T183443Z pkg:/incorporation/jeos/omnios-userland at 11,5.11-0.151006:20131030T205312Z pkg:/omniti/library/uuid at 1.41.14,5.11-0.151006:20131015T044739Z # pkg publisher PUBLISHER TYPE STATUS URI omnios origin online http://pkg.omniti.com/omnios/release/ uulm.mawi origin online http://scott.mathematik.uni-ulm.de/release/ ms.omniti.com origin online http://pkg.omniti.com/omniti-ms/ # pkg info pkg:/omniti/library/uuid at 1.41.14,5.11-0.151006:20131015T044739Z Name: omniti/library/uuid Summary: libuuid (e2fsprogs) State: Installed Publisher: ms.omniti.com Version: 1.41.14 Build Release: 5.11 Branch: 0.151006 Packaging Date: Tue Oct 15 04:47:39 2013 Size: 122.08 kB FMRI: pkg://ms.omniti.com/omniti/library/uuid at 1.41.14,5.11-0.151006:20131015T044739Z > Depending on stuff in ms.omniti.com violates > http://omnios.omniti.com/wiki.php/KYSTY. For reasons you're > seeing here, it really is better to package your own libgcrypt. > Yes, it's duplication of effort, but it means you have fewer > issues overall. So the library/uuid pkg is my problem here? That's... interesting. Is deinstalling and not using ms.omniti.com any more the only option? Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From esproul at omniti.com Mon Dec 9 17:08:59 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 9 Dec 2013 12:08:59 -0500 Subject: [OmniOS-discuss] userland woes In-Reply-To: <21157.62725.744647.328591@glaurung.bb-c.de> References: <20131209161502.GC67000@eschaton.local> <21157.62725.744647.328591@glaurung.bb-c.de> Message-ID: On Mon, Dec 9, 2013 at 11:51 AM, Volker A. Brandt wrote: > So the library/uuid pkg is my problem here? That's... interesting. > Is deinstalling and not using ms.omniti.com any more the only option? The packages in ms.omniti.com were built for r151006, so they appropriately use an incorporate dependency on entire at 151006. Eventually there will be r151008 versions in ms.omniti.com, so it's your choice. You can wait for that to happen or you can remove uuid and move the system forward. Eric From cnehren+omnios-discuss at omniti.com Mon Dec 9 17:20:44 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Mon, 9 Dec 2013 12:20:44 -0500 Subject: [OmniOS-discuss] userland woes In-Reply-To: References: <20131209161502.GC67000@eschaton.local> <21157.62725.744647.328591@glaurung.bb-c.de> Message-ID: <20131209172044.GG67000@eschaton.local> On Mon, Dec 09, 2013 at 12:08:59 -0500, Eric Sproul wrote: > On Mon, Dec 9, 2013 at 11:51 AM, Volker A. Brandt wrote: > > So the library/uuid pkg is my problem here? That's... interesting. > > Is deinstalling and not using ms.omniti.com any more the only option? > > The packages in ms.omniti.com were built for r151006, so they > appropriately use an incorporate dependency on entire at 151006. > Eventually there will be r151008 versions in ms.omniti.com, so it's > your choice. You can wait for that to happen or you can remove uuid > and move the system forward. Or, since the build bits are open source, you can build your own local copies and use those. Yes, it's an inconvenience, but we're working on it, and there are ways forward beyond "don't use this thing that's critical for your app". -- Chris Nehren Site Reliability Engineer, OmniTI From mir at miras.org Mon Dec 9 17:27:45 2013 From: mir at miras.org (Michael Rasmussen) Date: Mon, 9 Dec 2013 18:27:45 +0100 Subject: [OmniOS-discuss] userland woes In-Reply-To: References: <20131209161502.GC67000@eschaton.local> <21157.62725.744647.328591@glaurung.bb-c.de> Message-ID: <20131209182745.2aa1a876@sleipner.datanom.net> On Mon, 9 Dec 2013 12:08:59 -0500 Eric Sproul wrote: > On Mon, Dec 9, 2013 at 11:51 AM, Volker A. Brandt wrote: > > So the library/uuid pkg is my problem here? That's... interesting. > > Is deinstalling and not using ms.omniti.com any more the only option? > > The packages in ms.omniti.com were built for r151006, so they > appropriately use an incorporate dependency on entire at 151006. > Eventually there will be r151008 versions in ms.omniti.com, so it's > your choice. You can wait for that to happen or you can remove uuid > and move the system forward. > Discussing dependencies. My experience moving from 150007 to 150008 ended up by reinstalling using official ISO. What prevented a smooth upgrade from 150007 to 150008 was a missing userland for 150007 (my packages in 150007, even though I did not upgrade for several months, was never than latest userland in 150007. So my question is: How come that userland is not installed even though we are dealing with bloody? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Use the "telephone test" for readability. - The Elements of Programming Style (Kernighan & Plaugher) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ben at fluffy.co.uk Mon Dec 9 17:41:58 2013 From: ben at fluffy.co.uk (Ben Summers) Date: Mon, 9 Dec 2013 17:41:58 +0000 Subject: [OmniOS-discuss] userland woes In-Reply-To: References: <20131209161502.GC67000@eschaton.local> <21157.62725.744647.328591@glaurung.bb-c.de> Message-ID: <0BFE11DD-B4CA-41C2-8A99-A9E53B7FBBA6@fluffy.co.uk> On 9 Dec 2013, at 17:08, Eric Sproul wrote: > On Mon, Dec 9, 2013 at 11:51 AM, Volker A. Brandt wrote: >> So the library/uuid pkg is my problem here? That's... interesting. >> Is deinstalling and not using ms.omniti.com any more the only option? > > The packages in ms.omniti.com were built for r151006, so they > appropriately use an incorporate dependency on entire at 151006. > Eventually there will be r151008 versions in ms.omniti.com, so it's > your choice. You can wait for that to happen or you can remove uuid > and move the system forward. Given that there will be r151006 and r151008 versions of your own stuff, does this imply that software built for r151006 won't necessarily run on r151008 and we should copy OmniTI by building new versions of everything? Thanks! Ben From scotty at jhu.edu Mon Dec 9 17:50:44 2013 From: scotty at jhu.edu (Scott Roberts) Date: Mon, 9 Dec 2013 17:50:44 +0000 Subject: [OmniOS-discuss] Heirarchical Storage Recommendation Message-ID: Hello all, What is the current recommendation for HSM under OmniOS? We?re deploying new ZFS storage arrays and I recall hearing something about SAM-QFS back in the OpenSolaris days. However, it looks like you need Oracle support to get the latest patches. Thanks in advance for your input, ?Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From scotty at jhu.edu Mon Dec 9 18:39:12 2013 From: scotty at jhu.edu (Scott Roberts) Date: Mon, 9 Dec 2013 18:39:12 +0000 Subject: [OmniOS-discuss] Heirarchical Storage Recommendation Message-ID: Some digging found this: http://www.oracle.com/technetwork/systems/articles/enterprise-vault-x4500-naas-jsp-135756.html. However, the document (http://www.sun.com/bigadmin/sundocs/articles/enterprise_vault_x4500_naas.pdf) is missing. Oh well. From: Scott Roberts > Date: Monday, December 9, 2013 at 12:50 PM To: OmniOS-discuss > Subject: [OmniOS-discuss] Heirarchical Storage Recommendation Hello all, What is the current recommendation for HSM under OmniOS? We?re deploying new ZFS storage arrays and I recall hearing something about SAM-QFS back in the OpenSolaris days. However, it looks like you need Oracle support to get the latest patches. Thanks in advance for your input, ?Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Mon Dec 9 21:45:46 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 9 Dec 2013 13:45:46 -0800 Subject: [OmniOS-discuss] mpt_sas wedge Message-ID: <090701cef528$06b51230$141f3690$@acm.org> My storage server (currently running omnios stable 151006) with an LSI 9201-16i SAS controller misbehaved this morning :(. It started out with some complaints about a target: Dec 9 05:18:23 storage kernel: scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,3c0 a at 3,2/pci1000,30c0 at 0 (mpt_sas0): Log info 0x31080000 received for target 17. scsi_status=0x0, ioc_status=0x804b, scsi_state=0x0 It repeated quite a few of these, then one with a different status: Dec 9 05:24:11 storage kernel: scsi_vhci: [ID 734749 kern.warning] WARNING: vhci_scsi_res et 0x1 Dec 9 05:24:11 storage kernel: scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,3c0a at 3,2/pci1 000,30c0 at 0 (mpt_sas0): Log info 0x31140000 received for target 17. scsi_status=0x0, ioc_status=0x8048, scsi_state=0xc Then it seems it tried to reset the bus: Dec 9 05:28:18 storage kernel: scsi_vhci: [ID 734749 kern.warning] WARNING: vhci_scsi_res et 0x1 And then it got really unhappy: Dec 9 05:28:42 storage kernel: scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,3 c0a at 3,2/pci1000,30c0 at 0 (mpt_sas0): mptsas_check_task_mgt: Task 0x3 failed. IOCStatus=0x4a IOCLogInfo=0x0 target=17 Dec 9 05:28:42 storage kernel: scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,3 c0a at 3,2/pci1000,30c0 at 0 (mpt_sas0): mptsas_ioc_task_management failed try to reset ioc to recovery! Dec 9 05:28:44 storage kernel: scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,3c0a at 3,2/pci1 000,30c0 at 0 (mpt_sas0): mpt0 Firmware version v16.0.0.0 (?) Dec 9 05:28:44 storage kernel: scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,3c0a at 3,2/pci1 000,30c0 at 0 (mpt_sas0): mpt0: IOC Operational. Dec 9 05:29:45 storage kernel: scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,3 c0a at 3,2/pci1000,30c0 at 0 (mpt_sas0): config header request timeout Dec 9 05:29:45 storage kernel: scsi: [ID 365881 kern.warning] WARNING: /pci at 0,0/pci8086,3 c0a at 3,2/pci1000,30c0 at 0 (mpt_sas0): NULL command for address reply in slot 6 Dec 9 05:30:45 storage kernel: scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,3 c0a at 3,2/pci1000,30c0 at 0 (mpt_sas0): config header request timeout Dec 9 05:31:45 storage kernel: scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,3 c0a at 3,2/pci1000,30c0 at 0 (mpt_sas0): config header request timeout Dec 9 05:31:45 storage kernel: scsi: [ID 243001 kern.warning] WARNING: /scsi_vhci (scsi_v hci0): sd10: path mpt_sas7/disk at w50014ee603347e67,0, reset 1 failed Dec 9 05:31:45 storage kernel: scsi: [ID 365881 kern.warning] WARNING: /pci at 0,0/pci8086,3c0a at 3,2/pci1000,30c0 at 0 (mpt_sas0): NULL command for address reply in slot 38 Dec 9 05:31:45 storage kernel: scsi: [ID 365881 kern.warning] WARNING: /pci at 0,0/pci8086,3 c0a at 3,2/pci1000,30c0 at 0 (mpt_sas0): NULL command for address reply in slot 54 At this point, it looks like any I/O to any device on that controller was wedged, which pretty much took out my storage pool. I sent an NMI to try and get a crash dump, but while my dump device is a raw disk, not part of any zpool, it is on that controller, and after about an hour I gave up and just did a hard reset. It came up okay, and seemed to be working fine. I ran a few scrubs to see what would happen, on every scrub I saw some of the same errors: Dec 9 13:03:02 storage kernel: scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,3c0 a at 3,2/pci1000,30c0 at 0 (mpt_sas0): Log info 0x31080000 received for target 17. scsi_status=0x0, ioc_status=0x804b, scsi_state=0x0 Sometimes it would reset the bus, sometimes it wouldn't, but while I was poking at it it never completely wedged up and froze like it did earlier this morning. Disks fail, I'm running RAIDZ2 on this box plus have a hot spare, so no worries there; but it kind of sucks when a misbehaving disk takes out the entire controller :(. I went ahead and off-lined the disk and replaced it with a hot spare, I'll poke at it some more once it is done resilvering and make sure I don't get any more errors. Is it a pretty sure bet that the disk is going bad, or should I take the time/trouble to pull it out and run diagnostics on it on a separate machine before RMA'ing it? I vaguely recall seeing some mpt_sas improvements flyby over the past 6-8 months, once the first update for 151008 comes out I guess I will go ahead and upgrade to that, maybe next time things go wiggy it won't take out the whole controller. One question; in this case, when it completely died, it ended up printing out the wwn of the drive in question so it was easy to find. However, I'm not quite sure how to map "target 17" to an actual disk if all I had were the warning messages. Any pointers? Thanks much. From esproul at omniti.com Mon Dec 9 22:20:21 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 9 Dec 2013 17:20:21 -0500 Subject: [OmniOS-discuss] [discuss] mpt_sas wedge In-Reply-To: <090701cef528$06b51230$141f3690$@acm.org> References: <090701cef528$06b51230$141f3690$@acm.org> Message-ID: On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson wrote: > I vaguely recall seeing some mpt_sas improvements flyby over the past 6-8 > months, once the first update for 151008 comes out I guess I will go ahead > and upgrade to that, maybe next time things go wiggy it won't take out the > whole controller. We back-ported the major one, which was the fix for https://www.illumos.org/issues/4013 aka "backout 6910752/6968206: needs more work". Make sure you have driver/storage/mpt_sas at 0.5.11,5.11-0.151006:20130906T160306Z which contains the fix. > > One question; in this case, when it completely died, it ended up printing > out the wwn of the drive in question so it was easy to find. However, I'm > not quite sure how to map "target 17" to an actual disk if all I had were > the warning messages. Any pointers? AFAIK mapping the topology behind an mpt_sas device required private ioctls to extract that info from the IOC. Josh Clulow did the grunt work to get that done, in https://www.illumos.org/issues/4018 and we have *that* stuff in r151008. In r151006 you would need to use LSI's "sas2ircu" utility to get that information. Eric From henson at acm.org Mon Dec 9 23:07:39 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 9 Dec 2013 15:07:39 -0800 Subject: [OmniOS-discuss] [discuss] mpt_sas wedge In-Reply-To: References: <090701cef528$06b51230$141f3690$@acm.org> Message-ID: <090d01cef533$77568860$66039920$@acm.org> > From: Eric Sproul > Sent: Monday, December 09, 2013 2:20 PM > > needs more work". Make sure you have > driver/storage/mpt_sas at 0.5.11,5.11-0.151006:20130906T160306Z which > contains the fix. Looks like I've just got 0.5.11-0.151006 right now, I installed from the latest 151006 release media at the time, but I don't think I've updated since, so I'm probably a little out of date on 151006 updates. I'll be updating to 151008 shortly, so will pull it in that way. > work to get that done, in https://www.illumos.org/issues/4018 and we > have *that* stuff in r151008. Cool, more to look forward to :). Where is the libtopo data exposed? Does it end up in the fault management log, or can you dump it with prtconf -v? Hmm, actually, looking at the fault management log, even with the current version while the error logged via syslog did not include the wwn, the fault management error log does, so I guess even in this version I would have had enough information to figure it out: Dec 09 2013 05:18:23.195493496 ereport.io.scsi.cmd.disk.tran nvlist version: 0 class = ereport.io.scsi.cmd.disk.tran ena = 0xee88d202d6401401 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev device-path = /pci at 0,0/pci8086,3c0a at 3,2/pci1000,30c0 at 0/iport at 1/disk at w50014ee603347e67,0 (end detector) devid = id1,sd at n50014ee603347e67 driver-assessment = retry op-code = 0x28 cdb = 0x28 0x0 0x2 0x1b 0xe 0x48 0x0 0x0 0xc0 0x0 pkt-reason = 0x4 pkt-state = 0x0 pkt-stats = 0x10 __ttl = 0x1 __tod = 0x52a5c31f 0xba6fe78 Thanks much. From henson at acm.org Tue Dec 10 00:06:55 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 9 Dec 2013 16:06:55 -0800 Subject: [OmniOS-discuss] [discuss] mpt_sas wedge In-Reply-To: References: <090701cef528$06b51230$141f3690$@acm.org> Message-ID: <091701cef53b$bee7f030$3cb7d090$@acm.org> > From: Garrett D'Amore [mailto:garrett at damore.org] > Sent: Monday, December 09, 2013 3:10 PM > > This *looks* like its SAS drives, but can you confirm that you're using SAS > disks and not SATA drives in an expander or converter? I intended to mention in the original message that this was a WD red 3TB SATA drive, perhaps I forgot. So it is a SATA drive, but there are no expanders involved, it is connected directly to a single port on the SAS hba. I was aware of potential issues with SATA drives and SAS expanders, and made sure to avoid such a configuration, but my understanding was that a SATA disk attached directly to a SAS hba shouldn't be a problem. From henson at acm.org Tue Dec 10 02:37:00 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 9 Dec 2013 18:37:00 -0800 Subject: [OmniOS-discuss] Supermicro IPMI based BIOS update Message-ID: <094801cef550$b5cc58a0$216509e0$@acm.org> This isn't strictly an illumos question, but supermicro kit is pretty popular for running illumos, so you guys are usually an excellent resource for questions like this :). I recently bought a supermicro X9SCL-F motherboard, which came with a new version of the IPMI firmware, 3.15. This version is also becoming available as an update for older boards, including my X9DRi-F. A new feature on this version of the IPMI web interface is allegedly the ability to update the BIOS completely hands-off. Unfortunately, it seems supermicro decided to make this a "value added" feature, so out-of-the-box all you see on that page is a request for an activation key :(. I've gone back and forth with supermicro technical support a bit, and gotten a reasonable grip on the technical details of the feature. Supposedly you can update the BIOS on a board that's not powered on and doesn't even have a CPU installed, which would be handy for those intervals where an updated processor has been released requiring a bios update, but boards are still being shipped with the old bios. They also say that unlike the boot to DOS installer, which always says you're required to completely remove power from the system and short the clear CMOS jumper, when updating the BIOS via the IPMI interface you don't need to do that. It also supposedly allows you to fix a corrupted BIOS that normally would require RMA'ing the board back to supermicro to reprogram, which is nice, I'm always nervous doing BIOS updates that I might brick the board and causing extensive downtime. As far as actually enabling the feature, they just tell me I should contact my reseller. I don't exactly buy a lot of volume :), so that would be somebody like Newegg, Amazon, Superbiiz... And so far they don't seem to have "IPMI BIOS update activation keys" available for sale. I was just curious if anybody else had looked at this, or possibly actually activated it, out of interest in the details of buying the feature as well as how well it worked out for anybody that's tried it. Thanks. From moo at wuffers.net Tue Dec 10 03:34:50 2013 From: moo at wuffers.net (wuffers) Date: Mon, 9 Dec 2013 22:34:50 -0500 Subject: [OmniOS-discuss] Supermicro IPMI based BIOS update In-Reply-To: <094801cef550$b5cc58a0$216509e0$@acm.org> References: <094801cef550$b5cc58a0$216509e0$@acm.org> Message-ID: Huh, I had recently updated all my servers' IPMI firmware as well as BIOS recently, and didn't notice this new feature. It's kind of interesting that they're trying to charge for it (at least that's the assumption with an "activation key"). It's useful, but outside of the "fix corrupted BIOS" (which would probably save themselves $$$), not worth a premium. How hard is it to update the BIOS manually by hand anyways? I've just emailed my reseller about this, so I'll update this thread when I get a response. On Mon, Dec 9, 2013 at 9:37 PM, Paul B. Henson wrote: > This isn't strictly an illumos question, but supermicro kit is pretty > popular for running illumos, so you guys are usually an excellent resource > for questions like this :). > > I recently bought a supermicro X9SCL-F motherboard, which came with a new > version of the IPMI firmware, 3.15. This version is also becoming available > as an update for older boards, including my X9DRi-F. A new feature on this > version of the IPMI web interface is allegedly the ability to update the > BIOS completely hands-off. > > Unfortunately, it seems supermicro decided to make this a "value added" > feature, so out-of-the-box all you see on that page is a request for an > activation key :(. > > I've gone back and forth with supermicro technical support a bit, and > gotten > a reasonable grip on the technical details of the feature. Supposedly you > can update the BIOS on a board that's not powered on and doesn't even have > a > CPU installed, which would be handy for those intervals where an updated > processor has been released requiring a bios update, but boards are still > being shipped with the old bios. They also say that unlike the boot to DOS > installer, which always says you're required to completely remove power > from > the system and short the clear CMOS jumper, when updating the BIOS via the > IPMI interface you don't need to do that. It also supposedly allows you to > fix a corrupted BIOS that normally would require RMA'ing the board back to > supermicro to reprogram, which is nice, I'm always nervous doing BIOS > updates that I might brick the board and causing extensive downtime. > > As far as actually enabling the feature, they just tell me I should contact > my reseller. I don't exactly buy a lot of volume :), so that would be > somebody like Newegg, Amazon, Superbiiz... And so far they don't seem to > have "IPMI BIOS update activation keys" available for sale. > > I was just curious if anybody else had looked at this, or possibly actually > activated it, out of interest in the details of buying the feature as well > as how well it worked out for anybody that's tried it. > > 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: From henson at acm.org Tue Dec 10 04:13:03 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 9 Dec 2013 20:13:03 -0800 Subject: [OmniOS-discuss] mpt_sas wedge In-Reply-To: <090701cef528$06b51230$141f3690$@acm.org> References: <090701cef528$06b51230$141f3690$@acm.org> Message-ID: <20131210041303.GN4044@bender.unx.csupomona.edu> On Mon, Dec 09, 2013 at 01:45:46PM -0800, Paul B. Henson wrote: > make sure I don't get any more errors. Is it a pretty sure bet that the disk > is going bad, or should I take the time/trouble to pull it out and run > diagnostics on it on a separate machine before RMA'ing it? Definitely a bad disk, I yanked it out and stuck it in a linux box to test, it immediately failed a short smart test: Self-test execution status: ( 116) The previous self-test completed having the read element of the test failed. [...] SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA _of_first_error # 1 Short offline Completed: read failure 40% 1445 # 3655496 Submitting an advance RMA request through Western Digital was pretty painless, hopefully the replacement will show up shortly. Other than the controller failing and requiring a hard reboot about what I'd expect from a dead drive... From henson at acm.org Tue Dec 10 04:17:35 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 9 Dec 2013 20:17:35 -0800 Subject: [OmniOS-discuss] [discuss] mpt_sas wedge In-Reply-To: References: <090701cef528$06b51230$141f3690$@acm.org> <091701cef53b$bee7f030$3cb7d090$@acm.org> Message-ID: <20131210041735.GP4044@bender.unx.csupomona.edu> On Mon, Dec 09, 2013 at 05:23:07PM -0800, Garrett D'Amore wrote: > That's right... direct connection *with nothing else on the bus* should be > fine. Cool. Hopefully that mpt_sas commit I'm currently lacking will keep the controller from going wiggy next time. It cost a bit more for the 16 port HBA vs the 4 port, but a lot less than 13 3TB SAS disks vs the WD red SATA disks. Thanks... > > > From: Garrett D'Amore [mailto:garrett at damore.org] > > > Sent: Monday, December 09, 2013 3:10 PM > > > > > > This *looks* like its SAS drives, but can you confirm that you're using > > SAS > > > disks and not SATA drives in an expander or converter? > > > > I intended to mention in the original message that this was a WD red 3TB > > SATA drive, perhaps I forgot. So it is a SATA drive, but there are no > > expanders involved, it is connected directly to a single port on the SAS > > hba. I was aware of potential issues with SATA drives and SAS expanders, > > and > > made sure to avoid such a configuration, but my understanding was that a > > SATA disk attached directly to a SAS hba shouldn't be a problem. From henson at acm.org Tue Dec 10 04:28:17 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 9 Dec 2013 20:28:17 -0800 Subject: [OmniOS-discuss] Supermicro IPMI based BIOS update In-Reply-To: References: <094801cef550$b5cc58a0$216509e0$@acm.org> Message-ID: <20131210042817.GQ4044@bender.unx.csupomona.edu> On Mon, Dec 09, 2013 at 10:34:50PM -0500, wuffers wrote: > Huh, I had recently updated all my servers' IPMI firmware as well as BIOS > recently, and didn't notice this new feature. The other new feature is a power usage/statistics screen which is kinda cool, but only works if your power supply has an i2c connection to the motherboard. And then this version is supposed to fix some of the swiss cheese security holes that the previous ipmi firmware had. It breaks using SOL over the ssh interface though, I have an open bug report on that, they say they're working on it. > It's kind of interesting that they're trying to charge for it (at least > that's the assumption with an "activation key"). Not just an assumption, support verified it's an additional cost feature, they think it will run about $15 but said I needed to check with a reseller to verify. > It's useful, but outside of the "fix corrupted BIOS" (which would > probably save themselves $$$), not worth a premium. How hard is it to > update the BIOS manually by hand anyways? Well, by hand typically involves visiting the box, maybe to stick in a USB stick, if nothing else to clear the CMOS (unless you ignore that part of the bios update instructions). Plus some boards (like the X9DRi-F) recommend you disable the Intel management engine bios by moving jumpers before updating the bios. The IPMI method doesn't need any physical proximity, so if you've got a *lot* of boxes, it would save a lot of time. I made the point to support that given they will reprogram boards with corrupted BIOS chips for free even out of warranty, which probably costs them more than $15, it would be a cost savings to just include it. They actually agreed, but said upper management decided to nickel and dime it . > I've just emailed my reseller about this, so I'll update this thread when I > get a response. Cool, thanks. I assume they need a serial number or something to tie it to the specific board, otherwise you could just buy one activation key and use it everywhere. From moo at wuffers.net Tue Dec 10 05:04:05 2013 From: moo at wuffers.net (wuffers) Date: Tue, 10 Dec 2013 00:04:05 -0500 Subject: [OmniOS-discuss] mpt_sas wedge In-Reply-To: <090701cef528$06b51230$141f3690$@acm.org> References: <090701cef528$06b51230$141f3690$@acm.org> Message-ID: On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson wrote: > > One question; in this case, when it completely died, it ended up printing > out the wwn of the drive in question so it was easy to find. However, I'm > not quite sure how to map "target 17" to an actual disk if all I had were > the warning messages. Any pointers? > I had some SCSI warnings as well relating to a target, and I found this helpful thread on determining a disk target (uses lsiutil): http://lists.omniti.com/pipermail/omnios-discuss/2013-March/000544.html It'll help you find a serial number or wwn. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emunch at utmi.in Tue Dec 10 09:21:11 2013 From: emunch at utmi.in (Sam M) Date: Tue, 10 Dec 2013 14:51:11 +0530 Subject: [OmniOS-discuss] Fixing a Package With Errors In-Reply-To: References: Message-ID: Anyone? Am kind of stuck here. Thanks. On 04/12/2013, Sam M wrote: > Hello. > > I'm running OmniOS Bloody. I was getting an error with visudo so I tried to > fix this by re-0nstalling the package in question. But I'm unable to. How > can I fix this? How do I create/modify an alternate boot environment? > > BTW, I upgraded from Release to Bloody, so I booted into a Release boot > envirnment, and I'm seeing the same error with libc.so.1 as in Bloody. > > TIA. > > Sam > > System > *# uname -a* > SunOS sequoia 5.11 omnios-e97fba8 i86pc i386 i86pc > > Error - > *# visudo* > ld.so.1: visudo: fatal: libc.so.1: version 'ILLUMOS_0.7' not found > (required by file /usr/sbin/visudo) > ld.so.1: visudo: fatal: libc.so.1: open failed: No such file or directory > Killed > > pkg fix error - > *# pkg fix pkg://omnios/system/library * > Verifying: pkg://omnios/system/library ERROR > > file: lib/libc.so.1 > Elfhash: c31add3bd373a101cb7aa14a2185beef9bd6ad61 should be > 2f678d3e88ee49238a7c4b87dfdcc92837ea5814 > Created ZFS snapshot: 2013-12-04-14:00:23 > > Repairing: pkg://omnios/system/library > pkg: Requested "fix" operation would affect files that cannot be modified > in live image. > Please retry this operation on an alternate boot environment. > From narayan.desai at gmail.com Tue Dec 10 13:01:33 2013 From: narayan.desai at gmail.com (Narayan Desai) Date: Tue, 10 Dec 2013 07:01:33 -0600 Subject: [OmniOS-discuss] mpt_sas wedge In-Reply-To: <20131210041303.GN4044@bender.unx.csupomona.edu> References: <090701cef528$06b51230$141f3690$@acm.org> <20131210041303.GN4044@bender.unx.csupomona.edu> Message-ID: We've started running smartctl to try to catch sata drive failures earlier. it seems to avoid mayhem in our experience. -nld On Mon, Dec 9, 2013 at 10:13 PM, Paul B. Henson wrote: > On Mon, Dec 09, 2013 at 01:45:46PM -0800, Paul B. Henson wrote: > > > make sure I don't get any more errors. Is it a pretty sure bet that the > disk > > is going bad, or should I take the time/trouble to pull it out and run > > diagnostics on it on a separate machine before RMA'ing it? > > Definitely a bad disk, I yanked it out and stuck it in a linux box to > test, it immediately failed a short smart test: > > Self-test execution status: ( 116) The previous self-test completed > having > the read element of the test > failed. > [...] > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining LifeTime(hours) > LBA _of_first_error > # 1 Short offline Completed: read failure 40% 1445 # > 3655496 > > Submitting an advance RMA request through Western Digital was pretty > painless, hopefully the replacement will show up shortly. Other than the > controller failing and requiring a hard reboot about what I'd expect > from a dead drive... > _______________________________________________ > 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: From narayan.desai at gmail.com Tue Dec 10 13:03:34 2013 From: narayan.desai at gmail.com (Narayan Desai) Date: Tue, 10 Dec 2013 07:03:34 -0600 Subject: [OmniOS-discuss] [discuss] mpt_sas wedge In-Reply-To: References: <090701cef528$06b51230$141f3690$@acm.org> Message-ID: I hacked up some stuff using sas2ircu to build system level summaries. It build a table of all of the identifiers that I could find in the logs: https://github.com/narayandesai/diy-lsi -nld On Mon, Dec 9, 2013 at 4:20 PM, Eric Sproul wrote: > On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson wrote: > > > I vaguely recall seeing some mpt_sas improvements flyby over the past 6-8 > > months, once the first update for 151008 comes out I guess I will go > ahead > > and upgrade to that, maybe next time things go wiggy it won't take out > the > > whole controller. > > We back-ported the major one, which was the fix for > https://www.illumos.org/issues/4013 aka "backout 6910752/6968206: > needs more work". Make sure you have > driver/storage/mpt_sas at 0.5.11,5.11-0.151006:20130906T160306Z which > contains the fix. > > > > > One question; in this case, when it completely died, it ended up printing > > out the wwn of the drive in question so it was easy to find. However, I'm > > not quite sure how to map "target 17" to an actual disk if all I had were > > the warning messages. Any pointers? > > AFAIK mapping the topology behind an mpt_sas device required private > ioctls to extract that info from the IOC. Josh Clulow did the grunt > work to get that done, in https://www.illumos.org/issues/4018 and we > have *that* stuff in r151008. > > In r151006 you would need to use LSI's "sas2ircu" utility to get that > information. > > Eric > _______________________________________________ > 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: From cnehren+omnios-discuss at omniti.com Tue Dec 10 15:04:03 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Tue, 10 Dec 2013 10:04:03 -0500 Subject: [OmniOS-discuss] Fixing a Package With Errors In-Reply-To: References: Message-ID: <20131210150403.GM67000@eschaton.local> The best way to fix this would be to roll back to a prior BE, figure out what broke you upgrade, fix i, and try again. On Tue, Dec 10, 2013 at 14:51:11 +0530, Sam M wrote: > Anyone? Am kind of stuck here. > > Thanks. > > On 04/12/2013, Sam M wrote: > > Hello. > > > > I'm running OmniOS Bloody. I was getting an error with visudo so I tried to > > fix this by re-0nstalling the package in question. But I'm unable to. How > > can I fix this? How do I create/modify an alternate boot environment? > > > > BTW, I upgraded from Release to Bloody, so I booted into a Release boot > > envirnment, and I'm seeing the same error with libc.so.1 as in Bloody. > > > > TIA. > > > > Sam > > > > System > > *# uname -a* > > SunOS sequoia 5.11 omnios-e97fba8 i86pc i386 i86pc > > > > Error - > > *# visudo* > > ld.so.1: visudo: fatal: libc.so.1: version 'ILLUMOS_0.7' not found > > (required by file /usr/sbin/visudo) > > ld.so.1: visudo: fatal: libc.so.1: open failed: No such file or directory > > Killed > > > > pkg fix error - > > *# pkg fix pkg://omnios/system/library * > > Verifying: pkg://omnios/system/library ERROR > > > > file: lib/libc.so.1 > > Elfhash: c31add3bd373a101cb7aa14a2185beef9bd6ad61 should be > > 2f678d3e88ee49238a7c4b87dfdcc92837ea5814 > > Created ZFS snapshot: 2013-12-04-14:00:23 > > > > Repairing: pkg://omnios/system/library > > pkg: Requested "fix" operation would affect files that cannot be modified > > in live image. > > Please retry this operation on an alternate boot environment. > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Chris Nehren Site Reliability Engineer, OmniTI From hasslerd at gmx.li Tue Dec 10 15:42:42 2013 From: hasslerd at gmx.li (Dominik Hassler) Date: Tue, 10 Dec 2013 16:42:42 +0100 Subject: [OmniOS-discuss] apache22 after upgrading to r151008 Message-ID: <52A73672.9010608@gmx.li> hi there, to be able to install omnios-userland at 11,5.11-0.151006 and upgrade omnios to r151008 i had to remove serveral ms.omniti packages, including apache22. however after successfully upgrading omnios to r151008, if i dry-run install apache22 again it looks like there won't be any issues. # cat /etc/release OmniOS v11 r151008 Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. # pkg list |grep omnios-userland incorporation/jeos/omnios-userland 11-0.151008 i-- # pkg install -nv omniti/server/apache22 Packages to install: 4 Estimated space available: 197.32 GB Estimated space to be consumed: 66.73 MB Create boot environment: No Create backup boot environment: No Rebuild boot archive: No Changed packages: ms.omniti.com omniti/library/apr None -> 1.4.6,5.11-0.151002:20120401T205441Z omniti/library/apr-util None -> 1.4.1,5.11-0.151002:20120401T200739Z omniti/library/uuid None -> 1.41.14,5.11-0.151002:20120401T185308Z omniti/server/apache22 None -> 2.2.25,5.11-0.151006:20130904T164853Z this seems odd to me. how can this be explained? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xF9ECC6A5.asc Type: application/pgp-keys Size: 2686 bytes Desc: not available URL: From jesus at omniti.com Tue Dec 10 15:55:23 2013 From: jesus at omniti.com (Theo Schlossnagle) Date: Tue, 10 Dec 2013 10:55:23 -0500 Subject: [OmniOS-discuss] apache22 after upgrading to r151008 In-Reply-To: <52A73672.9010608@gmx.li> References: <52A73672.9010608@gmx.li> Message-ID: You are likely getting older versions that don't rely on 151006. At some point in the lifecycle of ms.omniti.com we opted to make the packages depend on the release. On Tue, Dec 10, 2013 at 10:42 AM, Dominik Hassler wrote: > hi there, > > to be able to install omnios-userland at 11,5.11-0.151006 and upgrade > omnios to r151008 i had to remove serveral ms.omniti packages, including > apache22. > > however after successfully upgrading omnios to r151008, if i dry-run > install apache22 again it looks like there won't be any issues. > > # cat /etc/release > OmniOS v11 r151008 > Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved. > Use is subject to license terms. > > # pkg list |grep omnios-userland > incorporation/jeos/omnios-userland 11-0.151008 i-- > > # pkg install -nv omniti/server/apache22 > Packages to install: 4 > Estimated space available: 197.32 GB > Estimated space to be consumed: 66.73 MB > Create boot environment: No > Create backup boot environment: No > Rebuild boot archive: No > > Changed packages: > ms.omniti.com > omniti/library/apr > None -> 1.4.6,5.11-0.151002:20120401T205441Z > omniti/library/apr-util > None -> 1.4.1,5.11-0.151002:20120401T200739Z > omniti/library/uuid > None -> 1.41.14,5.11-0.151002:20120401T185308Z > omniti/server/apache22 > None -> 2.2.25,5.11-0.151006:20130904T164853Z > > > > this seems odd to me. how can this be explained? > > _______________________________________________ > 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: From hasslerd at gmx.li Tue Dec 10 16:32:07 2013 From: hasslerd at gmx.li (Dominik Hassler) Date: Tue, 10 Dec 2013 17:32:07 +0100 Subject: [OmniOS-discuss] apache22 after upgrading to r151008 In-Reply-To: References: <52A73672.9010608@gmx.li> Message-ID: <52A74207.4000406@gmx.li> hmm, my point was the following: these older versions (installed on my r151006) prevented me from upgrading, but now can be installed again (the same versions that have been installed) after the upgrade has been finished. why does a piece of software prevent me from upgrading if it can be installed again (same version as before) after upgrading? sorry i'm quite new to omnios. On 12/10/2013 04:55 PM, Theo Schlossnagle wrote: > You are likely getting older versions that don't rely on 151006. > > At some point in the lifecycle of ms.omniti.com > we opted to make the packages depend on the release. > > > On Tue, Dec 10, 2013 at 10:42 AM, Dominik Hassler > wrote: > > hi there, > > to be able to install omnios-userland at 11,5.11-0.151006 and upgrade > omnios to r151008 i had to remove serveral ms.omniti packages, including > apache22. > > however after successfully upgrading omnios to r151008, if i dry-run > install apache22 again it looks like there won't be any issues. > > # cat /etc/release > OmniOS v11 r151008 > Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved. > Use is subject to license terms. > > # pkg list |grep omnios-userland > incorporation/jeos/omnios-userland 11-0.151008 i-- > > # pkg install -nv omniti/server/apache22 > Packages to install: 4 > Estimated space available: 197.32 GB > Estimated space to be consumed: 66.73 MB > Create boot environment: No > Create backup boot environment: No > Rebuild boot archive: No > > Changed packages: > ms.omniti.com > omniti/library/apr > None -> 1.4.6,5.11-0.151002:20120401T205441Z > omniti/library/apr-util > None -> 1.4.1,5.11-0.151002:20120401T200739Z > omniti/library/uuid > None -> 1.41.14,5.11-0.151002:20120401T185308Z > omniti/server/apache22 > None -> 2.2.25,5.11-0.151006:20130904T164853Z > > > > this seems odd to me. how can this be explained? > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: 0xF9ECC6A5.asc Type: application/pgp-keys Size: 2686 bytes Desc: not available URL: From jesus at omniti.com Tue Dec 10 16:39:27 2013 From: jesus at omniti.com (Theo Schlossnagle) Date: Tue, 10 Dec 2013 11:39:27 -0500 Subject: [OmniOS-discuss] apache22 after upgrading to r151008 In-Reply-To: <52A74207.4000406@gmx.li> References: <52A73672.9010608@gmx.li> <52A74207.4000406@gmx.li> Message-ID: You didn't have the same version as before.... you now have an older version... You likely had omniti/library/uuid at 1.41.14,5.11-0.151006:20131015T044739Z installed on your box.... now you have omniti/library/uuid at 1.41.14,5.11-0.151002:20120401T185308Z Likely true for a few of those other packages. On Tue, Dec 10, 2013 at 11:32 AM, Dominik Hassler wrote: > hmm, my point was the following: > > these older versions (installed on my r151006) prevented me from > upgrading, but now can be installed again (the same versions that have > been installed) after the upgrade has been finished. > > why does a piece of software prevent me from upgrading if it can be > installed again (same version as before) after upgrading? > > sorry i'm quite new to omnios. > > On 12/10/2013 04:55 PM, Theo Schlossnagle wrote: > > You are likely getting older versions that don't rely on 151006. > > > > At some point in the lifecycle of ms.omniti.com > > we opted to make the packages depend on the release. > > > > > > On Tue, Dec 10, 2013 at 10:42 AM, Dominik Hassler > > wrote: > > > > hi there, > > > > to be able to install omnios-userland at 11,5.11-0.151006 and upgrade > > omnios to r151008 i had to remove serveral ms.omniti packages, > including > > apache22. > > > > however after successfully upgrading omnios to r151008, if i dry-run > > install apache22 again it looks like there won't be any issues. > > > > # cat /etc/release > > OmniOS v11 r151008 > > Copyright 2013 OmniTI Computer Consulting, Inc. All rights > reserved. > > Use is subject to license terms. > > > > # pkg list |grep omnios-userland > > incorporation/jeos/omnios-userland 11-0.151008 > i-- > > > > # pkg install -nv omniti/server/apache22 > > Packages to install: 4 > > Estimated space available: 197.32 GB > > Estimated space to be consumed: 66.73 MB > > Create boot environment: No > > Create backup boot environment: No > > Rebuild boot archive: No > > > > Changed packages: > > ms.omniti.com > > omniti/library/apr > > None -> 1.4.6,5.11-0.151002:20120401T205441Z > > omniti/library/apr-util > > None -> 1.4.1,5.11-0.151002:20120401T200739Z > > omniti/library/uuid > > None -> 1.41.14,5.11-0.151002:20120401T185308Z > > omniti/server/apache22 > > None -> 2.2.25,5.11-0.151006:20130904T164853Z > > > > > > > > this seems odd to me. how can this be explained? > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com OmniOS-discuss at lists.omniti.com> > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > > > > > -- > > > > Theo Schlossnagle > > > > http://omniti.com/is/theo-schlossnagle > > > -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle -------------- next part -------------- An HTML attachment was scrubbed... URL: From garrett at damore.org Mon Dec 9 23:10:03 2013 From: garrett at damore.org (Garrett D'Amore) Date: Mon, 9 Dec 2013 15:10:03 -0800 Subject: [OmniOS-discuss] [discuss] mpt_sas wedge In-Reply-To: References: <090701cef528$06b51230$141f3690$@acm.org> Message-ID: This *looks* like its SAS drives, but can you confirm that you're using SAS disks and not SATA drives in an expander or converter? In particular, *really* bad things can happen when you use SATA drives with SAS expanders, particularly when you start encountering errors. These solutions work great when everything is working well, but they have catastrophic failure modes owing to cascading resets and timeouts, as SATA drives generally aren't individually reset, but rather the entire bus gets reset. Pure SAS should be fine though -- the HBAs will reset a single drive in the case of most SAS failure conditions, and these resets should not affect any other drives on the bus. On Mon, Dec 9, 2013 at 2:20 PM, Eric Sproul wrote: > On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson wrote: > > > I vaguely recall seeing some mpt_sas improvements flyby over the past 6-8 > > months, once the first update for 151008 comes out I guess I will go > ahead > > and upgrade to that, maybe next time things go wiggy it won't take out > the > > whole controller. > > We back-ported the major one, which was the fix for > https://www.illumos.org/issues/4013 aka "backout 6910752/6968206: > needs more work". Make sure you have > driver/storage/mpt_sas at 0.5.11,5.11-0.151006:20130906T160306Z which > contains the fix. > > > > > One question; in this case, when it completely died, it ended up printing > > out the wwn of the drive in question so it was easy to find. However, I'm > > not quite sure how to map "target 17" to an actual disk if all I had were > > the warning messages. Any pointers? > > AFAIK mapping the topology behind an mpt_sas device required private > ioctls to extract that info from the IOC. Josh Clulow did the grunt > work to get that done, in https://www.illumos.org/issues/4018 and we > have *that* stuff in r151008. > > In r151006 you would need to use LSI's "sas2ircu" utility to get that > information. > > Eric > > > ------------------------------------------- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garrett at damore.org Tue Dec 10 01:23:07 2013 From: garrett at damore.org (Garrett D'Amore) Date: Mon, 9 Dec 2013 17:23:07 -0800 Subject: [OmniOS-discuss] [discuss] mpt_sas wedge In-Reply-To: <091701cef53b$bee7f030$3cb7d090$@acm.org> References: <090701cef528$06b51230$141f3690$@acm.org> <091701cef53b$bee7f030$3cb7d090$@acm.org> Message-ID: That's right... direct connection *with nothing else on the bus* should be fine. On Mon, Dec 9, 2013 at 4:06 PM, Paul B. Henson wrote: > > From: Garrett D'Amore [mailto:garrett at damore.org] > > Sent: Monday, December 09, 2013 3:10 PM > > > > This *looks* like its SAS drives, but can you confirm that you're using > SAS > > disks and not SATA drives in an expander or converter? > > I intended to mention in the original message that this was a WD red 3TB > SATA drive, perhaps I forgot. So it is a SATA drive, but there are no > expanders involved, it is connected directly to a single port on the SAS > hba. I was aware of potential issues with SATA drives and SAS expanders, > and > made sure to avoid such a configuration, but my understanding was that a > SATA disk attached directly to a SAS hba shouldn't be a problem. > > > > ------------------------------------------- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Tue Dec 10 20:34:55 2013 From: henson at acm.org (Paul B. Henson) Date: Tue, 10 Dec 2013 12:34:55 -0800 Subject: [OmniOS-discuss] mpt_sas wedge In-Reply-To: References: <090701cef528$06b51230$141f3690$@acm.org> Message-ID: <0a8501cef5e7$4b6eb4c0$e24c1e40$@acm.org> > From: wuffers [mailto:moo at wuffers.net] > Sent: Monday, December 09, 2013 9:04 PM > > I had some SCSI warnings as well relating to a target, and I found this helpful > thread on determining a disk target (uses lsiutil): While I was poking around, I discovered that while the syslog messages only mention the target, if you run 'fmdump -e', the fault manager logs include the wwn. From tom.robinson at motec.com.au Wed Dec 11 00:01:57 2013 From: tom.robinson at motec.com.au (Tom Robinson) Date: Wed, 11 Dec 2013 11:01:57 +1100 Subject: [OmniOS-discuss] NFS baulks under load Message-ID: <52A7AB75.6070804@motec.com.au> OmniOS v11 r151006 Hi, I'm having many stability/performance issues with NFS. Server end is OmniOS; client end is CentOS 5. When the server end is functioning, I can mount OK, but there are really long waits on simple things like listing a directory. Often I will get an I/O error. I have been using NFS4 but I'm thinking I should just configure the server/client maximum to NFS3. Currently the NFS server is hosed. This happened yesterday as well. The only way I could bring it back to life was to reboot the hardware; something I want to avoid. Is there a way to tidy up the network/nfs/server without rebooting? I had these settings: # sharectl get nfs servers=16 lockd_listen_backlog=32 lockd_servers=20 lockd_retransmit_timeout=5 grace_period=90 server_versmin=2 server_versmax=4 client_versmin=2 client_versmax=4 server_delegation=on nfsmapid_domain= max_connections=-1 protocol=ALL listen_backlog=32 device= But after reading this: http://virtuallyhyper.com/2013/04/installing-and-configuring-omnios/ I have changed to these settings to try to improve responsiveness under load: # sharectl get nfs servers=512 lockd_listen_backlog=256 lockd_servers=128 lockd_retransmit_timeout=5 grace_period=90 server_versmin=2 server_versmax=3 client_versmin=2 client_versmax=3 server_delegation=on nfsmapid_domain= max_connections=-1 protocol=ALL listen_backlog=32 device= The problem is I can't re-enable the service and I don't want to reboot to have to fix this. # svcs -a | grep -e nfs -e rpc disabled 17:24:56 svc:/network/nfs/cbd:default disabled 17:24:56 svc:/network/nfs/client:default disabled 17:24:57 svc:/network/nfs/log:default disabled 17:27:55 svc:/network/rpc/meta:default disabled 17:27:55 svc:/network/rpc/metamh:default disabled 17:27:55 svc:/network/rpc/rex:default disabled 17:27:55 svc:/network/rpc/metamed:default disabled 17:27:55 svc:/network/rpc/mdcomm:default online 17:25:55 svc:/network/rpc/bind:default online 17:25:56 svc:/network/rpc/keyserv:default online 17:25:56 svc:/network/nfs/status:default online 17:27:55 svc:/network/nfs/mapid:default online 17:27:56 svc:/network/rpc/gss:default online 17:27:56 svc:/network/rpc/smserver:default online 17:27:56 svc:/network/nfs/rquota:default online* 10:05:07 svc:/network/nfs/server:default online 10:32:20 svc:/network/nfs/nlockmgr:default # svcs -xv network/nfs/server svc:/network/nfs/server:default (NFS server) State: online since 11 December 2013 10:05:07 AM EST See: man -M /usr/share/man -s 1M nfsd See: /var/svc/log/network-nfs-server:default.log Impact: None. # svcs -vl network/nfs/server fmri svc:/network/nfs/server:default name NFS server enabled true state online next_state offline state_time 11 December 2013 10:05:07 AM EST logfile /var/svc/log/network-nfs-server:default.log restarter svc:/system/svc/restarter:default contract_id 96 dependency require_any/error svc:/milestone/network (online) dependency require_all/error svc:/network/nfs/nlockmgr (online) dependency optional_all/error svc:/network/nfs/mapid (online) dependency require_all/restart svc:/network/rpc/bind (online) dependency optional_all/none svc:/network/rpc/keyserv (online) dependency optional_all/none svc:/network/rpc/gss (online) dependency optional_all/none svc:/network/shares/group (multiple) dependency optional_all/none svc:/system/filesystem/reparse (online) dependency require_all/error svc:/system/filesystem/local (online) # svcs -vp network/nfs/server STATE NSTATE STIME CTID FMRI online offline 10:05:07 96 svc:/network/nfs/server:default 17:27:56 692 nfsd 10:05:07 1123 nfs-server 10:05:07 1134 sharemgr # ps -elf | grep -e share -e nfs -e rpc 0 S daemon 465 1 0 40 20 ? 796 ? 17:25:56 ? 0:00 /usr/sbin/rpcbind 0 S daemon 582 1 0 40 20 ? 1554 ? 17:27:56 ? 0:00 /usr/lib/nfs/nfsmapid 0 S daemon 545 1 0 40 20 ? 758 ? 17:25:57 ? 0:00 /usr/lib/nfs/statd 0 S daemon 692 1 0 39 0 ? 732 ? 17:27:56 ? 5:27 /usr/lib/nfs/nfsd 0 S root 1123 10 0 40 20 ? 946 ? 10:05:08 ? 0:00 /sbin/sh /lib/svc/method/nfs-server 0 S root 1134 1123 0 40 20 ? 1607 ? 10:05:08 ? 0:00 /usr/sbin/sharemgr stop -P nfs -a 0 S root 1462 1318 0 50 20 ? 578 ? 11:00:43 pts/4 0:00 grep -e share -e nfs -e rpc 0 S daemon 1274 1 0 39 0 ? 713 ? 10:32:20 ? 0:00 /usr/lib/nfs/lockd /var/svc/log/network-nfs-server:default.log [ Dec 11 10:05:07 Stopping because service restarting. ] [ Dec 11 10:05:07 Executing stop method ("/lib/svc/method/nfs-server stop 96"). ] I'm really stuck. Any assistance is much appreciated. Kind regards, Tom -- Tom Robinson IT Manager/System Administrator MoTeC Pty Ltd 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 E: tom.robinson at motec.com.au -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From cnehren+omnios-discuss at omniti.com Wed Dec 11 01:37:36 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Tue, 10 Dec 2013 20:37:36 -0500 Subject: [OmniOS-discuss] Updated releases: 151008f, 151006_32 Message-ID: <20131211013736.GB5178@eschaton.local> This week brings us two new releases in each current stable branch. r151006_032 has a fix in the `entire` incorporation to allow users to upgrade and install new packages while staying on 151006, and r151008f brings a fix for pkg:/system/file-system/zfs for 4347 ZPL can use dmu_tx_assign(TXG_WAIT) (https://www.illumos.org/issues/4347). In addition, the documentation for upgrading from 151006->151008 has been updated to reflect the new incorporation fixes in 151006. These should fix present known upgrade and installation issues users are experiencing. As always, you can view the release notes on our site: http://omnios.omniti.com/wiki.php/ReleaseNotes Thank you so much for using OmniOS. I hope it is as useful for you as it is for us. Have fun! -- Chris Nehren Site Reliability Engineer, OmniTI -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available URL: From henson at acm.org Wed Dec 11 02:32:26 2013 From: henson at acm.org (Paul B. Henson) Date: Tue, 10 Dec 2013 18:32:26 -0800 Subject: [OmniOS-discuss] mpt_sas wedge In-Reply-To: References: <090701cef528$06b51230$141f3690$@acm.org> <20131210041303.GN4044@bender.unx.csupomona.edu> Message-ID: <0b0001cef619$3df03210$b9d09630$@acm.org> > From: Narayan Desai [mailto:narayan.desai at gmail.com] > Sent: Tuesday, December 10, 2013 5:02 AM > > We've started running smartctl to try to catch sata drive failures earlier. it > seems to avoid mayhem in our experience. Are you compiling that yourself or pulling it from one of the third party repos? Seems like that might be something worth having in the official repository like ipmitool? I believe it also works with SAS drives, not just SATA drives. I definitely wouldn't have minded finding out my drive was in a death spiral before it wedged the controller and took out the pool :(. From narayan.desai at gmail.com Wed Dec 11 04:12:54 2013 From: narayan.desai at gmail.com (Narayan Desai) Date: Tue, 10 Dec 2013 22:12:54 -0600 Subject: [OmniOS-discuss] mpt_sas wedge In-Reply-To: <0b0001cef619$3df03210$b9d09630$@acm.org> References: <090701cef528$06b51230$141f3690$@acm.org> <20131210041303.GN4044@bender.unx.csupomona.edu> <0b0001cef619$3df03210$b9d09630$@acm.org> Message-ID: IIRC (on vacation atm) we pulled it from one of the omniti repos. You do need to run it with some options to get info out of SATA drives, and it results in a cosmetic scsi error, but it gives the full drive info. For us at least, our drives are noisy with errors before taking a dive; we get smart and other errors that show up in iostat -En output. We remove them proactively at that point, and get pretty regular failures on a testing rig afterward. -nld On Tue, Dec 10, 2013 at 8:32 PM, Paul B. Henson wrote: > > From: Narayan Desai [mailto:narayan.desai at gmail.com] > > Sent: Tuesday, December 10, 2013 5:02 AM > > > > We've started running smartctl to try to catch sata drive failures > earlier. it > > seems to avoid mayhem in our experience. > > Are you compiling that yourself or pulling it from one of the third party > repos? Seems like that might be something worth having in the official > repository like ipmitool? I believe it also works with SAS drives, not just > SATA drives. I definitely wouldn't have minded finding out my drive was in > a > death spiral before it wedged the controller and took out the pool :(. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.robinson at motec.com.au Wed Dec 11 05:33:26 2013 From: tom.robinson at motec.com.au (Tom Robinson) Date: Wed, 11 Dec 2013 16:33:26 +1100 Subject: [OmniOS-discuss] NFS baulks under load In-Reply-To: <52A7AB75.6070804@motec.com.au> References: <52A7AB75.6070804@motec.com.au> Message-ID: <52A7F926.6080106@motec.com.au> Hi, It would be good to know how to work around this without having to reboot the server. Anyway, after some time the network/nfs/server timed out: ==> /var/svc/log/network-nfs-server:default.log <== [ Dec 11 12:05:08 Method or service exit timed out. Killing contract 123. ] ==> /var/svc/log/svc.startd.log <== Dec 11 12:05:08/3: svc:/network/nfs/server:default: Method or service exit timed out. Killing contract 123. Dec 11 12:05:08/366: network/nfs/server:default timed out: transitioned to maintenance (see 'svcs -xv' for details) ==> /var/adm/messages <== Dec 11 12:05:08 monza.motec.com.au svc.startd[10]: [ID 122153 daemon.warning] svc:/network/nfs/server:default: Method or service exit timed out. Killing contract 123. Dec 11 12:05:08 monza.motec.com.au svc.startd[10]: [ID 748625 daemon.error] network/nfs/server:default timed out: transitioned to maintenance (see 'svcs -xv' for details) Dec 11 12:05:08 monza.motec.com.au fmd: [ID 377184 daemon.error] SUNW-MSG-ID: SMF-8000-YX, TYPE: defect, VER: 1, SEVERITY: major Dec 11 12:05:08 monza.motec.com.au EVENT-TIME: Wed Dec 11 12:05:08 EST 2013 Dec 11 12:05:08 monza.motec.com.au PLATFORM: X9DR3-F, CSN: 1234567890, HOSTNAME: monza.motec.com.au Dec 11 12:05:08 monza.motec.com.au SOURCE: software-diagnosis, REV: 0.1 Dec 11 12:05:08 monza.motec.com.au EVENT-ID: ae3c39b1-7f6c-e39e-bef1-977913c867ce Dec 11 12:05:08 monza.motec.com.au DESC: A service failed - a start, stop or refresh method failed. Dec 11 12:05:08 monza.motec.com.au Refer to http://illumos.org/msg/SMF-8000-YX for more information. Dec 11 12:05:08 monza.motec.com.au AUTO-RESPONSE: The service has been placed into the maintenance state. Dec 11 12:05:08 monza.motec.com.au IMPACT: svc:/network/nfs/server:default is unavailable. Dec 11 12:05:08 monza.motec.com.au REC-ACTION: Run 'svcs -xv svc:/network/nfs/server:default' to determine the generic reason why the service failed, the location of any logfiles, and a list of other services impacted. # svcs -xv svc:/network/nfs/server:default svc:/network/nfs/server:default (NFS server) State: maintenance since 11 December 2013 12:05:08 PM EST Reason: Start method died on Killed (9). See: http://illumos.org/msg/SMF-8000-KS See: man -M /usr/share/man -s 1M nfsd See: /var/svc/log/network-nfs-server:default.log Impact: This service is not running. # svcs -vp svc:/network/nfs/server:default STATE NSTATE STIME CTID FMRI maintenance - 12:05:08 - svc:/network/nfs/server:default ps -elf | grep share 0 S root 1684 1055 0 50 20 ? 576 ? 12:36:52 pts/1 0:00 grep share 0 S root 1134 1 0 40 20 ? 1607 ? 10:05:08 ? 0:00 /usr/sbin/sharemgr stop -P nfs -a 0 S root 1485 1 0 40 20 ? 1623 ? 11:05:08 ? 0:00 /usr/sbin/sharemgr start -P nfs -a The network/nfs/server service couldn't be started so I tried unsuccessfully to get rid of the sharemgr processes. Maybe my assumption was bad? Are these processes only related to the nfs server? No joy again, so I rebooted. What am I not understanding here? Also, before rebooting, I had set the nfs properties as: servers=512 lockd_listen_backlog=256 lockd_servers=128 lockd_retransmit_timeout=5 grace_period=90 server_versmin=2 server_versmax=3 client_versmin=2 client_versmax=3 server_delegation=on nfsmapid_domain= max_connections=-1 protocol=ALL listen_backlog=32 device= I've moved backward to NFSv3 and both client and server seem a lot happier. I've just about completed a full load test and it all looks pretty stable. Kind regards, Tom Tom Robinson IT Manager/System Administrator MoTeC Pty Ltd 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 E: tom.robinson at motec.com.au On 11/12/13 11:01, Tom Robinson wrote: > OmniOS v11 r151006 > > Hi, > > I'm having many stability/performance issues with NFS. Server end is OmniOS; client end is CentOS 5. > > When the server end is functioning, I can mount OK, but there are really long waits on simple things > like listing a directory. Often I will get an I/O error. I have been using NFS4 but I'm thinking I > should just configure the server/client maximum to NFS3. > > Currently the NFS server is hosed. This happened yesterday as well. The only way I could bring it > back to life was to reboot the hardware; something I want to avoid. Is there a way to tidy up the > network/nfs/server without rebooting? > > I had these settings: > # sharectl get nfs > servers=16 > lockd_listen_backlog=32 > lockd_servers=20 > lockd_retransmit_timeout=5 > grace_period=90 > server_versmin=2 > server_versmax=4 > client_versmin=2 > client_versmax=4 > server_delegation=on > nfsmapid_domain= > max_connections=-1 > protocol=ALL > listen_backlog=32 > device= > > But after reading this: http://virtuallyhyper.com/2013/04/installing-and-configuring-omnios/ > I have changed to these settings to try to improve responsiveness under load: > > # sharectl get nfs > servers=512 > lockd_listen_backlog=256 > lockd_servers=128 > lockd_retransmit_timeout=5 > grace_period=90 > server_versmin=2 > server_versmax=3 > client_versmin=2 > client_versmax=3 > server_delegation=on > nfsmapid_domain= > max_connections=-1 > protocol=ALL > listen_backlog=32 > device= > > The problem is I can't re-enable the service and I don't want to reboot to have to fix this. > > # svcs -a | grep -e nfs -e rpc > disabled 17:24:56 svc:/network/nfs/cbd:default > disabled 17:24:56 svc:/network/nfs/client:default > disabled 17:24:57 svc:/network/nfs/log:default > disabled 17:27:55 svc:/network/rpc/meta:default > disabled 17:27:55 svc:/network/rpc/metamh:default > disabled 17:27:55 svc:/network/rpc/rex:default > disabled 17:27:55 svc:/network/rpc/metamed:default > disabled 17:27:55 svc:/network/rpc/mdcomm:default > online 17:25:55 svc:/network/rpc/bind:default > online 17:25:56 svc:/network/rpc/keyserv:default > online 17:25:56 svc:/network/nfs/status:default > online 17:27:55 svc:/network/nfs/mapid:default > online 17:27:56 svc:/network/rpc/gss:default > online 17:27:56 svc:/network/rpc/smserver:default > online 17:27:56 svc:/network/nfs/rquota:default > online* 10:05:07 svc:/network/nfs/server:default > online 10:32:20 svc:/network/nfs/nlockmgr:default > > > # svcs -xv network/nfs/server > svc:/network/nfs/server:default (NFS server) > State: online since 11 December 2013 10:05:07 AM EST > See: man -M /usr/share/man -s 1M nfsd > See: /var/svc/log/network-nfs-server:default.log > Impact: None. > > # svcs -vl network/nfs/server > fmri svc:/network/nfs/server:default > name NFS server > enabled true > state online > next_state offline > state_time 11 December 2013 10:05:07 AM EST > logfile /var/svc/log/network-nfs-server:default.log > restarter svc:/system/svc/restarter:default > contract_id 96 > dependency require_any/error svc:/milestone/network (online) > dependency require_all/error svc:/network/nfs/nlockmgr (online) > dependency optional_all/error svc:/network/nfs/mapid (online) > dependency require_all/restart svc:/network/rpc/bind (online) > dependency optional_all/none svc:/network/rpc/keyserv (online) > dependency optional_all/none svc:/network/rpc/gss (online) > dependency optional_all/none svc:/network/shares/group (multiple) > dependency optional_all/none svc:/system/filesystem/reparse (online) > dependency require_all/error svc:/system/filesystem/local (online) > > # svcs -vp network/nfs/server > STATE NSTATE STIME CTID FMRI > online offline 10:05:07 96 svc:/network/nfs/server:default > 17:27:56 692 nfsd > 10:05:07 1123 nfs-server > 10:05:07 1134 sharemgr > > # ps -elf | grep -e share -e nfs -e rpc > 0 S daemon 465 1 0 40 20 ? 796 ? 17:25:56 ? 0:00 > /usr/sbin/rpcbind > 0 S daemon 582 1 0 40 20 ? 1554 ? 17:27:56 ? 0:00 > /usr/lib/nfs/nfsmapid > 0 S daemon 545 1 0 40 20 ? 758 ? 17:25:57 ? 0:00 > /usr/lib/nfs/statd > 0 S daemon 692 1 0 39 0 ? 732 ? 17:27:56 ? 5:27 > /usr/lib/nfs/nfsd > 0 S root 1123 10 0 40 20 ? 946 ? 10:05:08 ? 0:00 /sbin/sh > /lib/svc/method/nfs-server > 0 S root 1134 1123 0 40 20 ? 1607 ? 10:05:08 ? 0:00 > /usr/sbin/sharemgr stop -P nfs -a > 0 S root 1462 1318 0 50 20 ? 578 ? 11:00:43 pts/4 0:00 grep -e > share -e nfs -e rpc > 0 S daemon 1274 1 0 39 0 ? 713 ? 10:32:20 ? 0:00 > /usr/lib/nfs/lockd > > /var/svc/log/network-nfs-server:default.log > [ Dec 11 10:05:07 Stopping because service restarting. ] > [ Dec 11 10:05:07 Executing stop method ("/lib/svc/method/nfs-server stop 96"). ] > > I'm really stuck. Any assistance is much appreciated. > > Kind regards, > Tom > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From lotheac at iki.fi Wed Dec 11 08:16:13 2013 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Wed, 11 Dec 2013 10:16:13 +0200 Subject: [OmniOS-discuss] r151008 ipkg zone attach problems In-Reply-To: <20131207165258.GA7252@gutsman.lotheac.fi> References: <20131207165258.GA7252@gutsman.lotheac.fi> Message-ID: <20131211081613.GC22875@gutsman.lotheac.fi> On Sat, Dec 07 2013 18:52:59 +0200, Lauri Tirkkonen wrote: > I noticed that I could not attach my non-global zones under r151008 > after upgrading from r151006. I made a couple VMs to reproduce, and it > turns out that ipkg zone attach is broken on r151008 even on a fresh > install Just a heads up - this is still broken on r151008f. Should I make a bug report on the tracker? -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet From martinschki at mac.com Wed Dec 11 10:06:10 2013 From: martinschki at mac.com (Martin Kloboucnik) Date: Wed, 11 Dec 2013 11:06:10 +0100 Subject: [OmniOS-discuss] issues with r151008 and LSI disk controller Message-ID: Good Day, I upgraded to R151008 yesterday and then one of my LSI2008 controllers, or at least the disks connected, didn?t show anymore. After rolling back to 151006 everything worked fine again. Reboot before that didn?t help either. Any thoughts on what might be the problem or thoughts on how to debug? (Staying on 151006 for now) config: Supermicro MB E3-1240v2 ESXi 5.1 LSI 2008 with IT Firmware in passthrough mode thanks martin From cnehren+omnios-discuss at omniti.com Wed Dec 11 13:52:27 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Wed, 11 Dec 2013 08:52:27 -0500 Subject: [OmniOS-discuss] r151008 ipkg zone attach problems In-Reply-To: <20131211081613.GC22875@gutsman.lotheac.fi> References: <20131207165258.GA7252@gutsman.lotheac.fi> <20131211081613.GC22875@gutsman.lotheac.fi> Message-ID: <20131211135227.GD5178@eschaton.local> On Wed, Dec 11, 2013 at 10:16:13 +0200, Lauri Tirkkonen wrote: > On Sat, Dec 07 2013 18:52:59 +0200, Lauri Tirkkonen wrote: > > I noticed that I could not attach my non-global zones under r151008 > > after upgrading from r151006. I made a couple VMs to reproduce, and it > > turns out that ipkg zone attach is broken on r151008 even on a fresh > > install > > Just a heads up - this is still broken on r151008f. Should I make a bug > report on the tracker? Yes, please. -- Chris Nehren Site Reliability Engineer, OmniTI From keith.wesolowski at joyent.com Wed Dec 11 17:00:54 2013 From: keith.wesolowski at joyent.com (Keith Wesolowski) Date: Wed, 11 Dec 2013 17:00:54 +0000 Subject: [OmniOS-discuss] [smartos-discuss] Re: Supermicro IPMI based BIOS update In-Reply-To: References: <094801cef550$b5cc58a0$216509e0$@acm.org> Message-ID: <20131211170054.GA497@joyent.com> On Mon, Dec 09, 2013 at 10:34:50PM -0500, wuffers wrote: > It's kind of interesting that they're trying to charge for it (at least > that's the assumption with an "activation key"). It's useful, but outside > of the "fix corrupted BIOS" (which would probably save themselves $$$), not > worth a premium. How hard is it to update the BIOS manually by hand > anyways? On one system, or on 1000? My perspective on this is that being able to upgrade firmware over the LAN interface is an essential manageability feature. That many don't have it, that there's no standard interface that seems to be seeing adoption, and that some are trying to charge extra for it are borderline criminal. Booting to DOS, even FreeDOS with scripts baked into every system's boot media, in order to fix *the vendor's bugs* with an upgrade is really only an option if the alternative is to go out of business. It's too slow, too disruptive, too difficult to automate safely, and requires too much effort relative to its plausible utility. What's even more obnoxious is that it's usually impossible to preserve settings across a firmware upgrade, and that there's generally no way to export or import settings or set them noninteractively. These are all obvious holes in basic manageability functionality and most vendors seem either not to care or to view basic and obvious functionality as "value-adds" and thus opportunities to extract more money from their customers. These shortcomings are not trivial. They make manufacturing, integration, and deployment costly, slow, and difficult, and they make post-deployment management and even validation impossible. And that's if you're doing business with a single vendor. Add a second and you can forget it; you need an army the size of Google's just to keep up with the infinite variations, formats, proprietary tools, and nonstandard protocols. Very much appreciate everyone out there fighting the good fight on this stuff. When you win, we all win! From henson at acm.org Thu Dec 12 02:08:24 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 11 Dec 2013 18:08:24 -0800 Subject: [OmniOS-discuss] mpt_sas wedge In-Reply-To: References: <090701cef528$06b51230$141f3690$@acm.org> <20131210041303.GN4044@bender.unx.csupomona.edu> <0b0001cef619$3df03210$b9d09630$@acm.org> Message-ID: <0c4801cef6df$0bec52a0$23c4f7e0$@acm.org> > From: Narayan Desai [mailto:narayan.desai at gmail.com] > Sent: Tuesday, December 10, 2013 8:13 PM > > IIRC (on vacation atm) we pulled it from one of the omniti repos. Ah, yes, looks like it's in the ms.omniti.com repo. Doesn't look like that version includes an smf manifest for running smartd though. Do you use smartd, or just call smartctl directly from your own scheduled scripts? From henson at acm.org Thu Dec 12 02:24:03 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 11 Dec 2013 18:24:03 -0800 Subject: [OmniOS-discuss] [smartos-discuss] Re: Supermicro IPMI based BIOS update In-Reply-To: <20131211170054.GA497@joyent.com> References: <094801cef550$b5cc58a0$216509e0$@acm.org> <20131211170054.GA497@joyent.com> Message-ID: <0c4d01cef6e1$3da1c710$b8e55530$@acm.org> > From: Keith Wesolowski [mailto:keith.wesolowski at joyent.com] > Sent: Wednesday, December 11, 2013 9:01 AM > > My perspective on this is that being able to upgrade firmware over the > LAN interface is an essential manageability feature. I don't know if I want to call them "higher end", or "brand name", but for the most part all of my servers from Sun or IBM have had this functionality, other than occasionally needing to boot an ISO image to update RAID controller firmware. > What's even more obnoxious is that it's usually impossible to preserve > settings across a firmware upgrade, and that there's generally no way to > export or import settings or set them noninteractively. Yah, BIOS sucks :(. > Very much appreciate everyone out there fighting the good fight on this > stuff. When you win, we all win! I think you guys have more clout with at least supermicro than most if not everybody else on this list ;), maybe you could give your sales rep a good smack about the ridiculousness of trying to nickel and dime customers for this IPMI feature :). From henson at acm.org Thu Dec 12 04:00:37 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 11 Dec 2013 20:00:37 -0800 Subject: [OmniOS-discuss] Updated releases: 151008f, 151006_32 In-Reply-To: <20131211013736.GB5178@eschaton.local> References: <20131211013736.GB5178@eschaton.local> Message-ID: <20131212040037.GS4044@bender.unx.csupomona.edu> > As always, you can view the release notes on our site: > http://omnios.omniti.com/wiki.php/ReleaseNotes Typically people only post with problems, but I'd just like to report I updated from 151006 to 151008f per the upgrade guide in the wiki with zero problems and everything seems to be working perfectly so far :). The update guide for 151008 seems inaccurate as far as zpool upgrade though, r151006 already included feature flag support, so unless you installed from an earlier rev or used an old pool they should already be enabled. There are some new feature flags, it looks like if you enable spacemap_histogram your pool is only usable read-only with r151006, whereas multi_vdev_crash_dump only renders your pool incompatible if you have an active non-mirror dump defined, and it doesn't look like there are any features using extensible_dataset yet, so even if you enable it it won't be activated. The specific message I see after updating from a system installed with r151006 is: This system supports ZFS pool feature flags. All pools are formatted using feature flags. Some supported features are not enabled on the following pools. Once a feature is enabled the pool may become incompatible with software that does not support the feature. See zpool-features(5) for details. POOL FEATURE --------------- export multi_vdev_crash_dump spacemap_histogram extensible_dataset rpool multi_vdev_crash_dump spacemap_histogram extensible_dataset From narayan.desai at gmail.com Thu Dec 12 13:50:12 2013 From: narayan.desai at gmail.com (Narayan Desai) Date: Thu, 12 Dec 2013 07:50:12 -0600 Subject: [OmniOS-discuss] mpt_sas wedge In-Reply-To: <0c4801cef6df$0bec52a0$23c4f7e0$@acm.org> References: <090701cef528$06b51230$141f3690$@acm.org> <20131210041303.GN4044@bender.unx.csupomona.edu> <0b0001cef619$3df03210$b9d09630$@acm.org> <0c4801cef6df$0bec52a0$23c4f7e0$@acm.org> Message-ID: We're just calling smartctl periodically. -nld On Wed, Dec 11, 2013 at 8:08 PM, Paul B. Henson wrote: > > From: Narayan Desai [mailto:narayan.desai at gmail.com] > > Sent: Tuesday, December 10, 2013 8:13 PM > > > > IIRC (on vacation atm) we pulled it from one of the omniti repos. > > Ah, yes, looks like it's in the ms.omniti.com repo. Doesn't look like that > version includes an smf manifest for running smartd though. Do you use > smartd, or just call smartctl directly from your own scheduled scripts? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From esproul at omniti.com Thu Dec 12 15:16:43 2013 From: esproul at omniti.com (Eric Sproul) Date: Thu, 12 Dec 2013 10:16:43 -0500 Subject: [OmniOS-discuss] Updated releases: 151008f, 151006_32 In-Reply-To: <20131212040037.GS4044@bender.unx.csupomona.edu> References: <20131211013736.GB5178@eschaton.local> <20131212040037.GS4044@bender.unx.csupomona.edu> Message-ID: On Wed, Dec 11, 2013 at 11:00 PM, Paul B. Henson wrote: > >> As always, you can view the release notes on our site: >> http://omnios.omniti.com/wiki.php/ReleaseNotes > > Typically people only post with problems, but I'd just like to report I > updated from 151006 to 151008f per the upgrade guide in the wiki with > zero problems and everything seems to be working perfectly so far :). That's great to hear, thanks Paul! > > > The update guide for 151008 seems inaccurate as far as zpool upgrade > though, r151006 already included feature flag support, so unless you > installed from an earlier rev or used an old pool they should already be > enabled. There are some new feature flags, it looks like if you enable > spacemap_histogram your pool is only usable read-only with r151006, > whereas multi_vdev_crash_dump only renders your pool incompatible if you > have an active non-mirror dump defined, and it doesn't look like there > are any features using extensible_dataset yet, so even if you enable it > it won't be activated. Yep, thanks for pointing that out. I've updated the upgrade page with the right message text. Eric From richard.elling at richardelling.com Thu Dec 12 22:12:20 2013 From: richard.elling at richardelling.com (Richard Elling) Date: Thu, 12 Dec 2013 14:12:20 -0800 Subject: [OmniOS-discuss] NFS baulks under load In-Reply-To: <52A7AB75.6070804@motec.com.au> References: <52A7AB75.6070804@motec.com.au> Message-ID: On Dec 10, 2013, at 4:01 PM, Tom Robinson wrote: > OmniOS v11 r151006 > > Hi, > > I'm having many stability/performance issues with NFS. Server end is OmniOS; client end is CentOS 5. > > When the server end is functioning, I can mount OK, but there are really long waits on simple things > like listing a directory. Often I will get an I/O error. I have been using NFS4 but I'm thinking I > should just configure the server/client maximum to NFS3. > > Currently the NFS server is hosed. This happened yesterday as well. The only way I could bring it > back to life was to reboot the hardware; something I want to avoid. Is there a way to tidy up the > network/nfs/server without rebooting? None of these settings are your problem. Look elsewhere, the domain name is a good starting point for NFSv4. -- richard > > I had these settings: > # sharectl get nfs > servers=16 > lockd_listen_backlog=32 > lockd_servers=20 > lockd_retransmit_timeout=5 > grace_period=90 > server_versmin=2 > server_versmax=4 > client_versmin=2 > client_versmax=4 > server_delegation=on > nfsmapid_domain= > max_connections=-1 > protocol=ALL > listen_backlog=32 > device= > > But after reading this: http://virtuallyhyper.com/2013/04/installing-and-configuring-omnios/ > I have changed to these settings to try to improve responsiveness under load: > > # sharectl get nfs > servers=512 > lockd_listen_backlog=256 > lockd_servers=128 > lockd_retransmit_timeout=5 > grace_period=90 > server_versmin=2 > server_versmax=3 > client_versmin=2 > client_versmax=3 > server_delegation=on > nfsmapid_domain= > max_connections=-1 > protocol=ALL > listen_backlog=32 > device= > > The problem is I can't re-enable the service and I don't want to reboot to have to fix this. > > # svcs -a | grep -e nfs -e rpc > disabled 17:24:56 svc:/network/nfs/cbd:default > disabled 17:24:56 svc:/network/nfs/client:default > disabled 17:24:57 svc:/network/nfs/log:default > disabled 17:27:55 svc:/network/rpc/meta:default > disabled 17:27:55 svc:/network/rpc/metamh:default > disabled 17:27:55 svc:/network/rpc/rex:default > disabled 17:27:55 svc:/network/rpc/metamed:default > disabled 17:27:55 svc:/network/rpc/mdcomm:default > online 17:25:55 svc:/network/rpc/bind:default > online 17:25:56 svc:/network/rpc/keyserv:default > online 17:25:56 svc:/network/nfs/status:default > online 17:27:55 svc:/network/nfs/mapid:default > online 17:27:56 svc:/network/rpc/gss:default > online 17:27:56 svc:/network/rpc/smserver:default > online 17:27:56 svc:/network/nfs/rquota:default > online* 10:05:07 svc:/network/nfs/server:default > online 10:32:20 svc:/network/nfs/nlockmgr:default > > > # svcs -xv network/nfs/server > svc:/network/nfs/server:default (NFS server) > State: online since 11 December 2013 10:05:07 AM EST > See: man -M /usr/share/man -s 1M nfsd > See: /var/svc/log/network-nfs-server:default.log > Impact: None. > > # svcs -vl network/nfs/server > fmri svc:/network/nfs/server:default > name NFS server > enabled true > state online > next_state offline > state_time 11 December 2013 10:05:07 AM EST > logfile /var/svc/log/network-nfs-server:default.log > restarter svc:/system/svc/restarter:default > contract_id 96 > dependency require_any/error svc:/milestone/network (online) > dependency require_all/error svc:/network/nfs/nlockmgr (online) > dependency optional_all/error svc:/network/nfs/mapid (online) > dependency require_all/restart svc:/network/rpc/bind (online) > dependency optional_all/none svc:/network/rpc/keyserv (online) > dependency optional_all/none svc:/network/rpc/gss (online) > dependency optional_all/none svc:/network/shares/group (multiple) > dependency optional_all/none svc:/system/filesystem/reparse (online) > dependency require_all/error svc:/system/filesystem/local (online) > > # svcs -vp network/nfs/server > STATE NSTATE STIME CTID FMRI > online offline 10:05:07 96 svc:/network/nfs/server:default > 17:27:56 692 nfsd > 10:05:07 1123 nfs-server > 10:05:07 1134 sharemgr > > # ps -elf | grep -e share -e nfs -e rpc > 0 S daemon 465 1 0 40 20 ? 796 ? 17:25:56 ? 0:00 > /usr/sbin/rpcbind > 0 S daemon 582 1 0 40 20 ? 1554 ? 17:27:56 ? 0:00 > /usr/lib/nfs/nfsmapid > 0 S daemon 545 1 0 40 20 ? 758 ? 17:25:57 ? 0:00 > /usr/lib/nfs/statd > 0 S daemon 692 1 0 39 0 ? 732 ? 17:27:56 ? 5:27 > /usr/lib/nfs/nfsd > 0 S root 1123 10 0 40 20 ? 946 ? 10:05:08 ? 0:00 /sbin/sh > /lib/svc/method/nfs-server > 0 S root 1134 1123 0 40 20 ? 1607 ? 10:05:08 ? 0:00 > /usr/sbin/sharemgr stop -P nfs -a > 0 S root 1462 1318 0 50 20 ? 578 ? 11:00:43 pts/4 0:00 grep -e > share -e nfs -e rpc > 0 S daemon 1274 1 0 39 0 ? 713 ? 10:32:20 ? 0:00 > /usr/lib/nfs/lockd > > /var/svc/log/network-nfs-server:default.log > [ Dec 11 10:05:07 Stopping because service restarting. ] > [ Dec 11 10:05:07 Executing stop method ("/lib/svc/method/nfs-server stop 96"). ] > > I'm really stuck. Any assistance is much appreciated. > > Kind regards, > Tom > > -- > > Tom Robinson > IT Manager/System Administrator > > MoTeC Pty Ltd > > 121 Merrindale Drive > Croydon South > 3136 Victoria > Australia > > T: +61 3 9761 5050 > F: +61 3 9761 5051 > E: tom.robinson at motec.com.au > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.elling at richardelling.com Thu Dec 12 22:21:45 2013 From: richard.elling at richardelling.com (Richard Elling) Date: Thu, 12 Dec 2013 14:21:45 -0800 Subject: [OmniOS-discuss] [discuss] mpt_sas wedge In-Reply-To: <0a8501cef5e7$4b6eb4c0$e24c1e40$@acm.org> References: <090701cef528$06b51230$141f3690$@acm.org> <0a8501cef5e7$4b6eb4c0$e24c1e40$@acm.org> Message-ID: Here is another method: There is a handy mptstat dcmd. echo ::mptsas -t | mdb -k mptsas_t inst ncmds suspend power ================================================================================ ffffff0703785000 0 0 0 ON=D0 The SCSI target information devhdl 12, sasaddress 5000c5002128f332, phymask ff,devinfo 401 throttle 20, dr_flag 0, m_t_ncmds 0 devhdl 11, sasaddress 5000c50021295cb2, phymask ff,devinfo 401 throttle 20, dr_flag 0, m_t_ncmds 0 ... The devhdl is reported in the messages from mptsas. The sasaddress can be translated into the device name. Yes, this should be much easier :-( -- richard On Dec 10, 2013, at 12:34 PM, Paul B. Henson wrote: >> From: wuffers [mailto:moo at wuffers.net] >> Sent: Monday, December 09, 2013 9:04 PM >> >> I had some SCSI warnings as well relating to a target, and I found this > helpful >> thread on determining a disk target (uses lsiutil): > > While I was poking around, I discovered that while the syslog messages only > mention the target, if you run 'fmdump -e', the fault manager logs include > the wwn. > > > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175743-23d1427b > Modify Your Subscription: https://www.listbox.com/member/?member_id=21175743&id_secret=21175743-81b50b6e > Powered by Listbox: http://www.listbox.com -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Fri Dec 13 10:25:52 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 13 Dec 2013 11:25:52 +0100 (CET) Subject: [OmniOS-discuss] strange io-pattern Message-ID: Multitudes, Tonight our omnios 1510006 server had a very strange io-pattern. The attached charts show the output of iostat over time ... the filesystem in question is a raidz2 on sas disks the other filesystems did not show this pattern. any ideas ? cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 -------------- next part -------------- A non-text attachment was scrubbed... Name: io-pattern2.jpg Type: image/jpeg Size: 121489 bytes Desc: URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: io-pattern.jpg Type: image/jpeg Size: 174743 bytes Desc: URL: From natxo.asenjo at gmail.com Fri Dec 13 12:06:17 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 13 Dec 2013 13:06:17 +0100 Subject: [OmniOS-discuss] upgrade nearly perfect Message-ID: hi, I just followed the instructions on the wiki http://omnios.omniti.com/wiki.php/Upgrade_r151006_r151008 and everything worked fine, except now is java broken: # /usr/java/bin/java -version ld.so.1: java: fatal: libjli.so: open failed: No such file or directory Killed # ldd /usr/bin/java libthread.so.1 => /lib/libthread.so.1 libjli.so => (file not found) libdl.so.1 => /lib/libdl.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 This is causing the backup software (crashplan) to fail. As far as I can see, my root zone only has this publisher: # pkg publisher PUBLISHER TYPE STATUS URI omnios origin online http://pkg.omniti.com/omnios/release/ reverting to the former version fixes java and crashplan works again: # /usr/java/bin/java -version java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode) # ldd /usr/bin/java libthread.so.1 => /lib/libthread.so.1 libjli.so => /usr/jdk/instances/jdk1.6.0/bin/../jre/lib/i386/jli/libjli.so libdl.so.1 => /lib/libdl.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 I see in the release changelog that oracle java was replaced by openjdk, so I think I found the reason it fails ;-), but now the question remains, where is the openjdk java ... I will keep searching, but maybe someone has already found this problem. TIA, Groeten, natxo From ci4 at outlook.com Fri Dec 13 12:41:14 2013 From: ci4 at outlook.com (Chavdar Ivanov) Date: Fri, 13 Dec 2013 12:41:14 +0000 Subject: [OmniOS-discuss] upgrade nearly perfect In-Reply-To: References: Message-ID: -----Original Message----- From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Natxo Asenjo Sent: 13 December 2013 12:06 To: omnios-discuss at lists.omniti.com Subject: [OmniOS-discuss] upgrade nearly perfect hi, I just followed the instructions on the wiki http://omnios.omniti.com/wiki.php/Upgrade_r151006_r151008 and everything worked fine, except now is java broken: # /usr/java/bin/java -version ld.so.1: java: fatal: libjli.so: open failed: No such file or directory Killed # ldd /usr/bin/java libthread.so.1 => /lib/libthread.so.1 libjli.so => (file not found) libdl.so.1 => /lib/libdl.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 This is causing the backup software (crashplan) to fail. As far as I can see, my root zone only has this publisher: # pkg publisher PUBLISHER TYPE STATUS URI omnios origin online http://pkg.omniti.com/omnios/release/ reverting to the former version fixes java and crashplan works again: # /usr/java/bin/java -version java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode) # ldd /usr/bin/java libthread.so.1 => /lib/libthread.so.1 libjli.so => /usr/jdk/instances/jdk1.6.0/bin/../jre/lib/i386/jli/libjli.so libdl.so.1 => /lib/libdl.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 I see in the release changelog that oracle java was replaced by openjdk, so I think I found the reason it fails ;-), but now the question remains, where is the openjdk java ... I will keep searching, but maybe someone has already found this problem. [[ci]] My update didn't have that problem: ? ~ cat /etc/release OmniOS v11 r151008 Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. ? ~ uname -a SunOS uksup5 5.11 omnios-6de5e81 i86pc i386 i86pc ? ~ /usr/java/bin/java -version openjdk version "1.7.0_06" OpenJDK Runtime Environment (build 1.7.0_06-b24) OpenJDK Server VM (build 24.0-b47, mixed mode) ? ~ pkg list | grep -i java developer/java/jdk (omnios) 1.7.0.6.24-0.151007 i-- runtime/java (omnios) 1.7.0.6.24-0.151007 i-- ? ~ pkg list | grep -i jre I do have omniti repo, but as far as I can see, java comes from the main one. ? ~ pkg publisher PUBLISHER TYPE STATUS URI ms.omniti.com (non-sticky) origin online http://pkg.omniti.com/omniti-ms/ omnios origin online http://pkg.omniti.com/omnios/release/ Chavdar Ivanov TIA, Groeten, natxo _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From paul.jochum at alcatel-lucent.com Fri Dec 13 13:03:38 2013 From: paul.jochum at alcatel-lucent.com (Paul Jochum) Date: Fri, 13 Dec 2013 07:03:38 -0600 Subject: [OmniOS-discuss] strange io-pattern In-Reply-To: References: Message-ID: <52AB05AA.7010202@alcatel-lucent.com> An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Fri Dec 13 13:13:43 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 13 Dec 2013 14:13:43 +0100 (CET) Subject: [OmniOS-discuss] strange io-pattern In-Reply-To: <52AB05AA.7010202@alcatel-lucent.com> References: <52AB05AA.7010202@alcatel-lucent.com> Message-ID: Hi Paul, Today Paul Jochum wrote: > Hi Tobias: > > ??? Sorry, I don't know why you are having these strang io-patterns, but I was wondering if you could share how you > record and display this info? I created a little plugin for collectd to interface with iostat. I guess having one for vfsstat and arcstat along the same lines would give a better picture as to what users actually experience but this one gives some impression as to what happens deep down. #!/usr/bin/perl my $filter = $ARGV[0] || '.+'; my $pid = open my $iostat, "-|", "/usr/bin/iostat","-Tu","-xnr",int($ENV{COLLECTD_INTERVAL}) or die "launching iostat: $!"; $SIG{PIPE} = 'ignore'; $SIG{CHLD} = 'ignore'; $SIG{TERM} = sub { kill 9,$pid; exit 1; }; my %data; my @cols; my $round = 0; while (<$iostat>){ chomp; my @input = split /,/; if ($#input == 0 and $input[0] =~ /^\d+$/){ publish() if $round++ > 1; %data = (); next; } if ($input[-1] eq 'device'){ @cols = @input; pop @cols; next; } if ($#input == $#cols+1){ my $dev = pop @input; my %row; @row{@cols} = @input; $data{$dev} = \%row; }; } sub publish { $|=0; my $time = time(); for my $dev (sort keys %data){ next unless $dev =~ /^${filter}$/; my $d = $data{$dev}; my $prefix = "PUTVAL $ENV{COLLECTD_HOSTNAME}/sol_iostat-$dev/sol_iostat_"; print $prefix."op $time:$d->{'r/s'}:$d->{'w/s'}\n"; print $prefix."byte $time:".($d->{'kr/s'}*1024).":".($d->{'kw/s'}*1024)."\n"; print $prefix."busypct $time:$d->{'%w'}:$d->{'%b'}\n"; print $prefix."wait $time:$d->{wait}\n"; print $prefix."actv $time:$d->{actv}\n"; print $prefix."wsvc_t $time:".($d->{wsvc_t}/1000)."\n"; print $prefix."asvc_t $time:".($d->{asvc_t}/1000)."\n"; } } --------- adding these new types to the types.db sol_iostat_op read:GAUGE:0:U, write:GAUGE:0:U sol_iostat_byte read:GAUGE:0:U, write:GAUGE:0:U sol_iostat_busypct queue:GAUGE:0:100, disk:GAUGE:0:100 sol_iostat_wait count:GAUGE:0:U sol_iostat_actv count:GAUGE:0:U sol_iostat_wsvc_t second:GAUGE:0:U sol_iostat_asvc_t second:GAUGE:0:U cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From natxo.asenjo at gmail.com Fri Dec 13 14:23:14 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 13 Dec 2013 15:23:14 +0100 Subject: [OmniOS-discuss] upgrade nearly perfect In-Reply-To: References: Message-ID: -- Groeten, natxo On Fri, Dec 13, 2013 at 1:41 PM, Chavdar Ivanov wrote: > > > -----Original Message----- > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Natxo Asenjo > Sent: 13 December 2013 12:06 > To: omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] upgrade nearly perfect > > hi, > > I just followed the instructions on the wiki > http://omnios.omniti.com/wiki.php/Upgrade_r151006_r151008 > > and everything worked fine, except now is java broken: > > # /usr/java/bin/java -version > ld.so.1: java: fatal: libjli.so: open failed: No such file or directory Killed # ldd /usr/bin/java > libthread.so.1 => /lib/libthread.so.1 > libjli.so => (file not found) > libdl.so.1 => /lib/libdl.so.1 > libc.so.1 => /lib/libc.so.1 > libm.so.2 => /lib/libm.so.2 > > This is causing the backup software (crashplan) to fail. > > As far as I can see, my root zone only has this publisher: > > # pkg publisher > PUBLISHER TYPE STATUS URI > omnios origin online > http://pkg.omniti.com/omnios/release/ > > reverting to the former version fixes java and crashplan works again: > > # /usr/java/bin/java -version > java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode) > > > # ldd /usr/bin/java > libthread.so.1 => /lib/libthread.so.1 > libjli.so => > /usr/jdk/instances/jdk1.6.0/bin/../jre/lib/i386/jli/libjli.so > libdl.so.1 => /lib/libdl.so.1 > libc.so.1 => /lib/libc.so.1 > libm.so.2 => /lib/libm.so.2 > > I see in the release changelog that oracle java was replaced by openjdk, so I think I found the reason it fails ;-), but now the question remains, where is the openjdk java ... > > I will keep searching, but maybe someone has already found this problem. > [[ci]] > > My update didn't have that problem: > > ? ~ cat /etc/release > OmniOS v11 r151008 > Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved. > Use is subject to license terms. > ? ~ uname -a > SunOS uksup5 5.11 omnios-6de5e81 i86pc i386 i86pc > ? ~ /usr/java/bin/java -version > openjdk version "1.7.0_06" > OpenJDK Runtime Environment (build 1.7.0_06-b24) > OpenJDK Server VM (build 24.0-b47, mixed mode) > > ? ~ pkg list | grep -i java > developer/java/jdk (omnios) 1.7.0.6.24-0.151007 i-- > runtime/java (omnios) 1.7.0.6.24-0.151007 i-- > ? ~ pkg list | grep -i jre > > I do have omniti repo, but as far as I can see, java comes from the main one. > > ? ~ pkg publisher > PUBLISHER TYPE STATUS URI > ms.omniti.com (non-sticky) origin online http://pkg.omniti.com/omniti-ms/ > omnios origin online http://pkg.omniti.com/omnios/release/ > > Chavdar Ivanov > > > TIA, > Groeten, > natxo > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From henk at hlangeveld.nl Fri Dec 13 14:24:22 2013 From: henk at hlangeveld.nl (Henk Langeveld) Date: Fri, 13 Dec 2013 15:24:22 +0100 Subject: [OmniOS-discuss] strange io-pattern In-Reply-To: References: <52AB05AA.7010202@alcatel-lucent.com> Message-ID: <52AB1896.8080906@hlangeveld.nl> There's a known problem with iostat -xn on multi-processor systems that I posted on the illumos-list back in September/October, where we occasionally see an astronomical spike in the io wait and service times. This appears to be caused by the hires kernel timer used by the kstat_io routines, which produces increasing values of timestamps *per* *physical* *cpu*. When io events are handled by different cpus, the delta_t can become negative, as the result of a 64bit int underflow. These occurrences are rare, but frequent enough to mess up those wait times. Also, the wait times only show up with the combined '-x' and '-n' options. Can you eliminate the possibility of such an incident? I intended to post a bug report on this, but I've moved on since then, and don't have access to any multi-cpu hardware right now. I *think* I've seen it once in a multi-cpu virtualbox instance, but have not been able to reproduce that. (This would suggest that virtualbox actually emulates the physical cpu registers.) Cheers, Henk On 13/12/2013 14:13, Tobias Oetiker wrote: > I created a little plugin for collectd to interface with iostat. I > guess having one for vfsstat and arcstat along the same lines would > give a better picture as to what users actually experience but this > one gives some impression as to what happens deep down. > > #!/usr/bin/perl > my $filter = $ARGV[0] || '.+'; > > my $pid = open my $iostat, "-|", "/usr/bin/iostat","-Tu","-xnr",int($ENV{COLLECTD_INTERVAL}) or die "launching iostat: $!"; > From tobi at oetiker.ch Fri Dec 13 14:48:48 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 13 Dec 2013 15:48:48 +0100 (CET) Subject: [OmniOS-discuss] strange io-pattern In-Reply-To: <52AB1896.8080906@hlangeveld.nl> References: <52AB05AA.7010202@alcatel-lucent.com> <52AB1896.8080906@hlangeveld.nl> Message-ID: Hi Henk, Today Henk Langeveld wrote: > There's a known problem with iostat -xn on multi-processor systems that I > posted on the illumos-list > back in September/October, where we occasionally see an astronomical spike in > the io wait and service times. > > This appears to be caused by the hires kernel timer used by the kstat_io > routines, which produces increasing > values of timestamps *per* *physical* *cpu*. When io events are handled by > different cpus, the delta_t can > become negative, as the result of a 64bit int underflow. > > These occurrences are rare, but frequent enough to mess up those wait times. > Also, the wait times only show > up with the combined '-x' and '-n' options. > > Can you eliminate the possibility of such an incident? > > I intended to post a bug report on this, but I've moved on since then, and > don't have access to > any multi-cpu hardware right now. I *think* I've seen it once in a multi-cpu > virtualbox instance, but have not > been able to reproduce that. (This would suggest that virtualbox actually > emulates the physical cpu registers.) have a look at the graphs attached to my original post, its not a spiking problem I think ... cheers tobi > > Cheers, > Henk > > > On 13/12/2013 14:13, Tobias Oetiker wrote: > > I created a little plugin for collectd to interface with iostat. I > > guess having one for vfsstat and arcstat along the same lines would > > give a better picture as to what users actually experience but this > > one gives some impression as to what happens deep down. > > > > #!/usr/bin/perl > > my $filter = $ARGV[0] || '.+'; > > > > my $pid = open my $iostat, "-|", > > "/usr/bin/iostat","-Tu","-xnr",int($ENV{COLLECTD_INTERVAL}) or die > > "launching iostat: $!"; > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From alain.odea at gmail.com Thu Dec 12 23:57:37 2013 From: alain.odea at gmail.com (Alain O'Dea) Date: Thu, 12 Dec 2013 23:57:37 +0000 Subject: [OmniOS-discuss] [smartos-discuss] Re: Supermicro IPMI based BIOS update In-Reply-To: <0c4d01cef6e1$3da1c710$b8e55530$@acm.org> References: <094801cef550$b5cc58a0$216509e0$@acm.org> <20131211170054.GA497@joyent.com> <0c4d01cef6e1$3da1c710$b8e55530$@acm.org> Message-ID: <8E0B8DC0-D80A-42AC-B8BC-5990CBE47782@gmail.com> On Dec 12, 2013, at 2:24, "Paul B. Henson" wrote: >> From: Keith Wesolowski [mailto:keith.wesolowski at joyent.com] >> Sent: Wednesday, December 11, 2013 9:01 AM >> >> My perspective on this is that being able to upgrade firmware over the >> LAN interface is an essential manageability feature. > > I don't know if I want to call them "higher end", or "brand name", but for > the most part all of my servers from Sun or IBM have had this functionality, > other than occasionally needing to boot an ISO image to update RAID > controller firmware. The SOL included in iDRAC7 (with or without the Enterprise license) lets you configure BIOS settings with an XML file on an NFS share: http://en.community.dell.com/techcenter/b/techcenter/archive/2013/01/04/idrac7-now-support-configuring-server-idrac-bios-perc-and-nic-using-xml-file-and-racadm.aspx > >> What's even more obnoxious is that it's usually impossible to preserve >> settings across a firmware upgrade, and that there's generally no way to >> export or import settings or set them noninteractively. > > Yah, BIOS sucks :(. > >> Very much appreciate everyone out there fighting the good fight on this >> stuff. When you win, we all win! > > I think you guys have more clout with at least supermicro than most if not > everybody else on this list ;), maybe you could give your sales rep a good > smack about the ridiculousness of trying to nickel and dime customers for > this IPMI feature :). -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Fri Dec 13 15:09:43 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 13 Dec 2013 16:09:43 +0100 Subject: [OmniOS-discuss] upgrade nearly perfect In-Reply-To: References: Message-ID: On Fri, Dec 13, 2013 at 1:41 PM, Chavdar Ivanov wrote: > ? ~ /usr/java/bin/java -version > openjdk version "1.7.0_06" > OpenJDK Runtime Environment (build 1.7.0_06-b24) > OpenJDK Server VM (build 24.0-b47, mixed mode) > > ? ~ pkg list | grep -i java > developer/java/jdk (omnios) 1.7.0.6.24-0.151007 i-- > runtime/java (omnios) 1.7.0.6.24-0.151007 i-- > ? ~ pkg list | grep -i jre > > I do have omniti repo, but as far as I can see, java comes from the main one. > > ? ~ pkg publisher > PUBLISHER TYPE STATUS URI > ms.omniti.com (non-sticky) origin online http://pkg.omniti.com/omniti-ms/ > omnios origin online http://pkg.omniti.com/omnios/release/ mmm, I have this: root at zfstank:~# pkg list | grep -i java runtime/java 0.5.11-0.151008 i-- # pkg info java Name: runtime/java Summary: Open-source implementation of the seventh edition of the Java SE Platform State: Installed Publisher: omnios Version: 0.5.11 (jdk7u21-b30) Build Release: 5.11 Branch: 0.151008 Packaging Date: Wed Dec 4 20:10:13 2013 Size: 105.29 MB FMRI: pkg://omnios/runtime/java at 0.5.11,5.11-0.151008:20131204T201013Z Is this the right one? How can I reinstall it or verify it is correctly installed? TIA, -- groet, natxo From jdg117 at elvis.arl.psu.edu Fri Dec 13 15:29:09 2013 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Fri, 13 Dec 2013 10:29:09 -0500 Subject: [OmniOS-discuss] upgrade nearly perfect In-Reply-To: Your message of "Fri, 13 Dec 2013 16:09:43 +0100." References: Message-ID: <201312131529.rBDFT9dj004758@elvis.arl.psu.edu> In message , Natxo Asenjo writes: >Is this the right one? How can I reinstall it or verify it is >correctly installed? Looks like OmniTI's /usr/bin/java is linked to the wrong libjli.so. # pkg search libjli.so # pkg install pkg:/developer/java/jdk # /usr/bin/java -version John groenveld at acm.org From natxo.asenjo at gmail.com Fri Dec 13 15:36:47 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 13 Dec 2013 16:36:47 +0100 Subject: [OmniOS-discuss] upgrade nearly perfect In-Reply-To: <201312131529.rBDFT9dj004758@elvis.arl.psu.edu> References: <201312131529.rBDFT9dj004758@elvis.arl.psu.edu> Message-ID: On Fri, Dec 13, 2013 at 4:29 PM, John D Groenveld wrote: > In message > , Natxo Asenjo writes: >>Is this the right one? How can I reinstall it or verify it is >>correctly installed? > > Looks like OmniTI's /usr/bin/java is linked to the wrong > libjli.so. > # pkg search libjli.so > # pkg install pkg:/developer/java/jdk > # /usr/bin/java -version aha! That looks like the solution. In the http://omnios.omniti.com/wiki.php/KYSTY fashion, I had already downloaded java from oracle and got it running in the meantime, but I am going to try this as well, although I do not really see why I need the jdk when I just want the jre. Thanks, I did not know you could use pkg search for files as well, very nice tip. -- Groet, natxo From richard.elling at richardelling.com Fri Dec 13 15:38:56 2013 From: richard.elling at richardelling.com (Richard Elling) Date: Fri, 13 Dec 2013 07:38:56 -0800 Subject: [OmniOS-discuss] strange io-pattern In-Reply-To: References: <52AB05AA.7010202@alcatel-lucent.com> Message-ID: <336F86A6-146D-43D2-92B2-6F379398410A@richardelling.com> On Dec 13, 2013, at 5:13 AM, Tobias Oetiker wrote: > Hi Paul, > > Today Paul Jochum wrote: > >> Hi Tobias: >> >> Sorry, I don't know why you are having these strang io-patterns, but I was wondering if you could share how you >> record and display this info? > > I created a little plugin for collectd to interface with iostat. I > guess having one for vfsstat and arcstat along the same lines would > give a better picture as to what users actually experience but this > one gives some impression as to what happens deep down. Your script seems to break this out per-device, but that isn?t clear from the graphs you posted. This pattern is consistent with a misbehaving device. ? richard > > #!/usr/bin/perl > my $filter = $ARGV[0] || '.+'; > > my $pid = open my $iostat, "-|", "/usr/bin/iostat","-Tu","-xnr",int($ENV{COLLECTD_INTERVAL}) or die "launching iostat: $!"; > > $SIG{PIPE} = 'ignore'; > $SIG{CHLD} = 'ignore'; > $SIG{TERM} = sub { > kill 9,$pid; > exit 1; > }; > > my %data; > my @cols; > my $round = 0; > while (<$iostat>){ > chomp; > my @input = split /,/; > if ($#input == 0 and $input[0] =~ /^\d+$/){ > publish() if $round++ > 1; > %data = (); > next; > } > if ($input[-1] eq 'device'){ > @cols = @input; > pop @cols; > next; > } > if ($#input == $#cols+1){ > my $dev = pop @input; > my %row; > @row{@cols} = @input; > $data{$dev} = \%row; > }; > } > > sub publish { > $|=0; > my $time = time(); > for my $dev (sort keys %data){ > next unless $dev =~ /^${filter}$/; > my $d = $data{$dev}; > my $prefix = "PUTVAL $ENV{COLLECTD_HOSTNAME}/sol_iostat-$dev/sol_iostat_"; > print $prefix."op $time:$d->{'r/s'}:$d->{'w/s'}\n"; > print $prefix."byte $time:".($d->{'kr/s'}*1024).":".($d->{'kw/s'}*1024)."\n"; > print $prefix."busypct $time:$d->{'%w'}:$d->{'%b'}\n"; > print $prefix."wait $time:$d->{wait}\n"; > print $prefix."actv $time:$d->{actv}\n"; > print $prefix."wsvc_t $time:".($d->{wsvc_t}/1000)."\n"; > print $prefix."asvc_t $time:".($d->{asvc_t}/1000)."\n"; > } > } > > --------- > adding these new types to the types.db > > sol_iostat_op read:GAUGE:0:U, write:GAUGE:0:U > sol_iostat_byte read:GAUGE:0:U, write:GAUGE:0:U > sol_iostat_busypct queue:GAUGE:0:100, disk:GAUGE:0:100 > sol_iostat_wait count:GAUGE:0:U > sol_iostat_actv count:GAUGE:0:U > sol_iostat_wsvc_t second:GAUGE:0:U > sol_iostat_asvc_t second:GAUGE:0:U > > cheers > tobi > > -- > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland > http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900_______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From natxo.asenjo at gmail.com Fri Dec 13 15:52:31 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 13 Dec 2013 16:52:31 +0100 Subject: [OmniOS-discuss] zoneadm -z zone attach -u fails Message-ID: hi, Following the update I needed to update my only non-global zone as well but this is the result: # /usr/sbin/zoneadm -z zone1 attach -u Log File: /var/tmp/zone1.attach_log.X6ai9c Attach Path: /tank/zones/zone1/root Attach ZFS Dataset: tank/zones/zone1/ROOT/zbe-1 Installing: Using pre-existing data in zonepath Result: Attach Failed. And in the log: [Fri Dec 13 16:38:35 CET 2013] Log File: /var/tmp/zone1.attach_log.X6ai9c [Fri Dec 13 16:38:38 CET 2013] Attach Path: /tank/zones/zone1/root [Fri Dec 13 16:38:38 CET 2013] Attach ZFS Dataset: tank/zones/zone1/ROOT/zbe-1 [Fri Dec 13 16:38:38 CET 2013] existing [Fri Dec 13 16:38:38 CET 2013] Installing: Using pre-existing data in zonepath [Fri Dec 13 16:38:38 CET 2013] Sanity Check: Passed. Looks like an OpenSolaris system. Unable to get preferred publisher information for zone 'global'. brand-specific usage: attach [-a archive] [-d dataset] [-n] [-r zfs-recv] [-u] The -a archive option specifies a tar file or cpio archive. The -d dataset option specifies an existing dataset. The -r zfs-recv option receives the output of a 'zfs send' command of an existing zone root dataset. The -u option indicates that the software should be updated to match the current host. [Fri Dec 13 16:38:43 CET 2013] Result: Attach Failed. Any clues? -- Groeten, natxo From cnehren+omnios-discuss at omniti.com Fri Dec 13 16:26:41 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Fri, 13 Dec 2013 11:26:41 -0500 Subject: [OmniOS-discuss] zoneadm -z zone attach -u fails In-Reply-To: References: Message-ID: <20131213162641.GE5178@eschaton.local> On Fri, Dec 13, 2013 at 16:52:31 +0100, Natxo Asenjo wrote: > hi, > > Following the update I needed to update my only non-global zone as > well but this is the result: > > # /usr/sbin/zoneadm -z zone1 attach -u > Log File: /var/tmp/zone1.attach_log.X6ai9c > Attach Path: /tank/zones/zone1/root > Attach ZFS Dataset: tank/zones/zone1/ROOT/zbe-1 > > Installing: Using pre-existing data in zonepath > Result: Attach Failed. > > And in the log: > > [Fri Dec 13 16:38:35 CET 2013] Log File: /var/tmp/zone1.attach_log.X6ai9c > [Fri Dec 13 16:38:38 CET 2013] Attach Path: > /tank/zones/zone1/root > [Fri Dec 13 16:38:38 CET 2013] Attach ZFS Dataset: > tank/zones/zone1/ROOT/zbe-1 > > [Fri Dec 13 16:38:38 CET 2013] existing > [Fri Dec 13 16:38:38 CET 2013] Installing: Using > pre-existing data in zonepath > [Fri Dec 13 16:38:38 CET 2013] Sanity Check: Passed. Looks like an > OpenSolaris system. > Unable to get preferred publisher information for zone 'global'. > brand-specific usage: attach [-a archive] [-d dataset] [-n] [-r zfs-recv] [-u] > The -a archive option specifies a tar file or cpio archive. > The -d dataset option specifies an existing dataset. > The -r zfs-recv option receives the output of a 'zfs send' command > of an existing zone root dataset. > The -u option indicates that the software should be updated to match > the current host. > [Fri Dec 13 16:38:43 CET 2013] Result: Attach Failed. > > Any clues? This is an issue that we're looking into fixing. It looks like the zone attach script is expecting output that isn't there, or output in another format. More to come when we know more. -- Chris Nehren Site Reliability Engineer, OmniTI From ci4 at outlook.com Fri Dec 13 16:45:17 2013 From: ci4 at outlook.com (Chavdar Ivanov) Date: Fri, 13 Dec 2013 16:45:17 +0000 Subject: [OmniOS-discuss] upgrade nearly perfect In-Reply-To: References: Message-ID: -----Original Message----- From: Natxo Asenjo [mailto:natxo.asenjo at gmail.com] Sent: 13 December 2013 15:10 To: Chavdar Ivanov Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] upgrade nearly perfect On Fri, Dec 13, 2013 at 1:41 PM, Chavdar Ivanov wrote: > ? ~ /usr/java/bin/java -version > openjdk version "1.7.0_06" > OpenJDK Runtime Environment (build 1.7.0_06-b24) OpenJDK Server VM > (build 24.0-b47, mixed mode) > > ? ~ pkg list | grep -i java > developer/java/jdk (omnios) 1.7.0.6.24-0.151007 i-- > runtime/java (omnios) 1.7.0.6.24-0.151007 i-- > ? ~ pkg list | grep -i jre > > I do have omniti repo, but as far as I can see, java comes from the main one. > > ? ~ pkg publisher > PUBLISHER TYPE STATUS URI > ms.omniti.com (non-sticky) origin online http://pkg.omniti.com/omniti-ms/ > omnios origin online http://pkg.omniti.com/omnios/release/ mmm, I have this: root at zfstank:~# pkg list | grep -i java runtime/java 0.5.11-0.151008 i-- # pkg info java Name: runtime/java Summary: Open-source implementation of the seventh edition of the Java SE Platform State: Installed Publisher: omnios Version: 0.5.11 (jdk7u21-b30) Build Release: 5.11 Branch: 0.151008 Packaging Date: Wed Dec 4 20:10:13 2013 Size: 105.29 MB FMRI: pkg://omnios/runtime/java at 0.5.11,5.11-0.151008:20131204T201013Z Is this the right one? How can I reinstall it or verify it is correctly installed? [[ci]] Looks like yours is the correct one, but there may be some packaging problem. I'll have to make a clean 151008 installation and add java to see if it will do the same; in my case java was left over from the time I was running bloody. No idea why it hasn't been upgraded. Chavdar TIA, -- groet, natxo From esproul at omniti.com Fri Dec 13 16:53:43 2013 From: esproul at omniti.com (Eric Sproul) Date: Fri, 13 Dec 2013 11:53:43 -0500 Subject: [OmniOS-discuss] upgrade nearly perfect In-Reply-To: References: Message-ID: On Fri, Dec 13, 2013 at 11:45 AM, Chavdar Ivanov wrote: > Looks like yours is the correct one, but there may be some packaging problem. I'll have to make a clean 151008 installation and add java to see if it will do the same; in my case java was left over from the time I was running bloody. No idea why it hasn't been upgraded. If you upgraded from r151007, you may still be missing the omnios-userland incorporation, and should install that to ensure all your packages are brought up to r151008. As there is less difference between r151007 and r151008 than from r151006, it may not have been as obvious that you were missing something. Eric From doug at will.to Fri Dec 13 17:15:59 2013 From: doug at will.to (Doug Hughes) Date: Fri, 13 Dec 2013 12:15:59 -0500 Subject: [OmniOS-discuss] strange io-pattern In-Reply-To: <336F86A6-146D-43D2-92B2-6F379398410A@richardelling.com> References: <52AB05AA.7010202@alcatel-lucent.com> <336F86A6-146D-43D2-92B2-6F379398410A@richardelling.com> Message-ID: regarding the possibility of multi-processor shifting and counters, it seems like that would be fairly easy to rule out (however unlikely) by running pbind on the iostat process to keep it pegged to a specific core. On Fri, Dec 13, 2013 at 10:38 AM, Richard Elling < richard.elling at richardelling.com> wrote: > On Dec 13, 2013, at 5:13 AM, Tobias Oetiker wrote: > > > Hi Paul, > > > > Today Paul Jochum wrote: > > > >> Hi Tobias: > >> > >> Sorry, I don't know why you are having these strang io-patterns, > but I was wondering if you could share how you > >> record and display this info? > > > > I created a little plugin for collectd to interface with iostat. I > > guess having one for vfsstat and arcstat along the same lines would > > give a better picture as to what users actually experience but this > > one gives some impression as to what happens deep down. > > Your script seems to break this out per-device, but that isn?t clear from > the graphs you posted. This pattern is consistent with a misbehaving > device. > ? richard > > > > > #!/usr/bin/perl > > my $filter = $ARGV[0] || '.+'; > > > > my $pid = open my $iostat, "-|", > "/usr/bin/iostat","-Tu","-xnr",int($ENV{COLLECTD_INTERVAL}) or die > "launching iostat: $!"; > > > > $SIG{PIPE} = 'ignore'; > > $SIG{CHLD} = 'ignore'; > > $SIG{TERM} = sub { > > kill 9,$pid; > > exit 1; > > }; > > > > my %data; > > my @cols; > > my $round = 0; > > while (<$iostat>){ > > chomp; > > my @input = split /,/; > > if ($#input == 0 and $input[0] =~ /^\d+$/){ > > publish() if $round++ > 1; > > %data = (); > > next; > > } > > if ($input[-1] eq 'device'){ > > @cols = @input; > > pop @cols; > > next; > > } > > if ($#input == $#cols+1){ > > my $dev = pop @input; > > my %row; > > @row{@cols} = @input; > > $data{$dev} = \%row; > > }; > > } > > > > sub publish { > > $|=0; > > my $time = time(); > > for my $dev (sort keys %data){ > > next unless $dev =~ /^${filter}$/; > > my $d = $data{$dev}; > > my $prefix = "PUTVAL > $ENV{COLLECTD_HOSTNAME}/sol_iostat-$dev/sol_iostat_"; > > print $prefix."op $time:$d->{'r/s'}:$d->{'w/s'}\n"; > > print $prefix."byte > $time:".($d->{'kr/s'}*1024).":".($d->{'kw/s'}*1024)."\n"; > > print $prefix."busypct $time:$d->{'%w'}:$d->{'%b'}\n"; > > print $prefix."wait $time:$d->{wait}\n"; > > print $prefix."actv $time:$d->{actv}\n"; > > print $prefix."wsvc_t $time:".($d->{wsvc_t}/1000)."\n"; > > print $prefix."asvc_t $time:".($d->{asvc_t}/1000)."\n"; > > } > > } > > > > --------- > > adding these new types to the types.db > > > > sol_iostat_op read:GAUGE:0:U, write:GAUGE:0:U > > sol_iostat_byte read:GAUGE:0:U, write:GAUGE:0:U > > sol_iostat_busypct queue:GAUGE:0:100, disk:GAUGE:0:100 > > sol_iostat_wait count:GAUGE:0:U > > sol_iostat_actv count:GAUGE:0:U > > sol_iostat_wsvc_t second:GAUGE:0:U > > sol_iostat_asvc_t second:GAUGE:0:U > > > > cheers > > tobi > > > > -- > > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland > > http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: > -9900_______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Fri Dec 13 20:23:10 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 13 Dec 2013 21:23:10 +0100 (CET) Subject: [OmniOS-discuss] strange io-pattern In-Reply-To: <336F86A6-146D-43D2-92B2-6F379398410A@richardelling.com> References: <52AB05AA.7010202@alcatel-lucent.com> <336F86A6-146D-43D2-92B2-6F379398410A@richardelling.com> Message-ID: Today Richard Elling wrote: > On Dec 13, 2013, at 5:13 AM, Tobias Oetiker wrote: > > > Hi Paul, > > > > Today Paul Jochum wrote: > > > >> Hi Tobias: > >> > >> Sorry, I don't know why you are having these strang io-patterns, but I was wondering if you could share how you > >> record and display this info? > > > > I created a little plugin for collectd to interface with iostat. I > > guess having one for vfsstat and arcstat along the same lines would > > give a better picture as to what users actually experience but this > > one gives some impression as to what happens deep down. > > Your script seems to break this out per-device, but that isn?t clear from > the graphs you posted. This pattern is consistent with a misbehaving device. the charts just show the stats for one zpool (a raidz2) standard illumos style ... so it can not realy be 'a device' also zfs and smart did not record any irregularities cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From ci4 at outlook.com Mon Dec 16 10:05:48 2013 From: ci4 at outlook.com (Chavdar Ivanov) Date: Mon, 16 Dec 2013 10:05:48 +0000 Subject: [OmniOS-discuss] upgrade nearly perfect In-Reply-To: References: Message-ID: -----Original Message----- From: Eric Sproul [mailto:esproul at omniti.com] Sent: 13 December 2013 16:54 To: Chavdar Ivanov Cc: Natxo Asenjo; omnios-discuss Subject: Re: [OmniOS-discuss] upgrade nearly perfect On Fri, Dec 13, 2013 at 11:45 AM, Chavdar Ivanov wrote: > Looks like yours is the correct one, but there may be some packaging problem. I'll have to make a clean 151008 installation and add java to see if it will do the same; in my case java was left over from the time I was running bloody. No idea why it hasn't been upgraded. If you upgraded from r151007, you may still be missing the omnios-userland incorporation, and should install that to ensure all your packages are brought up to r151008. As there is less difference between r151007 and r151008 than from r151006, it may not have been as obvious that you were missing something. [[ci]] Yes, that seems to have been the case. Installing omnios-userland failed initially, I had to uninstall jdk, poold, java and gnu-tar; after that I was able to install omnios-userland and bring back the packages I uninstalled. Java works fine. Chavdar Ivanov Eric From esproul at omniti.com Mon Dec 16 15:09:13 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 16 Dec 2013 10:09:13 -0500 Subject: [OmniOS-discuss] i210 support in bloody In-Reply-To: <52ADF320.4040607@gmx.eu> References: <529BA492.4060105@gmx.eu> <52ADF320.4040607@gmx.eu> Message-ID: Hello David, Unfortunately I don't have any such hardware to try to repeat this issue. I'm copying the omnios-discuss list in hopes that someone else does. Eric On Sun, Dec 15, 2013 at 1:21 PM, David Wehrhahn wrote: > Dear Eric, > > thank you for the quick reply. meanwhile i tested omnios r151008 and > openindiana hipster with the same issue. > the asus p9d-c/4l has 4*i210at nics and i added another e1000g intel nic. > now i try to give them all static ip-adresses. > after third nic, the network-connection crashes and i need to remove the > last nic by "ipadm delete-if igbx" > after this and reboot everything works fine. > > root at omnios:~# dladm show-phys > LINK MEDIA STATE SPEED DUPLEX DEVICE > igb3 Ethernet unknown 0 half igb3 > igb2 Ethernet unknown 0 half igb2 > igb0 Ethernet up 1000 full igb0 > e1000g0 Ethernet up 1000 full e1000g0 > igb1 Ethernet down 0 half igb1 > root at omnios:~# ipadm show-addr > ADDROBJ TYPE STATE ADDR > lo0/v4 static ok 127.0.0.1/8 > e1000g0/v4 static ok 192.168.1.120/24 > igb0/v4 static ok 192.168.1.130/24 > igb1/v4 static inaccessible 192.168.1.140/24 > lo0/v6 static ok ::1/128 > root at omnios:~# ipadm show-if > IFNAME STATE CURRENT PERSISTENT > lo0 ok -m-v------46 --- > e1000g0 ok bm--------46 -46 > igb0 ok bm--------46 -46 > igb1 failed bm--------46 -46 > > > > > > > > no i tried same in vmware player with openindia hipster and 6 nvics (e1000g) > and it works, so maybe we have an issue with the i210at driver. i hope you > can help me. > > dladm show-phys > LINK MEDIA STATE SPEED DUPLEX DEVICE > e1000g0 Ethernet up 1000 full e1000g0 > e1000g1 Ethernet up 1000 full e1000g1 > e1000g3 Ethernet up 1000 full e1000g3 > e1000g5 Ethernet unknown 1000 full e1000g5 > e1000g4 Ethernet unknown 1000 full e1000g4 > e1000g2 Ethernet up 1000 full e1000g2 > Monitor-Extension: Command Log interface.pl 894# ipadm show-addr > exe: ipadm show-addr > ADDROBJ TYPE STATE ADDR > lo0/v4 static ok 127.0.0.1/8 > e1000g0/v4 static ok 192.168.1.200/24 > e1000g1/v4 static ok 192.168.1.201/24 > e1000g2/v4 static ok 192.168.1.202/24 > e1000g3/v4 static ok 192.168.1.203/24 > lo0/v6 static ok ::1/128 > e1000g4/v4 static disabled 192.168.1.204/24 > e1000g5/v4 static disabled 192.168.1.205/24 > > > > > > > best reagrds from germany, > > david > > > > > > > > > > > > > > > > Am 01.12.2013 22:27, schrieb Eric Sproul: > >> On Sun, Dec 1, 2013 at 4:05 PM, David Wehrhahn wrote: >>> >>> Dear Mr. Sproul, >>> >>> i just want to ask about i210 support in omnios bloody. i bought a asus >>> p9d-c/4l mainboard with four intel i210 nics and installed latest omnios >>> bloody, but i cant find them with " dladm show-phys". >>> how can i acticate the network interface? >> >> The ISO image for bloody on our website is quite old. We were not >> diligent in keeping the ISO image updated during this release cycle. >> You are probably running r151005, which lacks the i210-capable igb >> driver. We are planning to have r151008 released this week, which is >> our next stable release and will include i210 support. It will be >> announced on omnios-discuss and in #omnios on Freenode IRC. >> >> Regards, >> Eric > > From gate03 at landcroft.co.uk Mon Dec 16 19:46:24 2013 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Tue, 17 Dec 2013 05:46:24 +1000 Subject: [OmniOS-discuss] SSH over HTTPS Message-ID: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> Hello, to get around super-tight restrictions in my workplace, I'm looking for an SSH over HTTPS solution. My home server runs OmniOS (of course) and my workplace is a M$ shop through and through. Running sshd on port 443, and connecting via Putty, doesn't work. I don't know why as surely their firewall must allow https traffic, but it doesn't. I don't understand these things fully. Please don't warn me about the dangers of being found out: I don't really care. Thanks in expectation. From jimklimov at cos.ru Tue Dec 17 08:39:12 2013 From: jimklimov at cos.ru (Jim Klimov) Date: Tue, 17 Dec 2013 12:39:12 +0400 Subject: [OmniOS-discuss] SSH over HTTPS In-Reply-To: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> References: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> Message-ID: <52B00DB0.6070402@cos.ru> On 2013-12-16 23:46, Michael Mounteney wrote: > Hello, to get around super-tight restrictions in my workplace, I'm looking for an SSH over HTTPS solution. My home server runs OmniOS (of course) and my workplace is a M$ shop through and through. > > Running sshd on port 443, and connecting via Putty, doesn't work. I don't know why as surely their firewall must allow https traffic, but it doesn't. I don't understand these things fully. Does (from work to home) "telnet home 443" print the SSH banner like this? SSH-2.0-Sun_SSH_1.5 Are there any logs about broken connections at home? Maybe there is something bad about MTU mismatches, etc.? Hint: you can set up IPFILTER with a "custom" config via files and "log" all packets from your work's IP address(es), then go review the ipmon logs. > Please don't warn me about the dangers of being found out: I don't really care. Beside SSH, take a look at OpenVPN - they had some method of co-existing with an HTTPS server. Possibly, your work's firewall is smart enough to probe the port you requested and find out that there is no HTTP(S) on it, so it denies the connection. If your home's port 443 does serve HTTPS, even if just an Apache Welcome page, this test would likely pass. If this works, you can fire up an OpenVPN client connection from work to home, and use SSH with minimal encryption inside this tunnel. This does add overhead, but should work. HTH, //Jim From natxo.asenjo at gmail.com Tue Dec 17 08:57:12 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 17 Dec 2013 09:57:12 +0100 Subject: [OmniOS-discuss] SSH over HTTPS In-Reply-To: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> References: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> Message-ID: On Mon, Dec 16, 2013 at 8:46 PM, Michael Mounteney wrote: > Hello, to get around super-tight restrictions in my workplace, I'm looking for an SSH over HTTPS solution. My home server runs OmniOS (of course) and my workplace is a M$ shop through and through. > > Running sshd on port 443, and connecting via Putty, doesn't work. I don't know why as surely their firewall must allow https traffic, but it doesn't. I don't understand these things fully. have you tried this: http://dag.wiee.rs/howto/ssh-http-tunneling/ -- groet, natxo From natxo.asenjo at gmail.com Tue Dec 17 09:02:18 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 17 Dec 2013 10:02:18 +0100 Subject: [OmniOS-discuss] SSH over HTTPS In-Reply-To: References: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> Message-ID: or maybe this: http://en.wikipedia.org/wiki/Web-based_SSH -- Groeten, natxo On Tue, Dec 17, 2013 at 9:57 AM, Natxo Asenjo wrote: > On Mon, Dec 16, 2013 at 8:46 PM, Michael Mounteney > wrote: >> Hello, to get around super-tight restrictions in my workplace, I'm looking for an SSH over HTTPS solution. My home server runs OmniOS (of course) and my workplace is a M$ shop through and through. >> >> Running sshd on port 443, and connecting via Putty, doesn't work. I don't know why as surely their firewall must allow https traffic, but it doesn't. I don't understand these things fully. > > have you tried this: > > http://dag.wiee.rs/howto/ssh-http-tunneling/ > > -- > groet, > natxo From gate03 at landcroft.co.uk Tue Dec 17 11:31:50 2013 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Tue, 17 Dec 2013 22:31:50 +1100 Subject: [OmniOS-discuss] SSH over HTTPS In-Reply-To: References: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> Message-ID: <20131217223150.23bb9648@dickless.landy.net> On Tue, 17 Dec 2013 10:02:18 +0100 Natxo Asenjo wrote: > or maybe this: > > http://en.wikipedia.org/wiki/Web-based_SSH Thanks to you and others for the various replies. Enough for me to think about. I should have made clear that obviously this problem is not specific to OmniOS but I was hoping that there might be some ready-made packages for the server side that would provide half of one solution at least. But some ideas so thanks people. Michael. From skiselkov.ml at gmail.com Tue Dec 17 11:50:37 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Tue, 17 Dec 2013 11:50:37 +0000 Subject: [OmniOS-discuss] SSH over HTTPS In-Reply-To: <52B00DB0.6070402@cos.ru> References: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> <52B00DB0.6070402@cos.ru> Message-ID: <52B03A8D.8090309@gmail.com> On 12/17/13, 8:39 AM, Jim Klimov wrote: > Possibly, your work's firewall > is smart enough to probe the port you requested and find out that > there is no HTTP(S) on it, so it denies the connection. Minor side-note, unless the proxy is trying to brutally MITM the session (forged certificates and all), then there's absolutely no way for it to know if a particular TLS session is carrying HTTPS traffic or something else (short of doing some kind of statistical analysis of the traffic flow, that is). Cheers, -- Saso From rafibeyli at gmail.com Tue Dec 17 13:51:02 2013 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Tue, 17 Dec 2013 15:51:02 +0200 (EET) Subject: [OmniOS-discuss] IRQ16 is being shared by drivers with different interrupt levels In-Reply-To: <1319494630.95591.1387287924202.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <24775525.96051.1387288262524.JavaMail.zimbra@cantekstil.com.tr> Hello, I'm getting these errors on my omnios after adding INTEL D14799-001 PRO/1000 PF Dual Port Server Network Adapter. New added NIC working well. what is wrong with my system? Dec 17 15:26:03 canomnios This may result in reduced system performance. Dec 17 15:26:03 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. Dec 17 15:26:03 canomnios This may result in reduced system performance. Dec 17 15:26:16 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. Dec 17 15:26:16 canomnios This may result in reduced system performance. Dec 17 15:26:16 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. Dec 17 15:26:16 canomnios This may result in reduced system performance. Dec 17 15:26:34 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. Dec 17 15:26:34 canomnios This may result in reduced system performance. Dec 17 15:26:34 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. Dec 17 15:26:34 canomnios This may result in reduced system performance. Some info about system: > ::interrupts -d IRQ Vect IPL Bus Trg Type CPU Share APIC/INT# Driver Name(s) 3 0xb1 12 ISA Edg Fixed 2 1 0x0/0x3 asy#1 4 0xb0 12 ISA Edg Fixed 1 1 0x0/0x4 asy#0 5 0xb2 12 ISA Edg Fixed 3 1 0x0/0x5 asy#2 9 0x80 9 PCI Lvl Fixed 1 1 0x0/0x9 acpi_wrapper_isr 11 0xd1 14 PCI Lvl Fixed 2 1 0x0/0xb hpet_isr 16 0x85 9 PCI Lvl Fixed 1 1 0x0/0x10 uhci#0 17 0x88 9 PCI Lvl Fixed 4 1 0x0/0x11 hci1394#0 18 0x83 9 PCI Lvl Fixed 7 2 0x0/0x12 uhci#5, ehci#0 19 0x87 9 PCI Lvl Fixed 3 2 0x0/0x13 uhci#4, uhci#2 21 0x86 9 PCI Lvl Fixed 2 1 0x0/0x15 uhci#1 23 0x84 9 PCI Lvl Fixed 0 2 0x0/0x17 uhci#3, ehci#1 24 0x40 5 PCI Edg MSI 3 1 - ahci#0 25 0x81 7 PCI Edg MSI 4 1 - pcieb#0 26 0x30 4 PCI Edg MSI 5 1 - pcieb#2 27 0x82 7 PCI Edg MSI 6 1 - pcieb#3 28 0x31 4 PCI Edg MSI 5 1 - pcieb#6 29 0x89 7 PCI Edg MSI 6 1 - pcieb#7 30 0x32 4 PCI Edg MSI 7 1 - pcieb#1 31 0x60 6 PCI Edg MSI-X 0 1 - igb#0 32 0x20 2 Edg IPI all 1 - cmi_cmci_trap 33 0x61 6 PCI Edg MSI-X 1 1 - igb#0 34 0x62 6 PCI Edg MSI-X 2 1 - igb#1 35 0x63 6 PCI Edg MSI-X 3 1 - igb#1 36 0x64 6 PCI Edg MSI 4 1 - e1000g#0 37 0x65 6 PCI Edg MSI 5 1 - e1000g#3 38 0x66 6 PCI Edg MSI 6 1 - e1000g#1 39 0x67 6 PCI Edg MSI 7 1 - e1000g#2 40 0x41 5 PCI Edg MSI 0 1 - mpt_sas#0 41 0x42 5 PCI Edg MSI 1 1 - mpt_sas#1 42 0x68 6 PCI Edg MSI 7 1 - e1000g#4 43 0x69 6 PCI Edg MSI 0 1 - e1000g#5 160 0xa0 0 Edg IPI all 0 - poke_cpu 208 0xd0 14 Edg IPI all 1 - kcpc_hw_overflow_intr 209 0xd3 14 Edg IPI all 1 - cbe_fire 210 0xd4 14 Edg IPI all 1 - cbe_fire 240 0xe0 15 Edg IPI all 1 - xc_serv 241 0xe1 15 Edg IPI all 1 - apic_error_intr OmniOS 5.11 omnios-6de5e81 2013.11.27 root at canomnios:~# prtdiag System Configuration: Supermicro X8DAH BIOS Configuration: American Megatrends Inc. 2.1 12/30/2011 BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style) ==== Processor Sockets ==================================== Version Location Tag -------------------------------- -------------------------- Intel(R) Xeon(R) CPU E5620 @ 2.40GHz CPU 1 ==== Memory Device Sockets ================================ Type Status Set Device Locator Bank Locator ----------- ------ --- ------------------- ---------------- other in use 0 P1_DIMM1A P1_BANK1 other in use 0 P1_DIMM1B P1_BANK1 other empty 0 P1_DIMM1C P1_BANK1 other in use 0 P1_DIMM2A P1_BANK2 other in use 0 P1_DIMM2B P1_BANK2 other empty 0 P1_DIMM2C P1_BANK2 other in use 0 P1_DIMM3A P1_BANK3 other in use 0 P1_DIMM3B P1_BANK3 other empty 0 P1_DIMM3C P1_BANK3 other empty 0 P2_DIMM1A P2_BANK1 other empty 0 P2_DIMM1B P2_BANK1 other empty 0 P2_DIMM1C P2_BANK1 other empty 0 P2_DIMM2A P2_BANK2 other empty 0 P2_DIMM2B P2_BANK2 other empty 0 P2_DIMM2C P2_BANK2 other empty 0 P2_DIMM3A P2_BANK3 other empty 0 P2_DIMM3B P2_BANK3 other empty 0 P2_DIMM3C P2_BANK3 FLASH in use 0 BIOS ROM0 ==== On-Board Devices ===================================== ==== Upgradeable Slots ==================================== ID Status Type Description --- --------- ---------------- ---------------------------- 1 in use PCI Express x8 PCIE1 2 available PCI Express x16 PCIE2 3 in use PCI Express x8 PCIE3 4 in use PCI Express x16 PCIE4 5 in use PCI Express x8 PCIE5 6 available PCI Express x16 PCIE6 7 in use PCI Express x8 PCIE7 From jdg117 at elvis.arl.psu.edu Tue Dec 17 14:14:49 2013 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Tue, 17 Dec 2013 09:14:49 -0500 Subject: [OmniOS-discuss] SSH over HTTPS In-Reply-To: Your message of "Tue, 17 Dec 2013 11:50:37 GMT." <52B03A8D.8090309@gmail.com> References: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> <52B00DB0.6070402@cos.ru> <52B03A8D.8090309@gmail.com> Message-ID: <201312171414.rBHEEnTp000647@elvis.arl.psu.edu> In message <52B03A8D.8090309 at gmail.com>, Saso Kiselkov writes: >Minor side-note, unless the proxy is trying to brutally MITM the session >(forged certificates and all), then there's absolutely no way for it to >know if a particular TLS session is carrying HTTPS traffic or something >else (short of doing some kind of statistical analysis of the traffic >flow, that is). I believe Palo Alto Network's product combines statefull firewall and application proxy inspection. John groenveld at acm.org From skiselkov.ml at gmail.com Tue Dec 17 14:29:53 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Tue, 17 Dec 2013 14:29:53 +0000 Subject: [OmniOS-discuss] SSH over HTTPS In-Reply-To: <201312171414.rBHEEnTp000647@elvis.arl.psu.edu> References: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk> <52B00DB0.6070402@cos.ru> <52B03A8D.8090309@gmail.com> <201312171414.rBHEEnTp000647@elvis.arl.psu.edu> Message-ID: <52B05FE1.3060906@gmail.com> On 12/17/13, 2:14 PM, John D Groenveld wrote: > In message <52B03A8D.8090309 at gmail.com>, Saso Kiselkov writes: >> Minor side-note, unless the proxy is trying to brutally MITM the session >> (forged certificates and all), then there's absolutely no way for it to >> know if a particular TLS session is carrying HTTPS traffic or something >> else (short of doing some kind of statistical analysis of the traffic >> flow, that is). > > I believe Palo Alto Network's product combines statefull firewall and > application proxy inspection. > Which does it exactly by utilizing statistical analysis, as I mentioned. That having been said, it's trivial to break through that by simply encapsulating your SSH traffic using HTTP tunneling software. Then, for all intents and purposes, your traffic looks like regular HTTPS (because it is). Of course they may choose to filter anything that exchanges small HTTP requests too aggressively, but that would probably break a fair number of AJAX-based web apps such as GMail (which can be rather chatty over the line, frequently exchanging tiny XML blobs as you type messages, etc.). Cheers, -- Saso From mir at miras.org Tue Dec 17 19:31:02 2013 From: mir at miras.org (Michael Rasmussen) Date: Tue, 17 Dec 2013 20:31:02 +0100 Subject: [OmniOS-discuss] Upgrade path Message-ID: <20131217203102.43e38f99@sleipner.datanom.net> Hi all, I am currently on r151008 and my intention is to move to the LTS track as of r151014. My question is whether this upgrade path will be supported: r151008 -> r151010 -> r151014 or do I require to follow the full path r151008 -> r151010 -> r151012 -> r151014 -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Linux is obsolete (Andrew Tanenbaum) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From richard.elling at richardelling.com Tue Dec 17 23:38:21 2013 From: richard.elling at richardelling.com (Richard Elling) Date: Tue, 17 Dec 2013 15:38:21 -0800 Subject: [OmniOS-discuss] IRQ16 is being shared by drivers with different interrupt levels In-Reply-To: <24775525.96051.1387288262524.JavaMail.zimbra@cantekstil.com.tr> References: <24775525.96051.1387288262524.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <15ECB1A5-2609-44F3-84E2-E7CBF5FCE68D@RichardElling.com> On Dec 17, 2013, at 5:51 AM, Hafiz Rafibeyli wrote: > Hello, > > I'm getting these errors on my omnios after adding INTEL D14799-001 PRO/1000 PF Dual Port Server Network Adapter. > New added NIC working well. > > what is wrong with my system? Nothing. This is a common annoyance for the X8DAH. If you'd like it to go away, you can try disabling the uchi driver (USB 1.1) and be happy with the ehci driver (both USB 1.1 and 2.0) by adding an "exclude: uhci" in /etc/system and reboot. See the exclude section of /etc/system for more info on how to exclude drivers. -- richard > > > Dec 17 15:26:03 canomnios This may result in reduced system performance. > Dec 17 15:26:03 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. > Dec 17 15:26:03 canomnios This may result in reduced system performance. > Dec 17 15:26:16 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. > Dec 17 15:26:16 canomnios This may result in reduced system performance. > Dec 17 15:26:16 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. > Dec 17 15:26:16 canomnios This may result in reduced system performance. > Dec 17 15:26:34 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. > Dec 17 15:26:34 canomnios This may result in reduced system performance. > Dec 17 15:26:34 canomnios unix: [ID 954099 kern.info] NOTICE: IRQ16 is being shared by drivers with different interrupt levels. > Dec 17 15:26:34 canomnios This may result in reduced system performance. > > Some info about system: > >> ::interrupts -d > IRQ Vect IPL Bus Trg Type CPU Share APIC/INT# Driver Name(s) > 3 0xb1 12 ISA Edg Fixed 2 1 0x0/0x3 asy#1 > 4 0xb0 12 ISA Edg Fixed 1 1 0x0/0x4 asy#0 > 5 0xb2 12 ISA Edg Fixed 3 1 0x0/0x5 asy#2 > 9 0x80 9 PCI Lvl Fixed 1 1 0x0/0x9 acpi_wrapper_isr > 11 0xd1 14 PCI Lvl Fixed 2 1 0x0/0xb hpet_isr > 16 0x85 9 PCI Lvl Fixed 1 1 0x0/0x10 uhci#0 > 17 0x88 9 PCI Lvl Fixed 4 1 0x0/0x11 hci1394#0 > 18 0x83 9 PCI Lvl Fixed 7 2 0x0/0x12 uhci#5, ehci#0 > 19 0x87 9 PCI Lvl Fixed 3 2 0x0/0x13 uhci#4, uhci#2 > 21 0x86 9 PCI Lvl Fixed 2 1 0x0/0x15 uhci#1 > 23 0x84 9 PCI Lvl Fixed 0 2 0x0/0x17 uhci#3, ehci#1 > 24 0x40 5 PCI Edg MSI 3 1 - ahci#0 > 25 0x81 7 PCI Edg MSI 4 1 - pcieb#0 > 26 0x30 4 PCI Edg MSI 5 1 - pcieb#2 > 27 0x82 7 PCI Edg MSI 6 1 - pcieb#3 > 28 0x31 4 PCI Edg MSI 5 1 - pcieb#6 > 29 0x89 7 PCI Edg MSI 6 1 - pcieb#7 > 30 0x32 4 PCI Edg MSI 7 1 - pcieb#1 > 31 0x60 6 PCI Edg MSI-X 0 1 - igb#0 > 32 0x20 2 Edg IPI all 1 - cmi_cmci_trap > 33 0x61 6 PCI Edg MSI-X 1 1 - igb#0 > 34 0x62 6 PCI Edg MSI-X 2 1 - igb#1 > 35 0x63 6 PCI Edg MSI-X 3 1 - igb#1 > 36 0x64 6 PCI Edg MSI 4 1 - e1000g#0 > 37 0x65 6 PCI Edg MSI 5 1 - e1000g#3 > 38 0x66 6 PCI Edg MSI 6 1 - e1000g#1 > 39 0x67 6 PCI Edg MSI 7 1 - e1000g#2 > 40 0x41 5 PCI Edg MSI 0 1 - mpt_sas#0 > 41 0x42 5 PCI Edg MSI 1 1 - mpt_sas#1 > 42 0x68 6 PCI Edg MSI 7 1 - e1000g#4 > 43 0x69 6 PCI Edg MSI 0 1 - e1000g#5 > 160 0xa0 0 Edg IPI all 0 - poke_cpu > 208 0xd0 14 Edg IPI all 1 - kcpc_hw_overflow_intr > 209 0xd3 14 Edg IPI all 1 - cbe_fire > 210 0xd4 14 Edg IPI all 1 - cbe_fire > 240 0xe0 15 Edg IPI all 1 - xc_serv > 241 0xe1 15 Edg IPI all 1 - apic_error_intr > > OmniOS 5.11 omnios-6de5e81 2013.11.27 > root at canomnios:~# prtdiag > System Configuration: Supermicro X8DAH > BIOS Configuration: American Megatrends Inc. 2.1 12/30/2011 > BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style) > > ==== Processor Sockets ==================================== > > Version Location Tag > -------------------------------- -------------------------- > Intel(R) Xeon(R) CPU E5620 @ 2.40GHz CPU 1 > > ==== Memory Device Sockets ================================ > > Type Status Set Device Locator Bank Locator > ----------- ------ --- ------------------- ---------------- > other in use 0 P1_DIMM1A P1_BANK1 > other in use 0 P1_DIMM1B P1_BANK1 > other empty 0 P1_DIMM1C P1_BANK1 > other in use 0 P1_DIMM2A P1_BANK2 > other in use 0 P1_DIMM2B P1_BANK2 > other empty 0 P1_DIMM2C P1_BANK2 > other in use 0 P1_DIMM3A P1_BANK3 > other in use 0 P1_DIMM3B P1_BANK3 > other empty 0 P1_DIMM3C P1_BANK3 > other empty 0 P2_DIMM1A P2_BANK1 > other empty 0 P2_DIMM1B P2_BANK1 > other empty 0 P2_DIMM1C P2_BANK1 > other empty 0 P2_DIMM2A P2_BANK2 > other empty 0 P2_DIMM2B P2_BANK2 > other empty 0 P2_DIMM2C P2_BANK2 > other empty 0 P2_DIMM3A P2_BANK3 > other empty 0 P2_DIMM3B P2_BANK3 > other empty 0 P2_DIMM3C P2_BANK3 > FLASH in use 0 BIOS ROM0 > > ==== On-Board Devices ===================================== > > ==== Upgradeable Slots ==================================== > > ID Status Type Description > --- --------- ---------------- ---------------------------- > 1 in use PCI Express x8 PCIE1 > 2 available PCI Express x16 PCIE2 > 3 in use PCI Express x8 PCIE3 > 4 in use PCI Express x16 PCIE4 > 5 in use PCI Express x8 PCIE5 > 6 available PCI Express x16 PCIE6 > 7 in use PCI Express x8 PCIE7 > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdunn at getchef.com Wed Dec 18 00:58:51 2013 From: jdunn at getchef.com (Julian C. Dunn) Date: Tue, 17 Dec 2013 19:58:51 -0500 Subject: [OmniOS-discuss] OmniOS r151008f panic under VMWare Fusion Message-ID: All, I?m testing OmniOS under VMWare Fusion. After installing the VMware tools that come with 6.0.2, attempting to shut the box down (e.g. ?init 5?) instantly kernel panics with the attached. Has anyone seen this before? I recovered the cores, etc. from the box if anyone is interested. - Julian -- Julian C. Dunn Senior Consultant | Chef Software, Inc. o: 206-504-7787 | m: 347-986-0308 f: 206-223-2770 | t: @julian_dunn 1008 Western Ave., Suite 600 | Seattle, WA 98104 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 45fa36e3-7c65-4ac0-ca87-b3cfb3db4f1c.txt URL: From tom.robinson at motec.com.au Wed Dec 18 05:10:49 2013 From: tom.robinson at motec.com.au (Tom Robinson) Date: Wed, 18 Dec 2013 16:10:49 +1100 Subject: [OmniOS-discuss] st driver issue with blocksize > 1MiB Message-ID: <52B12E59.1060808@motec.com.au> OmniOS v11 r151006 st driver sgen driver Hi, I'm having issues with the st driver accepting writes to tape with a block size larger than 1MiB where it previously did write 2MiB blocks. Previously I had written to the tape using a blocksize of 2MiB (using amanda software command 'amtapetype'): $ amtapetype -f -b 2048k -t ULT3580-TD5 weekly /dev/rmt/0bn Checking for FSF_AFTER_FILEMARK requirement device-property "FSF_AFTER_FILEMARK" "false" Applying heuristic check for compression. Wrote random (uncompressible) data at 87839727.2131148 bytes/sec Wrote fixed (compressible) data at 282011755.789474 bytes/sec Compression: enabled Writing one file to fill the volume. Wrote 1519520841728 bytes at 86133 kb/sec Writing smaller files (15193866240 bytes) to determine filemark. define tapetype ULT3580-TD5 { comment "Created by amtapetype; compression enabled" length 1483907072 kbytes filemark 1820 kbytes speed 86133 kps blocksize 2048 kbytes } # LEOM is not supported for this drive and kernel I have since rebooted a few times but the tape unit always appeared to be available as mt and mtx worked apparently without error. # mt config "IBM ULT3580-TD5", "IBM ULT3580-TD5 ", "CFGIBMULT3580TD5"; CFGIBMULT3580TD5 = 2,0x3B,0,0x1018619,4,0x46,0x46,0x58,0x58,3,60,1500,600,16920,780,780,16380; # mt status IBM ULT3580-TD5 tape drive: sense key(0x0)= No Additional Sense residual= 0 retries= 0 file no= 0 block no= 0 Now, I tried to determine the block size on the tape using dd and got this: dd if=/dev/rmt/0bn bs=1024K count=1 of=/dev/null 0+1 records in 0+1 records out 32768 bytes (33 kB) copied, 0.0103029 s, 3.2 MB/s That is, the block is 32KiB (told to read 1MiB, got 32KiB) But that tape was written with 2MiB blocks! I powered off, then on the tape unit and got this: dd if=/dev/rmt/0bn bs=1024K count=1 of=/dev/null 0+1 records in 0+1 records out 1047552 bytes (1.0 MB) copied, 0.0172134 s, 60.9 MB/s That is the block is at least 1MiB, ask for 1MiB, got 1MiB. If I read one more byte, I get a kernel error dd if=/dev/rmt/0b bs=1048577 count=1 of=/dev/null dd: reading ?/dev/rmt/0b?: Invalid argument 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.00532612 s, 0.0 kB/s (see /var/adm/messages) Dec 18 15:09:50 monza.motec.com.au scsi: [ID 107833 kern.notice] /pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/tape at w5000e11156304003,0 (st5): Dec 18 15:09:50 monza.motec.com.au Read Write scsi_init_pkt() failure Dec 18 15:09:50 monza.motec.com.au scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/tape at w5000e11156304003,0 (st5): Dec 18 15:09:50 monza.motec.com.au errors after pkt alloc (b_flags=0x2200065, b_error=0x16) Is this a driver issue? Does st5 mean LUN 5? grep -e '\' -e '\' /etc/path_to_inst "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/tape at w5000e11156304003,0" 2 "st" "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/medium-changer at w5000e11156304003,1" 3 "st" "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/medium-changer at w5000e11156304003,1" 1 "sgen" "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/tape at w5000e11156304002,0" 4 "st" "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/medium-changer at w5000e11156304002,1" 3 "sgen" "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/tape at w5000e11156304002,0" 0 "st" "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/medium-changer at w5000e11156304002,1" 1 "st" "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/medium-changer at w5000e11156304002,1" 0 "sgen" "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/tape at w5000e11156304003,0" 5 "st" "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/medium-changer at w5000e11156304003,1" 2 "sgen" # iostat -En rmt/0 rmt/1 rmt/1 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: IBM Product: ULT3580-TD5 Revision: B6W0 Serial No: rmt/0 Soft Errors: 4 Hard Errors: 0 Transport Errors: 11 Vendor: IBM Product: ULT3580-TD5 Revision: B6W0 Serial No: BTW, the tape unit is configured through a backplane onto an LSI SAS 9207-8i which also has SSD connected to it. Is this going to cause the issues I'm seeing? cfgadm -av ---8<--- Ap_Id Receptacle Occupant Condition Information When Type Busy Phys_Id c1 connected configured unknown unavailable scsi-sas n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi c1::dsk/c1t5000A72A30086BBDd0 connected configured unknown STEC ZeusRAM unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A30086BBDd0 c1::dsk/c1t5000A72A300893E9d0 connected configured unknown STEC S842E200M2 unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A300893E9d0 c1::dsk/c1t5000A72A300893EBd0 connected configured unknown STEC S842E200M2 unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A300893EBd0 c1::dsk/c1t5000A72A300893EDd0 connected configured unknown STEC S842E200M2 unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A300893EDd0 c1::dsk/c1t5000A72A300893F1d0 connected configured unknown STEC S842E200M2 unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A300893F1d0 c1::es/ses0 connected configured unknown LSI SAS2X28 unavailable ESI n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::es/ses0 c1::rmt/0 connected configured unknown IBM ULT3580-TD5 unavailable tape n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::rmt/0 c1::scsi/changer/c1t5000E1115 connected configured unknown IBM 3573-TL unavailable med-changer n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::scsi/changer/c1t5000E11156304003d1 c1::smp/expd0 connected configured unknown LSI SAS2X28 unavailable smp n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::smp/expd0 c2 connected configured unknown unavailable scsi-sas n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi c2::dsk/c2t5000A72B30086BBDd0 connected configured unknown STEC ZeusRAM unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B30086BBDd0 c2::dsk/c2t5000A72B300893E9d0 connected configured unknown STEC S842E200M2 unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B300893E9d0 c2::dsk/c2t5000A72B300893EBd0 connected configured unknown STEC S842E200M2 unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B300893EBd0 c2::dsk/c2t5000A72B300893EDd0 connected configured unknown STEC S842E200M2 unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B300893EDd0 c2::dsk/c2t5000A72B300893F1d0 connected configured unknown STEC S842E200M2 unavailable disk n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B300893F1d0 c2::es/ses1 connected configured unknown LSI SAS2X28 unavailable ESI n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::es/ses1 c2::rmt/1 connected configured unknown IBM ULT3580-TD5 unavailable tape n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::rmt/1 c2::scsi/changer/c2t5000E1115 connected configured unknown IBM 3573-TL unavailable med-changer n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::scsi/changer/c2t5000E11156304002d1 c2::smp/expd1 connected configured unknown LSI SAS2X28 unavailable smp n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::smp/expd1 ---8<--- Any help is appreciated. Kind regards, Tom -- Tom Robinson IT Manager/System Administrator MoTeC Pty Ltd 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 E: tom.robinson at motec.com.au -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From ben at fluffy.co.uk Wed Dec 18 08:20:25 2013 From: ben at fluffy.co.uk (Ben Summers) Date: Wed, 18 Dec 2013 08:20:25 +0000 Subject: [OmniOS-discuss] OmniOS r151008f panic under VMWare Fusion In-Reply-To: References: Message-ID: On 18 Dec 2013, at 00:58, "Julian C. Dunn" wrote: > All, > > I?m testing OmniOS under VMWare Fusion. After installing the VMware tools that come with 6.0.2, attempting to shut the box down (e.g. ?init 5?) instantly kernel panics with the attached. > > Has anyone seen this before? I recovered the cores, etc. from the box if anyone is interested. I've had this on earlier OmniOS versions, with VMware Fusion 5.something. My solution was to install the tools with all the defaults, except NO - VMware Host-Guest Filesystem NO - vmblock This seems to avoid the crashes, while providing the functionality I care about. I suspect vmblock rather than the guest filesystem, so you could try installing that feature if it's important to you. Ben -- http://bens.me.uk From fwp at deepthought.com Wed Dec 18 09:48:19 2013 From: fwp at deepthought.com (Frank Pittel) Date: Wed, 18 Dec 2013 03:48:19 -0600 Subject: [OmniOS-discuss] Problem upgrading Message-ID: <20131218094818.GB21469@warlock.deepthought.com> I've been trying to upgrade my omnios installation from r151006 to r151008 since r151008 was released without any luck. I've been following the instructions to the letter and don't actually get any errors during the process. During the "upgrade" about 3MB of something gets installed and after rebooting running pkg update completely fails. I've captured the steps I took during the "upgrade": root at omni1:~# kg update package/pkg at 0.5.11,5.11-0.151006:20130731T192303Z web/ca-bundle at 5.11,5.11-0.151006:20130718T173831Z -bash: kg: command not found root at omni1:~# pkg update package/pkg at 0.5.11,5.11-0.151006:20130731T192303Z web/ca-bundle at 5.11,5.11-0.151006:20130718T173831Z No updates available for this image. root at omni1:~# pkg list incorporation/jeos/omnios-userland >/dev/null 2>&1 || pkg install incorporation/jeos/omnios-userland at 11,5.11-0.151006 root at omni1:~# pkg update runtime/perl/manual at 5.16.1,5.11-0.151006 No updates available for this image. root at omni1:~# pkg list runtime/perl-64 >/dev/null 2>&1 && pkg update runtime/perl-64 at 5.16.1,5.11-0.151006 root at omni1:~# /usr/bin/pkg update --be-name=omnios-r151008 Packages to update: 3 Create boot environment: Yes Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) Completed 3/3 38/38 3.0/3.0 PHASE ACTIONS Install Phase 3/3 Update Phase 45/45 PHASE ITEMS Package State Update Phase 6/6 Package Cache Update Phase 3/3 Image State Update Phase 2/2 PHASE ITEMS Reading Existing Index 8/8 Indexing Packages 3/3 A clone of omnios-3 exists and has been updated and activated. On the next boot the Boot Environment omnios-r151008 will be mounted on '/'. Reboot when ready to switch to this updated BE. --------------------------------------------------------------------------- NOTE: Please review release notes posted at: http://omnios.omniti.com/ReleaseNotes --------------------------------------------------------------------------- Figuring something wasn't right I tried running "pkg update after rebooting and got the following mess: root at omni1:~# 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.151008:20131204T022427Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z The following indicates why the system cannot update to the latest version: No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z found: Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found I'm sure I'm doing something wrong but have no idea of what that may be. I haven't built any zones yet and am wondering if the only way for me to get this upgrade to work is to reinstall. I see that others were able to perform the upgrade so I'm sure it's something I did wrong at sometime which is causing the upgrade to fail. Has anyone run into thise and found a solution? Frank From carlopmart at gmail.com Wed Dec 18 18:05:17 2013 From: carlopmart at gmail.com (C. L. Martinez) Date: Wed, 18 Dec 2013 18:05:17 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 Message-ID: Hi all, It is time to migrate my home NAS server (an old Pentium host) to a new brand server. I am thinking to use a similar server like Microserver Gen8. Searching in this mailing lists I see some threads about problems with this type of server. Any hardware recommendation?? I prefer to use HP or Lenovo boxes than to buy every component, but I accept all type of suggestions. Thanks. From tom.robinson at motec.com.au Wed Dec 18 22:35:35 2013 From: tom.robinson at motec.com.au (Tom Robinson) Date: Thu, 19 Dec 2013 09:35:35 +1100 Subject: [OmniOS-discuss] st driver issue with blocksize > 1MiB In-Reply-To: <52B12E59.1060808@motec.com.au> References: <52B12E59.1060808@motec.com.au> Message-ID: <52B22337.3010404@motec.com.au> Anyone have a clue? On 18/12/13 16:10, Tom Robinson wrote: > OmniOS v11 r151006 > st driver > sgen driver > > Hi, > > I'm having issues with the st driver accepting writes to tape with a block size larger than 1MiB > where it previously did write 2MiB blocks. > > Previously I had written to the tape using a blocksize of 2MiB (using amanda software command > 'amtapetype'): > $ amtapetype -f -b 2048k -t ULT3580-TD5 weekly /dev/rmt/0bn > Checking for FSF_AFTER_FILEMARK requirement > device-property "FSF_AFTER_FILEMARK" "false" > Applying heuristic check for compression. > Wrote random (uncompressible) data at 87839727.2131148 bytes/sec > Wrote fixed (compressible) data at 282011755.789474 bytes/sec > Compression: enabled > Writing one file to fill the volume. > Wrote 1519520841728 bytes at 86133 kb/sec > Writing smaller files (15193866240 bytes) to determine filemark. > define tapetype ULT3580-TD5 { > comment "Created by amtapetype; compression enabled" > length 1483907072 kbytes > filemark 1820 kbytes > speed 86133 kps > blocksize 2048 kbytes > } > # LEOM is not supported for this drive and kernel > > I have since rebooted a few times but the tape unit always appeared to be available as mt and mtx > worked apparently without error. > # mt config > "IBM ULT3580-TD5", "IBM ULT3580-TD5 ", "CFGIBMULT3580TD5"; > CFGIBMULT3580TD5 = 2,0x3B,0,0x1018619,4,0x46,0x46,0x58,0x58,3,60,1500,600,16920,780,780,16380; > # mt status > IBM ULT3580-TD5 tape drive: > sense key(0x0)= No Additional Sense residual= 0 retries= 0 > file no= 0 block no= 0 > > Now, I tried to determine the block size on the tape using dd and got this: > dd if=/dev/rmt/0bn bs=1024K count=1 of=/dev/null > 0+1 records in > 0+1 records out > 32768 bytes (33 kB) copied, 0.0103029 s, 3.2 MB/s > > That is, the block is 32KiB (told to read 1MiB, got 32KiB) > > But that tape was written with 2MiB blocks! I powered off, then on the tape unit and got this: > dd if=/dev/rmt/0bn bs=1024K count=1 of=/dev/null > 0+1 records in > 0+1 records out > 1047552 bytes (1.0 MB) copied, 0.0172134 s, 60.9 MB/s > > That is the block is at least 1MiB, ask for 1MiB, got 1MiB. > > If I read one more byte, I get a kernel error > > dd if=/dev/rmt/0b bs=1048577 count=1 of=/dev/null > dd: reading '/dev/rmt/0b': Invalid argument > 0+0 records in > 0+0 records out > 0 bytes (0 B) copied, 0.00532612 s, 0.0 kB/s > > (see /var/adm/messages) > Dec 18 15:09:50 monza.motec.com.au scsi: [ID 107833 kern.notice] > /pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/tape at w5000e11156304003,0 (st5): > Dec 18 15:09:50 monza.motec.com.au Read Write scsi_init_pkt() failure > Dec 18 15:09:50 monza.motec.com.au scsi: [ID 107833 kern.warning] WARNING: > /pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/tape at w5000e11156304003,0 (st5): > Dec 18 15:09:50 monza.motec.com.au errors after pkt alloc (b_flags=0x2200065, b_error=0x16) > > Is this a driver issue? Does st5 mean LUN 5? > > grep -e '\' -e '\' /etc/path_to_inst > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/tape at w5000e11156304003,0" 2 "st" > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/medium-changer at w5000e11156304003,1" 3 "st" > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/medium-changer at w5000e11156304003,1" 1 "sgen" > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/tape at w5000e11156304002,0" 4 "st" > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0/medium-changer at w5000e11156304002,1" 3 "sgen" > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/tape at w5000e11156304002,0" 0 "st" > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/medium-changer at w5000e11156304002,1" 1 "st" > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/medium-changer at w5000e11156304002,1" 0 "sgen" > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/tape at w5000e11156304003,0" 5 "st" > "/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f/medium-changer at w5000e11156304003,1" 2 "sgen" > > # iostat -En rmt/0 rmt/1 > rmt/1 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 > Vendor: IBM Product: ULT3580-TD5 Revision: B6W0 Serial No: > rmt/0 Soft Errors: 4 Hard Errors: 0 Transport Errors: 11 > Vendor: IBM Product: ULT3580-TD5 Revision: B6W0 Serial No: > > > BTW, the tape unit is configured through a backplane onto an LSI SAS 9207-8i which also has SSD > connected to it. Is this going to cause the issues I'm seeing? > > cfgadm -av > ---8<--- > Ap_Id Receptacle Occupant Condition Information > When Type Busy Phys_Id > c1 connected configured unknown > unavailable scsi-sas n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi > c1::dsk/c1t5000A72A30086BBDd0 connected configured unknown STEC ZeusRAM > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A30086BBDd0 > c1::dsk/c1t5000A72A300893E9d0 connected configured unknown STEC S842E200M2 > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A300893E9d0 > c1::dsk/c1t5000A72A300893EBd0 connected configured unknown STEC S842E200M2 > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A300893EBd0 > c1::dsk/c1t5000A72A300893EDd0 connected configured unknown STEC S842E200M2 > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A300893EDd0 > c1::dsk/c1t5000A72A300893F1d0 connected configured unknown STEC S842E200M2 > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::dsk/c1t5000A72A300893F1d0 > c1::es/ses0 connected configured unknown LSI SAS2X28 > unavailable ESI n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::es/ses0 > c1::rmt/0 connected configured unknown IBM ULT3580-TD5 > unavailable tape n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::rmt/0 > c1::scsi/changer/c1t5000E1115 connected configured unknown IBM 3573-TL > unavailable med-changer n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::scsi/changer/c1t5000E11156304003d1 > c1::smp/expd0 connected configured unknown LSI SAS2X28 > unavailable smp n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f:scsi::smp/expd0 > c2 connected configured unknown > unavailable scsi-sas n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi > c2::dsk/c2t5000A72B30086BBDd0 connected configured unknown STEC ZeusRAM > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B30086BBDd0 > c2::dsk/c2t5000A72B300893E9d0 connected configured unknown STEC S842E200M2 > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B300893E9d0 > c2::dsk/c2t5000A72B300893EBd0 connected configured unknown STEC S842E200M2 > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B300893EBd0 > c2::dsk/c2t5000A72B300893EDd0 connected configured unknown STEC S842E200M2 > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B300893EDd0 > c2::dsk/c2t5000A72B300893F1d0 connected configured unknown STEC S842E200M2 > unavailable disk n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::dsk/c2t5000A72B300893F1d0 > c2::es/ses1 connected configured unknown LSI SAS2X28 > unavailable ESI n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::es/ses1 > c2::rmt/1 connected configured unknown IBM ULT3580-TD5 > unavailable tape n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::rmt/1 > c2::scsi/changer/c2t5000E1115 connected configured unknown IBM 3573-TL > unavailable med-changer n > /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::scsi/changer/c2t5000E11156304002d1 > c2::smp/expd1 connected configured unknown LSI SAS2X28 > unavailable smp n /devices/pci at 0,0/pci8086,3c0a at 3,2/pci1000,3020 at 0/iport at f0:scsi::smp/expd1 > ---8<--- > > Any help is appreciated. > > Kind regards, > Tom > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From jimklimov at cos.ru Thu Dec 19 09:24:51 2013 From: jimklimov at cos.ru (jimklimov at cos.ru) Date: Thu, 19 Dec 2013 13:24:51 +0400 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 Message-ID: I've recently coordinated a maxed-out build of Gen7 N54L Microserver (my brother bought and assembled the parts) with 2*8gb ecc ram. Its main advantage is the ODD bay where you can mount 2.5" cradles for up to 6 small disks - laptop sized hdds or ssds, so that your big 3.5" disks are used only for the data pool. We went with raidz1 to maximize space (4*4tb hdds), but if you are not too constrained in this regard, raid10 should be better for reliability, efficiency and performance.? Also, our build ultimately connected all disk bays to an 8-port (2*4-port fanout cables) LSI card. Make sure to use half-height short cards, our first bet did not fit ;) Performance is not quite stellar due to the cpu, but decent. The SSDs (iirc mirrored Seagate 600 Pro with powerloss protection, at 120gb formatted to only use 100gb, for rpool and l2arc for metadata, zil is configured but stays empty) do rock :) So while we looked at hacking another bios as many users do to gain better control of the mobo sata ports, we had no reason to risk this so far - these ports are not currently used at all. Typos courtesy of my Samsung Mobile -------- ???????? ????????? -------- ??: "C. L. Martinez" ????: 2013.12.18 22:05 (GMT+04:00) ????: omnios-discuss at lists.omniti.com ????: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 Hi all, It is time to migrate my home NAS server (an old Pentium host) to a new brand server. I am thinking to use a similar server like Microserver Gen8. Searching in this mailing lists I see some threads about problems with this type of server. Any hardware recommendation?? I prefer to use HP or Lenovo boxes than to buy every component, but I accept all type of suggestions. 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: From carlopmart at gmail.com Fri Dec 20 07:54:48 2013 From: carlopmart at gmail.com (C. L. Martinez) Date: Fri, 20 Dec 2013 07:54:48 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: Message-ID: On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez wrote: > Thanks jimklimov, but my idea is not to use a microserver box due to > problems with SATA disks in AHCI mode under Gen8 series ... And Gen7 > is too slowly machines ... > > On Thu, Dec 19, 2013 at 9:24 AM, jimklimov at cos.ru wrote: >> I've recently coordinated a maxed-out build of Gen7 N54L Microserver (my >> brother bought and assembled the parts) with 2*8gb ecc ram. Its main >> advantage is the ODD bay where you can mount 2.5" cradles for up to 6 small >> disks - laptop sized hdds or ssds, so that your big 3.5" disks are used only >> for the data pool. We went with raidz1 to maximize space (4*4tb hdds), but >> if you are not too constrained in this regard, raid10 should be better for >> reliability, efficiency and performance. >> >> Also, our build ultimately connected all disk bays to an 8-port (2*4-port >> fanout cables) LSI card. Make sure to use half-height short cards, our first >> bet did not fit ;) >> >> Performance is not quite stellar due to the cpu, but decent. The SSDs (iirc >> mirrored Seagate 600 Pro with powerloss protection, at 120gb formatted to >> only use 100gb, for rpool and l2arc for metadata, zil is configured but >> stays empty) do rock :) >> >> So while we looked at hacking another bios as many users do to gain better >> control of the mobo sata ports, we had no reason to risk this so far - these >> ports are not currently used at all. >> >> Typos courtesy of my Samsung Mobile >> >> >> -------- ???????? ????????? -------- >> ??: "C. L. Martinez" >> ????: 2013.12.18 22:05 (GMT+04:00) >> ????: omnios-discuss at lists.omniti.com >> ????: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 >> >> >> Hi all, >> >> It is time to migrate my home NAS server (an old Pentium host) to a >> new brand server. I am thinking to use a similar server like >> Microserver Gen8. Searching in this mailing lists I see some threads >> about problems with this type of server. >> >> Any hardware recommendation?? I prefer to use HP or Lenovo boxes than >> to buy every component, but I accept all type of suggestions. >> Please any more inputs?? From natxo.asenjo at gmail.com Fri Dec 20 10:35:21 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 20 Dec 2013 11:35:21 +0100 Subject: [OmniOS-discuss] zoneadm -z zone attach -u fails In-Reply-To: <20131213162641.GE5178@eschaton.local> References: <20131213162641.GE5178@eschaton.local> Message-ID: On Fri, Dec 13, 2013 at 5:26 PM, Chris Nehren wrote: > On Fri, Dec 13, 2013 at 16:52:31 +0100, Natxo Asenjo wrote: >> hi, >> >> Following the update I needed to update my only non-global zone as >> well but this is the result: >> >> # /usr/sbin/zoneadm -z zone1 attach -u >> Log File: /var/tmp/zone1.attach_log.X6ai9c >> Attach Path: /tank/zones/zone1/root >> Attach ZFS Dataset: tank/zones/zone1/ROOT/zbe-1 >> >> Installing: Using pre-existing data in zonepath >> Result: Attach Failed. >> >> And in the log: >> >> [Fri Dec 13 16:38:35 CET 2013] Log File: /var/tmp/zone1.attach_log.X6ai9c >> [Fri Dec 13 16:38:38 CET 2013] Attach Path: >> /tank/zones/zone1/root >> [Fri Dec 13 16:38:38 CET 2013] Attach ZFS Dataset: >> tank/zones/zone1/ROOT/zbe-1 >> >> [Fri Dec 13 16:38:38 CET 2013] existing >> [Fri Dec 13 16:38:38 CET 2013] Installing: Using >> pre-existing data in zonepath >> [Fri Dec 13 16:38:38 CET 2013] Sanity Check: Passed. Looks like an >> OpenSolaris system. >> Unable to get preferred publisher information for zone 'global'. >> brand-specific usage: attach [-a archive] [-d dataset] [-n] [-r zfs-recv] [-u] >> The -a archive option specifies a tar file or cpio archive. >> The -d dataset option specifies an existing dataset. >> The -r zfs-recv option receives the output of a 'zfs send' command >> of an existing zone root dataset. >> The -u option indicates that the software should be updated to match >> the current host. >> [Fri Dec 13 16:38:43 CET 2013] Result: Attach Failed. >> >> Any clues? > > This is an issue that we're looking into fixing. It looks like > the zone attach script is expecting output that isn't there, or > output in another format. More to come when we know more. Is there a tracker where one can follow the status of omnios issues like this one? So people do not have to ask on the list what the status of bugs/issues are ;-) -- groet, natxo From slefevre at indy.rr.com Fri Dec 20 12:59:41 2013 From: slefevre at indy.rr.com (Scott LeFevre) Date: Fri, 20 Dec 2013 07:59:41 -0500 Subject: [OmniOS-discuss] How to install OminOS as a BE on an existing OI box? Message-ID: <1387544381.562.0.camel@exilis.si-consulting.us> I have an existing OI storage box that I want to upgrade to OmniOS. I've spent a fair amount of time fine tuning this system as well as adding services via SMF so I'd rather not start from scratch. What would be the best way to install OmniOS as a BE on the existing rpool and then merge the configs? In reading through the wiki, it appears that using kayak might be an option. I skimmed the list archive but didn't find anything on this. I'm open to all suggestions. Thanks, -Scott -- Scott LeFevre 317-696-1010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus at omniti.com Fri Dec 20 13:29:40 2013 From: jesus at omniti.com (Theo Schlossnagle) Date: Fri, 20 Dec 2013 08:29:40 -0500 Subject: [OmniOS-discuss] zoneadm -z zone attach -u fails In-Reply-To: References: <20131213162641.GE5178@eschaton.local> Message-ID: OmniOS specific issues are here http://omnios.omniti.com/report.php/4 More general Illumos issues are here https://www.illumos.org/projects/illumos-gate/issues On Fri, Dec 20, 2013 at 5:35 AM, Natxo Asenjo wrote: > On Fri, Dec 13, 2013 at 5:26 PM, Chris Nehren > wrote: > > On Fri, Dec 13, 2013 at 16:52:31 +0100, Natxo Asenjo wrote: > >> hi, > >> > >> Following the update I needed to update my only non-global zone as > >> well but this is the result: > >> > >> # /usr/sbin/zoneadm -z zone1 attach -u > >> Log File: /var/tmp/zone1.attach_log.X6ai9c > >> Attach Path: /tank/zones/zone1/root > >> Attach ZFS Dataset: tank/zones/zone1/ROOT/zbe-1 > >> > >> Installing: Using pre-existing data in zonepath > >> Result: Attach Failed. > >> > >> And in the log: > >> > >> [Fri Dec 13 16:38:35 CET 2013] Log File: > /var/tmp/zone1.attach_log.X6ai9c > >> [Fri Dec 13 16:38:38 CET 2013] Attach Path: > >> /tank/zones/zone1/root > >> [Fri Dec 13 16:38:38 CET 2013] Attach ZFS Dataset: > >> tank/zones/zone1/ROOT/zbe-1 > >> > >> [Fri Dec 13 16:38:38 CET 2013] existing > >> [Fri Dec 13 16:38:38 CET 2013] Installing: Using > >> pre-existing data in zonepath > >> [Fri Dec 13 16:38:38 CET 2013] Sanity Check: Passed. Looks like an > >> OpenSolaris system. > >> Unable to get preferred publisher information for zone 'global'. > >> brand-specific usage: attach [-a archive] [-d dataset] [-n] [-r > zfs-recv] [-u] > >> The -a archive option specifies a tar file or cpio archive. > >> The -d dataset option specifies an existing dataset. > >> The -r zfs-recv option receives the output of a 'zfs send' > command > >> of an existing zone root dataset. > >> The -u option indicates that the software should be updated to > match > >> the current host. > >> [Fri Dec 13 16:38:43 CET 2013] Result: Attach > Failed. > >> > >> Any clues? > > > > This is an issue that we're looking into fixing. It looks like > > the zone attach script is expecting output that isn't there, or > > output in another format. More to come when we know more. > > Is there a tracker where one can follow the status of omnios issues > like this one? So people do not have to ask on the list what the > status of bugs/issues are ;-) > > -- > groet, > natxo > _______________________________________________ > 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: From jesus at omniti.com Fri Dec 20 13:37:38 2013 From: jesus at omniti.com (Theo Schlossnagle) Date: Fri, 20 Dec 2013 08:37:38 -0500 Subject: [OmniOS-discuss] Upgrade path In-Reply-To: <20131217203102.43e38f99@sleipner.datanom.net> References: <20131217203102.43e38f99@sleipner.datanom.net> Message-ID: On Tue, Dec 17, 2013 at 2:31 PM, Michael Rasmussen wrote: > I am currently on r151008 and my intention is to move to the LTS track > as of r151014. My question is whether this upgrade path will be > supported: > > r151008 -> r151010 -> r151014 > > or do I require to follow the full path > > r151008 -> r151010 -> r151012 -> r151014 > This is an interesting question. We make effort to make upgrades work between each subsequent normal release: 8->10->12->14, we'll also invest in making the upgrades work between LTSs 6->14. Given that, 8->14 isn't specifically on that list... As 14 approaches, we'll better understand if we get the non-LTS -> LTS skips for free due to the LTS -> LTS effort. Given the nuances of systems and packaging, my guess is: no. -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.kragsterman at capvert.se Fri Dec 20 13:50:07 2013 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Fri, 20 Dec 2013 14:50:07 +0100 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: , Message-ID: Sorry, forgot the list: Well, this depends a lot of what you're going to use it for... If you're concerned about performance, or if you're concerned about how much space you need, or both or neither... I would buy a second hand HP DL380 G6 for performance needs, or a DL180 G6 for space needs. If you would want both perfermance and space, I'd buy a DL380 G6 and an expansion jbod, perhaps HP MSA60 if you like HP gear. In this way you will get much more for your buck. Rgrds Johan -----"OmniOS-discuss" skrev: ----- Till: omnios-discuss at lists.omniti.com Fr?n: "C. L. Martinez" S?nt av: "OmniOS-discuss" Datum: 2013-12-20 08:56 ?rende: Re: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez wrote: > Thanks jimklimov, but my idea is not to use a microserver box due to > problems with SATA disks in AHCI mode under Gen8 series ... And Gen7 > is too slowly machines ... > > On Thu, Dec 19, 2013 at 9:24 AM, jimklimov at cos.ru wrote: >> I've recently coordinated a maxed-out build of Gen7 N54L Microserver (my >> brother bought and assembled the parts) with 2*8gb ecc ram. Its main >> advantage is the ODD bay where you can mount 2.5" cradles for up to 6 small >> disks - laptop sized hdds or ssds, so that your big 3.5" disks are used only >> for the data pool. We went with raidz1 to maximize space (4*4tb hdds), but >> if you are not too constrained in this regard, raid10 should be better for >> reliability, efficiency and performance. >> >> Also, our build ultimately connected all disk bays to an 8-port (2*4-port >> fanout cables) LSI card. Make sure to use half-height short cards, our first >> bet did not fit ;) >> >> Performance is not quite stellar due to the cpu, but decent. The SSDs (iirc >> mirrored Seagate 600 Pro with powerloss protection, at 120gb formatted to >> only use 100gb, for rpool and l2arc for metadata, zil is configured but >> stays empty) do rock :) >> >> So while we looked at hacking another bios as many users do to gain better >> control of the mobo sata ports, we had no reason to risk this so far - these >> ports are not currently used at all. >> >> Typos courtesy of my Samsung Mobile >> >> >> -------- Исходное сообщение -------- >> От: "C. L. Martinez" >> Дата: 2013.12.18 22:05 (GMT+04:00) >> Кому: omnios-discuss at lists.omniti.com >> Тема: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 >> >> >> Hi all, >> >> It is time to migrate my home NAS server (an old Pentium host) to a >> new brand server. I am thinking to use a similar server like >> Microserver Gen8. Searching in this mailing lists I see some threads >> about problems with this type of server. >> >> Any hardware recommendation?? I prefer to use HP or Lenovo boxes than >> to buy every component, but I accept all type of suggestions. >> Please any more inputs?? _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From carlopmart at gmail.com Fri Dec 20 14:19:22 2013 From: carlopmart at gmail.com (C. L. Martinez) Date: Fri, 20 Dec 2013 14:19:22 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: Message-ID: On Fri, Dec 20, 2013 at 1:50 PM, Johan Kragsterman wrote: > Sorry, forgot the list: > > Well, this depends a lot of what you're going to use it for... > > If you're concerned about performance, or if you're concerned about how much space you need, or both or neither... > > I would buy a second hand HP DL380 G6 for performance needs, or a DL180 G6 for space needs. > > If you would want both perfermance and space, I'd buy a DL380 G6 and an expansion jbod, perhaps HP MSA60 if you like HP gear. > > In this way you will get much more for your buck. > > Rgrds Johan > Thanks Johan .. but it is for home use :)) Rack server could not be the best idea ...:) From johan.kragsterman at capvert.se Fri Dec 20 14:33:50 2013 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Fri, 20 Dec 2013 15:33:50 +0100 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: , Message-ID: What's the differens? A rack server you can hang, lean, stand up, upside down, whatever. doesn't matter, place it anywhere, anyhow. Doesn't need to be in a rack! And the noice from a DL380 G6 is really low now, compared to G4/5 models. You could of coarse by a ML350 G6, but I you get much better prices on DL-series. Compare what you buy a new Microserver G8 for with e second hand DL380/DL180 G6... Rgrds Johan -----"OmniOS-discuss" skrev: ----- Till: omnios-discuss at lists.omniti.com Fr?n: "C. L. Martinez" S?nt av: "OmniOS-discuss" Datum: 2013-12-20 15:20 ?rende: Re: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 On Fri, Dec 20, 2013 at 1:50 PM, Johan Kragsterman wrote: > Sorry, forgot the list: > > Well, this depends a lot of what you're going to use it for... > > If you're concerned about performance, or if you're concerned about how much space you need, or both or neither... > > I would buy a second hand HP DL380 G6 for performance needs, or a DL180 G6 for space needs. > > If you would want both perfermance and space, I'd buy a DL380 G6 and an expansion jbod, perhaps HP MSA60 if you like HP gear. > > In this way you will get much more for your buck. > > Rgrds Johan > Thanks Johan .. but it is for home use :)) Rack server could not be the best idea ...:) _______________________________________________ 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 Dec 20 14:44:50 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Fri, 20 Dec 2013 14:44:50 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: , Message-ID: <52B457E2.9020003@gmail.com> On 12/20/13, 1:50 PM, Johan Kragsterman wrote: > Sorry, forgot the list: > > Well, this depends a lot of what you're going to use it for... > > If you're concerned about performance, or if you're concerned about how much space you need, or both or neither... > > I would buy a second hand HP DL380 G6 for performance needs, or a DL180 G6 for space needs. > > If you would want both perfermance and space, I'd buy a DL380 G6 and an expansion jbod, perhaps HP MSA60 if you like HP gear. > > In this way you will get much more for your buck. And you get the added benefit of watching your electricity meter turn into a blower as it spins itself to death and eats your wallet in the process. By a quick first-degree approximation a server drawing 250W 24x7x365 will set you back about $300 a year - that's more than the cost of a brand new HP MicroServer. By comparison, an HP MicroServer's draw is more in the 25-35W region. Cheers, -- Saso From skiselkov.ml at gmail.com Fri Dec 20 14:53:14 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Fri, 20 Dec 2013 14:53:14 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: Message-ID: <52B459DA.7030501@gmail.com> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez wrote: > Thanks jimklimov, but my idea is not to use a microserver box due to > problems with SATA disks in AHCI mode under Gen8 series ... And Gen7 > is too slowly machines ... Gen7 too slow for you? Didn't you say you're doing a home NAS? Don't underestimate the venerable MicroServer, it's plenty fast enough to saturate its Gigabit NIC, even while transparently compressing: https://www.illumos.org/attachments/822/lz4_compression_bench.ods (This is a set of ZFS LZ4 compression benchmarks I ran on my old Gen6 MicroServer box, so a Gen7 is even faster than this.) Unless you're doing some serious compute or web serving I wouldn't worry about it. It's only 25W TDP, so you won't break the bank running the thing 24x7 at home, and it's multi-core and has HVM and ECC memory support. Cheers, -- Saso From carlopmart at gmail.com Fri Dec 20 15:22:58 2013 From: carlopmart at gmail.com (C. L. Martinez) Date: Fri, 20 Dec 2013 15:22:58 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <52B459DA.7030501@gmail.com> References: <52B459DA.7030501@gmail.com> Message-ID: On Fri, Dec 20, 2013 at 2:53 PM, Saso Kiselkov wrote: > On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez > wrote: >> Thanks jimklimov, but my idea is not to use a microserver box due to >> problems with SATA disks in AHCI mode under Gen8 series ... And Gen7 >> is too slowly machines ... > > Gen7 too slow for you? Didn't you say you're doing a home NAS? Don't > underestimate the venerable MicroServer, it's plenty fast enough to > saturate its Gigabit NIC, even while transparently compressing: > https://www.illumos.org/attachments/822/lz4_compression_bench.ods > (This is a set of ZFS LZ4 compression benchmarks I ran on my old Gen6 > MicroServer box, so a Gen7 is even faster than this.) > > Unless you're doing some serious compute or web serving I wouldn't worry > about it. It's only 25W TDP, so you won't break the bank running the > thing 24x7 at home, and it's multi-core and has HVM and ECC memory support. > > Cheers, > -- > Saso Thanks Saso ... I have discarded Microserver N56L due to the reports provided by people in their blogs about poor performance with AMD cpu using it with ZFS (most of them with FreeNAS). But, if I buy a Microserver N56L, do I need to buy some additonal storage adapter or it is ok with the default?? From carlopmart at gmail.com Fri Dec 20 15:24:37 2013 From: carlopmart at gmail.com (C. L. Martinez) Date: Fri, 20 Dec 2013 15:24:37 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: <52B459DA.7030501@gmail.com> Message-ID: On Fri, Dec 20, 2013 at 3:22 PM, C. L. Martinez wrote: > On Fri, Dec 20, 2013 at 2:53 PM, Saso Kiselkov wrote: >> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez >> wrote: >>> Thanks jimklimov, but my idea is not to use a microserver box due to >>> problems with SATA disks in AHCI mode under Gen8 series ... And Gen7 >>> is too slowly machines ... >> >> Gen7 too slow for you? Didn't you say you're doing a home NAS? Don't >> underestimate the venerable MicroServer, it's plenty fast enough to >> saturate its Gigabit NIC, even while transparently compressing: >> https://www.illumos.org/attachments/822/lz4_compression_bench.ods >> (This is a set of ZFS LZ4 compression benchmarks I ran on my old Gen6 >> MicroServer box, so a Gen7 is even faster than this.) >> >> Unless you're doing some serious compute or web serving I wouldn't worry >> about it. It's only 25W TDP, so you won't break the bank running the >> thing 24x7 at home, and it's multi-core and has HVM and ECC memory support. >> >> Cheers, >> -- >> Saso > > Thanks Saso ... I have discarded Microserver N56L due to the reports > provided by people in their blogs about poor performance with AMD cpu > using it with ZFS (most of them with FreeNAS). > > But, if I buy a Microserver N56L, do I need to buy some additonal > storage adapter or it is ok with the default?? And another point, I need to use this NAS with OmniOS to serve iscsi disks for one KVM host (CentOS). From skiselkov.ml at gmail.com Fri Dec 20 15:36:41 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Fri, 20 Dec 2013 15:36:41 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: <52B459DA.7030501@gmail.com> Message-ID: <52B46409.8010106@gmail.com> On 12/20/13, 3:22 PM, C. L. Martinez wrote: > On Fri, Dec 20, 2013 at 2:53 PM, Saso Kiselkov wrote: >> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez >> wrote: >>> Thanks jimklimov, but my idea is not to use a microserver box due to >>> problems with SATA disks in AHCI mode under Gen8 series ... And Gen7 >>> is too slowly machines ... >> >> Gen7 too slow for you? Didn't you say you're doing a home NAS? Don't >> underestimate the venerable MicroServer, it's plenty fast enough to >> saturate its Gigabit NIC, even while transparently compressing: >> https://www.illumos.org/attachments/822/lz4_compression_bench.ods >> (This is a set of ZFS LZ4 compression benchmarks I ran on my old Gen6 >> MicroServer box, so a Gen7 is even faster than this.) >> >> Unless you're doing some serious compute or web serving I wouldn't worry >> about it. It's only 25W TDP, so you won't break the bank running the >> thing 24x7 at home, and it's multi-core and has HVM and ECC memory support. >> >> Cheers, >> -- >> Saso > > Thanks Saso ... I have discarded Microserver N56L due to the reports > provided by people in their blogs about poor performance with AMD cpu > using it with ZFS (most of them with FreeNAS). That's strange. Can you point me to these reviews? Sure it's not fast enough to do a full Illumos nightly build on the spot, but it's plenty fast enough for serving files and even standard web server usage (been toying with the idea of replacing some old power-hungry clunkers with it). > But, if I buy a Microserver N56L, do I need to buy some additonal > storage adapter or it is ok with the default?? Never had any trouble with the on-board AHCI one, though you may want to reflash the BIOS if you want to use the 5th SATA port in AHCI mode. If you plan on using SAS drives, you can just get an OEM-branded LSI card (they're much cheaper than buying LSI-original ones, despite having the same components: http://accessories.euro.dell.com/sna/productdetail.aspx?c=uk&l=en&s=bsd&sku=405-11540 ) and just replug the SFF-8087 multi-link drive-bay connector from the motherboard into your HBA. Alternatively and if you're going for some really crazy deployments, I've used an external micro-JBOD (http://www.amazon.co.uk/Icy-Box-IB-545SSK-5-Bay-Channel/dp/B006BQYSFA) with two MicroServers talking to it over external LSI HBAs (http://accessories.euro.dell.com/sna/productdetail.aspx?c=uk&l=en&s=bsd&cs=ukbsdt1&sku=405-11482&ref=2531xC) > And another point, I need to use this NAS with OmniOS to serve iscsi > disks for one KVM host (CentOS). Just use the COMSTAR iSCSI target as usual. Cheers, -- Saso From tobi at oetiker.ch Sat Dec 21 13:15:40 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Sat, 21 Dec 2013 14:15:40 +0100 (CET) Subject: [OmniOS-discuss] background snapshot destruction impact Message-ID: I am running omnios r151008 on a recent box with 3gig SAS disks arranged in a raidz2 pool. I have this 7TB filesystem where I have my zimbra server store its backups. The backup-sets are highly redundant, so for a time I had deduplication turned on to great effect, but as the size of the backup-sets grew, I ran out of ram and performance on the system became realy bad. So I turned deduplication of. Performance for newly written data is fine again. The other day, I destroyed a bunch of old snapshots on this filesysem. Thanks to background destruction this did not realy take a long time. But now as background destruction is progressing, the system remains very slugish when doing io on the pool where the destruction is taking place. I put up some graphs and raw data on http://tobi.oetiker.ch/background-destruction/ to show the state of things. My Questions: a) would it be faster to send/receive the content of the deduplicated filesystem to a new non deduplicated and then destroy the entire filesystem (not the pool). b) is there a way to monitor progress on the background destruction? c) shouldn't the smarter write throttle change https://github.com/illumos/illumos-gate/commit/69962b5647e4a8b9b14998733b765925381b727e have helped with this by makeing zfs do its internal things with a lower priority. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From fwp at deepthought.com Sat Dec 21 19:47:36 2013 From: fwp at deepthought.com (Frank Pittel) Date: Sat, 21 Dec 2013 13:47:36 -0600 Subject: [OmniOS-discuss] Problem upgrading In-Reply-To: <20131218094818.GB21469@warlock.deepthought.com> References: <20131218094818.GB21469@warlock.deepthought.com> Message-ID: <20131221194735.GD21469@warlock.deepthought.com> I don't like to reply to my own posts but I think that an update is in order. Yesterday I posted my issue on the omnios IRC channel asking for assistance and got immediate assistance from a number of the people there. As it turns out I had a number of packages that I installed from the "ms.omniti" repository and that was intergering with the upgrade. I removed those packages and the upgrade proceeded without issue. I should mention that I'm not using omnios on the job but at home as a home server. Using zones I've been able to replace 7 linux machines with a single omnios machine. Interestingly enough the single machine not only much more stable (OS not hardware) it performs better than the 7 individual machines. Thanks again to all that assisted with getting the machine upgraded! Frank On Wed, Dec 18, 2013 at 03:48:19AM -0600, Frank Pittel wrote: > I've been trying to upgrade my omnios installation from r151006 to r151008 since r151008 was released without any luck. I've been following the instructions to the letter and don't actually get > any errors during the process. During the "upgrade" about 3MB of something gets installed and after rebooting running pkg update completely fails. I've captured the steps I took during the > "upgrade": > > root at omni1:~# kg update package/pkg at 0.5.11,5.11-0.151006:20130731T192303Z web/ca-bundle at 5.11,5.11-0.151006:20130718T173831Z > -bash: kg: command not found > root at omni1:~# pkg update package/pkg at 0.5.11,5.11-0.151006:20130731T192303Z web/ca-bundle at 5.11,5.11-0.151006:20130718T173831Z > No updates available for this image. > root at omni1:~# pkg list incorporation/jeos/omnios-userland >/dev/null 2>&1 || pkg install incorporation/jeos/omnios-userland at 11,5.11-0.151006 > root at omni1:~# pkg update runtime/perl/manual at 5.16.1,5.11-0.151006 > No updates available for this image. > root at omni1:~# pkg list runtime/perl-64 >/dev/null 2>&1 && pkg update runtime/perl-64 at 5.16.1,5.11-0.151006 > root at omni1:~# /usr/bin/pkg update --be-name=omnios-r151008 > Packages to update: 3 > Create boot environment: Yes > Create backup boot environment: No > > DOWNLOAD PKGS FILES XFER (MB) > Completed 3/3 38/38 3.0/3.0 > > PHASE ACTIONS > Install Phase 3/3 > Update Phase 45/45 > > PHASE ITEMS > Package State Update Phase 6/6 > Package Cache Update Phase 3/3 > Image State Update Phase 2/2 > > PHASE ITEMS > Reading Existing Index 8/8 > Indexing Packages 3/3 > > A clone of omnios-3 exists and has been updated and activated. > On the next boot the Boot Environment omnios-r151008 will be > mounted on '/'. Reboot when ready to switch to this updated BE. > > > --------------------------------------------------------------------------- > NOTE: Please review release notes posted at: > > > http://omnios.omniti.com/ReleaseNotes > --------------------------------------------------------------------------- > > Figuring something wasn't right I tried running "pkg update after rebooting and got the following mess: > > root at omni1:~# 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.151008:20131204T022427Z > pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z > pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z > pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z > > The following indicates why the system cannot update to the latest version: > > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z found: > Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T191259Z > Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z found: > Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T223747Z > Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z found: > Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131205T195253Z > Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z found: > Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131204T231613Z > Reason: A version for 'incorporate' dependency on pkg:/system/library/pcap at 1.3.0,5.11-0.151008 cannot be found > > > > I'm sure I'm doing something wrong but have no idea of what that may be. I haven't built any zones yet and am wondering if the only way for me to get this upgrade to work is to reinstall. I see > that others were able to perform the upgrade so I'm sure it's something I did wrong at sometime which is causing the upgrade to fail. Has anyone run into thise and found a solution? > > Frank > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From tobi at oetiker.ch Sun Dec 22 23:17:00 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 23 Dec 2013 00:17:00 +0100 (CET) Subject: [OmniOS-discuss] arcstat and vfsstat and r151008 Message-ID: I just noticed that vfsstat and arcstat seem to have gone from SUNWcs in r151008 there were quite useful ... cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From richard.elling at richardelling.com Mon Dec 23 00:03:17 2013 From: richard.elling at richardelling.com (Richard Elling) Date: Sun, 22 Dec 2013 16:03:17 -0800 Subject: [OmniOS-discuss] [discuss] background snapshot destruction impact In-Reply-To: References: Message-ID: <2F7ACA02-1109-4A4B-8F77-7357B475E5A3@richardelling.com> Hi Tobias, comments below? On Dec 21, 2013, at 5:15 AM, Tobias Oetiker wrote: > I am running omnios r151008 on a recent box with 3gig SAS disks > arranged in a raidz2 pool. > > I have this 7TB filesystem where I have my zimbra server store its > backups. The backup-sets are highly redundant, so for a time I had > deduplication turned on to great effect, but as the size of the > backup-sets grew, I ran out of ram and performance on the system > became realy bad. So I turned deduplication of. Performance for > newly written data is fine again. > > The other day, I destroyed a bunch of old snapshots on this > filesysem. Thanks to background destruction this did not realy take > a long time. But now as background destruction is progressing, the > system remains very slugish when doing io on the pool where > the destruction is taking place. > > I put up some graphs and raw data on > > http://tobi.oetiker.ch/background-destruction/ > > to show the state of things. > > My Questions: > > a) would it be faster to send/receive the content of the > deduplicated filesystem to a new non deduplicated > and then destroy the entire filesystem (not the pool). > > b) is there a way to monitor progress on the background > destruction? > > c) shouldn't the smarter write throttle change > https://github.com/illumos/illumos-gate/commit/69962b5647e4a8b9b14998733b765925381b727e > have helped with this by makeing zfs do its internal things > with a lower priority. Yes, but the default zfs_vdev_max_pending remains at 10. Once the I/Os are sent to disk, there is no priority scheduling. You should consider lowering zfs_vdev_max_pending to allow the ZIO scheduler to do a better job of rescheduling the more important I/Os. ? richard > > cheers > tobi > > > -- > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland > http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 > > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175743-23d1427b > Modify Your Subscription: https://www.listbox.com/member/?member_id=21175743&id_secret=21175743-81b50b6e > Powered by Listbox: http://www.listbox.com From tobi at oetiker.ch Mon Dec 23 00:23:42 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 23 Dec 2013 01:23:42 +0100 (CET) Subject: [OmniOS-discuss] [discuss] background snapshot destruction impact In-Reply-To: <2F7ACA02-1109-4A4B-8F77-7357B475E5A3@richardelling.com> References: <2F7ACA02-1109-4A4B-8F77-7357B475E5A3@richardelling.com> Message-ID: Hi Richard, Yesterday Richard Elling wrote: > > c) shouldn't the smarter write throttle change > > https://github.com/illumos/illumos-gate/commit/69962b5647e4a8b9b14998733b765925381b727e > > have helped with this by makeing zfs do its internal things > > with a lower priority. > > Yes, but the default zfs_vdev_max_pending remains at 10. Once > the I/Os are sent to disk, there is no priority scheduling. You > should consider lowering zfs_vdev_max_pending to allow the ZIO > scheduler to do a better job of rescheduling the more important > I/Os. the patch mentioned introduces a ton of new tuneables but it removes zfs_vdev_max_pending cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From sriram at belenix.org Mon Dec 23 01:15:21 2013 From: sriram at belenix.org (Sriram Narayanan) Date: Mon, 23 Dec 2013 06:45:21 +0530 Subject: [OmniOS-discuss] Any OmniOS hosting recommendations? Message-ID: Hi folks: Could anyone recommend a hosting that are OmniOS-friendly? I'm looking for: - A Physical server that will run OmniOS as a build server. - Have ECC RAM - Have the ability for me to either connect via IPKVM or other to diagnose boot up time issues. -- Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoffn at gnaa.net Mon Dec 23 05:23:04 2013 From: geoffn at gnaa.net (Geoff Nordli) Date: Sun, 22 Dec 2013 21:23:04 -0800 Subject: [OmniOS-discuss] Any OmniOS hosting recommendations? In-Reply-To: References: Message-ID: <52B7C8B8.1050503@gnaa.net> On 13-12-22 05:15 PM, Sriram Narayanan wrote: > Hi folks: > > Could anyone recommend a hosting that are OmniOS-friendly? > > I'm looking for: > - A Physical server that will run OmniOS as a build server. > - Have ECC RAM > - Have the ability for me to either connect via IPKVM or other to > diagnose boot up time issues. > It would be good to have something on the wiki with companies offering omnios hosting. I am looking for private cloud type of hosting with Omnios as the storage server on a private LAN with large ram based linux servers. Geoff From richard.elling at richardelling.com Mon Dec 23 06:55:45 2013 From: richard.elling at richardelling.com (Richard Elling) Date: Sun, 22 Dec 2013 22:55:45 -0800 Subject: [OmniOS-discuss] [discuss] background snapshot destruction impact In-Reply-To: References: <2F7ACA02-1109-4A4B-8F77-7357B475E5A3@richardelling.com> Message-ID: <2D67EFA5-C4B7-4556-B1CA-5906EAEEDA22@richardelling.com> On Dec 22, 2013, at 4:23 PM, Tobias Oetiker wrote: > Hi Richard, > > Yesterday Richard Elling wrote: > >>> c) shouldn't the smarter write throttle change >>> https://github.com/illumos/illumos-gate/commit/69962b5647e4a8b9b14998733b765925381b727e >>> have helped with this by makeing zfs do its internal things >>> with a lower priority. >> >> Yes, but the default zfs_vdev_max_pending remains at 10. Once >> the I/Os are sent to disk, there is no priority scheduling. You >> should consider lowering zfs_vdev_max_pending to allow the ZIO >> scheduler to do a better job of rescheduling the more important >> I/Os. > > the patch mentioned introduces a ton of new tuneables but it > removes zfs_vdev_max_pending Indeed, these are now zfs_vdev_max_active and friends. It is very unclear to me what your graphite is attempting to show. Is this data from the pool itself, or from vdevs under the pool? The pool-level stats are mostly useless for this analysis, need to see the per-vdev stats. ? richard From tobi at oetiker.ch Mon Dec 23 07:56:58 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 23 Dec 2013 08:56:58 +0100 (CET) Subject: [OmniOS-discuss] [discuss] background snapshot destruction impact In-Reply-To: <2D67EFA5-C4B7-4556-B1CA-5906EAEEDA22@richardelling.com> References: <2F7ACA02-1109-4A4B-8F77-7357B475E5A3@richardelling.com> <2D67EFA5-C4B7-4556-B1CA-5906EAEEDA22@richardelling.com> Message-ID: Hi Richard, Yesterday Richard Elling wrote: > On Dec 22, 2013, at 4:23 PM, Tobias Oetiker wrote: > > > Hi Richard, > > > > Yesterday Richard Elling wrote: > > > >>> c) shouldn't the smarter write throttle change > >>> https://github.com/illumos/illumos-gate/commit/69962b5647e4a8b9b14998733b765925381b727e > >>> have helped with this by makeing zfs do its internal things > >>> with a lower priority. > >> > >> Yes, but the default zfs_vdev_max_pending remains at 10. Once > >> the I/Os are sent to disk, there is no priority scheduling. You > >> should consider lowering zfs_vdev_max_pending to allow the ZIO > >> scheduler to do a better job of rescheduling the more important > >> I/Os. > > > > the patch mentioned introduces a ton of new tuneables but it > > removes zfs_vdev_max_pending > > Indeed, these are now zfs_vdev_max_active and friends. > It is very unclear to me what your graphite is attempting to show. > Is this data from the pool itself, or from vdevs under the pool? > The pool-level stats are mostly useless for this analysis, need to > see the per-vdev stats. the reason I am interested in this is that while the removal operation is active, all data access to data not already in ARC this is very slow ... 'ls' in a directory with 10 entries takes several seconds to complete. iostat -xnd 10 returns lines like this: extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 85.3 265.1 350.4 3280.5 22.4 0.9 63.8 2.5 6 8 fast 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 rpool 0.0 0.2 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t5001517BB2AD9526d0 0.0 0.2 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t5001517BB2AD9589d0 0.0 92.8 0.0 1205.7 0.0 0.0 0.0 0.1 0 1 c0t5001517803D28EA3d0 0.6 331.8 0.4 789.1 0.0 1.4 0.0 4.2 0 99 c24t5000CCA03E45E11Dd0 11.1 25.6 49.9 302.8 0.0 0.1 0.0 3.2 0 5 c20t50014EE700052642d0 0.3 394.6 0.2 919.5 0.0 1.2 0.0 3.1 0 99 c25t5000CCA03E45E25Dd0 10.5 24.4 43.4 302.4 0.0 0.1 0.0 3.2 0 5 c19t50014EE70005217Ed0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c29t5000CCA03E404FDDd0 12.0 23.8 42.5 301.2 0.0 0.1 0.0 3.4 0 5 c15t50014EE70005248Ed0 0.4 427.3 0.3 960.5 0.0 1.7 0.0 3.9 0 99 c28t5000CCA03E426985d0 9.2 24.3 45.5 302.1 0.0 0.1 0.0 3.2 0 5 c18t50014EE7AAAFCC0Ad0 0.6 380.2 0.5 1061.0 0.0 1.8 0.0 4.6 0 99 c22t5000CCA03E45E211d0 11.1 24.8 49.1 301.2 0.0 0.1 0.0 3.0 0 5 c14t50014EE7555A792Ed0 0.4 330.6 0.3 800.3 0.0 1.3 0.0 3.9 0 99 c26t5000CCA03E420D4Dd0 10.4 24.7 35.8 302.7 0.0 0.1 0.0 2.6 0 4 c17t50014EE7555A7B7Ad0 0.6 371.7 0.5 901.7 0.0 1.2 0.0 3.1 0 99 c23t5000CCA03E434C41d0 10.4 27.3 52.0 302.1 0.0 0.1 0.0 3.1 0 5 c13t50014EE700052386d0 0.3 347.4 0.3 766.9 0.0 1.7 0.0 4.8 0 100 c27t5000CCA03E4229ADd0 10.6 24.2 32.3 301.3 0.0 0.1 0.0 2.8 0 5 c16t50014EE7555A7B4Ad0 3.2 2607.4 2.3 6539.9 3610203.4 10.2 1382912.3 3.9 100 100 slow the config of the pool is this: NAME STATE READ WRITE CKSUM slowpool ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 c22t5000CCA03E45E211d0 ONLINE 0 0 0 c23t5000CCA03E434C41d0 ONLINE 0 0 0 c24t5000CCA03E45E11Dd0 ONLINE 0 0 0 c25t5000CCA03E45E25Dd0 ONLINE 0 0 0 c26t5000CCA03E420D4Dd0 ONLINE 0 0 0 c27t5000CCA03E4229ADd0 ONLINE 0 0 0 c28t5000CCA03E426985d0 ONLINE 0 0 0 logs mirror-1 ONLINE 0 0 0 c0t5001517BB2AD9526d0s3 ONLINE 0 0 0 c0t5001517BB2AD9589d0s3 ONLINE 0 0 0 cache c0t5001517803D28EA3d0s1 ONLINE 0 0 0 spares c29t5000CCA03E404FDDd0 AVAIL > ? richard > > > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182180/25228367-6b1cb39c > Modify Your Subscription: https://www.listbox.com/member/?member_id=25228367&id_secret=25228367-5c415042 > Powered by Listbox: http://www.listbox.com > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From carlopmart at gmail.com Mon Dec 23 11:30:50 2013 From: carlopmart at gmail.com (C. L. Martinez) Date: Mon, 23 Dec 2013 11:30:50 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <52B46409.8010106@gmail.com> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> Message-ID: On Fri, Dec 20, 2013 at 3:36 PM, Saso Kiselkov wrote: > On 12/20/13, 3:22 PM, C. L. Martinez wrote: >> On Fri, Dec 20, 2013 at 2:53 PM, Saso Kiselkov wrote: >>> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez >>> wrote: >>>> Thanks jimklimov, but my idea is not to use a microserver box due to >>>> problems with SATA disks in AHCI mode under Gen8 series ... And Gen7 >>>> is too slowly machines ... >>> >>> Gen7 too slow for you? Didn't you say you're doing a home NAS? Don't >>> underestimate the venerable MicroServer, it's plenty fast enough to >>> saturate its Gigabit NIC, even while transparently compressing: >>> https://www.illumos.org/attachments/822/lz4_compression_bench.ods >>> (This is a set of ZFS LZ4 compression benchmarks I ran on my old Gen6 >>> MicroServer box, so a Gen7 is even faster than this.) >>> >>> Unless you're doing some serious compute or web serving I wouldn't worry >>> about it. It's only 25W TDP, so you won't break the bank running the >>> thing 24x7 at home, and it's multi-core and has HVM and ECC memory support. >>> >>> Cheers, >>> -- >>> Saso >> >> Thanks Saso ... I have discarded Microserver N56L due to the reports >> provided by people in their blogs about poor performance with AMD cpu >> using it with ZFS (most of them with FreeNAS). > > That's strange. Can you point me to these reviews? Sure it's not fast > enough to do a full Illumos nightly build on the spot, but it's plenty > fast enough for serving files and even standard web server usage (been > toying with the idea of replacing some old power-hungry clunkers with it). > >> But, if I buy a Microserver N56L, do I need to buy some additonal >> storage adapter or it is ok with the default?? > > Never had any trouble with the on-board AHCI one, though you may want to > reflash the BIOS if you want to use the 5th SATA port in AHCI mode. If > you plan on using SAS drives, you can just get an OEM-branded LSI card > (they're much cheaper than buying LSI-original ones, despite having the > same components: > http://accessories.euro.dell.com/sna/productdetail.aspx?c=uk&l=en&s=bsd&sku=405-11540 > ) and just replug the SFF-8087 multi-link drive-bay connector from the > motherboard into your HBA. Alternatively and if you're going for some > really crazy deployments, I've used an external micro-JBOD > (http://www.amazon.co.uk/Icy-Box-IB-545SSK-5-Bay-Channel/dp/B006BQYSFA) > with two MicroServers talking to it over external LSI HBAs > (http://accessories.euro.dell.com/sna/productdetail.aspx?c=uk&l=en&s=bsd&cs=ukbsdt1&sku=405-11482&ref=2531xC) > >> And another point, I need to use this NAS with OmniOS to serve iscsi >> disks for one KVM host (CentOS). > I will add Microserver to my basket, but any more hardware recommendations for OmniOS?? From skiselkov.ml at gmail.com Mon Dec 23 11:37:18 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 23 Dec 2013 11:37:18 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> Message-ID: <52B8206E.1050806@gmail.com> On 12/23/13, 11:30 AM, C. L. Martinez wrote: > On Fri, Dec 20, 2013 at 3:36 PM, Saso Kiselkov wrote: >> On 12/20/13, 3:22 PM, C. L. Martinez wrote: >>> On Fri, Dec 20, 2013 at 2:53 PM, Saso Kiselkov wrote: >>>> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez >>>> wrote: >>>>> Thanks jimklimov, but my idea is not to use a microserver box due to >>>>> problems with SATA disks in AHCI mode under Gen8 series ... And Gen7 >>>>> is too slowly machines ... >>>> >>>> Gen7 too slow for you? Didn't you say you're doing a home NAS? Don't >>>> underestimate the venerable MicroServer, it's plenty fast enough to >>>> saturate its Gigabit NIC, even while transparently compressing: >>>> https://www.illumos.org/attachments/822/lz4_compression_bench.ods >>>> (This is a set of ZFS LZ4 compression benchmarks I ran on my old Gen6 >>>> MicroServer box, so a Gen7 is even faster than this.) >>>> >>>> Unless you're doing some serious compute or web serving I wouldn't worry >>>> about it. It's only 25W TDP, so you won't break the bank running the >>>> thing 24x7 at home, and it's multi-core and has HVM and ECC memory support. >>>> >>>> Cheers, >>>> -- >>>> Saso >>> >>> Thanks Saso ... I have discarded Microserver N56L due to the reports >>> provided by people in their blogs about poor performance with AMD cpu >>> using it with ZFS (most of them with FreeNAS). >> >> That's strange. Can you point me to these reviews? Sure it's not fast >> enough to do a full Illumos nightly build on the spot, but it's plenty >> fast enough for serving files and even standard web server usage (been >> toying with the idea of replacing some old power-hungry clunkers with it). >> >>> But, if I buy a Microserver N56L, do I need to buy some additonal >>> storage adapter or it is ok with the default?? >> >> Never had any trouble with the on-board AHCI one, though you may want to >> reflash the BIOS if you want to use the 5th SATA port in AHCI mode. If >> you plan on using SAS drives, you can just get an OEM-branded LSI card >> (they're much cheaper than buying LSI-original ones, despite having the >> same components: >> http://accessories.euro.dell.com/sna/productdetail.aspx?c=uk&l=en&s=bsd&sku=405-11540 >> ) and just replug the SFF-8087 multi-link drive-bay connector from the >> motherboard into your HBA. Alternatively and if you're going for some >> really crazy deployments, I've used an external micro-JBOD >> (http://www.amazon.co.uk/Icy-Box-IB-545SSK-5-Bay-Channel/dp/B006BQYSFA) >> with two MicroServers talking to it over external LSI HBAs >> (http://accessories.euro.dell.com/sna/productdetail.aspx?c=uk&l=en&s=bsd&cs=ukbsdt1&sku=405-11482&ref=2531xC) >> >>> And another point, I need to use this NAS with OmniOS to serve iscsi >>> disks for one KVM host (CentOS). >> > > I will add Microserver to my basket, but any more hardware > recommendations for OmniOS?? I'm quite fond of WD Red drives. They are just marginally more expensive than your el-cheapo home drive, but are built for 8760 on hours per year (24x7) and are capable for throttling down to 5400rpm when not in use (so they suck less power). WD markets them as designed for use in NAS. I've got 4 of these in my MicroServer and I've never had any issues with them. Cheers, -- Saso From mir at miras.org Mon Dec 23 12:09:52 2013 From: mir at miras.org (Michael Rasmussen) Date: Mon, 23 Dec 2013 13:09:52 +0100 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> Message-ID: <20131223130952.5a07244d@sleipner.datanom.net> On Mon, 23 Dec 2013 11:30:50 +0000 "C. L. Martinez" wrote: > > I will add Microserver to my basket, but any more hardware > recommendations for OmniOS?? > _______________________________________________ While we are at it. Have somebody tried this motherboard? http://www.asrock.com/server/overview.asp?Model=C2750D4I -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Ain't nothin' an old man can do for me but bring me a message from a young man. -- Moms Mabley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From skiselkov.ml at gmail.com Mon Dec 23 12:26:47 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 23 Dec 2013 12:26:47 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <20131223130952.5a07244d@sleipner.datanom.net> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <20131223130952.5a07244d@sleipner.datanom.net> Message-ID: <52B82C07.2030305@gmail.com> On 12/23/13, 12:09 PM, Michael Rasmussen wrote: > On Mon, 23 Dec 2013 11:30:50 +0000 > "C. L. Martinez" wrote: > >> >> I will add Microserver to my basket, but any more hardware >> recommendations for OmniOS?? >> _______________________________________________ > While we are at it. Have somebody tried this motherboard? > http://www.asrock.com/server/overview.asp?Model=C2750D4I That's one damn sweet looking piece of hardware, though it's probably going to cost more than the entire HP MicroServer (seeing as the CPU by itself is $171 MSRP). Still, it looks like one kick-ass toy to play with. -- Saso From gc at birzan.org Mon Dec 23 13:00:07 2013 From: gc at birzan.org (=?ISO-8859-1?Q?George=2DCristian_B=EErzan?=) Date: Mon, 23 Dec 2013 15:00:07 +0200 Subject: [OmniOS-discuss] background snapshot destruction impact In-Reply-To: References: Message-ID: On Sat, Dec 21, 2013 at 3:15 PM, Tobias Oetiker wrote: > a) would it be faster to send/receive the content of the > deduplicated filesystem to a new non deduplicated > and then destroy the entire filesystem (not the pool). > > Destroying the entire dataset directly won't help, if anything, it'll just prolong the agony. If you want a controlled 'deletion', you can zero the current version of it (delete files individually and whatnot), then revert to the previous snapshot, repeat until there are no snapshots. > b) is there a way to monitor progress on the background > destruction? > > zpool get freeing pool will list how much is left. -- George-Cristian B?rzan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Mon Dec 23 13:35:40 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 23 Dec 2013 14:35:40 +0100 (CET) Subject: [OmniOS-discuss] background snapshot destruction impact In-Reply-To: References: Message-ID: Today George-Cristian B?rzan wrote: > On Sat, Dec 21, 2013 at 3:15 PM, Tobias Oetiker wrote: > > > a) would it be faster to send/receive the content of the > > deduplicated filesystem to a new non deduplicated > > and then destroy the entire filesystem (not the pool). > > > > > Destroying the entire dataset directly won't help, if anything, it'll just > prolong the agony. If you want a controlled 'deletion', you can zero the > current version of it (delete files individually and whatnot), then revert > to the previous snapshot, repeat until there are no snapshots. so I did it anyway ... :-) and it took roughtly 13 hours to destroy 10TB two things to note: a) monitoring the change in values reported from queing zpool get freeing pool repeatedly it seemd that the freeing was sort of a linear process ... I expected it to last 60 hours. But at least in my case the process spead up 20 fold after about 11 hours ... this may coincide with the point in time where I had turned of deduplication on the dataset. b) also after 11 hours, the server crashed. It's last words were Dec 23 11:01:36 fugu genunix: [ID 843051 kern.info] NOTICE: SUNW-MSG-ID: SUNOS-8000-0G, TYPE: Error, VER: 1, SEVERITY: Major Dec 23 11:01:36 fugu unix: [ID 836849 kern.notice] Dec 23 11:01:36 fugu ^Mpanic[cpu0]/thread=ffffff00f40c5c40: Dec 23 11:01:36 fugu genunix: [ID 918906 kern.notice] I/O to pool 'slow' appears to be hung. Dec 23 11:01:36 fugu unix: [ID 100000 kern.notice] Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f40c5a20 zfs:vdev_deadman+10b () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f40c5a70 zfs:vdev_deadman+4a () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f40c5ac0 zfs:vdev_deadman+4a () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f40c5af0 zfs:spa_deadman+ad () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f40c5b90 genunix:cyclic_softint+f3 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f40c5ba0 unix:cbe_low_level+14 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f40c5bf0 unix:av_dispatch_softvect+78 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f40c5c20 unix:dispatch_softint+39 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb27d0 unix:switch_sp_and_call+13 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2810 unix:dosoftint+44 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2870 unix:do_interrupt+ba () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2880 unix:cmnint+ba () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb29d0 unix:mutex_enter+10 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2a00 unix:page_destroy+70 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2a40 genunix:fs_dispose+32 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2ac0 genunix:swap_dispose+a9 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2b50 genunix:fop_dispose+91 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2b90 genunix:anon_decref+13f () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2c00 genunix:anon_free+74 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2c50 genunix:segvn_free+242 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2c80 genunix:seg_free+30 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2d60 genunix:segvn_unmap+cde () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2dc0 genunix:as_free+e7 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2df0 genunix:relvm+220 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2e80 genunix:proc_exit+454 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2ea0 genunix:exit+15 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2ec0 genunix:rexit+18 () Dec 23 11:01:36 fugu genunix: [ID 655072 kern.notice] ffffff00f7bb2f10 unix:brand_sys_sysenter+1c9 () Dec 23 11:01:36 fugu unix: [ID 100000 kern.notice] Dec 23 11:01:36 fugu genunix: [ID 672855 kern.notice] syncing file systems... Dec 23 11:01:38 fugu genunix: [ID 904073 kern.notice] done Dec 23 11:01:39 fugu genunix: [ID 111219 kern.notice] dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel Dec 23 11:05:35 fugu genunix: [ID 100000 kern.notice] Dec 23 11:05:35 fugu genunix: [ID 665016 kern.notice] ^M 26% done: 3709201 pages dumped, Dec 23 11:05:35 fugu genunix: [ID 495082 kern.notice] dump failed: error 28 as you can see the dump did not succeed: savecore -vf vmdump.0 savecore: incomplete dump on dump device savecore: System dump time: Mon Dec 23 11:01:39 2013 savecore: saving system crash dump in /var/crash/unknown/{unix,vmcore}.0 Constructing namelist /var/crash/unknown/unix.0 Constructing corefile /var/crash/unknown/vmcore.0 pfn 32542208 not found for as=fffffffffbc30ac0, va=ffffff0000000000 pfn 32542209 not found for as=fffffffffbc30ac0, va=ffffff0000001000 pfn 32542210 not found for as=fffffffffbc30ac0, va=ffffff0000002000 pfn 32542211 not found for as=fffffffffbc30ac0, va=ffffff0000003000 pfn 32542212 not found for as=fffffffffbc30ac0, va=ffffff0000004000 pfn 32542213 not found for as=fffffffffbc30ac0, va=ffffff0000005000 pfn 32542214 not found for as=fffffffffbc30ac0, va=ffffff0000006000 pfn 32542215 not found for as=fffffffffbc30ac0, va=ffffff0000007000 pfn 32542216 not found for as=fffffffffbc30ac0, va=ffffff0000008000 pfn 32542217 not found for as=fffffffffbc30ac0, va=ffffff0000009000 1:36 99% donesavecore: stream tag 1862 not in range 1..1 savecore: bad summary magic 62063c2c it then came back up and completed the job without a hitch, picking up pace very quickly. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From smd at mis.use.net Sat Dec 21 23:20:08 2013 From: smd at mis.use.net (Sean Doran) Date: Sat, 21 Dec 2013 23:20:08 +0000 Subject: [OmniOS-discuss] background snapshot destruction impact In-Reply-To: References: Message-ID: <08986B7D-3B60-456B-A364-EE21ACF05869@mis.use.net> On 21 Dec, 2013, at 13:15, Tobias Oetiker wrote: > But now as background destruction is progressing, the > system remains very slugish when doing io on the pool where > the destruction is taking place. Each dataset block to be freed requires an update to the deduplication data table, so will involve several reads from and writes to the pool. > a) would it be faster to send/receive the content of the > deduplicated filesystem to a new non deduplicated > and then destroy the entire filesystem (not the pool). Destroying the pool would be faster, yes, but destroying a zfs dataset still requires visiting the deduplication data linked within it. > b) is there a way to monitor progress on the background > destruction? zpool get freeing poolname > c) shouldn't the smarter write throttle change > https://github.com/illumos/illumos-gate/commit/69962b5647e4a8b9b14998733b765925381b727e > have helped with this by makeing zfs do its internal things > with a lower priority. It does. things are much worse on pools without it; not only would you need more patience, so would anything else hoping to get IOPS to and from of the pool. Finally, a really big L2ARC for the pool helps, although it takes a while to heat up. Even hundreds of gigabytes of properly USB 3 keys will make a palpable difference, as the deduplication data is spread into a table with many many blocks which get visited and revisited in an effectively unpredictable fashion. L2ARC compression is great for DDT data - I've seen approaching half a terabyte on a 128 GiB vdev. Persisting that across reboots will make lots of people happier and make deduplication and snapshot removal (and other write-intensive jobs) less time-consuming. Sean. From mir at miras.org Mon Dec 23 14:30:58 2013 From: mir at miras.org (Michael Rasmussen) Date: Mon, 23 Dec 2013 15:30:58 +0100 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <52B82C07.2030305@gmail.com> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <20131223130952.5a07244d@sleipner.datanom.net> <52B82C07.2030305@gmail.com> Message-ID: <20131223153058.70a24936@sleipner.datanom.net> On Mon, 23 Dec 2013 12:26:47 +0000 Saso Kiselkov wrote: > > That's one damn sweet looking piece of hardware, though it's probably > going to cost more than the entire HP MicroServer (seeing as the CPU by > itself is $171 MSRP). Still, it looks like one kick-ass toy to play with. > On Newegg it is listed for a price of: $392.99 http://www.newegg.com/Product/Product.aspx?Item=N82E16813157475 Combining the individual components on the board it seems like a fair price. There is also a quad core (otherwise same specs) available for the price of: $289.99 http://www.asrock.com/server/overview.asp?Model=C2550D4I -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Football is a game designed to keep coalminers off the streets. -- Jimmy Breslin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From esproul at omniti.com Mon Dec 23 14:35:27 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 23 Dec 2013 09:35:27 -0500 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <52B82C07.2030305@gmail.com> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <20131223130952.5a07244d@sleipner.datanom.net> <52B82C07.2030305@gmail.com> Message-ID: On Mon, Dec 23, 2013 at 7:26 AM, Saso Kiselkov wrote: > On 12/23/13, 12:09 PM, Michael Rasmussen wrote: >> On Mon, 23 Dec 2013 11:30:50 +0000 >> "C. L. Martinez" wrote: >> >>> >>> I will add Microserver to my basket, but any more hardware >>> recommendations for OmniOS?? >>> _______________________________________________ >> While we are at it. Have somebody tried this motherboard? >> http://www.asrock.com/server/overview.asp?Model=C2750D4I > > That's one damn sweet looking piece of hardware, though it's probably > going to cost more than the entire HP MicroServer (seeing as the CPU by > itself is $171 MSRP). Still, it looks like one kick-ass toy to play with. The Marvell SATA ports probably won't work, but you'll presumably still have 6 from the Intel controller, if ahci(7D) will attach. Eric From mir at miras.org Mon Dec 23 14:36:15 2013 From: mir at miras.org (Michael Rasmussen) Date: Mon, 23 Dec 2013 15:36:15 +0100 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <52B82C07.2030305@gmail.com> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <20131223130952.5a07244d@sleipner.datanom.net> <52B82C07.2030305@gmail.com> Message-ID: <20131223153615.63f021ed@sleipner.datanom.net> On Mon, 23 Dec 2013 12:26:47 +0000 Saso Kiselkov wrote: > > That's one damn sweet looking piece of hardware, though it's probably > going to cost more than the entire HP MicroServer (seeing as the CPU by > itself is $171 MSRP). Still, it looks like one kick-ass toy to play with. > Quad core available in Germany for ?259 http://www.servershop-bayern.de/index.php?page=product&info=9583 Amazon.co.uk for ?267 http://www.amazon.co.uk/C2550D4I-ASROCK-MOTHERBOARD-MINI-ITX-FCBGA1283/dp/B00GG94YDS servethehome.com has a review: http://www.servethehome.com/Server-detail/asrock-c2750d4i-atom-c2750-storage-platform-review/ -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Yow! Maybe I should have asked for my Neutron Bomb in PAISLEY -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From skiselkov.ml at gmail.com Mon Dec 23 14:41:44 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 23 Dec 2013 14:41:44 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <20131223130952.5a07244d@sleipner.datanom.net> <52B82C07.2030305@gmail.com> Message-ID: <52B84BA8.3030508@gmail.com> On 12/23/13, 2:35 PM, Eric Sproul wrote: > On Mon, Dec 23, 2013 at 7:26 AM, Saso Kiselkov wrote: >> On 12/23/13, 12:09 PM, Michael Rasmussen wrote: >>> On Mon, 23 Dec 2013 11:30:50 +0000 >>> "C. L. Martinez" wrote: >>> >>>> >>>> I will add Microserver to my basket, but any more hardware >>>> recommendations for OmniOS?? >>>> _______________________________________________ >>> While we are at it. Have somebody tried this motherboard? >>> http://www.asrock.com/server/overview.asp?Model=C2750D4I >> >> That's one damn sweet looking piece of hardware, though it's probably >> going to cost more than the entire HP MicroServer (seeing as the CPU by >> itself is $171 MSRP). Still, it looks like one kick-ass toy to play with. > > The Marvell SATA ports probably won't work, but you'll presumably > still have 6 from the Intel controller, if ahci(7D) will attach. Don't worry, I didn't plan on buying it, though by the looks of it, it would make a formidable home/SOHO server if you need something with more oomph than a MicroServer. -- Saso From skiselkov.ml at gmail.com Mon Dec 23 14:45:11 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 23 Dec 2013 14:45:11 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <20131223153058.70a24936@sleipner.datanom.net> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <20131223130952.5a07244d@sleipner.datanom.net> <52B82C07.2030305@gmail.com> <20131223153058.70a24936@sleipner.datanom.net> Message-ID: <52B84C77.50306@gmail.com> On 12/23/13, 2:30 PM, Michael Rasmussen wrote: > On Mon, 23 Dec 2013 12:26:47 +0000 > Saso Kiselkov wrote: > >> >> That's one damn sweet looking piece of hardware, though it's probably >> going to cost more than the entire HP MicroServer (seeing as the CPU by >> itself is $171 MSRP). Still, it looks like one kick-ass toy to play with. >> > On Newegg it is listed for a price of: $392.99 > http://www.newegg.com/Product/Product.aspx?Item=N82E16813157475 > > Combining the individual components on the board it seems like a fair > price. > > There is also a quad core (otherwise same specs) available for the price > of: $289.99 > http://www.asrock.com/server/overview.asp?Model=C2550D4I Well, a brand new Gen 7 MicroServer, with case, CPU, PSU and basic equipment (2GB RAM, 1 250GB HDD) will set you back about $280-290: http://www.amazon.co.uk/gp/aag/main/ref=olp_merch_name_3?ie=UTF8&asin=B00AHQUX86&isAmazonFulfilled=0&seller=A2JOOGMTVUOES But you get what you pay for. That Asrock board has a lot more horsepower and if that's what you need, go for it. Ultimately it really comes down to choosing the right tool for the job. The MicroServer works for me. -- Saso From skiselkov.ml at gmail.com Mon Dec 23 14:49:19 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 23 Dec 2013 14:49:19 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <20131223153615.63f021ed@sleipner.datanom.net> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <20131223130952.5a07244d@sleipner.datanom.net> <52B82C07.2030305@gmail.com> <20131223153615.63f021ed@sleipner.datanom.net> Message-ID: <52B84D6F.8030206@gmail.com> On 12/23/13, 2:36 PM, Michael Rasmussen wrote: > On Mon, 23 Dec 2013 12:26:47 +0000 > Saso Kiselkov wrote: > >> >> That's one damn sweet looking piece of hardware, though it's probably >> going to cost more than the entire HP MicroServer (seeing as the CPU by >> itself is $171 MSRP). Still, it looks like one kick-ass toy to play with. >> > Quad core available in Germany for ?259 > http://www.servershop-bayern.de/index.php?page=product&info=9583 > Amazon.co.uk for ?267 > http://www.amazon.co.uk/C2550D4I-ASROCK-MOTHERBOARD-MINI-ITX-FCBGA1283/dp/B00GG94YDS > > servethehome.com has a review: > http://www.servethehome.com/Server-detail/asrock-c2750d4i-atom-c2750-storage-platform-review/ Well, if I were in the market looking for a new home server build (which I'm not, at least not yet), the deal breaker for me would not be so much the price, as the presence of fully-featured IPKVM with remote media. That would enable me to freely experiment with new ZFS development without having to worry about getting my machine into a non-bootable state (especially when I'm thousands of miles away from it). I can definitely see a market for this board. Cheers, -- Saso From geoffn at gnaa.net Mon Dec 23 20:07:18 2013 From: geoffn at gnaa.net (Geoff Nordli) Date: Mon, 23 Dec 2013 12:07:18 -0800 Subject: [OmniOS-discuss] r151008 stmf crash Message-ID: <52B897F6.3090600@gnaa.net> I am not very well versed in this area, but I have the core dump from the crash. I can upload it if someone wants to take a more detailed look. Here is what I have so far: /usr/bin/mdb -k unix.0 vmcore.0 Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc apix scsi_vhci zfs mpt_sas sd ip hook neti sockfs arp usba stmf stmf_sbd md lofs random idm smbsrv nfs cpc kvm crypto ufs logindmux ptm nsmb ] > ::status debugging crash dump vmcore.0 (64-bit) from stor2 operating system: 5.11 omnios-6de5e81 (i86pc) image uuid: 1be881fe-834b-c1dd-b5ec-f528b9d6f1f9 panic message: BAD TRAP: type=e (#pf Page fault) rp=ffffff007a4908d0 addr=8 occurred in module "stmf" due to a NULL pointer dereference dump content: kernel pages only > ::stack stmf_remove_lu_from_session+0x7c(ffffff11586f3920, ffffff116f40e1b8, ffffff1169658580, ffffff11801698b8) stmf_update_sessions_per_ve+0x118(ffffff1180169888, ffffff1169658580, 0) stmf_session_lu_unmapall+0x55(ffffff1169658580) stmf_svc+0x111(0) taskq_thread+0x2d0(ffffff1157404a08) thread_start+8() > ::msgbuf MESSAGE ISA-device: asy0 asy0 is /pci at 0,0/isa at 1f/asy at 1,3f8 ISA-device: asy1 asy1 is /pci at 0,0/isa at 1f/asy at 1,2f8 pseudo-device: stmf0 stmf0 is /pseudo/stmf at 0 pseudo-device: ucode0 ucode0 is /pseudo/ucode at 0 npe1 at root: space 78 offset 0 npe1 is /pci at 78,0 mpt_sas2 at mpt_sas0: scsi-iport v0 mpt_sas2 is /pci at 0,0/pci8086,3c06 at 2,2/pci15d9,691 at 0/iport at v0 /pci at 0,0/pci8086,3c06 at 2,2/pci15d9,691 at 0/iport at v0 (mpt_sas2) online ISA-device: pit_beep0 pit_beep0 is /pci at 0,0/isa at 1f/pit_beep pseudo-device: pseudo1 pseudo1 is /pseudo/zconsnex at 1 pseudo-device: fct0 fct0 is /pseudo/fct at 0 pseudo-device: dcpc0 dcpc0 is /pseudo/dcpc at 0 pseudo-device: dtrace0 dtrace0 is /pseudo/dtrace at 0 pseudo-device: fasttrap0 fasttrap0 is /pseudo/fasttrap at 0 pseudo-device: fbt0 fbt0 is /pseudo/fbt at 0 pseudo-device: lockstat0 lockstat0 is /pseudo/lockstat at 0 pseudo-device: profile0 profile0 is /pseudo/profile at 0 pseudo-device: sdt0 sdt0 is /pseudo/sdt at 0 pseudo-device: systrace0 systrace0 is /pseudo/systrace at 0 pseudo-device: fcsm0 fcsm0 is /pseudo/fcsm at 0 pseudo-device: kvm0 kvm0 is /pseudo/kvm at 0 pseudo-device: fcp0 fcp0 is /pseudo/fcp at 0 pseudo-device: llc10 llc10 is /pseudo/llc1 at 0 pseudo-device: lofi0 lofi0 is /pseudo/lofi at 0 pseudo-device: ramdisk1024 ramdisk1024 is /pseudo/ramdisk at 1024 pseudo-device: pool0 pool0 is /pseudo/pool at 0 IP Filter: v4.1.9, running. pseudo-device: fssnap0 fssnap0 is /pseudo/fssnap at 0 pseudo-device: nsmb0 nsmb0 is /pseudo/nsmb at 0 pseudo-device: bpf0 bpf0 is /pseudo/bpf at 0 NOTICE: igb0 unregistered NOTICE: ixgbe1 unregistered NOTICE: igb1 unregistered NOTICE: igb2 unregistered NOTICE: igb3 unregistered pseudo-device: stmf0 stmf0 is /pseudo/stmf at 0 pseudo-device: devinfo0 devinfo0 is /pseudo/devinfo at 0 ISA-device: asy0 asy0 is /pci at 0,0/isa at 1f/asy at 1,3f8 ISA-device: asy1 asy1 is /pci at 0,0/isa at 1f/asy at 1,2f8 pseudo-device: fct0 fct0 is /pseudo/fct at 0 pseudo-device: dcpc0 dcpc0 is /pseudo/dcpc at 0 pseudo-device: fbt0 fbt0 is /pseudo/fbt at 0 pseudo-device: lockstat0 lockstat0 is /pseudo/lockstat at 0 pseudo-device: profile0 profile0 is /pseudo/profile at 0 pseudo-device: sdt0 sdt0 is /pseudo/sdt at 0 pseudo-device: systrace0 systrace0 is /pseudo/systrace at 0 pseudo-device: fcsm0 fcsm0 is /pseudo/fcsm at 0 pseudo-device: kvm0 kvm0 is /pseudo/kvm at 0 pseudo-device: fcp0 fcp0 is /pseudo/fcp at 0 NOTICE: igb0 registered NOTICE: igb0: igb 2.3.8-ish smp0 at mpt_sas1: target-port w500304800096a33f smp0 is /pci at 0,0/pci8086,3c06 at 2,2/pci15d9,691 at 0/iport at f/smp at w500304800096a33f sd3 at scsi_vhci0: unit-address g50015178f363f417: f_sym sd3 is /scsi_vhci/disk at g50015178f363f417 pseudo-device: llc10 llc10 is /pseudo/llc1 at 0 pseudo-device: lofi0 lofi0 is /pseudo/lofi at 0 pseudo-device: ramdisk1024 ramdisk1024 is /pseudo/ramdisk at 1024 pseudo-device: ucode0 ucode0 is /pseudo/ucode at 0 pseudo-device: pm0 pm0 is /pseudo/pm at 0 pseudo-device: fssnap0 fssnap0 is /pseudo/fssnap at 0 NOTICE: igb1 registered NOTICE: igb1: igb 2.3.8-ish pseudo-device: nsmb0 nsmb0 is /pseudo/nsmb at 0 pseudo-device: bpf0 bpf0 is /pseudo/bpf at 0 NOTICE: igb2 registered NOTICE: igb2: igb 2.3.8-ish NOTICE: igb3 registered NOTICE: igb3: igb 2.3.8-ish NOTICE: ixgbe1 registered NOTICE: ixgbe1: Intel 10Gb Ethernet, ixgbe 1.1.7 panic[cpu11]/thread=ffffff007a490c40: BAD TRAP: type=e (#pf Page fault) rp=ffffff007a4908d0 addr=8 occurred in module "stmf" due to a NULL pointer dereference sched: #pf Page fault Bad kernel fault at addr=0x8 pid=0, pc=0xfffffffff7df504c, sp=0xffffff007a4909c0, eflags=0x10202 cr0: 8005003b cr4: 426f8 cr2: 8 cr3: bc00000 cr8: 0 rdi: ffffff11696587f0 rsi: ffffffff rdx: 37 rcx: 0 r8: ffffff115799fa80 r9: ffffff007d537c40 rax: 1000000100000000 rbx: ffffff116f40e1b8 rbp: ffffff007a490a20 r10: fffffffffbcf3990 r11: 0 r12: ffffff1169658580 r13: 0 r14: ffffff11801698b8 r15: ffffff19fb7c77d8 fsb: fffffd7fff0b0240 gsb: ffffff11579b6540 ds: 4b es: 4b fs: 0 gs: 0 trp: e err: 0 rip: fffffffff7df504c cs: 30 rfl: 10202 rsp: ffffff007a4909c0 ss: 38 ffffff007a4907b0 unix:die+df () ffffff007a4908c0 unix:trap+db3 () ffffff007a4908d0 unix:cmntrap+e6 () ffffff007a490a20 stmf:stmf_remove_lu_from_session+7c () ffffff007a490ab0 stmf:stmf_update_sessions_per_ve+118 () ffffff007a490af0 stmf:stmf_session_lu_unmapall+55 () ffffff007a490b60 stmf:stmf_svc+111 () ffffff007a490c20 genunix:taskq_thread+2d0 () ffffff007a490c30 unix:thread_start+8 () syncing file systems... done dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel Happy Holidays!! Geoff From geoffn at gnaa.net Tue Dec 24 17:21:31 2013 From: geoffn at gnaa.net (Geoff Nordli) Date: Tue, 24 Dec 2013 09:21:31 -0800 Subject: [OmniOS-discuss] r151008 stmf crash In-Reply-To: <52B897F6.3090600@gnaa.net> References: <52B897F6.3090600@gnaa.net> Message-ID: <52B9C29B.8090808@gnaa.net> I created a bug on the illumos tracker: https://www.illumos.org/issues/4423 On 13-12-23 12:07 PM, Geoff Nordli wrote: > I am not very well versed in this area, but I have the core dump from > the crash. I can upload it if someone wants to take a more detailed > look. > > Here is what I have so far: > > /usr/bin/mdb -k unix.0 vmcore.0 > Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc > apix scsi_vhci zfs mpt_sas sd ip hook neti sockfs arp usba stmf > stmf_sbd md lofs random idm smbsrv nfs cpc kvm crypto ufs logindmux > ptm nsmb ] > > ::status > debugging crash dump vmcore.0 (64-bit) from stor2 > operating system: 5.11 omnios-6de5e81 (i86pc) > image uuid: 1be881fe-834b-c1dd-b5ec-f528b9d6f1f9 > panic message: > BAD TRAP: type=e (#pf Page fault) rp=ffffff007a4908d0 addr=8 occurred > in module "stmf" due to a NULL pointer dereference > dump content: kernel pages only > > > > ::stack > stmf_remove_lu_from_session+0x7c(ffffff11586f3920, ffffff116f40e1b8, > ffffff1169658580, ffffff11801698b8) > stmf_update_sessions_per_ve+0x118(ffffff1180169888, ffffff1169658580, 0) > stmf_session_lu_unmapall+0x55(ffffff1169658580) > stmf_svc+0x111(0) > taskq_thread+0x2d0(ffffff1157404a08) > thread_start+8() > > > > ::msgbuf > MESSAGE > ISA-device: asy0 > asy0 is /pci at 0,0/isa at 1f/asy at 1,3f8 > ISA-device: asy1 > asy1 is /pci at 0,0/isa at 1f/asy at 1,2f8 > pseudo-device: stmf0 > stmf0 is /pseudo/stmf at 0 > pseudo-device: ucode0 > ucode0 is /pseudo/ucode at 0 > npe1 at root: space 78 offset 0 > npe1 is /pci at 78,0 > mpt_sas2 at mpt_sas0: scsi-iport v0 > mpt_sas2 is /pci at 0,0/pci8086,3c06 at 2,2/pci15d9,691 at 0/iport at v0 > /pci at 0,0/pci8086,3c06 at 2,2/pci15d9,691 at 0/iport at v0 (mpt_sas2) online > ISA-device: pit_beep0 > pit_beep0 is /pci at 0,0/isa at 1f/pit_beep > pseudo-device: pseudo1 > pseudo1 is /pseudo/zconsnex at 1 > pseudo-device: fct0 > fct0 is /pseudo/fct at 0 > pseudo-device: dcpc0 > dcpc0 is /pseudo/dcpc at 0 > pseudo-device: dtrace0 > dtrace0 is /pseudo/dtrace at 0 > pseudo-device: fasttrap0 > fasttrap0 is /pseudo/fasttrap at 0 > pseudo-device: fbt0 > fbt0 is /pseudo/fbt at 0 > pseudo-device: lockstat0 > lockstat0 is /pseudo/lockstat at 0 > pseudo-device: profile0 > profile0 is /pseudo/profile at 0 > pseudo-device: sdt0 > sdt0 is /pseudo/sdt at 0 > pseudo-device: systrace0 > systrace0 is /pseudo/systrace at 0 > pseudo-device: fcsm0 > fcsm0 is /pseudo/fcsm at 0 > pseudo-device: kvm0 > kvm0 is /pseudo/kvm at 0 > pseudo-device: fcp0 > fcp0 is /pseudo/fcp at 0 > pseudo-device: llc10 > llc10 is /pseudo/llc1 at 0 > pseudo-device: lofi0 > lofi0 is /pseudo/lofi at 0 > pseudo-device: ramdisk1024 > ramdisk1024 is /pseudo/ramdisk at 1024 > pseudo-device: pool0 > pool0 is /pseudo/pool at 0 > IP Filter: v4.1.9, running. > pseudo-device: fssnap0 > fssnap0 is /pseudo/fssnap at 0 > pseudo-device: nsmb0 > nsmb0 is /pseudo/nsmb at 0 > pseudo-device: bpf0 > bpf0 is /pseudo/bpf at 0 > NOTICE: igb0 unregistered > NOTICE: ixgbe1 unregistered > NOTICE: igb1 unregistered > NOTICE: igb2 unregistered > NOTICE: igb3 unregistered > pseudo-device: stmf0 > stmf0 is /pseudo/stmf at 0 > pseudo-device: devinfo0 > devinfo0 is /pseudo/devinfo at 0 > ISA-device: asy0 > asy0 is /pci at 0,0/isa at 1f/asy at 1,3f8 > ISA-device: asy1 > asy1 is /pci at 0,0/isa at 1f/asy at 1,2f8 > pseudo-device: fct0 > fct0 is /pseudo/fct at 0 > pseudo-device: dcpc0 > dcpc0 is /pseudo/dcpc at 0 > pseudo-device: fbt0 > fbt0 is /pseudo/fbt at 0 > pseudo-device: lockstat0 > lockstat0 is /pseudo/lockstat at 0 > pseudo-device: profile0 > profile0 is /pseudo/profile at 0 > pseudo-device: sdt0 > sdt0 is /pseudo/sdt at 0 > pseudo-device: systrace0 > systrace0 is /pseudo/systrace at 0 > pseudo-device: fcsm0 > fcsm0 is /pseudo/fcsm at 0 > pseudo-device: kvm0 > kvm0 is /pseudo/kvm at 0 > pseudo-device: fcp0 > fcp0 is /pseudo/fcp at 0 > NOTICE: igb0 registered > NOTICE: igb0: igb 2.3.8-ish > smp0 at mpt_sas1: target-port w500304800096a33f > smp0 is > /pci at 0,0/pci8086,3c06 at 2,2/pci15d9,691 at 0/iport at f/smp at w500304800096a33f > sd3 at scsi_vhci0: unit-address g50015178f363f417: f_sym > sd3 is /scsi_vhci/disk at g50015178f363f417 > pseudo-device: llc10 > llc10 is /pseudo/llc1 at 0 > pseudo-device: lofi0 > lofi0 is /pseudo/lofi at 0 > pseudo-device: ramdisk1024 > ramdisk1024 is /pseudo/ramdisk at 1024 > pseudo-device: ucode0 > ucode0 is /pseudo/ucode at 0 > pseudo-device: pm0 > pm0 is /pseudo/pm at 0 > pseudo-device: fssnap0 > fssnap0 is /pseudo/fssnap at 0 > NOTICE: igb1 registered > NOTICE: igb1: igb 2.3.8-ish > pseudo-device: nsmb0 > nsmb0 is /pseudo/nsmb at 0 > pseudo-device: bpf0 > bpf0 is /pseudo/bpf at 0 > NOTICE: igb2 registered > NOTICE: igb2: igb 2.3.8-ish > NOTICE: igb3 registered > NOTICE: igb3: igb 2.3.8-ish > NOTICE: ixgbe1 registered > NOTICE: ixgbe1: Intel 10Gb Ethernet, ixgbe 1.1.7 > > panic[cpu11]/thread=ffffff007a490c40: > BAD TRAP: type=e (#pf Page fault) rp=ffffff007a4908d0 addr=8 occurred > in module "stmf" due to a NULL pointer dereference > > > sched: > #pf Page fault > Bad kernel fault at addr=0x8 > pid=0, pc=0xfffffffff7df504c, sp=0xffffff007a4909c0, eflags=0x10202 > cr0: 8005003b cr4: > 426f8 > cr2: 8 > cr3: bc00000 > cr8: 0 > > rdi: ffffff11696587f0 rsi: ffffffff rdx: 37 > rcx: 0 r8: ffffff115799fa80 r9: ffffff007d537c40 > rax: 1000000100000000 rbx: ffffff116f40e1b8 rbp: ffffff007a490a20 > r10: fffffffffbcf3990 r11: 0 r12: ffffff1169658580 > r13: 0 r14: ffffff11801698b8 r15: ffffff19fb7c77d8 > fsb: fffffd7fff0b0240 gsb: ffffff11579b6540 ds: 4b > es: 4b fs: 0 gs: 0 > trp: e err: 0 rip: fffffffff7df504c > cs: 30 rfl: 10202 rsp: ffffff007a4909c0 > ss: 38 > > ffffff007a4907b0 unix:die+df () > ffffff007a4908c0 unix:trap+db3 () > ffffff007a4908d0 unix:cmntrap+e6 () > ffffff007a490a20 stmf:stmf_remove_lu_from_session+7c () > ffffff007a490ab0 stmf:stmf_update_sessions_per_ve+118 () > ffffff007a490af0 stmf:stmf_session_lu_unmapall+55 () > ffffff007a490b60 stmf:stmf_svc+111 () > ffffff007a490c20 genunix:taskq_thread+2d0 () > ffffff007a490c30 unix:thread_start+8 () > > syncing file systems... > done > dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel > > > > > > Happy Holidays!! > > Geoff > > From henson at acm.org Tue Dec 24 21:03:39 2013 From: henson at acm.org (Paul B. Henson) Date: Tue, 24 Dec 2013 13:03:39 -0800 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <52B8206E.1050806@gmail.com> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <52B8206E.1050806@gmail.com> Message-ID: <52B9F6AB.8000305@acm.org> On 12/23/2013 3:37 AM, Saso Kiselkov wrote: > I'm quite fond of WD Red drives. They are just marginally more expensive > than your el-cheapo home drive, but are built for 8760 on hours per year > (24x7) and are capable for throttling down to 5400rpm when not in use > (so they suck less power). WD markets them as designed for use in NAS. Do you have an authoritative source for the WD Red drives actually spinning at variable rates? From what I've read, while the actual rpm might vary between models, any given model only spins at a constant rpm, thought to be somewhere between 5000-5900. WD isn't exactly clear as to what exactly "Intellipower" means 8-/... I have been pretty happy with my 3TB WD reds so far? From skiselkov.ml at gmail.com Tue Dec 24 21:13:26 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Tue, 24 Dec 2013 21:13:26 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <52B9F6AB.8000305@acm.org> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <52B8206E.1050806@gmail.com> <52B9F6AB.8000305@acm.org> Message-ID: <52B9F8F6.1080706@gmail.com> On 12/24/13, 9:03 PM, Paul B. Henson wrote: > On 12/23/2013 3:37 AM, Saso Kiselkov wrote: > >> I'm quite fond of WD Red drives. They are just marginally more expensive >> than your el-cheapo home drive, but are built for 8760 on hours per year >> (24x7) and are capable for throttling down to 5400rpm when not in use >> (so they suck less power). WD markets them as designed for use in NAS. > > Do you have an authoritative source for the WD Red drives actually > spinning at variable rates? From what I've read, while the actual rpm > might vary between models, any given model only spins at a constant rpm, > thought to be somewhere between 5000-5900. WD isn't exactly clear as to > what exactly "Intellipower" means 8-/... > > I have been pretty happy with my 3TB WD reds so far? True, I had always assumed Intellipower meant "auto-throttle", but they do mention in their datasheets that it can be anything-to-anything, even invariable. I guess if you placed a microphone near to it and ran some FT on it you could easily determine that, but then, I've got better things to do with my life. So yeah, they *may* or *may not* auto-throttle :) -- Saso From daleg at omniti.com Tue Dec 24 21:17:35 2013 From: daleg at omniti.com (Dale Ghent) Date: Tue, 24 Dec 2013 16:17:35 -0500 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <52B9F6AB.8000305@acm.org> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <52B8206E.1050806@gmail.com> <52B9F6AB.8000305@acm.org> Message-ID: <088E990C-C5EB-4D28-934C-48DA01C4DBE8@omniti.com> On Dec 24, 2013, at 4:03 PM, Paul B. Henson wrote: > On 12/23/2013 3:37 AM, Saso Kiselkov wrote: > >> I'm quite fond of WD Red drives. They are just marginally more expensive >> than your el-cheapo home drive, but are built for 8760 on hours per year >> (24x7) and are capable for throttling down to 5400rpm when not in use >> (so they suck less power). WD markets them as designed for use in NAS. > > Do you have an authoritative source for the WD Red drives actually spinning at variable rates? From what I've read, while the actual rpm might vary between models, any given model only spins at a constant rpm, thought to be somewhere between 5000-5900. WD isn't exactly clear as to what exactly "Intellipower" means 8-/... http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-771442.pdf "A fine-tuned balance of spin speed, transfer rate and caching algorithms designed to deliver both significant power savings and solid performance. For each drive model, WD may use a different, invariable RPM." So much for technical details, but that's the gist of it. /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From skiselkov.ml at gmail.com Tue Dec 24 21:20:30 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Tue, 24 Dec 2013 21:20:30 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <088E990C-C5EB-4D28-934C-48DA01C4DBE8@omniti.com> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <52B8206E.1050806@gmail.com> <52B9F6AB.8000305@acm.org> <088E990C-C5EB-4D28-934C-48DA01C4DBE8@omniti.com> Message-ID: <52B9FA9E.8050207@gmail.com> On 12/24/13, 9:17 PM, Dale Ghent wrote: > > On Dec 24, 2013, at 4:03 PM, Paul B. Henson wrote: > >> On 12/23/2013 3:37 AM, Saso Kiselkov wrote: >> >>> I'm quite fond of WD Red drives. They are just marginally more expensive >>> than your el-cheapo home drive, but are built for 8760 on hours per year >>> (24x7) and are capable for throttling down to 5400rpm when not in use >>> (so they suck less power). WD markets them as designed for use in NAS. >> >> Do you have an authoritative source for the WD Red drives actually spinning at variable rates? From what I've read, while the actual rpm might vary between models, any given model only spins at a constant rpm, thought to be somewhere between 5000-5900. WD isn't exactly clear as to what exactly "Intellipower" means 8-/... > > http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-771442.pdf > > "A fine-tuned balance of spin speed, transfer rate and caching algorithms designed to deliver both significant power savings and solid performance. For each drive model, WD may use a different, invariable RPM." > > So much for technical details, but that's the gist of it. Yeah, I read that too, but you have to realize that that's just marketing speak for "I'm not tellin'". Cheers, -- Saso From henson at acm.org Tue Dec 24 21:21:45 2013 From: henson at acm.org (Paul B. Henson) Date: Tue, 24 Dec 2013 13:21:45 -0800 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <52B9F8F6.1080706@gmail.com> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <52B8206E.1050806@gmail.com> <52B9F6AB.8000305@acm.org> <52B9F8F6.1080706@gmail.com> Message-ID: <20131224212145.GD7372@bender.unx.csupomona.edu> On Tue, Dec 24, 2013 at 09:13:26PM +0000, Saso Kiselkov wrote: > True, I had always assumed Intellipower meant "auto-throttle" I think Intellipower means "if we called them 5400rpm drives nobody would buy them so let's be vague as hell" ;). > invariable. I guess if you placed a microphone near to it and ran some > FT on it you could easily determine that, but then, I've got better > things to do with my life. Seems some people don't: http://www.silentpcreview.com/article1285-page5.html "The two Red drives produced a slight tone at ~90 Hz, confirming that their motors spin at about 5,400 RPM." From skiselkov.ml at gmail.com Tue Dec 24 21:29:06 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Tue, 24 Dec 2013 21:29:06 +0000 Subject: [OmniOS-discuss] OT: Similar hardware like MIcroserver Gen8 In-Reply-To: <20131224212145.GD7372@bender.unx.csupomona.edu> References: <52B459DA.7030501@gmail.com> <52B46409.8010106@gmail.com> <52B8206E.1050806@gmail.com> <52B9F6AB.8000305@acm.org> <52B9F8F6.1080706@gmail.com> <20131224212145.GD7372@bender.unx.csupomona.edu> Message-ID: <52B9FCA2.7060209@gmail.com> On 12/24/13, 9:21 PM, Paul B. Henson wrote: > On Tue, Dec 24, 2013 at 09:13:26PM +0000, Saso Kiselkov wrote: > >> True, I had always assumed Intellipower meant "auto-throttle" > > I think Intellipower means "if we called them 5400rpm drives nobody > would buy them so let's be vague as hell" ;). > >> invariable. I guess if you placed a microphone near to it and ran some >> FT on it you could easily determine that, but then, I've got better >> things to do with my life. > > Seems some people don't: > > http://www.silentpcreview.com/article1285-page5.html > > "The two Red drives produced a slight tone at ~90 Hz, confirming that > their motors spin at about 5,400 RPM." Well, silentpcreview is a special brand of people who are obsessed about stuff that I don't care about one bit. For me, the best solution to get rid of hardware-induced noise is to simply shove the hardware in a separate room and run cables to my workstation. Anyway, I digress. Even if the drives are 5400rpm, they are plenty snappy enough for me and 1Gbit/s network (not running any transactional workloads on the, of course). -- Saso From nagele at wildbit.com Thu Dec 26 17:31:30 2013 From: nagele at wildbit.com (Chris Nagele) Date: Thu, 26 Dec 2013 12:31:30 -0500 Subject: [OmniOS-discuss] Failing zfs send / receive Message-ID: For one of our products, we run a fairly aggressive snapshot and backup process. At the moment, it it runs a process that sends snapshots to both a local and offsite server every 60 seconds for 20 filesystems in ZFS. For the most part it works really well. The issues is that every once in a while the process will fail when sending the snapshot to either the local or offsite server. I assume it is a network issue, but I ran a constant ping and during the time that it failed there was 0 packet loss. The only hint I have so far is this in the logs of the remote server: Dec 26 13:16:18 sl-wdc-backup sshd[7470]: [ID 800047 auth.crit] fatal: Timeout before authentication for x.x.15.34 Dec 26 14:24:12 sl-wdc-backup sshd[23567]: [ID 800047 auth.crit] fatal: Timeout before authentication for x.x.15.34 Dec 26 15:14:47 sl-wdc-backup sshd[3481]: [ID 800047 auth.crit] fatal: Timeout before authentication for x.x.15.34 Dec 26 16:42:41 sl-wdc-backup sshd[11456]: [ID 800047 auth.crit] fatal: Timeout before authentication for x.x.15.34 Any ideas what could cause this timeout or if it is something I can increase? Thanks, Chris From mir at miras.org Thu Dec 26 17:52:02 2013 From: mir at miras.org (Michael Rasmussen) Date: Thu, 26 Dec 2013 18:52:02 +0100 Subject: [OmniOS-discuss] Failing zfs send / receive In-Reply-To: References: Message-ID: <20131226185202.201e1488@sleipner.datanom.net> On Thu, 26 Dec 2013 12:31:30 -0500 Chris Nagele wrote: > > Any ideas what could cause this timeout or if it is something I can increase? > Do you have this config in sshd_config on the remote side: GSSAPIAuthentication no If GSSAPIAuthentication is active you sometimes see timeouts cause by the remote side waiting for GSSAPIAuthentication which by default first will timeout after 20 sec. Other configs of interest: LookupClientHostnames no VerifyReverseMapping no -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Lost: gray and white female cat. Answers to electric can opener. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From scotty at jhu.edu Thu Dec 26 18:34:34 2013 From: scotty at jhu.edu (Scott Roberts) Date: Thu, 26 Dec 2013 18:34:34 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet Message-ID: Hello all, I have a new Dell R720 server and unfortunately the network interfaces do not show up. "dladm show-phys" and "dladm show-link" don't return anything. I can see e1000g0 and e1000g1 under /dev but when I try to plumb the interfaces I receive the error message "ifconfig: cannot plumb e1000g0: Could not open DLPI link". Any thoughts on how I can get the network up and running? This is the first time I have encountered this particular error and I have run OmniOS on a variety of hardware. Thank you in advance, --Scott. From skiselkov.ml at gmail.com Thu Dec 26 18:43:59 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 18:43:59 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: Message-ID: <52BC78EF.8090704@gmail.com> On 12/26/13, 6:34 PM, Scott Roberts wrote: > Hello all, > > I have a new Dell R720 server and unfortunately the network interfaces do > not show up. "dladm show-phys" and "dladm show-link" don't return > anything. I can see e1000g0 and e1000g1 under /dev but when I try to > plumb the interfaces I receive the error message "ifconfig: cannot plumb > e1000g0: Could not open DLPI link". > > Any thoughts on how I can get the network up and running? This is the > first time I have encountered this particular error and I have run OmniOS > on a variety of hardware. What does lspci say? # lspci | grep Ethernet (if you don't have it installed, "pkg install pciutils") Cheers, -- Saso From scotty at jhu.edu Thu Dec 26 19:27:35 2013 From: scotty at jhu.edu (Scott Roberts) Date: Thu, 26 Dec 2013 19:27:35 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet Message-ID: To be clear, neither the onboard Gigabit or 10Gig links are shown, only loopback, so running a pkg install fails. I don't have any PCI ethernet cards to throw in this thing, either. I'm pretty much dead in the water. From scotty at jhu.edu Thu Dec 26 19:45:46 2013 From: scotty at jhu.edu (Scott Roberts) Date: Thu, 26 Dec 2013 19:45:46 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC85BA.7080902@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> Message-ID: Saso, It has the following: Broadcom 57800 2x10Gb DA/SFP+ + 2x1Gb BT Network Daughter Card Broadcom 57810 Dual Port 10Gb Direct Attach/SFP+ Network Adapter Total of (2) GigE and (4) 10Gb SFP+ ports. --Scott On 12/26/13, 2:38 PM, "Saso Kiselkov" wrote: >On 12/26/13, 7:19 PM, Scott Roberts wrote: >> To be clear, neither the onboard Gigabit or 10Gig links are shown, only >> loopback, so running a pkg install fails. I don't have any PCI ethernet >> cards to throw in this thing, either. I'm pretty much dead in the >>water. >> > >Which NICs did you purchase this box with? Broadcom or Intel? > >-- >Saso From scotty at jhu.edu Thu Dec 26 19:50:10 2013 From: scotty at jhu.edu (Scott Roberts) Date: Thu, 26 Dec 2013 19:50:10 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC8763.2070708@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8763.2070708@gmail.com> Message-ID: Saso, No worries. I'll grab the Broadcom GigE driver and install that first. Thanks! WRT the 10Gig, it just flat out isn't compatible? That's a real problem for my project. On 12/26/13, 2:45 PM, "Saso Kiselkov" wrote: >On 12/26/13, 7:38 PM, Saso Kiselkov wrote: >> On 12/26/13, 7:19 PM, Scott Roberts wrote: >>> To be clear, neither the onboard Gigabit or 10Gig links are shown, only >>> loopback, so running a pkg install fails. I don't have any PCI >>>ethernet >>> cards to throw in this thing, either. I'm pretty much dead in the >>>water. >>> >> >> Which NICs did you purchase this box with? Broadcom or Intel? >> > >Shit, I'm having a reading comprehension problem, apparently :) it was >in your subject. > >For the gigabit Broadcom 5720 you should be able to use the Solaris >driver from here: >http://www.broadcom.com/support/ethernet_nic/netxtreme_server.php > >For the 10-gig 57800 part, I'm afraid, you're out of luck. Broadcom >stopped shipping anything besides Windows and Linux drivers for this NIC. > >Hope this helps. >-- >Saso From cnehren+omnios-discuss at omniti.com Thu Dec 26 19:50:14 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Thu, 26 Dec 2013 14:50:14 -0500 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: Message-ID: <20131226195014.GB60645@eschaton.local> On Thu, Dec 26, 2013 at 19:27:35 +0000, Scott Roberts wrote: > To be clear, neither the onboard Gigabit or 10Gig links are shown, only > loopback, so running a pkg install fails. I don't have any PCI ethernet > cards to throw in this thing, either. I'm pretty much dead in the water. You can use an existing system to create a package archive of lspci, which you could then transfer over virtual disk in your IPKVM, via sneakernet, or other means. pkgrecv -a -d lspci.p5a -s http://pkg.omniti.com/omnios/release/ \ pkg:/system/pciutils Also of interest would be `prtconf -v` output, but admittedly without network that might be hard to acquire. The R720, according to the datasheet, uses the Intel C600 series chipset, and its NIC (the 82579LM) is listed in the HCL, so in theory it should work. It's not disabled in the BIOS, or anything silly like that, right? -- Chris Nehren From skiselkov.ml at gmail.com Thu Dec 26 19:50:41 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 19:50:41 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> Message-ID: <52BC8891.1040906@gmail.com> On 12/26/13, 7:45 PM, Scott Roberts wrote: > Saso, > > It has the following: > > Broadcom 57800 2x10Gb DA/SFP+ + 2x1Gb BT Network Daughter Card > > Broadcom 57810 Dual Port 10Gb Direct Attach/SFP+ Network Adapter > > Total of (2) GigE and (4) 10Gb SFP+ ports. Sorry to disappoint, but those 10Gb parts aren't and probably never will be supported. Unfortunately, Broadcom has a bad habit of shipping binary blobs only, so there's no way we could even port over support from other platforms (as we're doing with Intel hardware). For Illumos I'd recommend always going with Intel NICs whenever possible. I know it's not much consolation, just a piece of forward-looking advice. -- Saso From skiselkov.ml at gmail.com Thu Dec 26 19:52:47 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 19:52:47 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8763.2070708@gmail.com> Message-ID: <52BC890F.7010909@gmail.com> On 12/26/13, 7:50 PM, Scott Roberts wrote: > Saso, > > No worries. I'll grab the Broadcom GigE driver and install that first. > Thanks! > > WRT the 10Gig, it just flat out isn't compatible? That's a real problem > for my project. Sadly, that's the situation, it seems. If you can spare a PCI-e slot, though, you can get an Intel X520-DA2 very cheaply nowadays. Talk to your Dell sales rep, they can easily knock the price down to ~$250. Cheers, -- Saso From daleg at omniti.com Thu Dec 26 19:55:08 2013 From: daleg at omniti.com (Dale Ghent) Date: Thu, 26 Dec 2013 14:55:08 -0500 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> Message-ID: <3EEFC41E-7826-4F5C-AAA1-2BBA876ABB1F@omniti.com> Broadcomm does have GLDv3 drivers for "Solaris" - whether it'll work on Illumos derivatives would be a quick and easy experiment with hopefully favorable results. http://www.broadcom.com/support/ethernet_nic/netxtremeii10.php /dale On Dec 26, 2013, at 2:45 PM, Scott Roberts wrote: > Saso, > > It has the following: > > Broadcom 57800 2x10Gb DA/SFP+ + 2x1Gb BT Network Daughter Card > > Broadcom 57810 Dual Port 10Gb Direct Attach/SFP+ Network Adapter > > > Total of (2) GigE and (4) 10Gb SFP+ ports. > > --Scott > > On 12/26/13, 2:38 PM, "Saso Kiselkov" wrote: > >> On 12/26/13, 7:19 PM, Scott Roberts wrote: >>> To be clear, neither the onboard Gigabit or 10Gig links are shown, only >>> loopback, so running a pkg install fails. I don't have any PCI ethernet >>> cards to throw in this thing, either. I'm pretty much dead in the >>> water. >>> >> >> Which NICs did you purchase this box with? Broadcom or Intel? >> >> -- >> Saso > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From skiselkov.ml at gmail.com Thu Dec 26 19:56:30 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 19:56:30 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> Message-ID: <52BC89EE.7000703@gmail.com> On 12/26/13, 7:45 PM, Scott Roberts wrote: > Saso, > > It has the following: > > Broadcom 57800 2x10Gb DA/SFP+ + 2x1Gb BT Network Daughter Card > > Broadcom 57810 Dual Port 10Gb Direct Attach/SFP+ Network Adapter > > Total of (2) GigE and (4) 10Gb SFP+ ports. Talk to your Dell sales rep, if it's newly purchased stuff, you might be able to get those swapped out for Intel parts. Cheers, -- Saso From jdg117 at elvis.arl.psu.edu Thu Dec 26 19:56:56 2013 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Thu, 26 Dec 2013 14:56:56 -0500 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: Your message of "Thu, 26 Dec 2013 14:50:14 EST." <20131226195014.GB60645@eschaton.local> References: <20131226195014.GB60645@eschaton.local> Message-ID: <201312261956.rBQJuuUS026684@elvis.arl.psu.edu> In message <20131226195014.GB60645 at eschaton.local>, Chris Nehren writes: >The R720, according to the datasheet, uses the Intel C600 series >chipset, and its NIC (the 82579LM) is listed in the HCL, so in >theory it should work. It's not disabled in the BIOS, or anything >silly like that, right? Or configured as the iDRAC management interface. John groenveld at acm.org From skiselkov.ml at gmail.com Thu Dec 26 19:59:18 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 19:59:18 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <3EEFC41E-7826-4F5C-AAA1-2BBA876ABB1F@omniti.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <3EEFC41E-7826-4F5C-AAA1-2BBA876ABB1F@omniti.com> Message-ID: <52BC8A96.3040008@gmail.com> On 12/26/13, 7:55 PM, Dale Ghent wrote: > > > Broadcomm does have GLDv3 drivers for "Solaris" - whether it'll work on Illumos derivatives would be a quick and easy experiment with hopefully favorable results. > > http://www.broadcom.com/support/ethernet_nic/netxtremeii10.php The Dell R720 doesn't use NetExtreme II NICs. They use the newer NetLink NICs, for which even Broadcom remarks on their driver site: "Note: Broadcom does not offer UnixWare, SCO and Solaris drivers for NetLink Ethernet controllers." Cheers, -- Saso From skiselkov.ml at gmail.com Thu Dec 26 20:10:10 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 20:10:10 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC8891.1040906@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> Message-ID: <52BC8D22.5040500@gmail.com> On 12/26/13, 7:50 PM, Saso Kiselkov wrote: > On 12/26/13, 7:45 PM, Scott Roberts wrote: >> Saso, >> >> It has the following: >> >> Broadcom 57800 2x10Gb DA/SFP+ + 2x1Gb BT Network Daughter Card >> >> Broadcom 57810 Dual Port 10Gb Direct Attach/SFP+ Network Adapter >> >> Total of (2) GigE and (4) 10Gb SFP+ ports. > > Sorry to disappoint, but those 10Gb parts aren't and probably never will > be supported. Unfortunately, Broadcom has a bad habit of shipping binary > blobs only, so there's no way we could even port over support from other > platforms (as we're doing with Intel hardware). Minor correction here. It appears the tg3 Linux driver *is* open-source, so provided that you can get Broadcom to give it a liberal-enough license to let us include it in Illumos, you might be able to port it to Illumos. FreeBSD, which is the source of many drivers that Illumos ports over, sadly, doesn't seem to support it either. Cheers, -- Saso From skiselkov.ml at gmail.com Thu Dec 26 20:12:18 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 20:12:18 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC8D22.5040500@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> Message-ID: <52BC8DA2.4090406@gmail.com> On 12/26/13, 8:10 PM, Saso Kiselkov wrote: > On 12/26/13, 7:50 PM, Saso Kiselkov wrote: >> On 12/26/13, 7:45 PM, Scott Roberts wrote: >>> Saso, >>> >>> It has the following: >>> >>> Broadcom 57800 2x10Gb DA/SFP+ + 2x1Gb BT Network Daughter Card >>> >>> Broadcom 57810 Dual Port 10Gb Direct Attach/SFP+ Network Adapter >>> >>> Total of (2) GigE and (4) 10Gb SFP+ ports. >> >> Sorry to disappoint, but those 10Gb parts aren't and probably never will >> be supported. Unfortunately, Broadcom has a bad habit of shipping binary >> blobs only, so there's no way we could even port over support from other >> platforms (as we're doing with Intel hardware). > > Minor correction here. It appears the tg3 Linux driver *is* open-source, > so provided that you can get Broadcom to give it a liberal-enough > license to let us include it in Illumos, you might be able to port it to > Illumos. FreeBSD, which is the source of many drivers that Illumos ports > over, sadly, doesn't seem to support it either. Damn, correction #2 here: FreeBSD does include support for this since 10-current, so its bxe(4) driver is a potential target for porting: http://www.freebsd.org/cgi/man.cgi?query=bxe&apropos=0&sektion=4&manpath=FreeBSD+10-current&arch=default&format=html Now just to find the person with enough spare time on their hands to do the actual grunt work... -- Saso From daleg at omniti.com Thu Dec 26 20:19:58 2013 From: daleg at omniti.com (Dale Ghent) Date: Thu, 26 Dec 2013 15:19:58 -0500 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC8A96.3040008@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <3EEFC41E-7826-4F5C-AAA1-2BBA876ABB1F@omniti.com> <52BC8A96.3040008@gmail.com> Message-ID: On Dec 26, 2013, at 2:59 PM, Saso Kiselkov wrote: > On 12/26/13, 7:55 PM, Dale Ghent wrote: >> >> >> Broadcomm does have GLDv3 drivers for "Solaris" - whether it'll work on Illumos derivatives would be a quick and easy experiment with hopefully favorable results. >> >> http://www.broadcom.com/support/ethernet_nic/netxtremeii10.php > > The Dell R720 doesn't use NetExtreme II NICs. They use the newer NetLink > NICs, for which even Broadcom remarks on their driver site: > "Note: Broadcom does not offer UnixWare, SCO and Solaris drivers for > NetLink Ethernet controllers." The driver I linked purports to cover the 578xx chips, which are the chipsets that Scott quoted as being the ones he has on his server? /dale From skiselkov.ml at gmail.com Thu Dec 26 20:20:35 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 20:20:35 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC8A96.3040008@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <3EEFC41E-7826-4F5C-AAA1-2BBA876ABB1F@omniti.com> <52BC8A96.3040008@gmail.com> Message-ID: <52BC8F93.3000203@gmail.com> On 12/26/13, 7:59 PM, Saso Kiselkov wrote: > On 12/26/13, 7:55 PM, Dale Ghent wrote: >> >> >> Broadcomm does have GLDv3 drivers for "Solaris" - whether it'll work on Illumos derivatives would be a quick and easy experiment with hopefully favorable results. >> >> http://www.broadcom.com/support/ethernet_nic/netxtremeii10.php > > The Dell R720 doesn't use NetExtreme II NICs. They use the newer NetLink > NICs, for which even Broadcom remarks on their driver site: > "Note: Broadcom does not offer UnixWare, SCO and Solaris drivers for > NetLink Ethernet controllers." Sorry for the false info, 578xx indeed appear to be NetExtreme II NICs, so the driver *should* work. I got the NIC series numbers mixed up on the driver page. Cheers, -- Saso From scotty at jhu.edu Thu Dec 26 20:22:06 2013 From: scotty at jhu.edu (Scott Roberts) Date: Thu, 26 Dec 2013 20:22:06 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC8EAD.9080204@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> <52BC8EAD.9080204@gmail.com> Message-ID: Thanks to all for the quick replies and suggestions. This list is awesome. I just finished burning the driver update CDs for the GigE and 10G drivers and will re-install OmniOS using the DUs. I will let you all know how it goes. I will also question Dell about swapping out with Intel hardware. I somehow missed the switch to Broadcom hardware in their last quote... my fault. Cheers, --Scott On 12/26/13, 3:16 PM, "Saso Kiselkov" wrote: >Looking around the FreeBSD man pages it appears that the 57800S/57840 >indeed are NetExtreme II NICs. Can you try the NIC driver that Dale >suggested? > >http://www.broadcom.com/support/ethernet_nic/netxtremeii10.php > >-- >Saso From skiselkov.ml at gmail.com Thu Dec 26 20:22:18 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 20:22:18 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <3EEFC41E-7826-4F5C-AAA1-2BBA876ABB1F@omniti.com> <52BC8A96.3040008@gmail.com> Message-ID: <52BC8FFA.2030407@gmail.com> On 12/26/13, 8:19 PM, Dale Ghent wrote: > On Dec 26, 2013, at 2:59 PM, Saso Kiselkov wrote: > >> On 12/26/13, 7:55 PM, Dale Ghent wrote: >>> >>> >>> Broadcomm does have GLDv3 drivers for "Solaris" - whether it'll work on Illumos derivatives would be a quick and easy experiment with hopefully favorable results. >>> >>> http://www.broadcom.com/support/ethernet_nic/netxtremeii10.php >> >> The Dell R720 doesn't use NetExtreme II NICs. They use the newer NetLink >> NICs, for which even Broadcom remarks on their driver site: >> "Note: Broadcom does not offer UnixWare, SCO and Solaris drivers for >> NetLink Ethernet controllers." > > The driver I linked purports to cover the 578xx chips, which are the chipsets that Scott quoted as being the ones he has on his server? You're right, I got the numbers mixed up. My bad. -- Saso From skiselkov.ml at gmail.com Thu Dec 26 20:27:55 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 20:27:55 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> <52BC8EAD.9080204@gmail.com> Message-ID: <52BC914B.9020503@gmail.com> On 12/26/13, 8:22 PM, Scott Roberts wrote: > Thanks to all for the quick replies and suggestions. This list is awesome. Glad we could get this finally sorted to some kind of happy ending. Again, sorry for giving you bad info initially. > I just finished burning the driver update CDs for the GigE and 10G drivers > and will re-install OmniOS using the DUs. I will let you all know how it > goes. > > I will also question Dell about swapping out with Intel hardware. I > somehow missed the switch to Broadcom hardware in their last quote... my > fault. If you can get them swapped out, the added benefit will be that igb and ixgbe (the Intel drivers) support fast reboot, so you'll be able to reboot your machine without having to go through the lengthy BIOS boot checks. Cheers, -- Saso From mir at miras.org Thu Dec 26 20:33:36 2013 From: mir at miras.org (Michael Rasmussen) Date: Thu, 26 Dec 2013 21:33:36 +0100 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC914B.9020503@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> <52BC8EAD.9080204@gmail.com> <52BC914B.9020503@gmail.com> Message-ID: <20131226213336.416a31e3@sleipner.datanom.net> On Thu, 26 Dec 2013 20:27:55 +0000 Saso Kiselkov wrote: > > If you can get them swapped out, the added benefit will be that igb and > ixgbe (the Intel drivers) support fast reboot, so you'll be able to > reboot your machine without having to go through the lengthy BIOS boot > checks. Is this the case for all Intel drivers or are there some Intel drivers which does not support fast reboot? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- These days the necessities of life cost you about three times what they used to, and half the time they aren't even fit to drink. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From skiselkov.ml at gmail.com Thu Dec 26 20:41:18 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 20:41:18 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <20131226213336.416a31e3@sleipner.datanom.net> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> <52BC8EAD.9080204@gmail.com> <52BC914B.9020503@gmail.com> <20131226213336.416a31e3@sleipner.datanom.net> Message-ID: <52BC946E.4090904@gmail.com> On 12/26/13, 8:33 PM, Michael Rasmussen wrote: > On Thu, 26 Dec 2013 20:27:55 +0000 > Saso Kiselkov wrote: > >> >> If you can get them swapped out, the added benefit will be that igb and >> ixgbe (the Intel drivers) support fast reboot, so you'll be able to >> reboot your machine without having to go through the lengthy BIOS boot >> checks. > Is this the case for all Intel drivers or are there some Intel drivers > which does not support fast reboot? Anything handled e1000g, igb and ixgbe supports it. Don't know if this covers *all* Intel NICs we support, but these three drivers certainly handle all Intel NICs available for the R720. Cheers, -- Saso From lotheac at iki.fi Thu Dec 26 20:44:55 2013 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Thu, 26 Dec 2013 22:44:55 +0200 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC8DA2.4090406@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> Message-ID: <20131226204455.GE10749@gutsman.lotheac.fi> On Thu, Dec 26 2013 20:12:18 +0000, Saso Kiselkov wrote: > On 12/26/13, 8:10 PM, Saso Kiselkov wrote: > > On 12/26/13, 7:50 PM, Saso Kiselkov wrote: > >> On 12/26/13, 7:45 PM, Scott Roberts wrote: > >>> Saso, > >>> > >>> It has the following: > >>> > >>> Broadcom 57800 2x10Gb DA/SFP+ + 2x1Gb BT Network Daughter Card > >>> > >>> Broadcom 57810 Dual Port 10Gb Direct Attach/SFP+ Network Adapter > >>> > >>> Total of (2) GigE and (4) 10Gb SFP+ ports. > >> > >> Sorry to disappoint, but those 10Gb parts aren't and probably never will > >> be supported. Unfortunately, Broadcom has a bad habit of shipping binary > >> blobs only, so there's no way we could even port over support from other > >> platforms (as we're doing with Intel hardware). > > > > Minor correction here. It appears the tg3 Linux driver *is* open-source, > > so provided that you can get Broadcom to give it a liberal-enough > > license to let us include it in Illumos, you might be able to port it to > > Illumos. FreeBSD, which is the source of many drivers that Illumos ports > > over, sadly, doesn't seem to support it either. > > Damn, correction #2 here: FreeBSD does include support for this since > 10-current, so its bxe(4) driver is a potential target for porting: > http://www.freebsd.org/cgi/man.cgi?query=bxe&apropos=0&sektion=4&manpath=FreeBSD+10-current&arch=default&format=html > > Now just to find the person with enough spare time on their hands to do > the actual grunt work... Interestingly, Broadcom's GLDv3 driver package for these cards from http://www.broadcom.com/support/license.php?file=NXII_10/solaris_ev-7.8.11.zip includes the source code and even has an illumos compilation target (but no illumos binaries). We tried at work and the driver attaches to our 57810 NICs, but we haven't tried actually using them yet. The license doesn't seem very permissive though... -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet From skiselkov.ml at gmail.com Thu Dec 26 20:48:49 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 26 Dec 2013 20:48:49 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <20131226204455.GE10749@gutsman.lotheac.fi> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> <20131226204455.GE10749@gutsman.lotheac.fi> Message-ID: <52BC9631.2040208@gmail.com> On 12/26/13, 8:44 PM, Lauri Tirkkonen wrote: > On Thu, Dec 26 2013 20:12:18 +0000, Saso Kiselkov wrote: >> On 12/26/13, 8:10 PM, Saso Kiselkov wrote: >>> On 12/26/13, 7:50 PM, Saso Kiselkov wrote: >>>> On 12/26/13, 7:45 PM, Scott Roberts wrote: >>>>> Saso, >>>>> >>>>> It has the following: >>>>> >>>>> Broadcom 57800 2x10Gb DA/SFP+ + 2x1Gb BT Network Daughter Card >>>>> >>>>> Broadcom 57810 Dual Port 10Gb Direct Attach/SFP+ Network Adapter >>>>> >>>>> Total of (2) GigE and (4) 10Gb SFP+ ports. >>>> >>>> Sorry to disappoint, but those 10Gb parts aren't and probably never will >>>> be supported. Unfortunately, Broadcom has a bad habit of shipping binary >>>> blobs only, so there's no way we could even port over support from other >>>> platforms (as we're doing with Intel hardware). >>> >>> Minor correction here. It appears the tg3 Linux driver *is* open-source, >>> so provided that you can get Broadcom to give it a liberal-enough >>> license to let us include it in Illumos, you might be able to port it to >>> Illumos. FreeBSD, which is the source of many drivers that Illumos ports >>> over, sadly, doesn't seem to support it either. >> >> Damn, correction #2 here: FreeBSD does include support for this since >> 10-current, so its bxe(4) driver is a potential target for porting: >> http://www.freebsd.org/cgi/man.cgi?query=bxe&apropos=0&sektion=4&manpath=FreeBSD+10-current&arch=default&format=html >> >> Now just to find the person with enough spare time on their hands to do >> the actual grunt work... > > Interestingly, Broadcom's GLDv3 driver package for these cards from > http://www.broadcom.com/support/license.php?file=NXII_10/solaris_ev-7.8.11.zip > includes the source code and even has an illumos compilation target (but > no illumos binaries). We tried at work and the driver attaches to our > 57810 NICs, but we haven't tried actually using them yet. The license > doesn't seem very permissive though... > Neat. If anybody knows the relevant people at Broadcom, it would be interesting to ask them if they'd be interested for this work to be folded into the Illumos mainline code. My guess is the answer will be "no", but would be interesting to ask nonetheless. Cheers, -- Saso From scotty at jhu.edu Thu Dec 26 21:12:31 2013 From: scotty at jhu.edu (Scott Roberts) Date: Thu, 26 Dec 2013 21:12:31 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC9631.2040208@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> <20131226204455.GE10749@gutsman.lotheac.fi> <52BC9631.2040208@gmail.com> Message-ID: So here's the current state, which is still broken. I tried installing BRCMbge however OmniOS complains that SUNWbge is already installed. I've tried every combination of pkgrm I can think of to no avail - I cannot uninstall SUNWbge for the life of me. I tried installing BRCMbxne however I get a message that the maximum number of instances of BRCMbxne is already installed. Sigh. From scotty at jhu.edu Thu Dec 26 21:24:37 2013 From: scotty at jhu.edu (Scott Roberts) Date: Thu, 26 Dec 2013 21:24:37 +0000 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> <20131226204455.GE10749@gutsman.lotheac.fi> <52BC9631.2040208@gmail.com> Message-ID: I found instructions buried in the DU tar file to remove SUNbge and BRCMbxne and was finally able to install the updated drivers. "dladm show-phys" still shows nothing, so I'm rebooting the server now to see if it is something else. Before the reboot I saw the updated drivers were loaded using modinfo, so hopefully the reboot will show good results. On 12/26/13, 4:12 PM, "Scott Roberts" wrote: >So here's the current state, which is still broken. > >I tried installing BRCMbge however OmniOS complains that SUNWbge is >already installed. I've tried every combination of pkgrm I can think of >to no avail - I cannot uninstall SUNWbge for the life of me. > >I tried installing BRCMbxne however I get a message that the maximum >number of instances of BRCMbxne is already installed. > >Sigh. > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss From daleg at omniti.com Thu Dec 26 21:55:11 2013 From: daleg at omniti.com (Dale Ghent) Date: Thu, 26 Dec 2013 16:55:11 -0500 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> <20131226204455.GE10749@gutsman.lotheac.fi> <52BC9631.2040208@gmail.com> Message-ID: There's a chance that, given the utter wreck that the broadcomm source tarball is, that your particular cards' PCI IDs might not be added to /etc/driver_aliases by the package. All isn't lost if that's the case? but let's see how far you get after the reboot and see what happens. /dale On Dec 26, 2013, at 4:24 PM, Scott Roberts wrote: > I found instructions buried in the DU tar file to remove SUNbge and > BRCMbxne and was finally able to install the updated drivers. "dladm > show-phys" still shows nothing, so I'm rebooting the server now to see if > it is something else. > > Before the reboot I saw the updated drivers were loaded using modinfo, so > hopefully the reboot will show good results. > > > On 12/26/13, 4:12 PM, "Scott Roberts" wrote: > >> So here's the current state, which is still broken. >> >> I tried installing BRCMbge however OmniOS complains that SUNWbge is >> already installed. I've tried every combination of pkgrm I can think of >> to no avail - I cannot uninstall SUNWbge for the life of me. >> >> I tried installing BRCMbxne however I get a message that the maximum >> number of instances of BRCMbxne is already installed. >> >> Sigh. >> >> _______________________________________________ >> 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 mir at miras.org Thu Dec 26 22:35:16 2013 From: mir at miras.org (Michael Rasmussen) Date: Thu, 26 Dec 2013 23:35:16 +0100 Subject: [OmniOS-discuss] Dell R720 & Broadcom ethernet In-Reply-To: <52BC946E.4090904@gmail.com> References: <52BC78EF.8090704@gmail.com> <52BC85BA.7080902@gmail.com> <52BC8891.1040906@gmail.com> <52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com> <52BC8EAD.9080204@gmail.com> <52BC914B.9020503@gmail.com> <20131226213336.416a31e3@sleipner.datanom.net> <52BC946E.4090904@gmail.com> Message-ID: <20131226233516.6c8a2e5d@sleipner.datanom.net> On Thu, 26 Dec 2013 20:41:18 +0000 Saso Kiselkov wrote: > > Anything handled e1000g, igb and ixgbe supports it. Don't know if this > covers *all* Intel NICs we support, but these three drivers certainly > handle all Intel NICs available for the R720. > Thanks. That sort of covers all Intel nics available to me;-) -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- 3990 N Apr 15 Cute Girlfriend ( 45) Erotic Amateur Girlfriends I wasn't aware you had professional girlfriends as well -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nagele at wildbit.com Sat Dec 28 17:22:35 2013 From: nagele at wildbit.com (Chris Nagele) Date: Sat, 28 Dec 2013 12:22:35 -0500 Subject: [OmniOS-discuss] Failing zfs send / receive In-Reply-To: <20131226185202.201e1488@sleipner.datanom.net> References: <20131226185202.201e1488@sleipner.datanom.net> Message-ID: Hi Michael, I tried those settings with no luck. I also tested network latency, routes, throughput with netperf, etc. The network side is perfectly fine with no packet loss over a long period of time. What I do see is ssh hanging for 10 seconds or so if I run commands over it. For instance, if I run "ssh -vvv host ls -l" a bunch of times it is usually very fast, but will hang every 30 times for several seconds. Due to the way our backups work we run a lot of remote ssh commands (100+ every 60 seconds). Is there something we could try in terms of increasing ssh performance? Or is there anything else I can look at to troubleshoot? Thanks for the help. Chris On Thu, Dec 26, 2013 at 12:52 PM, Michael Rasmussen wrote: > On Thu, 26 Dec 2013 12:31:30 -0500 > Chris Nagele wrote: > >> >> Any ideas what could cause this timeout or if it is something I can increase? >> > Do you have this config in sshd_config on the remote side: > GSSAPIAuthentication no > > If GSSAPIAuthentication is active you sometimes see timeouts cause by > the remote side waiting for GSSAPIAuthentication which by default first > will timeout after 20 sec. > > Other configs of interest: > LookupClientHostnames no > VerifyReverseMapping no > > -- > Hilsen/Regards > Michael Rasmussen > > Get my public GnuPG keys: > michael rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > Lost: gray and white female cat. Answers to electric can opener. > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From hasslerd at gmx.li Sat Dec 28 17:43:49 2013 From: hasslerd at gmx.li (Dominik Hassler) Date: Sat, 28 Dec 2013 18:43:49 +0100 Subject: [OmniOS-discuss] Failing zfs send / receive In-Reply-To: References: <20131226185202.201e1488@sleipner.datanom.net> Message-ID: <52BF0DD5.2010107@gmx.li> hi chris, have you ever checked if you run out of entropy? On 12/28/2013 06:22 PM, Chris Nagele wrote: > Hi Michael, > > I tried those settings with no luck. I also tested network latency, > routes, throughput with netperf, etc. The network side is perfectly > fine with no packet loss over a long period of time. > > What I do see is ssh hanging for 10 seconds or so if I run commands > over it. For instance, if I run "ssh -vvv host ls -l" a bunch of times > it is usually very fast, but will hang every 30 times for several > seconds. > > Due to the way our backups work we run a lot of remote ssh commands > (100+ every 60 seconds). Is there something we could try in terms of > increasing ssh performance? Or is there anything else I can look at to > troubleshoot? > > Thanks for the help. > > Chris > > On Thu, Dec 26, 2013 at 12:52 PM, Michael Rasmussen wrote: >> On Thu, 26 Dec 2013 12:31:30 -0500 >> Chris Nagele wrote: >> >>> >>> Any ideas what could cause this timeout or if it is something I can increase? >>> >> Do you have this config in sshd_config on the remote side: >> GSSAPIAuthentication no >> >> If GSSAPIAuthentication is active you sometimes see timeouts cause by >> the remote side waiting for GSSAPIAuthentication which by default first >> will timeout after 20 sec. >> >> Other configs of interest: >> LookupClientHostnames no >> VerifyReverseMapping no >> >> -- >> Hilsen/Regards >> Michael Rasmussen >> >> Get my public GnuPG keys: >> michael rasmussen cc >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E >> mir datanom net >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C >> mir miras org >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 >> -------------------------------------------------------------- >> Lost: gray and white female cat. Answers to electric can opener. >> >> _______________________________________________ >> 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xF9ECC6A5.asc Type: application/pgp-keys Size: 2686 bytes Desc: not available URL: From mir at miras.org Sat Dec 28 17:51:36 2013 From: mir at miras.org (Michael Rasmussen) Date: Sat, 28 Dec 2013 18:51:36 +0100 Subject: [OmniOS-discuss] Failing zfs send / receive In-Reply-To: References: <20131226185202.201e1488@sleipner.datanom.net> Message-ID: <20131228185136.3a52054a@sleipner.datanom.net> On Sat, 28 Dec 2013 12:22:35 -0500 Chris Nagele wrote: > > What I do see is ssh hanging for 10 seconds or so if I run commands > over it. For instance, if I run "ssh -vvv host ls -l" a bunch of times > it is usually very fast, but will hang every 30 times for several > seconds. > Is this seen when connecting to the same server or is it a generel observation? When it hangs is the server serving other requests at the same time? Does vmstat on the server show something when it hangs? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: Death is God's way of telling you not to be such a wise guy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nagele at wildbit.com Sat Dec 28 17:56:36 2013 From: nagele at wildbit.com (Chris Nagele) Date: Sat, 28 Dec 2013 12:56:36 -0500 Subject: [OmniOS-discuss] Failing zfs send / receive In-Reply-To: <20131228185136.3a52054a@sleipner.datanom.net> References: <20131226185202.201e1488@sleipner.datanom.net> <20131228185136.3a52054a@sleipner.datanom.net> Message-ID: How can I check if it runs out of entropy? It is connecting to the same server and nothing else. I assume it is always serving another request since it is so busy. The hard part is that it is random. Vmstat looked normal in terms of usage and swap. What else can I look for? Also, I will see if it has the same behavior connecting to other servers. Thanks! On Saturday, December 28, 2013, Michael Rasmussen wrote: > On Sat, 28 Dec 2013 12:22:35 -0500 > Chris Nagele > wrote: > > > > > What I do see is ssh hanging for 10 seconds or so if I run commands > > over it. For instance, if I run "ssh -vvv host ls -l" a bunch of times > > it is usually very fast, but will hang every 30 times for several > > seconds. > > > Is this seen when connecting to the same server or is it a generel > observation? > > When it hangs is the server serving other requests at the same time? > Does vmstat on the server show something when it hangs? > > -- > Hilsen/Regards > Michael Rasmussen > > Get my public GnuPG keys: > michael rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > /usr/games/fortune -es says: > Death is God's way of telling you not to be such a wise guy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagele at wildbit.com Sat Dec 28 21:12:31 2013 From: nagele at wildbit.com (Chris Nagele) Date: Sat, 28 Dec 2013 16:12:31 -0500 Subject: [OmniOS-discuss] Failing zfs send / receive In-Reply-To: References: <20131226185202.201e1488@sleipner.datanom.net> <20131228185136.3a52054a@sleipner.datanom.net> Message-ID: After some more testing I can see that it gets hung up here most of the time, but not every time: debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible) debug1: SSH2_MSG_KEXINIT sent I do have gssapi set to no in /etc/ssh/ssh_config on the client and in sshd_config on the server. Chris On Sat, Dec 28, 2013 at 12:56 PM, Chris Nagele wrote: > How can I check if it runs out of entropy? > > It is connecting to the same server and nothing else. I assume it is always > serving another request since it is so busy. The hard part is that it is > random. > > Vmstat looked normal in terms of usage and swap. What else can I look for? > > Also, I will see if it has the same behavior connecting to other servers. > > Thanks! > > > On Saturday, December 28, 2013, Michael Rasmussen wrote: >> >> On Sat, 28 Dec 2013 12:22:35 -0500 >> Chris Nagele wrote: >> >> > >> > What I do see is ssh hanging for 10 seconds or so if I run commands >> > over it. For instance, if I run "ssh -vvv host ls -l" a bunch of times >> > it is usually very fast, but will hang every 30 times for several >> > seconds. >> > >> Is this seen when connecting to the same server or is it a generel >> observation? >> >> When it hangs is the server serving other requests at the same time? >> Does vmstat on the server show something when it hangs? >> >> -- >> Hilsen/Regards >> Michael Rasmussen >> >> Get my public GnuPG keys: >> michael rasmussen cc >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E >> mir datanom net >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C >> mir miras org >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 >> -------------------------------------------------------------- >> /usr/games/fortune -es says: >> Death is God's way of telling you not to be such a wise guy. From mir at miras.org Sat Dec 28 21:19:23 2013 From: mir at miras.org (Michael Rasmussen) Date: Sat, 28 Dec 2013 22:19:23 +0100 Subject: [OmniOS-discuss] Failing zfs send / receive Message-ID: <201312282119.rBSLJaxJ026093@lists-il.int.omniti.net> Did you remember to restart SSH on the server? On Dec 28, 2013 10:12 PM, Chris Nagele wrote: > > After some more testing I can see that it gets hung up here most of > the time, but not every time: > > debug1: Failed to acquire GSS-API credentials for any mechanisms (No > credentials were supplied, or the credentials were unavailable or > inaccessible) > debug1: SSH2_MSG_KEXINIT sent > > I do have gssapi set to no in /etc/ssh/ssh_config on the client and in > sshd_config on the server. > > Chris > > On Sat, Dec 28, 2013 at 12:56 PM, Chris Nagele wrote: > > How can I check if it runs out of entropy? > > > > It is connecting to the same server and nothing else. I assume it is always > > serving another request since it is so busy. The hard part is that it is > > random. > > > > Vmstat looked normal in terms of usage and swap. What else can I look for? > > > > Also, I will see if it has the same behavior connecting to other servers. > > > > Thanks! > > > > > > On Saturday, December 28, 2013, Michael Rasmussen wrote: > >> > >> On Sat, 28 Dec 2013 12:22:35 -0500 > >> Chris Nagele wrote: > >> > >> > > >> > What I do see is ssh hanging for 10 seconds or so if I run commands > >> > over it. For instance, if I run "ssh -vvv host ls -l" a bunch of times > >> > it is usually very fast, but will hang every 30 times for several > >> > seconds. > >> > > >> Is this seen when connecting to the same server or is it a generel > >> observation? > >> > >> When it hangs is the server serving other requests at the same time? > >> Does vmstat on the server show something when it hangs? > >> > >> -- > >> Hilsen/Regards > >> Michael Rasmussen > >> > >> Get my public GnuPG keys: > >> michael rasmussen cc > >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > >> mir datanom net > >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > >> mir miras org > >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > >> -------------------------------------------------------------- > >> /usr/games/fortune -es says: > >> Death is God's way of telling you not to be such a wise guy. > > !DSPAM:52bf3ec258095089412099! > > From nagele at wildbit.com Sat Dec 28 21:21:02 2013 From: nagele at wildbit.com (Chris Nagele) Date: Sat, 28 Dec 2013 16:21:02 -0500 Subject: [OmniOS-discuss] Failing zfs send / receive In-Reply-To: <52bf406a.09d10e0a.026b.fffff6d6SMTPIN_ADDED_MISSING@mx.google.com> References: <52bf406a.09d10e0a.026b.fffff6d6SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Yes, I even rebooted the server to be sure. Is this line stating that it is still using gss-api? Chris On Sat, Dec 28, 2013 at 4:19 PM, Michael Rasmussen wrote: > Did you remember to restart SSH on the server? > > On Dec 28, 2013 10:12 PM, Chris Nagele wrote: >> >> After some more testing I can see that it gets hung up here most of >> the time, but not every time: >> >> debug1: Failed to acquire GSS-API credentials for any mechanisms (No >> credentials were supplied, or the credentials were unavailable or >> inaccessible) >> debug1: SSH2_MSG_KEXINIT sent >> >> I do have gssapi set to no in /etc/ssh/ssh_config on the client and in >> sshd_config on the server. >> >> Chris >> >> On Sat, Dec 28, 2013 at 12:56 PM, Chris Nagele wrote: >> > How can I check if it runs out of entropy? >> > >> > It is connecting to the same server and nothing else. I assume it is always >> > serving another request since it is so busy. The hard part is that it is >> > random. >> > >> > Vmstat looked normal in terms of usage and swap. What else can I look for? >> > >> > Also, I will see if it has the same behavior connecting to other servers. >> > >> > Thanks! >> > >> > >> > On Saturday, December 28, 2013, Michael Rasmussen wrote: >> >> >> >> On Sat, 28 Dec 2013 12:22:35 -0500 >> >> Chris Nagele wrote: >> >> >> >> > >> >> > What I do see is ssh hanging for 10 seconds or so if I run commands >> >> > over it. For instance, if I run "ssh -vvv host ls -l" a bunch of times >> >> > it is usually very fast, but will hang every 30 times for several >> >> > seconds. >> >> > >> >> Is this seen when connecting to the same server or is it a generel >> >> observation? >> >> >> >> When it hangs is the server serving other requests at the same time? >> >> Does vmstat on the server show something when it hangs? >> >> >> >> -- >> >> Hilsen/Regards >> >> Michael Rasmussen >> >> >> >> Get my public GnuPG keys: >> >> michael rasmussen cc >> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E >> >> mir datanom net >> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C >> >> mir miras org >> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 >> >> -------------------------------------------------------------- >> >> /usr/games/fortune -es says: >> >> Death is God's way of telling you not to be such a wise guy. >> >> !DSPAM:52bf3ec258095089412099! >> >> From nagele at wildbit.com Sat Dec 28 22:13:54 2013 From: nagele at wildbit.com (Chris Nagele) Date: Sat, 28 Dec 2013 17:13:54 -0500 Subject: [OmniOS-discuss] Failing zfs send / receive In-Reply-To: References: <52bf406a.09d10e0a.026b.fffff6d6SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Regarding entropy, this seems crazy: Random number device statistics: 9996376040162949185 bytes generated for /dev/random 6821614472103628244 bytes read from /dev/random cache 5345995122346756435 bytes generated for /dev/urandom On Sat, Dec 28, 2013 at 4:21 PM, Chris Nagele wrote: > Yes, I even rebooted the server to be sure. Is this line stating that > it is still using gss-api? > > Chris > > On Sat, Dec 28, 2013 at 4:19 PM, Michael Rasmussen wrote: >> Did you remember to restart SSH on the server? >> >> On Dec 28, 2013 10:12 PM, Chris Nagele wrote: >>> >>> After some more testing I can see that it gets hung up here most of >>> the time, but not every time: >>> >>> debug1: Failed to acquire GSS-API credentials for any mechanisms (No >>> credentials were supplied, or the credentials were unavailable or >>> inaccessible) >>> debug1: SSH2_MSG_KEXINIT sent >>> >>> I do have gssapi set to no in /etc/ssh/ssh_config on the client and in >>> sshd_config on the server. >>> >>> Chris >>> >>> On Sat, Dec 28, 2013 at 12:56 PM, Chris Nagele wrote: >>> > How can I check if it runs out of entropy? >>> > >>> > It is connecting to the same server and nothing else. I assume it is always >>> > serving another request since it is so busy. The hard part is that it is >>> > random. >>> > >>> > Vmstat looked normal in terms of usage and swap. What else can I look for? >>> > >>> > Also, I will see if it has the same behavior connecting to other servers. >>> > >>> > Thanks! >>> > >>> > >>> > On Saturday, December 28, 2013, Michael Rasmussen wrote: >>> >> >>> >> On Sat, 28 Dec 2013 12:22:35 -0500 >>> >> Chris Nagele wrote: >>> >> >>> >> > >>> >> > What I do see is ssh hanging for 10 seconds or so if I run commands >>> >> > over it. For instance, if I run "ssh -vvv host ls -l" a bunch of times >>> >> > it is usually very fast, but will hang every 30 times for several >>> >> > seconds. >>> >> > >>> >> Is this seen when connecting to the same server or is it a generel >>> >> observation? >>> >> >>> >> When it hangs is the server serving other requests at the same time? >>> >> Does vmstat on the server show something when it hangs? >>> >> >>> >> -- >>> >> Hilsen/Regards >>> >> Michael Rasmussen >>> >> >>> >> Get my public GnuPG keys: >>> >> michael rasmussen cc >>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E >>> >> mir datanom net >>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C >>> >> mir miras org >>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 >>> >> -------------------------------------------------------------- >>> >> /usr/games/fortune -es says: >>> >> Death is God's way of telling you not to be such a wise guy. >>> >>> !DSPAM:52bf3ec258095089412099! >>> >>> From chip at innovates.com Mon Dec 30 19:35:34 2013 From: chip at innovates.com (Schweiss, Chip) Date: Mon, 30 Dec 2013 13:35:34 -0600 Subject: [OmniOS-discuss] Repeated disk offline messages in system log Message-ID: I'm getting these messages constantly. This disk died and was removed from the system. Dec 30 13:07:29 hcp-iops1 genunix: [ID 408114 kern.info] /scsi_vhci/disk at g50025385a00ec254 (sd151) offline Dec 30 13:12:25 hcp-iops1 last message repeated 131 times Dec 30 13:12:27 hcp-iops1 genunix: [ID 408114 kern.info] /scsi_vhci/disk at g50025385a00ec254 (sd151) offline Dec 30 13:19:06 hcp-iops1 last message repeated 255 times Dec 30 13:19:09 hcp-iops1 genunix: [ID 408114 kern.info] /scsi_vhci/disk at g50025385a00ec254 (sd151) offline How do I get this to stop? Thanks! -Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagele at wildbit.com Mon Dec 30 19:52:09 2013 From: nagele at wildbit.com (Chris Nagele) Date: Mon, 30 Dec 2013 14:52:09 -0500 Subject: [OmniOS-discuss] Failing zfs send / receive In-Reply-To: References: <52bf406a.09d10e0a.026b.fffff6d6SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Just a heads up that we resolved this. It ended up being a network issue, even though ping/traceroute was not showing any problems. We asked our data center to change the routes away from NTT and the timeouts went away. So strange, but it must have been something between the two data centers that caused the issue. Chris On Sat, Dec 28, 2013 at 5:13 PM, Chris Nagele wrote: > Regarding entropy, this seems crazy: > > Random number device statistics: > 9996376040162949185 bytes generated for /dev/random > 6821614472103628244 bytes read from /dev/random cache > 5345995122346756435 bytes generated for /dev/urandom > > > > On Sat, Dec 28, 2013 at 4:21 PM, Chris Nagele wrote: >> Yes, I even rebooted the server to be sure. Is this line stating that >> it is still using gss-api? >> >> Chris >> >> On Sat, Dec 28, 2013 at 4:19 PM, Michael Rasmussen wrote: >>> Did you remember to restart SSH on the server? >>> >>> On Dec 28, 2013 10:12 PM, Chris Nagele wrote: >>>> >>>> After some more testing I can see that it gets hung up here most of >>>> the time, but not every time: >>>> >>>> debug1: Failed to acquire GSS-API credentials for any mechanisms (No >>>> credentials were supplied, or the credentials were unavailable or >>>> inaccessible) >>>> debug1: SSH2_MSG_KEXINIT sent >>>> >>>> I do have gssapi set to no in /etc/ssh/ssh_config on the client and in >>>> sshd_config on the server. >>>> >>>> Chris >>>> >>>> On Sat, Dec 28, 2013 at 12:56 PM, Chris Nagele wrote: >>>> > How can I check if it runs out of entropy? >>>> > >>>> > It is connecting to the same server and nothing else. I assume it is always >>>> > serving another request since it is so busy. The hard part is that it is >>>> > random. >>>> > >>>> > Vmstat looked normal in terms of usage and swap. What else can I look for? >>>> > >>>> > Also, I will see if it has the same behavior connecting to other servers. >>>> > >>>> > Thanks! >>>> > >>>> > >>>> > On Saturday, December 28, 2013, Michael Rasmussen wrote: >>>> >> >>>> >> On Sat, 28 Dec 2013 12:22:35 -0500 >>>> >> Chris Nagele wrote: >>>> >> >>>> >> > >>>> >> > What I do see is ssh hanging for 10 seconds or so if I run commands >>>> >> > over it. For instance, if I run "ssh -vvv host ls -l" a bunch of times >>>> >> > it is usually very fast, but will hang every 30 times for several >>>> >> > seconds. >>>> >> > >>>> >> Is this seen when connecting to the same server or is it a generel >>>> >> observation? >>>> >> >>>> >> When it hangs is the server serving other requests at the same time? >>>> >> Does vmstat on the server show something when it hangs? >>>> >> >>>> >> -- >>>> >> Hilsen/Regards >>>> >> Michael Rasmussen >>>> >> >>>> >> Get my public GnuPG keys: >>>> >> michael rasmussen cc >>>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E >>>> >> mir datanom net >>>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C >>>> >> mir miras org >>>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 >>>> >> -------------------------------------------------------------- >>>> >> /usr/games/fortune -es says: >>>> >> Death is God's way of telling you not to be such a wise guy. >>>> >>>> !DSPAM:52bf3ec258095089412099! >>>> >>>>