From christian.meunier at magelo.com  Thu Jan  2 06:02:16 2014
From: christian.meunier at magelo.com (Christian Meunier)
Date: Thu, 02 Jan 2014 14:02:16 +0800
Subject: [OmniOS-discuss] How to update system to a specific release version
	?
Message-ID: <52C500E8.6090306@magelo.com>

Hi all and happy new year !

I currently have a server on r151004 and I would like to update it to 
the r151006 which is now one release behind the latest one (r151008).
The upgrade instructions ( 
http://omnios.omniti.com/wiki.php/Upgrade_r151004_r151006 ) does not 
specify a version and would currently try to update my system straight 
to r151008.

I searched the wiki and couldn't find a pointer on how to upgrade to a 
specific version which is pretty important given that you can upgrade to 
the r151008 only from the r151006 so you have to iteratively upgrade 
your system...

Thanks in advance for your help.

--
Chris



From richard.palo at free.fr  Thu Jan  2 22:38:52 2014
From: richard.palo at free.fr (Richard PALO)
Date: Thu, 02 Jan 2014 23:38:52 +0100
Subject: [OmniOS-discuss] #83 libgmp problems in 151008
Message-ID: <la4ppg$hr1$1@ger.gmane.org>

hi, is there any idea of when/if an update might land fixing
https://src.omniti.com/omnios-private/ticket.php/83

thanks in advance


From henson at acm.org  Sat Jan  4 00:59:04 2014
From: henson at acm.org (Paul B. Henson)
Date: Fri, 3 Jan 2014 16:59:04 -0800
Subject: [OmniOS-discuss] disable NetBIOS-Over-TCP for smb server
Message-ID: <20140104005904.GL7372@bender.unx.csupomona.edu>

Is there any way to disable netbios for the in-kernel smb server? Per
the man page:

     The smbd  daemon  is  automatically  invoked  by  using  the
     sharemgr  command over all available transports. By default,
     smbd starts over the NetBIOS-Over-TCP (NBT)  and  TCP  tran-
     sports.

     When smbd is started over NBT, the  following  services  are
     started:

         o    The NetBIOS name service is  started  on  UDP  port
              137.

         o    The NetBIOS datagram service is started on UDP port
              138.

         o    The NetBIOS session service is started on TCP  port
              139.

     When the smbd daemon is started over TCP, the  CIFS  service
     is started on TCP port 445.

If this is the "default", it kinda implies you could change it, but I
haven't been able to figure out how. I don't really want to run NetBIOS,
I just want to listen on port 445.

Thanks...


From matthias-omn-discuss at mteege.de  Sun Jan  5 13:17:55 2014
From: matthias-omn-discuss at mteege.de (Matthias Teege)
Date: Sun, 5 Jan 2014 14:17:55 +0100
Subject: [OmniOS-discuss] r151008 ipkg zone attach problems
In-Reply-To: <20131207165258.GA7252@gutsman.lotheac.fi>
References: <20131207165258.GA7252@gutsman.lotheac.fi>
Message-ID: <90524a43-e12c-4e09-97dd-5cb957c48a17@mteege.de>

On Sat, Dec 07, 2013 at 06:52:59PM +0200, Lauri Tirkkonen wrote:

Hi,

> 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

I run in the same issue.  Can I attach the r151006 zones without "-u"
and update later?

Many Thanks
Matthias

From gordon.w.ross at gmail.com  Sat Jan  4 05:30:51 2014
From: gordon.w.ross at gmail.com (Gordon Ross)
Date: Sat, 4 Jan 2014 00:30:51 -0500
Subject: [OmniOS-discuss] [discuss] disable NetBIOS-Over-TCP for smb
	server
In-Reply-To: <20140104005904.GL7372@bender.unx.csupomona.edu>
References: <20140104005904.GL7372@bender.unx.csupomona.edu>
Message-ID: <CAD0Ztp0Nd7E1hdM42gEi9SLpk2H0s7RNnBi8-hLNpEynkDWG2Q@mail.gmail.com>

At the moment, no, there's no way to disable the NetBIOS listener.  We
have a "knob" for that in updated SMB server code we're developing for
NexentaStor, so once that makes its way to illumos you'll have it.


On Fri, Jan 3, 2014 at 7:59 PM, Paul B. Henson <henson at acm.org> wrote:
> Is there any way to disable netbios for the in-kernel smb server? Per
> the man page:
>
>      The smbd  daemon  is  automatically  invoked  by  using  the
>      sharemgr  command over all available transports. By default,
>      smbd starts over the NetBIOS-Over-TCP (NBT)  and  TCP  tran-
>      sports.
>
>      When smbd is started over NBT, the  following  services  are
>      started:
>
>          o    The NetBIOS name service is  started  on  UDP  port
>               137.
>
>          o    The NetBIOS datagram service is started on UDP port
>               138.
>
>          o    The NetBIOS session service is started on TCP  port
>               139.
>
>      When the smbd daemon is started over TCP, the  CIFS  service
>      is started on TCP port 445.
>
> If this is the "default", it kinda implies you could change it, but I
> haven't been able to figure out how. I don't really want to run NetBIOS,
> I just want to listen on port 445.
>
> Thanks...
>
>
>
> -------------------------------------------
> illumos-discuss
> Archives: https://www.listbox.com/member/archive/182180/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175550-721fcbaf
> Modify Your Subscription: https://www.listbox.com/member/?member_id=21175550&id_secret=21175550-eae52450
> Powered by Listbox: http://www.listbox.com



-- 
Gordon Ross <gwr at nexenta.com>
Nexenta Systems, Inc.  www.nexenta.com
Enterprise class storage for everyone

From daleg at omniti.com  Mon Jan  6 15:49:56 2014
From: daleg at omniti.com (Dale Ghent)
Date: Mon, 6 Jan 2014 10:49:56 -0500
Subject: [OmniOS-discuss] r151008 ipkg zone attach problems
In-Reply-To: <90524a43-e12c-4e09-97dd-5cb957c48a17@mteege.de>
References: <20131207165258.GA7252@gutsman.lotheac.fi>
	<90524a43-e12c-4e09-97dd-5cb957c48a17@mteege.de>
Message-ID: <4A790812-F8A0-4FA9-991E-355FC4C8F160@omniti.com>


There's a fix out now for this, released on friday. New packages for:

package/pkg
system/zones/brand/ipkg

Update these before you do your zone-related work and it should work as expected.

/dale

On Jan 5, 2014, at 8:17 AM, Matthias Teege <matthias-omn-discuss at mteege.de> wrote:

> On Sat, Dec 07, 2013 at 06:52:59PM +0200, Lauri Tirkkonen wrote:
> 
> Hi,
> 
>> 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
> 
> I run in the same issue.  Can I attach the r151006 zones without "-u"
> and update later?
> 
> Many Thanks
> Matthias
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From ngoossens at gmail.com  Mon Jan  6 22:50:18 2014
From: ngoossens at gmail.com (Niels Goossens)
Date: Mon, 6 Jan 2014 23:50:18 +0100
Subject: [OmniOS-discuss] OmniOS random freezes
Message-ID: <CAGHroZBLN66oXhKA+PVNz_7XwUsN=dVFzpUAwOs98VNDLrbvsQ@mail.gmail.com>

All,

Short introduction: I'm a non-professional user running a home lab
(actually in a Sun 900 rack, but that's a different story). One of my
machines is a Supermicro X9SCL-F motherboard with a Xeon 1230v2 running the
latest OmniOS release, r151008 - 6de5e81.

The reason I chose OmniOS is because it allows me to have one machine act
as FC target and KVM host simultaneously. In my home lab, where the
electricity bill is always an issue, this is a good thing.

I'm running Cloudstack in my home lab divided over three machines: two
Supermicro X9SCL-F boards with Xeon 1230v2 act as compute hosts (running a
basic Ubuntu 13.10 with KVM because Cloudstack needs libvirt for
controlling the hosts), and one machine acts as Cloudstack controller. This
is the OmniOS machine and it runs a few VMs (mysql, bind,
Cloudstack-management, alfresco, plex).

The machine itself has 32gb ram, 5x1tb drives on the motherboard sata
controller (in raidz1). Boot drive is a dedicated 320gb sata drive on the
same onboard sata controller. Two PCIe cards are connected: one QLogic 2460
FC card, and one IBM branded Intel PRO/1000 PT dual port.

My OmniOS host experiences random freezes. These appear out of nowhere. I
will list the steps I've taken to isolate the issue so far.

1. Is the system under load when the freeze occurs?
A. No. I've let the machine run idle the past few days, and it will freeze
anyway.

2. Is there anything in /var/adm/messages?
A. Not anymore. There used to be though: I've seen the following:

Jan  4 20:40:16 controller mac: [ID 469746 kern.info] NOTICE: e1000g2
registered
Jan  4 20:40:19 controller mac: [ID 435574 kern.info] NOTICE: e1000g2 link
up, 1000 Mbps, full duplex
Jan  4 20:49:30 controller mac: [ID 486395 kern.info] NOTICE: e1000g2 link
down
Jan  4 20:49:30 controller in.routed[1382]: [ID 238047 daemon.warning]
interface e1000g2 to 10.10.3.8 turned off

I've disabled e1000g2 (simply ifconfig e1000g2 down and the warnings have
disappeared - this leads me to suspect the Intel NIC though)

I've also seen lots of these entries in /var/adm/messages:

Jan  5 11:08:21 controller ahci: [ID 117845 kern.warning] WARNING: satapkt
0xffffff0935ec3900: cmd_reg = 0xb0 features_reg = 0x0 sec_count_msb = 0x0
lba_low_msb = 0x4f lba_mid_msb = 0x4f lba_high_msb = 0x0 sec_count_lsb =
0x0 lba_low_lsb = 0x0 lba_mid_lsb = 0x4f lba_high_lsb = 0xc2 device_reg =
0x0 addr_type = 0x4 cmd_flags = 0x12

There was an additional PCIe sata card in this machine, which I have
removed. The warnings went away.

3. Is the pool healthy?
A. The drives are consumer grade sata drives and about 3 years old. They
are not really used that much - they used to be in my Opensolaris based NAS
before I upgraded that to something bigger. Smartctl tells me SMART status
of all drives is OK. There are no other log entries that lead me to believe
a drive is bad. Zpool status is OK.

4. Is there anything in Supermicro IPMI?
A. The following, which has occurred only twice now:

2013/11/23 19:53:28 Correctable Memory ECC @ DIMM2A(CPU1) - Asserted
2013/11/23 19:53:29 Uncorrectable Memory ECC @ DIMM2A(CPU1) - Asserted
2013/11/23 22:28:56 Correctable Memory ECC @ DIMM2A(CPU1) - Asserted
2013/11/23 22:28:57 Uncorrectable Memory ECC @ DIMM2A(CPU1) - Asserted

Even though I'd rather not see this error, I'm not alarmed considering it
has not occurred since.
5. Are core dump or crash files available?
A. I've setup dumpadm and coreadm only today. There are no core files in /,
or crash files in /var/crash. There are no log entries in /var/log. There
is nothing in /var/adm/messages, the last entry there is hours before the
machine freezes.

Now I am not a full blown sysadmin but I do have some experience with
Solaris, so I know my way around a little bit. I start to feel stuck
however, I need help in further isolating this issue. Therefore any help is
seriously appreciated!

Thanks for any advice and kind regards,

Niels Goossens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140106/c8880295/attachment.html>

From skiselkov.ml at gmail.com  Mon Jan  6 23:32:54 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Mon, 06 Jan 2014 23:32:54 +0000
Subject: [OmniOS-discuss] OmniOS random freezes
In-Reply-To: <CAGHroZBLN66oXhKA+PVNz_7XwUsN=dVFzpUAwOs98VNDLrbvsQ@mail.gmail.com>
References: <CAGHroZBLN66oXhKA+PVNz_7XwUsN=dVFzpUAwOs98VNDLrbvsQ@mail.gmail.com>
Message-ID: <52CB3D26.8090407@gmail.com>

On 1/6/14, 10:50 PM, Niels Goossens wrote:
> 3. Is the pool healthy?
> A. The drives are consumer grade sata drives and about 3 years old. They
> are not really used that much - they used to be in my Opensolaris based
> NAS before I upgraded that to something bigger. Smartctl tells me SMART
> status of all drives is OK. There are no other log entries that lead me
> to believe a drive is bad. Zpool status is OK.

Just to perform a test, you could try loading up the pool with as much
test data as you can (some repetitive incompressible test pattern would
be best, e.g. a movie file) and then run "zpool scrub" to verify all the
checksums.

> 4. Is there anything in Supermicro IPMI?
> A. The following, which has occurred only twice now:
> 
> 2013/11/23 19:53:28Correctable Memory ECC @ DIMM2A(CPU1) - Asserted
> 2013/11/23 19:53:29Uncorrectable Memory ECC @ DIMM2A(CPU1) - Asserted
> 2013/11/23 22:28:56Correctable Memory ECC @ DIMM2A(CPU1) - Asserted
> 2013/11/23 22:28:57Uncorrectable Memory ECC @ DIMM2A(CPU1) - Asserted
> 
> Even though I'd rather not see this error, I'm not alarmed considering
> it has not occurred since.

This could indicate degrading or failing ECC memory. Try running
memtest86+ on the machine for a while to see if it reports anything
useful. You can grab a pre-built ISO at http://www.memtest.org/#downiso
Alternatively, grab a bootable file from that site. Then, just put it
somewhere on your root filesystem, e.g.
/platform/i86pc/memtest86+-4.20.bin, gunzip and boot to it from GRUB by
entering the following GRUB commands:

findroot (pool_rpool,0,a)	<- partition number + slice
bootfs rpool/ROOT/omnios	<- see "beadm list" for the exact name
kernel /platform/i86pc/memtest86+-4.20.bin
boot

> 5. Are core dump or crash files available?
> A. I've setup dumpadm and coreadm only today. There are no core files in
> /, or crash files in /var/crash. There are no log entries in /var/log.
> There is nothing in /var/adm/messages, the last entry there is hours
> before the machine freezes.

System crash dumps are usually saved on the dump device (rpool/dump)
until you manually retrieve them. If you run "savecore" without any
arguments it will try to extract the crash dump from the dump device and
save it to /var/crash/<hostname>.

Cheers,
-- 
Saso

From Rob at Logan.com  Tue Jan  7 00:53:07 2014
From: Rob at Logan.com (Rob Logan)
Date: Mon, 6 Jan 2014 19:53:07 -0500
Subject: [OmniOS-discuss] [SPAM]  OmniOS random freezes
In-Reply-To: <CAGHroZBLN66oXhKA+PVNz_7XwUsN=dVFzpUAwOs98VNDLrbvsQ@mail.gmail.com>
References: <CAGHroZBLN66oXhKA+PVNz_7XwUsN=dVFzpUAwOs98VNDLrbvsQ@mail.gmail.com>
Message-ID: <F39E6414-F370-488C-A37E-7ED0F041B566@Logan.com>


> My OmniOS host experiences random freezes. 

what is a ?freeze?? while its frozen:

can you ping it (getty or other console related issue)

does the shell on the console respond? (network stack issue)

tapping the num lock key on a PS2 console keyboard light the num lock light? (hardware issue)

forcing a dump will let us search the running stacks:
http://docs.oracle.com/cd/E19082-01/819-2379/fvzpl/index.html

				Rob

From henson at acm.org  Tue Jan  7 03:37:16 2014
From: henson at acm.org (Paul B. Henson)
Date: Mon, 6 Jan 2014 19:37:16 -0800
Subject: [OmniOS-discuss] [discuss] disable NetBIOS-Over-TCP for smb
	server
In-Reply-To: <CAD0Ztp0Nd7E1hdM42gEi9SLpk2H0s7RNnBi8-hLNpEynkDWG2Q@mail.gmail.com>
References: <20140104005904.GL7372@bender.unx.csupomona.edu>
	<CAD0Ztp0Nd7E1hdM42gEi9SLpk2H0s7RNnBi8-hLNpEynkDWG2Q@mail.gmail.com>
Message-ID: <006a01cf0b59$c4da9d10$4e8fd730$@acm.org>

> From: Gordon Ross [mailto:gordon.w.ross at gmail.com]
> Sent: Friday, January 03, 2014 9:31 PM
>
> At the moment, no, there's no way to disable the NetBIOS listener.  We
> have a "knob" for that in updated SMB server code we're developing for
> NexentaStor, so once that makes its way to illumos you'll have it.

Cool, is that going to be in the same drop with SMB2 protocol support ;)?

Any idea as to when that might get integrated? Thanks much.


From sk at kram.io  Tue Jan  7 12:51:39 2014
From: sk at kram.io (Steffen Kram)
Date: Tue, 7 Jan 2014 13:51:39 +0100
Subject: [OmniOS-discuss] r151008 ipkg zone attach problems
In-Reply-To: <4A790812-F8A0-4FA9-991E-355FC4C8F160@omniti.com>
References: <20131207165258.GA7252@gutsman.lotheac.fi>
	<90524a43-e12c-4e09-97dd-5cb957c48a17@mteege.de>
	<4A790812-F8A0-4FA9-991E-355FC4C8F160@omniti.com>
Message-ID: <6E4B61D3-76F9-4F65-B860-682FE9C2BAF1@kram.io>

Hi,

beside this fix I?m still having problems re-attaching my zone. I just upgraded the global zone to r151008f. So I already got the fixed versions:

root at hume:~# pkg info package/pkg
...       FMRI: pkg://omnios/package/pkg at 0.5.11,5.11-0.151008:20131230T201906Z
root at hume:~# pkg info system/zones/brand/ipkg
...       FMRI: pkg://omnios/system/zones/brand/ipkg at 0.5.11,5.11-0.151008:20131230T201908Z

Next I tried to update one of my non-global zones using the zoneadm attach -u command:

root at hume:~# zoneadm -z telford attach -u
Log File: /var/tmp/telford.attach_log.hmaqMh
               Attach Path: /zones/telford/root
        Attach ZFS Dataset: cairngorm/zones/telford/ROOT/zbe-2

                Installing: Using pre-existing data in zonepath
       Global zone version: entire at 11,5.11-0.151008:20131205T195242Z
   Non-Global zone version: entire at 11,5.11-0.151006:20130507T204959Z
                     Cache: Using /var/pkg/publisher.
  Updating non-global zone: Output follows
Creating Plan
ERROR: Could not update attaching zone
                    Result: Attach Failed.

It did fail because of

[ 7. Januar 2014 13:42:55 CET]   Updating non-global zone: Output follows
pkg set-publisher: The origin URIs for 'omnios' do not appear to point to a valid pkg repository.
Please verify the repository's location and the client's network configuration.
Additional details:

Unable to contact valid package repository
Encountered the following error(s):
Unable to contact any configured publishers.
This is likely a network configuration problem.
Framework error: code: 7 reason: Failed connect to localhost:10000; Connection refused
URL: 'http://localhost:10000'. (happened 4 times)

pkg set-publisher: The origin URIs for 'uulm.mawi' do not appear to point to a valid pkg repository.
Please verify the repository's location and the client's network configuration.
Additional details:

Unable to contact valid package repository
Encountered the following error(s):
Unable to contact any configured publishers.
This is likely a network configuration problem.
Framework error: code: 7 reason: Failed connect to localhost:10000; Connection refused
URL: 'http://localhost:10000'. (happened 4 times)


pkg install: The following pattern(s) did not match any allowable packages.  Try
using a different matching pattern, or refreshing publisher information:

        entire at 11,5.11-0.151008:20131205T195242Z
[ 7. Januar 2014 13:43:05 CET] ERROR: Could not update attaching zone
[ 7. Januar 2014 13:43:08 CET]                     Result: Attach Failed.

However, there was never a pkg publisher configured on localhost:10000 for this zone.

I am able to upgrade and boot the zone when preforming the update from the global zone using

zoneadm -R /zones/telford/root update

and attaching the zone afterwards. In this case the publisher information in the non-global zone is empty and I have to re-add the omnios default publisher manually.

Cheers,
Steffen


Am 06.01.2014 um 16:49 schrieb Dale Ghent <daleg at omniti.com>:

> 
> There's a fix out now for this, released on friday. New packages for:
> 
> package/pkg
> system/zones/brand/ipkg
> 
> Update these before you do your zone-related work and it should work as expected.
> 
> /dale
> 
> On Jan 5, 2014, at 8:17 AM, Matthias Teege <matthias-omn-discuss at mteege.de> wrote:
> 
>> On Sat, Dec 07, 2013 at 06:52:59PM +0200, Lauri Tirkkonen wrote:
>> 
>> Hi,
>> 
>>> 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
>> 
>> I run in the same issue.  Can I attach the r151006 zones without "-u"
>> and update later?
>> 
>> Many Thanks
>> Matthias
>> _______________________________________________
>> 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: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://omniosce.org/ml-archive/attachments/20140107/4179b766/attachment-0001.bin>

From lotheac at iki.fi  Tue Jan  7 13:57:21 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Tue, 7 Jan 2014 15:57:21 +0200
Subject: [OmniOS-discuss] r151008 ipkg zone attach problems
In-Reply-To: <4A790812-F8A0-4FA9-991E-355FC4C8F160@omniti.com>
References: <20131207165258.GA7252@gutsman.lotheac.fi>
	<90524a43-e12c-4e09-97dd-5cb957c48a17@mteege.de>
	<4A790812-F8A0-4FA9-991E-355FC4C8F160@omniti.com>
Message-ID: <20140107135721.GA21845@gutsman.lotheac.fi>

On Mon, Jan 06 2014 10:49:56 -0500, Dale Ghent wrote:
> 
> There's a fix out now for this, released on friday. New packages for:
> 
> package/pkg
> system/zones/brand/ipkg

What repo are these built from? I'm curious as to the fix and am not
seeing any new commits in omniti-labs/omnios-build, postwait/pkg5 or
omniti-labs/illumos-omnios on github.

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

From ngoossens at gmail.com  Tue Jan  7 20:13:03 2014
From: ngoossens at gmail.com (Niels Goossens)
Date: Tue, 7 Jan 2014 21:13:03 +0100
Subject: [OmniOS-discuss] OmniOS random freezes
Message-ID: <CAGHroZC5cGwnK7DBNOr_gghT6Gv+9bNwDcb6QWrki_jir+7dcA@mail.gmail.com>

Thank you Saso and Rob for your replies. I will answer what I can and
provide an update as well.

@Rob, With "freeze" I mean "hang". The system does not respond anymore. SSH
sessions are disconnected ("broken pipe"), pings show "destination host
unreachable". (IPMI) Console does not respond to key strokes. No freeze has
occurred after my previous post, so I do not know if numlock lights up - I
will make sure to test that.

Last night something happened - I noticed today that even though the system
is up, network connectivity is gone. More specifically, the only devices I
can ping are my Macbook (which has an ssh session open to the OmniOS
machine), the Netgear switch the Macbook is connected to, and the Netgear
switch that the OmniOs machine is connected to. In /var/adm/messages, I can
only find:

Jan  7 03:10:00 controller cron[8392]: [ID 574227 user.alert] Solaris_audit
getaddrinfo(controller) failed[node name or service name not known]: Error 0
Jan  7 03:30:00 controller cron[8393]: [ID 574227 user.alert] Solaris_audit
getaddrinfo(controller) failed[node name or service name not known]: Error 0
So that's a cron job gone wrong because it cannot reach the network I
guess. My next action will be to first yank the Intel PCIe NIC.

@Saso, thanks for the great advice on how to test memory and the zfs pool!
I will look into those next.

Kind regards,

Niels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140107/196f130d/attachment.html>

From martin at dojcak.sk  Wed Jan  8 12:45:04 2014
From: martin at dojcak.sk (Martin Dojcak)
Date: Wed, 08 Jan 2014 13:45:04 +0100
Subject: [OmniOS-discuss] Problem installing new zone (version problem)
Message-ID: <52CD4850.60009@dojcak.sk>

Hi everyone,

i have production instalation of omnios with global zone of version r151006.
Installation of non-global zones in the past has been successful, but
now when i try to install new zone i have a problem with libc. For
example in new installed zone:

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

pkg --version
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

ldd /usr/lib/amd64/libpython2.6.so.1.0
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libm.so.2 => /lib/64/libm.so.2
libgcc_s.so.1 => /usr/lib/64/libgcc_s.so.1
libc.so.1 => /lib/64/libc.so.1
libc.so.1 (ILLUMOS_0.6) => (version not found)
libmp.so.2 => /lib/64/libmp.so.2
libmd.so.1 => /lib/64/libmd.so.1

or

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
Killed

I think there is problem with version because global zone is r151006 but
"zoneadm -z test install" install r151008 version with r151006 packages.
On global zone I install omnios-userland package and freeze packages:
pkg freeze
NAME VERSION DATE COMMENT
entire 11-0.151006 08 Jan 2014 12:36:35 CET Stay on r151006
incorporation/jeos/illumos-gate 11-0.151006 08 Jan 2014 11:27:27 CET
Stay on r151006
incorporation/jeos/omnios-userland 11-0.151006 08 Jan 2014 11:27:36 CET
Stay on r151006

then I tried to install new zone, but it brought an unsuccessful result.
Im unable to upgrade entire system to new version r151008.

zoneadm -z test attach -u
Log File: /var/tmp/db-mini-1.attach_log.Lbay3e
Attach Path: /zones/db-mini-1/root
Attach ZFS Dataset: rpool/zones/db-mini-1/ROOT/zbe

Installing: Using pre-existing data in zonepath
Global zone version: entire at 11,5.11-0.151006:20130507T204959Z
Non-Global zone version: entire at 11,5.11-0.151006:20130507T204959Z

in non-global zone:
cat /etc/release
OmniOS v11 r151008
Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
Use is subject to license terms.

cat /etc/release
OmniOS v11 r151008
Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
Use is subject to license terms.

Can anyone help pls ?

-- 
Martin Doj??k

mail: martin at dojcak.sk
jabber: martindojcak at jabbim.sk

pgp: http://pgp.dojcak.sk/

From martin at dojcak.sk  Wed Jan  8 18:30:15 2014
From: martin at dojcak.sk (Martin Dojcak)
Date: Wed, 08 Jan 2014 19:30:15 +0100
Subject: [OmniOS-discuss] Problem installing new zone (version problem)
In-Reply-To: <52CD4850.60009@dojcak.sk>
References: <52CD4850.60009@dojcak.sk>
Message-ID: <52CD9937.8040800@dojcak.sk>

It probably has nothing to do of the global zone.

New hint:

entire package in non-global zone (test) is
entire at 11,5.11-0.151006:20130507T204959Z. Here is manifest of package
http://pastebin.com/NJv5cRJC. But i really do not understand why
"entire" pakcage for installing new zone is 151006 version and
/etc/release is  OmniOS v11 r151008. From manifest depend
fmri=release/name at 0.5.11,5.11-0.151006: but on system is installed
release/name at 0.5.11,5.11-0.151008:3A20131204T024419Z. There are more
packages r151008. Here is the log from /var/pkg/history
http://pastebin.com/PACcXPFf.


On 01/08/2014 01:45 PM, Martin Dojcak wrote:
> Hi everyone,
> 
> i have production instalation of omnios with global zone of version r151006.
> Installation of non-global zones in the past has been successful, but
> now when i try to install new zone i have a problem with libc. For
> example in new installed zone:
> 
> root at test:~# cat /etc/release
> OmniOS v11 r151008
> Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
> Use is subject to license terms.
> 
> pkg --version
> 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
> 
> ldd /usr/lib/amd64/libpython2.6.so.1.0
> libsocket.so.1 => /lib/64/libsocket.so.1
> libnsl.so.1 => /lib/64/libnsl.so.1
> libm.so.2 => /lib/64/libm.so.2
> libgcc_s.so.1 => /usr/lib/64/libgcc_s.so.1
> libc.so.1 => /lib/64/libc.so.1
> libc.so.1 (ILLUMOS_0.6) => (version not found)
> libmp.so.2 => /lib/64/libmp.so.2
> libmd.so.1 => /lib/64/libmd.so.1
> 
> or
> 
> 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
> Killed
> 
> I think there is problem with version because global zone is r151006 but
> "zoneadm -z test install" install r151008 version with r151006 packages.
> On global zone I install omnios-userland package and freeze packages:
> pkg freeze
> NAME VERSION DATE COMMENT
> entire 11-0.151006 08 Jan 2014 12:36:35 CET Stay on r151006
> incorporation/jeos/illumos-gate 11-0.151006 08 Jan 2014 11:27:27 CET
> Stay on r151006
> incorporation/jeos/omnios-userland 11-0.151006 08 Jan 2014 11:27:36 CET
> Stay on r151006
> 
> then I tried to install new zone, but it brought an unsuccessful result.
> Im unable to upgrade entire system to new version r151008.
> 
> zoneadm -z test attach -u
> Log File: /var/tmp/db-mini-1.attach_log.Lbay3e
> Attach Path: /zones/db-mini-1/root
> Attach ZFS Dataset: rpool/zones/db-mini-1/ROOT/zbe
> 
> Installing: Using pre-existing data in zonepath
> Global zone version: entire at 11,5.11-0.151006:20130507T204959Z
> Non-Global zone version: entire at 11,5.11-0.151006:20130507T204959Z
> 
> in non-global zone:
> cat /etc/release
> OmniOS v11 r151008
> Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
> Use is subject to license terms.
> 
> cat /etc/release
> OmniOS v11 r151008
> Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
> Use is subject to license terms.
> 
> Can anyone help pls ?
> 

-- 
Martin Doj??k

mail: martin at dojcak.sk
jabber: martindojcak at jabbim.sk

pgp: http://pgp.dojcak.sk/

From lotheac at iki.fi  Wed Jan  8 19:04:41 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 8 Jan 2014 21:04:41 +0200
Subject: [OmniOS-discuss] Problem installing new zone (version problem)
In-Reply-To: <52CD4850.60009@dojcak.sk>
References: <52CD4850.60009@dojcak.sk>
Message-ID: <20140108190441.GC15765@gutsman.lotheac.fi>

On Wed, Jan 08 2014 13:45:04 +0100, Martin Dojcak wrote:
> in non-global zone:
> cat /etc/release
> OmniOS v11 r151008
> Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
> Use is subject to license terms.

This is probably due to omnios-userland not getting installed in the
non-global zone. I think that was fixed with a new r151006 'entire'
(which has a depend type=require on omnios-userland; earlier version did
not actually make sure omnios-userland is installed) sometime in
December, but you need to have that fix in your GZ because non-global
zones are always installed with the same exact version of entire as the
GZ. Or as a workaround, you can tell zoneadm to install the correct
version of omnios-userland as an extra package (-e was the command line
flag I think).

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

From martin at dojcak.sk  Wed Jan  8 19:57:42 2014
From: martin at dojcak.sk (Martin Dojcak)
Date: Wed, 08 Jan 2014 20:57:42 +0100
Subject: [OmniOS-discuss] Problem installing new zone (version problem)
In-Reply-To: <20140108190441.GC15765@gutsman.lotheac.fi>
References: <52CD4850.60009@dojcak.sk>
	<20140108190441.GC15765@gutsman.lotheac.fi>
Message-ID: <52CDADB6.80302@dojcak.sk>

Solved!
Workaround perform successful instalation of zone. I run zoneadm -z test
install -e incorporation/jeos/omnios-userland at 11,5.11-0.151006.In the
non-global zone are no longer any pakcages with r151008.
I thnik omnios guys should fix
pkg://omnios/entire at 11,5.11-0.151006:20131210T224515Z and later versions
with omnios-userland type=require. I will upgrade GZ to r151008 as soon
as I can.

Thank you very much Lauri.


On 01/08/2014 08:04 PM, Lauri Tirkkonen wrote:
> On Wed, Jan 08 2014 13:45:04 +0100, Martin Dojcak wrote:
>> in non-global zone:
>> cat /etc/release
>> OmniOS v11 r151008
>> Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
>> Use is subject to license terms.
> 
> This is probably due to omnios-userland not getting installed in the
> non-global zone. I think that was fixed with a new r151006 'entire'
> (which has a depend type=require on omnios-userland; earlier version did
> not actually make sure omnios-userland is installed) sometime in
> December, but you need to have that fix in your GZ because non-global
> zones are always installed with the same exact version of entire as the
> GZ. Or as a workaround, you can tell zoneadm to install the correct
> version of omnios-userland as an extra package (-e was the command line
> flag I think).
> 

-- 
Martin Doj??k

mail: martin at dojcak.sk
jabber: martindojcak at jabbim.sk

pgp: http://pgp.dojcak.sk/

From lotheac at iki.fi  Wed Jan  8 20:09:08 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 8 Jan 2014 22:09:08 +0200
Subject: [OmniOS-discuss] Problem installing new zone (version problem)
In-Reply-To: <52CDADB6.80302@dojcak.sk>
References: <52CD4850.60009@dojcak.sk>
	<20140108190441.GC15765@gutsman.lotheac.fi>
	<52CDADB6.80302@dojcak.sk>
Message-ID: <20140108200908.GD15765@gutsman.lotheac.fi>

On Wed, Jan 08 2014 20:57:42 +0100, Martin Dojcak wrote:
> I thnik omnios guys should fix
> pkg://omnios/entire at 11,5.11-0.151006:20131210T224515Z and later versions
> with omnios-userland type=require.

They already have:

    % pkg contents -rm pkg://omnios/entire at 11,5.11-0.151006:20131210T224515Z|grep userland
    depend fmri=incorporation/jeos/omnios-userland at 11,5.11-0.151006 type=incorporate
    depend fmri=incorporation/jeos/omnios-userland type=require

Your issue was that your entire was older (and did not include this
fix).

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

From alka at hfg-gmuend.de  Thu Jan  9 09:51:37 2014
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Thu, 09 Jan 2014 10:51:37 +0100
Subject: [OmniOS-discuss] netatalk setup (via uulm.mawi repo) failed with
 ld.so.1: afpd: fatal: libsasl2.so.2: open failed
In-Reply-To: <CAHfYOdW9r4Nng=jDhJeh7JVNxz08Vd40Sc885Xv6acpMM6SoSQ@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>
	<CAHfYOdW9r4Nng=jDhJeh7JVNxz08Vd40Sc885Xv6acpMM6SoSQ@mail.gmail.com>
Message-ID: <52CE7129.6030508@hfg-gmuend.de>

When installing netatalk (3.05)  and OmniOS 1006 and 1006 in napp-it the 
installer runs fine after a:

pkg set-publisher -g http://scott.mathematik.uni-ulm.de/release uulm.mawi
pkg install netatalk
pkg unset-publisher uulm.mawi

but when I try to enable the netatalk service it ended with a:
ld.so.1: afpd: fatal: libsasl2.so.2: open failed: No such file or directory

It seems the problem are newer sas library files, that you now have in
/usr/local/lib/libsasl2.so.3
/usr/local/lib/amd64/libsasl2.so.3

instead the searched libsasl2.so.2

I solved the problem with:
  ln -s /usr/local/lib/libsasl2.so.3 /usr/local/lib/libsasl2.so.2
  ln -s /usr/local/lib/amd64/libsasl2.so.3 
/usr/local/lib/amd64/libsasl2.so.2


Gea
napp-it.org



From sk at kram.io  Thu Jan  9 11:27:39 2014
From: sk at kram.io (Steffen Kram)
Date: Thu, 9 Jan 2014 12:27:39 +0100
Subject: [OmniOS-discuss] netatalk setup (via uulm.mawi repo) failed
	with ld.so.1: afpd: fatal: libsasl2.so.2: open failed
In-Reply-To: <52CE7129.6030508@hfg-gmuend.de>
References: <52bf406a.09d10e0a.026b.fffff6d6SMTPIN_ADDED_MISSING@mx.google.com>	<CAHfYOdWWy+Au1Zsf_g+zSS1nrN5nMnx59iYzrEHZxjq7F_h+FA@mail.gmail.com>	<CAHfYOdXTjBQHB0ZBap5kT0qhBDQ5QeiBOzKjAUKg6nWOMqrO6Q@mail.gmail.com>
	<CAHfYOdW9r4Nng=jDhJeh7JVNxz08Vd40Sc885Xv6acpMM6SoSQ@mail.gmail.com>
	<52CE7129.6030508@hfg-gmuend.de>
Message-ID: <0A328C77-BBCC-4DD4-8722-7A5021F9196A@kram.io>

Hi Guenther,

currently I?m in the middle updating my repository to 151008. I might have accidentally published a newer version of the sasl-package with 151006 version string. I?ll check this.

The problem I?m facing right now, is that my sasl libs depend on libpq5 which I cannot build right now. See my comment on ticket http://omnios.omniti.com/ticket.php/83 for details. Meanwhile you should be able to use the old libsasl2. The old packages are still lying around. I?ll drop you a note as soon as I?ve updated all packages.

Cheers,
Steffen


Am 09.01.2014 um 10:51 schrieb Guenther Alka <alka at hfg-gmuend.de>:

> When installing netatalk (3.05)  and OmniOS 1006 and 1006 in napp-it the installer runs fine after a:
> 
> pkg set-publisher -g http://scott.mathematik.uni-ulm.de/release uulm.mawi
> pkg install netatalk
> pkg unset-publisher uulm.mawi
> 
> but when I try to enable the netatalk service it ended with a:
> ld.so.1: afpd: fatal: libsasl2.so.2: open failed: No such file or directory
> 
> It seems the problem are newer sas library files, that you now have in
> /usr/local/lib/libsasl2.so.3
> /usr/local/lib/amd64/libsasl2.so.3
> 
> instead the searched libsasl2.so.2
> 
> I solved the problem with:
> ln -s /usr/local/lib/libsasl2.so.3 /usr/local/lib/libsasl2.so.2
> ln -s /usr/local/lib/amd64/libsasl2.so.3 /usr/local/lib/amd64/libsasl2.so.2
> 
> 
> Gea
> napp-it.org
> 
> 
> _______________________________________________
> 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: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://omniosce.org/ml-archive/attachments/20140109/f7790567/attachment-0001.bin>

From damian at virtualunix.eu  Thu Jan  9 15:04:45 2014
From: damian at virtualunix.eu (Damian McD)
Date: Thu, 09 Jan 2014 15:04:45 +0000
Subject: [OmniOS-discuss] libc.so.1 checksum
Message-ID: <157d329641c729037b21a6d1f2d55724@virtualunix.eu>

I was following some security guidelines in Oracle's docs and get an 
error regarding libc.so.1 via pkg verify


pkg://omnios/system/library
         file: lib/libc.so.1
                 Elfhash: 21008faaa95e095cdd5a6200dee4659db922fb66 should 
be 560f24729aedd180595ce78e58e95432ea93f5ad

ls -l /lib/libc.so.1
-rwxr-xr-x 1 root bin 1575684 Dec 10 21:39 /lib/libc.so.1

As a workaround could I download and install the library.p5i?

From cnehren+omnios-discuss at omniti.com  Thu Jan  9 16:06:52 2014
From: cnehren+omnios-discuss at omniti.com (Chris Nehren)
Date: Thu, 9 Jan 2014 11:06:52 -0500
Subject: [OmniOS-discuss] libc.so.1 checksum
In-Reply-To: <157d329641c729037b21a6d1f2d55724@virtualunix.eu>
References: <157d329641c729037b21a6d1f2d55724@virtualunix.eu>
Message-ID: <20140109160652.GA47654@eschaton.local>

