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: <CAHDYqcrLFMSsbiY5hrpeL=usWrSyErhHejX7zPUyASn358b0CA@mail.gmail.com>
References: <CAHDYqcrLFMSsbiY5hrpeL=usWrSyErhHejX7zPUyASn358b0CA@mail.gmail.com>
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 <emunch at utmi.in> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131202/fe2b3543/attachment-0001.html>

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: <CAHDYqcrLFMSsbiY5hrpeL=usWrSyErhHejX7zPUyASn358b0CA@mail.gmail.com>
References: <CAHDYqcrLFMSsbiY5hrpeL=usWrSyErhHejX7zPUyASn358b0CA@mail.gmail.com>
Message-ID: <B3452613-0C4C-4CD2-9B32-3358ADB0849F@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 <emunch at utmi.in> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131202/8a7686b8/attachment.html>

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: <mailman.13359.1385975693.5504.omnios-discuss@lists.omniti.com>
	<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 <skiselkov.ml at gmail.com>
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: <mailman.13359.1385975693.5504.omnios-discuss@lists.omniti.com>	<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: <B3452613-0C4C-4CD2-9B32-3358ADB0849F@mm.st>
References: <CAHDYqcrLFMSsbiY5hrpeL=usWrSyErhHejX7zPUyASn358b0CA@mail.gmail.com>
	<B3452613-0C4C-4CD2-9B32-3358ADB0849F@mm.st>
Message-ID: <CA+QY2RSFCZ=Tu=-6+kFyqxPNvW6Gw=o=L2tc0RBpybBnOgZ7SQ@mail.gmail.com>

On Mon, Dec 2, 2013 at 4:26 AM, Piers Dawson-Damer <piers at mm.st> 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: <mailman.13379.1385995183.5504.omnios-discuss@lists.omniti.com>
References: <mailman.13379.1385995183.5504.omnios-discuss@lists.omniti.com>
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 <piers at mm.st>
To: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash
Message-ID: <B3452613-0C4C-4CD2-9B32-3358ADB0849F at mm.st>
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 <emunch at utmi.in> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131202/8a7686b8/attachment-0001.html>

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

Message: 2
Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET)
From: Hafiz Rafibeyli <rafibeyli at gmail.com>
To: omnios-discuss <omnios-discuss at lists.omniti.com>
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 <skiselkov.ml at gmail.com>
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 <skiselkov.ml at gmail.com>
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 <rafibeyli at gmail.com>
To: omnios-discuss <omnios-discuss at lists.omniti.com>
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 <skiselkov.ml at gmail.com>
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: <mailman.13379.1385995183.5504.omnios-discuss@lists.omniti.com>
	<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 <DEFAULT cyl 8872 alt 2 hd 255 sec 63>
          /pci at 7b,0/pci1022,7458 at 11/pci1000,3060 at 2/sd at 0,0
       1. c6t600D0230006B66680C50AB7821F0E900d0 <ADVUNI-OXYGENRAID
416F4-347B-3.41TB>
          /scsi_vhci/disk at g600d0230006b66680c50ab7821f0e900
       2. c6t600D0230006C1C4C0C50BE5BC9D49100d0 <ADVUNI-OXYGENRAID
416F4-347B-3.41TB>
          /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 <piers at mm.st>
> To: omnios-discuss at lists.omniti.com
> Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash
> Message-ID: <B3452613-0C4C-4CD2-9B32-3358ADB0849F at mm.st>
> 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 <emunch at utmi.in> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131202/8a7686b8/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET)
> From: Hafiz Rafibeyli <rafibeyli at gmail.com>
> To: omnios-discuss <omnios-discuss at lists.omniti.com>
> 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 <skiselkov.ml at gmail.com>
> 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: <mailman.13387.1385996373.5504.omnios-discuss@lists.omniti.com>
References: <mailman.13387.1385996373.5504.omnios-discuss@lists.omniti.com>
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 <SEAGATE-ST33000650SS-0004-2.73TB>
          /scsi_vhci/disk at g5000c50041e9d9a7
       1. c1t5000C50041F1A5EFd0 <SEAGATE-ST33000650SS-0004-2.73TB>
          /scsi_vhci/disk at g5000c50041f1a5ef
       2. c1t5000C50055A62F57d0 <SEAGATE-ST33000650SS-0004-2.73TB>
          /scsi_vhci/disk at g5000c50055a62f57
       3. c1t5000C50055A607E3d0 <SEAGATE-ST33000650SS-0004-2.73TB>
          /scsi_vhci/disk at g5000c50055a607e3
       4. c1t5000C50055A628EFd0 <SEAGATE-ST33000650SS-0004-2.73TB>
          /scsi_vhci/disk at g5000c50055a628ef
       5. c1t5000C5004253FF87d0 <SEAGATE-ST33000650SS-0004-2.73TB>
          /scsi_vhci/disk at g5000c5004253ff87
       6. c1t5000C5005600A6B3d0 <SEAGATE-ST33000650SS-0004-2.73TB>
          /scsi_vhci/disk at g5000c5005600a6b3
       7. c1t5000C5005600B43Bd0 <SEAGATE-ST33000650SS-0004-2.73TB>
          /scsi_vhci/disk at g5000c5005600b43b
       8. c1t5001517BB2AFB592d0 <ATA-INTEL SSDSC2CW12-400i-111.79GB>
          /scsi_vhci/disk at g5001517bb2afb592
       9. c1t5001517BB2747BE7d0 <ATA-SSDSA2SH032G1GN-8860-29.80GB>
          /scsi_vhci/disk at g5001517bb2747be7
      10. c1t5001517803D007D8d0 <ATA-INTEL SSDSC2CW12-400i-111.79GB>
          /scsi_vhci/disk at g5001517803d007d8
      11. c1t5001517959627219d0 <ATA-SSDSA2SH032G1GN-8860-29.80GB>
          /scsi_vhci/disk at g5001517959627219
      12. c3t1d0 <ATA-STECMACH16M-0299 cyl 7785 alt 2 hd 224 sec 56>
          /pci at 0,0/pci15d9,100 at 1f,2/disk at 1,0
      13. c3t2d0 <ATA-STECMACH16M-0299 cyl 7785 alt 2 hd 224 sec 56>
          /pci at 0,0/pci15d9,100 at 1f,2/disk at 2,0
      14. c4t5000C5002BD75C05d0 <HP-EG0300FAWHV-HPDE-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w5000c5002bd75c05,0
      15. c4t5000CCA01505A321d0 <HP-DG0300FARVV-HPD8-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w5000cca01505a321,0
      16. c4t5000CCA0150597A5d0 <HP-DG0300FARVV-HPD8-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w5000cca0150597a5,0
      17. c4t500000E1168BB382d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w500000e1168bb382,0
      18. c4t500000E11693F232d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w500000e11693f232,0
      19. c4t500000E11696D5A2d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w500000e11696d5a2,0
      20. c4t500000E116974FB2d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w500000e116974fb2,0
      21. c4t50000392C8008B7Ed0 <HP-EG0300FBDSP-HPD1-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,400 at 0/iport at f/disk at w50000392c8008b7e,0
      22. c6t5000C5002BD75C06d0 <HP-EG0300FAWHV-HPDE-279.40GB>
          /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w5000c5002bd75c06,0
      23. c6t5000CCA01505A322d0 <HP-DG0300FARVV-HPD8-279.40GB>
          /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w5000cca01505a322,0
      24. c6t5000CCA0150597A6d0 <HP-DG0300FARVV-HPD8-279.40GB>
          /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w5000cca0150597a6,0
      25. c6t500000E1168BB383d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w500000e1168bb383,0
      26. c6t500000E11693F233d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w500000e11693f233,0
      27. c6t500000E11696D5A3d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w500000e11696d5a3,0
      28. c6t500000E116974FB3d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,3410 at 9/pci15d9,400 at 0/iport at f/disk at w500000e116974fb3,0
      29. c6t50000392C8008B7Fd0 <HP-EG0300FBDSP-HPD1-279.40GB>
          /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 <esproul at omniti.com>
To: Piers Dawson-Damer <piers at mm.st>
Cc: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash
Message-ID:
	<CA+QY2RSFCZ=Tu=-6+kFyqxPNvW6Gw=o=L2tc0RBpybBnOgZ7SQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 2, 2013 at 4:26 AM, Piers Dawson-Damer <piers at mm.st> 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 <rafibeyli at gmail.com>
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 <piers at mm.st>
To: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash
Message-ID: <B3452613-0C4C-4CD2-9B32-3358ADB0849F at mm.st>
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 <emunch at utmi.in> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131202/8a7686b8/attachment-0001.html>

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

Message: 2
Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET)
From: Hafiz Rafibeyli <rafibeyli at gmail.com>
To: omnios-discuss <omnios-discuss at lists.omniti.com>
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 <skiselkov.ml at gmail.com>
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 <skiselkov.ml at gmail.com>
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 <rafibeyli at gmail.com>
To: omnios-discuss <omnios-discuss at lists.omniti.com>
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 <skiselkov.ml at gmail.com>
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 <skiselkov.ml at gmail.com>
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 <DEFAULT cyl 8872 alt 2 hd 255 sec 63>
          /pci at 7b,0/pci1022,7458 at 11/pci1000,3060 at 2/sd at 0,0
       1. c6t600D0230006B66680C50AB7821F0E900d0 <ADVUNI-OXYGENRAID
416F4-347B-3.41TB>
          /scsi_vhci/disk at g600d0230006b66680c50ab7821f0e900
       2. c6t600D0230006C1C4C0C50BE5BC9D49100d0 <ADVUNI-OXYGENRAID
416F4-347B-3.41TB>
          /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 <piers at mm.st>
> To: omnios-discuss at lists.omniti.com
> Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash
> Message-ID: <B3452613-0C4C-4CD2-9B32-3358ADB0849F at mm.st>
> 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 <emunch at utmi.in> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131202/8a7686b8/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET)
> From: Hafiz Rafibeyli <rafibeyli at gmail.com>
> To: omnios-discuss <omnios-discuss at lists.omniti.com>
> 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 <skiselkov.ml at gmail.com>
> 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: <mailman.13379.1385995183.5504.omnios-discuss@lists.omniti.com>
	<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 <HP-EG0300FAWHV-HPDE-279.40GB>

