Re: [OmniOS-discuss] Change Zone Hostname

[Alex McWhirter]

I had been toying around with a lot of different settings, it's possible I just 
messed something up in the process. Let me try again with a fresh zone.

Sent from my iPhone

> On Dec 11, 2014, at 2:18 AM, Tim Rice  wrote:
> 
> On Thu, 11 Dec 2014, Alex McWhirter wrote:
> 
> | Yea, some services picked it up but others did not. It seems the 
> identity/node service does not have the config variable set for nodename. I 
> attempted to set it but received and error saying that the variable didn't 
> exist.
> | 
> | I don't think this was ever an intended function for a zone.
> 
> Well it does on solaris 10 so I thought it might be worth a try.
> .
> # uname -n
> ftp22
> # zonename
> ftp
> # cat /etc/nodename
> ftp22
> #
> .
> 
> | 
> | Sent from my iPhone
> | 
> | > On Dec 11, 2014, at 1:30 AM, Tim Rice  wrote:
> | > 
> | >> On Wed, 10 Dec 2014, Alex McWhirter wrote:
> | >> 
> | >> I have a small cluster of servers hosting zones over multiple VLAN’s. I 
> would like to name the zones so that they don’t run into naming collisions. 
> For example, instead of “web0” i would like to name them “2049_web0” and 
> “2050_web0”. The problem is that this set’s the hostname to “_web0”. Is 
> there a way to change the hostname to be something different than the zone 
> name?
> | >> 
> | >> I had a look at /etc/nodname and it is an empty file when used in a zone.
> | > 
> | > What happens if you put the hostname you want in /etc/nodname ?
> | > 
> | > 
> | > -- 
> | > Tim RiceMultitalents
> | > t...@multitalents.net
> | ___
> | OmniOS-discuss mailing list
> | OmniOS-discuss@lists.omniti.com
> | http://lists.omniti.com/mailman/listinfo/omnios-discuss
> | 
> | 
> | 
> 
> -- 
> Tim RiceMultitalents(707) 456-1146
> t...@multitalents.net
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Change Zone Hostname

[Tim Rice]

On Thu, 11 Dec 2014, Alex McWhirter wrote:

| Yea, some services picked it up but others did not. It seems the 
identity/node service does not have the config variable set for nodename. I 
attempted to set it but received and error saying that the variable didn't 
exist.
| 
| I don't think this was ever an intended function for a zone.

Well it does on solaris 10 so I thought it might be worth a try.
.
# uname -n
ftp22
# zonename
ftp
# cat /etc/nodename
ftp22
#
.

| 
| Sent from my iPhone
| 
| > On Dec 11, 2014, at 1:30 AM, Tim Rice  wrote:
| > 
| >> On Wed, 10 Dec 2014, Alex McWhirter wrote:
| >> 
| >> I have a small cluster of servers hosting zones over multiple VLAN’s. I 
would like to name the zones so that they don’t run into naming collisions. For 
example, instead of “web0” i would like to name them “2049_web0” and 
“2050_web0”. The problem is that this set’s the hostname to “_web0”. Is 
there a way to change the hostname to be something different than the zone name?
| >> 
| >> I had a look at /etc/nodname and it is an empty file when used in a zone.
| > 
| > What happens if you put the hostname you want in /etc/nodname ?
| > 
| > 
| > -- 
| > Tim RiceMultitalents
| > t...@multitalents.net
| ___
| OmniOS-discuss mailing list
| OmniOS-discuss@lists.omniti.com
| http://lists.omniti.com/mailman/listinfo/omnios-discuss
| 
| 
| 

-- 
Tim RiceMultitalents(707) 456-1146
t...@multitalents.net
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Change Zone Hostname

[Dan McDonald]

Editing nodename and rebooting the zone will give it a different name.  I do 
this on my own HDC.

Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Dec 11, 2014, at 1:30 AM, Tim Rice  wrote:
> 
>> On Wed, 10 Dec 2014, Alex McWhirter wrote:
>> 
>> I have a small cluster of servers hosting zones over multiple VLAN’s. I 
>> would like to name the zones so that they don’t run into naming collisions. 
>> For example, instead of “web0” i would like to name them “2049_web0” and 
>> “2050_web0”. The problem is that this set’s the hostname to “_web0”. Is 
>> there a way to change the hostname to be something different than the zone 
>> name?
>> 
>> I had a look at /etc/nodname and it is an empty file when used in a zone.
> 
> What happens if you put the hostname you want in /etc/nodname ?
> 
> 
> -- 
> Tim RiceMultitalents
> t...@multitalents.net
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Change Zone Hostname

[Alex McWhirter]

Yea, some services picked it up but others did not. It seems the identity/node 
service does not have the config variable set for nodename. I attempted to set 
it but received and error saying that the variable didn't exist.

I don't think this was ever an intended function for a zone.

Sent from my iPhone

> On Dec 11, 2014, at 1:30 AM, Tim Rice  wrote:
> 
>> On Wed, 10 Dec 2014, Alex McWhirter wrote:
>> 
>> I have a small cluster of servers hosting zones over multiple VLAN’s. I 
>> would like to name the zones so that they don’t run into naming collisions. 
>> For example, instead of “web0” i would like to name them “2049_web0” and 
>> “2050_web0”. The problem is that this set’s the hostname to “_web0”. Is 
>> there a way to change the hostname to be something different than the zone 
>> name?
>> 
>> I had a look at /etc/nodname and it is an empty file when used in a zone.
> 
> What happens if you put the hostname you want in /etc/nodname ?
> 
> 
> -- 
> Tim RiceMultitalents
> t...@multitalents.net
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Change Zone Hostname

[Tim Rice]

On Wed, 10 Dec 2014, Alex McWhirter wrote:

> I have a small cluster of servers hosting zones over multiple VLAN’s. I would 
> like to name the zones so that they don’t run into naming collisions. For 
> example, instead of “web0” i would like to name them “2049_web0” and 
> “2050_web0”. The problem is that this set’s the hostname to “_web0”. Is 
> there a way to change the hostname to be something different than the zone 
> name?
> 
> I had a look at /etc/nodname and it is an empty file when used in a zone.

What happens if you put the hostname you want in /etc/nodname ?


-- 
Tim RiceMultitalents
t...@multitalents.net
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Change Zone Hostname

[Alex McWhirter]

I have a small cluster of servers hosting zones over multiple VLAN’s. I would 
like to name the zones so that they don’t run into naming collisions. For 
example, instead of “web0” i would like to name them “2049_web0” and 
“2050_web0”. The problem is that this set’s the hostname to “_web0”. Is 
there a way to change the hostname to be something different than the zone name?

I had a look at /etc/nodname and it is an empty file when used in a zone.
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] weird library issue

[Ian Kaufman]

Thanks Dan.

Alas, I get stuck here:

root@massive02-b:~# pkg -R /mnt update
Creating Plan -
pkg update: The certificate which issued this
certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151012
Release Signing Certificate/emailAddress=omnios-supp...@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/locale/gu@0.5.11,5.11-0.151012:20140913T033547Z