On Thu, Jan 09, 2014 at 15:04:45 +0000, Damian McD wrote:
> I was following some security guidelines in Oracle's docs and get an 
> error regarding libc.so.1 via pkg verify
> 
> 
> pkg://omnios/system/library
>          file: lib/libc.so.1
>                  Elfhash: 21008faaa95e095cdd5a6200dee4659db922fb66 should 
> be 560f24729aedd180595ce78e58e95432ea93f5ad
> 
> ls -l /lib/libc.so.1
> -rwxr-xr-x 1 root bin 1575684 Dec 10 21:39 /lib/libc.so.1

This is not actually an issue because of the way we're delivering
libc.so.1. If you look at your mounts you'll see that there's a
mount for that file, which changes the elfhash.
-- 
Chris Nehren
Site Reliability Engineer, OmniTI

From mounty at landcroft.com  Thu Jan  9 20:23:13 2014
From: mounty at landcroft.com (Entfernt)
Date: Fri, 10 Jan 2014 06:23:13 +1000
Subject: [OmniOS-discuss] the right card for a server
Message-ID: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>

This question covers OmniOS and the usual Supermicro hardware base.  I want to add a four-port gigabit ethernet card to a 5017C-LF:

http://www.supermicro.com/products/system/1u/5017/sys-5017c-lf.cfm

So that's PCI Express x8.

Most cards for the machine are two-port but this one:

http://www.iphase.com/products/product.cfm/PCI%20Express/399

appears to fit the bill.  In particular, it has the Broadcom? BCM5704C chipset which appears on the HCL:

https://www.illumos.org/hcl/

but I'm a programmer rather than a sysadmin or hardware person.  Can anyone see any obvious reason for the card not working ?  Thanks in expectation.


-- 
Michael Mounteney

From danmcd at omniti.com  Thu Jan  9 21:50:17 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Jan 2014 16:50:17 -0500
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
Message-ID: <6D3990BC-01C7-44FB-B26C-95CE5383D6BC@omniti.com>


On Jan 9, 2014, at 3:23 PM, Entfernt <mounty at landcroft.com> wrote:

> This question covers OmniOS and the usual Supermicro hardware base.  I want to add a four-port gigabit ethernet card to a 5017C-LF:
> 
> http://www.supermicro.com/products/system/1u/5017/sys-5017c-lf.cfm
> 
> So that's PCI Express x8.
> 
> Most cards for the machine are two-port but this one:
> 
> http://www.iphase.com/products/product.cfm/PCI%20Express/399
> 
> appears to fit the bill.  In particular, it has the Broadcom? BCM5704C chipset which appears on the HCL:
> 
> https://www.illumos.org/hcl/

This is a pretty good one to pick.  It's supported by open-source 'bge'.

> but I'm a programmer rather than a sysadmin or hardware person.  Can anyone see any obvious reason for the card not working ?  Thanks in expectation.

If you want something a bit more modern, you could try the Intel I350:

	http://www.newegg.com/Product/Product.aspx?Item=N82E16833106129

But the one you mentioned SHOULD work just fine.

Dan


From jim.oltman at gmail.com  Thu Jan  9 22:41:20 2014
From: jim.oltman at gmail.com (Jim Oltman)
Date: Thu, 9 Jan 2014 15:41:20 -0700
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <6D3990BC-01C7-44FB-B26C-95CE5383D6BC@omniti.com>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
	<6D3990BC-01C7-44FB-B26C-95CE5383D6BC@omniti.com>
Message-ID: <CA+Rs3OeUAae4AeegU-jNBaebUY=cm8pOAnM9E36gL+=v1HnaHw@mail.gmail.com>

On Thu, Jan 9, 2014 at 2:50 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> On Jan 9, 2014, at 3:23 PM, Entfernt <mounty at landcroft.com> wrote:
>
> > This question covers OmniOS and the usual Supermicro hardware base.  I
> want to add a four-port gigabit ethernet card to a 5017C-LF:
> >
> > http://www.supermicro.com/products/system/1u/5017/sys-5017c-lf.cfm
> >
> > So that's PCI Express x8.
> >
> > Most cards for the machine are two-port but this one:
> >
> > http://www.iphase.com/products/product.cfm/PCI%20Express/399
> >
> > appears to fit the bill.  In particular, it has the Broadcom? BCM5704C
> chipset which appears on the HCL:
> >
> > https://www.illumos.org/hcl/
>
> This is a pretty good one to pick.  It's supported by open-source 'bge'.
>
> > but I'm a programmer rather than a sysadmin or hardware person.  Can
> anyone see any obvious reason for the card not working ?  Thanks in
> expectation.
>
> If you want something a bit more modern, you could try the Intel I350:
>
>         http://www.newegg.com/Product/Product.aspx?Item=N82E16833106129
>
> But the one you mentioned SHOULD work just fine.
>
> Dan


It's recommended to stick with Intel hardware as it's most supported.  I
would go with Dan's recommendation.  He knows his stuff.

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140109/76096b00/attachment.html>

From danmcd at omniti.com  Thu Jan  9 22:55:04 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Jan 2014 17:55:04 -0500
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <CA+Rs3OeUAae4AeegU-jNBaebUY=cm8pOAnM9E36gL+=v1HnaHw@mail.gmail.com>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
	<6D3990BC-01C7-44FB-B26C-95CE5383D6BC@omniti.com>
	<CA+Rs3OeUAae4AeegU-jNBaebUY=cm8pOAnM9E36gL+=v1HnaHw@mail.gmail.com>
Message-ID: <6B5BD9EB-A582-4DAC-93F8-25293A9264D3@omniti.com>


On Jan 9, 2014, at 5:41 PM, Jim Oltman <jim.oltman at gmail.com> wrote:
> 
> It's recommended to stick with Intel hardware as it's most supported.  I would go with Dan's recommendation.  He knows his stuff.

The reason people buy Broadcom is because it's cheaper... MUCH cheaper sometimes.

Luckily, the Broadcom part mentioned by the original poster was a NetXreme I part, which is open-source-happy bge, AND already supported.  It's not like he looked at a 5720 (two ports per chip, and mostly working, but not yet integrated) or 5719 (four ports per chip, and has Real Problems from what I've seen and tested).

The original poster could go with the specific Broadcom board he found and would be fine.  I mentioned the I350 for completeness and paranoia.

Dan


From gate03 at landcroft.co.uk  Thu Jan  9 23:26:45 2014
From: gate03 at landcroft.co.uk (Michael Mounteney)
Date: Fri, 10 Jan 2014 10:26:45 +1100
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <6B5BD9EB-A582-4DAC-93F8-25293A9264D3@omniti.com>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
	<6D3990BC-01C7-44FB-B26C-95CE5383D6BC@omniti.com>
	<CA+Rs3OeUAae4AeegU-jNBaebUY=cm8pOAnM9E36gL+=v1HnaHw@mail.gmail.com>
	<6B5BD9EB-A582-4DAC-93F8-25293A9264D3@omniti.com>
Message-ID: <b995e1580fb2b5e9c24c8761c593241e.squirrel@landcroft.co.uk>

Thanks for your comments Dan.

The board I found is a PCI Express x8 whereas the I350 is x4.  What does
that mean, and does it matter at all ?  The server has an x8 slot.

> Luckily, the Broadcom part mentioned by the original poster was a NetXreme
> I part, which is open-source-happy bge, AND already supported.  It's not
> like he looked at a 5720 (two ports per chip, and mostly working, but not
> yet integrated) or 5719 (four ports per chip, and has Real Problems from
> what I've seen and tested).
>
> The original poster could go with the specific Broadcom board he found and
> would be fine.  I mentioned the I350 for completeness and paranoia.

Michael.

From gate03 at landcroft.co.uk  Thu Jan  9 23:48:08 2014
From: gate03 at landcroft.co.uk (Michael Mounteney)
Date: Fri, 10 Jan 2014 10:48:08 +1100
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <1973910759.20140109231509@tierarzt-mueller.de>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
	<1973910759.20140109231509@tierarzt-mueller.de>
Message-ID: <30e9da749bc0b63d2beb1803d85abac7.squirrel@landcroft.co.uk>

> Hello,
>
> you need a Riser-Card (RSC-RR1U-E8) too.
>
> Take a look at Supermicro add-on Cards:
> http://www.supermicro.nl/products/accessories/index.cfm
>
> There you can find a 4 Port Intel Nic
> http://www.supermicro.nl/products/accessories/addon/AOC-UG-i4.cfm

I appreciate that you are trying to help, Alexandre, but there are two
points that I find puzzling in your advice.

Firstly that I've never seen any other reference to needing a riser for a
PCI card.  SAS, yes;   PCI, no.

Secondly, Supermicro's own compatibility matrix for the product, at
http://www.supermicro.nl/support/resources/AOC/UIO_AOC_Compatibility.cfm ,
excludes the NIC you mention from my hardware;  it is a full-height card
and the 5017C-LF only accommodates low-profile.

Michael.

From skiselkov.ml at gmail.com  Thu Jan  9 23:55:13 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Thu, 09 Jan 2014 23:55:13 +0000
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <b995e1580fb2b5e9c24c8761c593241e.squirrel@landcroft.co.uk>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>	<6D3990BC-01C7-44FB-B26C-95CE5383D6BC@omniti.com>	<CA+Rs3OeUAae4AeegU-jNBaebUY=cm8pOAnM9E36gL+=v1HnaHw@mail.gmail.com>	<6B5BD9EB-A582-4DAC-93F8-25293A9264D3@omniti.com>
	<b995e1580fb2b5e9c24c8761c593241e.squirrel@landcroft.co.uk>
Message-ID: <52CF36E1.3010802@gmail.com>

On 1/9/14, 11:26 PM, Michael Mounteney wrote:
> Thanks for your comments Dan.
> 
> The board I found is a PCI Express x8 whereas the I350 is x4.  What does
> that mean, and does it matter at all ?  The server has an x8 slot.

As both cards use PCI-Express 2.0, four lanes are able to deliver up to
4x 4Gbit/s full duplex. Given that the card is a 4x 1Gbit/s Ethernet
part, I wouldn't worry about it.

-- 
Saso

From skiselkov.ml at gmail.com  Fri Jan 10 00:02:07 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Fri, 10 Jan 2014 00:02:07 +0000
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <30e9da749bc0b63d2beb1803d85abac7.squirrel@landcroft.co.uk>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>	<1973910759.20140109231509@tierarzt-mueller.de>
	<30e9da749bc0b63d2beb1803d85abac7.squirrel@landcroft.co.uk>
Message-ID: <52CF387F.1040200@gmail.com>

On 1/9/14, 11:48 PM, Michael Mounteney wrote:
>> Hello,
>>
>> you need a Riser-Card (RSC-RR1U-E8) too.
>>
>> Take a look at Supermicro add-on Cards:
>> http://www.supermicro.nl/products/accessories/index.cfm
>>
>> There you can find a 4 Port Intel Nic
>> http://www.supermicro.nl/products/accessories/addon/AOC-UG-i4.cfm
> 
> I appreciate that you are trying to help, Alexandre, but there are two
> points that I find puzzling in your advice.
> 
> Firstly that I've never seen any other reference to needing a riser for a
> PCI card.  SAS, yes;   PCI, no.

Of course you need a riser. How else do you think the card's gonna make
that turn from vertical to horizontal to fit in that chassis? PCI risers
are simply (most commonly) passive mechanical adapters that allow you to
route PCI ports to other physical locations within the chassis.

And SAS risers? Never of that. Don't you mean expanders?

> Secondly, Supermicro's own compatibility matrix for the product, at
> http://www.supermicro.nl/support/resources/AOC/UIO_AOC_Compatibility.cfm ,
> excludes the NIC you mention from my hardware;  it is a full-height card
> and the 5017C-LF only accommodates low-profile.

Interesting, because from the pictures it *looks* like a full-height
slot. But yeah, if it's low-profile-only, then you'd wanna get something
that fits into low-profile (like the I350-T4: http://tinyurl.com/ncwa92s )

-- 
Saso

From skiselkov.ml at gmail.com  Fri Jan 10 00:08:06 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Fri, 10 Jan 2014 00:08:06 +0000
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
Message-ID: <52CF39E6.4020304@gmail.com>

On 1/9/14, 8:23 PM, Entfernt wrote:
> This question covers OmniOS and the usual Supermicro hardware base.  I want to add a four-port gigabit ethernet card to a 5017C-LF:
> 
> http://www.supermicro.com/products/system/1u/5017/sys-5017c-lf.cfm
> 
> So that's PCI Express x8.
> 
> Most cards for the machine are two-port but this one:
> 
> http://www.iphase.com/products/product.cfm/PCI%20Express/399
> 
> appears to fit the bill.  In particular, it has the Broadcom? BCM5704C chipset which appears on the HCL:
> 
> https://www.illumos.org/hcl/
> 
> but I'm a programmer rather than a sysadmin or hardware person.  Can anyone see any obvious reason for the card not working ?  Thanks in expectation.
> 
> 

Oh and one last thing: what do you *need* the extra 2 ports for? As in,
do you need them for the physically separate ports, or do you need the
extra performance? If it's for the performance, it might make sense to
look at 10-gig NICs. Dual-port 10-gig can be had in low-profile for just
a little more money than 4x 1-gig. But of course, if it doesn't fit your
workload requirements, then ignore me. Just a thought...

-- 
Saso

From mattfrazer at gmail.com  Fri Jan 10 00:46:16 2014
From: mattfrazer at gmail.com (Matthew Frazer)
Date: Thu, 9 Jan 2014 19:46:16 -0500
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <52CF387F.1040200@gmail.com>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
	<1973910759.20140109231509@tierarzt-mueller.de>
	<30e9da749bc0b63d2beb1803d85abac7.squirrel@landcroft.co.uk>
	<52CF387F.1040200@gmail.com>
Message-ID: <CAKMYTWADzDe+06WYhwFtAA-h1g2ni0OYbDV4tX5GC0YWyf0uew@mail.gmail.com>

I think the confusion is partly on supermicro. The manual for the server
states:
...
The 5017C-LF includes a CSE-RR1U-E8 riser card. This riser ?ts into a PCI
slot
to support a full-height, half-length PCI Express expansion card. (The
riser card
provides a PCI-E x8 signal
...

Which appears to be at odds with the spec sheet that states:

   - 1x PCI-E 3.0* x8 Low-profile slot



It certainly looks like a full height slot but the spec sheet also states
2x2.5" bays maximum where the manual states 4x2.5". I can't see how 4x2.5"
is possible with a full height card, so it's entirely possible that all the
above statements are true depending on the how you order it. You'll need a
reseller or someone with direct experience to be sure.

-mjf




On Thu, Jan 9, 2014 at 7:02 PM, Saso Kiselkov <skiselkov.ml at gmail.com>wrote:

> On 1/9/14, 11:48 PM, Michael Mounteney wrote:
> >> Hello,
> >>
> >> you need a Riser-Card (RSC-RR1U-E8) too.
> >>
> >> Take a look at Supermicro add-on Cards:
> >> http://www.supermicro.nl/products/accessories/index.cfm
> >>
> >> There you can find a 4 Port Intel Nic
> >> http://www.supermicro.nl/products/accessories/addon/AOC-UG-i4.cfm
> >
> > I appreciate that you are trying to help, Alexandre, but there are two
> > points that I find puzzling in your advice.
> >
> > Firstly that I've never seen any other reference to needing a riser for a
> > PCI card.  SAS, yes;   PCI, no.
>
> Of course you need a riser. How else do you think the card's gonna make
> that turn from vertical to horizontal to fit in that chassis? PCI risers
> are simply (most commonly) passive mechanical adapters that allow you to
> route PCI ports to other physical locations within the chassis.
>
> And SAS risers? Never of that. Don't you mean expanders?
>
> > Secondly, Supermicro's own compatibility matrix for the product, at
> > http://www.supermicro.nl/support/resources/AOC/UIO_AOC_Compatibility.cfm,
> > excludes the NIC you mention from my hardware;  it is a full-height card
> > and the 5017C-LF only accommodates low-profile.
>
> Interesting, because from the pictures it *looks* like a full-height
> slot. But yeah, if it's low-profile-only, then you'd wanna get something
> that fits into low-profile (like the I350-T4: http://tinyurl.com/ncwa92s )
>
> --
> Saso
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 
It is in love that we are made, in love we disappear.
-Leonard Cohen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140109/91f5242a/attachment.html>

From gate03 at landcroft.co.uk  Fri Jan 10 00:58:48 2014
From: gate03 at landcroft.co.uk (Michael Mounteney)
Date: Fri, 10 Jan 2014 11:58:48 +1100
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <52CF44FD.10101@gmail.com>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
	<1973910759.20140109231509@tierarzt-mueller.de>
	<30e9da749bc0b63d2beb1803d85abac7.squirrel@landcroft.co.uk>
	<52CF387F.1040200@gmail.com>
	<30caa541ac1624df4be1fb3fd45d1077.squirrel@landcroft.co.uk>
	<52CF42DF.3040609@gmail.com> <52CF44FD.10101@gmail.com>
Message-ID: <156220b6d6187f3f6f5ac3f2b367749d.squirrel@landcroft.co.uk>

> On 1/10/14, 12:46 AM, Saso Kiselkov wrote:
>> How about getting a dedicated 8-port gig switch? Sure, it can be a bit
>> of extra hassle, but for the kind of money you'll spend on a 4-port
>> gig-E server NIC you can also get a reasonable dedicated rack-mountable
>> 8-port gig-E switch (Linksys SRW2008 seems like a workable basic switch
>> for SOHO deployments).
>
> You may also want to have a look at Cisco's 300 series of SOHO switches.
> I'm seeing a SG 300-10 (10-port gig-E managed) for about $200 on Amazon
> - that's damn cheap for a Cisco-anything. Maybe they're crap, haven't
> tried one myself, though it does look tempting...

I already have a secondhand Netgear GS724T which hopefully should be up to
the job.

Thanks again,

Michael.

From sergey57 at gmail.com  Fri Jan 10 02:45:59 2014
From: sergey57 at gmail.com (sergey ivanov)
Date: Thu, 9 Jan 2014 21:45:59 -0500
Subject: [OmniOS-discuss] r151008 ipkg zone attach problems
In-Reply-To: <6E4B61D3-76F9-4F65-B860-682FE9C2BAF1@kram.io>
References: <20131207165258.GA7252@gutsman.lotheac.fi>
	<90524a43-e12c-4e09-97dd-5cb957c48a17@mteege.de>
	<4A790812-F8A0-4FA9-991E-355FC4C8F160@omniti.com>
	<6E4B61D3-76F9-4F65-B860-682FE9C2BAF1@kram.io>
Message-ID: <CAAv=BDE_X+ZgwpdPSpXPa86mr-aT47ABrAJm7BEHCSJab5RTbg@mail.gmail.com>

I had similar problem.
I do not see "update" verb in zoneadm command. I think "pkg -R
<zonepath>/root update" was used for upgrading detached zones.
For me it did not work initially. All detached zones had empty list of
publishers. So, to workaround the problem, the needed steps were the
following:
1. Recreate package publishers, that is,  for all publishers do
---
pkg -R <zonepath>/root set-publisher -g
http://pkg.omniti.com/omnios/releaseomnios
---
2. Update zone image
---
pkg -R <zonepath>/root update
---
3. Attach the zone
---
zoneadm -z <zonename> attach
---
When I've tried after 1-st step, instead of updating packages from global
zone just attaching with '-u', all publishers were unset immediately.
-- 
  Regards,
  Sergey Ivanov.


On Tue, Jan 7, 2014 at 7:51 AM, Steffen Kram <sk at kram.io> wrote:

> Hi,
>
> beside this fix I?m still having problems re-attaching my zone. I just
> upgraded the global zone to r151008f. So I already got the fixed versions:
>
> root at hume:~# pkg info package/pkg
> ...       FMRI: pkg://omnios/package/pkg at 0.5.11
> ,5.11-0.151008:20131230T201906Z
> root at hume:~# pkg info system/zones/brand/ipkg
> ...       FMRI: pkg://omnios/system/zones/brand/ipkg at 0.5.11
> ,5.11-0.151008:20131230T201908Z
>
> Next I tried to update one of my non-global zones using the zoneadm attach
> -u command:
>
> root at hume:~# zoneadm -z telford attach -u
> Log File: /var/tmp/telford.attach_log.hmaqMh
>                Attach Path: /zones/telford/root
>         Attach ZFS Dataset: cairngorm/zones/telford/ROOT/zbe-2
>
>                 Installing: Using pre-existing data in zonepath
>        Global zone version: entire at 11,5.11-0.151008:20131205T195242Z
>    Non-Global zone version: entire at 11,5.11-0.151006:20130507T204959Z
>                      Cache: Using /var/pkg/publisher.
>   Updating non-global zone: Output follows
> Creating Plan
> ERROR: Could not update attaching zone
>                     Result: Attach Failed.
>
> It did fail because of
>
> [ 7. Januar 2014 13:42:55 CET]   Updating non-global zone: Output follows
> pkg set-publisher: The origin URIs for 'omnios' do not appear to point to
> a valid pkg repository.
> Please verify the repository's location and the client's network
> configuration.
> Additional details:
>
> Unable to contact valid package repository
> Encountered the following error(s):
> Unable to contact any configured publishers.
> This is likely a network configuration problem.
> Framework error: code: 7 reason: Failed connect to localhost:10000;
> Connection refused
> URL: 'http://localhost:10000'. (happened 4 times)
>
> pkg set-publisher: The origin URIs for 'uulm.mawi' do not appear to point
> to a valid pkg repository.
> Please verify the repository's location and the client's network
> configuration.
> Additional details:
>
> Unable to contact valid package repository
> Encountered the following error(s):
> Unable to contact any configured publishers.
> This is likely a network configuration problem.
> Framework error: code: 7 reason: Failed connect to localhost:10000;
> Connection refused
> URL: 'http://localhost:10000'. (happened 4 times)
>
>
> pkg install: The following pattern(s) did not match any allowable
> packages.  Try
> using a different matching pattern, or refreshing publisher information:
>
>         entire at 11,5.11-0.151008:20131205T195242Z
> [ 7. Januar 2014 13:43:05 CET] ERROR: Could not update attaching zone
> [ 7. Januar 2014 13:43:08 CET]                     Result: Attach Failed.
>
> However, there was never a pkg publisher configured on localhost:10000 for
> this zone.
>
> I am able to upgrade and boot the zone when preforming the update from the
> global zone using
>
> zoneadm -R /zones/telford/root update
>
> and attaching the zone afterwards. In this case the publisher information
> in the non-global zone is empty and I have to re-add the omnios default
> publisher manually.
>
> Cheers,
> Steffen
>
>
> Am 06.01.2014 um 16:49 schrieb Dale Ghent <daleg at omniti.com>:
>
> >
> > There's a fix out now for this, released on friday. New packages for:
> >
> > package/pkg
> > system/zones/brand/ipkg
> >
> > Update these before you do your zone-related work and it should work as
> expected.
> >
> > /dale
> >
> > On Jan 5, 2014, at 8:17 AM, Matthias Teege <
> matthias-omn-discuss at mteege.de> wrote:
> >
> >> On Sat, Dec 07, 2013 at 06:52:59PM +0200, Lauri Tirkkonen wrote:
> >>
> >> Hi,
> >>
> >>> 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
> >>
> >> I run in the same issue.  Can I attach the r151006 zones without "-u"
> >> and update later?
> >>
> >> Many Thanks
> >> Matthias
> >> _______________________________________________
> >> 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
> >
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>


-- 
Regards,
Sergey Ivanov | sergey57 at gmail.com
http://www.linkedin.com/pub/sergey-ivanov/8/270/a09
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140109/c7ce34d7/attachment-0001.html>

From groups at tierarzt-mueller.de  Fri Jan 10 11:18:09 2014
From: groups at tierarzt-mueller.de (Alexander Lesle)
Date: Fri, 10 Jan 2014 12:18:09 +0100
Subject: [OmniOS-discuss] the right card for a server
In-Reply-To: <30e9da749bc0b63d2beb1803d85abac7.squirrel@landcroft.co.uk>
References: <20140110062313.45d3e7134802ab54ab4bbded@landcroft.com>
	<1973910759.20140109231509@tierarzt-mueller.de>
	<30e9da749bc0b63d2beb1803d85abac7.squirrel@landcroft.co.uk>
Message-ID: <0309633.20140110121809@tierarzt-mueller.de>

Morning Michael and List,

am Freitag, 10. Januar 2014 um 00:48 hat <Michael Mounteney> u.a.
in mid:30e9da749bc0b63d2beb1803d85abac7.squirrel at landcroft.co.uk geschrieben:
>> you need a Riser-Card (RSC-RR1U-E8) too.

About riser-card you got a answer from Matthew Frazer.

>> Take a look at Supermicro add-on Cards:
>> http://www.supermicro.nl/products/accessories/index.cfm
>>
>> There you can find a 4 Port Intel Nic
>> http://www.supermicro.nl/products/accessories/addon/AOC-UG-i4.cfm

> I appreciate that you are trying to help, Alexandre, but there are two
> points that I find puzzling in your advice.

> Firstly that I've never seen any other reference to needing a riser for a
> PCI card.  SAS, yes;   PCI, no.


> Secondly, Supermicro's own compatibility matrix for the product, at
> http://www.supermicro.nl/support/resources/AOC/UIO_AOC_Compatibility.cfm
> excludes the NIC you mention from my hardware;  it is a full-height card
> and the 5017C-LF only accommodates low-profile.

Thats about the slot-plate nothing else.
UIO is it on the other side. Its not a problem to chance it to
standard and the SM add-on cards are quite cheap.

Look at the 4-port interphase nic
the specs tells also:
Form Factor: PCI express, standard height, half length
and standard height is full height

I have found this Intel nic in low profile, but maybe EOL
http://www.intel.com/content/www/us/en/network-adapters/gigabit-network-adapters/pro-1000-pt-qp.html

-- 
Mit freundlichem Gruss
Alexander
mailto:groups at tierarzt-mueller.de
eMail geschrieben mit: The Bat! 5.8.8
unter Windows 7 Pro Service Pack 1



From natxo.asenjo at gmail.com  Fri Jan 10 11:46:37 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 10 Jan 2014 12:46:37 +0100
Subject: [OmniOS-discuss] zoneadm -z zone attach -u fails
In-Reply-To: <CACLsApvs6Cffh38wY9_juN2yeHkgw3w6xwux16SEqCBKkfxH6g@mail.gmail.com>
References: <CAHBEJzUK2t92B=d+ACGvqQrihPcZpRfonEbDK-f_W67cZ5Djug@mail.gmail.com>
	<20131213162641.GE5178@eschaton.local>
	<CAHBEJzV8CL8nT9KGqUDs6v5m+fda8rwFeF0RzXn0EvPRT3Frpg@mail.gmail.com>
	<CACLsApvs6Cffh38wY9_juN2yeHkgw3w6xwux16SEqCBKkfxH6g@mail.gmail.com>
Message-ID: <CAHBEJzVHns6cy9WusTiCK8bFS-pYv7X1So75gYuNVkQjUvrUHw@mail.gmail.com>

hi,

to follow up in this issue, today I read in another post that updating
pkg and ipkg should solve this, so I booted in
r151008, updated pkg and ipkg in that BE and retried the zone attach command:

# /usr/sbin/zoneadm -z zone1 attach -u
Log File: /var/tmp/zone1.attach_log.qDaiXc
               Attach Path: /tank/zones/zone1/root
        Attach ZFS Dataset: tank/zones/zone1/ROOT/zbe-1

                Installing: Using pre-existing data in zonepath
       Global zone version: entire at 11,5.11-0.151008:20131205T195242Z
   Non-Global zone version: entire at 11,5.11-0.151006:20130507T204959Z
                     Cache: Using /var/pkg/publisher.
  Updating non-global zone: Output follows
Creating Plan
ERROR: Could not update attaching zone
                    Result: Attach Failed.

in the log file I see this:

pkg set-publisher: Publisher 'omnios' is disabled and cannot be used
for packaging operations.

pkg install: The following pattern(s) did not match any allowable packages.  Try
using a different matching pattern, or refreshing publisher information:

        entire at 11,5.11-0.151008:20131205T195242Z
[January 10, 2014 12:37:28 PM CET] ERROR: Could not update attaching zone
[January 10, 2014 12:37:29 PM CET]                     Result: Attach Failed.

Any clues as to why this is failing? This is just a test zone, so it
is not a big deal to wipe it and go on with my life, but I am just
curious as to why it is failing.

TIA,

--
Groeten,
natxo

From sergey57 at gmail.com  Fri Jan 10 12:42:42 2014
From: sergey57 at gmail.com (sergey ivanov)
Date: Fri, 10 Jan 2014 07:42:42 -0500
Subject: [OmniOS-discuss] zoneadm -z zone attach -u fails
In-Reply-To: <CAHBEJzVHns6cy9WusTiCK8bFS-pYv7X1So75gYuNVkQjUvrUHw@mail.gmail.com>
References: <CAHBEJzUK2t92B=d+ACGvqQrihPcZpRfonEbDK-f_W67cZ5Djug@mail.gmail.com>
	<20131213162641.GE5178@eschaton.local>
	<CAHBEJzV8CL8nT9KGqUDs6v5m+fda8rwFeF0RzXn0EvPRT3Frpg@mail.gmail.com>
	<CACLsApvs6Cffh38wY9_juN2yeHkgw3w6xwux16SEqCBKkfxH6g@mail.gmail.com>
	<CAHBEJzVHns6cy9WusTiCK8bFS-pYv7X1So75gYuNVkQjUvrUHw@mail.gmail.com>
Message-ID: <CAAv=BDHXH8buT83fpvXboUVEEr6f45q_X2U=DqbQmS6C_wHfRQ@mail.gmail.com>

I still have a problem with upgrading to 151008 my first testing host,
running some non-global zones. I think the cause of my problems is absence
of packages built for 151008 in omniti-ms repository.

Global zone upgraded per instructions without problems. When I tried
attaching with '-u' non-global zones, it failed.
Running 'pkg -R <zonepath>/root -u' for these zones from global zones
revealed that they have lost all publishers.
Readding publishers with 'pkg -R <zonepath>/root pkg set-publisher -g <url>
<publisher>'  and then running
'pkg -R <zonepath>/root update' worked for some of the zones. But some
completed update very fast, without much of work done:
---

# pkg -R <zonepath>/root/ update
            Packages to update:  7
       Create boot environment: No
Create backup boot environment: No

DOWNLOAD                                  PKGS       FILES    XFER (MB)
Completed                                  7/7     151/151      6.1/6.1

PHASE                                        ACTIONS
Install Phase                                    5/5
Update Phase                                 163/163

PHASE                                          ITEMS
Package State Update Phase                     14/14
Package Cache Update Phase                       7/7
Image State Update Phase                         2/2

---------------------------------------------------------------------------
NOTE: Please review release notes posted at:
http://omnios.omniti.com/ReleaseNotes
---------------------------------------------------------------------------

---
I looked at the list of packages installed there by 'pkg -R ... list' and
saw not any package from 151008 release!
I tried running 'pkg -R ... update' second time, I got:
---

# pkg -R <zonepath>/root/ 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
Dependency analysis is unable to determine exact cause.
Try specifying expected results to obtain more detailed error messages.

---

Then I was trying to update these packgages one by one in -R
<zonepath>/root, and I think I saw the cause of my problem:

---

# pkg -R <zonepath>/root/ install
pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151008:20131204T022427Z
Creating Plan /
pkg install: No matching version of
consolidation/osnet/osnet-incorporation can be installed:
  Reject:  pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151008:20131204T022427Z
  Reason:  This version is excluded by installed incorporation
pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151006:20130506T183443Z

# pkg -R <zonepath>/root/ install
pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151006:20130506T183443Z
No updates necessary for this image.
# pkg -R <zonepath>/root/ install
pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008
Creating Plan /
pkg install: No matching version of incorporation/jeos/illumos-gate
can be installed:
  Reject:  pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z
  Reason:  This version is excluded by installed incorporation
pkg://omnios/entire at 11,5.11-0.151006:20131210T224515Z

# pkg -R <zonepath>/root/ install pkg://omnios/entire at 11,5.11-0.151008
Creating Plan /
pkg install: No matching version of entire can be installed:
  Reject:  pkg://omnios/entire at 11,5.11-0.151008:20131204T230829Z
           pkg://omnios/entire at 11,5.11-0.151008:20131205T191306Z
           pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z
  Reason:  This version is excluded by installed incorporation
pkg://ms.omniti.com/omniti/database/postgresql-930 at 9.3.0,5.11-0.151006:20130918T174100Z
           This version is excluded by installed incorporation
pkg://ms.omniti.com/omniti/library/uuid at 1.41.14,5.11-0.151006:20131015T044739Z

---

So, I think I have to wait until omniti-ms will have packages for new
stable release, or to build these packages myself.

-- 

  Regards,

  Sergey Ivanov.



On Fri, Jan 10, 2014 at 6:46 AM, Natxo Asenjo <natxo.asenjo at gmail.com>wrote:

> hi,
>
> to follow up in this issue, today I read in another post that updating
> pkg and ipkg should solve this, so I booted in
> r151008, updated pkg and ipkg in that BE and retried the zone attach
> command:
>
> # /usr/sbin/zoneadm -z zone1 attach -u
> Log File: /var/tmp/zone1.attach_log.qDaiXc
>                Attach Path: /tank/zones/zone1/root
>         Attach ZFS Dataset: tank/zones/zone1/ROOT/zbe-1
>
>                 Installing: Using pre-existing data in zonepath
>        Global zone version: entire at 11,5.11-0.151008:20131205T195242Z
>    Non-Global zone version: entire at 11,5.11-0.151006:20130507T204959Z
>                      Cache: Using /var/pkg/publisher.
>   Updating non-global zone: Output follows
> Creating Plan
> ERROR: Could not update attaching zone
>                     Result: Attach Failed.
>
> in the log file I see this:
>
> pkg set-publisher: Publisher 'omnios' is disabled and cannot be used
> for packaging operations.
>
> pkg install: The following pattern(s) did not match any allowable
> packages.  Try
> using a different matching pattern, or refreshing publisher information:
>
>         entire at 11,5.11-0.151008:20131205T195242Z
> [January 10, 2014 12:37:28 PM CET] ERROR: Could not update attaching zone
> [January 10, 2014 12:37:29 PM CET]                     Result: Attach
> Failed.
>
> Any clues as to why this is failing? This is just a test zone, so it
> is not a big deal to wipe it and go on with my life, but I am just
> curious as to why it is failing.
>
> TIA,
>
> --
> Groeten,
> natxo
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 
Regards,
Sergey Ivanov | sergey57 at gmail.com
http://www.linkedin.com/pub/sergey-ivanov/8/270/a09
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140110/3abf35db/attachment.html>

From natxo.asenjo at gmail.com  Fri Jan 10 13:29:24 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 10 Jan 2014 14:29:24 +0100
Subject: [OmniOS-discuss] zoneadm -z zone attach -u fails
In-Reply-To: <CAAv=BDHXH8buT83fpvXboUVEEr6f45q_X2U=DqbQmS6C_wHfRQ@mail.gmail.com>
References: <CAHBEJzUK2t92B=d+ACGvqQrihPcZpRfonEbDK-f_W67cZ5Djug@mail.gmail.com>
	<20131213162641.GE5178@eschaton.local>
	<CAHBEJzV8CL8nT9KGqUDs6v5m+fda8rwFeF0RzXn0EvPRT3Frpg@mail.gmail.com>
	<CACLsApvs6Cffh38wY9_juN2yeHkgw3w6xwux16SEqCBKkfxH6g@mail.gmail.com>
	<CAHBEJzVHns6cy9WusTiCK8bFS-pYv7X1So75gYuNVkQjUvrUHw@mail.gmail.com>
	<CAAv=BDHXH8buT83fpvXboUVEEr6f45q_X2U=DqbQmS6C_wHfRQ@mail.gmail.com>
Message-ID: <CAHBEJzWqHQ9QhrFryh3bCgUMEw2cXrdJTYV00rCs2=9ehT8uTA@mail.gmail.com>

hi,

Thanks to Sergey's tips I got it working.

Here is how:

1. I checked the list of publishers in the zone, and indeed, omnios was missing:
root at zfstank:~# pkg -R /tank/zones/zone1/root/ publisher
PUBLISHER                             TYPE     STATUS   URI
omnios.blackdot.be                    origin   online
http://omnios.blackdot.be/

2. Then I added the omnios publisher:
root at zfstank:~# pkg -R /tank/zones/zone1/root/ set-publisher -g
http://pkg.omniti.com/omnios/release/ omnios

3. Rechecked the publishers' list, now you see omnios in there:
root at zfstank:~# pkg -R /tank/zones/zone1/root/ publisher
PUBLISHER                             TYPE     STATUS   URI
omnios.blackdot.be                    origin   online
http://omnios.blackdot.be/
omnios                                origin   online
http://pkg.omniti.com/omnios/release/

4. Run the update:
root at zfstank:~# pkg -R /tank/zones/zone1/root/ update
            Packages to remove:   4
            Packages to update: 375
       Create boot environment:  No
Create backup boot environment:  No
            Services to change:   1

DOWNLOAD                                  PKGS       FILES    XFER (MB)
Completed                              379/379 11962/11962  193.5/193.5

PHASE                                        ACTIONS
Removal Phase                            12268/12268
Install Phase                            10325/10325
Update Phase                               8660/8660

PHASE                                          ITEMS
Package State Update Phase                   754/754
Package Cache Update Phase                   379/379
Image State Update Phase                         2/2

---------------------------------------------------------------------------
NOTE: Please review release notes posted at:

http://omnios.omniti.com/ReleaseNotes
---------------------------------------------------------------------------

5. Attache the zone:
root at zfstank:~# zoneadm -z zone1 attach
Log File: /var/tmp/zone1.attach_log.FMaGQf
               Attach Path: /tank/zones/zone1/root
        Attach ZFS Dataset: tank/zones/zone1/ROOT/zbe-1

                Installing: Using pre-existing data in zonepath
       Global zone version: entire at 11,5.11-0.151008:20131205T195242Z
   Non-Global zone version: entire at 11,5.11-0.151008:20131205T195242Z
                     Cache: Using /var/pkg/publisher.
  Updating non-global zone: Output follows
No updates necessary for this image.

                    Result: Attach Succeeded.


6. Booted the zone, all is well now.

Thanks!


-- 
regards,
Natxo

From cj.keist at colostate.edu  Fri Jan 10 20:57:31 2014
From: cj.keist at colostate.edu (CJ Keist)
Date: Fri, 10 Jan 2014 13:57:31 -0700
Subject: [OmniOS-discuss] Newbie to OmniOS
Message-ID: <52D05EBB.8070802@colostate.edu>

Looking to see if OmniOS runs well as a VM with Proxmox?  We are running 
Proxmox 3.1-3 currently.  I was able to get OmniOS to install but have 
issue in that it is not enabling the 4 cpus I defined for the vm.  Boot 
states something like it sees 4 cpus but only enabled one. See 
boot-ncpus with eeprom to set more cpus.  I did this and rebooted, but 
the system still only enables one cpu of the four.

Setup:
Memory: 4gb
Processors 4(1 socket, 4cores)[qemu64]
hard disk(ide0) format vmdk, cache=writethrough size=12gb
Network Device(net0) e1000 bridge=vmbr0

Any help would be greatly appreciated.


-- 
C. J. Keist                     Email: cj.keist at colostate.edu
Systems Group Manager           Solaris 10 OS (SAI)
Engineering Network Services    Phone: 970-491-0630
College of Engineering, CSU     Fax:   970-491-5569
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'

From mir at miras.org  Fri Jan 10 23:56:45 2014
From: mir at miras.org (Michael Rasmussen)
Date: Sat, 11 Jan 2014 00:56:45 +0100
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <52D05EBB.8070802@colostate.edu>
References: <52D05EBB.8070802@colostate.edu>
Message-ID: <20140111005645.7f9af583@sleipner.datanom.net>

On Fri, 10 Jan 2014 13:57:31 -0700
CJ Keist <cj.keist at colostate.edu> wrote:

> 
> Setup:
> Memory: 4gb
> Processors 4(1 socket, 4cores)[qemu64]
> hard disk(ide0) format vmdk, cache=writethrough size=12gb
> Network Device(net0) e1000 bridge=vmbr0
> 
Omnios does not handle cores, only sockets. So do this instead:
Processors 4(4 socket, 1cores)[qemu64]

And for performance:
hard disk(sata0) format qcow2, cache=none size=12gb

-- 
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:
You have the body of a 19 year old.  Please return it before it gets
wrinkled.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140111/f79c08af/attachment.bin>

From henson at acm.org  Sat Jan 11 02:36:46 2014
From: henson at acm.org (Paul B. Henson)
Date: Fri, 10 Jan 2014 18:36:46 -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: <03f401cf0e75$faf5d0d0$f0e17270$@acm.org>

> From: wuffers [mailto:moo at wuffers.net]
> Sent: Monday, December 09, 2013 7:35 PM
>
> I've just emailed my reseller about this, so I'll update this thread when
I get a
> response.

Did you ever get a response? So far I have still been unable to find a
source for purchasing these "IPMI BIOS update" license keys...



From ypismerov at gmail.com  Sat Jan 11 13:47:30 2014
From: ypismerov at gmail.com (Yuri Pismerov)
Date: Sat, 11 Jan 2014 08:47:30 -0500
Subject: [OmniOS-discuss] pkg update
Message-ID: <26647D0A-7112-4F2D-B757-7E19F562BBDE@gmail.com>

t does not seem it works :(



root at omnios:~# pkg update
pkg: 0/1 catalogs successfully updated:
   
Unable to contact valid package repository
Encountered the following error(s):
Unable to contact any configured publishers.
This is likely a network configuration problem.
http protocol error: code: 404 reason: Not Found
URL: 'http://pkg.omniti.com/omnios/bloody'. (happened 4 times)

root at omnios:~# cat /etc/release
  OmniOS v11 r151007
  Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
  Use is subject to license terms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140111/6929ff5f/attachment.html>

From ypismerov at gmail.com  Sat Jan 11 14:47:31 2014
From: ypismerov at gmail.com (Yuri Pismerov)
Date: Sat, 11 Jan 2014 09:47:31 -0500
Subject: [OmniOS-discuss] pkg update
Message-ID: <E7792A20-6C37-4F9D-B2C0-6F2A0A97B5D6@gmail.com>


I am on bloody and trying to upgrade.
After reading the list I found that bloody repository is no longer available, so I tried:

root at omnios:~# pkg unset-publisher omnios
root at omnios:~# pkg set-publisher -g http://pkg.omniti.com/omnios/release omnios
root at omnios:~# pkg update
Creating Plan -               
pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151008 Release Signing Certificate/emailAddress=om
nios-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/libtool/libltdl at 2.4.2,5.11-0.151008:20131204T024209Z


Then, after more reading, I found that CA ccert an be installed by downloading an unsigned package as follows:

root at omnios:~# pkg update web/ca-bundle at 5.11,5.11-0.151007:20130823T212116Z
Creating Plan                 
pkg update: 'web/ca-bundle at 5.11,5.11-0.151007:20130823T212116Z' matches no installed packages


As it says, it did not work. What are my options now?


root at omnios:~# cat /etc/release 
  OmniOS v11 r151007
  Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
  Use is subject to license terms.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140111/ddc8d3bb/attachment.html>

From mir at miras.org  Sat Jan 11 14:56:13 2014
From: mir at miras.org (Michael Rasmussen)
Date: Sat, 11 Jan 2014 15:56:13 +0100
Subject: [OmniOS-discuss] pkg update
In-Reply-To: <E7792A20-6C37-4F9D-B2C0-6F2A0A97B5D6@gmail.com>
References: <E7792A20-6C37-4F9D-B2C0-6F2A0A97B5D6@gmail.com>
Message-ID: <20140111155613.5abd7fd6@sleipner.datanom.net>

On Sat, 11 Jan 2014 09:47:31 -0500
Yuri Pismerov <ypismerov at gmail.com> wrote:

> 
> As it says, it did not work. What are my options now?
> 
The least painful is to reinstall with 15008.
1) zpool export (all your pools except rpool)
2) install using a downloaded image of 15008
3) zpool import (all your pools except rpool)

-- 
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:
It's not Camelot, but it's not Cleveland, either.
		-- Kevin White, Mayor of Boston
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140111/5c477078/attachment.bin>

From mir at miras.org  Sat Jan 11 15:00:41 2014
From: mir at miras.org (Michael Rasmussen)
Date: Sat, 11 Jan 2014 16:00:41 +0100
Subject: [OmniOS-discuss] pkg update
In-Reply-To: <20140111155613.5abd7fd6@sleipner.datanom.net>
References: <E7792A20-6C37-4F9D-B2C0-6F2A0A97B5D6@gmail.com>
	<20140111155613.5abd7fd6@sleipner.datanom.net>
Message-ID: <20140111160041.5ab20a5f@sleipner.datanom.net>

On Sat, 11 Jan 2014 15:56:13 +0100
Michael Rasmussen <mir at miras.org> wrote:

> On Sat, 11 Jan 2014 09:47:31 -0500
> Yuri Pismerov <ypismerov at gmail.com> wrote:
> 
> > 
> > As it says, it did not work. What are my options now?
> > 
> The least painful is to reinstall with 15008.
> 1) zpool export (all your pools except rpool)
> 2) install using a downloaded image of 15008
> 3) zpool import (all your pools except rpool)
> 
Arrgh. s/15008/151008/g