/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 <piers at mm.st>
> To: omnios-discuss at lists.omniti.com
> Subject: Re: [OmniOS-discuss] Re-installing OmniOS after Crash
> Message-ID: <B3452613-0C4C-4CD2-9B32-3358ADB0849F at mm.st>
> 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 <emunch at utmi.in> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131202/8a7686b8/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 2 Dec 2013 14:08:04 +0200 (EET)
> From: Hafiz Rafibeyli <rafibeyli at gmail.com>
> To: omnios-discuss <omnios-discuss at lists.omniti.com>
> 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 <skiselkov.ml at gmail.com>
> 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: <CA+QY2RSFCZ=Tu=-6+kFyqxPNvW6Gw=o=L2tc0RBpybBnOgZ7SQ@mail.gmail.com>
References: <CAHDYqcrLFMSsbiY5hrpeL=usWrSyErhHejX7zPUyASn358b0CA@mail.gmail.com>	<B3452613-0C4C-4CD2-9B32-3358ADB0849F@mm.st>
	<CA+QY2RSFCZ=Tu=-6+kFyqxPNvW6Gw=o=L2tc0RBpybBnOgZ7SQ@mail.gmail.com>
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 <piers at mm.st> 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: <mailman.13392.1385996847.5504.omnios-discuss@lists.omniti.com>
	<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 <HP-EG0300FAWHV-HPDE-279.40GB>

/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: <mailman.13392.1385996847.5504.omnios-discuss@lists.omniti.com>	<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: <mailman.13392.1385996847.5504.omnios-discuss@lists.omniti.com>
	<154455286.84861.1386058128380.JavaMail.zimbra@cantekstil.com.tr>
	<1251946144.85273.1386058387233.JavaMail.zimbra@cantekstil.com.tr>
	<529DB556.3080605@gmail.com>
Message-ID: <etPan.529ddadf.238e1f29.241@Marvin.local>

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    <HP      Ultrium 6-SCSI  >

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131203/6113cb56/attachment-0001.html>

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 <ATA-ST2000NM0033-9ZM-0001-1.82TB>
          /scsi_vhci/disk at g5000c5004feb5cd4
       1. c1t5000C5004FEB205Ad0 <ATA-ST2000NM0033-9ZM-0001-1.82TB>
          /scsi_vhci/disk at g5000c5004feb205a
       2. c1t5000C5004FEBCDA1d0 <ATA-ST2000NM0033-9ZM-0001-1.82TB>
          /scsi_vhci/disk at g5000c5004febcda1
       3. c1t5000C5004FED9BE6d0 <ATA-ST2000NM0033-9ZM-0001-1.82TB>
          /scsi_vhci/disk at g5000c5004fed9be6
       4. c1t5000C5004FF4A4AEd0 <ATA-ST2000NM0033-9ZM-0001-1.82TB>
          /scsi_vhci/disk at g5000c5004ff4a4ae
       5. c1t5000C5004FF4E0F9d0 <ATA-ST2000NM0033-9ZM-0001-1.82TB>
          /scsi_vhci/disk at g5000c5004ff4e0f9
       6. c1t50000393DB700B6Ad0 <ATA-TOSHIBA MK2002TS-MT2A-1.82TB>
          /scsi_vhci/disk at g50000393db700b6a
       7. c1t50000393DB700B6Bd0 <ATA-TOSHIBA MK2002TS-MT2A-1.82TB>
          /scsi_vhci/disk at g50000393db700b6b
       8. c1t50000393DB700B68d0 <ATA-TOSHIBA MK2002TS-MT2A-1.82TB>
          /scsi_vhci/disk at g50000393db700b68
       9. c1t50000393DB700B69d0 <ATA-TOSHIBA MK2002TS-MT2A-1.82TB>
          /scsi_vhci/disk at g50000393db700b69
      10. c1t500003944B703F9Bd0 <ATA-TOSHIBA MK2002TS-MT4A-1.82TB>
          /scsi_vhci/disk at g500003944b703f9b
      11. c1t500003944B703F9Dd0 <ATA-TOSHIBA MK2002TS-MT4A-1.82TB>
          /scsi_vhci/disk at g500003944b703f9d
      12. c1t500003944B703F9Fd0 <ATA-TOSHIBA MK2002TS-MT4A-1.82TB>
          /scsi_vhci/disk at g500003944b703f9f
      13. c1t500003944B783D3Fd0 <ATA-TOSHIBA MK2002TS-MT4A-1.82TB>
          /scsi_vhci/disk at g500003944b783d3f
      14. c1t500003944B80451Ed0 <ATA-TOSHIBA MK2002TS-MT4A-1.82TB>
          /scsi_vhci/disk at g500003944b80451e
      15. c1t500003944B80451Fd0 <ATA-TOSHIBA MK2002TS-MT4A-1.82TB>
          /scsi_vhci/disk at g500003944b80451f
      16. c1t500003944B704306d0 <ATA-TOSHIBA MK2002TS-MT4A-1.82TB>
          /scsi_vhci/disk at g500003944b704306
      17. c1t500003944B804521d0 <ATA-TOSHIBA MK2002TS-MT4A-1.82TB>
          /scsi_vhci/disk at g500003944b804521
      18. c1t500003944B804534d0 <ATA-TOSHIBA MK2002TS-MT4A-1.82TB>
          /scsi_vhci/disk at g500003944b804534
      19. c3t0d0 <Unknown-Unknown-0001 cyl 1953 alt 2 hd 255 sec 63>
          /pci at 0,0/pci15d9,100 at 1f,2/disk at 0,0
      20. c3t1d0 <ATA-SATASSD-.02c cyl 1953 alt 2 hd 255 sec 63>
          /pci at 0,0/pci15d9,100 at 1f,2/disk at 1,0
      21. c4t500000E1168BB382d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,691 at 0/iport at f/disk at w500000e1168bb382,0
      22. c4t500000E11693F232d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,691 at 0/iport at f/disk at w500000e11693f232,0
      23. c4t500000E11696D5A2d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /pci at 0,0/pci8086,340e at 7/pci15d9,691 at 0/iport at f/disk at w500000e11696d5a2,0
      24. c4t500000E116974FB2d0 <HP-EG0300FARTT-HPDA-279.40GB>
          /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: <CAHDYqcrLFMSsbiY5hrpeL=usWrSyErhHejX7zPUyASn358b0CA@mail.gmail.com>
	<B3452613-0C4C-4CD2-9B32-3358ADB0849F@mm.st>
	<CA+QY2RSFCZ=Tu=-6+kFyqxPNvW6Gw=o=L2tc0RBpybBnOgZ7SQ@mail.gmail.com>
	<529D82D2.5080900@gnaa.net>
Message-ID: <CA+QY2RTy7+3gNdCaUBrjOsqoJ0iY03-U9RKiP-eHHmCUbf=HEA@mail.gmail.com>

On Tue, Dec 3, 2013 at 2:05 AM, Geoff Nordli <geoffn at gnaa.net> 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'>
            <service_fmri
-               value='svc:/system/system-log:default'/>
+               value='svc:/system/system-log'/>
        </dependency>

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: <CA+QY2RT1j6VrRWsXvqu-vLuUWbSnLtDfKbVC4Msp-NkKeE2-Mg@mail.gmail.com>

On Tue, Dec 3, 2013 at 3:31 PM, Paul B. Henson <henson at acm.org> 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'>
>             <service_fmri
> -               value='svc:/system/system-log:default'/>
> +               value='svc:/system/system-log'/>
>         </dependency>
>
> 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: <CAHDYqcoER5aPmJgSRbwsdphKS__T-NJodo2-MhY_JPFUvOGZag@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131204/ae8c018f/attachment-0001.html>

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: <CA+QY2RT1j6VrRWsXvqu-vLuUWbSnLtDfKbVC4Msp-NkKeE2-Mg@mail.gmail.com>
References: <0a7a01ceef9f$024fdd30$06ef9790$@acm.org>	<0a7c01ceefa0$5c71c9d0$15555d70$@acm.org>	<20131203203115.GB4044@bender.unx.csupomona.edu>
	<CA+QY2RT1j6VrRWsXvqu-vLuUWbSnLtDfKbVC4Msp-NkKeE2-Mg@mail.gmail.com>
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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>

>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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
References: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
Message-ID: <20131206015946.06867a39@sleipner.datanom.net>

On Thu, 5 Dec 2013 17:00:18 -0500
Eric Sproul <esproul at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
<wichert> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131206/4c83b5bc/attachment.bin>

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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<20131206015946.06867a39@sleipner.datanom.net>
Message-ID: <20131206032642.158b351f@sleipner.datanom.net>

On Fri, 6 Dec 2013 01:59:46 +0100
Michael Rasmussen <mir at miras.org> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131206/c2bc323e/attachment.bin>

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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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 <mir at miras.org> 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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>	<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: <DUB407-EAS105D5BB12C10CA7B72F11D9E2D60@phx.gbl>

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" <henson at acm.org>
Sent: 6 December 2013 03:38
To: "'Chris Nehren'" <cnehren+omnios-discuss at omniti.com>
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: <alpine.GSO.2.00.1312061031490.6377@areb.pvgehf-vg.arg>


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: <CAJjvXiEb3Rz3zA8R5fg7+Gvks6bPneUQkW35eaS3tk65nrgxjg@mail.gmail.com>
References: <52A14F24.7080308@gmail.com>
	<CAJjvXiEb3Rz3zA8R5fg7+Gvks6bPneUQkW35eaS3tk65nrgxjg@mail.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 <mahrens at delphix.com <mailto:mahrens at delphix.com>>
> 
> Date:   Tue Nov 26 13:47:33 2013 -0500
> 
> 
>     4347 ZPL can use dmu_tx_assign(TXG_WAIT)
> 
>     Reviewed by: George Wilson <george.wilson at delphix.com
> <mailto:george.wilson at delphix.com>>
> 
>     Reviewed by: Adam Leventhal <ahl at delphix.com <mailto:ahl at delphix.com>>
> 
>     Reviewed by: Dan McDonald <danmcd at nexenta.com
> <mailto:danmcd at nexenta.com>>
> 
>     Reviewed by: Boris Protopopov <boris.protopopov at nexenta.com
> <mailto:boris.protopopov at nexenta.com>>
> 
>     Approved by: Dan McDonald <danmcd at nexenta.com
> <mailto:danmcd at nexenta.com>>

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: <alpine.GSO.2.00.1312061031490.6377@areb.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1312061031490.6377@areb.pvgehf-vg.arg>
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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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: <alpine.GSO.2.00.1312061031490.6377@areb.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1312061031490.6377@areb.pvgehf-vg.arg>
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: <CA+QY2RQvot+FxNK-ctmEQqNHs4tZ2CZj3QQ_Nj4nfDnmCqg8Sg@mail.gmail.com>

On Fri, Dec 6, 2013 at 5:40 AM, Saso Kiselkov <skiselkov.ml at gmail.com> 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: <alpine.GSO.2.00.1312061031490.6377@areb.pvgehf-vg.arg>
	<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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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: <alpine.GSO.2.00.1312061031490.6377@areb.pvgehf-vg.arg>
	<20131206144849.GK2078@eschaton.local>
	<20131206151343.GL2078@eschaton.local>
