From doug at will.to  Wed Mar  1 02:33:34 2017
From: doug at will.to (Doug Hughes)
Date: Tue, 28 Feb 2017 21:33:34 -0500
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
Message-ID: <fa13878a-cd7b-8d76-ae44-9c03bd59794c@will.to>

I get an endless boot loop.

libvirt/kvm on Centos7

It took me a while, but I managed to get a screenshot, which was very 
difficult and took about 15 tries.


then it goes back to countdown, logo, periods, ad nauseum.

2 cpus, 2GB ram.



On 2/28/2017 2:43 PM, Dan McDonald wrote:
> I meant on the installer, not on LOADER.  Press return on loader (that's the GRUB repoacment) to boot illumos and then the installer.  You should see the SunOS banner THEN look for the OmniOS installation menu.
>
> Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
>> On Feb 28, 2017, at 1:58 PM, Michael Rasmussen <mir at miras.org> wrote:
>>
>> On Tue, 28 Feb 2017 13:23:24 -0500
>> Dan McDonald <danmcd at omniti.com> wrote:
>>
>>>> On Feb 28, 2017, at 1:02 PM, Dan McDonald <danmcd at omniti.com> wrote:
>>>>
>>>> I messed something up in this ISO's construction.  Please wait, folks,
>>> Okay...
>>>
>>> 1.) I've reconstructed the ISO, and diskinfo is available in the shell.
>>>
>> How should diskinfo be invoked?
>> When pressing menu '3' I see:
>> ok _
>> Doing
>> ok diskinfo gives:
>>   not found
>>
>>
>> -- 
>> 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:
>> All generalizations are false, including this one.
>>         -- Mark Twain
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/0822af0f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nednihcbkbhmfjhh.png
Type: image/png
Size: 264756 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/0822af0f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kgiiikinidkhbcgi.png
Type: image/png
Size: 129606 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/0822af0f/attachment-0003.png>

From danmcd at omniti.com  Wed Mar  1 03:27:34 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 28 Feb 2017 22:27:34 -0500
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <fa13878a-cd7b-8d76-ae44-9c03bd59794c@will.to>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<fa13878a-cd7b-8d76-ae44-9c03bd59794c@will.to>
Message-ID: <376CACC4-F847-47CD-B800-228264261244@omniti.com>


> On Feb 28, 2017, at 9:33 PM, Doug Hughes <doug at will.to> wrote:
> 
> I get an endless boot loop.
> 
> libvirt/kvm on Centos7
> 
> It took me a while, but I managed to get a screenshot, which was very difficult and took about 15 tries.
> 

You can use the BSD Loader menu to enable kmdb.  Then you will die and enter KMDB, where you can do $C and other things.  :)

Dan


From doug at will.to  Wed Mar  1 03:37:39 2017
From: doug at will.to (Doug Hughes)
Date: Tue, 28 Feb 2017 22:37:39 -0500
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <376CACC4-F847-47CD-B800-228264261244@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<fa13878a-cd7b-8d76-ae44-9c03bd59794c@will.to>
	<376CACC4-F847-47CD-B800-228264261244@omniti.com>
Message-ID: <0547c64e-c8fe-b73b-534a-1c8d5caf7db7@will.to>



On 2/28/2017 10:27 PM, Dan McDonald wrote:
>> On Feb 28, 2017, at 9:33 PM, Doug Hughes <doug at will.to> wrote:
>>
>> I get an endless boot loop.
>>
>> libvirt/kvm on Centos7
>>
>> It took me a while, but I managed to get a screenshot, which was very difficult and took about 15 tries.
>>
> You can use the BSD Loader menu to enable kmdb.  Then you will die and enter KMDB, where you can do $C and other things.  :)
>
> Dan
Not able to get there. The ISO boot is doing the boot loop so I can't 
get past that to the numeric menu.



From danmcd at omniti.com  Wed Mar  1 13:12:57 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 1 Mar 2017 08:12:57 -0500
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <0547c64e-c8fe-b73b-534a-1c8d5caf7db7@will.to>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<fa13878a-cd7b-8d76-ae44-9c03bd59794c@will.to>
	<376CACC4-F847-47CD-B800-228264261244@omniti.com>
	<0547c64e-c8fe-b73b-534a-1c8d5caf7db7@will.to>
Message-ID: <12C21505-664D-4B70-8C36-3D15DF1CDF05@omniti.com>

Okay.  Not even seeing the loader screen then... shoot.  Good news is that there are some new fixes in loader from upstream that I'm building now. A new test ISO will get spun from them.

Dan

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

> On Feb 28, 2017, at 10:37 PM, Doug Hughes <doug at will.to> wrote:
> 
> 
> 
> On 2/28/2017 10:27 PM, Dan McDonald wrote:
>>> On Feb 28, 2017, at 9:33 PM, Doug Hughes <doug at will.to> wrote:
>>> 
>>> I get an endless boot loop.
>>> 
>>> libvirt/kvm on Centos7
>>> 
>>> It took me a while, but I managed to get a screenshot, which was very difficult and took about 15 tries.
>>> 
>> You can use the BSD Loader menu to enable kmdb.  Then you will die and enter KMDB, where you can do $C and other things.  :)
>> 
>> Dan
> Not able to get there. The ISO boot is doing the boot loop so I can't get past that to the numeric menu.
> 
> 

From peter.tribble at gmail.com  Wed Mar  1 13:36:41 2017
From: peter.tribble at gmail.com (Peter Tribble)
Date: Wed, 1 Mar 2017 13:36:41 +0000
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <27CB83D1-4B09-436F-AA83-1D1CCCD06428@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<CAEgYsbGiW_pvB-01zmJ2tOhO8mzujp3tF7rSMJtj+VTRWz4VFQ@mail.gmail.com>
	<27CB83D1-4B09-436F-AA83-1D1CCCD06428@omniti.com>
Message-ID: <CAEgYsbFzDGi-eUZooKSA=_HtMvOXLoo95kon=vJS4hmO7k7xQw@mail.gmail.com>

On Tue, Feb 28, 2017 at 10:35 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On Feb 28, 2017, at 5:22 PM, Peter Tribble <peter.tribble at gmail.com>
> wrote:
> >
> > Dan,
>
> <SNIP!>
>
> > Ok, some comments (I'm wearing 2 hats here, one as an omnios
> > customer, the other as someone who's actually written an installer):
> >
> > Overall, I think I prefer it to Caiman. But then I was never a
> > fan of Caiman, it was all so slow and klunky.
> >
> > The ISO is, how can I say this, rather bigger than before.
>
> Yes.  This is because I wanted to get it running first.
>
> I will note that if I used 7z instead of bzip2, I can shrink the ZFS image
> that lives in the ISO.
>
> > Right, so you've dropped the good old solaris.zlib approach
>
> Oddly enough, solaris.zlib uses 7z, IIRC.
>

Well, lzma or gzip. I use gzip in Tribblix because lzma didn't
give me a noticeable benefit and gzip was much quicker.


> > looks like a 64-bit only ISO. (The image you install is dual
> > 32/64-bit though.)
>
> OmniOS officially only supports 64-bit installs.  That we still provide a
> 32-bit one is an artifact of limited resources, not a statement of
> direction.
>

I just think you should be consistent.


> > The root archive is uncompressed. You could make the iso smaller
> > by gzipping the root archive.
>
> Can boot_archive be compressed?  I didn't think it could.
>

It's normally gzipped. (Without the extension.)


> > The root archive doesn't need the root reserve or anything like as
> > many inodes, which can save you quite a lot of space.
>

Another benefit from gzipping the root archive is that the empty space on
the ufs filesystem compresses away really well...


> > The loader menu on the ISO ought to have a 'boot from disk' option
> > that's removed for the installed system.
>
> Interesting idea.  I'll make note of that.
>

Thanks.


> > You probably want to be able to control the name of the initial BE
> > you create (think of the case of installing into an older system that
> > already has omnios installed).
>
> Currently no installer does this.  I don't want to go down the path of
> feeping-creaturism unless it's a huge win.  One user != huge.
>

I mentioned this because we see this request crop up for OI
fairly regularly. Essentially, how do I reinstall a broken system
without losing all my data? (And I implemented it for Tribblix
a while back.)

Your quick-networking idea is something I've been considering in a
> different context --> full DHCP-node install.  Basically, the media runs,
> guesses disks and interfaces, slaps bits, tells new bits to DHCP and DNS,
> and it's one-button install.  Again, I want to beware of
> feeping-creaturism, though.
>

Oh, I'm not saying you need to implement all this, or do it today; but
thinking about possible scenarios means you don't paint yourself into
a corner.

Thanks,

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

From nnmiller at gmail.com  Wed Mar  1 13:56:06 2017
From: nnmiller at gmail.com (N. Nadine Miller)
Date: Wed, 1 Mar 2017 08:56:06 -0500
Subject: [OmniOS-discuss] Change in uname behavior between r151014 and
	r151020?
Message-ID: <CACfqXAL-V_KOndrSn_7+mpbq7t8L6-1a=+fLp9OTa5uMu6nFaQ@mail.gmail.com>

I installed pkgsrc some time ago and attempted to upgrade this
morning. When I attempted to update the pkg tools, it gave me an error
regarding 32-bit vs 64-bit, so reflexively I checked 'uname' output to
verify I hadn't broken my recent update to r151020.

I discovered that 'uname' incorrectly reports that I have a 32-bit
version of OmniOS:
>root at jarvis:/opt# uname -a
>SunOS jarvis 5.11 omnios-bed3013 i86pc i386 i86pc

My kernel is 64-bit, per 'isainfo -k':
>root at jarvis:/opt# isainfo -k
>amd64
>root at jarvis:/opt# isalist
>amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

Build version:
>root at jarvis:/opt# uname -v
>omnios-bed3013
>root at jarvis:/opt# cat /etc/release
>  OmniOS v11 r151020

Looking at the uname binary, it's 32-bit:
root at jarvis:/# file /sbin/uname
/sbin/uname:    ELF 32-bit LSB executable 80386 Version 1, dynamically
linked, not stripped, no debugging information available

There's another binary in /usr/lib/bash/uname but it is completely broken:
>root at jarvis:/usr/bin# /usr/lib/bash/uname
>uname: Bad entry point
>Killed

Thanks--
=Nadine=

From danmcd at omniti.com  Wed Mar  1 15:39:12 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 1 Mar 2017 10:39:12 -0500
Subject: [OmniOS-discuss] Change in uname behavior between r151014 and
 r151020?
In-Reply-To: <CACfqXAL-V_KOndrSn_7+mpbq7t8L6-1a=+fLp9OTa5uMu6nFaQ@mail.gmail.com>
References: <CACfqXAL-V_KOndrSn_7+mpbq7t8L6-1a=+fLp9OTa5uMu6nFaQ@mail.gmail.com>
Message-ID: <236E8D27-9ACC-4B37-9340-DA3BF28B9696@omniti.com>


> On Mar 1, 2017, at 8:56 AM, N. Nadine Miller <nnmiller at gmail.com> wrote:
> 
> I installed pkgsrc some time ago and attempted to upgrade this
> morning. When I attempted to update the pkg tools, it gave me an error

What exactly do you mean when you says "update the pkg tools"?

> regarding 32-bit vs 64-bit, so reflexively I checked 'uname' output to
> verify I hadn't broken my recent update to r151020.
> 
> I discovered that 'uname' incorrectly reports that I have a 32-bit
> version of OmniOS:
>> root at jarvis:/opt# uname -a
>> SunOS jarvis 5.11 omnios-bed3013 i86pc i386 i86pc

That (mis)behavior has always been there.

r151014(~/ws/illumos-omnios)[0]% uname -a
SunOS r151014 5.11 omnios-280c743 i86pc i386 i86pc
r151014(~/ws/illumos-omnios)[0]% 

> My kernel is 64-bit, per 'isainfo -k':
>> root at jarvis:/opt# isainfo -k
>> amd64
>> root at jarvis:/opt# isalist
>> amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

Correct also.  isainfo & isalist are the proper illumos interfaces for figuring these things out.

> Build version:
>> root at jarvis:/opt# uname -v
>> omnios-bed3013
>> root at jarvis:/opt# cat /etc/release
>> OmniOS v11 r151020
> 
> Looking at the uname binary, it's 32-bit:
> root at jarvis:/# file /sbin/uname
> /sbin/uname:    ELF 32-bit LSB executable 80386 Version 1, dynamically
> linked, not stripped, no debugging information available

Also correct -- the binaries in /sbin are compiled 32-bit for ancient reasons.  And you may also notice that a binary in /usr/{bin,sbin} is also 32-bit, but there are /usr/{bin,sbin}/{i86,i386,amd64} versions, which are auto-switched-into the correct version based on isainfo:

r151014(~/ws/illumos-omnios)[0]% ls -lt /usr/sbin/dtrace
-r-xr-xr-x  77 root     bin        12768 Feb  3  2015 /usr/sbin/dtrace*
r151014(~/ws/illumos-omnios)[0]% ls -lt /usr/sbin/*/dtrace
-r-xr-xr-x   1 root     bin        57920 Dec 31 01:50 /usr/sbin/amd64/dtrace*
-r-xr-xr-x   1 root     bin        50924 Dec 31 01:50 /usr/sbin/i86/dtrace*
r151014(~/ws/illumos-omnios)[0]% 


As I said earlier, I'm not sure what you mean by "update the pkg tools".  Please elaborate.

Thanks,
Dan


From mir at miras.org  Wed Mar  1 16:00:05 2017
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 1 Mar 2017 17:00:05 +0100
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <20170301005530.7e7d1316@sleipner.datanom.net>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
	<20170228221543.27a5db05@sleipner.datanom.net>
	<20170228224637.597f060f@sleipner.datanom.net>
	<20170228225028.41fb3642@sleipner.datanom.net>
	<7F0EE08D-AFA1-4D93-A773-F2D48802212D@omniti.com>
	<20170228233609.0dcc738b@sleipner.datanom.net>
	<20170301001220.5fd143f1@sleipner.datanom.net>
	<20170301005530.7e7d1316@sleipner.datanom.net>
Message-ID: <20170301170005.54d24e0e@sleipner.datanom.net>

On Wed, 1 Mar 2017 00:55:30 +0100
Michael Rasmussen <mir at miras.org> wrote:

> To quick. First disk can never be used since removing DVD/CD will only
> make IPXE shadow first disk and IPXE by default cannot be moved.
> 
I have digged deeper into this problem and have discovered that it is
actually a very critical problem since the low-level disk tools
recognizes the disk but the kernel has mapped the disk to another disk
so that two different /dev/dsk points to the same physical disk.

AVAILABLE DISK SELECTIONS:
       0. c2t0d0 <Virtio-Block Device-0000 cyl 4096 alt 0 hd 128 sec 32>
          /pci at 0,0/pci1af4,2 at a/blkdev at 0,0
       1. c3t0d0 <Virtio-Block Device-0000-8.00GB>
          /pci at 0,0/pci1af4,2 at b/blkdev at 0,0
       2. c5t0d0 <Virtio-Block Device-0000-8.00GB>
          /pci at 0,0/pci1af4,2 at c/blkdev at 0,0

Specify disk (enter its number): 0
selecting c2t0d0
No defect list found
[disk formatted, no defect list found]
/dev/dsk/c5t0d0s0 is part of active ZFS pool rpool. Please see zpool(1M).
No Solaris fdisk partition found.

 zpool status
  pool: rpool
 state: ONLINE
  scan: resilvered 2.00M in 0h0m with 0 errors on Wed Mar  1 15:49:20 2017
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c3t0d0  ONLINE       0     0     0
            c5t0d0  ONLINE       0     0     0

zpool attach rpool c5t0d0 c2t0d0
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c5t0d0s0 is part of active ZFS pool rpool. Please see zpool(1M).
root at unknown:~# zpool attach rpool c3t0d0 c2t0d0
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c5t0d0s0 is part of active ZFS pool rpool. Please see zpool(1M).

-- 
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:
Flying is the second greatest feeling you can have.  The greatest
feeling? Landing...  Landing is the greatest feeling you can have.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170301/915474d9/attachment.bin>

From danmcd at omniti.com  Wed Mar  1 17:16:14 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 1 Mar 2017 12:16:14 -0500
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <20170301170005.54d24e0e@sleipner.datanom.net>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
	<20170228221543.27a5db05@sleipner.datanom.net>
	<20170228224637.597f060f@sleipner.datanom.net>
	<20170228225028.41fb3642@sleipner.datanom.net>
	<7F0EE08D-AFA1-4D93-A773-F2D48802212D@omniti.com>
	<20170228233609.0dcc738b@sleipner.datanom.net>
	<20170301001220.5fd143f1@sleipner.datanom.net>
	<20170301005530.7e7d1316@sleipner.datanom.net>
	<20170301170005.54d24e0e@sleipner.datanom.net>
Message-ID: <3EFA811A-19B9-403B-88FF-31E7D56B0581@omniti.com>


> On Mar 1, 2017, at 11:00 AM, Michael Rasmussen <mir at miras.org> wrote:
> 
> I have digged deeper into this problem and have discovered that it is
> actually a very critical problem since the low-level disk tools
> recognizes the disk but the kernel has mapped the disk to another disk
> so that two different /dev/dsk points to the same physical disk.

This is on Xen?  There's a fix coming for this:

https://github.com/omniti-labs/illumos-omnios/commit/1b5a946e10cb0aefb70eb10f6a0fb7f6d8a91f42

That started here:

https://github.com/openzfs/openzfs/pull/281

Dan


From mir at miras.org  Wed Mar  1 17:23:13 2017
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 1 Mar 2017 18:23:13 +0100
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <3EFA811A-19B9-403B-88FF-31E7D56B0581@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
	<20170228221543.27a5db05@sleipner.datanom.net>
	<20170228224637.597f060f@sleipner.datanom.net>
	<20170228225028.41fb3642@sleipner.datanom.net>
	<7F0EE08D-AFA1-4D93-A773-F2D48802212D@omniti.com>
	<20170228233609.0dcc738b@sleipner.datanom.net>
	<20170301001220.5fd143f1@sleipner.datanom.net>
	<20170301005530.7e7d1316@sleipner.datanom.net>
	<20170301170005.54d24e0e@sleipner.datanom.net>
	<3EFA811A-19B9-403B-88FF-31E7D56B0581@omniti.com>
Message-ID: <20170301182313.5c5e6f84@sleipner.datanom.net>

On Wed, 1 Mar 2017 12:16:14 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> This is on Xen?  There's a fix coming for this:
> 
No, qemu.

-- 
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:
No passes accepted for this engagement.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170301/45355259/attachment.bin>

From stephan.budach at jvm.de  Wed Mar  1 18:02:58 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Wed, 1 Mar 2017 19:02:58 +0100 (CET)
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <929E9A7E-7211-4321-A589-AFA31804BEE0@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<372957988.1207.1488268775446.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<929E9A7E-7211-4321-A589-AFA31804BEE0@omniti.com>
Message-ID: <351930109.2266.1488391343000.JavaMail.stephan.budach@stephan.budach.jvm.de>

Hi Dan

----- Urspr?ngliche Mail -----

> It MIGHT, and you're the sort of person I need to confirm/deny it.
> 
> Watch for a kebe.com link later today.
> 
> Dan
> 
> 

Well, I just got it a shot on my Oracle VM cluster and after the iso loaded, it threw this on the screen:

BTX loader 1.00 Starting in protected mode (base mem=9d400)
.
.
.
BIOS CD is cd0

Next is some kind of stack trace and finally

BTX halted

Cheers,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170301/a421aba8/attachment.bin>

From danmcd at omniti.com  Wed Mar  1 18:56:42 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 1 Mar 2017 13:56:42 -0500
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <351930109.2266.1488391343000.JavaMail.stephan.budach@stephan.budach.jvm.de>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<372957988.1207.1488268775446.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<929E9A7E-7211-4321-A589-AFA31804BEE0@omniti.com>
	<351930109.2266.1488391343000.JavaMail.stephan.budach@stephan.budach.jvm.de>
Message-ID: <2B100205-94FC-4F3B-A1E8-79174B58851E@omniti.com>


> On Mar 1, 2017, at 1:02 PM, Stephan Budach <stephan.budach at jvm.de> wrote:
> 
> Hi Dan
> 
> Well, I just got it a shot on my Oracle VM cluster and after the iso loaded, it threw this on the screen:
> 
> BTX loader 1.00 Starting in protected mode (base mem=9d400)
> .
> .
> .
> BIOS CD is cd0
> 
> Next is some kind of stack trace and finally
> 
> BTX halted

Is that Xen-based?

Dan


From danmcd at omniti.com  Wed Mar  1 20:59:56 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 1 Mar 2017 15:59:56 -0500
Subject: [OmniOS-discuss] New OmniOS r151014 and r151020 updates & media
Message-ID: <009A7958-4A5B-4106-9167-0844EF2CE59C@omniti.com>

If you are user of LTS (r151014) or Stable (r151020), please "pkg update" and be ready for a new BE and a reboot.

Included in this update are:

	- bge fixes on HP Gen9 systems
	- MSI-X for NVMe is disable on VMware (where MSI-X is a problem)
	- mmap() now properly modifies a file's timestamps in ZFS.
	- Default NFS server threads are now increased.
	- i40e now uses multiple receive and transmit rings
	- One mpt_sas panic bugfix

The install media has been updated too, as the bge fix will help HP Gen9 users.  Install media pointers can be found here:

	https://omnios.omniti.com/wiki.php/Installation

Happy updating!
Dan


From danmcd at omniti.com  Wed Mar  1 21:00:44 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 1 Mar 2017 16:00:44 -0500
Subject: [OmniOS-discuss] REMINDER - r151018 EOSL on April 14th,
	and r151022 cadence delay
References: <3F4969B1-D9C5-49B0-8223-369277E29B2F@omniti.com>
Message-ID: <45D43D62-01EB-4EE1-ADCA-3158F2047E24@omniti.com>

In 45 days, OmniOS r151018 (old-Stable) will reach end-of-service-life.  Users should update to current-stable, r151020, if they haven't already.

Unlike prior releases, the next Stable, and next LTS, r151022, will not be ready until approximately June, due to the sheer number of upstream changes, and consequences to the OmniOS distro code.  (e.g. Python2.7 and BSD Loader).  r151020 will continue as current-Stable until r151022 is released. At that time, r151020 will become old Stable.  Also, r151024 will not be released until 1H 2018, at which time the OmniOS 6-month cadence should resume.  Because of the hiccup (2 releases in 18 months vs. 3), r151028, not r151030, will be the next LTS after r151022.

I've adjusted this page:

	https://omnios.omniti.com/wiki.php/ReleaseCycle

To reflect these changes.

Thank you,
Dan McDonald -- OmniOS Engineering


From danmcd at omniti.com  Wed Mar  1 21:57:35 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 1 Mar 2017 16:57:35 -0500
Subject: [OmniOS-discuss] Bloody update (illumos-omnos only)
Message-ID: <C3B99013-45B3-4CBA-AD88-9ED0B2866AC2@omniti.com>

Because I'm experimenting with Kayak-for-ISO, I want to have fresh illumos-omnios bits (esp. Loader itself) on the public server.  I've just pushed new packages (full build) out to the bloody repo.  Update highlights include:

- AIO improvements in LX
- Some loader bugfixes
- blkdev fixes for devices with blksize > 512 bytes.
- illumos 7777 "Expose xdf minor nodes when in PV-HVM mode" fix from Delphix.  We are taking this pre-integration because of its potential to help the new Kayak-based ISO installer.

I will not be cutting traditional install media, given I'm getting closer on the Kayak-for-ISO front.  Existing users should "pkg update".  New users should either install the old bits and upgrade, or take their chances on the WIP Kayak-for-ISO installer.

Watch this space for an updated Kayak-for-ISO, which will at least have a controlling-terminal fix in it (so you can do job control on shells, AND invoke format(1M) w/o it complaining about /dev/tty).

Dan


From danmcd at omniti.com  Wed Mar  1 22:05:02 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 1 Mar 2017 17:05:02 -0500
Subject: [OmniOS-discuss] Bloody update (illumos-omnos only)
In-Reply-To: <C3B99013-45B3-4CBA-AD88-9ED0B2866AC2@omniti.com>
References: <C3B99013-45B3-4CBA-AD88-9ED0B2866AC2@omniti.com>
Message-ID: <A596EBAB-B6F0-44D4-8B8E-72FF06D0FD90@omniti.com>

Shoot, the pkgrecv isn't done yet.  Stay tuned...

Dan


From danmcd at omniti.com  Thu Mar  2 02:40:21 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 1 Mar 2017 21:40:21 -0500
Subject: [OmniOS-discuss] Improved, but still alpha, ISO installer
Message-ID: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>

Please refresh your copy by downloading here:

	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

Here are the checksums:

	md5 (r151021-kayak.iso) = f4a726113e74dd84e3c74d9f5cfe7c95
	sha1 (r151021-kayak.iso) = d9c6381e7d7c792610b5f19c1c3a546b168d495a
	sha256 (r151021-kayak.iso) = 690a7e628d30e098c1064acfc43bb948d51be45a8c2ea5a6c448573263c996da

It has two noteworthy fixes:

1.) Job Control now works for the installer menu and its child processes, including the shell you can access!

2.) Thanks to IRC user "thebug" for confirming this, but it now has sufficient bugfixes (thanks esp. to Delphix for PR-ing an illumos 7777 fix into illumos-omnios) to detect and install vioblk devices, at least in a SmartOS KVM guest.

Other fixes were included by synching with early today's illumos-gate fixes, the most recent being:

commit ff157c8690676593df83d0602f60f960862d3492
Author: Toomas Soome <tsoome at me.com>
Date:   Sat Nov 12 18:27:42 2016 +0200

    7896 loader.efi: Don't set *dev in the zfs root case, it may be NULL

I'm taking tomorrow away from ISO work to spend the day reading & reviewing code or other people's designs (modulo an OmniOS emergency), so pardon any latency on getting things fixed in the next 24 hours.

Thanks,
Dan


From stephan.budach at jvm.de  Thu Mar  2 07:29:34 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Thu, 2 Mar 2017 08:29:34 +0100 (CET)
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <2B100205-94FC-4F3B-A1E8-79174B58851E@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<372957988.1207.1488268775446.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<929E9A7E-7211-4321-A589-AFA31804BEE0@omniti.com>
	<351930109.2266.1488391343000.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<2B100205-94FC-4F3B-A1E8-79174B58851E@omniti.com>
Message-ID: <1426011197.2342.1488439739030.JavaMail.stephan.budach@stephanbudach.local>



----- Urspr?ngliche Mail -----
> Von: "Dan McDonald" <danmcd at omniti.com>
> An: "Stephan Budach" <stephan.budach at jvm.de>
> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>, "Dan McDonald" <danmcd at omniti.com>
> Gesendet: Mittwoch, 1. M?rz 2017 19:56:42
> Betreff: Re: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
> 
> 
> > On Mar 1, 2017, at 1:02 PM, Stephan Budach <stephan.budach at jvm.de>
> > wrote:
> > 
> > Hi Dan
> > 
> > Well, I just got it a shot on my Oracle VM cluster and after the
> > iso loaded, it threw this on the screen:
> > 
> > BTX loader 1.00 Starting in protected mode (base mem=9d400)
> > .
> > .
> > .
> > BIOS CD is cd0
> > 
> > Next is some kind of stack trace and finally
> > 
> > BTX halted
> 
> Is that Xen-based?
> 
> Dan
> 
> 

Yes, it is.

Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170302/c9aa3f0a/attachment-0001.bin>

From mir at miras.org  Thu Mar  2 10:51:55 2017
From: mir at miras.org (miras)
Date: Thu, 02 Mar 2017 11:51:55 +0100
Subject: [OmniOS-discuss] Improved, but still alpha, ISO installer
In-Reply-To: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
Message-ID: <648442c44b641e1bc649e3905b9bf948@miras.org>

On 2017-03-02 03:40, Dan McDonald wrote:
> 2.) Thanks to IRC user "thebug" for confirming this, but it now has
> sufficient bugfixes (thanks esp. to Delphix for PR-ing an illumos 7777
> fix into illumos-omnios) to detect and install vioblk devices, at
> least in a SmartOS KVM guest.
> 
This fix has not solved the problem with qemu. First disk is still 
mapped by the kernel to the last disk so /dev/dsk/1 and /dev/dsk/n is 
pointing to the same physical disk (n is the number of last disk).

Apart from this I also noticed that diskinfo only lists the last disk - 
perhaps as a consequence of the kernel is mapping /dev/dsk for first and 
last disk to the same physical disk.

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

----

This mail was virus scanned and spam checked before delivery.
This mail is also DKIM signed. See header dkim-signature.


From nnmiller at gmail.com  Thu Mar  2 12:29:20 2017
From: nnmiller at gmail.com (N. Nadine Miller)
Date: Thu, 2 Mar 2017 07:29:20 -0500
Subject: [OmniOS-discuss] Change in uname behavior between r151014 and
	r151020?
In-Reply-To: <236E8D27-9ACC-4B37-9340-DA3BF28B9696@omniti.com>
References: <CACfqXAL-V_KOndrSn_7+mpbq7t8L6-1a=+fLp9OTa5uMu6nFaQ@mail.gmail.com>
	<236E8D27-9ACC-4B37-9340-DA3BF28B9696@omniti.com>
Message-ID: <CACfqXAKvAuY+Vx+R9ce=L9=jYwjadp6jwBzY8N7TJXDX5+ihHg@mail.gmail.com>

On Wed, Mar 1, 2017 at 10:39 AM, Dan McDonald <danmcd at omniti.com> wrote:
>
>> On Mar 1, 2017, at 8:56 AM, N. Nadine Miller <nnmiller at gmail.com> wrote:
>>
>> I installed pkgsrc some time ago and attempted to upgrade this
>> morning. When I attempted to update the pkg tools, it gave me an error
>
> What exactly do you mean when you says "update the pkg tools"?

Joyent has a process to upgrade pkgsrc, one of those steps is:

PKG_PATH=http://pkgsrc.joyent.com/packages/SmartOS/2016Q4/x86_64/All
pkg_add -U pkg_install pkgin

This failed with an error that I mistakenly took to mean that my
kernel was not 64-bit. After looking at uname, and then isainfo, I
realized that the error was due to the Joyent pkgsrc I have installed
being 32-bit and the upgrade I attempted to install being 64-bit.

This has nothing to do with how uname behaves, which triggered me to post.

>> regarding 32-bit vs 64-bit, so reflexively I checked 'uname' output to
>> verify I hadn't broken my recent update to r151020.
>>
>> I discovered that 'uname' incorrectly reports that I have a 32-bit
>> version of OmniOS:
>>> root at jarvis:/opt# uname -a
>>> SunOS jarvis 5.11 omnios-bed3013 i86pc i386 i86pc
>
> That (mis)behavior has always been there.

Thanks for verifying that. I hadn't realized that has always been the
behavior, OmniOS generally "just works" so I had not run into this
oddity previously, and my incorrect assumption in the subject.

[...]
> Also correct -- the binaries in /sbin are compiled 32-bit for ancient reasons.  And you may also notice that a binary in /usr/{bin,sbin} is also 32-bit, but there are /usr/{bin,sbin}/{i86,i386,amd64} versions, which are auto-switched-into the correct version based on isainfo:
>
> r151014(~/ws/illumos-omnios)[0]% ls -lt /usr/sbin/dtrace
> -r-xr-xr-x  77 root     bin        12768 Feb  3  2015 /usr/sbin/dtrace*
> r151014(~/ws/illumos-omnios)[0]% ls -lt /usr/sbin/*/dtrace
> -r-xr-xr-x   1 root     bin        57920 Dec 31 01:50 /usr/sbin/amd64/dtrace*
> -r-xr-xr-x   1 root     bin        50924 Dec 31 01:50 /usr/sbin/i86/dtrace*
> r151014(~/ws/illumos-omnios)[0]%

I was aware of this, thanks to the thorough documentation on how this
works to provide both versions, hence my confusion about uname.

Thanks for the response.

=Nadine=

From danmcd at omniti.com  Thu Mar  2 14:18:14 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 2 Mar 2017 09:18:14 -0500
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <1426011197.2342.1488439739030.JavaMail.stephan.budach@stephanbudach.local>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<372957988.1207.1488268775446.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<929E9A7E-7211-4321-A589-AFA31804BEE0@omniti.com>
	<351930109.2266.1488391343000.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<2B100205-94FC-4F3B-A1E8-79174B58851E@omniti.com>
	<1426011197.2342.1488439739030.JavaMail.stephan.budach@stephanbudach.local>
Message-ID: <03D4C8D7-05B0-441B-B973-562309120486@omniti.com>


> On Mar 2, 2017, at 2:29 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
> 
>>> 
>>> Next is some kind of stack trace and finally
>>> 
>>> BTX halted
>> 
>> Is that Xen-based?
>> 
>> Dan
>> 
>> 
> 
> Yes, it is.

Doug Hughes just showed me the same thing, and I'm pretty sure he's Xen too.

I wonder if I need to add BE items to the ISO.  I think instead of /kernel/i86pc/kernel/amd64/unix, you Xen folks may need to boot /platform/i86{hvm,xpv}/kernel/amd64/unix instead.  Worst case is I have to build a distinct xpv or hvm ISO.  :-P

Like I said, today's going to be a reading day, but I'll add that to my work on build_iso.sh, as that's where it belongs.

Thanks,
Dan


From doug at will.to  Thu Mar  2 15:22:19 2017
From: doug at will.to (Doug Hughes)
Date: Thu, 2 Mar 2017 10:22:19 -0500
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <03D4C8D7-05B0-441B-B973-562309120486@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<372957988.1207.1488268775446.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<929E9A7E-7211-4321-A589-AFA31804BEE0@omniti.com>
	<351930109.2266.1488391343000.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<2B100205-94FC-4F3B-A1E8-79174B58851E@omniti.com>
	<1426011197.2342.1488439739030.JavaMail.stephan.budach@stephanbudach.local>
	<03D4C8D7-05B0-441B-B973-562309120486@omniti.com>
Message-ID: <76388475-375e-a64a-84bb-1e51a1f8e6f3@will.to>



On 3/2/2017 9:18 AM, Dan McDonald wrote:
>> On Mar 2, 2017, at 2:29 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
>>
>>>> Next is some kind of stack trace and finally
>>>>
>>>> BTX halted
>>> Is that Xen-based?
>>>
>>> Dan
>>>
>>>
>> Yes, it is.
> Doug Hughes just showed me the same thing, and I'm pretty sure he's Xen too.
>
> I wonder if I need to add BE items to the ISO.  I think instead of /kernel/i86pc/kernel/amd64/unix, you Xen folks may need to boot /platform/i86{hvm,xpv}/kernel/amd64/unix instead.  Worst case is I have to build a distinct xpv or hvm ISO.  :-P
>
> Like I said, today's going to be a reading day, but I'll add that to my work on build_iso.sh, as that's where it belongs.
>
> Thanks,
> Dan
>
>

I'm on libvirt/KVM/qemu
If it matters, it's an AMD processor (but I seriously doubt it)



From stephan.budach at jvm.de  Thu Mar  2 18:01:49 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Thu, 2 Mar 2017 19:01:49 +0100 (CET)
Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
In-Reply-To: <03D4C8D7-05B0-441B-B973-562309120486@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<372957988.1207.1488268775446.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<929E9A7E-7211-4321-A589-AFA31804BEE0@omniti.com>
	<351930109.2266.1488391343000.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<2B100205-94FC-4F3B-A1E8-79174B58851E@omniti.com>
	<1426011197.2342.1488439739030.JavaMail.stephan.budach@stephanbudach.local>
	<03D4C8D7-05B0-441B-B973-562309120486@omniti.com>
Message-ID: <1353696808.23.1488477671914.JavaMail.stephan.budach@budy.stephanbudach.de>



----- Urspr?ngliche Mail -----
> Von: "Dan McDonald" <danmcd at omniti.com>
> An: "Stephan Budach" <stephan.budach at jvm.de>
> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>, "Dan McDonald" <danmcd at omniti.com>
> Gesendet: Donnerstag, 2. M?rz 2017 15:18:14
> Betreff: Re: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
> 
> 
> > On Mar 2, 2017, at 2:29 AM, Stephan Budach <stephan.budach at jvm.de>
> > wrote:
> > 
> >>> 
> >>> Next is some kind of stack trace and finally
> >>> 
> >>> BTX halted
> >> 
> >> Is that Xen-based?
> >> 
> >> Dan
> >> 
> >> 
> > 
> > Yes, it is.
> 
> Doug Hughes just showed me the same thing, and I'm pretty sure he's
> Xen too.
> 
> I wonder if I need to add BE items to the ISO.  I think instead of
> /kernel/i86pc/kernel/amd64/unix, you Xen folks may need to boot
> /platform/i86{hvm,xpv}/kernel/amd64/unix instead.  Worst case is I
> have to build a distinct xpv or hvm ISO.  :-P
> 
> Like I said, today's going to be a reading day, but I'll add that to
> my work on build_iso.sh, as that's where it belongs.
> 
> Thanks,
> Dan
> 
> 

Great - that would be a blast!

Happy reading,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170302/e0680f0b/attachment-0001.bin>

From tobi at oetiker.ch  Fri Mar  3 10:32:24 2017
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Fri, 3 Mar 2017 11:32:24 +0100 (CET)
Subject: [OmniOS-discuss] what about zfs-io-priority
Message-ID: <1359485346.693750.1488537144331.JavaMail.zimbra@oetiker.ch>

Did zfs-io-priority for zones ever make it into omnios ? 

https://omnios.omniti.com/ticket.php/13 suggests it did 

but the notes on configuring it from 
https://wiki.smartos.org/display/DOC/Tuning+the+IO+Throttle 

don't seem to apply. 

anyone ? 

cheers 
tobi 

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170303/e290fdf7/attachment.html>

From danmcd at omniti.com  Fri Mar  3 13:40:24 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 3 Mar 2017 08:40:24 -0500
Subject: [OmniOS-discuss] what about zfs-io-priority
In-Reply-To: <1359485346.693750.1488537144331.JavaMail.zimbra@oetiker.ch>
References: <1359485346.693750.1488537144331.JavaMail.zimbra@oetiker.ch>
Message-ID: <24EFDB5E-745E-4FA2-9C70-5F1DBD2B6BC9@omniti.com>


> On Mar 3, 2017, at 5:32 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
> 
> Did zfs-io-priority for zones ever make it into omnios ?
> 
>   https://omnios.omniti.com/ticket.php/13 suggests it did
> 
> but the notes on configuring it from 
>  
>   https://wiki.smartos.org/display/DOC/Tuning+the+IO+Throttle
> 
> don't seem to apply.
> 
> anyone ?

I think an early version was ported in, and nobody kept up with any subsequent changes from Joyent afterwards.

If that wiki has older revs, see if they apply instead.

Dan


From tobi at oetiker.ch  Fri Mar  3 13:56:38 2017
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Fri, 3 Mar 2017 14:56:38 +0100 (CET)
Subject: [OmniOS-discuss] what about zfs-io-priority
In-Reply-To: <24EFDB5E-745E-4FA2-9C70-5F1DBD2B6BC9@omniti.com>
References: <1359485346.693750.1488537144331.JavaMail.zimbra@oetiker.ch>
	<24EFDB5E-745E-4FA2-9C70-5F1DBD2B6BC9@omniti.com>
Message-ID: <alpine.DEB.2.20.1703031455050.32049@froburg.oetiker.ch>

Hi Dan

you imported the change in r14 and the article from the joyent wiki
is from Sep 21, 2011

so I guess if anything, you have something newer than what is
described in the joyent wiki, but the question is what ...

cheers
tobi


Today Dan McDonald wrote:

>
> > On Mar 3, 2017, at 5:32 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
> >
> > Did zfs-io-priority for zones ever make it into omnios ?
> >
> >   https://omnios.omniti.com/ticket.php/13 suggests it did
> >
> > but the notes on configuring it from
> >
> >   https://wiki.smartos.org/display/DOC/Tuning+the+IO+Throttle
> >
> > don't seem to apply.
> >
> > anyone ?
>
> I think an early version was ported in, and nobody kept up with any subsequent changes from Joyent afterwards.
>
> If that wiki has older revs, see if they apply instead.
>
> Dan
>
>

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


From danmcd at omniti.com  Fri Mar  3 14:16:09 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 3 Mar 2017 09:16:09 -0500
Subject: [OmniOS-discuss] what about zfs-io-priority
In-Reply-To: <alpine.DEB.2.20.1703031455050.32049@froburg.oetiker.ch>
References: <1359485346.693750.1488537144331.JavaMail.zimbra@oetiker.ch>
	<24EFDB5E-745E-4FA2-9C70-5F1DBD2B6BC9@omniti.com>
	<alpine.DEB.2.20.1703031455050.32049@froburg.oetiker.ch>
Message-ID: <B348CEBE-0A73-4A4C-A653-6ECD9D80E384@omniti.com>


> On Mar 3, 2017, at 8:56 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
> 
> you imported the change in r14 and the article from the joyent wiki
> is from Sep 21, 2011

I see what happened.

#14 was backed out, likely due to insane merge hell (maintaining a sideport is ongoing work... trust me, LX).  It was merged back in with #72, BUT it didn't include the zonecfg changes.  :-/

I'm not sure what to make of this, all of it happened before I arrived at OmniTI.  I'm heading down to OmniTI's office in a little over a week, maybe I can sort it out there.

Dan


From peter.tribble at gmail.com  Fri Mar  3 15:06:24 2017
From: peter.tribble at gmail.com (Peter Tribble)
Date: Fri, 3 Mar 2017 15:06:24 +0000
Subject: [OmniOS-discuss] Improved, but still alpha, ISO installer
In-Reply-To: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
Message-ID: <CAEgYsbEhYDM+Se37rYfNFw1rGT-S1+pkaQKyc18O60BgbBL5zA@mail.gmail.com>

Dan,

On Thu, Mar 2, 2017 at 2:40 AM, Dan McDonald <danmcd at omniti.com> wrote:

> Please refresh your copy by downloading here:
>
>         http://kebe.com/~danmcd/webrevs/r151021-kayak.iso
>

So I had a play with this on vultr (cloud, KVM based, virtio)

And it worked pretty well, takes a while to load the boot archive but
other than that worked just fine.

Couple of things I noticed:

There's no org.opensolaris.libbe:uuid property set on the root filesystem's
dataset, which I think you'll need

I saw a message at boot I didn't recognise:
"Short hash module of length 0x0 bytes; ignoring"

Mind you, it's confused between c3t0d0 and c2t0d0:

$ zpool status
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Fri Mar  3 15:03:09 2017
config:

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

# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c2t0d0 <Virtio-Block Device-0000-40.00GB>
          /pci at 0,0/pci1af4,2 at 4/blkdev at 0,0

It was c3t0d0 in the installer shell, but that device no longer exisst and
it's
moved to c2t0d0.

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

From dirk.willems at exitas.be  Fri Mar  3 15:12:24 2017
From: dirk.willems at exitas.be (Dirk Willems)
Date: Fri, 3 Mar 2017 16:12:24 +0100
Subject: [OmniOS-discuss] qemu: too many IDE bus
Message-ID: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>

Hello,

I experience some issue's with too many IDE bus on KVM ?

I'm only allowed to having 3 HDD, when I add the fourth HDD I get the 
following error

qemu: too many IDE bus

root at OmniosExitas:/KVM_Machines/JDN# ./JDN01_Start-VM.sh
qemu-system-x86_64: -net 
vnic,vlan=0,name=net0,ifname=VLJDN01,macaddr=2:8:20:2:4b:a4,: vnic dhcp 
disabled

qemu-system-x86_64: -net 
vnic,vlan=1,name=net1,ifname=VSJDN01,macaddr=2:8:20:67:1:7c,: vnic dhcp 
disabled

qemu: too many IDE bus
Failed to start VM
Started VM:
Public: 127.0.0.1
10.100.23.86
::1/128
::/0:5903


I just upgrade to

root at OmniosExitas:/KVM_Machines/JDN# uname -a
SunOS OmniosExitas 5.11 omnios-r151020-4151d05 i86pc i386 i86pc

Any suggestions ?


Thanks in advance.


Kind Regards.


Dirk



-- 
	Dirk Willems
System Engineer


+32 (0)3 443 12 38
Dirk.Willems at exitas.be <mailto:Dirk.Willems at exitas.be>

Quality. Passion. Personality

www.exitas.be <http://www.exitas.be/> | Veldkant 31 | 2550 Kontich

Illumos OmniOS Installation and Configuration Implementation Specialist.
Oracle Solaris 11 Installation and Configuration Certified 
Implementation Specialist. 	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170303/a5410a31/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: placeholder-exitas.jpg
Type: image/jpeg
Size: 12658 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170303/a5410a31/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmallPhoenixLogotypeRGB.png
Type: image/png
Size: 4648 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170303/a5410a31/attachment-0001.png>

From danmcd at omniti.com  Fri Mar  3 15:23:57 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 3 Mar 2017 10:23:57 -0500
Subject: [OmniOS-discuss] Improved, but still alpha, ISO installer
In-Reply-To: <CAEgYsbEhYDM+Se37rYfNFw1rGT-S1+pkaQKyc18O60BgbBL5zA@mail.gmail.com>
References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
	<CAEgYsbEhYDM+Se37rYfNFw1rGT-S1+pkaQKyc18O60BgbBL5zA@mail.gmail.com>
Message-ID: <D9560901-9483-4495-A714-B172975CD21D@omniti.com>


> On Mar 3, 2017, at 10:06 AM, Peter Tribble <peter.tribble at gmail.com> wrote:
> 
> Dan,
> 
> On Thu, Mar 2, 2017 at 2:40 AM, Dan McDonald <danmcd at omniti.com> wrote:
> Please refresh your copy by downloading here:
> 
>         http://kebe.com/~danmcd/webrevs/r151021-kayak.iso
> 
> So I had a play with this on vultr (cloud, KVM based, virtio)
> 
> And it worked pretty well, takes a while to load the boot archive but
> other than that worked just fine.

The boot archive takes so long because I was lazy and put the ZFS send stream IN the boot archive itself, instead of figuring out how to make it a separate mount point from boot archive and have it be on the ISO, but not on the boot archive.

> Couple of things I noticed:
> 
> There's no org.opensolaris.libbe:uuid property set on the root filesystem's
> dataset, which I think you'll need

Even after "beadm activate"?  That seems odd.

OTOH, I've not noticed this getting set in either traditional Kayak (the PXE one) OR even the caiman installer we use.  I wonder if that property is set after a fresh old-school Installation?  (I can find out later...)

> I saw a message at boot I didn't recognise:
> "Short hash module of length 0x0 bytes; ignoring"

This is a known bug.  We're missing the digest(1M) command & friends in the image the installer uses for rootfs.  I need to add this, that way bootadm(1M) will DTRT.  If that brings along too much code, the gnu-binutils sha1sum is already there, so I can create these by hand during the installer script.

> Mind you, it's confused between c3t0d0 and c2t0d0:
> 
> $ zpool status
>   pool: rpool
>  state: ONLINE
>   scan: scrub repaired 0 in 0h0m with 0 errors on Fri Mar  3 15:03:09 2017
> config:
> 
>     NAME        STATE     READ WRITE CKSUM
>     rpool       ONLINE       0     0     0
>       c3t0d0    ONLINE       0     0     0
> 
> # format
> Searching for disks...done
> 
> 
> AVAILABLE DISK SELECTIONS:
>        0. c2t0d0 <Virtio-Block Device-0000-40.00GB>
>           /pci at 0,0/pci1af4,2 at 4/blkdev at 0,0
> 
> It was c3t0d0 in the installer shell, but that device no longer exisst and it's
> moved to c2t0d0.

What does "diskinfo" say?  Also, I seem to recall there's an issue with Xen-like environments where the same disk gets two /dev/ entries.

Thank you!
Dan


From bfriesen at simple.dallas.tx.us  Fri Mar  3 15:31:48 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 3 Mar 2017 09:31:48 -0600 (CST)
Subject: [OmniOS-discuss] USB issue with Xeon D / SuperMicro X10SDV-TLN4F
	motherboard
Message-ID: <alpine.GSO.2.20.1703030910030.12318@freddy.simplesystems.org>

With a SuperMicro X10SDV-TLN4F motherboard with BIOS version 1.0a and 
latest OmniOS v11 r151020 (omnios-r151020-4151d05), I noticed a USB 
issue yesterday while I was adding an Adderview Pro KVM to the 
configuration.  The BIOS is configured for USB 2.0 compatibility.

This motherboard provides two USB ports.  I think that previously I 
had a keyboard plugged directly into the lower port.

My hardware builder (who also installed the OS) reported that he 
noticed USB issues with this hardware and OmniOS (he claimed a need to 
cold-boot the system) but I had not noticed issues until yesterday.

With the KVM or keyboard plugged into the upper USB port, Grub was 
able to function normally with the keyboard but OmniOS reports these 
messages after boot:

USB 1.10 device (usb430,5) operating at low speed (USB 1.x) on USB 1.10 external hub: keyboard at 1, hid14 at bus address 9
WARNING: /pci at 0,0/pci15d9,86d at 1d (ehci1): Error recovery failure: Please hotplug the 2.0 hub at/pci at 0,0/pci15d9,86d at 1d/hub at 1/hub at 1
WARNING: /pci at 0,0/pci15d9,86d at 1d/hub at 1/hub at 1/hub at 1 (hubd7): Connecting device on port 2 failed

By moving the USB cable to the lower port, USB works fine in OmniOS.

Is this issue reproducible elsewhere?  I think that Dale Gent has 
access to the same hardware (but with BIOS 1.0c).

I have another OmniOS system, as well as a Sun SPARC Solaris 10 
system, on the same KVM and these did not encounter any USB issue.

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

From bfriesen at simple.dallas.tx.us  Fri Mar  3 23:57:07 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 3 Mar 2017 17:57:07 -0600 (CST)
Subject: [OmniOS-discuss] dhcpd quits with error if subnet exists which is
 not in config file
Message-ID: <alpine.GSO.2.20.1703031753070.12318@freddy.simplesystems.org>

Today I added a temporary subnet on an interface for temporary 
testing.

When I restarted dhcpd, it went into maintenance state due to this 
error (setsockopt: IP_PKTINFO: Bad file number).  The complaint about 
the unknown subnet seems benign but the setsockopt error is not.  This 
issue seems harmful for servers which may have a lot of interfaces, 
which may come and go:

Mar  3 17:49:20 scrappy dhcpd: [ID 702911 daemon.error] No subnet declaration for igb1 (192.168.0.1).
Mar  3 17:49:20 scrappy dhcpd: [ID 702911 daemon.error] ** Ignoring requests on igb1.  If this is not what
Mar  3 17:49:20 scrappy dhcpd: [ID 702911 daemon.error]    you want, please write a subnet declaration
Mar  3 17:49:20 scrappy dhcpd: [ID 702911 daemon.error]    in your dhcpd.conf file for the network segment
Mar  3 17:49:20 scrappy dhcpd: [ID 702911 daemon.error]    to which interface igb1 is attached. **
Mar  3 17:49:20 scrappy dhcpd: [ID 702911 daemon.error]
Mar  3 17:49:26 scrappy dhcpd: [ID 702911 daemon.error] setsockopt: IP_PKTINFO: Bad file number
Mar  3 17:49:26 scrappy dhcpd: [ID 702911 daemon.error]
Mar  3 17:49:26 scrappy dhcpd: [ID 702911 daemon.error] If you think you have received this message due to a bug rather
Mar  3 17:49:26 scrappy dhcpd: [ID 702911 daemon.error] than a configuration issue please read the section on submitting
Mar  3 17:49:26 scrappy dhcpd: [ID 702911 daemon.error] bugs on either our web page at www.isc.org or in the README file
Mar  3 17:49:26 scrappy dhcpd: [ID 702911 daemon.error] before submitting a bug.  These pages explain the proper
Mar  3 17:49:26 scrappy dhcpd: [ID 702911 daemon.error] process and the information we find helpful for debugging..
Mar  3 17:49:26 scrappy dhcpd: [ID 702911 daemon.error]
Mar  3 17:49:26 scrappy dhcpd: [ID 702911 daemon.error] exiting.

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

From gearboxes at outlook.com  Sun Mar  5 17:56:31 2017
From: gearboxes at outlook.com (Machine Man)
Date: Sun, 5 Mar 2017 17:56:31 +0000
Subject: [OmniOS-discuss] stmfproxy ALUA RSF-1
Message-ID: <CY4PR0101MB31609D1FEC9DC67CB1F2571EE72D0@CY4PR0101MB3160.prod.exchangelabs.com>

I am in the process of deploying RSF-1 and running into trouble with ALUA. Access is slow or most of the time it does not work.
Disabling ALUA access instantly works, but requires a rescan on the VMware nodes when failing over.

I see the following on both nodes:

 [ID 602194 daemon.warning] recv() call failed: 0
 [ID 682322 daemon.warning] postMsg() no transport handle

I am assuming this is related to my problem?

We are using OmniOS current LTS with all updates applied. FC target with 2x dual port HBAs

Thanks,


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

From daniel at dgnetwork.com.br  Sun Mar  5 22:53:20 2017
From: daniel at dgnetwork.com.br (=?UTF-8?Q?Daniel_D._Gon=c3=a7alves?=)
Date: Sun, 5 Mar 2017 19:53:20 -0300
Subject: [OmniOS-discuss] Seagate 4k HDD model ST4000NM0085
Message-ID: <bbe72fe5-e833-9be7-474a-9bab4e5bac30@dgnetwork.com.br>

I have a problem with Seagate 4k HDD model ST4000NM0085, my controller 
M1015 doesn't detect the hd, only onboard SATA, but not ready to work.

When i tried:
echo "::walk sd_state | ::grep '.!=0' | ::print struct sd_lun un_sd | \
   ::print struct scsi_device sd_inq | ::print struct scsi_inquiry \
   inq_vid inq_pid" | mdb -k

Doesn't show the HDD model ST4000NM0085.

On dmesg with onboard SATA:
Mar  5 19:41:05 storage02  SATA device detected at port 5
Mar  5 19:41:05 storage02 genunix: [ID 663010 kern.info] 
/pci at 0,0/pci8086,7270 at 1f,2 :
Mar  5 19:41:05 storage02 genunix: [ID 761595 kern.info]        SATA 
disk device at port 5
Mar  5 19:41:05 storage02 genunix: [ID 846691 kern.info] model 
ST4000NM0085-1YY107
Mar  5 19:41:05 storage02 genunix: [ID 693010 kern.info] firmware NN02
Mar  5 19:41:05 storage02 genunix: [ID 163988 kern.info] serial 
number             ZC101MCH
Mar  5 19:41:05 storage02 genunix: [ID 594940 kern.info] supported features:
Mar  5 19:41:05 storage02 genunix: [ID 981177 kern.info] 48-bit LBA, 
DMA, Native Command Queueing, SMART, SMART self-test
Mar  5 19:41:05 storage02 genunix: [ID 996592 kern.info]        SATA 
Gen3 signaling speed (6.0Gbps)
Mar  5 19:41:05 storage02 genunix: [ID 349649 kern.info] Supported queue 
depth 32
Mar  5 19:41:05 storage02 genunix: [ID 349649 kern.info] capacity = 
976754646 sectors

On dmesg with M1015 controller not show nothing.

Is there anything I should consider?

Thanks,
Daniel



---
Este email foi escaneado pelo Avast antiv?rus.
https://www.avast.com/antivirus


From danmcd at omniti.com  Mon Mar  6 14:34:11 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 6 Mar 2017 09:34:11 -0500
Subject: [OmniOS-discuss] stmfproxy ALUA RSF-1
In-Reply-To: <CY4PR0101MB31609D1FEC9DC67CB1F2571EE72D0@CY4PR0101MB3160.prod.exchangelabs.com>
References: <CY4PR0101MB31609D1FEC9DC67CB1F2571EE72D0@CY4PR0101MB3160.prod.exchangelabs.com>
Message-ID: <6CACA42B-A8CE-4A8D-9A35-83B5C758B877@omniti.com>


> On Mar 5, 2017, at 12:56 PM, Machine Man <gearboxes at outlook.com> wrote:
> 
> I see the following on both nodes:
> 
>  [ID 602194 daemon.warning] recv() call failed: 0
>  [ID 682322 daemon.warning] postMsg() no transport handle
> 
> I am assuming this is related to my problem?

This is likely an RSF-1 problem. Have you checked with them about this yet?

Dan


From danmcd at omniti.com  Mon Mar  6 15:10:05 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 6 Mar 2017 10:10:05 -0500
Subject: [OmniOS-discuss] Seagate 4k HDD model ST4000NM0085
In-Reply-To: <bbe72fe5-e833-9be7-474a-9bab4e5bac30@dgnetwork.com.br>
References: <bbe72fe5-e833-9be7-474a-9bab4e5bac30@dgnetwork.com.br>
Message-ID: <741165EC-4A21-475A-B96C-D03A9704C49C@omniti.com>


> On Mar 5, 2017, at 5:53 PM, Daniel D. Gon?alves <daniel at dgnetwork.com.br> wrote:
> 
> I have a problem with Seagate 4k HDD model ST4000NM0085, my controller M1015 doesn't detect the hd, only onboard SATA, but not ready to work.
> 
> When i tried:
> echo "::walk sd_state | ::grep '.!=0' | ::print struct sd_lun un_sd | \
>  ::print struct scsi_device sd_inq | ::print struct scsi_inquiry \
>  inq_vid inq_pid" | mdb -k
> 
> Doesn't show the HDD model ST4000NM0085.
> 
> On dmesg with onboard SATA:
> Mar  5 19:41:05 storage02  SATA device detected at port 5
> Mar  5 19:41:05 storage02 genunix: [ID 663010 kern.info] /pci at 0,0/pci8086,7270 at 1f,2 :
> Mar  5 19:41:05 storage02 genunix: [ID 761595 kern.info]        SATA disk device at port 5
> Mar  5 19:41:05 storage02 genunix: [ID 846691 kern.info] model ST4000NM0085-1YY107
> Mar  5 19:41:05 storage02 genunix: [ID 693010 kern.info] firmware NN02
> Mar  5 19:41:05 storage02 genunix: [ID 163988 kern.info] serial number             ZC101MCH
> Mar  5 19:41:05 storage02 genunix: [ID 594940 kern.info] supported features:
> Mar  5 19:41:05 storage02 genunix: [ID 981177 kern.info] 48-bit LBA, DMA, Native Command Queueing, SMART, SMART self-test
> Mar  5 19:41:05 storage02 genunix: [ID 996592 kern.info]        SATA Gen3 signaling speed (6.0Gbps)
> Mar  5 19:41:05 storage02 genunix: [ID 349649 kern.info] Supported queue depth 32
> Mar  5 19:41:05 storage02 genunix: [ID 349649 kern.info] capacity = 976754646 sectors
> 
> On dmesg with M1015 controller not show nothing.
> 
> Is there anything I should consider?

1.) You're not saying which revision of OmniOS you're using.

2.) The M1015... is it FW flashed to look like any other LSI 920x board?  (Put another way, are you using mpt_sas?)  If not, how does this board show up to the system?

Dan


From omnios at citrus-it.net  Tue Mar  7 16:28:08 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Tue, 7 Mar 2017 16:28:08 +0000 (UTC)
Subject: [OmniOS-discuss] Improved, but still alpha, ISO installer
In-Reply-To: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
Message-ID: <alpine.GSO.2.20.1703071624470.203757@erncre.pvgehf-vg.arg>


On Wed, 1 Mar 2017, Dan McDonald wrote:

; Please refresh your copy by downloading here:
;
; 	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

I'm a bit late to the party but I've downloaded this and burned it to a
CD (old school, I know) and tried booting a Dell R620. It hangs just after
printing:

	loading ficl string class
	/

With just that / on the last line.

Tried a few times but it always hangs at the same place.

Anything useful I can try?

Andy

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


From danmcd at omniti.com  Tue Mar  7 16:29:55 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 7 Mar 2017 11:29:55 -0500
Subject: [OmniOS-discuss] Improved, but still alpha, ISO installer
In-Reply-To: <alpine.GSO.2.20.1703071624470.203757@erncre.pvgehf-vg.arg>
References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
	<alpine.GSO.2.20.1703071624470.203757@erncre.pvgehf-vg.arg>
Message-ID: <22F78EFB-683C-4E74-BF60-8A4015242837@omniti.com>


> On Mar 7, 2017, at 11:28 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> 
> I'm a bit late to the party but I've downloaded this and burned it to a
> CD (old school, I know) and tried booting a Dell R620. It hangs just after
> printing:
> 
> 	loading ficl string class
> 	/
> 
> With just that / on the last line.
> 
> Tried a few times but it always hangs at the same place.
> 
> Anything useful I can try?

Hmmm... I wonder if the .iso image is a bit too large for an actual physical CD?

Can you burn it onto a dvd?

Dan


From john.barfield at bissinc.com  Tue Mar  7 20:13:47 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Tue, 7 Mar 2017 20:13:47 +0000
Subject: [OmniOS-discuss] r151020 installer issues
Message-ID: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>

I?m having several installer issues with the r151020 usb installer.

It keeps crashing at different parts with different errors.

My question is: should I be using r151014 and run pkg update until the next LTS release?

Or is there a best-practices doc that I need to follow to get r151020 working right?

This is a sunfire x4170 m2 ? All intel, cpu?s, nics, chipset,etc,etc


John Barfield
Engineering and Stuff

M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>

[cid:image001.png at 01D2974D.08ADA780]
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com<http://support.bissinc.com/> or support at bissinc.com<mailto:support at bissinc.com>

Follow us on Twitter for Network Status &  Updates!

[cid:image002.gif at 01D2974D.08ADA780]<https://twitter.com/johnbarfield>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/fdef08cf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3508 bytes
Desc: image001.png
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/fdef08cf/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1351 bytes
Desc: image002.gif
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/fdef08cf/attachment.gif>

From danmcd at omniti.com  Tue Mar  7 20:21:44 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 7 Mar 2017 15:21:44 -0500
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
Message-ID: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>

The installer crashes, or OmniOS itself crashes?  I'd like to know at least a bit more detail.

Btw, the installer for the next release of OmniOS is brand new, based on our PXE installer Kayak. Between Loader replacing GRUB, Python2.7, and reports like yours, it's time to put Caiman out to pasture.

If you're in a hurry, install 014, switch from SunSSH to OpenSSH on 014, and then upgrade to 020.

Dan

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

> On Mar 7, 2017, at 3:13 PM, John Barfield <john.barfield at bissinc.com> wrote:
> 
> I?m having several installer issues with the r151020 usb installer.
>  
> It keeps crashing at different parts with different errors.
>  
> My question is: should I be using r151014 and run pkg update until the next LTS release?
>  
> Or is there a best-practices doc that I need to follow to get r151020 working right?
>  
> This is a sunfire x4170 m2 ? All intel, cpu?s, nics, chipset,etc,etc
>  
>  
> John Barfield
> Engineering and Stuff
>  
> M: +1 (214) 425-0783  O: +1 (214) 506-8354 
> john.barfield at bissinc.com
>  
> <image001.png>
> 4925 Greenville Ave, Ste 900
> Dallas, TX 75206
>  
> For Support Requests:
> http://support.bissinc.com or support at bissinc.com
>  
> Follow us on Twitter for Network Status &  Updates!
>  
> <image002.gif> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/b11ff81b/attachment-0001.html>

From daleg at omniti.com  Tue Mar  7 20:22:24 2017
From: daleg at omniti.com (Dale Ghent)
Date: Tue, 7 Mar 2017 15:22:24 -0500
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
Message-ID: <0657F116-2C8F-4090-80C5-2C6E6B873046@omniti.com>


> On Mar 7, 2017, at 3:13 PM, John Barfield <john.barfield at bissinc.com> wrote:
> 
> I?m having several installer issues with the r151020 usb installer.
> 
> It keeps crashing at different parts with different errors.

Don't keep us in suspense! What are the errors you are seeing?

> My question is: should I be using r151014 and run pkg update until the next LTS release?

You should under normal circumstances be able to install using the 020 media as you are attempting to do.

> Or is there a best-practices doc that I need to follow to get r151020 working right?

Under normal circumstances, the "best practice" is boot the install image, and use the installer. It would be really helpful to know what these errors you're seeing consist of. X4170s are old Intel Westemere-based systems; OmniOS should have no problems running on these. Are you using the on-board SAS controller in a hardware RAID mode?

/dale

> This is a sunfire x4170 m2 ? All intel, cpu?s, nics, chipset,etc,etc
> 
> 
> John Barfield
> Engineering and Stuff
> 
> M: +1 (214) 425-0783  O: +1 (214) 506-8354
> john.barfield at bissinc.com
> 
> <image001.png>
> 4925 Greenville Ave, Ste 900
> Dallas, TX 75206
> 
> For Support Requests:
> http://support.bissinc.com or support at bissinc.com
> 
> Follow us on Twitter for Network Status &  Updates!
> 
> <image002.gif>
> _______________________________________________
> 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: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/43c01e5f/attachment.bin>

From john.barfield at bissinc.com  Tue Mar  7 20:25:32 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Tue, 7 Mar 2017 20:25:32 +0000
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
Message-ID: <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>

Yeah, its definitely the hurry factor?this SAN was running r151012 and instead of upgrading I?m just reinstalling. (going on pretty long outage duration now)

I did get python errors @99% the last time I ran the installer.

Here are a list of issues I had (I did not write down the actual error messages so these are simply generic):


?         Crashed @5% after copying data into var

o    Dropped to shell checked install log

?  Saw complaint about dumpdev not unmounting so I removed it and re-ran the installer

?         After rerunning the installer the system got to 99% and color terminal disappeared?I just saw random messages about disks infinitely

o    Rebooted and reran installer

?         This time I got all the way through the installer to 99% and it crashed. A lot of python errors in the installer log.

?         Gave up and downloaded the r14

John Barfield
Engineering and Stuff

M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>

[cid:image001.png at 01D2974E.AD10AC40]
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com<http://support.bissinc.com/> or support at bissinc.com<mailto:support at bissinc.com>

Follow us on Twitter for Network Status &  Updates!

[cid:image002.gif at 01D2974E.AD10AC40]<https://twitter.com/johnbarfield>

From: Dan McDonald <danmcd at omniti.com>
Date: Tuesday, March 7, 2017 at 2:21 PM
To: John Barfield <john.barfield at bissinc.com>
Cc: "omnios-discuss at lists.omniti.com" <omnios-discuss at lists.omniti.com>, Dan McDonald <danmcd at omniti.com>
Subject: Re: [OmniOS-discuss] r151020 installer issues

Btw, the installer for the next release of OmniOS is brand new, based on our PXE installer Kayak. Between Loader replacing GRUB, Python2.7, and reports like yours, it's time to put Caiman out to pasture.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/f489fa85/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3508 bytes
Desc: image001.png
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/f489fa85/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1351 bytes
Desc: image002.gif
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/f489fa85/attachment-0001.gif>

From john.barfield at bissinc.com  Tue Mar  7 20:27:10 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Tue, 7 Mar 2017 20:27:10 +0000
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <0657F116-2C8F-4090-80C5-2C6E6B873046@omniti.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<0657F116-2C8F-4090-80C5-2C6E6B873046@omniti.com>
Message-ID: <0E98CCD8-44F5-424A-9FD7-AFAB5C7468FD@bissinc.com>

Not using hardware RAID mode. It is using the on board SAS controller but I?m running in jbod or passthrough mode. Whatever its called on here. 

I just sent a list of errors that I?ve hit so far to the list replying to Dan McDonald.

If you guys really want me to I?ll rerun the installer one more time and get actual screenshots from the ilom. 



John Barfield
Engineering and Stuff 
 
M: +1 (214) 425-0783  O: +1 (214) 506-8354 
john.barfield at bissinc.com
 

4925 Greenville Ave, Ste 900
Dallas, TX 75206
 
For Support Requests:
http://support.bissinc.com <http://support.bissinc.com/> or support at bissinc.com
 
Follow us on Twitter for Network Status &  Updates! 
 
 <https://twitter.com/johnbarfield>  

On 3/7/17, 2:22 PM, "Dale Ghent" <daleg at omniti.com> wrote:

    
    > On Mar 7, 2017, at 3:13 PM, John Barfield <john.barfield at bissinc.com> wrote:
    > 
    > I?m having several installer issues with the r151020 usb installer.
    > 
    > It keeps crashing at different parts with different errors.
    
    Don't keep us in suspense! What are the errors you are seeing?
    
    > My question is: should I be using r151014 and run pkg update until the next LTS release?
    
    You should under normal circumstances be able to install using the 020 media as you are attempting to do.
    
    > Or is there a best-practices doc that I need to follow to get r151020 working right?
    
    Under normal circumstances, the "best practice" is boot the install image, and use the installer. It would be really helpful to know what these errors you're seeing consist of. X4170s are old Intel Westemere-based systems; OmniOS should have no problems running on these. Are you using the on-board SAS controller in a hardware RAID mode?
    
    /dale
    
    > This is a sunfire x4170 m2 ? All intel, cpu?s, nics, chipset,etc,etc
    > 
    > 
    > John Barfield
    > Engineering and Stuff
    > 
    > M: +1 (214) 425-0783  O: +1 (214) 506-8354
    > john.barfield at bissinc.com
    > 
    > <image001.png>
    > 4925 Greenville Ave, Ste 900
    > Dallas, TX 75206
    > 
    > For Support Requests:
    > http://support.bissinc.com or support at bissinc.com
    > 
    > Follow us on Twitter for Network Status &  Updates!
    > 
    > <image002.gif>
    > _______________________________________________
    > OmniOS-discuss mailing list
    > OmniOS-discuss at lists.omniti.com
    > http://lists.omniti.com/mailman/listinfo/omnios-discuss
    
    


From danmcd at omniti.com  Tue Mar  7 20:32:00 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 7 Mar 2017 15:32:00 -0500
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
	<7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>
Message-ID: <D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>

Disappearing disks is a sign.... what disk controller are you running?  Dale mentioned some of those possibilities as well.

Dan

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

> On Mar 7, 2017, at 3:25 PM, John Barfield <john.barfield at bissinc.com> wrote:
> 
> Yeah, its definitely the hurry factor?this SAN was running r151012 and instead of upgrading I?m just reinstalling. (going on pretty long outage duration now)
>  
> I did get python errors @99% the last time I ran the installer.
>  
> Here are a list of issues I had (I did not write down the actual error messages so these are simply generic):
>  
> ?         Crashed @5% after copying data into var
> o    Dropped to shell checked install log
> ?  Saw complaint about dumpdev not unmounting so I removed it and re-ran the installer
> ?         After rerunning the installer the system got to 99% and color terminal disappeared?I just saw random messages about disks infinitely
> o    Rebooted and reran installer
> ?         This time I got all the way through the installer to 99% and it crashed. A lot of python errors in the installer log.
> ?         Gave up and downloaded the r14
>  
> John Barfield
> Engineering and Stuff
>  
> M: +1 (214) 425-0783  O: +1 (214) 506-8354 
> john.barfield at bissinc.com
>  
> <image001.png>
> 4925 Greenville Ave, Ste 900
> Dallas, TX 75206
>  
> For Support Requests:
> http://support.bissinc.com or support at bissinc.com
>  
> Follow us on Twitter for Network Status &  Updates!
>  
> <image002.gif> 
>  
> From: Dan McDonald <danmcd at omniti.com>
> Date: Tuesday, March 7, 2017 at 2:21 PM
> To: John Barfield <john.barfield at bissinc.com>
> Cc: "omnios-discuss at lists.omniti.com" <omnios-discuss at lists.omniti.com>, Dan McDonald <danmcd at omniti.com>
> Subject: Re: [OmniOS-discuss] r151020 installer issues
>  
> Btw, the installer for the next release of OmniOS is brand new, based on our PXE installer Kayak. Between Loader replacing GRUB, Python2.7, and reports like yours, it's time to put Caiman out to pasture.
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/96212d76/attachment.html>

From danmcd at omniti.com  Tue Mar  7 20:39:10 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 7 Mar 2017 15:39:10 -0500
Subject: [OmniOS-discuss] Fwd: [developer] Review request: 7948 Remove old
	calendar utility
References: <CAEgYsbEncEotZZrrfwiASc88bb_w43tgdp=6Un2UHPjszJNcAw@mail.gmail.com>
Message-ID: <237225B6-6EC9-4A0A-89EA-25E021F994C9@omniti.com>

Not to be confused with cal(1), but does anyone here use calendar(1)?

Trying to gauge how hard I should try to replace it or not.

Thanks,
Dan

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

Begin forwarded message:

> From: "Peter Tribble" <peter.tribble at gmail.com>
> Date: March 7, 2017 at 3:33:40 PM EST
> To: illumos-dev <developer at lists.illumos.org>
> Subject: [developer] Review request: 7948 Remove old calendar utility
> Reply-To: developer at lists.illumos.org
> 
> Please review:
> 
> Issue: https://illumos.org/issues/7948
> Webrev: http://pkgs.tribblix.org/webrevs/7948/
> 
> A couple of alternatives for distros (and individuals) that might
> want a replacement are mentioned in the bug report.
> 
> Thanks,
> 
> -- 
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
> illumos-developer | Archives  | Modify Your Subscription	 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/bc6363a6/attachment-0001.html>

From john.barfield at bissinc.com  Tue Mar  7 20:50:09 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Tue, 7 Mar 2017 20:50:09 +0000
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
	<7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>
	<D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>
Message-ID: <A0ADA038-B74C-4B43-9535-34A9F84491A0@bissinc.com>

I think it?s the main board.

Our original errors were related to network issues (onboard NICS) and now these installer issues appear to be SAS issues.

All PCIe related. I?m going to put in another server and go from there.

A couple more screenshots attached.

John Barfield
Engineering and Stuff

M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>

[cid:image001.png at 01D29752.1CE09B40]
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com<http://support.bissinc.com/> or support at bissinc.com<mailto:support at bissinc.com>

Follow us on Twitter for Network Status &  Updates!

[cid:image002.gif at 01D29752.1CE09B40]<https://twitter.com/johnbarfield>

From: Dan McDonald <danmcd at omniti.com>
Date: Tuesday, March 7, 2017 at 2:32 PM
To: John Barfield <john.barfield at bissinc.com>
Cc: "omnios-discuss at lists.omniti.com" <omnios-discuss at lists.omniti.com>, Dan McDonald <danmcd at omniti.com>
Subject: Re: [OmniOS-discuss] r151020 installer issues

Disappearing disks is a sign.... what disk controller are you running?  Dale mentioned some of those possibilities as well.

Dan

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

On Mar 7, 2017, at 3:25 PM, John Barfield <john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>> wrote:
Yeah, its definitely the hurry factor?this SAN was running r151012 and instead of upgrading I?m just reinstalling. (going on pretty long outage duration now)

I did get python errors @99% the last time I ran the installer.

Here are a list of issues I had (I did not write down the actual error messages so these are simply generic):


?         Crashed @5% after copying data into var

o   Dropped to shell checked install log

?  Saw complaint about dumpdev not unmounting so I removed it and re-ran the installer

?         After rerunning the installer the system got to 99% and color terminal disappeared?I just saw random messages about disks infinitely

o   Rebooted and reran installer

?         This time I got all the way through the installer to 99% and it crashed. A lot of python errors in the installer log.

?         Gave up and downloaded the r14

John Barfield
Engineering and Stuff

M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>

<image001.png>
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com<http://support.bissinc.com/> or support at bissinc.com<mailto:support at bissinc.com>

Follow us on Twitter for Network Status &  Updates!

<image002.gif><https://twitter.com/johnbarfield>

From: Dan McDonald <danmcd at omniti.com<mailto:danmcd at omniti.com>>
Date: Tuesday, March 7, 2017 at 2:21 PM
To: John Barfield <john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>>
Cc: "omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>" <omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>>, Dan McDonald <danmcd at omniti.com<mailto:danmcd at omniti.com>>
Subject: Re: [OmniOS-discuss] r151020 installer issues

Btw, the installer for the next release of OmniOS is brand new, based on our PXE installer Kayak. Between Loader replacing GRUB, Python2.7, and reports like yours, it's time to put Caiman out to pasture.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/2a7f25ee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3508 bytes
Desc: image001.png
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/2a7f25ee/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1351 bytes
Desc: image002.gif
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/2a7f25ee/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-07 at 2.40.16 PM.png
Type: image/png
Size: 478055 bytes
Desc: Screen Shot 2017-03-07 at 2.40.16 PM.png
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/2a7f25ee/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-07 at 2.47.39 PM.png
Type: image/png
Size: 160926 bytes
Desc: Screen Shot 2017-03-07 at 2.47.39 PM.png
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/2a7f25ee/attachment-0005.png>

From john.barfield at bissinc.com  Tue Mar  7 21:46:12 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Tue, 7 Mar 2017 21:46:12 +0000
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
	<7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>
	<D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>
Message-ID: <F870FA88-FFC9-4AB4-B50A-133543C629C5@bissinc.com>

Okay. I just ran it again on another x4170 m2.

Fails on the last part of the installation.

Attached installer_logs.

John Barfield
Engineering and Stuff

M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>

[cid:image001.png at 01D29759.F1FD0460]
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com<http://support.bissinc.com/> or support at bissinc.com<mailto:support at bissinc.com>

Follow us on Twitter for Network Status &  Updates!

[cid:image002.gif at 01D29759.F1FD0460]<https://twitter.com/johnbarfield>

From: Dan McDonald <danmcd at omniti.com>
Date: Tuesday, March 7, 2017 at 2:32 PM
To: John Barfield <john.barfield at bissinc.com>
Cc: "omnios-discuss at lists.omniti.com" <omnios-discuss at lists.omniti.com>, Dan McDonald <danmcd at omniti.com>
Subject: Re: [OmniOS-discuss] r151020 installer issues

Disappearing disks is a sign.... what disk controller are you running?  Dale mentioned some of those possibilities as well.

Dan

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

On Mar 7, 2017, at 3:25 PM, John Barfield <john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>> wrote:
Yeah, its definitely the hurry factor?this SAN was running r151012 and instead of upgrading I?m just reinstalling. (going on pretty long outage duration now)

I did get python errors @99% the last time I ran the installer.

Here are a list of issues I had (I did not write down the actual error messages so these are simply generic):


?         Crashed @5% after copying data into var

o   Dropped to shell checked install log

?  Saw complaint about dumpdev not unmounting so I removed it and re-ran the installer

?         After rerunning the installer the system got to 99% and color terminal disappeared?I just saw random messages about disks infinitely

o   Rebooted and reran installer

?         This time I got all the way through the installer to 99% and it crashed. A lot of python errors in the installer log.

?         Gave up and downloaded the r14

John Barfield
Engineering and Stuff

M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>

<image001.png>
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com<http://support.bissinc.com/> or support at bissinc.com<mailto:support at bissinc.com>

Follow us on Twitter for Network Status &  Updates!

<image002.gif><https://twitter.com/johnbarfield>

From: Dan McDonald <danmcd at omniti.com<mailto:danmcd at omniti.com>>
Date: Tuesday, March 7, 2017 at 2:21 PM
To: John Barfield <john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>>
Cc: "omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>" <omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>>, Dan McDonald <danmcd at omniti.com<mailto:danmcd at omniti.com>>
Subject: Re: [OmniOS-discuss] r151020 installer issues

Btw, the installer for the next release of OmniOS is brand new, based on our PXE installer Kayak. Between Loader replacing GRUB, Python2.7, and reports like yours, it's time to put Caiman out to pasture.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/11396ac6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3508 bytes
Desc: image001.png
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/11396ac6/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1351 bytes
Desc: image002.gif
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/11396ac6/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: volatile.zip
Type: application/zip
Size: 2672 bytes
Desc: volatile.zip
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/11396ac6/attachment-0001.zip>

From danmcd at omniti.com  Tue Mar  7 22:17:01 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 7 Mar 2017 17:17:01 -0500
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <F870FA88-FFC9-4AB4-B50A-133543C629C5@bissinc.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
	<7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>
	<D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>
	<F870FA88-FFC9-4AB4-B50A-133543C629C5@bissinc.com>
Message-ID: <6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com>


> On Mar 7, 2017, at 4:46 PM, John Barfield <john.barfield at bissinc.com> wrote:
> 
> <volatile.zip>

open() returned EIO:

  File "/usr/lib/python2.6/vendor-packages/pkg/manifest.py", line 1713, in gen_actions_by_type
    raise apx._convert_error(e)
IOError: [Errno 5] I/O error
2017-03-07 15:38:08,494   InstallationLogger ERROR      Checkpoint cleanup-cpio-install failed            
2017-03-07 15:38:08,494   InstallationLogger ERROR      [Errno 5] I/O error                               


That doesn't look promising... and makes me wonder about hardware as well.  Also, are there any existing rpool or rpool-like pools available?  Maybe the beadm libraries got confused?

Dan


From john.barfield at bissinc.com  Tue Mar  7 22:22:26 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Tue, 7 Mar 2017 22:22:26 +0000
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
	<7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>
	<D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>
	<F870FA88-FFC9-4AB4-B50A-133543C629C5@bissinc.com>
	<6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com>
Message-ID: <C5A40D85-7462-4C51-9276-4C8D6BA821AA@bissinc.com>

I caught that and pulled the SAS HBA. I?ve got another Oracle RAID controller card in now and the installer just finished. 

The old card was: LSI SAS3081E-S

New Card is: LSI BAT1S1P

Thanks for the help. I just did an old fashioned hardware RAID1 in the LSI GUI. 

John Barfield
Engineering and Stuff 
 
M: +1 (214) 425-0783  O: +1 (214) 506-8354 
john.barfield at bissinc.com
 

4925 Greenville Ave, Ste 900
Dallas, TX 75206
 
For Support Requests:
http://support.bissinc.com <http://support.bissinc.com/> or support at bissinc.com
 
Follow us on Twitter for Network Status &  Updates! 
 
 <https://twitter.com/johnbarfield>  

On 3/7/17, 4:17 PM, "Dan McDonald" <danmcd at omniti.com> wrote:

    
    > On Mar 7, 2017, at 4:46 PM, John Barfield <john.barfield at bissinc.com> wrote:
    > 
    > <volatile.zip>
    
    open() returned EIO:
    
      File "/usr/lib/python2.6/vendor-packages/pkg/manifest.py", line 1713, in gen_actions_by_type
        raise apx._convert_error(e)
    IOError: [Errno 5] I/O error
    2017-03-07 15:38:08,494   InstallationLogger ERROR      Checkpoint cleanup-cpio-install failed            
    2017-03-07 15:38:08,494   InstallationLogger ERROR      [Errno 5] I/O error                               
    
    
    That doesn't look promising... and makes me wonder about hardware as well.  Also, are there any existing rpool or rpool-like pools available?  Maybe the beadm libraries got confused?
    
    Dan
    
    


From daleg at omniti.com  Tue Mar  7 22:42:02 2017
From: daleg at omniti.com (Dale Ghent)
Date: Tue, 7 Mar 2017 17:42:02 -0500
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <C5A40D85-7462-4C51-9276-4C8D6BA821AA@bissinc.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
	<7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>
	<D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>
	<F870FA88-FFC9-4AB4-B50A-133543C629C5@bissinc.com>
	<6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com>
	<C5A40D85-7462-4C51-9276-4C8D6BA821AA@bissinc.com>
Message-ID: <C1EE9B55-BBAA-42C3-B28C-F614FDE83E5D@omniti.com>


> On Mar 7, 2017, at 5:22 PM, John Barfield <john.barfield at bissinc.com> wrote:
> 
> I caught that and pulled the SAS HBA. I?ve got another Oracle RAID controller card in now and the installer just finished.
> 
> The old card was: LSI SAS3081E-S
> 
> New Card is: LSI BAT1S1P
> 
> Thanks for the help. I just did an old fashioned hardware RAID1 in the LSI GUI.

Why? You can just attach the second drive to form one under ZFS.

/dale

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/c522669a/attachment.bin>

From danmcd at omniti.com  Tue Mar  7 22:50:43 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 7 Mar 2017 17:50:43 -0500
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <C1EE9B55-BBAA-42C3-B28C-F614FDE83E5D@omniti.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
	<7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>
	<D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>
	<F870FA88-FFC9-4AB4-B50A-133543C629C5@bissinc.com>
	<6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com>
	<C5A40D85-7462-4C51-9276-4C8D6BA821AA@bissinc.com>
	<C1EE9B55-BBAA-42C3-B28C-F614FDE83E5D@omniti.com>
Message-ID: <D71CD59F-90BE-43F8-94F8-52FC7D56E62E@omniti.com>


>> The old card was: LSI SAS3081E-S

Eeesh, that's the old 1068 chipset.

>> New Card is: LSI BAT1S1P

That's a battery backup part number.  Odd.

Dan


From john.barfield at bissinc.com  Tue Mar  7 22:59:01 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Tue, 7 Mar 2017 22:59:01 +0000
Subject: [OmniOS-discuss] r151020 installer issues
In-Reply-To: <D71CD59F-90BE-43F8-94F8-52FC7D56E62E@omniti.com>
References: <A00E9718-91ED-4569-9682-CD112E88E881@bissinc.com>
	<4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com>
	<7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com>
	<D87E1499-AE98-4350-9459-A5B767EB6DED@omniti.com>
	<F870FA88-FFC9-4AB4-B50A-133543C629C5@bissinc.com>
	<6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com>
	<C5A40D85-7462-4C51-9276-4C8D6BA821AA@bissinc.com>
	<C1EE9B55-BBAA-42C3-B28C-F614FDE83E5D@omniti.com>
	<D71CD59F-90BE-43F8-94F8-52FC7D56E62E@omniti.com>
Message-ID: <9B03A12C-B087-417E-A385-DEF40DF5B45B@bissinc.com>

Yeah, I have two servers that came with those. 

I can?t figure out how to put them in jbod mode is the only problem. 

John Barfield
Engineering and Stuff 
 
M: +1 (214) 425-0783  O: +1 (214) 506-8354 
john.barfield at bissinc.com
 

4925 Greenville Ave, Ste 900
Dallas, TX 75206
 
For Support Requests:
http://support.bissinc.com <http://support.bissinc.com/> or support at bissinc.com
 
Follow us on Twitter for Network Status &  Updates! 
 
 <https://twitter.com/johnbarfield>  

On 3/7/17, 4:50 PM, "Dan McDonald" <danmcd at omniti.com> wrote:

    
    >> The old card was: LSI SAS3081E-S
    
    Eeesh, that's the old 1068 chipset.
    
    >> New Card is: LSI BAT1S1P
    
    That's a battery backup part number.  Odd.
    
    Dan
    
    


From prakash.surya at delphix.com  Wed Mar  8 00:55:19 2017
From: prakash.surya at delphix.com (Prakash Surya)
Date: Tue, 7 Mar 2017 16:55:19 -0800
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen HVM
	and an "xdf" Device
Message-ID: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>

Hey All,

I just wanted to post and say that I've tested the new r151021 ISO
installer using a Xen VM and was able to successfully perform the
installation. Here's a copy of the Xen VM configuration that I used:

# cat ami-template.cfg
builder='hvm'
name='ami-template'
vcpus=4
memory=4096
vif=['bridge=xenbr0, type=ioemu']
#disk=[  'file:/root/psurya/omni-kayak/r151021-kayak.iso,hdb:cdrom,r',
#        'file:/root/psurya/omni-kayak/ami-template.img,xvda,w' ]
disk=[  'file:/root/psurya/omni-kayak/ami-template.img,xvda,w' ]
#boot='d'
boot='c'
vnc=1
vnclisten='0.0.0.0'
vncconsole=1
on_crash='preserve'
xen_platform_pci=1
serial='pty'
on_reboot='destroy'

The only "catch", is I have to set "apix_enable" to 0. I do that using KMDB
during the installer (e.g. edit the loader so I drop to KMDB first), and
then edit "/etc/system" after the install is completed but prior to the
first boot (so I don't have to keep using KMDB for every boot).

If I don't set that tuning, the system will "hang" during boot up (this is
a problem with illumos and Xen HVM, and not specific to OmniOS or the new
ISO).

Additionally, I've attached a PNG image with some "zpool" and "format"
output from within the Xen VM running after the ISO install (hopefully the
mailing list doesn't strip the image from this post).

Cheers,
Prakash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/35bf509f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omnios-kayak-disks.png
Type: image/png
Size: 11962 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170307/35bf509f/attachment-0001.png>

From geoffn at gnaa.net  Wed Mar  8 01:16:12 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Tue, 7 Mar 2017 17:16:12 -0800
Subject: [OmniOS-discuss] new supermicro server
Message-ID: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>

Hi.

I am looking at ordering a new 3U supermicro server. as an all-in one.   
I have been using these recently:

https://www.supermicro.com/products/system/3U/6038/SSG-6038R-E1CR16L.cfm

It has the LSI 3008 HBA in IT mode.

Any other suggestions out there?

thanks,

Geoff





From danmcd at omniti.com  Wed Mar  8 01:21:20 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 7 Mar 2017 20:21:20 -0500
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
Message-ID: <52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>


> On Mar 7, 2017, at 8:16 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
> 
> Hi.
> 
> I am looking at ordering a new 3U supermicro server. as an all-in one.   I have been using these recently:
> 
> https://www.supermicro.com/products/system/3U/6038/SSG-6038R-E1CR16L.cfm
> 
> It has the LSI 3008 HBA in IT mode.
> 
> Any other suggestions out there?

The one you mention is pretty good, especially if you want 2 + 16 drives (2x2.5", 16x3.5") online.

Unless you want something smaller, I can think of much worse ways to spend your money.

Dan


From tim at multitalents.net  Wed Mar  8 01:41:05 2017
From: tim at multitalents.net (Tim Rice)
Date: Tue, 7 Mar 2017 17:41:05 -0800 (PST)
Subject: [OmniOS-discuss] Fwd: [developer] Review request: 7948 Remove
 old calendar utility
In-Reply-To: <237225B6-6EC9-4A0A-89EA-25E021F994C9@omniti.com>
References: <CAEgYsbEncEotZZrrfwiASc88bb_w43tgdp=6Un2UHPjszJNcAw@mail.gmail.com>
	<237225B6-6EC9-4A0A-89EA-25E021F994C9@omniti.com>
Message-ID: <alpine.UW2.2.11.1703071732410.19286@server01.int.multitalents.net>


Hi Dan,

On Tue, 7 Mar 2017, Dan McDonald wrote:

> Not to be confused with cal(1), but does anyone here use calendar(1)?

I use it here in my mail zone.

> Trying to gauge how hard I should try to replace it or not.

It would not be anywhere near as anoying to lose it as it was to
discover bind was missing. ;-)

> Thanks,
> Dan
> 
> Sent from my iPhone (typos, autocorrect, and all)
> 
> Begin forwarded message:
> 
[snip]

-- 
Tim Rice				Multitalents
tim at multitalents.net



From stephan.budach at jvm.de  Wed Mar  8 05:35:53 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Wed, 8 Mar 2017 06:35:53 +0100 (CET)
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
Message-ID: <540718223.55.1488951317198.JavaMail.stephan.budach@budy.stephanbudach.de>



----- Urspr?ngliche Mail -----
> Von: "Dan McDonald" <danmcd at omniti.com>
> An: "Geoff Nordli" <geoffn at gnaa.net>
> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Mittwoch, 8. M?rz 2017 02:21:20
> Betreff: Re: [OmniOS-discuss] new supermicro server
> 
> 
> > On Mar 7, 2017, at 8:16 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
> > 
> > Hi.
> > 
> > I am looking at ordering a new 3U supermicro server. as an all-in
> > one.   I have been using these recently:
> > 
> > https://www.supermicro.com/products/system/3U/6038/SSG-6038R-E1CR16L.cfm
> > 
> > It has the LSI 3008 HBA in IT mode.
> > 
> > Any other suggestions out there?
> 
> The one you mention is pretty good, especially if you want 2 + 16
> drives (2x2.5", 16x3.5") online.
> 
> Unless you want something smaller, I can think of much worse ways to
> spend your money.
> 
> Dan
> 

Yeah - I do have a couple of those, even with the current X10 board and I am really satisfied with those. Just throwed in another Intel 10GbE DP and hooked them up to our Nexus network. Really solid boxes!

Cheers,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/ecfbbcef/attachment.bin>

From geoffn at gnaa.net  Wed Mar  8 06:13:58 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Tue, 7 Mar 2017 22:13:58 -0800
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <540718223.55.1488951317198.JavaMail.stephan.budach@budy.stephanbudach.de>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
	<540718223.55.1488951317198.JavaMail.stephan.budach@budy.stephanbudach.de>
Message-ID: <5e6f5ed4-f0cf-f39d-e3a5-a3d82f5ec8b1@gnaa.net>


On 2017-03-07 09:35 PM, Stephan Budach wrote:
>
> ----- Urspr?ngliche Mail -----
>> Von: "Dan McDonald" <danmcd at omniti.com>
>> An: "Geoff Nordli" <geoffn at gnaa.net>
>> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
>> Gesendet: Mittwoch, 8. M?rz 2017 02:21:20
>> Betreff: Re: [OmniOS-discuss] new supermicro server
>>
>>
>>> On Mar 7, 2017, at 8:16 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
>>>
>>> Hi.
>>>
>>> I am looking at ordering a new 3U supermicro server. as an all-in
>>> one.   I have been using these recently:
>>>
>>> https://www.supermicro.com/products/system/3U/6038/SSG-6038R-E1CR16L.cfm
>>>
>>> It has the LSI 3008 HBA in IT mode.
>>>
>>> Any other suggestions out there?
>> The one you mention is pretty good, especially if you want 2 + 16
>> drives (2x2.5", 16x3.5") online.
>>
>> Unless you want something smaller, I can think of much worse ways to
>> spend your money.
>>
>> Dan
>>
> Yeah - I do have a couple of those, even with the current X10 board and I am really satisfied with those. Just throwed in another Intel 10GbE DP and hooked them up to our Nexus network. Really solid boxes!
>
> Cheers,
> Stephan

Thanks Stephan and Dan.

One thing I am not sure about is NVMe drives.

Are those stable?

Geoff



From danmcd at omniti.com  Wed Mar  8 06:44:30 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 8 Mar 2017 01:44:30 -0500
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <5e6f5ed4-f0cf-f39d-e3a5-a3d82f5ec8b1@gnaa.net>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
	<540718223.55.1488951317198.JavaMail.stephan.budach@budy.stephanbudach.de>
	<5e6f5ed4-f0cf-f39d-e3a5-a3d82f5ec8b1@gnaa.net>
Message-ID: <E2670F8D-D6CF-453E-A0AB-C94B4FAF33C0@omniti.com>

You didn't mention anything in the original note about NVMe, and neither did the spec sheet.

NVMe 1.0 and 1.1 should work on 020 and later OmniOS. Hang out on the illumos developers list to see the latest on that front.

Dan

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


From stephan.budach at jvm.de  Wed Mar  8 07:25:30 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Wed, 8 Mar 2017 08:25:30 +0100 (CET)
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <E2670F8D-D6CF-453E-A0AB-C94B4FAF33C0@omniti.com>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
	<540718223.55.1488951317198.JavaMail.stephan.budach@budy.stephanbudach.de>
	<5e6f5ed4-f0cf-f39d-e3a5-a3d82f5ec8b1@gnaa.net>
	<E2670F8D-D6CF-453E-A0AB-C94B4FAF33C0@omniti.com>
Message-ID: <1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de>



----- Urspr?ngliche Mail -----
> Von: "Dan McDonald" <danmcd at omniti.com>
> An: "Geoff Nordli" <geoffn at gnaa.net>
> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Mittwoch, 8. M?rz 2017 07:44:30
> Betreff: Re: [OmniOS-discuss] new supermicro server
> 
> You didn't mention anything in the original note about NVMe, and
> neither did the spec sheet.
> 
> NVMe 1.0 and 1.1 should work on 020 and later OmniOS. Hang out on the
> illumos developers list to see the latest on that front.
> 
> Dan
> 
> Sent from my iPhone (typos, autocorrect, and all)
> 

In regards of NVMe, I am eyeing this particular Supermicro and I intend to get my hands on two of those in Q2:

SuperMicro SuperServer SSG-2028R-NR48N

I think these will bring a lot of fun to the table. ;)

Cheers,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/7b3bf329/attachment.bin>

From stephan.budach at jvm.de  Wed Mar  8 07:28:37 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Wed, 8 Mar 2017 08:28:37 +0100 (CET)
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
 HVM	and an "xdf" Device
In-Reply-To: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
Message-ID: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>

Hi Prakash, 

----- Urspr?ngliche Mail -----

> Von: "Prakash Surya" <prakash.surya at delphix.com>
> An: omnios-discuss at lists.omniti.com
> Gesendet: Mittwoch, 8. M?rz 2017 01:55:19
> Betreff: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
> HVM and an "xdf" Device

> Hey All,

> I just wanted to post and say that I've tested the new r151021 ISO
> installer using a Xen VM and was able to successfully perform the
> installation. Here's a copy of the Xen VM configuration that I used:

> # cat ami-template.cfg
> builder='hvm'
> name='ami-template'
> vcpus=4
> memory=4096
> vif=['bridge=xenbr0, type=ioemu']
> #disk=[ 'file:/root/psurya/omni-kayak/r151021-kayak.iso,hdb:cdrom,r',
> # 'file:/root/psurya/omni-kayak/ami-template.img,xvda,w' ]
> disk=[ 'file:/root/psurya/omni-kayak/ami-template.img,xvda,w' ]
> #boot='d'
> boot='c'
> vnc=1
> vnclisten='0.0.0.0'
> vncconsole=1
> on_crash='preserve'
> xen_platform_pci=1
> serial='pty'
> on_reboot='destroy'

> The only "catch", is I have to set "apix_enable" to 0. I do that
> using KMDB during the installer (e.g. edit the loader so I drop to
> KMDB first), and then edit "/etc/system" after the install is
> completed but prior to the first boot (so I don't have to keep using
> KMDB for every boot).

> If I don't set that tuning, the system will "hang" during boot up
> (this is a problem with illumos and Xen HVM, and not specific to
> OmniOS or the new ISO).

> Additionally, I've attached a PNG image with some "zpool" and
> "format" output from within the Xen VM running after the ISO install
> (hopefully the mailing list doesn't strip the image from this post).

> Cheers,
> Prakash

Can you elaborate on that a little more as of what exactly you did to the loader? I am guessing that you modified the kernel boot arguments, but unfortuanetly, I am unfamiliar with the new loader. 

Cheers, 
Stephan 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/71cb8d74/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/71cb8d74/attachment-0001.bin>

From ergi.thanasko at avsquad.com  Wed Mar  8 07:32:11 2017
From: ergi.thanasko at avsquad.com (Ergi Thanasko)
Date: Wed, 8 Mar 2017 07:32:11 +0000
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
	<540718223.55.1488951317198.JavaMail.stephan.budach@budy.stephanbudach.de>
	<5e6f5ed4-f0cf-f39d-e3a5-a3d82f5ec8b1@gnaa.net>
	<E2670F8D-D6CF-453E-A0AB-C94B4FAF33C0@omniti.com>,
	<1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de>
Message-ID: <A0854771-9A75-4874-8379-2630DD88EE6E@avsquad.com>

No LSI controller on those, they connect directly to the CPU with razor cards.  In theory they can utilize the entire bus speed but in the backplane you get around 2GB/sec throughout on each nvme drive.

Sent from my iPhone

> On Mar 7, 2017, at 11:25 PM, Stephan Budach <stephan.budach at jvm.de> wrote:
> 
> 
> 
> ----- Urspr?ngliche Mail -----
>> Von: "Dan McDonald" <danmcd at omniti.com>
>> An: "Geoff Nordli" <geoffn at gnaa.net>
>> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
>> Gesendet: Mittwoch, 8. M?rz 2017 07:44:30
>> Betreff: Re: [OmniOS-discuss] new supermicro server
>> 
>> You didn't mention anything in the original note about NVMe, and
>> neither did the spec sheet.
>> 
>> NVMe 1.0 and 1.1 should work on 020 and later OmniOS. Hang out on the
>> illumos developers list to see the latest on that front.
>> 
>> Dan
>> 
>> Sent from my iPhone (typos, autocorrect, and all)
>> 
> 
> In regards of NVMe, I am eyeing this particular Supermicro and I intend to get my hands on two of those in Q2:
> 
> SuperMicro SuperServer SSG-2028R-NR48N
> 
> I think these will bring a lot of fun to the table. ;)
> 
> Cheers,
> Stephan
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From omnios at citrus-it.net  Wed Mar  8 10:43:17 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Wed, 8 Mar 2017 10:43:17 +0000 (UTC)
Subject: [OmniOS-discuss] Improved, but still alpha, ISO installer
In-Reply-To: <22F78EFB-683C-4E74-BF60-8A4015242837@omniti.com>
References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
	<alpine.GSO.2.20.1703071624470.203757@erncre.pvgehf-vg.arg>
	<22F78EFB-683C-4E74-BF60-8A4015242837@omniti.com>
Message-ID: <alpine.GSO.2.20.1703081042530.458177@erncre.pvgehf-vg.arg>


On Tue, 7 Mar 2017, Dan McDonald wrote:

;
; > On Mar 7, 2017, at 11:28 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:
; >
; > I'm a bit late to the party but I've downloaded this and burned it to a
; > CD (old school, I know) and tried booting a Dell R620. It hangs just after
; > printing:
; >
; > 	loading ficl string class
; > 	/
; >
; > With just that / on the last line.
; >
; > Tried a few times but it always hangs at the same place.
; >
; > Anything useful I can try?
;
; Hmmm... I wonder if the .iso image is a bit too large for an actual physical CD?
;
; Can you burn it onto a dvd?

Morning,

Same result with a DVD unfortunately.

Andy

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


From peter.tribble at gmail.com  Wed Mar  8 11:05:18 2017
From: peter.tribble at gmail.com (Peter Tribble)
Date: Wed, 8 Mar 2017 11:05:18 +0000
Subject: [OmniOS-discuss] Fwd: [developer] Review request: 7948 Remove
 old calendar utility
In-Reply-To: <alpine.UW2.2.11.1703071732410.19286@server01.int.multitalents.net>
References: <CAEgYsbEncEotZZrrfwiASc88bb_w43tgdp=6Un2UHPjszJNcAw@mail.gmail.com>
	<237225B6-6EC9-4A0A-89EA-25E021F994C9@omniti.com>
	<alpine.UW2.2.11.1703071732410.19286@server01.int.multitalents.net>
Message-ID: <CAEgYsbHiYSxPKNRONuiB=NbfCaGN7mdjw4HTU5Nx=O-mhYZbUg@mail.gmail.com>

On Wed, Mar 8, 2017 at 1:41 AM, Tim Rice <tim at multitalents.net> wrote:

>
> Hi Dan,
>
> On Tue, 7 Mar 2017, Dan McDonald wrote:
>
> > Not to be confused with cal(1), but does anyone here use calendar(1)?
>
> I use it here in my mail zone.
>

Ouch.


> > Trying to gauge how hard I should try to replace it or not.
>
> It would not be anywhere near as anoying to lose it as it was to
> discover bind was missing. ;-)
>

I'm trying to understand the impact here - if it's bad then I'll look
again.

If you know the format of your calendar file, then something like

grep "^`date '+%D'`" ~/calendar

or

grep "^`date '+%b %e'`" ~/calendar

ought to do more or less the same thing.

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

From bfriesen at simple.dallas.tx.us  Wed Mar  8 14:36:21 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Wed, 8 Mar 2017 08:36:21 -0600 (CST)
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
Message-ID: <alpine.GSO.2.20.1703080830070.13280@freddy.simplesystems.org>

On Tue, 7 Mar 2017, Geoff Nordli wrote:

> Hi.
>
> I am looking at ordering a new 3U supermicro server. as an all-in one.   I 
> have been using these recently:
>
> https://www.supermicro.com/products/system/3U/6038/SSG-6038R-E1CR16L.cfm
>
> It has the LSI 3008 HBA in IT mode.

I have one of these.  It runs OmniOS very well.  Mine has four Intel 
SATA SSDs, two for boot, and two for SLOG.  Two of the SSDs are fixed 
internal and two are accessible via optional rear slots.

However, I am encountering BIOS issues with booting.  The drives 
advertized by the HBA overwelm the BIOS so that it does not list 
internal SATA drives for booting and currently my system only boots 
from internal SATA drives if the Intel network boot agent runs.  The 
BIOS behavior is unstable.

This problem did not appear to exist when the system was delivered to 
me but appeared as soon as I tried to statically configure the BMC IP 
address.

Perhaps there is a way to tell the HBA BIOS to not advertize the SAS 
drives which are not needed for booting?

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

From nshalman at omniti.com  Wed Mar  8 15:06:58 2017
From: nshalman at omniti.com (Nahum Shalman)
Date: Wed, 8 Mar 2017 10:06:58 -0500
Subject: [OmniOS-discuss] qemu: too many IDE bus
In-Reply-To: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>
References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>
Message-ID: <CAOc1FHhzHQJ7SL8683zq3WdDBxEWPsNkih=v9P_A4odt8gwROg@mail.gmail.com>

I would think that depending on how you're invoking QEMU (it looked like
the full qemu command line was truncated from the output you pasted) it'
allocating one of the 4 available IDE slots to a virtual CDROM. Depending
on your guest OS you could consider using a different virtual controller
for the virtual disks, or you might be able to tell qemu not to allocate a
virtual cdrom drive.

If you want to share the full qemu command line being invoked I'm happy to
take a quick look at it to see if I can figure out a simple way to improve
it.

(I suspect that "cd /KVM_Machines/JDN && bash -x ./JDN01_Start-VM.sh" will
provide the information needed)

-Nahum

On Fri, Mar 3, 2017 at 10:12 AM, Dirk Willems <dirk.willems at exitas.be>
wrote:

> Hello,
>
> I experience some issue's with too many IDE bus on KVM ?
>
> I'm only allowed to having 3 HDD, when I add the fourth HDD I get the
> following error
>
> qemu: too many IDE bus
>
> root at OmniosExitas:/KVM_Machines/JDN# ./JDN01_Start-VM.sh
> qemu-system-x86_64: -net vnic,vlan=0,name=net0,ifname=
> VLJDN01,macaddr=2:8:20:2:4b:a4,: vnic dhcp disabled
>
> qemu-system-x86_64: -net vnic,vlan=1,name=net1,ifname=
> VSJDN01,macaddr=2:8:20:67:1:7c,: vnic dhcp disabled
>
> qemu: too many IDE bus
> Failed to start VM
> Started VM:
> Public: 127.0.0.1
> 10.100.23.86
> ::1/128
> ::/0:5903
>
>
> I just upgrade to
>
> root at OmniosExitas:/KVM_Machines/JDN# uname -a
> SunOS OmniosExitas 5.11 omnios-r151020-4151d05 i86pc i386 i86pc
>
> Any suggestions ?
>
>
> Thanks in advance.
>
>
> Kind Regards.
>
>
> Dirk
>
>
>
> --
> Dirk Willems
> System Engineer
>
>
> +32 (0)3 443 12 38 <+32%203%20443%2012%2038>
> Dirk.Willems at exitas.be
>
> Quality. Passion. Personality
>
> www.exitas.be | Veldkant 31 | 2550 Kontich
>
> Illumos OmniOS Installation and Configuration Implementation Specialist.
> Oracle Solaris 11 Installation and Configuration Certified Implementation
> Specialist.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/d87edca7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmallPhoenixLogotypeRGB.png
Type: image/png
Size: 4648 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/d87edca7/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: placeholder-exitas.jpg
Type: image/jpeg
Size: 12658 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/d87edca7/attachment-0001.jpg>

From danmcd at omniti.com  Wed Mar  8 15:08:33 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 8 Mar 2017 10:08:33 -0500
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
 HVM and an "xdf" Device
In-Reply-To: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
	<939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>
Message-ID: <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>


> On Mar 8, 2017, at 2:28 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
> 
> Can you elaborate on that a little more as of what exactly you did to the loader? I am guessing that you modified the kernel boot arguments, but unfortuanetly, I am unfamiliar with the new loader.

Screenshots being inlined...

Step 1:  Say hello to the new Loader menu:



note that on the new ISO, there will be no "Select Boot Environment" option.  Nonetheless, we don't want that.  We want to modify the boot options (#5 or the 'O' key):

Step 2:  Say hello to the Boot Options menu:



To boot under kmdb  (the kernel debugger) AND have the kmdb prompt occur immediately you now simply enable kmdb with 'm' or with '7', and debug with 'd' or '8'.  After pressing both keys, things should look like this:



Step 3:  Press RETURN to boot, and get to the kmdb prompt and fix apix_enable.

You will get to the kmdb prompt now.  I've typed in three commands:  "apix_enable/X" to show its current value, "apix_enable/W0" to set it to 0, and "apix_enable/X" again to show it is indeed 0.  Pardon the noise on one part... using arrows for history on kmdb prints extra characters:



Step 4:  Proceed with boot.

Enter ":c" into kmdb and the kernel will boot.



If you do that trick on the installer ISO, you'll jump immediately to the installation menu.

Once booted, if it's an installed system, you can login and edit /etc/system to add: "set apix_enable=0" on a line by itself.  If it's the installer ISO, do the installation, THEN enter the shell and edit /mnt/etc/system.  The new installer keeps the newly-installed BE mounted on /mnt so people can post-process it after installation.  We MAY exploit this to enhance the installation menu and installation experience.

Hope this helps!
Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/98ff1d87/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 9.58.00 AM.png
Type: image/png
Size: 67519 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/98ff1d87/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 9.59.47 AM.png
Type: image/png
Size: 101565 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/98ff1d87/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 10.02.32 AM.png
Type: image/png
Size: 65033 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/98ff1d87/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 10.05.01 AM.png
Type: image/png
Size: 49320 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/98ff1d87/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 10.06.03 AM.png
Type: image/png
Size: 74822 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/98ff1d87/attachment-0009.png>

From danmcd at omniti.com  Wed Mar  8 15:10:56 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 8 Mar 2017 10:10:56 -0500
Subject: [OmniOS-discuss] Improved, but still alpha, ISO installer
In-Reply-To: <alpine.GSO.2.20.1703081042530.458177@erncre.pvgehf-vg.arg>
References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com>
	<alpine.GSO.2.20.1703071624470.203757@erncre.pvgehf-vg.arg>
	<22F78EFB-683C-4E74-BF60-8A4015242837@omniti.com>
	<alpine.GSO.2.20.1703081042530.458177@erncre.pvgehf-vg.arg>
Message-ID: <22C49704-5CC9-43DE-84BE-55D7AC939D3C@omniti.com>


> On Mar 8, 2017, at 5:43 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> 
> ; Hmmm... I wonder if the .iso image is a bit too large for an actual physical CD?
> ;
> ; Can you burn it onto a dvd?
> 
> Morning,
> 
> Same result with a DVD unfortunately.

Hmmm... so clearly something on your environment doesn't get along with the ISO.

I'd debug this further, but first, I'm issuing a bloody update to the IPS repo server, and then I'm going to spin a new ISO (which also has a disk-selection scheme working now in my own tests).

Stay tuned!
Dan


From lkateley at kateley.com  Wed Mar  8 15:18:50 2017
From: lkateley at kateley.com (Linda Kateley)
Date: Wed, 8 Mar 2017 09:18:50 -0600
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
Message-ID: <13788629-7563-eb76-f8a1-fd4e7ff68ba5@kateley.com>

I have been using the 6037R-E1R16L for several of my builds for archive, 
but the 6038 is also a nice frame. It always depends on what you are 
doing with it.

lk


On 3/7/17 7:21 PM, Dan McDonald wrote:
>> On Mar 7, 2017, at 8:16 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
>>
>> Hi.
>>
>> I am looking at ordering a new 3U supermicro server. as an all-in one.   I have been using these recently:
>>
>> https://www.supermicro.com/products/system/3U/6038/SSG-6038R-E1CR16L.cfm
>>
>> It has the LSI 3008 HBA in IT mode.
>>
>> Any other suggestions out there?
> The one you mention is pretty good, especially if you want 2 + 16 drives (2x2.5", 16x3.5") online.
>
> Unless you want something smaller, I can think of much worse ways to spend your money.
>
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From lkateley at kateley.com  Wed Mar  8 15:23:55 2017
From: lkateley at kateley.com (Linda Kateley)
Date: Wed, 8 Mar 2017 09:23:55 -0600
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
	<540718223.55.1488951317198.JavaMail.stephan.budach@budy.stephanbudach.de>
	<5e6f5ed4-f0cf-f39d-e3a5-a3d82f5ec8b1@gnaa.net>
	<E2670F8D-D6CF-453E-A0AB-C94B4FAF33C0@omniti.com>
	<1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de>
Message-ID: <f4cb37c5-a247-6a46-f1e2-354fd7cf9c47@kateley.com>


SuperMicro SuperServer SSG-2028R-NR48N

I have been looking at those too.. Maybe someone can help me understand 
how you can have nvme on a sata bus? I thought the benefit or primary 
function of nvme was that it was low latency and sits on the pci bus? It 
looks like these are nvme modules with sata/sas attachments



On 3/8/17 1:25 AM, Stephan Budach wrote:
>
> ----- Urspr?ngliche Mail -----
>> Von: "Dan McDonald" <danmcd at omniti.com>
>> An: "Geoff Nordli" <geoffn at gnaa.net>
>> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
>> Gesendet: Mittwoch, 8. M?rz 2017 07:44:30
>> Betreff: Re: [OmniOS-discuss] new supermicro server
>>
>> You didn't mention anything in the original note about NVMe, and
>> neither did the spec sheet.
>>
>> NVMe 1.0 and 1.1 should work on 020 and later OmniOS. Hang out on the
>> illumos developers list to see the latest on that front.
>>
>> Dan
>>
>> Sent from my iPhone (typos, autocorrect, and all)
>>
> In regards of NVMe, I am eyeing this particular Supermicro and I intend to get my hands on two of those in Q2:
>
> SuperMicro SuperServer SSG-2028R-NR48N
>
> I think these will bring a lot of fun to the table. ;)
>
> Cheers,
> Stephan
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

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

From eric.sproul at circonus.com  Wed Mar  8 15:36:56 2017
From: eric.sproul at circonus.com (Eric Sproul)
Date: Wed, 8 Mar 2017 10:36:56 -0500
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
 HVM and an "xdf" Device
In-Reply-To: <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
	<939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
Message-ID: <CAO8hXRAOCfCNv4gQUW2-DyCJ2fAd2YkwdWdVcz4b6Zhcguq8rQ@mail.gmail.com>

On Wed, Mar 8, 2017 at 10:08 AM, Dan McDonald <danmcd at omniti.com> wrote:

>
> On Mar 8, 2017, at 2:28 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
>
> Can you elaborate on that a little more as of what exactly you did to the
> loader? I am guessing that you modified the kernel boot arguments,
> but unfortuanetly, I am unfamiliar with the new loader.
>
>
> Screenshots being inlined...
>
> Step 1:  Say hello to the new Loader menu:
>

Wow, this is awesome, Dan. Thanks for bringing this to OmniOS!

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

From Kevin.Swab at colostate.edu  Wed Mar  8 16:20:41 2017
From: Kevin.Swab at colostate.edu (Kevin.Swab at colostate.edu)
Date: Wed, 8 Mar 2017 09:20:41 -0700
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <alpine.GSO.2.20.1703080830070.13280@freddy.simplesystems.org>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<alpine.GSO.2.20.1703080830070.13280@freddy.simplesystems.org>
Message-ID: <1731769e-a1cc-d07c-46c4-4750a55b4109@yuma.acns.colostate.edu>

We haven't used this particular system, but we had the same problem with
SuperMicro Gen 9 motherboards.  The solution for us on those systems was
to disable BIOS loading for the particular PCI slot the SAS HBA was
installed in.  This was a system BIOS setting, rather than an HBA BIOS
setting.

It looks like this MB may have an onboard SAS controller.  If you're
using that, there may be a similar option somewhere in the system BIOS.

We opened a support case on this issue with SuperMicro via our vendor,
they concluded that there was an address space limitation with the BIOS
boot process, and suggested that an HBA capable of UEFI boot might
resolve the problem.  Unfortunately, our LSI2308 HBAs were not UEFI
capable, so we were unable to test that theory.  If you're currently
using BIOS boot mode, it might be worthwhile to try switching to UEFI
boot mode to see if that helps.

Kevin


On 03/08/2017 07:36 AM, Bob Friesenhahn wrote:
> On Tue, 7 Mar 2017, Geoff Nordli wrote:
> 
>> Hi.
>>
>> I am looking at ordering a new 3U supermicro server. as an all-in
>> one.   I have been using these recently:
>>
>> https://www.supermicro.com/products/system/3U/6038/SSG-6038R-E1CR16L.cfm
>>
>> It has the LSI 3008 HBA in IT mode.
> 
> I have one of these.  It runs OmniOS very well.  Mine has four Intel
> SATA SSDs, two for boot, and two for SLOG.  Two of the SSDs are fixed
> internal and two are accessible via optional rear slots.
> 
> However, I am encountering BIOS issues with booting.  The drives
> advertized by the HBA overwelm the BIOS so that it does not list
> internal SATA drives for booting and currently my system only boots from
> internal SATA drives if the Intel network boot agent runs.  The BIOS
> behavior is unstable.
> 
> This problem did not appear to exist when the system was delivered to me
> but appeared as soon as I tried to statically configure the BMC IP address.
> 
> Perhaps there is a way to tell the HBA BIOS to not advertize the SAS
> drives which are not needed for booting?
> 
> Bob

-- 
-------------------------------------------------------------------
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 chip at innovates.com  Wed Mar  8 16:30:02 2017
From: chip at innovates.com (Schweiss, Chip)
Date: Wed, 8 Mar 2017 10:30:02 -0600
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <alpine.GSO.2.20.1703080830070.13280@freddy.simplesystems.org>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<alpine.GSO.2.20.1703080830070.13280@freddy.simplesystems.org>
Message-ID: <CALeZrrQTyob=Yd4xaQapL3-cXJVNF00qGP04OoXjvernmdCJkg@mail.gmail.com>

On Wed, Mar 8, 2017 at 8:36 AM, Bob Friesenhahn <
bfriesen at simple.dallas.tx.us> wrote:

>
>
> Perhaps there is a way to tell the HBA BIOS to not advertize the SAS
> drives which are not needed for booting?


In the HBA BIOS configuration, set the HBA to disabled.  OmniOS will still
see the HBA and disks, but the BIOS will not want to list all the disks.
You only need it enabled if you boot from a disk attached to the HBA.

-Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/8153adae/attachment-0001.html>

From bfriesen at simple.dallas.tx.us  Wed Mar  8 16:52:17 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Wed, 8 Mar 2017 10:52:17 -0600 (CST)
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <1731769e-a1cc-d07c-46c4-4750a55b4109@yuma.acns.colostate.edu>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<alpine.GSO.2.20.1703080830070.13280@freddy.simplesystems.org>
	<1731769e-a1cc-d07c-46c4-4750a55b4109@yuma.acns.colostate.edu>
Message-ID: <alpine.GSO.2.20.1703081045200.64@scrappy.simplesystems.org>

On Wed, 8 Mar 2017, Kevin.Swab at colostate.edu wrote:
>
> It looks like this MB may have an onboard SAS controller.  If you're
> using that, there may be a similar option somewhere in the system BIOS.

I am using a plug-in HBA and direct-connect chassis with 16 channels. 
I think it is a Broadcom/Avago SAS 9300-16i

This controller is definitely not a bottleneck for the 16 SAS drives.

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

From lkateley at kateley.com  Wed Mar  8 17:01:42 2017
From: lkateley at kateley.com (Linda Kateley)
Date: Wed, 8 Mar 2017 11:01:42 -0600
Subject: [OmniOS-discuss] new supermicro server
In-Reply-To: <A0854771-9A75-4874-8379-2630DD88EE6E@avsquad.com>
References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net>
	<52F1007B-37FB-4CB4-A4C9-732D39A023E5@omniti.com>
	<540718223.55.1488951317198.JavaMail.stephan.budach@budy.stephanbudach.de>
	<5e6f5ed4-f0cf-f39d-e3a5-a3d82f5ec8b1@gnaa.net>
	<E2670F8D-D6CF-453E-A0AB-C94B4FAF33C0@omniti.com>
	<1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<A0854771-9A75-4874-8379-2630DD88EE6E@avsquad.com>
Message-ID: <e4f95618-95a8-a663-712c-4a504c78041f@kateley.com>

So quick google on "razor cards" came up pretty empty(lots of using a 
razor blade on your cpu).. I will assume that is some sort of switch? 
pci switch? Does latency stay in tact?

Ok so I read the first part of the manual.. It looks like it has 4 nvme 
ports via OCuLink, which if I am reading correctly will have/need 4 
lanes of  PCI Express 4? and a dual sas backplane for like the rest. 
OCuLink driver in Omni? First pass on Oculink looks pretty cool. 8T

I am looking at one of those for a project so I will read and report back :)


lk


On 3/8/17 1:32 AM, Ergi Thanasko wrote:
> No LSI controller on those, they connect directly to the CPU with razor cards.  In theory they can utilize the entire bus speed but in the backplane you get around 2GB/sec throughout on each nvme drive.
>
> Sent from my iPhone
>
>> On Mar 7, 2017, at 11:25 PM, Stephan Budach <stephan.budach at jvm.de> wrote:
>>
>>
>>
>> ----- Urspr?ngliche Mail -----
>>> Von: "Dan McDonald" <danmcd at omniti.com>
>>> An: "Geoff Nordli" <geoffn at gnaa.net>
>>> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
>>> Gesendet: Mittwoch, 8. M?rz 2017 07:44:30
>>> Betreff: Re: [OmniOS-discuss] new supermicro server
>>>
>>> You didn't mention anything in the original note about NVMe, and
>>> neither did the spec sheet.
>>>
>>> NVMe 1.0 and 1.1 should work on 020 and later OmniOS. Hang out on the
>>> illumos developers list to see the latest on that front.
>>>
>>> Dan
>>>
>>> Sent from my iPhone (typos, autocorrect, and all)
>>>
>> In regards of NVMe, I am eyeing this particular Supermicro and I intend to get my hands on two of those in Q2:
>>
>> SuperMicro SuperServer SSG-2028R-NR48N
>>
>> I think these will bring a lot of fun to the table. ;)
>>
>> Cheers,
>> Stephan
>> _______________________________________________
>> 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 prakash.surya at delphix.com  Wed Mar  8 18:49:56 2017
From: prakash.surya at delphix.com (Prakash Surya)
Date: Wed, 8 Mar 2017 10:49:56 -0800
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
 HVM and an "xdf" Device
In-Reply-To: <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
	<939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
Message-ID: <CAGDMPV9H-ONWnzJYPQ-yYCqfZ8_KBE6WJek2pXnpPSfHZTyCeg@mail.gmail.com>

Thanks Dan, this is exactly the process I took. I used the KMDB "trick" to
modify "apix_enable" and get the ISO installer to boot, and the updated
"/mnt/etc/system" after the installation completed (as Dan mentioned).

On Wed, Mar 8, 2017 at 7:08 AM, Dan McDonald <danmcd at omniti.com> wrote:

>
> On Mar 8, 2017, at 2:28 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
>
> Can you elaborate on that a little more as of what exactly you did to the
> loader? I am guessing that you modified the kernel boot arguments,
> but unfortuanetly, I am unfamiliar with the new loader.
>
>
> Screenshots being inlined...
>
> Step 1:  Say hello to the new Loader menu:
>
>
> note that on the new ISO, there will be no "Select Boot Environment"
> option.  Nonetheless, we don't want that.  We want to modify the boot
> options (#5 or the 'O' key):
>
> Step 2:  Say hello to the Boot Options menu:
>
>
> To boot under kmdb  (the kernel debugger) AND have the kmdb prompt occur
> immediately you now simply enable kmdb with 'm' or with '7', and debug with
> 'd' or '8'.  After pressing both keys, things should look like this:
>
>
> Step 3:  Press RETURN to boot, and get to the kmdb prompt and fix
> apix_enable.
>
> You will get to the kmdb prompt now.  I've typed in three commands:
>  "apix_enable/X" to show its current value, "apix_enable/W0" to set it to
> 0, and "apix_enable/X" again to show it is indeed 0.  Pardon the noise on
> one part... using arrows for history on kmdb prints extra characters:
>
>
> Step 4:  Proceed with boot.
>
> Enter ":c" into kmdb and the kernel will boot.
>
>
> If you do that trick on the installer ISO, you'll jump immediately to the
> installation menu.
>
> Once booted, if it's an installed system, you can login and edit
> /etc/system to add: "set apix_enable=0" on a line by itself.  If it's the
> installer ISO, do the installation, THEN enter the shell and edit
> /mnt/etc/system.  The new installer keeps the newly-installed BE mounted on
> /mnt so people can post-process it after installation.  We MAY exploit this
> to enhance the installation menu and installation experience.
>
> Hope this helps!
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/33187336/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 9.58.00 AM.png
Type: image/png
Size: 67519 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/33187336/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 9.59.47 AM.png
Type: image/png
Size: 101565 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/33187336/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 10.02.32 AM.png
Type: image/png
Size: 65033 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/33187336/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 10.06.03 AM.png
Type: image/png
Size: 74822 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/33187336/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-08 at 10.05.01 AM.png
Type: image/png
Size: 49320 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/33187336/attachment-0009.png>

From dirk.willems at exitas.be  Wed Mar  8 18:53:02 2017
From: dirk.willems at exitas.be (Dirk Willems)
Date: Wed, 8 Mar 2017 19:53:02 +0100
Subject: [OmniOS-discuss] qemu: too many IDE bus
In-Reply-To: <CAOc1FHhzHQJ7SL8683zq3WdDBxEWPsNkih=v9P_A4odt8gwROg@mail.gmail.com>
References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>
	<CAOc1FHhzHQJ7SL8683zq3WdDBxEWPsNkih=v9P_A4odt8gwROg@mail.gmail.com>
Message-ID: <5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be>

Hello Nahum,


My apologize in the meantime I had found the solution with changing the 
IDE with the virtio, the ide is indeed limit to 4 devices but now it's 
running perfectly  thanks ;)

But another question, do you have experience with adding raw devices in 
KVM ?


Thanks in advance.


Kind Regards,


Dirk


On 08-03-17 16:06, Nahum Shalman wrote:
> I would think that depending on how you're invoking QEMU (it looked 
> like the full qemu command line was truncated from the output you 
> pasted) it' allocating one of the 4 available IDE slots to a virtual 
> CDROM. Depending on your guest OS you could consider using a different 
> virtual controller for the virtual disks, or you might be able to tell 
> qemu not to allocate a virtual cdrom drive.
>
> If you want to share the full qemu command line being invoked I'm 
> happy to take a quick look at it to see if I can figure out a simple 
> way to improve it.
>
> (I suspect that "cd /KVM_Machines/JDN && bash -x ./JDN01_Start-VM.sh" 
> will provide the information needed)
>
> -Nahum
>
> On Fri, Mar 3, 2017 at 10:12 AM, Dirk Willems <dirk.willems at exitas.be 
> <mailto:dirk.willems at exitas.be>> wrote:
>
>     Hello,
>
>     I experience some issue's with too many IDE bus on KVM ?
>
>     I'm only allowed to having 3 HDD, when I add the fourth HDD I get
>     the following error
>
>     qemu: too many IDE bus
>
>     root at OmniosExitas:/KVM_Machines/JDN# ./JDN01_Start-VM.sh
>     qemu-system-x86_64: -net
>     vnic,vlan=0,name=net0,ifname=VLJDN01,macaddr=2:8:20:2:4b:a4,: vnic
>     dhcp disabled
>
>     qemu-system-x86_64: -net
>     vnic,vlan=1,name=net1,ifname=VSJDN01,macaddr=2:8:20:67:1:7c,: vnic
>     dhcp disabled
>
>     qemu: too many IDE bus
>     Failed to start VM
>     Started VM:
>     Public: 127.0.0.1
>     10.100.23.86
>     ::1/128
>     ::/0:5903
>
>
>     I just upgrade to
>
>     root at OmniosExitas:/KVM_Machines/JDN# uname -a
>     SunOS OmniosExitas 5.11 omnios-r151020-4151d05 i86pc i386 i86pc
>
>     Any suggestions ?
>
>
>     Thanks in advance.
>
>
>     Kind Regards.
>
>
>     Dirk
>
>
>
>     -- 
>     	Dirk Willems
>     System Engineer
>
>
>     +32 (0)3 443 12 38 <tel:+32%203%20443%2012%2038>
>     Dirk.Willems at exitas.be <mailto:Dirk.Willems at exitas.be>
>
>     Quality. Passion. Personality
>
>     www.exitas.be <http://www.exitas.be/> | Veldkant 31 | 2550 Kontich
>
>     Illumos OmniOS Installation and Configuration Implementation
>     Specialist.
>     Oracle Solaris 11 Installation and Configuration Certified
>     Implementation Specialist. 	
>
>
>     _______________________________________________
>     OmniOS-discuss mailing list
>     OmniOS-discuss at lists.omniti.com
>     <mailto:OmniOS-discuss at lists.omniti.com>
>     http://lists.omniti.com/mailman/listinfo/omnios-discuss
>     <http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>
>

-- 
	Dirk Willems
System Engineer


+32 (0)3 443 12 38
Dirk.Willems at exitas.be <mailto:Dirk.Willems at exitas.be>

Quality. Passion. Personality

www.exitas.be <http://www.exitas.be/> | Veldkant 31 | 2550 Kontich

Illumos OmniOS Installation and Configuration Implementation Specialist.
Oracle Solaris 11 Installation and Configuration Certified 
Implementation Specialist. 	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/67f8fcb0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12658 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/67f8fcb0/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4648 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/67f8fcb0/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: placeholder-exitas.jpg
Type: image/jpeg
Size: 12658 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/67f8fcb0/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmallPhoenixLogotypeRGB.png
Type: image/png
Size: 4648 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/67f8fcb0/attachment-0003.png>

From pietervanpuymbroeck at hotmail.com  Wed Mar  8 19:32:23 2017
From: pietervanpuymbroeck at hotmail.com (pieter van puymbroeck)
Date: Wed, 8 Mar 2017 19:32:23 +0000
Subject: [OmniOS-discuss] Omnios: can't start as many kvm's as I thought due
	to memory pressure
In-Reply-To: <5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be>
References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>
	<CAOc1FHhzHQJ7SL8683zq3WdDBxEWPsNkih=v9P_A4odt8gwROg@mail.gmail.com>,
	<5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be>
Message-ID: <AM5PR0901MB150658EAA77C45136CCF91B5AA2E0@AM5PR0901MB1506.eurprd09.prod.outlook.com>

Hi,


I want to start 12 kvm machines in my global zone and I end up in an memlock issue after the 6th machine:


qemu_mlock: have only locked 0 of 7516192768 bytes; still trying?


The details:


# echo "::memstat" | mdb -k

Page Summary                Pages                MB  %Tot

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

Kernel                    1462114              5711    5%

Boot pages                    166                 0    0%

ZFS File Data              143529               560    0%

Anon                        27477               107    0%

Exec and libs                1244                 4    0%

Page cache                   4911                19    0%

Free (cachelist)             3597                14    0%

Free (freelist)          29809914            116444   95%


Total                    31452952            122863

Physical                 31452951            122863

#


My pagesize is:


# pagesize

4096

#



so 31452952 pages = (122863*1024*1024) bytes / 4096 (bytes)

thus: 31452952 / 256 = 122863MB


That's correct. So pages to MB we can divide by 256. MB to pages, multiply with 256.


I want 8GB per vm and I want 12vm's. This is 96GB (98304MB)

-> needs 98304 * 256 = 25165824 pages.



31452952 - 25165824 = 6287128 left (or 24559 MB ~ 23.9GB )


I reserved (in /etc/system ) 15 GB for zfs arc

15GB = 15360 MB = 3932160 pages


So this gives 6287128 - 3932160 = 2354968 pages left (or 9199MB ~ 8.98 GB)


-> this should be sufficient for omnios to run. Unless I'm not aware of other things, which is very well possible.


So remember


Page Summary                Pages                MB  %Tot

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

...

Free (cachelist)             3597                14    0%

Free (freelist)          29809914            116444   95%


Total                    31452952            122863

Physical                 31452951            122863

#


Let's boot one kvm with 8GB ram for the vm. We expect to see (8GB *1024) * 256 = 2097152 pages be eaten up. So we should end up with 31452952 - 2097152 = 29355800 pages.

OR if we are eating from the "Free" part, we should end up with 29809914 - 2097152 = 27712762 pages (or 108252MB ~105.71 GB)


Let's confirm:


Before boot:

# mdb -ke 'availrmem/D ; pages_pp_maximum/D'

availrmem:

availrmem:      29845807

pages_pp_maximum:

pages_pp_maximum:               1216998

#


Boot the machine.


# echo "::memstat" | mdb -k

Page Summary                Pages                MB  %Tot

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

Kernel                    1472257              5751    5%

Boot pages                    166                 0    0%

ZFS File Data              149321               583    0%

Anon                      2139596              8357    7%

Exec and libs                1549                 6    0%

Page cache                   4955                19    0%

Free (cachelist)             3445                13    0%

Free (freelist)          27681663            108131   88% <<<----- 27712762 pages


Total                    31452952            122863

Physical                 31452951            122863

# mdb -ke 'availrmem/D ; pages_pp_maximum/D'

availrmem:

availrmem:      26621718

pages_pp_maximum:

pages_pp_maximum:               1216998

#



look there. We expected to end up with 29355800 pages or 27712762 free pages.


If we check in the available memory 29845807 - 26621718 = 3224089 pages were consumed (12594.09MB ~ 12.29GB )

Double check: 29809914 - 27681663 = 2128251 pages consumed ( 8313.48MB ~ 8.11GB )

And this for a machine of 8GB.


Let's do a test with a vm with 4GB allocated ( 1048576 pages )



Before boot:

# echo "::memstat" | mdb -k

Page Summary                Pages                MB  %Tot

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

Kernel                    1476857              5768    5%

Boot pages                    166                 0    0%

ZFS File Data              176243               688    1%

Anon                      2139416              8357    7%

Exec and libs                1549                 6    0%

Page cache                   4961                19    0%

Free (cachelist)             3440                13    0%

Free (freelist)          27650320            108009   88%


Total                    31452952            122863

Physical                 31452951            122863

# mdb -ke 'availrmem/D ; pages_pp_maximum/D'

availrmem:

availrmem:      26596813

pages_pp_maximum:

pages_pp_maximum:               1216998

#


So we expect

27650320 - 1048576 = 26601744 free pages (103913.06 MB ~ 101.47 GB free)

or

26596813 - 1048576 = 25548237 free pages (99797.80 MB ~ 97.45 GB free)


Booting the vm.

And the aftermath:


# ./start_kvm_pogo.sh

qemu-system-x86_64: -net vnic,vlan=40,name=net0,ifname=vnic_kvm_pogo0,macaddr=2:8:20:87:2f:69: vnic dhcp disabled


Started VM: pogo

VNC available at: host IP 127.0.0.1

10.0.1.171

::1/128

::/0 port 5900

QEMU Monitor, do: # telnet localhost . Note: use Control ] to exit monitor before quit!

#


Check the values

# echo "::memstat" | mdb -k

Page Summary                Pages                MB  %Tot

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

Kernel                    1482301              5790    5%

Boot pages                    166                 0    0%

ZFS File Data              180958               706    1%

Anon                      3198541             12494   10%

Exec and libs                1549                 6    0%

Page cache                   4961                19    0%

Free (cachelist)             3440                13    0%

Free (freelist)          26581036            103832   85%


Total                    31452952            122863

Physical                 31452951            122863

#

# mdb -ke 'availrmem/D ; pages_pp_maximum/D'

availrmem:

availrmem:      24472324

pages_pp_maximum:

pages_pp_maximum:               1216998

#


let's verify.

Test1:

27650320 - 26581036 = 1069284 pages consumed ( 4176.89 MB ~ 4GB )

Test 2:

26596813 - 24472324 = 2124489 pages consumed ( 8298.78 MB ~ 8.10GB )



3 questions remain.

- Why does this happen. If we check using the memstat it's fairly ok, but appearently this is not correct as I can't start the 12 machines.

- How to avoid this. If I say to kvm "use 8GB" I want it to use 8GB not 12GB. Or am I missing something crucial?

- If it's a (kernel) parameter ... which one and how to set it?


Thanks and best regards,

Pieter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170308/141acc32/attachment-0001.html>

From danmcd at omniti.com  Wed Mar  8 19:45:14 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 8 Mar 2017 14:45:14 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
	plus Kayak for ISO is almost beta
Message-ID: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>

If you're using bloody, please use "pkg update (-r)" to update to the very latest:  omnios-master-650595c.  This is a merge-with-upstreams update, with one or two other fixes to help the Kayak-for-ISO work move along.  (Notably, "diskinfo" is now part of the "entire" consolidation.)

More interestingly, the Kayak-for-ISO is now feature complete with the addition of working disk-selection-install.  PLEASE try it out.  It's simpler than the old Caiman one, but should be functionally equivalent (and it doesn't use function keys).

The still-in-testing ISO is here:

	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

Hashes are:

md5 (r151021-kayak.iso) = f875c1f102d7f242869f9afde2196aa4
sha1 (r151021-kayak.iso) = a1b3ce074c40a4b8436c4dba02f08e0a29ba82d7
sha256 (r151021-kayak.iso) = a3c65ef2dd3bd6f42fb6d36e9fac155f055e3495fe272dc5bc7c86fa3757fea2

Please share with the whole list how this goes.  I know there are still some systems that appear to not even get past loader, but with Prakash's explanation of how to disable apix, it may run better on Xen environments.

Thanks,
Dan


From janus at volny.cz  Wed Mar  8 21:29:28 2017
From: janus at volny.cz (Jan Vlach)
Date: Wed, 8 Mar 2017 22:29:28 +0100
Subject: [OmniOS-discuss] Omnios: can't start as many kvm's as I thought
 due to memory pressure
In-Reply-To: <AM5PR0901MB150658EAA77C45136CCF91B5AA2E0@AM5PR0901MB1506.eurprd09.prod.outlook.com>
References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>
	<CAOc1FHhzHQJ7SL8683zq3WdDBxEWPsNkih=v9P_A4odt8gwROg@mail.gmail.com>
	<5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be>
	<AM5PR0901MB150658EAA77C45136CCF91B5AA2E0@AM5PR0901MB1506.eurprd09.prod.outlook.com>
Message-ID: <20170308212916.oq57sj2jnpyhr5oa@volny.cz>

Hi Pieter,

how much disk space do you have allocated for swap?

Jan

On Wed, Mar 08, 2017 at 07:32:23PM +0000, pieter van puymbroeck wrote:
> Hi,
> 
> 
> I want to start 12 kvm machines in my global zone and I end up in an memlock issue after the 6th machine:
> 
> 
> qemu_mlock: have only locked 0 of 7516192768 bytes; still trying?
> 
> 
> The details:
> 
> 
> # echo "::memstat" | mdb -k
> 
> Page Summary                Pages                MB  %Tot
> 
> ------------     ----------------  ----------------  ----
> 
> Kernel                    1462114              5711    5%
> 
> Boot pages                    166                 0    0%
> 
> ZFS File Data              143529               560    0%
> 
> Anon                        27477               107    0%
> 
> Exec and libs                1244                 4    0%
> 
> Page cache                   4911                19    0%
> 
> Free (cachelist)             3597                14    0%
> 
> Free (freelist)          29809914            116444   95%
> 
> 
> Total                    31452952            122863
> 
> Physical                 31452951            122863
> 
> #
> 
> 
> My pagesize is:
> 
> 
> # pagesize
> 
> 4096
> 
> #
> 
> 
> 
> so 31452952 pages = (122863*1024*1024) bytes / 4096 (bytes)
> 
> thus: 31452952 / 256 = 122863MB
> 
> 
> That's correct. So pages to MB we can divide by 256. MB to pages, multiply with 256.
> 
> 
> I want 8GB per vm and I want 12vm's. This is 96GB (98304MB)
> 
> -> needs 98304 * 256 = 25165824 pages.
> 
> 
> 
> 31452952 - 25165824 = 6287128 left (or 24559 MB ~ 23.9GB )
> 
> 
> I reserved (in /etc/system ) 15 GB for zfs arc
> 
> 15GB = 15360 MB = 3932160 pages
> 
> 
> So this gives 6287128 - 3932160 = 2354968 pages left (or 9199MB ~ 8.98 GB)
> 
> 
> -> this should be sufficient for omnios to run. Unless I'm not aware of other things, which is very well possible.
> 
> 
> So remember
> 
> 
> Page Summary                Pages                MB  %Tot
> 
> ------------     ----------------  ----------------  ----
> 
> ...
> 
> Free (cachelist)             3597                14    0%
> 
> Free (freelist)          29809914            116444   95%
> 
> 
> Total                    31452952            122863
> 
> Physical                 31452951            122863
> 
> #
> 
> 
> Let's boot one kvm with 8GB ram for the vm. We expect to see (8GB *1024) * 256 = 2097152 pages be eaten up. So we should end up with 31452952 - 2097152 = 29355800 pages.
> 
> OR if we are eating from the "Free" part, we should end up with 29809914 - 2097152 = 27712762 pages (or 108252MB ~105.71 GB)
> 
> 
> Let's confirm:
> 
> 
> Before boot:
> 
> # mdb -ke 'availrmem/D ; pages_pp_maximum/D'
> 
> availrmem:
> 
> availrmem:      29845807
> 
> pages_pp_maximum:
> 
> pages_pp_maximum:               1216998
> 
> #
> 
> 
> Boot the machine.
> 
> 
> # echo "::memstat" | mdb -k
> 
> Page Summary                Pages                MB  %Tot
> 
> ------------     ----------------  ----------------  ----
> 
> Kernel                    1472257              5751    5%
> 
> Boot pages                    166                 0    0%
> 
> ZFS File Data              149321               583    0%
> 
> Anon                      2139596              8357    7%
> 
> Exec and libs                1549                 6    0%
> 
> Page cache                   4955                19    0%
> 
> Free (cachelist)             3445                13    0%
> 
> Free (freelist)          27681663            108131   88% <<<----- 27712762 pages
> 
> 
> Total                    31452952            122863
> 
> Physical                 31452951            122863
> 
> # mdb -ke 'availrmem/D ; pages_pp_maximum/D'
> 
> availrmem:
> 
> availrmem:      26621718
> 
> pages_pp_maximum:
> 
> pages_pp_maximum:               1216998
> 
> #
> 
> 
> 
> look there. We expected to end up with 29355800 pages or 27712762 free pages.
> 
> 
> If we check in the available memory 29845807 - 26621718 = 3224089 pages were consumed (12594.09MB ~ 12.29GB )
> 
> Double check: 29809914 - 27681663 = 2128251 pages consumed ( 8313.48MB ~ 8.11GB )
> 
> And this for a machine of 8GB.
> 
> 
> Let's do a test with a vm with 4GB allocated ( 1048576 pages )
> 
> 
> 
> Before boot:
> 
> # echo "::memstat" | mdb -k
> 
> Page Summary                Pages                MB  %Tot
> 
> ------------     ----------------  ----------------  ----
> 
> Kernel                    1476857              5768    5%
> 
> Boot pages                    166                 0    0%
> 
> ZFS File Data              176243               688    1%
> 
> Anon                      2139416              8357    7%
> 
> Exec and libs                1549                 6    0%
> 
> Page cache                   4961                19    0%
> 
> Free (cachelist)             3440                13    0%
> 
> Free (freelist)          27650320            108009   88%
> 
> 
> Total                    31452952            122863
> 
> Physical                 31452951            122863
> 
> # mdb -ke 'availrmem/D ; pages_pp_maximum/D'
> 
> availrmem:
> 
> availrmem:      26596813
> 
> pages_pp_maximum:
> 
> pages_pp_maximum:               1216998
> 
> #
> 
> 
> So we expect
> 
> 27650320 - 1048576 = 26601744 free pages (103913.06 MB ~ 101.47 GB free)
> 
> or
> 
> 26596813 - 1048576 = 25548237 free pages (99797.80 MB ~ 97.45 GB free)
> 
> 
> Booting the vm.
> 
> And the aftermath:
> 
> 
> # ./start_kvm_pogo.sh
> 
> qemu-system-x86_64: -net vnic,vlan=40,name=net0,ifname=vnic_kvm_pogo0,macaddr=2:8:20:87:2f:69: vnic dhcp disabled
> 
> 
> Started VM: pogo
> 
> VNC available at: host IP 127.0.0.1
> 
> 10.0.1.171
> 
> ::1/128
> 
> ::/0 port 5900
> 
> QEMU Monitor, do: # telnet localhost . Note: use Control ] to exit monitor before quit!
> 
> #
> 
> 
> Check the values
> 
> # echo "::memstat" | mdb -k
> 
> Page Summary                Pages                MB  %Tot
> 
> ------------     ----------------  ----------------  ----
> 
> Kernel                    1482301              5790    5%
> 
> Boot pages                    166                 0    0%
> 
> ZFS File Data              180958               706    1%
> 
> Anon                      3198541             12494   10%
> 
> Exec and libs                1549                 6    0%
> 
> Page cache                   4961                19    0%
> 
> Free (cachelist)             3440                13    0%
> 
> Free (freelist)          26581036            103832   85%
> 
> 
> Total                    31452952            122863
> 
> Physical                 31452951            122863
> 
> #
> 
> # mdb -ke 'availrmem/D ; pages_pp_maximum/D'
> 
> availrmem:
> 
> availrmem:      24472324
> 
> pages_pp_maximum:
> 
> pages_pp_maximum:               1216998
> 
> #
> 
> 
> let's verify.
> 
> Test1:
> 
> 27650320 - 26581036 = 1069284 pages consumed ( 4176.89 MB ~ 4GB )
> 
> Test 2:
> 
> 26596813 - 24472324 = 2124489 pages consumed ( 8298.78 MB ~ 8.10GB )
> 
> 
> 
> 3 questions remain.
> 
> - Why does this happen. If we check using the memstat it's fairly ok, but appearently this is not correct as I can't start the 12 machines.
> 
> - How to avoid this. If I say to kvm "use 8GB" I want it to use 8GB not 12GB. Or am I missing something crucial?
> 
> - If it's a (kernel) parameter ... which one and how to set it?
> 
> 
> Thanks and best regards,
> 
> Pieter
> 
> 

> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


-- 
Be the change you want to see in the world.

From pietervanpuymbroeck at hotmail.com  Thu Mar  9 06:34:11 2017
From: pietervanpuymbroeck at hotmail.com (pieter van puymbroeck)
Date: Thu, 9 Mar 2017 06:34:11 +0000
Subject: [OmniOS-discuss] Omnios: can't start as many kvm's as I thought
 due to memory pressure
In-Reply-To: <20170308212916.oq57sj2jnpyhr5oa@volny.cz>
References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>
	<CAOc1FHhzHQJ7SL8683zq3WdDBxEWPsNkih=v9P_A4odt8gwROg@mail.gmail.com>
	<5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be>
	<AM5PR0901MB150658EAA77C45136CCF91B5AA2E0@AM5PR0901MB1506.eurprd09.prod.outlook.com>,
	<20170308212916.oq57sj2jnpyhr5oa@volny.cz>
Message-ID: <AM5PR0901MB1506096E2F4C5A845B86691DAA210@AM5PR0901MB1506.eurprd09.prod.outlook.com>

Hello Jan,

$ swap -sh                           
total: 52G allocated + 100M reserved = 53G used, 8.8G available
$

This is when 7 machines are running. 
I face the issue when starting the 8th one.

Br
Pieter


Verstuurd vanaf mijn iPhone

> Op 8 mrt. 2017 om 22:29 heeft Jan Vlach <janus at volny.cz> het volgende geschreven:
> 
> Hi Pieter,
> 
> how much disk space do you have allocated for swap?
> 
> Jan
> 
>> On Wed, Mar 08, 2017 at 07:32:23PM +0000, pieter van puymbroeck wrote:
>> Hi,
>> 
>> 
>> I want to start 12 kvm machines in my global zone and I end up in an memlock issue after the 6th machine:
>> 
>> 
>> qemu_mlock: have only locked 0 of 7516192768 bytes; still trying?
>> 
>> 
>> The details:
>> 
>> 
>> # echo "::memstat" | mdb -k
>> 
>> Page Summary                Pages                MB  %Tot
>> 
>> ------------     ----------------  ----------------  ----
>> 
>> Kernel                    1462114              5711    5%
>> 
>> Boot pages                    166                 0    0%
>> 
>> ZFS File Data              143529               560    0%
>> 
>> Anon                        27477               107    0%
>> 
>> Exec and libs                1244                 4    0%
>> 
>> Page cache                   4911                19    0%
>> 
>> Free (cachelist)             3597                14    0%
>> 
>> Free (freelist)          29809914            116444   95%
>> 
>> 
>> Total                    31452952            122863
>> 
>> Physical                 31452951            122863
>> 
>> #
>> 
>> 
>> My pagesize is:
>> 
>> 
>> # pagesize
>> 
>> 4096
>> 
>> #
>> 
>> 
>> 
>> so 31452952 pages = (122863*1024*1024) bytes / 4096 (bytes)
>> 
>> thus: 31452952 / 256 = 122863MB
>> 
>> 
>> That's correct. So pages to MB we can divide by 256. MB to pages, multiply with 256.
>> 
>> 
>> I want 8GB per vm and I want 12vm's. This is 96GB (98304MB)
>> 
>> -> needs 98304 * 256 = 25165824 pages.
>> 
>> 
>> 
>> 31452952 - 25165824 = 6287128 left (or 24559 MB ~ 23.9GB )
>> 
>> 
>> I reserved (in /etc/system ) 15 GB for zfs arc
>> 
>> 15GB = 15360 MB = 3932160 pages
>> 
>> 
>> So this gives 6287128 - 3932160 = 2354968 pages left (or 9199MB ~ 8.98 GB)
>> 
>> 
>> -> this should be sufficient for omnios to run. Unless I'm not aware of other things, which is very well possible.
>> 
>> 
>> So remember
>> 
>> 
>> Page Summary                Pages                MB  %Tot
>> 
>> ------------     ----------------  ----------------  ----
>> 
>> ...
>> 
>> Free (cachelist)             3597                14    0%
>> 
>> Free (freelist)          29809914            116444   95%
>> 
>> 
>> Total                    31452952            122863
>> 
>> Physical                 31452951            122863
>> 
>> #
>> 
>> 
>> Let's boot one kvm with 8GB ram for the vm. We expect to see (8GB *1024) * 256 = 2097152 pages be eaten up. So we should end up with 31452952 - 2097152 = 29355800 pages.
>> 
>> OR if we are eating from the "Free" part, we should end up with 29809914 - 2097152 = 27712762 pages (or 108252MB ~105.71 GB)
>> 
>> 
>> Let's confirm:
>> 
>> 
>> Before boot:
>> 
>> # mdb -ke 'availrmem/D ; pages_pp_maximum/D'
>> 
>> availrmem:
>> 
>> availrmem:      29845807
>> 
>> pages_pp_maximum:
>> 
>> pages_pp_maximum:               1216998
>> 
>> #
>> 
>> 
>> Boot the machine.
>> 
>> 
>> # echo "::memstat" | mdb -k
>> 
>> Page Summary                Pages                MB  %Tot
>> 
>> ------------     ----------------  ----------------  ----
>> 
>> Kernel                    1472257              5751    5%
>> 
>> Boot pages                    166                 0    0%
>> 
>> ZFS File Data              149321               583    0%
>> 
>> Anon                      2139596              8357    7%
>> 
>> Exec and libs                1549                 6    0%
>> 
>> Page cache                   4955                19    0%
>> 
>> Free (cachelist)             3445                13    0%
>> 
>> Free (freelist)          27681663            108131   88% <<<----- 27712762 pages
>> 
>> 
>> Total                    31452952            122863
>> 
>> Physical                 31452951            122863
>> 
>> # mdb -ke 'availrmem/D ; pages_pp_maximum/D'
>> 
>> availrmem:
>> 
>> availrmem:      26621718
>> 
>> pages_pp_maximum:
>> 
>> pages_pp_maximum:               1216998
>> 
>> #
>> 
>> 
>> 
>> look there. We expected to end up with 29355800 pages or 27712762 free pages.
>> 
>> 
>> If we check in the available memory 29845807 - 26621718 = 3224089 pages were consumed (12594.09MB ~ 12.29GB )
>> 
>> Double check: 29809914 - 27681663 = 2128251 pages consumed ( 8313.48MB ~ 8.11GB )
>> 
>> And this for a machine of 8GB.
>> 
>> 
>> Let's do a test with a vm with 4GB allocated ( 1048576 pages )
>> 
>> 
>> 
>> Before boot:
>> 
>> # echo "::memstat" | mdb -k
>> 
>> Page Summary                Pages                MB  %Tot
>> 
>> ------------     ----------------  ----------------  ----
>> 
>> Kernel                    1476857              5768    5%
>> 
>> Boot pages                    166                 0    0%
>> 
>> ZFS File Data              176243               688    1%
>> 
>> Anon                      2139416              8357    7%
>> 
>> Exec and libs                1549                 6    0%
>> 
>> Page cache                   4961                19    0%
>> 
>> Free (cachelist)             3440                13    0%
>> 
>> Free (freelist)          27650320            108009   88%
>> 
>> 
>> Total                    31452952            122863
>> 
>> Physical                 31452951            122863
>> 
>> # mdb -ke 'availrmem/D ; pages_pp_maximum/D'
>> 
>> availrmem:
>> 
>> availrmem:      26596813
>> 
>> pages_pp_maximum:
>> 
>> pages_pp_maximum:               1216998
>> 
>> #
>> 
>> 
>> So we expect
>> 
>> 27650320 - 1048576 = 26601744 free pages (103913.06 MB ~ 101.47 GB free)
>> 
>> or
>> 
>> 26596813 - 1048576 = 25548237 free pages (99797.80 MB ~ 97.45 GB free)
>> 
>> 
>> Booting the vm.
>> 
>> And the aftermath:
>> 
>> 
>> # ./start_kvm_pogo.sh
>> 
>> qemu-system-x86_64: -net vnic,vlan=40,name=net0,ifname=vnic_kvm_pogo0,macaddr=2:8:20:87:2f:69: vnic dhcp disabled
>> 
>> 
>> Started VM: pogo
>> 
>> VNC available at: host IP 127.0.0.1
>> 
>> 10.0.1.171
>> 
>> ::1/128
>> 
>> ::/0 port 5900
>> 
>> QEMU Monitor, do: # telnet localhost . Note: use Control ] to exit monitor before quit!
>> 
>> #
>> 
>> 
>> Check the values
>> 
>> # echo "::memstat" | mdb -k
>> 
>> Page Summary                Pages                MB  %Tot
>> 
>> ------------     ----------------  ----------------  ----
>> 
>> Kernel                    1482301              5790    5%
>> 
>> Boot pages                    166                 0    0%
>> 
>> ZFS File Data              180958               706    1%
>> 
>> Anon                      3198541             12494   10%
>> 
>> Exec and libs                1549                 6    0%
>> 
>> Page cache                   4961                19    0%
>> 
>> Free (cachelist)             3440                13    0%
>> 
>> Free (freelist)          26581036            103832   85%
>> 
>> 
>> Total                    31452952            122863
>> 
>> Physical                 31452951            122863
>> 
>> #
>> 
>> # mdb -ke 'availrmem/D ; pages_pp_maximum/D'
>> 
>> availrmem:
>> 
>> availrmem:      24472324
>> 
>> pages_pp_maximum:
>> 
>> pages_pp_maximum:               1216998
>> 
>> #
>> 
>> 
>> let's verify.
>> 
>> Test1:
>> 
>> 27650320 - 26581036 = 1069284 pages consumed ( 4176.89 MB ~ 4GB )
>> 
>> Test 2:
>> 
>> 26596813 - 24472324 = 2124489 pages consumed ( 8298.78 MB ~ 8.10GB )
>> 
>> 
>> 
>> 3 questions remain.
>> 
>> - Why does this happen. If we check using the memstat it's fairly ok, but appearently this is not correct as I can't start the 12 machines.
>> 
>> - How to avoid this. If I say to kvm "use 8GB" I want it to use 8GB not 12GB. Or am I missing something crucial?
>> 
>> - If it's a (kernel) parameter ... which one and how to set it?
>> 
>> 
>> Thanks and best regards,
>> 
>> Pieter
>> 
>> 
> 
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
> 
> -- 
> Be the change you want to see in the world.

From bauernfeind at ipk-gatersleben.de  Thu Mar  9 07:52:57 2017
From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind)
Date: Thu, 9 Mar 2017 07:52:57 +0000
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>

Hello,

thanks for the new iso and your work.
I tested it in Vmware (one virtual disk) without problems.
Later that day I will try it in our Oracle VM system (Xen).
The only thing I am missing is the selection of the keyboard layout, can
this be implemented?

Jens

-----Original Message-----
From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On
Behalf Of Dan McDonald
Sent: Mittwoch, 8. M?rz 2017 20:45
To: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is
almost beta

If you're using bloody, please use "pkg update (-r)" to update to the very
latest:  omnios-master-650595c.  This is a merge-with-upstreams update, with
one or two other fixes to help the Kayak-for-ISO work move along.  (Notably,
"diskinfo" is now part of the "entire" consolidation.)

More interestingly, the Kayak-for-ISO is now feature complete with the
addition of working disk-selection-install.  PLEASE try it out.  It's
simpler than the old Caiman one, but should be functionally equivalent (and
it doesn't use function keys).

The still-in-testing ISO is here:

	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

Hashes are:

md5 (r151021-kayak.iso) = f875c1f102d7f242869f9afde2196aa4
sha1 (r151021-kayak.iso) = a1b3ce074c40a4b8436c4dba02f08e0a29ba82d7
sha256 (r151021-kayak.iso) =
a3c65ef2dd3bd6f42fb6d36e9fac155f055e3495fe272dc5bc7c86fa3757fea2

Please share with the whole list how this goes.  I know there are still some
systems that appear to not even get past loader, but with Prakash's
explanation of how to disable apix, it may run better on Xen environments.

Thanks,
Dan

_______________________________________________
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: smime.p7s
Type: application/pkcs7-signature
Size: 6023 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/8cd89443/attachment.bin>

From janus at volny.cz  Thu Mar  9 08:55:14 2017
From: janus at volny.cz (Jan Vlach)
Date: Thu, 9 Mar 2017 09:55:14 +0100
Subject: [OmniOS-discuss] Omnios: can't start as many kvm's as I thought
 due to memory pressure
In-Reply-To: <AM5PR0901MB1506096E2F4C5A845B86691DAA210@AM5PR0901MB1506.eurprd09.prod.outlook.com>
References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>
	<CAOc1FHhzHQJ7SL8683zq3WdDBxEWPsNkih=v9P_A4odt8gwROg@mail.gmail.com>
	<5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be>
	<AM5PR0901MB150658EAA77C45136CCF91B5AA2E0@AM5PR0901MB1506.eurprd09.prod.outlook.com>
	<20170308212916.oq57sj2jnpyhr5oa@volny.cz>
	<AM5PR0901MB1506096E2F4C5A845B86691DAA210@AM5PR0901MB1506.eurprd09.prod.outlook.com>
Message-ID: <20170309085514.mkbf5c2scl6imjd6@volny.cz>

Hi Pieter,

Can you make your swapfile 96G or larger? 

If I recall correctly, KVM needs all it's RAM backed up by swap, because
of fragmentation and other reasons. 

Jan



On Thu, Mar 09, 2017 at 06:34:11AM +0000, pieter van puymbroeck wrote:
> Hello Jan,
> 
> $ swap -sh                           
> total: 52G allocated + 100M reserved = 53G used, 8.8G available
> $
> 
> This is when 7 machines are running. 
> I face the issue when starting the 8th one.
> 
> Br
> Pieter
> 
> 
> Verstuurd vanaf mijn iPhone

From manuel at oetiker.ch  Thu Mar  9 09:07:22 2017
From: manuel at oetiker.ch (Manuel Oetiker)
Date: Thu, 9 Mar 2017 10:07:22 +0100 (CET)
Subject: [OmniOS-discuss] how to set a ipv6 address in a lxzone
Message-ID: <646447041.95746.1489050442316.JavaMail.zimbra@oetiker.ch>

Hi 

I what to setup a lxzone with a ipv4 and a ipv6 address.

/usr/sbin/zonecfg -z franz add net; add property (name=ips,value="44.141.183.210/24") ; add property (name=gateway,value="44.141.183.193") ; add property (name=primary,value="true") ; set physical=franz0; end

this ist working but how can I add the ipv6 address?

thanks 

manuel

From bauernfeind at ipk-gatersleben.de  Thu Mar  9 10:23:32 2017
From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind)
Date: Thu, 9 Mar 2017 10:23:32 +0000
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>

Hello again,

I installed successfully the ISO on our oracle vm server (Oracle VM 3.2.9)
-> xen-4.1.3-25.el5.223.26
I just need to disable the apix stuff and add " set apix_enable=0" after the
installation.
The installer found 2 disks:
8<---
bash-4.4# diskinfo
TYPE    DISK                    VID      PID              SIZE          RMV
SSD
ATA     c2d0                    -        -                  20.00 GiB   no
no
-       c4t768d0                -        -                  20.00 GiB   no
no
8<---
During the installation I used the c2d0 device.

A message about a failed pv driver pops up twice, but i don't know which
device that is
8<---
WARNING: pv driver failed to connect: /xpvd/xdf at 5632
WARNING: PV access to device disabled: /pci at 0,0/pci-ide at 1,1/ide at 1/sd at 0,0
8<---

Jens

-----Original Message-----
From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On
Behalf Of Jens Bauernfeind
Sent: Donnerstag, 9. M?rz 2017 08:53
To: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is
almost beta

Hello,

thanks for the new iso and your work.
I tested it in Vmware (one virtual disk) without problems.
Later that day I will try it in our Oracle VM system (Xen).
The only thing I am missing is the selection of the keyboard layout, can
this be implemented?

Jens

-----Original Message-----
From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On
Behalf Of Dan McDonald
Sent: Mittwoch, 8. M?rz 2017 20:45
To: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is
almost beta

If you're using bloody, please use "pkg update (-r)" to update to the very
latest:  omnios-master-650595c.  This is a merge-with-upstreams update, with
one or two other fixes to help the Kayak-for-ISO work move along.  (Notably,
"diskinfo" is now part of the "entire" consolidation.)

More interestingly, the Kayak-for-ISO is now feature complete with the
addition of working disk-selection-install.  PLEASE try it out.  It's
simpler than the old Caiman one, but should be functionally equivalent (and
it doesn't use function keys).

The still-in-testing ISO is here:

	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

Hashes are:

md5 (r151021-kayak.iso) = f875c1f102d7f242869f9afde2196aa4
sha1 (r151021-kayak.iso) = a1b3ce074c40a4b8436c4dba02f08e0a29ba82d7
sha256 (r151021-kayak.iso) =
a3c65ef2dd3bd6f42fb6d36e9fac155f055e3495fe272dc5bc7c86fa3757fea2

Please share with the whole list how this goes.  I know there are still some
systems that appear to not even get past loader, but with Prakash's
explanation of how to disable apix, it may run better on Xen environments.

Thanks,
Dan

_______________________________________________
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: smime.p7s
Type: application/pkcs7-signature
Size: 6023 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/acc4e115/attachment-0001.bin>

From stephan.budach at jvm.de  Thu Mar  9 10:46:08 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Thu, 9 Mar 2017 11:46:08 +0100 (CET)
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local>

Hi Jens,

----- Urspr?ngliche Mail -----
> Von: "Jens Bauernfeind" <bauernfeind at ipk-gatersleben.de>
> An: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Donnerstag, 9. M?rz 2017 11:23:32
> Betreff: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is almost beta
> 
> Hello again,
> 
> I installed successfully the ISO on our oracle vm server (Oracle VM
> 3.2.9)
> -> xen-4.1.3-25.el5.223.26
> I just need to disable the apix stuff and add " set apix_enable=0"
> after the
> installation.
> The installer found 2 disks:
> 8<---
> bash-4.4# diskinfo
> TYPE    DISK                    VID      PID              SIZE
>          RMV
> SSD
> ATA     c2d0                    -        -                  20.00 GiB
>   no
> no
> -       c4t768d0                -        -                  20.00 GiB
>   no
> no
> 8<---
> During the installation I used the c2d0 device.
> 
> A message about a failed pv driver pops up twice, but i don't know
> which
> device that is
> 8<---
> WARNING: pv driver failed to connect: /xpvd/xdf at 5632
> WARNING: PV access to device disabled:
> /pci at 0,0/pci-ide at 1,1/ide at 1/sd at 0,0
> 8<---
> 
> Jens
> 

I tested the prior ISO yesterday on our OVM 3.4.2 and I couldn't get it to work. OVM 3.2.9 is somwhat "outdated", but could you provide the settings for the guest, that you chose?

Thanks,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/646399a3/attachment.bin>

From bauernfeind at ipk-gatersleben.de  Thu Mar  9 10:56:43 2017
From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind)
Date: Thu, 9 Mar 2017 10:56:43 +0000
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>
	<292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC635B5E@XCH-MBX1.ipk-gatersleben.de>

Hi Stephan,

thats correct, it is an old version, but the current version on the Oracle Database Appliance we are running here, engineered system, yeah :-(

I think a snippet of the vm.cfg is enough?
8<---
memory = 4096
kernel = '/usr/lib/xen/boot/hvmloader'
cpu_cap = 0
vif = ['type=netfront,bridge=net1']
device_model = '/usr/lib64/xen/bin/qemu-dm'
builder = 'hvm'
vnclisten = '0.0.0.0'
boot = 'c'
cpus = '0,1,2,3,4,5,6,7,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47'
passwd = ''
vcpus = 4
apic = 1
sdl = 0
maxvcpus = 4
serial = 'pty'
disk = [u'file:/OVS/Repositories/sh_repo/.ACFS/snaps/omnios-test/VirtualMachines/omnios-test/omnios.img,hda,w']
vnc = 1
acpi = 1
maxmem = 4096
8<---

Jens

-----Original Message-----
From: Stephan Budach [mailto:stephan.budach at jvm.de] 
Sent: Donnerstag, 9. M?rz 2017 11:46
To: Jens Bauernfeind <bauernfeind at ipk-gatersleben.de>
Cc: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is almost beta

Hi Jens,

----- Urspr?ngliche Mail -----
> Von: "Jens Bauernfeind" <bauernfeind at ipk-gatersleben.de>
> An: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Donnerstag, 9. M?rz 2017 11:23:32
> Betreff: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is almost beta
> 
> Hello again,
> 
> I installed successfully the ISO on our oracle vm server (Oracle VM
> 3.2.9)
> -> xen-4.1.3-25.el5.223.26
> I just need to disable the apix stuff and add " set apix_enable=0"
> after the
> installation.
> The installer found 2 disks:
> 8<---
> bash-4.4# diskinfo
> TYPE    DISK                    VID      PID              SIZE
>          RMV
> SSD
> ATA     c2d0                    -        -                  20.00 GiB
>   no
> no
> -       c4t768d0                -        -                  20.00 GiB
>   no
> no
> 8<---
> During the installation I used the c2d0 device.
> 
> A message about a failed pv driver pops up twice, but i don't know
> which
> device that is
> 8<---
> WARNING: pv driver failed to connect: /xpvd/xdf at 5632
> WARNING: PV access to device disabled:
> /pci at 0,0/pci-ide at 1,1/ide at 1/sd at 0,0
> 8<---
> 
> Jens
> 

I tested the prior ISO yesterday on our OVM 3.4.2 and I couldn't get it to work. OVM 3.2.9 is somwhat "outdated", but could you provide the settings for the guest, that you chose?

Thanks,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6023 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/be8153e4/attachment.bin>

From lotheac at iki.fi  Thu Mar  9 11:01:07 2017
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Thu, 9 Mar 2017 13:01:07 +0200
Subject: [OmniOS-discuss] how to set a ipv6 address in a lxzone
In-Reply-To: <646447041.95746.1489050442316.JavaMail.zimbra@oetiker.ch>
References: <646447041.95746.1489050442316.JavaMail.zimbra@oetiker.ch>
Message-ID: <20170309110107.GD23293@kekkonen.niksula.hut.fi>

On Thu, Mar 09 2017 10:07:22 +0100, Manuel Oetiker wrote:
> I what to setup a lxzone with a ipv4 and a ipv6 address.
> 
> /usr/sbin/zonecfg -z franz add net; add property (name=ips,value="44.141.183.210/24") ; add property (name=gateway,value="44.141.183.193") ; add property (name=primary,value="true") ; set physical=franz0; end
> 
> this ist working but how can I add the ipv6 address?

I found the following works for SLAAC+DHCP, but I haven't tested static
addresses:

    add net
    set physical=foo0
    add property (name=primary,value="true")
    add property (name=ips,value="dhcp,addrconf")
    end

ie. just add another address into the same property and delimit them with
commas.

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From bauernfeind at ipk-gatersleben.de  Thu Mar  9 11:14:04 2017
From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind)
Date: Thu, 9 Mar 2017 11:14:04 +0000
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC635B5E@XCH-MBX1.ipk-gatersleben.de>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>
	<292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local>
	<B9D9271554C34B41866AA2801A8FD279AC635B5E@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC635B8F@XCH-MBX1.ipk-gatersleben.de>

Little mistake, we are running 3.2.10

-----Original Message-----
From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Jens Bauernfeind
Sent: Donnerstag, 9. M?rz 2017 11:57
To: Stephan Budach <stephan.budach at jvm.de>
Cc: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is almost beta

Hi Stephan,

thats correct, it is an old version, but the current version on the Oracle Database Appliance we are running here, engineered system, yeah :-(

I think a snippet of the vm.cfg is enough?
8<---
memory = 4096
kernel = '/usr/lib/xen/boot/hvmloader'
cpu_cap = 0
vif = ['type=netfront,bridge=net1']
device_model = '/usr/lib64/xen/bin/qemu-dm'
builder = 'hvm'
vnclisten = '0.0.0.0'
boot = 'c'
cpus = '0,1,2,3,4,5,6,7,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47'
passwd = ''
vcpus = 4
apic = 1
sdl = 0
maxvcpus = 4
serial = 'pty'
disk = [u'file:/OVS/Repositories/sh_repo/.ACFS/snaps/omnios-test/VirtualMachines/omnios-test/omnios.img,hda,w']
vnc = 1
acpi = 1
maxmem = 4096
8<---

Jens

-----Original Message-----
From: Stephan Budach [mailto:stephan.budach at jvm.de]
Sent: Donnerstag, 9. M?rz 2017 11:46
To: Jens Bauernfeind <bauernfeind at ipk-gatersleben.de>
Cc: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is almost beta

Hi Jens,

----- Urspr?ngliche Mail -----
> Von: "Jens Bauernfeind" <bauernfeind at ipk-gatersleben.de>
> An: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Donnerstag, 9. M?rz 2017 11:23:32
> Betreff: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for 
> ISO is almost beta
> 
> Hello again,
> 
> I installed successfully the ISO on our oracle vm server (Oracle VM
> 3.2.9)
> -> xen-4.1.3-25.el5.223.26
> I just need to disable the apix stuff and add " set apix_enable=0"
> after the
> installation.
> The installer found 2 disks:
> 8<---
> bash-4.4# diskinfo
> TYPE    DISK                    VID      PID              SIZE
>          RMV
> SSD
> ATA     c2d0                    -        -                  20.00 GiB
>   no
> no
> -       c4t768d0                -        -                  20.00 GiB
>   no
> no
> 8<---
> During the installation I used the c2d0 device.
> 
> A message about a failed pv driver pops up twice, but i don't know 
> which device that is
> 8<---
> WARNING: pv driver failed to connect: /xpvd/xdf at 5632
> WARNING: PV access to device disabled:
> /pci at 0,0/pci-ide at 1,1/ide at 1/sd at 0,0
> 8<---
> 
> Jens
> 

I tested the prior ISO yesterday on our OVM 3.4.2 and I couldn't get it to work. OVM 3.2.9 is somwhat "outdated", but could you provide the settings for the guest, that you chose?

Thanks,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6023 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/58c289aa/attachment-0001.bin>

From manuel at oetiker.ch  Thu Mar  9 13:27:09 2017
From: manuel at oetiker.ch (Manuel Oetiker)
Date: Thu, 9 Mar 2017 14:27:09 +0100 (CET)
Subject: [OmniOS-discuss] how to set a ipv6 address in a lxzone
In-Reply-To: <20170309110107.GD23293@kekkonen.niksula.hut.fi>
References: <646447041.95746.1489050442316.JavaMail.zimbra@oetiker.ch>
	<20170309110107.GD23293@kekkonen.niksula.hut.fi>
Message-ID: <1379925303.104380.1489066029719.JavaMail.zimbra@oetiker.ch>

----- Original Message -----
> From: "Lauri Tirkkonen" <lotheac at iki.fi>
> To: "Manuel Oetiker" <manuel at oetiker.ch>
> Cc: omnios-discuss at lists.omniti.com
> Sent: Thursday, March 9, 2017 12:01:07 PM
> Subject: Re: [OmniOS-discuss] how to set a ipv6 address in a lxzone

> On Thu, Mar 09 2017 10:07:22 +0100, Manuel Oetiker wrote:
>> I what to setup a lxzone with a ipv4 and a ipv6 address.
>> 
>> /usr/sbin/zonecfg -z franz add net; add property
>> (name=ips,value="44.141.183.210/24") ; add property
>> (name=gateway,value="44.141.183.193") ; add property
>> (name=primary,value="true") ; set physical=franz0; end
>> 
>> this ist working but how can I add the ipv6 address?
> 
> I found the following works for SLAAC+DHCP, but I haven't tested static
> addresses:
> 
>    add net
>    set physical=foo0
>    add property (name=primary,value="true")
>    add property (name=ips,value="dhcp,addrconf")
>    end
> 
> ie. just add another address into the same property and delimit them with
> commas.


yes thats working for a second ipv4 address in the same subnet but I need to configure
a ipv6 default gw as well. 


--
Manuel Oetiker 


From prakash.surya at delphix.com  Thu Mar  9 14:29:18 2017
From: prakash.surya at delphix.com (Prakash Surya)
Date: Thu, 9 Mar 2017 06:29:18 -0800
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <CAGDMPV9OrcAQRxonnED4LrSFcshQyLZq68haDDMKPCS_3X0L2A@mail.gmail.com>

Dan,

This is was I was talking about; depending on the VM configuration, the ATA
device, and the XDF device may show up inside the VM on Xen.

Without this patch:


https://github.com/omniti-labs/illumos-omnios/commit/1b5a946e10cb0aefb70eb10f6a0fb7f6d8a91f42

I think only the ATA would have shown up in the example below.

On Thu, Mar 9, 2017 at 2:23 AM, Jens Bauernfeind <
bauernfeind at ipk-gatersleben.de> wrote:

> Hello again,
>
> I installed successfully the ISO on our oracle vm server (Oracle VM 3.2.9)
> -> xen-4.1.3-25.el5.223.26
> I just need to disable the apix stuff and add " set apix_enable=0" after
> the
> installation.
> The installer found 2 disks:
> 8<---
> bash-4.4# diskinfo
> TYPE    DISK                    VID      PID              SIZE          RMV
> SSD
> ATA     c2d0                    -        -                  20.00 GiB   no
> no
> -       c4t768d0                -        -                  20.00 GiB   no
> no
> 8<---
> During the installation I used the c2d0 device.
>
> A message about a failed pv driver pops up twice, but i don't know which
> device that is
> 8<---
> WARNING: pv driver failed to connect: /xpvd/xdf at 5632
> WARNING: PV access to device disabled: /pci at 0,0/pci-ide at 1,1/ide at 1/sd at 0,0
> 8<---
>
> Jens
>
> -----Original Message-----
> From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On
> Behalf Of Jens Bauernfeind
> Sent: Donnerstag, 9. M?rz 2017 08:53
> To: omnios-discuss <omnios-discuss at lists.omniti.com>
> Subject: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is
> almost beta
>
> Hello,
>
> thanks for the new iso and your work.
> I tested it in Vmware (one virtual disk) without problems.
> Later that day I will try it in our Oracle VM system (Xen).
> The only thing I am missing is the selection of the keyboard layout, can
> this be implemented?
>
> Jens
>
> -----Original Message-----
> From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On
> Behalf Of Dan McDonald
> Sent: Mittwoch, 8. M?rz 2017 20:45
> To: omnios-discuss <omnios-discuss at lists.omniti.com>
> Subject: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is
> almost beta
>
> If you're using bloody, please use "pkg update (-r)" to update to the very
> latest:  omnios-master-650595c.  This is a merge-with-upstreams update,
> with
> one or two other fixes to help the Kayak-for-ISO work move along.
> (Notably,
> "diskinfo" is now part of the "entire" consolidation.)
>
> More interestingly, the Kayak-for-ISO is now feature complete with the
> addition of working disk-selection-install.  PLEASE try it out.  It's
> simpler than the old Caiman one, but should be functionally equivalent (and
> it doesn't use function keys).
>
> The still-in-testing ISO is here:
>
>         http://kebe.com/~danmcd/webrevs/r151021-kayak.iso
>
> Hashes are:
>
> md5 (r151021-kayak.iso) = f875c1f102d7f242869f9afde2196aa4
> sha1 (r151021-kayak.iso) = a1b3ce074c40a4b8436c4dba02f08e0a29ba82d7
> sha256 (r151021-kayak.iso) =
> a3c65ef2dd3bd6f42fb6d36e9fac155f055e3495fe272dc5bc7c86fa3757fea2
>
> Please share with the whole list how this goes.  I know there are still
> some
> systems that appear to not even get past loader, but with Prakash's
> explanation of how to disable apix, it may run better on Xen environments.
>
> Thanks,
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/6a01340f/attachment.html>

From pietervanpuymbroeck at hotmail.com  Thu Mar  9 14:43:48 2017
From: pietervanpuymbroeck at hotmail.com (pieter van puymbroeck)
Date: Thu, 9 Mar 2017 14:43:48 +0000
Subject: [OmniOS-discuss] Omnios: can't start as many kvm's as I thought
 due to memory pressure
In-Reply-To: <20170309085514.mkbf5c2scl6imjd6@volny.cz>
References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>
	<CAOc1FHhzHQJ7SL8683zq3WdDBxEWPsNkih=v9P_A4odt8gwROg@mail.gmail.com>
	<5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be>
	<AM5PR0901MB150658EAA77C45136CCF91B5AA2E0@AM5PR0901MB1506.eurprd09.prod.outlook.com>
	<20170308212916.oq57sj2jnpyhr5oa@volny.cz>
	<AM5PR0901MB1506096E2F4C5A845B86691DAA210@AM5PR0901MB1506.eurprd09.prod.outlook.com>,
	<20170309085514.mkbf5c2scl6imjd6@volny.cz>
Message-ID: <AM5PR0901MB1506A4F527CD9CD14963725FAA210@AM5PR0901MB1506.eurprd09.prod.outlook.com>

Will try it tonight or tomorrow and provide feedback. 
Thanks for the tip.
P.

Verstuurd vanaf mijn iPhone

> Op 9 mrt. 2017 om 09:55 heeft Jan Vlach <janus at volny.cz> het volgende geschreven:
> 
> Hi Pieter,
> 
> Can you make your swapfile 96G or larger? 
> 
> If I recall correctly, KVM needs all it's RAM backed up by swap, because
> of fragmentation and other reasons. 
> 
> Jan
> 
> 
> 
>> On Thu, Mar 09, 2017 at 06:34:11AM +0000, pieter van puymbroeck wrote:
>> Hello Jan,
>> 
>> $ swap -sh                           
>> total: 52G allocated + 100M reserved = 53G used, 8.8G available
>> $
>> 
>> This is when 7 machines are running. 
>> I face the issue when starting the 8th one.
>> 
>> Br
>> Pieter
>> 
>> 
>> Verstuurd vanaf mijn iPhone

From danmcd at omniti.com  Thu Mar  9 14:56:48 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 09:56:48 -0500
Subject: [OmniOS-discuss] how to set a ipv6 address in a lxzone
In-Reply-To: <1379925303.104380.1489066029719.JavaMail.zimbra@oetiker.ch>
References: <646447041.95746.1489050442316.JavaMail.zimbra@oetiker.ch>
	<20170309110107.GD23293@kekkonen.niksula.hut.fi>
	<1379925303.104380.1489066029719.JavaMail.zimbra@oetiker.ch>
Message-ID: <D0BDA1C1-AACF-40C8-9B67-4C292291F5DB@omniti.com>


> On Mar 9, 2017, at 8:27 AM, Manuel Oetiker <manuel at oetiker.ch> wrote:
> 
> yes thats working for a second ipv4 address in the same subnet but I need to configure
> a ipv6 default gw as well. 

addrconf (aka. SLAAC) should get you one from your next-hop already, no?

If you need manual configuration, do your LX native bits have something that can help?  Something akin to the old-fashioned/now-disfavored /etc/defaultrouter on illumos?

Dan


From danmcd at omniti.com  Thu Mar  9 15:04:58 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 10:04:58 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>


> On Mar 9, 2017, at 2:52 AM, Jens Bauernfeind <bauernfeind at ipk-gatersleben.de> wrote:
> 
> The only thing I am missing is the selection of the keyboard layout, can
> this be implemented?

I *think* I can do that.  Apparently it's just the invocation of "kbd -s".  I'll have to include /bin/kbd in the miniroot, of course.  :)

If I spun an experimental ISO that does this, would you try it to confirm? I don't have non-US keyboards readily available.

Dan


From danmcd at omniti.com  Thu Mar  9 15:06:51 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 10:06:51 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <CAGDMPV9OrcAQRxonnED4LrSFcshQyLZq68haDDMKPCS_3X0L2A@mail.gmail.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>
	<CAGDMPV9OrcAQRxonnED4LrSFcshQyLZq68haDDMKPCS_3X0L2A@mail.gmail.com>
Message-ID: <81049D39-1429-48EA-AA1B-5EE6038AFB17@omniti.com>


> On Mar 9, 2017, at 9:29 AM, Prakash Surya <prakash.surya at delphix.com> wrote:
> 
> Dan,
> 
> This is was I was talking about; depending on the VM configuration, the ATA device, and the XDF device may show up inside the VM on Xen.
> 
> Without this patch:
> 
>     https://github.com/omniti-labs/illumos-omnios/commit/1b5a946e10cb0aefb70eb10f6a0fb7f6d8a91f42
> 
> I think only the ATA would have shown up in the example below.

Yeah... I have your patch in illumos-omnios to help people on qemu out, but apparently this is bad for Xen.

Advice on how to proceed?  We have a couple of months before this bloody closes, so additional fixes are fine.  Otherwise I'll have to document this somehow.

Dan


From bauernfeind at ipk-gatersleben.de  Thu Mar  9 15:11:16 2017
From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind)
Date: Thu, 9 Mar 2017 15:11:16 +0000
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>

Sure :-)
But now I am finished for today, so If you later have time to build a new
iso, I will test it tomorrow.

Jens

-----Original Message-----
From: Dan McDonald [mailto:danmcd at omniti.com] 
Sent: Donnerstag, 9. M?rz 2017 16:05
To: Jens Bauernfeind <bauernfeind at ipk-gatersleben.de>
Cc: omnios-discuss <omnios-discuss at lists.omniti.com>; Dan McDonald
<danmcd at omniti.com>
Subject: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is
almost beta


> On Mar 9, 2017, at 2:52 AM, Jens Bauernfeind
<bauernfeind at ipk-gatersleben.de> wrote:
> 
> The only thing I am missing is the selection of the keyboard layout, 
> can this be implemented?

I *think* I can do that.  Apparently it's just the invocation of "kbd -s".
I'll have to include /bin/kbd in the miniroot, of course.  :)

If I spun an experimental ISO that does this, would you try it to confirm? I
don't have non-US keyboards readily available.

Dan

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

From tobi at oetiker.ch  Thu Mar  9 15:35:25 2017
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Thu, 9 Mar 2017 16:35:25 +0100 (CET)
Subject: [OmniOS-discuss] kvm instances random short freeze
Message-ID: <1059368436.106240.1489073725270.JavaMail.zimbra@oetiker.ch>

Hi 

We are running kvm instances on omni r20 and are experiencing random short freezes. 
I wrote the following short test script to see how frequent the freezing occurres 

perl -e 'use Time::HiRes qw(time usleep); my $now = time; while(1){usleep 200000; my $next = time; my $diff = $next - $now; $now=$next; if ($diff > 0.22){ print "".localtime(time)." ".$diff,"\n"}}' 

the output looks like this 

Thu Mar 9 15:26:12 2017 0.224979877471924 
Thu Mar 9 15:26:23 2017 0.273133993148804 
Thu Mar 9 15:27:54 2017 1.17526292800903 
Thu Mar 9 15:28:59 2017 2.04209899902344 
Thu Mar 9 15:30:31 2017 1.0813729763031 
Thu Mar 9 15:30:44 2017 0.600342988967896 
Thu Mar 9 15:31:47 2017 1.43648099899292 
Thu Mar 9 15:32:25 2017 0.897988796234131 
Thu Mar 9 15:33:28 2017 0.998631000518799 
Thu Mar 9 15:34:10 2017 4.89306116104126 
Thu Mar 9 15:36:15 2017 1.22311997413635 
Thu Mar 9 15:38:57 2017 1.64742302894592 
Thu Mar 9 15:39:21 2017 1.36228013038635 
Thu Mar 9 15:40:08 2017 1.62232208251953 
Thu Mar 9 15:40:32 2017 1.37291598320007 
Thu Mar 9 15:42:30 2017 0.211127996444702 

as you can see there are quite frequent short freezes ... 

I am running the same script in the omnios global zone there is no freezing over 0.02s 

any ideas ? 

cheers 
tobi 
-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/1dd94db8/attachment.html>

From stephan.budach at jvm.de  Thu Mar  9 15:41:04 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Thu, 9 Mar 2017 16:41:04 +0100 (CET)
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC635B5E@XCH-MBX1.ipk-gatersleben.de>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>
	<292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local>
	<B9D9271554C34B41866AA2801A8FD279AC635B5E@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <1752144629.965.1489074026813.JavaMail.stephan.budach@stephanbudach.local>

Bummer?

----- Urspr?ngliche Mail -----
> Von: "Jens Bauernfeind" <bauernfeind at ipk-gatersleben.de>
> An: "Stephan Budach" <stephan.budach at jvm.de>
> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Donnerstag, 9. M?rz 2017 11:56:43
> Betreff: RE: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is almost beta [signed OK]
> 
> Hi Stephan,
> 
> thats correct, it is an old version, but the current version on the
> Oracle Database Appliance we are running here, engineered system,
> yeah :-(
> 
> I think a snippet of the vm.cfg is enough?
> 8<---
> memory = 4096
> kernel = '/usr/lib/xen/boot/hvmloader'
> cpu_cap = 0
> vif = ['type=netfront,bridge=net1']
> device_model = '/usr/lib64/xen/bin/qemu-dm'
> builder = 'hvm'
> vnclisten = '0.0.0.0'
> boot = 'c'
> cpus =
> '0,1,2,3,4,5,6,7,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47'
> passwd = ''
> vcpus = 4
> apic = 1
> sdl = 0
> maxvcpus = 4
> serial = 'pty'
> disk =
> [u'file:/OVS/Repositories/sh_repo/.ACFS/snaps/omnios-test/VirtualMachines/omnios-test/omnios.img,hda,w']
> vnc = 1
> acpi = 1
> maxmem = 4096
> 8<---
> 
> Jens

seems, like I can't get that to work on OVM 3.4.2. OVM 3.4.2 is Xen 4.3.something and it totally stalls after having tweaked the apix settings and continue booting. It won't probably work on anything newer than OVM 3.3.x.

Cheers,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/bf3e9a45/attachment-0001.bin>

From stephan.budach at jvm.de  Thu Mar  9 15:49:50 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Thu, 9 Mar 2017 16:49:50 +0100 (CET)
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <1752144629.965.1489074026813.JavaMail.stephan.budach@stephanbudach.local>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<B9D9271554C34B41866AA2801A8FD279AC635B3C@XCH-MBX1.ipk-gatersleben.de>
	<292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local>
	<B9D9271554C34B41866AA2801A8FD279AC635B5E@XCH-MBX1.ipk-gatersleben.de>
	<1752144629.965.1489074026813.JavaMail.stephan.budach@stephanbudach.local>
Message-ID: <1161910211.969.1489074553789.JavaMail.stephan.budach@stephanbudach.local>



----- Urspr?ngliche Mail -----
> Von: "Stephan Budach" <stephan.budach at jvm.de>
> An: "Jens Bauernfeind" <bauernfeind at ipk-gatersleben.de>
> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Donnerstag, 9. M?rz 2017 16:41:04
> Betreff: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is almost beta [signed OK]
> 
> Bummer?
> 
> ----- Urspr?ngliche Mail -----
> > Von: "Jens Bauernfeind" <bauernfeind at ipk-gatersleben.de>
> > An: "Stephan Budach" <stephan.budach at jvm.de>
> > CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> > Gesendet: Donnerstag, 9. M?rz 2017 11:56:43
> > Betreff: RE: [OmniOS-discuss] Bloody update on Repo, plus Kayak for
> > ISO is almost beta [signed OK]
> > 
> > Hi Stephan,
> > 
> > thats correct, it is an old version, but the current version on the
> > Oracle Database Appliance we are running here, engineered system,
> > yeah :-(
> > 
> > I think a snippet of the vm.cfg is enough?
> > 8<---
> > memory = 4096
> > kernel = '/usr/lib/xen/boot/hvmloader'
> > cpu_cap = 0
> > vif = ['type=netfront,bridge=net1']
> > device_model = '/usr/lib64/xen/bin/qemu-dm'
> > builder = 'hvm'
> > vnclisten = '0.0.0.0'
> > boot = 'c'
> > cpus =
> > '0,1,2,3,4,5,6,7,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47'
> > passwd = ''
> > vcpus = 4
> > apic = 1
> > sdl = 0
> > maxvcpus = 4
> > serial = 'pty'
> > disk =
> > [u'file:/OVS/Repositories/sh_repo/.ACFS/snaps/omnios-test/VirtualMachines/omnios-test/omnios.img,hda,w']
> > vnc = 1
> > acpi = 1
> > maxmem = 4096
> > 8<---
> > 
> > Jens
> 
> seems, like I can't get that to work on OVM 3.4.2. OVM 3.4.2 is Xen
> 4.3.something and it totally stalls after having tweaked the apix
> settings and continue booting. It won't probably work on anything
> newer than OVM 3.3.x.
> 
> Cheers,
> Stephan

Sorry, I closed without providing any useful(?) information on the boot process, so here it comes and basically goes like this:

Welcome to kmdb
kmdb: dmod krtld failed to load: Error 2
[0] apix_enable/X
apix_enable:
apix_enable: 1
[0] apix_enable/W0
apix_enable: 0x1 = 0x0
[0] apix_enable/X
apix_enable:
apix_enable: 0
[0] :c
SunOS Release 5.11 Version omnios-master-650595c 64-bit
Copyright (c) 1983,2010, Oracle and/or its affiliates. All rights reserved.
WARNING: /pci at 0,pci1af4,1100 at 1,2 (uhci0); No SOF interrupts have been received, this USB UHCI host controller us unusable
NOTICE: Kernel debugger present: disabling console power management.

aaand? that's it. Up from there it just sits there doing nothing, well seemingly, at least.

Cheers,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/9af86e7f/attachment.bin>

From danmcd at omniti.com  Thu Mar  9 16:05:00 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 11:05:00 -0500
Subject: [OmniOS-discuss] kvm instances random short freeze
In-Reply-To: <1059368436.106240.1489073725270.JavaMail.zimbra@oetiker.ch>
References: <1059368436.106240.1489073725270.JavaMail.zimbra@oetiker.ch>
Message-ID: <6982F519-D9D1-425E-9009-10334A8C29EC@omniti.com>


> On Mar 9, 2017, at 10:35 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
> 
> Hi
> 
> 
> as you can see there are quite frequent short freezes ... 

What are you running in qemu?  Another OmniOS?  Something else?

One thing you might be able to do is use pstack(1) on the qemu process itself to see what's it's doing during these freezes.  Perhaps taking samples every second on the qemu process while it runs and corresponding it to freeze events?

> I am running the same script in the omnios global zone there is no freezing over 0.02s
> 
> any ideas ?

I wonder if qemu is being swapped out due to a scheduling issue?  I wonder if you used priocntl(1) on the process whether or not you could give qemu more scheduling and smooth things out?

Dan


From danmcd at omniti.com  Thu Mar  9 16:18:17 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 11:18:17 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>


> On Mar 9, 2017, at 10:11 AM, Jens Bauernfeind <bauernfeind at ipk-gatersleben.de> wrote:
> 
> Sure :-)
> But now I am finished for today, so If you later have time to build a new
> iso, I will test it tomorrow.

Just updated it in place to new bits that invoke "kbd -s" prior to the menu's first display.  The new checksums for http://kebe.com/~danmcd/webrevs/r151021-kayak.iso are:

md5 (r151021-kayak.iso) = 971cc094a6dc89666f76bc453e2ab13a
sha1 (r151021-kayak.iso) = b72cb1dd08a09f5f9e491acc5aac8f25f852d000
sha256 (r151021-kayak.iso) = 4350d227b28f65746bb361686bde05202d536e5137db07dbfee3d9611756a622

Thanks for the feedback!
Dan


From nshalman at omniti.com  Thu Mar  9 17:10:00 2017
From: nshalman at omniti.com (Nahum Shalman)
Date: Thu, 9 Mar 2017 12:10:00 -0500
Subject: [OmniOS-discuss] qemu: too many IDE bus
In-Reply-To: <5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be>
References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be>
	<CAOc1FHhzHQJ7SL8683zq3WdDBxEWPsNkih=v9P_A4odt8gwROg@mail.gmail.com>
	<5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be>
Message-ID: <CAOc1FHgkDEpxr9j8D=yXGvyw+N1TioqkczQinJJuODoCqNJwyw@mail.gmail.com>

On my SmartOS box I have a one-line script I use for verifying that my USB
stick is still bootable after I update the platform image on it.
It contains:

qemu-system-x86_64 -m 4096 -smp 4 -hda /dev/dsk/c0t0d0p0 -serial stdio

So you should be able to do that with any raw hard drive you might want to
pass through to a virtual machine. (Though I would recommend doing it with
the fancier "-drive" syntax and passing it through with a non-ide
controller.)

-Nahum


On Wed, Mar 8, 2017 at 1:53 PM, Dirk Willems <dirk.willems at exitas.be> wrote:

> Hello Nahum,
>
>
> My apologize in the meantime I had found the solution with changing the
> IDE with the virtio, the ide is indeed limit to 4 devices but now it's
> running perfectly  thanks ;)
>
> But another question, do you have experience with adding raw devices in
> KVM ?
>
>
> Thanks in advance.
>
>
> Kind Regards,
>
>
> Dirk
>
> On 08-03-17 16:06, Nahum Shalman wrote:
>
> I would think that depending on how you're invoking QEMU (it looked like
> the full qemu command line was truncated from the output you pasted) it'
> allocating one of the 4 available IDE slots to a virtual CDROM. Depending
> on your guest OS you could consider using a different virtual controller
> for the virtual disks, or you might be able to tell qemu not to allocate a
> virtual cdrom drive.
>
> If you want to share the full qemu command line being invoked I'm happy to
> take a quick look at it to see if I can figure out a simple way to improve
> it.
>
> (I suspect that "cd /KVM_Machines/JDN && bash -x ./JDN01_Start-VM.sh" will
> provide the information needed)
>
> -Nahum
>
> On Fri, Mar 3, 2017 at 10:12 AM, Dirk Willems <dirk.willems at exitas.be>
> wrote:
>
>> Hello,
>>
>> I experience some issue's with too many IDE bus on KVM ?
>>
>> I'm only allowed to having 3 HDD, when I add the fourth HDD I get the
>> following error
>>
>> qemu: too many IDE bus
>>
>> root at OmniosExitas:/KVM_Machines/JDN# ./JDN01_Start-VM.sh
>> qemu-system-x86_64: -net vnic,vlan=0,name=net0,ifname=V
>> LJDN01,macaddr=2:8:20:2:4b:a4,: vnic dhcp disabled
>>
>> qemu-system-x86_64: -net vnic,vlan=1,name=net1,ifname=V
>> SJDN01,macaddr=2:8:20:67:1:7c,: vnic dhcp disabled
>>
>> qemu: too many IDE bus
>> Failed to start VM
>> Started VM:
>> Public: 127.0.0.1
>> 10.100.23.86
>> ::1/128
>> ::/0:5903
>>
>>
>> I just upgrade to
>>
>> root at OmniosExitas:/KVM_Machines/JDN# uname -a
>> SunOS OmniosExitas 5.11 omnios-r151020-4151d05 i86pc i386 i86pc
>>
>> Any suggestions ?
>>
>>
>> Thanks in advance.
>>
>>
>> Kind Regards.
>>
>>
>> Dirk
>>
>>
>>
>> --
>> Dirk Willems
>> System Engineer
>>
>>
>> +32 (0)3 443 12 38 <+32%203%20443%2012%2038>
>> Dirk.Willems at exitas.be
>>
>> Quality. Passion. Personality
>>
>> www.exitas.be | Veldkant 31 | 2550 Kontich
>>
>> Illumos OmniOS Installation and Configuration Implementation Specialist.
>> Oracle Solaris 11 Installation and Configuration Certified Implementation
>> Specialist.
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>
> --
> Dirk Willems
> System Engineer
>
>
> +32 (0)3 443 12 38 <+32%203%20443%2012%2038>
> Dirk.Willems at exitas.be
>
> Quality. Passion. Personality
>
> www.exitas.be | Veldkant 31 | 2550 Kontich
>
> Illumos OmniOS Installation and Configuration Implementation Specialist.
> Oracle Solaris 11 Installation and Configuration Certified Implementation
> Specialist.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/e8d3277a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: placeholder-exitas.jpg
Type: image/jpeg
Size: 12658 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/e8d3277a/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmallPhoenixLogotypeRGB.png
Type: image/png
Size: 4648 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/e8d3277a/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12658 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/e8d3277a/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4648 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/e8d3277a/attachment-0003.png>

From john.barfield at bissinc.com  Thu Mar  9 18:06:48 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Thu, 9 Mar 2017 18:06:48 +0000
Subject: [OmniOS-discuss] DTrace Scripts
Message-ID: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>

Im looking for some general dtrace scripts for debugging ZFS on OmniOS (like updated dtrace toolkit)..didnt want to reinvent the wheel if some folks are willing to share. Also willing to purchase if needed.

John Barfield
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/abeada59/attachment.html>

From danmcd at omniti.com  Thu Mar  9 18:15:19 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 13:15:19 -0500
Subject: [OmniOS-discuss] DTrace Scripts
In-Reply-To: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
References: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
Message-ID: <37C45A89-F894-43F1-A908-DAA0E1F6136F@omniti.com>


> On Mar 9, 2017, at 1:06 PM, John Barfield <john.barfield at bissinc.com> wrote:
> 
> Im looking for some general dtrace scripts for debugging ZFS on OmniOS (like updated dtrace toolkit)..didnt want to reinvent the wheel if some folks are willing to share. Also willing to purchase if needed.

You may wish to forward this query along to the illumos developer's list and the OpenZFS developer's list as well.

Dan


From apenner.it at gmail.com  Thu Mar  9 18:56:08 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Thu, 09 Mar 2017 18:56:08 +0000
Subject: [OmniOS-discuss] DTrace Scripts
In-Reply-To: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
References: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
Message-ID: <CAE9csxMsh7J-3aD2UT096T4_vhG2CN9KoP9FHqyFiKrwDrVR5A@mail.gmail.com>

May be links below will be helpful for you

https://github.com/brendangregg/dtrace-cloud-tools
https://github.com/richardelling/dtrace
https://github.com/richardelling/arcstat
https://bitbucket.org/d-helios/dtrace/src/7b479a97099f3146b4d08652315b03d1dfc28f9c/zfs/?at=master





??, 9 ???. 2017 ?. ? 21:08, John Barfield <john.barfield at bissinc.com>:

> Im looking for some general dtrace scripts for debugging ZFS on OmniOS
> (like updated dtrace toolkit)..didnt want to reinvent the wheel if some
> folks are willing to share. Also willing to purchase if needed.
>
> John Barfield
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/92dd0844/attachment.html>

From cks at cs.toronto.edu  Thu Mar  9 19:05:13 2017
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Thu, 09 Mar 2017 14:05:13 -0500
Subject: [OmniOS-discuss] DTrace Scripts
In-Reply-To: Your message of Thu, 09 Mar 2017 18:06:48 +0000.
	<F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
Message-ID: <20170309190513.3A2605A00D2@apps1.cs.toronto.edu>

> Im looking for some general dtrace scripts for debugging ZFS on OmniOS
> (like updated dtrace toolkit)..didnt want to reinvent the wheel if
> some folks are willing to share. Also willing to purchase if needed.

 We have a collection of local DTrace scripts at:
	https://github.com/siebenmann/cks-dtrace

These include some ZFS monitoring and tracing scripts that you may
find useful, even if they have some extra features (eg iSCSI and NFSv3
tracing) that you don't need.

	- cks

From danmcd at omniti.com  Thu Mar  9 20:28:16 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 15:28:16 -0500
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
Message-ID: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>

Say hello:

	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

It now includes over this morning's major bump of "menu option #1":

	- Keyboard layout query at start time, like the old installer.

	- A fix so the boot archive at installation HAS its SHA-1 checksum in place

The sums are:

md5 (r151021-kayak.iso) = 3170424fecdf582f7014e1a253acc7d3
sha1 (r151021-kayak.iso) = 29e8a2fc207b39617809867818197752de47dbe8
sha256 (r151021-kayak.iso) = 9236d2ee76368ed30d3102402b968ac9b8ca59a7e17195a16f6ae417eba303e2


Please try it, both on existing, known-to-work platforms, and continuing on to the newer ones like Xen or qemu, that had not worked in the past.

Thank you!
Dan

p.s. If people are happy with this, I may officially cut over bloody media to use this revision of kayak-for-ISO once I can figure out the .usb-dd problem.


From mir at miras.org  Thu Mar  9 20:46:33 2017
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 9 Mar 2017 21:46:33 +0100
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
Message-ID: <20170309214633.52905b34@sleipner.datanom.net>

On Thu, 9 Mar 2017 11:18:17 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> Just updated it in place to new bits that invoke "kbd -s" prior to the menu's first display.  The new checksums for http://kebe.com/~danmcd/webrevs/r151021-kayak.iso are:
> 
> md5 (r151021-kayak.iso) = 971cc094a6dc89666f76bc453e2ab13a
> sha1 (r151021-kayak.iso) = b72cb1dd08a09f5f9e491acc5aac8f25f852d000
> sha256 (r151021-kayak.iso) = 4350d227b28f65746bb361686bde05202d536e5137db07dbfee3d9611756a622
> 
Hi Dan,

Just tried this iso but disk discovery is weird. Can you explain this?
(see attached screenshot)

-- 
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 sect or party is an elegant incognito devised to save a man from
the vexation of thinking.
		-- Ralph Waldo Emerson, Journals, 1831
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot at 2017-03-09 21-45-02.png
Type: image/png
Size: 14257 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/cb581929/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/cb581929/attachment-0001.bin>

From danmcd at omniti.com  Thu Mar  9 20:53:21 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 15:53:21 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <20170309214633.52905b34@sleipner.datanom.net>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
Message-ID: <268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>


> On Mar 9, 2017, at 3:46 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Thu, 9 Mar 2017 11:18:17 -0500
> Dan McDonald <danmcd at omniti.com> wrote:
> 
>> 
>> Just updated it in place to new bits that invoke "kbd -s" prior to the menu's first display.  The new checksums for http://kebe.com/~danmcd/webrevs/r151021-kayak.iso are:
>> 
>> md5 (r151021-kayak.iso) = 971cc094a6dc89666f76bc453e2ab13a
>> sha1 (r151021-kayak.iso) = b72cb1dd08a09f5f9e491acc5aac8f25f852d000
>> sha256 (r151021-kayak.iso) = 4350d227b28f65746bb361686bde05202d536e5137db07dbfee3d9611756a622
>> 
> Hi Dan,
> 
> Just tried this iso but disk discovery is weird. Can you explain this?
> (see attached screenshot)

Is this on a Xen install?  Prakash mentioned that there are "two paths, one device" problems on Xen.

BTW, option #1 (based on diskinfo) works now, if you just want a whole-disk install.

Dan


From mir at miras.org  Thu Mar  9 21:02:59 2017
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 9 Mar 2017 22:02:59 +0100
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
Message-ID: <20170309220259.5b977199@sleipner.datanom.net>

On Thu, 9 Mar 2017 15:53:21 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> Is this on a Xen install?  Prakash mentioned that there are "two paths, one device" problems on Xen.
> 
No, qemu

> BTW, option #1 (based on diskinfo) works now, if you just want a whole-disk install.
> 
Option #1 did not find any disks and as the screendump shows there is 3
disks to choose from. The disks contain a previous installation. Could
that be an explanation?

-- 
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 kissed my first girl and smoked my first cigarette on the same day.
I haven't had time for tobacco since.
		-- Arturo Toscanini
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/2465aa23/attachment.bin>

From mir at miras.org  Thu Mar  9 21:17:51 2017
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 9 Mar 2017 22:17:51 +0100
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <20170309220259.5b977199@sleipner.datanom.net>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
	<20170309220259.5b977199@sleipner.datanom.net>
Message-ID: <20170309221751.5efa3079@sleipner.datanom.net>

On Thu, 9 Mar 2017 22:02:59 +0100
Michael Rasmussen <mir at miras.org> wrote:

> Option #1 did not find any disks and as the screendump shows there is 3
> disks to choose from. The disks contain a previous installation. Could
> that be an explanation?
> 
Choosing option #3 makes all 3 disks available which was not working in
the previous iso releases. Only problem seems that either diskinfo is
broken or brakes if disks contains file systems and/or exported pools.

-- 
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:
Close cover before striking.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/8f05a8c4/attachment.bin>

From danmcd at omniti.com  Thu Mar  9 21:20:07 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 16:20:07 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <20170309220259.5b977199@sleipner.datanom.net>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
	<20170309220259.5b977199@sleipner.datanom.net>
Message-ID: <BA7E903A-AB0C-4882-B9D2-3175BA75FAAD@omniti.com>


> On Mar 9, 2017, at 4:02 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> Option #1 did not find any disks and as the screendump shows there is 3
> disks to choose from. The disks contain a previous installation. Could
> that be an explanation?

If diskinfo showed a single disk, option 1's screen should've shown a single disk as well.  Why the difference?

If you exit the shell (where diskinfo clearly showed something) and go back to option 1, what does it show now?

Dan


From danmcd at omniti.com  Thu Mar  9 21:21:55 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 16:21:55 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <20170309221751.5efa3079@sleipner.datanom.net>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
	<20170309220259.5b977199@sleipner.datanom.net>
	<20170309221751.5efa3079@sleipner.datanom.net>
Message-ID: <A147AF49-0BC4-444A-AC99-9D28582D72D7@omniti.com>


> On Mar 9, 2017, at 4:17 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> Only problem seems that either diskinfo is
> broken or brakes if disks contains file systems and/or exported pools.

That's not true.  Run diskinfo on a running system.

I'm willing to wager that FMA's libtopo stuff still has problems with vioblk disks somehow.

Dan


From doug at will.to  Thu Mar  9 21:21:59 2017
From: doug at will.to (Doug Hughes)
Date: Thu, 9 Mar 2017 16:21:59 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
Message-ID: <19d41f04-c255-09ee-1273-fc83a3d5351a@will.to>

Kvm/libvirt

it goes a good ways, but then cycles back. I set it to verbose and kmdb 
and am at the kmdb prompt with the following traceback:

I set console=ttya, acpi = off, single user = on, verbose = on, and kmdb 
= on and selected option 1 to go into single user mode.

Aside: it'd be nice if the console stuff was mirrored to ttya as a 
default so that one could do everything without having the virtual 
console up. RIght now, the menu is only available on the virtual console.

module /platform/i86pc/kernel/amd64/unix: text at [0xfffffffffb800000, 
0xfffffffffb959b23] data at 0xfffffffffbc00000
module /kernel/amd64/genunix: text at [0xfffffffffb959b40, 
0xfffffffffbbe5c07] data at 0xfffffffffbc9ea80
Loading kmdb...
module /kernel/misc/amd64/kmdbmod: text at [0xfffffffffbd0edc0, 
0xfffffffffbdc7667] data at 0xfffffffffbdc7680
module /kernel/misc/amd64/ctf: text at [0xfffffffffbbe5c20, 
0xfffffffffbbf03cf] data at 0xfffffffffbe00ae0

panic[cpu0]/thread=fffffffffbc38560: BAD TRAP: type=d (#gp General 
protection) rp=fffffffffbc7abc0 addr=0

#gp General protection
pid=0, pc=0xfffffffffb861ccb, sp=0xfffffffffbc7acb0, eflags=0x10002
cr0: 80050011<pg,wp,et,pe> cr4: b8<pge,pae,pse,de>
cr2: 0cr3: 27000000cr8: 0

         rdi:         9c5a203a rsi:                e rdx:              f00
         rcx:         c0011023  r8:               fc r9:              f61
         rax:                8 rbx: fffffffffbc397a0 rbp: fffffffffbc7acb0
         r10: fffffffffb856f10 r11:                f r12:                8
         r13:               1f r14:                8 r15:                0
         fsb:        200000000 gsb: fffffffffbc397a0 ds:                0
          es:                0  fs:                0 gs:                0
         trp:                d err:                0 rip: fffffffffb861ccb
          cs:               30 rfl:            10002 rsp: fffffffffbc7acb0
          ss:               38

Warning - stack not written to the dump buffer
fffffffffbc7aaa0 unix:real_mode_stop_cpu_stage2_end+b1f3 ()
fffffffffbc7abb0 unix:trap+a70 ()
fffffffffbc7abc0 unix:_cmntrap+e6 ()
fffffffffbc7acb0 unix:xrdmsr+b ()
fffffffffbc7ad70 unix:workaround_errata+3c0 ()
fffffffffbc7adb0 unix:mlsetup+59e ()
fffffffffbc7adc0 unix:_locore_start+8b ()


panic: entering debugger (no dump device, continue to reboot)

Welcome to kmdb
kmdb: unable to determine terminal type: assuming `vt100'
kmdb: dmod krtld failed to load: Error 2
[0]> $C
fffffffffbc82e00 kmdb_enter+0xb()
fffffffffbc82e30 debug_enter+0x59(fffffffffb93d3d8)
fffffffffbc82f10 panicsys+0x600(fffffffffb93baf8, fffffffffbc7a9b0,
fffffffffbc82f20, 1)
fffffffffbc7a9a0 vpanic+0x15c()
fffffffffbc7aa10 param_preset()
fffffffffbc7aaa0 0xfffffffffb84a56c()
fffffffffbc7abb0 trap+0xa70(fffffffffbc7abc0, 0, 0)
fffffffffbc7abc0 0xfffffffffb8001d6()
fffffffffbc7acb0 xrdmsr+0xb()
fffffffffbc7ad70 workaround_errata+0x3c0(fffffffffbc397a0)
fffffffffbc7adb0 mlsetup+0x59e(fffffffffbc7adc8)
fffffffffbc7adc0 _locore_start+0x8b()



On 3/9/2017 3:53 PM, Dan McDonald wrote:
>> On Mar 9, 2017, at 3:46 PM, Michael Rasmussen <mir at miras.org> wrote:
>>
>> On Thu, 9 Mar 2017 11:18:17 -0500
>> Dan McDonald <danmcd at omniti.com> wrote:
>>
>>> Just updated it in place to new bits that invoke "kbd -s" prior to the menu's first display.  The new checksums for http://kebe.com/~danmcd/webrevs/r151021-kayak.iso are:
>>>
>>> md5 (r151021-kayak.iso) = 971cc094a6dc89666f76bc453e2ab13a
>>> sha1 (r151021-kayak.iso) = b72cb1dd08a09f5f9e491acc5aac8f25f852d000
>>> sha256 (r151021-kayak.iso) = 4350d227b28f65746bb361686bde05202d536e5137db07dbfee3d9611756a622
>>>
>> Hi Dan,
>>
>> Just tried this iso but disk discovery is weird. Can you explain this?
>> (see attached screenshot)
> Is this on a Xen install?  Prakash mentioned that there are "two paths, one device" problems on Xen.
>
> BTW, option #1 (based on diskinfo) works now, if you just want a whole-disk install.
>
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From vab at bb-c.de  Thu Mar  9 21:42:54 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Thu, 9 Mar 2017 22:42:54 +0100
Subject: [OmniOS-discuss] Bloody update on Repo,
	plus Kayak for ISO is almost beta
In-Reply-To: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
Message-ID: <22721.52318.11027.49651@urukhai.local>

Hi Dan!


> The still-in-testing ISO is here:
> 
> 	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso
> 
> Hashes are:
> 
> md5 (r151021-kayak.iso) = f875c1f102d7f242869f9afde2196aa4
> sha1 (r151021-kayak.iso) = a1b3ce074c40a4b8436c4dba02f08e0a29ba82d7
> sha256 (r151021-kayak.iso) = a3c65ef2dd3bd6f42fb6d36e9fac155f055e3495fe272dc5bc7c86fa3757fea2
> 
> Please share with the whole list how this goes.  I know there are still some
> systems that appear to not even get past loader, but with Prakash's
> explanation of how to disable apix, it may run better on Xen environments.

On a whim, I just downloaded the ISO via the hotel LAN and installed
it (MacBook Pro 13" Late 2016, macOS 10.12.3, Virtual Box 5.1.14).

Nice work!!  My first direct experience with the new loader.  Here are
some random observations:

- I like the "straight install to pool" option.  I have had this in my
  Kayak net installer for a long time but never sent the pull request.

- The keyboard selection did not work; I selected 18 for German but
  still got US.  This may well be due to VBox interfering; I usually
  don't use the console of my VMs but just ssh in.

- The disk selection screen had some lines with more than 80 columns,
  causing line wrap.  So it all looked a bit ragged.  Worked fine,
  though -- installed on a single 20GB VDI disk.

- After installation, I wanted to stop the VM so I could remove the
  boot DVD from the config.  So I told VBox to "send the shutdown
  signal".  This caused a message of "/usr/sbin/shutdown not found".
  Maybe you want to put that binary on the miniroot. :-)

Will do more tests as time permits.  All in all, looking very good.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From peter.tribble at gmail.com  Thu Mar  9 21:44:46 2017
From: peter.tribble at gmail.com (Peter Tribble)
Date: Thu, 9 Mar 2017 21:44:46 +0000
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
Message-ID: <CAEgYsbGadETPQ59C3jiGmUe75uC1wKD0tA2yJXcy+VbyzZp3dA@mail.gmail.com>

On Thu, Mar 9, 2017 at 8:28 PM, Dan McDonald <danmcd at omniti.com> wrote:

> Say hello:
>
>         http://kebe.com/~danmcd/webrevs/r151021-kayak.iso
>
> It now includes over this morning's major bump of "menu option #1":
>

That bit seems to work fine.


>         - Keyboard layout query at start time, like the old installer.
>

This doesn't appear to be carried through to the installed system.

The way illumos does this is a bit of a twisty maze that I ended
up digging into a while back:

http://ptribble.blogspot.co.uk/2015/02/how-illumos-sets-keyboard-type.html


>         - A fix so the boot archive at installation HAS its SHA-1 checksum
> in place
>
> The sums are:
>
> md5 (r151021-kayak.iso) = 3170424fecdf582f7014e1a253acc7d3
> sha1 (r151021-kayak.iso) = 29e8a2fc207b39617809867818197752de47dbe8
> sha256 (r151021-kayak.iso) = 9236d2ee76368ed30d3102402b968a
> c9b8ca59a7e17195a16f6ae417eba303e2
>
>
> Please try it, both on existing, known-to-work platforms, and continuing
> on to the newer ones like Xen or qemu, that had not worked in the past.
>
> Thank you!
> Dan
>
> p.s. If people are happy with this, I may officially cut over bloody media
> to use this revision of kayak-for-ISO once I can figure out the .usb-dd
> problem.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



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

From peter.tribble at gmail.com  Thu Mar  9 21:48:25 2017
From: peter.tribble at gmail.com (Peter Tribble)
Date: Thu, 9 Mar 2017 21:48:25 +0000
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <22721.52318.11027.49651@urukhai.local>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<22721.52318.11027.49651@urukhai.local>
Message-ID: <CAEgYsbGhZi1r0Y+wN9_zw4+wGVHkCnnL61KSzfj2vkCbLmr3YQ@mail.gmail.com>

> - After installation, I wanted to stop the VM so I could remove the
>   boot DVD from the config.  So I told VBox to "send the shutdown
>   signal".  This caused a message of "/usr/sbin/shutdown not found".
>   Maybe you want to put that binary on the miniroot. :-)
>

You should just be able to remove the iso at any time, the installer doesn't
hold it open.

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

From vab at bb-c.de  Thu Mar  9 21:52:41 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Thu, 9 Mar 2017 22:52:41 +0100
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <CAEgYsbGhZi1r0Y+wN9_zw4+wGVHkCnnL61KSzfj2vkCbLmr3YQ@mail.gmail.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<22721.52318.11027.49651@urukhai.local>
	<CAEgYsbGhZi1r0Y+wN9_zw4+wGVHkCnnL61KSzfj2vkCbLmr3YQ@mail.gmail.com>
Message-ID: <22721.52905.913557.921374@urukhai.local>

> > - After installation, I wanted to stop the VM so I could remove the
> >   boot DVD from the config.  So I told VBox to "send the shutdown
> >   signal".  This caused a message of "/usr/sbin/shutdown not found".
> >   Maybe you want to put that binary on the miniroot. :-)
> 
> You should just be able to remove the iso at any time, the installer doesn't
> hold it open.

Yes.  Probably just habit.  It's a throwaway VM anyway, so I'll try
that in the next round.

The point remains that a user could send a shutdown signal by choosing
the option in VBox, or pressing the physical power button, or whatever
other methods there might be.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From danmcd at omniti.com  Thu Mar  9 21:55:33 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 16:55:33 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <22721.52318.11027.49651@urukhai.local>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<22721.52318.11027.49651@urukhai.local>
Message-ID: <B0B36917-79B8-4AF2-9134-5C62176CB1DA@omniti.com>


> On Mar 9, 2017, at 4:42 PM, Volker A. Brandt <vab at bb-c.de> wrote:
> 
> Hi Dan!
> 

<SNIP!>

> 
> - I like the "straight install to pool" option.  I have had this in my
>  Kayak net installer for a long time but never sent the pull request.

You can only install it on a PRE-CONFIGURED rpool.  The idea is you enter shell first, create your pool, exit the shell, and then use option 2.  It's for people like me who dual-purpose SSDs for rpool, slog, and leave unallocated room for load-balancing.

> - The keyboard selection did not work; I selected 18 for German but
>  still got US.  This may well be due to VBox interfering; I usually
>  don't use the console of my VMs but just ssh in.

Did that ever work on the Caiman installer?  If it does, I may need more fixes in the build_iso.sh script I have.

> - The disk selection screen had some lines with more than 80 columns,
>  causing line wrap.  So it all looked a bit ragged.  Worked fine,
>  though -- installed on a single 20GB VDI disk.

It's SUPPOSED TO be > 80 columns and ragged. It's one reason you only get 7 disks at a time on a screen.

> - After installation, I wanted to stop the VM so I could remove the
>  boot DVD from the config.  So I told VBox to "send the shutdown
>  signal".  This caused a message of "/usr/sbin/shutdown not found".
>  Maybe you want to put that binary on the miniroot. :-)

I've had to bloat the original kayak miniroot a lot already.  You could use "init 0".  I could also include the hard-linked aliases to reboot:  "poweroff" and "halt". I think that would be easier.  To that end, I think I'll include poweroff and halt.

> Will do more tests as time permits.  All in all, looking very good.

Thanks,
Dan


From danmcd at omniti.com  Thu Mar  9 21:58:45 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 16:58:45 -0500
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <CAEgYsbGadETPQ59C3jiGmUe75uC1wKD0tA2yJXcy+VbyzZp3dA@mail.gmail.com>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
	<CAEgYsbGadETPQ59C3jiGmUe75uC1wKD0tA2yJXcy+VbyzZp3dA@mail.gmail.com>
Message-ID: <886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com>


> On Mar 9, 2017, at 4:44 PM, Peter Tribble <peter.tribble at gmail.com> wrote:
> 
> This doesn't appear to be carried through to the installed system.
<SNIP!>

Thanks for the blog post.

I'm going to be upstreaming the sources I've changed in https://github.com/omniti-labs/kayak/ very soon.  I think it may be useful for you to take a look at the beginning of kayak-menu.sh or rpool-install.sh to make this happen.

Thanks,
Dan


From mir at miras.org  Thu Mar  9 22:18:06 2017
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 9 Mar 2017 23:18:06 +0100
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <BA7E903A-AB0C-4882-B9D2-3175BA75FAAD@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
	<20170309220259.5b977199@sleipner.datanom.net>
	<BA7E903A-AB0C-4882-B9D2-3175BA75FAAD@omniti.com>
Message-ID: <20170309231806.2ebda4df@sleipner.datanom.net>

On Thu, 9 Mar 2017 16:20:07 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> If diskinfo showed a single disk, option 1's screen should've shown a single disk as well.  Why the difference?
> 
I have no idea.
> If you exit the shell (where diskinfo clearly showed something) and go back to option 1, what does it show now?
> 
I can confirm that choosing #1 shows no disks. If I then choose #3 and
runs diskinfo 1 disk is shown. exit #3 and then enters #1 again now
suddenly shows 1 disk. But again it only finds the last disk and not
all 3.


-- 
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:
Enzymes are things invented by biologists that explain things which
otherwise require harder thinking.
		-- Jerome Lettvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/2dc36382/attachment-0001.bin>

From danmcd at omniti.com  Thu Mar  9 22:19:43 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 17:19:43 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <20170309231806.2ebda4df@sleipner.datanom.net>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
	<20170309220259.5b977199@sleipner.datanom.net>
	<BA7E903A-AB0C-4882-B9D2-3175BA75FAAD@omniti.com>
	<20170309231806.2ebda4df@sleipner.datanom.net>
Message-ID: <BE388F43-6036-4BBB-9E3D-291C50EEEC7C@omniti.com>


> On Mar 9, 2017, at 5:18 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> I can confirm that choosing #1 shows no disks. If I then choose #3 and
> runs diskinfo 1 disk is shown. exit #3 and then enters #1 again now
> suddenly shows 1 disk. But again it only finds the last disk and not
> all 3.

I'll also bet you that diskinfo will show different output again when you enter the shell.

You may wish to raise this on the illumos developer's list.  If there are supposed to be three disks, then FMA topology isn't finding them for some reason.  if there are supposed to be one, it's that Prakash-reported case I mentioned earlier.

Thank you!
Dan


From mir at miras.org  Thu Mar  9 22:26:07 2017
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 9 Mar 2017 23:26:07 +0100
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <BE388F43-6036-4BBB-9E3D-291C50EEEC7C@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
	<20170309220259.5b977199@sleipner.datanom.net>
	<BA7E903A-AB0C-4882-B9D2-3175BA75FAAD@omniti.com>
	<20170309231806.2ebda4df@sleipner.datanom.net>
	<BE388F43-6036-4BBB-9E3D-291C50EEEC7C@omniti.com>
Message-ID: <20170309232607.42bc5207@sleipner.datanom.net>

On Thu, 9 Mar 2017 17:19:43 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> I'll also bet you that diskinfo will show different output again when you enter the shell.
> 
> You may wish to raise this on the illumos developer's list.  If there are supposed to be three disks, then FMA topology isn't finding them for some reason.  if there are supposed to be one, it's that Prakash-reported case I mentioned earlier.
> 
Just tried with new clean unformatted disks and then option #1 finds a
disk but again only one and again only the last disk. Using format
finds all disks as expected so clearly diskinfo is not working correct.

How, and where, should this be reported?

-- 
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:
No animal should ever jump on the dining room furniture unless
absolutely certain he can hold his own in conversation.
		-- Fran Lebowitz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/01d1b84a/attachment.bin>

From mir at miras.org  Thu Mar  9 22:35:47 2017
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 9 Mar 2017 23:35:47 +0100
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
	<CAEgYsbGadETPQ59C3jiGmUe75uC1wKD0tA2yJXcy+VbyzZp3dA@mail.gmail.com>
	<886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com>
Message-ID: <20170309233547.01b55bff@sleipner.datanom.net>

On Thu, 9 Mar 2017 16:58:45 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> I'm going to be upstreaming the sources I've changed in https://github.com/omniti-labs/kayak/ very soon.  I think it may be useful for you to take a look at the beginning of kayak-menu.sh or rpool-install.sh to make this happen.
> 
I feature request:
Given that diskinfo finds more than one disk under option #1 it would
be nice to be able to choose 2 disks to create a mirrored 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:
To fear love is to fear life, and those who fear life are already three
parts dead.
		-- Bertrand Russell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/17fc03ab/attachment.bin>

From danmcd at omniti.com  Thu Mar  9 22:39:13 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 17:39:13 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <20170309232607.42bc5207@sleipner.datanom.net>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
	<20170309220259.5b977199@sleipner.datanom.net>
	<BA7E903A-AB0C-4882-B9D2-3175BA75FAAD@omniti.com>
	<20170309231806.2ebda4df@sleipner.datanom.net>
	<BE388F43-6036-4BBB-9E3D-291C50EEEC7C@omniti.com>
	<20170309232607.42bc5207@sleipner.datanom.net>
Message-ID: <6A091B2E-9E69-4B27-A6B0-58128C557AE7@omniti.com>


> On Mar 9, 2017, at 5:26 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> How, and where, should this be reported?

Send a note to the illumos developer's list (developer at lists.illumos.org) with precise details about which qemu/kvmOmni you're using (on Linux? On *BSD?), and let them know.

You can also file a bug:


	https://illumos.org/issues/

Dan


From danmcd at omniti.com  Thu Mar  9 22:39:53 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 17:39:53 -0500
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <20170309233547.01b55bff@sleipner.datanom.net>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
	<CAEgYsbGadETPQ59C3jiGmUe75uC1wKD0tA2yJXcy+VbyzZp3dA@mail.gmail.com>
	<886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com>
	<20170309233547.01b55bff@sleipner.datanom.net>
Message-ID: <5BFA66C5-1982-42DA-8C6D-7728038A4640@omniti.com>


> On Mar 9, 2017, at 5:35 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Thu, 9 Mar 2017 16:58:45 -0500
> Dan McDonald <danmcd at omniti.com> wrote:
> 
>> 
>> I'm going to be upstreaming the sources I've changed in https://github.com/omniti-labs/kayak/ very soon.  I think it may be useful for you to take a look at the beginning of kayak-menu.sh or rpool-install.sh to make this happen.
>> 
> I feature request:
> Given that diskinfo finds more than one disk under option #1 it would
> be nice to be able to choose 2 disks to create a mirrored rpool.

That's how it works already!!!  :)

Dan


From danmcd at omniti.com  Thu Mar  9 22:43:18 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 17:43:18 -0500
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <5BFA66C5-1982-42DA-8C6D-7728038A4640@omniti.com>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
	<CAEgYsbGadETPQ59C3jiGmUe75uC1wKD0tA2yJXcy+VbyzZp3dA@mail.gmail.com>
	<886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com>
	<20170309233547.01b55bff@sleipner.datanom.net>
	<5BFA66C5-1982-42DA-8C6D-7728038A4640@omniti.com>
Message-ID: <F00CC176-1152-4EBC-8DAB-479AA4558098@omniti.com>


> On Mar 9, 2017, at 5:39 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Mar 9, 2017, at 5:35 PM, Michael Rasmussen <mir at miras.org> wrote:
>> 
>> On Thu, 9 Mar 2017 16:58:45 -0500
>> Dan McDonald <danmcd at omniti.com> wrote:
>> 
>>> 
>>> I'm going to be upstreaming the sources I've changed in https://github.com/omniti-labs/kayak/ very soon.  I think it may be useful for you to take a look at the beginning of kayak-menu.sh or rpool-install.sh to make this happen.
>>> 
>> I feature request:
>> Given that diskinfo finds more than one disk under option #1 it would
>> be nice to be able to choose 2 disks to create a mirrored rpool.
> 
> That's how it works already!!!  :)

SHOOT!  I guess it doesn't work like that.

I'll fix it, and update here.

Sorry,
Dan


From mir at miras.org  Thu Mar  9 22:43:58 2017
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 9 Mar 2017 23:43:58 +0100
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <5BFA66C5-1982-42DA-8C6D-7728038A4640@omniti.com>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
	<CAEgYsbGadETPQ59C3jiGmUe75uC1wKD0tA2yJXcy+VbyzZp3dA@mail.gmail.com>
	<886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com>
	<20170309233547.01b55bff@sleipner.datanom.net>
	<5BFA66C5-1982-42DA-8C6D-7728038A4640@omniti.com>
Message-ID: <20170309234358.134858ee@sleipner.datanom.net>

On Thu, 9 Mar 2017 17:39:53 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> That's how it works already!!!  :)
> 
Nice :-)

-- 
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:
When you dig another out of trouble, you've got a place to bury your
own.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/49506634/attachment-0001.bin>

From mir at miras.org  Thu Mar  9 22:50:01 2017
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 9 Mar 2017 23:50:01 +0100
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <6A091B2E-9E69-4B27-A6B0-58128C557AE7@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6359FB@XCH-MBX1.ipk-gatersleben.de>
	<49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC636D50@XCH-MBX1.ipk-gatersleben.de>
	<CF75EB0E-50CC-4EC3-817F-A7A8BBA48A96@omniti.com>
	<20170309214633.52905b34@sleipner.datanom.net>
	<268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com>
	<20170309220259.5b977199@sleipner.datanom.net>
	<BA7E903A-AB0C-4882-B9D2-3175BA75FAAD@omniti.com>
	<20170309231806.2ebda4df@sleipner.datanom.net>
	<BE388F43-6036-4BBB-9E3D-291C50EEEC7C@omniti.com>
	<20170309232607.42bc5207@sleipner.datanom.net>
	<6A091B2E-9E69-4B27-A6B0-58128C557AE7@omniti.com>
Message-ID: <20170309235001.60a66c97@sleipner.datanom.net>

On Thu, 9 Mar 2017 17:39:13 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> > On Mar 9, 2017, at 5:26 PM, Michael Rasmussen <mir at miras.org> wrote:
> > 
> > How, and where, should this be reported?  
> 
> Send a note to the illumos developer's list (developer at lists.illumos.org) with precise details about which qemu/kvmOmni you're using (on Linux? On *BSD?), and let them know.
> 
> You can also file a bug:
> 
> 
> 	https://illumos.org/issues/
> 
I will do that.

I have actually discovered that disk assignment is actually severely
broken since is seems no matter the number of disks shown in format it
is actually diskinfo which displays the current result since all disks
found by format is actually the same disk which is linked with every
reference:

2 disks:

c2t0d0 -
        |
        ----> c3t0d0
        |
c3t0d0 -

3 disks:

c2t0d0 -
        |
c3t0d0  ----> c4t0d0
        |
c4t0d0 -

So the correct number of disks is identified but all disks identified is linked to the same physical disk!!!


-- 
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:
When you dig another out of trouble, you've got a place to bury your
own.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/165c8b14/attachment.bin>

From danmcd at omniti.com  Thu Mar  9 22:55:06 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 17:55:06 -0500
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <F00CC176-1152-4EBC-8DAB-479AA4558098@omniti.com>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
	<CAEgYsbGadETPQ59C3jiGmUe75uC1wKD0tA2yJXcy+VbyzZp3dA@mail.gmail.com>
	<886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com>
	<20170309233547.01b55bff@sleipner.datanom.net>
	<5BFA66C5-1982-42DA-8C6D-7728038A4640@omniti.com>
	<F00CC176-1152-4EBC-8DAB-479AA4558098@omniti.com>
Message-ID: <329824C8-D5A8-4DAE-A42C-6FF81A858B34@omniti.com>


> On Mar 9, 2017, at 5:43 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> SHOOT!  I guess it doesn't work like that.
> 
> I'll fix it, and update here.

Strike that -- I think it was operator error on my part.

You can select multiple disk.  Here's a screenshot where I have:



See the top of the screen?

After I press '0' to proceed, you'll see some useful output:



The installer just created a mirrored rpool.  This was stuff Kayak for PXE did already.  I just refactored it slightly and called into it from the new interactive installer bits.

Sorry for the confusion,
Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/bad1563c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-09 at 5.52.32 PM.png
Type: image/png
Size: 53908 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/bad1563c/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-09 at 5.53.43 PM.png
Type: image/png
Size: 79713 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170309/bad1563c/attachment-0003.png>

From danmcd at omniti.com  Fri Mar 10 02:43:00 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 9 Mar 2017 21:43:00 -0500
Subject: [OmniOS-discuss] Kayak for ISO and USB now in Beta (with source to
	review)
Message-ID: <AA7E4A32-8847-4372-8932-8EF3D8542CB4@omniti.com>

Hello everyone!

Over the past few weeks I've been hammering on a problem:  What to do about installation in a Python2.7 and Loader world?  The existing OmniOS installer, a derivative of old OpenSolaris "caiman", managed the Python2.7 jump, but failed miserably in my efforts to tame it for Loader.  After my first year at OmniTI, I would joke about "ahh, we'll just wait until Kayak on ISO for that...".  Kayak is, of course, our PXE installer, that was brought up by Theo & Eric in the early days of OmniOS.

So I gave up on Caiman, and started down "Kayak for ISO".  It was suprisingly straightforward, if mildly annoying.  I've done some awful hacks to get this up and running, but it is a smooth enough experience for a user, and it allows faster media generation for an OmniOS release.  Please note it is still in Beta... I expect to hear from people as I have during the earlier trials.

First, the code.  For those who like webrevs vs. the current kayak repo:

	http://kebe.com/~danmcd/webrevs/kayak-iso/

For those who like git repos:

	https://github.com/danmcd/kayak-iso/

And finally, for those who just like media:

	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

	http://kebe.com/~danmcd/webrevs/r151021-kayak.usb-dd

Checksums:

md5 (r151021-kayak.iso) = 2469df1deec9a78ead797f66a3246cbe
sha1 (r151021-kayak.iso) = 9ec0dc1aa2db1b811ea654b723de052df2cde404
sha256 (r151021-kayak.iso) = c4f26268659dae6a9dd1ce3fd66804049478606f71cc6286735e4b8b3017f9ab
md5 (r151021-kayak.usb-dd) = 0e38778d78a993fcf9ed525e20fac6bf
sha1 (r151021-kayak.usb-dd) = 08552a9ba939fd1be69c2e40eea33fe3425095aa
sha256 (r151021-kayak.usb-dd) = c954f3b696d729865d7d41e5a395697d34c6487fd748a8060911f3af54e59dc5


That media will install the latest OmniOS bloody (omnios-master-650595c) straight with loader.

Highlights include:

- Ability to create mirrored rpools.

- Ability to let the user create a custom rpool, and then have the installer finish the job.

- No more pesky function keys.

- Any device diskinfo(1M) can see will show up on the installation menu, modulo some corner-cases below.

- Improved (but not full improvement) abilities not only for blkdev devices, but for virtualized environment installations.

Known issues:

- Some vioblk disks appear twice.  See Prakash Surya's earlier note on this list about it.

- The keyboard setting doesn't stick on the installed image.  You need to run "kbd -s" manually post-installation.

Please let me know what you think!

Thanks,
Dan


From skeltonr at btconnect.com  Fri Mar 10 10:23:45 2017
From: skeltonr at btconnect.com (Richard Skelton)
Date: Fri, 10 Mar 2017 10:23:45 +0000
Subject: [OmniOS-discuss] DTrace Scripts
In-Reply-To: <CAE9csxMsh7J-3aD2UT096T4_vhG2CN9KoP9FHqyFiKrwDrVR5A@mail.gmail.com>
References: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
	<CAE9csxMsh7J-3aD2UT096T4_vhG2CN9KoP9FHqyFiKrwDrVR5A@mail.gmail.com>
Message-ID: <58C27EB1.40505@btconnect.com>

Hi All,
I tried arc_stat.pl but it barfs :-

./arcstat.pl -f read,hits,miss,hit%,l2read,l2hits,l2miss,l2hit%,arcsz,l2size
read  hits  miss  hit%  l2read  l2hits  l2miss  l2hit%  arcsz  l2size
Use of uninitialized value in division (/) at ./arcstat.pl line 332.
   0     0     0     0       0       0       0       0   3.5G     14G

>From the blog

http://blog.harschsystems.com/tools/arcstat-pl-updated-for-l2arc-statistics/

Sounds just what I need :-)

Artem Penner wrote:
> May be links below will be helpful for you
>
> https://github.com/brendangregg/dtrace-cloud-tools
> https://github.com/richardelling/dtrace
> https://github.com/richardelling/arcstat
> https://bitbucket.org/d-helios/dtrace/src/7b479a97099f3146b4d08652315b03d1dfc28f9c/zfs/?at=master
>
>
>
>
>
> ??, 9 ???. 2017 ?. ? 21:08, John Barfield <john.barfield at bissinc.com
> <mailto:john.barfield at bissinc.com>>:
>
>     Im looking for some general dtrace scripts for debugging ZFS on
>     OmniOS (like updated dtrace toolkit)..didnt want to reinvent the
>     wheel if some folks are willing to share. Also willing to purchase
>     if needed.
>
>     John Barfield
>     _______________________________________________
>     OmniOS-discuss mailing list
>     OmniOS-discuss at lists.omniti.com
>     <mailto:OmniOS-discuss at lists.omniti.com>
>     http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170310/66ba64e9/attachment.html>

From apenner.it at gmail.com  Fri Mar 10 13:23:33 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Fri, 10 Mar 2017 13:23:33 +0000
Subject: [OmniOS-discuss] DTrace Scripts
In-Reply-To: <58C27EB1.40505@btconnect.com>
References: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
	<CAE9csxMsh7J-3aD2UT096T4_vhG2CN9KoP9FHqyFiKrwDrVR5A@mail.gmail.com>
	<58C27EB1.40505@btconnect.com>
Message-ID: <CAE9csxNoQHHTq4mWFK06r5QEOMa_MywiwiyAftVBzrkcpYsoeA@mail.gmail.com>

if you use omnios, install from package* system/monitoring/arcstat*

??, 10 ???. 2017 ?. ? 13:23, Richard Skelton <skeltonr at btconnect.com>:

> Hi All,
> I tried arc_stat.pl but it barfs :-
>
> ./arcstat.pl -f
> read,hits,miss,hit%,l2read,l2hits,l2miss,l2hit%,arcsz,l2size
> read  hits  miss  hit%  l2read  l2hits  l2miss  l2hit%  arcsz  l2size
> Use of uninitialized value in division (/) at ./arcstat.pl line 332.
>    0     0     0     0       0       0       0       0   3.5G     14G
>
> From the blog
>
> http://blog.harschsystems.com/tools/arcstat-pl-updated-for-l2arc-statistics/
>
> Sounds just what I need :-)
>
> Artem Penner wrote:
>
> May be links below will be helpful for you
>
> https://github.com/brendangregg/dtrace-cloud-tools
> https://github.com/richardelling/dtrace
> https://github.com/richardelling/arcstat
>
> https://bitbucket.org/d-helios/dtrace/src/7b479a97099f3146b4d08652315b03d1dfc28f9c/zfs/?at=master
>
>
>
>
>
> ??, 9 ???. 2017 ?. ? 21:08, John Barfield <john.barfield at bissinc.com>:
>
> Im looking for some general dtrace scripts for debugging ZFS on OmniOS
> (like updated dtrace toolkit)..didnt want to reinvent the wheel if some
> folks are willing to share. Also willing to purchase if needed.
>
> John Barfield
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
> _______________________________________________
> OmniOS-discuss mailing listOmniOS-discuss at lists.omniti.comhttp://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170310/41b9b802/attachment.html>

From lkateley at kateley.com  Fri Mar 10 15:44:59 2017
From: lkateley at kateley.com (Linda Kateley)
Date: Fri, 10 Mar 2017 09:44:59 -0600
Subject: [OmniOS-discuss] DTrace Scripts
In-Reply-To: <CAE9csxNoQHHTq4mWFK06r5QEOMa_MywiwiyAftVBzrkcpYsoeA@mail.gmail.com>
References: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
	<CAE9csxMsh7J-3aD2UT096T4_vhG2CN9KoP9FHqyFiKrwDrVR5A@mail.gmail.com>
	<58C27EB1.40505@btconnect.com>
	<CAE9csxNoQHHTq4mWFK06r5QEOMa_MywiwiyAftVBzrkcpYsoeA@mail.gmail.com>
Message-ID: <f49f8ea3-0f13-c0a2-16fd-a4e998a78ec3@kateley.com>

You also want to run it with an increment

#./arcstat.pl 1


On 3/10/17 7:23 AM, Artem Penner wrote:
> if you use omnios, install from package* system/monitoring/arcstat*
>
> ??, 10 ???. 2017 ?. ? 13:23, Richard Skelton <skeltonr at btconnect.com 
> <mailto:skeltonr at btconnect.com>>:
>
>     Hi All,
>     I tried arc_stat.pl <http://arc_stat.pl> but it barfs :-
>
>     ./arcstat.pl <http://arcstat.pl> -f
>     read,hits,miss,hit%,l2read,l2hits,l2miss,l2hit%,arcsz,l2size
>     read  hits  miss  hit%  l2read  l2hits  l2miss  l2hit% arcsz  l2size
>     Use of uninitialized value in division (/) at ./arcstat.pl
>     <http://arcstat.pl> line 332.
>        0     0     0     0       0       0       0       0 3.5G     14G
>
>     From the blog
>
>     http://blog.harschsystems.com/tools/arcstat-pl-updated-for-l2arc-statistics/
>
>     Sounds just what I need :-)
>
>     Artem Penner wrote:
>>     May be links below will be helpful for you
>>
>>     https://github.com/brendangregg/dtrace-cloud-tools
>>     https://github.com/richardelling/dtrace
>>     https://github.com/richardelling/arcstat
>>     https://bitbucket.org/d-helios/dtrace/src/7b479a97099f3146b4d08652315b03d1dfc28f9c/zfs/?at=master
>>
>>
>>
>>
>>
>>     ??, 9 ???. 2017 ?. ? 21:08, John Barfield
>>     <john.barfield at bissinc.com <mailto:john.barfield at bissinc.com>>:
>>
>>         Im looking for some general dtrace scripts for debugging ZFS
>>         on OmniOS (like updated dtrace toolkit)..didnt want to
>>         reinvent the wheel if some folks are willing to share. Also
>>         willing to purchase if needed.
>>
>>         John Barfield
>>         _______________________________________________
>>         OmniOS-discuss mailing list
>>         OmniOS-discuss at lists.omniti.com
>>         <mailto:OmniOS-discuss at lists.omniti.com>
>>         http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>     _______________________________________________
>>     OmniOS-discuss mailing list
>>     OmniOS-discuss at lists.omniti.com
>>     <mailto:OmniOS-discuss at lists.omniti.com>
>>     http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>        
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170310/47050d51/attachment-0001.html>

From bauernfeind at ipk-gatersleben.de  Fri Mar 10 15:46:02 2017
From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind)
Date: Fri, 10 Mar 2017 15:46:02 +0000
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <B0B36917-79B8-4AF2-9134-5C62176CB1DA@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<22721.52318.11027.49651@urukhai.local>
	<B0B36917-79B8-4AF2-9134-5C62176CB1DA@omniti.com>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC63709C@XCH-MBX1.ipk-gatersleben.de>

Hi Dan,

> - The keyboard selection did not work; I selected 18 for German but  
> still got US.  This may well be due to VBox interfering; I usually  
> don't use the console of my VMs but just ssh in.

-> Did that ever work on the Caiman installer?  If it does, I may need more
fixes in the build_iso.sh script I have.

As far as i remember, yes this selection worked.
I also get only US after selection, so I tried to setup the layout via the
SMF "keymap", but it complains its missing the loadkeys binary.

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

From vab at bb-c.de  Fri Mar 10 18:58:25 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Fri, 10 Mar 2017 19:58:25 +0100
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <B0B36917-79B8-4AF2-9134-5C62176CB1DA@omniti.com>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<22721.52318.11027.49651@urukhai.local>
	<B0B36917-79B8-4AF2-9134-5C62176CB1DA@omniti.com>
Message-ID: <22722.63313.951458.525306@gargle.gargle.HOWL>

Dan McDonald writes:
> > - I like the "straight install to pool" option.  I have had this in my
> >  Kayak net installer for a long time but never sent the pull request.
> 
> You can only install it on a PRE-CONFIGURED rpool.  The idea is you enter
> shell first, create your pool, exit the shell, and then use option 2.  It's
> for people like me who dual-purpose SSDs for rpool, slog, and leave
> unallocated room for load-balancing.

Yes, that's exactly how I do it, except that I have hacked my Kayak
PXE-based installation environment to accept a new option. :-)

> > - The keyboard selection did not work; I selected 18 for German but
> >  still got US.  This may well be due to VBox interfering; I usually
> >  don't use the console of my VMs but just ssh in.
> 
> Did that ever work on the Caiman installer?  If it does, I may need more
> fixes in the build_iso.sh script I have.

TBH I have never tried it, but am willing to do so on a real-metal
install RSN.

> > - The disk selection screen had some lines with more than 80 columns,
> >  causing line wrap.  So it all looked a bit ragged.  Worked fine,
> >  though -- installed on a single 20GB VDI disk.
> 
> It's SUPPOSED TO be > 80 columns and ragged. It's one reason you only get 7
> disks at a time on a screen.

Ah OK.  Some Linuxes switch their console into a different video mode
giving more than 80x25 -- maybe that is an option.

> > - After installation, I wanted to stop the VM so I could remove the
> >  boot DVD from the config.  So I told VBox to "send the shutdown
> >  signal".  This caused a message of "/usr/sbin/shutdown not found".
> >  Maybe you want to put that binary on the miniroot. :-)
> 
> I've had to bloat the original kayak miniroot a lot already.  You could use "init 0".  I could also include the hard-linked aliases to reboot:  "poweroff" and "halt". I think that would be easier.  To that end, I think I'll include poweroff and halt.

I guess I did not state my point properly.  I do know several ways to
gracefully stop a machine. :-)  My point was:  If someone for some
reason somehow generates the "shutdown" signal, there will be an ugly
error message.  You would need to include "/usr/sbin/shutdown" in the
miniroot, or fix the "powerfail" line in /etc/inittab.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From danmcd at omniti.com  Fri Mar 10 19:03:45 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 10 Mar 2017 14:03:45 -0500
Subject: [OmniOS-discuss] Bloody update on Repo,
 plus Kayak for ISO is almost beta
In-Reply-To: <22722.63313.951458.525306@gargle.gargle.HOWL>
References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com>
	<22721.52318.11027.49651@urukhai.local>
	<B0B36917-79B8-4AF2-9134-5C62176CB1DA@omniti.com>
	<22722.63313.951458.525306@gargle.gargle.HOWL>
Message-ID: <7CC87149-E7BF-4F64-8FFD-D7529227CA8F@omniti.com>

Thanks for the reminder...

> On Mar 10, 2017, at 1:58 PM, Volker A. Brandt <vab at bb-c.de> wrote:
> 
>>> - The keyboard selection did not work; I selected 18 for German but
>>> still got US.  This may well be due to VBox interfering; I usually
>>> don't use the console of my VMs but just ssh in.
>> 
>> Did that ever work on the Caiman installer?  If it does, I may need more
>> fixes in the build_iso.sh script I have.

... I'm working on the keyboard selection problem now.  Peter Tribble game me some good advice about eeprom, which I'm trying to take to heart.

Stay tuned!
Dan


From mir at miras.org  Sat Mar 11 15:13:05 2017
From: mir at miras.org (Michael Rasmussen)
Date: Sat, 11 Mar 2017 16:13:05 +0100
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
Message-ID: <20170311161305.12505147@sleipner.datanom.net>

On Thu, 9 Mar 2017 15:28:16 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> Please try it, both on existing, known-to-work platforms, and continuing on to the newer ones like Xen or qemu, that had not worked in the past.
> 
Hi Dan,

As you might have noticed from the illumos developer list the problem
with disk discovery was caused by a requirement for the kernel to have
unique id's assigned to disks. Maybe this should be mentioned somewhere
in the wiki? It might also solves problems regarding xen?

Apart from the above I have found another issue which might could be
solved more elegantly. Given disk(s) provided for install contains an
exported pool the disk(s) does not show up using #1. Maybe a notice to
the user should be given to either discard the pool and continue
selecting disks or import this pool and continue the install using this
pool as rpool. What do you think?


-- 
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 think, therefore I am... I think.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170311/61bb4dc8/attachment.bin>

From mir at miras.org  Sat Mar 11 15:26:39 2017
From: mir at miras.org (Michael Rasmussen)
Date: Sat, 11 Mar 2017 16:26:39 +0100
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
Message-ID: <20170311162639.41e78835@sleipner.datanom.net>

On Thu, 9 Mar 2017 15:28:16 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> Please try it, both on existing, known-to-work platforms, and continuing on to the newer ones like Xen or qemu, that had not worked in the past.
> 
Found another issue using #1:
Everything goes as expected until the time when image is supposed to be
transferred to the rpool - installation simply hangs. See screenshoot.

Increasing memory to 1 GB solves it so maybe add to wiki that memory
requirements is 1 GB.

-- 
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:
Q:	How many lawyers does it take to change a light bulb?
A:	One.  Only it's his light bulb when he's done.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot at 2017-03-11 16-14-16.png
Type: image/png
Size: 33135 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170311/1c55e029/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170311/1c55e029/attachment-0001.bin>

From danmcd at omniti.com  Sat Mar 11 22:07:31 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Sat, 11 Mar 2017 17:07:31 -0500
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <20170311161305.12505147@sleipner.datanom.net>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
	<20170311161305.12505147@sleipner.datanom.net>
Message-ID: <A5E7B9D1-A4F2-4905-8819-585BCCDD2577@omniti.com>


> On Mar 11, 2017, at 10:13 AM, Michael Rasmussen <mir at miras.org> wrote:
> 
> As you might have noticed from the illumos developer list the problem
> with disk discovery was caused by a requirement for the kernel to have
> unique id's assigned to disks. Maybe this should be mentioned somewhere
> in the wiki? It might also solves problems regarding xen?

Oh yes, part of the r151022 release notes at the very least.

As for not seeing the disks... that's odd, I'm pretty sure exported drives show up in my environments.

And for now, 1GB is required.  I may see how I can slim that down, however.

Dan


From richard.elling at richardelling.com  Sun Mar 12 01:08:21 2017
From: richard.elling at richardelling.com (Richard Elling)
Date: Sat, 11 Mar 2017 17:08:21 -0800
Subject: [OmniOS-discuss] DTrace Scripts
In-Reply-To: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
References: <F841A52C-4EEB-414D-87EF-1C534CC740D0@bissinc.com>
Message-ID: <9C3A12D5-AED3-4BAD-89A4-0E7E71D963C5@richardelling.com>


> On Mar 9, 2017, at 10:06 AM, John Barfield <john.barfield at bissinc.com> wrote:
> 
> Im looking for some general dtrace scripts for debugging ZFS on OmniOS (like updated dtrace toolkit)..didnt want to reinvent the wheel if some folks are willing to share. Also willing to purchase if needed.

Having written a number of these over the years, most are constructed to answer specific
questions. Those questions that we feel become routine, usually get converted to kstats,
which is a better method for long-term collection.

That said, I've got a few that are more generally useful when debugging some performance
issues. But they aren't documented, so a little work is required to get them documented.
 -- richard

> 
> John Barfield
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

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

From danmcd at omniti.com  Sun Mar 12 02:54:43 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Sat, 11 Mar 2017 21:54:43 -0500
Subject: [OmniOS-discuss] New media with new fixes!
Message-ID: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>

It's installing the same OmniOS revision, but the installer itself has two new fixes:

1.) The output from pv(1) doesn't scroll up anymore during the actual "zfs recv" operation.

2.) The keyboard layout selection takes effect for the installation AND it will be the one installed on the image itself.

The github commit for this change is here:

	https://github.com/danmcd/kayak-iso/commit/1de7422fd017dc1bac989a1625cf5bd0025a3e5b

And I've updated the media:

http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

md5 (r151021-kayak.iso) = 3a413aadb46fd9ac92fbbdf925fde798
sha1 (r151021-kayak.iso) = a3c46749116be20a520dcb2e43ed66cef20879c3
sha256 (r151021-kayak.iso) = b7604d1661c135f7e22813a0d0720e430b5cc5355915cdcd2003b92b581e3268


http://kebe..com/~danmcd/webrevs/r151021-kayak.usb-dd

md5 (r151021-kayak.usb-dd) = 6abe5e7ad5d428b839f0a53c466a933f
sha1 (r151021-kayak.usb-dd) = 6c424eb9d4a6ef9d771cd97193b0a0cc3a6cd8b4
sha256 (r151021-kayak.usb-dd) = 50e3ad1fbfa9c4c2651380092d9a9323b40754fcc581d9d40ba52c18b2cfc876



NOTE:  I will be unavailable all day Sunday, so pardon any latency if you all discover more weirdness.


Happy installing!
Dan


From mir at miras.org  Sun Mar 12 12:06:31 2017
From: mir at miras.org (Michael Rasmussen)
Date: Sun, 12 Mar 2017 13:06:31 +0100
Subject: [OmniOS-discuss] Kayak for ISO now at Beta
In-Reply-To: <A5E7B9D1-A4F2-4905-8819-585BCCDD2577@omniti.com>
References: <E38E2853-5E89-4E80-BECF-F1BD6BBD7257@omniti.com>
	<20170311161305.12505147@sleipner.datanom.net>
	<A5E7B9D1-A4F2-4905-8819-585BCCDD2577@omniti.com>
Message-ID: <20170312130631.05bf1b6b@sleipner.datanom.net>

On Sat, 11 Mar 2017 17:07:31 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> As for not seeing the disks... that's odd, I'm pretty sure exported drives show up in my environments.
> 
If I understand this explanation correct
(https://www.listbox.com/member/archive/182179/2017/03/sort/time_rev/page/1/entry/18:200/20170310150358:AFC98960-05CC-11E7-B128-CC58F01E9545/)
then it boils down to that libdiskmgmt will assign a devid to each disk
which in turn will all zeroes and apparently this confuses the kernel
since it seems that the kernel distinguishes one disk from another by
comparing devid's. Eg the physical disks are detected but since they
are given identical devid the kernel maps entries to the same disk.
This would also explains why diskinfo only displays one disk which is
the last disk. Diskinfo and format obviously sees disks from a
different perspective.

-- 
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:
He missed an invaluable opportunity to hold his tongue.
		-- Andrew Lang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170312/eec8dbb4/attachment.bin>

From mir at miras.org  Sun Mar 12 12:28:11 2017
From: mir at miras.org (Michael Rasmussen)
Date: Sun, 12 Mar 2017 13:28:11 +0100
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
Message-ID: <20170312132811.641770e8@sleipner.datanom.net>

On Sat, 11 Mar 2017 21:54:43 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> 
> 2.) The keyboard layout selection takes effect for the installation AND it will be the one installed on the image itself.
> 
No change here. Keyboard is still US even if Danish was selected.

-- 
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 handful of friends is worth more than a wagon of gold.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170312/02221995/attachment.bin>

From mir at miras.org  Sun Mar 12 12:36:14 2017
From: mir at miras.org (Michael Rasmussen)
Date: Sun, 12 Mar 2017 13:36:14 +0100
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <20170312132811.641770e8@sleipner.datanom.net>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<20170312132811.641770e8@sleipner.datanom.net>
Message-ID: <20170312133614.3034bb35@sleipner.datanom.net>

On Sun, 12 Mar 2017 13:28:11 +0100
Michael Rasmussen <mir at miras.org> wrote:

> On Sat, 11 Mar 2017 21:54:43 -0500
> Dan McDonald <danmcd at omniti.com> wrote:
> 
> > 
> > 2.) The keyboard layout selection takes effect for the installation AND it will be the one installed on the image itself.
> >   
> No change here. Keyboard is still US even if Danish was selected.
>
Why not simply have the installer configure the correct layout running
this svccfg -s keymap:default setprop keymap/layout = `layout` in the
BE?

-- 
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:
Ever feel like life was a game and you had the wrong instruction book?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170312/2e4fa74b/attachment-0001.bin>

From vab at bb-c.de  Sun Mar 12 17:05:20 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Sun, 12 Mar 2017 18:05:20 +0100
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
Message-ID: <22725.32720.129486.305014@shelob.bb-c.de>

Hi Dan!


> http://kebe..com/~danmcd/webrevs/r151021-kayak.usb-dd

Even after I remove the extra '.' I still get "forbidden".
Could you have a look?


Thanks -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From danmcd at omniti.com  Mon Mar 13 01:28:49 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Sun, 12 Mar 2017 21:28:49 -0400
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <22725.32720.129486.305014@shelob.bb-c.de>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<22725.32720.129486.305014@shelob.bb-c.de>
Message-ID: <70EDAA9B-0A6F-445A-9C65-62AAD7038C05@omniti.com>


> On Mar 12, 2017, at 1:05 PM, Volker A. Brandt <vab at bb-c.de> wrote:
> 
> Even after I remove the extra '.' I still get "forbidden".
> Could you have a look?

Fixed -- permission weirdness.

Dan


From danmcd at omniti.com  Mon Mar 13 02:16:28 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Sun, 12 Mar 2017 22:16:28 -0400
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <20170312133614.3034bb35@sleipner.datanom.net>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<20170312132811.641770e8@sleipner.datanom.net>
	<20170312133614.3034bb35@sleipner.datanom.net>
Message-ID: <9A490820-7FD2-41F7-98A4-D3E70BD6AD5C@omniti.com>


> On Mar 12, 2017, at 8:36 AM, Michael Rasmussen <mir at miras.org> wrote:
> 
> Why not simply have the installer configure the correct layout running
> this svccfg -s keymap:default setprop keymap/layout = `layout` in the
> BE?

Because there's no "-R <alt-root>" option.  Also, on a fresh install, the xml manifests are all imported for the first time.  The best way to make it stick is to alter the keymap.xml manifest.

As for this:

> No change here. Keyboard is still US even if Danish was selected.

Odd... my test environment showed a successful UK-English (vs. US-English) installation.  Let me try Danish...

...

... Aha!

You found a bug with the manifest-modifying setup in kayak-menu.sh.  I'm doing "grep <number>" not "grep -w <number>", so your Danish (layout 6) gets the first hit with '6' in it, Albanian.  Here's a fix:

bloody(~/ws/kayak-iso)[0]% git diff
diff --git a/kayak-menu.sh b/kayak-menu.sh
index 28fa6b3..22f949c 100755
--- a/kayak-menu.sh
+++ b/kayak-menu.sh
@@ -46,7 +46,7 @@ fi
 # Remember it post-installation scribbling into installed-image /etc/default/kbd
 ktype=`/usr/bin/kbd -l | grep type | awk -F= '{print $2}'`
 layout=`/usr/bin/kbd -l | grep layout | awk -F= '{print $2}' | awk '{print $1}'`
-klang=`grep $layout /usr/share/lib/keytables/type_$ktype/kbd_layouts | awk -F= '{print $1}'`
+klang=`grep -w $layout /usr/share/lib/keytables/type_$ktype/kbd_layouts | awk -F= '{print $1}'`
 
 # Define the menu of commands and prompts
 menu_items=( \
bloody(~/ws/kayak-iso)[0]% 

I'll respin the ISOs now...

... here, try these:

md5 (r151021-kayak.iso) = 2cb722cc88aacdcb57e5c33a8e190734
sha1 (r151021-kayak.iso) = 4c8c314160aeb71c9680f92e1456c3ad0bb03563
sha256 (r151021-kayak.iso) = ec6eb8c603a8667e1a4218e87844e322fc967b7c2dd3c40d4b308aef214075d7
md5 (r151021-kayak.usb-dd) = 0f69c7301b394727784bae73f3a477c1
sha1 (r151021-kayak.usb-dd) = 9847efab9a0a043624b4eef3c12c40d85e27b4ec
sha256 (r151021-kayak.usb-dd) = 84dd0a502bbd40b8d850c7a49d239a8be8b7644a40bf6c63d0b14c3eac5924c3


Good catch, and thank you!
Dan


From bauernfeind at ipk-gatersleben.de  Mon Mar 13 06:36:45 2017
From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind)
Date: Mon, 13 Mar 2017 06:36:45 +0000
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <9A490820-7FD2-41F7-98A4-D3E70BD6AD5C@omniti.com>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<20170312132811.641770e8@sleipner.datanom.net>
	<20170312133614.3034bb35@sleipner.datanom.net>
	<9A490820-7FD2-41F7-98A4-D3E70BD6AD5C@omniti.com>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC6372F7@XCH-MBX1.ipk-gatersleben.de>

Hi Dan,

thanks for the updated media.
The installed system now has the correct keyboard (german in my case).
But the install environment is still english (when i go to the shell [Point
3]).
When i invoke a "loadkeys" after I enter the shell, the correct layout is
loaded.

Jens

-----Original Message-----
From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On
Behalf Of Dan McDonald
Sent: Montag, 13. M?rz 2017 03:16
To: Michael Rasmussen <mir at miras.org>
Cc: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] New media with new fixes!


> On Mar 12, 2017, at 8:36 AM, Michael Rasmussen <mir at miras.org> wrote:
> 
> Why not simply have the installer configure the correct layout running 
> this svccfg -s keymap:default setprop keymap/layout = `layout` in the 
> BE?

Because there's no "-R <alt-root>" option.  Also, on a fresh install, the
xml manifests are all imported for the first time.  The best way to make it
stick is to alter the keymap.xml manifest.

As for this:

> No change here. Keyboard is still US even if Danish was selected.

Odd... my test environment showed a successful UK-English (vs. US-English)
installation.  Let me try Danish...

...

... Aha!

You found a bug with the manifest-modifying setup in kayak-menu.sh.  I'm
doing "grep <number>" not "grep -w <number>", so your Danish (layout 6) gets
the first hit with '6' in it, Albanian.  Here's a fix:

bloody(~/ws/kayak-iso)[0]% git diff
diff --git a/kayak-menu.sh b/kayak-menu.sh index 28fa6b3..22f949c 100755
--- a/kayak-menu.sh
+++ b/kayak-menu.sh
@@ -46,7 +46,7 @@ fi
 # Remember it post-installation scribbling into installed-image
/etc/default/kbd  ktype=`/usr/bin/kbd -l | grep type | awk -F= '{print $2}'`
layout=`/usr/bin/kbd -l | grep layout | awk -F= '{print $2}' | awk '{print
$1}'` -klang=`grep $layout /usr/share/lib/keytables/type_$ktype/kbd_layouts
| awk -F= '{print $1}'`
+klang=`grep -w $layout /usr/share/lib/keytables/type_$ktype/kbd_layouts 
+| awk -F= '{print $1}'`
 
 # Define the menu of commands and prompts  menu_items=( \
bloody(~/ws/kayak-iso)[0]% 

I'll respin the ISOs now...

... here, try these:

md5 (r151021-kayak.iso) = 2cb722cc88aacdcb57e5c33a8e190734
sha1 (r151021-kayak.iso) = 4c8c314160aeb71c9680f92e1456c3ad0bb03563
sha256 (r151021-kayak.iso) =
ec6eb8c603a8667e1a4218e87844e322fc967b7c2dd3c40d4b308aef214075d7
md5 (r151021-kayak.usb-dd) = 0f69c7301b394727784bae73f3a477c1
sha1 (r151021-kayak.usb-dd) = 9847efab9a0a043624b4eef3c12c40d85e27b4ec
sha256 (r151021-kayak.usb-dd) =
84dd0a502bbd40b8d850c7a49d239a8be8b7644a40bf6c63d0b14c3eac5924c3


Good catch, and thank you!
Dan

_______________________________________________
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: smime.p7s
Type: application/pkcs7-signature
Size: 6023 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170313/0976514d/attachment.bin>

From danmcd at omniti.com  Mon Mar 13 11:56:21 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 13 Mar 2017 07:56:21 -0400
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC6372F7@XCH-MBX1.ipk-gatersleben.de>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<20170312132811.641770e8@sleipner.datanom.net>
	<20170312133614.3034bb35@sleipner.datanom.net>
	<9A490820-7FD2-41F7-98A4-D3E70BD6AD5C@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6372F7@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <A5E09D6B-D54E-49B5-800C-2A7420EB1687@omniti.com>


> On Mar 13, 2017, at 2:36 AM, Jens Bauernfeind <bauernfeind at ipk-gatersleben.de> wrote:
> 
> Hi Dan,
> 
> thanks for the updated media.
> The installed system now has the correct keyboard (german in my case).
> But the install environment is still english (when i go to the shell [Point
> 3]).
> When i invoke a "loadkeys" after I enter the shell, the correct layout is
> loaded.

Okay.  Adding a "loadkeys" invocation after keyboard selection should do the trick:

 # Get the user's keyboard choice out of the way now.
 /usr/bin/kbd -s
+/usr/bin/loadkeys
 # Remember it post-installation scribbling into installed-image /etc/default/kbd

Thanks,
Dan


From danmcd at omniti.com  Mon Mar 13 14:09:10 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 13 Mar 2017 10:09:10 -0400
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <A5E09D6B-D54E-49B5-800C-2A7420EB1687@omniti.com>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<20170312132811.641770e8@sleipner.datanom.net>
	<20170312133614.3034bb35@sleipner.datanom.net>
	<9A490820-7FD2-41F7-98A4-D3E70BD6AD5C@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6372F7@XCH-MBX1.ipk-gatersleben.de>
	<A5E09D6B-D54E-49B5-800C-2A7420EB1687@omniti.com>
Message-ID: <2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com>


> On Mar 13, 2017, at 7:56 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> Okay.  Adding a "loadkeys" invocation after keyboard selection should do the trick:

Images with this fix are now also available:

md5 (r151021-kayak.iso) = c8a34acebfa91abdc7d77da695c17ec9
sha1 (r151021-kayak.iso) = 734bcaecbaaff661c98770b003933e4bdd8951e9
sha256 (r151021-kayak.iso) = c8b6e195f10e84cf00ac6e718b6226c691118e7db69f36c68987492520f151fd
md5 (r151021-kayak.usb-dd) = af03637ee28a42df1f0527a2bb64b872
sha1 (r151021-kayak.usb-dd) = 4f87ad1571a6e471c6a6bf652bb3da1e417deda3
sha256 (r151021-kayak.usb-dd) = 1678c6c13b10ec9935556adbe6461fee58a8018cf45ffcd618f729f1da74a3ee

Dan


From jeff at 1beyond.com  Mon Mar 13 20:05:02 2017
From: jeff at 1beyond.com (Jeff Berkembrock)
Date: Mon, 13 Mar 2017 16:05:02 -0400
Subject: [OmniOS-discuss] VMware tools for Omni
Message-ID: <CAEGbm67kYgpLuKO_8OGcE6d6FVOom3_1tE5Prgnk-nS-g=jW4w@mail.gmail.com>

Hello,

Has anyone had any success installing VMware tools on Omni r151020?

I'm trying to do so from a ESXi 6.5 host and an Omni r151020 guest that
runs within. This omni instance was loaded from the omniti ISO install media
<http://omnios.omniti.com/media/OmniOS_Text_r151020.iso>

root at omnitool:/root# uname -a
SunOS omnitool 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc

This link <https://omnios.omniti.com/wiki.php/VMwareNotes> refers to a VMware
KB
<https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023956>
article that explains how to perform the install. Unfortunately when I get
to step 4 (mounting the virtual DVD install media) I see the error below.

I'm seeing the same error with a Solaris 11.3 host.

It seems like VMware removed their installers for Solaris & related OS.


Call "VirtualMachine.MountToolsInstaller" for object "omni" on ESXi
"10.1.10.11" failed.
vix error code = 21001
Unable to install VMware Tools. An error occurred while trying to access
image file "/usr/lib/vmware/isoimages/solaris.iso" needed to install VMware
Tools: 2 (No such file or directory). Please refer the product
documentation or KB article 2129825 for details about how to get VMware
Tools package for this guest operating system.

Best Regards,

Jeff Berkembrock
www.1beyond.com
617-591-2200 x2212
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170313/6b949d7a/attachment.html>

From bauernfeind at ipk-gatersleben.de  Mon Mar 13 20:23:41 2017
From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind)
Date: Mon, 13 Mar 2017 20:23:41 +0000
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<20170312132811.641770e8@sleipner.datanom.net>
	<20170312133614.3034bb35@sleipner.datanom.net>
	<9A490820-7FD2-41F7-98A4-D3E70BD6AD5C@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6372F7@XCH-MBX1.ipk-gatersleben.de>
	<A5E09D6B-D54E-49B5-800C-2A7420EB1687@omniti.com>,
	<2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC6374CB@XCH-MBX1.ipk-gatersleben.de>

Hi,

it's working :-)

Jens
________________________________________
From: Dan McDonald [danmcd at omniti.com]
Sent: Monday, March 13, 2017 15:09
To: Jens Bauernfeind
Cc: omnios-discuss; Dan McDonald
Subject: Re: [OmniOS-discuss] New media with new fixes!

> On Mar 13, 2017, at 7:56 AM, Dan McDonald <danmcd at omniti.com> wrote:
>
> Okay.  Adding a "loadkeys" invocation after keyboard selection should do the trick:

Images with this fix are now also available:

md5 (r151021-kayak.iso) = c8a34acebfa91abdc7d77da695c17ec9
sha1 (r151021-kayak.iso) = 734bcaecbaaff661c98770b003933e4bdd8951e9
sha256 (r151021-kayak.iso) = c8b6e195f10e84cf00ac6e718b6226c691118e7db69f36c68987492520f151fd
md5 (r151021-kayak.usb-dd) = af03637ee28a42df1f0527a2bb64b872
sha1 (r151021-kayak.usb-dd) = 4f87ad1571a6e471c6a6bf652bb3da1e417deda3
sha256 (r151021-kayak.usb-dd) = 1678c6c13b10ec9935556adbe6461fee58a8018cf45ffcd618f729f1da74a3ee

Dan


From bauernfeind at ipk-gatersleben.de  Mon Mar 13 20:35:42 2017
From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind)
Date: Mon, 13 Mar 2017 20:35:42 +0000
Subject: [OmniOS-discuss] VMware tools for Omni
In-Reply-To: <CAEGbm67kYgpLuKO_8OGcE6d6FVOom3_1tE5Prgnk-nS-g=jW4w@mail.gmail.com>
References: <CAEGbm67kYgpLuKO_8OGcE6d6FVOom3_1tE5Prgnk-nS-g=jW4w@mail.gmail.com>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC6374E2@XCH-MBX1.ipk-gatersleben.de>

Hello,

Following the 6.5 Release Notes:
8<---
In ESXi 6.5, only a subset of VMware Tools ISO images are bundled with the ESXi 6.5 host.
8<---
windows and linux only, but you can download the tools for other OSes here:
https://my.vmware.com/group/vmware/details?downloadGroup=VMTOOLS1015&productId=614 (login needed)

You can either extract the solaris.iso and put it in the correct location (so enable esxi shell and scp it) or you extract the solaris.iso and transfer the contained tar.gz file directly in your VM

Jens
________________________________
From: OmniOS-discuss [omnios-discuss-bounces at lists.omniti.com] on behalf of Jeff Berkembrock [jeff at 1beyond.com]
Sent: Monday, March 13, 2017 21:05
To: OmniOS-discuss at lists.omniti.com
Subject: [OmniOS-discuss] VMware tools for Omni

Hello,

Has anyone had any success installing VMware tools on Omni r151020?

I'm trying to do so from a ESXi 6.5 host and an Omni r151020 guest that runs within. This omni instance was loaded from the omniti ISO install media<http://omnios.omniti.com/media/OmniOS_Text_r151020.iso>

root at omnitool:/root# uname -a
SunOS omnitool 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc

This link<https://omnios.omniti.com/wiki.php/VMwareNotes> refers to a VMware KB<https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023956> article that explains how to perform the install. Unfortunately when I get to step 4 (mounting the virtual DVD install media) I see the error below.

I'm seeing the same error with a Solaris 11.3 host.

It seems like VMware removed their installers for Solaris & related OS.


Call "VirtualMachine.MountToolsInstaller" for object "omni" on ESXi "10.1.10.11" failed.
vix error code = 21001
Unable to install VMware Tools. An error occurred while trying to access image file "/usr/lib/vmware/isoimages/solaris.iso" needed to install VMware Tools: 2 (No such file or directory). Please refer the product documentation or KB article 2129825 for details about how to get VMware Tools package for this guest operating system.

Best Regards,

Jeff Berkembrock
www.1beyond.com<http://www.1beyond.com/>
617-591-2200 x2212
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170313/d09bdc23/attachment.html>

From vab at bb-c.de  Mon Mar 13 20:52:34 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Mon, 13 Mar 2017 21:52:34 +0100
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC6374CB@XCH-MBX1.ipk-gatersleben.de>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<20170312132811.641770e8@sleipner.datanom.net>
	<20170312133614.3034bb35@sleipner.datanom.net>
	<9A490820-7FD2-41F7-98A4-D3E70BD6AD5C@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6372F7@XCH-MBX1.ipk-gatersleben.de>
	<A5E09D6B-D54E-49B5-800C-2A7420EB1687@omniti.com>
	<2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6374CB@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <22727.1682.51883.355266@shelob.bb-c.de>

Jens Bauernfeind writes:
> it's working :-)

Confirm.

> md5 (r151021-kayak.usb-dd) = af03637ee28a42df1f0527a2bb64b872

Tested this on a "metal" system (Sun Fire X2270 with a Sun Keyboard 
Type 6/USB).  Selected 18 == "German", dropped to shell after 
installation, keyboard layout German.  Rebooted, logged in as root,
keyboard layout still German. :-)

USB installation does take quite a bit longer than .iso in VirtualBox.

One thing that surprised me was that it would boot after hitting the
enter key in the "5 Boot options" menu.  That's very convenient, but
maybe a "hit return to boot straight away" info text could be added.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From danmcd at omniti.com  Mon Mar 13 20:57:55 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 13 Mar 2017 16:57:55 -0400
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <22727.1682.51883.355266@shelob.bb-c.de>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<20170312132811.641770e8@sleipner.datanom.net>
	<20170312133614.3034bb35@sleipner.datanom.net>
	<9A490820-7FD2-41F7-98A4-D3E70BD6AD5C@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6372F7@XCH-MBX1.ipk-gatersleben.de>
	<A5E09D6B-D54E-49B5-800C-2A7420EB1687@omniti.com>
	<2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6374CB@XCH-MBX1.ipk-gatersleben.de>
	<22727.1682.51883.355266@shelob.bb-c.de>
Message-ID: <D633ACBA-2D45-4A2A-8BB3-E86BBDD810C6@omniti.com>


> On Mar 13, 2017, at 4:52 PM, Volker A. Brandt <vab at bb-c.de> wrote:
> 
> 
> One thing that surprised me was that it would boot after hitting the
> enter key in the "5 Boot options" menu.  That's very convenient, but
> maybe a "hit return to boot straight away" info text could be added.

Wait... you mean option 5?  That is literally the same behavior as the old Caiman installer.  The only difference is that in the new Kayak-for-ISO, you don't reboot IMMEDIATELY after an installation, you can go back.  I did it this way on purpose, figuring people might want to manipulate their BE after installation.

Dan


From jeff at 1beyond.com  Mon Mar 13 21:54:58 2017
From: jeff at 1beyond.com (Jeff Berkembrock)
Date: Mon, 13 Mar 2017 17:54:58 -0400
Subject: [OmniOS-discuss] VMware tools for Omni
In-Reply-To: <B9D9271554C34B41866AA2801A8FD279AC6374E2@XCH-MBX1.ipk-gatersleben.de>
References: <CAEGbm67kYgpLuKO_8OGcE6d6FVOom3_1tE5Prgnk-nS-g=jW4w@mail.gmail.com>
	<B9D9271554C34B41866AA2801A8FD279AC6374E2@XCH-MBX1.ipk-gatersleben.de>
Message-ID: <CAEGbm6685zuwbXRtbcrQXdUDhHNzGjOZYyd6xEA_xD9iA=GVQQ@mail.gmail.com>

Hi Jens,

Thanks for this - the link you provided had the tools I needed.

Best Regards,

Jeff Berkembrock
www.1beyond.com
617-591-2200 x2212

On Mon, Mar 13, 2017 at 4:35 PM, Jens Bauernfeind <
bauernfeind at ipk-gatersleben.de> wrote:

> Hello,
>
> Following the 6.5 Release Notes:
> 8<---
> In ESXi 6.5, only a subset of VMware Tools ISO images are bundled with the
> ESXi 6.5 host.
> 8<---
> windows and linux only, but you can download the tools for other OSes here:
> https://my.vmware.com/group/vmware/details?downloadGroup=
> VMTOOLS1015&productId=614 (login needed)
>
> You can either extract the solaris.iso and put it in the correct location
> (so enable esxi shell and scp it) or you extract the solaris.iso and
> transfer the contained tar.gz file directly in your VM
>
> Jens
> ------------------------------
> *From:* OmniOS-discuss [omnios-discuss-bounces at lists.omniti.com] on
> behalf of Jeff Berkembrock [jeff at 1beyond.com]
> *Sent:* Monday, March 13, 2017 21:05
> *To:* OmniOS-discuss at lists.omniti.com
> *Subject:* [OmniOS-discuss] VMware tools for Omni
>
> Hello,
>
> Has anyone had any success installing VMware tools on Omni r151020?
>
> I'm trying to do so from a ESXi 6.5 host and an Omni r151020 guest that
> runs within. This omni instance was loaded from the omniti ISO install
> media <http://omnios.omniti.com/media/OmniOS_Text_r151020.iso>
>
> root at omnitool:/root# uname -a
> SunOS omnitool 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc
>
> This link <https://omnios.omniti.com/wiki.php/VMwareNotes> refers to a VMware
> KB
> <https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023956>
> article that explains how to perform the install. Unfortunately when I get
> to step 4 (mounting the virtual DVD install media) I see the error below.
>
> I'm seeing the same error with a Solaris 11.3 host.
>
> It seems like VMware removed their installers for Solaris & related OS.
>
>
> Call "VirtualMachine.MountToolsInstaller" for object "omni" on ESXi
> "10.1.10.11" failed.
> vix error code = 21001
> Unable to install VMware Tools. An error occurred while trying to access
> image file "/usr/lib/vmware/isoimages/solaris.iso" needed to install
> VMware Tools: 2 (No such file or directory). Please refer the product
> documentation or KB article 2129825 for details about how to get VMware
> Tools package for this guest operating system.
>
> Best Regards,
>
> Jeff Berkembrock
> www.1beyond.com
> 617-591-2200 x2212 <(617)%20591-2200>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170313/9e468968/attachment-0001.html>

From alka at hfg-gmuend.de  Mon Mar 13 21:55:36 2017
From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=)
Date: Mon, 13 Mar 2017 22:55:36 +0100
Subject: [OmniOS-discuss] VMware tools for Omni
In-Reply-To: <CAEGbm67kYgpLuKO_8OGcE6d6FVOom3_1tE5Prgnk-nS-g=jW4w@mail.gmail.com>
References: <CAEGbm67kYgpLuKO_8OGcE6d6FVOom3_1tE5Prgnk-nS-g=jW4w@mail.gmail.com>
Message-ID: <69bb948f-67bf-7321-8ddd-59fd7b22ed71@hfg-gmuend.de>

You can also use Open-VM Tools. They are in the OmniOS repo
http://pkg.omniti.com/omnios/r151020/en/search.shtml?token=vmware&action=Search

Gea

Am 13.03.2017 um 21:05 schrieb Jeff Berkembrock:
> Hello,
>
> Has anyone had any success installing VMware tools on Omni r151020?
>
> I'm trying to do so from a ESXi 6.5 host and an Omni r151020 guest 
> that runs within. This omni instance was loaded from the omniti ISO 
> install media <http://omnios.omniti.com/media/OmniOS_Text_r151020.iso>
>
> root at omnitool:/root# uname -a
> SunOS omnitool 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc
>
> This link <https://omnios.omniti.com/wiki.php/VMwareNotes> refers to a 
> VMware KB 
> <https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023956> 
> article that explains how to perform the install. Unfortunately when I 
> get to step 4 (mounting the virtual DVD install media) I see the error 
> below.
>
> I'm seeing the same error with a Solaris 11.3 host.
>
> It seems like VMware removed their installers for Solaris & related OS.
>
>
> Call "VirtualMachine.MountToolsInstaller" for object "omni" on ESXi 
> "10.1.10.11" failed.
> vix error code = 21001
> Unable to install VMware Tools. An error occurred while trying to 
> access image file "/usr/lib/vmware/isoimages/solaris.iso" needed to 
> install VMware Tools: 2 (No such file or directory). Please refer the 
> product documentation or KB article 2129825 for details about how to 
> get VMware Tools package for this guest operating system.
>
> Best Regards,
>
> Jeff Berkembrock
> www.1beyond.com <http://www.1beyond.com/>
> 617-591-2200 x2212
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


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

From vab at bb-c.de  Mon Mar 13 22:24:23 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Mon, 13 Mar 2017 23:24:23 +0100
Subject: [OmniOS-discuss] New media with new fixes!
In-Reply-To: <D633ACBA-2D45-4A2A-8BB3-E86BBDD810C6@omniti.com>
References: <3D07BFCF-1E4F-4361-95ED-EA0B4239437F@omniti.com>
	<20170312132811.641770e8@sleipner.datanom.net>
	<20170312133614.3034bb35@sleipner.datanom.net>
	<9A490820-7FD2-41F7-98A4-D3E70BD6AD5C@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6372F7@XCH-MBX1.ipk-gatersleben.de>
	<A5E09D6B-D54E-49B5-800C-2A7420EB1687@omniti.com>
	<2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC6374CB@XCH-MBX1.ipk-gatersleben.de>
	<22727.1682.51883.355266@shelob.bb-c.de>
	<D633ACBA-2D45-4A2A-8BB3-E86BBDD810C6@omniti.com>
Message-ID: <22727.7191.879654.22033@shelob.bb-c.de>

Dan McDonald writes:
> 
> > On Mar 13, 2017, at 4:52 PM, Volker A. Brandt <vab at bb-c.de> wrote:
> > 
> > 
> > One thing that surprised me was that it would boot after hitting the
> > enter key in the "5 Boot options" menu.  That's very convenient, but
> > maybe a "hit return to boot straight away" info text could be added.
> 
> Wait... you mean option 5?  That is literally the same behavior as the old
> Caiman installer.  The only difference is that in the new Kayak-for-ISO, you
> don't reboot IMMEDIATELY after an installation, you can go back.  I did it
> this way on purpose, figuring people might want to manipulate their BE after
> installation. 

Sorry, this was probably me not being clear enough again...

On the new loader screen before booting, there is a box of menu 
options.  1-4 are Boot Multi, Boot Single, Escape to loader, Reboot.

Option 5 is labelled "Configure Boot Options...".  Selecting it brings
me into a submenu.  It looks like I will have to go back to the "Main
Menu" to boot, but I really only need to press enter to boot.  I found
this only by hitting enter accidentally. :-)

In that same submenu, the console type and verbose boot are selectable.
However, the speed for a serial console isn't.  That's not too much of
a problem, but it would be nice.  I haven't managed to set up the
installed system with a proper BIOS-redirected console -- in GRUB, I 
would use -v -B console=ttya,ttya-mode="115200,8,n,1,-" on the kernel
line in the menu.  So I guess I need to start looking for the doc that
goes with the loader...

But all that doesn't have that much to do with kayak-for-iso, it's more
a question of configuring the new loader.  The installation itself went
absolutely fine.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From gearboxes at outlook.com  Tue Mar 14 23:12:33 2017
From: gearboxes at outlook.com (Machine Man)
Date: Tue, 14 Mar 2017 23:12:33 +0000
Subject: [OmniOS-discuss] stmfproxy ALUA RSF-1
In-Reply-To: <6CACA42B-A8CE-4A8D-9A35-83B5C758B877@omniti.com>
References: <CY4PR0101MB31609D1FEC9DC67CB1F2571EE72D0@CY4PR0101MB3160.prod.exchangelabs.com>,
	<6CACA42B-A8CE-4A8D-9A35-83B5C758B877@omniti.com>
Message-ID: <CY4PR0101MB316064A7713BE4F4260F5687E7240@CY4PR0101MB3160.prod.exchangelabs.com>

Sorry Dan I just realized that I hit replay and not replay to the mailing list.


I opened a support case with High Availability, they verified the cluster configuration and all checked out good. I was also told that the messages in my 1st message are to be expected.
They mentioned that they have been seeing issues with VMware 5.5U3 and up and its a VMware ALUA issue. I am not really finding anything out there as far as complaints around it being a VMware issue and was wondering if anyone else is using RSF-1 with VMware. (They are doing a force-lip on a workaround, but this is not doing anything in our case.)

With ALUA enabled its slow and when failing over connection to the LUN never returns. Disabling ALUA it works well, but a rescan is needed in VMware after the failover leaving us in the cold for unexpected failures when a failover is done triggered. This is a plus for scheduled maintenance Im just not sure for the price if its worth it.

We don't run critical systems on the OmniOS storage targets, but they are connected to VMware clusters that run business critical systems. Anyone that have dealt with an APD event in VMware would understand my concern here.

I would like to just mentioned that I just completed testing with windows and I have the exact same results, in fact it worse and it results in a hard boot for the windows machine.

Any feedback from anyone using RSF-1 with OmiOS will be appreciated.


________________________________
From: Dan McDonald <danmcd at omniti.com>
Sent: Monday, March 6, 2017 9:34:11 AM
To: Machine Man
Cc: omnios-discuss at lists.omniti.com; Dan McDonald
Subject: Re: [OmniOS-discuss] stmfproxy ALUA RSF-1


> On Mar 5, 2017, at 12:56 PM, Machine Man <gearboxes at outlook.com> wrote:
>
> I see the following on both nodes:
>
>  [ID 602194 daemon.warning] recv() call failed: 0
>  [ID 682322 daemon.warning] postMsg() no transport handle
>
> I am assuming this is related to my problem?

This is likely an RSF-1 problem. Have you checked with them about this yet?

Dan

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

From danmcd at omniti.com  Wed Mar 15 03:41:04 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 14 Mar 2017 23:41:04 -0400
Subject: [OmniOS-discuss] Bloody update: NOW WITH ISO & USB on the install
	page
Message-ID: <3921AB11-F4F1-4301-95B8-73F164BA7CCC@omniti.com>

I think Kayak-for-ISO is good enough now to start putting it on the OmniOS Installation page.  There is a stub for the new Kayak Interactive installer, which will be filled with more documentation and screen shots.

If you're already on bloody, please "pkg update (-r)" to the very latest:  omnios-master-e2435f2.

There are some new and exciting things in this update, and not just the Kayak-based new interactive installer.

* USB3.0/XHCI support is now in OmniOS, via illumos.  Thanks to Joyent for their efforts in getting this up.  There may still be some quirks or bugs, but they will be tiny and not kernel-panicking.  There's a specific set of Seagate drives that don't attach under USB3.0, for example, but that's being worked on.  You can now enable USB3.0 on your motherboards after you update to this release!!!

* Intel XXV710 25Gig Ethernet support in the i40e driver.

* /dev/full support.

* Overlooked previously, inotify and eventfd devices now will appear in lipkg and ipkg zones.

Please visit the https://omnios.omniti.com/wiki.php/Installation page to see the new bloody ISO and USB images.  This is still a bloody release, so things are in motion, and possibly not yet complete. This week I'll be regression-testing the PXE support for Kayak, to make sure I didn't break anything.  This is still a release under development, in spite of the surprisingly smooth jumps to BSD Loader, Python2.7, and now Kayak for ISO.

Thank you for your continuing use and feedback!
Dan


From omnios at citrus-it.net  Wed Mar 15 13:58:12 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Wed, 15 Mar 2017 13:58:12 +0000 (UTC)
Subject: [OmniOS-discuss] Loader serial console
Message-ID: <alpine.GSO.2.20.1703151355340.415683@erncre.pvgehf-vg.arg>


In case anyone else is experimenting with the new loaded in bloody and
uses a serial console (or serial redirection), this is what I've done to
my test server to continue using the serial console:

Create new file /boot/conf.d/serial and add:

boot_multicons="YES"
boot_serial="YES"
comconsole_speed="115200"
osconsole="ttya,text"
console="ttya,text"
ttya-mode="115200,8,n,1,-"


I'm not entirely sure if all of this is necessary - I borrowed some of
it from BSD tutorials - but it works for me.

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


From vab at bb-c.de  Wed Mar 15 14:26:20 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Wed, 15 Mar 2017 15:26:20 +0100
Subject: [OmniOS-discuss] Loader serial console
In-Reply-To: <alpine.GSO.2.20.1703151355340.415683@erncre.pvgehf-vg.arg>
References: <alpine.GSO.2.20.1703151355340.415683@erncre.pvgehf-vg.arg>
Message-ID: <22729.20236.967015.36054@shelob.bb-c.de>

Hi Andy!

> In case anyone else is experimenting with the new loaded in bloody and
> uses a serial console (or serial redirection), this is what I've done to
> my test server to continue using the serial console:
[...]

Thanks, this is very helpful!

> Create new file /boot/conf.d/serial and add:
> 
> boot_multicons="YES"
> boot_serial="YES"
> comconsole_speed="115200"
> osconsole="ttya,text"
> console="ttya,text"
> ttya-mode="115200,8,n,1,-"

Interesting.  Seems I was *almost* there in my test. :-)
 
> I'm not entirely sure if all of this is necessary - I borrowed some of
> it from BSD tutorials - but it works for me.

Good to know.  But you still needed the entries on the OS level, namely

setprop ttya-mode 115200,8,n,1,-
setprop console ttya

in /boot/solaris/bootenv.rc and the ttymon/label property in the
console-login SMF service.  Correct?


Viele Gr??e -- Volker A. Brandt
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From vab at bb-c.de  Wed Mar 15 21:56:09 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Wed, 15 Mar 2017 22:56:09 +0100
Subject: [OmniOS-discuss] Packaged ntp.conf in bloody breaks my local config
	pkg
Message-ID: <22729.47225.826646.769250@shelob.bb-c.de>

Hi Dan!


I see that you ship a preconfigured ntp.conf with bloody.  This is nice
because we instantly get a system with the correct time of day.

However, traditionally Solaris shipped only sample files, not an active
NTP configuration.  It was the duty of the local admin to provide one.
So you now break my local configuration package, which IPS refuses to
install because of duplicate file actions. :-(

Could you please add an "overlay=allow" to the file action for ntp.conf
in service/network/ntp?


Thanks -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From danmcd at omniti.com  Wed Mar 15 21:57:40 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 15 Mar 2017 17:57:40 -0400
Subject: [OmniOS-discuss] Packaged ntp.conf in bloody breaks my local
	config pkg
In-Reply-To: <22729.47225.826646.769250@shelob.bb-c.de>
References: <22729.47225.826646.769250@shelob.bb-c.de>
Message-ID: <FF8F5352-F057-4CEF-8E5E-9B72E49A0D86@omniti.com>


> On Mar 15, 2017, at 5:56 PM, Volker A. Brandt <vab at bb-c.de> wrote:
> 
> Could you please add an "overlay=allow" to the file action for ntp.conf
> in service/network/ntp?

I take pull requests...  :)

I'm in the middle of debugging a horrible discovery I made in bloody's kayak.  I'm going to be very slow in responding until I fix this bug.

FYI,
Dan


From vab at bb-c.de  Wed Mar 15 22:02:08 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Wed, 15 Mar 2017 23:02:08 +0100
Subject: [OmniOS-discuss] Packaged ntp.conf in bloody breaks my local
	config pkg
In-Reply-To: <FF8F5352-F057-4CEF-8E5E-9B72E49A0D86@omniti.com>
References: <22729.47225.826646.769250@shelob.bb-c.de>
	<FF8F5352-F057-4CEF-8E5E-9B72E49A0D86@omniti.com>
Message-ID: <22729.47584.458425.731396@shelob.bb-c.de>

Dan McDonald writes:
> 
> > On Mar 15, 2017, at 5:56 PM, Volker A. Brandt <vab at bb-c.de> wrote:
> > 
> > Could you please add an "overlay=allow" to the file action for ntp.conf
> > in service/network/ntp?
> 
> I take pull requests...  :)

Point taken.  One of these days I'll sit down and deal with the
abomination that is git.

> I'm in the middle of debugging a horrible discovery I made in bloody's
> kayak.  I'm going to be very slow in responding until I fix this bug. 

No prob.  Take your time.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From vab at bb-c.de  Wed Mar 15 22:12:58 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Wed, 15 Mar 2017 23:12:58 +0100
Subject: [OmniOS-discuss] Loader serial console
In-Reply-To: <22729.20236.967015.36054@shelob.bb-c.de>
References: <alpine.GSO.2.20.1703151355340.415683@erncre.pvgehf-vg.arg>
	<22729.20236.967015.36054@shelob.bb-c.de>
Message-ID: <22729.48234.48551.204448@shelob.bb-c.de>

Andy Fiddaman wrote: 
> > In case anyone else is experimenting with the new loaded in bloody and
> > uses a serial console (or serial redirection), this is what I've done to
> > my test server to continue using the serial console:
[...]

> > Create new file /boot/conf.d/serial and add:
> >
> > boot_multicons="YES"
> > boot_serial="YES"
> > comconsole_speed="115200"
> > osconsole="ttya,text"
> > console="ttya,text"
> > ttya-mode="115200,8,n,1,-"

Works great!  I added another file:

# cat /boot/conf.d/boot-args
boot-args="-v"

Now I have my familiar boot messages back. :-)


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From bfriesen at simple.dallas.tx.us  Wed Mar 15 22:22:07 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Wed, 15 Mar 2017 17:22:07 -0500 (CDT)
Subject: [OmniOS-discuss] Packaged ntp.conf in bloody breaks my local
 config pkg
In-Reply-To: <22729.47225.826646.769250@shelob.bb-c.de>
References: <22729.47225.826646.769250@shelob.bb-c.de>
Message-ID: <alpine.GSO.2.20.1703151719030.2142@scrappy.simplesystems.org>

On Wed, 15 Mar 2017, Volker A. Brandt wrote:

> I see that you ship a preconfigured ntp.conf with bloody.  This is nice
> because we instantly get a system with the correct time of day.

I don't think this is so nice.  Not all systems or zones are intended 
to access the Internet and sometimes additional network configuration 
is required.

Only the global zone should need to access the "Internet" or a server 
offering the IPS repository.

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

From vab at bb-c.de  Wed Mar 15 23:17:19 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Thu, 16 Mar 2017 00:17:19 +0100
Subject: [OmniOS-discuss] Packaged ntp.conf in bloody breaks my local
 config pkg
In-Reply-To: <alpine.GSO.2.20.1703151719030.2142@scrappy.simplesystems.org>
References: <22729.47225.826646.769250@shelob.bb-c.de>
	<alpine.GSO.2.20.1703151719030.2142@scrappy.simplesystems.org>
Message-ID: <22729.52095.799889.895036@shelob.bb-c.de>

Bob Friesenhahn writes:
> On Wed, 15 Mar 2017, Volker A. Brandt wrote:
> 
> > I see that you ship a preconfigured ntp.conf with bloody.  This is nice
> > because we instantly get a system with the correct time of day.
> 
> I don't think this is so nice.  Not all systems or zones are intended 
> to access the Internet and sometimes additional network configuration 
> is required.

You certainly have a point.  I didn't want to bash Dan, however. :-)
 
> Only the global zone should need to access the "Internet" or a server 
> offering the IPS repository.

Typically, the ntp package is only installed in the GZ.  The NTP daemon
will not be able run in a zone anyway unless you grant that right in the
NGZ configuration.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From bfriesen at simple.dallas.tx.us  Thu Mar 16 01:52:17 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Wed, 15 Mar 2017 20:52:17 -0500 (CDT)
Subject: [OmniOS-discuss] Packaged ntp.conf in bloody breaks my local
 config pkg
In-Reply-To: <22729.52095.799889.895036@shelob.bb-c.de>
References: <22729.47225.826646.769250@shelob.bb-c.de>
	<alpine.GSO.2.20.1703151719030.2142@scrappy.simplesystems.org>
	<22729.52095.799889.895036@shelob.bb-c.de>
Message-ID: <alpine.GSO.2.20.1703152046300.13280@freddy.simplesystems.org>

On Thu, 16 Mar 2017, Volker A. Brandt wrote:

> Bob Friesenhahn writes:
>> On Wed, 15 Mar 2017, Volker A. Brandt wrote:
>>
>>> I see that you ship a preconfigured ntp.conf with bloody.  This is nice
>>> because we instantly get a system with the correct time of day.
>>
>> I don't think this is so nice.  Not all systems or zones are intended
>> to access the Internet and sometimes additional network configuration
>> is required.
>
> You certainly have a point.  I didn't want to bash Dan, however. :-)

Of course.

While we are not bashing Dan (fan of Dan!), I would like to point out 
that 'routed' (svc:/network/routing/route:default) gets enabled by 
default.  Even though I explicitly disabled it (due to security 
concerns), it became re-enabled in my global zone and other zones, 
probably after system updates.  I have every unneeded service disabled 
in my Internet-facing zones but routed keeps coming back.

Not all networks require a RIP routing daemon.  It could cause harm.

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

From skeltonr at btconnect.com  Fri Mar 17 08:12:37 2017
From: skeltonr at btconnect.com (Richard Skelton)
Date: Fri, 17 Mar 2017 08:12:37 +0000
Subject: [OmniOS-discuss] arcstat ZFS question
Message-ID: <58CB9A75.2030907@btconnect.com>

Hi,
I am running OmniOS r151020 on an Intel S2600WTTR with two Intel(R)
Xeon(R) CPU E5-2640 v4 @ 2.40GHz CPU and 256GB of memory.
The zpool scratch is made up of 16 x 600GB 15K rpm SAS drives with a
DDRdrive as log and a 750GB INTEL-SSDPEDMD800G4 NVME card as cache.
When I run du I see a lot of L2misses from arcstat also the L2size seems
a lot bigger than the used size shown by zpool iostat scratch.
Why does du generate writes?
Is this normal?

Cheers
Richard

root at hosta:/scratch# du -sh *
201M    dir01
59G     dir02
136K    dir03
6.7G    dir04
1.4G    dir05
133K    dir06
726K    dir07
6.6G    dir08
268K    dir09
12G     dir10
146K    dir11
137M    dir12
29G     dir13
3.9G    dir14
83M     dir15
244M    dir16
201M    dir17
382K    dir18
242M    dir19
199M    dir20
405K    dir21
root at hosts:/scratch#

07:44:53     0     0     0     0       0       0       0       0  
118G    607G
07:45:03  3.4K  1.0K  2.4K    29    2.4K       0    2.4K       0  
118G    607G
07:45:13   41K   30K   10K    73     10K       0     10K       0  
119G    607G
07:45:23   40K   23K   17K    57     17K       0     17K       0  
119G    607G
    time  read  hits  miss  hit%  l2read  l2hits  l2miss  l2hit%  arcsz 
l2size
07:45:33   44K   21K   23K    48     23K       0     23K       0  
119G    607G
07:45:43   46K   28K   18K    59     18K       0     18K       0  
119G    607G
07:45:53   24K  7.2K   17K    29     17K       0     17K       0  
119G    607G
07:46:03     1     1     0    90       0       0       0       0  
119G    607G
07:46:13     0     0     0   100       0       0       0       0  
119G    607G

17 March 2017 07:46:16 GMT
                               capacity     operations    bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
scratch                      118G  3.07T      0      0      0      0
  mirror                    19.6G   524G      0      0      0      0
    c5t5000CCA018364819d0       -      -      0      0      0      0
    c6t5000CCA018355AF1d0       -      -      0      0      0      0
  mirror                    19.7G   524G      0      0      0      0
    c7t5000CCA018330A55d0       -      -      0      0      0      0
    c8t5000CCA0183561F5d0       -      -      0      0      0      0
  mirror                    19.7G   524G      0      0      0      0
    c9t5000CCA01832FA21d0       -      -      0      0      0      0
    c10t5000CCA018356271d0      -      -      0      0      0      0
  mirror                    19.5G   524G      0      0      0      0
    c11t5000CCA01830A3E1d0      -      -      0      0      0      0
    c12t5000CCA018331455d0      -      -      0      0      0      0
  mirror                    19.5G   524G      0      0      0      0
    c13t5000CCA018356211d0      -      -      0      0      0      0
    c14t5000CCA018339B1Dd0      -      -      0      0      0      0
  mirror                    19.6G   524G      0      0      0      0
    c15t5000CCA01837D171d0      -      -      0      0      0      0
    c16t5000CCA0387184FDd0      -      -      0      0      0      0
logs                            -      -      -      -      -      -
  c21t0d0                    128K  3.84G      0      0      0      0
cache                           -      -      -      -      -      -
  c17t1d0                    109G   636G      0    115      0   294K
--------------------------  -----  -----  -----  -----  -----  -----



From apenner.it at gmail.com  Fri Mar 17 08:44:10 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Fri, 17 Mar 2017 08:44:10 +0000
Subject: [OmniOS-discuss]  8TB Seagates under load = PANIC?
Message-ID: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>

Hi,
we have similar problem, we create pool in following configuration:
4 x Toshiba PX04SHB020 for zfs slog in mirror
2 x HGST HUSMH8040BSS204 for L2ARC
4 group in radz2(8D + 2P)

and when we perform crash test ( remove disks ), some times OmniOS going
into kernel panic:
[image: pasted1]

Any idias?

-------------------------------------------------
My configuration is:
*FILE: /etc/system*

* Disable cpu c-state
* Change scheduler frequency
set idle_cpu_prefer_mwait = 0
set idle_cpu_no_deep_c = 1
set hires_tick=1

* Scanning for iBFT may conflict with devices which use memory
* in 640-1024KB of physical address space. The iBFT
* specification suggests use of low RAM method - scanning
* physical memory 512-1024 KB for iBFT table.
* Disable low RAM method.
set ibft_noprobe=1

* SECURITY PARAMETERS
set noexec_user_stack=1
set noexec_user_stack_log=1

* IP / TCP Parameters
set ip:ip_squeue_fanout=1
set ndd:tcp_wscale_always = 1
set ndd:tstamp_if_wscale = 1
set ndd:tcp_max_buf = 166777216

* APIC
set pcplusmp:apic_panic_on_nmi=1
set apix:apic_panic_on_nmi=1

* Kernel DUMP
set dump_plat_mincpu=0
set dump_bzip2_level=1
set dump_metrics_on=1

* SATA
set sata:sata_auto_online=1

* SAS
set sd:sd_io_time=10

* Max open files by single process
set rlim_fd_max = 131072
set rlim_fd_cur = 65536

* Maximum size of physical I/O requests
set maxphys=1048576

**
*  NFS Tunning
**
set nfs:nfs_allow_preepoch_time = 1

* Maximum io threads. client.
set nfs:nfs3_max_threads = 256
set nfs:nfs4_max_threads = 256

* Read ahead operations by the NFS client.
set nfs:nfs3_nra = 32
set nfs:nfs4_nra = 32

* Logical block size used by the NFS client
set nfs:nfs3_bsize = 1048576
set nfs:nfs4_bsize = 1048576

* Controls the maximum size of the data portion of an NFS client
set nfs3:max_transfer_size = 1048576
set nfs4:max_transfer_size = 1048576

* Controls the mix of asynchronous requests that are generated by the NFS
version 4 client
set nfs:nfs4_async_clusters = 256

* RPC Tunning
* Sets the size of the kernel stack for kernel RPC service threads
set rpcmod:svc_default_stksize=0x6000

* Controls the size of the duplicate request cache that detects RPC
*   level retransmissions on connection oriented transports
set rpcmod:cotsmaxdupreqs = 4096

* Controls the size of the duplicate request cache that detect RPC
*   level retransmissions on connectionless transports
set rpcmod:maxdupreqs = 4096
* Controls the number of TCP connections that the NFS client uses when
communicating with each
*   NFS server. The kernel RPC is constructed so that it can multiplex RPCs
over a single connection
set rpcmod:clnt_max_conns = 8

* ZFS Tunning
set zfs:zfs_dirty_data_max = 0x300000000
set zfs:zfs_txg_timeout = 0xa
set zfs:zfs_dirty_data_sync = 0x200000000
set zfs:zfs_arc_max = 0x3480000000
set zfs:zfs_arc_shrink_shift=11
set zfs:l2arc_write_max = 0x9600000
set zfs:l2arc_write_boost = 0xC800000
set zfs:l2arc_headroom = 12
set zfs:l2arc_norw=0
set zfs:zfs_arc_shrink_shift=11

-----------------------------------------------------
*FILE: /kernel/drv/ixgbe.conf*
flow_control = 0;
tx_ring_size = 4096;
rx_ring_size = 4096;
tx_queue_number = 16;
rx_queue_number = 16;
rx_limit_per_intr = 1024;
tx_copy_threshold = 1024;
rx_copy_threshold = 512;
rx_group_number = 8;
mr_enable = 0;
intr_throttling = 0;

-----------------------------------------------------
sd-config-list from* /kernel/drv/sd.conf*
sd-config-list=
    "", "retries-timeout:1,retries-busy:1,retries-reset:1,retries-victim:2",
    "DELL    PERC H710", "cache-nonvolatile:true",
    "DELL    PERC H700", "cache-nonvolatile:true",
    "DELL    PERC/6i", "cache-nonvolatile:true",
    "ATA     Samsung SSD 830", "physical-block-size:4096",
    "ATA     Samsung SSD 840", "physical-block-size:4096",
    "ATA     Samsung SSD 850", "physical-block-size:4096",
    "HGST    HUH721008AL4204", "physical-block-size:4096",
    "HGST    HUH721010AL5204", "physical-block-size:4096",
    "HGST    HUH721008AL5204", "physical-block-size:4096",
    "HGST    HUH721010AL4204", "physical-block-size:4096",
    "HGST    HUH728080AL4204", "physical-block-size:4096",
    "HGST    HUH728060AL4204", "physical-block-size:4096",
    "HGST    HUH728080AL5204", "physical-block-size:4096",
    "HGST    HUH728060AL5204", "physical-block-size:4096",
    "HGST    HUS724030ALS640", "physical-block-size:4096",
    "HGST    HMH7210A0AL4604", "physical-block-size:4096",
    "HGST    HUS726060AL4214", "physical-block-size:4096",
    "HGST    HUS726050AL4214", "physical-block-size:4096",
    "HGST    HUS726040AL4214", "physical-block-size:4096",
    "HGST    HUS726020AL4214", "physical-block-size:4096",
    "HGST    HUS726060AL5214", "physical-block-size:4096",
    "HGST    HUS726050AL5214", "physical-block-size:4096",
    "HGST    HUS726040AL5214", "physical-block-size:4096",
    "HGST    HUS726020AL5214", "physical-block-size:4096",
    "HGST    HUS726060ALS214", "physical-block-size:4096",
    "HGST    HUS726050ALS214", "physical-block-size:4096",
    "HGST    HUS726040ALS214", "physical-block-size:4096",
    "HGST    HUS726020ALS214", "physical-block-size:4096",
    "HGST    HUC101818CS4204", "physical-block-size:4096",
    "HGST    HUC101812CS4204", "physical-block-size:4096",
    "HGST    HUC101890CS4204", "physical-block-size:4096",
    "HGST    HUC101860CS4204", "physical-block-size:4096",
    "HGST    HUC101845CS4204", "physical-block-size:4096",
    "HGST    HUC156060CS4204", "physical-block-size:4096",
    "HGST    HUC156045CS4204", "physical-block-size:4096",
    "HGST    HUC156030CS4204", "physical-block-size:4096",
    "HGST    HUSMH8010BSS204",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "HGST    HUSMH8020BSS204",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "HGST    HUSMH8040BSS204",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "HGST    HUSMH8080BSS204",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "HGST    HUSMM1616ASS204",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "HGST    HUSMM1680ASS204",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "HGST    HUSMM1640ASS204",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "HGST    HUSMM1620ASS204",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "TOSHIBA PX04SHB160",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "TOSHIBA PX04SHB080",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "TOSHIBA PX04SHB040",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
    "TOSHIBA PX04SHB020",
"throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096";

-----------------------------------------------------
scsi-vhci-failover-override from */kernel/drv/scsi_vhci.conf*
scsi-vhci-failover-override =
        "HGST    HUS724030ALS640",      "f_sym",
        "HGST    HUSMH8010BSS204",      "f_sym",
        "HGST    HUSMH8020BSS204",      "f_sym",
        "HGST    HUSMH8040BSS204",      "f_sym",
        "HGST    HUSMH8080BSS204",      "f_sym",
        "HGST    HUSMM1616ASS204",      "f_sym",
        "HGST    HUSMM1680ASS204",      "f_sym",
        "HGST    HUSMM1640ASS204",      "f_sym",
        "HGST    HUSMM1620ASS204",      "f_sym",
        "HGST    HUH721008AL4204",      "f_sym",
        "HGST    HUH721010AL5204",      "f_sym",
        "HGST    HUH721008AL5204",      "f_sym",
        "HGST    HUH721010AL4204",      "f_sym",
        "HGST    HUH728080AL4204",      "f_sym",
        "HGST    HUH728060AL4204",      "f_sym",
        "HGST    HUH728080AL5204",      "f_sym",
        "HGST    HUH728060AL5204",      "f_sym",
        "HGST    HMH7210A0AL4604",      "f_sym",
        "HGST    HUS726060AL4214",      "f_sym",
        "HGST    HUS726050AL4214",      "f_sym",
        "HGST    HUS726040AL4214",      "f_sym",
        "HGST    HUS726020AL4214",      "f_sym",
        "HGST    HUS726060AL5214",      "f_sym",
        "HGST    HUS726050AL5214",      "f_sym",
        "HGST    HUS726040AL5214",      "f_sym",
        "HGST    HUS726020AL5214",      "f_sym",
        "HGST    HUS726060ALS214",      "f_sym",
        "HGST    HUS726050ALS214",      "f_sym",
        "HGST    HUS726040ALS214",      "f_sym",
        "HGST    HUS726020ALS214",      "f_sym",
        "HGST    HUC101818CS4204",      "f_sym",
        "HGST    HUC101812CS4204",      "f_sym",
        "HGST    HUC101890CS4204",      "f_sym",
        "HGST    HUC101860CS4204",      "f_sym",
        "HGST    HUC101845CS4204",      "f_sym",
        "HGST    HUC156060CS4204",      "f_sym",
        "HGST    HUC156045CS4204",      "f_sym",
        "HGST    HUC156030CS4204",      "f_sym",
        "TOSHIBA PX04SHB160",           "f_sym",
        "TOSHIBA PX04SHB080",           "f_sym",
        "TOSHIBA PX04SHB040",           "f_sym",
        "TOSHIBA PX04SHB020",           "f_sym";
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/9ac189fc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted1
Type: image/png
Size: 310722 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/9ac189fc/attachment-0001.png>

From apenner.it at gmail.com  Fri Mar 17 11:14:57 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Fri, 17 Mar 2017 11:14:57 +0000
Subject: [OmniOS-discuss] 8TB Seagates under load = PANIC?
In-Reply-To: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
References: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
Message-ID: <CAE9csxM8ZC5Y1aY_=zit6iBnNKM9pH0RnUbGB4gNekhzjPtwJg@mail.gmail.com>

After reboot pool is ONLINE state and it continue data resilvering

root at zns2-n2:/root# zpool status pool5
  pool: pool5
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Fri Mar 17 02:04:45 2017
    213G scanned out of 5.15T at 42.4M/s, 33h55m to go
    7.15G resilvered, 4.04% done
config:

        NAME                         STATE     READ WRITE CKSUM
        pool5                        ONLINE       0     0     0
          raidz2-0                   ONLINE       0     0     0
            c9t5000CCA031039F18d0    ONLINE       0     0     0
            c9t5000CCA03103A054d0    ONLINE       0     0     0
            c9t5000CCA031048B88d0    ONLINE       0     0     0
            c9t5000CCA031039E80d0    ONLINE       0     0     0
            c9t5000CCA031048C18d0    ONLINE       0     0     0
            c9t5000CCA031039F50d0    ONLINE       0     0     0
            c9t5000CCA03104AA40d0    ONLINE       0     0     0
            c9t5000CCA03104AD44d0    ONLINE       0     0     0
            c9t5000CCA03103B274d0    ONLINE       0     0     0
            c9t5000CCA03103B2C8d0    ONLINE       0     0     0
          raidz2-1                   ONLINE       0     0     0
            c9t5000CCA03103B34Cd0    ONLINE       0     0     0
            c9t5000CCA03104AE18d0    ONLINE       0     0     0
            c9t5000CCA03104AE54d0    ONLINE       0     0     0
            spare-3                  ONLINE       0     0     0
              c9t5000CCA03103B2D4d0  ONLINE       0     0     0
              c9t5000CCA03104AD84d0  ONLINE       0     0     0
 (resilvering)
            c9t5000CCA03103B26Cd0    ONLINE       0     0     0
            c9t5000CCA03103B3ACd0    ONLINE       0     0     0
            c9t5000CCA03103B338d0    ONLINE       0     0     0
            c9t5000CCA03104DFACd0    ONLINE       0     0     0
            c9t5000CCA03104ABA8d0    ONLINE       0     0     0
            c9t5000CCA03103A10Cd0    ONLINE       0     0     0
          raidz2-2                   ONLINE       0     0     0
            c9t5000CCA02C413D04d0    ONLINE       0     0     0
            c9t5000CCA03104D40Cd0    ONLINE       0     0     0
            c9t5000CCA03104D7A8d0    ONLINE       0     0     0
            c9t5000CCA03104D768d0    ONLINE       0     0     0
            c9t5000CCA031046494d0    ONLINE       0     0     0
            c9t5000CCA03104D458d0    ONLINE       0     0     0
            c9t5000CCA03104D408d0    ONLINE       0     0     0
            c9t5000CCA03104D798d0    ONLINE       0     0     0
            c9t5000CCA03103D28Cd0    ONLINE       0     0     0
            c9t5000CCA031047A30d0    ONLINE       0     0     0
          raidz2-3                   ONLINE       0     0     0
            spare-0                  ONLINE       0     0     0
              c9t5000CCA03104D2ECd0  ONLINE       0     0     0
              c9t5000CCA02C414524d0  ONLINE       0     0     0
 (resilvering)
            c9t5000CCA03104D370d0    ONLINE       0     0     0
            c9t5000CCA031038248d0    ONLINE       0     0     0
            c9t5000CCA03104D448d0    ONLINE       0     0     0
            c9t5000CCA03104D81Cd0    ONLINE       0     0     0
            c9t5000CCA031038470d0    ONLINE       0     0     0
            c9t5000CCA03104D400d0    ONLINE       0     0     0
            c9t5000CCA03104D330d0    ONLINE       0     0     0
            c9t5000CCA03104D7F8d0    ONLINE       0     0     0
            c9t5000CCA031046C68d0    ONLINE       0     0     0
        logs
          mirror-4                   ONLINE       0     0     0
            c9t500003979C88FF91d0    ONLINE       0     0     0
            c9t500003973C88B6F5d0    ONLINE       0     0     0
          mirror-5                   ONLINE       0     0     0
            c9t500003979C88FF5Dd0    ONLINE       0     0     0
            c9t500003979C890019d0    ONLINE       0     0     0
        cache
          c9t5000CCA04B12952Cd0      ONLINE       0     0     0
          c9t5000CCA04B12A1D0d0      ONLINE       0     0     0
        spares
          c9t5000CCA03104AD84d0      INUSE     currently in use
          c9t5000CCA02C414524d0      INUSE     currently in use

errors: No known data errors

But filesystem pool5/fs1, which I used for *performance / crash*
testing is *not
available *

root at zns2-n2:/root# zfs list pool5/fs1
NAME        USED  AVAIL  REFER  MOUNTPOINT
pool5/fs1  3.90T  44.1T  3.90T  /pool5/fs1

root at zns2-n2:/root# zfs mount pool5/fs1
cannot mount 'pool5/fs1': mountpoint or dataset is busy
root at zns2-n2:/root# zfs umount pool5/fs1
cannot unmount 'pool5/fs1': not currently mounted

root at zns2-n2:/root# df -h
Filesystem                      Size  Used Avail Use% Mounted on
/usr/lib/libc/libc_hwcap1.so.1  470G  2.8G  467G   1% /lib/libc.so.1
swap                            225G  272K  225G   1% /etc/svc/volatile
swap                            225G     0  225G   0% /tmp
swap                            225G   24K  225G   1% /var/run
rpool/export                    467G   96K  467G   1% /export
rpool/export/home               467G   96K  467G   1% /export/home
pool5                            45T  220K   45T   1% /pool5




??, 17 ???. 2017 ?. ? 11:44, Artem Penner <apenner.it at gmail.com>:

> Hi,
> we have similar problem, we create pool in following configuration:
> 4 x Toshiba PX04SHB020 for zfs slog in mirror
> 2 x HGST HUSMH8040BSS204 for L2ARC
> 4 group in radz2(8D + 2P)
>
> and when we perform crash test ( remove disks ), some times OmniOS going
> into kernel panic:
> [image: pasted1]
>
> Any idias?
>
> -------------------------------------------------
> My configuration is:
> *FILE: /etc/system*
>
> * Disable cpu c-state
> * Change scheduler frequency
> set idle_cpu_prefer_mwait = 0
> set idle_cpu_no_deep_c = 1
> set hires_tick=1
>
> * Scanning for iBFT may conflict with devices which use memory
> * in 640-1024KB of physical address space. The iBFT
> * specification suggests use of low RAM method - scanning
> * physical memory 512-1024 KB for iBFT table.
> * Disable low RAM method.
> set ibft_noprobe=1
>
> * SECURITY PARAMETERS
> set noexec_user_stack=1
> set noexec_user_stack_log=1
>
> * IP / TCP Parameters
> set ip:ip_squeue_fanout=1
> set ndd:tcp_wscale_always = 1
> set ndd:tstamp_if_wscale = 1
> set ndd:tcp_max_buf = 166777216
>
> * APIC
> set pcplusmp:apic_panic_on_nmi=1
> set apix:apic_panic_on_nmi=1
>
> * Kernel DUMP
> set dump_plat_mincpu=0
> set dump_bzip2_level=1
> set dump_metrics_on=1
>
> * SATA
> set sata:sata_auto_online=1
>
> * SAS
> set sd:sd_io_time=10
>
> * Max open files by single process
> set rlim_fd_max = 131072
> set rlim_fd_cur = 65536
>
> * Maximum size of physical I/O requests
> set maxphys=1048576
>
> **
> *  NFS Tunning
> **
> set nfs:nfs_allow_preepoch_time = 1
>
> * Maximum io threads. client.
> set nfs:nfs3_max_threads = 256
> set nfs:nfs4_max_threads = 256
>
> * Read ahead operations by the NFS client.
> set nfs:nfs3_nra = 32
> set nfs:nfs4_nra = 32
>
> * Logical block size used by the NFS client
> set nfs:nfs3_bsize = 1048576
> set nfs:nfs4_bsize = 1048576
>
> * Controls the maximum size of the data portion of an NFS client
> set nfs3:max_transfer_size = 1048576
> set nfs4:max_transfer_size = 1048576
>
> * Controls the mix of asynchronous requests that are generated by the NFS
> version 4 client
> set nfs:nfs4_async_clusters = 256
>
> * RPC Tunning
> * Sets the size of the kernel stack for kernel RPC service threads
> set rpcmod:svc_default_stksize=0x6000
>
> * Controls the size of the duplicate request cache that detects RPC
> *   level retransmissions on connection oriented transports
> set rpcmod:cotsmaxdupreqs = 4096
>
> * Controls the size of the duplicate request cache that detect RPC
> *   level retransmissions on connectionless transports
> set rpcmod:maxdupreqs = 4096
> * Controls the number of TCP connections that the NFS client uses when
> communicating with each
> *   NFS server. The kernel RPC is constructed so that it can multiplex
> RPCs over a single connection
> set rpcmod:clnt_max_conns = 8
>
> * ZFS Tunning
> set zfs:zfs_dirty_data_max = 0x300000000
> set zfs:zfs_txg_timeout = 0xa
> set zfs:zfs_dirty_data_sync = 0x200000000
> set zfs:zfs_arc_max = 0x3480000000
> set zfs:zfs_arc_shrink_shift=11
> set zfs:l2arc_write_max = 0x9600000
> set zfs:l2arc_write_boost = 0xC800000
> set zfs:l2arc_headroom = 12
> set zfs:l2arc_norw=0
> set zfs:zfs_arc_shrink_shift=11
>
> -----------------------------------------------------
> *FILE: /kernel/drv/ixgbe.conf*
> flow_control = 0;
> tx_ring_size = 4096;
> rx_ring_size = 4096;
> tx_queue_number = 16;
> rx_queue_number = 16;
> rx_limit_per_intr = 1024;
> tx_copy_threshold = 1024;
> rx_copy_threshold = 512;
> rx_group_number = 8;
> mr_enable = 0;
> intr_throttling = 0;
>
> -----------------------------------------------------
> sd-config-list from* /kernel/drv/sd.conf*
> sd-config-list=
>     "",
> "retries-timeout:1,retries-busy:1,retries-reset:1,retries-victim:2",
>     "DELL    PERC H710", "cache-nonvolatile:true",
>     "DELL    PERC H700", "cache-nonvolatile:true",
>     "DELL    PERC/6i", "cache-nonvolatile:true",
>     "ATA     Samsung SSD 830", "physical-block-size:4096",
>     "ATA     Samsung SSD 840", "physical-block-size:4096",
>     "ATA     Samsung SSD 850", "physical-block-size:4096",
>     "HGST    HUH721008AL4204", "physical-block-size:4096",
>     "HGST    HUH721010AL5204", "physical-block-size:4096",
>     "HGST    HUH721008AL5204", "physical-block-size:4096",
>     "HGST    HUH721010AL4204", "physical-block-size:4096",
>     "HGST    HUH728080AL4204", "physical-block-size:4096",
>     "HGST    HUH728060AL4204", "physical-block-size:4096",
>     "HGST    HUH728080AL5204", "physical-block-size:4096",
>     "HGST    HUH728060AL5204", "physical-block-size:4096",
>     "HGST    HUS724030ALS640", "physical-block-size:4096",
>     "HGST    HMH7210A0AL4604", "physical-block-size:4096",
>     "HGST    HUS726060AL4214", "physical-block-size:4096",
>     "HGST    HUS726050AL4214", "physical-block-size:4096",
>     "HGST    HUS726040AL4214", "physical-block-size:4096",
>     "HGST    HUS726020AL4214", "physical-block-size:4096",
>     "HGST    HUS726060AL5214", "physical-block-size:4096",
>     "HGST    HUS726050AL5214", "physical-block-size:4096",
>     "HGST    HUS726040AL5214", "physical-block-size:4096",
>     "HGST    HUS726020AL5214", "physical-block-size:4096",
>     "HGST    HUS726060ALS214", "physical-block-size:4096",
>     "HGST    HUS726050ALS214", "physical-block-size:4096",
>     "HGST    HUS726040ALS214", "physical-block-size:4096",
>     "HGST    HUS726020ALS214", "physical-block-size:4096",
>     "HGST    HUC101818CS4204", "physical-block-size:4096",
>     "HGST    HUC101812CS4204", "physical-block-size:4096",
>     "HGST    HUC101890CS4204", "physical-block-size:4096",
>     "HGST    HUC101860CS4204", "physical-block-size:4096",
>     "HGST    HUC101845CS4204", "physical-block-size:4096",
>     "HGST    HUC156060CS4204", "physical-block-size:4096",
>     "HGST    HUC156045CS4204", "physical-block-size:4096",
>     "HGST    HUC156030CS4204", "physical-block-size:4096",
>     "HGST    HUSMH8010BSS204",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "HGST    HUSMH8020BSS204",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "HGST    HUSMH8040BSS204",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "HGST    HUSMH8080BSS204",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "HGST    HUSMM1616ASS204",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "HGST    HUSMM1680ASS204",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "HGST    HUSMM1640ASS204",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "HGST    HUSMM1620ASS204",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "TOSHIBA PX04SHB160",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "TOSHIBA PX04SHB080",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "TOSHIBA PX04SHB040",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096",
>     "TOSHIBA PX04SHB020",
> "throttle-max:32,disksort:false,cache-nonvolatile:true,power-condition:false,physical-block-size:4096";
>
> -----------------------------------------------------
> scsi-vhci-failover-override from */kernel/drv/scsi_vhci.conf*
> scsi-vhci-failover-override =
>         "HGST    HUS724030ALS640",      "f_sym",
>         "HGST    HUSMH8010BSS204",      "f_sym",
>         "HGST    HUSMH8020BSS204",      "f_sym",
>         "HGST    HUSMH8040BSS204",      "f_sym",
>         "HGST    HUSMH8080BSS204",      "f_sym",
>         "HGST    HUSMM1616ASS204",      "f_sym",
>         "HGST    HUSMM1680ASS204",      "f_sym",
>         "HGST    HUSMM1640ASS204",      "f_sym",
>         "HGST    HUSMM1620ASS204",      "f_sym",
>         "HGST    HUH721008AL4204",      "f_sym",
>         "HGST    HUH721010AL5204",      "f_sym",
>         "HGST    HUH721008AL5204",      "f_sym",
>         "HGST    HUH721010AL4204",      "f_sym",
>         "HGST    HUH728080AL4204",      "f_sym",
>         "HGST    HUH728060AL4204",      "f_sym",
>         "HGST    HUH728080AL5204",      "f_sym",
>         "HGST    HUH728060AL5204",      "f_sym",
>         "HGST    HMH7210A0AL4604",      "f_sym",
>         "HGST    HUS726060AL4214",      "f_sym",
>         "HGST    HUS726050AL4214",      "f_sym",
>         "HGST    HUS726040AL4214",      "f_sym",
>         "HGST    HUS726020AL4214",      "f_sym",
>         "HGST    HUS726060AL5214",      "f_sym",
>         "HGST    HUS726050AL5214",      "f_sym",
>         "HGST    HUS726040AL5214",      "f_sym",
>         "HGST    HUS726020AL5214",      "f_sym",
>         "HGST    HUS726060ALS214",      "f_sym",
>         "HGST    HUS726050ALS214",      "f_sym",
>         "HGST    HUS726040ALS214",      "f_sym",
>         "HGST    HUS726020ALS214",      "f_sym",
>         "HGST    HUC101818CS4204",      "f_sym",
>         "HGST    HUC101812CS4204",      "f_sym",
>         "HGST    HUC101890CS4204",      "f_sym",
>         "HGST    HUC101860CS4204",      "f_sym",
>         "HGST    HUC101845CS4204",      "f_sym",
>         "HGST    HUC156060CS4204",      "f_sym",
>         "HGST    HUC156045CS4204",      "f_sym",
>         "HGST    HUC156030CS4204",      "f_sym",
>         "TOSHIBA PX04SHB160",           "f_sym",
>         "TOSHIBA PX04SHB080",           "f_sym",
>         "TOSHIBA PX04SHB040",           "f_sym",
>         "TOSHIBA PX04SHB020",           "f_sym";
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/5ae7f858/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted1
Type: image/png
Size: 310722 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/5ae7f858/attachment-0001.png>

From danmcd at omniti.com  Fri Mar 17 12:41:14 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 17 Mar 2017 08:41:14 -0400
Subject: [OmniOS-discuss] arcstat ZFS question
In-Reply-To: <58CB9A75.2030907@btconnect.com>
References: <58CB9A75.2030907@btconnect.com>
Message-ID: <2564F2CB-C602-42EA-8A16-CA54A45088C6@omniti.com>


> On Mar 17, 2017, at 4:12 AM, Richard Skelton <skeltonr at btconnect.com> wrote:
> 
> Why does du generate writes?
> Is this normal?

If you've L2ARC, it'd make sense that du (a program that traverses tons of directories if not more to find out how many blocks and/or bytes each file holds) would change the usage patterns AND that it would get cached in your L2ARC device.  Caches are written when usage patterns change.

So yes, it's expected behavior:  caches change based on usage patterns, and "du -sh *" changes your usage to "read every directory".

Hope this helps,
Dan


From danmcd at omniti.com  Fri Mar 17 12:48:41 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 17 Mar 2017 08:48:41 -0400
Subject: [OmniOS-discuss] 8TB Seagates under load = PANIC?
In-Reply-To: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
References: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
Message-ID: <E3D54E6F-CE9E-46D3-BAE2-F89933105CB2@omniti.com>


> On Mar 17, 2017, at 4:44 AM, Artem Penner <apenner.it at gmail.com> wrote:
> 
> we have similar problem, we create pool in following configuration: 
> 

All that configuration data you provided, and you didn't provide "uname -a" (and possibly "cat /etc/release" for an older version).

I'd like to know, because this is a older, but apparently not fixed, bug:

	https://illumos.org/issues/4454

I do not know whether or not it's been fixed recently under a different bug report, so it's critical I know what OmniOS revision you're running.

Meanwhile, I'll link your archived note into the bug report and ping the ZFSers again.  PLEASE report to me the version of OmniOS you're running.

Thanks,
Dan


From danmcd at omniti.com  Fri Mar 17 12:52:17 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 17 Mar 2017 08:52:17 -0400
Subject: [OmniOS-discuss] 8TB Seagates under load = PANIC?
In-Reply-To: <CAE9csxM8ZC5Y1aY_=zit6iBnNKM9pH0RnUbGB4gNekhzjPtwJg@mail.gmail.com>
References: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
	<CAE9csxM8ZC5Y1aY_=zit6iBnNKM9pH0RnUbGB4gNekhzjPtwJg@mail.gmail.com>
Message-ID: <F3723586-7557-4531-91F5-24766B66FB68@omniti.com>


> On Mar 17, 2017, at 7:14 AM, Artem Penner <apenner.it at gmail.com> wrote:
> 
> root at zns2-n2:/root# zfs list pool5/fs1
> NAME        USED  AVAIL  REFER  MOUNTPOINT
> pool5/fs1  3.90T  44.1T  3.90T  /pool5/fs1
> 
> root at zns2-n2:/root# zfs mount pool5/fs1
> cannot mount 'pool5/fs1': mountpoint or dataset is busy
> root at zns2-n2:/root# zfs umount pool5/fs1
> cannot unmount 'pool5/fs1': not currently mounted

What's pool5/fs1's actual mount point?  ("zfs get mountpoint pool5/fs1")?  Does that directory contain something?  I'd quiesce any process that writes there, and make sure it didn't race to write there while you were mounting pool5/fs1.

Dan


From apenner.it at gmail.com  Fri Mar 17 12:59:39 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Fri, 17 Mar 2017 12:59:39 +0000
Subject: [OmniOS-discuss] 8TB Seagates under load = PANIC?
In-Reply-To: <E3D54E6F-CE9E-46D3-BAE2-F89933105CB2@omniti.com>
References: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
	<E3D54E6F-CE9E-46D3-BAE2-F89933105CB2@omniti.com>
Message-ID: <CAE9csxMSzZFKNXhbaB2M=ikfwu1HYdORYKQaYiGyhmsKgid6mg@mail.gmail.com>

root at zns2-n2:/root# cat /etc/release
  OmniOS v11 r151014
  Copyright 2015 OmniTI Computer Consulting, Inc. All rights reserved.
  Use is subject to license terms.

root at zns2-n2:/root# pkg info entire
          Name: entire
       Summary: Incorporation to constrain core system packages to same
build
   Description: This package constrains core system package versions to the
same
                build and provides a minimal set of additional packages.
         State: Installed
     Publisher: omnios
       Version: 11
        Branch: 0.151014
Packaging Date: Thu Oct 27 17:29:55 2016
          Size: 1.41 kB
          FMRI: pkg://omnios/entire at 11-0.151014:20161027T172955Z

root at zns2-n2:/root# uname -a
SunOS zns2-n2 5.11 omnios-2fb9a48 i86pc i386 i86pc


In attach all files that been modified manually, also zpool status command
output.

I'll try to reproduce panic in close time.


??, 17 ???. 2017 ?. ? 15:48, Dan McDonald <danmcd at omniti.com>:

>
> > On Mar 17, 2017, at 4:44 AM, Artem Penner <apenner.it at gmail.com> wrote:
> >
> > we have similar problem, we create pool in following configuration:
> >
>
> All that configuration data you provided, and you didn't provide "uname
> -a" (and possibly "cat /etc/release" for an older version).
>
> I'd like to know, because this is a older, but apparently not fixed, bug:
>
>         https://illumos.org/issues/4454
>
> I do not know whether or not it's been fixed recently under a different
> bug report, so it's critical I know what OmniOS revision you're running.
>
> Meanwhile, I'll link your archived note into the bug report and ping the
> ZFSers again.  PLEASE report to me the version of OmniOS you're running.
>
> Thanks,
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/6fcd6d8e/attachment-0001.html>
-------------- next part --------------
root at zns2-n2:/root# zpool status pool5
  pool: pool5
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Fri Mar 17 02:04:45 2017
    489G scanned out of 5.15T at 41.2M/s, 33h1m to go
    16.3G resilvered, 9.26% done
config:

        NAME                         STATE     READ WRITE CKSUM
        pool5                        ONLINE       0     0     0
          raidz2-0                   ONLINE       0     0     0
            c9t5000CCA031039F18d0    ONLINE       0     0     0
            c9t5000CCA03103A054d0    ONLINE       0     0     0
            c9t5000CCA031048B88d0    ONLINE       0     0     0
            c9t5000CCA031039E80d0    ONLINE       0     0     0
            c9t5000CCA031048C18d0    ONLINE       0     0     0
            c9t5000CCA031039F50d0    ONLINE       0     0     0
            c9t5000CCA03104AA40d0    ONLINE       0     0     0
            c9t5000CCA03104AD44d0    ONLINE       0     0     0
            c9t5000CCA03103B274d0    ONLINE       0     0     0
            c9t5000CCA03103B2C8d0    ONLINE       0     0     0
          raidz2-1                   ONLINE       0     0     0
            c9t5000CCA03103B34Cd0    ONLINE       0     0     0
            c9t5000CCA03104AE18d0    ONLINE       0     0     0
            c9t5000CCA03104AE54d0    ONLINE       0     0     0
            spare-3                  ONLINE       0     0     0
              c9t5000CCA03103B2D4d0  ONLINE       0     0     0
              c9t5000CCA03104AD84d0  ONLINE       0     0     0  (resilvering)
            c9t5000CCA03103B26Cd0    ONLINE       0     0     0
            c9t5000CCA03103B3ACd0    ONLINE       0     0     0
            c9t5000CCA03103B338d0    ONLINE       0     0     0
            c9t5000CCA03104DFACd0    ONLINE       0     0     0
            c9t5000CCA03104ABA8d0    ONLINE       0     0     0
            c9t5000CCA03103A10Cd0    ONLINE       0     0     0
          raidz2-2                   ONLINE       0     0     0
            c9t5000CCA02C413D04d0    ONLINE       0     0     0
            c9t5000CCA03104D40Cd0    ONLINE       0     0     0
            c9t5000CCA03104D7A8d0    ONLINE       0     0     0
            c9t5000CCA03104D768d0    ONLINE       0     0     0
            c9t5000CCA031046494d0    ONLINE       0     0     0
            c9t5000CCA03104D458d0    ONLINE       0     0     0
            c9t5000CCA03104D408d0    ONLINE       0     0     0
            c9t5000CCA03104D798d0    ONLINE       0     0     0
            c9t5000CCA03103D28Cd0    ONLINE       0     0     0
            c9t5000CCA031047A30d0    ONLINE       0     0     0
          raidz2-3                   ONLINE       0     0     0
            spare-0                  ONLINE       0     0     0
              c9t5000CCA03104D2ECd0  ONLINE       0     0     0
              c9t5000CCA02C414524d0  ONLINE       0     0     0  (resilvering)
            c9t5000CCA03104D370d0    ONLINE       0     0     0
            c9t5000CCA031038248d0    ONLINE       0     0     0
            c9t5000CCA03104D448d0    ONLINE       0     0     0
            c9t5000CCA03104D81Cd0    ONLINE       0     0     0
            c9t5000CCA031038470d0    ONLINE       0     0     0
            c9t5000CCA03104D400d0    ONLINE       0     0     0
            c9t5000CCA03104D330d0    ONLINE       0     0     0
            c9t5000CCA03104D7F8d0    ONLINE       0     0     0
            c9t5000CCA031046C68d0    ONLINE       0     0     0
        logs
          mirror-4                   ONLINE       0     0     0
            c9t500003979C88FF91d0    ONLINE       0     0     0
            c9t500003973C88B6F5d0    ONLINE       0     0     0
          mirror-5                   ONLINE       0     0     0
            c9t500003979C88FF5Dd0    ONLINE       0     0     0
            c9t500003979C890019d0    ONLINE       0     0     0
        cache
          c9t5000CCA04B12952Cd0      ONLINE       0     0     0
          c9t5000CCA04B12A1D0d0      ONLINE       0     0     0
        spares
          c9t5000CCA03104AD84d0      INUSE     currently in use
          c9t5000CCA02C414524d0      INUSE     currently in use

errors: No known data errors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ixgbe.conf
Type: application/octet-stream
Size: 237 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/6fcd6d8e/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: system
Type: application/octet-stream
Size: 1771 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/6fcd6d8e/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sd.conf
Type: application/octet-stream
Size: 4494 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/6fcd6d8e/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scsi_vhci.conf
Type: application/octet-stream
Size: 2513 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/6fcd6d8e/attachment-0007.obj>

From apenner.it at gmail.com  Fri Mar 17 13:05:50 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Fri, 17 Mar 2017 13:05:50 +0000
Subject: [OmniOS-discuss] 8TB Seagates under load = PANIC?
In-Reply-To: <F3723586-7557-4531-91F5-24766B66FB68@omniti.com>
References: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
	<CAE9csxM8ZC5Y1aY_=zit6iBnNKM9pH0RnUbGB4gNekhzjPtwJg@mail.gmail.com>
	<F3723586-7557-4531-91F5-24766B66FB68@omniti.com>
Message-ID: <CAE9csxNDeD4gjBdMVYKdJyX2h=ZaSbSqW4DG7EWoV7NAAGgH3A@mail.gmail.com>

>> What's pool5/fs1's actual mount point?  (
root at zns2-n2:/var/adm# zfs get mountpoint pool5/fs1
NAME       PROPERTY    VALUE       SOURCE
pool5/fs1  mountpoint  /pool5/fs1  local

>> Does that directory contain something?
root at zns2-n2:/var/adm# ls -la /pool5/fs1/
total 1
drwxr-xr-x 2 root root 2 Mar 16 14:39 .
drwxr-xr-x 4 root root 4 Mar 17 05:55 ..


And I also try to mount it to another location, but I can't do that

root at zns2-n2:/var/adm# zfs set mountpoint=/pool5/new_fs1 pool5/fs1
cannot mount 'pool5/fs1': mountpoint or dataset is busy
property may be set but unable to remount filesystem

root at zns2-n2:/var/adm# zfs set mountpoint=none pool5/fs1
root at zns2-n2:/var/adm# zfs set mountpoint=/pool5/new_fs1_1 pool5/fs1
cannot mount 'pool5/fs1': mountpoint or dataset is busy
property may be set but unable to remount filesystem

>>  I'd quiesce any process that writes there, and make sure it didn't race
to write there while you were mounting pool5/fs1.
I do not see any processes that open files in /pool5/* directories ( I'm
using pfiles utility to check it)


??, 17 ???. 2017 ?. ? 15:52, Dan McDonald <danmcd at omniti.com>:

>
> > On Mar 17, 2017, at 7:14 AM, Artem Penner <apenner.it at gmail.com> wrote:
> >
> > root at zns2-n2:/root# zfs list pool5/fs1
> > NAME        USED  AVAIL  REFER  MOUNTPOINT
> > pool5/fs1  3.90T  44.1T  3.90T  /pool5/fs1
> >
> > root at zns2-n2:/root# zfs mount pool5/fs1
> > cannot mount 'pool5/fs1': mountpoint or dataset is busy
> > root at zns2-n2:/root# zfs umount pool5/fs1
> > cannot unmount 'pool5/fs1': not currently mounted
>
> What's pool5/fs1's actual mount point?  ("zfs get mountpoint pool5/fs1")?
> Does that directory contain something?  I'd quiesce any process that writes
> there, and make sure it didn't race to write there while you were mounting
> pool5/fs1.
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/df4f0cb4/attachment.html>

From danmcd at omniti.com  Fri Mar 17 13:12:11 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 17 Mar 2017 09:12:11 -0400
Subject: [OmniOS-discuss] 8TB Seagates under load = PANIC?
In-Reply-To: <CAE9csxMSzZFKNXhbaB2M=ikfwu1HYdORYKQaYiGyhmsKgid6mg@mail.gmail.com>
References: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
	<E3D54E6F-CE9E-46D3-BAE2-F89933105CB2@omniti.com>
	<CAE9csxMSzZFKNXhbaB2M=ikfwu1HYdORYKQaYiGyhmsKgid6mg@mail.gmail.com>
Message-ID: <21A73104-AB1D-4CFF-AF70-F9D6605CCAD5@omniti.com>

Thank you.

So you're running LTS, AND it is up to date as of today.  This helps me understand some things. IF this was fixed already in later releases (under a different bug id), we likely deemed it too big/intrusive to backport to an LTS release, or we overlooked its importance.

As for the busy filesystem, I wonder if it'll behave better after your resilver finishes?  Otherwise, I'm not immediately sure what to tell you.

And one last thing... I'm travelling back home today, so I'll be unavailable in a couple of hours.

Dan


From apenner.it at gmail.com  Fri Mar 17 13:25:01 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Fri, 17 Mar 2017 13:25:01 +0000
Subject: [OmniOS-discuss] 8TB Seagates under load = PANIC?
In-Reply-To: <21A73104-AB1D-4CFF-AF70-F9D6605CCAD5@omniti.com>
References: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
	<E3D54E6F-CE9E-46D3-BAE2-F89933105CB2@omniti.com>
	<CAE9csxMSzZFKNXhbaB2M=ikfwu1HYdORYKQaYiGyhmsKgid6mg@mail.gmail.com>
	<21A73104-AB1D-4CFF-AF70-F9D6605CCAD5@omniti.com>
Message-ID: <CAE9csxO3hWLOM5F=8GO=s9YGF2Jq8f8e-eZOssMNSRugchU0yQ@mail.gmail.com>

Thank a lot,

>> As for the busy filesystem, I wonder if it'll behave better after your
resilver finishes?  Otherwise, I'm not immediately sure what to tell you.
I will certainly report the result after resilver finished.

>> And one last thing... I'm travelling back home today, so I'll be
unavailable in a couple of hours.
It's not production. We are only testing the fault tolerance before
entering it to production use.

----------
PS: Thank you very much, it feels like Sun Microsystem is alive again and
you applied to the most qualified support ever.


??, 17 ???. 2017 ?. ? 16:12, Dan McDonald <danmcd at omniti.com>:

> Thank you.
>
> So you're running LTS, AND it is up to date as of today.  This helps me
> understand some things. IF this was fixed already in later releases (under
> a different bug id), we likely deemed it too big/intrusive to backport to
> an LTS release, or we overlooked its importance.
>
> As for the busy filesystem, I wonder if it'll behave better after your
> resilver finishes?  Otherwise, I'm not immediately sure what to tell you.
>
> And one last thing... I'm travelling back home today, so I'll be
> unavailable in a couple of hours.
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/bc1152a7/attachment.html>

From tobi at oetiker.ch  Fri Mar 17 13:42:09 2017
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Fri, 17 Mar 2017 14:42:09 +0100 (CET)
Subject: [OmniOS-discuss] KVMs locking up for seconds at a time...
In-Reply-To: <ECBAC0E7-D92F-4103-8DA0-4416FA905988@omniti.com>
References: <326695157.1392.1489422006874.JavaMail.zimbra@oetiker.ch>
	<ECBAC0E7-D92F-4103-8DA0-4416FA905988@omniti.com>
Message-ID: <620274505.158012.1489758129815.JavaMail.zimbra@oetiker.ch>

We found the cause of the problem:

  svc:/system/rcap:default

enable it and enjoy the behaviour detailed below plus random hangs on nfs and iscsi export

disable it and things are as before


cheers
tobi


----- On Mar 13, 2017, at 6:15 PM, Dan McDonald danmcd at omniti.com wrote:

> Hello!
> 
> I'm including Tobias in this, as he reported this to me in OmniOS r151020
> (released November of 2016).  He can correct any mistake I make in reporting
> this.
> 
> His KVM instances are experiencing, "Random short freezes".  Let me quote him:
> 
>> We are running kvm instances on omni r20 and are experiencing random short
>> freezes.
>> I wrote the following short test script to see how frequent the freezing
>> occurres
>> 
>> perl -e 'use Time::HiRes qw(time usleep); my $now = time; while(1){usleep
>> 200000; my $next = time; my $diff = $next - $now; $now=$next; if ($diff >
>> 0.22){ print "".localtime(time)." ".$diff,"\n"}}'
>> 
>> the output looks like this
>> 
>> Thu Mar  9 15:26:12 2017 0.224979877471924
>> Thu Mar  9 15:26:23 2017 0.273133993148804
>> Thu Mar  9 15:27:54 2017 1.17526292800903
>> Thu Mar  9 15:28:59 2017 2.04209899902344
>> Thu Mar  9 15:30:31 2017 1.0813729763031
>> Thu Mar  9 15:30:44 2017 0.600342988967896
>> Thu Mar  9 15:31:47 2017 1.43648099899292
>> Thu Mar  9 15:32:25 2017 0.897988796234131
>> Thu Mar  9 15:33:28 2017 0.998631000518799
>> Thu Mar  9 15:34:10 2017 4.89306116104126
>> Thu Mar  9 15:36:15 2017 1.22311997413635
>> Thu Mar  9 15:38:57 2017 1.64742302894592
>> Thu Mar  9 15:39:21 2017 1.36228013038635
>> Thu Mar  9 15:40:08 2017 1.62232208251953
>> Thu Mar  9 15:40:32 2017 1.37291598320007
>> Thu Mar  9 15:42:30 2017 0.211127996444702
>> 
>> as you can see there are quite frequent short freezes ...
> 
> So his KVM guest sees freezes.  And he ran that perl in the OmniOS global zone
> w/o noticing any slowdowns.
> 
> I asked him to pstack(1) the qemu process.  It's attached below as pstack.zip.
> 
> He further noticed a manifestation in the global zone:
> 
>> What I found while looking up process numbers on the problematic box, is that
>> 
>>   time cat /proc/*/psinfo > /dev/null
>> 
>> Takes anywhere between 0.01s and 4s if called repeatedly, whereas on a machine
>> another host where there are no sever kvm hangs this command always takes about
>> 0.02 secons.
> 
> So he can find slowness that's likely KVM-induced in the global zone.  With that
> in mind, I told him, and he responded:
> 
>>> lockstat(1M) may be helpful here:
>>> 
>>> 	lockstat -o <somewhere> cat /proc/*/psinfo > /dev/null
>>> 
>>> I'll want to see that output from <somewhere>.  ESPECIALLY if it's a "takes way
>>> too long" sort of result.
> 
> 
> He included three lockstat outputs, also attached below.
> 
> The longer-running ones had this lock:
> 
> 11423  73%  73% 0.00     3403 0xfffffea4320ef020
> gfn_to_memslot_unaliased+0x1f
> 
> being hammered more in the long-running ones than in the short-running ones.
> Now I don't know KVM internals all that well, but  it looks like the lock in
> question protects a linear-array-search of memory slots.  It appears it just
> runs through and stops when the requested address is in the range of one of the
> hits.
> 
> I've not asked Tobias yet to dig into kmdb to see how many memory slots are in
> this kvm, but let me do that too:
> 
> Tobias:  Try this:
> 
>	dtrace -n 'gfn_to_memslot_unaliased:entry { printf("\nKVM 0x%p, number of
>	memslots: %d\n", arg0, ((struct kvm_memslots *)((struct kvm
>	*)arg0)->memslots)->nmemslots); stack(); exit(0);}'
> 
> If your system is still running the same KVM instances, check for
> 0xfffffea4320ef000 as the KVM pointer.
> 
> Everyone else ===> Any idea if memslots would cause KVM instances to misbehave
> per above?  If not, any other clues so I don't keep chasing red herrings?  If
> so, should we perhaps spend some time making memslots more efficient?  Or are
> there operational considerations not being accounted for?
> 
> Thanks,
> Dan

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

From apenner.it at gmail.com  Fri Mar 17 13:59:24 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Fri, 17 Mar 2017 13:59:24 +0000
Subject: [OmniOS-discuss] 8TB Seagates under load = PANIC?
In-Reply-To: <CAE9csxO3hWLOM5F=8GO=s9YGF2Jq8f8e-eZOssMNSRugchU0yQ@mail.gmail.com>
References: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
	<E3D54E6F-CE9E-46D3-BAE2-F89933105CB2@omniti.com>
	<CAE9csxMSzZFKNXhbaB2M=ikfwu1HYdORYKQaYiGyhmsKgid6mg@mail.gmail.com>
	<21A73104-AB1D-4CFF-AF70-F9D6605CCAD5@omniti.com>
	<CAE9csxO3hWLOM5F=8GO=s9YGF2Jq8f8e-eZOssMNSRugchU0yQ@mail.gmail.com>
Message-ID: <CAE9csxOMCpG1gwzFoDOkT8vcVG1wR7BZuG5p3Js_zZz4B0JVqA@mail.gmail.com>

Additional info:

> ::stack
vpanic()
0xfffffffffba8b1a8()
vdev_disk_io_start+0x130(ffffd06a690b8c70)
zio_vdev_io_start+0xae(ffffd06a690b8c70)
zio_execute+0x78(ffffd06a690b8c70)
vdev_queue_io_done+0x78(ffffd06af0a85708)
zio_vdev_io_done+0x80(ffffd06af0a85708)
zio_execute+0x78(ffffd06af0a85708)
taskq_thread+0x2d0(ffffd06342f81020)
thread_start+8()


> ::status
debugging crash dump /var/crash/unknown/vmcore.0 (64-bit) from zns2-n2
operating system: 5.11 omnios-2fb9a48 (i86pc)
image uuid: 32c56db4-4a94-4af4-eb2a-8fd6ed5e524f
panic message: assertion failed: ldi_strategy(dvd->vd_lh, bp) == 0, file:
../../common/fs/zfs/vdev_disk.c, line: 819
dump content: kernel pages only

> ::spa -v
ADDR                 STATE NAME

ffffd06343afa000    ACTIVE pool5

    ADDR             STATE     AUX          DESCRIPTION

    ffffd06344a51380 DEGRADED  -            root
    ffffd06344a519c0 HEALTHY   -              raidz
    ffffd06344a52080 HEALTHY   -
 /dev/dsk/c9t5000CCA031039F18d0s0
    ffffd06344a526c0 HEALTHY   -
 /dev/dsk/c9t5000CCA03103A054d0s0
    ffffd06344a52d00 HEALTHY   -
 /dev/dsk/c9t5000CCA031048B88d0s0
    ffffd06344a53340 HEALTHY   -
 /dev/dsk/c9t5000CCA031039E80d0s0
    ffffd06344a53980 HEALTHY   -
 /dev/dsk/c9t5000CCA031048C18d0s0
    ffffd06344a54040 HEALTHY   -
 /dev/dsk/c9t5000CCA031039F50d0s0
    ffffd06344a54680 HEALTHY   -
 /dev/dsk/c9t5000CCA03104AA40d0s0
    ffffd06344a54cc0 HEALTHY   -
 /dev/dsk/c9t5000CCA03104AD44d0s0
    ffffd06344a55300 HEALTHY   -
 /dev/dsk/c9t5000CCA03103B274d0s0
    ffffd06344a55940 HEALTHY   -
 /dev/dsk/c9t5000CCA03103B2C8d0s0
    ffffd06344a56000 DEGRADED  -              raidz
    ffffd06344a56640 HEALTHY   -
 /dev/dsk/c9t5000CCA03103B34Cd0s0
    ffffd06344a56c80 HEALTHY   -
 /dev/dsk/c9t5000CCA03104AE18d0s0
    ffffd06344a572c0 HEALTHY   -
 /dev/dsk/c9t5000CCA03104AE54d0s0
    ffffd066f7ecd040 REMOVED   -                spare
    ffffd06344a57900 REMOVED   -
 /dev/dsk/c9t5000CCA03103B2D4d0s0
    ffffd0634229bd40 HEALTHY   -
 /dev/dsk/c9t5000CCA03104AD84d0s0
    ffffd06344a580c0 HEALTHY   -
 /dev/dsk/c9t5000CCA03103B26Cd0s0
    ffffd06344a58700 HEALTHY   -
 /dev/dsk/c9t5000CCA03103B3ACd0s0
    ffffd06344a58d40 HEALTHY   -
 /dev/dsk/c9t5000CCA03103B338d0s0
    ffffd06344a59380 HEALTHY   -
 /dev/dsk/c9t5000CCA03104DFACd0s0
    ffffd06344a599c0 HEALTHY   -
 /dev/dsk/c9t5000CCA03104ABA8d0s0
    ffffd06344a5a080 HEALTHY   -
 /dev/dsk/c9t5000CCA03103A10Cd0s0
    ffffd06344a5a6c0 HEALTHY   -              raidz
    ffffd06344a5ad00 HEALTHY   -
 /dev/dsk/c9t5000CCA02C413D04d0s0
    ffffd06344a5b340 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D40Cd0s0
    ffffd0634579c6c0 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D7A8d0s0
    ffffd0634579c080 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D768d0s0
    ffffd0634f2329c0 HEALTHY   -
 /dev/dsk/c9t5000CCA031046494d0s0
    ffffd0634f232380 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D458d0s0
    ffffd0634f231d40 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D408d0s0
    ffffd0634f231700 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D798d0s0
    ffffd0634f2310c0 HEALTHY   -
 /dev/dsk/c9t5000CCA03103D28Cd0s0
    ffffd0634f228900 HEALTHY   -
 /dev/dsk/c9t5000CCA031047A30d0s0
    ffffd0634f2282c0 DEGRADED  -              raidz
    ffffd0634579d980 REMOVED   -                spare
    ffffd0634f227c80 REMOVED   -
 /dev/dsk/c9t5000CCA03104D2ECd0s0
    ffffd071db7da340 HEALTHY   -
 /dev/dsk/c9t5000CCA02C414524d0s0
    ffffd0634f227640 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D370d0s0
    ffffd0634f227000 HEALTHY   -
 /dev/dsk/c9t5000CCA031038248d0s0
    ffffd0634f226940 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D448d0s0
    ffffd0634f226300 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D81Cd0s0
    ffffd0634f225cc0 HEALTHY   -
 /dev/dsk/c9t5000CCA031038470d0s0
    ffffd0634f225680 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D400d0s0
    ffffd0634f225040 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D330d0s0
    ffffd0634f22a980 HEALTHY   -
 /dev/dsk/c9t5000CCA03104D7F8d0s0
    ffffd0634f22a340 HEALTHY   -
 /dev/dsk/c9t5000CCA031046C68d0s0
    ffffd0634f229d00 HEALTHY   -              mirror
    ffffd0634f2296c0 HEALTHY   -
 /dev/dsk/c9t500003979C88FF91d0s0
    ffffd0634f229080 HEALTHY   -
 /dev/dsk/c9t500003973C88B6F5d0s0
    ffffd0634f2209c0 HEALTHY   -              mirror
    ffffd0634f220380 HEALTHY   -
 /dev/dsk/c9t500003979C88FF5Dd0s0
    ffffd0634f21fd40 HEALTHY   -
 /dev/dsk/c9t500003979C890019d0s0
    -                -         -            cache
    ffffd06352e1d640 HEALTHY   -
 /dev/dsk/c9t5000CCA04B12952Cd0s0
    ffffd06352e1d000 HEALTHY   -
 /dev/dsk/c9t5000CCA04B12A1D0d0s0
    -                -         -            spares
    ffffd06352e1e2c0 HEALTHY   -
 /dev/dsk/c9t5000CCA03104AD84d0s0
    ffffd06352e1dc80 HEALTHY   -
 /dev/dsk/c9t5000CCA02C414524d0s0
ffffd063157c9000    ACTIVE rpool

    ffffd063160dc340 HEALTHY   -            root
    ffffd062a21b4040 HEALTHY   -              /dev/dsk/c3t8d1s0



??, 17 ???. 2017 ?. ? 16:25, Artem Penner <apenner.it at gmail.com>:

Thank a lot,

>> As for the busy filesystem, I wonder if it'll behave better after your
resilver finishes?  Otherwise, I'm not immediately sure what to tell you.
I will certainly report the result after resilver finished.

>> And one last thing... I'm travelling back home today, so I'll be
unavailable in a couple of hours.
It's not production. We are only testing the fault tolerance before
entering it to production use.

----------
PS: Thank you very much, it feels like Sun Microsystem is alive again and
you applied to the most qualified support ever.


??, 17 ???. 2017 ?. ? 16:12, Dan McDonald <danmcd at omniti.com>:

Thank you.

So you're running LTS, AND it is up to date as of today.  This helps me
understand some things. IF this was fixed already in later releases (under
a different bug id), we likely deemed it too big/intrusive to backport to
an LTS release, or we overlooked its importance.

As for the busy filesystem, I wonder if it'll behave better after your
resilver finishes?  Otherwise, I'm not immediately sure what to tell you.

And one last thing... I'm travelling back home today, so I'll be
unavailable in a couple of hours.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/c2ad90d5/attachment-0001.html>

From danmcd at omniti.com  Fri Mar 17 14:02:32 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 17 Mar 2017 10:02:32 -0400
Subject: [OmniOS-discuss] KVMs locking up for seconds at a time...
In-Reply-To: <620274505.158012.1489758129815.JavaMail.zimbra@oetiker.ch>
References: <326695157.1392.1489422006874.JavaMail.zimbra@oetiker.ch>
	<ECBAC0E7-D92F-4103-8DA0-4416FA905988@omniti.com>
	<620274505.158012.1489758129815.JavaMail.zimbra@oetiker.ch>
Message-ID: <4A0F6041-5972-4303-8407-0C97A24F83EB@omniti.com>


> On Mar 17, 2017, at 9:42 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
> 
> We found the cause of the problem:
> 
>  svc:/system/rcap:default
> 
> enable it and enjoy the behaviour detailed below plus random hangs on nfs and iscsi export
> 
> disable it and things are as before

Wow!  Just... wow!

Okay, thank you, and sorry I couldn't help you arrive here sooner,
Dan


From tobi at oetiker.ch  Fri Mar 17 15:03:40 2017
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Fri, 17 Mar 2017 16:03:40 +0100 (CET)
Subject: [OmniOS-discuss] KVMs locking up for seconds at a time...
In-Reply-To: <4A0F6041-5972-4303-8407-0C97A24F83EB@omniti.com>
References: <326695157.1392.1489422006874.JavaMail.zimbra@oetiker.ch>
	<ECBAC0E7-D92F-4103-8DA0-4416FA905988@omniti.com>
	<620274505.158012.1489758129815.JavaMail.zimbra@oetiker.ch>
	<4A0F6041-5972-4303-8407-0C97A24F83EB@omniti.com>
Message-ID: <734895504.184704.1489763020048.JavaMail.zimbra@oetiker.ch>

----- On Mar 17, 2017, at 3:02 PM, Dan McDonald danmcd at omniti.com wrote:

>> On Mar 17, 2017, at 9:42 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
>> 
>> We found the cause of the problem:
>> 
>>  svc:/system/rcap:default
>> 
>> enable it and enjoy the behaviour detailed below plus random hangs on nfs and
>> iscsi export
>> 
>> disable it and things are as before
> 
> Wow!  Just... wow!
> 
> Okay, thank you, and sorry I couldn't help you arrive here sooner,

the problem was found by my brother: Manuel Oetiker manuel at oetiker.ch btw :)

cheers
tobi

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

From skeltonr at btconnect.com  Fri Mar 17 23:50:00 2017
From: skeltonr at btconnect.com (Richard Skelton)
Date: Fri, 17 Mar 2017 23:50:00 +0000
Subject: [OmniOS-discuss] arcstat ZFS question
In-Reply-To: <2564F2CB-C602-42EA-8A16-CA54A45088C6@omniti.com>
References: <58CB9A75.2030907@btconnect.com>
	<2564F2CB-C602-42EA-8A16-CA54A45088C6@omniti.com>
Message-ID: <58CC7628.4080008@btconnect.com>

Hi Dan,
Thanks for the prompt response.

But why the arc misses if I repeat the du and why is the L2arc size from
arcstat much bigger than from zpool iostat?

Dan McDonald wrote:
>> On Mar 17, 2017, at 4:12 AM, Richard Skelton <skeltonr at btconnect.com> wrote:
>>
>> Why does du generate writes?
>> Is this normal?
>>     
>
> If you've L2ARC, it'd make sense that du (a program that traverses tons of directories if not more to find out how many blocks and/or bytes each file holds) would change the usage patterns AND that it would get cached in your L2ARC device.  Caches are written when usage patterns change.
>
> So yes, it's expected behavior:  caches change based on usage patterns, and "du -sh *" changes your usage to "read every directory".
>
> Hope this helps,
> Dan
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170317/317686d4/attachment.html>

From vab at bb-c.de  Fri Mar 17 23:56:23 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Sat, 18 Mar 2017 00:56:23 +0100
Subject: [OmniOS-discuss] OmniOS Bloody USB3 Feedback
Message-ID: <22732.30631.731084.680717@shelob.bb-c.de>

Hello all!


Today I did some USB3 testing.  Here is the feedback.
I used this card, based on the NEC/Renesas uPD720202:

  https://www.amazon.de/Exsys-PCI-Express-Erweiterungskarte-Super-Speed-Spezifikationen/dp/B01440VZF0/

The card has a 4pin "molex" power input which I did not hook up.

This was just a quick functional test in the only available PCIe slot in
a Sun Fire X2270, using the latest bloody.  Here are some more details:


1. Add card to system, power up, boot

Card is recognized:

  Mar 17 18:32:36 omnit0 pcplusmp: [ID 805372 kern.info] pcplusmp: pciclass,0c0330 (xhci) instance 0 irq 0x33 vector 0x83 ioapic 0xff intin 0xff is bound to cpu 7

/etc/path_to_inst has:

  "/pci at 0,0/pci8086,340e at 7/pci1912,15 at 0" 0 "xhci"


2. Plug in external Toshiba USB3 2.5" HD (my only USB3 device :-):

  Mar 17 18:43:19 omnit0 usba: [ID 912658 kern.notice] USB 3.0 device (usb480,a006) operating at super speed (USB 3.x) on USB 3.0 root hub: storage at 2, scsa2usb0 at bus address 2
  Mar 17 18:43:19 omnit0 usba: [ID 349649 kern.notice] TOSHIBA External USB 3.0 20130702020443
  Mar 17 18:43:19 omnit0 genunix: [ID 936769 kern.notice] scsa2usb0 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 2
  Mar 17 18:43:19 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 2 (scsa2usb0) online
  Mar 17 18:43:22 omnit0 scsi: [ID 583861 kern.notice] sd1 at scsa2usb0: target 0 lun 0
  Mar 17 18:43:22 omnit0 genunix: [ID 936769 kern.notice] sd1 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 2/disk at 0,0
  Mar 17 18:43:22 omnit0 genunix: [ID 408114 kern.notice]
  /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 2/disk at 0,0 (sd1) online

Device nodes are looking good, "cfgadm -la" shows connected storage:

Ap_Id                          Type         Receptacle   Occupant     Condition
...
usb9/1                         unknown      empty        unconfigured ok
usb9/2                         usb-storage  connected    configured   ok
usb9/3                         unknown      empty        unconfigured ok
usb9/4                         unknown      empty        unconfigured ok

The 1-4 confuses me a bit, the card has two ports.  Maybe it's because
a USB3 port really also contains a USB2 port...


3. Import the pool on the Toshiba HD, start a scrub, do "zpool iostat 1":
  
  # zpool list -v Transfer
  NAME         SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
  Transfer     928G   135G   793G         -      -    14%  1.00x  ONLINE  -
    c3t0d0     928G   135G   793G         -      -    14%

  ...
                 capacity     operations    bandwidth
  pool        alloc   free   read  write   read  write
  ----------  -----  -----  -----  -----  -----  -----
  Transfer     135G   793G    502      0  62.4M      0
  Transfer     135G   793G    538      0  66.8M      0
  Transfer     135G   793G    387     30  46.5M   110K
  Transfer     135G   793G    503      0  62.5M      0
  ...

So it's not really fast, but much better than USB2. :-)


4. While the scrub is running, insert a USB2 stick into the other port:

  Mar 17 18:49:21 omnit0 usba: [ID 912658 kern.notice] USB 2.0 device (usb90c,1000) operating at hi speed (USB 2.x) on USB 3.0 root hub: storage at 3, scsa2usb1 at bus address 3
  Mar 17 18:49:21 omnit0 usba: [ID 349649 kern.notice] General USB Flash Disk FBK1602242500409
  Mar 17 18:49:21 omnit0 genunix: [ID 936769 kern.notice] scsa2usb1 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3
  Mar 17 18:49:21 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3 (scsa2usb1) online
  Mar 17 18:49:22 omnit0 scsi: [ID 583861 kern.notice] sd2 at scsa2usb1: target 0 lun 0
  Mar 17 18:49:22 omnit0 genunix: [ID 936769 kern.notice] sd2 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0
  Mar 17 18:49:22 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0 (sd2) online
  Mar 17 18:49:22 omnit0 genunix: [ID 127566 kern.info] device pciclass,030000 at 5(display#0) keeps up device sd at 0,0(disk#2), but the former is not power managed

cfgadm -al says:

  Ap_Id                          Type         Receptacle   Occupant     Condition
  ...
  usb9/1                         unknown      empty        unconfigured ok
  usb9/2                         usb-storage  connected    configured   ok
  usb9/3                         usb-storage  connected    configured   ok
  usb9/4                         unknown      empty        unconfigured ok


5. Pull the stick, insert a different one.

  Mar 17 18:52:57 omnit0 scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0 (sd2):
  Mar 17 18:52:57 omnit0  Command failed to complete...Device is gone
  Mar 17 18:53:01 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0 (sd2) removed
  Mar 17 18:53:01 omnit0 last message repeated 1 time
  Mar 17 18:53:01 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3 (scsa2usb1) removed
  Mar 17 18:53:07 omnit0 usba: [ID 912658 kern.notice] USB 2.0 device (usb13fe,1e23) operating at hi speed (USB 2.x) on USB 3.0 root hub: storage at 3, scsa2usb1 at bus address 3
  Mar 17 18:53:07 omnit0 usba: [ID 349649 kern.notice] Verbatim STORE N GO 0700078415BE00D2
  Mar 17 18:53:07 omnit0 genunix: [ID 936769 kern.notice] scsa2usb1 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3
  Mar 17 18:53:07 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3 (scsa2usb1) online
  Mar 17 18:53:10 omnit0 scsi: [ID 583861 kern.notice] sd2 at scsa2usb1: target 0 lun 0
  Mar 17 18:53:10 omnit0 genunix: [ID 936769 kern.notice] sd2 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0
  Mar 17 18:53:10 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0 (sd2) online
  Mar 17 18:53:10 omnit0 genunix: [ID 127566 kern.info] device pciclass,030000 at 5(display#0) keeps up device sd at 0,0(disk#2), but the former is not power managed

Everything worked, all this time the zpool scrub did not skip a beat.


6. Try to unconfigure the stick before removing it to avoid the ugly
   "Command failed to complete...Device is gone" message.

  # cfgadm -c unconfigure usb9/3 
  Unconfigure the device: /devices/pci at 0,0/pci8086,340e at 7/pci1912,15 at 0:3
  This operation will suspend activity on the USB device
  Continue (yes/no)? y
  cfgadm: Hardware specific failure: Cannot issue devctl to ap_id: /devices/pci at 0,0/pci8086,340e at 7/pci1912,15 at 0:3
  Exit 1

And sure enough, it's still "configured":

  ...
  usb9/1                         unknown      empty        unconfigured ok
  usb9/2                         usb-storage  connected    configured   ok
  usb9/3                         usb-storage  connected    configured   ok
  usb9/4                         unknown      empty        unconfigured ok


Executive summary:  Works as expected, except the cfgadm -c unconfigure.

Thanks to Robert and Dan for giving us USB3 support in OmniOS!


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From danmcd at omniti.com  Sat Mar 18 05:01:59 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Sat, 18 Mar 2017 01:01:59 -0400
Subject: [OmniOS-discuss] OmniOS Bloody USB3 Feedback
In-Reply-To: <22732.30631.731084.680717@shelob.bb-c.de>
References: <22732.30631.731084.680717@shelob.bb-c.de>
Message-ID: <81AF57F4-0AA4-4AA2-98C8-519123EBDE04@omniti.com>

Thanks for the report.  Robert did all of the work, BTW.  I merely pulled it in.  OmniTI's Dale Ghent did testing and reviews, which was more than I did.

Credit where due, please!  :)
Dan

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

> On Mar 17, 2017, at 7:56 PM, Volker A. Brandt <vab at bb-c.de> wrote:
> 
> Hello all!
> 
> 
> Today I did some USB3 testing.  Here is the feedback.
> I used this card, based on the NEC/Renesas uPD720202:
> 
>  https://www.amazon.de/Exsys-PCI-Express-Erweiterungskarte-Super-Speed-Spezifikationen/dp/B01440VZF0/
> 
> The card has a 4pin "molex" power input which I did not hook up.
> 
> This was just a quick functional test in the only available PCIe slot in
> a Sun Fire X2270, using the latest bloody.  Here are some more details:
> 
> 
> 1. Add card to system, power up, boot
> 
> Card is recognized:
> 
>  Mar 17 18:32:36 omnit0 pcplusmp: [ID 805372 kern.info] pcplusmp: pciclass,0c0330 (xhci) instance 0 irq 0x33 vector 0x83 ioapic 0xff intin 0xff is bound to cpu 7
> 
> /etc/path_to_inst has:
> 
>  "/pci at 0,0/pci8086,340e at 7/pci1912,15 at 0" 0 "xhci"
> 
> 
> 2. Plug in external Toshiba USB3 2.5" HD (my only USB3 device :-):
> 
>  Mar 17 18:43:19 omnit0 usba: [ID 912658 kern.notice] USB 3.0 device (usb480,a006) operating at super speed (USB 3.x) on USB 3.0 root hub: storage at 2, scsa2usb0 at bus address 2
>  Mar 17 18:43:19 omnit0 usba: [ID 349649 kern.notice] TOSHIBA External USB 3.0 20130702020443
>  Mar 17 18:43:19 omnit0 genunix: [ID 936769 kern.notice] scsa2usb0 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 2
>  Mar 17 18:43:19 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 2 (scsa2usb0) online
>  Mar 17 18:43:22 omnit0 scsi: [ID 583861 kern.notice] sd1 at scsa2usb0: target 0 lun 0
>  Mar 17 18:43:22 omnit0 genunix: [ID 936769 kern.notice] sd1 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 2/disk at 0,0
>  Mar 17 18:43:22 omnit0 genunix: [ID 408114 kern.notice]
>  /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 2/disk at 0,0 (sd1) online
> 
> Device nodes are looking good, "cfgadm -la" shows connected storage:
> 
> Ap_Id                          Type         Receptacle   Occupant     Condition
> ...
> usb9/1                         unknown      empty        unconfigured ok
> usb9/2                         usb-storage  connected    configured   ok
> usb9/3                         unknown      empty        unconfigured ok
> usb9/4                         unknown      empty        unconfigured ok
> 
> The 1-4 confuses me a bit, the card has two ports.  Maybe it's because
> a USB3 port really also contains a USB2 port...
> 
> 
> 3. Import the pool on the Toshiba HD, start a scrub, do "zpool iostat 1":
> 
>  # zpool list -v Transfer
>  NAME         SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
>  Transfer     928G   135G   793G         -      -    14%  1.00x  ONLINE  -
>    c3t0d0     928G   135G   793G         -      -    14%
> 
>  ...
>                 capacity     operations    bandwidth
>  pool        alloc   free   read  write   read  write
>  ----------  -----  -----  -----  -----  -----  -----
>  Transfer     135G   793G    502      0  62.4M      0
>  Transfer     135G   793G    538      0  66.8M      0
>  Transfer     135G   793G    387     30  46.5M   110K
>  Transfer     135G   793G    503      0  62.5M      0
>  ...
> 
> So it's not really fast, but much better than USB2. :-)
> 
> 
> 4. While the scrub is running, insert a USB2 stick into the other port:
> 
>  Mar 17 18:49:21 omnit0 usba: [ID 912658 kern.notice] USB 2.0 device (usb90c,1000) operating at hi speed (USB 2.x) on USB 3.0 root hub: storage at 3, scsa2usb1 at bus address 3
>  Mar 17 18:49:21 omnit0 usba: [ID 349649 kern.notice] General USB Flash Disk FBK1602242500409
>  Mar 17 18:49:21 omnit0 genunix: [ID 936769 kern.notice] scsa2usb1 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3
>  Mar 17 18:49:21 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3 (scsa2usb1) online
>  Mar 17 18:49:22 omnit0 scsi: [ID 583861 kern.notice] sd2 at scsa2usb1: target 0 lun 0
>  Mar 17 18:49:22 omnit0 genunix: [ID 936769 kern.notice] sd2 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0
>  Mar 17 18:49:22 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0 (sd2) online
>  Mar 17 18:49:22 omnit0 genunix: [ID 127566 kern.info] device pciclass,030000 at 5(display#0) keeps up device sd at 0,0(disk#2), but the former is not power managed
> 
> cfgadm -al says:
> 
>  Ap_Id                          Type         Receptacle   Occupant     Condition
>  ...
>  usb9/1                         unknown      empty        unconfigured ok
>  usb9/2                         usb-storage  connected    configured   ok
>  usb9/3                         usb-storage  connected    configured   ok
>  usb9/4                         unknown      empty        unconfigured ok
> 
> 
> 5. Pull the stick, insert a different one.
> 
>  Mar 17 18:52:57 omnit0 scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0 (sd2):
>  Mar 17 18:52:57 omnit0  Command failed to complete...Device is gone
>  Mar 17 18:53:01 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0 (sd2) removed
>  Mar 17 18:53:01 omnit0 last message repeated 1 time
>  Mar 17 18:53:01 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3 (scsa2usb1) removed
>  Mar 17 18:53:07 omnit0 usba: [ID 912658 kern.notice] USB 2.0 device (usb13fe,1e23) operating at hi speed (USB 2.x) on USB 3.0 root hub: storage at 3, scsa2usb1 at bus address 3
>  Mar 17 18:53:07 omnit0 usba: [ID 349649 kern.notice] Verbatim STORE N GO 0700078415BE00D2
>  Mar 17 18:53:07 omnit0 genunix: [ID 936769 kern.notice] scsa2usb1 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3
>  Mar 17 18:53:07 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3 (scsa2usb1) online
>  Mar 17 18:53:10 omnit0 scsi: [ID 583861 kern.notice] sd2 at scsa2usb1: target 0 lun 0
>  Mar 17 18:53:10 omnit0 genunix: [ID 936769 kern.notice] sd2 is /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0
>  Mar 17 18:53:10 omnit0 genunix: [ID 408114 kern.notice] /pci at 0,0/pci8086,340e at 7/pci1912,15 at 0/storage at 3/disk at 0,0 (sd2) online
>  Mar 17 18:53:10 omnit0 genunix: [ID 127566 kern.info] device pciclass,030000 at 5(display#0) keeps up device sd at 0,0(disk#2), but the former is not power managed
> 
> Everything worked, all this time the zpool scrub did not skip a beat.
> 
> 
> 6. Try to unconfigure the stick before removing it to avoid the ugly
>   "Command failed to complete...Device is gone" message.
> 
>  # cfgadm -c unconfigure usb9/3 
>  Unconfigure the device: /devices/pci at 0,0/pci8086,340e at 7/pci1912,15 at 0:3
>  This operation will suspend activity on the USB device
>  Continue (yes/no)? y
>  cfgadm: Hardware specific failure: Cannot issue devctl to ap_id: /devices/pci at 0,0/pci8086,340e at 7/pci1912,15 at 0:3
>  Exit 1
> 
> And sure enough, it's still "configured":
> 
>  ...
>  usb9/1                         unknown      empty        unconfigured ok
>  usb9/2                         usb-storage  connected    configured   ok
>  usb9/3                         usb-storage  connected    configured   ok
>  usb9/4                         unknown      empty        unconfigured ok
> 
> 
> Executive summary:  Works as expected, except the cfgadm -c unconfigure.
> 
> Thanks to Robert and Dan for giving us USB3 support in OmniOS!
> 
> 
> Regards -- Volker
> -- 
> ------------------------------------------------------------------------
> Volker A. Brandt               Consulting and Support for Oracle Solaris
> Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
> Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
> Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
> Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt
> 
> "When logic and proportion have fallen sloppy dead"

From mir at miras.org  Sun Mar 19 13:03:23 2017
From: mir at miras.org (Michael Rasmussen)
Date: Sun, 19 Mar 2017 14:03:23 +0100
Subject: [OmniOS-discuss] Web: Release notes. Small bug
Message-ID: <20170319140323.20c5708c@sleipner.datanom.net>

Hi Dan

For March 1 update for r151014 the following link:
https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014

Contains this:

March 1 2017 Update #

illumos-omnios branch r151020 at 2fb9a48
uname -v/uname -a shows omnios-2fb9a48

Should it not be:
illumos-omnios branch r151014 at 2fb9a48

-- 
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:
There is nothing so easy but that it becomes difficult when you do it
reluctantly.
		-- Publius Terentius Afer (Terence)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170319/b554ee35/attachment.bin>

From tim at multitalents.net  Mon Mar 20 05:36:54 2017
From: tim at multitalents.net (Tim Rice)
Date: Sun, 19 Mar 2017 22:36:54 -0700 (PDT)
Subject: [OmniOS-discuss] Fwd: [developer] Review request: 7948 Remove
 old calendar utility
In-Reply-To: <CAEgYsbHiYSxPKNRONuiB=NbfCaGN7mdjw4HTU5Nx=O-mhYZbUg@mail.gmail.com>
References: <CAEgYsbEncEotZZrrfwiASc88bb_w43tgdp=6Un2UHPjszJNcAw@mail.gmail.com>
	<237225B6-6EC9-4A0A-89EA-25E021F994C9@omniti.com>
	<alpine.UW2.2.11.1703071732410.19286@server01.int.multitalents.net>
	<CAEgYsbHiYSxPKNRONuiB=NbfCaGN7mdjw4HTU5Nx=O-mhYZbUg@mail.gmail.com>
Message-ID: <alpine.UW2.2.11.1703192223340.14913@server01.int.multitalents.net>


Hi Peter,

Sorry for the delayed response. Overworked at $DAYJOB

On Wed, 8 Mar 2017, Peter Tribble wrote:

| On Wed, Mar 8, 2017 at 1:41 AM, Tim Rice <tim at multitalents.net> wrote:
| 
| > On Tue, 7 Mar 2017, Dan McDonald wrote:
| >
| > > Not to be confused with cal(1), but does anyone here use calendar(1)?
| >
| > I use it here in my mail zone.
| 
| Ouch.
| 
| > > Trying to gauge how hard I should try to replace it or not.
| >
| > It would not be anywhere near as anoying to lose it as it was to
| > discover bind was missing. ;-)
| >
| 
| I'm trying to understand the impact here - if it's bad then I'll look
| again.

I'd guees from the lack of feedback the impact seems to be very low.
(just me?)

I'll be able to work around it.

| If you know the format of your calendar file, then something like
| grep "^`date '+%D'`" ~/calendar
| or
| grep "^`date '+%b %e'`" ~/calendar
| ought to do more or less the same thing.
| 

-- 
Tim Rice				Multitalents
tim at multitalents.net



From stephan.budach at jvm.de  Mon Mar 20 09:25:26 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Mon, 20 Mar 2017 10:25:26 +0100 (CET)
Subject: [OmniOS-discuss] =?utf-8?q?dladm_shows_-NaN_f=C3=BCr_LACP_bond?=
In-Reply-To: <1690244075.185.1490001479936.JavaMail.stephan.budach@stephan.budach.jvm.de>
Message-ID: <36098045.209.1490001886969.JavaMail.stephan.budach@stephan.budach.jvm.de>

Hi, 


I was just checking the states of my LACP bonds on my omniOS boxes, due to some scheduled maintenace work on our Nexus switches, when I came across one box that does work normally, but where dladm shows no stats for one of the two LACP bonds, when running dladm show-aggr -s: 



root at zfsha01colt:/root# dladm show-aggr -s 
LINK PORT IPACKETS RBYTES OPACKETS OBYTES IPKTDIST OPKTDIST 
iscsi0 -- 61867781898 73344540353111 70243236328 129909713865234 -- -- 
-- ixgbe0 11144772596 3672486214983 24068168071 64207901139258 18,0 34,3 
-- ixgbe2 50723009302 69672054138128 46175068257 65701812725976 82,0 65,7 
nfs0 -- 0 0 0 0 -- -- 
-- ixgbe1 0 0 0 0 -NaN -NaN 
-- ixgbe3 0 0 0 0 -NaN -NaN 


However, when querying nfs0 directly, dladm just reports as expected: 



root at zfsha01colt:/root# dladm show-aggr -s nfs0 
LINK PORT IPACKETS RBYTES OPACKETS OBYTES IPKTDIST OPKTDIST 
nfs0 -- 10996605142 23230932089631 12027822487 62128732526817 -- -- 
-- ixgbe1 598367842 23690118857 2779810032 13926608816419 5,4 23,1 
-- ixgbe3 10398237300 23207241970774 9248012455 48202123710398 94,6 76,9 


This box is a r020 one: 



root at zfsha01colt:/root# uname -a 
SunOS zfsha01colt 5.11 omnios-bed3013 i86pc i386 i86pc 




Any idea as of why this could happen? The only thing I can think of is that one of the ports on one Nexus was flapping, which is also the cause for the scheduled maintenance on that switch, but it hasn't flapped for hours? 


Cheers, 
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170320/05e97292/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170320/05e97292/attachment.bin>

From danmcd at omniti.com  Mon Mar 20 13:31:47 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 20 Mar 2017 09:31:47 -0400
Subject: [OmniOS-discuss] Web: Release notes. Small bug
In-Reply-To: <20170319140323.20c5708c@sleipner.datanom.net>
References: <20170319140323.20c5708c@sleipner.datanom.net>
Message-ID: <8F91C1A1-BD9D-4C2F-A0CE-DF917337BE29@omniti.com>


> On Mar 19, 2017, at 9:03 AM, Michael Rasmussen <mir at miras.org> wrote:
> 
> Should it not be:
> illumos-omnios branch r151014 at 2fb9a48

It totally should be.

Fixed, and thanks!
Dan


From danmcd at omniti.com  Mon Mar 20 13:52:02 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 20 Mar 2017 09:52:02 -0400
Subject: [OmniOS-discuss] =?utf-8?q?dladm_shows_-NaN_f=C3=BCr_LACP_bond?=
In-Reply-To: <36098045.209.1490001886969.JavaMail.stephan.budach@stephan.budach.jvm.de>
References: <36098045.209.1490001886969.JavaMail.stephan.budach@stephan.budach.jvm.de>
Message-ID: <C1F64C0E-7DE5-4B82-953E-0C372CA87DEC@omniti.com>


> On Mar 20, 2017, at 5:25 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
> 
> Hi,
> 
> I was just checking the states of my LACP bonds on my omniOS boxes, due to some scheduled maintenace work on our Nexus switches, when I came across one box that does work normally, but where dladm shows no stats for one of the two LACP bonds, when running dladm show-aggr -s:

<SNIP!>

Just to be clear, this problem doesn't just happen sometimes, it happens all the time you "dladm show-aggr -s"?

Clearly everything's zeroed for "nfs0" when you're querying all of them.  The question is why.  IF (and only if) you have two spare physicals (maybe two unused igbs on the motherboard?) you could create a third (albeit unused) aggr to see if which of the "last one in the sequence" or "specifically nfs0" or "all but first in the sequence" fail.  Once the test is done, you could destroy the third, unused, aggr.

I can't dive into this deeply at the moment.  If you've the spare unused NICs, try the third-aggr experiment I suggested to see how the iterated output behaves.

Thanks,
Dan


From apenner.it at gmail.com  Mon Mar 20 20:44:15 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Mon, 20 Mar 2017 20:44:15 +0000
Subject: [OmniOS-discuss] 8TB Seagates under load = PANIC?
In-Reply-To: <CAE9csxO3hWLOM5F=8GO=s9YGF2Jq8f8e-eZOssMNSRugchU0yQ@mail.gmail.com>
References: <CAE9csxPrNOwSDzsct_vxa19B9dhcqV5=Lu1q5__98WJ2J7PJ5Q@mail.gmail.com>
	<E3D54E6F-CE9E-46D3-BAE2-F89933105CB2@omniti.com>
	<CAE9csxMSzZFKNXhbaB2M=ikfwu1HYdORYKQaYiGyhmsKgid6mg@mail.gmail.com>
	<21A73104-AB1D-4CFF-AF70-F9D6605CCAD5@omniti.com>
	<CAE9csxO3hWLOM5F=8GO=s9YGF2Jq8f8e-eZOssMNSRugchU0yQ@mail.gmail.com>
Message-ID: <CAE9csxP4c5_EjDQSY=a5JJ+M40vzyVRRYSF_RP6uEML8FxRWfw@mail.gmail.com>

>> >> As for the busy filesystem, I wonder if it'll behave better after
your resilver finishes?  Otherwise, I'm not immediately sure what to tell
you.
>> I will certainly report the result after resilver finished.
After  resilver was completed, the pool became available again.
Today I try to reproduce bug, that led to a kernel panic, but without
success. I continue tomorrow.
I also have kernel crash dump, if need I can provide it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170320/088f20c3/attachment.html>

From softwareinforjam at gmail.com  Tue Mar 21 15:11:55 2017
From: softwareinforjam at gmail.com (Software Information)
Date: Tue, 21 Mar 2017 10:11:55 -0500
Subject: [OmniOS-discuss] Package Versions
Message-ID: <CAFM8923wZr3K1iWu1cZC5o8V+yzJu0_uc6rtcCGWiF0eAwq4Pw@mail.gmail.com>

Hi All
I am just being introduced to IllumOS and OmniOS. I am coming from FreeBSD
so as I learn I try to think of the command equivalent to what I know in
FreeBSD. I am currently studying how to manage packages and so far, one
thing that is eluding me is how to know which packages need updating. In
freebsd I would do pkg version -v to see the list. Something like below
would be the result.

opendkim-2.9.2_5                   <   needs updating (index has 2.10.3_6)
openntpd-6.0p1_3,2                 <   needs updating (index has 6.0p1_4,2)
p5-Bit-Vector-7.3                  <   needs updating (index has 7.4)
p5-Carp-Clan-6.04                  <   needs updating (index has 6.06)
p5-Date-Calc-6.3                   <   needs updating (index has 6.4)
p5-Locale-gettext-1.05_3           <   needs updating (index has 1.06)
pcre-8.37_4                        <   needs updating (index has 8.40)

What command would I use in IllumOS? Thanks for any help and I have to say,
I am impressed with the concepts I am seeing.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170321/7fbbe3fb/attachment.html>

From danmcd at omniti.com  Tue Mar 21 15:24:51 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 21 Mar 2017 11:24:51 -0400
Subject: [OmniOS-discuss] Package Versions
In-Reply-To: <CAFM8923wZr3K1iWu1cZC5o8V+yzJu0_uc6rtcCGWiF0eAwq4Pw@mail.gmail.com>
References: <CAFM8923wZr3K1iWu1cZC5o8V+yzJu0_uc6rtcCGWiF0eAwq4Pw@mail.gmail.com>
Message-ID: <92615562-DC29-498A-963D-305E088F0A93@omniti.com>


> On Mar 21, 2017, at 11:11 AM, Software Information <softwareinforjam at gmail.com> wrote:
> 
> Hi All
> I am just being introduced to IllumOS and OmniOS. I am coming from FreeBSD so as I learn I try to think of the command equivalent to what I know in FreeBSD. I am currently studying how to manage packages and so far, one thing that is eluding me is how to know which packages need updating. In freebsd I would do pkg version -v to see the list. Something like below would be the result.
> 
> opendkim-2.9.2_5                   <   needs updating (index has 2.10.3_6)
> openntpd-6.0p1_3,2                 <   needs updating (index has 6.0p1_4,2)
> p5-Bit-Vector-7.3                  <   needs updating (index has 7.4)
> p5-Carp-Clan-6.04                  <   needs updating (index has 6.06)
> p5-Date-Calc-6.3                   <   needs updating (index has 6.4)
> p5-Locale-gettext-1.05_3           <   needs updating (index has 1.06)
> pcre-8.37_4                        <   needs updating (index has 8.40)
> 
> What command would I use in IllumOS? Thanks for any help and I have to say, I am impressed with the concepts I am seeing.

Hello again!

A reminder, pkg(1) is distro-specific, not native to upstream illumos.

As I said on the other list:

Read the manual page for pkg(1).  If you utter "pkg update -nv", you'll get a breakdown similar to the one you see above.  For a larger upgrade (like if illumos got rebuilt and pushed to your upstream repo server), that can be quite verbose.  Also, if you have zones, linked-image zone will get pulled along for the ride.


Welcome to illumos (note the capitalization) and OmniOS (note the capitalization)!

Dan


From davide.poletto at gmail.com  Tue Mar 21 15:26:59 2017
From: davide.poletto at gmail.com (Davide Poletto)
Date: Tue, 21 Mar 2017 16:26:59 +0100
Subject: [OmniOS-discuss] Package Versions
In-Reply-To: <CAFM8923wZr3K1iWu1cZC5o8V+yzJu0_uc6rtcCGWiF0eAwq4Pw@mail.gmail.com>
References: <CAFM8923wZr3K1iWu1cZC5o8V+yzJu0_uc6rtcCGWiF0eAwq4Pw@mail.gmail.com>
Message-ID: <CANKMAMbsysNfVwRXYyH1vaYf02f8DWM1zxOkS4X-E5ebb=_Syg@mail.gmail.com>

Generally (and I write as a noob) I use:

pkg update -nv (it's a dry run)

then you can decide to apply all of them with:

pkg update -v (verbose mode)

or select the package proposed update you want to apply.

More info here:

https://omnios.omniti.com/wiki.php/GeneralAdministration#PackageManagement



On Tue, Mar 21, 2017 at 4:11 PM, Software Information <
softwareinforjam at gmail.com> wrote:

> Hi All
> I am just being introduced to IllumOS and OmniOS. I am coming from FreeBSD
> so as I learn I try to think of the command equivalent to what I know in
> FreeBSD. I am currently studying how to manage packages and so far, one
> thing that is eluding me is how to know which packages need updating. In
> freebsd I would do pkg version -v to see the list. Something like below
> would be the result.
>
> opendkim-2.9.2_5                   <   needs updating (index has 2.10.3_6)
> openntpd-6.0p1_3,2                 <   needs updating (index has 6.0p1_4,2)
> p5-Bit-Vector-7.3                  <   needs updating (index has 7.4)
> p5-Carp-Clan-6.04                  <   needs updating (index has 6.06)
> p5-Date-Calc-6.3                   <   needs updating (index has 6.4)
> p5-Locale-gettext-1.05_3           <   needs updating (index has 1.06)
> pcre-8.37_4                        <   needs updating (index has 8.40)
>
> What command would I use in IllumOS? Thanks for any help and I have to
> say, I am impressed with the concepts I am seeing.
>
> Regards
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170321/4a523bd5/attachment.html>

From mailing-list-omnios at kopierkatze.net  Tue Mar 21 19:25:07 2017
From: mailing-list-omnios at kopierkatze.net (Arne)
Date: Tue, 21 Mar 2017 20:25:07 +0100
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
Message-ID: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>

Hi everyone!

I am currently trying to setup a nice little file server for home use.
I intend to evaluate OmniOS as the operating system, but I have some
trouble installing it onto an NVMe SSD.

My hardware setup:
CPU: Intel Xeon E3-1230 v5
Memory: Crucial 64GB (4x 16GB), DDR4-2133, ECC
Mainboard: Supermicro X11SSH-CTF
System Disk: Intel SSD 600p 256GB, M.2 PCIe (=NVMe)

To run the OmniOS installer, I had to install a SATA optical drive and
enable legacy USB mouse/keyboard support in the BIOS (the XHCI
controller of my mainboard is not supported by OmniOS).
Now I am stuck at the next problem: The OmniOS installer is not able to
see my NVMe disk.

Under Linux I can see the SSD, it shows up as "/dev/nvme0n1", showing
256GB capacity.
The OmniOS installer gives me the following error message: "OmniOS
cannot be installed on any disk"

OmniOsNoDisk.png

I used the ISO image of OmniOS v11 r151020 (current stable).
AFAIK, this should already contain an NVMe driver, so I am a little bit
surprised, why it won't see my disk.

Any hints what I am missing?

Thank you!

Arne 

FYI: I asked the same question in the forums at servethehome.com a few
days ago, without any answer so far:
https://forums.servethehome.com/index.php?threads/omnios-r151020-setup-wont-see-my-nvme-disk.13842/

From bfriesen at simple.dallas.tx.us  Tue Mar 21 19:30:57 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Tue, 21 Mar 2017 14:30:57 -0500 (CDT)
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
Message-ID: <alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>

On Tue, 21 Mar 2017, Arne wrote:

> Hi everyone!
>
> I am currently trying to setup a nice little file server for home use.
> I intend to evaluate OmniOS as the operating system, but I have some
> trouble installing it onto an NVMe SSD.

OmniOS can use a NVMe SSD but surely can not be installed on one.

The BIOS and boot software would need to support NVMe before it is 
possible to install the OS on it.

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

From danmcd at omniti.com  Tue Mar 21 19:37:32 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 21 Mar 2017 15:37:32 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
Message-ID: <D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>

If you're feeling brave, try the brand new bloody ISO, which has installer support for blkdev devices.  The old INSTALLER had problems with blkdev devices like NMVE.

Dan

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

> On Mar 21, 2017, at 3:30 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> 
>> On Tue, 21 Mar 2017, Arne wrote:
>> 
>> Hi everyone!
>> 
>> I am currently trying to setup a nice little file server for home use.
>> I intend to evaluate OmniOS as the operating system, but I have some
>> trouble installing it onto an NVMe SSD.
> 
> OmniOS can use a NVMe SSD but surely can not be installed on one.
> 
> The BIOS and boot software would need to support NVMe before it is possible to install the OS on it.
> 
> Bob
> -- 
> Bob Friesenhahn
> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From bfriesen at simple.dallas.tx.us  Tue Mar 21 19:43:47 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Tue, 21 Mar 2017 14:43:47 -0500 (CDT)
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
Message-ID: <alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>

On Tue, 21 Mar 2017, Dan McDonald wrote:

> If you're feeling brave, try the brand new bloody ISO, which has 
> installer support for blkdev devices.  The old INSTALLER had 
> problems with blkdev devices like NMVE.

Does the BIOS need to support NMVE in order for this to work?

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

From danmcd at omniti.com  Tue Mar 21 19:45:26 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 21 Mar 2017 15:45:26 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
Message-ID: <AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>

Yes it would.  We don't have EFI boot yet in illumos.

Dan

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

> On Mar 21, 2017, at 3:43 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> 
>> On Tue, 21 Mar 2017, Dan McDonald wrote:
>> 
>> If you're feeling brave, try the brand new bloody ISO, which has installer support for blkdev devices.  The old INSTALLER had problems with blkdev devices like NMVE.
> 
> Does the BIOS need to support NMVE in order for this to work?
> 
> Bob
> -- 
> Bob Friesenhahn
> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From mailing-list-omnios at kopierkatze.net  Tue Mar 21 21:07:23 2017
From: mailing-list-omnios at kopierkatze.net (Arne)
Date: Tue, 21 Mar 2017 22:07:23 +0100
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
Message-ID: <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>

Dan and Bob, thank you for your very quick responses!

I just did what you suggested, Dan: I tried to install the r151021 
bloody release.

In the OmniOS installation menu, I chose option 1:
"Find disks, create rpool, and install OmniOS"

Unfortunately, I won't see any disks in that menu, either.
Does this mean that there is a problem with my BIOS not supporting NVMe 
block devices, as Bob suggested?


-------- Original Message  --------
Subject: Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
From: Dan McDonald <danmcd at omniti.com>
To: Bob Friesenhahn <bfriesen at simple.dallas.tx.us>, Dan McDonald 
<danmcd at omniti.com>
Date: Tue Mar 21 2017 20:45:26 GMT+0100

> Yes it would.  We don't have EFI boot yet in illumos.
>
> Dan
>
>> On Mar 21, 2017, at 3:43 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
>>
>> Does the BIOS need to support NMVE in order for this to work?
>>
>> Bob

From danmcd at omniti.com  Tue Mar 21 21:24:23 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 21 Mar 2017 17:24:23 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
Message-ID: <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>


> On Mar 21, 2017, at 5:07 PM, Arne <mailing-list-omnios at kopierkatze.net> wrote:
> 
> Unfortunately, I won't see any disks in that menu, either.
> Does this mean that there is a problem with my BIOS not supporting NVMe block devices, as Bob suggested?

I went back to your original note:

> System Disk: Intel SSD 600p 256GB, M.2 PCIe (=NVMe)


Which version of NVMe does this use?  I can't seem to find it anywhere. Also, can you "lspci -nn" from the bloody installer's shell?  I'm wondering if it's new enough where we don't have it in /etc/driver_aliases.

Thanks,
Dan


From danmcd at omniti.com  Tue Mar 21 21:33:57 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 21 Mar 2017 17:33:57 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
Message-ID: <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>


> On Mar 21, 2017, at 5:24 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> Which version of NVMe does this use?  I can't seem to find it anywhere. Also, can you "lspci -nn" from the bloody installer's shell? I'm wondering if it's new enough where we don't have it in /etc/driver_aliases.

Damn, I thought we included lspci in the kayak image.

Instead, please try "prtconf -vp" and include it in an attachment.

Dan


From mailing-list-omnios at kopierkatze.net  Tue Mar 21 21:51:46 2017
From: mailing-list-omnios at kopierkatze.net (Arne)
Date: Tue, 21 Mar 2017 22:51:46 +0100
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
Message-ID: <e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>

Haha, I also noted that there is no lspci in the bloody installer, but I 
already rebooted to Linux before I read your answer.
The relevant output of "lspci -nn" on Linux is:

06:00.0 Non-Volatile memory controller [0108]: Intel Corporation Device 
[8086:f1a5] (rev 03)

Is this information sufficient, or do you want me to reboot to the 
bloody installer?


The exact name of the SSD is: SSDPEKKW256G7X1

I could not find a detailed data sheet on the Intel website, only this 
short one:
http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ssd-600p-brief.pdf

Other websites lists this as an NVMe 1.1 device, though.


-------- Original Message  --------
Subject: Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
From: Dan McDonald <danmcd at omniti.com>
To: Arne <mailing-list-omnios at kopierkatze.net>, Dan McDonald 
<danmcd at omniti.com>
Date: Tue Mar 21 2017 22:33:57 GMT+0100

>
>> On Mar 21, 2017, at 5:24 PM, Dan McDonald <danmcd at omniti.com> wrote:
>>
>> Which version of NVMe does this use?  I can't seem to find it anywhere. Also, can you "lspci -nn" from the bloody installer's shell? I'm wondering if it's new enough where we don't have it in /etc/driver_aliases.
>
> Damn, I thought we included lspci in the kayak image.
>
> Instead, please try "prtconf -vp" and include it in an attachment.
>
> Dan
>

From skeltonr at btconnect.com  Tue Mar 21 22:54:13 2017
From: skeltonr at btconnect.com (Richard Skelton)
Date: Tue, 21 Mar 2017 22:54:13 +0000
Subject: [OmniOS-discuss] nfsv3rwsnoop.d lists NFS writes to <unknown> files
Message-ID: <58D1AF15.5040706@btconnect.com>

Hi,
I am using the dtrace script nfsv3rwsnoop.d to find file that are
accessed from my OmniOS r151020 filer and some file names are listed as
unknown :-(
I guess they are files that have been open for a long time and have
dropped out of some data structure.
Is there any way to increase the persistence of the name stored.
I have lots on memory in this system and would be happy to sacrifice
some if I could see more file name :-)

root at filer:/scratch# /root/dtrace/nfsv3rwsnoop.d |more

1189849649391    xxx.xx.xxx.59       W 10500    138879 <unknown>
1189849649582    xxx.xx.xxx.59       W 10500    137788 <unknown>
1189849740621    xxx.xx.xxx.118      W 0          2404 <unknown>
1189849781136    xxx.xx.xxx.109      W 19832    756675 /scratch/run.log
1189849849301    xxx.xx.xxx.102      W 1096      57513
/scratch/avm_remote_job_f64ccf56-efa1-4605-8a48-874816779289_2.out

Cheers
Richard


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

From cks at cs.toronto.edu  Tue Mar 21 23:18:24 2017
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Tue, 21 Mar 2017 19:18:24 -0400
Subject: [OmniOS-discuss] nfsv3rwsnoop.d lists NFS writes to <unknown>
	files
In-Reply-To: Your message of Tue, 21 Mar 2017 22:54:13 -0000.
	<58D1AF15.5040706@btconnect.com>
Message-ID: <20170321231825.0F7BF11C00B9@apps0.cs.toronto.edu>

> Hi,
> I am using the dtrace script nfsv3rwsnoop.d to find file that are
> accessed from my OmniOS r151020 filer and some file names are listed as
> unknown :-(
> I guess they are files that have been open for a long time and have
> dropped out of some data structure.
> Is there any way to increase the persistence of the name stored.
> I have lots on memory in this system and would be happy to sacrifice
> some if I could see more file name :-)

 My usual way to force many of the names back into cache is to
run find over the filesystem, looking for that inode number. If I needed
to do it regularly I would probably write a dedicated filesystem walker
that could be fed relevant output from nfsv3rwsnoop.d or a similar DTrace
script and then do the find in bulk.

(I can come up with a whole collection of evil ideas here, but I've
not tested any of them and perhaps someone with experience has better
ideas here.)

	- cks

From richard.elling at richardelling.com  Tue Mar 21 23:34:36 2017
From: richard.elling at richardelling.com (Richard Elling)
Date: Tue, 21 Mar 2017 16:34:36 -0700
Subject: [OmniOS-discuss] nfsv3rwsnoop.d lists NFS writes to <unknown>
	files
In-Reply-To: <58D1AF15.5040706@btconnect.com>
References: <58D1AF15.5040706@btconnect.com>
Message-ID: <224F2FDE-E0F2-468C-B42E-D17B59C0B584@richardelling.com>


> On Mar 21, 2017, at 3:54 PM, Richard Skelton <skeltonr at btconnect.com> wrote:
> 
> Hi,
> I am using the dtrace script nfsv3rwsnoop.d to find file that are accessed from my OmniOS r151020 filer and some file names are listed as unknown :-(
> I guess they are files that have been open for a long time and have dropped out of some data structure.

almost... they are files that were open prior to the dtrace script running or they are files
which have been deleted (!), such that there is no mapping between the nfs file handle and
the current file system

> Is there any way to increase the persistence of the name stored.
> I have lots on memory in this system and would be happy to sacrifice some if I could see more file name :-)

depending on what you wish to accomplish, dtrace might be the wrong tool and you might
want auditing or NFS logging instead 
 ? richard

> 
> root at filer:/scratch# /root/dtrace/nfsv3rwsnoop.d |more
> 1189849649391    xxx.xx.xxx.59       W 10500    138879 <unknown>
> 1189849649582    xxx.xx.xxx.59       W 10500    137788 <unknown>
> 1189849740621    xxx.xx.xxx.118      W 0          2404 <unknown>
> 1189849781136    xxx.xx.xxx.109      W 19832    756675 /scratch/run.log
> 1189849849301    xxx.xx.xxx.102      W 1096      57513 /scratch/avm_remote_job_f64ccf56-efa1-4605-8a48-874816779289_2.out
> Cheers
> Richard
> 
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

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

From danmcd at omniti.com  Wed Mar 22 00:21:13 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 21 Mar 2017 20:21:13 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
Message-ID: <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>


> On Mar 21, 2017, at 5:51 PM, Arne <mailing-list-omnios at kopierkatze.net> wrote:
> 
> Other websites lists this as an NVMe 1.1 device, though.

If it's NVMe 1.1, it should work with bloody.

I wonder if "grep nvme /var/adm/messages" would show you anything booting off of the bloody one.

Also, that "prtconf -vp" output I asked for earlier may be useful as well.

Dan


From mailing-list-omnios at kopierkatze.net  Wed Mar 22 07:28:00 2017
From: mailing-list-omnios at kopierkatze.net (Arne)
Date: Wed, 22 Mar 2017 08:28:00 +0100
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
	<3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
Message-ID: <47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>

There is no file "/var/adm/messages" and there is no file "messages" 
anywhere else either ("find /var -name 'mess*'" returns nothing).

Under "/var/adm" there are only 4 directory ("exacct", "log", "pool", 
"streams", all of them are empty) and 2 files: "utmpx" and "wtmpx".
Neither of them matches "nvme".


This is the output of "prtconf -vp":
--------------------------------------------------------------------------------
System Configuration:  Supermicro  i86pc
Memory size: 65358 Megabytes
System Peripherals (PROM Nodes):

ld.so.1: prtconf: fatal: libnvpair.so.1: open failed: No such file or 
directory
ld.so.1: prtconf: fatal: relocation error: file /usr/sbin/amd64/prtconf: 
symbol nvlist_unpack: referenced symbol not found
Killed
--------------------------------------------------------------------------------

So something seems wrong here as well...


-------- Original Message  --------
Subject: Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
From: Dan McDonald <danmcd at omniti.com>
To: Arne <mailing-list-omnios at kopierkatze.net>
Date: Wed Mar 22 2017 01:21:13 GMT+0100

>
> If it's NVMe 1.1, it should work with bloody.
>
> I wonder if "grep nvme /var/adm/messages" would show you anything booting off of the bloody one.
>
> Also, that "prtconf -vp" output I asked for earlier may be useful as well.
>
> Dan
>

From skeltonr at btconnect.com  Wed Mar 22 07:54:24 2017
From: skeltonr at btconnect.com (Richard Skelton)
Date: Wed, 22 Mar 2017 07:54:24 +0000
Subject: [OmniOS-discuss] nfsv3rwsnoop.d lists NFS writes to <unknown>
 files
In-Reply-To: <224F2FDE-E0F2-468C-B42E-D17B59C0B584@richardelling.com>
References: <58D1AF15.5040706@btconnect.com>
	<224F2FDE-E0F2-468C-B42E-D17B59C0B584@richardelling.com>
Message-ID: <58D22DB0.6000503@btconnect.com>

Hi Richard,
The nfsv3rwsnoop.d script shows to offset to the write as 0 is this then
not a new file?

TIME(us)         CLIENT             OP OFFSET    BYTES PATHNAME
20811423544560   xxx.xx.xxx.21       W 0           116 <unknown>
20811423525741   xxx.xx.xxx.50       W 0          5232 <unknown>
20811423528311   xxx.xx.xxx.50       W 0           304 <unknown>
20811423529251   xxx.xx.xxx.50       W 0           376 <unknown>
20811423555753   xxx.xx.xxx.18       R 0           685 <unknown>

If they are files which have been deleted they must be very short lived
files ?

Richard Elling wrote:
>
>> On Mar 21, 2017, at 3:54 PM, Richard Skelton <skeltonr at btconnect.com
>> <mailto:skeltonr at btconnect.com>> wrote:
>>
>> Hi,
>> I am using the dtrace script nfsv3rwsnoop.d to find file that are
>> accessed from my OmniOS r151020 filer and some file names are listed
>> as unknown :-(
>> I guess they are files that have been open for a long time and have
>> dropped out of some data structure.
>
> almost... they are files that were open prior to the dtrace script
> running or they are files
> which have been deleted (!), such that there is no mapping between the
> nfs file handle and
> the current file system
>
>> Is there any way to increase the persistence of the name stored.
>> I have lots on memory in this system and would be happy to sacrifice
>> some if I could see more file name :-)
>
> depending on what you wish to accomplish, dtrace might be the wrong
> tool and you might
> want auditing or NFS logging instead 
>  ? richard
>
>>
>> root at filer:/scratch# /root/dtrace/nfsv3rwsnoop.d |more
>>
>> 1189849649391    xxx.xx.xxx.59       W 10500    138879 <unknown>
>> 1189849649582    xxx.xx.xxx.59       W 10500    137788 <unknown>
>> 1189849740621    xxx.xx.xxx.118      W 0          2404 <unknown>
>> 1189849781136    xxx.xx.xxx.109      W 19832    756675 /scratch/run.log
>> 1189849849301    xxx.xx.xxx.102      W 1096      57513
>> /scratch/avm_remote_job_f64ccf56-efa1-4605-8a48-874816779289_2.out
>>
>> Cheers
>> Richard
>>
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com>
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170322/e3761dfe/attachment-0001.html>

From danmcd at omniti.com  Wed Mar 22 15:00:14 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 22 Mar 2017 11:00:14 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
	<3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
	<47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>
Message-ID: <6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com>


> On Mar 22, 2017, at 3:28 AM, Arne <mailing-list-omnios at kopierkatze.net> wrote:
> 
> This is the output of "prtconf -vp":
> --------------------------------------------------------------------------------
> System Configuration:  Supermicro  i86pc
> Memory size: 65358 Megabytes
> System Peripherals (PROM Nodes):
> 
> ld.so.1: prtconf: fatal: libnvpair.so.1: open failed: No such file or directory
> ld.so.1: prtconf: fatal: relocation error: file /usr/sbin/amd64/prtconf: symbol nvlist_unpack: referenced symbol not found
> Killed
> --------------------------------------------------------------------------------
> 
> So something seems wrong here as well...

It means we need to add at least libnvpair to the Kayak-for-ISO wad.  Thank you for finding this bug.

Dan


From mailing-list-omnios at kopierkatze.net  Wed Mar 22 16:15:56 2017
From: mailing-list-omnios at kopierkatze.net (Arne)
Date: Wed, 22 Mar 2017 17:15:56 +0100
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
	<3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
	<47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>
	<6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com>
Message-ID: <fbcefec2-62ba-45c3-fba8-8e9d84b0ef6e@kopierkatze.net>

What is the impact of this bug with libnvpair?

a) Is this only responsible for non-working "prtconf"? (I guess 
"prtconf" is some kind of system overview tool!?)

b) Is it also responsible for the non-working NVMe SSD?


-------- Original Message  --------
Subject: Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
From: Dan McDonald <danmcd at omniti.com>
To: Arne <mailing-list-omnios at kopierkatze.net>, Dan McDonald 
<danmcd at omniti.com>
Date: Wed Mar 22 2017 16:00:14 GMT+0100

>
> It means we need to add at least libnvpair to the Kayak-for-ISO wad.  Thank you for finding this bug.
>
> Dan
>

From danmcd at omniti.com  Wed Mar 22 18:01:17 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 22 Mar 2017 14:01:17 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <fbcefec2-62ba-45c3-fba8-8e9d84b0ef6e@kopierkatze.net>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
	<3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
	<47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>
	<6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com>
	<fbcefec2-62ba-45c3-fba8-8e9d84b0ef6e@kopierkatze.net>
Message-ID: <7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com>


> On Mar 22, 2017, at 12:15 PM, Arne <mailing-list-omnios at kopierkatze.net> wrote:
> 
> What is the impact of this bug with libnvpair?
> 
> a) Is this only responsible for non-working "prtconf"? (I guess "prtconf" is some kind of system overview tool!?)

Correct.

> b) Is it also responsible for the non-working NVMe SSD?

No.  Not correct.

Please try this ISO:

	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

which now has a working prtconf (because /lib/amd64/libnvpair.so... is now there).  Then please share "prtconf -v" and "prtconf -vp" output.  (You should be able to bring up a network interface using the installer shell.)

Thanks,
Dan


From richard.elling at richardelling.com  Wed Mar 22 21:21:46 2017
From: richard.elling at richardelling.com (Richard Elling)
Date: Wed, 22 Mar 2017 14:21:46 -0700
Subject: [OmniOS-discuss] nfsv3rwsnoop.d lists NFS writes to <unknown>
 files
In-Reply-To: <58D22DB0.6000503@btconnect.com>
References: <58D1AF15.5040706@btconnect.com>
	<224F2FDE-E0F2-468C-B42E-D17B59C0B584@richardelling.com>
	<58D22DB0.6000503@btconnect.com>
Message-ID: <090EE2CE-7657-4D87-AFDF-D18646FB030A@richardelling.com>


> On Mar 22, 2017, at 12:54 AM, Richard Skelton <skeltonr at btconnect.com> wrote:
> 
> Hi Richard,
> The nfsv3rwsnoop.d script shows to offset to the write as 0 is this then not a new file?

not necessarily

> TIME(us)         CLIENT             OP OFFSET    BYTES PATHNAME
> 20811423544560   xxx.xx.xxx.21       W 0           116 <unknown>
> 20811423525741   xxx.xx.xxx.50       W 0          5232 <unknown>
> 20811423528311   xxx.xx.xxx.50       W 0           304 <unknown>
> 20811423529251   xxx.xx.xxx.50       W 0           376 <unknown>
> 20811423555753   xxx.xx.xxx.18       R 0           685 <unknown>
> If they are files which have been deleted they must be very short lived files ?

not necessarily

If you want auditing, you need auditing tools and dtrace is not the right tool
 -- richard

> 
> Richard Elling wrote:
>> 
>> 
>>> On Mar 21, 2017, at 3:54 PM, Richard Skelton <skeltonr at btconnect.com <mailto:skeltonr at btconnect.com>> wrote:
>>> 
>>> Hi,
>>> I am using the dtrace script nfsv3rwsnoop.d to find file that are accessed from my OmniOS r151020 filer and some file names are listed as unknown :-(
>>> I guess they are files that have been open for a long time and have dropped out of some data structure.
>> 
>> almost... they are files that were open prior to the dtrace script running or they are files
>> which have been deleted (!), such that there is no mapping between the nfs file handle and
>> the current file system
>> 
>>> Is there any way to increase the persistence of the name stored.
>>> I have lots on memory in this system and would be happy to sacrifice some if I could see more file name :-)
>> 
>> depending on what you wish to accomplish, dtrace might be the wrong tool and you might
>> want auditing or NFS logging instead 
>>  ? richard
>> 
>>> 
>>> root at filer:/scratch# /root/dtrace/nfsv3rwsnoop.d |more
>>> 1189849649391    xxx.xx.xxx.59       W 10500    138879 <unknown>
>>> 1189849649582    xxx.xx.xxx.59       W 10500    137788 <unknown>
>>> 1189849740621    xxx.xx.xxx.118      W 0          2404 <unknown>
>>> 1189849781136    xxx.xx.xxx.109      W 19832    756675 /scratch/run.log
>>> 1189849849301    xxx.xx.xxx.102      W 1096      57513 /scratch/avm_remote_job_f64ccf56-efa1-4605-8a48-874816779289_2.out
>>> Cheers
>>> Richard
>>> 
>>> 
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com>
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>> 

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

From mailing-list-omnios at kopierkatze.net  Thu Mar 23 15:20:01 2017
From: mailing-list-omnios at kopierkatze.net (Arne)
Date: Thu, 23 Mar 2017 16:20:01 +0100
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
	<3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
	<47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>
	<6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com>
	<fbcefec2-62ba-45c3-fba8-8e9d84b0ef6e@kopierkatze.net>
	<7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com>
Message-ID: <d6a8b38a-37b6-2542-bfc1-178c1c2d6ad5@kopierkatze.net>


Thanks for creating the updated ISO. I can now mount that disc to the 
IPMI's virtual drive, which is a lot more convenient!
"prtconf -v" and "prtconf -vp" also work fine now.

Unfortunately I am unable to capture their output. I tried several ways:

a) Network. Problem: The OmniOS installer won't recognize my Intel X550 
10G network card.

b) Serial-over-LAN. Problem: I can see everything including the OmniOS 
installer bootloader, but afterwards serial output stops. There seems to 
be no option to enable serial console output for the main installer!?

c) USB stick. Problem: How to identify the USB stick in the installer 
shell? There is no "rmformat" to identify the device. "ls -l 
/dev/rdsk/c*0" only showed the CD-ROM.
The USB stick will probably not work at all because there is no XHCI 
support in the installer, I guess.

Any ideas?


Anyway, I just ran "devfsadm -C" and I saw this output:
"nvme0: NVMe spec version 1.2"

This suggests that the SSD is indeed a NVM 1.2 SSD. :-(
But I still did not find a proper datasheet or any (Linux, ...) tool to 
identify the NVMe level.

What are your plans to support NVMe 1.2?


-------- Original Message  --------
Subject: Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
From: Dan McDonald <danmcd at omniti.com>
To: Arne <mailing-list-omnios at kopierkatze.net>, Dan McDonald 
<danmcd at omniti.com>
Date: Wed Mar 22 2017 19:01:17 GMT+0100

>
> Please try this ISO:
>
> 	http://kebe.com/~danmcd/webrevs/r151021-kayak.iso
>
> which now has a working prtconf (because /lib/amd64/libnvpair.so... is now there).  Then please share "prtconf -v" and "prtconf -vp" output.  (You should be able to bring up a network interface using the installer shell.)
>
> Thanks,
> Dan
>

From danmcd at omniti.com  Thu Mar 23 15:43:47 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 23 Mar 2017 11:43:47 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <d6a8b38a-37b6-2542-bfc1-178c1c2d6ad5@kopierkatze.net>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
	<3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
	<47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>
	<6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com>
	<fbcefec2-62ba-45c3-fba8-8e9d84b0ef6e@kopierkatze.net>
	<7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com>
	<d6a8b38a-37b6-2542-bfc1-178c1c2d6ad5@kopierkatze.net>
Message-ID: <B40ADA0B-47E2-4725-B194-F612366D6B58@omniti.com>


> On Mar 23, 2017, at 11:20 AM, Arne <mailing-list-omnios at kopierkatze.net> wrote:
> 
> 
> Thanks for creating the updated ISO. I can now mount that disc to the IPMI's virtual drive, which is a lot more convenient!
> "prtconf -v" and "prtconf -vp" also work fine now.

Good!

> Unfortunately I am unable to capture their output. I tried several ways:
> 
> a) Network. Problem: The OmniOS installer won't recognize my Intel X550 10G network card.

We *have* support for X550.  ESPECIALLY in bloody. I wonder what happened?

> b) Serial-over-LAN. Problem: I can see everything including the OmniOS installer bootloader, but afterwards serial output stops. There seems to be no option to enable serial console output for the main installer!?

There is, but it involves interacting with Loader.  Menu option #5 on the loader screen can dink with that.  Basically, you have to boot OmniOS mentioning console-output on the command line.

> c) USB stick. Problem: How to identify the USB stick in the installer shell? There is no "rmformat" to identify the device. "ls -l /dev/rdsk/c*0" only showed the CD-ROM.
> The USB stick will probably not work at all because there is no XHCI support in the installer, I guess.

There is XHCI support in the bloody installer.  It was part of the bloody update last week.  There's still one fixed-but-not-yet-pushed bug, but that shouldn't affect USB sticks... at least I think it shouldn't.

> Anyway, I just ran "devfsadm -C" and I saw this output:
> "nvme0: NVMe spec version 1.2"

Aha.

> This suggests that the SSD is indeed a NVM 1.2 SSD. :-(
> But I still did not find a proper datasheet or any (Linux, ...) tool to identify the NVMe level.
> 
> What are your plans to support NVMe 1.2?

We can override the NVMe settings to support 1.2 devices, but we can't support all of the 1.2 improvements (e.g. namespaces).  Colleague Dale Ghent, who's spent time both in ixgbe (he put X550 support into illumos and therefore OmniOS) and NVMe can speak more, but I don't think he'll disagree with anything I've said here.

The big question to my mind is whether or not we should just support NVMe 1.2 devices out of the box (and out of the Installer ISO).

Dan


From wonko at 4amlunch.net  Thu Mar 23 15:53:47 2017
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Thu, 23 Mar 2017 11:53:47 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <B40ADA0B-47E2-4725-B194-F612366D6B58@omniti.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
	<3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
	<47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>
	<6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com>
	<fbcefec2-62ba-45c3-fba8-8e9d84b0ef6e@kopierkatze.net>
	<7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com>
	<d6a8b38a-37b6-2542-bfc1-178c1c2d6ad5@kopierkatze.net>
	<B40ADA0B-47E2-4725-B194-F612366D6B58@omniti.com>
Message-ID: <CB140698-699A-444E-BB17-A6E1A2C0244F@4amlunch.net>


>> This suggests that the SSD is indeed a NVM 1.2 SSD. :-(
>> But I still did not find a proper datasheet or any (Linux, ...) tool to identify the NVMe level.
>> 
>> What are your plans to support NVMe 1.2?
> 
> We can override the NVMe settings to support 1.2 devices, but we can't support all of the 1.2 improvements (e.g. namespaces).  Colleague Dale Ghent, who's spent time both in ixgbe (he put X550 support into illumos and therefore OmniOS) and NVMe can speak more, but I don't think he'll disagree with anything I've said here.
> 
> The big question to my mind is whether or not we should just support NVMe 1.2 devices out of the box (and out of the Installer ISO).

Has the issue with the Samsung drives been fixed? I haven?t tried it lately, but the 950 Pros were hanging. Those are 1.2a devices though, so I don?t know if that matters.

Just worried that enabling 1.2 might result in crashy systems.

-brian

From danmcd at omniti.com  Thu Mar 23 16:01:11 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 23 Mar 2017 12:01:11 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <CB140698-699A-444E-BB17-A6E1A2C0244F@4amlunch.net>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
	<3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
	<47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>
	<6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com>
	<fbcefec2-62ba-45c3-fba8-8e9d84b0ef6e@kopierkatze.net>
	<7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com>
	<d6a8b38a-37b6-2542-bfc1-178c1c2d6ad5@kopierkatze.net>
	<B40ADA0B-47E2-4725-B194-F612366D6B58@omniti.com>
	<CB140698-699A-444E-BB17-A6E1A2C0244F@4amlunch.net>
Message-ID: <1AC1812B-8210-4853-AD1F-C3785372FC6A@omniti.com>


> On Mar 23, 2017, at 11:53 AM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> 
> Has the issue with the Samsung drives been fixed? I haven?t tried it lately, but the 950 Pros were hanging. Those are 1.2a devices though, so I don?t know if that matters.
> 
> Just worried that enabling 1.2 might result in crashy systems.
> 

No idea, and "crashy systems" is why it's not turned on by default today.

Thank you for the reality check!
Dan


From wonko at 4amlunch.net  Thu Mar 23 16:37:08 2017
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Thu, 23 Mar 2017 12:37:08 -0400
Subject: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
In-Reply-To: <1AC1812B-8210-4853-AD1F-C3785372FC6A@omniti.com>
References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com>
	<alpine.GSO.2.20.1703211429440.23644@scrappy.simplesystems.org>
	<D215FDBD-746F-4E1B-8B14-848C9BD7604B@omniti.com>
	<alpine.GSO.2.20.1703211442590.23644@scrappy.simplesystems.org>
	<AE124A90-F079-43DA-AC21-5CC4CAFCB428@omniti.com>
	<4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net>
	<8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com>
	<4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com>
	<e8c96be0-e407-2d20-5c11-40eb4ab0e4f7@kopierkatze.net>
	<3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com>
	<47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net>
	<6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com>
	<fbcefec2-62ba-45c3-fba8-8e9d84b0ef6e@kopierkatze.net>
	<7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com>
	<d6a8b38a-37b6-2542-bfc1-178c1c2d6ad5@kopierkatze.net>
	<B40ADA0B-47E2-4725-B194-F612366D6B58@omniti.com>
	<CB140698-699A-444E-BB17-A6E1A2C0244F@4amlunch.net>
	<1AC1812B-8210-4853-AD1F-C3785372FC6A@omniti.com>
Message-ID: <E7A06A17-FC05-4BC4-B7D5-FCB447BDA5BA@4amlunch.net>


> On Mar 23, 2017, at 12:01, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Mar 23, 2017, at 11:53 AM, Brian Hechinger <wonko at 4amlunch.net> wrote:
>> 
>> Has the issue with the Samsung drives been fixed? I haven?t tried it lately, but the 950 Pros were hanging. Those are 1.2a devices though, so I don?t know if that matters.
>> 
>> Just worried that enabling 1.2 might result in crashy systems.
>> 
> 
> No idea, and "crashy systems" is why it's not turned on by default today.

Fix it, fix it, fix it, fix it, fix it, fix it!

> Thank you for the reality check!

Yay, I?m useful! :-D

-brian

From stephan.budach at jvm.de  Thu Mar 23 17:05:19 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Thu, 23 Mar 2017 18:05:19 +0100 (CET)
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
 HVM and an "xdf" Device
In-Reply-To: <CAGDMPV9H-ONWnzJYPQ-yYCqfZ8_KBE6WJek2pXnpPSfHZTyCeg@mail.gmail.com>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
	<939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
	<CAGDMPV9H-ONWnzJYPQ-yYCqfZ8_KBE6WJek2pXnpPSfHZTyCeg@mail.gmail.com>
Message-ID: <505799553.385.1490288723840.JavaMail.stephan.budach@stephanbudach.local>

Hi, 

following-up on this thread, I managed to get the current r151021 ISO booting and installing on my Oracle VM Xen host - yay!! 

I have installed and tweaked /etc/system such as that the system boots up sucessfully. However, I am unable to configure the network card, since as soon as I am trying ipadm create-addr on it, omniOS crashes, dumps a core and reboots. 

Another interesting issue may be the fact that format shows two disks c1d0 <QEMU HARDDISK> and c2t0d0 <Unknown-Unknown>, when there is only one disk in the system anyway and rpool has been installed on c3t0d0. 

Also, there're some occasional log messages to the console about a PCI device from which no SOF interrupts have been received and which is an unusable USB UHCI host controller at this point. 

Cheers, 
Stephan 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170323/59376fab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170323/59376fab/attachment-0001.bin>

From danmcd at omniti.com  Thu Mar 23 17:08:11 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 23 Mar 2017 13:08:11 -0400
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
	HVM and an "xdf" Device
In-Reply-To: <505799553.385.1490288723840.JavaMail.stephan.budach@stephanbudach.local>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
	<939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
	<CAGDMPV9H-ONWnzJYPQ-yYCqfZ8_KBE6WJek2pXnpPSfHZTyCeg@mail.gmail.com>
	<505799553.385.1490288723840.JavaMail.stephan.budach@stephanbudach.local>
Message-ID: <91EB08F9-14D9-4408-83A7-AD5D4E13277F@omniti.com>

Share kernel core dumps please so we can debug them please.

Dan

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

> On Mar 23, 2017, at 1:05 PM, Stephan Budach <stephan.budach at jvm.de> wrote:
> 
> Hi,
> 
> following-up on this thread, I managed to get the current r151021 ISO booting and installing on my Oracle VM Xen host - yay!!
> 
> I have installed and tweaked /etc/system such as that the system boots up sucessfully. However, I am unable to configure the network card, since as soon as I am trying ipadm create-addr on it, omniOS crashes, dumps a core and reboots.
> 
> Another interesting issue may be the fact that format shows two disks c1d0 <QEMU HARDDISK> and c2t0d0 <Unknown-Unknown>, when there is only one disk in the system anyway and rpool has been installed on c3t0d0.
> 
> Also, there're some occasional log messages to the console about  a PCI device from which no SOF interrupts have been received and which is an unusable USB UHCI host controller at this point.
> 
> Cheers,
> Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170323/56cba6a0/attachment.html>

From stephan.budach at jvm.de  Thu Mar 23 17:43:04 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Thu, 23 Mar 2017 18:43:04 +0100 (CET)
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
 HVM and an "xdf" Device
In-Reply-To: <91EB08F9-14D9-4408-83A7-AD5D4E13277F@omniti.com>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
	<939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
	<CAGDMPV9H-ONWnzJYPQ-yYCqfZ8_KBE6WJek2pXnpPSfHZTyCeg@mail.gmail.com>
	<505799553.385.1490288723840.JavaMail.stephan.budach@stephanbudach.local>
	<91EB08F9-14D9-4408-83A7-AD5D4E13277F@omniti.com>
Message-ID: <1029234274.426.1490290985889.JavaMail.stephan.budach@stephanbudach.local>

Ha ha? yeah? I will try. Howerver, without any network connectivity, I will be having quite a hard time getting those dumps from the guest anywhere. 


Cheers, 
Stephan 

----- Urspr?ngliche Mail -----


Von: "Dan McDonald" <danmcd at omniti.com> 
An: "Stephan Budach" <stephan.budach at jvm.de>, "Dan McDonald" <danmcd at omniti.com> 
CC: "Prakash Surya" <prakash.surya at delphix.com>, "omnios-discuss" <omnios-discuss at lists.omniti.com> 
Gesendet: Donnerstag, 23. M?rz 2017 18:08:11 
Betreff: Re: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen HVM and an "xdf" Device 


Share kernel core dumps please so we can debug them please. 


Dan 

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

On Mar 23, 2017, at 1:05 PM, Stephan Budach < stephan.budach at jvm.de > wrote: 


<blockquote>



Hi, 


following-up on this thread, I managed to get the current r151021 ISO booting and installing on my Oracle VM Xen host - yay!! 


I have installed and tweaked /etc/system such as that the system boots up sucessfully. However, I am unable to configure the network card, since as soon as I am trying ipadm create-addr on it, omniOS crashes, dumps a core and reboots. 


Another interesting issue may be the fact that format shows two disks c1d0 <QEMU HARDDISK> and c2t0d0 <Unknown-Unknown>, when there is only one disk in the system anyway and rpool has been installed on c3t0d0. 


Also, there're some occasional log messages to the console about a PCI device from which no SOF interrupts have been received and which is an unusable USB UHCI host controller at this point. 


Cheers, 
Stephan 


</blockquote>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170323/af79fdfd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170323/af79fdfd/attachment.bin>

From danmcd at omniti.com  Thu Mar 23 17:45:01 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 23 Mar 2017 13:45:01 -0400
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
 HVM and an "xdf" Device
In-Reply-To: <1029234274.426.1490290985889.JavaMail.stephan.budach@stephanbudach.local>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
	<939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
	<CAGDMPV9H-ONWnzJYPQ-yYCqfZ8_KBE6WJek2pXnpPSfHZTyCeg@mail.gmail.com>
	<505799553.385.1490288723840.JavaMail.stephan.budach@stephanbudach.local>
	<91EB08F9-14D9-4408-83A7-AD5D4E13277F@omniti.com>
	<1029234274.426.1490290985889.JavaMail.stephan.budach@stephanbudach.local>
Message-ID: <92B00EF0-A51B-4FF0-BB17-BD38F638FCD5@omniti.com>


> On Mar 23, 2017, at 1:43 PM, Stephan Budach <stephan.budach at jvm.de> wrote:
> 
> Ha ha? yeah? I will try. Howerver, without any network connectivity, I will be having quite a hard time getting those dumps from the guest anywhere.

Can you maybe use the virtual-disks and attach them to a system with working network connectivity?

Just a thought,
Dan


From stephan.budach at jvm.de  Thu Mar 23 17:53:18 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Thu, 23 Mar 2017 18:53:18 +0100 (CET)
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
 HVM and an "xdf" Device
In-Reply-To: <92B00EF0-A51B-4FF0-BB17-BD38F638FCD5@omniti.com>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
	<939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
	<CAGDMPV9H-ONWnzJYPQ-yYCqfZ8_KBE6WJek2pXnpPSfHZTyCeg@mail.gmail.com>
	<505799553.385.1490288723840.JavaMail.stephan.budach@stephanbudach.local>
	<91EB08F9-14D9-4408-83A7-AD5D4E13277F@omniti.com>
	<1029234274.426.1490290985889.JavaMail.stephan.budach@stephanbudach.local>
	<92B00EF0-A51B-4FF0-BB17-BD38F638FCD5@omniti.com>
Message-ID: <905977756.438.1490291600950.JavaMail.stephan.budach@stephanbudach.local>



----- Urspr?ngliche Mail -----
> Von: "Dan McDonald" <danmcd at omniti.com>
> An: "Stephan Budach" <stephan.budach at jvm.de>, "Dan McDonald" <danmcd at omniti.com>
> CC: "Prakash Surya" <prakash.surya at delphix.com>, "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Donnerstag, 23. M?rz 2017 18:45:01
> Betreff: Re: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen HVM and an "xdf" Device
> 
> 
> > On Mar 23, 2017, at 1:43 PM, Stephan Budach <stephan.budach at jvm.de>
> > wrote:
> > 
> > Ha ha? yeah? I will try. Howerver, without any network
> > connectivity, I will be having quite a hard time getting those
> > dumps from the guest anywhere.
> 
> Can you maybe use the virtual-disks and attach them to a system with
> working network connectivity?
> 
> Just a thought,
> Dan
> 
> 
Yes, this is what I also thought, but the guest would need to be able to read the rpool. Will Solaris 11 be able to mount the rpool or is the underlying zpool version too far off? Solaris 11 runs as guest on Oracle VM?

Other than that, I could try to transfer the vdisk itself over to a omniOS box and just try to mount there. There was something about some offset, when doing this? with vdisk images, which I vaguely remember? ;)

Stephan

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

From danmcd at omniti.com  Fri Mar 24 03:53:08 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 23 Mar 2017 23:53:08 -0400
Subject: [OmniOS-discuss] Fwd: SMB file locking problem in r151020 vs r151012
Message-ID: <651A0DAB-1C18-4DD0-AF26-31C69E66D62C@omniti.com>

From he bounced file...

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

Begin forwarded message:

> We have a legacy billing app that writes thousand of files to an SMB share on an OmniOS file server twice a month when we do billing.  It had been running r151012 for over a year but was recently upgraded to r151020.  I don?t remember the exact timing ? but think we did the upgrade, rejoined it to the domain, and let it sit for about a month to see if there were any problems.  In this time, everything continued to work fine.  However, eventually, I got tired of seeing the ?pool needs upgraded? message in the scrub emails, so we did a zpool upgrade, at which point the software that writes to the share started having problems (the developers say with file locking).  I still have the r151012 BE, but am uncertain what will happen when I boot back into it ? will the pool degrade gracefully to only the features that older release knows about?  I?m not certain this is even an OmniOS/ZFS bug, but given that was the only change we can think of during the timeframe when the problem popped up, it seems a possibility ? so I thought I?d ask the list if anyone else has seen anything like this or has ideas how to troubleshoot?

From geoffn at gnaa.net  Fri Mar 24 04:42:44 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Thu, 23 Mar 2017 21:42:44 -0700
Subject: [OmniOS-discuss] Fwd: SMB file locking problem in r151020 vs
 r151012
In-Reply-To: <651A0DAB-1C18-4DD0-AF26-31C69E66D62C@omniti.com>
References: <651A0DAB-1C18-4DD0-AF26-31C69E66D62C@omniti.com>
Message-ID: <1a655e3d-2b89-3496-745a-e46909f16852@gnaa.net>

On 2017-03-23 08:53 PM, Dan McDonald wrote:
>  From he bounced file...
>
> Sent from my iPhone (typos, autocorrect, and all)
>
> Begin forwarded message:
>
>> We have a legacy billing app that writes thousand of files to an SMB share on an OmniOS file server twice a month when we do billing.  It had been running r151012 for over a year but was recently upgraded to r151020.  I don?t remember the exact timing ? but think we did the upgrade, rejoined it to the domain, and let it sit for about a month to see if there were any problems.  In this time, everything continued to work fine.  However, eventually, I got tired of seeing the ?pool needs upgraded? message in the scrub emails, so we did a zpool upgrade, at which point the software that writes to the share started having problems (the developers say with file locking).  I still have the r151012 BE, but am uncertain what will happen when I boot back into it ? will the pool degrade gracefully to only the features that older release knows about?  I?m not certain this is even an OmniOS/ZFS bug, but given that was the only change we can think of during the timeframe when the problem popped up, it seems a possibility ? so I thought I?d ask the list if anyone else has seen anything like this or has ideas how to troubleshoot?
> ___

After an upgrade I had problems with some applications.   I had to 
disable the oplock.

svccfg -s network/smb/server setprop smbd/oplock_enable=false


Wonder if that setting will fix anything.

Geoff

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

From stephan.budach at jvm.de  Fri Mar 24 13:46:02 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Fri, 24 Mar 2017 14:46:02 +0100 (CET)
Subject: [OmniOS-discuss] Quick Test of r151021 ISO Install using Xen
 HVM and an "xdf" Device
In-Reply-To: <905977756.438.1490291600950.JavaMail.stephan.budach@stephanbudach.local>
References: <CAGDMPV-Gb_iXT1=A_+YuQW+srJU9gphhHWakL6qt596C5-zj0w@mail.gmail.com>
	<4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com>
	<CAGDMPV9H-ONWnzJYPQ-yYCqfZ8_KBE6WJek2pXnpPSfHZTyCeg@mail.gmail.com>
	<505799553.385.1490288723840.JavaMail.stephan.budach@stephanbudach.local>
	<91EB08F9-14D9-4408-83A7-AD5D4E13277F@omniti.com>
	<1029234274.426.1490290985889.JavaMail.stephan.budach@stephanbudach.local>
	<92B00EF0-A51B-4FF0-BB17-BD38F638FCD5@omniti.com>
	<905977756.438.1490291600950.JavaMail.stephan.budach@stephanbudach.local>
Message-ID: <2007747064.1173.1490363161542.JavaMail.stephan.budach@stephan.budach.jvm.de>

Hi,

I have started out by simply copying the Xen disk image over to a omniOS host, where I attached the disk image using lofiadm. I then immediately tried zpool import -d /dev/lofi, but that didn't output anything. I then ran prtvtoc on the lofi device:

root at tr1207410:/tr1207410data01# prtvtoc /dev/lofi/1
* /dev/lofi/1 (volume "lofi") partition map
*
* Dimensions:
*     512 bytes/sector
*    1449 sectors/track
*       1 tracks/cylinder
*    1449 sectors/cylinder
*   46312 cylinders
*   46312 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      0    01          0  67106088  67106087
This is what fdisk says about this volume:

root at tr1207410:/tr1207410data01# fdisk -R /dev/rlofi/1
             Total disk size is 46312 cylinders
             Cylinder size is 1449 (512 byte) blocks

                                               Cylinders
      Partition   Status    Type          Start   End   Length    %
      =========   ======    ============  =====   ===   ======   ===
          1                 EFI               0  46313    46314    100


So? there is something there, but how to mount that sucker?

Cheers,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170324/db5859b8/attachment.bin>

From bfriesen at simple.dallas.tx.us  Tue Mar 28 13:43:01 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Tue, 28 Mar 2017 08:43:01 -0500 (CDT)
Subject: [OmniOS-discuss] WARNING: High TCP connect timeout rate! System
 (port 80) may be under a SYN flood attack!
Message-ID: <alpine.GSO.2.20.1703280837190.785@freddy.simplesystems.org>

Since updating OmniOS to r151020, I have been seeing many "SYN flood 
attack!" warnings on the system console.  I never saw these before.

Has something changed in the TCP/IP stack which now produces these 
warnings or has my server been co-incidentally targeted for SYN flood 
attacks and was not targeted before?

Are other users seeing these warnings?

I have 45 such alerts posted since Febrary 27 (in the 
/var/adm/messages* files).

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

From daleg at omniti.com  Tue Mar 28 14:24:02 2017
From: daleg at omniti.com (Dale Ghent)
Date: Tue, 28 Mar 2017 10:24:02 -0400
Subject: [OmniOS-discuss] WARNING: High TCP connect timeout rate! System
 (port 80) may be under a SYN flood attack!
In-Reply-To: <alpine.GSO.2.20.1703280837190.785@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1703280837190.785@freddy.simplesystems.org>
Message-ID: <E6A71C4C-20DA-4A5B-B817-A17449A53525@omniti.com>


Likely coincidence. Have you managed to catch one of these in the act and inspected netstat and snoop/tcpdump output?

/dale

> On Mar 28, 2017, at 9:43 AM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> 
> Since updating OmniOS to r151020, I have been seeing many "SYN flood attack!" warnings on the system console.  I never saw these before.
> 
> Has something changed in the TCP/IP stack which now produces these warnings or has my server been co-incidentally targeted for SYN flood attacks and was not targeted before?
> 
> Are other users seeing these warnings?
> 
> I have 45 such alerts posted since Febrary 27 (in the /var/adm/messages* files).
> 
> Bob
> --
> Bob Friesenhahn
> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.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: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170328/fb09ec15/attachment-0001.bin>

From bfriesen at simple.dallas.tx.us  Tue Mar 28 15:50:04 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Tue, 28 Mar 2017 10:50:04 -0500 (CDT)
Subject: [OmniOS-discuss] WARNING: High TCP connect timeout rate! System
 (port 80) may be under a SYN flood attack!
In-Reply-To: <E6A71C4C-20DA-4A5B-B817-A17449A53525@omniti.com>
References: <alpine.GSO.2.20.1703280837190.785@freddy.simplesystems.org>
	<E6A71C4C-20DA-4A5B-B817-A17449A53525@omniti.com>
Message-ID: <alpine.GSO.2.20.1703281045490.8010@scrappy.simplesystems.org>

On Tue, 28 Mar 2017, Dale Ghent wrote:

>
> Likely coincidence. Have you managed to catch one of these in the act and inspected netstat and snoop/tcpdump output?

I have not yet taken it to that level since it does not seem to cause 
actual harm.  I do have a host in the AT&T network somewhere in NY 
city which has been repeatedly trying to do zone transfers from my DNS 
server for at least the same duration so it is possible that this is 
related activity.

Bob

>
> /dale
>
>> On Mar 28, 2017, at 9:43 AM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
>>
>> Since updating OmniOS to r151020, I have been seeing many "SYN flood attack!" warnings on the system console.  I never saw these before.
>>
>> Has something changed in the TCP/IP stack which now produces these warnings or has my server been co-incidentally targeted for SYN flood attacks and was not targeted before?
>>
>> Are other users seeing these warnings?
>>
>> I have 45 such alerts posted since Febrary 27 (in the /var/adm/messages* files).
>>
>> Bob
>> --
>> Bob Friesenhahn
>> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
>> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>

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

From danmcd at omniti.com  Tue Mar 28 19:22:38 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 28 Mar 2017 15:22:38 -0400
Subject: [OmniOS-discuss] OmniOS bloody update
References: <35FD8F4E-855C-413B-A6E9-87B20FB5336D@kebe.com>
Message-ID: <3E205457-8E93-4D37-9260-693873B11D96@omniti.com>

Hey everybody!

There's a new bloody update.  I've updated both release media AND the pkg repo.

"uname -v" show omnios-master-b67a892, and there has been only one change to omnios-build (see below).

With this, we have two development-y items left for this bloody cycle:

   - Attempt to make ipadm(1M) work in an LX zone.

   - Link some sets of packages with the new world order of "pkg update -r" such that some packages will ALWAYS be updated in linked-image zones, regardless of "-r" or not.

So let's proceed to what's new this update:

* First off, we have severed the use of the "caiman" repo with OmniOS.  The following packages are now obsolete, and have been removed from various consolidation manifests:

   install/distribution-constructor
   install/installadm
   install/js2ai
   system/install
   system/install/auto-install
   system/install/auto-install/auto-install-common
   system/install/configuration
   system/install/media/internal
   system/install/tests
   system/install/text-install
   system/library/boot-management
   system/library/install

The prior bloody used an improved kayak to generate all release media (not just PXE and ZFS send streams).  This version is now available in the "kayak" package, with new files existing in /usr/share/kayak/.

* The du(1) command now has -A, for actual-file-size measuring.  (Thanks to OmniTI's own Dale Ghent for this one!)

* New in ZFS: Multi-threaded spa_sync().  I'm seeing 15-minute time savings on OmniOS-on-demand builds (4:30-ish down to 4:15-ish) I believe are due to this fix.

* A small USB3 bugfix that should make more USB3 drives recognizable.

* LX zones now have NFS client lockd support.  (From Joyent.)

Happy updating!
Dan


From john.barfield at bissinc.com  Tue Mar 28 21:40:26 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Tue, 28 Mar 2017 21:40:26 +0000
Subject: [OmniOS-discuss] ZFS/NFS Lockup when deleting or copying large files
Message-ID: <C0848B1F-08DA-441E-8542-192600475690@bissinc.com>

Greetings!


I have an issue with ZFS/NFS on OmniOS where copying or deleting large files causes the SAN to lockup and requires that we reboot it sometimes to recover. One customer was trying to copy a 400GB file and another tried to delete a 4TB vmdk from a vmware NFS vstore. In both situations the issue is reproducible and in both situations I cannot seem to find anything crazy happening on either of the boxes.  This doesn?t mean anything though because I?m limited in my kstat/dtrace knowledge for troubleshooting this type of behavior on illumos.

If there is an illumOS bug I?m missing or something that jumps out at ya please let me know?of if you need more detailed information I can detail both customer locations hardware, software, and operating conditions upon request.

The VMware customer is running on r151016 and the other customer is running on the latest release.

NFSv3 Only Clients

OS:
ESXi 5.5

All 64bit Linux Clients
CentOS 5,6,&7
Some Older Debian 7 Boxes

I should also note that the VMware customer experiences this same issue on two different SAN?s that are very different in hardware configurations.

The one common thread is that they are all Sun Servers. X4170 M2, X4270 M2, x4540

This thread is being posted to both the illumos email list and the omnios email list as well.

I?m looking, I guess, for a methodology to follow to trace this down and determine if it?s a bug or a misconfiguration either on the client or in ZFS or in the NFS server.

I can get someone access if so desired.

Have a great day!

John Barfield
Engineering and Stuff

M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>

[id:image001.png at 01D2837C.19B23B20]
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com<http://support.bissinc.com/> or support at bissinc.com<mailto:support at bissinc.com>

Follow us on Twitter for Network Status &  Updates!

[id:image002.gif at 01D2837C.19B23B20]<https://twitter.com/johnbarfield>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170328/4f42f443/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3509 bytes
Desc: image001.png
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170328/4f42f443/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1352 bytes
Desc: image002.gif
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170328/4f42f443/attachment-0001.gif>

From daleg at omniti.com  Tue Mar 28 22:17:05 2017
From: daleg at omniti.com (Dale Ghent)
Date: Tue, 28 Mar 2017 18:17:05 -0400
Subject: [OmniOS-discuss] [ANN] Security update for NTP
Message-ID: <B12DD77B-4709-4B96-8E36-3D72AF5D89A9@omniti.com>


A new version of the service/network/ntp package is now available which updates it to 4.2.8p10. This update is available for the following releases of OmniOS:

r151014
r151018
r151020
Bloody

To update, issue the following command:

# pkg update -v service/network/ntp

The ntp service will be automatically restarted. No reboot is required.

Interested persons may review the security fixes in this release on the ntp.org website:
http://support.ntp.org/bin/view/Main/SecurityNotice#March_2017_ntp_4_2_8p10_NTP_Secu

/dale
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170328/271864ed/attachment.bin>

From danmcd at omniti.com  Wed Mar 29 00:43:16 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 28 Mar 2017 20:43:16 -0400
Subject: [OmniOS-discuss] OmniOS bloody update
In-Reply-To: <3E205457-8E93-4D37-9260-693873B11D96@omniti.com>
References: <35FD8F4E-855C-413B-A6E9-87B20FB5336D@kebe.com>
	<3E205457-8E93-4D37-9260-693873B11D96@omniti.com>
Message-ID: <29EC7AD8-27A9-4913-A8B7-46D14530AF95@omniti.com>

I found a slight error in the ISO & USB builds (it hits a spot where you must press ^D to continue on to the installer).  This was due to a very recent SMF bug fix that I was working around previously.

I've uploaded new media and updated the checksums on the Installation wiki page.  Make sure you reload the page if it's cached.

Thank you,
Dan


From doug at will.to  Wed Mar 29 01:03:51 2017
From: doug at will.to (Doug Hughes)
Date: Tue, 28 Mar 2017 21:03:51 -0400
Subject: [OmniOS-discuss] ZFS/NFS Lockup when deleting or copying large
 files
In-Reply-To: <C0848B1F-08DA-441E-8542-192600475690@bissinc.com>
References: <C0848B1F-08DA-441E-8542-192600475690@bissinc.com>
Message-ID: <d222617e-b827-f306-7eea-0751030990b6@will.to>

There are quite a bit of things to look at.

One question: do you have deduplication turned on?

I have seen things like this (with or without dedup) as a result of
memory exhaustion. I happen to know that the x4540 can only hold about
32GB of ram, so this seems like a possibility.

you might want to start collecting vmstat output (e.g. vmstat 5) and if
you can reproduce this easily, watch that. If this is the same thing
that I've experienced, you'll go into desparation free swapping (DE
column > 0 = very bad) and then the machine will just fall over. This
seems to happen in particular with extremely heavy NFS traffic which
uses up a lot of memory buffers that can't be freed up fast enough to
prevent memory exhaustion.

There are a lot of other contributed scripts in the dtrace toolkit that
may be useful too. It's venerable, but still useful.



On 3/28/2017 5:40 PM, John Barfield wrote:
>
> Greetings!
>
>  
>
>  
>
> I have an issue with ZFS/NFS on OmniOS where copying or deleting large
> files causes the SAN to lockup and requires that we reboot it
> sometimes to recover. One customer was trying to copy a 400GB file and
> another tried to delete a 4TB vmdk from a vmware NFS vstore. In both
> situations the issue is reproducible and in both situations I cannot
> seem to find anything crazy happening on either of the boxes.  This
> doesn?t mean anything though because I?m limited in my kstat/dtrace
> knowledge for troubleshooting this type of behavior on illumos.
>
>  
>
> If there is an illumOS bug I?m missing or something that jumps out at
> ya please let me know?of if you need more detailed information I can
> detail both customer locations hardware, software, and operating
> conditions upon request.
>
>  
>
> The VMware customer is running on r151016 and the other customer is
> running on the latest release.
>
>  
>
> _NFSv3 Only Clients_
>
>  
>
> OS:
>
> ESXi 5.5
>
>  
>
> _All 64bit Linux Clients_
>
> CentOS 5,6,&7
>
> Some Older Debian 7 Boxes
>
>  
>
> I should also note that the VMware customer experiences this same
> issue on two different SAN?s that are very different in hardware
> configurations.
>
>  
>
> The one common thread is that they are all Sun Servers. X4170 M2,
> X4270 M2, x4540
>
>  
>
> This thread is being posted to both the illumos email list and the
> omnios email list as well.
>
>  
>
> I?m looking, I guess, for a methodology to follow to trace this down
> and determine if it?s a bug or a misconfiguration either on the client
> or in ZFS or in the NFS server.
>
>  
>
> I can get someone access if so desired.
>
>  
>
> Have a great day!
>
>  
>
> *John Barfield*
>
> *Engineering and Stuff *
>
> * *
>
> M: +1 (214) 425-0783  O: +1 (214) 506-8354 
>
> john.barfield at bissinc.com <mailto:john.barfield at bissinc.com>
>
> * *
>
> *id:image001.png at 01D2837C.19B23B20***
>
> 4925 Greenville Ave, Ste 900
>
> Dallas, TX 75206
>
> * *
>
> _For Support Requests:_
>
> http://support.bissinc.com <http://support.bissinc.com/> or
> support at bissinc.com <mailto:support at bissinc.com>
>
>  
>
> Follow us on Twitter for Network Status &  Updates!
>
>  
>
> id:image002.gif at 01D2837C.19B23B20 <https://twitter.com/johnbarfield> 
>
>  
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170328/b52ccdc2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3509 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170328/b52ccdc2/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1352 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170328/b52ccdc2/attachment-0001.gif>

From lorban at bitronix.be  Wed Mar 29 07:48:29 2017
From: lorban at bitronix.be (Ludovic Orban)
Date: Wed, 29 Mar 2017 09:48:29 +0200
Subject: [OmniOS-discuss] OmniOS bloody update
In-Reply-To: <29EC7AD8-27A9-4913-A8B7-46D14530AF95@omniti.com>
References: <35FD8F4E-855C-413B-A6E9-87B20FB5336D@kebe.com>
	<3E205457-8E93-4D37-9260-693873B11D96@omniti.com>
	<29EC7AD8-27A9-4913-A8B7-46D14530AF95@omniti.com>
Message-ID: <CAN0RhAMvkmngjZ+dGc5iexK6reuHo6LqgB9G3pEqxq5Pz_S3yA@mail.gmail.com>

Would you, by any chance, have the time to look at 7388 and hopefully
manage to make it go into this bloody ? A patch has been submitted months
ago but is still pending review.

AFAICT it looks good to me, but I don't think my opinion has much weight.

Thanks in advance,
Ludovic

On Wed, Mar 29, 2017 at 2:43 AM, Dan McDonald <danmcd at omniti.com> wrote:

> I found a slight error in the ISO & USB builds (it hits a spot where you
> must press ^D to continue on to the installer).  This was due to a very
> recent SMF bug fix that I was working around previously.
>
> I've uploaded new media and updated the checksums on the Installation wiki
> page.  Make sure you reload the page if it's cached.
>
> Thank you,
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170329/e31a3ad8/attachment.html>

From john.barfield at bissinc.com  Wed Mar 29 13:46:57 2017
From: john.barfield at bissinc.com (John Barfield)
Date: Wed, 29 Mar 2017 13:46:57 +0000
Subject: [OmniOS-discuss] ZFS/NFS Lockup when deleting or copying large
 files
In-Reply-To: <ED1F17BA-4A83-40FB-9E50-00D1D1EE1215@teknograd.no>
References: <C0848B1F-08DA-441E-8542-192600475690@bissinc.com>,
	<ED1F17BA-4A83-40FB-9E50-00D1D1EE1215@teknograd.no>
Message-ID: <10F448BD-A424-4AEE-BCED-6F103BFB65A3@bissinc.com>

zilstat showed all zeros.

In fact I emailed Richard Elling about it to be sure that I was using it properly.

iostat, prstat, & arcstat stayed very busy the whole time though.

Ill pay more attention nexttime.

John Barfield

On Mar 29, 2017, at 1:22 AM, Knut Erik S?rvik <kes at teknograd.no<mailto:kes at teknograd.no>> wrote:

Hi

I've had similar things happen, and in our case I think this might be related:

https://github.com/openzfs/openzfs/pull/214

A simple zpool iostat on the pool, with a frequent update, showed that the write column were all zeroes for an extended time, causing the clients to believe the storage was gone.

kes


Den 28. mar. 2017 kl. 23.54 skrev John Barfield <john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>>:

Greetings!


I have an issue with ZFS/NFS on OmniOS where copying or deleting large files causes the SAN to lockup and requires that we reboot it sometimes to recover. One customer was trying to copy a 400GB file and another tried to delete a 4TB vmdk from a vmware NFS vstore. In both situations the issue is reproducible and in both situations I cannot seem to find anything crazy happening on either of the boxes.  This doesn?t mean anything though because I?m limited in my kstat/dtrace knowledge for troubleshooting this type of behavior on illumos.

If there is an illumOS bug I?m missing or something that jumps out at ya please let me know?of if you need more detailed information I can detail both customer locations hardware, software, and operating conditions upon request.

The VMware customer is running on r151016 and the other customer is running on the latest release.

NFSv3 Only Clients

OS:
ESXi 5.5

All 64bit Linux Clients
CentOS 5,6,&7
Some Older Debian 7 Boxes

I should also note that the VMware customer experiences this same issue on two different SAN?s that are very different in hardware configurations.

The one common thread is that they are all Sun Servers. X4170 M2, X4270 M2, x4540

This thread is being posted to both the illumos email list and the omnios email list as well.

I?m looking, I guess, for a methodology to follow to trace this down and determine if it?s a bug or a misconfiguration either on the client or in ZFS or in the NFS server.

I can get someone access if so desired.

Have a great day!

John Barfield
Engineering and Stuff

M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfield at bissinc.com<mailto:john.barfield at bissinc.com>

<image001.png>
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com<https://url12.mailanyone.net/v1/?m=1csz4e-00085p-3G&i=57e1b682&c=9IlDjjPpk-5UCrCMFk6HSjMe2nUi5cI3kwNmKHpQpR9kuxm7fU-b_hC5P0WeTyBGrDz0zay6r2YYrImrvUikzW2dywbVvROrkwpR2S9sd89tBkKu_N60XPp9f1g8jpM5mcVhpU0WQHse1GpHuHUsFy4410p5FJ4QxX2I9bHqDdLuWhguJDTCpBYBI-w8hs5XEnvzQWtR19ud-QDucXKPmw_v5b47JftMIzAYoDY2JXA> or support at bissinc.com<mailto:support at bissinc.com>

Follow us on Twitter for Network Status &  Updates!

<image002.gif><https://url12.mailanyone.net/v1/?m=1csz4e-00085p-3G&i=57e1b682&c=Oost5JgpPBN1Zl_l5wMwGG464L9v13c1IIli6CSlLHKKgRmK3NNtCgg7AiwNB6_-CxXM4D7vwvp9JwZRk5wldseR6wBniGTVUxLaJDPRdW-FADOVCD-Cxk8sY-PcmC5r_usv0LRVfVLQ3jfedqEGaCVEID6UGIr7sRdoxG_EXVGjRqq4b4iK0SarW3fHfayNz5x06aW9LbenkcGoORjej4Vp4F97E0Rxs7UyU21NN8I>

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com<mailto:OmniOS-discuss at lists.omniti.com>
http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170329/6817b4f7/attachment-0001.html>

From danmcd at omniti.com  Wed Mar 29 15:11:33 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 29 Mar 2017 11:11:33 -0400
Subject: [OmniOS-discuss] OmniOS bloody update
In-Reply-To: <CAN0RhAMvkmngjZ+dGc5iexK6reuHo6LqgB9G3pEqxq5Pz_S3yA@mail.gmail.com>
References: <35FD8F4E-855C-413B-A6E9-87B20FB5336D@kebe.com>
	<3E205457-8E93-4D37-9260-693873B11D96@omniti.com>
	<29EC7AD8-27A9-4913-A8B7-46D14530AF95@omniti.com>
	<CAN0RhAMvkmngjZ+dGc5iexK6reuHo6LqgB9G3pEqxq5Pz_S3yA@mail.gmail.com>
Message-ID: <7986B19D-810B-4D64-965E-F81D6E54A96E@omniti.com>


> On Mar 29, 2017, at 3:48 AM, Ludovic Orban <lorban at bitronix.be> wrote:
> 
> Would you, by any chance, have the time to look at 7388 and hopefully manage to make it go into this bloody ? A patch has been submitted months ago but is still pending review.
> 
> AFAICT it looks good to me, but I don't think my opinion has much weight.

Yeah.  This is a big wad that requires a careful review.  I did give it some a few months back.

ALSO, and as I'm gearing up for the last bit of this bloody cycle, it's going to need someone from SmartOS to look at it as well, given it touches files (ipadm & friends) that have deviations in SmartOS for their zones model AND for LX Zones.  One of the things I promised OmniOS users was to give ipadm(1M) for LX zones a go.  This work will completely interfere with that.

I'm sorry, but unless it's been reviewed by some more people, I can't put this one into OmniOS this time around.

Dan


From danmcd at omniti.com  Wed Mar 29 15:30:46 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 29 Mar 2017 11:30:46 -0400
Subject: [OmniOS-discuss] VMware Fusion 8.5.6 + macOS 10.12.4 == black
	screens
Message-ID: <7A18EA02-8104-412E-BDE9-EED2547744CA@omniti.com>

Please look here first:

	https://communities.vmware.com/thread/560145

This bug, an interaction between newly-updated macOS and VMware Fusion, affects OmniOS users who run in VMware Fusion (like I do).

The Loader screen for bloody will not show up, you will see a black screen.  So far, however, experiments show that once the illumos kernel kicks in, life returns to normal.  For GRUB-based releases, it appears that the illumos kernel also returns things to normal, but it seems to fix things "later in boot", so you will have a small period where your screen is black post-GRUB.

I've heard reports that other illumos distros STAY with a black screen.

Please consider yourself warned if you are a VMware Fusion user.

An extra shout-out to Toomas Soome who pointed me at the VMware forum above (and whose illumos community work on Loader should be lauded here).

Thanks,
Dan


From lorban at bitronix.be  Wed Mar 29 16:00:10 2017
From: lorban at bitronix.be (Ludovic Orban)
Date: Wed, 29 Mar 2017 18:00:10 +0200
Subject: [OmniOS-discuss] OmniOS bloody update
In-Reply-To: <7986B19D-810B-4D64-965E-F81D6E54A96E@omniti.com>
References: <35FD8F4E-855C-413B-A6E9-87B20FB5336D@kebe.com>
	<3E205457-8E93-4D37-9260-693873B11D96@omniti.com>
	<29EC7AD8-27A9-4913-A8B7-46D14530AF95@omniti.com>
	<CAN0RhAMvkmngjZ+dGc5iexK6reuHo6LqgB9G3pEqxq5Pz_S3yA@mail.gmail.com>
	<7986B19D-810B-4D64-965E-F81D6E54A96E@omniti.com>
Message-ID: <CAN0RhAMRXc-cQ-n12kH=AYhDP0ZeBn-2+Vz0-pBNr-CUy2u_uw@mail.gmail.com>

Understood, your plate already is more than full.

Thanks anyway!

On Wed, Mar 29, 2017 at 5:11 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On Mar 29, 2017, at 3:48 AM, Ludovic Orban <lorban at bitronix.be> wrote:
> >
> > Would you, by any chance, have the time to look at 7388 and hopefully
> manage to make it go into this bloody ? A patch has been submitted months
> ago but is still pending review.
> >
> > AFAICT it looks good to me, but I don't think my opinion has much weight.
>
> Yeah.  This is a big wad that requires a careful review.  I did give it
> some a few months back.
>
> ALSO, and as I'm gearing up for the last bit of this bloody cycle, it's
> going to need someone from SmartOS to look at it as well, given it touches
> files (ipadm & friends) that have deviations in SmartOS for their zones
> model AND for LX Zones.  One of the things I promised OmniOS users was to
> give ipadm(1M) for LX zones a go.  This work will completely interfere with
> that.
>
> I'm sorry, but unless it's been reviewed by some more people, I can't put
> this one into OmniOS this time around.
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170329/00669453/attachment.html>

From geoffn at gnaa.net  Wed Mar 29 17:13:02 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Wed, 29 Mar 2017 10:13:02 -0700
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
Message-ID: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>

Hi.

Anyone have any luck installing VBox 5.1 on Omnios?

I am missing:

IPS :  system/library/gcc/gcc-c++-runtime or 
system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or 
system/library/gcc-45-runtime


/usr/sbin/pkgadd -d VirtualBox\-5.1.18\-SunOS\-amd64\-r114002.pkg

The following packages are available:

1  SUNWvbox     Oracle VM VirtualBox (i386) 
5.1.18,REV=2017.03.15.16.41.114002

Select package(s) you wish to process (or 'all' to process all 
packages). (default: all) [?,??,q]:

Processing package instance <SUNWvbox> from 
</backup/test/VirtualBox-5.1.18-SunOS-amd64-r114002.pkg>

Oracle VM VirtualBox(i386) 5.1.18,REV=2017.03.15.16.41.114002
Oracle Corporation
## Executing checkinstall script.
Checking package dependencies...
## Missing packages:
## IPS :  system/library/gcc/gcc-c++-runtime or 
system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or 
system/library/gcc-45-runtime
## SVr4:  SUNWPython SUNWPython-devel
##
## Please install either the IPS or SVr4 packages before installing 
VirtualBox.
pkgadd: ERROR: checkinstall script did not complete successfully

Installation of <SUNWvbox> failed.
No changes were made to the system.


thanks,

Geoff


From geoffn at gnaa.net  Wed Mar 29 17:15:23 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Wed, 29 Mar 2017 10:15:23 -0700
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
In-Reply-To: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
References: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
Message-ID: <eff5f45c-d6b4-c4e1-b48a-6795f69170d9@gnaa.net>

Forgot to mention that I am running r151020.

On 2017-03-29 10:13 AM, Geoff Nordli wrote:
> Hi.
>
> Anyone have any luck installing VBox 5.1 on Omnios?
>
> I am missing:
>
> IPS :  system/library/gcc/gcc-c++-runtime or 
> system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or 
> system/library/gcc-45-runtime
>
>
> /usr/sbin/pkgadd -d VirtualBox\-5.1.18\-SunOS\-amd64\-r114002.pkg
>
> The following packages are available:
>
> 1  SUNWvbox     Oracle VM VirtualBox (i386) 
> 5.1.18,REV=2017.03.15.16.41.114002
>
> Select package(s) you wish to process (or 'all' to process all 
> packages). (default: all) [?,??,q]:
>
> Processing package instance <SUNWvbox> from 
> </backup/test/VirtualBox-5.1.18-SunOS-amd64-r114002.pkg>
>
> Oracle VM VirtualBox(i386) 5.1.18,REV=2017.03.15.16.41.114002
> Oracle Corporation
> ## Executing checkinstall script.
> Checking package dependencies...
> ## Missing packages:
> ## IPS :  system/library/gcc/gcc-c++-runtime or 
> system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or 
> system/library/gcc-45-runtime
> ## SVr4:  SUNWPython SUNWPython-devel
> ##
> ## Please install either the IPS or SVr4 packages before installing 
> VirtualBox.
> pkgadd: ERROR: checkinstall script did not complete successfully
>
> Installation of <SUNWvbox> failed.
> No changes were made to the system.
>
>
> thanks,
>
> Geoff
>


From daleg at omniti.com  Wed Mar 29 17:22:54 2017
From: daleg at omniti.com (Dale Ghent)
Date: Wed, 29 Mar 2017 13:22:54 -0400
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
In-Reply-To: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
References: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
Message-ID: <C8276498-C07C-44C9-9BAC-33B3F7D24E40@omniti.com>

Oracle VirtualBox is made for Oracle Solaris, and any ability for it to operate on OmniOS (or any other illumos distribution) is entirely coincidental.

/dale

> On Mar 29, 2017, at 1:13 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
> 
> Hi.
> 
> Anyone have any luck installing VBox 5.1 on Omnios?
> 
> I am missing:
> 
> IPS :  system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime
> 
> 
> /usr/sbin/pkgadd -d VirtualBox\-5.1.18\-SunOS\-amd64\-r114002.pkg
> 
> The following packages are available:
> 
> 1  SUNWvbox     Oracle VM VirtualBox (i386) 5.1.18,REV=2017.03.15.16.41.114002
> 
> Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]:
> 
> Processing package instance <SUNWvbox> from </backup/test/VirtualBox-5.1.18-SunOS-amd64-r114002.pkg>
> 
> Oracle VM VirtualBox(i386) 5.1.18,REV=2017.03.15.16.41.114002
> Oracle Corporation
> ## Executing checkinstall script.
> Checking package dependencies...
> ## Missing packages:
> ## IPS :  system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime
> ## SVr4:  SUNWPython SUNWPython-devel
> ##
> ## Please install either the IPS or SVr4 packages before installing VirtualBox.
> pkgadd: ERROR: checkinstall script did not complete successfully
> 
> Installation of <SUNWvbox> failed.
> No changes were made to the system.
> 
> 
> thanks,
> 
> Geoff
> 
> _______________________________________________
> 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
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170329/7d56e86d/attachment-0001.bin>

From danmcd at omniti.com  Wed Mar 29 17:23:37 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 29 Mar 2017 13:23:37 -0400
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
In-Reply-To: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
References: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
Message-ID: <464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com>


> On Mar 29, 2017, at 1:13 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
> 
> Hi.
> 
> Anyone have any luck installing VBox 5.1 on Omnios?
> 
> I am missing:
> 
> IPS :  system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime
> 
> 
> /usr/sbin/pkgadd -d VirtualBox\-5.1.18\-SunOS\-amd64\-r114002.pkg
> 
> The following packages are available:
> 
> 1  SUNWvbox     Oracle VM VirtualBox (i386) 5.1.18,REV=2017.03.15.16.41.114002
> 
> Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]:
> 
> Processing package instance <SUNWvbox> from </backup/test/VirtualBox-5.1.18-SunOS-amd64-r114002.pkg>
> 
> Oracle VM VirtualBox(i386) 5.1.18,REV=2017.03.15.16.41.114002
> Oracle Corporation
> ## Executing checkinstall script.
> Checking package dependencies...
> ## Missing packages:
> ## IPS :  system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime
> ## SVr4:  SUNWPython SUNWPython-devel
> ##
> ## Please install either the IPS or SVr4 packages before installing VirtualBox.
> pkgadd: ERROR: checkinstall script did not complete successfully
> 
> Installation of <SUNWvbox> failed.
> No changes were made to the system.

Wow!

It's assuming Oracle Solaris paths and package definitions.  Our versions of those packages have slightly different names.  (e.g. we have gcc-51 runtime).

You'll have to work around it somehow.  I wonder if the SysV package programs let you override that crap or not?  And even if you do, VBox's library paths may assume libraries are places where they are not in OmniOS.

I can't say it's impossible, but I can say it'll be much pain.

Dan


From geoffn at gnaa.net  Wed Mar 29 17:39:11 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Wed, 29 Mar 2017 10:39:11 -0700
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
In-Reply-To: <464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com>
References: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
	<464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com>
Message-ID: <1a90f314-a446-cc2b-1a3c-b002c32a2223@gnaa.net>

On 2017-03-29 10:23 AM, Dan McDonald wrote:
>> On Mar 29, 2017, at 1:13 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
>>
>> Hi.
>>
>> Anyone have any luck installing VBox 5.1 on Omnios?
>>
>> I am missing:
>>
>> IPS :  system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime
>>
>>
>> /usr/sbin/pkgadd -d VirtualBox\-5.1.18\-SunOS\-amd64\-r114002.pkg
>>
>> The following packages are available:
>>
>> 1  SUNWvbox     Oracle VM VirtualBox (i386) 5.1.18,REV=2017.03.15.16.41.114002
>>
>> Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]:
>>
>> Processing package instance <SUNWvbox> from </backup/test/VirtualBox-5.1.18-SunOS-amd64-r114002.pkg>
>>
>> Oracle VM VirtualBox(i386) 5.1.18,REV=2017.03.15.16.41.114002
>> Oracle Corporation
>> ## Executing checkinstall script.
>> Checking package dependencies...
>> ## Missing packages:
>> ## IPS :  system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime
>> ## SVr4:  SUNWPython SUNWPython-devel
>> ##
>> ## Please install either the IPS or SVr4 packages before installing VirtualBox.
>> pkgadd: ERROR: checkinstall script did not complete successfully
>>
>> Installation of <SUNWvbox> failed.
>> No changes were made to the system.
> Wow!
>
> It's assuming Oracle Solaris paths and package definitions.  Our versions of those packages have slightly different names.  (e.g. we have gcc-51 runtime).
>
> You'll have to work around it somehow.  I wonder if the SysV package programs let you override that crap or not?  And even if you do, VBox's library paths may assume libraries are places where they are not in OmniOS.
>
> I can't say it's impossible, but I can say it'll be much pain.
>
> Dan
>

Hi Dan.

I will post on the vbox list, maybe someone has some clues there.

I guess at some point I will need to look at other options, but vbox has 
been really solid and I have a lot of tools to manage it.

I can stay on the 5.0 series.

thanks,

Geoff



From danmcd at omniti.com  Wed Mar 29 17:43:59 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 29 Mar 2017 13:43:59 -0400
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
In-Reply-To: <1a90f314-a446-cc2b-1a3c-b002c32a2223@gnaa.net>
References: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
	<464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com>
	<1a90f314-a446-cc2b-1a3c-b002c32a2223@gnaa.net>
Message-ID: <AD8DE7C5-F2D3-4A86-BD00-2EEFD9D14AA2@omniti.com>


> On Mar 29, 2017, at 1:39 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
> 
> I will post on the vbox list, maybe someone has some clues there.

Ideally someone would package it on OmniOS itself for OmniOS.

Dan


From omnios at citrus-it.net  Wed Mar 29 18:32:58 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Wed, 29 Mar 2017 18:32:58 +0000 (UTC)
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
In-Reply-To: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
References: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
Message-ID: <alpine.GSO.2.20.1703291830420.430156@erncre.pvgehf-vg.arg>


On Wed, 29 Mar 2017, Geoff Nordli wrote:

; Hi.
;
; Anyone have any luck installing VBox 5.1 on Omnios?
;
; I am missing:
;
; IPS :  system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime
; system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime

# gtar zxvf ~/dl/VirtualBox-5.1.18-114002-SunOS.tar.gz
# ls
LICENSE
ReadMe.txt
VirtualBox-5.1.18-SunOS-amd64-r114002.pkg
autoresponse

# sed -i 's/quit/nocheck/' autoresponse
# pkgadd -r autoresponse -d VirtualBox-5.1.18-SunOS-amd64-r114002.pkg all

Binaries seem to run, didn't look any further.

Andy

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


From geoffn at gnaa.net  Wed Mar 29 20:08:32 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Wed, 29 Mar 2017 13:08:32 -0700
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
In-Reply-To: <alpine.GSO.2.20.1703291830420.430156@erncre.pvgehf-vg.arg>
References: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
	<alpine.GSO.2.20.1703291830420.430156@erncre.pvgehf-vg.arg>
Message-ID: <e24be25c-ff4d-dc92-5315-cc73252b1039@gnaa.net>



On 2017-03-29 11:32 AM, Andy Fiddaman wrote:
> On Wed, 29 Mar 2017, Geoff Nordli wrote:
>
> ; Hi.
> ;
> ; Anyone have any luck installing VBox 5.1 on Omnios?
> ;
> ; I am missing:
> ;
> ; IPS :  system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime
> ; system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime
>
> # gtar zxvf ~/dl/VirtualBox-5.1.18-114002-SunOS.tar.gz
> # ls
> LICENSE
> ReadMe.txt
> VirtualBox-5.1.18-SunOS-amd64-r114002.pkg
> autoresponse
>
> # sed -i 's/quit/nocheck/' autoresponse
> # pkgadd -r autoresponse -d VirtualBox-5.1.18-SunOS-amd64-r114002.pkg all
>
> Binaries seem to run, didn't look any further.
>
> Andy
>
Thanks for the tip Andy.

I will see if that works.

Geoff

From vab at bb-c.de  Wed Mar 29 21:00:33 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Wed, 29 Mar 2017 23:00:33 +0200
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
In-Reply-To: <AD8DE7C5-F2D3-4A86-BD00-2EEFD9D14AA2@omniti.com>
References: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
	<464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com>
	<1a90f314-a446-cc2b-1a3c-b002c32a2223@gnaa.net>
	<AD8DE7C5-F2D3-4A86-BD00-2EEFD9D14AA2@omniti.com>
Message-ID: <22748.8305.199354.108543@urukhai.local>

Dan McDonald writes:
> Ideally someone would package it on OmniOS itself for OmniOS.

Would that be permitted by the VirtualBox license?  Shouldn't be too
hard if it is just repackaging...


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From daleg at omniti.com  Wed Mar 29 22:07:42 2017
From: daleg at omniti.com (Dale Ghent)
Date: Wed, 29 Mar 2017 18:07:42 -0400
Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies
In-Reply-To: <22748.8305.199354.108543@urukhai.local>
References: <ef66f2e0-446c-6622-ea28-9858a129391c@gnaa.net>
	<464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com>
	<1a90f314-a446-cc2b-1a3c-b002c32a2223@gnaa.net>
	<AD8DE7C5-F2D3-4A86-BD00-2EEFD9D14AA2@omniti.com>
	<22748.8305.199354.108543@urukhai.local>
Message-ID: <98FB8D41-C2A5-4D27-A03F-7292CD9D0257@omniti.com>


> On Mar 29, 2017, at 5:00 PM, Volker A. Brandt <vab at bb-c.de> wrote:
> 
> Dan McDonald writes:
>> Ideally someone would package it on OmniOS itself for OmniOS.
> 
> Would that be permitted by the VirtualBox license?  Shouldn't be too
> hard if it is just repackaging...

Preferably it would also be natively built. One of the unfortunate legacy aspects is that VirtualBox?s notion of ?SunOS? is Oracle Solaris and stays absolutely true to that expectation. This was certainly an issue with the vbox add-ons and the vboxfs driver no longer building or working on illumos, as it was expecting symbols that were introduced in later versions of Oracle Solaris 11 but are not present in illumos, which still self-identifies as the same.

As time progresses, these kinds of differences will only widen, especially as there will be no Solaris 12, whereupon the differences between illumos and Oracle Solaris 11 would at least stop widening. Once the Oracle Solaris virtualbox binaries start expecting a library that we don?t ship, or either Oracle or us change the behavior of some call or the like, things start breaking rapidly and running it on illumos ceases to be an option.

It is conceivable, however, that a patch set could be maintained by someone with the time and interest which could make vbox buildable and runnable on illumos-based OSes such as OmniOS or OI.

/dale
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170329/d5974cd5/attachment-0001.bin>

From danmcd at omniti.com  Thu Mar 30 00:10:11 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 29 Mar 2017 20:10:11 -0400
Subject: [OmniOS-discuss] LX Zones question: Do you miss ipadm(1M)?
Message-ID: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>

One of the checkbox-items for this bloody *was* "ipadm for LX zones".  After having some conversations with Joyent, and noticing a lack of enthusiasm here, I'm wondering if I should even bother with it for this bloody & r151022.

Please speak up if you have ANY opinion on this subject.  I'm honestly not sure, so I wouldn't be taking sides or advocating one way or the other.

Thanks,
Dan


From johan.kragsterman at capvert.se  Thu Mar 30 05:30:00 2017
From: johan.kragsterman at capvert.se (Johan Kragsterman)
Date: Thu, 30 Mar 2017 07:30:00 +0200
Subject: [OmniOS-discuss] Ang:  LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
Message-ID: <OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>


Hi!



-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Fr?n: Dan McDonald 
S?nt av: "OmniOS-discuss" 
Datum: 2017-03-30 02:12
?rende: [OmniOS-discuss] LX Zones question: Do you miss ipadm(1M)?

One of the checkbox-items for this bloody *was* "ipadm for LX zones".  After having some conversations with Joyent, and noticing a lack of enthusiasm here, I'm wondering if I should even bother with it for this bloody & r151022.

Please speak up if you have ANY opinion on this subject.  I'm honestly not sure, so I wouldn't be taking sides or advocating one way or the other.

Thanks,
Dan



ipadm is a nice and versatile tool, and I would for sure like to see it in LX zones. Though the priority of the development is another question, WHEN to put it there.
r151022 is an LTS release, and I believe it would be nice to have ipadm in there, but if you can't get it there before release, due to other priorities, perhaps you can backport it later?

Rgrds Johan




_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss






From alka at hfg-gmuend.de  Thu Mar 30 07:19:40 2017
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Thu, 30 Mar 2017 09:19:40 +0200
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
Message-ID: <b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>

Setting ip properties atthe virtualisation layer
seems not straight forward to me. Lately I was
asked about the problem where DNS onUbuntu 16
was not working despite the setting in the zone.cfg
(Configurating /etc/resolv in Linux was needed)

I would prefer a more ESXi like behaviour where settings
about hardware like (lofi) disks, CPU, RAM, vnics are zone
settings while network configuration is done by the VM
itself with the different but regular Linux tools and ways.

A related question
Exclusive ip access over a dedicated vnic is working.
I had problems with shared/ bridged access to a physical nic
that is in use by OmniOS itself or a different zone. Is that possible?

And is there a property to limit RAM or CPU of an LX zone?

Gea


Am 30.03.2017 um 07:30 schrieb Johan Kragsterman:
> Hi!
>
>
>
> -----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
> Till: OmniOS-discuss <omnios-discuss at lists.omniti.com>
> Fr?n: Dan McDonald
> S?nt av: "OmniOS-discuss"
> Datum: 2017-03-30 02:12
> ?rende: [OmniOS-discuss] LX Zones question: Do you miss ipadm(1M)?
>
> One of the checkbox-items for this bloody *was* "ipadm for LX zones".  After having some conversations with Joyent, and noticing a lack of enthusiasm here, I'm wondering if I should even bother with it for this bloody & r151022.
>
> Please speak up if you have ANY opinion on this subject.  I'm honestly not sure, so I wouldn't be taking sides or advocating one way or the other.
>
> Thanks,
> Dan
>
>
>
> ipadm is a nice and versatile tool, and I would for sure like to see it in LX zones. Though the priority of the development is another question, WHEN to put it there.
> r151022 is an LTS release, and I believe it would be nice to have ipadm in there, but if you can't get it there before release, due to other priorities, perhaps you can backport it later?
>
> Rgrds Johan
>
>
>
>


From lorban at bitronix.be  Thu Mar 30 07:47:55 2017
From: lorban at bitronix.be (Ludovic Orban)
Date: Thu, 30 Mar 2017 09:47:55 +0200
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
Message-ID: <CAN0RhAN1_uCg0sbOM54x6OxSkPO8Gg0RYKLKNHJcYZRyS0C15Q@mail.gmail.com>

I personally don't need ipadm in my LX zones, nerver missed it and I'm
pretty certain I wouldn't use it even if it was available. I'd *much*
prefer to have 7388 though (sorry for insisting, I couldn't resist ;-))

On Thu, Mar 30, 2017 at 9:19 AM, Guenther Alka <alka at hfg-gmuend.de> wrote:

> Setting ip properties atthe virtualisation layer
> seems not straight forward to me. Lately I was
> asked about the problem where DNS onUbuntu 16
> was not working despite the setting in the zone.cfg
> (Configurating /etc/resolv in Linux was needed)
>
> I would prefer a more ESXi like behaviour where settings
> about hardware like (lofi) disks, CPU, RAM, vnics are zone
> settings while network configuration is done by the VM
> itself with the different but regular Linux tools and ways.
>
> A related question
> Exclusive ip access over a dedicated vnic is working.
> I had problems with shared/ bridged access to a physical nic
> that is in use by OmniOS itself or a different zone. Is that possible?
>
> And is there a property to limit RAM or CPU of an LX zone?
>
> Gea
>
>
>
> Am 30.03.2017 um 07:30 schrieb Johan Kragsterman:
>
>> Hi!
>>
>>
>>
>> -----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev:
>> -----
>> Till: OmniOS-discuss <omnios-discuss at lists.omniti.com>
>> Fr?n: Dan McDonald
>> S?nt av: "OmniOS-discuss"
>> Datum: 2017-03-30 02:12
>> ?rende: [OmniOS-discuss] LX Zones question: Do you miss ipadm(1M)?
>>
>> One of the checkbox-items for this bloody *was* "ipadm for LX zones".
>> After having some conversations with Joyent, and noticing a lack of
>> enthusiasm here, I'm wondering if I should even bother with it for this
>> bloody & r151022.
>>
>> Please speak up if you have ANY opinion on this subject.  I'm honestly
>> not sure, so I wouldn't be taking sides or advocating one way or the other.
>>
>> Thanks,
>> Dan
>>
>>
>>
>> ipadm is a nice and versatile tool, and I would for sure like to see it
>> in LX zones. Though the priority of the development is another question,
>> WHEN to put it there.
>> r151022 is an LTS release, and I believe it would be nice to have ipadm
>> in there, but if you can't get it there before release, due to other
>> priorities, perhaps you can backport it later?
>>
>> Rgrds Johan
>>
>>
>>
>>
>>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170330/ce9d7616/attachment.html>

From omnios at citrus-it.net  Thu Mar 30 08:00:11 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Thu, 30 Mar 2017 08:00:11 +0000 (UTC)
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <CAN0RhAN1_uCg0sbOM54x6OxSkPO8Gg0RYKLKNHJcYZRyS0C15Q@mail.gmail.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<CAN0RhAN1_uCg0sbOM54x6OxSkPO8Gg0RYKLKNHJcYZRyS0C15Q@mail.gmail.com>
Message-ID: <alpine.GSO.2.20.1703300759410.648441@erncre.pvgehf-vg.arg>



On Thu, 30 Mar 2017, Ludovic Orban wrote:

; I personally don't need ipadm in my LX zones, nerver missed it and I'm
; pretty certain I wouldn't use it even if it was available.

Same here.

Andy

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


From bfriesen at simple.dallas.tx.us  Thu Mar 30 17:51:38 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Thu, 30 Mar 2017 12:51:38 -0500 (CDT)
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
Message-ID: <alpine.GSO.2.20.1703301247030.7926@scrappy.simplesystems.org>

On Thu, 30 Mar 2017, Guenther Alka wrote:
>
> I would prefer a more ESXi like behaviour where settings
> about hardware like (lofi) disks, CPU, RAM, vnics are zone
> settings while network configuration is done by the VM
> itself with the different but regular Linux tools and ways.

The "regular Linux tools and ways" are not likely to work due to the 
LX Zone actually still being Illumos and lacking support for netlink 
sockets, which is how modern facilities like 'ip' are implemented. 
Perhaps primitive utilities as provided by Busybox (e.g. Alpine) might 
work due to being based on deprecated ioctl interfaces.

It could be possible to provide alternate work-alike "native" Linux 
tools but these would need to be provided in source form, or in Linux 
distribution-specific binary packages.

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

From danmcd at omniti.com  Thu Mar 30 19:21:05 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 30 Mar 2017 15:21:05 -0400
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
Message-ID: <F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>


> On Mar 30, 2017, at 3:19 AM, Guenther Alka <alka at hfg-gmuend.de> wrote:
> 
> Setting ip properties atthe virtualisation layer
> seems not straight forward to me. Lately I was
> asked about the problem where DNS onUbuntu 16
> was not working despite the setting in the zone.cfg
> (Configurating /etc/resolv in Linux was needed)

Yeah, that may be some distro weirdness.  It may also be something that our install or boot scripts need help with as well.

> I would prefer a more ESXi like behaviour where settings
> about hardware like (lofi) disks, CPU, RAM, vnics are zone
> settings while network configuration is done by the VM
> itself with the different but regular Linux tools and ways.

Oh I didn't say "linux tools".  I said "ipadm(1M)" which is in /native/sbin and works like it does in the global zone or an ipkg/lipkg zone.

> A related question
> Exclusive ip access over a dedicated vnic is working.
> I had problems with shared/ bridged access to a physical nic
> that is in use by OmniOS itself or a different zone. Is that possible?

Shared-stack IP is not allowed with LX zones.

> And is there a property to limit RAM or CPU of an LX zone?

Should work like any other zone brand.

Dan


From danmcd at omniti.com  Thu Mar 30 19:22:05 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 30 Mar 2017 15:22:05 -0400
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <alpine.GSO.2.20.1703301247030.7926@scrappy.simplesystems.org>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<alpine.GSO.2.20.1703301247030.7926@scrappy.simplesystems.org>
Message-ID: <F503E7B0-4E7E-412A-B0BB-0EE20732ECB8@omniti.com>


> On Mar 30, 2017, at 1:51 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> 
> It could be possible to provide alternate work-alike "native" Linux tools but these would need to be provided in source form, or in Linux distribution-specific binary packages.

It could be, but it'd take a LOT longer than even just getting ipadm(1M) to work properly in an LX zone.

Dan


From mtalbott at lji.org  Thu Mar 30 19:29:48 2017
From: mtalbott at lji.org (Michael Talbott)
Date: Thu, 30 Mar 2017 12:29:48 -0700
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
Message-ID: <B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>

I have experienced the same /etc/resolv.conf issue in a CentOS 6 and 7 LX zones. No DNS servers get propagated from zonecfg.

Oh, and I am on the same boat with ipadm. Would likely never use it inside an LX zone.

Michael


> On Mar 30, 2017, at 12:21 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Mar 30, 2017, at 3:19 AM, Guenther Alka <alka at hfg-gmuend.de> wrote:
>> 
>> Setting ip properties atthe virtualisation layer
>> seems not straight forward to me. Lately I was
>> asked about the problem where DNS onUbuntu 16
>> was not working despite the setting in the zone.cfg
>> (Configurating /etc/resolv in Linux was needed)
> 
> Yeah, that may be some distro weirdness.  It may also be something that our install or boot scripts need help with as well.
> 
>> I would prefer a more ESXi like behaviour where settings
>> about hardware like (lofi) disks, CPU, RAM, vnics are zone
>> settings while network configuration is done by the VM
>> itself with the different but regular Linux tools and ways.
> 
> Oh I didn't say "linux tools".  I said "ipadm(1M)" which is in /native/sbin and works like it does in the global zone or an ipkg/lipkg zone.
> 
>> A related question
>> Exclusive ip access over a dedicated vnic is working.
>> I had problems with shared/ bridged access to a physical nic
>> that is in use by OmniOS itself or a different zone. Is that possible?
> 
> Shared-stack IP is not allowed with LX zones.
> 
>> And is there a property to limit RAM or CPU of an LX zone?
> 
> Should work like any other zone brand.
> 
> Dan
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From vab at bb-c.de  Thu Mar 30 20:03:06 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Thu, 30 Mar 2017 22:03:06 +0200
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
Message-ID: <22749.25722.419198.43085@urukhai.local>

Michael Talbott writes:
> I have experienced the same /etc/resolv.conf issue in a CentOS 6 and 7 LX
> zones. No DNS servers get propagated from zonecfg.

Me, too.  The default search domain does get set, however.  Maybe it
is a trivial thing.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

From bfriesen at simple.dallas.tx.us  Thu Mar 30 20:26:24 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Thu, 30 Mar 2017 15:26:24 -0500 (CDT)
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
Message-ID: <alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>

On Thu, 30 Mar 2017, Michael Talbott wrote:

> I have experienced the same /etc/resolv.conf issue in a CentOS 6 and 
> 7 LX zones. No DNS servers get propagated from zonecfg.

The only way it could possibly work is if /etc/resolv.conf gets 
updated in the zone.  This is because native user-space apps/libraries 
take care of the DNS lookups rather than kernel code.

The Linux dhcp client is likely to overwrite the content of 
/etc/resolv.conf if the dhcp client is enabled (typical default). 
Anything written when the zone is configured would be overwritten.

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

From danmcd at omniti.com  Thu Mar 30 20:31:19 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 30 Mar 2017 16:31:19 -0400
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
Message-ID: <FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>


> On Mar 30, 2017, at 4:26 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> 
> The only way it could possibly work is if /etc/resolv.conf gets updated in the zone.  This is because native user-space apps/libraries take care of the DNS lookups rather than kernel code.

Check out /usr/lib/brand/lx/lx_boot_zone_*.  Those scripts scribble resolv.conf at zone boot time.

Dan


From bfriesen at simple.dallas.tx.us  Thu Mar 30 21:02:52 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Thu, 30 Mar 2017 16:02:52 -0500 (CDT)
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
Message-ID: <alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>

On Thu, 30 Mar 2017, Dan McDonald wrote:

>
>> On Mar 30, 2017, at 4:26 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
>>
>> The only way it could possibly work is if /etc/resolv.conf gets updated in the zone.  This is because native user-space apps/libraries take care of the DNS lookups rather than kernel code.
>
> Check out /usr/lib/brand/lx/lx_boot_zone_*.  Those scripts scribble resolv.conf at zone boot time.

Linux DHCP can overwrite files at any time, possibly weeks after boot.

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

From danmcd at omniti.com  Thu Mar 30 21:04:12 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 30 Mar 2017 17:04:12 -0400
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
Message-ID: <83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com>


> On Mar 30, 2017, at 5:02 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> 
> On Thu, 30 Mar 2017, Dan McDonald wrote:
> 
>> 
>>> On Mar 30, 2017, at 4:26 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
>>> 
>>> The only way it could possibly work is if /etc/resolv.conf gets updated in the zone.  This is because native user-space apps/libraries take care of the DNS lookups rather than kernel code.
>> 
>> Check out /usr/lib/brand/lx/lx_boot_zone_*.  Those scripts scribble resolv.conf at zone boot time.
> 
> Linux DHCP can overwrite files at any time, possibly weeks after boot.

Interesting.

Given "lxinit" does DHCP too, you probably shouldn't be using any Linux DHCP client in an LX zone.

Dan


From wonko at 4amlunch.net  Thu Mar 30 21:11:11 2017
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Thu, 30 Mar 2017 17:11:11 -0400
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com>
Message-ID: <CAFETE_ubcJj+5Sgq6WxBsf38jWXtm88K2JC0mgkoEKkKQwO+VA@mail.gmail.com>

I'd like to see a way that network configuration can be disabled from
within the zone so that it's set by the host admin and not the zone admin
(assuming they are different people).

Is this a possibility?

On Mar 30, 2017 5:04 PM, "Dan McDonald" <danmcd at omniti.com> wrote:

>
> > On Mar 30, 2017, at 5:02 PM, Bob Friesenhahn <
> bfriesen at simple.dallas.tx.us> wrote:
> >
> > On Thu, 30 Mar 2017, Dan McDonald wrote:
> >
> >>
> >>> On Mar 30, 2017, at 4:26 PM, Bob Friesenhahn <
> bfriesen at simple.dallas.tx.us> wrote:
> >>>
> >>> The only way it could possibly work is if /etc/resolv.conf gets
> updated in the zone.  This is because native user-space apps/libraries take
> care of the DNS lookups rather than kernel code.
> >>
> >> Check out /usr/lib/brand/lx/lx_boot_zone_*.  Those scripts scribble
> resolv.conf at zone boot time.
> >
> > Linux DHCP can overwrite files at any time, possibly weeks after boot.
>
> Interesting.
>
> Given "lxinit" does DHCP too, you probably shouldn't be using any Linux
> DHCP client in an LX zone.
>
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170330/be63b7f5/attachment-0001.html>

From henson at acm.org  Thu Mar 30 21:16:21 2017
From: henson at acm.org (Paul B. Henson)
Date: Thu, 30 Mar 2017 14:16:21 -0700
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
Message-ID: <20170330211620.GV20300@bender.unx.cpp.edu>

On Thu, Mar 30, 2017 at 04:02:52PM -0500, Bob Friesenhahn wrote:

> Linux DHCP can overwrite files at any time, possibly weeks after boot.

You can configure it not to; for example, with dhcpcd, you would use the
option '--nohook resolv.conf'. Other clients have similar options.

From bfriesen at simple.dallas.tx.us  Thu Mar 30 21:46:55 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Thu, 30 Mar 2017 16:46:55 -0500 (CDT)
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <20170330211620.GV20300@bender.unx.cpp.edu>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<20170330211620.GV20300@bender.unx.cpp.edu>
Message-ID: <alpine.GSO.2.20.1703301644210.7926@scrappy.simplesystems.org>

On Thu, 30 Mar 2017, Paul B. Henson wrote:
>
>> Linux DHCP can overwrite files at any time, possibly weeks after boot.
>
> You can configure it not to; for example, with dhcpcd, you would use the
> option '--nohook resolv.conf'. Other clients have similar options.

This is all very true.

Something I see is that with normal Solaris zones, one can provide 
root access to a relatively untrusted third-party since everything 
important can be locked-down.  This approach should currently not be 
used with LX Zones.

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

From danmcd at omniti.com  Fri Mar 31 02:38:11 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 30 Mar 2017 22:38:11 -0400
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <CAFETE_ubcJj+5Sgq6WxBsf38jWXtm88K2JC0mgkoEKkKQwO+VA@mail.gmail.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com>
	<CAFETE_ubcJj+5Sgq6WxBsf38jWXtm88K2JC0mgkoEKkKQwO+VA@mail.gmail.com>
Message-ID: <9F84445C-29AF-4536-80D6-1453198C4097@omniti.com>


> On Mar 30, 2017, at 5:11 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> 
> I'd like to see a way that network configuration can be disabled from within the zone so that it's set by the host admin and not the zone admin (assuming they are different people).

I thought more people would be in agreement with you, but that appears not to be the case.

Rewriting lxinit & friends to allow this sort of admin model is going to be harder than I thought, and since r151022 is already late relative to prior releases (it's a cadence-breaker thanks to Loader, Python2.7, and Kayak-for-ISO), I don't know if getting ipadm(1M) for LX zones would work.  You're the strongest endorser of doing it so far.

Dan


From josh at sysmgr.org  Fri Mar 31 06:04:53 2017
From: josh at sysmgr.org (Joshua M. Clulow)
Date: Thu, 30 Mar 2017 23:04:53 -0700
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <alpine.GSO.2.20.1703301644210.7926@scrappy.simplesystems.org>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<20170330211620.GV20300@bender.unx.cpp.edu>
	<alpine.GSO.2.20.1703301644210.7926@scrappy.simplesystems.org>
Message-ID: <CAEwA5nLP0F9mCMGbYXHY19_tebcyRfBPpBjWVEdB-L8YuqPDiQ@mail.gmail.com>

On 30 March 2017 at 14:46, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> Something I see is that with normal Solaris zones, one can provide root
> access to a relatively untrusted third-party since everything important can
> be locked-down.  This approach should currently not be used with LX Zones.

Why is that?  There shouldn't be any difference between a native zone
and an LX zone with respect to untrusted workloads.  The containment
model is the same in both cases.


Cheers.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org

From peter.tribble at gmail.com  Fri Mar 31 08:28:00 2017
From: peter.tribble at gmail.com (Peter Tribble)
Date: Fri, 31 Mar 2017 09:28:00 +0100
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <9F84445C-29AF-4536-80D6-1453198C4097@omniti.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com>
	<CAFETE_ubcJj+5Sgq6WxBsf38jWXtm88K2JC0mgkoEKkKQwO+VA@mail.gmail.com>
	<9F84445C-29AF-4536-80D6-1453198C4097@omniti.com>
Message-ID: <CAEgYsbFKP3BGsx5=LcAfRJOU2hH7PE+FrpR8eyOFzZCjbMbh4Q@mail.gmail.com>

On Fri, Mar 31, 2017 at 3:38 AM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On Mar 30, 2017, at 5:11 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> >
> > I'd like to see a way that network configuration can be disabled from
> within the zone so that it's set by the host admin and not the zone admin
> (assuming they are different people).
>
> I thought more people would be in agreement with you, but that appears not
> to be the case.
>

Well that's what I want, absolutely.

Although it's not just LX, I would also like global-zone configuration of
native exclusive-ip zones, which is not necessarily the same problem.


> Rewriting lxinit & friends to allow this sort of admin model is going to
> be harder than I thought, and since r151022 is already late relative to
> prior releases (it's a cadence-breaker thanks to Loader, Python2.7, and
> Kayak-for-ISO), I don't know if getting ipadm(1M) for LX zones would work.
> You're the strongest endorser of doing it so far.
>
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



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

From omnios at citrus-it.net  Fri Mar 31 10:54:42 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Fri, 31 Mar 2017 10:54:42 +0000 (UTC)
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <9F84445C-29AF-4536-80D6-1453198C4097@omniti.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com>
	<CAFETE_ubcJj+5Sgq6WxBsf38jWXtm88K2JC0mgkoEKkKQwO+VA@mail.gmail.com>
	<9F84445C-29AF-4536-80D6-1453198C4097@omniti.com>
Message-ID: <alpine.GSO.2.20.1703311052520.139370@erncre.pvgehf-vg.arg>



On Thu, 30 Mar 2017, Dan McDonald wrote:

;
; > On Mar 30, 2017, at 5:11 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
; >
; > I'd like to see a way that network configuration can be disabled from within the zone so that it's set by the host admin and not the zone admin (assuming they are different people).
;
; I thought more people would be in agreement with you, but that appears not to be the case.
;
; Rewriting lxinit & friends to allow this sort of admin model is going to be harder than I thought, and since r151022 is already late relative to prior releases (it's a cadence-breaker thanks to Loader, Python2.7, and Kayak-for-ISO), I don't know if getting ipadm(1M) for LX zones would work.  You're the strongest endorser of doing it so far.

I read Brian's comment as wanting to stop network configuration from within
the zone => no ipadm. That's what I want too - if I set up a Linux zone and
hand control over, I don't want the zone root user to be able to change
the IP address.

Andy

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


From hasslerd at gmx.li  Fri Mar 31 11:33:55 2017
From: hasslerd at gmx.li (Dominik Hassler)
Date: Fri, 31 Mar 2017 13:33:55 +0200
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <alpine.GSO.2.20.1703300759410.648441@erncre.pvgehf-vg.arg>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<CAN0RhAN1_uCg0sbOM54x6OxSkPO8Gg0RYKLKNHJcYZRyS0C15Q@mail.gmail.com>
	<alpine.GSO.2.20.1703300759410.648441@erncre.pvgehf-vg.arg>
Message-ID: <174ab0cc-532b-b24f-117a-ad5b79cdadf1@gmx.li>



On 03/30/2017 10:00 AM, Andy Fiddaman wrote:
>
>
> On Thu, 30 Mar 2017, Ludovic Orban wrote:
>
> ; I personally don't need ipadm in my LX zones, nerver missed it and I'm
> ; pretty certain I wouldn't use it even if it was available.
>
> Same here.

+1

From bfriesen at simple.dallas.tx.us  Fri Mar 31 13:32:51 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 31 Mar 2017 08:32:51 -0500 (CDT)
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <CAEwA5nLP0F9mCMGbYXHY19_tebcyRfBPpBjWVEdB-L8YuqPDiQ@mail.gmail.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<20170330211620.GV20300@bender.unx.cpp.edu>
	<alpine.GSO.2.20.1703301644210.7926@scrappy.simplesystems.org>
	<CAEwA5nLP0F9mCMGbYXHY19_tebcyRfBPpBjWVEdB-L8YuqPDiQ@mail.gmail.com>
Message-ID: <alpine.GSO.2.20.1703310828410.27192@freddy.simplesystems.org>

On Thu, 30 Mar 2017, Joshua M. Clulow wrote:

> On 30 March 2017 at 14:46, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
>> Something I see is that with normal Solaris zones, one can provide root
>> access to a relatively untrusted third-party since everything important can
>> be locked-down.  This approach should currently not be used with LX Zones.
>
> Why is that?  There shouldn't be any difference between a native zone
> and an LX zone with respect to untrusted workloads.  The containment
> model is the same in both cases.

I made an over-statement.  The threat level to the global zone and 
network is similar.  What is not similar is that well known Linux 
system admistration methods may cause the Linux install to stop 
working.  Merely installing a package which uses network interfaces 
might cause harm to the Linux installation.

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

From mir at miras.org  Fri Mar 31 14:02:08 2017
From: mir at miras.org (Michael Rasmussen)
Date: Fri, 31 Mar 2017 16:02:08 +0200
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <alpine.GSO.2.20.1703310828410.27192@freddy.simplesystems.org>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<20170330211620.GV20300@bender.unx.cpp.edu>
	<alpine.GSO.2.20.1703301644210.7926@scrappy.simplesystems.org>
	<CAEwA5nLP0F9mCMGbYXHY19_tebcyRfBPpBjWVEdB-L8YuqPDiQ@mail.gmail.com>
	<alpine.GSO.2.20.1703310828410.27192@freddy.simplesystems.org>
Message-ID: <20170331160208.0fa886da@sleipner.datanom.net>

On Fri, 31 Mar 2017 08:32:51 -0500 (CDT)
Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:

> 
> I made an over-statement.  The threat level to the global zone and network is similar.  What is not similar is that well known Linux system admistration methods may cause the Linux install to stop working.  Merely installing a package which uses network interfaces might cause harm to the Linux installation.
> 
Without access to network configuration using client native network
tools prevents using network based and/or PXE booted installs.

-- 
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 always avoid prophesying beforehand because it is much better
  to prophesy after the event has already taken place. " - Winston
  Churchill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170331/ecf6b2d9/attachment.bin>

From danmcd at omniti.com  Fri Mar 31 14:59:39 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 31 Mar 2017 10:59:39 -0400
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <alpine.GSO.2.20.1703311052520.139370@erncre.pvgehf-vg.arg>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com>
	<CAFETE_ubcJj+5Sgq6WxBsf38jWXtm88K2JC0mgkoEKkKQwO+VA@mail.gmail.com>
	<9F84445C-29AF-4536-80D6-1453198C4097@omniti.com>
	<alpine.GSO.2.20.1703311052520.139370@erncre.pvgehf-vg.arg>
Message-ID: <F602F151-5863-4F43-A2E9-A0E9E2D8454F@omniti.com>


> On Mar 31, 2017, at 6:54 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> 
> I don't want the zone root user to be able to change
> the IP address.

Well, so far, that seems to be the case, so it's looking like not changing anything is a good thing.

And then in another mail... Bob F. says...

> What is not similar is that well known Linux system admistration methods may cause the Linux install to stop working.  Merely installing a package which uses network interfaces might cause harm to the Linux installation.

Given that the purpose of LX zones is primarily to run apps (not necessarily admin tools for the installation itself), I'm not sure if this is something I can prevent.  I suspect if you got an LX zone on the Joyent Public Cloud and used those same tools, you'd land in a similar mess.

Dan


From vab at bb-c.de  Fri Mar 31 16:54:28 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Fri, 31 Mar 2017 18:54:28 +0200
Subject: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?
In-Reply-To: <F602F151-5863-4F43-A2E9-A0E9E2D8454F@omniti.com>
References: <FA73B84C-610F-4A4C-9BF0-B190BFC0EFD3@omniti.com>
	<OF6A65B1A1.600B4D76-ONC12580F3.001E3683-C12580F3.001E3695@inse.com>
	<b9904a12-3dad-27be-8a07-bf19a14badc5@hfg-gmuend.de>
	<F227A55C-65BC-4343-8653-A40D11730FC2@omniti.com>
	<B0BEA1F9-57F6-4C9F-AFBA-AA3BC9ACB411@lji.org>
	<alpine.GSO.2.20.1703301521410.7926@scrappy.simplesystems.org>
	<FE81F7CA-D1D4-432E-BA26-923F97F3AB79@omniti.com>
	<alpine.GSO.2.20.1703301601560.7926@scrappy.simplesystems.org>
	<83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com>
	<CAFETE_ubcJj+5Sgq6WxBsf38jWXtm88K2JC0mgkoEKkKQwO+VA@mail.gmail.com>
	<9F84445C-29AF-4536-80D6-1453198C4097@omniti.com>
	<alpine.GSO.2.20.1703311052520.139370@erncre.pvgehf-vg.arg>
	<F602F151-5863-4F43-A2E9-A0E9E2D8454F@omniti.com>
Message-ID: <22750.35268.507153.877411@urukhai.local>

Dan McDonald writes:
> > On Mar 31, 2017, at 6:54 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> >
> > I don't want the zone root user to be able to change
> > the IP address.
> 
> Well, so far, that seems to be the case, so it's looking like not changing anything is a good thing.

When I did a demo using a Centos 7.3 LX branded zone last week, I used
VirtualBox and it's built-in DHCP server for the OmniOS Bloody host.

I simply omitted the IP address when I configured the zone.  From the
zone console, I then used the native "ipadm create-addr -T dhcp ..." to
obtain an address from within the zone.  I can provide details if anyone
would like to see them.

Worked Just Fine(tm). :-)


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 46
Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