-- 
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:
A man is like a rusty wheel on a rusty cart,
He sings his song as he rattles along and then he falls apart.
		-- Richard Thompson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140111/fe3e6103/attachment-0001.bin>

From terahz at geodar.com  Sat Jan 11 19:09:07 2014
From: terahz at geodar.com (Georgi Todorov)
Date: Sat, 11 Jan 2014 14:09:07 -0500
Subject: [OmniOS-discuss] Publishers down?
Message-ID: <52D196D3.2010708@geodar.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I was about to upgrade to the latest stable release but I can't seem
to get to the publishers. I was set to the bloody publisher for a
while and have not done updates so switched back to release:

~# pkg unset-publisher omnios
~# pkg set-publisher -g http://pkg.omniti.com/omnios/release omnios
pkg set-publisher: The origin URIs for 'omnios' do not appear to point
to a valid pkg repository.
Please verify the repository's location and the client's network
configuration.
Additional details:

Unable to contact valid package repository
Encountered the following error(s):
Unable to contact any configured publishers.
This is likely a network configuration problem.
1: Framework error: code: 28 reason: Connection timed out after 60000
milliseconds
URL: 'http://pkg.omniti.com/omniti-perl'. (happened 4 times)
2: Framework error: code: 28 reason: Connection timed out after 60000
milliseconds
URL: 'http://pkg.omniti.com/omniti-ms'. (happened 4 times)
3: Framework error: code: 28 reason: Connection timed out after 60000
milliseconds
URL: 'http://pkg.omniti.com/omnios/release'. (happened 4 times)


~# cat /etc/release
  OmniOS v11 r151007
  Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
  Use is subject to license terms.

Internet connection confirmation:
~# curl google.com
<HTML><HEAD><meta http-equiv="content-type"
content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>


Any ideas?

Thanks,
Georgi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJS0ZbSAAoJEAzuUQIrkZXu/KwQAMkaxfKqMBxgDZ3VvyYNxlg5
wWpGcdDfd6XgeClMOsK3eBf29bhvALerZEQ3Dy6YySGCL4yHGz5nz+UpVbi2qBbZ
9KjOFL5mMB4B+QleaA95YKS71dxR8JF5QF6H3XEFYBiJlK3VWX5Y18PHGgaIImdv
lHFKyF/k9niU7QthSDotOOCNYmItFwzxxop/bv9cJZyJmJsgg5KIZNj0wicFTFqw
EpLU1/hIa+WUZB+u7Mbv7MhGjQkwIpRu4yKlGUNCzq5lXeEKTTa1yRMiMrnCf+t3
0oTe8ZnkGvAb9XiWQ36OaECSXiALzsolsi0DKlshW0f2BKvGRPDlB0z7S5VouQyN
7owTaW7SAkaIMq79hSzMKjLIQI1SEr8o4Eq7iUqpW68wSVlGg6lZDJfYj9rIIPUv
aaOEvfMDV6r6dD6nLpxRtNdx9fiQv1yfyx+1M5ZOHtswt4MARVat1eC4PrbHT4rS
Q6hZktevSpDPcWGTK9nL+Xo+DV0aKEQJhFs5deuwuh45ZY8ugwe237GeF7EDewNC
uwwV2rMYoIR2skXyVjhLNUw8ZEnv8fyM83y0wK89+BBUVOA5ozfSS2XKk7Kjn7p2
/ncL0942yzdx0IPojSBWDBAG9eFlwvbypu8V5ns5ANPMSu9e7yp/TEJ0dFMqV8Z9
3WNgmQuLP7YhYymP9Fxb
=I9l9
-----END PGP SIGNATURE-----

From mark at omniti.com  Sun Jan 12 00:02:23 2014
From: mark at omniti.com (Mark Harrison)
Date: Sat, 11 Jan 2014 19:02:23 -0500
Subject: [OmniOS-discuss] Publishers down?
In-Reply-To: <52D196D3.2010708@geodar.com>
References: <52D196D3.2010708@geodar.com>
Message-ID: <CABC3qWcf1VE4MQh0u_YNCqoAnAHQ7T1Ssr+Wh9jb8Hnq_et_Uw@mail.gmail.com>

What does pkg.omniti.com resolve to for you? A little while ago the IP
address changed and it's possible you're still trying to connect to
the old server. The correct IP is 199.15.226.221.

On Sat, Jan 11, 2014 at 2:09 PM, Georgi Todorov <terahz at geodar.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> I was about to upgrade to the latest stable release but I can't seem
> to get to the publishers. I was set to the bloody publisher for a
> while and have not done updates so switched back to release:
>
> ~# pkg unset-publisher omnios
> ~# pkg set-publisher -g http://pkg.omniti.com/omnios/release omnios
> pkg set-publisher: The origin URIs for 'omnios' do not appear to point
> to a valid pkg repository.
> Please verify the repository's location and the client's network
> configuration.
> Additional details:
>
> Unable to contact valid package repository
> Encountered the following error(s):
> Unable to contact any configured publishers.
> This is likely a network configuration problem.
> 1: Framework error: code: 28 reason: Connection timed out after 60000
> milliseconds
> URL: 'http://pkg.omniti.com/omniti-perl'. (happened 4 times)
> 2: Framework error: code: 28 reason: Connection timed out after 60000
> milliseconds
> URL: 'http://pkg.omniti.com/omniti-ms'. (happened 4 times)
> 3: Framework error: code: 28 reason: Connection timed out after 60000
> milliseconds
> URL: 'http://pkg.omniti.com/omnios/release'. (happened 4 times)
>
>
> ~# cat /etc/release
>   OmniOS v11 r151007
>   Copyright 2013 OmniTI Computer Consulting, Inc. All rights reserved.
>   Use is subject to license terms.
>
> Internet connection confirmation:
> ~# curl google.com
> <HTML><HEAD><meta http-equiv="content-type"
> content="text/html;charset=utf-8">
> <TITLE>301 Moved</TITLE></HEAD><BODY>
> <H1>301 Moved</H1>
> The document has moved
> <A HREF="http://www.google.com/">here</A>.
> </BODY></HTML>
>
>
> Any ideas?
>
> Thanks,
> Georgi
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBAgAGBQJS0ZbSAAoJEAzuUQIrkZXu/KwQAMkaxfKqMBxgDZ3VvyYNxlg5
> wWpGcdDfd6XgeClMOsK3eBf29bhvALerZEQ3Dy6YySGCL4yHGz5nz+UpVbi2qBbZ
> 9KjOFL5mMB4B+QleaA95YKS71dxR8JF5QF6H3XEFYBiJlK3VWX5Y18PHGgaIImdv
> lHFKyF/k9niU7QthSDotOOCNYmItFwzxxop/bv9cJZyJmJsgg5KIZNj0wicFTFqw
> EpLU1/hIa+WUZB+u7Mbv7MhGjQkwIpRu4yKlGUNCzq5lXeEKTTa1yRMiMrnCf+t3
> 0oTe8ZnkGvAb9XiWQ36OaECSXiALzsolsi0DKlshW0f2BKvGRPDlB0z7S5VouQyN
> 7owTaW7SAkaIMq79hSzMKjLIQI1SEr8o4Eq7iUqpW68wSVlGg6lZDJfYj9rIIPUv
> aaOEvfMDV6r6dD6nLpxRtNdx9fiQv1yfyx+1M5ZOHtswt4MARVat1eC4PrbHT4rS
> Q6hZktevSpDPcWGTK9nL+Xo+DV0aKEQJhFs5deuwuh45ZY8ugwe237GeF7EDewNC
> uwwV2rMYoIR2skXyVjhLNUw8ZEnv8fyM83y0wK89+BBUVOA5ozfSS2XKk7Kjn7p2
> /ncL0942yzdx0IPojSBWDBAG9eFlwvbypu8V5ns5ANPMSu9e7yp/TEJ0dFMqV8Z9
> 3WNgmQuLP7YhYymP9Fxb
> =I9l9
> -----END PGP SIGNATURE-----
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Mark Harrison
Lead Site Reliability Engineer
OmniTI

From terahz at geodar.com  Sun Jan 12 06:20:08 2014
From: terahz at geodar.com (Georgi Todorov)
Date: Sun, 12 Jan 2014 01:20:08 -0500
Subject: [OmniOS-discuss] Publishers down?
In-Reply-To: <CABC3qWcf1VE4MQh0u_YNCqoAnAHQ7T1Ssr+Wh9jb8Hnq_et_Uw@mail.gmail.com>
References: <52D196D3.2010708@geodar.com>
	<CABC3qWcf1VE4MQh0u_YNCqoAnAHQ7T1Ssr+Wh9jb8Hnq_et_Uw@mail.gmail.com>
Message-ID: <52D23418.40900@geodar.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/11/14 7:02 PM, Mark Harrison wrote:
> What does pkg.omniti.com resolve to for you? A little while ago the
> IP address changed and it's possible you're still trying to connect
> to the old server. The correct IP is 199.15.226.221.

That was it, thanks!

> pkg.omniti.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   pkg.omniti.com
Address: 66.225.209.50
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> pkg.omniti.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   pkg.omniti.com
Address: 199.15.226.221


Georgi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJS0jQXAAoJEAzuUQIrkZXuU7oQAOXQy9nFjwfeKhKZ2s1rTy/7
VoCwbfaBn8kKODkOhpy8m+lrOf4yis4tG9NPKSNsOJxqtV75KyWPX8DggJVmwDBF
b0k0rJHWSk2RxGzORLWRwcR512mfgbbJc3L9mwgkKlCDaCc6N/ZkzzsjW6/0Tm2a
/182+FntfWosAYobs0omYFBq8d3iJm4eat2miI7/nhmUamtS/R1UOv9AOSWjX362
dNq4aGedk7PiVmfhq4lgWzXzgluVZ/CG+hpZtyXdcH/I7H9sG18LLV02R0+XviwA
91tdd3p6wcj7VFaILsEAJ1VNzt/8uZ0uNw2dON8ftOWwhJxH4T5oOF0JnXpsJQ3I
cm/j5oB6DBXlFZ+B0lpn16madY/Wlq0a8Tw8YVpEtdSI2Zt8nKRe+5R5A9VJK4mV
lfZ6Q3tTUO7JO38qLXU+TZKwsUqsWYPsHQ2kask0PJGh2kETmL1UE2FZ64iW5b7F
RfwtnnOlf3qoAOrDInSrqdjSPFY7eLJynbPO2utDNL4nPF68uxAqkVLV/37o+EbT
Yvz+ZNV1YlzUk8AZY3/c+thtQdi77EwwGRYUwMzgCsGmcGa2VYpsVI7n0HtqFGHn
h1ZdaEgoa06MSIz19LPOKPO9diqVztVNPUeqtqTX8gzKpy+rthVBmylX8fA9w0NS
vjdfzq87RKaxfOw1z6lE
=3BVA
-----END PGP SIGNATURE-----

From svavar at fiton.is  Sun Jan 12 14:46:53 2014
From: svavar at fiton.is (=?iso-8859-1?Q?Svavar_=D6rn_Eysteinsson?=)
Date: Sun, 12 Jan 2014 14:46:53 +0000
Subject: [OmniOS-discuss] Not a UFS magic Number... Boot OmniOS installation
	on new Supermicro X10SAE
Message-ID: <81DE9068-F8D0-4A78-ADD0-B0EB8EA19C0F@fiton.is>

Hello.

I'm currently trying to install OmniOS on a brand new server.
Using the latest OmniOS build on USB stick with a SuperMicro X10SAE motherboard, and a XEON CPU.

When I have no SATA disk connected to the Intel SATA controller the installation boots up fine.

As soon as I plug a disk into the controller, it gives me the following errors at boot :


Probing for device nodes?
Preparing image for use
NOTICE : mount: not a UFS magic number (0x1c798c2e)
NOTICE : mount: not a UFS magic number (0x1c798c2e)
NOTICE : mount: not a UFS magic number (0x0)
NOTICE : mount: not a UFS magic number (0x1c798c2e)
Requesting System Maintenance Mode
Console login services cannot run.

Enter username for system maintenance?.


My SATA disk is empty.

Does anyone know what the hell is going on ?
Are there any BOOT options on OmniOS installation? Can't find any information regarding boot options.

Any help would be much appreciated.

Thanks allot people.

Best regards,

Svavar 
Reykjavik - Iceland




From skiselkov.ml at gmail.com  Sun Jan 12 14:54:03 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Sun, 12 Jan 2014 14:54:03 +0000
Subject: [OmniOS-discuss] Not a UFS magic Number... Boot OmniOS
 installation on new Supermicro X10SAE
In-Reply-To: <81DE9068-F8D0-4A78-ADD0-B0EB8EA19C0F@fiton.is>
References: <81DE9068-F8D0-4A78-ADD0-B0EB8EA19C0F@fiton.is>
Message-ID: <52D2AC8B.4060700@gmail.com>

On 1/12/14, 2:46 PM, Svavar ?rn Eysteinsson wrote:
> Hello.
> 
> I'm currently trying to install OmniOS on a brand new server.
> Using the latest OmniOS build on USB stick with a SuperMicro X10SAE motherboard, and a XEON CPU.
> 
> When I have no SATA disk connected to the Intel SATA controller the installation boots up fine.
> 
> As soon as I plug a disk into the controller, it gives me the following errors at boot :
> 
> 
> Probing for device nodes?
> Preparing image for use
> NOTICE : mount: not a UFS magic number (0x1c798c2e)
> NOTICE : mount: not a UFS magic number (0x1c798c2e)
> NOTICE : mount: not a UFS magic number (0x0)
> NOTICE : mount: not a UFS magic number (0x1c798c2e)
> Requesting System Maintenance Mode
> Console login services cannot run.
> 
> Enter username for system maintenance?.
> 
> 
> My SATA disk is empty.
> 
> Does anyone know what the hell is going on ?
> Are there any BOOT options on OmniOS installation? Can't find any information regarding boot options.
> 
> Any help would be much appreciated.
> 
> Thanks allot people.

Can you try dd'ing over the disk with zeros and trying again?

-- 
Saso


From svavar at fiton.is  Sun Jan 12 15:03:25 2014
From: svavar at fiton.is (=?iso-8859-1?Q?Svavar_=D6rn_Eysteinsson?=)
Date: Sun, 12 Jan 2014 15:03:25 +0000
Subject: [OmniOS-discuss] Not a UFS magic Number... Boot OmniOS
	installation on new Supermicro X10SAE
In-Reply-To: <52D2AC8B.4060700@gmail.com>
References: <81DE9068-F8D0-4A78-ADD0-B0EB8EA19C0F@fiton.is>
	<52D2AC8B.4060700@gmail.com>
Message-ID: <6284EAE6-BF4A-4311-A153-2B441F75F199@fiton.is>

Well, I've changed the disk from a brand new one, just opened it up from a static bag
inserted it, and the exact same error messages?. 

:S

so two disks, no boot?.







On 12.1.2014, at 14:54, Saso Kiselkov wrote:

> On 1/12/14, 2:46 PM, Svavar ?rn Eysteinsson wrote:
>> Hello.
>> 
>> I'm currently trying to install OmniOS on a brand new server.
>> Using the latest OmniOS build on USB stick with a SuperMicro X10SAE motherboard, and a XEON CPU.
>> 
>> When I have no SATA disk connected to the Intel SATA controller the installation boots up fine.
>> 
>> As soon as I plug a disk into the controller, it gives me the following errors at boot :
>> 
>> 
>> Probing for device nodes?
>> Preparing image for use
>> NOTICE : mount: not a UFS magic number (0x1c798c2e)
>> NOTICE : mount: not a UFS magic number (0x1c798c2e)
>> NOTICE : mount: not a UFS magic number (0x0)
>> NOTICE : mount: not a UFS magic number (0x1c798c2e)
>> Requesting System Maintenance Mode
>> Console login services cannot run.
>> 
>> Enter username for system maintenance?.
>> 
>> 
>> My SATA disk is empty.
>> 
>> Does anyone know what the hell is going on ?
>> Are there any BOOT options on OmniOS installation? Can't find any information regarding boot options.
>> 
>> Any help would be much appreciated.
>> 
>> Thanks allot people.
> 
> Can you try dd'ing over the disk with zeros and trying again?
> 
> -- 
> 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  Sun Jan 12 15:05:16 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Sun, 12 Jan 2014 15:05:16 +0000
Subject: [OmniOS-discuss] Not a UFS magic Number... Boot OmniOS
 installation on new Supermicro X10SAE
In-Reply-To: <6284EAE6-BF4A-4311-A153-2B441F75F199@fiton.is>
References: <81DE9068-F8D0-4A78-ADD0-B0EB8EA19C0F@fiton.is>
	<52D2AC8B.4060700@gmail.com>
	<6284EAE6-BF4A-4311-A153-2B441F75F199@fiton.is>
Message-ID: <52D2AF2C.4060400@gmail.com>

On 1/12/14, 3:03 PM, Svavar ?rn Eysteinsson wrote:
> Well, I've changed the disk from a brand new one, just opened it up from a static bag
> inserted it, and the exact same error messages?. 
> 
> :S
> 
> so two disks, no boot?.

It's not that I think that the disks would be bad, it's that maybe
there's something written on there that the kernel is misinterpreting as
being a UFS filesystem. If you zero out the initial portions of the
disk, then we know that there's just zeros there, and we will know to
look somewhere else.

-- 
Saso

From skiselkov.ml at gmail.com  Sun Jan 12 15:08:50 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Sun, 12 Jan 2014 15:08:50 +0000
Subject: [OmniOS-discuss] Not a UFS magic Number... Boot OmniOS
 installation on new Supermicro X10SAE
In-Reply-To: <6284EAE6-BF4A-4311-A153-2B441F75F199@fiton.is>
References: <81DE9068-F8D0-4A78-ADD0-B0EB8EA19C0F@fiton.is>
	<52D2AC8B.4060700@gmail.com>
	<6284EAE6-BF4A-4311-A153-2B441F75F199@fiton.is>
Message-ID: <52D2B002.3020506@gmail.com>

On 1/12/14, 3:03 PM, Svavar ?rn Eysteinsson wrote:
> Well, I've changed the disk from a brand new one, just opened it up from a static bag
> inserted it, and the exact same error messages?. 
> 
> :S
> 
> so two disks, no boot?.

Scrap what I said earlier. I think I understand what the problem is. The
mount scripts on the installer USB are confusing the USB disk with the
SATA drive and are trying to mount the SATA disk as the installer root.
This is obviously a bug in the install image, but you should be able to
work around it by booting from an ISO (that motherboard should have a
on-board IP KVM with media redirection, so you can use that if you don't
want to burn install media).

Cheers,
-- 
Saso

From terahz at geodar.com  Sun Jan 12 15:54:30 2014
From: terahz at geodar.com (Georgi Todorov)
Date: Sun, 12 Jan 2014 10:54:30 -0500
Subject: [OmniOS-discuss] pkg update
Message-ID: <52D2BAB6.2060800@geodar.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 11 Jan 2014 15:56:13 +0100
Michael Rasmussen <mir at miras.org> wrote:

> On Sat, 11 Jan 2014 09:47:31 -0500 Yuri Pismerov <ypismerov at
> gmail.com> wrote:
> 
>> 
>> As it says, it did not work. What are my options now?
>> 
> The least painful is to reinstall with 15008. 1) zpool export (all
> your pools except rpool) 2) install using a downloaded image of
> 15008 3) zpool import (all your pools except rpool)


I just hit the same problem after moving the the new release from bloody.

# pkg update -nv
Creating Plan \
pkg update: The certificate which issued this
certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151008
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/libtool/libltdl at 2.4.2,5.11-0.151008:20131204T024209Z


I can't afford to do a fresh reinstall. Can I put the required certs
in /etc/ssl/pkg and run pkg set-property trust-anchor-directory
etc/ssl/pkg?

If yes, where do I get the right CA from ?


What are the other options do I have?


Thanks!
Georgi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJS0rq2AAoJEAzuUQIrkZXuqLkP+wT8lwY20bDLUvPxatVm78go
Abn0OYHvh531lyS0XtGLccNRQXWNGTIqpXvh22S9C09J9VLPQyKrbxn6BJPFHvjn
nFJUZ4NbcaY+VwP7OH3dLnGPKR/DVJF1RO25D/PTf93LpTjyNCEKxLe+NBc68Yp1
jLxDDKmYYKeN7uQgGK5PLro4y6hwBxajwP+2gA9DLiWuyQ0yeram7G+ZtHeJhthy
OTvrsG27rmx3y3UsaILZ0ci1qq8fKfA8d+T3bQY+sURdeY5fNjoF8mKNlwub7vrO
dZ+io5PSVU43H7ymhGm/0o5glmKibZh8XJbIdSXVL7dz7L/0MQu09UdXlaP2IbNy
s5FyKJowsnYJ291mjsWSjmBtrwV6fEMWhVwv8GznqSj+Pb7ede4sFR/u3LzHe1iz
kOn+6QGGhZ1be9sXAfThAVe3hXZGGrMjl3D0aJ4GES6/I64/WYhBCa1TrSWSnWI/
I7arxw+pceLs28sUTAAE2hTUWETYquke6jiy5UMXeMSCOtLBvSa2aRHbXApRF88m
0W6YGQedhHjgh3vQ5nC1nQOppyP26maXwHOBkB/Yj6hpTfMq8xZlv5V6VOMgRVfC
ISHQKJYRtWhiEDQ4wVJWvTrJplHEZcjJjHnXVLz5O4PIq3PQ7ZH6JiEMVoAwMCOO
NFS9UyAnwccVzJjP5e/Y
=8YOW
-----END PGP SIGNATURE-----

From cj.keist at colostate.edu  Mon Jan 13 21:52:43 2014
From: cj.keist at colostate.edu (CJ Keist)
Date: Mon, 13 Jan 2014 14:52:43 -0700
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <20140111005645.7f9af583@sleipner.datanom.net>
References: <52D05EBB.8070802@colostate.edu>
	<20140111005645.7f9af583@sleipner.datanom.net>
Message-ID: <52D4602B.1030706@colostate.edu>

Thank you!  That did the trick.  Next issue I have run into is that I 
cannot get the OS to see the network. Followed the instructions here:

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

Everything went through as stated in the instructions.  My device is 
e1000g0, route was added and IP/netmask/broadcast are all correct. But 
no access to the network.

Any suggestions?



On 1/10/14, 4:56 PM, Michael Rasmussen wrote:
> On Fri, 10 Jan 2014 13:57:31 -0700
> CJ Keist <cj.keist at colostate.edu> wrote:
>
>>
>> Setup:
>> Memory: 4gb
>> Processors 4(1 socket, 4cores)[qemu64]
>> hard disk(ide0) format vmdk, cache=writethrough size=12gb
>> Network Device(net0) e1000 bridge=vmbr0
>>
> Omnios does not handle cores, only sockets. So do this instead:
> Processors 4(4 socket, 1cores)[qemu64]
>
> And for performance:
> hard disk(sata0) format qcow2, cache=none size=12gb
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

-- 
C. J. Keist                     Email: cj.keist at colostate.edu
Systems Group Manager           Solaris 10 OS (SAI)
Engineering Network Services    Phone: 970-491-0630
College of Engineering, CSU     Fax:   970-491-5569
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'

From mir at miras.org  Mon Jan 13 21:59:06 2014
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 13 Jan 2014 22:59:06 +0100
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <52D4602B.1030706@colostate.edu>
References: <52D05EBB.8070802@colostate.edu>
	<20140111005645.7f9af583@sleipner.datanom.net>
	<52D4602B.1030706@colostate.edu>
Message-ID: <20140113225906.4c40207b@sleipner.datanom.net>

On Mon, 13 Jan 2014 14:52:43 -0700
CJ Keist <cj.keist at colostate.edu> wrote:

> Everything went through as stated in the instructions.  My device is e1000g0, route was added and IP/netmask/broadcast are all correct. But no access to the network.
> 
> Any suggestions?
> 
what does netstat -rn show?

-- 
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:
Hors d'oeuvres -- a ham sandwich cut into forty pieces.
		-- Jack Benny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140113/d2321b83/attachment.bin>

From cj.keist at colostate.edu  Mon Jan 13 22:03:40 2014
From: cj.keist at colostate.edu (CJ Keist)
Date: Mon, 13 Jan 2014 15:03:40 -0700
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <20140113225906.4c40207b@sleipner.datanom.net>
References: <52D05EBB.8070802@colostate.edu>	<20140111005645.7f9af583@sleipner.datanom.net>	<52D4602B.1030706@colostate.edu>
	<20140113225906.4c40207b@sleipner.datanom.net>
Message-ID: <52D462BC.8060008@colostate.edu>

Excuse the pics, but don't have cut paste ability while working through 
the java console.  Here is all the network info I believe.



On 1/13/14, 2:59 PM, Michael Rasmussen wrote:
> On Mon, 13 Jan 2014 14:52:43 -0700
> CJ Keist <cj.keist at colostate.edu> wrote:
>
>> Everything went through as stated in the instructions.  My device is e1000g0, route was added and IP/netmask/broadcast are all correct. But no access to the network.
>>
>> Any suggestions?
>>
> what does netstat -rn show?
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

-- 
C. J. Keist                     Email: cj.keist at colostate.edu
Systems Group Manager           Solaris 10 OS (SAI)
Engineering Network Services    Phone: 970-491-0630
College of Engineering, CSU     Fax:   970-491-5569
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-01-13 at 3.01.12 PM.png
Type: image/png
Size: 22880 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140113/8031c7f3/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-01-13 at 3.02.26 PM.png
Type: image/png
Size: 25230 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140113/8031c7f3/attachment-0003.png>

From mir at miras.org  Mon Jan 13 22:45:43 2014
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 13 Jan 2014 23:45:43 +0100
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <52D462BC.8060008@colostate.edu>
References: <52D05EBB.8070802@colostate.edu>
	<20140111005645.7f9af583@sleipner.datanom.net>
	<52D4602B.1030706@colostate.edu>
	<20140113225906.4c40207b@sleipner.datanom.net>
	<52D462BC.8060008@colostate.edu>
Message-ID: <20140113234543.3c1d732b@sleipner.datanom.net>

On Mon, 13 Jan 2014 15:03:40 -0700
CJ Keist <cj.keist at colostate.edu> wrote:

> Excuse the pics, but don't have cut paste ability while working through the java console.  Here is all the network info I believe.
> 
I think you have entered wrong network data.
IP 129.82.20.15
GW 129.82.20.1
BA 129.82.23.255
NW 129.82.20.0 ???

Something does not compute here. You are sure your broadcast address
should not have been 129.82.20.255 instead of 129.82.23.255?

-- 
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:
Aliquid melius quam pessimum optimum non est.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140113/8f9ff29a/attachment.bin>

From cj.keist at colostate.edu  Mon Jan 13 23:02:19 2014
From: cj.keist at colostate.edu (CJ Keist)
Date: Mon, 13 Jan 2014 16:02:19 -0700
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <20140113234543.3c1d732b@sleipner.datanom.net>
References: <52D05EBB.8070802@colostate.edu>	<20140111005645.7f9af583@sleipner.datanom.net>	<52D4602B.1030706@colostate.edu>	<20140113225906.4c40207b@sleipner.datanom.net>	<52D462BC.8060008@colostate.edu>
	<20140113234543.3c1d732b@sleipner.datanom.net>
Message-ID: <52D4707B.5020003@colostate.edu>

Michael,
     Broadcast is set right (255.255.252.0) so 129.82.23.255 is correct 
for the broadcast.
The 129.82.20.0      129.82.20.15 in the route table is consistent with 
other Solaris servers I have on the network (non-virtual).


On 1/13/14, 3:45 PM, Michael Rasmussen wrote:
> On Mon, 13 Jan 2014 15:03:40 -0700
> CJ Keist <cj.keist at colostate.edu> wrote:
>
>> Excuse the pics, but don't have cut paste ability while working through the java console.  Here is all the network info I believe.
>>
> I think you have entered wrong network data.
> IP 129.82.20.15
> GW 129.82.20.1
> BA 129.82.23.255
> NW 129.82.20.0 ???
>
> Something does not compute here. You are sure your broadcast address
> should not have been 129.82.20.255 instead of 129.82.23.255?
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

-- 
C. J. Keist                     Email: cj.keist at colostate.edu
Systems Group Manager           Solaris 10 OS (SAI)
Engineering Network Services    Phone: 970-491-0630
College of Engineering, CSU     Fax:   970-491-5569
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'

From ikaufman at eng.ucsd.edu  Mon Jan 13 23:21:07 2014
From: ikaufman at eng.ucsd.edu (Ian Kaufman)
Date: Mon, 13 Jan 2014 15:21:07 -0800
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <52D4707B.5020003@colostate.edu>
References: <52D05EBB.8070802@colostate.edu>
	<20140111005645.7f9af583@sleipner.datanom.net>
	<52D4602B.1030706@colostate.edu>
	<20140113225906.4c40207b@sleipner.datanom.net>
	<52D462BC.8060008@colostate.edu>
	<20140113234543.3c1d732b@sleipner.datanom.net>
	<52D4707B.5020003@colostate.edu>
Message-ID: <CAPJtH1jXR+gJenOVBNp-CYixzk6wtb1xqRGSRkdbc4Yb02Vr3w@mail.gmail.com>

If the subnet mask is 255.255.252.0, the broadcast should be 129.82.31.255.

Ian

On Mon, Jan 13, 2014 at 3:02 PM, CJ Keist <cj.keist at colostate.edu> wrote:
> Michael,
>     Broadcast is set right (255.255.252.0) so 129.82.23.255 is correct for
> the broadcast.
> The 129.82.20.0      129.82.20.15 in the route table is consistent with
> other Solaris servers I have on the network (non-virtual).
>
>
>
> On 1/13/14, 3:45 PM, Michael Rasmussen wrote:
>>
>> On Mon, 13 Jan 2014 15:03:40 -0700
>> CJ Keist <cj.keist at colostate.edu> wrote:
>>
>>> Excuse the pics, but don't have cut paste ability while working through
>>> the java console.  Here is all the network info I believe.
>>>
>> I think you have entered wrong network data.
>> IP 129.82.20.15
>> GW 129.82.20.1
>> BA 129.82.23.255
>> NW 129.82.20.0 ???
>>
>> Something does not compute here. You are sure your broadcast address
>> should not have been 129.82.20.255 instead of 129.82.23.255?
>>
>>
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>
> --
> C. J. Keist                     Email: cj.keist at colostate.edu
> Systems Group Manager           Solaris 10 OS (SAI)
> Engineering Network Services    Phone: 970-491-0630
> College of Engineering, CSU     Fax:   970-491-5569
> Ft. Collins, CO 80523-1301
>
> All I want is a chance to prove 'Money can't buy happiness'
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu

From mir at miras.org  Mon Jan 13 23:22:59 2014
From: mir at miras.org (Michael Rasmussen)
Date: Tue, 14 Jan 2014 00:22:59 +0100
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <52D4707B.5020003@colostate.edu>
References: <52D05EBB.8070802@colostate.edu>
	<20140111005645.7f9af583@sleipner.datanom.net>
	<52D4602B.1030706@colostate.edu>
	<20140113225906.4c40207b@sleipner.datanom.net>
	<52D462BC.8060008@colostate.edu>
	<20140113234543.3c1d732b@sleipner.datanom.net>
	<52D4707B.5020003@colostate.edu>
Message-ID: <20140114002259.3b9c733a@sleipner.datanom.net>

On Mon, 13 Jan 2014 16:02:19 -0700
CJ Keist <cj.keist at colostate.edu> wrote:

> Michael,
>      Broadcast is set right (255.255.252.0) so 129.82.23.255 is correct for the broadcast.
> The 129.82.20.0      129.82.20.15 in the route table is consistent with other Solaris servers I have on the network (non-virtual).
> 
You have this network - 129.82.20.0/22 ?

It looks as no traffic is going through the default route. Is it a vlan
issue? How is your switch port configured?

-- 
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:
  Monotheism is a gift from the gods.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140114/44e9cf4d/attachment.bin>

From mir at miras.org  Mon Jan 13 23:33:36 2014
From: mir at miras.org (Michael Rasmussen)
Date: Tue, 14 Jan 2014 00:33:36 +0100
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <52D4707B.5020003@colostate.edu>
References: <52D05EBB.8070802@colostate.edu>
	<20140111005645.7f9af583@sleipner.datanom.net>
	<52D4602B.1030706@colostate.edu>
	<20140113225906.4c40207b@sleipner.datanom.net>
	<52D462BC.8060008@colostate.edu>
	<20140113234543.3c1d732b@sleipner.datanom.net>
	<52D4707B.5020003@colostate.edu>
Message-ID: <20140114003336.79ef8263@sleipner.datanom.net>

On Mon, 13 Jan 2014 16:02:19 -0700
CJ Keist <cj.keist at colostate.edu> wrote:

> Michael,
>      Broadcast is set right (255.255.252.0) so 129.82.23.255 is correct for the broadcast.
> The 129.82.20.0      129.82.20.15 in the route table is consistent with other Solaris servers I have on the network (non-virtual).
> 
Ahh, now I know want is wrong. You need to upgrade to latest proxmox
and choose OS Type 'Solaris'.