Message-ID: <alpine.GSO.2.00.1312061520240.21005@areb.pvgehf-vg.arg>


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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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: <alpine.GSO.2.00.1312061520240.21005@areb.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1312061031490.6377@areb.pvgehf-vg.arg>
	<20131206144849.GK2078@eschaton.local>
	<20131206151343.GL2078@eschaton.local>
	<alpine.GSO.2.00.1312061520240.21005@areb.pvgehf-vg.arg>
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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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:

  <nfs:/home/nfsadmin,1020# pkg install -v incorporation/jeos/omnios-userland at 11,5.11-0.151006
             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:

  <nfs:/var/tmp,1007# /usr/bin/pkg update -nv --be-name=omnios-r151008
  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"

From mahrens at delphix.com  Fri Dec  6 06:31:38 2013
From: mahrens at delphix.com (Matthew Ahrens)
Date: Thu, 5 Dec 2013 22:31:38 -0800
Subject: [OmniOS-discuss] [zfs] 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: <CAJjvXiEb3Rz3zA8R5fg7+Gvks6bPneUQkW35eaS3tk65nrgxjg@mail.gmail.com>

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 <mahrens at delphix.com>

Date:   Tue Nov 26 13:47:33 2013 -0500


    4347 ZPL can use dmu_tx_assign(TXG_WAIT)

    Reviewed by: George Wilson <george.wilson at delphix.com>

    Reviewed by: Adam Leventhal <ahl at delphix.com>

    Reviewed by: Dan McDonald <danmcd at nexenta.com>

    Reviewed by: Boris Protopopov <boris.protopopov at nexenta.com>

    Approved by: Dan McDonald <danmcd at nexenta.com>


On Thu, Dec 5, 2013 at 8:14 PM, Saso Kiselkov <skiselkov.ml at gmail.com>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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131205/fbb7d160/attachment-0001.html>

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: <CA+QY2RQvot+FxNK-ctmEQqNHs4tZ2CZj3QQ_Nj4nfDnmCqg8Sg@mail.gmail.com>
References: <52A14F24.7080308@gmail.com>
	<8FBCE2ED-CD72-4008-A293-CAFD97AC4870@Logan.com>
	<52A1A9AD.7030901@gmail.com>
	<CA+QY2RQvot+FxNK-ctmEQqNHs4tZ2CZj3QQ_Nj4nfDnmCqg8Sg@mail.gmail.com>
Message-ID: <CA+QY2RQeUgrsUhsgEQbYGTbXf_NP=zUx3GM+NaBveefv9RNdOw@mail.gmail.com>

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: <CA+QY2RQeUgrsUhsgEQbYGTbXf_NP=zUx3GM+NaBveefv9RNdOw@mail.gmail.com>
References: <52A14F24.7080308@gmail.com>	<8FBCE2ED-CD72-4008-A293-CAFD97AC4870@Logan.com>	<52A1A9AD.7030901@gmail.com>	<CA+QY2RQvot+FxNK-ctmEQqNHs4tZ2CZj3QQ_Nj4nfDnmCqg8Sg@mail.gmail.com>
	<CA+QY2RQeUgrsUhsgEQbYGTbXf_NP=zUx3GM+NaBveefv9RNdOw@mail.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>
	<CA+QY2RQvot+FxNK-ctmEQqNHs4tZ2CZj3QQ_Nj4nfDnmCqg8Sg@mail.gmail.com>
	<CA+QY2RQeUgrsUhsgEQbYGTbXf_NP=zUx3GM+NaBveefv9RNdOw@mail.gmail.com>
	<52A23B2F.4060906@gmail.com>
Message-ID: <CA+QY2RRH8qtiOAvD_+9_=WM636WPd7iqXKzYcS21LWH6LiOMtA@mail.gmail.com>

On Fri, Dec 6, 2013 at 4:01 PM, Saso Kiselkov <skiselkov.ml at gmail.com> 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: <CA+QY2RQvKneuUgKZXBRax-xn0KoW15gTnM4tjUGQ1WGUoCobEA@mail.gmail.com>

On Fri, Dec 6, 2013 at 4:38 PM, Ask Bj?rn Hansen <ask at apache.org> 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: <CA+QY2RQvKneuUgKZXBRax-xn0KoW15gTnM4tjUGQ1WGUoCobEA@mail.gmail.com>
References: <2ED645DC-CB49-482A-AF25-4923362C24EA@apache.org>
	<CA+QY2RQvKneuUgKZXBRax-xn0KoW15gTnM4tjUGQ1WGUoCobEA@mail.gmail.com>
Message-ID: <63B9EDEA-572E-4881-9116-A9E9EC8FEF8D@apache.org>


On Dec 6, 2013, at 13:44 , Eric Sproul <esproul at omniti.com> 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>
	<CA+QY2RQvKneuUgKZXBRax-xn0KoW15gTnM4tjUGQ1WGUoCobEA@mail.gmail.com>
	<63B9EDEA-572E-4881-9116-A9E9EC8FEF8D@apache.org>
Message-ID: <BC2E0FBF-BB11-42C5-8210-0CF189EF15A5@apache.org>


On Dec 6, 2013, at 16:09 , Ask Bj?rn Hansen <ask at apache.org> 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: <BC2E0FBF-BB11-42C5-8210-0CF189EF15A5@apache.org>
References: <2ED645DC-CB49-482A-AF25-4923362C24EA@apache.org>
	<CA+QY2RQvKneuUgKZXBRax-xn0KoW15gTnM4tjUGQ1WGUoCobEA@mail.gmail.com>
	<63B9EDEA-572E-4881-9116-A9E9EC8FEF8D@apache.org>
	<BC2E0FBF-BB11-42C5-8210-0CF189EF15A5@apache.org>
Message-ID: <CA+QY2RQYSao8gu9p-YAnYevjJjrGj6CWH3_krwJc=iiv3vvPwg@mail.gmail.com>

On Friday, December 6, 2013, Ask Bj?rn Hansen wrote:

>
> On Dec 6, 2013, at 16:09 , Ask Bj?rn Hansen <ask at apache.org <javascript:;>>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131206/2a586af6/attachment.html>

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: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>

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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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 <vab at bb-c.de> 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:
> 
>  <nfs:/home/nfsadmin,1020# pkg install -v incorporation/jeos/omnios-userland at 11,5.11-0.151006
>             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:
> 
>  <nfs:/var/tmp,1007# /usr/bin/pkg update -nv --be-name=omnios-r151008
>  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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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 <robin at coraid.com> 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 <vab at bb-c.de> 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:
>> 
>> <nfs:/home/nfsadmin,1020# pkg install -v incorporation/jeos/omnios-userland at 11,5.11-0.151006
>>            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:
>> 
>> <nfs:/var/tmp,1007# /usr/bin/pkg update -nv --be-name=omnios-r151008
>> 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: <CA+QY2RRcb1GKx9iGuEbW2p8H1es9woEz-_0hRqgxs+8ojCmxhQ@mail.gmail.com>

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 <javascript:;>
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131208/af0ed20b/attachment.html>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131208/636f5aeb/attachment.html>

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: <CA+QY2RRcb1GKx9iGuEbW2p8H1es9woEz-_0hRqgxs+8ojCmxhQ@mail.gmail.com>
References: <20131208002805.GA2153@lab.pobox.com>
	<CA+QY2RRcb1GKx9iGuEbW2p8H1es9woEz-_0hRqgxs+8ojCmxhQ@mail.gmail.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: <CA+QY2RRcb1GKx9iGuEbW2p8H1es9woEz-_0hRqgxs+8ojCmxhQ@mail.gmail.com>
References: <20131208002805.GA2153@lab.pobox.com>
	<CA+QY2RRcb1GKx9iGuEbW2p8H1es9woEz-_0hRqgxs+8ojCmxhQ@mail.gmail.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>
	<CA+QY2RRcb1GKx9iGuEbW2p8H1es9woEz-_0hRqgxs+8ojCmxhQ@mail.gmail.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>
	<CA+QY2RRcb1GKx9iGuEbW2p8H1es9woEz-_0hRqgxs+8ojCmxhQ@mail.gmail.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>
	<CA+QY2RRcb1GKx9iGuEbW2p8H1es9woEz-_0hRqgxs+8ojCmxhQ@mail.gmail.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: <CA+QY2RQefa-1aZTEVTSVaWDDfOrcemmgFfg+8L60P8G1km7Yow@mail.gmail.com>
	<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 <robin at coraid.com> wrote:

> iftop to blame.
> 
> all fixed
> 
> 
> On Dec 7, 2013, at 07:14 AM, Robin P. Blanchard <robin at coraid.com> 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 <vab at bb-c.de> 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:
>>> 
>>> <nfs:/home/nfsadmin,1020# pkg install -v incorporation/jeos/omnios-userland at 11,5.11-0.151006
>>>           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:
>>> 
>>> <nfs:/var/tmp,1007# /usr/bin/pkg update -nv --be-name=omnios-r151008
>>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131208/2894beff/attachment.html>
-------------- 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131208/2894beff/attachment.bin>

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: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
Message-ID: <CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>

On Sat, Dec 7, 2013 at 10:06 AM, Tobias Oetiker <tobi at oetiker.ch> 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: <CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>
References: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
	<CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>

Hi Eric,

Today Eric Sproul wrote:

> On Sat, Dec 7, 2013 at 10:06 AM, Tobias Oetiker <tobi at oetiker.ch> 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: <alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>
References: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
	<CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>
	<alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>
Message-ID: <CA+QY2RQrdRms3H23nhg2pRVW3n_FZ9LDd1LjcRKuE-q7WHoK0Q@mail.gmail.com>

On Mon, Dec 9, 2013 at 10:51 AM, Tobias Oetiker <tobi at oetiker.ch> 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: <CAOpmc6xvY2MuVp2ZLan_ECC-VDfKUDoEKXTXzh2ZVpfVa2UGUw@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131209/0a92ccc8/attachment.html>

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: <alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>
References: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
	<CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>
	<alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>
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: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
	<CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>
	<alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>
	<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: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
	<CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>
	<alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>
	<20131209161502.GC67000@eschaton.local>
	<21157.62725.744647.328591@glaurung.bb-c.de>
Message-ID: <CA+QY2RTeCMbrvCwPv_dUhBtFOCqAJU8fOLKovieD7z2OfAtgsw@mail.gmail.com>