Ian

On Wed, Dec 10, 2014 at 10:55 AM, Dan McDonald  wrote:
>
>> On Dec 10, 2014, at 1:42 PM, Ian Kaufman  wrote:
>>
>> It looks like this system is in some weird state where there are
>> packages from 151006 and 151008.
>
> Oh my.
>
> Yes, you've been bitten by the pkg upgrade problems between 006 and 008.  
> This was before my time here, so I'm not sure how best to extricate yourself 
> from things.
>
> If you want, you can jump forward to the current stable release (r151012).  
> If you want to try that, and you don't have zones, do this:
>
>
> 1.) Create a new BE, call it 012 for this example:  beadm create 012
>
> 2.) Mount the BE on /mnt:   beadm mount 012 /mnt
>
> 3.) Change the publisher on the new BE to point to r151012's repo:
> pkg -R /mnt set-publisher -G http://pkg.omniti.com/omnios/release/ -g 
> http://pkg.omniti.com/omnios/r151012/ omnios
>
> 4.) Apply the update to the new BE:   pkg -R /mnt update
>
> 5.) Unmount the BE:   beadm umount 012
>
> 6.) Either reboot and use the GRUB menu to try out the new 012 BE, or "beadm 
> activate 012" to make it go there on the next reboot.
>
>
> Dan
>



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] NEWS: r151008 packages retroactively separated into own repo

[Dan McDonald]

Thank you to Eric Sproul (now of Circonus)!  Here's his good news:

.  .  .

Good news everyone!

As many of you are aware, the current practice for core OmniOS
packaging is to separate packages for a given release into their own
repository.  This was prompted by all the headaches caused when
r151008 packages were added to the release repo where r151006 (and
earlier) lived.  As of about an hour ago, I have split out the r151008
packages from http://pkg.omniti.com/omnios/release/ into
http://pkg.omniti.com/omnios/r151008/ .

The good news is that LTS users now no longer need to take
extraordinary measures to stay on r151006.  We'll be updating the
documentation shortly.  If you've already done the pkg freeze stuff,
you can either leave it in place and plan to remove it when you're
ready to upgrade to the next LTS, or go ahead and remove it now.
Either way, you will never again see post-r151006 packages in the
/omnios/release/ location.

Since r151008 is EOL this is essentially just an archival operation--
no new packages will ever be published for this release.  Those still
running r151008 (pro tip: you should upgrade!) will no longer be able
to install any existing packages unless you switch publisher URLs:
pkg set-publisher -G  -g  omnios

.  .  .

I will reiterate the protip mentioned earlier. You should not be running 008 
anywhere anymore.

Thanks again to Eric!

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Stephan Budach]

Hi Dan,

Am 10.12.14 um 21:17 schrieb Dan McDonald:

On Dec 10, 2014, at 3:14 PM, Stephan Budach  wrote:

Now, this one… I don't get it. ;)

root@nfsvmpool01:~# ipadm create-if ixgbe3
root@nfsvmpool01:~# ipadm show-if
IFNAME STATECURRENT  PERSISTENT
lo0ok   -m-v--46 ---
igb0   ok   bm46 -46
ixgbe0 ok   bm46 -46
ixgbe3 down bm46 -46
root@nfsvmpool01:~# ipadm create-addr -T static -a 192.168.1.1/24 
ixgbe3/v4static
root@nfsvmpool01:~# ping 192.168.1.2
192.168.1.2 is alive
root@nfsvmpool01:~# dladm show-linkprop -p mtu
LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
igb0 mtu rw   1500 1500   60-9000
igb1 mtu rw   1500 1500   60-9000
igb2 mtu rw   1500 1500   60-9000
igb3 mtu rw   1500 1500   60-9000
ixgbe2   mtu rw   1500 1500   1500-15500
ixgbe0   mtu rw   1500 1500   1500-15500
ixgbe3   mtu rw   9216 1500   1500-15500
ixgbe1   mtu rw   1500 1500   1500-15500

Call me old-fashioned, but I'm used to doing this all with ifconfig(1M) and 
editing /etc/hostname.X files.  I know I should learn this new stuff, but I 
never have had the wherewithal until now.


I do have a OmniOS 012 system, where all this works without these issues… ;)

REALLY?  So this fails on 006, but works on 012?!  I quickly looked at 
illumos-gate to see what all got fixed if anything, and I didn't see anything 
that would've necessarily improved things.


Now, I won#t change the mtu that soon again, I guess…

I guess.

Sorry I couldn't provide an authoritative answer,
Dan


Ha ha - never mind! Sometimes, I find it enough to chat about such 
issues with someone.
I do have to admit, that on the 012 system, none of the ixgbe ports were 
already in use. You provided mental care and that alone helped. ;)
Besides, you' re able to make something of the illumos sources - one 
thing that really escapes me…


Cheers,
budy
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Dan McDonald]

> On Dec 10, 2014, at 3:14 PM, Stephan Budach  wrote:
> 
>> 
> Now, this one… I don't get it. ;)
> 
> root@nfsvmpool01:~# ipadm create-if ixgbe3
> root@nfsvmpool01:~# ipadm show-if
> IFNAME STATECURRENT  PERSISTENT
> lo0ok   -m-v--46 ---
> igb0   ok   bm46 -46
> ixgbe0 ok   bm46 -46
> ixgbe3 down bm46 -46
> root@nfsvmpool01:~# ipadm create-addr -T static -a 192.168.1.1/24 
> ixgbe3/v4static
> root@nfsvmpool01:~# ping 192.168.1.2
> 192.168.1.2 is alive
> root@nfsvmpool01:~# dladm show-linkprop -p mtu
> LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
> igb0 mtu rw   1500 1500   60-9000
> igb1 mtu rw   1500 1500   60-9000
> igb2 mtu rw   1500 1500   60-9000
> igb3 mtu rw   1500 1500   60-9000
> ixgbe2   mtu rw   1500 1500   1500-15500
> ixgbe0   mtu rw   1500 1500   1500-15500
> ixgbe3   mtu rw   9216 1500   1500-15500
> ixgbe1   mtu rw   1500 1500   1500-15500

Call me old-fashioned, but I'm used to doing this all with ifconfig(1M) and 
editing /etc/hostname.X files.  I know I should learn this new stuff, but I 
never have had the wherewithal until now.

> I do have a OmniOS 012 system, where all this works without these issues… ;)

REALLY?  So this fails on 006, but works on 012?!  I quickly looked at 
illumos-gate to see what all got fixed if anything, and I didn't see anything 
that would've necessarily improved things.

> Now, I won#t change the mtu that soon again, I guess…

I guess.

Sorry I couldn't provide an authoritative answer,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Stephan Budach]

Am 10.12.14 um 20:56 schrieb Stephan Budach:

I don't know… it seems to have serious issues with the MTU specifically…