If this is not possible you will have to change cpu parameters in the
start script from -cpu qemu64,+x2apic to -cpu qemu64,-x2apic 

ps -ef |grep <your_omnios_server_name> on your proxmox host will show
you the complete opstart parameters which you can simply copy and paste
and remember to change the cpu parameters.

-- 
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:
Employees must wash hands before returning to work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140114/6706bc4b/attachment.bin>

From cj.keist at colostate.edu  Mon Jan 13 23:35:02 2014
From: cj.keist at colostate.edu (CJ Keist)
Date: Mon, 13 Jan 2014 16:35:02 -0700
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <CAPJtH1jXR+gJenOVBNp-CYixzk6wtb1xqRGSRkdbc4Yb02Vr3w@mail.gmail.com>
References: <52D05EBB.8070802@colostate.edu>	<20140111005645.7f9af583@sleipner.datanom.net>	<52D4602B.1030706@colostate.edu>	<20140113225906.4c40207b@sleipner.datanom.net>	<52D462BC.8060008@colostate.edu>	<20140113234543.3c1d732b@sleipner.datanom.net>	<52D4707B.5020003@colostate.edu>
	<CAPJtH1jXR+gJenOVBNp-CYixzk6wtb1xqRGSRkdbc4Yb02Vr3w@mail.gmail.com>
Message-ID: <52D47826.4010003@colostate.edu>

Nope,
    255.255.252.0/22 is 1022 host sub-net.



On 1/13/14, 4:21 PM, Ian Kaufman wrote:
> If the subnet mask is 255.255.252.0, the broadcast should be 129.82.31.255.
>
> Ian
>
> On Mon, Jan 13, 2014 at 3:02 PM, CJ Keist <cj.keist at colostate.edu> wrote:
>> Michael,
>>      Broadcast is set right (255.255.252.0) so 129.82.23.255 is correct for
>> the broadcast.
>> The 129.82.20.0      129.82.20.15 in the route table is consistent with
>> other Solaris servers I have on the network (non-virtual).
>>
>>
>>
>> On 1/13/14, 3:45 PM, Michael Rasmussen wrote:
>>>
>>> On Mon, 13 Jan 2014 15:03:40 -0700
>>> CJ Keist <cj.keist at colostate.edu> wrote:
>>>
>>>> Excuse the pics, but don't have cut paste ability while working through
>>>> the java console.  Here is all the network info I believe.
>>>>
>>> I think you have entered wrong network data.
>>> IP 129.82.20.15
>>> GW 129.82.20.1
>>> BA 129.82.23.255
>>> NW 129.82.20.0 ???
>>>
>>> Something does not compute here. You are sure your broadcast address
>>> should not have been 129.82.20.255 instead of 129.82.23.255?
>>>
>>>
>>>
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>>
>>
>> --
>> C. J. Keist                     Email: cj.keist at colostate.edu
>> Systems Group Manager           Solaris 10 OS (SAI)
>> Engineering Network Services    Phone: 970-491-0630
>> College of Engineering, CSU     Fax:   970-491-5569
>> Ft. Collins, CO 80523-1301
>>
>> All I want is a chance to prove 'Money can't buy happiness'
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>

-- 
C. J. Keist                     Email: cj.keist at colostate.edu
Systems Group Manager           Solaris 10 OS (SAI)
Engineering Network Services    Phone: 970-491-0630
College of Engineering, CSU     Fax:   970-491-5569
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'

From ikaufman at eng.ucsd.edu  Mon Jan 13 23:38:59 2014
From: ikaufman at eng.ucsd.edu (Ian Kaufman)
Date: Mon, 13 Jan 2014 15:38:59 -0800
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <52D47826.4010003@colostate.edu>
References: <52D05EBB.8070802@colostate.edu>
	<20140111005645.7f9af583@sleipner.datanom.net>
	<52D4602B.1030706@colostate.edu>
	<20140113225906.4c40207b@sleipner.datanom.net>
	<52D462BC.8060008@colostate.edu>
	<20140113234543.3c1d732b@sleipner.datanom.net>
	<52D4707B.5020003@colostate.edu>
	<CAPJtH1jXR+gJenOVBNp-CYixzk6wtb1xqRGSRkdbc4Yb02Vr3w@mail.gmail.com>
	<52D47826.4010003@colostate.edu>
Message-ID: <CAPJtH1itKO+4j7Zj6sdELSiGzLLARidA0eb75iKKjkE4YM_-5Q@mail.gmail.com>

Oops, yup, my bad. For some reason, I was using 129.82.29.15 as the host ...

Ian

On Mon, Jan 13, 2014 at 3:35 PM, CJ Keist <cj.keist at colostate.edu> wrote:
> Nope,
>    255.255.252.0/22 is 1022 host sub-net.
>
>
>
>
> On 1/13/14, 4:21 PM, Ian Kaufman wrote:
>>
>> If the subnet mask is 255.255.252.0, the broadcast should be
>> 129.82.31.255.
>>
>> Ian
>>
>> On Mon, Jan 13, 2014 at 3:02 PM, CJ Keist <cj.keist at colostate.edu> wrote:
>>>
>>> Michael,
>>>      Broadcast is set right (255.255.252.0) so 129.82.23.255 is correct
>>> for
>>> the broadcast.
>>> The 129.82.20.0      129.82.20.15 in the route table is consistent with
>>> other Solaris servers I have on the network (non-virtual).
>>>
>>>
>>>
>>> On 1/13/14, 3:45 PM, Michael Rasmussen wrote:
>>>>
>>>>
>>>> On Mon, 13 Jan 2014 15:03:40 -0700
>>>> CJ Keist <cj.keist at colostate.edu> wrote:
>>>>
>>>>> Excuse the pics, but don't have cut paste ability while working through
>>>>> the java console.  Here is all the network info I believe.
>>>>>
>>>> I think you have entered wrong network data.
>>>> IP 129.82.20.15
>>>> GW 129.82.20.1
>>>> BA 129.82.23.255
>>>> NW 129.82.20.0 ???
>>>>
>>>> Something does not compute here. You are sure your broadcast address
>>>> should not have been 129.82.20.255 instead of 129.82.23.255?
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OmniOS-discuss mailing list
>>>> OmniOS-discuss at lists.omniti.com
>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>>>
>>>
>>> --
>>> C. J. Keist                     Email: cj.keist at colostate.edu
>>> Systems Group Manager           Solaris 10 OS (SAI)
>>> Engineering Network Services    Phone: 970-491-0630
>>> College of Engineering, CSU     Fax:   970-491-5569
>>> Ft. Collins, CO 80523-1301
>>>
>>> All I want is a chance to prove 'Money can't buy happiness'
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>>
>>
>
> --
> C. J. Keist                     Email: cj.keist at colostate.edu
> Systems Group Manager           Solaris 10 OS (SAI)
> Engineering Network Services    Phone: 970-491-0630
> College of Engineering, CSU     Fax:   970-491-5569
> Ft. Collins, CO 80523-1301
>
> All I want is a chance to prove 'Money can't buy happiness'



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu

From mir at miras.org  Mon Jan 13 23:42:03 2014
From: mir at miras.org (Michael Rasmussen)
Date: Tue, 14 Jan 2014 00:42:03 +0100
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <CAPJtH1jXR+gJenOVBNp-CYixzk6wtb1xqRGSRkdbc4Yb02Vr3w@mail.gmail.com>
References: <52D05EBB.8070802@colostate.edu>
	<20140111005645.7f9af583@sleipner.datanom.net>
	<52D4602B.1030706@colostate.edu>
	<20140113225906.4c40207b@sleipner.datanom.net>
	<52D462BC.8060008@colostate.edu>
	<20140113234543.3c1d732b@sleipner.datanom.net>
	<52D4707B.5020003@colostate.edu>
	<CAPJtH1jXR+gJenOVBNp-CYixzk6wtb1xqRGSRkdbc4Yb02Vr3w@mail.gmail.com>
Message-ID: <20140114004203.3e6803fc@sleipner.datanom.net>

On Mon, 13 Jan 2014 15:21:07 -0800
Ian Kaufman <ikaufman at eng.ucsd.edu> wrote:

> If the subnet mask is 255.255.252.0, the broadcast should be 129.82.31.255.
> 
If it is CIDR notation 129.82.20.0/22 the broadcast is 129.82.23.255 as
stated.

-- 
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:
Anything is good if it's made of chocolate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140114/6de6bb6c/attachment.bin>

From ypismerov at gmail.com  Tue Jan 14 11:12:09 2014
From: ypismerov at gmail.com (Yuri Pismerov)
Date: Tue, 14 Jan 2014 06:12:09 -0500
Subject: [OmniOS-discuss] Time Machine volume via dns-ds
Message-ID: <BFC3207C-36B6-429C-912B-3E5F3A0F7458@gmail.com>


Hello everybody.

I?ve been trying to set up proper announcement of a Time Machine volume, but I failed so far.
Has anybody managed to do it? Could you provide an example of dns-ds commands?

TIA.


From bdha at mirrorshades.net  Tue Jan 14 12:10:32 2014
From: bdha at mirrorshades.net (Bryan Horstmann-Allen)
Date: Tue, 14 Jan 2014 07:10:32 -0500
Subject: [OmniOS-discuss] Zone "lost" its IP, was then bound to global zone
Message-ID: <20140114121032.GA28704@lab.pobox.com>

The global zone:

# grep network /etc/zones/icg_mx.xml
   <network address="a.b.c.96" physical="igb1"/>

igb1:16: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet a.b.c.96 netmask ffffff00 broadcast 208.72.237.255

Note the lack of a "zone: icg_mx" field in that alias output.

The zone:

# ifconfig -a
lo0:14: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
lo0:14: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
        inet6 ::1/128

Any connections to a.b.c.96 went to the global zone instead of the zone itself.

How I "fixed" it:

  # ifconfig igb1:16 down
  # ifconfig igb1:16 unplumb
  # zoneadm -z icg_mx reboot

In 7 years of heavy zone usage, I've never seen anything like this.

This caused about 11 hours of internal automated mail (systems, sev2
monitoring, cron, etc) -- thankfully just that -- to bounce, since it was all
going to the gz, instead of the zone.

To put it _very_ mildly, this is _really_ concerning.  No humans were logged
into the machine when this occurred. The config mgmt daemon was disabled. I'm
going by when mail stopped being accepts on the ngz; which was still running...
just missing its IP.

No useful logs to syslog, SMF, etc.

Has anyone run into this?
-- 
bdha
cyberpunk is dead. long live cyberpunk.

From smd at mis.use.net  Tue Jan 14 15:54:21 2014
From: smd at mis.use.net (Sean Doran)
Date: Tue, 14 Jan 2014 15:54:21 +0000
Subject: [OmniOS-discuss] kayak bugs, r151008j
Message-ID: <B3D7018D-8280-48F5-BC0F-C3790B76A5E8@mis.use.net>

Firstly, on:

http://omnios.omniti.com/wiki.php/Installation#Fromthenetwork

	? Current stable: http://omnios.omniti.com/media/r151008j.zfs.bz2
md5  (kayak_r151008j.zfs.bz2) = 1c0060a51004f486343e1bc43d637c2c
sha1 (kayak_r151008j.zfs.bz2) = ffef3d56815b20be215f0170cc98617fda6b9657

The URL is wrong (and produces a 404 error).  It should be ?http://omnios.omniti.com/media/kayak_r151008j.zfs.bz2?; the filenames in the grey checksum box are correct.