On Mon, Dec 9, 2013 at 11:51 AM, Volker A. Brandt <vab at bb-c.de> 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: <CA+QY2RTeCMbrvCwPv_dUhBtFOCqAJU8fOLKovieD7z2OfAtgsw@mail.gmail.com>
References: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
	<CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>
	<alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>
	<20131209161502.GC67000@eschaton.local>
	<21157.62725.744647.328591@glaurung.bb-c.de>
	<CA+QY2RTeCMbrvCwPv_dUhBtFOCqAJU8fOLKovieD7z2OfAtgsw@mail.gmail.com>
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 <vab at bb-c.de> 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: <CA+QY2RTeCMbrvCwPv_dUhBtFOCqAJU8fOLKovieD7z2OfAtgsw@mail.gmail.com>
References: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
	<CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>
	<alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>
	<20131209161502.GC67000@eschaton.local>
	<21157.62725.744647.328591@glaurung.bb-c.de>
	<CA+QY2RTeCMbrvCwPv_dUhBtFOCqAJU8fOLKovieD7z2OfAtgsw@mail.gmail.com>
Message-ID: <20131209182745.2aa1a876@sleipner.datanom.net>

On Mon, 9 Dec 2013 12:08:59 -0500
Eric Sproul <esproul at omniti.com> wrote:

> On Mon, Dec 9, 2013 at 11:51 AM, Volker A. Brandt <vab at bb-c.de> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131209/b77fb3b0/attachment-0001.bin>

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: <CA+QY2RTeCMbrvCwPv_dUhBtFOCqAJU8fOLKovieD7z2OfAtgsw@mail.gmail.com>
References: <alpine.DEB.2.02.1312071604360.30933@froburg.oetiker.ch>
	<CA+QY2RR8d1e9UUyFCgqjihW8RUJhWs4zAdFUirf3fdEwOV7DJw@mail.gmail.com>
	<alpine.DEB.2.02.1312091647470.354@engelberg.oetiker.ch>
	<20131209161502.GC67000@eschaton.local>
	<21157.62725.744647.328591@glaurung.bb-c.de>
	<CA+QY2RTeCMbrvCwPv_dUhBtFOCqAJU8fOLKovieD7z2OfAtgsw@mail.gmail.com>
Message-ID: <0BFE11DD-B4CA-41C2-8A99-A9E53B7FBBA6@fluffy.co.uk>


On 9 Dec 2013, at 17:08, Eric Sproul <esproul at omniti.com> wrote:

> On Mon, Dec 9, 2013 at 11:51 AM, Volker A. Brandt <vab at bb-c.de> 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: <CECB6D24.5EED3%scotty@jhu.edu>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131209/8320e35d/attachment.html>

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: <CECB7831.5EEE3%scotty@jhu.edu>

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 <scotty at jhu.edu<mailto:scotty at jhu.edu>>
Date: Monday, December 9, 2013 at 12:50 PM
To: OmniOS-discuss <omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131209/06d2c59f/attachment.html>

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: <CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>

On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson <henson at acm.org> 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: <CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>
References: <090701cef528$06b51230$141f3690$@acm.org>
	<CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>
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: <CAAYoGd8H7xTVRbD8HwcZ35aXc4Q0wiC+UgrvRi0veRY7Bg025A@mail.gmail.com>
References: <090701cef528$06b51230$141f3690$@acm.org>	<CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>
	<CAAYoGd8H7xTVRbD8HwcZ35aXc4Q0wiC+UgrvRi0veRY7Bg025A@mail.gmail.com>
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: <CA+tR_KyQD=6RYkgcChhixoMF36Oi7Uk9koaj4H-YHrsZ57igzQ@mail.gmail.com>

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 <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131209/ab0ab00e/attachment.html>

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: <CAAYoGd8djUreOpECbtL28VYvyaQnpocZaFdezmDyvdsS+YtMnw@mail.gmail.com>
References: <090701cef528$06b51230$141f3690$@acm.org>
	<CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>
	<CAAYoGd8H7xTVRbD8HwcZ35aXc4Q0wiC+UgrvRi0veRY7Bg025A@mail.gmail.com>
	<091701cef53b$bee7f030$3cb7d090$@acm.org>
	<CAAYoGd8djUreOpECbtL28VYvyaQnpocZaFdezmDyvdsS+YtMnw@mail.gmail.com>
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: <CA+tR_KyQD=6RYkgcChhixoMF36Oi7Uk9koaj4H-YHrsZ57igzQ@mail.gmail.com>
References: <094801cef550$b5cc58a0$216509e0$@acm.org>
	<CA+tR_KyQD=6RYkgcChhixoMF36Oi7Uk9koaj4H-YHrsZ57igzQ@mail.gmail.com>
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
<sigh>.

> 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: <CA+tR_Kwr3XXo6TituaN5kZpzBrhtYGSDUFwdk7dRghTiBSUbfA@mail.gmail.com>

On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131210/e39ba964/attachment-0001.html>

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: <CAHDYqcoER5aPmJgSRbwsdphKS__T-NJodo2-MhY_JPFUvOGZag@mail.gmail.com>
References: <CAHDYqcoER5aPmJgSRbwsdphKS__T-NJodo2-MhY_JPFUvOGZag@mail.gmail.com>
Message-ID: <CAHDYqcqWRh+=afhiKJXRbYh0vAO7a1Za6k9Boasp6KZjNu+pYA@mail.gmail.com>

Anyone? Am kind of stuck here.

Thanks.

On 04/12/2013, Sam M <emunch at utmi.in> 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: <CABweQmJd3BoDmHBYcGDyffzNa05OgVa_cPDVWsmaxtyHBMo8Hw@mail.gmail.com>

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 <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131210/33268070/attachment.html>

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: <CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>
References: <090701cef528$06b51230$141f3690$@acm.org>
	<CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>
Message-ID: <CABweQm+pgohX-SjC98m6pRGfaRGzNOdpdrQ1yBn06Az5YwaYZg@mail.gmail.com>

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 <esproul at omniti.com> wrote:

> On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131210/24d0cae0/attachment.html>

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: <CAHDYqcqWRh+=afhiKJXRbYh0vAO7a1Za6k9Boasp6KZjNu+pYA@mail.gmail.com>
References: <CAHDYqcoER5aPmJgSRbwsdphKS__T-NJodo2-MhY_JPFUvOGZag@mail.gmail.com>
	<CAHDYqcqWRh+=afhiKJXRbYh0vAO7a1Za6k9Boasp6KZjNu+pYA@mail.gmail.com>
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 <emunch at utmi.in> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131210/cb29017b/attachment.bin>

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: <CACLsApv94p4c=qCj6o9UDSrBhOL4U8k3mQG2Ab1Qp4quHDsW6w@mail.gmail.com>

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 <hasslerd at gmx.li> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131210/f872e51a/attachment-0001.html>

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: <CACLsApv94p4c=qCj6o9UDSrBhOL4U8k3mQG2Ab1Qp4quHDsW6w@mail.gmail.com>
References: <52A73672.9010608@gmx.li>
	<CACLsApv94p4c=qCj6o9UDSrBhOL4U8k3mQG2Ab1Qp4quHDsW6w@mail.gmail.com>
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 <http://ms.omniti.com>
> we opted to make the packages depend on the release.
> 
> 
> On Tue, Dec 10, 2013 at 10:42 AM, Dominik Hassler <hasslerd at gmx.li
> <mailto:hasslerd at gmx.li>> 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 <http://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 <mailto: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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131210/f8d1313c/attachment.bin>

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>
	<CACLsApv94p4c=qCj6o9UDSrBhOL4U8k3mQG2Ab1Qp4quHDsW6w@mail.gmail.com>
	<52A74207.4000406@gmx.li>
Message-ID: <CACLsApuBUQ7PVM0gwLtows0LJsxgom1urGOayKxz5mN=aX0s5g@mail.gmail.com>

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 <hasslerd at gmx.li> 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 <http://ms.omniti.com>
> > we opted to make the packages depend on the release.
> >
> >
> > On Tue, Dec 10, 2013 at 10:42 AM, Dominik Hassler <hasslerd at gmx.li
> > <mailto:hasslerd at gmx.li>> 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 <http://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 <mailto:
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131210/95b32f86/attachment.html>

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: <CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>
References: <090701cef528$06b51230$141f3690$@acm.org>
	<CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>
Message-ID: <CAAYoGd8H7xTVRbD8HwcZ35aXc4Q0wiC+UgrvRi0veRY7Bg025A@mail.gmail.com>

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 <esproul at omniti.com> wrote:

> On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131209/bfbb196b/attachment-0001.html>

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>
	<CA+QY2RQi2xCT3kQU67tprSGgEyE9K1iMBOsn3hYm5uUefEhGGQ@mail.gmail.com>
	<CAAYoGd8H7xTVRbD8HwcZ35aXc4Q0wiC+UgrvRi0veRY7Bg025A@mail.gmail.com>
	<091701cef53b$bee7f030$3cb7d090$@acm.org>
Message-ID: <CAAYoGd8djUreOpECbtL28VYvyaQnpocZaFdezmDyvdsS+YtMnw@mail.gmail.com>

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 <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131209/992dc825/attachment-0001.html>

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: <CA+tR_Kwr3XXo6TituaN5kZpzBrhtYGSDUFwdk7dRghTiBSUbfA@mail.gmail.com>
References: <090701cef528$06b51230$141f3690$@acm.org>
	<CA+tR_Kwr3XXo6TituaN5kZpzBrhtYGSDUFwdk7dRghTiBSUbfA@mail.gmail.com>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131211/5fe160e0/attachment.bin>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131210/0646035d/attachment.bin>

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: <CABweQmJd3BoDmHBYcGDyffzNa05OgVa_cPDVWsmaxtyHBMo8Hw@mail.gmail.com>
References: <090701cef528$06b51230$141f3690$@acm.org>	<20131210041303.GN4044@bender.unx.csupomona.edu>
	<CABweQmJd3BoDmHBYcGDyffzNa05OgVa_cPDVWsmaxtyHBMo8Hw@mail.gmail.com>
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>
	<CABweQmJd3BoDmHBYcGDyffzNa05OgVa_cPDVWsmaxtyHBMo8Hw@mail.gmail.com>
	<0b0001cef619$3df03210$b9d09630$@acm.org>
