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: References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> <02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com> <20170228184800.4119d335@sleipner.datanom.net> <20170228195845.09f5c4bf@sleipner.datanom.net> Message-ID: 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 wrote: >> >> On Tue, 28 Feb 2017 13:23:24 -0500 >> Dan McDonald wrote: >> >>>> On Feb 28, 2017, at 1:02 PM, Dan McDonald 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 rasmussen cc >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E >> mir datanom net >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C >> mir miras org >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 >> -------------------------------------------------------------- >> /usr/games/fortune -es says: >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: nednihcbkbhmfjhh.png Type: image/png Size: 264756 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kgiiikinidkhbcgi.png Type: image/png Size: 129606 bytes Desc: not available URL: 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: References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> <02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com> <20170228184800.4119d335@sleipner.datanom.net> <20170228195845.09f5c4bf@sleipner.datanom.net> Message-ID: <376CACC4-F847-47CD-B800-228264261244@omniti.com> > On Feb 28, 2017, at 9:33 PM, Doug Hughes 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> <20170228195845.09f5c4bf@sleipner.datanom.net> <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 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> <20170228195845.09f5c4bf@sleipner.datanom.net> <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 wrote: > > > > On 2/28/2017 10:27 PM, Dan McDonald wrote: >>> On Feb 28, 2017, at 9:33 PM, Doug Hughes 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> <27CB83D1-4B09-436F-AA83-1D1CCCD06428@omniti.com> Message-ID: On Tue, Feb 28, 2017 at 10:35 PM, Dan McDonald wrote: > > > On Feb 28, 2017, at 5:22 PM, Peter Tribble > wrote: > > > > Dan, > > > > > 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: 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: 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: References: Message-ID: <236E8D27-9ACC-4B37-9340-DA3BF28B9696@omniti.com> > On Mar 1, 2017, at 8:56 AM, N. Nadine Miller 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> <20170228195845.09f5c4bf@sleipner.datanom.net> <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 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 /pci at 0,0/pci1af4,2 at a/blkdev at 0,0 1. c3t0d0 /pci at 0,0/pci1af4,2 at b/blkdev at 0,0 2. c5t0d0 /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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <20170228195845.09f5c4bf@sleipner.datanom.net> <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 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> <20170228195845.09f5c4bf@sleipner.datanom.net> <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 wrote: > > This is on Xen? There's a fix coming for this: > No, qemu. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: 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 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: 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: References: Message-ID: 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 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" > An: "Stephan Budach" > CC: "omnios-discuss" , "Dan McDonald" > 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 > > 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: 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- ---- 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: <236E8D27-9ACC-4B37-9340-DA3BF28B9696@omniti.com> Message-ID: On Wed, Mar 1, 2017 at 10:39 AM, Dan McDonald wrote: > >> On Mar 1, 2017, at 8:56 AM, N. Nadine Miller 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 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 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" > An: "Stephan Budach" > CC: "omnios-discuss" , "Dan McDonald" > 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 > > 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: 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: 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 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: 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 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: References: <1359485346.693750.1488537144331.JavaMail.zimbra@oetiker.ch> <24EFDB5E-745E-4FA2-9C70-5F1DBD2B6BC9@omniti.com> Message-ID: > On Mar 3, 2017, at 8:56 AM, Tobias Oetiker 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: Dan, On Thu, Mar 2, 2017 at 2:40 AM, Dan McDonald 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 /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: 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: placeholder-exitas.jpg Type: image/jpeg Size: 12658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SmallPhoenixLogotypeRGB.png Type: image/png Size: 4648 bytes Desc: not available URL: 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: References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com> Message-ID: > On Mar 3, 2017, at 10:06 AM, Peter Tribble wrote: > > Dan, > > On Thu, Mar 2, 2017 at 2:40 AM, Dan McDonald 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 > /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: 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: 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: 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: 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: 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: References: Message-ID: <6CACA42B-A8CE-4A8D-9A35-83B5C758B877@omniti.com> > On Mar 5, 2017, at 12:56 PM, Machine Man 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: References: Message-ID: <741165EC-4A21-475A-B96C-D03A9704C49C@omniti.com> > On Mar 5, 2017, at 5:53 PM, Daniel D. Gon?alves 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: 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: References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com> Message-ID: <22F78EFB-683C-4E74-BF60-8A4015242837@omniti.com> > On Mar 7, 2017, at 11:28 AM, Andy Fiddaman 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: 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 [cid:image001.png at 01D2974D.08ADA780] 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! [cid:image002.gif at 01D2974D.08ADA780] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3508 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1351 bytes Desc: image002.gif URL: 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: References: 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 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 > > > 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! > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From 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: References: Message-ID: <0657F116-2C8F-4090-80C5-2C6E6B873046@omniti.com> > On Mar 7, 2017, at 3:13 PM, John Barfield 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 > > > 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! > > > _______________________________________________ > 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: 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: <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 [cid:image001.png at 01D2974E.AD10AC40] 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! [cid:image002.gif at 01D2974E.AD10AC40] From: Dan McDonald Date: Tuesday, March 7, 2017 at 2:21 PM To: John Barfield Cc: "omnios-discuss at lists.omniti.com" , Dan McDonald 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3508 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1351 bytes Desc: image002.gif URL: 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: <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 or support at bissinc.com Follow us on Twitter for Network Status & Updates! On 3/7/17, 2:22 PM, "Dale Ghent" wrote: > On Mar 7, 2017, at 3:13 PM, John Barfield 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 > > > 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! > > > _______________________________________________ > 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: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com> <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com> Message-ID: 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 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 > > > 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! > > > > From: Dan McDonald > Date: Tuesday, March 7, 2017 at 2:21 PM > To: John Barfield > Cc: "omnios-discuss at lists.omniti.com" , Dan McDonald > 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: 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: 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" > Date: March 7, 2017 at 3:33:40 PM EST > To: illumos-dev > 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: 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: References: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com> <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com> Message-ID: 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 [cid:image001.png at 01D29752.1CE09B40] 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! [cid:image002.gif at 01D29752.1CE09B40] From: Dan McDonald Date: Tuesday, March 7, 2017 at 2:32 PM To: John Barfield Cc: "omnios-discuss at lists.omniti.com" , Dan McDonald 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 > 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 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! From: Dan McDonald > Date: Tuesday, March 7, 2017 at 2:21 PM To: John Barfield > Cc: "omnios-discuss at lists.omniti.com" >, Dan McDonald > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3508 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1351 bytes Desc: image002.gif URL: -------------- 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: -------------- 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: 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: References: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com> <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com> Message-ID: 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 [cid:image001.png at 01D29759.F1FD0460] 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! [cid:image002.gif at 01D29759.F1FD0460] From: Dan McDonald Date: Tuesday, March 7, 2017 at 2:32 PM To: John Barfield Cc: "omnios-discuss at lists.omniti.com" , Dan McDonald 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 > 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 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! From: Dan McDonald > Date: Tuesday, March 7, 2017 at 2:21 PM To: John Barfield > Cc: "omnios-discuss at lists.omniti.com" >, Dan McDonald > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3508 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1351 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: volatile.zip Type: application/zip Size: 2672 bytes Desc: volatile.zip URL: 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: References: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com> <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com> Message-ID: <6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com> > On Mar 7, 2017, at 4:46 PM, John Barfield wrote: > > 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: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com> <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com> <6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com> Message-ID: 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 or support at bissinc.com Follow us on Twitter for Network Status & Updates! On 3/7/17, 4:17 PM, "Dan McDonald" wrote: > On Mar 7, 2017, at 4:46 PM, John Barfield wrote: > > 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: References: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com> <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com> <6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com> Message-ID: > On Mar 7, 2017, at 5:22 PM, John Barfield 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: 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: References: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com> <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com> <6E417E47-646D-4922-B017-417DA5B9C97D@omniti.com> Message-ID: >> 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: References: <4BD876AB-CD56-4371-BB88-00E67816A8A9@omniti.com> <7CAA0F06-BFD5-4BD1-BB26-E920B17AA028@bissinc.com> <6E417E47-646D-4922-B017-417DA5B9C97D@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 or support at bissinc.com Follow us on Twitter for Network Status & Updates! On 3/7/17, 4:50 PM, "Dan McDonald" 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: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: omnios-kayak-disks.png Type: image/png Size: 11962 bytes Desc: not available URL: 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 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: <237225B6-6EC9-4A0A-89EA-25E021F994C9@omniti.com> Message-ID: 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" > An: "Geoff Nordli" > CC: "omnios-discuss" > 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 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: 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" >> An: "Geoff Nordli" >> CC: "omnios-discuss" >> 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 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: 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: 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: <1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de> ----- Urspr?ngliche Mail ----- > Von: "Dan McDonald" > An: "Geoff Nordli" > CC: "omnios-discuss" > 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: 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: References: Message-ID: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de> Hi Prakash, ----- Urspr?ngliche Mail ----- > Von: "Prakash Surya" > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: 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> , <1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de> Message-ID: 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 wrote: > > > > ----- Urspr?ngliche Mail ----- >> Von: "Dan McDonald" >> An: "Geoff Nordli" >> CC: "omnios-discuss" >> 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> <22F78EFB-683C-4E74-BF60-8A4015242837@omniti.com> Message-ID: On Tue, 7 Mar 2017, Dan McDonald wrote: ; ; > On Mar 7, 2017, at 11:28 AM, Andy Fiddaman 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: References: <237225B6-6EC9-4A0A-89EA-25E021F994C9@omniti.com> Message-ID: On Wed, Mar 8, 2017 at 1:41 AM, Tim Rice 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: 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: 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: 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: SmallPhoenixLogotypeRGB.png Type: image/png Size: 4648 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: placeholder-exitas.jpg Type: image/jpeg Size: 12658 bytes Desc: not available URL: 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: <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 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: -------------- 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: -------------- 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: -------------- 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: -------------- 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: -------------- 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: 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: References: <678CB888-450E-4D4B-AF44-4B28201691F2@omniti.com> <22F78EFB-683C-4E74-BF60-8A4015242837@omniti.com> Message-ID: <22C49704-5CC9-43DE-84BE-55D7AC939D3C@omniti.com> > On Mar 8, 2017, at 5:43 AM, Andy Fiddaman 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 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> <1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de> Message-ID: 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" >> An: "Geoff Nordli" >> CC: "omnios-discuss" >> 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: 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: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de> <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com> Message-ID: On Wed, Mar 8, 2017 at 10:08 AM, Dan McDonald wrote: > > On Mar 8, 2017, at 2:28 AM, Stephan Budach 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: 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: References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net> 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: References: <847fde02-f532-211e-9632-049c9269d6ef@gnaa.net> Message-ID: 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: 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> <1731769e-a1cc-d07c-46c4-4750a55b4109@yuma.acns.colostate.edu> Message-ID: 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: 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> <1097156201.164.1488957894504.JavaMail.stephan.budach@stephan.budach.jvm.de> Message-ID: 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 wrote: >> >> >> >> ----- Urspr?ngliche Mail ----- >>> Von: "Dan McDonald" >>> An: "Geoff Nordli" >>> CC: "omnios-discuss" >>> 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: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de> <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.com> Message-ID: 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 wrote: > > On Mar 8, 2017, at 2:28 AM, Stephan Budach 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: -------------- 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: -------------- 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: -------------- 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: -------------- 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: -------------- 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: 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: References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be> 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 > 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 > 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 4648 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: placeholder-exitas.jpg Type: image/jpeg Size: 12658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SmallPhoenixLogotypeRGB.png Type: image/png Size: 4648 bytes Desc: not available URL: 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> , <5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be> Message-ID: 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: 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: References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be> <5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be> 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> <5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be> , <20170308212916.oq57sj2jnpyhr5oa@volny.cz> Message-ID: 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 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: 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 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: 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: References: <7a45350d-cae3-3e8f-617b-e58bc4e8a28e@exitas.be> <5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be> <20170308212916.oq57sj2jnpyhr5oa@volny.cz> 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> Message-ID: 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 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 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: 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> Message-ID: <292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local> Hi Jens, ----- Urspr?ngliche Mail ----- > Von: "Jens Bauernfeind" > An: "omnios-discuss" > 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: 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> <292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local> Message-ID: 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 Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is almost beta Hi Jens, ----- Urspr?ngliche Mail ----- > Von: "Jens Bauernfeind" > An: "omnios-discuss" > 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: 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> <292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local> Message-ID: 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 Cc: omnios-discuss 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 Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Bloody update on Repo, plus Kayak for ISO is almost beta Hi Jens, ----- Urspr?ngliche Mail ----- > Von: "Jens Bauernfeind" > An: "omnios-discuss" > 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: 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" > To: "Manuel Oetiker" > 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> Message-ID: 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 > 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 > 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: 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> <5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be> <20170308212916.oq57sj2jnpyhr5oa@volny.cz> , <20170309085514.mkbf5c2scl6imjd6@volny.cz> Message-ID: 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 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: > On Mar 9, 2017, at 8:27 AM, Manuel Oetiker 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> Message-ID: <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> > On Mar 9, 2017, at 2:52 AM, Jens Bauernfeind 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> Message-ID: <81049D39-1429-48EA-AA1B-5EE6038AFB17@omniti.com> > On Mar 9, 2017, at 9:29 AM, Prakash Surya 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> Message-ID: 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 Cc: omnios-discuss ; Dan McDonald 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 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: 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: 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> <292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local> Message-ID: <1752144629.965.1489074026813.JavaMail.stephan.budach@stephanbudach.local> Bummer? ----- Urspr?ngliche Mail ----- > Von: "Jens Bauernfeind" > An: "Stephan Budach" > CC: "omnios-discuss" > 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: 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> <292127257.649.1489056331262.JavaMail.stephan.budach@stephanbudach.local> <1752144629.965.1489074026813.JavaMail.stephan.budach@stephanbudach.local> Message-ID: <1161910211.969.1489074553789.JavaMail.stephan.budach@stephanbudach.local> ----- Urspr?ngliche Mail ----- > Von: "Stephan Budach" > An: "Jens Bauernfeind" > CC: "omnios-discuss" > 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" > > An: "Stephan Budach" > > CC: "omnios-discuss" > > 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: 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 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> Message-ID: > On Mar 9, 2017, at 10:11 AM, Jens Bauernfeind 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> <5c2e0580-d578-69bb-c5cc-7cdb92bb2665@exitas.be> Message-ID: 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 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 > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: placeholder-exitas.jpg Type: image/jpeg Size: 12658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SmallPhoenixLogotypeRGB.png Type: image/png Size: 4648 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 4648 bytes Desc: not available URL: 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: 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: 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: References: Message-ID: <37C45A89-F894-43F1-A908-DAA0E1F6136F@omniti.com> > On Mar 9, 2017, at 1:06 PM, John Barfield 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: References: Message-ID: 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 : > 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: 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. 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: 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> Message-ID: <20170309214633.52905b34@sleipner.datanom.net> On Thu, 9 Mar 2017 11:18:17 -0500 Dan McDonald 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@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 wrote: > > On Thu, 9 Mar 2017 11:18:17 -0500 > Dan McDonald 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> <20170309214633.52905b34@sleipner.datanom.net> <268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com> <20170309220259.5b977199@sleipner.datanom.net> Message-ID: > On Mar 9, 2017, at 4:02 PM, Michael Rasmussen 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@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: > On Mar 9, 2017, at 4:17 PM, Michael Rasmussen 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@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 cr4: b8 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 wrote: >> >> On Thu, 9 Mar 2017 11:18:17 -0500 >> Dan McDonald 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: References: Message-ID: On Thu, Mar 9, 2017 at 8:28 PM, Dan McDonald 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: 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: > - 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: 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> <22721.52318.11027.49651@urukhai.local> 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: > On Mar 9, 2017, at 4:42 PM, Volker A. Brandt wrote: > > Hi Dan! > > > - 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: References: Message-ID: <886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com> > On Mar 9, 2017, at 4:44 PM, Peter Tribble wrote: > > This doesn't appear to be carried through to the installed system. 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> <20170309214633.52905b34@sleipner.datanom.net> <268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com> <20170309220259.5b977199@sleipner.datanom.net> Message-ID: <20170309231806.2ebda4df@sleipner.datanom.net> On Thu, 9 Mar 2017 16:20:07 -0500 Dan McDonald 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> <20170309214633.52905b34@sleipner.datanom.net> <268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com> <20170309220259.5b977199@sleipner.datanom.net> <20170309231806.2ebda4df@sleipner.datanom.net> Message-ID: > On Mar 9, 2017, at 5:18 PM, Michael Rasmussen 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> <20170309214633.52905b34@sleipner.datanom.net> <268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com> <20170309220259.5b977199@sleipner.datanom.net> <20170309231806.2ebda4df@sleipner.datanom.net> Message-ID: <20170309232607.42bc5207@sleipner.datanom.net> On Thu, 9 Mar 2017 17:19:43 -0500 Dan McDonald 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: <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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> <20170309214633.52905b34@sleipner.datanom.net> <268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com> <20170309220259.5b977199@sleipner.datanom.net> <20170309231806.2ebda4df@sleipner.datanom.net> <20170309232607.42bc5207@sleipner.datanom.net> Message-ID: <6A091B2E-9E69-4B27-A6B0-58128C557AE7@omniti.com> > On Mar 9, 2017, at 5:26 PM, Michael Rasmussen 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: <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 wrote: > > On Thu, 9 Mar 2017 16:58:45 -0500 > Dan McDonald 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: <886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com> <20170309233547.01b55bff@sleipner.datanom.net> <5BFA66C5-1982-42DA-8C6D-7728038A4640@omniti.com> Message-ID: > On Mar 9, 2017, at 5:39 PM, Dan McDonald wrote: > > >> On Mar 9, 2017, at 5:35 PM, Michael Rasmussen wrote: >> >> On Thu, 9 Mar 2017 16:58:45 -0500 >> Dan McDonald 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: <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 wrote: > > That's how it works already!!! :) > Nice :-) -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <49C42BEE-F805-4FD1-8820-BD51C60822A8@omniti.com> <20170309214633.52905b34@sleipner.datanom.net> <268254BC-3567-4E41-B6AB-9A04E6A5B276@omniti.com> <20170309220259.5b977199@sleipner.datanom.net> <20170309231806.2ebda4df@sleipner.datanom.net> <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 wrote: > > On Mar 9, 2017, at 5:26 PM, Michael Rasmussen 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: References: <886E61E8-AC55-4E8C-AF78-467299CBACFE@omniti.com> <20170309233547.01b55bff@sleipner.datanom.net> <5BFA66C5-1982-42DA-8C6D-7728038A4640@omniti.com> Message-ID: <329824C8-D5A8-4DAE-A42C-6FF81A858B34@omniti.com> > On Mar 9, 2017, at 5:43 PM, Dan McDonald 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: -------------- 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: -------------- 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: 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: 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: References: 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 >: > > 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 list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <58C27EB1.40505@btconnect.com> Message-ID: if you use omnios, install from package* system/monitoring/arcstat* ??, 10 ???. 2017 ?. ? 13:23, Richard Skelton : > 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 : > > 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: 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: References: <58C27EB1.40505@btconnect.com> Message-ID: 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 >: > > 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 >> >: >> >> 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 list >> OmniOS-discuss at lists.omniti.com >> >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> <22721.52318.11027.49651@urukhai.local> Message-ID: 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: 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: References: <581AFE8E-F340-4492-AE54-35E71FDAA21D@omniti.com> <22721.52318.11027.49651@urukhai.local> 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> <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 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: References: Message-ID: <20170311161305.12505147@sleipner.datanom.net> On Thu, 9 Mar 2017 15:28:16 -0500 Dan McDonald 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: References: Message-ID: <20170311162639.41e78835@sleipner.datanom.net> On Thu, 9 Mar 2017 15:28:16 -0500 Dan McDonald 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: 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: <20170311161305.12505147@sleipner.datanom.net> Message-ID: > On Mar 11, 2017, at 10:13 AM, Michael Rasmussen 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: References: Message-ID: <9C3A12D5-AED3-4BAD-89A4-0E7E71D963C5@richardelling.com> > On Mar 9, 2017, at 10:06 AM, John Barfield 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: 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: References: <20170311161305.12505147@sleipner.datanom.net> Message-ID: <20170312130631.05bf1b6b@sleipner.datanom.net> On Sat, 11 Mar 2017 17:07:31 -0500 Dan McDonald 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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 wrote: > On Sat, 11 Mar 2017 21:54:43 -0500 > Dan McDonald 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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 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 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 " 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 " not "grep -w ", 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: 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 Cc: omnios-discuss Subject: Re: [OmniOS-discuss] New media with new fixes! > On Mar 12, 2017, at 8:36 AM, Michael Rasmussen 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 " 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 " not "grep -w ", 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: 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: 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: > On Mar 13, 2017, at 2:36 AM, Jens Bauernfeind 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: 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: <2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com> > On Mar 13, 2017, at 7:56 AM, Dan McDonald 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: 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 root at omnitool:/root# uname -a SunOS omnitool 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc This link refers to a VMware KB 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: 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> , <2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com> Message-ID: 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 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: References: Message-ID: 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 root at omnitool:/root# uname -a SunOS omnitool 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc This link refers to a VMware KB 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: 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: 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> <2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com> 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> <2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com> <22727.1682.51883.355266@shelob.bb-c.de> Message-ID: > On Mar 13, 2017, at 4:52 PM, Volker A. Brandt 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: References: Message-ID: 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 > > root at omnitool:/root# uname -a > SunOS omnitool 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc > > This link refers to a VMware > KB > > 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: 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: References: 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 > > root at omnitool:/root# uname -a > SunOS omnitool 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc > > This link refers to a > VMware KB > > 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 > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From 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: 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> <2E09A376-79F7-4350-B567-5C56F53EF1DB@omniti.com> <22727.1682.51883.355266@shelob.bb-c.de> Message-ID: <22727.7191.879654.22033@shelob.bb-c.de> Dan McDonald writes: > > > On Mar 13, 2017, at 4:52 PM, Volker A. Brandt 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: , <6CACA42B-A8CE-4A8D-9A35-83B5C758B877@omniti.com> Message-ID: 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 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 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: 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: 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: References: 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: > On Mar 15, 2017, at 5:56 PM, Volker A. Brandt 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: References: <22729.47225.826646.769250@shelob.bb-c.de> Message-ID: <22729.47584.458425.731396@shelob.bb-c.de> Dan McDonald writes: > > > On Mar 15, 2017, at 5:56 PM, Volker A. Brandt 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: <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: 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: References: <22729.47225.826646.769250@shelob.bb-c.de> 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> <22729.52095.799889.895036@shelob.bb-c.de> Message-ID: 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: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: pasted1 Type: image/png Size: 310722 bytes Desc: not available URL: 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: References: Message-ID: 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 : > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: pasted1 Type: image/png Size: 310722 bytes Desc: not available URL: 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 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: References: Message-ID: > On Mar 17, 2017, at 4:44 AM, Artem Penner 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: References: Message-ID: > On Mar 17, 2017, at 7:14 AM, Artem Penner 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: References: Message-ID: 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 : > > > On Mar 17, 2017, at 4:44 AM, Artem Penner 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: -------------- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: system Type: application/octet-stream Size: 1771 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sd.conf Type: application/octet-stream Size: 4494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scsi_vhci.conf Type: application/octet-stream Size: 2513 bytes Desc: not available URL: 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: References: Message-ID: >> 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 : > > > On Mar 17, 2017, at 7:14 AM, Artem Penner 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: 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: References: 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: <21A73104-AB1D-4CFF-AF70-F9D6605CCAD5@omniti.com> Message-ID: 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 : > 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: 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: References: <326695157.1392.1489422006874.JavaMail.zimbra@oetiker.ch> 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 cat /proc/*/psinfo > /dev/null >>> >>> I'll want to see that output from . 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: References: <21A73104-AB1D-4CFF-AF70-F9D6605CCAD5@omniti.com> Message-ID: 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 : 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 : 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: 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> <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 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> <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 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 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: 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: References: <237225B6-6EC9-4A0A-89EA-25E021F994C9@omniti.com> Message-ID: 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: 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 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: > On Mar 20, 2017, at 5:25 AM, Stephan Budach 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: 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: References: <21A73104-AB1D-4CFF-AF70-F9D6605CCAD5@omniti.com> Message-ID: >> >> 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: 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: 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: 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: References: Message-ID: <92615562-DC29-498A-963D-305E088F0A93@omniti.com> > On Mar 21, 2017, at 11:11 AM, Software Information 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: References: Message-ID: 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: 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: 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: References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com> Message-ID: 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 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: References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com> Message-ID: 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: References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com> Message-ID: 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 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: References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.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 To: Bob Friesenhahn , Dan McDonald 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 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> <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 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> <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 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> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> Message-ID: 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 To: Arne , Dan McDonald Date: Tue Mar 21 2017 22:33:57 GMT+0100 > >> On Mar 21, 2017, at 5:24 PM, Dan McDonald 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 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 1189849649582 xxx.xx.xxx.59 W 10500 137788 1189849740621 xxx.xx.xxx.118 W 0 2404 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: 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 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 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 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 > 1189849649582 xxx.xx.xxx.59 W 10500 137788 > 1189849740621 xxx.xx.xxx.118 W 0 2404 > 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: 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: References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> Message-ID: <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com> > On Mar 21, 2017, at 5:51 PM, Arne 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> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> <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 To: Arne 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 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 20811423525741 xxx.xx.xxx.50 W 0 5232 20811423528311 xxx.xx.xxx.50 W 0 304 20811423529251 xxx.xx.xxx.50 W 0 376 20811423555753 xxx.xx.xxx.18 R 0 685 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 > > 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 >> 1189849649582 xxx.xx.xxx.59 W 10500 137788 >> 1189849740621 xxx.xx.xxx.118 W 0 2404 >> 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: 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> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> <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 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> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com> <47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net> <6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com> Message-ID: 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 To: Arne , Dan McDonald 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: References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com> <47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net> <6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com> Message-ID: <7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com> > On Mar 22, 2017, at 12:15 PM, Arne 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 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 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 > 20811423525741 xxx.xx.xxx.50 W 0 5232 > 20811423528311 xxx.xx.xxx.50 W 0 304 > 20811423529251 xxx.xx.xxx.50 W 0 376 > 20811423555753 xxx.xx.xxx.18 R 0 685 > 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 > 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 >>> 1189849649582 xxx.xx.xxx.59 W 10500 137788 >>> 1189849740621 xxx.xx.xxx.118 W 0 2404 >>> 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: 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> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com> <47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net> <6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com> <7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com> Message-ID: 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 To: Arne , Dan McDonald 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: References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com> <47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net> <6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com> <7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com> Message-ID: > On Mar 23, 2017, at 11:20 AM, Arne 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: References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com> <47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net> <6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com> <7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com> Message-ID: >> 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: References: <1490124307.3204220.918865472.66F0463D@webmail.messagingengine.com> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com> <47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net> <6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com> <7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com> Message-ID: <1AC1812B-8210-4853-AD1F-C3785372FC6A@omniti.com> > On Mar 23, 2017, at 11:53 AM, Brian Hechinger 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> <4878f975-8bcd-7f4f-e754-ae0a73cf0ceb@kopierkatze.net> <8CCBF6D3-4CD8-4AED-A267-8ED38C4B9C78@omniti.com> <4D10F6F9-A43B-4074-8B20-EC27824DC5DB@omniti.com> <3E4A1833-F94A-4F1C-980D-8417B762F09A@omniti.com> <47af18c0-1602-1901-26fa-9735dbc4bb57@kopierkatze.net> <6B62ADDA-1A2E-4008-A9F1-347C4D66E57F@omniti.com> <7FD5CCA2-0DED-4795-8BD3-1DA71B41F8A6@omniti.com> <1AC1812B-8210-4853-AD1F-C3785372FC6A@omniti.com> Message-ID: > On Mar 23, 2017, at 12:01, Dan McDonald wrote: > > >> On Mar 23, 2017, at 11:53 AM, Brian Hechinger 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: References: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de> <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.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 and c2t0d0 , 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: 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: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de> <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.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 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 and c2t0d0 , 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: 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: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de> <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.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" An: "Stephan Budach" , "Dan McDonald" CC: "Prakash Surya" , "omnios-discuss" 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:
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 and c2t0d0 , 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: 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: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de> <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.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 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: <939405972.170.1488958080670.JavaMail.stephan.budach@stephan.budach.jvm.de> <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.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" > An: "Stephan Budach" , "Dan McDonald" > CC: "Prakash Surya" , "omnios-discuss" > 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 > > 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: 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: 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: <4C74B734-902E-4513-9D4E-1CFA2E5F767D@omniti.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: 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: 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 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: 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 [id:image001.png at 01D2837C.19B23B20] 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! [id:image002.gif at 01D2837C.19B23B20] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3509 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1352 bytes Desc: image002.gif URL: 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: 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: 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: References: Message-ID: 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 > > * * > > *id:image001.png at 01D2837C.19B23B20*** > > 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! > > > > id:image002.gif at 01D2837C.19B23B20 > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1352 bytes Desc: not available URL: 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: 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 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: 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: References: , 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 > 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 >: 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 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! _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From 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: References: <35FD8F4E-855C-413B-A6E9-87B20FB5336D@kebe.com> <3E205457-8E93-4D37-9260-693873B11D96@omniti.com> <29EC7AD8-27A9-4913-A8B7-46D14530AF95@omniti.com> Message-ID: <7986B19D-810B-4D64-965E-F81D6E54A96E@omniti.com> > On Mar 29, 2017, at 3:48 AM, Ludovic Orban 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> <7986B19D-810B-4D64-965E-F81D6E54A96E@omniti.com> Message-ID: Understood, your plate already is more than full. Thanks anyway! On Wed, Mar 29, 2017 at 5:11 PM, Dan McDonald wrote: > > > On Mar 29, 2017, at 3:48 AM, Ludovic Orban 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: 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: 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 from 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 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: References: Message-ID: 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 from > > > 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 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: References: Message-ID: 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 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 from > > 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 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: 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: References: Message-ID: <464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com> > On Mar 29, 2017, at 1:13 PM, 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 from > > 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 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: <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 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 from >> >> 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 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: <464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com> <1a90f314-a446-cc2b-1a3c-b002c32a2223@gnaa.net> Message-ID: > On Mar 29, 2017, at 1:39 PM, Geoff Nordli 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: References: Message-ID: 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: References: Message-ID: 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: References: <464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com> <1a90f314-a446-cc2b-1a3c-b002c32a2223@gnaa.net> 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: <464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com> <1a90f314-a446-cc2b-1a3c-b002c32a2223@gnaa.net> <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 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: 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: 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: References: Message-ID: Hi! -----"OmniOS-discuss" skrev: ----- Till: OmniOS-discuss 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: References: Message-ID: 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" skrev: ----- > Till: OmniOS-discuss > 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: References: Message-ID: 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 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" skrev: >> ----- >> Till: OmniOS-discuss >> 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: 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: References: Message-ID: 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: References: Message-ID: 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: References: Message-ID: > On Mar 30, 2017, at 3:19 AM, Guenther Alka 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: References: Message-ID: > On Mar 30, 2017, at 1:51 PM, Bob Friesenhahn 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: References: Message-ID: 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 wrote: > > >> On Mar 30, 2017, at 3:19 AM, Guenther Alka 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: References: 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: References: Message-ID: 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: References: Message-ID: > On Mar 30, 2017, at 4:26 PM, Bob Friesenhahn 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: References: Message-ID: On Thu, 30 Mar 2017, Dan McDonald wrote: > >> On Mar 30, 2017, at 4:26 PM, Bob Friesenhahn 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: References: Message-ID: <83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com> > On Mar 30, 2017, at 5:02 PM, Bob Friesenhahn wrote: > > On Thu, 30 Mar 2017, Dan McDonald wrote: > >> >>> On Mar 30, 2017, at 4:26 PM, Bob Friesenhahn 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: <83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com> Message-ID: 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" 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: 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: References: 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: <20170330211620.GV20300@bender.unx.cpp.edu> Message-ID: 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: References: <83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com> Message-ID: <9F84445C-29AF-4536-80D6-1453198C4097@omniti.com> > On Mar 30, 2017, at 5:11 PM, Brian Hechinger 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: References: <20170330211620.GV20300@bender.unx.cpp.edu> Message-ID: On 30 March 2017 at 14:46, Bob Friesenhahn 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: <83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com> <9F84445C-29AF-4536-80D6-1453198C4097@omniti.com> Message-ID: On Fri, Mar 31, 2017 at 3:38 AM, Dan McDonald wrote: > > > On Mar 30, 2017, at 5:11 PM, Brian Hechinger 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: 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: <83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com> <9F84445C-29AF-4536-80D6-1453198C4097@omniti.com> Message-ID: On Thu, 30 Mar 2017, Dan McDonald wrote: ; ; > On Mar 30, 2017, at 5:11 PM, Brian Hechinger 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: References: 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: References: <20170330211620.GV20300@bender.unx.cpp.edu> Message-ID: On Thu, 30 Mar 2017, Joshua M. Clulow wrote: > On 30 March 2017 at 14:46, Bob Friesenhahn 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: References: <20170330211620.GV20300@bender.unx.cpp.edu> Message-ID: <20170331160208.0fa886da@sleipner.datanom.net> On Fri, 31 Mar 2017 08:32:51 -0500 (CDT) Bob Friesenhahn 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: "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: 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: References: <83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com> <9F84445C-29AF-4536-80D6-1453198C4097@omniti.com> Message-ID: > On Mar 31, 2017, at 6:54 AM, Andy Fiddaman 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: References: <83387935-0F5D-43E3-A883-E9B2AA913A4A@omniti.com> <9F84445C-29AF-4536-80D6-1453198C4097@omniti.com> Message-ID: <22750.35268.507153.877411@urukhai.local> Dan McDonald writes: > > On Mar 31, 2017, at 6:54 AM, Andy Fiddaman 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"