root@nfsvmpool01:~# dladm show-phys
LINK MEDIASTATE  SPEED DUPLEX DEVICE
igb0 Ethernet up 1000 full  igb0
igb1 Ethernet unknown1000 full  igb1
igb2 Ethernet unknown0 half  igb2
igb3 Ethernet unknown0 half  igb3
ixgbe2   Ethernet down   0 unknown   ixgbe2
ixgbe0   Ethernet up 1 full ixgbe0
ixgbe3   Ethernet up 1 full ixgbe3
ixgbe1   Ethernet down   0 unknown   ixgbe1

root@nfsvmpool01:~# dladm show-linkprop -p mtu
LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
igb0 mtu rw   1500 1500   60-9000
igb1 mtu rw   1500 1500   60-9000
igb2 mtu rw   1500 1500   60-9000
igb3 mtu rw   1500 1500   60-9000
ixgbe2   mtu rw   1500 1500   1500-15500
ixgbe0   mtu rw   1500 1500   1500-15500
^C

So, dladm shows the phys status, but it isn't able to tell me about 
the MTU of ixgbe3…?


Needless to mention that ipadm also doesn't work. I will try to reset 
the MTU back to 1500 again and seem if I can get the interface back. 

Now, this one… I don't get it. ;)

root@nfsvmpool01:~# ipadm create-if ixgbe3
root@nfsvmpool01:~# ipadm show-if
IFNAME STATECURRENT  PERSISTENT
lo0ok   -m-v--46 ---
igb0   ok   bm46 -46
ixgbe0 ok   bm46 -46
ixgbe3 down bm46 -46
root@nfsvmpool01:~# ipadm create-addr -T static -a 192.168.1.1/24 
ixgbe3/v4static

root@nfsvmpool01:~# ping 192.168.1.2
192.168.1.2 is alive
root@nfsvmpool01:~# dladm show-linkprop -p mtu
LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
igb0 mtu rw   1500 1500   60-9000
igb1 mtu rw   1500 1500   60-9000
igb2 mtu rw   1500 1500   60-9000
igb3 mtu rw   1500 1500   60-9000
ixgbe2   mtu rw   1500 1500   1500-15500
ixgbe0   mtu rw   1500 1500   1500-15500
ixgbe3   mtu rw   9216 1500   1500-15500
ixgbe1   mtu rw   1500 1500   1500-15500

I do have a OmniOS 012 system, where all this works without these issues… ;)

Now, I won#t change the mtu that soon again, I guess…

Cheers,
budy
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Stephan Budach]

Am 10.12.14 um 20:28 schrieb Dan McDonald:

On Dec 10, 2014, at 2:23 PM, Stephan Budach  wrote:

This worked, but I wanted to change the MTU, so I deciced to remove this config 
again:

ipadm delete-addr ixgb3/v4static
ipadm delete-if ixgbe3

Interesting.  Your "dladm show-linkprop" output didn't have anything for 
ixgbe3.  I wonder if that happened because of the delete-if for ipadm?


Then I tried to set the MTU of ixgbe3 like this:
dladm set-linkprop -p mtu=9216 ixgbe3

I can't remember, if that already stalled, however, now dladm show-linkprop 
hangs and it does need to get killed -9.

It's probably not able to find ixgbe3, and hanging.  The question is how did 
ixgbe3 disappear from the list of links (vs. ip addrs)?


I don't know… it seems to have serious issues with the MTU specifically…

root@nfsvmpool01:~# dladm show-phys
LINK MEDIASTATE  SPEED DUPLEXDEVICE
igb0 Ethernet up 1000 full  igb0
igb1 Ethernet unknown1000 full  igb1
igb2 Ethernet unknown0 half  igb2
igb3 Ethernet unknown0 half  igb3
ixgbe2   Ethernet down   0 unknown   ixgbe2
ixgbe0   Ethernet up 1 full  ixgbe0
ixgbe3   Ethernet up 1 full  ixgbe3
ixgbe1   Ethernet down   0 unknown   ixgbe1

root@nfsvmpool01:~# dladm show-linkprop -p mtu
LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
igb0 mtu rw   1500 1500   60-9000
igb1 mtu rw   1500 1500   60-9000
igb2 mtu rw   1500 1500   60-9000
igb3 mtu rw   1500 1500   60-9000
ixgbe2   mtu rw   1500 1500   1500-15500
ixgbe0   mtu rw   1500 1500   1500-15500
^C

So, dladm shows the phys status, but it isn't able to tell me about the 
MTU of ixgbe3…?


Needless to mention that ipadm also doesn't work. I will try to reset 
the MTU back to 1500 again and seem if I can get the interface back.


Cheers,
budy

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Dan McDonald]

> On Dec 10, 2014, at 2:23 PM, Stephan Budach  wrote:
> 
> This worked, but I wanted to change the MTU, so I deciced to remove this 
> config again:
> 
> ipadm delete-addr ixgb3/v4static
> ipadm delete-if ixgbe3

Interesting.  Your "dladm show-linkprop" output didn't have anything for 
ixgbe3.  I wonder if that happened because of the delete-if for ipadm?

> Then I tried to set the MTU of ixgbe3 like this:
> dladm set-linkprop -p mtu=9216 ixgbe3
> 
> I can't remember, if that already stalled, however, now dladm show-linkprop 
> hangs and it does need to get killed -9.

It's probably not able to find ixgbe3, and hanging.  The question is how did 
ixgbe3 disappear from the list of links (vs. ip addrs)?

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Stephan Budach]

Am 10.12.14 um 20:12 schrieb Dan McDonald:

You said it was ipadm earlier, not dladm.

Well, yes it was. I am sure that ipadm will now hang as well.

On Dec 10, 2014, at 2:07 PM, Stephan Budach  wrote:
Ahh… here we go again…

root@nfsvmpool01:~#  dladm show-linkprop -p mtu
LINK PROPERTYPERM VALUE  DEFAULT POSSIBLE
igb0 mtu rw   1500   1500 60-9000
igb1 mtu rw   1500   1500 60-9000
igb2 mtu rw   1500   1500 60-9000
igb3 mtu rw   1500   1500 60-9000
ixgbe2   mtu rw   1500   1500 1500-15500
ixgbe0   mtu rw   1500   1500 1500-15500


root@nfsvmpool01:~#  pstack `pgrep dladm`
23948:  dladm show-linkprop -p mtu

What I did was to remove the ixgbe3 interface and try to set the mtu to 9216 
like this:

How did you remove the ixgbe3 interface?  With delete-phys?


dladm set-linkprop -p mtu=9216 ixgbe3

I seem only to be able to kill dladm by killing it using kill -9 

It may be hanging because you removed it.

Generally speaking, you shouldn't remove hardware entities (vs. created 
entities like vnics, aggrs, etc.) with dladm.  They are harmless lying in the 
background, if you don't have them configured up with ifconfig or ipadm, you 
won't be using them.

Dan

Maybe I have told things not clearly enough. I have created the 
interface like this:


ipadm create-if ixgbe3
ipadm create-addr -T static -a 192.168.1.1/24 ixgbe3/v4static