Message-ID: <CABweQmJ64nU1Cqu3Kq35kVVcy+eX4W15rBuuL2+Qe-ayP0yLmg@mail.gmail.com>

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 <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131210/1377f5b3/attachment.html>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131211/1459ca80/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131211/1459ca80/attachment-0001.bin>

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: <B649EC13-C821-4F0B-BB90-79C7B461ECED@mac.com>

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: <CA+tR_KyQD=6RYkgcChhixoMF36Oi7Uk9koaj4H-YHrsZ57igzQ@mail.gmail.com>
References: <094801cef550$b5cc58a0$216509e0$@acm.org>
	<CA+tR_KyQD=6RYkgcChhixoMF36Oi7Uk9koaj4H-YHrsZ57igzQ@mail.gmail.com>
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: <CABweQmJ64nU1Cqu3Kq35kVVcy+eX4W15rBuuL2+Qe-ayP0yLmg@mail.gmail.com>
References: <090701cef528$06b51230$141f3690$@acm.org>	<20131210041303.GN4044@bender.unx.csupomona.edu>	<CABweQmJd3BoDmHBYcGDyffzNa05OgVa_cPDVWsmaxtyHBMo8Hw@mail.gmail.com>	<0b0001cef619$3df03210$b9d09630$@acm.org>
	<CABweQmJ64nU1Cqu3Kq35kVVcy+eX4W15rBuuL2+Qe-ayP0yLmg@mail.gmail.com>
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>
	<CA+tR_KyQD=6RYkgcChhixoMF36Oi7Uk9koaj4H-YHrsZ57igzQ@mail.gmail.com>
	<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>
	<CABweQmJd3BoDmHBYcGDyffzNa05OgVa_cPDVWsmaxtyHBMo8Hw@mail.gmail.com>
	<0b0001cef619$3df03210$b9d09630$@acm.org>
	<CABweQmJ64nU1Cqu3Kq35kVVcy+eX4W15rBuuL2+Qe-ayP0yLmg@mail.gmail.com>
	<0c4801cef6df$0bec52a0$23c4f7e0$@acm.org>
Message-ID: <CABweQmJfLAb9yCHW-_rO12SueTaESeroQxvvV_1kDVQy=_f5eg@mail.gmail.com>

We're just calling smartctl periodically.
 -nld


On Wed, Dec 11, 2013 at 8:08 PM, Paul B. Henson <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131212/78e41610/attachment.html>

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: <CA+QY2RSSVFpYTaxVJLA2b25iqf04Y-Eq3AZWW4b7heQ87cxsBA@mail.gmail.com>

On Wed, Dec 11, 2013 at 11:00 PM, Paul B. Henson <henson at acm.org> 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: <AC73FC1A-A3AD-46B3-85EB-60BA2A8411DA@RichardElling.com>

On Dec 10, 2013, at 4:01 PM, Tom Robinson <tom.robinson at motec.com.au> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131212/6c1e6c85/attachment.html>

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>
	<CA+tR_Kwr3XXo6TituaN5kZpzBrhtYGSDUFwdk7dRghTiBSUbfA@mail.gmail.com>
	<0a8501cef5e7$4b6eb4c0$e24c1e40$@acm.org>
Message-ID: <CF9F5E40-6560-448F-8E80-7ED3AC866C7D@RichardElling.com>

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 <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131212/95b5f8bc/attachment-0001.html>

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: <alpine.DEB.2.02.1312131123170.26735@engelberg.oetiker.ch>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131213/ab452708/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: io-pattern.jpg
Type: image/jpeg
Size: 174743 bytes
Desc: 
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131213/ab452708/attachment-0003.jpg>

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: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>

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: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>
References: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>
Message-ID: <DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>



-----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: <alpine.DEB.2.02.1312131123170.26735@engelberg.oetiker.ch>
References: <alpine.DEB.2.02.1312131123170.26735@engelberg.oetiker.ch>
Message-ID: <52AB05AA.7010202@alcatel-lucent.com>

An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131213/f2b20259/attachment.html>

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: <alpine.DEB.2.02.1312131123170.26735@engelberg.oetiker.ch>
	<52AB05AA.7010202@alcatel-lucent.com>
Message-ID: <alpine.DEB.2.02.1312131409570.26735@engelberg.oetiker.ch>

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: <DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>
References: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>
	<DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>
Message-ID: <CAHBEJzW20pFgk_AX_X3gf0eOqEhC9SUAbN=CJ87xNnDzM4rKCw@mail.gmail.com>

--
Groeten,
natxo


On Fri, Dec 13, 2013 at 1:41 PM, Chavdar Ivanov <ci4 at outlook.com> 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: <alpine.DEB.2.02.1312131409570.26735@engelberg.oetiker.ch>
References: <alpine.DEB.2.02.1312131123170.26735@engelberg.oetiker.ch>	<52AB05AA.7010202@alcatel-lucent.com>
	<alpine.DEB.2.02.1312131409570.26735@engelberg.oetiker.ch>
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: <alpine.DEB.2.02.1312131123170.26735@engelberg.oetiker.ch>
	<52AB05AA.7010202@alcatel-lucent.com>
	<alpine.DEB.2.02.1312131409570.26735@engelberg.oetiker.ch>
	<52AB1896.8080906@hlangeveld.nl>
Message-ID: <alpine.DEB.2.02.1312131548130.26735@engelberg.oetiker.ch>

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>
	<CA+tR_KyQD=6RYkgcChhixoMF36Oi7Uk9koaj4H-YHrsZ57igzQ@mail.gmail.com>
	<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" <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131212/89d3a829/attachment.html>

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: <DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>
References: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>
	<DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>
Message-ID: <CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw@mail.gmail.com>

On Fri, Dec 13, 2013 at 1:41 PM, Chavdar Ivanov <ci4 at outlook.com> 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."
	<CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw@mail.gmail.com> 
References: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>
	<DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>
	<CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw@mail.gmail.com>
Message-ID: <201312131529.rBDFT9dj004758@elvis.arl.psu.edu>

In message <CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw at mail.gmail.com>
, 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: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>
	<DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>
	<CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw@mail.gmail.com>
	<201312131529.rBDFT9dj004758@elvis.arl.psu.edu>
Message-ID: <CAHBEJzW8p1hS+SY4++k1MbYQWWsGa8_1Hw+VH42dWVTyCq+zzQ@mail.gmail.com>

On Fri, Dec 13, 2013 at 4:29 PM, John D Groenveld
<jdg117 at elvis.arl.psu.edu> wrote:
> In message <CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw at mail.gmail.com>
> , 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: <alpine.DEB.2.02.1312131409570.26735@engelberg.oetiker.ch>
References: <alpine.DEB.2.02.1312131123170.26735@engelberg.oetiker.ch>
	<52AB05AA.7010202@alcatel-lucent.com>
	<alpine.DEB.2.02.1312131409570.26735@engelberg.oetiker.ch>
Message-ID: <336F86A6-146D-43D2-92B2-6F379398410A@richardelling.com>

On Dec 13, 2013, at 5:13 AM, Tobias Oetiker <tobi at oetiker.ch> 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: <CAHBEJzUK2t92B=d+ACGvqQrihPcZpRfonEbDK-f_W67cZ5Djug@mail.gmail.com>

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: <CAHBEJzUK2t92B=d+ACGvqQrihPcZpRfonEbDK-f_W67cZ5Djug@mail.gmail.com>
References: <CAHBEJzUK2t92B=d+ACGvqQrihPcZpRfonEbDK-f_W67cZ5Djug@mail.gmail.com>
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: <CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw@mail.gmail.com>
References: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>	<DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>
	<CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw@mail.gmail.com>
Message-ID: <DUB404-EAS334032CF35999A20EE0E1BBE2DF0@phx.gbl>



-----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 <ci4 at outlook.com> 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: <DUB404-EAS334032CF35999A20EE0E1BBE2DF0@phx.gbl>
References: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>
	<DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>
	<CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw@mail.gmail.com>
	<DUB404-EAS334032CF35999A20EE0E1BBE2DF0@phx.gbl>
Message-ID: <CA+QY2RTJ-mmsWmutNYtKKj2XstJD2OmWK1Oswmq4qb6cmsKrVg@mail.gmail.com>

On Fri, Dec 13, 2013 at 11:45 AM, Chavdar Ivanov <ci4 at outlook.com> 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: <alpine.DEB.2.02.1312131123170.26735@engelberg.oetiker.ch>
	<52AB05AA.7010202@alcatel-lucent.com>
	<alpine.DEB.2.02.1312131409570.26735@engelberg.oetiker.ch>
	<336F86A6-146D-43D2-92B2-6F379398410A@richardelling.com>
Message-ID: <CAOpmc6wxiRH0So3fVVB4cdkwFhiHLmQcFB_LBk32GGSWtYuotA@mail.gmail.com>

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 <tobi at oetiker.ch> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131213/b07ed659/attachment.html>

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: <alpine.DEB.2.02.1312131123170.26735@engelberg.oetiker.ch>
	<52AB05AA.7010202@alcatel-lucent.com>
	<alpine.DEB.2.02.1312131409570.26735@engelberg.oetiker.ch>
	<336F86A6-146D-43D2-92B2-6F379398410A@richardelling.com>
Message-ID: <alpine.DEB.2.02.1312132121030.26735@engelberg.oetiker.ch>

Today Richard Elling wrote:

> On Dec 13, 2013, at 5:13 AM, Tobias Oetiker <tobi at oetiker.ch> 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: <CA+QY2RTJ-mmsWmutNYtKKj2XstJD2OmWK1Oswmq4qb6cmsKrVg@mail.gmail.com>
References: <CAHBEJzVpQkX9SgpkYyBixWaVQ8EoSht8kT00rxXjGsw+H6Rwgg@mail.gmail.com>	<DUB404-EAS403DF0E7B27042F023444A3E2DF0@phx.gbl>	<CAHBEJzW5O2S3W5F42u1yT+AV8X1ckNq4sZADgLVm21zmGyPdxw@mail.gmail.com>	<DUB404-EAS334032CF35999A20EE0E1BBE2DF0@phx.gbl>
	<CA+QY2RTJ-mmsWmutNYtKKj2XstJD2OmWK1Oswmq4qb6cmsKrVg@mail.gmail.com>
Message-ID: <DUB407-EAS99269209943D934CE5078BE2D80@phx.gbl>



-----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 <ci4 at outlook.com> 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: <CA+QY2RRvMYP888j4ky1yzWFBLw2cLjvMjc5-esELpEpAd9GB9A@mail.gmail.com>
	<529BA492.4060105@gmx.eu>
	<CA+QY2RTuAuq3926_cHP1ziV+H2d2QKPTMpjZUrgxLH+7R2Hddw@mail.gmail.com>
	<52ADF320.4040607@gmx.eu>
Message-ID: <CA+QY2RRn-TCdFnVkCjet6aCReNn4oOsL=_N7vq_mPRTwyXDQ8w@mail.gmail.com>

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 <david at gmx.eu> 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 <david at gmx.eu> 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: <CAHBEJzWs7JNHLQibKUm2NL-HPXOHyrv9dwMCOLH4Hb+wOROH9w@mail.gmail.com>