Secondly, the miniroot in pkg://omnios/system/install/kayak-kernel has a couple of problems.

	* curl fails because there is no /usr/lib/{32,64,amd64/libidn.so.11.6.11
	* curl also fails because there is  no /usr/lib/{32,64,amd64}/libz.so.1.2.8

Thirdly, the miniroot?s /kayak/disk_help.sh will bomb at line 124:

 log "Creating rpool with: zpool create -f rpool $ztype $ztgt"
 zpool create -f rpool $ztype $ztgt || bomb "Failed to create rpool?

because zpool create complains about not being able to share rpool in the absence of shareadm(1M).

Copying the missing shared libraries to the miniroot and working around the zpool exit status (all changes made via mount -o nologging `lofiadm -a miniroot` /mnt/t;  {cp ...,vi,?} /mnt/t/...), a kayak installation following the online docs appears to complete successfully.

	Sean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140114/920194d7/attachment.html>

From bdha at mirrorshades.net  Tue Jan 14 16:05:24 2014
From: bdha at mirrorshades.net (Bryan Horstmann-Allen)
Date: Tue, 14 Jan 2014 11:05:24 -0500
Subject: [OmniOS-discuss] Zone "lost" its IP,
	was then bound to global	zone
In-Reply-To: <20140114121032.GA28704@lab.pobox.com>
References: <20140114121032.GA28704@lab.pobox.com>
Message-ID: <20140114160524.GB15458@lab.pobox.com>

Further investigation when I wasn't covered in three small children wanting
breakfast definitely suggests this was operator error.

Sorry for the noise.
-- 
bdha
cyberpunk is dead. long live cyberpunk.

From smd at mis.use.net  Tue Jan 14 16:18:03 2014
From: smd at mis.use.net (Sean Doran)
Date: Tue, 14 Jan 2014 16:18:03 +0000
Subject: [OmniOS-discuss] zoneadm install on clean install vs on r151008
	with a bit of history
Message-ID: <B6203A9B-050A-4C57-8693-4B9CF15AEBB1@mis.use.net>

I can install (and detach, and export) a nonglobal zone on a completely new fresh install of r151008j.

The detached zone attaches and boots fine on my r151008j (and -f) systems which have been running for a couple of months and which started at 151006 and were likely munged in dealing with the -6 to -8 upgrade.

A zoneadm install on these running systems results in:

- ?

DOWNLOAD                                  PKGS       FILES    XFER (MB)
Completed                              375/375 33113/33113  252.3/252.3

PHASE                                        ACTIONS
Install Phase                            43997/54841Action install failed for 'usr/share/lib/nterm/tab.300s' (pkg://omnios/text/doctools):
  ActionExecutionError: Requested operation failed for package pkg://omnios/text/doctools at 0.5.11,5.11-0.151008:20131204T025157Z:
Unable to create hard link [path]/root/usr/share/lib/nterm/tab.300s; target [path]/root/usr/share/lib/nterm/tab.300S is missing.

pkg: Requested operation failed for package pkg://omnios/text/doctools at 0.5.11,5.11-0.151008:20131204T025157Z:
Unable to create hard link [path]/root/usr/share/lib/nterm/tab.300s; target [path]/samba/root/usr/share/lib/nterm/tab.300S is missing.

ERROR: failed to install package

- ?

I can?t figure out how to fix this, and would appreciate anyone?s advice, particularly to avoid future trouble.

	Sean.

P.S. that pkg supports $http_proxy is nice.  A http cache in front of several pkg installs says:

	Hits as % of all requests:	5min: 99.9%, 60min: 95.4%
        Hits as % of bytes sent:	5min: 100.0%, 60min: 89.8%

saving lots of time and on-the-wire traffic.   I did check that the cache is not a factor in the error.	

From cks at cs.toronto.edu  Tue Jan 14 22:02:11 2014
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Tue, 14 Jan 2014 17:02:11 -0500
Subject: [OmniOS-discuss] What are people using as a source of additional
	packages currently?
Message-ID: <20140114220211.78CB41A0D11@apps0.cs.toronto.edu>

 When I tested and experimented with OmniOS last year, I used pkgsrc.org
as a general source of additional packages. However it currently seems
to be fairly non-functional on OmniOS (or in general, eg its install
instructions point to things that don't exist right now).

 Is there some generally recommended alternative to pkgsrc, or is
the recommendation to build everything you want yourself?
(Possibly from the pkgsrc source base.)

	- cks

From lotheac at iki.fi  Wed Jan 15 12:30:26 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 15 Jan 2014 14:30:26 +0200
Subject: [OmniOS-discuss] kayak bugs, r151008j
In-Reply-To: <B3D7018D-8280-48F5-BC0F-C3790B76A5E8@mis.use.net>
References: <B3D7018D-8280-48F5-BC0F-C3790B76A5E8@mis.use.net>
Message-ID: <20140115123026.GA19170@gutsman.lotheac.fi>

On Tue, Jan 14 2014 15:54:21 +0000, Sean Doran wrote:
> Thirdly, the miniroot?s /kayak/disk_help.sh will bomb at line 124:
> 
>  log "Creating rpool with: zpool create -f rpool $ztype $ztgt"
>  zpool create -f rpool $ztype $ztgt || bomb "Failed to create rpool?
> 
> because zpool create complains about not being able to share rpool in the absence of shareadm(1M).

I'm currently building a kayak miniroot of my own due to needing to
include a non-redistributable NIC driver and also ran into this. The
root cause is that libshare needs libxml2, which is dropped from the
miniroot: in the kayak repo data/access.log includes a libxml2.so.2.9.0,
but the current version is libxml2.so.2.9.1 and that gets dropped. I
don't know how this 'access.log' was generated, but I'm thinking it
should be regenerated :)

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

From jesus at omniti.com  Wed Jan 15 14:24:48 2014
From: jesus at omniti.com (Theo Schlossnagle)
Date: Wed, 15 Jan 2014 09:24:48 -0500
Subject: [OmniOS-discuss] kayak bugs, r151008j
In-Reply-To: <20140115123026.GA19170@gutsman.lotheac.fi>
References: <B3D7018D-8280-48F5-BC0F-C3790B76A5E8@mis.use.net>
	<20140115123026.GA19170@gutsman.lotheac.fi>
Message-ID: <CACLsApuskhmXY1-55fwBP0OpmAiHYzo+H0uCMKUD00vnHy6n_A@mail.gmail.com>

patches welcome.

The access.log is generated via the anonymous dtrace
script: anon.dtrace.conf (check the makefile for more info).

The method isn't perfect, but it gets a ton of low hanging fruit.  Any
additional stuff can just be manually added to a data file (I'd suggest
data/known_extras).  The build_image.sh script just does:

load_keep_list data/*

to pull in a list of files to not delete from the miniroot.  Should be
simple enough to add in all the files that need to be there.  Also, someone
is welcome to try to run a new install with the anonymous dtrace function
and catch the access.log.  It's a bit more work, but it hasn't been done
since 151002.


On Wed, Jan 15, 2014 at 7:30 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:

> On Tue, Jan 14 2014 15:54:21 +0000, Sean Doran wrote:
> > Thirdly, the miniroot?s /kayak/disk_help.sh will bomb at line 124:
> >
> >  log "Creating rpool with: zpool create -f rpool $ztype $ztgt"
> >  zpool create -f rpool $ztype $ztgt || bomb "Failed to create rpool?
> >
> > because zpool create complains about not being able to share rpool in
> the absence of shareadm(1M).
>
> I'm currently building a kayak miniroot of my own due to needing to
> include a non-redistributable NIC driver and also ran into this. The
> root cause is that libshare needs libxml2, which is dropped from the
> miniroot: in the kayak repo data/access.log includes a libxml2.so.2.9.0,
> but the current version is libxml2.so.2.9.1 and that gets dropped. I
> don't know how this 'access.log' was generated, but I'm thinking it
> should be regenerated :)
>
> --
> Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet
> _______________________________________________
> 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: <https://omniosce.org/ml-archive/attachments/20140115/c5500af7/attachment-0001.html>

From cj.keist at colostate.edu  Wed Jan 15 17:47:11 2014
From: cj.keist at colostate.edu (CJ Keist)
Date: Wed, 15 Jan 2014 10:47:11 -0700
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <20140114003336.79ef8263@sleipner.datanom.net>
References: <52D05EBB.8070802@colostate.edu>	<20140111005645.7f9af583@sleipner.datanom.net>	<52D4602B.1030706@colostate.edu>	<20140113225906.4c40207b@sleipner.datanom.net>	<52D462BC.8060008@colostate.edu>	<20140113234543.3c1d732b@sleipner.datanom.net>	<52D4707B.5020003@colostate.edu>
	<20140114003336.79ef8263@sleipner.datanom.net>
Message-ID: <52D6C99F.2000809@colostate.edu>

Michael,
    Thank you very much! That was the issue. After upgrading my Proxmox 
  to the latest release network is working now.   It looks like the 
Solaris network issue started with the move from pve-manger 3.0 to 3.1.



On 1/13/14, 4:33 PM, Michael Rasmussen wrote:
> On Mon, 13 Jan 2014 16:02:19 -0700
> CJ Keist <cj.keist at colostate.edu> wrote:
>
>> Michael,
>>       Broadcast is set right (255.255.252.0) so 129.82.23.255 is correct for the broadcast.
>> The 129.82.20.0      129.82.20.15 in the route table is consistent with other Solaris servers I have on the network (non-virtual).
>>
> Ahh, now I know want is wrong. You need to upgrade to latest proxmox
> and choose OS Type 'Solaris'.
>
> If this is not possible you will have to change cpu parameters in the
> start script from -cpu qemu64,+x2apic to -cpu qemu64,-x2apic
>
> ps -ef |grep <your_omnios_server_name> on your proxmox host will show
> you the complete opstart parameters which you can simply copy and paste
> and remember to change the cpu parameters.
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

-- 
C. J. Keist                     Email: cj.keist at colostate.edu
Systems Group Manager           Solaris 10 OS (SAI)
Engineering Network Services    Phone: 970-491-0630
College of Engineering, CSU     Fax:   970-491-5569
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'

From mir at miras.org  Wed Jan 15 18:02:19 2014
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 15 Jan 2014 19:02:19 +0100
Subject: [OmniOS-discuss] Newbie to OmniOS
In-Reply-To: <52D6C99F.2000809@colostate.edu>
References: <52D05EBB.8070802@colostate.edu>
	<20140111005645.7f9af583@sleipner.datanom.net>
	<52D4602B.1030706@colostate.edu>
	<20140113225906.4c40207b@sleipner.datanom.net>
	<52D462BC.8060008@colostate.edu>
	<20140113234543.3c1d732b@sleipner.datanom.net>
	<52D4707B.5020003@colostate.edu>
	<20140114003336.79ef8263@sleipner.datanom.net>
	<52D6C99F.2000809@colostate.edu>
Message-ID: <20140115190219.79ba193c@sleipner.datanom.net>

On Wed, 15 Jan 2014 10:47:11 -0700
CJ Keist <cj.keist at colostate.edu> wrote:

> Michael,
>     Thank you very much! That was the issue. After upgrading my Proxmox   to the latest release network is working now.   It looks like the Solaris network issue started with the move from pve-manger 3.0 to 3.1.
> 
It was not the Proxmox version in itself it was the new version of KVM
and the prior used cpu options which in combination triggered a
regression. Whether Omnios/Illumos is to blame or it is KVM is
currently unknown. But as long as it works I am less tempted to pursue
an answer to the question;-)

-- 
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:
...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly).
		-- Matt Welsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140115/a70b877b/attachment.bin>

From ngoossens at gmail.com  Wed Jan 15 21:43:43 2014
From: ngoossens at gmail.com (Niels Goossens)
Date: Wed, 15 Jan 2014 22:43:43 +0100
Subject: [OmniOS-discuss] OmniOS random freezes
Message-ID: <CAGHroZCQ9zGW_8LhPM+utv0b-6TKsw5es7+YLOAY3sZhro0ZDQ@mail.gmail.com>

An update on the hangs that are occurring on my OmniOS install. First of
all, it takes up to a day for a hang to occur, so that explains why it took
some time for me to post this update..

First I removed the second ethernet card. This had no effect, the machine
still hangs.

After that I ran memtest+ for a few hours: no errors were found.

Finally, I filled the zpool with /dev/urandom generated files, then started
scrub. This resulted in a hang shortly after the scrub started! After a
reboot scrub does complete with no errors (scan: scrub repaired 24K in
2h36m with 0 errors).

Iostat -E shows illegal requests. I have a Supermicro (X9SCM-F) motherboard
with 6 sata ports, out of which 1 is used for the boot drive and the other
5 are used for a 5x1tb zfs1 pool. All show pretty much the same amount of
illegal requests:

# iostat -E | grep Illegal
Illegal Request: 54 Predictive Failure Analysis: 0
Illegal Request: 53 Predictive Failure Analysis: 0
Illegal Request: 53 Predictive Failure Analysis: 0
Illegal Request: 53 Predictive Failure Analysis: 0
Illegal Request: 53 Predictive Failure Analysis: 0
Illegal Request: 52 Predictive Failure Analysis: 0

This leads me to believe there is an issue with the onboard SATA controller
- before I started the scrub I had 5 illegal requests... I also managed to
find something remarkably similar on the SmartOS mailing list (
http://www.kdump.cn/forums/viewtopic.php?pid=3519).

These illegal requests started appearing recently, and the only thing I?ve
done is upgrade to OmniOS r151008 (from r151006). Now this could be pure
coincidence, so my next step is install r151006 and just test, I guess.

What would be the best way to downgrade from 151008 to 151006?

Niels Goossens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140115/e9f52b1e/attachment.html>

From mir at miras.org  Wed Jan 15 21:56:04 2014
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 15 Jan 2014 22:56:04 +0100
Subject: [OmniOS-discuss] OmniOS random freezes
In-Reply-To: <CAGHroZCQ9zGW_8LhPM+utv0b-6TKsw5es7+YLOAY3sZhro0ZDQ@mail.gmail.com>
References: <CAGHroZCQ9zGW_8LhPM+utv0b-6TKsw5es7+YLOAY3sZhro0ZDQ@mail.gmail.com>
Message-ID: <20140115225604.1ab487b0@sleipner.datanom.net>

On Wed, 15 Jan 2014 22:43:43 +0100
Niels Goossens <ngoossens at gmail.com> wrote:

> 
> What would be the best way to downgrade from 151008 to 151006?
> 
If you have updated your pool there is no turning back.

-- 
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:
I have yet to see any problem, however complicated, which, when
you looked at it in the right way, did not become still more
complicated. -- Poul Anderson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20140115/6eef1602/attachment.bin>

From ngoossens at gmail.com  Wed Jan 15 22:30:44 2014
From: ngoossens at gmail.com (Niels Goossens)
Date: Wed, 15 Jan 2014 23:30:44 +0100
Subject: [OmniOS-discuss] OmniOS random freezes
Message-ID: <CAGHroZDBoOXf5PB8GE+fAdTkUF5BMvkjBRK7ZRRMCTbV8y0Jdw@mail.gmail.com>

>* If you have updated your pool there is no turning back.*

I did not update the pool yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140115/c16d8061/attachment.html>

From esproul at omniti.com  Wed Jan 15 22:48:43 2014
From: esproul at omniti.com (Eric Sproul)
Date: Wed, 15 Jan 2014 17:48:43 -0500
Subject: [OmniOS-discuss] OmniOS random freezes
In-Reply-To: <CAGHroZDBoOXf5PB8GE+fAdTkUF5BMvkjBRK7ZRRMCTbV8y0Jdw@mail.gmail.com>
References: <CAGHroZDBoOXf5PB8GE+fAdTkUF5BMvkjBRK7ZRRMCTbV8y0Jdw@mail.gmail.com>
Message-ID: <CA+QY2RTqzStbqJ=GHLRyPECB3zJti_VciYouKdbV3LXPAa-aPA@mail.gmail.com>

On Wed, Jan 15, 2014 at 5:30 PM, Niels Goossens <ngoossens at gmail.com> wrote:
>
>> If you have updated your pool there is no turning back.
>
> I did not update the pool yet.

If you upgraded from r151006, you should have a previous boot
environment to roll back to.  See beadm(1M).

From alka at hfg-gmuend.de  Wed Jan 15 23:26:55 2014
From: alka at hfg-gmuend.de (alka)
Date: Thu, 16 Jan 2014 00:26:55 +0100
Subject: [OmniOS-discuss] What are people using as a source of
	additional packages currently?
In-Reply-To: <20140114220211.78CB41A0D11@apps0.cs.toronto.edu>
References: <20140114220211.78CB41A0D11@apps0.cs.toronto.edu>
Message-ID: <A6B24923-A655-4991-BD33-8D80F7FA8A25@hfg-gmuend.de>

I use the pkgsrc repo from SmartOS as well as they are far
more complete and up to date than any OmniOS repo  
and they work for OI as well. 

They are quite universal for Illumos based systems (mostly)
see http://www.napp-it.org/downloads/binaries_en.html

Gea
napp-it.org

Am 14.01.2014 um 23:02 schrieb Chris Siebenmann:

> When I tested and experimented with OmniOS last year, I used pkgsrc.org
> as a general source of additional packages. However it currently seems
> to be fairly non-functional on OmniOS (or in general, eg its install
> instructions point to things that don't exist right now).
> 
> Is there some generally recommended alternative to pkgsrc, or is
> the recommendation to build everything you want yourself?
> (Possibly from the pkgsrc source base.)
> 
> 	- cks
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

--



From ngoossens at gmail.com  Thu Jan 16 22:02:13 2014
From: ngoossens at gmail.com (Niels Goossens)
Date: Thu, 16 Jan 2014 23:02:13 +0100
Subject: [OmniOS-discuss] OmniOS random freezes
Message-ID: <CAGHroZAoPi2i5ZeE6W63=XKJU-LNwW_yK84A68w1pye_w0u5+g@mail.gmail.com>

Today I used beadm to boot 151006, scrubbed the pool, started a few VMs..
The machine has just locked itself up again, after just a few hours of
uptime. After scrubbing I immediately saw Illegal requests with iostat,
just like when I was running 151008.

I'm starting to run out of options...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140116/8ce9bcf1/attachment-0001.html>

From dseira at stackscale.com  Fri Jan 17 13:13:30 2014
From: dseira at stackscale.com (David Seira)
Date: Fri, 17 Jan 2014 14:13:30 +0100
Subject: [OmniOS-discuss] Dell poweredge
Message-ID: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>

Hi list,

I'm trying to install OmniOS on a Dell PowerEdge C6220 but once I select
the omniOS option in the grub, then it loads the drivers and suddenly
stops. It seems that there are any problem with any driver. I've tried this
with the iso image and also through the pxe without any succeed.

Anyone has installed OmniOS on this server?

Thanks.

--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140117/1f75afd6/attachment.html>

From frederic.alix at fredalix.com  Fri Jan 17 13:22:32 2014
From: frederic.alix at fredalix.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Alix?=)
Date: Fri, 17 Jan 2014 14:22:32 +0100
Subject: [OmniOS-discuss] Dell poweredge
In-Reply-To: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>
References: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>
Message-ID: <CAN4tE3_Xh5cq_yGA+YwsoVhAqaL-6hkLHrAkqOxV+-b0fHcnbA@mail.gmail.com>

Hi,

What is your RAID controller ? H710 or H810 ?


2014/1/17 David Seira <dseira at stackscale.com>

> Hi list,
>
> I'm trying to install OmniOS on a Dell PowerEdge C6220 but once I select
> the omniOS option in the grub, then it loads the drivers and suddenly
> stops. It seems that there are any problem with any driver. I've tried this
> with the iso image and also through the pxe without any succeed.
>
> Anyone has installed OmniOS on this server?
>
> 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: <https://omniosce.org/ml-archive/attachments/20140117/0c055d3e/attachment.html>

From dseira at stackscale.com  Fri Jan 17 13:28:45 2014
From: dseira at stackscale.com (David Seira)
Date: Fri, 17 Jan 2014 14:28:45 +0100
Subject: [OmniOS-discuss] Dell poweredge
In-Reply-To: <CAN4tE3_Xh5cq_yGA+YwsoVhAqaL-6hkLHrAkqOxV+-b0fHcnbA@mail.gmail.com>
References: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>
	<CAN4tE3_Xh5cq_yGA+YwsoVhAqaL-6hkLHrAkqOxV+-b0fHcnbA@mail.gmail.com>
Message-ID: <CAMGVNzOYQR=kmx6vYNsFTouS3pXcGV2F=Qc2xd24TbdSJ6LAPg@mail.gmail.com>

Hi Fr?d?ric,

I'm not sure but for testing purpose there is only one 1TB disk without
RAID.

Regards,
David


2014/1/17 Fr?d?ric Alix <frederic.alix at fredalix.com>

> Hi,
>
> What is your RAID controller ? H710 or H810 ?
>
>
> 2014/1/17 David Seira <dseira at stackscale.com>
>
>>  Hi list,
>>
>> I'm trying to install OmniOS on a Dell PowerEdge C6220 but once I select
>> the omniOS option in the grub, then it loads the drivers and suddenly
>> stops. It seems that there are any problem with any driver. I've tried this
>> with the iso image and also through the pxe without any succeed.
>>
>> Anyone has installed OmniOS on this server?
>>
>> Thanks.
>>
>> --
>>
>>
>> _______________________________________________
>> 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: <https://omniosce.org/ml-archive/attachments/20140117/ee72833b/attachment.html>

From frederic.alix at fredalix.com  Fri Jan 17 13:36:28 2014
From: frederic.alix at fredalix.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Alix?=)
Date: Fri, 17 Jan 2014 14:36:28 +0100
Subject: [OmniOS-discuss] Dell poweredge
In-Reply-To: <CAMGVNzOYQR=kmx6vYNsFTouS3pXcGV2F=Qc2xd24TbdSJ6LAPg@mail.gmail.com>
References: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>
	<CAN4tE3_Xh5cq_yGA+YwsoVhAqaL-6hkLHrAkqOxV+-b0fHcnbA@mail.gmail.com>
	<CAMGVNzOYQR=kmx6vYNsFTouS3pXcGV2F=Qc2xd24TbdSJ6LAPg@mail.gmail.com>
Message-ID: <CAN4tE39_nmW8MX2sETuw16WSTf_Lg1ePLizJDApUipfX9cKRTg@mail.gmail.com>

Ok no raid, but your hd, where is it connected ?
On a PCI card controller ? What is the model ?

Did you try to boot in verbose mode for show more informations ?


2014/1/17 David Seira <dseira at stackscale.com>

> Hi Fr?d?ric,
>
> I'm not sure but for testing purpose there is only one 1TB disk without
> RAID.
>
> Regards,
> David
>
>
> 2014/1/17 Fr?d?ric Alix <frederic.alix at fredalix.com>
>
>> Hi,
>>
>> What is your RAID controller ? H710 or H810 ?
>>
>>
>> 2014/1/17 David Seira <dseira at stackscale.com>
>>
>>>  Hi list,
>>>
>>> I'm trying to install OmniOS on a Dell PowerEdge C6220 but once I select
>>> the omniOS option in the grub, then it loads the drivers and suddenly
>>> stops. It seems that there are any problem with any driver. I've tried this
>>> with the iso image and also through the pxe without any succeed.
>>>
>>> Anyone has installed OmniOS on this server?
>>>
>>> Thanks.
>>>
>>> --
>>>
>>>
>>> _______________________________________________
>>> 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: <https://omniosce.org/ml-archive/attachments/20140117/e00c3a27/attachment.html>

From dseira at stackscale.com  Fri Jan 17 13:55:42 2014
From: dseira at stackscale.com (David Seira)
Date: Fri, 17 Jan 2014 14:55:42 +0100
Subject: [OmniOS-discuss] Dell poweredge
In-Reply-To: <CAN4tE39_nmW8MX2sETuw16WSTf_Lg1ePLizJDApUipfX9cKRTg@mail.gmail.com>
References: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>
	<CAN4tE3_Xh5cq_yGA+YwsoVhAqaL-6hkLHrAkqOxV+-b0fHcnbA@mail.gmail.com>
	<CAMGVNzOYQR=kmx6vYNsFTouS3pXcGV2F=Qc2xd24TbdSJ6LAPg@mail.gmail.com>
	<CAN4tE39_nmW8MX2sETuw16WSTf_Lg1ePLizJDApUipfX9cKRTg@mail.gmail.com>
Message-ID: <CAMGVNzO37bAjJLrPmB5yUwhnPrCi=XEisfp_VgmOAk-_JgOL2Q@mail.gmail.com>

I don't remember the model of the pci, I have to look for it. The hard
drive model is ST1000NM0033-9ZM173.

Meanwhile, I've put the boot in verbose mode and the boot stops at the
following line:

pcieb6 is /pci at 7a,0/pci8086,3c06 at 2,2



2014/1/17 Fr?d?ric Alix <frederic.alix at fredalix.com>

> Ok no raid, but your hd, where is it connected ?
> On a PCI card controller ? What is the model ?
>
> Did you try to boot in verbose mode for show more informations ?
>
>
> 2014/1/17 David Seira <dseira at stackscale.com>
>
>> Hi Fr?d?ric,
>>
>> I'm not sure but for testing purpose there is only one 1TB disk without
>> RAID.
>>
>> Regards,
>> David
>>
>>
>> 2014/1/17 Fr?d?ric Alix <frederic.alix at fredalix.com>
>>
>>> Hi,
>>>
>>> What is your RAID controller ? H710 or H810 ?
>>>
>>>
>>> 2014/1/17 David Seira <dseira at stackscale.com>
>>>
>>>>  Hi list,
>>>>
>>>> I'm trying to install OmniOS on a Dell PowerEdge C6220 but once I
>>>> select the omniOS option in the grub, then it loads the drivers and
>>>> suddenly stops. It seems that there are any problem with any driver. I've
>>>> tried this with the iso image and also through the pxe without any succeed.
>>>>
>>>> Anyone has installed OmniOS on this server?
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>>
>>>>
>>>> _______________________________________________
>>>> 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: <https://omniosce.org/ml-archive/attachments/20140117/c4706904/attachment-0001.html>

From danmcd at omniti.com  Fri Jan 17 15:40:33 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 17 Jan 2014 10:40:33 -0500
Subject: [OmniOS-discuss] Dell poweredge
In-Reply-To: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>
References: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>
Message-ID: <09819B90-104B-4616-8672-DAFE7A119BF1@omniti.com>


On Jan 17, 2014, at 8:13 AM, David Seira <dseira at stackscale.com> wrote:

> Hi list,
> 
> I'm trying to install OmniOS on a Dell PowerEdge C6220 but once I select the omniOS option in the grub, then it loads the drivers and suddenly stops. It seems that there are any problem with any driver. I've tried this with the iso image and also through the pxe without any succeed.
> 
> Anyone has installed OmniOS on this server?

Not OmniOS -> but I did install NexentaStor on a C6220 back in the old job.  This was for Dell themselves, and they had it configured per Nexenta's specs.

Fr?d?ric asked you which disk controller you were running.  Luckily, you supplied the disk model, and ST1000NM0033-9ZM173 is a SATA disk, so you're LIKELY using the on-motherboard SATA controller (hopefully under AHCI and not SCU -- these are BIOS options, I think).

You should, however, look and see if you're running one of the optional RAID controllers.  Do you get any "LSI MegaRAID" text from the BIOS at boot time?  Also, what other text was shown (i.e. not just the last line) before it froze?

Dan


From j.david.lists at gmail.com  Sun Jan 19 01:52:06 2014
From: j.david.lists at gmail.com (J David)
Date: Sat, 18 Jan 2014 20:52:06 -0500
Subject: [OmniOS-discuss] Running OmniOS under KVM
Message-ID: <CABXB=RQSSO+LVdtGTarAeeqfHxd_g6xBCGgMoXtJgKohFxCdVw@mail.gmail.com>

Hello all,

While attempting to try out OmniOS as a KVM guest (on a Debian host),
I've run into a weird snag.  Unfortunately my Solaris experience dates
back to when it came from a company called Sun so I'm kind of at a
loss.

It seems that there is some problem with the KVM VGA console.  Most
alphanumeric keys work fine but navigation keys, like the arrows keys
or backspace, appear to auto-repeat so that e.g. one press of
backspace will delete the entire line, and one press of left or right
arrow will go all the way to the beginning or end of the line,
respectively.  This is true both before and after installation.

There are a couple of different approaches that would solve this.  One
would be to figure out how to fix this problem.  The other would be to
find a way to install OmniOS from the ISO image using a serial
console, which is a lot easier for us to work with anyway.

This was all using the latest stable release ISO (r151008j), but when
I last tried it a few months ago, it was the same.

Thanks for any advice!

From tobi at oetiker.ch  Sun Jan 19 16:26:12 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Sun, 19 Jan 2014 17:26:12 +0100 (CET)
Subject: [OmniOS-discuss] igb0 'hangs'
Message-ID: <alpine.DEB.2.02.1401191710520.4208@froburg.oetiker.ch>

I just had an odd thing happening to my r151008 server. It suddenly
stopped communicating over its igb0 interface ...

Upon further investigation I found:

a) several KVM guests talking over the same physical interface were
   still happily chatting

b) logging into the guests and trying to reach the server over that
   route did not work either.

c) accessing the server via the hardware console revealed that it
   was working and did not seem to realize that igb0 was having a
   problem. At least dmesg did not show anyithing interesting.

   once I did

   # ipadm down-addr igb0/v4static
   # ipadm up-addr igb0/v4static

   the interface started working again ...

any idea what has happened here ?

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 dswartz at druber.com  Sun Jan 19 21:58:17 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Sun, 19 Jan 2014 16:58:17 -0500
Subject: [OmniOS-discuss] Resilver speed and record size?
Message-ID: <c20050b8ab1a644ae0d6c6c80b5c1464.squirrel@webmail.druber.com>

I have a pool with 3x2 mirrors.  SAS nearline drives.  One of them died,
so I replaced it, and it resilvered overnight.  Another drive is showing
40 grown defects, so I am suspicious.  I want to replace it and reformat
it to see if any problems crop up.  So.  I plugged in a new drive and did
'zpool replace tank foo bar', and it's going along just fine.  Kinda slow
though, compared to scrub.  It started at about 5MB/sec and is now up to
13MB/sec, which is pretty slow.  I've been googling and find posts various
places that the resilver speed depends to some extent on record size
(apologies if I am mis-stating this.)  A good chunk of the data (180GB) is
in a zvol serving up storage to an esxi server for virtual machine disks
(zvol, so defaulting to 8K).  Probably twice this is in nfs-exported
shares for veeam backup (defaulting to 128K).  Originally everything was
nfs-shared, and I seem to recall resilvering being faster.  Am I out to
lunch here?  Any thoughts or suggestions as to what I should do ('nothing'
is a valid reply, of course) would be much appreciated.







From dseira at stackscale.com  Mon Jan 20 09:25:30 2014
From: dseira at stackscale.com (David Seira)
Date: Mon, 20 Jan 2014 10:25:30 +0100
Subject: [OmniOS-discuss] Dell poweredge
In-Reply-To: <09819B90-104B-4616-8672-DAFE7A119BF1@omniti.com>
References: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>
	<09819B90-104B-4616-8672-DAFE7A119BF1@omniti.com>
Message-ID: <CAMGVNzMj3NXB92pg=WRXJ+gELOA5dX=U5raMXaQ24qdZ7HQ6yg@mail.gmail.com>

Hi Dan,

Yes, the server uses the AHCI.

There aren't any message in the boot time, directly appears the PXE options.

The completely output is this:

module /platform/i86pc/kernel/amd64/unix: text at [0xfffffffffb800000,
0xfffffffffb94fbff] data at 0xfffffffffbc00000
module /kernel/amd64/genunix: text at [0xfffffffffb94fc00,
0xfffffffffbbd1ce7] data at 0xfffffffffbc95e80

x86_feature: lgpg
x86_feature: tsc
x86_feature: msr
x86_feature: mtrr
x86_feature: pge
x86_feature: de
x86_feature: cmov
x86_feature: mmx
x86_feature: mca
x86_feature: pae
x86_feature: cv8
x86_feature: pat
x86_feature: sep
x86_feature: sse
x86_feature: sse2
x86_feature: htt
x86_feature: asyc
x86_feature: nx
x86_feature: sse3
x86_feature: cx16
x86_feature: cmp
x86_feature: tscp
x86_feature: mwait
x86_feature: cpuid
x86_feature: ssse3
x86_feature: sse4_1
x86_feature: sse4_2
x86_feature: 1gpg
x86_feature: clfsh
x86_feature: 64
x86_feature: aes
x86_feature: pclmulqdq
x86_feature: xsave
x86_feature: avx
x86_feature: vmx
mem = 134167160K (0x1ffce9e000)
Using default device instance data
SMBIOS v2.7 loaded (8321 bytes) initialized model-specific module
'cpu_ms.GenuineIntel' on chip 0 core 0 strand 0
root nexus = i86pc
pseudo0 at root
pseudo0 is /pseudo
scsi_vhci0 at root
scsi_vhci0 is /scsi_vhci
Reading Intel IOMMU boot options
pseudo-device: acpippm0
acpippm0 is /pseudo/acpippm at 0
pseudo-device: ppm0
ppm0 is /pseudo/ppm at 0
ramdisk0 at root
ramdisk0 is /ramdisk
root on /ramdisk:a fstype ufs
acpinex0 at root
acpinex0 is /fw
acpinex: sb at 0, acpinex1
acpinex1 is /fw/sb at 0
acpinex: socket at 0, acpinex2
acpinex2 is /fw/sb at 0/socket at 0
pseudo-device: dld at 0
npe0 at root: space 0 offset 0
PCI Express-device: pci8086,1d10 at 1c, pcieb3
pcieb3 is /pci at 0,0/pci8086,1d10 at 1c
PCI Express-device: pci8086,244e at 1e, pci_pci0
pci_pci0 is /pci at 0,0/pci8086,244e at 1e
PCIE-device: pci1a03,1150 at 0, pcieb4
pcieb4 is /pci at 0,0/pci8086,1d10 at 1c/pci1a03,1150 at 0
npe2 at root: space 7a offset 0
npe2 is /pci at 7a,0
PCI Express-device: pci8086,3c06 at 2,2, pcieb6
pcieb6 isd /pci at 7a,0/pci8086,3c06 at 2,2


Best regards,
David



2014/1/17 Dan McDonald <danmcd at omniti.com>

>
> On Jan 17, 2014, at 8:13 AM, David Seira <dseira at stackscale.com> wrote:
>
> > Hi list,
> >
> > I'm trying to install OmniOS on a Dell PowerEdge C6220 but once I select
> the omniOS option in the grub, then it loads the drivers and suddenly
> stops. It seems that there are any problem with any driver. I've tried this
> with the iso image and also through the pxe without any succeed.
> >
> > Anyone has installed OmniOS on this server?
>
> Not OmniOS -> but I did install NexentaStor on a C6220 back in the old
> job.  This was for Dell themselves, and they had it configured per
> Nexenta's specs.
>
> Fr?d?ric asked you which disk controller you were running.  Luckily, you
> supplied the disk model, and ST1000NM0033-9ZM173 is a SATA disk, so you're
> LIKELY using the on-motherboard SATA controller (hopefully under AHCI and
> not SCU -- these are BIOS options, I think).
>
> You should, however, look and see if you're running one of the optional
> RAID controllers.  Do you get any "LSI MegaRAID" text from the BIOS at boot
> time?  Also, what other text was shown (i.e. not just the last line) before
> it froze?
>
> Dan
>
>


--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140120/416b4548/attachment.html>

From sk at kram.io  Mon Jan 20 10:13:33 2014
From: sk at kram.io (Steffen Kram)
Date: Mon, 20 Jan 2014 11:13:33 +0100
Subject: [OmniOS-discuss] igb0 'hangs'
In-Reply-To: <alpine.DEB.2.02.1401191710520.4208@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1401191710520.4208@froburg.oetiker.ch>
Message-ID: <9E8F3921-72F8-40A9-A441-87A0C11A6B76@kram.io>

Hi Tobi,

I had a similar problem a while ago, when I was resetting the maxbw property without taking the interface down. The global zone could not communicate over that interface anymore, while the zones where all happy. Taking the interface down and up again solved my issue, too.

Cheers,
Steffen

Am 19.01.2014 um 17:26 schrieb Tobias Oetiker <tobi at oetiker.ch>:

> I just had an odd thing happening to my r151008 server. It suddenly
> stopped communicating over its igb0 interface ...
> 
> Upon further investigation I found:
> 
> a) several KVM guests talking over the same physical interface were
>   still happily chatting
> 
> b) logging into the guests and trying to reach the server over that
>   route did not work either.
> 
> c) accessing the server via the hardware console revealed that it
>   was working and did not seem to realize that igb0 was having a
>   problem. At least dmesg did not show anyithing interesting.
> 
>   once I did
> 
>   # ipadm down-addr igb0/v4static
>   # ipadm up-addr igb0/v4static
> 
>   the interface started working again ...
> 
> any idea what has happened here ?
> 
> 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
> 

-------------- 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: <https://omniosce.org/ml-archive/attachments/20140120/a827ddc2/attachment.bin>

From martin at dojcak.sk  Mon Jan 20 12:56:35 2014
From: martin at dojcak.sk (Martin Dojcak)
Date: Mon, 20 Jan 2014 13:56:35 +0100
Subject: [OmniOS-discuss] OmniOS HBA Brocade 815 hardware compatibilty
Message-ID: <52DD1D03.2070702@dojcak.sk>

Hi all,

Does anyone have experience with Brocade 815, Single Port 8Gb Fibre
Channel HBA card (or brocade 8XX) under OmniOS or Illumos ? The HCL of
illumos does not contain a definition for brocade hardware. We want to
use (buy) this card with dell PowerEdge R420. Brocade has adapter driver
package for solaris 10 and 11 but at the moment we dont have brocade FC
card. So it is impossible to verify installation.

Thx

-- 
Martin Doj??k


From lotheac at iki.fi  Mon Jan 20 15:52:40 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Mon, 20 Jan 2014 17:52:40 +0200
Subject: [OmniOS-discuss] kayak bugs, r151008j
In-Reply-To: <CACLsApuskhmXY1-55fwBP0OpmAiHYzo+H0uCMKUD00vnHy6n_A@mail.gmail.com>
References: <B3D7018D-8280-48F5-BC0F-C3790B76A5E8@mis.use.net>
	<20140115123026.GA19170@gutsman.lotheac.fi>
	<CACLsApuskhmXY1-55fwBP0OpmAiHYzo+H0uCMKUD00vnHy6n_A@mail.gmail.com>
Message-ID: <20140120155240.GA1437@gutsman.lotheac.fi>

On Wed, Jan 15 2014 09:24:48 -0500, Theo Schlossnagle wrote:
> patches welcome.
> 
> The access.log is generated via the anonymous dtrace
> script: anon.dtrace.conf (check the makefile for more info).
>
> Also, someone is welcome to try to run a new install with the
> anonymous dtrace function and catch the access.log.  It's a bit more
> work, but it hasn't been done since 151002.

I gave this a shot using r151006, but I might be missing something since
the file grew quite a bit:

     data/access.log | 3869 +++++++++++++++++++++++++++++------------------
      1 file changed, 2421 insertions(+), 1448 deletions(-)

I just ran the installation with NO_REBOOT=1 and consumed the data with
dtrace -ae in a shell afterwards. The output format generated by dtrace
here also seems different from the existing access.log -- the former
includes a third field (fi_mount). Maybe the dtrace script should be
modified to generate matching output (and probably drop the stuff from
under /mnt)?

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

From lotheac at iki.fi  Mon Jan 20 15:58:53 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Mon, 20 Jan 2014 17:58:53 +0200
Subject: [OmniOS-discuss] kayak bugs, r151008j
In-Reply-To: <20140120155240.GA1437@gutsman.lotheac.fi>
References: <B3D7018D-8280-48F5-BC0F-C3790B76A5E8@mis.use.net>
	<20140115123026.GA19170@gutsman.lotheac.fi>
	<CACLsApuskhmXY1-55fwBP0OpmAiHYzo+H0uCMKUD00vnHy6n_A@mail.gmail.com>
	<20140120155240.GA1437@gutsman.lotheac.fi>
Message-ID: <20140120155853.GB1437@gutsman.lotheac.fi>

On Mon, Jan 20 2014 17:52:40 +0200, Lauri Tirkkonen wrote:
> On Wed, Jan 15 2014 09:24:48 -0500, Theo Schlossnagle wrote:
> > patches welcome.
> > 
> > The access.log is generated via the anonymous dtrace
> > script: anon.dtrace.conf (check the makefile for more info).
> >
> > Also, someone is welcome to try to run a new install with the
> > anonymous dtrace function and catch the access.log.  It's a bit more
> > work, but it hasn't been done since 151002.
> 
> I gave this a shot using r151006, but I might be missing something since
> the file grew quite a bit:
> 
>      data/access.log | 3869 +++++++++++++++++++++++++++++------------------
>       1 file changed, 2421 insertions(+), 1448 deletions(-)

Answering to myself - while I did check that /mnt did not account for
all of the additions I didn't consider other filesystems like /proc :)

    % grep -c ' /$' data/access.log
    1187

I will make a PR soonish but there probably needs to be separate
access.log files for different releases.

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

From danmcd at omniti.com  Mon Jan 20 16:03:30 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 20 Jan 2014 11:03:30 -0500
Subject: [OmniOS-discuss] OmniOS HBA Brocade 815 hardware compatibilty
In-Reply-To: <52DD1D03.2070702@dojcak.sk>
References: <52DD1D03.2070702@dojcak.sk>
Message-ID: <4204E868-DFE8-4697-B9F1-FC0FDB32A46E@omniti.com>


On Jan 20, 2014, at 7:56 AM, Martin Dojcak <martin at dojcak.sk> wrote:

> Hi all,
> 
> Does anyone have experience with Brocade 815, Single Port 8Gb Fibre
> Channel HBA card (or brocade 8XX) under OmniOS or Illumos ? The HCL of
> illumos does not contain a definition for brocade hardware. We want to
> use (buy) this card with dell PowerEdge R420. Brocade has adapter driver
> package for solaris 10 and 11 but at the moment we dont have brocade FC
> card. So it is impossible to verify installation.

It is possible the S11 binary will work with OmniOS, BUT it would be impossible for us (or any other Illumos vendor) to properly support it.

I just visited the Brocade adapter site, and it seems they've sold their adapter business to QLogic.  In the past (during the OpenSolaris days) QLogic had open-sourceable drivers.  Perhaps they can and will do the same.

Sorry I can't be of more immediate assistance,
Dan


From esproul at omniti.com  Mon Jan 20 16:14:34 2014
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 20 Jan 2014 11:14:34 -0500
Subject: [OmniOS-discuss] kayak bugs, r151008j
In-Reply-To: <20140120155853.GB1437@gutsman.lotheac.fi>
References: <B3D7018D-8280-48F5-BC0F-C3790B76A5E8@mis.use.net>
	<20140115123026.GA19170@gutsman.lotheac.fi>
	<CACLsApuskhmXY1-55fwBP0OpmAiHYzo+H0uCMKUD00vnHy6n_A@mail.gmail.com>
	<20140120155240.GA1437@gutsman.lotheac.fi>
	<20140120155853.GB1437@gutsman.lotheac.fi>
Message-ID: <CA+QY2RSWApg51-n4Zwv-oi8v=fN=P2u+mBjJpGEeNaeGYETQ+w@mail.gmail.com>

On Mon, Jan 20, 2014 at 10:58 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:
> I will make a PR soonish but there probably needs to be separate
> access.log files for different releases.

Thanks for the work Lauri.  In fact we should probably make
release-specific branches in Kayak the way we do for illumos-omnios
and omnios-build, as the files will necessarily be different as
versions change (perfect example: libxml2 2.9.0/2.9.1)

Once that is done, it'd be great to retrofit each branch (r151006,
r151008, master) with an update generated this way.

Eric

From martin at dojcak.sk  Mon Jan 20 16:57:28 2014
From: martin at dojcak.sk (Martin Dojcak)
Date: Mon, 20 Jan 2014 17:57:28 +0100
Subject: [OmniOS-discuss] OmniOS HBA Brocade 815 hardware compatibilty
In-Reply-To: <4204E868-DFE8-4697-B9F1-FC0FDB32A46E@omniti.com>
References: <52DD1D03.2070702@dojcak.sk>
	<4204E868-DFE8-4697-B9F1-FC0FDB32A46E@omniti.com>
Message-ID: <52DD5578.2040105@dojcak.sk>

Thanks Dan.

I recently read news ... and yes Brocade sells network adapter bis to
QLogic. There is another solution. Dell HW configurator (shop) offer
also other FC cards (which fit for our purpose):

1. QLogic:
QLogic (QLE)2560, Single Port 8Gb Optical Fibre Channel HBA
Qlogic is supported by illumos HCL (driver qlc, QLogic Corp.
ISP2532-based 8Gb Fibre Channel to PCI Express HBA). From QLE2560
datasheet card is based on controller ISP2532.

2. Emulex:
Emulex LPE 12000, Single Port 8Gb Fibre Channel HBA.
Emulex is also supported by HCL (driver emlxs, Emulex Corporation
Saturn-X: LightPulse Fibre Channel Host Adapter).

So I choose betweeen Qlogic or Emulex.


On 01/20/2014 05:03 PM, Dan McDonald wrote:
> 
> On Jan 20, 2014, at 7:56 AM, Martin Dojcak <martin at dojcak.sk> wrote:
> 
>> Hi all,
>>
>> Does anyone have experience with Brocade 815, Single Port 8Gb Fibre
>> Channel HBA card (or brocade 8XX) under OmniOS or Illumos ? The HCL of
>> illumos does not contain a definition for brocade hardware. We want to
>> use (buy) this card with dell PowerEdge R420. Brocade has adapter driver
>> package for solaris 10 and 11 but at the moment we dont have brocade FC
>> card. So it is impossible to verify installation.
> 
> It is possible the S11 binary will work with OmniOS, BUT it would be impossible for us (or any other Illumos vendor) to properly support it.
> 
> I just visited the Brocade adapter site, and it seems they've sold their adapter business to QLogic.  In the past (during the OpenSolaris days) QLogic had open-sourceable drivers.  Perhaps they can and will do the same.
> 
> Sorry I can't be of more immediate assistance,
> Dan
> 

-- 
Martin Doj??k


From smd at mis.use.net  Mon Jan 20 17:10:14 2014
From: smd at mis.use.net (Sean Doran)
Date: Mon, 20 Jan 2014 17:10:14 +0000
Subject: [OmniOS-discuss] kayak bugs, r151008j
In-Reply-To: <CA+QY2RSWApg51-n4Zwv-oi8v=fN=P2u+mBjJpGEeNaeGYETQ+w@mail.gmail.com>
References: <B3D7018D-8280-48F5-BC0F-C3790B76A5E8@mis.use.net>
	<20140115123026.GA19170@gutsman.lotheac.fi>
	<CACLsApuskhmXY1-55fwBP0OpmAiHYzo+H0uCMKUD00vnHy6n_A@mail.gmail.com>
	<20140120155240.GA1437@gutsman.lotheac.fi>
	<20140120155853.GB1437@gutsman.lotheac.fi>
	<CA+QY2RSWApg51-n4Zwv-oi8v=fN=P2u+mBjJpGEeNaeGYETQ+w@mail.gmail.com>
Message-ID: <33312BA8-F27D-46F6-834D-75EBBB333BFC@mis.use.net>


On 20 Jan, 2014, at 16:14, Eric Sproul <esproul at omniti.com> wrote:

> On Mon, Jan 20, 2014 at 10:58 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:
>> 
> Thanks for the work Lauri.  In fact we should probably make
> release-specific branches in Kayak the way we do for illumos-omnios
> and omnios-build, as the files will necessarily be different as
> versions change (perfect example: libxml2 2.9.0/2.9.1)
> 
> Once that is done, it'd be great to retrofit each branch (r151006,
> r151008, master) with an update generated this way.

Neat.

Incidentally, the kayak process works fine with iPXE instead of pxegrub, with one big gotcha, namely that pxegrub gunzips miniroot.gz whereas iPXE does not have that functionality (yet).   The kernel can?t itself deal with a compressed miniroot and promptly crashes.

Given how much better http is than tftp is in almost every way, and ditto iPXE over pxegrub, having an uncompressed miniroot (at ca. 148M rather than 44M) kicking around in /var/kayak/kayak doesn?t seem too awful.

Something like this might go into tftpboot/menu.ipxe:

#!ipxe

set omnios-build r151008j

######## MAIN MENU ###################
:start
menu Welcome to iPXE's Boot Menu
item
item --gap -- ------------------------- Operating systems ------------------------------
item omnios-kayak      Boot OmniOS (needs MAC in /var/kayak/kayak) (${omnios-build})
item --gap -- ------------------------------ Utilities ---------------------------------
item shell      Enter iPXE shell
item reboot     Reboot
item
item exit       Exit (boot local disk)
choose ?default omnios-kayak --timeout 30000 target && goto ${target}

# miniroot
:omnios-kayak
kernel /boot/platform/i86pc/kernel/amd64/unix -B install_media=http:///kayak/r151008j.zfs.bz2,install_config=http:///kayak
module /kayak/miniroot
boot
goto start

#end

For chaining purposes, using ISC DHCPD:

subnet x.x.x.x netmask y.y.y.y {
   range ? ;
   next-server ka.y.a.k;
   if exists user-class and option user-class = ?iPXE? {
	filename = ?menu.ipxe?;
   } else {
        filename = ?undionly.kpxe?;
   }
}

The undionly.kpxe file can be found at http://boot.ipxe.org/undionly.kpxe and goes into /tftpboot on the kayak server.

The menu.ipxe above can be rewritten to use http rather than tftp.  The easiest way to take advantage of that is to copy the files in the ?kernel? and ?module? lines to somewhere under /var/kayak/kayak.    If one is provisioning lots of omnioses via kayak or if the kayak server is at a fair distance (round-trip-time-wise) from the systems being provisioned, it?s easily worthwhile.

It?s also worthwhile if you tend to netboot other things.

cf. http://wiki.smartos.org/display/DOC/PXE+Booting+SmartOS  

Finally, the rest of the kayak process remains the same, notably the need to make a configuration file in /var/kayak/kayak.

	Sean.



From tobi at oetiker.ch  Mon Jan 20 17:19:13 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Mon, 20 Jan 2014 18:19:13 +0100 (CET)
Subject: [OmniOS-discuss] igb0 'hangs'
In-Reply-To: <9E8F3921-72F8-40A9-A441-87A0C11A6B76@kram.io>
References: <alpine.DEB.2.02.1401191710520.4208@froburg.oetiker.ch>
	<9E8F3921-72F8-40A9-A441-87A0C11A6B76@kram.io>
Message-ID: <alpine.DEB.2.02.1401201818190.16159@froburg.oetiker.ch>

Today Steffen Kram wrote:

> Hi Tobi,
>
> I had a similar problem a while ago, when I was resetting the
> maxbw property without taking the interface down.  The global
> zone could not communicate over that interface anymore, while the
> zones where all happy.  Taking the interface down and up again
> solved my issue, too.

hmmm ... I have not fiddled with the interface at all before ...

I have now disabled HW flow-control ... maybe that helps

cheers
tobi

>
> Cheers,
> Steffen
>
> Am 19.01.2014 um 17:26 schrieb Tobias Oetiker <tobi at oetiker.ch>:
>
> > I just had an odd thing happening to my r151008 server. It suddenly
> > stopped communicating over its igb0 interface ...
> >
> > Upon further investigation I found:
> >
> > a) several KVM guests talking over the same physical interface were
> >   still happily chatting
> >
> > b) logging into the guests and trying to reach the server over that
> >   route did not work either.
> >
> > c) accessing the server via the hardware console revealed that it
> >   was working and did not seem to realize that igb0 was having a
> >   problem. At least dmesg did not show anyithing interesting.
> >
> >   once I did
> >
> >   # ipadm down-addr igb0/v4static
> >   # ipadm up-addr igb0/v4static
> >
> >   the interface started working again ...
> >
> > any idea what has happened here ?
> >
> > 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
> >
>
>

-- 
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 frederic.alix at fredalix.com  Mon Jan 20 17:32:41 2014
From: frederic.alix at fredalix.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Alix?=)
Date: Mon, 20 Jan 2014 18:32:41 +0100
Subject: [OmniOS-discuss] igb0 'hangs'
In-Reply-To: <alpine.DEB.2.02.1401201818190.16159@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1401191710520.4208@froburg.oetiker.ch>
	<9E8F3921-72F8-40A9-A441-87A0C11A6B76@kram.io>
	<alpine.DEB.2.02.1401201818190.16159@froburg.oetiker.ch>
Message-ID: <CAN4tE3-VK8c=v4vBu=9iU5zOAWM74YAU0VC0dSa00Pg=+uzcQQ@mail.gmail.com>

Perhaps iperf can help you for identify this problem.
When i have this sort of failure under Solaris, i use iperf for load
bandwidth and set different TCP window size. During the test, i use snoop
for see at what moment the problem appear come.


2014/1/20 Tobias Oetiker <tobi at oetiker.ch>

> Today Steffen Kram wrote:
>
> > Hi Tobi,
> >
> > I had a similar problem a while ago, when I was resetting the
> > maxbw property without taking the interface down.  The global
> > zone could not communicate over that interface anymore, while the
> > zones where all happy.  Taking the interface down and up again
> > solved my issue, too.
>
> hmmm ... I have not fiddled with the interface at all before ...
>
> I have now disabled HW flow-control ... maybe that helps
>
> cheers
> tobi
>
> >
> > Cheers,
> > Steffen
> >
> > Am 19.01.2014 um 17:26 schrieb Tobias Oetiker <tobi at oetiker.ch>:
> >
> > > I just had an odd thing happening to my r151008 server. It suddenly
> > > stopped communicating over its igb0 interface ...
> > >
> > > Upon further investigation I found:
> > >
> > > a) several KVM guests talking over the same physical interface were
> > >   still happily chatting
> > >
> > > b) logging into the guests and trying to reach the server over that
> > >   route did not work either.
> > >
> > > c) accessing the server via the hardware console revealed that it
> > >   was working and did not seem to realize that igb0 was having a
> > >   problem. At least dmesg did not show anyithing interesting.
> > >
> > >   once I did
> > >
> > >   # ipadm down-addr igb0/v4static
> > >   # ipadm up-addr igb0/v4static
> > >
> > >   the interface started working again ...
> > >
> > > any idea what has happened here ?
> > >
> > > 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
> > >
> >
> >
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140120/052d4c1f/attachment-0001.html>

From lotheac at iki.fi  Mon Jan 20 17:33:52 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Mon, 20 Jan 2014 19:33:52 +0200
Subject: [OmniOS-discuss] kayak bugs, r151008j
In-Reply-To: <33312BA8-F27D-46F6-834D-75EBBB333BFC@mis.use.net>
References: <B3D7018D-8280-48F5-BC0F-C3790B76A5E8@mis.use.net>
	<20140115123026.GA19170@gutsman.lotheac.fi>
	<CACLsApuskhmXY1-55fwBP0OpmAiHYzo+H0uCMKUD00vnHy6n_A@mail.gmail.com>
	<20140120155240.GA1437@gutsman.lotheac.fi>
	<20140120155853.GB1437@gutsman.lotheac.fi>
	<CA+QY2RSWApg51-n4Zwv-oi8v=fN=P2u+mBjJpGEeNaeGYETQ+w@mail.gmail.com>
	<33312BA8-F27D-46F6-834D-75EBBB333BFC@mis.use.net>
Message-ID: <20140120173352.GC1437@gutsman.lotheac.fi>

On Mon, Jan 20 2014 17:10:14 +0000, Sean Doran wrote:
> Incidentally, the kayak process works fine with iPXE instead of
> pxegrub, with one big gotcha, namely that pxegrub gunzips miniroot.gz
> whereas iPXE does not have that functionality (yet).   The kernel
> can?t itself deal with a compressed miniroot and promptly crashes.
> 
> Given how much better http is than tftp is in almost every way, and
> ditto iPXE over pxegrub, having an uncompressed miniroot (at ca. 148M
> rather than 44M) kicking around in /var/kayak/kayak doesn?t seem too
> awful.

Hmm, thanks for the heads up, I might try this at some point. We are
using grub2 for our netboots, which also supports http, but based on one
test the implementation seems to be just as slow as tftp.

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

From johan.kragsterman at capvert.se  Mon Jan 20 18:12:05 2014
From: johan.kragsterman at capvert.se (Johan Kragsterman)
Date: Mon, 20 Jan 2014 19:12:05 +0100
Subject: [OmniOS-discuss] OmniOS HBA Brocade 815 hardware compatibilty
In-Reply-To: <52DD5578.2040105@dojcak.sk>
References: <52DD5578.2040105@dojcak.sk>,
	<52DD1D03.2070702@dojcak.sk>	<4204E868-DFE8-4697-B9F1-FC0FDB32A46E@omniti.com>
Message-ID: <OFED7F6353.67CCC39A-ONC1257C66.0063AAAF-C1257C66.0063FBFF@inse.com>

An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140120/f4174661/attachment.html>

From tobi at oetiker.ch  Tue Jan 21 09:04:56 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Tue, 21 Jan 2014 10:04:56 +0100 (CET)
Subject: [OmniOS-discuss] iscsi timeouts
Message-ID: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>

Hi,

we are serving ISCSI volumes from our omnios box ... in the log on
the client I keep seeing this pattern every few hours.

any idea what could be causing this ?

server and client are directly via a crossover cable over a dedicated interface.

Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604535]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 4557605264, now 4557606516 [kern.err]
Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604656]  connection1:0: detected conn error (1011) [kern.info]
Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604661]  connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 4557605264, now 4557606516 [kern.err]
Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604763]  connection2:0: detected conn error (1011) [kern.info]
Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 1:0 error (1011) state (3) [daemon.warning]
Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 2:0 error (1011) state (3) [daemon.warning]
Jan 21 01:21:57 iscsi-client kernel:  : [1048713.496478] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048717.843552] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048718.087086] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048730.558551] nfs: server 10.10.10.1 OK [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559623] nfs: server 10.10.10.1 OK [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559654] nfs: server 10.10.10.1 OK [kern.notice]
Jan 21 01:21:59 iscsi-client iscsid:  connection1:0 is operational after recovery (2 attempts) [daemon.warning]
Jan 21 01:21:59 iscsi-client iscsid:  connection2:0 is operational after recovery (2 attempts) [daemon.warning]

chers
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 turbo124 at gmail.com  Tue Jan 21 09:10:53 2014
From: turbo124 at gmail.com (David Bomba)
Date: Tue, 21 Jan 2014 20:10:53 +1100
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
Message-ID: <AC8F9A4D-3C64-43E3-A7DF-C3C6C0744718@gmail.com>

It looks like your NFS is dropping also  ( but then recovering ), so I wouldn't be pinning the problem solely on iscsi.

The problem could be anywhere from the network driver all the way back to the switch/cables etc. You'll need to go through each item methodically to find the root cause.

On 21/01/2014, at 8:04 PM, Tobias Oetiker wrote:

> Hi,
> 
> we are serving ISCSI volumes from our omnios box ... in the log on
> the client I keep seeing this pattern every few hours.
> 
> any idea what could be causing this ?
> 
> server and client are directly via a crossover cable over a dedicated interface.
> 
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604535]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 4557605264, now 4557606516 [kern.err]
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604656]  connection1:0: detected conn error (1011) [kern.info]
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604661]  connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 4557605264, now 4557606516 [kern.err]
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604763]  connection2:0: detected conn error (1011) [kern.info]
> Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 1:0 error (1011) state (3) [daemon.warning]
> Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 2:0 error (1011) state (3) [daemon.warning]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048713.496478] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048717.843552] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048718.087086] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048730.558551] nfs: server 10.10.10.1 OK [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559623] nfs: server 10.10.10.1 OK [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559654] nfs: server 10.10.10.1 OK [kern.notice]
> Jan 21 01:21:59 iscsi-client iscsid:  connection1:0 is operational after recovery (2 attempts) [daemon.warning]
> Jan 21 01:21:59 iscsi-client iscsid:  connection2:0 is operational after recovery (2 attempts) [daemon.warning]
> 
> chers
> 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 narayan.desai at gmail.com  Tue Jan 21 12:21:41 2014
From: narayan.desai at gmail.com (Narayan Desai)
Date: Tue, 21 Jan 2014 06:21:41 -0600
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
Message-ID: <CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>

We've seen problems like this when we have a SATA drive in a SAS expander
that is going out to lunch. Are there any drives showing errors in iostat
-En? or any drive timeout messages in the ring buffer?
 -nld


On Tue, Jan 21, 2014 at 3:04 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:

> Hi,
>
> we are serving ISCSI volumes from our omnios box ... in the log on
> the client I keep seeing this pattern every few hours.
>
> any idea what could be causing this ?
>
> server and client are directly via a crossover cable over a dedicated
> interface.
>
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604535]  connection1:0:
> ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last
> ping 4557605264, now 4557606516 [kern.err]
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604656]  connection1:0:
> detected conn error (1011) [kern.info]
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604661]  connection2:0:
> ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last
> ping 4557605264, now 4557606516 [kern.err]
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604763]  connection2:0:
> detected conn error (1011) [kern.info]
> Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 1:0
> error (1011) state (3) [daemon.warning]
> Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 2:0
> error (1011) state (3) [daemon.warning]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048713.496478] nfs: server
> 10.10.10.1 not responding, still trying [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048717.843552] nfs: server
> 10.10.10.1 not responding, still trying [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048718.087086] nfs: server
> 10.10.10.1 not responding, still trying [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048730.558551] nfs: server
> 10.10.10.1 OK [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559623] nfs: server
> 10.10.10.1 OK [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559654] nfs: server
> 10.10.10.1 OK [kern.notice]
> Jan 21 01:21:59 iscsi-client iscsid:  connection1:0 is operational after
> recovery (2 attempts) [daemon.warning]
> Jan 21 01:21:59 iscsi-client iscsid:  connection2:0 is operational after
> recovery (2 attempts) [daemon.warning]
>
> chers
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140121/88458584/attachment.html>

From danmcd at omniti.com  Tue Jan 21 13:58:56 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 21 Jan 2014 08:58:56 -0500
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>
Message-ID: <AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>


On Jan 21, 2014, at 7:21 AM, Narayan Desai <narayan.desai at gmail.com> wrote:

> We've seen problems like this when we have a SATA drive in a SAS expander that is going out to lunch. Are there any drives showing errors in iostat -En? or any drive timeout messages in the ring buffer?

Generally speaking --> you use a SATA drive in a SAS expander at your own risk.  I used to be at Nexenta, and they would not support customers who deployed SATA drives on SAS expanders.  These days, the price delta between SAS and SATA (for enterprise) is small enough to be worth it for the headaches you avoid.

Dan



From tobi at oetiker.ch  Tue Jan 21 14:24:43 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Tue, 21 Jan 2014 15:24:43 +0100 (CET)
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>
	<AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>
Message-ID: <alpine.DEB.2.02.1401211523090.2519@froburg.oetiker.ch>

Today Dan McDonald wrote:

>
> On Jan 21, 2014, at 7:21 AM, Narayan Desai <narayan.desai at gmail.com> wrote:
>
> > We've seen problems like this when we have a SATA drive in a SAS expander that is going out to lunch. Are there any drives showing errors in iostat -En? or any drive timeout messages in the ring buffer?
>
> Generally speaking --> you use a SATA drive in a SAS expander at
> your own risk.  I used to be at Nexenta, and they would not
> support customers who deployed SATA drives on SAS expanders.
> These days, the price delta between SAS and SATA (for enterprise)
> is small enough to be worth it for the headaches you avoid.

we are not using sata NOR a sas expander ...

we have a bunch of sas drives directly attached to sas controller
ports each ... (the ssd drives are sata but they are directly
attached to individual sas ports too)

we have several system setup in a similar manner, and the problem
only manifests on this one ... but it is also the most busy of the
bunch.

cheers
tobi
>
> Dan
>
>
>

-- 
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 tim at multitalents.net  Tue Jan 21 19:48:44 2014
From: tim at multitalents.net (Tim Rice)
Date: Tue, 21 Jan 2014 11:48:44 -0800 (PST)
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
Message-ID: <Pine.UW2.4.64.1401211144590.25583@server01.int.multitalents.net>

On Tue, 21 Jan 2014, Tobias Oetiker wrote:

> Hi,
> 
> we are serving ISCSI volumes from our omnios box ... in the log on
> the client I keep seeing this pattern every few hours.
> 
> any idea what could be causing this ?
> 
> server and client are directly via a crossover cable over a dedicated interface.

It might be a good idea to tell the list what network cards you are using.
If they are 1G cards and you are using a Cat 5e cable, do yourself a
favor and replace it with a Cat 6 cable.

> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604535]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 4557605264, now 4557606516 [kern.err]
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604656]  connection1:0: detected conn error (1011) [kern.info]
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604661]  connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 4557605264, now 4557606516 [kern.err]
> Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604763]  connection2:0: detected conn error (1011) [kern.info]
> Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 1:0 error (1011) state (3) [daemon.warning]
> Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 2:0 error (1011) state (3) [daemon.warning]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048713.496478] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048717.843552] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048718.087086] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048730.558551] nfs: server 10.10.10.1 OK [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559623] nfs: server 10.10.10.1 OK [kern.notice]
> Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559654] nfs: server 10.10.10.1 OK [kern.notice]
> Jan 21 01:21:59 iscsi-client iscsid:  connection1:0 is operational after recovery (2 attempts) [daemon.warning]
> Jan 21 01:21:59 iscsi-client iscsid:  connection2:0 is operational after recovery (2 attempts) [daemon.warning]
> 
> chers
> tobi
> 

-- 
Tim Rice				Multitalents	(707) 456-1146
tim at multitalents.net



From tobi at oetiker.ch  Tue Jan 21 21:48:13 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Tue, 21 Jan 2014 22:48:13 +0100 (CET)
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <Pine.UW2.4.64.1401211144590.25583@server01.int.multitalents.net>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
	<Pine.UW2.4.64.1401211144590.25583@server01.int.multitalents.net>
Message-ID: <alpine.DEB.2.02.1401212245320.2519@froburg.oetiker.ch>

Hi Tim,

Today Tim Rice wrote:

> On Tue, 21 Jan 2014, Tobias Oetiker wrote:
>
> > Hi,
> >
> > we are serving ISCSI volumes from our omnios box ... in the log on
> > the client I keep seeing this pattern every few hours.
> >
> > any idea what could be causing this ?
> >
> > server and client are directly via a crossover cable over a dedicated interface.
>
> It might be a good idea to tell the list what network cards you are using.
> If they are 1G cards and you are using a Cat 5e cable, do yourself a
> favor and replace it with a Cat 6 cable.

sure, we have intel on-board controllers

07:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
        Subsystem: Intel Corporation Device 3584
        Flags: bus master, fast devsel, latency 0, IRQ 11
        Memory at d0960000 (32-bit, non-prefetchable)
        I/O ports at 1060
        Memory at d09b0000 (32-bit, non-prefetchable)
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Capabilities: [70] MSI-X: Enable+ Count=10 Masked-
        Capabilities: [a0] Express Endpoint, MSI 00
        Capabilities: [e0] Vital Product Data

the cable issue I have to verify ...

the odd thing about this behaviour is, that there are several kvm
virtual machines running on this box as well, and even when omnios
goes 'offline' the kvm hosts (talking over the same physical
interface) are still reachable. They themselfs can not talk to
omnios either ...

cheers
tobi

> > Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604535]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 4557605264, now 4557606516 [kern.err]
> > Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604656]  connection1:0: detected conn error (1011) [kern.info]
> > Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604661]  connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 4557605264, now 4557606516 [kern.err]
> > Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604763]  connection2:0: detected conn error (1011) [kern.info]
> > Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 1:0 error (1011) state (3) [daemon.warning]
> > Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 2:0 error (1011) state (3) [daemon.warning]
> > Jan 21 01:21:57 iscsi-client kernel:  : [1048713.496478] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
> > Jan 21 01:21:57 iscsi-client kernel:  : [1048717.843552] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
> > Jan 21 01:21:57 iscsi-client kernel:  : [1048718.087086] nfs: server 10.10.10.1 not responding, still trying [kern.notice]
> > Jan 21 01:21:57 iscsi-client kernel:  : [1048730.558551] nfs: server 10.10.10.1 OK [kern.notice]
> > Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559623] nfs: server 10.10.10.1 OK [kern.notice]
> > Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559654] nfs: server 10.10.10.1 OK [kern.notice]
> > Jan 21 01:21:59 iscsi-client iscsid:  connection1:0 is operational after recovery (2 attempts) [daemon.warning]
> > Jan 21 01:21:59 iscsi-client iscsid:  connection2:0 is operational after recovery (2 attempts) [daemon.warning]
> >
> > chers
> > 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 narayan.desai at gmail.com  Tue Jan 21 21:50:14 2014
From: narayan.desai at gmail.com (Narayan Desai)
Date: Tue, 21 Jan 2014 15:50:14 -0600
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>
	<AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>
Message-ID: <CABweQm+_aeDiMk6aVJmuf9K9V52zeWmi=3s9GTvej72+w9ajOg@mail.gmail.com>

Sorry, I should have given the requisite "yes, I know that this is a recipe
for sadness, for I too have experienced said sadness".

That said, we've seen this kind of problem when there was a device in a
vdev that was dying a slow death. There wouldn't necessarily be any sign,
aside from insanely high service times on an individual device in the pool.
>From this, I assume that ZFS is still sensitive to variation in underlying
drive performance.

Tobi, what do your drive service times look like?
 -nld


On Tue, Jan 21, 2014 at 7:58 AM, Dan McDonald <danmcd at omniti.com> wrote:

>
> On Jan 21, 2014, at 7:21 AM, Narayan Desai <narayan.desai at gmail.com>
> wrote:
>
> > We've seen problems like this when we have a SATA drive in a SAS
> expander that is going out to lunch. Are there any drives showing errors in
> iostat -En? or any drive timeout messages in the ring buffer?
>
> Generally speaking --> you use a SATA drive in a SAS expander at your own
> risk.  I used to be at Nexenta, and they would not support customers who
> deployed SATA drives on SAS expanders.  These days, the price delta between
> SAS and SATA (for enterprise) is small enough to be worth it for the
> headaches you avoid.
>
> Dan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140121/85d5c448/attachment.html>

From tobi at oetiker.ch  Tue Jan 21 22:01:51 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Tue, 21 Jan 2014 23:01:51 +0100 (CET)
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <CABweQm+_aeDiMk6aVJmuf9K9V52zeWmi=3s9GTvej72+w9ajOg@mail.gmail.com>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>
	<AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>
	<CABweQm+_aeDiMk6aVJmuf9K9V52zeWmi=3s9GTvej72+w9ajOg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1401212254290.2519@froburg.oetiker.ch>

Hi Nld,

Today Narayan Desai wrote:

> Sorry, I should have given the requisite "yes, I know that this is a recipe
> for sadness, for I too have experienced said sadness".
>
> That said, we've seen this kind of problem when there was a device in a
> vdev that was dying a slow death. There wouldn't necessarily be any sign,
> aside from insanely high service times on an individual device in the pool.
> From this, I assume that ZFS is still sensitive to variation in underlying
> drive performance.
>
> Tobi, what do your drive service times look like?
>  -nld

the drives seem fine, smart is not reporting anything out of the
ordinary and also iostat -En shows 0 on all counts

I don't think it is a disk issue, but rather something connected
with the network ...

On times the machine becomes unreachable for some time, and then it
is possible to login via console and all seems well internally.
setting the network interface offline and then online again using
the dladm tool brings the connectivity back immediatly. waiting
helps as well ... since the problem sorts itself out after a few
seconds to minutes ...

we just had another 'off the net' periode for 30 minutes

unfortunately omnios itself does not seem to realize that something
is off, at least dmesg does not show any kernel messages about this
problem ...

we have several systems running on the S2600CP MB ... this is the
only one showing problems ...

the next thing I intend todo is to upgrade the MB firmware since I
found that this box has an older version than the other ones ...

System Configuration: Intel Corporation S2600CP
BIOS Configuration: Intel Corp. SE5C600.86B.01.06.0002.110120121539 11/01/2012

other ideas, most welcome !

cheers
tobi
>
>
> On Tue, Jan 21, 2014 at 7:58 AM, Dan McDonald <danmcd at omniti.com> wrote:
>
> >
> > On Jan 21, 2014, at 7:21 AM, Narayan Desai <narayan.desai at gmail.com>
> > wrote:
> >
> > > We've seen problems like this when we have a SATA drive in a SAS
> > expander that is going out to lunch. Are there any drives showing errors in
> > iostat -En? or any drive timeout messages in the ring buffer?
> >
> > Generally speaking --> you use a SATA drive in a SAS expander at your own
> > risk.  I used to be at Nexenta, and they would not support customers who
> > deployed SATA drives on SAS expanders.  These days, the price delta between
> > SAS and SATA (for enterprise) is small enough to be worth it for the
> > headaches you avoid.
> >
> > Dan
> >
> >
> >
>

-- 
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 skiselkov.ml at gmail.com  Tue Jan 21 22:09:55 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Tue, 21 Jan 2014 22:09:55 +0000
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <alpine.DEB.2.02.1401212254290.2519@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>	<AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>	<CABweQm+_aeDiMk6aVJmuf9K9V52zeWmi=3s9GTvej72+w9ajOg@mail.gmail.com>
	<alpine.DEB.2.02.1401212254290.2519@froburg.oetiker.ch>
Message-ID: <52DEF033.7010107@gmail.com>

On 1/21/14, 10:01 PM, Tobias Oetiker wrote:
> Hi Nld,
> 
> Today Narayan Desai wrote:
> 
>> Sorry, I should have given the requisite "yes, I know that this is a recipe
>> for sadness, for I too have experienced said sadness".
>>
>> That said, we've seen this kind of problem when there was a device in a
>> vdev that was dying a slow death. There wouldn't necessarily be any sign,
>> aside from insanely high service times on an individual device in the pool.
>> From this, I assume that ZFS is still sensitive to variation in underlying
>> drive performance.
>>
>> Tobi, what do your drive service times look like?
>>  -nld
> 
> the drives seem fine, smart is not reporting anything out of the
> ordinary and also iostat -En shows 0 on all counts
> 
> I don't think it is a disk issue, but rather something connected
> with the network ...
> 
> On times the machine becomes unreachable for some time, and then it
> is possible to login via console and all seems well internally.
> setting the network interface offline and then online again using
> the dladm tool brings the connectivity back immediatly. waiting
> helps as well ... since the problem sorts itself out after a few
> seconds to minutes ...
> 
> we just had another 'off the net' periode for 30 minutes
> 
> unfortunately omnios itself does not seem to realize that something
> is off, at least dmesg does not show any kernel messages about this
> problem ...
> 
> we have several systems running on the S2600CP MB ... this is the
> only one showing problems ...
> 
> the next thing I intend todo is to upgrade the MB firmware since I
> found that this box has an older version than the other ones ...
> 
> System Configuration: Intel Corporation S2600CP
> BIOS Configuration: Intel Corp. SE5C600.86B.01.06.0002.110120121539 11/01/2012
> 
> other ideas, most welcome !

You mentioned a couple of e-mails back that you're using Intel I350s.
Can you verify that your kernel has:

commit 43ae55058ad99c869a9ae39d039490e8a3680520
Author: Dan McDonald <danmcd at nexenta.com>
Date:   Thu Feb 7 19:27:18 2013 -0500

    3534 Disable EEE support in igb for I350
    Reviewed by: Robert Mustacchi <rm at joyent.com>
    Reviewed by: Jason King <jason.brian.king at gmail.com>
    Reviewed by: Marcel Telka <marcel at telka.sk>
    Reviewed by: Sebastien Roy <sebastien.roy at delphix.com>
    Approved by: Richard Lowe <richlowe at richlowe.net>

I guess you can check for this string at runtime:
$ strings /kernel/drv/amd64/igb | grep _eee_support

If it is missing, then it could be the buggy EEE support that's throwing
your link out of whack here.

Cheers,
-- 
Saso

From skiselkov.ml at gmail.com  Tue Jan 21 22:16:11 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Tue, 21 Jan 2014 22:16:11 +0000
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <52DEF033.7010107@gmail.com>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>	<AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>	<CABweQm+_aeDiMk6aVJmuf9K9V52zeWmi=3s9GTvej72+w9ajOg@mail.gmail.com>
	<alpine.DEB.2.02.1401212254290.2519@froburg.oetiker.ch>
	<52DEF033.7010107@gmail.com>
Message-ID: <52DEF1AB.9030305@gmail.com>

On 1/21/14, 10:09 PM, Saso Kiselkov wrote:
> On 1/21/14, 10:01 PM, Tobias Oetiker wrote:
>> Hi Nld,
>>
>> Today Narayan Desai wrote:
>>
>>> Sorry, I should have given the requisite "yes, I know that this is a recipe
>>> for sadness, for I too have experienced said sadness".
>>>
>>> That said, we've seen this kind of problem when there was a device in a
>>> vdev that was dying a slow death. There wouldn't necessarily be any sign,
>>> aside from insanely high service times on an individual device in the pool.
>>> From this, I assume that ZFS is still sensitive to variation in underlying
>>> drive performance.
>>>
>>> Tobi, what do your drive service times look like?
>>>  -nld
>>
>> the drives seem fine, smart is not reporting anything out of the
>> ordinary and also iostat -En shows 0 on all counts
>>
>> I don't think it is a disk issue, but rather something connected
>> with the network ...
>>
>> On times the machine becomes unreachable for some time, and then it
>> is possible to login via console and all seems well internally.
>> setting the network interface offline and then online again using
>> the dladm tool brings the connectivity back immediatly. waiting
>> helps as well ... since the problem sorts itself out after a few
>> seconds to minutes ...
>>
>> we just had another 'off the net' periode for 30 minutes
>>
>> unfortunately omnios itself does not seem to realize that something
>> is off, at least dmesg does not show any kernel messages about this
>> problem ...
>>
>> we have several systems running on the S2600CP MB ... this is the
>> only one showing problems ...
>>
>> the next thing I intend todo is to upgrade the MB firmware since I
>> found that this box has an older version than the other ones ...
>>
>> System Configuration: Intel Corporation S2600CP
>> BIOS Configuration: Intel Corp. SE5C600.86B.01.06.0002.110120121539 11/01/2012
>>
>> other ideas, most welcome !
> 
> You mentioned a couple of e-mails back that you're using Intel I350s.
> Can you verify that your kernel has:
> 
> commit 43ae55058ad99c869a9ae39d039490e8a3680520
> Author: Dan McDonald <danmcd at nexenta.com>
> Date:   Thu Feb 7 19:27:18 2013 -0500
> 
>     3534 Disable EEE support in igb for I350
>     Reviewed by: Robert Mustacchi <rm at joyent.com>
>     Reviewed by: Jason King <jason.brian.king at gmail.com>
>     Reviewed by: Marcel Telka <marcel at telka.sk>
>     Reviewed by: Sebastien Roy <sebastien.roy at delphix.com>
>     Approved by: Richard Lowe <richlowe at richlowe.net>
> 
> I guess you can check for this string at runtime:
> $ strings /kernel/drv/amd64/igb | grep _eee_support
> 
> If it is missing, then it could be the buggy EEE support that's throwing
> your link out of whack here.

Nevermind, missed your description of the KVM guests being reachable
while only the host goes offline... Did snoop show anything arriving at
the host while it is offline?

Cheers,
-- 
Saso

From skiselkov.ml at gmail.com  Tue Jan 21 22:18:51 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Tue, 21 Jan 2014 22:18:51 +0000
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <52DEF1AB.9030305@gmail.com>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>	<AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>	<CABweQm+_aeDiMk6aVJmuf9K9V52zeWmi=3s9GTvej72+w9ajOg@mail.gmail.com>
	<alpine.DEB.2.02.1401212254290.2519@froburg.oetiker.ch>
	<52DEF033.7010107@gmail.com> <52DEF1AB.9030305@gmail.com>
Message-ID: <52DEF24B.7070806@gmail.com>

On 1/21/14, 10:16 PM, Saso Kiselkov wrote:
> On 1/21/14, 10:09 PM, Saso Kiselkov wrote:
>> On 1/21/14, 10:01 PM, Tobias Oetiker wrote:
>>> Hi Nld,
>>>
>>> Today Narayan Desai wrote:
>>>
>>>> Sorry, I should have given the requisite "yes, I know that this is a recipe
>>>> for sadness, for I too have experienced said sadness".
>>>>
>>>> That said, we've seen this kind of problem when there was a device in a
>>>> vdev that was dying a slow death. There wouldn't necessarily be any sign,
>>>> aside from insanely high service times on an individual device in the pool.
>>>> From this, I assume that ZFS is still sensitive to variation in underlying
>>>> drive performance.
>>>>
>>>> Tobi, what do your drive service times look like?
>>>>  -nld
>>>
>>> the drives seem fine, smart is not reporting anything out of the
>>> ordinary and also iostat -En shows 0 on all counts
>>>
>>> I don't think it is a disk issue, but rather something connected
>>> with the network ...
>>>
>>> On times the machine becomes unreachable for some time, and then it
>>> is possible to login via console and all seems well internally.
>>> setting the network interface offline and then online again using
>>> the dladm tool brings the connectivity back immediatly. waiting
>>> helps as well ... since the problem sorts itself out after a few
>>> seconds to minutes ...
>>>
>>> we just had another 'off the net' periode for 30 minutes
>>>
>>> unfortunately omnios itself does not seem to realize that something
>>> is off, at least dmesg does not show any kernel messages about this
>>> problem ...
>>>
>>> we have several systems running on the S2600CP MB ... this is the
>>> only one showing problems ...
>>>
>>> the next thing I intend todo is to upgrade the MB firmware since I
>>> found that this box has an older version than the other ones ...
>>>
>>> System Configuration: Intel Corporation S2600CP
>>> BIOS Configuration: Intel Corp. SE5C600.86B.01.06.0002.110120121539 11/01/2012
>>>
>>> other ideas, most welcome !
>>
>> You mentioned a couple of e-mails back that you're using Intel I350s.
>> Can you verify that your kernel has:
>>
>> commit 43ae55058ad99c869a9ae39d039490e8a3680520
>> Author: Dan McDonald <danmcd at nexenta.com>
>> Date:   Thu Feb 7 19:27:18 2013 -0500
>>
>>     3534 Disable EEE support in igb for I350
>>     Reviewed by: Robert Mustacchi <rm at joyent.com>
>>     Reviewed by: Jason King <jason.brian.king at gmail.com>
>>     Reviewed by: Marcel Telka <marcel at telka.sk>
>>     Reviewed by: Sebastien Roy <sebastien.roy at delphix.com>
>>     Approved by: Richard Lowe <richlowe at richlowe.net>
>>
>> I guess you can check for this string at runtime:
>> $ strings /kernel/drv/amd64/igb | grep _eee_support
>>
>> If it is missing, then it could be the buggy EEE support that's throwing
>> your link out of whack here.
> 
> Nevermind, missed your description of the KVM guests being reachable
> while only the host goes offline... Did snoop show anything arriving at
> the host while it is offline?

However, on second thought, you did mention that you're running
crossover between two hosts, which would match the description of the
EEE issue:

https://illumos.org/issues/3534
"The energy efficient Ethernet (EEE) support in Intel's I350 GigE NIC
drops link on directly-attached link cases."

Anyhow, make sure you're running the EEE fix.

-- 
Saso

From tobi at oetiker.ch  Tue Jan 21 23:00:05 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Wed, 22 Jan 2014 00:00:05 +0100 (CET)
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <52DEF24B.7070806@gmail.com>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>
	<AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>
	<CABweQm+_aeDiMk6aVJmuf9K9V52zeWmi=3s9GTvej72+w9ajOg@mail.gmail.com>
	<alpine.DEB.2.02.1401212254290.2519@froburg.oetiker.ch>
	<52DEF033.7010107@gmail.com> <52DEF1AB.9030305@gmail.com>
	<52DEF24B.7070806@gmail.com>
Message-ID: <alpine.DEB.2.02.1401212356540.2519@froburg.oetiker.ch>

Today Saso Kiselkov wrote:

> >> I guess you can check for this string at runtime:
> >> $ strings /kernel/drv/amd64/igb | grep _eee_support
> >>
> >> If it is missing, then it could be the buggy EEE support that's throwing
> >> your link out of whack here.
> >
> > Nevermind, missed your description of the KVM guests being reachable
> > while only the host goes offline... Did snoop show anything arriving at
> > the host while it is offline?
>
> However, on second thought, you did mention that you're running
> crossover between two hosts, which would match the description of the
> EEE issue:
>
> https://illumos.org/issues/3534
> "The energy efficient Ethernet (EEE) support in Intel's I350 GigE NIC
> drops link on directly-attached link cases."
>
> Anyhow, make sure you're running the EEE fix.
>

I think that is in

# strings /kernel/drv/amd64/igb | grep _eee_support
_eee_support

the issue manifests also on the main interface ...

the worst case scenario is, that some odd ethernet packet, present only
in the wild-west-network where this box lives is sending the
network stack into some sort of a tail-spin ...

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 dseira at stackscale.com  Wed Jan 22 15:18:48 2014
From: dseira at stackscale.com (David Seira)
Date: Wed, 22 Jan 2014 16:18:48 +0100
Subject: [OmniOS-discuss] Fwd:  Dell poweredge
In-Reply-To: <CAMGVNzN4NJ7zT6OBJXtZghs1QFJ46=GrygontBV4xbpT_PVw7g@mail.gmail.com>
References: <CAMGVNzNYSqRsn4c8YDf_VpQMD7XCfj+Oj+EY0X1-JGXMpDhM4Q@mail.gmail.com>
	<09819B90-104B-4616-8672-DAFE7A119BF1@omniti.com>
	<CAMGVNzMj3NXB92pg=WRXJ+gELOA5dX=U5raMXaQ24qdZ7HQ6yg@mail.gmail.com>
	<ABB87D87-C107-4779-852F-34EBEB3FE9DC@omniti.com>
	<CAMGVNzN4NJ7zT6OBJXtZghs1QFJ46=GrygontBV4xbpT_PVw7g@mail.gmail.com>
Message-ID: <CAMGVNzOYX48FpxfG_vB_PRwXp+=ejNt9beb3aXXOtuYRgGPGgw@mail.gmail.com>

---------- Forwarded message ----------
From: David Seira <dseira at stackscale.com>
Date: 2014/1/20
Subject: Re: [OmniOS-discuss] Dell poweredge
To: Dan McDonald <danmcd at omniti.com>


Hi Dan,

Thank you very much. With this hack it works ;D. If you are agree, I
would like to forward this message to the omnios list.

Best regards,
David


2014/1/20 Dan McDonald <danmcd at omniti.com>
>
> David!!!
>
> I just found out something.  We did encounter this same problem in NexentaStor, like I said before, but we never upstreamed the change.
>
> As a workaround, edit the grub line with unix in it and add:  " -B disable-amr=true ", which will disable the conflicting-ID, but obsolete, amr(7D) driver.
>
> I'm sorry I didn't think of this sooner!!!
> Dan
>



-- 




--

From dseira at stackscale.com  Wed Jan 22 16:09:08 2014
From: dseira at stackscale.com (David Seira)
Date: Wed, 22 Jan 2014 17:09:08 +0100
Subject: [OmniOS-discuss] Changing the mtu of a vlan interface
Message-ID: <CAMGVNzPta6x4TS-HO5d9G1k2sfR1V65ng5rF551YQZ-5HHsbrw@mail.gmail.com>

Hi all,

I'm trying to figure out how change the mtu of a vlan interface once
it is created.

First I've created the aggr interface with the mtu 1500. Then I've
created a vlan for this interface with the same mtu.

Next I want to change the mtu of this connection. First I've changed
the mtu of the aggr:

#dladm set-linkprop -p mtu=9000 aggr0

But the problem comes when I've tried to change the mtu of the vlan
interface with the same command; I receive the next message:

dladm: warning: cannot set link property 'mtu' on 'aggr0.164':
operation not supported

I've also tried disable the interface but with the same result.

If I delete and create the vlan interface again (with the aggr0 with
the mtu 9000) it works.

I don't understand why is not possible to change the mtu of a vlan
interface once it is created.

Is possible? How can I do that?


Regards,
David

From zmalone at omniti.com  Wed Jan 22 16:22:36 2014
From: zmalone at omniti.com (Zach Malone)
Date: Wed, 22 Jan 2014 11:22:36 -0500
Subject: [OmniOS-discuss] Changing the mtu of a vlan interface
In-Reply-To: <CAMGVNzPta6x4TS-HO5d9G1k2sfR1V65ng5rF551YQZ-5HHsbrw@mail.gmail.com>
References: <CAMGVNzPta6x4TS-HO5d9G1k2sfR1V65ng5rF551YQZ-5HHsbrw@mail.gmail.com>
Message-ID: <CALLZ=vWgtJFrNJzpZsHTNtcNGJjQciotVYgiy86tZfyFYSsgwQ@mail.gmail.com>

I bet the old ifconfig mtu commands will work, even if dladm won't
modify the interface.

On Wed, Jan 22, 2014 at 11:09 AM, David Seira <dseira at stackscale.com> wrote:
> Hi all,
>
> I'm trying to figure out how change the mtu of a vlan interface once
> it is created.
>
> First I've created the aggr interface with the mtu 1500. Then I've
> created a vlan for this interface with the same mtu.
>
> Next I want to change the mtu of this connection. First I've changed
> the mtu of the aggr:
>
> #dladm set-linkprop -p mtu=9000 aggr0
>
> But the problem comes when I've tried to change the mtu of the vlan
> interface with the same command; I receive the next message:
>
> dladm: warning: cannot set link property 'mtu' on 'aggr0.164':
> operation not supported
>
> I've also tried disable the interface but with the same result.
>
> If I delete and create the vlan interface again (with the aggr0 with
> the mtu 9000) it works.
>
> I don't understand why is not possible to change the mtu of a vlan
> interface once it is created.
>
> Is possible? How can I do that?
>
>
> Regards,
> David
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From chip at innovates.com  Wed Jan 22 20:47:38 2014
From: chip at innovates.com (Schweiss, Chip)
Date: Wed, 22 Jan 2014 14:47:38 -0600
Subject: [OmniOS-discuss] Heads up: Redhat/CentOS NFSv3 clients file locking
	failures
Message-ID: <CALeZrrRO_bVR1M4fTQYeyNC1BY=M1Kz3X=OE1yrc-J=UeNhOzg@mail.gmail.com>

A recent change in the NLM for NFSv3 has exposed a problem with the
firewall on Redhat/CentOS.

Connections back to the client are blocked by the firewall because the
connection tracking module is not catching connections as part of the open
NFS connections to the server.

I have attempted to resolve this by opening NFS specific ports but the
server kept connecting to ports that I haven't seen referenced before
including privileged ports.

As a work around I have implemented accept rules for all TCP from the NFS
server.

This could be across all Linux distributions.  My tests have only been on
CentOS.

The problem first appears when port 111 is blocked, opening 111 basically
opens a can worms to what seems randomly selected ports of any value.   I
know on Linux NFS servers the connection ports can be limited.   Is this
possible on Illumos?

-Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140122/2016da99/attachment-0001.html>

From dseira at stackscale.com  Thu Jan 23 10:34:05 2014
From: dseira at stackscale.com (David Seira)
Date: Thu, 23 Jan 2014 11:34:05 +0100
Subject: [OmniOS-discuss] Changing the mtu of a vlan interface
In-Reply-To: <CALLZ=vWgtJFrNJzpZsHTNtcNGJjQciotVYgiy86tZfyFYSsgwQ@mail.gmail.com>
References: <CAMGVNzPta6x4TS-HO5d9G1k2sfR1V65ng5rF551YQZ-5HHsbrw@mail.gmail.com>
	<CALLZ=vWgtJFrNJzpZsHTNtcNGJjQciotVYgiy86tZfyFYSsgwQ@mail.gmail.com>
Message-ID: <CAMGVNzN_BH_E9Mdr0-c4_kY-8y6Gy9T2YdmduX90fmMMPn2wmQ@mail.gmail.com>

Yes, but the problem is that with ifconfig the changes are not persistent.

2014/1/22 Zach Malone <zmalone at omniti.com>:
> I bet the old ifconfig mtu commands will work, even if dladm won't
> modify the interface.
>
> On Wed, Jan 22, 2014 at 11:09 AM, David Seira <dseira at stackscale.com> wrote:
>> Hi all,
>>
>> I'm trying to figure out how change the mtu of a vlan interface once
>> it is created.
>>
>> First I've created the aggr interface with the mtu 1500. Then I've
>> created a vlan for this interface with the same mtu.
>>
>> Next I want to change the mtu of this connection. First I've changed
>> the mtu of the aggr:
>>
>> #dladm set-linkprop -p mtu=9000 aggr0
>>
>> But the problem comes when I've tried to change the mtu of the vlan
>> interface with the same command; I receive the next message:
>>
>> dladm: warning: cannot set link property 'mtu' on 'aggr0.164':
>> operation not supported
>>
>> I've also tried disable the interface but with the same result.
>>
>> If I delete and create the vlan interface again (with the aggr0 with
>> the mtu 9000) it works.
>>
>> I don't understand why is not possible to change the mtu of a vlan
>> interface once it is created.
>>
>> Is possible? How can I do that?
>>
>>
>> Regards,
>> David
>> _______________________________________________
>> 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 jperkin at joyent.com  Fri Jan 24 15:38:01 2014
From: jperkin at joyent.com (Jonathan Perkin)
Date: Fri, 24 Jan 2014 15:38:01 +0000
Subject: [OmniOS-discuss] pkgsrc-2013Q4 binary packages for illumos now
	available
Message-ID: <20140124153801.GY461@joyent.com>

I'm pleased to announce that the pkgsrc-2013Q4 release for illumos
platforms is now available.  This is an alternative repository of over
11,000 binary packages built in both 32-bit and 64-bit configurations
for all illumos systems.

A quick-start tutorial is available here:

  http://pkgsrc.joyent.com/installing.html

You will notice from that page that we also provide over 10,000 binary
packages for OS X, which may be of interest to those of you who use a
Mac to connect to your illumos servers and want to use the same
package manager on both systems.

The list of major changes in 2013Q4 are here:

  http://pkgsrc-us-east.joyent.com/changes.html#major-changes-in-pkgsrc2013q4

Please report any bugs or feature requests to our GitHub issues page:

  https://github.com/joyent/pkgsrc/issues

Thanks!

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com

From ngoossens at gmail.com  Sun Jan 26 22:37:47 2014
From: ngoossens at gmail.com (Niels Goossens)
Date: Sun, 26 Jan 2014 23:37:47 +0100
Subject: [OmniOS-discuss] OmniOS random freezes
Message-ID: <CAGHroZBECVDC1Aaxt_p6kirZGhZCK4LzZcO-W7ZG+d+FTyFSxg@mail.gmail.com>

In order to rule out OmniOS as the cause of the random hangs, I created a
clean Debian install on a new SATA drive, removed the OmniOs boot drive and
booted from Debian. After import on the zpool (native ZFS on Linux
installed) I ran some tests, basically moving a few large KVM raw images
around. This resulted in a hang as well, which I could later reproduce.
Again, there is no sign of anything related to this hang in the Debian log
files. For some strange reason, using dd to dump the contents of a zvol
disk0 to a local file on the same zpool does not hang the machine, but
copying that file to an NFS share does. This might be coincidence though,
because on OmniOS I could get the system to hang with only a scrub (no
network involved).

This is starting to look like a hardware issue. I will now exchange the
memory in this machine and see if that resolves the issue. After that, I
guess I will have to setup BTRFS or something similar to start ruling out
the drives...

Niels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140126/8007c8b5/attachment.html>

From fields at gwu.edu  Mon Jan 27 21:29:43 2014
From: fields at gwu.edu (Garrett Fields)
Date: Mon, 27 Jan 2014 16:29:43 -0500
Subject: [OmniOS-discuss] ACL inheritance and ABE broke when using nested
	filesystems
Message-ID: <CAMC267eLZ2gJP7UUtdzVTPkk9D8uzFYBS-aSw39L+=gL4nYzwg@mail.gmail.com>

I'm setting up an OmniOS storage server with SMB shares for AD
authenticated group shares.  I got Active Directory integration, and Access
Based Enumeration to working, then focused on quotas.  I understand, I can
have user/fs, group/fs, and a generic fs quotas.

Originally, I was going to use a single fs with directories for the
different groups, but then I found that the group/fs quota is based on the
primary group in AD, which is "Domain User" for all my users, and I don't
have the rights to modify this.  Besides, there may be situations where a
single user may have multiple group memberships with differing quotas.  So,
I then created nested fs's under the "group" fs and set generic quotas on
those.  In the end, this more accuratley accomplishes what I wanted to do
but.....

Two bad things happened.  ACL inheritance broke and ABE broke.

ACL of the nested fs reverted to the default ACL (@owner, @group,
@everyone) instead of inheriting from "group".  I was able to work around
this by manually setting my admin account permissions on the server (could
have also used root), then via windows adding the additional users/groups.
But when I did this, it "rediscovered the inherited permissions from
"group", so had two entries.  I just deleted the non-inherited entries.  It
seems like I'd have to do this for every group nested fs.  Is there an
easier way to do this?

I also noticed that the nested fs, which shouldn't be visible because of
ABE, are now visible.  The security settings is properly blocking access,
but I don't want them seen if the user doesn't have access.  I have not
been able to fix this.  Any ideas here?


Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140127/7fa8abe3/attachment.html>

From mofta7y at gmail.com  Tue Jan 28 19:39:08 2014
From: mofta7y at gmail.com (moftah moftah)
Date: Tue, 28 Jan 2014 14:39:08 -0500
Subject: [OmniOS-discuss] no access issue through ssh or through physical
	console
Message-ID: <CAPFC4Rzr9cTUKc_okFD8XOMRU=h8H=VdBn=wkPcK=8vVHuKTvg@mail.gmail.com>

Hi all,

We have an issue in our omniOS installation.

We use the server as storage server (ZFS) with NFS.

the server works great and never crashed actually.

but we have very strange issue that after few days we are unable to ssh ,
http or even directly console access the server.

the console of the server when connecting a screen or using the IPMI will
show the normal black window where we can type anything but its like typing
in vi window nothing will happen.

while in this situation the NFS server is running ok with no dropped
performance.

the only way to go out of this situation is to hard reboot the server

is there any way to find out why this happens (I have 2 identical
supermicro servers and the issue is reproducible in both servers actually)
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140128/985e78ed/attachment.html>

From cks at cs.toronto.edu  Tue Jan 28 20:34:41 2014
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Tue, 28 Jan 2014 15:34:41 -0500
Subject: [OmniOS-discuss] Bug in 'zfs userspace -t ....'
Message-ID: <20140128203441.EA51A1A0252@apps0.cs.toronto.edu>

 zfs userspace -t <type> is documented as taking 'posixuser' as a type,
and this is traditional Solaris 10 behavior. In OmniOS r151008j, this
gets:
	# zfs userspace -t posixuser -H -o used,name -s name -p rpool/ROOT
	invalid type 'posixuser' for -t option

Inspection of /usr/sbin/zfs with 'strings' shows that somehow it has
become 'posxiuser' (and testing shows that this works). This change
doesn't appear to be in the current Illumos upstream and I can't see
any changeset related to this in a casual browse.

	- cks

From mark at omniti.com  Tue Jan 28 20:43:56 2014
From: mark at omniti.com (Mark Harrison)
Date: Tue, 28 Jan 2014 15:43:56 -0500
Subject: [OmniOS-discuss] Bug in 'zfs userspace -t ....'
In-Reply-To: <20140128203441.EA51A1A0252@apps0.cs.toronto.edu>
References: <20140128203441.EA51A1A0252@apps0.cs.toronto.edu>
Message-ID: <CABC3qWdW-HnvbRByxsCmFM5RB05+rYMZ-ijjGGiqDQWS9MpDKg@mail.gmail.com>

https://www.illumos.org/issues/4208

Looks like it made it into 151008, and the fix hasn't yet.

On Tue, Jan 28, 2014 at 3:34 PM, Chris Siebenmann <cks at cs.toronto.edu> wrote:
>  zfs userspace -t <type> is documented as taking 'posixuser' as a type,
> and this is traditional Solaris 10 behavior. In OmniOS r151008j, this
> gets:
>         # zfs userspace -t posixuser -H -o used,name -s name -p rpool/ROOT
>         invalid type 'posixuser' for -t option
>
> Inspection of /usr/sbin/zfs with 'strings' shows that somehow it has
> become 'posxiuser' (and testing shows that this works). This change
> doesn't appear to be in the current Illumos upstream and I can't see
> any changeset related to this in a casual browse.
>
>         - cks
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Mark Harrison
Lead Site Reliability Engineer
OmniTI

From dave-oo at pooserville.com  Tue Jan 28 21:12:37 2014
From: dave-oo at pooserville.com (Dave Pooser)
Date: Tue, 28 Jan 2014 15:12:37 -0600
Subject: [OmniOS-discuss] no access issue through ssh or through
 physical console
In-Reply-To: <CAPFC4Rzr9cTUKc_okFD8XOMRU=h8H=VdBn=wkPcK=8vVHuKTvg@mail.gmail.com>
Message-ID: <CF0D791E.D5C20%dave-oo@pooserville.com>

(resending because I left the list off last time)

>We have an issue in our omniOS installation.
>
>We use the server as storage server (ZFS) with NFS.
>
>the server works great and never crashed actually.
>
>but we have very strange issue that after few days we are unable to ssh ,
>http or even directly console access the server.
>
>the console of the server when connecting a screen or using the IPMI will
>show the normal black window where we can type anything but its like
>typing in vi window nothing will happen.
>
>while in this situation the NFS server is running ok with no dropped
>performance.
>
>the only way to go out of this situation is to hard reboot the server
>
>is there any way to find out why this happens (I have 2 identical
>supermicro servers and the issue is reproducible in both servers actually)

If you make an ssh connection to the server when it's working fine, and
then leave that connection open until the server issue reappears, does
that existing SSH connection still work, or does it go deaf?
-- 
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna




From dave-oo at pooserville.com  Tue Jan 28 21:17:14 2014
From: dave-oo at pooserville.com (Dave Pooser)
Date: Tue, 28 Jan 2014 15:17:14 -0600
Subject: [OmniOS-discuss] no access issue through ssh or through
 physical console
In-Reply-To: <CAPFC4Rx2_70NvCdKr_J+Q2o-w0wB661FK-D4yZBFvvbbmkFsQA@mail.gmail.com>
References: <CAPFC4Rzr9cTUKc_okFD8XOMRU=h8H=VdBn=wkPcK=8vVHuKTvg@mail.gmail.com>
	<CF0D765D.D5C08%dave-sa@pooserville.com>
	<CAPFC4Rx2_70NvCdKr_J+Q2o-w0wB661FK-D4yZBFvvbbmkFsQA@mail.gmail.com>
Message-ID: <CF0D79A7.D5C26%dave-sa@pooserville.com>

>never tried it.
>but the problem that this server is behind a vpn and maintaining an ssh
>connection to it without dropping for days in not easy

Is there another server behind the VPN, running Linux or Windows or
something, that you could use to ssh in to the OmniOS box? Then when the
OmniOS box goes deaf, use IPMI/VNC to get to the existing session....
-- 
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com



From mofta7y at gmail.com  Tue Jan 28 22:01:07 2014
From: mofta7y at gmail.com (moftah moftah)
Date: Tue, 28 Jan 2014 17:01:07 -0500
Subject: [OmniOS-discuss] no access issue through ssh or through
	physical console
In-Reply-To: <CF0D79A7.D5C26%dave-sa@pooserville.com>
References: <CAPFC4Rzr9cTUKc_okFD8XOMRU=h8H=VdBn=wkPcK=8vVHuKTvg@mail.gmail.com>
	<CF0D765D.D5C08%dave-sa@pooserville.com>
	<CAPFC4Rx2_70NvCdKr_J+Q2o-w0wB661FK-D4yZBFvvbbmkFsQA@mail.gmail.com>
	<CF0D79A7.D5C26%dave-sa@pooserville.com>
Message-ID: <CAPFC4RyCmVyF=8XfC2wnr031_UVpQ86xA7+S1AtF-6rNi-6isg@mail.gmail.com>

just checked the other spare server that i was hopping it will have the
same issue.

I didnt have it while it is running for 3 weeks.

So that is bad for this case as i wanted to check and ply with the test
server and make the changes with the real production server.

is there anywhere to read the logs to understand what is the issue ?
I mean what are the debugging steps here in this case

Thanks


On Tue, Jan 28, 2014 at 4:17 PM, Dave Pooser <dave-oo at pooserville.com>wrote:

> >never tried it.
> >but the problem that this server is behind a vpn and maintaining an ssh
> >connection to it without dropping for days in not easy
>
> Is there another server behind the VPN, running Linux or Windows or
> something, that you could use to ssh in to the OmniOS box? Then when the
> OmniOS box goes deaf, use IPMI/VNC to get to the existing session....
> --
> Dave Pooser
> Cat-Herder-in-Chief, Pooserville.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140128/66871cc5/attachment.html>

From lists at marzocchi.net  Tue Jan 28 22:48:33 2014
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Tue, 28 Jan 2014 23:48:33 +0100
Subject: [OmniOS-discuss] Bug report: java in r151008 missing libjli.so
Message-ID: <61DB66AC-15F2-4D71-B927-0903B1061D84@marzocchi.net>

Hello,
?java? doesn?t work in r151008 (libjli.so not found) unless the dev package is installed.
Check:

$ java  
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
$ env
TERM=xterm-256color
SHELL=/bin/bash
CLICOLOR=1
LSCOLORS=gxfxcxdxbxegedabagacad
PATH=/usr/bin:/bin:/usr/local/bin:/usr/sbin:/opt/omni/bin/
SHLVL=1
_=/usr/bin/env
$ pkg search libjli.so
INDEX      ACTION VALUE                               PACKAGE
basename   file   usr/java/lib/i386/jli/libjli.so     pkg:/developer/java/jdk at 0.5.11-0.151008
basename   file   usr/java/jre/lib/i386/jli/libjli.so pkg:/runtime/java at 0.5.11-0.151008
$ 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
$ ldd -s `which java`
?
   find object=libjli.so; required by /usr/java/bin/java
    search path=$ORIGIN/../lib/i386/jli:/usr/openwin/lib  (RUNPATH/RPATH from file /usr/java/bin/java)
    trying path=/usr/java/bin/../lib/i386/jli/libjli.so
    trying path=/usr/openwin/lib/libjli.so
    search path=/lib:/usr/lib:/usr/local/lib  (configuration default - /var/ld/ld.config)
    trying path=/lib/libjli.so
    trying path=/usr/lib/libjli.so
    trying path=/usr/local/lib/libjli.so
	libjli.so =>	 (file not found)
?

It is not found because the file is not in /usr/java/bin/../lib/i386/jli/libjli.so but in /usr/java/bin/../jre/lib/i386/jli/libjli.so (the difference is ?/jre?).

After installing the dev package, everything is fine.
The standard package has been linked on the dev libraries.
Checked on a clean install.

I don?t know whether this also bring lower performances (I expect a dev lib to be slower, but I?m no expert).

Regards
Olaf

From christian.flaig at gmail.com  Wed Jan 29 11:35:26 2014
From: christian.flaig at gmail.com (Christian Flaig)
Date: Wed, 29 Jan 2014 12:35:26 +0100
Subject: [OmniOS-discuss] Set locale in zone
Message-ID: <D4AEB7B5-4C1C-4C47-AFE1-D97178CFAB88@gmail.com>

Hello,

I'm still on r15006, will migrate/re-install soon.
I've created a new zone, and can't set the locale from "C" to "en_GB.UTF-8" for that zone. The global zone has this setting, but I haven't found out how to configure it (in non-global zone) or where it is configured (global zone).

I've tried the following:
(1) /etc/default/init
According to several instructions on the web, this is the place where I should put my locale configuration. I can define all the variables, but the system doesn't take them (command "locale" still shows "C"). A comment in the OpenIndiana Wiki mentions somethings about facets in SVC though (see 2).
(2) Facets
I read about the new way of setting locale in Solaris 11, and thought it might work the same way in OmniOS now. So I did "pkg facet", couldn't find my locale setting (GB) and enabled it with "pkg change-facet 'facet.locale.en_GB=True' ".
But then the Solaris docs mention a svc service to be adjusted, and that one is not available on OmniOS it seems (at least not in a default installation): svccfg -s svc:/system/environment:init setprop 
environment/LANG = astring: en_GB.UTF-8

I'm still puzzled that I can't find where to configure this. I did a search on my locale on /etc in my global zone (where it's correctly configured), but couldn't find anything.

Thanks alot for your help.

Chris

From lotheac at iki.fi  Wed Jan 29 13:37:58 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 29 Jan 2014 15:37:58 +0200
Subject: [OmniOS-discuss] Set locale in zone
In-Reply-To: <D4AEB7B5-4C1C-4C47-AFE1-D97178CFAB88@gmail.com>
References: <D4AEB7B5-4C1C-4C47-AFE1-D97178CFAB88@gmail.com>
Message-ID: <20140129133758.GA8324@gutsman.lotheac.fi>

On Wed, Jan 29 2014 12:35:26 +0100, Christian Flaig wrote:
> I'm still on r15006, will migrate/re-install soon.
> I've created a new zone, and can't set the locale from "C" to
> "en_GB.UTF-8" for that zone. The global zone has this setting, but I
> haven't found out how to configure it (in non-global zone) or where it
> is configured (global zone).
> 
> I've tried the following:
> (1) /etc/default/init
> According to several instructions on the web, this is the place where
> I should put my locale configuration. I can define all the variables,
> but the system doesn't take them (command "locale" still shows "C").

This works for me. You probably need to restart the zone for changes to
take effect though. Tested as follows:

    # pargs -e $(pgrep -z kekkonen svc.startd)
    5193:       /lib/svc/bin/svc.startd
    envp[0]: _=*5088*/lib/svc/bin/svc.startd
    envp[1]: LANG=en_US.UTF-8
    envp[2]: LC_TIME=C
    envp[3]: PATH=/usr/sbin:/usr/bin
    envp[4]: PWD=/
    envp[5]: SHLVL=1
    envp[6]: TZ=Europe/Helsinki
    envp[7]: A__z="*SHLVL

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

From lotheac at iki.fi  Wed Jan 29 13:40:58 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 29 Jan 2014 15:40:58 +0200
Subject: [OmniOS-discuss] system/fm/smtp-notify mailing about
	already-resolved events on boot
Message-ID: <20140129134058.GB8324@gutsman.lotheac.fi>

smtp-notify seems to be generating emails for every recorded diagnosed
event upon system boot, even when those faults have been repaired or
resolved long since. We're on r151006.

This seems like a bug - is anyone else seeing this?

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

From esproul at omniti.com  Wed Jan 29 15:06:22 2014
From: esproul at omniti.com (Eric Sproul)
Date: Wed, 29 Jan 2014 10:06:22 -0500
Subject: [OmniOS-discuss] Set locale in zone
In-Reply-To: <20140129133758.GA8324@gutsman.lotheac.fi>
References: <D4AEB7B5-4C1C-4C47-AFE1-D97178CFAB88@gmail.com>
	<20140129133758.GA8324@gutsman.lotheac.fi>
Message-ID: <CA+QY2RQRKwdNWO_mOZemBAjO43z_b+3LganFx=tuFBCqZdFD-g@mail.gmail.com>

On Wed, Jan 29, 2014 at 8:37 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:
> On Wed, Jan 29 2014 12:35:26 +0100, Christian Flaig wrote:
>> I'm still on r15006, will migrate/re-install soon.
>> I've created a new zone, and can't set the locale from "C" to
>> "en_GB.UTF-8" for that zone. The global zone has this setting, but I
>> haven't found out how to configure it (in non-global zone) or where it
>> is configured (global zone).
>>
>> I've tried the following:
>> (1) /etc/default/init
>> According to several instructions on the web, this is the place where
>> I should put my locale configuration. I can define all the variables,
>> but the system doesn't take them (command "locale" still shows "C").
>
> This works for me. You probably need to restart the zone for changes to
> take effect though. Tested as follows:
>
>     # pargs -e $(pgrep -z kekkonen svc.startd)
>     5193:       /lib/svc/bin/svc.startd
>     envp[0]: _=*5088*/lib/svc/bin/svc.startd
>     envp[1]: LANG=en_US.UTF-8
>     envp[2]: LC_TIME=C
>     envp[3]: PATH=/usr/sbin:/usr/bin
>     envp[4]: PWD=/
>     envp[5]: SHLVL=1
>     envp[6]: TZ=Europe/Helsinki
>     envp[7]: A__z="*SHLVL

You should also try to test over a connection that is not ssh, such as
zlogin from the global zone.  OpenSSH clients are frequently
configured by default to send the client's environment variables to
the server (this is a feature of the SSH protocol version 2).  See the
"SendEnv" setting in your ssh_config man page.  This tripped up
another of our users recently.

Unfortunately, our ssh daemon ("SunSSH"), having been forked quite a
long time ago from OpenSSH, does not have the corresponding AcceptEnv
server-side control, which could be used prevent clients from sending
certain environment variables if you so choose, so for now you'd need
to make sure your ssh client doesn't override the server's locale
environment.

Eric

From esproul at omniti.com  Wed Jan 29 17:26:04 2014
From: esproul at omniti.com (Eric Sproul)
Date: Wed, 29 Jan 2014 12:26:04 -0500
Subject: [OmniOS-discuss] Set locale in zone
In-Reply-To: <cc8cff4840c1e6e55fbe00f2738b119a.squirrel@fruiteater.riseup.net>
References: <D4AEB7B5-4C1C-4C47-AFE1-D97178CFAB88@gmail.com>
	<20140129133758.GA8324@gutsman.lotheac.fi>
	<CA+QY2RQRKwdNWO_mOZemBAjO43z_b+3LganFx=tuFBCqZdFD-g@mail.gmail.com>
	<cc8cff4840c1e6e55fbe00f2738b119a.squirrel@fruiteater.riseup.net>
Message-ID: <CA+QY2RShdMNDKF+naG=UVgVEJU_V2NGZNno5ymYZk-BSstMVwg@mail.gmail.com>

On Wed, Jan 29, 2014 at 11:34 AM, Rodney A. Mendez <ramendez at riseup.net> wrote:
> Is there some good history there about why illumos has yet to reconcile
> with upstream OpenSSH?

The short answer: no one qualified has stepped up to maintain SunSSH,
which is divergent enough from OpenSSH that maintenance is
non-trivial.  It's all open source, though, so anyone could.  There be
dragons, though, and as it's such a key component of any server system
now, and it involves crypto, we need a great deal of trust in whatever
updates come out of it.

You can search for previous discussions on the illumos mailing lists,
but this document describes the reason for the fork:
http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/ssh/README.altprivsep

Eric

From Kevin.Swab at ColoState.EDU  Wed Jan 29 18:00:43 2014
From: Kevin.Swab at ColoState.EDU (Kevin Swab)
Date: Wed, 29 Jan 2014 11:00:43 -0700
Subject: [OmniOS-discuss] system/fm/smtp-notify mailing about
 already-resolved events on boot
In-Reply-To: <20140129134058.GB8324@gutsman.lotheac.fi>
References: <20140129134058.GB8324@gutsman.lotheac.fi>
Message-ID: <52E941CB.6050409@ColoState.EDU>

We have this issue too.  For us, it happens on all versions of OmniOS up
through r151008 (and all versions of OpenIndiana we've tried too).

It will stop if you clear all the fault management logs using a
procedure like this:

https://blogs.oracle.com/unixgeek/entry/how_to_clear_fmadm_log

But this seems a bit drastic.  A fix would be most welcome!

Kevin



On 01/29/2014 06:40 AM, Lauri Tirkkonen wrote:
> smtp-notify seems to be generating emails for every recorded diagnosed
> event upon system boot, even when those faults have been repaired or
> resolved long since. We're on r151006.
> 
> This seems like a bug - is anyone else seeing this?
> 

-- 
-------------------------------------------------------------------
Kevin Swab                          UNIX Systems Administrator
ACNS                                Colorado State University
Phone: (970)491-6572                Email: Kevin.Swab at ColoState.EDU
GPG Fingerprint: 7026 3F66 A970 67BD 6F17  8EB8 8A7D 142F 2392 791C

From zembower at criterion.com  Wed Jan 29 18:38:24 2014
From: zembower at criterion.com (Chris Zembower)
Date: Wed, 29 Jan 2014 13:38:24 -0500
Subject: [OmniOS-discuss] Illumos and Infiniband
Message-ID: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>

Hello,

I'm trying to dig up some information on Illumos (or Solaris) compatibility
with the Mellanox ConnectX-3 VPI HCA. From what I can gather, the Hermon
driver (for 1st-gen ConnectX) may work with this hardware with tweaking,
but I can't seem to confirm that.

OmniOS is my server OS of choice (I have several systems running), but the
necessity of a working IB fabric here has led me to implement a ZFS on
Linux box for this particular purpose. I'm currently using LIO/targetcli to
export block SRP targets, and I'm not happy with it at all. Really wishing
I had Comstar for this.

Anyone here using IB with OmniOS? Anyone aware of a roadmap or active
development of new IB drivers? Why isn't there an Illumos OFED port
happening? No interest? It's thriving on the Linux side of the world...

Please don't lecture me on the merits of 10GbE/FC over Infiniband, I've
heard it all. :-)

Any insights or suggestions are very much appreciated!

Best,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140129/710cd9f2/attachment.html>

From dswartz at druber.com  Wed Jan 29 18:45:46 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Wed, 29 Jan 2014 13:45:46 -0500
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
Message-ID: <2b3ee868d32b00c124bf3f341a7f7f3b.squirrel@webmail.druber.com>


Chris, I totally understand where you are coming from. Linux has all the
latest and greatest goodies, but still is not stable for ZFS for my use
cases.  Illumos (and OI and etc) all work out of the box and stably, but
drivers for things like this, well...


From skiselkov.ml at gmail.com  Wed Jan 29 18:50:27 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Wed, 29 Jan 2014 18:50:27 +0000
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
Message-ID: <52E94D73.7060806@gmail.com>

On 1/29/14, 6:38 PM, Chris Zembower wrote:
> Please don't lecture me on the merits of 10GbE/FC over Infiniband, I've
> heard it all. :-)

You're not alone in your appreciation of IB's brute strength. As for why
stuff isn't happening, my guess is lack of manpower - we're a really
small community and people work on what they like, plus what they can
get their hands on (and IB gear is a little exotic). That being said,
I'd love to have a mature and up-to-date IB stack on Illumos that could
be used in production. It's sorely needed.

Cheers,
-- 
Saso

From christian.flaig at gmail.com  Wed Jan 29 18:53:12 2014
From: christian.flaig at gmail.com (Christian Flaig)
Date: Wed, 29 Jan 2014 19:53:12 +0100
Subject: [OmniOS-discuss] Set locale in zone
In-Reply-To: <CA+QY2RQRKwdNWO_mOZemBAjO43z_b+3LganFx=tuFBCqZdFD-g@mail.gmail.com>
References: <D4AEB7B5-4C1C-4C47-AFE1-D97178CFAB88@gmail.com>
	<20140129133758.GA8324@gutsman.lotheac.fi>
	<CA+QY2RQRKwdNWO_mOZemBAjO43z_b+3LganFx=tuFBCqZdFD-g@mail.gmail.com>
Message-ID: <3F7B98BA-8C7B-4CA8-8BF5-E2ABB415AED3@gmail.com>

Thanks for all your help!

I will now separate global zone and non-global zone, easier for me to report back.

Global zone
Eric, thanks, you were right about the global zone, ssh and taking settings from ssh client machine. Once I used IPMI to log into the machine, I had LANG and all LC_* on "C" again. So that explains why I couldn't find any configuration for my locale setting. I changed/added LANG and LC_ALL in /etc/default/init. Can't reboot right now, so need to wait for any impact.

Non-global zone
So I configured /etc/default/init again, like global zone above. Reboot. Logged into zone with zlogin, and got all locales on "C" again (ran command "locale"). Ran Lauri's command and it showed the wanted locale on LANG and LC_ALL. 

So I'm confused. "locale" always shows "C" or the setting of my SSH client machine, no change whatever I do. Lauri's command shows the right setting. And my application running in the zone seems to be happy with the new locale too.

Is there a bug or something in locale? I understand that I can set LANG and LC_* also as env variables, where would I do that for a system, not only for one user?

Thanks for your help.

Regards,

Chris

On 29 Jan 2014, at 16:06, Eric Sproul <esproul at omniti.com> wrote:

> On Wed, Jan 29, 2014 at 8:37 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:
>> On Wed, Jan 29 2014 12:35:26 +0100, Christian Flaig wrote:
>>> I'm still on r15006, will migrate/re-install soon.
>>> I've created a new zone, and can't set the locale from "C" to
>>> "en_GB.UTF-8" for that zone. The global zone has this setting, but I
>>> haven't found out how to configure it (in non-global zone) or where it
>>> is configured (global zone).
>>> 
>>> I've tried the following:
>>> (1) /etc/default/init
>>> According to several instructions on the web, this is the place where
>>> I should put my locale configuration. I can define all the variables,
>>> but the system doesn't take them (command "locale" still shows "C").
>> 
>> This works for me. You probably need to restart the zone for changes to
>> take effect though. Tested as follows:
>> 
>>    # pargs -e $(pgrep -z kekkonen svc.startd)
>>    5193:       /lib/svc/bin/svc.startd
>>    envp[0]: _=*5088*/lib/svc/bin/svc.startd
>>    envp[1]: LANG=en_US.UTF-8
>>    envp[2]: LC_TIME=C
>>    envp[3]: PATH=/usr/sbin:/usr/bin
>>    envp[4]: PWD=/
>>    envp[5]: SHLVL=1
>>    envp[6]: TZ=Europe/Helsinki
>>    envp[7]: A__z="*SHLVL
> 
> You should also try to test over a connection that is not ssh, such as
> zlogin from the global zone.  OpenSSH clients are frequently
> configured by default to send the client's environment variables to
> the server (this is a feature of the SSH protocol version 2).  See the
> "SendEnv" setting in your ssh_config man page.  This tripped up
> another of our users recently.
> 
> Unfortunately, our ssh daemon ("SunSSH"), having been forked quite a
> long time ago from OpenSSH, does not have the corresponding AcceptEnv
> server-side control, which could be used prevent clients from sending
> certain environment variables if you so choose, so for now you'd need
> to make sure your ssh client doesn't override the server's locale
> environment.
> 
> Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140129/1c2d37b7/attachment.html>

From ikaufman at eng.ucsd.edu  Wed Jan 29 19:06:36 2014
From: ikaufman at eng.ucsd.edu (Ian Kaufman)
Date: Wed, 29 Jan 2014 11:06:36 -0800
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <52E94D73.7060806@gmail.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
	<52E94D73.7060806@gmail.com>
Message-ID: <CAPJtH1jwr7Zwg7kDP4XvYT7-JrDpm-d7k=O5yr=2r4AbEf3rYw@mail.gmail.com>

I use OminOS and IB, and ran into the ConnectX-3 driver issues as we
were moving towards interfaces that can use QDR, FDR, 10GbE, or 40GbE,
depending on drivers and fabric. We had to go back to ConnectX-2 QDR
to get it all working. I was able to hack things to at least get the
NIC identified, but obviously the drivers were not there.

I was contemplating building OFED from source, but I don't have the time.

Ian

On Wed, Jan 29, 2014 at 10:50 AM, Saso Kiselkov <skiselkov.ml at gmail.com> wrote:
> On 1/29/14, 6:38 PM, Chris Zembower wrote:
>> Please don't lecture me on the merits of 10GbE/FC over Infiniband, I've
>> heard it all. :-)
>
> You're not alone in your appreciation of IB's brute strength. As for why
> stuff isn't happening, my guess is lack of manpower - we're a really
> small community and people work on what they like, plus what they can
> get their hands on (and IB gear is a little exotic). That being said,
> I'd love to have a mature and up-to-date IB stack on Illumos that could
> be used in production. It's sorely needed.
>
> Cheers,
> --
> Saso
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu

From mark at omniti.com  Wed Jan 29 19:11:58 2014
From: mark at omniti.com (Mark Harrison)
Date: Wed, 29 Jan 2014 14:11:58 -0500
Subject: [OmniOS-discuss] Set locale in zone
In-Reply-To: <3F7B98BA-8C7B-4CA8-8BF5-E2ABB415AED3@gmail.com>
References: <D4AEB7B5-4C1C-4C47-AFE1-D97178CFAB88@gmail.com>
	<20140129133758.GA8324@gutsman.lotheac.fi>
	<CA+QY2RQRKwdNWO_mOZemBAjO43z_b+3LganFx=tuFBCqZdFD-g@mail.gmail.com>
	<3F7B98BA-8C7B-4CA8-8BF5-E2ABB415AED3@gmail.com>
Message-ID: <CABC3qWdryXYVq8TshM7HiaQLSH6s+SYK=ZUWJ==uBjRqJDTomg@mail.gmail.com>

It appears that zlogin also messes with the environment, only in this
case it generates an environment with only a select few variables set
(LOGNAME, HOME, SHELL, MAIL), which leaves LANG unset (and locale uses
the environment to determine the values it prints out), so it looks
like zlogin -C is the only way to verify the locale on a zone.

As for system wide variables, somewhere like /etc/profile would
probably do the trick.

On Wed, Jan 29, 2014 at 1:53 PM, Christian Flaig
<christian.flaig at gmail.com> wrote:
> Thanks for all your help!
>
> I will now separate global zone and non-global zone, easier for me to report
> back.
>
> Global zone
> Eric, thanks, you were right about the global zone, ssh and taking settings
> from ssh client machine. Once I used IPMI to log into the machine, I had
> LANG and all LC_* on "C" again. So that explains why I couldn't find any
> configuration for my locale setting. I changed/added LANG and LC_ALL in
> /etc/default/init. Can't reboot right now, so need to wait for any impact.
>
> Non-global zone
> So I configured /etc/default/init again, like global zone above. Reboot.
> Logged into zone with zlogin, and got all locales on "C" again (ran command
> "locale"). Ran Lauri's command and it showed the wanted locale on LANG and
> LC_ALL.
>
> So I'm confused. "locale" always shows "C" or the setting of my SSH client
> machine, no change whatever I do. Lauri's command shows the right setting.
> And my application running in the zone seems to be happy with the new locale
> too.
>
> Is there a bug or something in locale? I understand that I can set LANG and
> LC_* also as env variables, where would I do that for a system, not only for
> one user?
>
> Thanks for your help.
>
> Regards,
>
> Chris
>
> On 29 Jan 2014, at 16:06, Eric Sproul <esproul at omniti.com> wrote:
>
> On Wed, Jan 29, 2014 at 8:37 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:
>
> On Wed, Jan 29 2014 12:35:26 +0100, Christian Flaig wrote:
>
> I'm still on r15006, will migrate/re-install soon.
> I've created a new zone, and can't set the locale from "C" to
> "en_GB.UTF-8" for that zone. The global zone has this setting, but I
> haven't found out how to configure it (in non-global zone) or where it
> is configured (global zone).
>
> I've tried the following:
> (1) /etc/default/init
> According to several instructions on the web, this is the place where
> I should put my locale configuration. I can define all the variables,
> but the system doesn't take them (command "locale" still shows "C").
>
>
> This works for me. You probably need to restart the zone for changes to
> take effect though. Tested as follows:
>
>    # pargs -e $(pgrep -z kekkonen svc.startd)
>    5193:       /lib/svc/bin/svc.startd
>    envp[0]: _=*5088*/lib/svc/bin/svc.startd
>    envp[1]: LANG=en_US.UTF-8
>    envp[2]: LC_TIME=C
>    envp[3]: PATH=/usr/sbin:/usr/bin
>    envp[4]: PWD=/
>    envp[5]: SHLVL=1
>    envp[6]: TZ=Europe/Helsinki
>    envp[7]: A__z="*SHLVL
>
>
> You should also try to test over a connection that is not ssh, such as
> zlogin from the global zone.  OpenSSH clients are frequently
> configured by default to send the client's environment variables to
> the server (this is a feature of the SSH protocol version 2).  See the
> "SendEnv" setting in your ssh_config man page.  This tripped up
> another of our users recently.
>
> Unfortunately, our ssh daemon ("SunSSH"), having been forked quite a
> long time ago from OpenSSH, does not have the corresponding AcceptEnv
> server-side control, which could be used prevent clients from sending
> certain environment variables if you so choose, so for now you'd need
> to make sure your ssh client doesn't override the server's locale
> environment.
>
> Eric
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 
Mark Harrison
Lead Site Reliability Engineer
OmniTI

From turbo124 at gmail.com  Wed Jan 29 19:17:11 2014
From: turbo124 at gmail.com (David Bomba)
Date: Thu, 30 Jan 2014 06:17:11 +1100
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
Message-ID: <CACS0AjHzFtZoUVMKuMTEN0aX08nZXfPE35sKS=7FfNqvKv46dA@mail.gmail.com>

Hi Chris,

We have an environment running OmniOS with both ConnectX and ConnectX-2
cards. The Hermon and Tavor drivers work very well.

The only problem we had was that the CX-2 cards would only sync at 20gb/s.
We export Comstar iSER targets and they have been rock solid for us for
over a year.

Dave


On 30 January 2014 05:38, Chris Zembower <zembower at criterion.com> wrote:

>
> Hello,
>
> I'm trying to dig up some information on Illumos (or Solaris)
> compatibility with the Mellanox ConnectX-3 VPI HCA. From what I can gather,
> the Hermon driver (for 1st-gen ConnectX) may work with this hardware with
> tweaking, but I can't seem to confirm that.
>
> OmniOS is my server OS of choice (I have several systems running), but the
> necessity of a working IB fabric here has led me to implement a ZFS on
> Linux box for this particular purpose. I'm currently using LIO/targetcli to
> export block SRP targets, and I'm not happy with it at all. Really wishing
> I had Comstar for this.
>
> Anyone here using IB with OmniOS? Anyone aware of a roadmap or active
> development of new IB drivers? Why isn't there an Illumos OFED port
> happening? No interest? It's thriving on the Linux side of the world...
>
> Please don't lecture me on the merits of 10GbE/FC over Infiniband, I've
> heard it all. :-)
>
> Any insights or suggestions are very much appreciated!
>
> Best,
> Chris
>
> _______________________________________________
> 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: <https://omniosce.org/ml-archive/attachments/20140130/6c403a14/attachment.html>

From ikaufman at eng.ucsd.edu  Wed Jan 29 19:24:49 2014
From: ikaufman at eng.ucsd.edu (Ian Kaufman)
Date: Wed, 29 Jan 2014 11:24:49 -0800
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <CACS0AjHzFtZoUVMKuMTEN0aX08nZXfPE35sKS=7FfNqvKv46dA@mail.gmail.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
	<CACS0AjHzFtZoUVMKuMTEN0aX08nZXfPE35sKS=7FfNqvKv46dA@mail.gmail.com>
Message-ID: <CAPJtH1hW1OOw5r8+q7AouBVQDYXxrm9rk5C0-BQxq2=fT5=HKA@mail.gmail.com>

On my systems, the X-2 cards claim 32 gbps. I sued IPoIB, and have
seen transfers NFS transfers over 6 gbps and snapshot send/receive as
high as 1.8 gbps while the system was simultaneously utilized during
cluster computation.

Ian

On Wed, Jan 29, 2014 at 11:17 AM, David Bomba <turbo124 at gmail.com> wrote:
> Hi Chris,
>
> We have an environment running OmniOS with both ConnectX and ConnectX-2
> cards. The Hermon and Tavor drivers work very well.
>
> The only problem we had was that the CX-2 cards would only sync at 20gb/s.
> We export Comstar iSER targets and they have been rock solid for us for over
> a year.
>
> Dave
>
>
> On 30 January 2014 05:38, Chris Zembower <zembower at criterion.com> wrote:
>>
>>
>> Hello,
>>
>> I'm trying to dig up some information on Illumos (or Solaris)
>> compatibility with the Mellanox ConnectX-3 VPI HCA. From what I can gather,
>> the Hermon driver (for 1st-gen ConnectX) may work with this hardware with
>> tweaking, but I can't seem to confirm that.
>>
>> OmniOS is my server OS of choice (I have several systems running), but the
>> necessity of a working IB fabric here has led me to implement a ZFS on Linux
>> box for this particular purpose. I'm currently using LIO/targetcli to export
>> block SRP targets, and I'm not happy with it at all. Really wishing I had
>> Comstar for this.
>>
>> Anyone here using IB with OmniOS? Anyone aware of a roadmap or active
>> development of new IB drivers? Why isn't there an Illumos OFED port
>> happening? No interest? It's thriving on the Linux side of the world...
>>
>> Please don't lecture me on the merits of 10GbE/FC over Infiniband, I've
>> heard it all. :-)
>>
>> Any insights or suggestions are very much appreciated!
>>
>> Best,
>> Chris
>>
>> _______________________________________________
>> 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
>



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu

From dswartz at druber.com  Wed Jan 29 19:42:01 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Wed, 29 Jan 2014 14:42:01 -0500
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <CAPJtH1hW1OOw5r8+q7AouBVQDYXxrm9rk5C0-BQxq2=fT5=HKA@mail.gmail.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
	<CACS0AjHzFtZoUVMKuMTEN0aX08nZXfPE35sKS=7FfNqvKv46dA@mail.gmail.com>
	<CAPJtH1hW1OOw5r8+q7AouBVQDYXxrm9rk5C0-BQxq2=fT5=HKA@mail.gmail.com>
Message-ID: <81d868b80675c38d752d836181a8cad3.squirrel@webmail.druber.com>

> On my systems, the X-2 cards claim 32 gbps. I sued IPoIB, and have
> seen transfers NFS transfers over 6 gbps and snapshot send/receive as
> high as 1.8 gbps while the system was simultaneously utilized during
> cluster computation.
>
> Ian

I assume you meant 'used', not 'sued'?  If not, your lawyer is in the
wrong line of work :)


From ikaufman at eng.ucsd.edu  Wed Jan 29 20:38:13 2014
From: ikaufman at eng.ucsd.edu (Ian Kaufman)
Date: Wed, 29 Jan 2014 12:38:13 -0800
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <81d868b80675c38d752d836181a8cad3.squirrel@webmail.druber.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
	<CACS0AjHzFtZoUVMKuMTEN0aX08nZXfPE35sKS=7FfNqvKv46dA@mail.gmail.com>
	<CAPJtH1hW1OOw5r8+q7AouBVQDYXxrm9rk5C0-BQxq2=fT5=HKA@mail.gmail.com>
	<81d868b80675c38d752d836181a8cad3.squirrel@webmail.druber.com>
Message-ID: <CAPJtH1hBMdJz2fxsj6CiACfowXyVGY83Q8iodCsD2dA_5BnCdw@mail.gmail.com>

Heh - mistype. But that cease and desist we sent to IPoIB ...

:)

On Wed, Jan 29, 2014 at 11:42 AM, Dan Swartzendruber <dswartz at druber.com> wrote:
>> On my systems, the X-2 cards claim 32 gbps. I sued IPoIB, and have
>> seen transfers NFS transfers over 6 gbps and snapshot send/receive as
>> high as 1.8 gbps while the system was simultaneously utilized during
>> cluster computation.
>>
>> Ian
>
> I assume you meant 'used', not 'sued'?  If not, your lawyer is in the
> wrong line of work :)
>



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu

From zembower at criterion.com  Wed Jan 29 20:51:47 2014
From: zembower at criterion.com (Chris Zembower)
Date: Wed, 29 Jan 2014 15:51:47 -0500
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <CAPJtH1hBMdJz2fxsj6CiACfowXyVGY83Q8iodCsD2dA_5BnCdw@mail.gmail.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
	<CACS0AjHzFtZoUVMKuMTEN0aX08nZXfPE35sKS=7FfNqvKv46dA@mail.gmail.com>
	<CAPJtH1hW1OOw5r8+q7AouBVQDYXxrm9rk5C0-BQxq2=fT5=HKA@mail.gmail.com>
	<81d868b80675c38d752d836181a8cad3.squirrel@webmail.druber.com>
	<CAPJtH1hBMdJz2fxsj6CiACfowXyVGY83Q8iodCsD2dA_5BnCdw@mail.gmail.com>
Message-ID: <CAKbxKA84sxwbLVoSh1DhvRE8rZWDF+5xi64u1FTWSjBBKrnPdg@mail.gmail.com>

Well, this is all very encouraging! I guess there is interest and actual
usage out there.

Unfortunately, I need FDR-ish speeds (at least 4GB/s), the entire network
is setup for FDR, and I only have ConnectX-3 adapters, so it's Linux for me
until some new developments emerge.

Dan, I can somewhat vouch for the stability of ZFS on Debian and CentOS
using the ZoL kernel implementation. My Debian system (the one using IB) is
at 65 days uptime with a 24/7 heavy load, managing 100TB+ of datasets in a
quasi-production (replicated) environment. First disk replacement went
smoothly last week. Time will tell... The CentOS install has been up for
close to a year. However, in terms of raw disk access speeds, neither of
these systems performs anywhere near as well as OmniOS or OI.

Thanks, all. I look forward to joining the conversation here in general.



On Wed, Jan 29, 2014 at 3:38 PM, Ian Kaufman <ikaufman at eng.ucsd.edu> wrote:

> Heh - mistype. But that cease and desist we sent to IPoIB ...
>
> :)
>
> On Wed, Jan 29, 2014 at 11:42 AM, Dan Swartzendruber <dswartz at druber.com>
> wrote:
> >> On my systems, the X-2 cards claim 32 gbps. I sued IPoIB, and have
> >> seen transfers NFS transfers over 6 gbps and snapshot send/receive as
> >> high as 1.8 gbps while the system was simultaneously utilized during
> >> cluster computation.
> >>
> >> Ian
> >
> > I assume you meant 'used', not 'sued'?  If not, your lawyer is in the
> > wrong line of work :)
> >
>
>
>
> --
> Ian Kaufman
> Research Systems Administrator
> UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140129/5707de29/attachment.html>

From dswartz at druber.com  Wed Jan 29 20:59:25 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Wed, 29 Jan 2014 15:59:25 -0500
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <CAKbxKA84sxwbLVoSh1DhvRE8rZWDF+5xi64u1FTWSjBBKrnPdg@mail.gmail.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
	<CACS0AjHzFtZoUVMKuMTEN0aX08nZXfPE35sKS=7FfNqvKv46dA@mail.gmail.com>
	<CAPJtH1hW1OOw5r8+q7AouBVQDYXxrm9rk5C0-BQxq2=fT5=HKA@mail.gmail.com>
	<81d868b80675c38d752d836181a8cad3.squirrel@webmail.druber.com>
	<CAPJtH1hBMdJz2fxsj6CiACfowXyVGY83Q8iodCsD2dA_5BnCdw@mail.gmail.com>
	<CAKbxKA84sxwbLVoSh1DhvRE8rZWDF+5xi64u1FTWSjBBKrnPdg@mail.gmail.com>
Message-ID: <36d0aa97198490f9b2d095b39a18f244.squirrel@webmail.druber.com>

> Well, this is all very encouraging! I guess there is interest and actual
> usage out there.
>
> Unfortunately, I need FDR-ish speeds (at least 4GB/s), the entire network
> is setup for FDR, and I only have ConnectX-3 adapters, so it's Linux for
> me
> until some new developments emerge.
>
> Dan, I can somewhat vouch for the stability of ZFS on Debian and CentOS
> using the ZoL kernel implementation. My Debian system (the one using IB)
> is
> at 65 days uptime with a 24/7 heavy load, managing 100TB+ of datasets in a
> quasi-production (replicated) environment. First disk replacement went
> smoothly last week. Time will tell... The CentOS install has been up for
> close to a year. However, in terms of raw disk access speeds, neither of
> these systems performs anywhere near as well as OmniOS or OI.

Chris, let me clarify.  I had this same converasation on a forum somewhere
where some guy got all defensive and borderline-accused me of being an
anti-ZoL troll or something.  Anyway, for basic I/O and serving up NFS
(andmaybe even iSCSI) clients, sure, I agree!  The places it still falls
down (not directly related to ZoL itself) are things where if your HBA is
a little slow off the mark presenting the disks to the ZFS driver, you can
end up with zvols that are not visible, datasets that have to be manually
exported, iscsi target daemon needing to be manually restarted, etc... 
All having to do with bad timing between udev and ZFS.  Oh, also, no zfs
root pool unless you want to slide down a very sharp razor blade...




From zembower at criterion.com  Wed Jan 29 21:05:34 2014
From: zembower at criterion.com (Chris Zembower)
Date: Wed, 29 Jan 2014 16:05:34 -0500
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <36d0aa97198490f9b2d095b39a18f244.squirrel@webmail.druber.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
	<CACS0AjHzFtZoUVMKuMTEN0aX08nZXfPE35sKS=7FfNqvKv46dA@mail.gmail.com>
	<CAPJtH1hW1OOw5r8+q7AouBVQDYXxrm9rk5C0-BQxq2=fT5=HKA@mail.gmail.com>
	<81d868b80675c38d752d836181a8cad3.squirrel@webmail.druber.com>
	<CAPJtH1hBMdJz2fxsj6CiACfowXyVGY83Q8iodCsD2dA_5BnCdw@mail.gmail.com>
	<CAKbxKA84sxwbLVoSh1DhvRE8rZWDF+5xi64u1FTWSjBBKrnPdg@mail.gmail.com>
	<36d0aa97198490f9b2d095b39a18f244.squirrel@webmail.druber.com>
Message-ID: <CAKbxKA_TybvvFG++2M6EkQP8Gt+ath=Z_Jn35ViL=GVRtO3uXw@mail.gmail.com>

Totally agreed on all fronts, and many, many more. That's why I emailed the
list!


On Wed, Jan 29, 2014 at 3:59 PM, Dan Swartzendruber <dswartz at druber.com>wrote:

> > Well, this is all very encouraging! I guess there is interest and actual
> > usage out there.
> >
> > Unfortunately, I need FDR-ish speeds (at least 4GB/s), the entire network
> > is setup for FDR, and I only have ConnectX-3 adapters, so it's Linux for
> > me
> > until some new developments emerge.
> >
> > Dan, I can somewhat vouch for the stability of ZFS on Debian and CentOS
> > using the ZoL kernel implementation. My Debian system (the one using IB)
> > is
> > at 65 days uptime with a 24/7 heavy load, managing 100TB+ of datasets in
> a
> > quasi-production (replicated) environment. First disk replacement went
> > smoothly last week. Time will tell... The CentOS install has been up for
> > close to a year. However, in terms of raw disk access speeds, neither of
> > these systems performs anywhere near as well as OmniOS or OI.
>
> Chris, let me clarify.  I had this same converasation on a forum somewhere
> where some guy got all defensive and borderline-accused me of being an
> anti-ZoL troll or something.  Anyway, for basic I/O and serving up NFS
> (andmaybe even iSCSI) clients, sure, I agree!  The places it still falls
> down (not directly related to ZoL itself) are things where if your HBA is
> a little slow off the mark presenting the disks to the ZFS driver, you can
> end up with zvols that are not visible, datasets that have to be manually
> exported, iscsi target daemon needing to be manually restarted, etc...
> All having to do with bad timing between udev and ZFS.  Oh, also, no zfs
> root pool unless you want to slide down a very sharp razor blade...
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140129/9041aed4/attachment-0001.html>

From nsmith at careyweb.com  Wed Jan 29 21:59:35 2014
From: nsmith at careyweb.com (Nate Smith)
Date: Wed, 29 Jan 2014 16:59:35 -0500
Subject: [OmniOS-discuss] Migrating from OpenIndiana
Message-ID: <00e3cde8-116d-4da5-857c-f24a0883afbe@careyweb.com>

I'm going to migrate the ZFS systems on my OpenIndiana file server to an Omnios based one for greater stability (my Openindiana server seems to lose all network connectivity about once every three months, though all the FC targets stay mounted and accessible). I am running oi_151a7, with version 28 ZFS volumes.  They are presented as block storage Comstar targets over fibre channel.  Should I have any problems migrating these to Omnios? Thanks in advance.
 
-Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140129/2a4634ca/attachment.html>

From narayan.desai at gmail.com  Wed Jan 29 23:00:40 2014
From: narayan.desai at gmail.com (Narayan Desai)
Date: Wed, 29 Jan 2014 17:00:40 -0600
Subject: [OmniOS-discuss] Illumos and Infiniband
In-Reply-To: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
References: <CAKbxKA92Di_0iDnrkDrNFPOJ29xYY96ymH99RzT0a2EhkfxnBA@mail.gmail.com>
Message-ID: <CABweQmK1CPvUDTe5YuLVO4z115HVCCWaFVrbACNp+Q_haAEb8A@mail.gmail.com>