This worked, but I wanted to change the MTU, so I deciced to remove this 
config again:


ipadm delete-addr ixgb3/v4static
ipadm delete-if ixgbe3

Then I tried to set the MTU of ixgbe3 like this:
dladm set-linkprop -p mtu=9216 ixgbe3

I can't remember, if that already stalled, however, now dladm 
show-linkprop hangs and it does need to get killed -9.


Cheers,
budy

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Dan McDonald]

You said it was ipadm earlier, not dladm.

> On Dec 10, 2014, at 2:07 PM, Stephan Budach  wrote:
> Ahh… here we go again…
> 
> root@nfsvmpool01:~#  dladm show-linkprop -p mtu
> LINK PROPERTYPERM VALUE  DEFAULT POSSIBLE
> igb0 mtu rw   1500   1500 60-9000
> igb1 mtu rw   1500   1500 60-9000
> igb2 mtu rw   1500   1500 60-9000
> igb3 mtu rw   1500   1500 60-9000
> ixgbe2   mtu rw   1500   1500 1500-15500
> ixgbe0   mtu rw   1500   1500 1500-15500
> 
> 
> root@nfsvmpool01:~#  pstack `pgrep dladm`
> 23948:  dladm show-linkprop -p mtu
> 
> What I did was to remove the ixgbe3 interface and try to set the mtu to 9216 
> like this:

How did you remove the ixgbe3 interface?  With delete-phys?

> dladm set-linkprop -p mtu=9216 ixgbe3
> 
> I seem only to be able to kill dladm by killing it using kill -9 

It may be hanging because you removed it.

Generally speaking, you shouldn't remove hardware entities (vs. created 
entities like vnics, aggrs, etc.) with dladm.  They are harmless lying in the 
background, if you don't have them configured up with ifconfig or ipadm, you 
won't be using them.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Stephan Budach]

Am 10.12.14 um 17:38 schrieb Stephan Budach:

Am 10.12.14 um 17:20 schrieb Dan McDonald:
On Dec 10, 2014, at 11:12 AM, Stephan Budach  
wrote:


Hi Dan,

I actually don't know the term "incantation" yet, but I assume, that 
you wanted to know the release of OmniOS I am running?
I meant what exact command-line arguments you typed for ipadm(1M).  
But that's okay, because it's good to know the other things you're 
about to show me.


What is really funny, is that running pstack against the ipadm 
process, somehow brought things back in line:


root@nfsvmpool01:~# pkg info entire
  Name: entire
   Summary: Incorporation to constrain core system packages to 
same build
   Description: This package constrains core system package versions 
to the same
build and provides a minimal set of additional 
packages.

 State: Installed
 Publisher: omnios
   Version: 11
Build Release: 5.11
Branch: 0.151006
Packaging Date: Mon Oct 27 19:15:00 2014
  Size: 0.00 B
  FMRI: pkg://omnios/entire@11,5.11-0.151006:20141027T191500Z

I was running ipadm create-if ixgbe3 in another session when I ran 
pstack as suggested:


root@nfsvmpool01:~# pstack `pgrep ipadm`
12397:ipadm create-if ixgbe3
fef07723 open (8047190, 2, fec9404c)
feef24f8 open (8047190, 2, fec9404c, 8068db8, 11, feffb0a4) + 105
fec935f8 i_dlpi_open (8068db8, 80475dc, 10, 1, 8047f00, 5) + ed
fec93768 i_dlpi_style1_open (8068db0, 804761c, 20, fec9386d, 3, 3) + 2a
fec939a8 dlpi_open (8047f00, 8047cd4, 10, fedf1541) + 149
fedf17fb i_ipadm_plumb_if (8068968, 8047f00, 2, 3) + 2cb
fedf0ed4 i_ipadm_create_if (8068968, 8047f00, 2, 3, 0, 3) + 9a
fedf0fc2 ipadm_create_if (8068968, 8047f00, 0, 3) + e3
0805553e do_create_if (2) + 8f
08052e72 main (80555ca, feffb0a4, 8047e30, 80525c7, 3, 8047e3c) 
+ df

080525c7 _start   (3, 8047ef0, 8047ef6, 8047f00, 0, 8047f07) + 83

ipadm returned and created the interface, just as if nothing ever 
happened. Afterwards I was able to create and delete interfaces 
without any issue on the ixgbe adaptors.
That's VERY odd, albeit with pleasant results.  I wouldn't think 
pstack would unblock something like what you showed me.  You're 
running 006 (long-term support), but I'm not seeing any major changes 
in the plumbing of interfaces between then and now.

Yes, it is… ;)


You mentioned a desire to not reboot your system.  Did you plug in 
these ixgbes while booted (i.e. hotplugging)?  Or were they always 
there, and you just hadn't configured them until now?
The two cards had been in the system right from the start and I 
already configured one port (ixgbe0) to connect to a 10GbE port on our 
6509, which went without issues. I wanted to resolve this issue 
without rebooting, since rebooting would have killed 53 VMs that are 
residing on my NFS export that is running over ixgbe0.
It seems like you tickled a race condition or some other odd 
combination of circumstances that inspecting the ipadm(1M) process 
jostled free.  I don't have any ixgbe handy at the moment, but had I, 
I'd like to know if this is a reproducible problem.  The only theory 
I can think of is that something weird happened while ipadm was 
communicating with ipmgmtd, and inspecting the process with pstack 
allowed a context switch to occur.
I can maybe help with that as well… I tried to set the MTU to the 
maximum, that the driver would accept and I ended up with a mtu of 
15500 (what a odd number anyway) which I set using dladm on ixgbe3. 
When i tried to create the interface using ipadm, that was the moment, 
when things went quirky. Although I trimmed the mtu down to a 
reasonable 9216 ipadm wouldn't create any longer and would hang at 
creating interfaces on any of the remaining 3 ports of my T540-X2's.


Thank you, and while it's nice to see things working, I'm sorry I 
don't have a better explanation about what happened, or the ability 
to immediately reproduce this bug.


Dan


Ha ha, no prob - you already provided a great deal of help!

Thanks a lot,
budy

Ahh… here we go again…

root@nfsvmpool01:~#  dladm show-linkprop -p mtu
LINK PROPERTYPERM VALUE  DEFAULT POSSIBLE
igb0 mtu rw   1500   1500 60-9000
igb1 mtu rw   1500   1500 60-9000
igb2 mtu rw   1500   1500 60-9000
igb3 mtu rw   1500   1500 60-9000
ixgbe2   mtu rw   1500   1500 1500-15500
ixgbe0   mtu rw   1500   1500 1500-15500


root@nfsvmpool01:~#  pstack `pgrep dladm`
23948:  dladm show-linkprop -p mtu

What I did was to remove the ixgbe3 interface and try to set the mtu to 
9216 like this:


dladm set-linkprop -p mtu=9216 ixgbe3

I seem only to be able to kill dladm by killing it using kill -9 

Cheers,
budy
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/list

Re: [OmniOS-discuss] weird library issue