On Mon, Dec 16, 2013 at 8:46 PM, Michael Mounteney
<gate03 at landcroft.co.uk> 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: <CAHBEJzWs7JNHLQibKUm2NL-HPXOHyrv9dwMCOLH4Hb+wOROH9w@mail.gmail.com>
References: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk>
	<CAHBEJzWs7JNHLQibKUm2NL-HPXOHyrv9dwMCOLH4Hb+wOROH9w@mail.gmail.com>
Message-ID: <CAHBEJzWxRs9D_vjvLPgTmV8sJqwPz=b3wKPj70uTO67K1WeJzA@mail.gmail.com>

or maybe this:

http://en.wikipedia.org/wiki/Web-based_SSH
--
Groeten,
natxo


On Tue, Dec 17, 2013 at 9:57 AM, Natxo Asenjo <natxo.asenjo at gmail.com> wrote:
> On Mon, Dec 16, 2013 at 8:46 PM, Michael Mounteney
> <gate03 at landcroft.co.uk> 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: <CAHBEJzWxRs9D_vjvLPgTmV8sJqwPz=b3wKPj70uTO67K1WeJzA@mail.gmail.com>
References: <20131217054624.87a90147fb900172a4d26eb1@landcroft.co.uk>
	<CAHBEJzWs7JNHLQibKUm2NL-HPXOHyrv9dwMCOLH4Hb+wOROH9w@mail.gmail.com>
	<CAHBEJzWxRs9D_vjvLPgTmV8sJqwPz=b3wKPj70uTO67K1WeJzA@mail.gmail.com>
Message-ID: <20131217223150.23bb9648@dickless.landy.net>

On Tue, 17 Dec 2013 10:02:18 +0100
Natxo Asenjo <natxo.asenjo at gmail.com> 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.
<URL:https://www.paloaltonetworks.com/content/dam/paloaltonetworks-com/en_US/assets/pdf/tech-briefs/paloaltonetworks-vs-proxy.pdf>

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.
> <URL:https://www.paloaltonetworks.com/content/dam/paloaltonetworks-com/en_US/assets/pdf/tech-briefs/paloaltonetworks-vs-proxy.pdf>

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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131217/25788e1a/attachment.bin>

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 <rafibeyli at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131217/f4d46159/attachment-0001.html>

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: <E64A7B8D-1AA5-40F1-9F0C-83B4219A5A1B@getchef.com>

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 <jdunn at getchef.com>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131217/eab9aab9/attachment.txt>

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 '\<st\>' -e '\<sgen\>' /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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131218/c61d321c/attachment.bin>

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: <E64A7B8D-1AA5-40F1-9F0C-83B4219A5A1B@getchef.com>
References: <E64A7B8D-1AA5-40F1-9F0C-83B4219A5A1B@getchef.com>
Message-ID: <A58D0D92-6C0F-41FA-A852-6E3C1743DCFB@fluffy.co.uk>

On 18 Dec 2013, at 00:58, "Julian C. Dunn" <jdunn at getchef.com> 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: <CAEjQA5Kg8=t99yonsEThHxzA7WrSiYu_=L-R_FJuMnOkTDHr_g@mail.gmail.com>

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 '\<st\>' -e '\<sgen\>' /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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131219/c52d83ab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131219/c52d83ab/attachment-0001.bin>

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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>

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" <carlopmart at gmail.com> 
????: 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131219/2f8c9e63/attachment.html>

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: <CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
References: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
Message-ID: <CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>

On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez <carlopmart at gmail.com> 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 <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" <carlopmart at gmail.com>
>> ????: 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: <CAHBEJzUK2t92B=d+ACGvqQrihPcZpRfonEbDK-f_W67cZ5Djug@mail.gmail.com>
	<20131213162641.GE5178@eschaton.local>
Message-ID: <CAHBEJzV8CL8nT9KGqUDs6v5m+fda8rwFeF0RzXn0EvPRT3Frpg@mail.gmail.com>

On Fri, Dec 13, 2013 at 5:26 PM, Chris Nehren
<cnehren+omnios-discuss at omniti.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131220/568cc6e1/attachment.html>

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: <CAHBEJzV8CL8nT9KGqUDs6v5m+fda8rwFeF0RzXn0EvPRT3Frpg@mail.gmail.com>
References: <CAHBEJzUK2t92B=d+ACGvqQrihPcZpRfonEbDK-f_W67cZ5Djug@mail.gmail.com>
	<20131213162641.GE5178@eschaton.local>
	<CAHBEJzV8CL8nT9KGqUDs6v5m+fda8rwFeF0RzXn0EvPRT3Frpg@mail.gmail.com>
Message-ID: <CACLsApvs6Cffh38wY9_juN2yeHkgw3w6xwux16SEqCBKkfxH6g@mail.gmail.com>

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 <natxo.asenjo at gmail.com>wrote:

> On Fri, Dec 13, 2013 at 5:26 PM, Chris Nehren
> <cnehren+omnios-discuss at omniti.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131220/2beab63d/attachment.html>

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: <CACLsApsaRC+Takqfn9QXUbrOKkw3oMOZMQ3Mne7ohTgtCBGVOg@mail.gmail.com>

On Tue, Dec 17, 2013 at 2:31 PM, Michael Rasmussen <mir at miras.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131220/203abb09/attachment-0001.html>

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: <CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
References: <CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>,
	<gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
Message-ID: <OF95B975CA.1A422348-ONC1257C47.004C001F-C1257C47.004C0022@inse.com>

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" <omnios-discuss-bounces at lists.omniti.com> 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 <carlopmart at gmail.com> 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 <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
>>
>>
>> -------- &#1048;&#1089;&#1093;&#1086;&#1076;&#1085;&#1086;&#1077; &#1089;&#1086;&#1086;&#1073;&#1097;&#1077;&#1085;&#1080;&#1077; --------
>> &#1054;&#1090;: "C. L. Martinez" <carlopmart at gmail.com>
>> &#1044;&#1072;&#1090;&#1072;: 2013.12.18 22:05 (GMT+04:00)
>> &#1050;&#1086;&#1084;&#1091;: omnios-discuss at lists.omniti.com
>> &#1058;&#1077;&#1084;&#1072;: [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: <OF95B975CA.1A422348-ONC1257C47.004C001F-C1257C47.004C0022@inse.com>
References: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<OF95B975CA.1A422348-ONC1257C47.004C001F-C1257C47.004C0022@inse.com>
Message-ID: <CAEjQA5L+O8QsR110as27=WiUHSg4jJb3jiZ2uCE739a3qOHzFg@mail.gmail.com>

On Fri, Dec 20, 2013 at 1:50 PM, Johan Kragsterman
<johan.kragsterman at capvert.se> 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: <CAEjQA5L+O8QsR110as27=WiUHSg4jJb3jiZ2uCE739a3qOHzFg@mail.gmail.com>
References: <CAEjQA5L+O8QsR110as27=WiUHSg4jJb3jiZ2uCE739a3qOHzFg@mail.gmail.com>,
	<gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<OF95B975CA.1A422348-ONC1257C47.004C001F-C1257C47.004C0022@inse.com>
Message-ID: <OFC148B816.2C07972D-ONC1257C47.00500081-C1257C47.00500084@inse.com>

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" <omnios-discuss-bounces at lists.omniti.com> 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
<johan.kragsterman at capvert.se> 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: <OF95B975CA.1A422348-ONC1257C47.004C001F-C1257C47.004C0022@inse.com>
References: <CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>,
	<gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<OF95B975CA.1A422348-ONC1257C47.004C001F-C1257C47.004C0022@inse.com>
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: <CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
References: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
Message-ID: <52B459DA.7030501@gmail.com>

On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez <carlopmart at gmail.com>
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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<52B459DA.7030501@gmail.com>
Message-ID: <CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>

On Fri, Dec 20, 2013 at 2:53 PM, Saso Kiselkov <skiselkov.ml at gmail.com> wrote:
> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez <carlopmart at gmail.com>
> 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: <CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
References: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<52B459DA.7030501@gmail.com>
	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
Message-ID: <CAEjQA5JWUNdsJprP1H92YMua6bkTsYYZPZxGLLQ=DaXqOqEMHQ@mail.gmail.com>

On Fri, Dec 20, 2013 at 3:22 PM, C. L. Martinez <carlopmart at gmail.com> wrote:
> On Fri, Dec 20, 2013 at 2:53 PM, Saso Kiselkov <skiselkov.ml at gmail.com> wrote:
>> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez <carlopmart at gmail.com>
>> 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: <CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
References: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>
	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.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 <skiselkov.ml at gmail.com> wrote:
>> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez <carlopmart at gmail.com>
>> 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: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>

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: <alpine.DEB.2.02.1312230015520.22191@engelberg.oetiker.ch>

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: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
References: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
Message-ID: <2F7ACA02-1109-4A4B-8F77-7357B475E5A3@richardelling.com>

Hi Tobias,
comments below?

On Dec 21, 2013, at 5:15 AM, Tobias Oetiker <tobi at oetiker.ch> 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: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
	<2F7ACA02-1109-4A4B-8F77-7357B475E5A3@richardelling.com>
Message-ID: <alpine.DEB.2.02.1312230122240.22191@engelberg.oetiker.ch>

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: <CANiY96bGzvPJCzhBh7313cDxQO8vBEtKSR_arGdShnYsySxOkA@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131223/032a72e1/attachment.html>

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: <CANiY96bGzvPJCzhBh7313cDxQO8vBEtKSR_arGdShnYsySxOkA@mail.gmail.com>
References: <CANiY96bGzvPJCzhBh7313cDxQO8vBEtKSR_arGdShnYsySxOkA@mail.gmail.com>
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: <alpine.DEB.2.02.1312230122240.22191@engelberg.oetiker.ch>
References: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
	<2F7ACA02-1109-4A4B-8F77-7357B475E5A3@richardelling.com>
	<alpine.DEB.2.02.1312230122240.22191@engelberg.oetiker.ch>
Message-ID: <2D67EFA5-C4B7-4556-B1CA-5906EAEEDA22@richardelling.com>

On Dec 22, 2013, at 4:23 PM, Tobias Oetiker <tobi at oetiker.ch> 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: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
	<2F7ACA02-1109-4A4B-8F77-7357B475E5A3@richardelling.com>
	<alpine.DEB.2.02.1312230122240.22191@engelberg.oetiker.ch>
	<2D67EFA5-C4B7-4556-B1CA-5906EAEEDA22@richardelling.com>
Message-ID: <alpine.DEB.2.02.1312230849280.22191@engelberg.oetiker.ch>

Hi Richard,

Yesterday Richard Elling wrote:

> On Dec 22, 2013, at 4:23 PM, Tobias Oetiker <tobi at oetiker.ch> 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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<52B459DA.7030501@gmail.com>
	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
	<52B46409.8010106@gmail.com>
Message-ID: <CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.gmail.com>

On Fri, Dec 20, 2013 at 3:36 PM, Saso Kiselkov <skiselkov.ml at gmail.com> wrote:
> On 12/20/13, 3:22 PM, C. L. Martinez wrote:
>> On Fri, Dec 20, 2013 at 2:53 PM, Saso Kiselkov <skiselkov.ml at gmail.com> wrote:
>>> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez <carlopmart at gmail.com>
>>> 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: <CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.gmail.com>
References: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>	<52B46409.8010106@gmail.com>
	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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 <skiselkov.ml at gmail.com> wrote:
>> On 12/20/13, 3:22 PM, C. L. Martinez wrote:
>>> On Fri, Dec 20, 2013 at 2:53 PM, Saso Kiselkov <skiselkov.ml at gmail.com> wrote:
>>>> On Thu, Dec 19, 2013 at 11:02 AM, C. L. Martinez <carlopmart at gmail.com>
>>>> 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: <CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.gmail.com>
References: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<52B459DA.7030501@gmail.com>
	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
	<52B46409.8010106@gmail.com>
	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.gmail.com>
Message-ID: <20131223130952.5a07244d@sleipner.datanom.net>

On Mon, 23 Dec 2013 11:30:50 +0000
"C. L. Martinez" <carlopmart at gmail.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131223/133c2712/attachment.bin>

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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>	<52B46409.8010106@gmail.com>	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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" <carlopmart at gmail.com> 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: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
References: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
Message-ID: <CAMxNYabss+Ft-PxL45vbj6pgZG=EPFvOp0P9oZ+dkELbw-b7EQ@mail.gmail.com>

On Sat, Dec 21, 2013 at 3:15 PM, Tobias Oetiker <tobi at oetiker.ch> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131223/12ebbd08/attachment.html>

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: <CAMxNYabss+Ft-PxL45vbj6pgZG=EPFvOp0P9oZ+dkELbw-b7EQ@mail.gmail.com>
References: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
	<CAMxNYabss+Ft-PxL45vbj6pgZG=EPFvOp0P9oZ+dkELbw-b7EQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1312231427230.22191@engelberg.oetiker.ch>

Today George-Cristian B?rzan wrote:

> On Sat, Dec 21, 2013 at 3:15 PM, Tobias Oetiker <tobi at oetiker.ch> 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: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
References: <alpine.DEB.2.02.1312211343130.22191@engelberg.oetiker.ch>
Message-ID: <08986B7D-3B60-456B-A364-EE21ACF05869@mis.use.net>


On 21 Dec, 2013, at 13:15, Tobias Oetiker <tobi at oetiker.ch> 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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<52B459DA.7030501@gmail.com>
	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
	<52B46409.8010106@gmail.com>
	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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 <skiselkov.ml at gmail.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131223/3068f97b/attachment.bin>

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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<52B459DA.7030501@gmail.com>
	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
	<52B46409.8010106@gmail.com>
	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.gmail.com>
	<20131223130952.5a07244d@sleipner.datanom.net>
	<52B82C07.2030305@gmail.com>
Message-ID: <CA+QY2RSWrB10J7O_Zg9td6478DJ=84bWdcRke2_r8HHZeH2m9A@mail.gmail.com>

On Mon, Dec 23, 2013 at 7:26 AM, Saso Kiselkov <skiselkov.ml at gmail.com> wrote:
> On 12/23/13, 12:09 PM, Michael Rasmussen wrote:
>> On Mon, 23 Dec 2013 11:30:50 +0000
>> "C. L. Martinez" <carlopmart at gmail.com> 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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<52B459DA.7030501@gmail.com>
	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
	<52B46409.8010106@gmail.com>
	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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 <skiselkov.ml at gmail.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131223/721342f8/attachment-0001.bin>

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: <CA+QY2RSWrB10J7O_Zg9td6478DJ=84bWdcRke2_r8HHZeH2m9A@mail.gmail.com>
References: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>	<52B46409.8010106@gmail.com>	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.gmail.com>	<20131223130952.5a07244d@sleipner.datanom.net>	<52B82C07.2030305@gmail.com>
	<CA+QY2RSWrB10J7O_Zg9td6478DJ=84bWdcRke2_r8HHZeH2m9A@mail.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 <skiselkov.ml at gmail.com> wrote:
>> On 12/23/13, 12:09 PM, Michael Rasmussen wrote:
>>> On Mon, 23 Dec 2013 11:30:50 +0000
>>> "C. L. Martinez" <carlopmart at gmail.com> 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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>	<52B46409.8010106@gmail.com>	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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 <skiselkov.ml at gmail.com> 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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>	<52B46409.8010106@gmail.com>	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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 <skiselkov.ml at gmail.com> 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<pg,wp,ne,et,ts,mp,pe> cr4: 
426f8<osxsav,vmxe,xmme,fxsr,pge,mce,pae,pse,de>
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<pg,wp,ne,et,ts,mp,pe> cr4: 
> 426f8<osxsav,vmxe,xmme,fxsr,pge,mce,pae,pse,de>
> 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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>	<52B46409.8010106@gmail.com>
	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>	<52B46409.8010106@gmail.com>	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>	<52B46409.8010106@gmail.com>
	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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 <henson at acm.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131224/c6b5a599/attachment.bin>

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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>	<52B459DA.7030501@gmail.com>	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>	<52B46409.8010106@gmail.com>	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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 <henson at acm.org> 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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<52B459DA.7030501@gmail.com>
	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
	<52B46409.8010106@gmail.com>
	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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: <gkoel3y12l3jkhhy8bnd55be.1387445091247@email.android.com>
	<CAEjQA5Jy2ThPbhLZFD7z5aP_5kbTt+ho=rS+mXMiPLKG9jDj+g@mail.gmail.com>
	<CAEjQA5J0r3R_B-3Wiwg09SkvxcHira6+9tc++LmEw5Jy22gWzQ@mail.gmail.com>
	<52B459DA.7030501@gmail.com>
	<CAEjQA5K=Qiohf4Xm8HyvcaeuVfU9JsvL+gNrV3Pny2SbL873NA@mail.gmail.com>
	<52B46409.8010106@gmail.com>
	<CAEjQA5K_OM+Kq6M_4AaqNczm_9RO2xAV_vhuceqCyh5NiW-Rkw@mail.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: <CAHfYOdWwZ=t6VV5g9r9pPV9SvsJ=8GEh_gsjBnQz-1btG8OHLw@mail.gmail.com>

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: <CAHfYOdWwZ=t6VV5g9r9pPV9SvsJ=8GEh_gsjBnQz-1btG8OHLw@mail.gmail.com>
References: <CAHfYOdWwZ=t6VV5g9r9pPV9SvsJ=8GEh_gsjBnQz-1btG8OHLw@mail.gmail.com>
Message-ID: <20131226185202.201e1488@sleipner.datanom.net>

On Thu, 26 Dec 2013 12:31:30 -0500
Chris Nagele <nagele at wildbit.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131226/dabefb4f/attachment-0001.bin>

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: <CEE1E0EA.5FBF1%scotty@jhu.edu>

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: <CEE1E0EA.5FBF1%scotty@jhu.edu>
References: <CEE1E0EA.5FBF1%scotty@jhu.edu>
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: <CEE1ED57.5FBFE%scotty@jhu.edu>

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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
Message-ID: <CEE1F136.5FC06%scotty@jhu.edu>

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" <skiselkov.ml at gmail.com> 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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<52BC8763.2070708@gmail.com>
Message-ID: <CEE1F202.5FC0D%scotty@jhu.edu>

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" <skiselkov.ml at gmail.com> 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: <CEE1ED57.5FBFE%scotty@jhu.edu>
References: <CEE1ED57.5FBFE%scotty@jhu.edu>
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: <CEE1F136.5FC06%scotty@jhu.edu>
References: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu>
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: <CEE1F202.5FC0D%scotty@jhu.edu>
References: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<52BC8763.2070708@gmail.com> <CEE1F202.5FC0D%scotty@jhu.edu>
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: <CEE1F136.5FC06%scotty@jhu.edu>
References: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu>
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 <scotty at jhu.edu> 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" <skiselkov.ml at gmail.com> 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: <CEE1F136.5FC06%scotty@jhu.edu>
References: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu>
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: <CEE1ED57.5FBFE%scotty@jhu.edu>
	<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: <CEE1E0EA.5FBF1%scotty@jhu.edu>
	<52BC78EF.8090704@gmail.com>	<CEE1EAE1.5FBF7%scotty@jhu.edu>
	<52BC85BA.7080902@gmail.com>	<CEE1F136.5FC06%scotty@jhu.edu>
	<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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <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: <CEE1E0EA.5FBF1%scotty@jhu.edu>
	<52BC78EF.8090704@gmail.com>	<CEE1EAE1.5FBF7%scotty@jhu.edu>
	<52BC85BA.7080902@gmail.com>	<CEE1F136.5FC06%scotty@jhu.edu>
	<3EEFC41E-7826-4F5C-AAA1-2BBA876ABB1F@omniti.com>
	<52BC8A96.3040008@gmail.com>
Message-ID: <E2BBC957-F04D-4B45-B8E8-48CFEDCB6903@omniti.com>

On Dec 26, 2013, at 2:59 PM, Saso Kiselkov <skiselkov.ml at gmail.com> 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: <CEE1E0EA.5FBF1%scotty@jhu.edu>
	<52BC78EF.8090704@gmail.com>	<CEE1EAE1.5FBF7%scotty@jhu.edu>
	<52BC85BA.7080902@gmail.com>	<CEE1F136.5FC06%scotty@jhu.edu>
	<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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <52BC8891.1040906@gmail.com>
	<52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com>
	<52BC8EAD.9080204@gmail.com>
Message-ID: <CEE1F9B1.5FC21%scotty@jhu.edu>

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" <skiselkov.ml at gmail.com> 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: <E2BBC957-F04D-4B45-B8E8-48CFEDCB6903@omniti.com>
References: <CEE1E0EA.5FBF1%scotty@jhu.edu>
	<52BC78EF.8090704@gmail.com>	<CEE1EAE1.5FBF7%scotty@jhu.edu>
	<52BC85BA.7080902@gmail.com>	<CEE1F136.5FC06%scotty@jhu.edu>
	<3EEFC41E-7826-4F5C-AAA1-2BBA876ABB1F@omniti.com>
	<52BC8A96.3040008@gmail.com>
	<E2BBC957-F04D-4B45-B8E8-48CFEDCB6903@omniti.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 <skiselkov.ml at gmail.com> 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: <CEE1F9B1.5FC21%scotty@jhu.edu>