We're running a mixed system with connectX 1 and 2, and IB only cards work
great with the hermon driver. We haven't had any luck with CX3, but hear
that it is possible. Performance has been quite good, and we haven't needed
to worry about it so far (knock on wood)

I did a bunch of digging to figure out the OFED front. Basically:
 - Sun did the port themselves
 - they wrote native drivers that provide a different API than the linux
drivers
 - they took their ball and went home

Mellanox has only had indirect involvement in this, and afaict, there has
never been any open activity on this.

Syoyo Fujita did a forward port of the last public release of the userland
source bits (from sunfreeware.com, iirc), and there is a binary package of
the userland bits that works fine for omnios (at least for us). I haven't
managed to get a full build working myself. This bits are here:
 - github.com/syoyo/solaris-infiniband-tools

Unfortunately, this doesn't do you much good on the CX3 front; the drivers
need to be done/reworked for illumos directly.

We're interested in this in order to build high bandwidth servers; we're
going to need 60-80 gbit in the next year or so, which means RDMA is the
only option.
 -nld


On Wed, Jan 29, 2014 at 12:38 PM, Chris Zembower <zembower at criterion.com>wrote:

>
> Hello,
>
> I'm trying to dig up some information on Illumos (or Solaris)
> compatibility with the Mellanox ConnectX-3 VPI HCA. From what I can gather,
> the Hermon driver (for 1st-gen ConnectX) may work with this hardware with
> tweaking, but I can't seem to confirm that.
>
> OmniOS is my server OS of choice (I have several systems running), but the
> necessity of a working IB fabric here has led me to implement a ZFS on
> Linux box for this particular purpose. I'm currently using LIO/targetcli to
> export block SRP targets, and I'm not happy with it at all. Really wishing
> I had Comstar for this.
>
> Anyone here using IB with OmniOS? Anyone aware of a roadmap or active
> development of new IB drivers? Why isn't there an Illumos OFED port
> happening? No interest? It's thriving on the Linux side of the world...
>
> Please don't lecture me on the merits of 10GbE/FC over Infiniband, I've
> heard it all. :-)
>
> Any insights or suggestions are very much appreciated!
>
> Best,
> Chris
>
> _______________________________________________
> 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: <https://omniosce.org/ml-archive/attachments/20140129/7aaf974a/attachment.html>

From fabio at fabiorabelo.wiki.br  Thu Jan 30 13:18:37 2014
From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=)
Date: Thu, 30 Jan 2014 11:18:37 -0200
Subject: [OmniOS-discuss] create ordinary user
Message-ID: <CAEekY64mZ+kTR=1jdZ7EfqjddxX0YSjOGz717muGjbRwxoCWYA@mail.gmail.com>

Hi to all

I am trying netatalk in an OminOS box, and having problem to create a user ...

All and every how-to that I found in the web refers to an utilitary in
command line from OpenSolaris, but this tool do not exist in OmniOS
...

So, how can I create an ordinary user to authenticate against netatalk ?

Thanks in advance ...


F?bio Rabelo

From matej at zunaj.si  Thu Jan 30 15:54:18 2014
From: matej at zunaj.si (Matej Zerovnik)
Date: Thu, 30 Jan 2014 16:54:18 +0100
Subject: [OmniOS-discuss] Can't copy/rsync to NFS share
Message-ID: <52EA75AA.6040402@zunaj.si>

Hello!!

I'm trying to setup NFS and SMB shares with ACL support and I got into
troubles...

I have a share, that is mounted to linux client over NFSv3 and to
windows client over SMB. My ACL's looks like the following:
https://dl.dropboxusercontent.com/u/5934229/forumi/ACL_for_share.png

What I want is to have a 755 unix permissions on folders and 644
permissions on files. User levak and root have full rights, when they
access the folder from windows. That seems to be properly configured.

Now the problem.

I tried to copy my data from one drive to another. It starts to copy,
but after some time, I start getting errors "cant create file, operation
not permitted":
[CODE]`joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin_src.js'
->
`/omnios/joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin_src.js'
cp: cannot create regular file
`/omnios/joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin_src.js':
Operation not permitted
`joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin.js'
->
`/omnios/joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin.js'
cp: cannot create regular file
`/omnios/joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin.js':
Operation not permitted
[/CODE]

If I cancel the transfer and start again, it goes a little further and
after some 10% more copied files, it starts throwing errors again, and
so on and so on...

The same happens if I try to copy over data with rsync... I use -var
parameters(verbose, archieve, recursive. It shows that it is coping
files, but when I look in the folder, all files start with a . and a
size of 0. After some time, it start throwing errors:
[CODE]
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/.index.html.gYKDOw"
failed: Operation not permitted (1)
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/.templates.xml.exWYLJ"
failed: Operation not permitted (1)
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/.toolbar.templates.html.php.0bG6WW"
failed: Operation not permitted (1)
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/.toolbar.templates.php.5wyZ89"
failed: Operation not permitted (1)
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/helpers/.index.html.qSFt8m"
failed: Operation not permitted (1)
[/CODE]

What is causing this? Are my ACL's wrong?

Matej

-- 
-------
http://www.zunaj.si - outdoor blog


From matej at zunaj.si  Thu Jan 30 15:57:58 2014
From: matej at zunaj.si (Matej Zerovnik)
Date: Thu, 30 Jan 2014 16:57:58 +0100
Subject: [OmniOS-discuss] Can't copy/rsync to NFS share
Message-ID: <52EA7686.2020701@zunaj.si>



Hello!!

I'm trying to setup NFS and SMB shares with ACL support and I got into
troubles...

I have a share, that is mounted to linux client over NFSv3 and to
windows client over SMB. My ACL's looks like the following:
https://dl.dropboxusercontent.com/u/5934229/forumi/ACL_for_share.png

What I want is to have a 755 unix permissions on folders and 644
permissions on files. User levak and root have full rights, when they
access the folder from windows. That seems to be properly configured.

Now the problem.

I tried to copy my data from one drive to another. It starts to copy,
but after some time, I start getting errors "cant create file, operation
not permitted":
`joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin_src.js'
->
`/omnios/joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin_src.js'
cp: cannot create regular file
`/omnios/joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin_src.js':
Operation not permitted
`joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin.js'
->
`/omnios/joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin.js'
cp: cannot create regular file
`/omnios/joomla/plugins/editors/tinymce/jscripts/tiny_mce/plugins/safari/editor_plugin.js':
Operation not permitted

If I cancel the transfer and start again, it goes a little further and
after some 10% more copied files, it starts throwing errors again, and
so on and so on...

The same happens if I try to copy over data with rsync... I use -var
parameters(verbose, archieve, recursive. It shows that it is coping
files, but when I look in the folder, all files start with a . and a
size of 0. After some time, it start throwing errors:
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/.index.html.gYKDOw"
failed: Operation not permitted (1)
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/.templates.xml.exWYLJ"
failed: Operation not permitted (1)
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/.toolbar.templates.html.php.0bG6WW"
failed: Operation not permitted (1)
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/.toolbar.templates.php.5wyZ89"
failed: Operation not permitted (1)
rsync: mkstemp
"/omnios/joomla/administrator/components/com_templates/helpers/.index.html.qSFt8m"
failed: Operation not permitted (1)

What is causing this? Are my ACL's wrong?

Matej

-- ------- http://www.zunaj.si - outdoor blog


-- 
-------
http://www.zunaj.si - outdoor blog


From stefan.skoglund at agj.net  Thu Jan 30 15:08:10 2014
From: stefan.skoglund at agj.net (Stefan Skoglund)
Date: Thu, 30 Jan 2014 16:08:10 +0100
Subject: [OmniOS-discuss] [zfs] Heads up: Redhat/CentOS NFSv3 clients
 file locking failures
In-Reply-To: <CALeZrrRO_bVR1M4fTQYeyNC1BY=M1Kz3X=OE1yrc-J=UeNhOzg@mail.gmail.com>
References: <CALeZrrRO_bVR1M4fTQYeyNC1BY=M1Kz3X=OE1yrc-J=UeNhOzg@mail.gmail.com>
Message-ID: <1391094490.29057.8.camel@compaq.lokeldarn.hobby-site.org>

ons 2014-01-22 klockan 14:47 -0600 skrev Schweiss, Chip:
> A recent change in the NLM for NFSv3 has exposed a problem with the
> firewall on Redhat/CentOS.   
> 
> Connections back to the client are blocked by the firewall because the
> connection tracking module is not catching connections as part of the
> open NFS connections to the server.
> 

This is (i think) callback related.

The portmapper works such that its users (for example the client-side
nfs kernel modules) bind to a tcp port and then registers the port's
number with the portmapper. 

Which means that the user's port number gets randomized, EXCEPT this:
---
[sudo root at compaq: /home/stefan]# lsmod |grep nfs
nfsd                  173890  2 
nfs                   265921  2 
nfs_acl                12463  2 nfs,nfsd
auth_rpcgss            32143  5 nfs,nfsd,rpcsec_gss_krb5
fscache                31978  1 nfs
lockd                  57277  2 nfs,nfsd
sunrpc                143904  16
lockd,auth_rpcgss,nfs_acl,nfs,nfsd,rpcsec_gss_krb5
[sudo root at compaq: /home/stefan]# modinfo nfsd
filename:       /lib/modules/3.2.0-4-686-pae/kernel/fs/nfsd/nfsd.ko
license:        GPL
author:         Olaf Kirch <okir at monad.swb.de>
depends:        auth_rpcgss,sunrpc,lockd,nfs_acl
intree:         Y
vermagic:       3.2.0-4-686-pae SMP mod_unload modversions 686 
[sudo root at compaq: /home/stefan]# modinfo nfs
filename:       /lib/modules/3.2.0-4-686-pae/kernel/fs/nfs/nfs.ko
license:        GPL
author:         Olaf Kirch <okir at monad.swb.de>
alias:          nfs4
depends:        fscache,sunrpc,lockd,auth_rpcgss,nfs_acl
intree:         Y
vermagic:       3.2.0-4-686-pae SMP mod_unload modversions 686 
parm:           callback_tcpport:portnr
parm:           cache_getent:Path to the client cache upcall program
(string)
parm:           cache_getent_timeout:Timeout (in seconds) after which
the cache upcall is assumed to have failed (ulong)
parm:           enable_ino64:bool
parm:           nfs4_disable_idmapping:Turn off NFSv4 idmapping when
using 'sec=sys' (bool)
[sudo root at compaq: /home/stefan]# [sudo root at compaq: /home/stefan]#
cat /etc/modprobe.d/local-conf-nfs-fixed-ports.conf 
options nfs callback_tcpport=2050
options lockd nlm_tcpport=2051 nlm_udpport=2051
[sudo root at compaq: /home/stefan]# 
----

The nfs related modules has parameters for using locally defined
well-known port numbers and which the firewall can be configured to
recognize.
 
I do use NFS4.


From lists at marzocchi.net  Thu Jan 30 20:24:33 2014
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Thu, 30 Jan 2014 21:24:33 +0100
Subject: [OmniOS-discuss] system/fm/smtp-notify mailing about
	already-resolved events on boot
In-Reply-To: <52E941CB.6050409@ColoState.EDU>
References: <20140129134058.GB8324@gutsman.lotheac.fi>
	<52E941CB.6050409@ColoState.EDU>
Message-ID: <C8763EE4-A5A8-405B-B524-5045E0CC1BC3@marzocchi.net>


Il giorno 29/gen/2014, alle ore 19:00, Kevin Swab <Kevin.Swab at colostate.edu> ha scritto:

> We have this issue too.  For us, it happens on all versions of OmniOS up
> through r151008 (and all versions of OpenIndiana we've tried too).
> 
> It will stop if you clear all the fault management logs using a
> procedure like this:
> 
> https://blogs.oracle.com/unixgeek/entry/how_to_clear_fmadm_log
> 
> But this seems a bit drastic.  A fix would be most welcome!
> 
> Kevin
> 
> 
> 
> On 01/29/2014 06:40 AM, Lauri Tirkkonen wrote:
>> smtp-notify seems to be generating emails for every recorded diagnosed
>> event upon system boot, even when those faults have been repaired or
>> resolved long since. We're on r151006.
>> 
>> This seems like a bug - is anyone else seeing this?
>> 
> 
> -- 
> -------------------------------------------------------------------
> Kevin Swab                          UNIX Systems Administrator
> ACNS                                Colorado State University
> Phone: (970)491-6572                Email: Kevin.Swab at ColoState.EDU
> GPG Fingerprint: 7026 3F66 A970 67BD 6F17  8EB8 8A7D 142F 2392 791C
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From lists at marzocchi.net  Thu Jan 30 20:25:31 2014
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Thu, 30 Jan 2014 21:25:31 +0100
Subject: [OmniOS-discuss] system/fm/smtp-notify mailing about
	already-resolved events on boot
In-Reply-To: <52E941CB.6050409@ColoState.EDU>
References: <20140129134058.GB8324@gutsman.lotheac.fi>
	<52E941CB.6050409@ColoState.EDU>
Message-ID: <BBF0B662-B8CB-4680-9FB7-28501453BF02@marzocchi.net>

I didn?t know smtp-notify but looked useful so I tried to install it.
However, it depends on sendmail and I already have postfix, that also provides a binary /usr/sbin/sendmail, so they conflict (see below).
If I install the ms.omniti package postfix (compiled for r151006 but probably fine) the conflict should disappear (its sendmail goes to opt/omni/sbin/sendmail) but then how to be sure that the postfix?s one is used?

Could give me some directions?

Thanks
Olaf


$ pfexec pkg install service/fault-management/smtp-notify
Creating Plan |                        
pkg install: The requested change to the system attempts to install multiple actions
for link 'usr/sbin/sendmail' with conflicting attributes:

   1 package delivers 'link path=usr/sbin/sendmail target=../lib/sendmail':
       pkg://omnios/service/network/smtp/sendmail at 8.14.4,5.11-0.151008:20131204T024609Z
   1 package delivers 'link path=usr/sbin/sendmail target=../local/sbin/sendmail':
       pkg://uulm.mawi/service/network/smtp/postfix at 2.10.2,5.11-0.151008:20140111T165835Z

These packages may not be installed together.  Any non-conflicting set may
be, or the packages must be corrected before they can be installed.

The following packages deliver conflicting action types to usr/lib/sendmail:

 link:
   pkg://uulm.mawi/service/network/smtp/postfix at 2.10.2,5.11-0.151008:20140111T165835Z
 file:
   pkg://omnios/service/network/smtp/sendmail at 8.14.4,5.11-0.151008:20131204T024609Z

These packages may not be installed together. Any non-conflicting set may
be, or the packages must be corrected before they can be installed.

$ pkg search sendmail
INDEX           ACTION VALUE                                               PACKAGE
basename        file   usr/local/sbin/sendmail                             pkg:/service/network/smtp/postfix at 2.10.2-0.151008
basename        link   usr/lib/sendmail                                    pkg:/service/network/smtp/postfix at 2.10.2-0.151008
basename        link   usr/sbin/sendmail                                   pkg:/service/network/smtp/postfix at 2.10.2-0.151008
pkg.descr       set    Wietse Venema's mail server alternative to Sendmail pkg:/omniti/network/smtp/postfix at 2.10.2-0.151006
basename        file   opt/omni/sbin/sendmail                              pkg:/omniti/network/smtp/postfix at 2.10.2-0.151006
basename        file   usr/lib/sendmail                                    pkg:/omniti/network/smtp/postfix at 2.10.2-0.151006
pkg.description set    Sendmail Utilities                                  pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
pkg.summary     set    Sendmail                                            pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
basename        file   etc/init.d/sendmail                                 pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
basename        file   usr/lib/sendmail                                    pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
basename        link   usr/sbin/sendmail                                   pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
pkg.fmri        set    omnios/service/network/smtp/sendmail                pkg:/service/network/smtp/sendmail at 8.14.4-0.151008



Il giorno 29/gen/2014, alle ore 19:00, Kevin Swab <Kevin.Swab at colostate.edu> ha scritto:

> We have this issue too.  For us, it happens on all versions of OmniOS up
> through r151008 (and all versions of OpenIndiana we've tried too).
> 
> It will stop if you clear all the fault management logs using a
> procedure like this:
> 
> https://blogs.oracle.com/unixgeek/entry/how_to_clear_fmadm_log
> 
> But this seems a bit drastic.  A fix would be most welcome!
> 
> Kevin
> 
> 
> 
> On 01/29/2014 06:40 AM, Lauri Tirkkonen wrote:
>> smtp-notify seems to be generating emails for every recorded diagnosed
>> event upon system boot, even when those faults have been repaired or
>> resolved long since. We're on r151006.
>> 
>> This seems like a bug - is anyone else seeing this?
>> 
> 
> -- 
> -------------------------------------------------------------------
> Kevin Swab                          UNIX Systems Administrator
> ACNS                                Colorado State University
> Phone: (970)491-6572                Email: Kevin.Swab at ColoState.EDU
> GPG Fingerprint: 7026 3F66 A970 67BD 6F17  8EB8 8A7D 142F 2392 791C
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From frederic.alix at fredalix.com  Fri Jan 31 00:35:25 2014
From: frederic.alix at fredalix.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Alix?=)
Date: Fri, 31 Jan 2014 01:35:25 +0100
Subject: [OmniOS-discuss] [OmniOS] Two problem for set a zfs dataset in a
	zone
Message-ID: <CAN4tE3_xAxJOKF4FZxo7Ew2jov3jXda9_f7SLu44HzxE=AQDGQ@mail.gmail.com>

Hello :)

I have two problem for use a zfs dataset in a zone.

First, i would like use it as a device

zfs create -V5g rpool/data0
In zonecfg:
add device
set match = "/dev/zvol/dsk/rpool/data0"
end

I boot the zone, and the device don't appear.
I read this, but it not resolve the problem
http://lists.omniti.com/pipermail/omnios-discuss/2013-February/000479.html

After, i try to use it lie this:
add dataset
set name = rpool/data0
end

and when i want boot the zone:
root at box:/var/tmp# zoneadm -z nappit0 boot
zone 'nappit0': cannot open ZFS dataset 'rpool/data0'
zoneadm: zone 'nappit0': call to zoneadmd failed

But my dataset exist
root at box:/var/tmp# zfs list rpool/data0
NAME          USED  AVAIL  REFER  MOUNTPOINT
rpool/data0  5,16G  33,2G    16K  -



Can you help me please ?

Regards, Fr?d?ric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140131/1a418c5b/attachment.html>

From sk at kram.io  Fri Jan 31 08:13:45 2014
From: sk at kram.io (Steffen Kram)
Date: Fri, 31 Jan 2014 09:13:45 +0100
Subject: [OmniOS-discuss] system/fm/smtp-notify mailing about
	already-resolved events on boot
In-Reply-To: <BBF0B662-B8CB-4680-9FB7-28501453BF02@marzocchi.net>
References: <20140129134058.GB8324@gutsman.lotheac.fi>
	<52E941CB.6050409@ColoState.EDU>
	<BBF0B662-B8CB-4680-9FB7-28501453BF02@marzocchi.net>
Message-ID: <CCAFC334-7FF1-4B26-94FB-7C83C165C312@kram.io>

Hi Olaf,

I provide a patched smtp-notify that does not depend on sendmail. However, you still have to throw out the smf dependency on sendmail manually.

Cheers,
Steffen


Am 30.01.2014 um 21:25 schrieb Olaf Marzocchi <lists at marzocchi.net>:

> I didn?t know smtp-notify but looked useful so I tried to install it.
> However, it depends on sendmail and I already have postfix, that also provides a binary /usr/sbin/sendmail, so they conflict (see below).
> If I install the ms.omniti package postfix (compiled for r151006 but probably fine) the conflict should disappear (its sendmail goes to opt/omni/sbin/sendmail) but then how to be sure that the postfix?s one is used?
> 
> Could give me some directions?
> 
> Thanks
> Olaf
> 
> 
> $ pfexec pkg install service/fault-management/smtp-notify
> Creating Plan |                        
> pkg install: The requested change to the system attempts to install multiple actions
> for link 'usr/sbin/sendmail' with conflicting attributes:
> 
>   1 package delivers 'link path=usr/sbin/sendmail target=../lib/sendmail':
>       pkg://omnios/service/network/smtp/sendmail at 8.14.4,5.11-0.151008:20131204T024609Z
>   1 package delivers 'link path=usr/sbin/sendmail target=../local/sbin/sendmail':
>       pkg://uulm.mawi/service/network/smtp/postfix at 2.10.2,5.11-0.151008:20140111T165835Z
> 
> These packages may not be installed together.  Any non-conflicting set may
> be, or the packages must be corrected before they can be installed.
> 
> The following packages deliver conflicting action types to usr/lib/sendmail:
> 
> link:
>   pkg://uulm.mawi/service/network/smtp/postfix at 2.10.2,5.11-0.151008:20140111T165835Z
> file:
>   pkg://omnios/service/network/smtp/sendmail at 8.14.4,5.11-0.151008:20131204T024609Z
> 
> These packages may not be installed together. Any non-conflicting set may
> be, or the packages must be corrected before they can be installed.
> 
> $ pkg search sendmail
> INDEX           ACTION VALUE                                               PACKAGE
> basename        file   usr/local/sbin/sendmail                             pkg:/service/network/smtp/postfix at 2.10.2-0.151008
> basename        link   usr/lib/sendmail                                    pkg:/service/network/smtp/postfix at 2.10.2-0.151008
> basename        link   usr/sbin/sendmail                                   pkg:/service/network/smtp/postfix at 2.10.2-0.151008
> pkg.descr       set    Wietse Venema's mail server alternative to Sendmail pkg:/omniti/network/smtp/postfix at 2.10.2-0.151006
> basename        file   opt/omni/sbin/sendmail                              pkg:/omniti/network/smtp/postfix at 2.10.2-0.151006
> basename        file   usr/lib/sendmail                                    pkg:/omniti/network/smtp/postfix at 2.10.2-0.151006
> pkg.description set    Sendmail Utilities                                  pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
> pkg.summary     set    Sendmail                                            pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
> basename        file   etc/init.d/sendmail                                 pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
> basename        file   usr/lib/sendmail                                    pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
> basename        link   usr/sbin/sendmail                                   pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
> pkg.fmri        set    omnios/service/network/smtp/sendmail                pkg:/service/network/smtp/sendmail at 8.14.4-0.151008
> 
> 
> 
> Il giorno 29/gen/2014, alle ore 19:00, Kevin Swab <Kevin.Swab at colostate.edu> ha scritto:
> 
>> We have this issue too.  For us, it happens on all versions of OmniOS up
>> through r151008 (and all versions of OpenIndiana we've tried too).
>> 
>> It will stop if you clear all the fault management logs using a
>> procedure like this:
>> 
>> https://blogs.oracle.com/unixgeek/entry/how_to_clear_fmadm_log
>> 
>> But this seems a bit drastic.  A fix would be most welcome!
>> 
>> Kevin
>> 
>> 
>> 
>> On 01/29/2014 06:40 AM, Lauri Tirkkonen wrote:
>>> smtp-notify seems to be generating emails for every recorded diagnosed
>>> event upon system boot, even when those faults have been repaired or
>>> resolved long since. We're on r151006.
>>> 
>>> This seems like a bug - is anyone else seeing this?
>>> 
>> 
>> -- 
>> -------------------------------------------------------------------
>> Kevin Swab                          UNIX Systems Administrator
>> ACNS                                Colorado State University
>> Phone: (970)491-6572                Email: Kevin.Swab at ColoState.EDU
>> GPG Fingerprint: 7026 3F66 A970 67BD 6F17  8EB8 8A7D 142F 2392 791C
>> _______________________________________________
>> 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: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://omniosce.org/ml-archive/attachments/20140131/ac6d1515/attachment.bin>

From zmalone at omniti.com  Fri Jan 31 16:29:26 2014
From: zmalone at omniti.com (Zach Malone)
Date: Fri, 31 Jan 2014 11:29:26 -0500
Subject: [OmniOS-discuss] [OmniOS] Two problem for set a zfs dataset in
	a zone
In-Reply-To: <CAN4tE3_xAxJOKF4FZxo7Ew2jov3jXda9_f7SLu44HzxE=AQDGQ@mail.gmail.com>
References: <CAN4tE3_xAxJOKF4FZxo7Ew2jov3jXda9_f7SLu44HzxE=AQDGQ@mail.gmail.com>
Message-ID: <CALLZ=vUZJgHHyzbradDJKjJ-_5PatU+SQO3qmiaw5a5io=pqbw@mail.gmail.com>

Hello,
I don't have much experience with delegating a zfs volume instead of
just a data set to a zone, but I believe the "add dataset" method
you've used second probably won't work, as that's how you add a
regular zfs filesystem.

http://lists.omniti.com/pipermail/omnios-discuss/2013-January/000413.html
sounds like exactly the same issue though.

Going back to the last time I needed a zvol inside a zone, I think I
might have tried creating the zvol on a dataset that had been
delegated to the zone already, and mounted/delegated the parent
dataset to the zone normally.  The dataset would have then been
created by the zone, rather then the gz.
--Zach Malone

On Thu, Jan 30, 2014 at 7:35 PM, Fr?d?ric Alix
<frederic.alix at fredalix.com> wrote:
> Hello :)
>
> I have two problem for use a zfs dataset in a zone.
>
> First, i would like use it as a device
>
> zfs create -V5g rpool/data0
> In zonecfg:
> add device
> set match = "/dev/zvol/dsk/rpool/data0"
> end
>
> I boot the zone, and the device don't appear.
> I read this, but it not resolve the problem
> http://lists.omniti.com/pipermail/omnios-discuss/2013-February/000479.html
>
> After, i try to use it lie this:
> add dataset
> set name = rpool/data0
> end
>
> and when i want boot the zone:
> root at box:/var/tmp# zoneadm -z nappit0 boot
> zone 'nappit0': cannot open ZFS dataset 'rpool/data0'
> zoneadm: zone 'nappit0': call to zoneadmd failed
>
> But my dataset exist
> root at box:/var/tmp# zfs list rpool/data0
> NAME          USED  AVAIL  REFER  MOUNTPOINT
> rpool/data0  5,16G  33,2G    16K  -
>
>
>
> Can you help me please ?
>
> Regards, Fr?d?ric
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From zmalone at omniti.com  Fri Jan 31 16:37:12 2014
From: zmalone at omniti.com (Zach Malone)
Date: Fri, 31 Jan 2014 11:37:12 -0500
Subject: [OmniOS-discuss] create ordinary user
In-Reply-To: <CAEekY64mZ+kTR=1jdZ7EfqjddxX0YSjOGz717muGjbRwxoCWYA@mail.gmail.com>
References: <CAEekY64mZ+kTR=1jdZ7EfqjddxX0YSjOGz717muGjbRwxoCWYA@mail.gmail.com>
Message-ID: <CALLZ=vVzmqUj+iwiO7EU_khDQL1EjsdfGpYwrkKFdCQv+FRE7A@mail.gmail.com>

What package repo did you install Netatalk from, or did you compile it
yourself?  Which utility is missing?

On Thu, Jan 30, 2014 at 8:18 AM, F?bio Rabelo <fabio at fabiorabelo.wiki.br> wrote:
> Hi to all
>
> I am trying netatalk in an OminOS box, and having problem to create a user ...
>
> All and every how-to that I found in the web refers to an utilitary in
> command line from OpenSolaris, but this tool do not exist in OmniOS
> ...
>
> So, how can I create an ordinary user to authenticate against netatalk ?
>
> Thanks in advance ...
>
>
> F?bio Rabelo
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From fabio at fabiorabelo.wiki.br  Fri Jan 31 16:44:36 2014
From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=)
Date: Fri, 31 Jan 2014 14:44:36 -0200
Subject: [OmniOS-discuss] create ordinary user
In-Reply-To: <CALLZ=vVzmqUj+iwiO7EU_khDQL1EjsdfGpYwrkKFdCQv+FRE7A@mail.gmail.com>
References: <CAEekY64mZ+kTR=1jdZ7EfqjddxX0YSjOGz717muGjbRwxoCWYA@mail.gmail.com>
	<CALLZ=vVzmqUj+iwiO7EU_khDQL1EjsdfGpYwrkKFdCQv+FRE7A@mail.gmail.com>
Message-ID: <CAEekY67WhQXCc0UQNrueTp3xEP8zL2bE+7Y5z5+fYBXHEUTRqw@mail.gmail.com>

Using the repo http://scott.mathematik.uni-ulm.de/
wget -O - www.napp-it.org/afp | perl

Nothing wrong here, but there are no ordinary user on the system, just
the root ...


F?bio Rabelo

2014-01-31 Zach Malone <zmalone at omniti.com>:
> What package repo did you install Netatalk from, or did you compile it
> yourself?  Which utility is missing?
>
> On Thu, Jan 30, 2014 at 8:18 AM, F?bio Rabelo <fabio at fabiorabelo.wiki.br> wrote:
>> Hi to all
>>
>> I am trying netatalk in an OminOS box, and having problem to create a user ...
>>
>> All and every how-to that I found in the web refers to an utilitary in
>> command line from OpenSolaris, but this tool do not exist in OmniOS
>> ...
>>
>> So, how can I create an ordinary user to authenticate against netatalk ?
>>
>> Thanks in advance ...
>>
>>
>> F?bio Rabelo
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From jimklimov at cos.ru  Fri Jan 31 17:09:23 2014
From: jimklimov at cos.ru (Jim Klimov)
Date: Fri, 31 Jan 2014 18:09:23 +0100
Subject: [OmniOS-discuss] [OmniOS] Two problem for set a zfs dataset in
	a	zone
In-Reply-To: <CAN4tE3_xAxJOKF4FZxo7Ew2jov3jXda9_f7SLu44HzxE=AQDGQ@mail.gmail.com>
References: <CAN4tE3_xAxJOKF4FZxo7Ew2jov3jXda9_f7SLu44HzxE=AQDGQ@mail.gmail.com>
Message-ID: <52EBD8C3.3050304@cos.ru>

On 2014-01-31 01:35, Fr?d?ric Alix wrote:
> Hello :)
>
> I have two problem for use a zfs dataset in a zone.
>
> First, i would like use it as a device
>
> zfs create -V5g rpool/data0
> In zonecfg:
> add device
> set match = "/dev/zvol/dsk/rpool/data0"
> end
>
> I boot the zone, and the device don't appear.

I do have a similar setup on one box, albeit on a SPARC Solaris 10
for a Solaris 8 branded zone (evacuation of an older server to newer
hardware), and the zone manifest (/etc/zones/zonename.xml) contains:

<device match="/dev/zvol/rdsk/pool/zones/local/colonel-data/chunk1"/>

The volume has no special properties set:

# zfs list -r pool/zones/local/colonel-data
NAME                                        USED  AVAIL  REFER  MOUNTPOINT
pool/zones/local/colonel-data              1.25G  16.1G  31.4K 
/zones/local/colonel-data
pool/zones/local/colonel-data/chunk1       1.25G  16.4G   331M  -


zfs get all pool/zones/local/colonel-data/infx-chunk1
NAME                                       PROPERTY               VALUE 
                  SOURCE
pool/zones/local/colonel-data/chunk1  type                   volume 
             -
pool/zones/local/colonel-data/chunk1  creation               Mon Nov 25 
  8:32 2013  -
pool/zones/local/colonel-data/chunk1  used                   1.25G 
             -
pool/zones/local/colonel-data/chunk1  available              16.4G 
             -
pool/zones/local/colonel-data/chunk1  referenced             331M 
             -
pool/zones/local/colonel-data/chunk1  compressratio          4.92x 
             -
pool/zones/local/colonel-data/chunk1  reservation            none 
             default
pool/zones/local/colonel-data/chunk1  volsize                2.05G 
             -
pool/zones/local/colonel-data/chunk1  volblocksize           8K 
             -
pool/zones/local/colonel-data/chunk1  checksum               on 
             default
pool/zones/local/colonel-data/chunk1  compression            gzip-9 
             inherited from pool/zones/local
pool/zones/local/colonel-data/chunk1  readonly               off 
             default
pool/zones/local/colonel-data/chunk1  shareiscsi             off 
             default
pool/zones/local/colonel-data/chunk1  copies                 1 
             default
pool/zones/local/colonel-data/chunk1  refreservation         300M 
             local
pool/zones/local/colonel-data/chunk1  primarycache           all 
             default
pool/zones/local/colonel-data/chunk1  secondarycache         all 
             default
pool/zones/local/colonel-data/chunk1  com.sun:auto-snapshot  true 
             inherited from pool


In particular, the "zoned" property is "off" on both the volume and
its higher containers.

This setup works, despite the fact that the branded Solaris 8 image
has of course no direct support for ZFS, so delegation of datasets
was not an option (either devices, or lofs-mounts, from the GZ into
LZ should have worked and did in fact work).

Now, this is indeed a different OS, but the basics like this should
be the same. Try starting "zlogin -C zonename" before booting the
zone, this may log something about some errors that may be in the way?

HTH,
//Jim


From Kevin.Swab at ColoState.EDU  Fri Jan 31 17:54:32 2014
From: Kevin.Swab at ColoState.EDU (Kevin Swab)
Date: Fri, 31 Jan 2014 10:54:32 -0700
Subject: [OmniOS-discuss] Migrating from OpenIndiana
In-Reply-To: <00e3cde8-116d-4da5-857c-f24a0883afbe@careyweb.com>
References: <00e3cde8-116d-4da5-857c-f24a0883afbe@careyweb.com>
Message-ID: <52EBE358.1060602@ColoState.EDU>

We recently did this on 18 of our storage servers, and the process went
smoothly, no issues were encountered.  Our setup sounds similar to
yours:  The OI 151a7 systems were serving LUNs over FC via Comstar.
The root pools were mirrored, and each system had at least one other
pool for data (zvols backing the Comstar LUNs).

I set up a Kayak server which makes the install process go much faster
(and minimizes downtime), but it's not necessary to get the job done.

The steps we followed were something like this:

- Save the Comstar config:

	svccfg export -a stmf > svccfg-stmf.xml

  I put the XML file in one of the data pools so it would be easy to
access from the new OmniOS install.

- save any other files you care about from the root pool

- break off one of the mirrored root pool devices to use for the OmniOS
install

- Install OmniOS onto the free device and boot.

- Import the data pools.  I didn't export them from the old OI install
first, so '-f' was needed on the 'zpool import' command

- Restore the Comstar config:

	svccfg import svccfg-stmf.xml


At this point you should be up and running on your OmniOS install, with
the old OpenIndiana install still available on the other root pool disk.

Once you feel confident things are working and you don't need to fall
back to the old OS, remirror the root pool and upgrade the data pools.

The total time the systems were unavailable for the upgrade was about
10-15 minutes.  Did I mention Kayak was fast? :-)

Good luck with your upgrades,
Kevin


On 01/29/2014 02:59 PM, Nate Smith wrote:
> I?m going to migrate the ZFS systems on my OpenIndiana file server to an
> Omnios based one for greater stability (my Openindiana server seems to
> lose all network connectivity about once every three months, though all
> the FC targets stay mounted and accessible). I am running oi_151a7, with
> version 28 ZFS volumes.  They are presented as block storage Comstar
> targets over fibre channel.  Should I have any problems migrating these
> to Omnios? Thanks in advance.
> 
>  
> 
> -Nate
> 
>  
> 
> 
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 

-- 
-------------------------------------------------------------------
Kevin Swab                          UNIX Systems Administrator
ACNS                                Colorado State University
Phone: (970)491-6572                Email: Kevin.Swab at ColoState.EDU
GPG Fingerprint: 7026 3F66 A970 67BD 6F17  8EB8 8A7D 142F 2392 791C

From alka at hfg-gmuend.de  Fri Jan 31 19:22:46 2014
From: alka at hfg-gmuend.de (alka)
Date: Fri, 31 Jan 2014 20:22:46 +0100
Subject: [OmniOS-discuss] create ordinary user
In-Reply-To: <CAEekY67WhQXCc0UQNrueTp3xEP8zL2bE+7Y5z5+fYBXHEUTRqw@mail.gmail.com>
References: <CAEekY64mZ+kTR=1jdZ7EfqjddxX0YSjOGz717muGjbRwxoCWYA@mail.gmail.com>
	<CALLZ=vVzmqUj+iwiO7EU_khDQL1EjsdfGpYwrkKFdCQv+FRE7A@mail.gmail.com>
	<CAEekY67WhQXCc0UQNrueTp3xEP8zL2bE+7Y5z5+fYBXHEUTRqw@mail.gmail.com>
Message-ID: <8ED539DC-5DE6-4257-8741-922173E2924B@hfg-gmuend.de>

Netatalk use regular OmniOS Unix users.
If you use napp-it, goto menu user and klick ++add local user

You can also use the CLI command useradd


Gea

Am 31.01.2014 um 17:44 schrieb F?bio Rabelo:

> Using the repo http://scott.mathematik.uni-ulm.de/
> wget -O - www.napp-it.org/afp | perl
> 
> Nothing wrong here, but there are no ordinary user on the system, just
> the root ...
> 
> 
> F?bio Rabelo
> 
> 2014-01-31 Zach Malone <zmalone at omniti.com>:
>> What package repo did you install Netatalk from, or did you compile it
>> yourself?  Which utility is missing?
>> 
>> On Thu, Jan 30, 2014 at 8:18 AM, F?bio Rabelo <fabio at fabiorabelo.wiki.br> wrote:
>>> Hi to all
>>> 
>>> I am trying netatalk in an OminOS box, and having problem to create a user ...
>>> 
>>> All and every how-to that I found in the web refers to an utilitary in
>>> command line from OpenSolaris, but this tool do not exist in OmniOS
>>> ...
>>> 
>>> So, how can I create an ordinary user to authenticate against netatalk ?
>>> 
>>> Thanks in advance ...
>>> 
>>> 
>>> F?bio Rabelo
>>> _______________________________________________
>>> 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: <https://omniosce.org/ml-archive/attachments/20140131/3766b801/attachment.html>

From anhquach at me.com  Fri Jan 31 23:07:38 2014
From: anhquach at me.com (Anh Quach)
Date: Fri, 31 Jan 2014 15:07:38 -0800
Subject: [OmniOS-discuss] SMB + Network tuning
Message-ID: <etPan.52ec2cba.66ef438d.4415@abp.local>

Hi all, new to the list.. apologies if this is a tired topic..?

I?m seeing poor SMB performance on my gigabit network here, as compared to a Synology filer. With the Synology, my test client can read/write consistently at near line speeds (100MB/s+), while with the OmniOS test filer, I can?t seem to get above 60MB/s.?

I?ve tried the usual TCP tuning of buffers, ack, and such, to no avail. NFS seems to yield about the same results.?

Some details:?

- Server: HP Proliant, DL360 G5, 16GB RAM
- OS: tested with both latest OmniOS + Solaris 11.1, with and without Napp-it, same results
- NIC: bnx?
- storage: Xyratex JBOD, SAS
- zpool: 2 x 6 disk raidz2

I?m getting hundreds of MB/s off the zpool, so I?m thinking the bottleneck has to be something in the Samba or NIC driver config.?

Any ideas greatly appreciated!
?
--?
Anh Quach
Sent with Airmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140131/e85e8837/attachment.html>