[Dan McDonald]

> On Dec 10, 2014, at 1:42 PM, Ian Kaufman  wrote:
> 
> It looks like this system is in some weird state where there are
> packages from 151006 and 151008.

Oh my.

Yes, you've been bitten by the pkg upgrade problems between 006 and 008.  This 
was before my time here, so I'm not sure how best to extricate yourself from 
things.

If you want, you can jump forward to the current stable release (r151012).  If 
you want to try that, and you don't have zones, do this:


1.) Create a new BE, call it 012 for this example:  beadm create 012

2.) Mount the BE on /mnt:   beadm mount 012 /mnt

3.) Change the publisher on the new BE to point to r151012's repo:
pkg -R /mnt set-publisher -G http://pkg.omniti.com/omnios/release/ -g 
http://pkg.omniti.com/omnios/r151012/ omnios

4.) Apply the update to the new BE:   pkg -R /mnt update

5.) Unmount the BE:   beadm umount 012

6.) Either reboot and use the GRUB menu to try out the new 012 BE, or "beadm 
activate 012" to make it go there on the next reboot.


Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] weird library issue

[Ian Kaufman]

It looks like this system is in some weird state where there are
packages from 151006 and 151008.

For example, /etc/release shows:

root@massive02-b:~# cat /etc/release
  OmniOS v11 r151008
  Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
  Use is subject to license terms.

but, when I try to do a pkg update, I see this (multiple repeating lines):

  No suitable version of required package
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151008:20131204T231613Z
found:
Reject:  
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151008:20131204T231613Z
Reason:  A version for 'incorporate' dependency on
pkg:/library/security/openssl@1.0.1,5.11-0.151008 cannot be found
  No suitable version of required package
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151004:20121024T180535Z
found:
Reject:  
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151004:20121024T180535Z
Reason:  A version for 'incorporate' dependency on
pkg:/archiver/gnu-tar@1.26,5.11-0.151004 cannot be found
  No suitable version of required package
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151006:20130506T214442Z
found:
Reject:  
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151006:20130506T214442Z
Reason:  A version for 'incorporate' dependency on
pkg:/archiver/gnu-tar@1.26,5.11-0.151006 cannot be found

and for openssl, I see this:

root@massive02-b:~# pkg info library/security/openssl
  Name: library/security/openssl
   Summary: openssl - A toolkit for Secure Sockets Layer (SSL
v2/v3) and Transport Layer (TLS v1) protocols and general purpose
cryptographic library
 State: Installed
 Publisher: omnios
   Version: 1.0.1.10 (1.0.1j)
 Build Release: 5.11
Branch: 0.151006
Packaging Date: October 15, 2014 03:40:22 PM
  Size: 18.08 MB
  FMRI:
pkg://omnios/library/security/openssl@1.0.1.10,5.11-0.151006:20141015T154022Z
root@massive02-b:~# pkg install
pkg:/library/security/openssl@1.0.1,5.11-0.151008
Creating Plan /
pkg install: No matching version of library/security/openssl can be installed:
  Reject:  
pkg://omnios/library/security/openssl@1.0.1.5,5.11-0.151008:20131204T024253Z
   
pkg://omnios/library/security/openssl@1.0.1.6,5.11-0.151008:20140110T173804Z
   
pkg://omnios/library/security/openssl@1.0.1.7,5.11-0.151008:20140407T220403Z
   
pkg://omnios/library/security/openssl@1.0.1.7,5.11-0.151008:20140408T142844Z
   
pkg://omnios/library/security/openssl@1.0.1.8,5.11-0.151008:20140605T140630Z
   
pkg://omnios/library/security/openssl@1.0.1.9,5.11-0.151008:20140807T035111Z
  Reason:  Newer version
pkg://omnios/library/security/openssl@1.0.1.10,5.11-0.151006:20141015T154022Z
is already installed

Ian

On Wed, Dec 10, 2014 at 10:15 AM, Dan McDonald  wrote:
>
>> On Dec 10, 2014, at 12:01 PM, Ian Kaufman  wrote:
>>
>> Hi all,
>>
>> I have a situation where a bunch of libs are complaining about missing
>> the following:
>>
>> libc.so.1 (ILLUMOS_0.7)
>>
>> or
>>
>> libc.so.1 (ILLUMOS_0.6)
>>
>> This is happening on one system, but I have others that are fine. A
>> standard libc.so.1 exists, but various libs are looking for the tagged
>> one.
>>
>> Any ideas?
>
> You'll need to provide more data.  It's as if something you compiled was 
> compiled against a later version of libc, and then moved to an earlier 
> version of libc.
>
> Dan
>



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] weird library issue

[Dan McDonald]

> On Dec 10, 2014, at 12:01 PM, Ian Kaufman  wrote:
> 
> Hi all,
> 
> I have a situation where a bunch of libs are complaining about missing
> the following:
> 
> libc.so.1 (ILLUMOS_0.7)
> 
> or
> 
> libc.so.1 (ILLUMOS_0.6)
> 
> This is happening on one system, but I have others that are fine. A
> standard libc.so.1 exists, but various libs are looking for the tagged
> one.
> 
> Any ideas?

You'll need to provide more data.  It's as if something you compiled was 
compiled against a later version of libc, and then moved to an earlier version 
of libc.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] weird library issue

[Ian Kaufman]

Hi all,

I have a situation where a bunch of libs are complaining about missing
the following:

libc.so.1 (ILLUMOS_0.7)

or

libc.so.1 (ILLUMOS_0.6)

This is happening on one system, but I have others that are fine. A
standard libc.so.1 exists, but various libs are looking for the tagged
one.

Any ideas?

Thanks,

Ian

-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Stephan Budach]

Am 10.12.14 um 17:20 schrieb Dan McDonald:

On Dec 10, 2014, at 11:12 AM, Stephan Budach  wrote:

Hi Dan,

I actually don't know the term "incantation" yet, but I assume, that you wanted 
to know the release of OmniOS I am running?

I meant what exact command-line arguments you typed for ipadm(1M).  But that's 
okay, because it's good to know the other things you're about to show me.


What is really funny, is that running pstack against the ipadm process, somehow 
brought things back in line:

root@nfsvmpool01:~# pkg info entire
  Name: entire
   Summary: Incorporation to constrain core system packages to same build
   Description: This package constrains core system package versions to the same
build and provides a minimal set of additional packages.
 State: Installed
 Publisher: omnios
   Version: 11
Build Release: 5.11
Branch: 0.151006
Packaging Date: Mon Oct 27 19:15:00 2014
  Size: 0.00 B
  FMRI: pkg://omnios/entire@11,5.11-0.151006:20141027T191500Z

I was running ipadm create-if ixgbe3 in another session when I ran pstack as 
suggested:

root@nfsvmpool01:~# pstack `pgrep ipadm`
12397:ipadm create-if ixgbe3
fef07723 open (8047190, 2, fec9404c)
feef24f8 open (8047190, 2, fec9404c, 8068db8, 11, feffb0a4) + 105
fec935f8 i_dlpi_open (8068db8, 80475dc, 10, 1, 8047f00, 5) + ed
fec93768 i_dlpi_style1_open (8068db0, 804761c, 20, fec9386d, 3, 3) + 2a
fec939a8 dlpi_open (8047f00, 8047cd4, 10, fedf1541) + 149
fedf17fb i_ipadm_plumb_if (8068968, 8047f00, 2, 3) + 2cb
fedf0ed4 i_ipadm_create_if (8068968, 8047f00, 2, 3, 0, 3) + 9a
fedf0fc2 ipadm_create_if (8068968, 8047f00, 0, 3) + e3
0805553e do_create_if (2) + 8f
08052e72 main (80555ca, feffb0a4, 8047e30, 80525c7, 3, 8047e3c) + df
080525c7 _start   (3, 8047ef0, 8047ef6, 8047f00, 0, 8047f07) + 83

ipadm returned and created the interface, just as if nothing ever happened. 
Afterwards I was able to create and delete interfaces without any issue on the 
ixgbe adaptors.

That's VERY odd, albeit with pleasant results.  I wouldn't think pstack would 
unblock something like what you showed me.  You're running 006 (long-term 
support), but I'm not seeing any major changes in the plumbing of interfaces 
between then and now.

Yes, it is… ;)


You mentioned a desire to not reboot your system.  Did you plug in these ixgbes 
while booted (i.e. hotplugging)?  Or were they always there, and you just 
hadn't configured them until now?
The two cards had been in the system right from the start and I already 
configured one port (ixgbe0) to connect to a 10GbE port on our 6509, 
which went without issues. I wanted to resolve this issue without 
rebooting, since rebooting would have killed 53 VMs that are residing on 
my NFS export that is running over ixgbe0.

It seems like you tickled a race condition or some other odd combination of 
circumstances that inspecting the ipadm(1M) process jostled free.  I don't have 
any ixgbe handy at the moment, but had I, I'd like to know if this is a 
reproducible problem.  The only theory I can think of is that something weird 
happened while ipadm was communicating with ipmgmtd, and inspecting the process 
with pstack allowed a context switch to occur.
I can maybe help with that as well… I tried to set the MTU to the 
maximum, that the driver would accept and I ended up with a mtu of 15500 
(what a odd number anyway) which I set using dladm on ixgbe3. When i 
tried to create the interface using ipadm, that was the moment, when 
things went quirky. Although I trimmed the mtu down to a reasonable 9216 
ipadm wouldn't create any longer and would hang at creating interfaces 
on any of the remaining 3 ports of my T540-X2's.


Thank you, and while it's nice to see things working, I'm sorry I don't have a 
better explanation about what happened, or the ability to immediately reproduce 
this bug.

Dan


Ha ha, no prob - you already provided a great deal of help!

Thanks a lot,
budy
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Dan McDonald]

> On Dec 10, 2014, at 11:12 AM, Stephan Budach  wrote:
> 
> Hi Dan,
> 
> I actually don't know the term "incantation" yet, but I assume, that you 
> wanted to know the release of OmniOS I am running?

I meant what exact command-line arguments you typed for ipadm(1M).  But that's 
okay, because it's good to know the other things you're about to show me.

> What is really funny, is that running pstack against the ipadm process, 
> somehow brought things back in line:
> 
> root@nfsvmpool01:~# pkg info entire
>  Name: entire
>   Summary: Incorporation to constrain core system packages to same build
>   Description: This package constrains core system package versions to the 
> same
>build and provides a minimal set of additional packages.
> State: Installed
> Publisher: omnios
>   Version: 11
> Build Release: 5.11
>Branch: 0.151006
> Packaging Date: Mon Oct 27 19:15:00 2014
>  Size: 0.00 B
>  FMRI: pkg://omnios/entire@11,5.11-0.151006:20141027T191500Z
> 
> I was running ipadm create-if ixgbe3 in another session when I ran pstack as 
> suggested:
> 
> root@nfsvmpool01:~# pstack `pgrep ipadm`
> 12397:ipadm create-if ixgbe3
> fef07723 open (8047190, 2, fec9404c)
> feef24f8 open (8047190, 2, fec9404c, 8068db8, 11, feffb0a4) + 105
> fec935f8 i_dlpi_open (8068db8, 80475dc, 10, 1, 8047f00, 5) + ed
> fec93768 i_dlpi_style1_open (8068db0, 804761c, 20, fec9386d, 3, 3) + 2a
> fec939a8 dlpi_open (8047f00, 8047cd4, 10, fedf1541) + 149
> fedf17fb i_ipadm_plumb_if (8068968, 8047f00, 2, 3) + 2cb
> fedf0ed4 i_ipadm_create_if (8068968, 8047f00, 2, 3, 0, 3) + 9a
> fedf0fc2 ipadm_create_if (8068968, 8047f00, 0, 3) + e3
> 0805553e do_create_if (2) + 8f
> 08052e72 main (80555ca, feffb0a4, 8047e30, 80525c7, 3, 8047e3c) + df
> 080525c7 _start   (3, 8047ef0, 8047ef6, 8047f00, 0, 8047f07) + 83
> 
> ipadm returned and created the interface, just as if nothing ever happened. 
> Afterwards I was able to create and delete interfaces without any issue on 
> the ixgbe adaptors.

That's VERY odd, albeit with pleasant results.  I wouldn't think pstack would 
unblock something like what you showed me.  You're running 006 (long-term 
support), but I'm not seeing any major changes in the plumbing of interfaces 
between then and now.

You mentioned a desire to not reboot your system.  Did you plug in these ixgbes 
while booted (i.e. hotplugging)?  Or were they always there, and you just 
hadn't configured them until now?

It seems like you tickled a race condition or some other odd combination of 
circumstances that inspecting the ipadm(1M) process jostled free.  I don't have 
any ixgbe handy at the moment, but had I, I'd like to know if this is a 
reproducible problem.  The only theory I can think of is that something weird 
happened while ipadm was communicating with ipmgmtd, and inspecting the process 
with pstack allowed a context switch to occur.

Thank you, and while it's nice to see things working, I'm sorry I don't have a 
better explanation about what happened, or the ability to immediately reproduce 
this bug.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Stephan Budach]

Hi Dan,

I actually don't know the term "incantation" yet, but I assume, that you 
wanted to know the release of OmniOS I am running? If not, please 
correct me on that.
What is really funny, is that running pstack against the ipadm process, 
somehow brought things back in line:


root@nfsvmpool01:~# pkg info entire
  Name: entire
   Summary: Incorporation to constrain core system packages to same 
build
   Description: This package constrains core system package versions to 
the same

build and provides a minimal set of additional packages.
 State: Installed
 Publisher: omnios
   Version: 11
 Build Release: 5.11
Branch: 0.151006
Packaging Date: Mon Oct 27 19:15:00 2014
  Size: 0.00 B
  FMRI: pkg://omnios/entire@11,5.11-0.151006:20141027T191500Z