References: <CEE1E0EA.5FBF1%scotty@jhu.edu>
	<52BC78EF.8090704@gmail.com>	<CEE1EAE1.5FBF7%scotty@jhu.edu>
	<52BC85BA.7080902@gmail.com>	<CEE1F136.5FC06%scotty@jhu.edu>
	<52BC8891.1040906@gmail.com>	<52BC8D22.5040500@gmail.com>
	<52BC8DA2.4090406@gmail.com>	<52BC8EAD.9080204@gmail.com>
	<CEE1F9B1.5FC21%scotty@jhu.edu>
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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <52BC8891.1040906@gmail.com>
	<52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com>
	<52BC8EAD.9080204@gmail.com> <CEE1F9B1.5FC21%scotty@jhu.edu>
	<52BC914B.9020503@gmail.com>
Message-ID: <20131226213336.416a31e3@sleipner.datanom.net>

On Thu, 26 Dec 2013 20:27:55 +0000
Saso Kiselkov <skiselkov.ml at gmail.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131226/eedd6bed/attachment.bin>

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: <CEE1E0EA.5FBF1%scotty@jhu.edu>
	<52BC78EF.8090704@gmail.com>	<CEE1EAE1.5FBF7%scotty@jhu.edu>
	<52BC85BA.7080902@gmail.com>	<CEE1F136.5FC06%scotty@jhu.edu>
	<52BC8891.1040906@gmail.com>	<52BC8D22.5040500@gmail.com>
	<52BC8DA2.4090406@gmail.com>	<52BC8EAD.9080204@gmail.com>
	<CEE1F9B1.5FC21%scotty@jhu.edu>	<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 <skiselkov.ml at gmail.com> 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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <52BC8891.1040906@gmail.com>
	<52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com>
	<20131226204455.GE10749@gutsman.lotheac.fi>
	<52BC9631.2040208@gmail.com>
Message-ID: <CEE20599.5FC32%scotty@jhu.edu>

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: <CEE20599.5FC32%scotty@jhu.edu>
References: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <52BC8891.1040906@gmail.com>
	<52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com>
	<20131226204455.GE10749@gutsman.lotheac.fi>
	<52BC9631.2040208@gmail.com> <CEE20599.5FC32%scotty@jhu.edu>
Message-ID: <CEE20856.5FC37%scotty@jhu.edu>

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" <scotty at jhu.edu> 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: <CEE20856.5FC37%scotty@jhu.edu>
References: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <52BC8891.1040906@gmail.com>
	<52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com>
	<20131226204455.GE10749@gutsman.lotheac.fi>
	<52BC9631.2040208@gmail.com> <CEE20599.5FC32%scotty@jhu.edu>
	<CEE20856.5FC37%scotty@jhu.edu>
Message-ID: <E6584ABC-327D-41F6-816D-CA8694CFA217@omniti.com>


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 <scotty at jhu.edu> 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" <scotty at jhu.edu> 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: <CEE1E0EA.5FBF1%scotty@jhu.edu> <52BC78EF.8090704@gmail.com>
	<CEE1EAE1.5FBF7%scotty@jhu.edu> <52BC85BA.7080902@gmail.com>
	<CEE1F136.5FC06%scotty@jhu.edu> <52BC8891.1040906@gmail.com>
	<52BC8D22.5040500@gmail.com> <52BC8DA2.4090406@gmail.com>
	<52BC8EAD.9080204@gmail.com> <CEE1F9B1.5FC21%scotty@jhu.edu>
	<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 <skiselkov.ml at gmail.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
<wiggyWork> 3990 N   Apr 15 Cute Girlfriend (  45) Erotic Amateur
Girlfriends <wiggyWork> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131226/9d746ac1/attachment-0001.bin>

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: <CAHfYOdWwZ=t6VV5g9r9pPV9SvsJ=8GEh_gsjBnQz-1btG8OHLw@mail.gmail.com>
	<20131226185202.201e1488@sleipner.datanom.net>
Message-ID: <CAHfYOdXsTBYu=3Aex041e+cy9O5Gy+UZnBjov-Z0V-6uRGMpeQ@mail.gmail.com>

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 <mir at miras.org> wrote:
> On Thu, 26 Dec 2013 12:31:30 -0500
> Chris Nagele <nagele at wildbit.com> 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 <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> 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: <CAHfYOdXsTBYu=3Aex041e+cy9O5Gy+UZnBjov-Z0V-6uRGMpeQ@mail.gmail.com>
References: <CAHfYOdWwZ=t6VV5g9r9pPV9SvsJ=8GEh_gsjBnQz-1btG8OHLw@mail.gmail.com>
	<20131226185202.201e1488@sleipner.datanom.net>
	<CAHfYOdXsTBYu=3Aex041e+cy9O5Gy+UZnBjov-Z0V-6uRGMpeQ@mail.gmail.com>
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 <mir at miras.org> wrote:
>> On Thu, 26 Dec 2013 12:31:30 -0500
>> Chris Nagele <nagele at wildbit.com> 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 <at> rasmussen <dot> cc
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
>> mir <at> datanom <dot> net
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
>> mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131228/9b1689b9/attachment.bin>

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: <CAHfYOdXsTBYu=3Aex041e+cy9O5Gy+UZnBjov-Z0V-6uRGMpeQ@mail.gmail.com>
References: <CAHfYOdWwZ=t6VV5g9r9pPV9SvsJ=8GEh_gsjBnQz-1btG8OHLw@mail.gmail.com>
	<20131226185202.201e1488@sleipner.datanom.net>
	<CAHfYOdXsTBYu=3Aex041e+cy9O5Gy+UZnBjov-Z0V-6uRGMpeQ@mail.gmail.com>
Message-ID: <20131228185136.3a52054a@sleipner.datanom.net>

On Sat, 28 Dec 2013 12:22:35 -0500
Chris Nagele <nagele at wildbit.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131228/7fc13c3e/attachment.bin>

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: <CAHfYOdWwZ=t6VV5g9r9pPV9SvsJ=8GEh_gsjBnQz-1btG8OHLw@mail.gmail.com>
	<20131226185202.201e1488@sleipner.datanom.net>
	<CAHfYOdXsTBYu=3Aex041e+cy9O5Gy+UZnBjov-Z0V-6uRGMpeQ@mail.gmail.com>
	<20131228185136.3a52054a@sleipner.datanom.net>
Message-ID: <CAHfYOdXbMiT0pBC2xT_w+yL57yifW6qJW8jc=m0VioBwKvbKgw@mail.gmail.com>

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 <nagele at wildbit.com <javascript:;>> 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 <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131228/48500a59/attachment.html>

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: <CAHfYOdXbMiT0pBC2xT_w+yL57yifW6qJW8jc=m0VioBwKvbKgw@mail.gmail.com>
References: <CAHfYOdWwZ=t6VV5g9r9pPV9SvsJ=8GEh_gsjBnQz-1btG8OHLw@mail.gmail.com>
	<20131226185202.201e1488@sleipner.datanom.net>
	<CAHfYOdXsTBYu=3Aex041e+cy9O5Gy+UZnBjov-Z0V-6uRGMpeQ@mail.gmail.com>
	<20131228185136.3a52054a@sleipner.datanom.net>
	<CAHfYOdXbMiT0pBC2xT_w+yL57yifW6qJW8jc=m0VioBwKvbKgw@mail.gmail.com>
Message-ID: <CAHfYOdXPfkitmpn3vUvx=FecKsEq3BdL++btiFNtEcVCyodOgQ@mail.gmail.com>

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 <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <at> rasmussen <dot> cc
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
>> mir <at> datanom <dot> net
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
>> mir <at> miras <dot> 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 <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <at> rasmussen <dot> cc 
> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E 
> >> mir <at> datanom <dot> net 
> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C 
> >> mir <at> miras <dot> 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: <CAHfYOdWWy+Au1Zsf_g+zSS1nrN5nMnx59iYzrEHZxjq7F_h+FA@mail.gmail.com>

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 <mir at miras.org> wrote:
> Did you remember to restart SSH on the server?
>
> On Dec 28, 2013 10:12 PM, Chris Nagele <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <at> rasmussen <dot> cc
>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
>> >> mir <at> datanom <dot> net
>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
>> >> mir <at> miras <dot> 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: <CAHfYOdWWy+Au1Zsf_g+zSS1nrN5nMnx59iYzrEHZxjq7F_h+FA@mail.gmail.com>
References: <52bf406a.09d10e0a.026b.fffff6d6SMTPIN_ADDED_MISSING@mx.google.com>
	<CAHfYOdWWy+Au1Zsf_g+zSS1nrN5nMnx59iYzrEHZxjq7F_h+FA@mail.gmail.com>
Message-ID: <CAHfYOdXTjBQHB0ZBap5kT0qhBDQ5QeiBOzKjAUKg6nWOMqrO6Q@mail.gmail.com>

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 <nagele at wildbit.com> 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 <mir at miras.org> wrote:
>> Did you remember to restart SSH on the server?
>>
>> On Dec 28, 2013 10:12 PM, Chris Nagele <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <at> rasmussen <dot> cc
>>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
>>> >> mir <at> datanom <dot> net
>>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
>>> >> mir <at> miras <dot> 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: <CALeZrrRHeGQq3VDVLFqi2F6wt=R-Mazx9N7nt4pcvE2eoajXdQ@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131230/51d37644/attachment.html>

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: <CAHfYOdXTjBQHB0ZBap5kT0qhBDQ5QeiBOzKjAUKg6nWOMqrO6Q@mail.gmail.com>
References: <52bf406a.09d10e0a.026b.fffff6d6SMTPIN_ADDED_MISSING@mx.google.com>
	<CAHfYOdWWy+Au1Zsf_g+zSS1nrN5nMnx59iYzrEHZxjq7F_h+FA@mail.gmail.com>
	<CAHfYOdXTjBQHB0ZBap5kT0qhBDQ5QeiBOzKjAUKg6nWOMqrO6Q@mail.gmail.com>
Message-ID: <CAHfYOdW9r4Nng=jDhJeh7JVNxz08Vd40Sc885Xv6acpMM6SoSQ@mail.gmail.com>

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 <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <mir at miras.org> wrote:
>>> Did you remember to restart SSH on the server?
>>>
>>> On Dec 28, 2013 10:12 PM, Chris Nagele <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <nagele at wildbit.com> 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 <at> rasmussen <dot> cc
>>>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
>>>> >> mir <at> datanom <dot> net
>>>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
>>>> >> mir <at> miras <dot> 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!
>>>>
>>>>