I was running ipadm create-if ixgbe3 in another session when I ran 
pstack as suggested:


root@nfsvmpool01:~# pstack `pgrep ipadm`
12397:ipadm create-if ixgbe3
 fef07723 open (8047190, 2, fec9404c)
 feef24f8 open (8047190, 2, fec9404c, 8068db8, 11, feffb0a4) + 105
 fec935f8 i_dlpi_open (8068db8, 80475dc, 10, 1, 8047f00, 5) + ed
 fec93768 i_dlpi_style1_open (8068db0, 804761c, 20, fec9386d, 3, 3) + 2a
 fec939a8 dlpi_open (8047f00, 8047cd4, 10, fedf1541) + 149
 fedf17fb i_ipadm_plumb_if (8068968, 8047f00, 2, 3) + 2cb
 fedf0ed4 i_ipadm_create_if (8068968, 8047f00, 2, 3, 0, 3) + 9a
 fedf0fc2 ipadm_create_if (8068968, 8047f00, 0, 3) + e3
 0805553e do_create_if (2) + 8f
 08052e72 main (80555ca, feffb0a4, 8047e30, 80525c7, 3, 8047e3c) + df
 080525c7 _start   (3, 8047ef0, 8047ef6, 8047f00, 0, 8047f07) + 83

ipadm returned and created the interface, just as if nothing ever 
happened. Afterwards I was able to create and delete interfaces without 
any issue on the ixgbe adaptors.


Cheers,
budy


Am 10.12.14 um 16:53 schrieb Dan McDonald:

On Dec 10, 2014, at 4:16 AM, Stephan Budach  wrote:

Hi all,

I have run into a situation, where ipadm hangs upon trying to create a new 
interface on my ixgbe adaptors. ipadm create-if ixgbe[0|1|2] didn't return and 
either got killed eventually by the system or by kill -9, which I issued 
against that process. I just tried to create another if on the on-board NIC 
igb1, which still works without issues.

What does "pstack `pgrep ipadm`" say when they hang?  And what's your exact incantation?  
And "killed by the system", what exactly do you mean?  Did ipadm(1M) time out?


What could cause ipadm to hang this way and is there a way to get ipadm working 
again on the ixgbe adaptors, preferreably without having to boot the OmniOS 
server, since it is serving a NFS export from the remaining functioning ixgbe3 
port to my Oracle VM servers.

I'll need more information before I can help you.

Dan




--
Stephan Budach
Deputy Managing Director
Jung von Matt/it-services GmbH
Glashüttenstraße 79
20357 Hamburg


Tel: +49 40-4321-1353
Fax: +49 40-4321-1114
E-Mail: stephan.bud...@jvm.de
Internet: http://www.jvm.com

Geschäftsführer: Frank Wilhelm, Stephan Budach (stellv.)
AG HH HRB 98380

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm hangs on interface creation

[Dan McDonald]

> On Dec 10, 2014, at 4:16 AM, Stephan Budach  wrote:
> 
> Hi all,
> 
> I have run into a situation, where ipadm hangs upon trying to create a new 
> interface on my ixgbe adaptors. ipadm create-if ixgbe[0|1|2] didn't return 
> and either got killed eventually by the system or by kill -9, which I issued 
> against that process. I just tried to create another if on the on-board NIC 
> igb1, which still works without issues.

What does "pstack `pgrep ipadm`" say when they hang?  And what's your exact 
incantation?  And "killed by the system", what exactly do you mean?  Did 
ipadm(1M) time out?

> What could cause ipadm to hang this way and is there a way to get ipadm 
> working again on the ixgbe adaptors, preferreably without having to boot the 
> OmniOS server, since it is serving a NFS export from the remaining 
> functioning ixgbe3 port to my Oracle VM servers.

I'll need more information before I can help you.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Parity error on path mpt_sas2

[Schweiss, Chip]

On Tue, Dec 9, 2014 at 9:51 AM, Dominik Hassler  wrote:

> Chip,
>
> when I had to reflash an onboard LSI2308 I used the UEFI shell. No
> fiddling around with boot disks etc.
>
> Not sure, if it is applicable to your problem.
>

That was the trick.  Under DOS I kept getting "ERROR: Failed to initialize
PAL."  Turns out this is a problem on X9 and newer Supermicro boards.

With the efi sas2flash version on a USB stick it was quite easy.  The
system BIOS has a boot override to drop into the UEFI shell from there I
could see the USB stick and run the erase and flash.

Thanks for everyone's input on this.  Hopefully I will only be upgrading in
the future and can stick to the Solaris version of sas2flash.

-Chip


> On 12/09/2014 03:49 PM, Schweiss, Chip wrote:
> > I'm still fighting this.
> >
> > Under OmniOS the erase function is disabled in sas2flash for solaris.
> >
> > I couldn't seem to find an iso bootable DOS that I could stage files
> > in.  FreeDOS1.0 won't mount the CD, 1.1 got rid of the live mode.
> > Tried a Linux rescue CD and I get " ERROR: Erase Flash Operation
> > Failed!"   Tried both P18 sas2flash and P20 sas2flash.
> >
> > What OS environment are you running this in?
> >
> >
> >
> > On Tue, Dec 9, 2014 at 3:06 AM, Filip Marvan  > > wrote:
> >
> > Hi,
> >
> > __ __
> >
> > first you have to erase P20 firmware with:
> >
> > __ __
> >
> > sas2flsh -o -e 6
> >
> > __ __
> >
> > now do not reboot(!) and flash P18 with
> >
> > __ __
> >
> > sas2flsh -f XX.bin -b mptsas2.rom
> >
> > __ __
> >
> > Filip
> >
> > __ __
> >
> > __ __
> >
> > *From:*OmniOS-discuss
> > [mailto:omnios-discuss-boun...@lists.omniti.com
> > ] *On Behalf Of
> > *Schweiss, Chip
> > *Sent:* Monday, December 08, 2014 08:09 AM
> > *To:* Filip Marvan
> > *Cc:* omnios-discuss@lists.omniti.com
> > 
> > *Subject:* Re: [OmniOS-discuss] Parity error on path mpt_sas2
> >
> > __ __
> >
> > I've got some new LSI HBAs I'm trying to downgrade from firmware
> > version 20 to 18.
> >
> > I'm getting errors when trying to downgrade:
> >
> > Attempting to flash firmware to LSI SAS SAS2308_2(D1) :
> >
> > Executing Operation: Flash Firmware Image
> >
> > Firmware Image has a Valid Checksum.
> > Firmware Version 18.00.00.00
> > Firmware Image compatible with Controller.
> >
> > Valid NVDATA Image found.
> > NVDATA Version 11.00.00.00
> > Checking for a compatible NVData image...
> >
> > NVDATA Device ID and Chip Revision match verified.
> > ERROR: Cannot downgrade NVDATA version 14.00.00.06
> >to 11.00.11.00.
> >
> > ERROR: Failed to get valid NVDATA image from File!
> >
> > Firmware Image Validation Failed!
> >
> > Tried downgrading bios:
> >
> > Attempting to flash Boot Service to LSI SAS SAS2308_2(D1) :
> >
> > Validating BIOS Image...
> >
> > BIOS Header Signature is Valid
> >
> > BIOS Image has a Valid Checksum.
> >
> > BIOS PCI Structure Signature Valid.
> >
> > BIOS Image Compatible with the SAS Controller.
> >
> > Attempting to Flash BIOS Image...
> >
> > BIOS Version in flash: 07.39.00.00
> > BIOS Version from File  : 07.35.00.00
> > Skipping flash since file version is not greater
> > than existing.
> >
> > Flash BIOS Image Failed!
> >
> > I've tried sas2flash from P20 and P18.
> >
> > Can someone fill me in on the trick to downgrade?  
> >
> > -Chip
> >
> > __ __
> >
> > __ __
> >
> > On Thu, Nov 27, 2014 at 9:03 AM, Filip Marvan  > > wrote:
> >
> > Thank you for your help Aaron! I downgraded firmware to P18 and
> > there are no more errors today.
> >
> > It seems, that there is something bad with P20 firmware!
> >
> >  
> >
> > You saved me a lot of time J
> >
> >  
> >
> > Filip
> >
> >  
> >
> >  
> >
> > *From:*Aaron Curry [mailto:asc1...@gmail.com
> > ]
> > *Sent:* Tuesday, November 25, 2014 5:46 PM
> > *To:* Filip Marvan
> > *Cc:* Dan McDonald; omnios-discuss@lists.omniti.com
> > 
> > *Subject:* Re: [OmniOS-discuss] Parity error on path mpt_sas2
> >
> >  
> >
> > I had this exact same problem recently when setting up a new home
> > server... same controller, same firm

Re: [OmniOS-discuss] kvm io 10 times slower after r151010 -> r151012 upgrade

[Tobias Oetiker]

Hi Michael,

Today Michael Mounteney wrote:

> On Wed, 10 Dec 2014 06:14:56 +0100 (CET)
> Tobias Oetiker  wrote:
>
> > This leads me to suspect, that either only very few people are
> > using omnios as a kvm server OR it is also a hardware dependent
> > problem.
>
> I think it must be.  I'm running KVM (Gentoo Linux guests) and have
> just gone from 151010 to 151012.  I haven't carried-out any
> quantitative assessment, but didn't notice any slowdown.  For the
> record, my KVM invocation is:
>
> /usr/bin/qemu-system-x86_64 \
> -name "Gentoo "$WHAT \
> -cpu host \
> -boot order=d \
> -enable-kvm \
> -vnc cortex:$VNC \
> -smp 1,maxcpus=1,cores=2 \
> -m 1024 \
> -no-hpet \
> -localtime \
> -kernel 
> /gentoo/kernel-source/linux-3.17.4-gentoo-vbox/arch/x86/boot/bzImage \
> -append "root=/dev/vda1 init=/usr/lib/systemd/systemd quiet" \
> -drive 
> file=/dev/zvol/dsk/rpool/vol/Gentoo-KVM-${WHAT},cache=none,if=virtio,index=0 \
> -drive 
> file=/dev/zvol/dsk/rpool/vol/Linuswap-${WHAT},cache=none,if=virtio,index=1 \
> -net nic,vlan=0,macaddr=$mac,model=virtio,name=ncard1 \
> -net vnic,vlan=0,name=net0,ifname=$VNIC,macaddr=$mac \
> -monitor telnet:127.0.0.1:${monitor},server,nowait \
> -vga std \
> -daemonize
>
> where ${WHAT} is either KDE or XFCE.  Machine is a Supermicro 5017C-LF with 1 
> x Intel Xeon E3-1240V2 3.40 GHz.4 Cores , 4 Threads,8Mb cache and 8 GiB RAM.
>
> If you are interested in any performance figures, let me know any tar or dd 
> etc. commands you'd like me to run.

yes, a very simple test:

guest$ dd if=/dev/zero bs=1M count=20 | ssh host dd of=/dev/null
guest$ ssh host dd if=/dev/zero bs=1M count=20 | dd of=/dev/null

and since I suspect that the disk io suffers too but due to
caching, maybe reading just a bit off the disk device might be an
interesting test:

  dd if=/dev/vda of=/dev/zero bs=1M count=1000

cheers
tobi


> Michael.
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] kvm io 10 times slower after r151010 -> r151012 upgrade

[Michael Mounteney]

On Wed, 10 Dec 2014 06:14:56 +0100 (CET)
Tobias Oetiker  wrote:

> This leads me to suspect, that either only very few people are
> using omnios as a kvm server OR it is also a hardware dependent
> problem.

I think it must be.  I'm running KVM (Gentoo Linux guests) and have
just gone from 151010 to 151012.  I haven't carried-out any
quantitative assessment, but didn't notice any slowdown.  For the
record, my KVM invocation is:

/usr/bin/qemu-system-x86_64 \
-name "Gentoo "$WHAT \
-cpu host \
-boot order=d \
-enable-kvm \
-vnc cortex:$VNC \
-smp 1,maxcpus=1,cores=2 \
-m 1024 \
-no-hpet \
-localtime \
-kernel 
/gentoo/kernel-source/linux-3.17.4-gentoo-vbox/arch/x86/boot/bzImage \
-append "root=/dev/vda1 init=/usr/lib/systemd/systemd quiet" \
-drive 
file=/dev/zvol/dsk/rpool/vol/Gentoo-KVM-${WHAT},cache=none,if=virtio,index=0 \
-drive 
file=/dev/zvol/dsk/rpool/vol/Linuswap-${WHAT},cache=none,if=virtio,index=1 \
-net nic,vlan=0,macaddr=$mac,model=virtio,name=ncard1 \
-net vnic,vlan=0,name=net0,ifname=$VNIC,macaddr=$mac \
-monitor telnet:127.0.0.1:${monitor},server,nowait \
-vga std \
-daemonize

where ${WHAT} is either KDE or XFCE.  Machine is a Supermicro 5017C-LF with 1 x 
Intel Xeon E3-1240V2 3.40 GHz.4 Cores , 4 Threads,8Mb cache and 8 GiB RAM.

If you are interested in any performance figures, let me know any tar or dd 
etc. commands you'd like me to run.

Michael.
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ipadm hangs on interface creation

[Stephan Budach]

Hi all,

I have run into a situation, where ipadm hangs upon trying to create a 
new interface on my ixgbe adaptors. ipadm create-if ixgbe[0|1|2] didn't 
return and either got killed eventually by the system or by kill -9, 
which I issued against that process. I just tried to create another if 
on the on-board NIC igb1, which still works without issues.


What could cause ipadm to hang this way and is there a way to get ipadm 
working again on the ixgbe adaptors, preferreably without having to boot 
the OmniOS server, since it is serving a NFS export from the remaining 
functioning ixgbe3 port to my Oracle VM servers.


Thanks,
budy

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss