From danmcd at omniti.com Wed Feb 1 00:34:15 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 31 Jan 2017 19:34:15 -0500 Subject: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!! References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com> Message-ID: <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> Hello! PLEASE READ THIS CAREFULLY BEFORE UPDATING!!! (And pardon any shouting, there are important things to read here.) Progress on our work for this bloody is going smoother than expected, thanks to the good work others have been doing upstream in illumos-gate. The Python2.7 switch has gone well (I'm seeing no complaints from bloody users). The new bits we're about to push on to http://pkg.omniti.com/omnios/bloody/ will enable another upstream innovation: BSD Loader. Unlike previous updates, I want this mail on the list before I push packages out to the repo server. The BSD Loader provides a replacement for GRUB. Its biggest upfront improvements over GRUB 0.97 are that it's an active Open Source project (GRUB went to 2.0), and that it eliminates the number-of-boot-environment limits that GRUB had. Furthermore, BSD Loader provides a more stable foundation for future improvements such as EFI boot (vs. BIOS boot) and the possibility of booting off of raidZ pools. The official arrival of BSD Loader constitutes an operational flag day for bloody users. This is a substantial enough change to merit its own new wiki page to accompany r151022's release. Current users of bloody may notice the presence of this file: /etc/default/be. This file has been in place to PREVENT the use of loader. As of this upcoming update, that file disappears, but it can be reconstituted. Before updating, you, the administrator, must make a decision: Stick with GRUB, or move to loader. The /etc/default/be file, specifically the "BE_HAS_GRUB=true" line, tells beadm(1M) what boot loader you wish to use going forward. I WANT TO MOVE TO LOADER - This is the default after updating, but Loader does not get installed until you "beadm activate" a loader-friendly BE (including the current one). Reboots after an update without the invocation of "beadm activate" or "installboot" will mean your machine stays with grub. You should notice an extra message about /rpool/boot/menu.lst being created. - If you have bloody BE from 2017, it is loader-friendly, so long as you remove /etc/default/be from that BE's root filesystem. - If you have a pre-2017 bloody BE, or an older OmniOS release BE, you can not "beadm activate" it, beadm(1M) will fail. - An old BE CAN be booted from the new Loader menu, but beadm will not work properly in that pre-Loader boot environment once booted. I WANT TO STICK WITH GRUB - Put "BE_HAS_GRUB=true" into /etc/default/be. This will instruct beadm(1M) and libbe that you wish to continue with GRUB. - Technically this has been happening since the first bloody release of 2017. The difference now is that "pkg update" removes this file from a system-installed image. - Old BEs will work fine, and you can "beadm activate" between all of them. I WANT TO MOVE FROM GRUB TO LOADER NOW (after sticking with GRUB) - Remove /etc/default/be on an active 2017 bloody BE. - "beadm activate " -- you should see a message about /rpool/boot/menu.lst being created. - You are now on loader. - If the "beadm activate" fails, or you still are booting with GRUB afterwards, explicitly install loader by: rm /etc/default/be (or at least remove the BE_HAS_GRUB line if you have multiple lines for some reason) installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/ rm /rpool/boot/menu.lst beadm activate (should reconstruct /rpool/boot/menu.lst) If you have mirrored roots, do the above installboot for each . I WANT TO MOVE FROM LOADER BACK TO GRUB (after being on Loader) - You will need to be in an active 2017 bloody BE. - Invoke the following: rm /rpool/boot/menu.lst echo "BE_HAS_GRUB=true" > /etc/default/be installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/ If you have mirrored roots, use "installgrub -M /dev/rdsk/ /dev/rdsk/ This update does NOT include an update to the ISO or USB install media yet (that's a problem we're still solving). It WILL, however, include an update to kayak software a day or two after, and the Kayak .zfs.bz2 media. With this update, Kayak will now install both Loader AND use whole-disk GPT partitioning for rpools. We'd appreciate additional feedback on the Kayak changes. The repo will be updated within 24 hours of the sending of this mail. The Kayak bits, 24 hours after that. Thanks for your patience as we move forward during this bloody cycle. Dan From danmcd at omniti.com Wed Feb 1 00:56:33 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 31 Jan 2017 19:56:33 -0500 Subject: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!! In-Reply-To: <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com> <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> Message-ID: <55818E1B-5EED-4C45-B60C-E11C3708B3FF@omniti.com> > On Jan 31, 2017, at 7:34 PM, Dan McDonald wrote: > > The repo will be updated within 24 hours of the sending of this mail. The Kayak bits, 24 hours after that. The bloody-USB3 repo will also get an update with these bits. Watch for an automated response once the pkgrecv(1M) commands are done. Thanks! Dan From danmcd at omniti.com Wed Feb 1 05:14:43 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 1 Feb 2017 00:14:43 -0500 Subject: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!! In-Reply-To: <55818E1B-5EED-4C45-B60C-E11C3708B3FF@omniti.com> References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com> <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> <55818E1B-5EED-4C45-B60C-E11C3708B3FF@omniti.com> Message-ID: <93C0A308-8184-4272-BFCA-D68434508B0B@omniti.com> > On Jan 31, 2017, at 7:56 PM, Dan McDonald wrote: > > The bloody-USB3 repo will also get an update with these bits. Watch for an automated response once the pkgrecv(1M) commands are done. My automated notification failed. Both repos are now updated, however. Happy updating! Dan From hasslerd at gmx.li Wed Feb 1 11:56:19 2017 From: hasslerd at gmx.li (Dominik Hassler) Date: Wed, 1 Feb 2017 12:56:19 +0100 Subject: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!! In-Reply-To: <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com> <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> Message-ID: <7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li> Dan, updated according to your instructions and switched to loader afterwards. Everything went smooth. Thanks! Dominik On 02/01/2017 01:34 AM, Dan McDonald wrote: > Hello! > > PLEASE READ THIS CAREFULLY BEFORE UPDATING!!! (And pardon any shouting, there are important things to read here.) > > Progress on our work for this bloody is going smoother than expected, thanks to the good work others have been doing upstream in illumos-gate. The Python2.7 switch has gone well (I'm seeing no complaints from bloody users). The new bits we're about to push on to http://pkg.omniti.com/omnios/bloody/ will enable another upstream innovation: BSD Loader. Unlike previous updates, I want this mail on the list before I push packages out to the repo server. > > The BSD Loader provides a replacement for GRUB. Its biggest upfront improvements over GRUB 0.97 are that it's an active Open Source project (GRUB went to 2.0), and that it eliminates the number-of-boot-environment limits that GRUB had. Furthermore, BSD Loader provides a more stable foundation for future improvements such as EFI boot (vs. BIOS boot) and the possibility of booting off of raidZ pools. > > The official arrival of BSD Loader constitutes an operational flag day for bloody users. This is a substantial enough change to merit its own new wiki page to accompany r151022's release. Current users of bloody may notice the presence of this file: /etc/default/be. This file has been in place to PREVENT the use of loader. As of this upcoming update, that file disappears, but it can be reconstituted. > > Before updating, you, the administrator, must make a decision: Stick with GRUB, or move to loader. The /etc/default/be file, specifically the "BE_HAS_GRUB=true" line, tells beadm(1M) what boot loader you wish to use going forward. > > I WANT TO MOVE TO LOADER > > - This is the default after updating, but Loader does not get installed until you "beadm activate" a loader-friendly BE (including the current one). Reboots after an update without the invocation of "beadm activate" or "installboot" will mean your machine stays with grub. You should notice an extra message about /rpool/boot/menu.lst being created. > > - If you have bloody BE from 2017, it is loader-friendly, so long as you remove /etc/default/be from that BE's root filesystem. > > - If you have a pre-2017 bloody BE, or an older OmniOS release BE, you can not "beadm activate" it, beadm(1M) will fail. > > - An old BE CAN be booted from the new Loader menu, but beadm will not work properly in that pre-Loader boot environment once booted. > > > I WANT TO STICK WITH GRUB > > - Put "BE_HAS_GRUB=true" into /etc/default/be. This will instruct beadm(1M) and libbe that you wish to continue with GRUB. > > - Technically this has been happening since the first bloody release of 2017. The difference now is that "pkg update" removes this file from a system-installed image. > > - Old BEs will work fine, and you can "beadm activate" between all of them. > > > I WANT TO MOVE FROM GRUB TO LOADER NOW (after sticking with GRUB) > > - Remove /etc/default/be on an active 2017 bloody BE. > > - "beadm activate " -- you should see a message about /rpool/boot/menu.lst being created. > > - You are now on loader. > > - If the "beadm activate" fails, or you still are booting with GRUB afterwards, explicitly install loader by: > > rm /etc/default/be (or at least remove the BE_HAS_GRUB line if you have multiple lines for some reason) > installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/ > rm /rpool/boot/menu.lst > beadm activate (should reconstruct /rpool/boot/menu.lst) > > If you have mirrored roots, do the above installboot for each . > > > I WANT TO MOVE FROM LOADER BACK TO GRUB (after being on Loader) > > - You will need to be in an active 2017 bloody BE. > > - Invoke the following: > > rm /rpool/boot/menu.lst > echo "BE_HAS_GRUB=true" > /etc/default/be > installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/ > > If you have mirrored roots, use "installgrub -M /dev/rdsk/ /dev/rdsk/ > > > This update does NOT include an update to the ISO or USB install media yet (that's a problem we're still solving). It WILL, however, include an update to kayak software a day or two after, and the Kayak .zfs.bz2 media. With this update, Kayak will now install both Loader AND use whole-disk GPT partitioning for rpools. We'd appreciate additional feedback on the Kayak changes. > > The repo will be updated within 24 hours of the sending of this mail. The Kayak bits, 24 hours after that. > > Thanks for your patience as we move forward during this bloody cycle. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From miniflowtrader at gmail.com Wed Feb 1 12:02:35 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 01 Feb 2017 12:02:35 +0000 Subject: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!! In-Reply-To: <7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li> References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com> <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> <7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li> Message-ID: Thanks Dan. Have the LX zone patches been added in? On Wed, Feb 1, 2017 at 6:58 AM Dominik Hassler wrote: > Dan, > > updated according to your instructions and switched to loader > afterwards. Everything went smooth. > > Thanks! > Dominik > > On 02/01/2017 01:34 AM, Dan McDonald wrote: > > Hello! > > > > PLEASE READ THIS CAREFULLY BEFORE UPDATING!!! (And pardon any shouting, > there are important things to read here.) > > > > Progress on our work for this bloody is going smoother than expected, > thanks to the good work others have been doing upstream in illumos-gate. > The Python2.7 switch has gone well (I'm seeing no complaints from bloody > users). The new bits we're about to push on to > http://pkg.omniti.com/omnios/bloody/ will enable another upstream > innovation: BSD Loader. Unlike previous updates, I want this mail on the > list before I push packages out to the repo server. > > > > The BSD Loader provides a replacement for GRUB. Its biggest upfront > improvements over GRUB 0.97 are that it's an active Open Source project > (GRUB went to 2.0), and that it eliminates the number-of-boot-environment > limits that GRUB had. Furthermore, BSD Loader provides a more stable > foundation for future improvements such as EFI boot (vs. BIOS boot) and the > possibility of booting off of raidZ pools. > > > > The official arrival of BSD Loader constitutes an operational flag day > for bloody users. This is a substantial enough change to merit its own new > wiki page to accompany r151022's release. Current users of bloody may > notice the presence of this file: /etc/default/be. This file has been in > place to PREVENT the use of loader. As of this upcoming update, that file > disappears, but it can be reconstituted. > > > > Before updating, you, the administrator, must make a decision: Stick > with GRUB, or move to loader. The /etc/default/be file, specifically the > "BE_HAS_GRUB=true" line, tells beadm(1M) what boot loader you wish to use > going forward. > > > > I WANT TO MOVE TO LOADER > > > > - This is the default after updating, but Loader does not get installed > until you "beadm activate" a loader-friendly BE (including the current > one). Reboots after an update without the invocation of "beadm activate" or > "installboot" will mean your machine stays with grub. You should notice an > extra message about /rpool/boot/menu.lst being created. > > > > - If you have bloody BE from 2017, it is loader-friendly, so long as you > remove /etc/default/be from that BE's root filesystem. > > > > - If you have a pre-2017 bloody BE, or an older OmniOS release BE, you > can not "beadm activate" it, beadm(1M) will fail. > > > > - An old BE CAN be booted from the new Loader menu, but beadm will not > work properly in that pre-Loader boot environment once booted. > > > > > > I WANT TO STICK WITH GRUB > > > > - Put "BE_HAS_GRUB=true" into /etc/default/be. This will instruct > beadm(1M) and libbe that you wish to continue with GRUB. > > > > - Technically this has been happening since the first bloody release of > 2017. The difference now is that "pkg update" removes this file from a > system-installed image. > > > > - Old BEs will work fine, and you can "beadm activate" between all of > them. > > > > > > I WANT TO MOVE FROM GRUB TO LOADER NOW (after sticking with GRUB) > > > > - Remove /etc/default/be on an active 2017 bloody BE. > > > > - "beadm activate " -- you should see a message about > /rpool/boot/menu.lst being created. > > > > - You are now on loader. > > > > - If the "beadm activate" fails, or you still are booting with GRUB > afterwards, explicitly install loader by: > > > > rm /etc/default/be (or at least remove the BE_HAS_GRUB line if you > have multiple lines for some reason) > > installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/ > > rm /rpool/boot/menu.lst > > beadm activate (should reconstruct /rpool/boot/menu.lst) > > > > If you have mirrored roots, do the above installboot for each > . > > > > > > I WANT TO MOVE FROM LOADER BACK TO GRUB (after being on Loader) > > > > - You will need to be in an active 2017 bloody BE. > > > > - Invoke the following: > > > > rm /rpool/boot/menu.lst > > echo "BE_HAS_GRUB=true" > /etc/default/be > > installgrub -m /boot/grub/stage1 /boot/grub/stage2 > /dev/rdsk/ > > > > If you have mirrored roots, use "installgrub -M > /dev/rdsk/ /dev/rdsk/ > > > > > > This update does NOT include an update to the ISO or USB install media > yet (that's a problem we're still solving). It WILL, however, include an > update to kayak software a day or two after, and the Kayak .zfs.bz2 media. > With this update, Kayak will now install both Loader AND use whole-disk GPT > partitioning for rpools. We'd appreciate additional feedback on the Kayak > changes. > > > > The repo will be updated within 24 hours of the sending of this mail. > The Kayak bits, 24 hours after that. > > > > Thanks for your patience as we move forward during this bloody cycle. > > > > 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 danmcd at omniti.com Wed Feb 1 16:04:11 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 1 Feb 2017 11:04:11 -0500 Subject: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!! In-Reply-To: References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com> <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> <7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li> Message-ID: We do try to keep up with LX from Joyent. The README.OmniOS file tracks this: https://github.com/omniti-labs/illumos-omnios/blob/master/README.OmniOS By recording the last illumos-Joyent commit we inspected. Dan Sent from my iPhone (typos, autocorrect, and all) > On Feb 1, 2017, at 7:02 AM, Mini Trader wrote: > > Thanks Dan. Have the LX zone patches been added in? > >> On Wed, Feb 1, 2017 at 6:58 AM Dominik Hassler wrote: >> Dan, >> >> updated according to your instructions and switched to loader >> afterwards. Everything went smooth. >> >> Thanks! >> Dominik >> >> On 02/01/2017 01:34 AM, Dan McDonald wrote: >> > Hello! >> > >> > PLEASE READ THIS CAREFULLY BEFORE UPDATING!!! (And pardon any shouting, there are important things to read here.) >> > >> > Progress on our work for this bloody is going smoother than expected, thanks to the good work others have been doing upstream in illumos-gate. The Python2.7 switch has gone well (I'm seeing no complaints from bloody users). The new bits we're about to push on to http://pkg.omniti.com/omnios/bloody/ will enable another upstream innovation: BSD Loader. Unlike previous updates, I want this mail on the list before I push packages out to the repo server. >> > >> > The BSD Loader provides a replacement for GRUB. Its biggest upfront improvements over GRUB 0.97 are that it's an active Open Source project (GRUB went to 2.0), and that it eliminates the number-of-boot-environment limits that GRUB had. Furthermore, BSD Loader provides a more stable foundation for future improvements such as EFI boot (vs. BIOS boot) and the possibility of booting off of raidZ pools. >> > >> > The official arrival of BSD Loader constitutes an operational flag day for bloody users. This is a substantial enough change to merit its own new wiki page to accompany r151022's release. Current users of bloody may notice the presence of this file: /etc/default/be. This file has been in place to PREVENT the use of loader. As of this upcoming update, that file disappears, but it can be reconstituted. >> > >> > Before updating, you, the administrator, must make a decision: Stick with GRUB, or move to loader. The /etc/default/be file, specifically the "BE_HAS_GRUB=true" line, tells beadm(1M) what boot loader you wish to use going forward. >> > >> > I WANT TO MOVE TO LOADER >> > >> > - This is the default after updating, but Loader does not get installed until you "beadm activate" a loader-friendly BE (including the current one). Reboots after an update without the invocation of "beadm activate" or "installboot" will mean your machine stays with grub. You should notice an extra message about /rpool/boot/menu.lst being created. >> > >> > - If you have bloody BE from 2017, it is loader-friendly, so long as you remove /etc/default/be from that BE's root filesystem. >> > >> > - If you have a pre-2017 bloody BE, or an older OmniOS release BE, you can not "beadm activate" it, beadm(1M) will fail. >> > >> > - An old BE CAN be booted from the new Loader menu, but beadm will not work properly in that pre-Loader boot environment once booted. >> > >> > >> > I WANT TO STICK WITH GRUB >> > >> > - Put "BE_HAS_GRUB=true" into /etc/default/be. This will instruct beadm(1M) and libbe that you wish to continue with GRUB. >> > >> > - Technically this has been happening since the first bloody release of 2017. The difference now is that "pkg update" removes this file from a system-installed image. >> > >> > - Old BEs will work fine, and you can "beadm activate" between all of them. >> > >> > >> > I WANT TO MOVE FROM GRUB TO LOADER NOW (after sticking with GRUB) >> > >> > - Remove /etc/default/be on an active 2017 bloody BE. >> > >> > - "beadm activate " -- you should see a message about /rpool/boot/menu.lst being created. >> > >> > - You are now on loader. >> > >> > - If the "beadm activate" fails, or you still are booting with GRUB afterwards, explicitly install loader by: >> > >> > rm /etc/default/be (or at least remove the BE_HAS_GRUB line if you have multiple lines for some reason) >> > installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/ >> > rm /rpool/boot/menu.lst >> > beadm activate (should reconstruct /rpool/boot/menu.lst) >> > >> > If you have mirrored roots, do the above installboot for each . >> > >> > >> > I WANT TO MOVE FROM LOADER BACK TO GRUB (after being on Loader) >> > >> > - You will need to be in an active 2017 bloody BE. >> > >> > - Invoke the following: >> > >> > rm /rpool/boot/menu.lst >> > echo "BE_HAS_GRUB=true" > /etc/default/be >> > installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/ >> > >> > If you have mirrored roots, use "installgrub -M /dev/rdsk/ /dev/rdsk/ >> > >> > >> > This update does NOT include an update to the ISO or USB install media yet (that's a problem we're still solving). It WILL, however, include an update to kayak software a day or two after, and the Kayak .zfs.bz2 media. With this update, Kayak will now install both Loader AND use whole-disk GPT partitioning for rpools. We'd appreciate additional feedback on the Kayak changes. >> > >> > The repo will be updated within 24 hours of the sending of this mail. The Kayak bits, 24 hours after that. >> > >> > Thanks for your patience as we move forward during this bloody cycle. >> > >> > 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 miniflowtrader at gmail.com Wed Feb 1 20:05:03 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 01 Feb 2017 20:05:03 +0000 Subject: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!! In-Reply-To: References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com> <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> <7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li> Message-ID: Has the bug we found been fixed? On Wed, Feb 1, 2017 at 11:04 AM Dan McDonald wrote: > We do try to keep up with LX from Joyent. The README.OmniOS file tracks > this: > > https://github.com/omniti-labs/illumos-omnios/blob/master/README.OmniOS > > By recording the last illumos-Joyent commit we inspected. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Feb 1, 2017, at 7:02 AM, Mini Trader wrote: > > Thanks Dan. Have the LX zone patches been added in? > > On Wed, Feb 1, 2017 at 6:58 AM Dominik Hassler wrote: > > Dan, > > updated according to your instructions and switched to loader > afterwards. Everything went smooth. > > Thanks! > Dominik > > On 02/01/2017 01:34 AM, Dan McDonald wrote: > > Hello! > > > > PLEASE READ THIS CAREFULLY BEFORE UPDATING!!! (And pardon any shouting, > there are important things to read here.) > > > > Progress on our work for this bloody is going smoother than expected, > thanks to the good work others have been doing upstream in illumos-gate. > The Python2.7 switch has gone well (I'm seeing no complaints from bloody > users). The new bits we're about to push on to > http://pkg.omniti.com/omnios/bloody/ will enable another upstream > innovation: BSD Loader. Unlike previous updates, I want this mail on the > list before I push packages out to the repo server. > > > > The BSD Loader provides a replacement for GRUB. Its biggest upfront > improvements over GRUB 0.97 are that it's an active Open Source project > (GRUB went to 2.0), and that it eliminates the number-of-boot-environment > limits that GRUB had. Furthermore, BSD Loader provides a more stable > foundation for future improvements such as EFI boot (vs. BIOS boot) and the > possibility of booting off of raidZ pools. > > > > The official arrival of BSD Loader constitutes an operational flag day > for bloody users. This is a substantial enough change to merit its own new > wiki page to accompany r151022's release. Current users of bloody may > notice the presence of this file: /etc/default/be. This file has been in > place to PREVENT the use of loader. As of this upcoming update, that file > disappears, but it can be reconstituted. > > > > Before updating, you, the administrator, must make a decision: Stick > with GRUB, or move to loader. The /etc/default/be file, specifically the > "BE_HAS_GRUB=true" line, tells beadm(1M) what boot loader you wish to use > going forward. > > > > I WANT TO MOVE TO LOADER > > > > - This is the default after updating, but Loader does not get installed > until you "beadm activate" a loader-friendly BE (including the current > one). Reboots after an update without the invocation of "beadm activate" or > "installboot" will mean your machine stays with grub. You should notice an > extra message about /rpool/boot/menu.lst being created. > > > > - If you have bloody BE from 2017, it is loader-friendly, so long as you > remove /etc/default/be from that BE's root filesystem. > > > > - If you have a pre-2017 bloody BE, or an older OmniOS release BE, you > can not "beadm activate" it, beadm(1M) will fail. > > > > - An old BE CAN be booted from the new Loader menu, but beadm will not > work properly in that pre-Loader boot environment once booted. > > > > > > I WANT TO STICK WITH GRUB > > > > - Put "BE_HAS_GRUB=true" into /etc/default/be. This will instruct > beadm(1M) and libbe that you wish to continue with GRUB. > > > > - Technically this has been happening since the first bloody release of > 2017. The difference now is that "pkg update" removes this file from a > system-installed image. > > > > - Old BEs will work fine, and you can "beadm activate" between all of > them. > > > > > > I WANT TO MOVE FROM GRUB TO LOADER NOW (after sticking with GRUB) > > > > - Remove /etc/default/be on an active 2017 bloody BE. > > > > - "beadm activate " -- you should see a message about > /rpool/boot/menu.lst being created. > > > > - You are now on loader. > > > > - If the "beadm activate" fails, or you still are booting with GRUB > afterwards, explicitly install loader by: > > > > rm /etc/default/be (or at least remove the BE_HAS_GRUB line if you > have multiple lines for some reason) > > installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/ > > rm /rpool/boot/menu.lst > > beadm activate (should reconstruct /rpool/boot/menu.lst) > > > > If you have mirrored roots, do the above installboot for each > . > > > > > > I WANT TO MOVE FROM LOADER BACK TO GRUB (after being on Loader) > > > > - You will need to be in an active 2017 bloody BE. > > > > - Invoke the following: > > > > rm /rpool/boot/menu.lst > > echo "BE_HAS_GRUB=true" > /etc/default/be > > installgrub -m /boot/grub/stage1 /boot/grub/stage2 > /dev/rdsk/ > > > > If you have mirrored roots, use "installgrub -M > /dev/rdsk/ /dev/rdsk/ > > > > > > This update does NOT include an update to the ISO or USB install media > yet (that's a problem we're still solving). It WILL, however, include an > update to kayak software a day or two after, and the Kayak .zfs.bz2 media. > With this update, Kayak will now install both Loader AND use whole-disk GPT > partitioning for rpools. We'd appreciate additional feedback on the Kayak > changes. > > > > The repo will be updated within 24 hours of the sending of this mail. > The Kayak bits, 24 hours after that. > > > > Thanks for your patience as we move forward during this bloody cycle. > > > > 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 danmcd at omniti.com Wed Feb 1 20:18:15 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 1 Feb 2017 15:18:15 -0500 Subject: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!! In-Reply-To: References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com> <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> <7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li> Message-ID: <1B335D76-F6F8-4E0A-8C05-CCB36E818B8F@omniti.com> > On Feb 1, 2017, at 3:05 PM, Mini Trader wrote: > > Has the bug we found been fixed? Ahh, OS-5167 and friends. No I haven't pulled those in. I was told that there are other issues with those fixes, and I don't want to cause more problems than I solve. Sorry, Dan From chip at innovates.com Thu Feb 2 02:59:24 2017 From: chip at innovates.com (Schweiss, Chip) Date: Wed, 1 Feb 2017 20:59:24 -0600 Subject: [OmniOS-discuss] Fwd: NFS server unresponsive In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Schweiss, Chip Date: Wed, Feb 1, 2017 at 8:58 PM Subject: NFS server unresponsive To: zfs I have a storage pool with 100+ NFS clients. It is part of an HA cluster. No matter which host I put the pool on NFS comes to a halt for all pools. Everything else is fine. Just no NFS. Most of the clients are NFSv4. I've rebooted the system and the problem repeats itself in just a few seconds of being responsive after the pool come online. I suspected NFS resources, and tried doubling most everything: # sharectl get nfs servers=1024 lockd_listen_backlog=512 lockd_servers=4096 lockd_retransmit_timeout=5 grace_period=90 server_versmin=3 server_versmax=4 client_versmin=3 client_versmax=4 server_delegation=on nfsmapid_domain= max_connections=-1 protocol=ALL listen_backlog=64 device= mountd_listen_backlog=64 mountd_max_threads=16 Didn't change anything. Nothing in logs. Pool is fine for everything but NFS. nfssvrtop show no I/O about 99% of the time, but periodically shows a couple small I/O. Possibly a client knocking over, but I cannot isolate the issue tighter than the entire pool. What else should I be looking at? Any help greatly appreciated. -Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: From paladinemishakal at gmail.com Thu Feb 2 04:37:19 2017 From: paladinemishakal at gmail.com (Lawrence Giam) Date: Thu, 2 Feb 2017 12:37:19 +0800 Subject: [OmniOS-discuss] Migration of OpenSolaris fileserver from one AD forest to another AD forest Message-ID: Hi All, I have a server running OpenIndiana as a file server that is joined to a AD forest and sharing out the zfs folders as smb shares. I followed the steps to join OpenSolaris into a windows AD environment and this is the step: 1. Setup the OI server to have IP address in AD forest 2. Configure DNS setup 3. Check SMB server libraries are installed 4. Configure /etc/krb5/krb5.conf to use the server in the AD forest 5. Join the OI server to the AD forest 6. Setup mapping of users and groups between systems - idmap add 'winuser:administrator at abc.internal' 'unixuser:root' 7. Enable mapping of unresolvable SIDs - svccfg -s idmap setprop config/unresolvable_sid_mapping = boolean: true Note: I have alot of SMB shares on this OI server. Now I have to move the OI server to another AD forest so I would like to know what is the proper steps to do this. Should I be doing the following: 1. Disjoin the OI server from AD forest A 2. Update the IP address, resolv.con, krb5.conf 3. Sync the time to the new AD forest B 4. Join the OI server to AD forest B 5. Setup mapping of users and groups between systems - idmap add 'winuser:administrator at xyz.internal' 'unixuser:root' Question: 1. Should I remove the mapping of users and groups after disjoin from AD forest A? - idmap remove 'winuser:administrator at abc.internal' 'unixuser:root' Thanks & Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daleg at omniti.com Thu Feb 2 06:34:23 2017 From: daleg at omniti.com (Dale Ghent) Date: Thu, 2 Feb 2017 01:34:23 -0500 Subject: [OmniOS-discuss] [ANN] OpenSSH 7.4p1 available Message-ID: <539FD444-3BC9-472D-A937-CDCF0C17C787@omniti.com> Scope: OmniOS releases r151014, r151018, r151020, bloody OpenSSH 7.4p1 is now available in the package repositories for the above releases of OmniOS. Immediate updating to this version is strongly suggested as it addresses the following CVEs: CVE-2016-10012 CVE-2016-10011 CVE-2016-10010 CVE-2016-10009 CVE-2016-8858 CVE-2016-6515 To update, simply utter: # pkg update -v openssh openssh-server The package update process will automatically restart the service FMRI svc:/network/ssh:default If you are still a user of SunSSH, it is always highly suggested that a migration to OpenSSH be done at earliest opportunity. SunSSH is considered EOL, is unmaintained, and only offers crypto which is considered unsafe. Directions to effect this migration for r151014 (current LTS) users may be found at the top of r151014 release notes: https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 /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 mir at miras.org Thu Feb 2 06:44:14 2017 From: mir at miras.org (Michael Rasmussen) Date: Thu, 2 Feb 2017 07:44:14 +0100 Subject: [OmniOS-discuss] Fwd: NFS server unresponsive In-Reply-To: References: Message-ID: <20170202074414.243832c6@sleipner.datanom.net> On Wed, 1 Feb 2017 20:59:24 -0600 "Schweiss, Chip" wrote: > > Possibly a client knocking over, but I cannot isolate the issue tighter > than the entire pool. > > What else should I be looking at? > Is your NFS connection through an infiniband nic? I am asking this because here putting heavy load on NFS over Infiniband will immediately kill the NFS server. -- 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: Things past redress and now with me past care. -- William Shakespeare, "Richard II" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Leonard_DeGuzman at comcast.com Fri Feb 3 22:04:24 2017 From: Leonard_DeGuzman at comcast.com (De Guzman, Leonard) Date: Fri, 3 Feb 2017 22:04:24 +0000 Subject: [OmniOS-discuss] Security Questions regarding OmniOS Message-ID: <6d0ac8f35a97474687f9a3165ccafb86@VAADCEX08.cable.comcast.com> Good Afternoon, I am writing with regard to some security questions I have related to OmniOS. I am currently in the process of applying to have OmniOS approved for use internally at Comcast. As part of the on-boarding process, I am seeking guidance from OmniOS regarding some security-related queries I have. What is the best method of forum for me to raise these questions with you? Any guidance or advice would be much appreciated. Regards, Leonard de Guzman SRE VADER | VIDEO Technology & Product L: Reston, VA (Eastern Time) T: (703) 638-4363 E: leonard_deguzman at comcast.com W: https://icollaborate.webex.com/join/leonard_deguzman -------------- next part -------------- An HTML attachment was scrubbed... URL: From vab at bb-c.de Fri Feb 3 22:32:19 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Fri, 3 Feb 2017 23:32:19 +0100 Subject: [OmniOS-discuss] Security Questions regarding OmniOS In-Reply-To: <6d0ac8f35a97474687f9a3165ccafb86@VAADCEX08.cable.comcast.com> References: <6d0ac8f35a97474687f9a3165ccafb86@VAADCEX08.cable.comcast.com> Message-ID: <22677.1267.487390.633874@urukhai.local> Hello Leonard! > I am seeking guidance from OmniOS regarding some security-related queries I have. > > What is the best method of forum for me to raise these questions with you? Unless those queries are confidential, this mailing list is a very good place to ask your questions. If you later decide to buy support from OmniTI and have private discussions, that is fine, too. Just MHO. 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 Feb 3 22:37:04 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 3 Feb 2017 17:37:04 -0500 Subject: [OmniOS-discuss] Security Questions regarding OmniOS In-Reply-To: <22677.1267.487390.633874@urukhai.local> References: <6d0ac8f35a97474687f9a3165ccafb86@VAADCEX08.cable.comcast.com> <22677.1267.487390.633874@urukhai.local> Message-ID: <652C5B85-F988-423E-8529-CB88B52A49B5@omniti.com> > On Feb 3, 2017, at 5:32 PM, Volker A. Brandt wrote: > > Unless those queries are confidential, this mailing list is a very > good place to ask your questions. If you later decide to buy support > from OmniTI and have private discussions, that is fine, too. I replied to him unicast covering the paid-support&private case already. In that note, I mentioned that public discussions can benefit the community AND him, per your point! Thanks! Dan From bfriesen at simple.dallas.tx.us Fri Feb 3 23:31:31 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Fri, 3 Feb 2017 17:31:31 -0600 (CST) Subject: [OmniOS-discuss] Security Questions regarding OmniOS In-Reply-To: <6d0ac8f35a97474687f9a3165ccafb86@VAADCEX08.cable.comcast.com> References: <6d0ac8f35a97474687f9a3165ccafb86@VAADCEX08.cable.comcast.com> Message-ID: On Fri, 3 Feb 2017, De Guzman, Leonard wrote: > > Any guidance or advice would be much appreciated. Compared with most other operating systems, OmniOS is quite spartan and provides a rather limited set of network applications which are externally accessible. The default set of network applications which are enabled is very small and well considered. There are sometimes user-space accessible issues which need to be fixed. OmniOS has done well at fixing issues that I became aware of from sources other than OmniOS. 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 Wed Feb 8 01:07:25 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 7 Feb 2017 20:07:25 -0500 Subject: [OmniOS-discuss] r151020 & bloody users --> new bash 4.4p12 available Message-ID: <7B6BFC82-BC21-489D-9A49-B9632B061684@omniti.com> Updated in response to this: https://github.com/jheyens/bash_completion_vuln/raw/master/2017-01-17.bash_completion_report.pdf "pkg update" is your friend. Note for bloody users, if you're running lipkg zones, use "-r" for update for now. We'll go into discussions later about why you need to do that for now. Thanks to both the oss-security list, and to Bob Friesenhahn, for making me aware of this. (And Bob, sorry for saying, "24 hours," when I should've said, "24 minutes." It was much easier than I thought.) Dan From danmcd at omniti.com Wed Feb 8 21:40:30 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 8 Feb 2017 16:40:30 -0500 Subject: [OmniOS-discuss] How many of you are building illumos? Message-ID: A push to illumos-gate today requires an updated gcc44 for DEBUG builds, one I haven't updated yet in older releases. With which releases are people building illumos-gate? Will you need an updated gcc44? I've bcced illumos developer, but please let me know either on OmniOS-discuss or via unicast. I'm expecting yes for r151020, but I'm not sure about r151014 (LTS). Thanks, Dan Sent from my iPhone (typos, autocorrect, and all) From danmcd at omniti.com Wed Feb 8 22:28:56 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 8 Feb 2017 17:28:56 -0500 Subject: [OmniOS-discuss] [developer] How many of you are building illumos? In-Reply-To: References: Message-ID: <9E5DB2A3-8CAD-41B7-9A29-23B944FD9790@omniti.com> It will most likely build older ones. I just need to confirm it, and confirm it works on older OmniOS releases. Dan Sent from my iPhone (typos, autocorrect, and all) > On Feb 8, 2017, at 5:25 PM, Sebastien Roy wrote: > > Hi Dan, > > Our master development branch is relatively in-sync with illumos > (within days or weeks). As such, we'll need an updated gcc shortly. I > take it that the updated version of gcc is capable of building > illumos-gate from before the change in question? > > Thanks, > -Seb > >> On Wed, Feb 8, 2017 at 4:40 PM, Dan McDonald wrote: >> A push to illumos-gate today requires an updated gcc44 for DEBUG builds, one I haven't updated yet in older releases. >> >> With which releases are people building illumos-gate? Will you need an updated gcc44? >> >> I've bcced illumos developer, but please let me know either on OmniOS-discuss or via unicast. >> >> I'm expecting yes for r151020, but I'm not sure about r151014 (LTS). >> >> Thanks, >> Dan >> >> Sent from my iPhone (typos, autocorrect, and all) >> > > > ------------------------------------------- > illumos-developer > Archives: https://www.listbox.com/member/archive/182179/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175029-813097db > Modify Your Subscription: https://www.listbox.com/member/?member_id=21175029&id_secret=21175029-471fe0d4 > Powered by Listbox: http://www.listbox.com From danmcd at omniti.com Thu Feb 9 16:09:31 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 9 Feb 2017 11:09:31 -0500 Subject: [OmniOS-discuss] SECURITY UPDATE - bind to 9.10.4-P6 Message-ID: <37F8CBA9-66E1-4004-8643-2FDF40DD9E06@omniti.com> All supported repos and bloody have new updated ISC BIND packages. Note that the "omnios" repo only contains the client side for OmniOS operation. If you get BIND server from somewhere, make sure that is being updated too. Also note that ms.omniti.com/omniti-ms, while not officially a supported repo, will be getting its BIND updated soon as well. Dan From danmcd at omniti.com Thu Feb 9 16:15:59 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 9 Feb 2017 11:15:59 -0500 Subject: [OmniOS-discuss] How many of you are building illumos? In-Reply-To: References: Message-ID: <4DC47804-3336-4EFC-BAC4-63AAF89FE96B@omniti.com> > On Feb 8, 2017, at 4:40 PM, Dan McDonald wrote: > > I'm expecting yes for r151020, but I'm not sure about r151014 (LTS). After seeing all the responses, it sounds like I should update both r151020 and r151014 with the new gcc44-il. I'll spin that sometime today or later this week. Dan From dirk.willems at exitas.be Thu Feb 9 16:28:52 2017 From: dirk.willems at exitas.be (Dirk Willems) Date: Thu, 9 Feb 2017 17:28:52 +0100 Subject: [OmniOS-discuss] mountpoint on the parent pool Message-ID: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be> Hello OmniOS, Why isn't allowed to install a LX-Zone or Zone if the DATA pool doesn't have a mountpoint on the parent ? below example doesn't allow you to install a Zone or LX-Zone root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 432G 777G 23K none DATA/Backup 432G 777G 432G /Backup DATA/LXZones 23K 777G 23K /LXZones below example does allow you to install a Zone or LX-Zone root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 433G 776G 23K /LXZones DATA/Backup 432G 776G 432G /Backup DATA/LXMatterMost 229M 776G 228M /LXZones/LXMatterMost It's kind ignoring because i like to make separated filesystems for having a nice overview :) Thanks. Dirk -- **Dirk Willems* * System Engineer *+32 (0)3 443 12 38* *dirk.willems at exitas.be* *Veldkant 31 - 2550 Kontich* *www.exitas.be* *Disclaimer* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: exitas_PMS.png Type: image/png Size: 8486 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm.png Type: image/png Size: 524 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Mail.png Type: image/png Size: 791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: plaats.png Type: image/png Size: 803 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: huis.png Type: image/png Size: 796 bytes Desc: not available URL: From grzempek at gmail.com Thu Feb 9 16:35:18 2017 From: grzempek at gmail.com (Krzysztof Grzempa) Date: Thu, 9 Feb 2017 17:35:18 +0100 Subject: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!! In-Reply-To: <08F8EEAB-294F-4B71-AF02-AB0D5AF63C5A@omniti.com> References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com> <44FDE281-F712-4366-ABC9-939DC8616872@omniti.com> <7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li> <1B335D76-F6F8-4E0A-8C05-CCB36E818B8F@omniti.com> <08F8EEAB-294F-4B71-AF02-AB0D5AF63C5A@omniti.com> Message-ID: OK. Thanks for quick reply. Cheers, Krzysztof 2017-02-09 17:14 GMT+01:00 Dan McDonald : > > > On Feb 9, 2017, at 5:09 AM, Krzysztof Grzempa > wrote: > > > > Hi! > > Question: Is BSD Loader will be available in r151022 LTS and included > into default system installer, allowing to configure RAIDZ as system pool ? > > Loader is necessary, but not sufficient, for a bootable raidz rpool. > Illumos itself needs changes as well. Such changes are unlikely to be > showing up quickly enough for r151022. > > Sorry, > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Feb 9 16:41:02 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 9 Feb 2017 11:41:02 -0500 Subject: [OmniOS-discuss] mountpoint on the parent pool In-Reply-To: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be> References: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be> Message-ID: > On Feb 9, 2017, at 11:28 AM, Dirk Willems wrote: > > Hello OmniOS, > > Why isn't allowed to install a LX-Zone or Zone if the DATA pool doesn't have a mountpoint on the parent ? > > > below example doesn't allow you to install a Zone or LX-Zone > > root at OmniOS:/root# zfs list > NAME USED AVAIL REFER MOUNTPOINT > DATA 432G 777G 23K none > DATA/Backup 432G 777G 432G /Backup > DATA/LXZones 23K 777G 23K /LXZones > > > below example does allow you to install a Zone or LX-Zone > > root at OmniOS:/root# zfs list > NAME USED AVAIL REFER MOUNTPOINT > DATA 433G 776G 23K /LXZones > DATA/Backup 432G 776G 432G /Backup > DATA/LXMatterMost 229M 776G 228M /LXZones/LXMatterMost > > > It's kind ignoring because i like to make separated filesystems for having a nice overview :) All zones (not just LX) need to be a subdirectory of a higher-level ZFS filesystem. This is so zoneadm(1M) can create the zone root. bloody(~)[0]% zfs list | grep zones | grep -v zbe data/zones 3.90G 509G 23K /zones data/zones/lipkg0 3.14G 509G 24K /zones/lipkg0 data/zones/lipkg0/ROOT 3.14G 509G 23K legacy data/zones/lx0 465M 509G 465M /zones/lx0 data/zones/lx1 315M 509G 239M /zones/lx1 bloody(~)[0]% My bloody box has zones name per their brand, so you can see what I mean. Dan From danmcd at omniti.com Thu Feb 9 17:06:34 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 9 Feb 2017 12:06:34 -0500 Subject: [OmniOS-discuss] gcc44 (illumos compilers) updated on OmniOS LTS and Stable Message-ID: <67A163E9-66D2-463B-A97A-B223D7BCDC58@omniti.com> OmniOS release r151014 (LTS) and r151020 (Stable) now have their "gcc44" packages updated to "il-4", which includes some cmn_err() argument improvements that allow the very latest (as of yesterday) illumos-gate to compile DEBUG packages. If your nightly builds start failing on DEBUG, make sure: * You're on r151014, r151020, or bloody. * You have the latest gcc44 package installed. Here they are, according to release: r151014(~)[0]% pkg list -v gcc44 FMRI IFO pkg://omnios/developer/gcc44 at 4.4.4-0.151014:20170209T164006Z i-- r151014(~)[0]% r151020(~)[0]% pkg list -v gcc44 FMRI IFO pkg://omnios/developer/gcc44 at 4.4.4-0.151020:20170209T164037Z i-- r151020(~)[0]% bloody(~)[0]% pkg list -v gcc44 FMRI IFO pkg://omnios/developer/gcc44 at 4.4.4-0.151021:20170209T013730Z i-- bloody(~)[0]% Just make sure you update things, and you'll be continuing to build illumos smoothly on OmniOS. Happy building! Dan From dirk.willems at exitas.be Thu Feb 9 17:09:04 2017 From: dirk.willems at exitas.be (Dirk Willems) Date: Thu, 9 Feb 2017 18:09:04 +0100 Subject: [OmniOS-discuss] mountpoint on the parent pool In-Reply-To: References: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be> Message-ID: <440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be> Thanks Dan, I just was wondering about it, because in Solaris it's allowed we do it all the time and it's become a automatic behavior for us, but if we know it we can arrange it like you do. Thanks On 09-02-17 17:41, Dan McDonald wrote: >> On Feb 9, 2017, at 11:28 AM, Dirk Willems wrote: >> >> Hello OmniOS, >> >> Why isn't allowed to install a LX-Zone or Zone if the DATA pool doesn't have a mountpoint on the parent ? >> >> >> below example doesn't allow you to install a Zone or LX-Zone >> >> root at OmniOS:/root# zfs list >> NAME USED AVAIL REFER MOUNTPOINT >> DATA 432G 777G 23K none >> DATA/Backup 432G 777G 432G /Backup >> DATA/LXZones 23K 777G 23K /LXZones >> >> >> below example does allow you to install a Zone or LX-Zone >> >> root at OmniOS:/root# zfs list >> NAME USED AVAIL REFER MOUNTPOINT >> DATA 433G 776G 23K /LXZones >> DATA/Backup 432G 776G 432G /Backup >> DATA/LXMatterMost 229M 776G 228M /LXZones/LXMatterMost >> >> >> It's kind ignoring because i like to make separated filesystems for having a nice overview :) > All zones (not just LX) need to be a subdirectory of a higher-level ZFS filesystem. This is so zoneadm(1M) can create the zone root. > > bloody(~)[0]% zfs list | grep zones | grep -v zbe > data/zones 3.90G 509G 23K /zones > data/zones/lipkg0 3.14G 509G 24K /zones/lipkg0 > data/zones/lipkg0/ROOT 3.14G 509G 23K legacy > data/zones/lx0 465M 509G 465M /zones/lx0 > data/zones/lx1 315M 509G 239M /zones/lx1 > bloody(~)[0]% > > My bloody box has zones name per their brand, so you can see what I mean. > > Dan > -- **Dirk Willems* * System Engineer *+32 (0)3 443 12 38* *dirk.willems at exitas.be* *Veldkant 31 - 2550 Kontich* *www.exitas.be* *Disclaimer* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: exitas_PMS.png Type: image/png Size: 8486 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm.png Type: image/png Size: 524 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Mail.png Type: image/png Size: 791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: plaats.png Type: image/png Size: 803 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: huis.png Type: image/png Size: 796 bytes Desc: not available URL: From bfriesen at simple.dallas.tx.us Fri Feb 10 02:13:48 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Thu, 9 Feb 2017 20:13:48 -0600 (CST) Subject: [OmniOS-discuss] ACPI warning from r151020 on SuperMicro Xeon D system Message-ID: I noticed that OmniOS r151020 is producing an ACPI warning on a SuperMicro Xeon D system. I don't think that it was doing this for r151018 (or else I didn't notice): Feb 5 17:43:01 scrappy unix: [ID 977644 kern.info] NOTICE: cpu_acpi: _TSS package bad count 1 for CPU 0. Feb 5 17:43:01 scrappy unix: [ID 340435 kern.info] NOTICE: Support for CPU throttling is being disabled due to errors parsing ACPI T-state objects exported by BIOS. Is there some data I can produce in order to help make this issue go away? 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 Feb 10 02:58:43 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Thu, 9 Feb 2017 20:58:43 -0600 (CST) Subject: [OmniOS-discuss] OpenSSH logging control Message-ID: Can someone provide a recipe which gets OpenSSH messages under control and puts them in their own log file (e.g. '/var/log/adm'), while also removing the noise from the console? OpenSSH is even noisier than SunSSH. For a machine with ssh access from the Internet, the console becomes unusable and even the logging to a file might eventually wear out an SSD. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From josh at sysmgr.org Fri Feb 10 07:11:33 2017 From: josh at sysmgr.org (Joshua M. Clulow) Date: Thu, 9 Feb 2017 23:11:33 -0800 Subject: [OmniOS-discuss] OpenSSH logging control In-Reply-To: References: Message-ID: On 9 February 2017 at 18:58, Bob Friesenhahn wrote: > OpenSSH is even noisier than SunSSH. For a machine with ssh access from the > Internet, the console becomes unusable and even the logging to a file might > eventually wear out an SSD. For what it's worth, moving the SSH port up to a high number made my logs almost silent. Most of the cheap (and thus plentiful) scans are on port 22 only. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From andre at ak47.co.za Fri Feb 10 07:44:34 2017 From: andre at ak47.co.za (Andre Kruger) Date: Fri, 10 Feb 2017 09:44:34 +0200 Subject: [OmniOS-discuss] Moving The Root Pool Message-ID: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Feb 10 14:05:57 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 10 Feb 2017 09:05:57 -0500 Subject: [OmniOS-discuss] Moving The Root Pool In-Reply-To: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> Message-ID: <07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com> > On Feb 10, 2017, at 2:44 AM, Andre Kruger wrote: > > I have a running OmniOS system that boots from HDD but I would like to boot the machine from SSD. I first pondered if I could just create an image, using CloneZilla, of the rpool disk and then restore that image again onto the SSD. I hadn't heard of clonezilla until just now. > I am not sure if that is an acceptable method? The problem with that is your disk device will be under a different name, and this confuses the illumos boot system a bit. > I know the windows community warns against this practice. You can clone from HDD to HDD or SSD to SSD, but I have read many reports of windows users experiencing slow performance when cloning from HDD to SSD. I have no idea why that would be the case, but regardless... > Would OmniOS suffer the same performance problems if cloning from HDD to SSD? ... I can't say for sure. > If it will, would this procedure that I found on the OpenIndiana Wiki be valid without much tweaking? > > https://wiki.openindiana.org/oi/How+to+migrate+the+root+pool That article is a bit old. I've some questions that will help me give better advice. There are no wrong answers here, just be as accurate as you can: - Which revision of OmniOS are you running? - Is your new SSD the same or greater size than the HD you have now? - Do you have a CD/DVD or USB installer media? Thanks, Dan From bfriesen at simple.dallas.tx.us Fri Feb 10 14:39:13 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Fri, 10 Feb 2017 08:39:13 -0600 (CST) Subject: [OmniOS-discuss] OpenSSH logging control In-Reply-To: References: Message-ID: On Thu, 9 Feb 2017, Joshua M. Clulow wrote: > On 9 February 2017 at 18:58, Bob Friesenhahn > wrote: >> OpenSSH is even noisier than SunSSH. For a machine with ssh access from the >> Internet, the console becomes unusable and even the logging to a file might >> eventually wear out an SSD. > > For what it's worth, moving the SSH port up to a high number made my > logs almost silent. Most of the cheap (and thus plentiful) scans are > on port 22 only. That would be confusing for my remote users, who would likely forget about a special port. These seem to be the only tweaks available for ssh logging configuration: # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO Setting LogLevel to QUIET seems like it would remove all logging. Setting to ERROR or FATAL would seem to lessen the logging but the fast majority of the annoying logs are at ERROR level. I will try setting to FATAL level. The structure of OpenSSH logging is not useful. I would like a way to specify IP address ranges for which I am interested in a high degree of logging (e.g. for my own network address ranges) while not treating remote annoyances as "errors". 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 Fri Feb 10 19:15:59 2017 From: daleg at omniti.com (Dale Ghent) Date: Fri, 10 Feb 2017 14:15:59 -0500 Subject: [OmniOS-discuss] ACPI warning from r151020 on SuperMicro Xeon D system In-Reply-To: References: Message-ID: > On Feb 9, 2017, at 9:13 PM, Bob Friesenhahn wrote: > > I noticed that OmniOS r151020 is producing an ACPI warning on a SuperMicro Xeon D system. I don't think that it was doing this for r151018 (or else I didn't notice): > > Feb 5 17:43:01 scrappy unix: [ID 977644 kern.info] NOTICE: cpu_acpi: _TSS package bad count 1 for CPU 0. > Feb 5 17:43:01 scrappy unix: [ID 340435 kern.info] NOTICE: Support for CPU throttling is being disabled due to errors parsing ACPI T-state objects exported by BIOS. > > Is there some data I can produce in order to help make this issue go away? It?s not an issue per se. I have the exact Xeon-D system you have, I believe, and have looked into this. The short answer is: This isn?t a error or problem, so much as it is a combination of the (much newer in r151020) Intel APCI-CA code being its characteristically gripey self, and the typical odd stuff that BIOS vendors put into their BIOSes. The longer answer: This is because you have T-States turned off in the BIOS config, which I believe is the default state as shipped from Supermico (it was on my D-1541 box from them.) If you look in the BIOS menu Advanced -> CPU Configuration -> Advanced Power Management Configuration -> CPU T-State Control you will find that it?s set to Disabled. This is with version 1.1c of the BIOS. Enabling that will prevent the ACPI-CA code from griping about it as T-States will be fully enabled, and not in some there-but-not-there state that the BIOS seems to leave the TSS (?T-State Status?) table in when it is disabled. /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 jimklimov at cos.ru Fri Feb 10 21:19:53 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Fri, 10 Feb 2017 22:19:53 +0100 Subject: [OmniOS-discuss] mountpoint on the parent pool In-Reply-To: <440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be> References: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be> <440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be> Message-ID: 9 ??????? 2017??. 18:09:04 CET, Dirk Willems ?????: >Thanks Dan, > > >I just was wondering about it, because in Solaris it's allowed we do it > >all the time and it's become a automatic behavior for us, but if we >know >it we can arrange it like you do. > > >Thanks > > >On 09-02-17 17:41, Dan McDonald wrote: >>> On Feb 9, 2017, at 11:28 AM, Dirk Willems >wrote: >>> >>> Hello OmniOS, >>> >>> Why isn't allowed to install a LX-Zone or Zone if the DATA pool >doesn't have a mountpoint on the parent ? >>> >>> >>> below example doesn't allow you to install a Zone or LX-Zone >>> >>> root at OmniOS:/root# zfs list >>> NAME USED AVAIL REFER MOUNTPOINT >>> DATA 432G 777G 23K none >>> DATA/Backup 432G 777G 432G /Backup >>> DATA/LXZones 23K 777G 23K /LXZones >>> >>> >>> below example does allow you to install a Zone or LX-Zone >>> >>> root at OmniOS:/root# zfs list >>> NAME USED AVAIL REFER MOUNTPOINT >>> DATA 433G 776G 23K /LXZones >>> DATA/Backup 432G 776G 432G /Backup >>> DATA/LXMatterMost 229M 776G 228M >/LXZones/LXMatterMost >>> >>> >>> It's kind ignoring because i like to make separated filesystems for >having a nice overview :) >> All zones (not just LX) need to be a subdirectory of a higher-level >ZFS filesystem. This is so zoneadm(1M) can create the zone root. >> >> bloody(~)[0]% zfs list | grep zones | grep -v zbe >> data/zones 3.90G 509G 23K /zones >> data/zones/lipkg0 3.14G 509G 24K >/zones/lipkg0 >> data/zones/lipkg0/ROOT 3.14G 509G 23K legacy >> data/zones/lx0 465M 509G 465M >/zones/lx0 >> data/zones/lx1 315M 509G 239M >/zones/lx1 >> bloody(~)[0]% >> >> My bloody box has zones name per their brand, so you can see what I >mean. >> >> Dan >> Just in case, do you not mistake zone roots here with delegated datasets (e.g. for data or local progs, but with zfs structure managed from inside the zone)? This is indeed usable even from different pools in solaris 10 up to openindiana at least. -- Typos courtesy of K-9 Mail on my Samsung Android From dirk.willems at exitas.be Sun Feb 12 15:08:11 2017 From: dirk.willems at exitas.be (Dirk Willems) Date: Sun, 12 Feb 2017 16:08:11 +0100 Subject: [OmniOS-discuss] mountpoint on the parent pool In-Reply-To: References: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be> <440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be> Message-ID: Hi Jim, Thank you for your feedback and your thoughs, I make some test for clarifying my experience ... *_On Solaris 11_* root at soledg14:~# zpool create -O mountpoint=none -O compression=lz4 Testpool c0t60060160F4D0320042F89EFA1FF1E611d0 root at soledg14:~# zpool list Testpool 49.8G 122K 49.7G 0% 1.00x ONLINE - rpool 278G 83.7G 194G 30% 1.00x ONLINE - root at soledg14:~# zfs list Testpool 143K 49.0G 31K none Testpool/TestZones 31K 49.0G 31K /TestZones root at soledg14:~# zoneadm list -civ - TestZone configured /TestZones/TestZone solaris excl root at soledg14:~# zoneadm -z TestZone install The following ZFS file system(s) have been created: Testpool/TestZones/TestZone Progress being logged to /var/log/zones/zoneadm.20170212T140109Z.TestZone.install Image: Preparing at /TestZones/TestZone/root. Install Log: /system/volatile/install.16565/install_log AI Manifest: /tmp/manifest.xml.vvcbTb SC Profile: /usr/share/auto_install/sc_profiles/enable_sci.xml Zonename: TestZone Installation: Starting ... Creating IPS image Startup linked: 1/1 done Installing packages from: solaris origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ cacao origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ mp-re origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ opscenter origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 285/285 55878/55878 479.8/479.8 5.9M/s PHASE ITEMS Installing new actions 73669/73669 Updating package state database Done Updating package cache 0/0 Updating image state Done Creating fast lookup database Done Updating package cache 4/4 Installation: Succeeded Note: Man pages can be obtained by installing pkg:/system/manual done. Done: Installation completed in 221.859 seconds. Next Steps: Boot the zone, then log into the zone console (zlogin -C) to complete the configuration process. Log saved in non-global zone as /TestZones/TestZone/root/var/log/zones/zoneadm.20170212T140109Z.TestZone.install root at soledg14:~# zfs list Testpool 932M 48.1G 31K none Testpool/TestZones 931M 48.1G 32K /TestZones Testpool/TestZones/TestZone 931M 48.1G 32K /TestZones/TestZone Testpool/TestZones/TestZone/rpool 931M 48.1G 31K /rpool Testpool/TestZones/TestZone/rpool/ROOT 931M 48.1G 31K legacy Testpool/TestZones/TestZone/rpool/ROOT/solaris 931M 48.1G 847M /TestZones/TestZone/root Testpool/TestZones/TestZone/rpool/ROOT/solaris/var 84.3M 48.1G 83.4M /TestZones/TestZone/root/var Testpool/TestZones/TestZone/rpool/VARSHARE 31K 48.1G 31K /var/share Testpool/TestZones/TestZone/rpool/export 62K 48.1G 31K /export Testpool/TestZones/TestZone/rpool/export/home 31K 48.1G 31K /export/home So on Solaris 11 it allow you to install a zone even if the parent mountpoint = none *_Did also some test on OmniOS_* root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 435G 774G 23K /LXZones DATA/Backup 432G 774G 432G /Backup DATA/LXMatterMost 408M 774G 347M /LXZones/LXMatterMost DATA/Zones2 2,13G 774G 23K /Zones2 DATA/Zones2/NGINX 959M 774G 24K /Zones2/NGINX DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy DATA/Zones2/Percona 1,19G 774G 24K /Zones2/Percona DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy root at OmniOS:/root# zfs set mountpoint=none DATA root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 435G 774G 23K none DATA/Backup 432G 774G 432G /Backup DATA/LXMatterMost 408M 774G 347M none DATA/Zones2 2,13G 774G 23K /Zones2 DATA/Zones2/NGINX 959M 774G 24K /Zones2/NGINX DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy DATA/Zones2/Percona 1,19G 774G 24K /Zones2/Percona DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy root at OmniOS:/root# zonecfg -z Test Test: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:Test> create zonecfg:Test> set zonepath=/Zones2/Test zonecfg:Test> info zonecfg:Test> exit root at OmniOS:/root# zonecfg -z Test info zonename: Test zonepath: /Zones2/Test brand: ipkg autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared hostid: fs-allowed: root at OmniOS:/root# I'm not making here the filesytem DATA/Zones2/Test !!!! root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 435G 774G 23K none DATA/Backup 432G 774G 432G /Backup DATA/LXMatterMost 408M 774G 347M none DATA/Zones2 2,13G 774G 23K /Zones2 DATA/Zones2/NGINX 959M 774G 24K /Zones2/NGINX DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy DATA/Zones2/Percona 1,19G 774G 24K /Zones2/Percona DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy root at OmniOS:/root# zoneadm list -civ ID NAME STATUS PATH BRAND IP 0 global running / ipkg shared - DNS installed /Zones/DNS lipkg excl - LXDebian8 installed /Zones/LXDebian8 lx excl - LXMatterMost installed /LXZones/LXMatterMost lx excl - Percona installed /Zones2/Percona lipkg excl - NGINX installed /Zones2/NGINX lipkg excl - Test configured /Zones2/Test ipkg shared root at OmniOS:/root# zoneadm -z Test install WARNING: zone LXMatterMost is installed, but its zonepath /LXZones/LXMatterMost does not exist. Sanity Check: Looking for 'entire' incorporation. ERROR: the zonepath must be a ZFS dataset. The parent directory of the zonepath must be a ZFS dataset so that the zonepath ZFS dataset can be created properly. root at OmniOS:/root# On this point I had to uninstall the LXMatterMost zone because I set the mountpoint=none on the DATA pool and the LXMatterMost zone depend on the mountpoint=/LXZones of the DATA pool. Then I also created a filesystem DATA/Zones2/Test root at OmniOS:/root# zfs create -o mountpoint=/Zones2/Test DATA/Zones2/Test root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 435G 774G 23K none DATA/Backup 432G 774G 432G /Backup DATA/Zones2 2,13G 774G 23K /Zones2 DATA/Zones2/NGINX 959M 774G 24K /Zones2/NGINX DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy DATA/Zones2/Percona 1,19G 774G 24K /Zones2/Percona DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy DATA/Zones2/Test 23K 774G 23K /Zones2/Test And now it is allowed to install the zone :) root at OmniOS:/root# zoneadm -z Test install /Zones2/Test must not be group readable. /Zones2/Test must not be group executable. /Zones2/Test must not be world readable. /Zones2/Test must not be world executable. /Zones2/Test: changing permissions to 0700. Sanity Check: Looking for 'entire' incorporation. Image: Preparing at /Zones2/Test/root. Publisher: Using omnios (http://pkg.omniti.com/omnios/r151020/). Cache: Using /var/pkg/publisher. Installing: Packages (output follows) Packages to install: 388 Mediators to change: 1 Services to change: 5 DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 388/388 37406/37406 332.0/332.0 0B/s PHASE ITEMS Installing new actions 61025/61025 Updating package state database Done Updating package cache 0/0 Updating image state Done Creating fast lookup database Done Note: Man pages can be obtained by installing pkg:/system/manual Postinstall: Copying SMF seed repository ... done. Done: Installation completed in 93,895 seconds. Next Steps: Boot the zone, then log into the zone console (zlogin -C) to complete the configuration process root at OmniOS:/root# zoneadm -z Test boot; zlogin -C Test [Connected to zone 'Test' console] Loading smf(5) service descriptions: 113/113 Hostname: Test Test console login: root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 435G 774G 23K none DATA/Backup 433G 774G 433G /Backup DATA/Zones2 2,66G 774G 24K /Zones2 DATA/Zones2/NGINX 959M 774G 24K /Zones2/NGINX DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy DATA/Zones2/Percona 1,19G 774G 24K /Zones2/Percona DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy DATA/Zones2/Test 540M 774G 23K /Zones2/Test DATA/Zones2/Test/ROOT 540M 774G 23K legacy DATA/Zones2/Test/ROOT/zbe 540M 774G 540M legacy So that's why I ask the question :) In my opinion we miss some logic in the zoneadm, we don't need to set a parent mountpoint like i proof with above example. Maybe someone can have a look on the code it would be great to fix this, if I had the knowledge how to fix it it should be great, but I'm unfortunately not so smart and intelligent as you guy's sorry :( I wish ;) Kind Regards, Dirk On 10-02-17 22:19, Jim Klimov wrote: > 9 ??????? 2017 ?. 18:09:04 CET, Dirk Willems ?????: >> Thanks Dan, >> >> >> I just was wondering about it, because in Solaris it's allowed we do it >> >> all the time and it's become a automatic behavior for us, but if we >> know >> it we can arrange it like you do. >> >> >> Thanks >> >> >> On 09-02-17 17:41, Dan McDonald wrote: >>>> On Feb 9, 2017, at 11:28 AM, Dirk Willems >> wrote: >>>> Hello OmniOS, >>>> >>>> Why isn't allowed to install a LX-Zone or Zone if the DATA pool >> doesn't have a mountpoint on the parent ? >>>> >>>> below example doesn't allow you to install a Zone or LX-Zone >>>> >>>> root at OmniOS:/root# zfs list >>>> NAME USED AVAIL REFER MOUNTPOINT >>>> DATA 432G 777G 23K none >>>> DATA/Backup 432G 777G 432G /Backup >>>> DATA/LXZones 23K 777G 23K /LXZones >>>> >>>> >>>> below example does allow you to install a Zone or LX-Zone >>>> >>>> root at OmniOS:/root# zfs list >>>> NAME USED AVAIL REFER MOUNTPOINT >>>> DATA 433G 776G 23K /LXZones >>>> DATA/Backup 432G 776G 432G /Backup >>>> DATA/LXMatterMost 229M 776G 228M >> /LXZones/LXMatterMost >>>> >>>> It's kind ignoring because i like to make separated filesystems for >> having a nice overview :) >>> All zones (not just LX) need to be a subdirectory of a higher-level >> ZFS filesystem. This is so zoneadm(1M) can create the zone root. >>> bloody(~)[0]% zfs list | grep zones | grep -v zbe >>> data/zones 3.90G 509G 23K /zones >>> data/zones/lipkg0 3.14G 509G 24K >> /zones/lipkg0 >>> data/zones/lipkg0/ROOT 3.14G 509G 23K legacy >>> data/zones/lx0 465M 509G 465M >> /zones/lx0 >>> data/zones/lx1 315M 509G 239M >> /zones/lx1 >>> bloody(~)[0]% >>> >>> My bloody box has zones name per their brand, so you can see what I >> mean. >>> Dan >>> > Just in case, do you not mistake zone roots here with delegated datasets (e.g. for data or local progs, but with zfs structure managed from inside the zone)? This is indeed usable even from different pools in solaris 10 up to openindiana at least. > -- > Typos courtesy of K-9 Mail on my Samsung Android -- **Dirk Willems* * System Engineer *+32 (0)3 443 12 38* *dirk.willems at exitas.be* *Veldkant 31 - 2550 Kontich* *www.exitas.be* *Disclaimer* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: exitas_PMS.png Type: image/png Size: 8486 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm.png Type: image/png Size: 524 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Mail.png Type: image/png Size: 791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: plaats.png Type: image/png Size: 803 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: huis.png Type: image/png Size: 796 bytes Desc: not available URL: From jimklimov at cos.ru Sun Feb 12 19:46:27 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Sun, 12 Feb 2017 20:46:27 +0100 Subject: [OmniOS-discuss] mountpoint on the parent pool In-Reply-To: References: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be> <440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be> Message-ID: <35F3CBA5-0E03-4E96-B419-7D50203BE4D9@cos.ru> 12 ??????? 2017??. 16:08:11 CET, Dirk Willems ?????: >Hi Jim, > > >Thank you for your feedback and your thoughs, I make some test for >clarifying my experience ... > > >*_On Solaris 11_* > >root at soledg14:~# zpool create -O mountpoint=none -O compression=lz4 >Testpool c0t60060160F4D0320042F89EFA1FF1E611d0 > >root at soledg14:~# zpool list >Testpool 49.8G 122K 49.7G 0% 1.00x ONLINE - >rpool 278G 83.7G 194G 30% 1.00x ONLINE - > >root at soledg14:~# zfs list >Testpool 143K 49.0G 31K none >Testpool/TestZones 31K 49.0G 31K >/TestZones > >root at soledg14:~# zoneadm list -civ > - TestZone configured /TestZones/TestZone solaris excl > >root at soledg14:~# zoneadm -z TestZone install >The following ZFS file system(s) have been created: > Testpool/TestZones/TestZone >Progress being logged to >/var/log/zones/zoneadm.20170212T140109Z.TestZone.install > Image: Preparing at /TestZones/TestZone/root. > > Install Log: /system/volatile/install.16565/install_log > AI Manifest: /tmp/manifest.xml.vvcbTb > SC Profile: /usr/share/auto_install/sc_profiles/enable_sci.xml > Zonename: TestZone >Installation: Starting ... > > Creating IPS image >Startup linked: 1/1 done > Installing packages from: > solaris > origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ > cacao > origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ > mp-re > origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ > opscenter > origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ >DOWNLOAD PKGS FILES XFER >(MB) SPEED >Completed 285/285 55878/55878 479.8/479.8 > >5.9M/s > >PHASE ITEMS >Installing new actions 73669/73669 >Updating package state database Done >Updating package cache 0/0 >Updating image state Done >Creating fast lookup database Done >Updating package cache 4/4 >Installation: Succeeded > > Note: Man pages can be obtained by installing pkg:/system/manual > > done. > > Done: Installation completed in 221.859 seconds. > > > Next Steps: Boot the zone, then log into the zone console (zlogin -C) > > to complete the configuration process. > >Log saved in non-global zone as >/TestZones/TestZone/root/var/log/zones/zoneadm.20170212T140109Z.TestZone.install > > >root at soledg14:~# zfs list >Testpool 932M 48.1G 31K none >Testpool/TestZones 931M 48.1G 32K > >/TestZones >Testpool/TestZones/TestZone 931M 48.1G 32K > >/TestZones/TestZone >Testpool/TestZones/TestZone/rpool 931M 48.1G 31K > >/rpool >Testpool/TestZones/TestZone/rpool/ROOT 931M 48.1G 31K > >legacy >Testpool/TestZones/TestZone/rpool/ROOT/solaris 931M 48.1G 847M >/TestZones/TestZone/root >Testpool/TestZones/TestZone/rpool/ROOT/solaris/var 84.3M 48.1G 83.4M > >/TestZones/TestZone/root/var >Testpool/TestZones/TestZone/rpool/VARSHARE 31K 48.1G 31K > >/var/share >Testpool/TestZones/TestZone/rpool/export 62K 48.1G 31K > >/export >Testpool/TestZones/TestZone/rpool/export/home 31K 48.1G 31K > >/export/home > > >So on Solaris 11 it allow you to install a zone even if the parent >mountpoint = none > > >*_Did also some test on OmniOS_* > >root at OmniOS:/root# zfs list >NAME USED AVAIL REFER >MOUNTPOINT >DATA 435G 774G 23K /LXZones >DATA/Backup 432G 774G 432G /Backup >DATA/LXMatterMost 408M 774G 347M >/LXZones/LXMatterMost >DATA/Zones2 2,13G 774G 23K /Zones2 >DATA/Zones2/NGINX 959M 774G 24K >/Zones2/NGINX >DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >DATA/Zones2/Percona 1,19G 774G 24K >/Zones2/Percona >DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy > > >root at OmniOS:/root# zfs set mountpoint=none DATA >root at OmniOS:/root# zfs list >NAME USED AVAIL REFER >MOUNTPOINT >DATA 435G 774G 23K none >DATA/Backup 432G 774G 432G /Backup >DATA/LXMatterMost 408M 774G 347M none >DATA/Zones2 2,13G 774G 23K /Zones2 >DATA/Zones2/NGINX 959M 774G 24K >/Zones2/NGINX >DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >DATA/Zones2/Percona 1,19G 774G 24K >/Zones2/Percona >DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy > >root at OmniOS:/root# zonecfg -z Test >Test: No such zone configured >Use 'create' to begin configuring a new zone. >zonecfg:Test> create >zonecfg:Test> set zonepath=/Zones2/Test >zonecfg:Test> info >zonecfg:Test> exit >root at OmniOS:/root# zonecfg -z Test info >zonename: Test >zonepath: /Zones2/Test >brand: ipkg >autoboot: false >bootargs: >pool: >limitpriv: >scheduling-class: >ip-type: shared >hostid: >fs-allowed: >root at OmniOS:/root# > >I'm not making here the filesytem DATA/Zones2/Test !!!! > > >root at OmniOS:/root# zfs list >NAME USED AVAIL REFER >MOUNTPOINT >DATA 435G 774G 23K none >DATA/Backup 432G 774G 432G /Backup >DATA/LXMatterMost 408M 774G 347M none >DATA/Zones2 2,13G 774G 23K /Zones2 >DATA/Zones2/NGINX 959M 774G 24K >/Zones2/NGINX >DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >DATA/Zones2/Percona 1,19G 774G 24K >/Zones2/Percona >DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy > >root at OmniOS:/root# zoneadm list -civ > ID NAME STATUS PATH BRAND IP > 0 global running / ipkg shared > - DNS installed /Zones/DNS lipkg excl > - LXDebian8 installed /Zones/LXDebian8 lx excl > - LXMatterMost installed /LXZones/LXMatterMost lx excl > - Percona installed /Zones2/Percona lipkg excl > - NGINX installed /Zones2/NGINX lipkg excl > - Test configured /Zones2/Test ipkg shared > >root at OmniOS:/root# zoneadm -z Test install >WARNING: zone LXMatterMost is installed, but its zonepath >/LXZones/LXMatterMost does not exist. >Sanity Check: Looking for 'entire' incorporation. >ERROR: the zonepath must be a ZFS dataset. >The parent directory of the zonepath must be a ZFS dataset so that the >zonepath ZFS dataset can be created properly. >root at OmniOS:/root# > >On this point I had to uninstall the LXMatterMost zone because I set >the >mountpoint=none on the DATA pool and the LXMatterMost zone depend on >the >mountpoint=/LXZones of the DATA pool. > >Then I also created a filesystem DATA/Zones2/Test > > >root at OmniOS:/root# zfs create -o mountpoint=/Zones2/Test >DATA/Zones2/Test >root at OmniOS:/root# zfs list >NAME USED AVAIL REFER >MOUNTPOINT >DATA 435G 774G 23K none >DATA/Backup 432G 774G 432G /Backup >DATA/Zones2 2,13G 774G 23K /Zones2 >DATA/Zones2/NGINX 959M 774G 24K >/Zones2/NGINX >DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >DATA/Zones2/Percona 1,19G 774G 24K >/Zones2/Percona >DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy >DATA/Zones2/Test 23K 774G 23K /Zones2/Test > > >And now it is allowed to install the zone :) > > >root at OmniOS:/root# zoneadm -z Test install >/Zones2/Test must not be group readable. >/Zones2/Test must not be group executable. >/Zones2/Test must not be world readable. >/Zones2/Test must not be world executable. >/Zones2/Test: changing permissions to 0700. >Sanity Check: Looking for 'entire' incorporation. > Image: Preparing at /Zones2/Test/root. > > Publisher: Using omnios (http://pkg.omniti.com/omnios/r151020/). > Cache: Using /var/pkg/publisher. > Installing: Packages (output follows) >Packages to install: 388 >Mediators to change: 1 > Services to change: 5 > >DOWNLOAD PKGS FILES XFER >(MB) SPEED >Completed 388/388 37406/37406 >332.0/332.0 0B/s > >PHASE ITEMS >Installing new actions 61025/61025 >Updating package state database Done >Updating package cache 0/0 >Updating image state Done >Creating fast lookup database Done > > Note: Man pages can be obtained by installing pkg:/system/manual > Postinstall: Copying SMF seed repository ... done. > Done: Installation completed in 93,895 seconds. > > Next Steps: Boot the zone, then log into the zone console (zlogin -C) > to complete the configuration process > >root at OmniOS:/root# zoneadm -z Test boot; zlogin -C Test >[Connected to zone 'Test' console] >Loading smf(5) service descriptions: 113/113 >Hostname: Test > >Test console login: > >root at OmniOS:/root# zfs list >NAME USED AVAIL REFER >MOUNTPOINT >DATA 435G 774G 23K none >DATA/Backup 433G 774G 433G /Backup >DATA/Zones2 2,66G 774G 24K /Zones2 >DATA/Zones2/NGINX 959M 774G 24K >/Zones2/NGINX >DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >DATA/Zones2/Percona 1,19G 774G 24K >/Zones2/Percona >DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >/export/home >DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >/export/home/witte >DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy >DATA/Zones2/Test 540M 774G 23K /Zones2/Test >DATA/Zones2/Test/ROOT 540M 774G 23K legacy >DATA/Zones2/Test/ROOT/zbe 540M 774G 540M legacy > >So that's why I ask the question :) > >In my opinion we miss some logic in the zoneadm, we don't need to set a > >parent mountpoint like i proof with above example. > >Maybe someone can have a look on the code it would be great to fix >this, >if I had the knowledge how to fix it it should be great, but I'm >unfortunately not so smart and intelligent as you guy's sorry :( > >I wish ;) > > >Kind Regards, > > >Dirk > > >On 10-02-17 22:19, Jim Klimov wrote: >> 9 ??????? 2017 ?. 18:09:04 CET, Dirk Willems >?????: >>> Thanks Dan, >>> >>> >>> I just was wondering about it, because in Solaris it's allowed we do >it >>> >>> all the time and it's become a automatic behavior for us, but if we >>> know >>> it we can arrange it like you do. >>> >>> >>> Thanks >>> >>> >>> On 09-02-17 17:41, Dan McDonald wrote: >>>>> On Feb 9, 2017, at 11:28 AM, Dirk Willems >>> wrote: >>>>> Hello OmniOS, >>>>> >>>>> Why isn't allowed to install a LX-Zone or Zone if the DATA pool >>> doesn't have a mountpoint on the parent ? >>>>> >>>>> below example doesn't allow you to install a Zone or LX-Zone >>>>> >>>>> root at OmniOS:/root# zfs list >>>>> NAME USED AVAIL REFER MOUNTPOINT >>>>> DATA 432G 777G 23K none >>>>> DATA/Backup 432G 777G 432G /Backup >>>>> DATA/LXZones 23K 777G 23K /LXZones >>>>> >>>>> >>>>> below example does allow you to install a Zone or LX-Zone >>>>> >>>>> root at OmniOS:/root# zfs list >>>>> NAME USED AVAIL REFER MOUNTPOINT >>>>> DATA 433G 776G 23K /LXZones >>>>> DATA/Backup 432G 776G 432G /Backup >>>>> DATA/LXMatterMost 229M 776G 228M >>> /LXZones/LXMatterMost >>>>> >>>>> It's kind ignoring because i like to make separated filesystems >for >>> having a nice overview :) >>>> All zones (not just LX) need to be a subdirectory of a higher-level >>> ZFS filesystem. This is so zoneadm(1M) can create the zone root. >>>> bloody(~)[0]% zfs list | grep zones | grep -v zbe >>>> data/zones 3.90G 509G 23K /zones >>>> data/zones/lipkg0 3.14G 509G 24K >>> /zones/lipkg0 >>>> data/zones/lipkg0/ROOT 3.14G 509G 23K legacy >>>> data/zones/lx0 465M 509G 465M >>> /zones/lx0 >>>> data/zones/lx1 315M 509G 239M >>> /zones/lx1 >>>> bloody(~)[0]% >>>> >>>> My bloody box has zones name per their brand, so you can see what I >>> mean. >>>> Dan >>>> >> Just in case, do you not mistake zone roots here with delegated >datasets (e.g. for data or local progs, but with zfs structure managed >from inside the zone)? This is indeed usable even from different pools >in solaris 10 up to openindiana at least. >> -- >> Typos courtesy of K-9 Mail on my Samsung Android Well, seems there is some mix of apples and oranges here - but you don't sen mountpoint of a pool (or rather its root dataset), while you do have a mountpoint of a sub-dataset dedicated to zones (zones2 and testzones) so the system can find it. Would be more interesting if these did not exist with such names and/or mountpoints before zoneadm call. Otherwise, if there is indeed an error or point of improvement, it is likely in brand scripts and should be easily fixable. Jim -- Typos courtesy of K-9 Mail on my Samsung Android From dirk.willems at exitas.be Sun Feb 12 21:53:08 2017 From: dirk.willems at exitas.be (Dirk Willems) Date: Sun, 12 Feb 2017 22:53:08 +0100 Subject: [OmniOS-discuss] mountpoint on the parent pool In-Reply-To: <35F3CBA5-0E03-4E96-B419-7D50203BE4D9@cos.ru> References: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be> <440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be> <35F3CBA5-0E03-4E96-B419-7D50203BE4D9@cos.ru> Message-ID: <1d24a1bb-468d-b753-aa9d-568c273957d7@exitas.be> Hi Jim, Thanks, if I install the zone without creating the filesystem DATA/Zones2/Test I'm not allowed to install the zone like next example root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 435G 774G 23K none DATA/Backup 432G 774G 432G /Backup DATA/Zones2 2,13G 774G 23K /Zones2 DATA/Zones2/NGINX 959M 774G 24K /Zones2/NGINX DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy DATA/Zones2/Percona 1,19G 774G 24K /Zones2/Percona DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy But when I create the filesystem DATA/Zones2/Test then I am allowed to install the zone. root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 435G 774G 23K none DATA/Backup 432G 774G 432G /Backup DATA/Zones2 2,13G 774G 23K /Zones2 DATA/Zones2/NGINX 959M 774G 24K /Zones2/NGINX DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy DATA/Zones2/Percona 1,19G 774G 24K /Zones2/Percona DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy DATA/Zones2/Test 23K 774G 23K /Zones2/Test After installing the Test zone I have this root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 435G 774G 23K none DATA/Backup 433G 774G 433G /Backup DATA/Zones2 2,66G 774G 24K /Zones2 DATA/Zones2/NGINX 959M 774G 24K /Zones2/NGINX DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy DATA/Zones2/Percona 1,19G 774G 24K /Zones2/Percona DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy DATA/Zones2/Test 540M 774G 23K /Zones2/Test DATA/Zones2/Test/ROOT 540M 774G 23K legacy DATA/Zones2/Test/ROOT/zbe 540M 774G 540M legacy And if I uninstall the zone it also clean up the filesystem DATA/Zones2/Test like it should be. root at OmniOS:/root# zoneadm -z Test uninstall Are you sure you want to uninstall zone Test (y/[n])? y root at OmniOS:/root# zfs list NAME USED AVAIL REFER MOUNTPOINT DATA 435G 774G 23K none DATA/Backup 433G 774G 433G /Backup DATA/Zones2 2,13G 774G 24K /Zones2 DATA/Zones2/NGINX 959M 774G 24K /Zones2/NGINX DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy DATA/Zones2/Percona 1,19G 774G 24K /Zones2/Percona DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K /export/home DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K /export/home/witte DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy So in my opinion zoneadm does not create the filesystem automatic, but clean afterwards well the filesystem like it should be. That's make me questioning about missing some logic in the zoneadm for creating automatisch the filesystem, after all cleaning up after uninstall the zone is working like designed .... Kind Regards, Dirk On 12-02-17 20:46, Jim Klimov wrote: > 12 ??????? 2017 ?. 16:08:11 CET, Dirk Willems ?????: >> Hi Jim, >> >> >> Thank you for your feedback and your thoughs, I make some test for >> clarifying my experience ... >> >> >> *_On Solaris 11_* >> >> root at soledg14:~# zpool create -O mountpoint=none -O compression=lz4 >> Testpool c0t60060160F4D0320042F89EFA1FF1E611d0 >> >> root at soledg14:~# zpool list >> Testpool 49.8G 122K 49.7G 0% 1.00x ONLINE - >> rpool 278G 83.7G 194G 30% 1.00x ONLINE - >> >> root at soledg14:~# zfs list >> Testpool 143K 49.0G 31K none >> Testpool/TestZones 31K 49.0G 31K >> /TestZones >> >> root at soledg14:~# zoneadm list -civ >> - TestZone configured /TestZones/TestZone solaris excl >> >> root at soledg14:~# zoneadm -z TestZone install >> The following ZFS file system(s) have been created: >> Testpool/TestZones/TestZone >> Progress being logged to >> /var/log/zones/zoneadm.20170212T140109Z.TestZone.install >> Image: Preparing at /TestZones/TestZone/root. >> >> Install Log: /system/volatile/install.16565/install_log >> AI Manifest: /tmp/manifest.xml.vvcbTb >> SC Profile: /usr/share/auto_install/sc_profiles/enable_sci.xml >> Zonename: TestZone >> Installation: Starting ... >> >> Creating IPS image >> Startup linked: 1/1 done >> Installing packages from: >> solaris >> origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ >> cacao >> origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ >> mp-re >> origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ >> opscenter >> origin: http://oracle-oem-oc-mgmt-ops-proxy-edg:8002/IPS/ >> DOWNLOAD PKGS FILES XFER >> (MB) SPEED >> Completed 285/285 55878/55878 479.8/479.8 >> >> 5.9M/s >> >> PHASE ITEMS >> Installing new actions 73669/73669 >> Updating package state database Done >> Updating package cache 0/0 >> Updating image state Done >> Creating fast lookup database Done >> Updating package cache 4/4 >> Installation: Succeeded >> >> Note: Man pages can be obtained by installing pkg:/system/manual >> >> done. >> >> Done: Installation completed in 221.859 seconds. >> >> >> Next Steps: Boot the zone, then log into the zone console (zlogin -C) >> >> to complete the configuration process. >> >> Log saved in non-global zone as >> /TestZones/TestZone/root/var/log/zones/zoneadm.20170212T140109Z.TestZone.install >> >> >> root at soledg14:~# zfs list >> Testpool 932M 48.1G 31K none >> Testpool/TestZones 931M 48.1G 32K >> >> /TestZones >> Testpool/TestZones/TestZone 931M 48.1G 32K >> >> /TestZones/TestZone >> Testpool/TestZones/TestZone/rpool 931M 48.1G 31K >> >> /rpool >> Testpool/TestZones/TestZone/rpool/ROOT 931M 48.1G 31K >> >> legacy >> Testpool/TestZones/TestZone/rpool/ROOT/solaris 931M 48.1G 847M >> /TestZones/TestZone/root >> Testpool/TestZones/TestZone/rpool/ROOT/solaris/var 84.3M 48.1G 83.4M >> >> /TestZones/TestZone/root/var >> Testpool/TestZones/TestZone/rpool/VARSHARE 31K 48.1G 31K >> >> /var/share >> Testpool/TestZones/TestZone/rpool/export 62K 48.1G 31K >> >> /export >> Testpool/TestZones/TestZone/rpool/export/home 31K 48.1G 31K >> >> /export/home >> >> >> So on Solaris 11 it allow you to install a zone even if the parent >> mountpoint = none >> >> >> *_Did also some test on OmniOS_* >> >> root at OmniOS:/root# zfs list >> NAME USED AVAIL REFER >> MOUNTPOINT >> DATA 435G 774G 23K /LXZones >> DATA/Backup 432G 774G 432G /Backup >> DATA/LXMatterMost 408M 774G 347M >> /LXZones/LXMatterMost >> DATA/Zones2 2,13G 774G 23K /Zones2 >> DATA/Zones2/NGINX 959M 774G 24K >> /Zones2/NGINX >> DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >> DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >> DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >> DATA/Zones2/Percona 1,19G 774G 24K >> /Zones2/Percona >> DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >> DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >> DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy >> >> >> root at OmniOS:/root# zfs set mountpoint=none DATA >> root at OmniOS:/root# zfs list >> NAME USED AVAIL REFER >> MOUNTPOINT >> DATA 435G 774G 23K none >> DATA/Backup 432G 774G 432G /Backup >> DATA/LXMatterMost 408M 774G 347M none >> DATA/Zones2 2,13G 774G 23K /Zones2 >> DATA/Zones2/NGINX 959M 774G 24K >> /Zones2/NGINX >> DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >> DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >> DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >> DATA/Zones2/Percona 1,19G 774G 24K >> /Zones2/Percona >> DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >> DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >> DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy >> >> root at OmniOS:/root# zonecfg -z Test >> Test: No such zone configured >> Use 'create' to begin configuring a new zone. >> zonecfg:Test> create >> zonecfg:Test> set zonepath=/Zones2/Test >> zonecfg:Test> info >> zonecfg:Test> exit >> root at OmniOS:/root# zonecfg -z Test info >> zonename: Test >> zonepath: /Zones2/Test >> brand: ipkg >> autoboot: false >> bootargs: >> pool: >> limitpriv: >> scheduling-class: >> ip-type: shared >> hostid: >> fs-allowed: >> root at OmniOS:/root# >> >> I'm not making here the filesytem DATA/Zones2/Test !!!! >> >> >> root at OmniOS:/root# zfs list >> NAME USED AVAIL REFER >> MOUNTPOINT >> DATA 435G 774G 23K none >> DATA/Backup 432G 774G 432G /Backup >> DATA/LXMatterMost 408M 774G 347M none >> DATA/Zones2 2,13G 774G 23K /Zones2 >> DATA/Zones2/NGINX 959M 774G 24K >> /Zones2/NGINX >> DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >> DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >> DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >> DATA/Zones2/Percona 1,19G 774G 24K >> /Zones2/Percona >> DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >> DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >> DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy >> >> root at OmniOS:/root# zoneadm list -civ >> ID NAME STATUS PATH BRAND IP >> 0 global running / ipkg shared >> - DNS installed /Zones/DNS lipkg excl >> - LXDebian8 installed /Zones/LXDebian8 lx excl >> - LXMatterMost installed /LXZones/LXMatterMost lx excl >> - Percona installed /Zones2/Percona lipkg excl >> - NGINX installed /Zones2/NGINX lipkg excl >> - Test configured /Zones2/Test ipkg shared >> >> root at OmniOS:/root# zoneadm -z Test install >> WARNING: zone LXMatterMost is installed, but its zonepath >> /LXZones/LXMatterMost does not exist. >> Sanity Check: Looking for 'entire' incorporation. >> ERROR: the zonepath must be a ZFS dataset. >> The parent directory of the zonepath must be a ZFS dataset so that the >> zonepath ZFS dataset can be created properly. >> root at OmniOS:/root# >> >> On this point I had to uninstall the LXMatterMost zone because I set >> the >> mountpoint=none on the DATA pool and the LXMatterMost zone depend on >> the >> mountpoint=/LXZones of the DATA pool. >> >> Then I also created a filesystem DATA/Zones2/Test >> >> >> root at OmniOS:/root# zfs create -o mountpoint=/Zones2/Test >> DATA/Zones2/Test >> root at OmniOS:/root# zfs list >> NAME USED AVAIL REFER >> MOUNTPOINT >> DATA 435G 774G 23K none >> DATA/Backup 432G 774G 432G /Backup >> DATA/Zones2 2,13G 774G 23K /Zones2 >> DATA/Zones2/NGINX 959M 774G 24K >> /Zones2/NGINX >> DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >> DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >> DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >> DATA/Zones2/Percona 1,19G 774G 24K >> /Zones2/Percona >> DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >> DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >> DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy >> DATA/Zones2/Test 23K 774G 23K /Zones2/Test >> >> >> And now it is allowed to install the zone :) >> >> >> root at OmniOS:/root# zoneadm -z Test install >> /Zones2/Test must not be group readable. >> /Zones2/Test must not be group executable. >> /Zones2/Test must not be world readable. >> /Zones2/Test must not be world executable. >> /Zones2/Test: changing permissions to 0700. >> Sanity Check: Looking for 'entire' incorporation. >> Image: Preparing at /Zones2/Test/root. >> >> Publisher: Using omnios (http://pkg.omniti.com/omnios/r151020/). >> Cache: Using /var/pkg/publisher. >> Installing: Packages (output follows) >> Packages to install: 388 >> Mediators to change: 1 >> Services to change: 5 >> >> DOWNLOAD PKGS FILES XFER >> (MB) SPEED >> Completed 388/388 37406/37406 >> 332.0/332.0 0B/s >> >> PHASE ITEMS >> Installing new actions 61025/61025 >> Updating package state database Done >> Updating package cache 0/0 >> Updating image state Done >> Creating fast lookup database Done >> >> Note: Man pages can be obtained by installing pkg:/system/manual >> Postinstall: Copying SMF seed repository ... done. >> Done: Installation completed in 93,895 seconds. >> >> Next Steps: Boot the zone, then log into the zone console (zlogin -C) >> to complete the configuration process >> >> root at OmniOS:/root# zoneadm -z Test boot; zlogin -C Test >> [Connected to zone 'Test' console] >> Loading smf(5) service descriptions: 113/113 >> Hostname: Test >> >> Test console login: >> >> root at OmniOS:/root# zfs list >> NAME USED AVAIL REFER >> MOUNTPOINT >> DATA 435G 774G 23K none >> DATA/Backup 433G 774G 433G /Backup >> DATA/Zones2 2,66G 774G 24K /Zones2 >> DATA/Zones2/NGINX 959M 774G 24K >> /Zones2/NGINX >> DATA/Zones2/NGINX/ROOT 959M 774G 23K legacy >> DATA/Zones2/NGINX/ROOT/export 71K 774G 23K /export >> DATA/Zones2/NGINX/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/NGINX/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/NGINX/ROOT/zbe 959M 774G 959M legacy >> DATA/Zones2/Percona 1,19G 774G 24K >> /Zones2/Percona >> DATA/Zones2/Percona/ROOT 1,19G 774G 23K legacy >> DATA/Zones2/Percona/ROOT/export 71K 774G 23K /export >> DATA/Zones2/Percona/ROOT/export/home 48K 774G 23K >> /export/home >> DATA/Zones2/Percona/ROOT/export/home/witte 25K 774G 25K >> /export/home/witte >> DATA/Zones2/Percona/ROOT/zbe 1,19G 774G 1,19G legacy >> DATA/Zones2/Test 540M 774G 23K /Zones2/Test >> DATA/Zones2/Test/ROOT 540M 774G 23K legacy >> DATA/Zones2/Test/ROOT/zbe 540M 774G 540M legacy >> >> So that's why I ask the question :) >> >> In my opinion we miss some logic in the zoneadm, we don't need to set a >> >> parent mountpoint like i proof with above example. >> >> Maybe someone can have a look on the code it would be great to fix >> this, >> if I had the knowledge how to fix it it should be great, but I'm >> unfortunately not so smart and intelligent as you guy's sorry :( >> >> I wish ;) >> >> >> Kind Regards, >> >> >> Dirk >> >> >> On 10-02-17 22:19, Jim Klimov wrote: >>> 9 ??????? 2017 ?. 18:09:04 CET, Dirk Willems >> ?????: >>>> Thanks Dan, >>>> >>>> >>>> I just was wondering about it, because in Solaris it's allowed we do >> it >>>> all the time and it's become a automatic behavior for us, but if we >>>> know >>>> it we can arrange it like you do. >>>> >>>> >>>> Thanks >>>> >>>> >>>> On 09-02-17 17:41, Dan McDonald wrote: >>>>>> On Feb 9, 2017, at 11:28 AM, Dirk Willems >>>> wrote: >>>>>> Hello OmniOS, >>>>>> >>>>>> Why isn't allowed to install a LX-Zone or Zone if the DATA pool >>>> doesn't have a mountpoint on the parent ? >>>>>> below example doesn't allow you to install a Zone or LX-Zone >>>>>> >>>>>> root at OmniOS:/root# zfs list >>>>>> NAME USED AVAIL REFER MOUNTPOINT >>>>>> DATA 432G 777G 23K none >>>>>> DATA/Backup 432G 777G 432G /Backup >>>>>> DATA/LXZones 23K 777G 23K /LXZones >>>>>> >>>>>> >>>>>> below example does allow you to install a Zone or LX-Zone >>>>>> >>>>>> root at OmniOS:/root# zfs list >>>>>> NAME USED AVAIL REFER MOUNTPOINT >>>>>> DATA 433G 776G 23K /LXZones >>>>>> DATA/Backup 432G 776G 432G /Backup >>>>>> DATA/LXMatterMost 229M 776G 228M >>>> /LXZones/LXMatterMost >>>>>> It's kind ignoring because i like to make separated filesystems >> for >>>> having a nice overview :) >>>>> All zones (not just LX) need to be a subdirectory of a higher-level >>>> ZFS filesystem. This is so zoneadm(1M) can create the zone root. >>>>> bloody(~)[0]% zfs list | grep zones | grep -v zbe >>>>> data/zones 3.90G 509G 23K /zones >>>>> data/zones/lipkg0 3.14G 509G 24K >>>> /zones/lipkg0 >>>>> data/zones/lipkg0/ROOT 3.14G 509G 23K legacy >>>>> data/zones/lx0 465M 509G 465M >>>> /zones/lx0 >>>>> data/zones/lx1 315M 509G 239M >>>> /zones/lx1 >>>>> bloody(~)[0]% >>>>> >>>>> My bloody box has zones name per their brand, so you can see what I >>>> mean. >>>>> Dan >>>>> >>> Just in case, do you not mistake zone roots here with delegated >> datasets (e.g. for data or local progs, but with zfs structure managed > >from inside the zone)? This is indeed usable even from different pools >> in solaris 10 up to openindiana at least. >>> -- >>> Typos courtesy of K-9 Mail on my Samsung Android > Well, seems there is some mix of apples and oranges here - but you don't sen mountpoint of a pool (or rather its root dataset), while you do have a mountpoint of a sub-dataset dedicated to zones (zones2 and testzones) so the system can find it. Would be more interesting if these did not exist with such names and/or mountpoints before zoneadm call. Otherwise, if there is indeed an error or point of improvement, it is likely in brand scripts and should be easily fixable. > > Jim > -- > Typos courtesy of K-9 Mail on my Samsung Android -- **Dirk Willems* * System Engineer *+32 (0)3 443 12 38* *dirk.willems at exitas.be* *Veldkant 31 - 2550 Kontich* *www.exitas.be* *Disclaimer* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: exitas_PMS.png Type: image/png Size: 8486 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm.png Type: image/png Size: 524 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Mail.png Type: image/png Size: 791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: plaats.png Type: image/png Size: 803 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: huis.png Type: image/png Size: 796 bytes Desc: not available URL: From andre at ak47.co.za Tue Feb 14 12:02:40 2017 From: andre at ak47.co.za (Andre Kruger) Date: Tue, 14 Feb 2017 14:02:40 +0200 Subject: [OmniOS-discuss] Moving The Root Pool In-Reply-To: References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> <07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com> Message-ID: On 2017/02/10 16:26, Andre Kruger wrote: > I am running r151018. > > The SSD is bigger that the HDD and I use USB installation media. > > > On 2017/02/10 16:05, Dan McDonald wrote: >>> On Feb 10, 2017, at 2:44 AM, Andre Kruger wrote: >>> >>> I have a running OmniOS system that boots from HDD but I would like to boot the machine from SSD. I first pondered if I could just create an image, using CloneZilla, of the rpool disk and then restore that image again onto the SSD. >> I hadn't heard of clonezilla until just now. >> >>> I am not sure if that is an acceptable method? >> The problem with that is your disk device will be under a different name, and this confuses the illumos boot system a bit. >> >>> I know the windows community warns against this practice. You can clone from HDD to HDD or SSD to SSD, but I have read many reports of windows users experiencing slow performance when cloning from HDD to SSD. >> I have no idea why that would be the case, but regardless... >> >>> Would OmniOS suffer the same performance problems if cloning from HDD to SSD? >> ... I can't say for sure. >> >>> If it will, would this procedure that I found on the OpenIndiana Wiki be valid without much tweaking? >>> >>> https://wiki.openindiana.org/oi/How+to+migrate+the+root+pool >> That article is a bit old. >> >> I've some questions that will help me give better advice. There are no wrong answers here, just be as accurate as you can: >> >> - Which revision of OmniOS are you running? >> - Is your new SSD the same or greater size than the HD you have now? >> - Do you have a CD/DVD or USB installer media? >> >> Thanks, >> Dan >> > Shall I consider the matter dead? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.budach at jvm.de Tue Feb 14 13:38:07 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Tue, 14 Feb 2017 14:38:07 +0100 (CET) Subject: [OmniOS-discuss] Moving The Root Pool In-Reply-To: References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> <07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com> Message-ID: <943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de> Hi Andre, well, I wouldn't call it dead? there is a way to accomplish, what you want and I had already performed such an action before. However, I cannot recall all the steps necessary. Looking at the link Dan provided, the steps lined out in the document are still valid and I don't think that there is an easier way to do it. Regarding the other issues about a general advice against using a SSD as a rpool? there is none I know of. Depending on the manufacturer you may want to provide enough free space on the SSD, as I don't know if Ilumos/OmniOS have come up to speed regarding TRIM, but you can always counter that by providing enough space for the SSD's GC. If a SSD is suited as a rpool in Ilumos may be hard to judge. All I know is, that you should stay away from Samsung EVOs? unless you're operating them in a Windows environment. 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 andre at ak47.co.za Tue Feb 14 14:06:37 2017 From: andre at ak47.co.za (Andre Kruger) Date: Tue, 14 Feb 2017 16:06:37 +0200 Subject: [OmniOS-discuss] Moving The Root Pool In-Reply-To: <943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de> References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> <07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com> <943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de> Message-ID: On 2017/02/14 15:38, Stephan Budach wrote: > Hi Andre, > > well, I wouldn't call it dead? there is a way to accomplish, what you > want and I had already performed such an action before. However, I > cannot recall all the steps necessary. Looking at the link Dan > provided, the steps lined out in the document are still valid and I > don't think that there is an easier way to do it. > > Regarding the other issues about a general advice against using a SSD > as a rpool? there is none I know of. Depending on the manufacturer you > may want to provide enough free space on the SSD, as I don't know if > Ilumos/OmniOS have come up to speed regarding TRIM, but you can always > counter that by providing enough space for the SSD's GC. > If a SSD is suited as a rpool in Ilumos may be hard to judge. All I > know is, that you should stay away from Samsung EVOs? unless you're > operating them in a Windows environment. > > Cheers, > Stephan Hi Stephan No sorry I think there is a misunderstanding. SSDs are excellent for rpool. I was talking about taking a HDD on which rpool is installed ie a running system. Shutting it down. Then cloning the HDD to the SSD. Plug the SSD into the previously running machine and just boot it up. Using this method is much easier, simpler, and faster. But, on many Windows forums there are warning cloning a HDD directly to an SSD, of the boot drive drive C, and then using the SSD. Apparently many users have experienced very slow performance. You can however clone from HDD to HDD or SSD to SSD without these performance problems. From there my question if anybody knows of a caveat not to do it in this way if I want to clone my rpool from HDD to SSD. If none I would rather walk this path as it is far less trouble. BTW, why should one steer clear of the Samsung EVO's? Regards Andr? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Feb 14 14:18:53 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 14 Feb 2017 09:18:53 -0500 Subject: [OmniOS-discuss] Moving The Root Pool In-Reply-To: References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> <07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com> Message-ID: <6DCE930B-F26C-41E1-9B4A-E0822A4E9856@omniti.com> > On Feb 14, 2017, at 7:02 AM, Andre Kruger wrote: > > Shall I consider the matter dead? No! I'd asked about some things offline: 1.) Are the SSDs larger than the HDs? (you said yes) 2.) Which OmniOS (you said r151018). Since the SSDs are larger, you COULD use mirroring to clone your rpool. 1.) zpool attach [-f] rpool HDD-drive SSD-drive 2.) Let the mirror completely resilver. 3.) installgrub -M /dev/rdsk/HDD-drive /dev/rdsk/SSD-drive (alternatively installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/SSD-drive) 4.) Reboot your system MAKING SURE YOU SELECT THE SSD TO BOOT. This is important, because if you can't boot via SSD, you shouldn't break the HDD from the mirror. OPTIONAL: Unplug your HDD before booting. If (and only if) you boot off the SSD successfully, proceed to decomission the HDD, and add the new SSD space to rpool: 5.) zpool detach rpool HDD-drive 6.) zpool online -e rpool If you cannot boot off the SSD for some reason, reconnect the HDD, boot off of it, and detach the SSD from the rpool instead. You'll have to try another way. Dan From jaakko.linnosaari at polarshift.fi Tue Feb 14 14:32:28 2017 From: jaakko.linnosaari at polarshift.fi (Jaakko Linnosaari) Date: Tue, 14 Feb 2017 16:32:28 +0200 Subject: [OmniOS-discuss] Moving The Root Pool In-Reply-To: References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> <07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com> <943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de> Message-ID: <35F997F1-A0D7-4808-987A-78EF7AD82B07@polarshift.fi> > On 14 Feb 2017, at 16.06, Andre Kruger wrote: > > But, on many Windows forums there are warning cloning a HDD directly to an SSD, of the boot drive drive C, and then using the SSD. Apparently many users have experienced very slow performance. You can however clone from HDD to HDD or SSD to SSD without these performance problems. From there my question if anybody knows of a caveat not to do it in this way if I want to clone my rpool from HDD to SSD. If none I would rather walk this path as it is far less trouble. I think the slow (write) performance is due to too small block size and write amplification. ? Jaakko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimklimov at cos.ru Tue Feb 14 15:16:04 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Tue, 14 Feb 2017 16:16:04 +0100 Subject: [OmniOS-discuss] Moving The Root Pool In-Reply-To: References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> <07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com> <943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de> Message-ID: 14 ??????? 2017??. 15:06:37 CET, Andre Kruger ?????: > > >On 2017/02/14 15:38, Stephan Budach wrote: >> Hi Andre, >> >> well, I wouldn't call it dead? there is a way to accomplish, what you > >> want and I had already performed such an action before. However, I >> cannot recall all the steps necessary. Looking at the link Dan >> provided, the steps lined out in the document are still valid and I >> don't think that there is an easier way to do it. >> >> Regarding the other issues about a general advice against using a SSD > >> as a rpool? there is none I know of. Depending on the manufacturer >you >> may want to provide enough free space on the SSD, as I don't know if >> Ilumos/OmniOS have come up to speed regarding TRIM, but you can >always >> counter that by providing enough space for the SSD's GC. >> If a SSD is suited as a rpool in Ilumos may be hard to judge. All I >> know is, that you should stay away from Samsung EVOs? unless you're >> operating them in a Windows environment. >> >> Cheers, >> Stephan > >Hi Stephan > >No sorry I think there is a misunderstanding. SSDs are excellent for >rpool. I was talking about taking a HDD on which rpool is installed ie >a >running system. Shutting it down. Then cloning the HDD to the SSD. Plug > >the SSD into the previously running machine and just boot it up. Using >this method is much easier, simpler, and faster. > >But, on many Windows forums there are warning cloning a HDD directly to > >an SSD, of the boot drive drive C, and then using the SSD. Apparently >many users have experienced very slow performance. You can however >clone >from HDD to HDD or SSD to SSD without these performance problems. From >there my question if anybody knows of a caveat not to do it in this way > >if I want to clone my rpool from HDD to SSD. If none I would rather >walk >this path as it is far less trouble. > >BTW, why should one steer clear of the Samsung EVO's? > > >Regards >Andr? My take on it is that cloning may fail you because of native sector size that might be 512b to 4k on HDDs but may be 4k or 8k on SSDs. Using old block sizes may be suboptimal (RMW cycles) or impossible (if storage firmware does not virtualize legacy sector sizes). So you'd be better off creating a pool on the ssd 'natively' and zfs send'ing the datasets from HDD recursively. Jim -- Typos courtesy of K-9 Mail on my Samsung Android From serge.fonville at gmail.com Tue Feb 14 17:19:19 2017 From: serge.fonville at gmail.com (Serge Fonville) Date: Tue, 14 Feb 2017 18:19:19 +0100 Subject: [OmniOS-discuss] Install postfix on OmniOS Message-ID: Hello, Whey trying to install postfix on OmniOS 151018 I get an error stating that "This version is excluded by installed incorporation". On IRC I was informed that this is due to the type of dependency the postfix package has on entire. Thank you very much for any help in advance! Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl From danmcd at omniti.com Tue Feb 14 17:44:07 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 14 Feb 2017 12:44:07 -0500 Subject: [OmniOS-discuss] Install postfix on OmniOS In-Reply-To: References: Message-ID: <68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com> > On Feb 14, 2017, at 12:19 PM, Serge Fonville wrote: > > Hello, > > Whey trying to install postfix on OmniOS 151018 I get an error stating > that "This version is excluded by installed incorporation". > > On IRC I was informed that this is due to the type of dependency the > postfix package has on entire. > > Thank you very much for any help in advance! To query such dependencies, use pkg(1): bloody(~)[0]% pkg contents -rm postfix | grep entire depend fmri=pkg:/entire at 11-0.151014 type=incorporate bloody(~)[0]% That one will present problems. An updated package won't, e.g.: bloody(~)[0]% pkg contents -rm python-34 | grep entire depend fmri=pkg:/entire at 11-0.151014 type=optional bloody(~)[0]% Dan From serge.fonville at gmail.com Tue Feb 14 18:28:59 2017 From: serge.fonville at gmail.com (Serge Fonville) Date: Tue, 14 Feb 2017 19:28:59 +0100 Subject: [OmniOS-discuss] Install postfix on OmniOS In-Reply-To: <68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com> References: <68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com> Message-ID: Hi Dan, Thanks for your explanation, what would be the best course of action to get this resolved? Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl 2017-02-14 18:44 GMT+01:00 Dan McDonald : > >> On Feb 14, 2017, at 12:19 PM, Serge Fonville wrote: >> >> Hello, >> >> Whey trying to install postfix on OmniOS 151018 I get an error stating >> that "This version is excluded by installed incorporation". >> >> On IRC I was informed that this is due to the type of dependency the >> postfix package has on entire. >> >> Thank you very much for any help in advance! > > To query such dependencies, use pkg(1): > > bloody(~)[0]% pkg contents -rm postfix | grep entire > depend fmri=pkg:/entire at 11-0.151014 type=incorporate > bloody(~)[0]% > > That one will present problems. An updated package won't, e.g.: > > bloody(~)[0]% pkg contents -rm python-34 | grep entire > depend fmri=pkg:/entire at 11-0.151014 type=optional > bloody(~)[0]% > > > Dan > From danmcd at omniti.com Tue Feb 14 18:39:22 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 14 Feb 2017 13:39:22 -0500 Subject: [OmniOS-discuss] Install postfix on OmniOS In-Reply-To: References: <68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com> Message-ID: <9ED05CC5-F0E4-4C44-9AAE-4D17DF3E3577@omniti.com> > On Feb 14, 2017, at 1:28 PM, Serge Fonville wrote: > > Thanks for your explanation, what would be the best course of action > to get this resolved? When and if someone who maintains omniti-ms gets some cycles, that someone can rebuild the postfix package so that the dependency in question gets altered. As mentioned here and elsewhere before: omniti-ms is unsupported, and is basically just an internal repo with world-readability. Be patient, and when someone has cycles, someone will get to it. Someone has read this note I'm sure, so it's not just shouting into the void. Thanks for your patience, Dan From illumos at cucumber.demon.co.uk Tue Feb 14 19:54:40 2017 From: illumos at cucumber.demon.co.uk (Andrew Gabriel) Date: Tue, 14 Feb 2017 19:54:40 +0000 Subject: [OmniOS-discuss] Moving The Root Pool In-Reply-To: <35F997F1-A0D7-4808-987A-78EF7AD82B07@polarshift.fi> References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za> <07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com> <943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de> <35F997F1-A0D7-4808-987A-78EF7AD82B07@polarshift.fi> Message-ID: <4a0737cb-6193-1c07-108b-79b895492a8a@cucumber.demon.co.uk> On 14/02/2017 14:32, Jaakko Linnosaari wrote: > >> On 14 Feb 2017, at 16.06, Andre Kruger > > wrote: >> >> But, on many Windows forums there are warning cloning a HDD directly >> to an SSD, of the boot drive drive C, and then using the SSD. >> Apparently many users have experienced very slow performance. You can >> however clone from HDD to HDD or SSD to SSD without these performance >> problems. From there my question if anybody knows of a caveat not to >> do it in this way if I want to clone my rpool from HDD to SSD. If >> none I would rather walk this path as it is far less trouble. > > I think the slow (write) performance is due to too small block size > and write amplification. You might want to update sd.conf with this... https://wiki.illumos.org/display/illumos/List+of+sd-config-list+entries+for+Advanced-Format+drives I recently added the Evo 850 to it, so it gives me an ashift 13 zpool on it. That might stop you attaching it to an ashift 9 rpool though. I created a new rpool (called something else - the name doesn't matter), replicated the fdisk/slice structure, zfs send/recv the data across, and installed grub. -- Andrew Gabriel -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Feb 14 22:50:54 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 14 Feb 2017 17:50:54 -0500 Subject: [OmniOS-discuss] Install postfix on OmniOS In-Reply-To: <9ED05CC5-F0E4-4C44-9AAE-4D17DF3E3577@omniti.com> References: <68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com> <9ED05CC5-F0E4-4C44-9AAE-4D17DF3E3577@omniti.com> Message-ID: <97896EAC-D540-478F-AE32-60605E59B4DE@omniti.com> > On Feb 14, 2017, at 1:39 PM, Dan McDonald wrote: > When and if someone who maintains omniti-ms gets some cycles, that someone can rebuild the postfix package so that the dependency in question gets altered. > > As mentioned here and elsewhere before: omniti-ms is unsupported, and is basically just an internal repo with world-readability. Be patient, and when someone has cycles, someone will get to it. Someone has read this note I'm sure, so it's not just shouting into the void. Someone was nice and had some cycles: pkg://ms.omniti.com/omniti/network/smtp/postfix at 2.10.10-0.151014:20170214T224634Z pkg://ms.omniti.com/omniti/network/smtp/postfix at 2.11.9-0.151014:20170214T224831Z Try now, Dan From serge.fonville at gmail.com Tue Feb 14 23:17:59 2017 From: serge.fonville at gmail.com (Serge Fonville) Date: Wed, 15 Feb 2017 00:17:59 +0100 Subject: [OmniOS-discuss] Install postfix on OmniOS In-Reply-To: <97896EAC-D540-478F-AE32-60605E59B4DE@omniti.com> References: <68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com> <9ED05CC5-F0E4-4C44-9AAE-4D17DF3E3577@omniti.com> <97896EAC-D540-478F-AE32-60605E59B4DE@omniti.com> Message-ID: I successfully installed postfix :D!!! Thank you very much for the effort and support!!! Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl 2017-02-14 23:50 GMT+01:00 Dan McDonald : > >> On Feb 14, 2017, at 1:39 PM, Dan McDonald wrote: >> When and if someone who maintains omniti-ms gets some cycles, that someone can rebuild the postfix package so that the dependency in question gets altered. >> >> As mentioned here and elsewhere before: omniti-ms is unsupported, and is basically just an internal repo with world-readability. Be patient, and when someone has cycles, someone will get to it. Someone has read this note I'm sure, so it's not just shouting into the void. > > Someone was nice and had some cycles: > > pkg://ms.omniti.com/omniti/network/smtp/postfix at 2.10.10-0.151014:20170214T224634Z > pkg://ms.omniti.com/omniti/network/smtp/postfix at 2.11.9-0.151014:20170214T224831Z > > Try now, > Dan > From lists at marzocchi.net Tue Feb 14 23:32:17 2017 From: lists at marzocchi.net (Olaf Marzocchi) Date: Wed, 15 Feb 2017 00:32:17 +0100 Subject: [OmniOS-discuss] Install postfix on OmniOS In-Reply-To: References: <68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com> <9ED05CC5-F0E4-4C44-9AAE-4D17DF3E3577@omniti.com> <97896EAC-D540-478F-AE32-60605E59B4DE@omniti.com> Message-ID: I also used to install omniti-ms packages, but I found that I could find all I needed from niksula.hut.fi or uulm.mawi, more often updated. If you care about not only about installing, but also about keeping packages updated, check those two repos. Compare also for which OmniOS release the packages from omniti-ms have been compiled... sometimes I remember very old releases. Olaf On 15/02/2017 00:17, Serge Fonville wrote: > I successfully installed postfix :D!!! > > Thank you very much for the effort and support!!! > Kind regards/met vriendelijke groet, > > Serge Fonville > > http://www.sergefonville.nl > > > 2017-02-14 23:50 GMT+01:00 Dan McDonald : >> >>> On Feb 14, 2017, at 1:39 PM, Dan McDonald wrote: >>> When and if someone who maintains omniti-ms gets some cycles, that someone can rebuild the postfix package so that the dependency in question gets altered. >>> >>> As mentioned here and elsewhere before: omniti-ms is unsupported, and is basically just an internal repo with world-readability. Be patient, and when someone has cycles, someone will get to it. Someone has read this note I'm sure, so it's not just shouting into the void. >> >> Someone was nice and had some cycles: >> >> pkg://ms.omniti.com/omniti/network/smtp/postfix at 2.10.10-0.151014:20170214T224634Z >> pkg://ms.omniti.com/omniti/network/smtp/postfix at 2.11.9-0.151014:20170214T224831Z >> >> Try now, >> Dan >> > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From fabio at fabiorabelo.wiki.br Wed Feb 15 17:16:25 2017 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Wed, 15 Feb 2017 15:16:25 -0200 Subject: [OmniOS-discuss] SMB and Netatalk Message-ID: Hi to all There are someone with experience in running SMB and/or Netatalk over OmniOS ? Works OK ? Some caveats to avoid ? The possible scenario would be a server to hold Audio and Video files in a Video/Audio editing facility, with 10 GB network in/out, and 12 8 TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM . Thanks in advance ... F?bio Rabelo From tom-omnios-discuss at tom.bn-ulm.de Wed Feb 15 18:09:22 2017 From: tom-omnios-discuss at tom.bn-ulm.de (Thomas Wagner) Date: Wed, 15 Feb 2017 19:09:22 +0100 Subject: [OmniOS-discuss] SMB and Netatalk In-Reply-To: References: Message-ID: <20170215180922.GK16986@wagner-net.com> I thought Apple was giving up on netatalk, but I might be wrong. The netatalk maintainers should know more detail. Last version update to 3.1.10 is from 20160912 About SMB, the more recent SMB implemtations with the updated SMB protocol should be and interesting choice compared to netatalk. I think samba 4.4 supports SMB2 and early versions of SMB3, but you should verify if samba or kernel-SMB from illumos give the expercted results. I can't tell right now what the exact kernel SMB protocol version in Illumos is currently supporting. One scenario could be to run the kernel SMB in the fileserver global zone and one samba instance in a non-global-zone to make up login/domain service. What type of SSD for ZIL do you intend to use? Will it be mirrored? It is a critical component that even gets small writes of data, depending on the type of transaction which is performed. (Details are up to the ZFS experts). I have a compile job running right now and see if I can make a package with netatalk 3.1.10 for OmniOS. Samba 4.4.9 is alread in the repo on http://sfe.opencsw.org. Regards, Thomas On Wed, Feb 15, 2017 at 03:16:25PM -0200, F??bio Rabelo wrote: > Hi to all > > There are someone with experience in running SMB and/or Netatalk over OmniOS ? > > Works OK ? > > Some caveats to avoid ? > > The possible scenario would be a server to hold Audio and Video files > in a Video/Audio editing facility, with 10 GB network in/out, and 12 8 > TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM . > > Thanks in advance ... > > > F??bio Rabelo > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -- -- From lkateley at kateley.com Wed Feb 15 19:09:11 2017 From: lkateley at kateley.com (Linda Kateley) Date: Wed, 15 Feb 2017 13:09:11 -0600 Subject: [OmniOS-discuss] SMB and Netatalk In-Reply-To: References: Message-ID: <07269b96-b4b1-e50f-0ef0-ff0abd2ce835@kateley.com> Fabio, I design systems all the time for video editing. There are several questions that need to be answered..what will be average file size? 4k? 8k video? How many 10gbe? how many editors accessing simultaneously? What software are you running? I usually size ram per user if they are working with different files, or size ram to average file.. I run procs up higher for multiple 10gbe. Need to be a little careful with 10gbe drivers in omni. For zil, you only need/use zil if you are running nfs or iscsi. Use the ssd for arc if you are running smb or netatalk. Been seeing several configs be successful with raidz2 and editing, but i would prefer mirrors. I would usually like to see 2 boxes one for work and one for archive. I hate to do marketing... but if you would like to contact me offlist, i can help you with design. That is what my company does :) linda On 2/15/17 11:16 AM, F?bio Rabelo wrote: > Hi to all > > There are someone with experience in running SMB and/or Netatalk over OmniOS ? > > Works OK ? > > Some caveats to avoid ? > > The possible scenario would be a server to hold Audio and Video files > in a Video/Audio editing facility, with 10 GB network in/out, and 12 8 > TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM . > > Thanks in advance ... > > > F?bio Rabelo > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From feigin at iis.ee.ethz.ch Thu Feb 16 08:47:50 2017 From: feigin at iis.ee.ethz.ch (Adam Feigin) Date: Thu, 16 Feb 2017 09:47:50 +0100 Subject: [OmniOS-discuss] SMB and Netatalk In-Reply-To: References: Message-ID: On 15/02/17 18:16, omnios-discuss-request at lists.omniti.com wrote: > From: F?bio Rabelo > To: omnios-discuss > Subject: [OmniOS-discuss] SMB and Netatalk > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Hi to all > > There are someone with experience in running SMB and/or Netatalk over OmniOS ? > > Works OK ? > > Some caveats to avoid ? > > The possible scenario would be a server to hold Audio and Video files > in a Video/Audio editing facility, with 10 GB network in/out, and 12 8 > TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM . > netatalk works like a charm, as does cifs. I'll just assume that you're wanting to serve Macs; despite all that Apple is telling the world, my experience is that AFP "works" better. I've experienced no end of bizzare and differing problems using SMB/CIFS with OSX (not just on OmniOS!). Each OSX version has various quirks with SMB, whereas AFP being the "native" OSX file protocol just works plug an play, no fooling around, across differing OSX versions. You can either pull it in from the uulm.mawi omnios package repository, or build it yourself (but it does have some dependencies, so you're probably better off installing the from the repository). /AWF From stephan.budach at jvm.de Thu Feb 16 09:34:29 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Thu, 16 Feb 2017 10:34:29 +0100 (CET) Subject: [OmniOS-discuss] SMB and Netatalk In-Reply-To: References: Message-ID: <911825537.794.1487237636308.JavaMail.stephan.budach@stephanbudach.local> ----- Urspr?ngliche Mail ----- Von: "Adam Feigin" An: omnios-discuss at lists.omniti.com Gesendet: Donnerstag, 16. Februar 2017 09:47:50 Betreff: [OmniOS-discuss] SMB and Netatalk On 15/02/17 18:16, omnios-discuss-request at lists.omniti.com wrote: > From: F?bio Rabelo > To: omnios-discuss > Subject: [OmniOS-discuss] SMB and Netatalk > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Hi to all > > There are someone with experience in running SMB and/or Netatalk over OmniOS ? > > Works OK ? > > Some caveats to avoid ? > > The possible scenario would be a server to hold Audio and Video files > in a Video/Audio editing facility, with 10 GB network in/out, and 12 8 > TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM . > netatalk works like a charm, as does cifs. I'll just assume that you're wanting to serve Macs; despite all that Apple is telling the world, my experience is that AFP "works" better. I've experienced no end of bizzare and differing problems using SMB/CIFS with OSX (not just on OmniOS!). Each OSX version has various quirks with SMB, whereas AFP being the "native" OSX file protocol just works plug an play, no fooling around, across differing OSX versions. You can either pull it in from the uulm.mawi omnios package repository, or build it yourself (but it does have some dependencies, so you're probably better off installing the from the repository). /AWF I guess anyone who looks into SMB for Macs, should also look at vfs_fruit for Samba. I haven't had the chance to set this up myself, but from what I have read, this is the way to go? ?on the other hand, I am still running our big servers using Netatalk 2.3.x and this hasn't failed me for years. ;) 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 davide.poletto at gmail.com Thu Feb 16 11:29:37 2017 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Feb 2017 12:29:37 +0100 Subject: [OmniOS-discuss] SMB and Netatalk In-Reply-To: References: Message-ID: I recall I've seen this: http://www.napp-it.com/doc/downloads/performance_smb2.pdf It would be an interesting document to read (it's not focused specifically on Netatalk but it explores some performance patterns using Mac OS X clients with NFS/SMB v1/v2 on OmniOS server side). On Wed, Feb 15, 2017 at 6:16 PM, F?bio Rabelo wrote: > Hi to all > > There are someone with experience in running SMB and/or Netatalk over > OmniOS ? > > Works OK ? > > Some caveats to avoid ? > > The possible scenario would be a server to hold Audio and Video files > in a Video/Audio editing facility, with 10 GB network in/out, and 12 8 > TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM . > > Thanks in advance ... > > > F?bio Rabelo > _______________________________________________ > 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 cf at ferebee.net Thu Feb 16 11:47:20 2017 From: cf at ferebee.net (Chris Ferebee) Date: Thu, 16 Feb 2017 12:47:20 +0100 Subject: [OmniOS-discuss] SMB and Netatalk In-Reply-To: References: Message-ID: Hi Fabio, Let me tell you about my personal hell. In 2014 I tried to set up a big file server for a motion graphics client using netatalk on SmartOS. To put it succinctly, it was a disaster. The Finder took forever to open windows on the server, etc. With help from people who actually know what they?re doing (unlike me) I reached the following conclusions. The Finder, starting around 10.7 or 10.8, behaves very poorly with shares under certain circumstances. If any folder window is open in the Finder, it will continually thrash through the subdirectories doing fsgetpath() getxattr() getattrlist() on everything. I think this is a Finder bug, and it seems to be present in macOS Sierra as well. Samba replies to these queries from a cache, but netatalk performs calls to getcwd() [get current working directory] for every call to fsgetpath. This call is very expensive on Solaris - the OS doesn?t cache it because there is no expectation that it will be called frequently. As a result, the Finder on a single Mac client, sitting idle with one folder window open to the netatalk share, would peg a core on the server. It would take tens of seconds, sometimes minutes, to display the contents of folders. (I?m sure it didn?t help that we had over 100 million files on the share.) Take a look at this thread, where we discuss the issues. At some point Ralph B?hme seemed to suggest that this Finder behaviour could be avoided if netatalk were built with full Spotlight API support, but that was too experimental at the time for me to attempt in production. That may be why this issue doesn?t seem to affect AFP connections to Apple?s afp server. In the end, we switched from netatalk to HELIOS EtherShare, which is $$$, but has been rock-solid and blazingly fast. Note that this problem seems to affect netatalk on Linux to a lesser degree, perhaps because getcwd() is much faster on Linux than on Solaris. Best, Chris > Am 15.02.2017 um 18:16 schrieb F?bio Rabelo : > > Hi to all > > There are someone with experience in running SMB and/or Netatalk over OmniOS ? > > Works OK ? > > Some caveats to avoid ? > > The possible scenario would be a server to hold Audio and Video files > in a Video/Audio editing facility, with 10 GB network in/out, and 12 8 > TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM . > > Thanks in advance ... > > > F?bio Rabelo > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From dan at syneto.eu Thu Feb 16 12:22:33 2017 From: dan at syneto.eu (Dan Vatca) Date: Thu, 16 Feb 2017 14:22:33 +0200 Subject: [OmniOS-discuss] SMB and Netatalk In-Reply-To: References: Message-ID: <8A1526D7-E6C7-470B-A0E1-A0B085BDEBC6@syneto.eu> Hi, This issue is caused indeed by the calls to getcwd that are very slow on illumos/solaris. A workaround that solves the performance problems is to avoid those calls entirely by setting ?follow symlinks = yes?. However, this will allow server-side symlinks to be followed outside the directory. If permissions are setup correctly, it should not be that big of a security issue. Dan. On 16/02/2017, 13:47, "OmniOS-discuss on behalf of Chris Ferebee" wrote: Hi Fabio, Let me tell you about my personal hell. In 2014 I tried to set up a big file server for a motion graphics client using netatalk on SmartOS. To put it succinctly, it was a disaster. The Finder took forever to open windows on the server, etc. With help from people who actually know what they?re doing (unlike me) I reached the following conclusions. The Finder, starting around 10.7 or 10.8, behaves very poorly with shares under certain circumstances. If any folder window is open in the Finder, it will continually thrash through the subdirectories doing fsgetpath() getxattr() getattrlist() on everything. I think this is a Finder bug, and it seems to be present in macOS Sierra as well. Samba replies to these queries from a cache, but netatalk performs calls to getcwd() [get current working directory] for every call to fsgetpath. This call is very expensive on Solaris - the OS doesn?t cache it because there is no expectation that it will be called frequently. As a result, the Finder on a single Mac client, sitting idle with one folder window open to the netatalk share, would peg a core on the server. It would take tens of seconds, sometimes minutes, to display the contents of folders. (I?m sure it didn?t help that we had over 100 million files on the share.) Take a look at this thread, where we discuss the issues. At some point Ralph B?hme seemed to suggest that this Finder behaviour could be avoided if netatalk were built with full Spotlight API support, but that was too experimental at the time for me to attempt in production. That may be why this issue doesn?t seem to affect AFP connections to Apple?s afp server. In the end, we switched from netatalk to HELIOS EtherShare, which is $$$, but has been rock-solid and blazingly fast. Note that this problem seems to affect netatalk on Linux to a lesser degree, perhaps because getcwd() is much faster on Linux than on Solaris. Best, Chris > Am 15.02.2017 um 18:16 schrieb F?bio Rabelo : > > Hi to all > > There are someone with experience in running SMB and/or Netatalk over OmniOS ? > > Works OK ? > > Some caveats to avoid ? > > The possible scenario would be a server to hold Audio and Video files > in a Video/Audio editing facility, with 10 GB network in/out, and 12 8 > TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM . > > Thanks in advance ... > > > F?bio Rabelo > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From lists at marzocchi.net Thu Feb 16 14:01:58 2017 From: lists at marzocchi.net (Olaf Marzocchi) Date: Thu, 16 Feb 2017 15:01:58 +0100 Subject: [OmniOS-discuss] SMB and Netatalk In-Reply-To: References: Message-ID: <3A2D48D4-6CDC-44C5-BBB9-855EDDB37AC4@marzocchi.net> I would like to remind all those interested in netatalk that a future switch to smb will probably cause loss of finder labels and similar metadata, plus some mismatch in uncommon characters like question marks and so on. At least, both happened to me and I was using a very basic configuration. It is possible to convert the metadata manually, but I forgot the name of the tool able to do that. I used an apple script I wrote for that, but there are better tools. I can provide it if requested. After my experience I'm of the opinion that, as long as no client uses OS X < 10.9 and as long as an OmniOS with built-in kernel smb2 is available, smb2 should be the choice. I never felt the need of Samba on OmniOS, since I use no AD credentials. If the chosen OmniOS has only cifs support, then netatalk will bring a visible performance benefit (but require later a conversion of metadata). Olaf Il 16 febbraio 2017 12:29:37 CET, Davide Poletto ha scritto: >I recall I've seen this: > >http://www.napp-it.com/doc/downloads/performance_smb2.pdf > >It would be an interesting document to read (it's not focused >specifically >on Netatalk but it explores some performance patterns using Mac OS X >clients with NFS/SMB v1/v2 on OmniOS server side). > >On Wed, Feb 15, 2017 at 6:16 PM, F?bio Rabelo > >wrote: > >> Hi to all >> >> There are someone with experience in running SMB and/or Netatalk over >> OmniOS ? >> >> Works OK ? >> >> Some caveats to avoid ? >> >> The possible scenario would be a server to hold Audio and Video files >> in a Video/Audio editing facility, with 10 GB network in/out, and 12 >8 >> TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM . >> >> Thanks in advance ... >> >> >> F?bio Rabelo >> _______________________________________________ >> 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 Feb 16 12:06:52 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Thu, 16 Feb 2017 12:06:52 +0000 (UTC) Subject: [OmniOS-discuss] Kernel panel Message-ID: Anyone interested in more information from a kernel panic this morning? OmniOS v11 r151020 carolina# (24) uname -a SunOS carolina 5.11 omnios-bed3013 i86pc i386 i86pc > ::status debugging crash dump vmcore.0 (64-bit) from carolina operating system: 5.11 omnios-bed3013 (i86pc) image uuid: 5e489eff-62c1-4ce7-deb5-c8b48d8aec0f panic message: BAD TRAP: type=e (#pf Page fault) rp=ffffd00042bccb10 addr=30 occurred in module "ip" due to a NULL pointer dereference dump content: kernel pages only > ::stack ip_quiesce_conn+0x2a(ffffd00d413e7a00) udp_do_close+0x40(ffffd00d413e7a00) udp_close+0x19(ffffd00d413e7a00, 83, ffffd00d86e21a88) so_close+0x7a(ffffd00d21f315a0, 83, ffffd00d86e21a88) socket_close_internal+0x1b(ffffd00d21f315a0, 83, ffffd00d86e21a88) socket_vop_close+0xe8(ffffd00d21f34440, 83, 1, 0, ffffd00d86e21a88, 0) fop_close+0x61(ffffd00d21f34440, 83, 1, 0, ffffd00d86e21a88, 0) closef+0x5e(ffffd02783669850) closeandsetf+0x398(38, 0) close+0x13(38) sys_syscall+0x196() -- 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 Thu Feb 16 18:07:06 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 16 Feb 2017 13:07:06 -0500 Subject: [OmniOS-discuss] Kernel panel In-Reply-To: References: Message-ID: <61E0D396-F530-4AAB-8217-F4ADA1968C7D@omniti.com> > On Feb 16, 2017, at 7:06 AM, Andy Fiddaman wrote: > > > Anyone interested in more information from a kernel panic this morning? > > OmniOS v11 r151020 Please share. Thanks, Dan From lukasstraub2 at web.de Sat Feb 18 22:53:53 2017 From: lukasstraub2 at web.de (lukas) Date: Sat, 18 Feb 2017 23:53:53 +0100 Subject: [OmniOS-discuss] [Bug] Installer crashes on disk selection Message-ID: <20170218235353.4c709575@luklap.fritz.box> Hello, I stumbled upon an Bug in the OmniOS Installer where it crashes on the "Disks" Screen of the Installer. It happens at least in "OmniOS_Text_r151020.iso" and "OmniOS_Text_bloody_20170117.iso" when used together with an Paravirtualized Disk Driver inside an VM. How to Reproduce ================ On an Debian Stretch host, Run an Qemu VM with the "virtio" Disk Interface: kvm -k de -smp 2 -drive file=OmniOS.img,if=virtio,format=raw -m 512M -monitor stdio -net nic,model=e1000 -net user -cdrom OmniOS_Text_r151020.iso -vnc :0 The same also happens with Xen. /system/volatile/install_log ============================ 2017-02-18 22:38:25,313 InstallationLogger INFO **** START **** PROGRESS REPORT: progress percent:0 Preparing for Installation PROGRESS REPORT: progress percent:100 TargetDiscovery completed. 2017-02-18 22:38:26,312 InstallationLogger INFO -> [DataObjectCache] () -> [persistent] (DataObjectCacheChild: persistent) -> [sysconfig] () -> [discovered] () -> [disk] (Disk: ctd=c2d0; volid=None; devpath=/xpvd/xdf at 0; devid=None; wwn=None; prop:dev_size=15.99gb; is_cdrom=False; label=VTOC; whole_disk=False; write_cache=False; active ctd aliases=c2d0) -> [logical] (Logical: noswap=True; nodump=True) -> [Engine-DOC-Root-Node] () -> [TargetDiscovery] () -> [desired] () -> [logical] (Logical: noswap=False; nodump=False) -> [rpool] (Zpool: name=rpool; action=create; is_root=True; vdev_list=[None]) -> [vdev] (Vdev: name=vdev; redundancy=none) -> [omnios] (BE: name=omnios; mountpoint=/a) -> [volatile] (DataObjectCacheChild: volatile) -> [apply_sysconfig_dict] () -> [transfer-ti-files] () 2017-02-18 22:38:26,313 InstallationLogger INFO Install Data: Install Completed - False Log Location - /system/volatile/install_log Log Final - /var/log/install/install_log No Install Mode - False 2017-02-18 22:38:26,313 InstallationLogger ERROR Install failed Traceback (most recent call last): File "/usr/lib/python2.7/vendor-packages/solaris_install/text_install/__init__.py", line 421, in main screen = screen.show() File "/usr/lib/python2.7/vendor-packages/terminalui/base_screen.py", line 149, in show self._show() File "/usr/lib/python2.7/vendor-packages/solaris_install/text_install/disk_selection.py", line 399, in _show self.disk_win.activate_object(self.selected_disk_index) File "/usr/lib/python2.7/vendor-packages/terminalui/scroll_window.py", line 338, in activate_object self.activate_object_force(index=index, loop=loop, force_to_top=jump) File "/usr/lib/python2.7/vendor-packages/terminalui/scroll_window.py", line 352, in activate_object_force jump=force_to_top) File "/usr/lib/python2.7/vendor-packages/terminalui/inner_window.py", line 318, in activate_object raise IndexError(err_msg) IndexError: Index (0) out of range (0-0) 2017-02-18 22:38:26,315 InstallationLogger INFO **** END **** format ====== Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c2d0 /xpvd/xdf at 0 Specify disk (enter its number): From danmcd at omniti.com Sun Feb 19 07:07:20 2017 From: danmcd at omniti.com (Dan McDonald) Date: Sun, 19 Feb 2017 02:07:20 -0500 Subject: [OmniOS-discuss] [Bug] Installer crashes on disk selection In-Reply-To: <20170218235353.4c709575@luklap.fritz.box> References: <20170218235353.4c709575@luklap.fritz.box> Message-ID: This is a known issue with the current installer. We're fixing this by replacing the installer for the next OmniOS release. Please track bloody for the upcoming installer change. If you can, boot off dhcp and use the Kayak PXE installer, which will form the basis of the new ISO one. Dan Sent from my iPhone (typos, autocorrect, and all) > On Feb 18, 2017, at 5:53 PM, lukas wrote: > > Hello, > I stumbled upon an Bug in the OmniOS Installer where it crashes on the > "Disks" Screen of the Installer. It happens at least in "OmniOS_Text_r151020.iso" > and "OmniOS_Text_bloody_20170117.iso" when used together with an Paravirtualized > Disk Driver inside an VM. > > How to Reproduce > ================ > > On an Debian Stretch host, Run an Qemu VM with the "virtio" Disk Interface: > > kvm -k de -smp 2 -drive file=OmniOS.img,if=virtio,format=raw -m 512M -monitor stdio -net nic,model=e1000 -net user -cdrom OmniOS_Text_r151020.iso -vnc :0 > > The same also happens with Xen. > > > /system/volatile/install_log > ============================ > > 2017-02-18 22:38:25,313 InstallationLogger INFO **** START **** > PROGRESS REPORT: progress percent:0 Preparing for Installation > PROGRESS REPORT: progress percent:100 TargetDiscovery completed. > 2017-02-18 22:38:26,312 InstallationLogger INFO -> [DataObjectCache] () > -> [persistent] (DataObjectCacheChild: persistent) > -> [sysconfig] () > -> [discovered] () > -> [disk] (Disk: ctd=c2d0; volid=None; devpath=/xpvd/xdf at 0; devid=None; wwn=None; prop:dev_size=15.99gb; is_cdrom=False; label=VTOC; whole_disk=False; write_cache=False; active ctd aliases=c2d0) > -> [logical] (Logical: noswap=True; nodump=True) > -> [Engine-DOC-Root-Node] () > -> [TargetDiscovery] () > -> [desired] () > -> [logical] (Logical: noswap=False; nodump=False) > -> [rpool] (Zpool: name=rpool; action=create; is_root=True; vdev_list=[None]) > -> [vdev] (Vdev: name=vdev; redundancy=none) > -> [omnios] (BE: name=omnios; mountpoint=/a) > -> [volatile] (DataObjectCacheChild: volatile) > -> [apply_sysconfig_dict] () > -> [transfer-ti-files] () > 2017-02-18 22:38:26,313 InstallationLogger INFO Install Data: > Install Completed - False > Log Location - /system/volatile/install_log > Log Final - /var/log/install/install_log > No Install Mode - False > 2017-02-18 22:38:26,313 InstallationLogger ERROR Install failed > Traceback (most recent call last): > File "/usr/lib/python2.7/vendor-packages/solaris_install/text_install/__init__.py", line 421, in main > screen = screen.show() > File "/usr/lib/python2.7/vendor-packages/terminalui/base_screen.py", line 149, in show > self._show() > File "/usr/lib/python2.7/vendor-packages/solaris_install/text_install/disk_selection.py", line 399, in _show > self.disk_win.activate_object(self.selected_disk_index) > File "/usr/lib/python2.7/vendor-packages/terminalui/scroll_window.py", line 338, in activate_object > self.activate_object_force(index=index, loop=loop, force_to_top=jump) > File "/usr/lib/python2.7/vendor-packages/terminalui/scroll_window.py", line 352, in activate_object_force > jump=force_to_top) > File "/usr/lib/python2.7/vendor-packages/terminalui/inner_window.py", line 318, in activate_object > raise IndexError(err_msg) > IndexError: Index (0) out of range (0-0) > 2017-02-18 22:38:26,315 InstallationLogger INFO **** END > **** > > > format > ====== > > Searching for disks...done > > > AVAILABLE DISK SELECTIONS: > 0. c2d0 > /xpvd/xdf at 0 > Specify disk (enter its number): > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From johan.kragsterman at capvert.se Sun Feb 19 08:06:54 2017 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Sun, 19 Feb 2017 09:06:54 +0100 Subject: [OmniOS-discuss] updating to openssh in ipkg zone Message-ID: Hi! Something I don't understand here. I try to update an ipkg zone to openssh from sunssh The host has already been updated to openssh, and both zone and host are the same version: root at sshzone:/root# uname -v omnios-r151018-258cc99 I'm running the suggested pkg install from the wiki: pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server But what I get is this: root at sshzone:/root# pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh-server Creating Plan (Checking for conflicting actions): | pkg install: The following packages deliver conflicting action types to etc/ssh/moduli: link: pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20161230T210352Z file: pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151018:20170202T053308Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to etc/ssh/ssh_config: pkg://omnios/network/openssh at 7.4.1,5.11-0.151018:20170202T053251Z pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20161230T210352Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages deliver conflicting action types to usr/share/man/man4/sshd_config.4: link: pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20161230T210352Z file: pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151018:20170202T053308Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to lib/svc/method/sshd: pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20161230T210352Z pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151018:20170202T053308Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to etc/ssh/sshd_config: pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151018:20170202T053308Z pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20161230T210352Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages deliver conflicting action types to usr/share/man/man4/ssh_config.4: link: pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20161230T210352Z file: pkg://omnios/network/openssh at 7.4.1,5.11-0.151018:20170202T053251Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to lib/svc/manifest/network/ssh.xml: pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20161230T210352Z pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151018:20170202T053308Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. So, what am I doing wrong here...? Best regards from/Med v?nliga h?lsningar fr?n Johan Kragsterman Capvert From mtalbott at lji.org Mon Feb 20 02:13:59 2017 From: mtalbott at lji.org (Michael Talbott) Date: Sun, 19 Feb 2017 18:13:59 -0800 Subject: [OmniOS-discuss] MPT SAS Update Message-ID: I've been experiencing an error for some time that's been driving me bonkers. One of my servers (currently running r151020) has a JBOD enclosure with 84 x 8TB Seagate Archive drives. I now know we should've avoided those horribly slow drives but, the price was right and now I'm stuck with them. The problem is after about 30 minutes of very heavy reads on those disks (no writes at all), the system panics with the following backtrace: ffffff00f58e1920 genunix:vmem_hash_delete+9b () ffffff00f58e1980 genunix:vmem_xfree+4b () ffffff00f58e19b0 genunix:vmem_free+23 () ffffff00f58e1a00 genunix:rmfree+6e () ffffff00f58e1a30 mpt_sas:mptsas_pkt_destroy_extern+cf () ffffff00f58e1a60 mpt_sas:mptsas_scsi_destroy_pkt+75 () ffffff00f58e1a80 scsi:scsi_destroy_pkt+1a () ffffff00f58e1ad0 ses:ses_callback+c1 () ffffff00f58e1b00 mpt_sas:mptsas_pkt_comp+2b () ffffff00f58e1b50 mpt_sas:mptsas_doneq_empty+ae () ffffff00f58e1b90 mpt_sas:mptsas_intr+177 () ffffff00f58e1be0 apix:apix_dispatch_by_vector+8c () ffffff00f58e1c20 apix:apix_dispatch_lowlevel+25 () ffffff00f58999e0 unix:switch_sp_and_call+13 () ffffff00f5899a40 apix:apix_do_interrupt+387 () ffffff00f5899a50 unix:_interrupt+ba () ffffff00f5899bc0 unix:acpi_cpu_cstate+11b () ffffff00f5899bf0 unix:cpu_acpi_idle+8d () ffffff00f5899c00 unix:cpu_idle_adaptive+13 () ffffff00f5899c20 unix:idle+a7 () ffffff00f5899c30 unix:thread_start+8 () After some googling I found this which I thiiiink seems to have addressed the underlying issue: https://www.illumos.org/issues/5698 via this commit: https://github.com/illumos/illumos-gate/commit/2482ae1b96a558eec551575934d5f06c87b807af I'm not very familiar with the Illumos build system, so I was hoping someone could give me a pointer as to how I could just build this updated mpt_sas driver (can I just build it alone or do I have to build the entire system?). Of course if that pull could be released as an OmniOS update, that'd be even better ;) Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Feb 20 15:33:44 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 10:33:44 -0500 Subject: [OmniOS-discuss] updating to openssh in ipkg zone In-Reply-To: References: Message-ID: <0D0272FD-3929-4E9D-AF21-1D283A53023B@omniti.com> Silly question: Are your packages on this zone (even the ones you plan to get rid of) up to the latest versions? It sounds silly, but see what: pkg update -nv shows you first. If there's output, make sure you update the zone to latest things first, THEN try the update. BTW, I ran this test on an r151018 zone (albeit using the global zone and "pkg -R"), and did not fail: r151018(~)[0]% zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / ipkg shared - test1 installed /zones/test1 ipkg excl - test2 configured /zones/test2 ipkg excl r151018(~)[0]% sudo pkg -R /zones/test1/root list | grep ssh Password: network/ssh 0.5.11-0.151018 i-- network/ssh/ssh-key 0.5.11-0.151018 i-- service/network/ssh 0.5.11-0.151018 i-- service/network/ssh-common 0.5.11-0.151018 i-- r151018(~)[0]% sudo pkg -R /zones/test1/root install -nv --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server Packages to remove: 4 Packages to install: 2 Packages to update: 1 Mediators to change: 1 Services to change: 2 Estimated space available: 312.28 GB Estimated space to be consumed: 61.75 MB Rebuild boot archive: No Changed mediators: mediator ssh: implementation: sunssh (system default) -> None Changed packages: omnios network/ssh 0.5.11-0.151018:20161027T152706Z -> None network/ssh/ssh-key 0.5.11-0.151018:20161027T152706Z -> None service/network/ssh 0.5.11-0.151018:20161027T152708Z -> None service/network/ssh-common 0.5.11-0.151018:20161027T152708Z -> None network/openssh None -> 7.4.1-0.151018:20170202T053251Z network/openssh-server None -> 7.4.1-0.151018:20170202T053308Z library/security/openssl 1.0.2.10-0.151018:20160926T143231Z -> 1.0.2.11-0.151018:20170126T161901Z Services: restart_fmri: svc:/network/ssh:default svc:/system/manifest-import:default r151018(~)[0]% sudo pkg -R /zones/test1/root install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server Packages to remove: 4 Packages to install: 2 Packages to update: 1 Mediators to change: 1 Services to change: 2 DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 7/7 427/427 9.2/9.2 1.9M/s PHASE ITEMS Removing old actions 140/140 Installing new actions 74/74 Updating modified actions 397/397 Updating package state database Done Updating package cache 5/5 Updating image state Done Creating fast lookup database Done r151018(~)[0]% Dan From danmcd at omniti.com Mon Feb 20 15:51:18 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 10:51:18 -0500 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: References: Message-ID: > On Feb 19, 2017, at 9:13 PM, Michael Talbott wrote: > > > After some googling I found this which I thiiiink seems to have addressed the underlying issue: > https://www.illumos.org/issues/5698 > via this commit: > https://github.com/illumos/illumos-gate/commit/2482ae1b96a558eec551575934d5f06c87b807af Very recently pushed into illumos (January 30th). > I'm not very familiar with the Illumos build system, so I was hoping someone could give me a pointer as to how I could just build this updated mpt_sas driver (can I just build it alone or do I have to build the entire system?). You'd clone illumos-omnios, to the branch of your release (r151020), patch it with the commit ("git cherry-pick 2482ae1b96a558eec551575934d5f06c87b807af" is your friend here), and run /opt/onbld/bin/nightly using a copy of /opt/onbld/env/omnios-illumos-omnios with paths pointing at your clone. Once built, you'd replace (in a separate boot environment for safety) /kernel/drv/amd64/mpt_sas with the new mpt_sas in .../usr/src/uts/intel/mpt_sas/obj64/mpt_sas. > Of course if that pull could be released as an OmniOS update, that'd be even better ;) This one is probably a good backport candidate. Given our next release is our next LTS, however, I'm not sure I'll be backporting it to r151014. I did notice that this commit is the only change between r151020 and current bloody. Would you like to volunteer to test this change being backported into r151020? I can build you a replacement mpt_sas module relatively quickly. Dan From mir at miras.org Mon Feb 20 16:17:42 2017 From: mir at miras.org (Michael Rasmussen) Date: Mon, 20 Feb 2017 17:17:42 +0100 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: References: Message-ID: <20170220171742.67f665b5@sleipner.datanom.net> On Mon, 20 Feb 2017 10:51:18 -0500 Dan McDonald wrote: > > This one is probably a good backport candidate. Given our next release is our next LTS, however, I'm not sure I'll be backporting it to r151014. > That is sad given that r151014 is still supported 1 year after the release of the next LTS and the possible repercussions of avoid doing this. -- 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 danmcd at omniti.com Mon Feb 20 16:22:54 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 11:22:54 -0500 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: <20170220171742.67f665b5@sleipner.datanom.net> References: <20170220171742.67f665b5@sleipner.datanom.net> Message-ID: <44AC1854-BD5F-42E8-A4A7-77048BBF9B6E@omniti.com> > On Feb 20, 2017, at 11:17 AM, Michael Rasmussen wrote: > > On Mon, 20 Feb 2017 10:51:18 -0500 > Dan McDonald wrote: > >> >> This one is probably a good backport candidate. Given our next release is our next LTS, however, I'm not sure I'll be backporting it to r151014. >> > That is sad given that r151014 is still supported 1 year after the > release of the next LTS and the possible repercussions of avoid doing > this. I didn't say I wouldn't, I just said I wasn't sure. Also, doing these device-driver updates causes systems to reboot, which some of our LTS users really don't like doing. Regardless, as we get feedback from any 020 testing, we can make the call then. Dan From mir at miras.org Mon Feb 20 16:25:46 2017 From: mir at miras.org (Michael Rasmussen) Date: Mon, 20 Feb 2017 17:25:46 +0100 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: <44AC1854-BD5F-42E8-A4A7-77048BBF9B6E@omniti.com> References: <20170220171742.67f665b5@sleipner.datanom.net> <44AC1854-BD5F-42E8-A4A7-77048BBF9B6E@omniti.com> Message-ID: <20170220172546.1f4ae4d0@sleipner.datanom.net> On Mon, 20 Feb 2017 11:22:54 -0500 Dan McDonald wrote: > I didn't say I wouldn't, I just said I wasn't sure. I misunderstood you. Sorry. > > Also, doing these device-driver updates causes systems to reboot, which some of our LTS users really don't like doing. > If these LTS users are hit by the bug they will at least need to do a reboot anyway;-) -- 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: Forgetfulness, n.: A gift of God bestowed upon debtors in compensation for their destitution of conscience. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From johan.kragsterman at capvert.se Mon Feb 20 16:50:00 2017 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 20 Feb 2017 17:50:00 +0100 Subject: [OmniOS-discuss] Ang: Re: updating to openssh in ipkg zone In-Reply-To: <0D0272FD-3929-4E9D-AF21-1D283A53023B@omniti.com> References: <0D0272FD-3929-4E9D-AF21-1D283A53023B@omniti.com>, Message-ID: Hi! Now it worked, and what was wrong was the string I copied from the wiki. It says this: pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server and the one that worked(Dan's) is this: pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server So, somneone needs to change the wiki. Best regards from/Med v?nliga h?lsningar fr?n Johan Kragsterman Capvert -----Dan McDonald skrev: ----- Till: Johan Kragsterman Fr?n: Dan McDonald Datum: 2017-02-20 16:33 Kopia: omnios-discuss , Dan McDonald ?rende: Re: [OmniOS-discuss] updating to openssh in ipkg zone Silly question: Are your packages on this zone (even the ones you plan to get rid of) up to the latest versions? It sounds silly, but see what: pkg update -nv shows you first. If there's output, make sure you update the zone to latest things first, THEN try the update. BTW, I ran this test on an r151018 zone (albeit using the global zone and "pkg -R"), and did not fail: r151018(~)[0]% zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / ipkg shared - test1 installed /zones/test1 ipkg excl - test2 configured /zones/test2 ipkg excl r151018(~)[0]% sudo pkg -R /zones/test1/root list | grep ssh Password: network/ssh 0.5.11-0.151018 i-- network/ssh/ssh-key 0.5.11-0.151018 i-- service/network/ssh 0.5.11-0.151018 i-- service/network/ssh-common 0.5.11-0.151018 i-- r151018(~)[0]% sudo pkg -R /zones/test1/root install -nv --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server Packages to remove: 4 Packages to install: 2 Packages to update: 1 Mediators to change: 1 Services to change: 2 Estimated space available: 312.28 GB Estimated space to be consumed: 61.75 MB Rebuild boot archive: No Changed mediators: mediator ssh: implementation: sunssh (system default) -> None Changed packages: omnios network/ssh 0.5.11-0.151018:20161027T152706Z -> None network/ssh/ssh-key 0.5.11-0.151018:20161027T152706Z -> None service/network/ssh 0.5.11-0.151018:20161027T152708Z -> None service/network/ssh-common 0.5.11-0.151018:20161027T152708Z -> None network/openssh None -> 7.4.1-0.151018:20170202T053251Z network/openssh-server None -> 7.4.1-0.151018:20170202T053308Z library/security/openssl 1.0.2.10-0.151018:20160926T143231Z -> 1.0.2.11-0.151018:20170126T161901Z Services: restart_fmri: svc:/network/ssh:default svc:/system/manifest-import:default r151018(~)[0]% sudo pkg -R /zones/test1/root install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server Packages to remove: 4 Packages to install: 2 Packages to update: 1 Mediators to change: 1 Services to change: 2 DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 7/7 427/427 9.2/9.2 1.9M/s PHASE ITEMS Removing old actions 140/140 Installing new actions 74/74 Updating modified actions 397/397 Updating package state database Done Updating package cache 5/5 Updating image state Done Creating fast lookup database Done r151018(~)[0]% Dan From danmcd at omniti.com Mon Feb 20 16:54:42 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 11:54:42 -0500 Subject: [OmniOS-discuss] Ang: Re: updating to openssh in ipkg zone In-Reply-To: References: <0D0272FD-3929-4E9D-AF21-1D283A53023B@omniti.com> Message-ID: > On Feb 20, 2017, at 11:50 AM, Johan Kragsterman wrote: > > and the one that worked(Dan's) is this: > > > pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server That works for 016 and 018. If you're on an r151014 box, you need to use the one on the wiki. Sorry about the confusion, Dan From johan.kragsterman at capvert.se Mon Feb 20 17:15:36 2017 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 20 Feb 2017 18:15:36 +0100 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: updating to openssh in ipkg zone In-Reply-To: References: , <0D0272FD-3929-4E9D-AF21-1D283A53023B@omniti.com> Message-ID: Hi! -----Dan McDonald skrev: ----- Till: Johan Kragsterman Fr?n: Dan McDonald Datum: 2017-02-20 17:54 Kopia: omnios-discuss , Dan McDonald ?rende: Re: Ang: Re: [OmniOS-discuss] updating to openssh in ipkg zone > On Feb 20, 2017, at 11:50 AM, Johan Kragsterman wrote: > > and the one that worked(Dan's) is this: > > > pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server That works for 016 and 018. If you're on an r151014 box, you need to use the one on the wiki. Sorry about the confusion, Dan Yeah, thanks, Dan, but the wrong one is on the release notes of 016, and I took it wrongly from there, since I now see the right one is on the release notes for 018... /Johan From danmcd at omniti.com Mon Feb 20 17:17:47 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 12:17:47 -0500 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: updating to openssh in ipkg zone In-Reply-To: References: <0D0272FD-3929-4E9D-AF21-1D283A53023B@omniti.com> Message-ID: <96980531-895C-4C8D-9F76-481C923F1318@omniti.com> > On Feb 20, 2017, at 12:15 PM, Johan Kragsterman wrote: > > Yeah, thanks, Dan, but the wrong one is on the release notes of 016, and I took it wrongly from there, since I now see the right one is on the release notes for 018... Phew! Okay, we did get that right then. Thank you, though, because LTS folks who are going to make the jump from 014 to 022 will need to be instructed to follow the "switch to OpenSSH" from the 014 release notes (same for 016 or 018). Thank you! Dan From mailinglists at qutic.com Mon Feb 20 18:11:38 2017 From: mailinglists at qutic.com (qutic development) Date: Mon, 20 Feb 2017 19:11:38 +0100 Subject: [OmniOS-discuss] No boot after pkg update Message-ID: <5C45BEF9-B67D-4BD7-A309-EA6FF55D704A@qutic.com> Hi List, after a pkg update to get the latest r151014 changes (which required a reboot) the supermicro server failed to boot with error [1]: failed to get ramdisk from boot Next I tried to boot from an older BEs. This failed too, but with another error [2]: null path krtld: failed to open '' Now I tried to create a new boot-archive with the help of an r151014 live-cd [3]: zpool import -f rpool beadm mount my_be /a mv /a/platform/i86pc/boot_archive /a/platform/i86pc/boot_archive.bak mv /a/platform/i86pc/amd64/boot_archive /a/platform/i86pc/amd64/boot_archive.bak bootadm update-archive -v -R /a zpool export -f rpool init 6 But the boot failed with the same error [2]: null path krtld: failed to open '' Does anyone has an idea how to fix this? Best regards Stefan Screenshots of all errors could be found here: [1] https://owncloud-002.qutic.com/index.php/s/dDODdEXmS1ebWwC [2] https://owncloud-002.qutic.com/index.php/s/Oy2YfKyZcgfFhcl [3] https://owncloud-002.qutic.com/index.php/s/4z2j5Od6s5YtxbG From mir at miras.org Mon Feb 20 18:24:47 2017 From: mir at miras.org (Michael Rasmussen) Date: Mon, 20 Feb 2017 19:24:47 +0100 Subject: [OmniOS-discuss] No boot after pkg update In-Reply-To: <5C45BEF9-B67D-4BD7-A309-EA6FF55D704A@qutic.com> References: <5C45BEF9-B67D-4BD7-A309-EA6FF55D704A@qutic.com> Message-ID: <20170220192447.46f5e037@sleipner.datanom.net> On Mon, 20 Feb 2017 19:11:38 +0100 qutic development wrote: > > Does anyone has an idea how to fix this? > How many boot environments do you have on this server? There is an upper limit which I cannot recall but it is somewhere in between 20 to 30 BE's. -- 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: Do not clog intellect's sluices with bits of knowledge of questionable uses. -------------- 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 Mon Feb 20 18:37:28 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 13:37:28 -0500 Subject: [OmniOS-discuss] No boot after pkg update In-Reply-To: <20170220192447.46f5e037@sleipner.datanom.net> References: <5C45BEF9-B67D-4BD7-A309-EA6FF55D704A@qutic.com> <20170220192447.46f5e037@sleipner.datanom.net> Message-ID: <6CAE8DB1-9071-4C99-A3AE-71D6926DA010@omniti.com> > On Feb 20, 2017, at 1:24 PM, Michael Rasmussen wrote: > > How many boot environments do you have on this server? > There is an upper limit which I cannot recall but it is somewhere in > between 20 to 30 BE's. Use this page to help you get out of your jam, if it's too-many-BEs: http://omnios.omniti.com/wiki.php/GrubTooManyBEs BTW, starting with r151022, this problem will be a thing of the past, thanks to BSD Loader. The only downside, however, is that any OLD GRUB BEs will not be able to be QUITE as functional. Dan From mtalbott at lji.org Mon Feb 20 18:39:43 2017 From: mtalbott at lji.org (Michael Talbott) Date: Mon, 20 Feb 2017 10:39:43 -0800 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: References: Message-ID: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> Sure. I'd love to volunteer to give it a go and report back what happens. Thankfully this particular server is just a replica server so a few reboots is no problem for me in this case. Michael Sent from my iPhone > On Feb 20, 2017, at 7:51 AM, Dan McDonald wrote: > > quickly. From danmcd at omniti.com Mon Feb 20 18:46:17 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 13:46:17 -0500 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> Message-ID: <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> > On Feb 20, 2017, at 1:39 PM, Michael Talbott wrote: > > Sure. I'd love to volunteer to give it a go and report back what happens. Thankfully this particular server is just a replica server so a few reboots is no problem for me in this case. I'll take this off-list from here. Thank you Michael! Dan From danmcd at omniti.com Mon Feb 20 22:28:57 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 17:28:57 -0500 Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 Message-ID: EXECUTIVE SUMMARY: As it stands, pkg(5) in bloody changes behavior from 014-020 to something different. It also fixes a shortcoming in 014-020. Do we go completely with the new behavior and document it? Or do we minimize least-surprise at the risk of introducing bugs? I'm leaning toward the second choice, modulo my pkg5 test suite experiences. Opinions, esp. from LTS folks, needed. . . . . . . . . I updated pkg5 during this bloody to handle Python2.7. That worked all well and good, but had a side-effect I didn't see (and neither did a lot of bloody users, apparently). So here's what happens today, on 014-020 pkg(5) for global zone invocations: pkg update - Updates on global zone. No others, REGARDLESS of linked-image or not. pkg update - Update all pkgs on global zone AND on any linked-image zones. Starting with the Python2.7 integration, this behavior changed: pkg update - Same as before pkg update - Only updates global zone, and linked-image "If needs sync", where "needs sync" is not well defined (may need a property inside a package itself). pkg update -r - Updates on global zone AND on linked-image zones. pkg update -r - Behaves like "pkg update" on 014-020, updates all pkgs on global and linked-image zones. The "-r" as an option - and you can specify zones with -z or zones to exclude with -Z - is new from Oracle with the wad of updates OpenIndiana pulled in to get Python2.7 support. And I quote from the pkg(1) man page you can see on bloody today: -r Run this operation in the global zone and also in all installed solaris branded non-global zones. The effect on the non-global zone is similar to logging into each non-global zone and running the command directly. Without this option, when you run pkg commands in the global zone, non-global zones are modified only to the extent required to keep them compatible with the global zone. With this option, the pkg operation is applied to all installed non-global zones except as limited by the -z and -Z options. Zones that are excluded by the -z and -Z options might still be modified if updates are required to keep them in sync with the global zone. Because of the least-suprise violation of new "pkg update" behavior, I'm wondering if we should make "-r" implicit. I'm working right now on an implicit "-r" solution, but am running into some problems with the pkg5 test suite I still need to sort out. Thanks! Dan From jesus at omniti.com Mon Feb 20 22:37:56 2017 From: jesus at omniti.com (Theo Schlossnagle) Date: Mon, 20 Feb 2017 17:37:56 -0500 Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: References: Message-ID: New behavior seems much more intuitive and self-consistent. IMHO in with the new and out with the old. On Mon, Feb 20, 2017 at 5:28 PM, Dan McDonald wrote: > EXECUTIVE SUMMARY: As it stands, pkg(5) in bloody changes behavior from > 014-020 to something different. It also fixes a shortcoming in 014-020. Do > we go completely with the new behavior and document it? Or do we minimize > least-surprise at the risk of introducing bugs? I'm leaning toward the > second choice, modulo my pkg5 test suite experiences. Opinions, esp. from > LTS folks, needed. > > . . . . . . . . > > I updated pkg5 during this bloody to handle Python2.7. That worked all > well and good, but had a side-effect I didn't see (and neither did a lot of > bloody users, apparently). > > So here's what happens today, on 014-020 pkg(5) for global zone > invocations: > > pkg update > - Updates on global zone. No others, REGARDLESS of linked-image or > not. > > pkg update > - Update all pkgs on global zone AND on any linked-image zones. > > > Starting with the Python2.7 integration, this behavior changed: > > pkg update > - Same as before > > pkg update > - Only updates global zone, and linked-image "If needs sync", where "needs > sync" is not well defined (may need a property inside a package itself). > > pkg update -r > - Updates on global zone AND on linked-image zones. > > pkg update -r > - Behaves like "pkg update" on 014-020, updates all pkgs on global and > linked-image zones. > > > > The "-r" as an option - and you can specify zones with -z or zones to > exclude with -Z - is new from Oracle with the wad of updates OpenIndiana > pulled in to get Python2.7 support. And I quote from the pkg(1) man page > you can see on bloody today: > > -r > > Run this operation in the global zone and also in all > installed > solaris branded non-global zones. The effect on the > non-global > zone is similar to logging into each non-global zone and > running the command directly. Without this option, when you > run > pkg commands in the global zone, non-global zones are > modified > only to the extent required to keep them compatible with the > global zone. With this option, the pkg operation is applied > to > all installed non-global zones except as limited by the -z > and > -Z options. Zones that are excluded by the -z and -Z options > might still be modified if updates are required to keep them > in > sync with the global zone. > > Because of the least-suprise violation of new "pkg update" behavior, I'm > wondering if we should make "-r" implicit. I'm working right now on an > implicit "-r" solution, but am running into some problems with the pkg5 > test suite I still need to sort out. > > Thanks! > Dan > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfriesen at simple.dallas.tx.us Mon Feb 20 22:46:14 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 20 Feb 2017 16:46:14 -0600 (CST) Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: References: Message-ID: On Mon, 20 Feb 2017, Dan McDonald wrote: > > Because of the least-suprise violation of new "pkg update" behavior, > I'm wondering if we should make "-r" implicit. I'm working right > now on an implicit "-r" solution, but am running into some problems > with the pkg5 test suite I still need to sort out. I like the new behavior because it provides an option which previously did not exist. It would be cleaner if 'update' also used -r. The documentation says that the linked zones are updated as required such that they still 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 Mon Feb 20 23:01:28 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 18:01:28 -0500 Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: References: Message-ID: <4046678E-CF50-41A0-BBC1-FAFA4F10C86B@omniti.com> > On Feb 20, 2017, at 5:37 PM, Theo Schlossnagle wrote: > > New behavior seems much more intuitive and self-consistent. IMHO in with the new and out with the old. Just so we're clear: You do NOT want "implicit -r" and are okay with the behavior change for "pkg update" that accompanies it. Correct? I should also point out -- "ipkg" zones are not affected by any of this. They stay dumb and non-linked. Dan From danmcd at omniti.com Mon Feb 20 23:03:45 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 18:03:45 -0500 Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: References: Message-ID: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> Also, the "-r" flag will be required for "update", "install", "uninstall", "change-facet", and "change-variant" subcommands as well. Right now, it appears we have two votes for "just accept -r and don't worry about making it implicit." Again, the two choices are: a.) Accept "-r" as a requirement, and document to users that the behavior between 014-020 and 022-beyond will change. b.) Make "-r" implicit, and make required changes to be less-surprising for existing 014-020 users. Thanks, Dan From bfriesen at simple.dallas.tx.us Mon Feb 20 23:17:17 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 20 Feb 2017 17:17:17 -0600 (CST) Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> References: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> Message-ID: On Mon, 20 Feb 2017, Dan McDonald wrote: > Also, the "-r" flag will be required for "update", "install", > "uninstall", "change-facet", and "change-variant" subcommands as > well. This is better than I understood since it is consistent. Copious documentation and alerts would be required. If someone forgets to use -r the first time around, can the same command be invoked again with the -r and then the zones get the updates as well? 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 Mon Feb 20 23:20:13 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Feb 2017 18:20:13 -0500 Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: References: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> Message-ID: <2EE1453A-48C3-40CB-B9FF-6C7E5E0A6EB8@omniti.com> > On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn wrote: > > If someone forgets to use -r the first time around, can the same command be invoked again with the -r and then the zones get the updates as well? Yes. The pkg5 test suite explicitly covers that, so I know it works. Dan From bfriesen at simple.dallas.tx.us Tue Feb 21 02:24:58 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 20 Feb 2017 20:24:58 -0600 (CST) Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: <2EE1453A-48C3-40CB-B9FF-6C7E5E0A6EB8@omniti.com> References: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> <2EE1453A-48C3-40CB-B9FF-6C7E5E0A6EB8@omniti.com> Message-ID: On Mon, 20 Feb 2017, Dan McDonald wrote: > >> On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn wrote: >> >> If someone forgets to use -r the first time around, can the same command be invoked again with the -r and then the zones get the updates as well? > > Yes. The pkg5 test suite explicitly covers that, so I know it works. This is very useful. Often the zones are located outside of the root pool. After updating just the root pool and seeing that it is working well, then the zones can be updated. This reduces the chance of problems when updating the zones. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From jaakko.linnosaari at polarshift.fi Tue Feb 21 04:48:57 2017 From: jaakko.linnosaari at polarshift.fi (Jaakko Linnosaari) Date: Tue, 21 Feb 2017 06:48:57 +0200 Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> References: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> Message-ID: > On 2017-02-21, at 1.03, Dan McDonald wrote: > > a.) Accept "-r" as a requirement, and document to users that the behavior between 014-020 and 022-beyond will change. I?m in favour of this change. It?s consistent and suits better with our usage patterns. Thanks, ? Jaakko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimklimov at cos.ru Tue Feb 21 06:38:02 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Tue, 21 Feb 2017 07:38:02 +0100 Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: References: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> <2EE1453A-48C3-40CB-B9FF-6C7E5E0A6EB8@omniti.com> Message-ID: 21 ??????? 2017??. 3:24:58 CET, Bob Friesenhahn ?????: >On Mon, 20 Feb 2017, Dan McDonald wrote: > >> >>> On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn > wrote: >>> >>> If someone forgets to use -r the first time around, can the same >command be invoked again with the -r and then the zones get the updates >as well? >> >> Yes. The pkg5 test suite explicitly covers that, so I know it works. > >This is very useful. Often the zones are located outside of the root >pool. After updating just the root pool and seeing that it is working >well, then the zones can be updated. This reduces the chance of >problems when updating the zones. > >Bob I'm in favor of keeping options consistent across the ecosystem, so scripts and habits are portable going forward. So '-r' behavior and option should be explicit as a new addition. It does make sense to add a run-time warning for the old usecase(s) which changed behavior - like "This command used to implicitly recurse into local zones, now you must specify -r to get that behavior." - and that should serve to recover the least surprise approach. Also mark this in release notes for people upgrading from older non-bloody releases (there's a chapter for deprecations and big changes, right?) and you're golden. Jim -- Typos courtesy of K-9 Mail on my Samsung Android From omnios at citrus-it.net Tue Feb 21 10:29:08 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Tue, 21 Feb 2017 10:29:08 +0000 (UTC) Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> References: <130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com> Message-ID: On Mon, 20 Feb 2017, Dan McDonald wrote: ; a.) Accept "-r" as a requirement, and document to users that the behavior between 014-020 and 022-beyond will change. This one gets my vote. It will actually improve our workflow 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 lkateley at kateley.com Tue Feb 21 15:57:42 2017 From: lkateley at kateley.com (Linda Kateley) Date: Tue, 21 Feb 2017 09:57:42 -0600 Subject: [OmniOS-discuss] panic in virtual box Message-ID: <9ef85ad6-ce14-809f-9bc9-6f06856de1c2@kateley.com> Has anyone run into omnios panicing in virtualbox? I have been working on a video series of napp-it and when I put them all together(omni and napp-it) on my big mac(running el cap) I get a day or 2 in, and panic. I seem to be able to run it on 16 or 18 without updates easily but when I run update bloosh.. I can run the same vm(export/import) on my little mac running sierra without error. just wondering if i am missing something simple. Linda From daleg at omniti.com Tue Feb 21 16:04:04 2017 From: daleg at omniti.com (Dale Ghent) Date: Tue, 21 Feb 2017 11:04:04 -0500 Subject: [OmniOS-discuss] panic in virtual box In-Reply-To: <9ef85ad6-ce14-809f-9bc9-6f06856de1c2@kateley.com> References: <9ef85ad6-ce14-809f-9bc9-6f06856de1c2@kateley.com> Message-ID: <7DA555B8-30DE-4772-9D8B-15AB75BC3F19@omniti.com> This is not normal. Do you have a crash dump available, or at least a panic string? /dale > On Feb 21, 2017, at 10:57 AM, Linda Kateley wrote: > > Has anyone run into omnios panicing in virtualbox? > > I have been working on a video series of napp-it and when I put them all together(omni and napp-it) on my big mac(running el cap) I get a day or 2 in, and panic. I seem to be able to run it on 16 or 18 without updates easily but when I run update bloosh.. I can run the same vm(export/import) on my little mac running sierra without error. > > just wondering if i am missing something simple. > > > Linda > > _______________________________________________ > 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 lkateley at kateley.com Tue Feb 21 16:47:04 2017 From: lkateley at kateley.com (Linda Kateley) Date: Tue, 21 Feb 2017 10:47:04 -0600 Subject: [OmniOS-discuss] panic in virtual box In-Reply-To: <7DA555B8-30DE-4772-9D8B-15AB75BC3F19@omniti.com> References: <9ef85ad6-ce14-809f-9bc9-6f06856de1c2@kateley.com> <7DA555B8-30DE-4772-9D8B-15AB75BC3F19@omniti.com> Message-ID: I can poke around to find one or recreate. thx Linda On 2/21/17 10:04 AM, Dale Ghent wrote: > This is not normal. Do you have a crash dump available, or at least a panic string? > > /dale > >> On Feb 21, 2017, at 10:57 AM, Linda Kateley wrote: >> >> Has anyone run into omnios panicing in virtualbox? >> >> I have been working on a video series of napp-it and when I put them all together(omni and napp-it) on my big mac(running el cap) I get a day or 2 in, and panic. I seem to be able to run it on 16 or 18 without updates easily but when I run update bloosh.. I can run the same vm(export/import) on my little mac running sierra without error. >> >> just wondering if i am missing something simple. >> >> >> Linda >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss From mtalbott at lji.org Tue Feb 21 21:19:49 2017 From: mtalbott at lji.org (Michael Talbott) Date: Tue, 21 Feb 2017 13:19:49 -0800 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> Message-ID: Dan, the updated driver that you provided did fix the issue I was experiencing. I've been running the same task that would normally panic the system within 30 min for almost 24 hours now and not a single panic and still running strong. Thanks a million! Michael > On Feb 20, 2017, at 10:46 AM, Dan McDonald wrote: > > >> On Feb 20, 2017, at 1:39 PM, Michael Talbott wrote: >> >> Sure. I'd love to volunteer to give it a go and report back what happens. Thankfully this particular server is just a replica server so a few reboots is no problem for me in this case. > > I'll take this off-list from here. Thank you Michael! > > Dan > From danmcd at omniti.com Tue Feb 21 22:01:42 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 21 Feb 2017 17:01:42 -0500 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> Message-ID: <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> Great. I'll make sure this gets back into at least 020, and hopefully it'll easily drop into 014 as well. Dan Sent from my iPhone (typos, autocorrect, and all) > On Feb 21, 2017, at 4:19 PM, Michael Talbott wrote: > > Dan, the updated driver that you provided did fix the issue I was experiencing. I've been running the same task that would normally panic the system within 30 min for almost 24 hours now and not a single panic and still running strong. > > Thanks a million! > > Michael > > >> On Feb 20, 2017, at 10:46 AM, Dan McDonald wrote: >> >> >>> On Feb 20, 2017, at 1:39 PM, Michael Talbott wrote: >>> >>> Sure. I'd love to volunteer to give it a go and report back what happens. Thankfully this particular server is just a replica server so a few reboots is no problem for me in this case. >> >> I'll take this off-list from here. Thank you Michael! >> >> Dan >> > From phil.harman at gmail.com Wed Feb 22 08:36:04 2017 From: phil.harman at gmail.com (Phil Harman) Date: Wed, 22 Feb 2017 08:36:04 +0000 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> Message-ID: This is all very good news. It would also be good to know what mpt_sas firmware is recommended with different illumos releases (an issue on other OSes too). Ideally, I'd like to see a table of releases with min and max versions. Thanks, Phil > On 21 Feb 2017, at 22:01, Dan McDonald wrote: > > Great. I'll make sure this gets back into at least 020, and hopefully it'll easily drop into 014 as well. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > >> On Feb 21, 2017, at 4:19 PM, Michael Talbott wrote: >> >> Dan, the updated driver that you provided did fix the issue I was experiencing. I've been running the same task that would normally panic the system within 30 min for almost 24 hours now and not a single panic and still running strong. >> >> Thanks a million! >> >> Michael >> >> >>> On Feb 20, 2017, at 10:46 AM, Dan McDonald wrote: >>> >>> >>>> On Feb 20, 2017, at 1:39 PM, Michael Talbott wrote: >>>> >>>> Sure. I'd love to volunteer to give it a go and report back what happens. Thankfully this particular server is just a replica server so a few reboots is no problem for me in this case. >>> >>> I'll take this off-list from here. Thank you Michael! >>> >>> Dan >>> >> > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From daniil.landau at gmail.com Wed Feb 22 10:15:35 2017 From: daniil.landau at gmail.com (Daniil V. Landau) Date: Wed, 22 Feb 2017 13:15:35 +0300 Subject: [OmniOS-discuss] OmniOS on H110 Message-ID: Hi! I'm trying to upgrade my home OmniOS server with ASUS H110I-Plus motherboard. Already understood that it was not a best choice, but still trying. Are there any information or experience concerning Illumos/OmniOS compatibility with Intel H110 chipset? At this time I try to boot this system with install OmniOS media (USB and SATA-attached CD). Every time I try to boot the system freezes after kernel header appeared. If I boot the kernel with -v option I see that kernel freezes after the following message: root on /ramdisk:a fstype ufs What could be the cause of this problem? And one more question: what miniITX motherboard could be recommended for OmniOS? Any help will be appreciated! Thank you! Daniil -------------- next part -------------- An HTML attachment was scrubbed... URL: From alka at hfg-gmuend.de Wed Feb 22 10:42:07 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Wed, 22 Feb 2017 11:42:07 +0100 Subject: [OmniOS-discuss] OmniOS on H110 In-Reply-To: References: Message-ID: <4a7f3c3d-9210-fe80-5079-f5b7aa210c34@hfg-gmuend.de> A good ITX choice for a ZFS NAS with ECC RAM may be from Asrock http://www.asrockrack.com/general/productdetail.asp?Model=E3C236D2I#Specifications or something from SuperMicro ex wih 10G https://www.supermicro.nl/products/motherboard/Xeon/D/X10SDV-4C-TLN2F.cfm btw Have you tried booting from the Sata CD/DVD drive (Sata=AHCI mode). I have had problems booting from USB on newer mainboards Gea Am 22.02.2017 um 11:15 schrieb Daniil V. Landau: > And one more question: what miniITX motherboard could be recommended > for OmniOS? From daniil.landau at gmail.com Wed Feb 22 12:32:40 2017 From: daniil.landau at gmail.com (=?utf-8?B?0JTQsNC90LjQuNC7INCb0LDQvdC00LDRgw==?=) Date: Wed, 22 Feb 2017 15:32:40 +0300 Subject: [OmniOS-discuss] OmniOS on H110 Message-ID: Guenther, thank you for the recommendations! And yes, I?ve tried to boot from SATA-attached CD-ROM using both current stable and LTS versions with the same result. Daniil -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Feb 22 14:59:49 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Feb 2017 09:59:49 -0500 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> Message-ID: <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> > On Feb 22, 2017, at 3:36 AM, Phil Harman wrote: > > This is all very good news. It would also be good to know what mpt_sas firmware is recommended with different illumos releases (an issue on other OSes too). You should ping the greater illumos lists on that topic. More expertise there. Dan From danmcd at omniti.com Wed Feb 22 15:22:29 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Feb 2017 10:22:29 -0500 Subject: [OmniOS-discuss] cURL 7.53.0 is out Message-ID: <9715CC0F-AC28-4193-8096-5DD90FFAEA3A@omniti.com> Please "pkg update" your supported or bloody OmniOS so you get the latest version of curl. Thank you! Dan From peter.tribble at gmail.com Wed Feb 22 16:35:06 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Wed, 22 Feb 2017 16:35:06 +0000 Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: References: Message-ID: On Mon, Feb 20, 2017 at 10:28 PM, Dan McDonald wrote: > EXECUTIVE SUMMARY: As it stands, pkg(5) in bloody changes behavior from > 014-020 to something different. It also fixes a shortcoming in 014-020. Do > we go completely with the new behavior and document it? Or do we minimize > least-surprise at the risk of introducing bugs? I'm leaning toward the > second choice, modulo my pkg5 test suite experiences. Opinions, esp. from > LTS folks, needed. > > . . . . . . . . > > I updated pkg5 during this bloody to handle Python2.7. That worked all > well and good, but had a side-effect I didn't see (and neither did a lot of > bloody users, apparently). > > So here's what happens today, on 014-020 pkg(5) for global zone > invocations: > > pkg update > - Updates on global zone. No others, REGARDLESS of linked-image or > not. > That behaviour initially surprised me, but once you understand that all it's doing in the linked zone is ensuring package compatibility then it makes sense - the currently installed version of the package clearly has to be compatible (else it couldn't be present) so there's no need to update it. > pkg update > - Update all pkgs on global zone AND on any linked-image zones. > > > Starting with the Python2.7 integration, this behavior changed: > > pkg update > - Same as before > > pkg update > - Only updates global zone, and linked-image "If needs sync", where "needs > sync" is not well defined (may need a property inside a package itself). > That sounds like there's a bug somewhere. If you update the OS in the global zone, with a change that breaks kernel<->libc compatibility, will libc get updated in an lipkg zone? The answer has to be yes, clearly. IPS relies heavily on package constraints, so if that's not happening then either pkg(5) is broken or package versions aren't adequately constrained, I guess. > pkg update -r > - Updates on global zone AND on linked-image zones. > > pkg update -r > - Behaves like "pkg update" on 014-020, updates all pkgs on global and > linked-image zones. > > > > The "-r" as an option - and you can specify zones with -z or zones to > exclude with -Z - is new from Oracle with the wad of updates OpenIndiana > pulled in to get Python2.7 support. And I quote from the pkg(1) man page > you can see on bloody today: > > -r > > Run this operation in the global zone and also in all > installed > solaris branded non-global zones. The effect on the > non-global > zone is similar to logging into each non-global zone and > running the command directly. Without this option, when you > run > pkg commands in the global zone, non-global zones are > modified > only to the extent required to keep them compatible with the > global zone. With this option, the pkg operation is applied > to > all installed non-global zones except as limited by the -z > and > -Z options. Zones that are excluded by the -z and -Z options > might still be modified if updates are required to keep them > in > sync with the global zone. > > Because of the least-suprise violation of new "pkg update" behavior, I'm > wondering if we should make "-r" implicit. I'm working right now on an > implicit "-r" solution, but am running into some problems with the pkg5 > test suite I still need to sort out. > FWIW, when updating a single package I have a script that effectively does -r by doing a zlogin into each zone. So 'pkg update -r' is a good thing. I'm not sure I would make -r the default. Apart from the existence of cases where you explicitly *don't* want to update zones, it makes you incompatible wit the rest of the IPS world. However, the fact that a bare 'pkg update' could lead to broken linked zones does concern me, and I suspect that you're going to have to look at whether you need to tighten up package and incorporate dependencies. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at will.to Wed Feb 22 16:55:25 2017 From: doug at will.to (Doug Hughes) Date: Wed, 22 Feb 2017 11:55:25 -0500 Subject: [OmniOS-discuss] ugrading r16 to r20 In-Reply-To: <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> Message-ID: <2b787934-762e-d8cb-238e-31a9dad81271@will.to> I'm very delayed in this but had an opportunity to tackle the ugprade. Unfortunately the prerequesite stage of upgrade to openssh is failing: # /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server Creating Plan (Solver setup): / pkg install: No matching version of network/openssh can be installed: Reject: pkg://omnios/network/openssh at 7.2.2,5.11-0.151020:20161102T011236Z Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.10,5.11-0.151020 are rejected Reject: pkg://omnios/library/security/openssl at 1.0.2.10,5.11-0.151020:20161102T001617Z pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z Reject: pkg://omnios/network/openssh at 7.4.1,5.11-0.151020:20170202T044205Z Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.11,5.11-0.151020 are rejected Reject: pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z No matching version of network/openssh-server can be installed: Reject: pkg://omnios/network/openssh-server at 7.2.2,5.11-0.151020:20161102T011250Z pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151020:20170202T044222Z Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151020 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161101T222456Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161230T213716Z Reason: This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20160603T025742Z This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z On 2/22/2017 9:59 AM, Dan McDonald wrote: >> On Feb 22, 2017, at 3:36 AM, Phil Harman wrote: >> >> This is all very good news. It would also be good to know what mpt_sas firmware is recommended with different illumos releases (an issue on other OSes too). > You should ping the greater illumos lists on that topic. More expertise there. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From doug at will.to Wed Feb 22 17:04:53 2017 From: doug at will.to (Doug Hughes) Date: Wed, 22 Feb 2017 12:04:53 -0500 Subject: [OmniOS-discuss] ugrading r16 to r20 In-Reply-To: <2b787934-762e-d8cb-238e-31a9dad81271@will.to> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> <2b787934-762e-d8cb-238e-31a9dad81271@will.to> Message-ID: Sorry for including the previous thread in there. mea culpa. On 2/22/2017 11:55 AM, Doug Hughes wrote: > I'm very delayed in this but had an opportunity to tackle the ugprade. > Unfortunately the prerequesite stage of upgrade to openssh is failing: > > # /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh > --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh > --reject pkg:/service/network/ssh-common pkg:/network/openssh > pkg:/network/openssh-server > Creating Plan (Solver setup): / > pkg install: No matching version of network/openssh can be installed: > Reject: > pkg://omnios/network/openssh at 7.2.2,5.11-0.151020:20161102T011236Z > Reason: All versions matching 'require' dependency > pkg:/library/security/openssl at 1.0.2.10,5.11-0.151020 are rejected > Reject: > pkg://omnios/library/security/openssl at 1.0.2.10,5.11-0.151020:20161102T001617Z > pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z > > Reason: This version is excluded by installed incorporation > pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z > Reject: > pkg://omnios/network/openssh at 7.4.1,5.11-0.151020:20170202T044205Z > Reason: All versions matching 'require' dependency > pkg:/library/security/openssl at 1.0.2.11,5.11-0.151020 are rejected > Reject: > pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z > Reason: This version is excluded by installed incorporation > pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z > No matching version of network/openssh-server can be installed: > Reject: > pkg://omnios/network/openssh-server at 7.2.2,5.11-0.151020:20161102T011250Z > pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151020:20170202T044222Z > Reason: All versions matching 'require' dependency > pkg:/SUNWcs at 0.5.11,5.11-0.151020 are rejected > Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161101T222456Z > pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161230T213716Z > Reason: This version is excluded by installed incorporation > pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20160603T025742Z > This version is excluded by installed incorporation > pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z > From danmcd at omniti.com Wed Feb 22 17:08:37 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Feb 2017 12:08:37 -0500 Subject: [OmniOS-discuss] ugrading r16 to r20 In-Reply-To: <2b787934-762e-d8cb-238e-31a9dad81271@will.to> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> <2b787934-762e-d8cb-238e-31a9dad81271@will.to> Message-ID: > On Feb 22, 2017, at 11:55 AM, Doug Hughes wrote: > > /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server I believe "ssh-common" doesn't exist on 016. Please try this: /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server Dan From danmcd at omniti.com Wed Feb 22 17:12:18 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Feb 2017 12:12:18 -0500 Subject: [OmniOS-discuss] On pkg(1) behavior in r151022 In-Reply-To: References: Message-ID: <14832825-5E06-4B36-BC23-0ED5FBEDBC86@omniti.com> > On Feb 22, 2017, at 11:35 AM, Peter Tribble wrote: > > I'm not sure I would make -r the default. Apart from the existence of > cases where you explicitly *don't* want to update zones, it makes you > incompatible wit the rest of the IPS world. > > However, the fact that a bare 'pkg update' could lead to broken linked > zones does concern me, and I suspect that you're going to have to look > at whether you need to tighten up package and incorporate dependencies. What needs to happen is that some core illumos-omnios packages need to always update regardless of "-r". Rich Lowe gave me a suggested set of diffs: https://gist.github.com/richlowe/c88e6defa0eba09e1a00 I may need to include those going forward. . . . It seems, however, the general consensus is "Yeah, let's not make -r implicit, and document the new behavior." I'm okay with this, especially given how it behaves with "pkg update -r ". Thank you everyone! Dan From doug at will.to Wed Feb 22 17:23:51 2017 From: doug at will.to (Doug Hughes) Date: Wed, 22 Feb 2017 12:23:51 -0500 Subject: [OmniOS-discuss] ugrading r16 to r20 In-Reply-To: References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> <2b787934-762e-d8cb-238e-31a9dad81271@will.to> Message-ID: <88befb5f-bf8f-1b5e-50bb-57fe8d561451@will.to> no luck: # /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server Creating Plan (Solver setup): / pkg install: No matching version of network/openssh can be installed: Reject: pkg://omnios/network/openssh at 7.2.2,5.11-0.151020:20161102T011236Z Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.10,5.11-0.151020 are rejected Reject: pkg://omnios/library/security/openssl at 1.0.2.10,5.11-0.151020:20161102T001617Z pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z Reject: pkg://omnios/network/openssh at 7.4.1,5.11-0.151020:20170202T044205Z Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.11,5.11-0.151020 are rejected Reject: pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z No matching version of network/openssh-server can be installed: Reject: pkg://omnios/network/openssh-server at 7.2.2,5.11-0.151020:20161102T011250Z pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151020:20170202T044222Z Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151020 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161101T222456Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161230T213716Z Reason: This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20160603T025742Z This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z # On 2/22/2017 12:08 PM, Dan McDonald wrote: > /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server From danmcd at omniti.com Wed Feb 22 17:26:56 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Feb 2017 12:26:56 -0500 Subject: [OmniOS-discuss] ugrading r16 to r20 In-Reply-To: <88befb5f-bf8f-1b5e-50bb-57fe8d561451@will.to> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> <2b787934-762e-d8cb-238e-31a9dad81271@will.to> <88befb5f-bf8f-1b5e-50bb-57fe8d561451@will.to> Message-ID: <77ADBAC3-400B-495E-9B04-0C0F37B8B4CC@omniti.com> > On Feb 22, 2017, at 12:23 PM, Doug Hughes wrote: > > > no luck: > > # /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server > Creating Plan (Solver setup): / > pkg install: No matching version of network/openssh can be installed: > Reject: pkg://omnios/network/openssh at 7.2.2,5.11-0.151020:20161102T011236Z > Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.10,5.11-0.151020 are rejected > Reject: pkg://omnios/library/security/openssl at 1.0.2.10,5.11-0.151020:20161102T001617Z > pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z > Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z > Reject: pkg://omnios/network/openssh at 7.4.1,5.11-0.151020:20170202T044205Z > Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.11,5.11-0.151020 are rejected > Reject: pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z > Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z > No matching version of network/openssh-server can be installed: > Reject: pkg://omnios/network/openssh-server at 7.2.2,5.11-0.151020:20161102T011250Z > pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151020:20170202T044222Z > Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151020 are rejected > Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161101T222456Z > pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161230T213716Z > Reason: This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20160603T025742Z > This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z > # Hmmm... silly question #2: did you first make sue your 016 node is upgraded to the latest everything (i.e. just a plain "pkg update")? I see an openssl line or two in your output, e.g. Dan From doug at will.to Wed Feb 22 17:29:10 2017 From: doug at will.to (Doug Hughes) Date: Wed, 22 Feb 2017 12:29:10 -0500 Subject: [OmniOS-discuss] ugrading r16 to r20 In-Reply-To: <77ADBAC3-400B-495E-9B04-0C0F37B8B4CC@omniti.com> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> <2b787934-762e-d8cb-238e-31a9dad81271@will.to> <88befb5f-bf8f-1b5e-50bb-57fe8d561451@will.to> <77ADBAC3-400B-495E-9B04-0C0F37B8B4CC@omniti.com> Message-ID: <972ee48b-fb1f-da71-d7f1-4ec35d8c2f9a@will.to> On 2/22/2017 12:26 PM, Dan McDonald wrote: >> On Feb 22, 2017, at 12:23 PM, Doug Hughes wrote: >> >> >> no luck: >> >> # /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server >> Creating Plan (Solver setup): / >> pkg install: No matching version of network/openssh can be installed: >> Reject: pkg://omnios/network/openssh at 7.2.2,5.11-0.151020:20161102T011236Z >> Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.10,5.11-0.151020 are rejected >> Reject: pkg://omnios/library/security/openssl at 1.0.2.10,5.11-0.151020:20161102T001617Z >> pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z >> Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z >> Reject: pkg://omnios/network/openssh at 7.4.1,5.11-0.151020:20170202T044205Z >> Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.11,5.11-0.151020 are rejected >> Reject: pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z >> Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z >> No matching version of network/openssh-server can be installed: >> Reject: pkg://omnios/network/openssh-server at 7.2.2,5.11-0.151020:20161102T011250Z >> pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151020:20170202T044222Z >> Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151020 are rejected >> Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161101T222456Z >> pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161230T213716Z >> Reason: This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20160603T025742Z >> This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z >> # > > Hmmm... silly question #2: did you first make sue your 016 node is upgraded to the latest everything (i.e. just a plain "pkg update")? I see an openssl line or two in your output, e.g. > > Dan > yes, and rebooted. # pkg update WARNING: The boot environment being modified is not the active one. Changes made will not be reflected on the next boot. Packages to update: 1 Create boot environment: No Create backup boot environment: Yes DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 1/1 13/13 0.0/0.0 182k/s PHASE ITEMS Removing old actions 2/2 Installing new actions 2/2 Updating modified actions 13/13 Updating package state database Done Updating package cache 1/1 Updating image state Done Creating fast lookup database Done --------------------------------------------------------------------------- NOTE: Please review release notes posted at: http://omnios.omniti.com/ReleaseNotes --------------------------------------------------------------------------- # /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server Creating Plan (Solver setup): / pkg install: No matching version of network/openssh can be installed: Reject: pkg://omnios/network/openssh at 7.2.2,5.11-0.151020:20161102T011236Z Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.10,5.11-0.151020 are rejected Reject: pkg://omnios/library/security/openssl at 1.0.2.10,5.11-0.151020:20161102T001617Z pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z Reject: pkg://omnios/network/openssh at 7.4.1,5.11-0.151020:20170202T044205Z Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.11,5.11-0.151020 are rejected Reject: pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z No matching version of network/openssh-server can be installed: Reject: pkg://omnios/network/openssh-server at 7.2.2,5.11-0.151020:20161102T011250Z pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151020:20170202T044222Z Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151020 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161101T222456Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161230T213716Z Reason: This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20160603T025742Z This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z # yes, and rebooted. # pkg update WARNING: The boot environment being modified is not the active one. Changes made will not be reflected on the next boot. Packages to update: 1 Create boot environment: No Create backup boot environment: Yes DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 1/1 13/13 0.0/0.0 182k/s PHASE ITEMS Removing old actions 2/2 Installing new actions 2/2 Updating modified actions 13/13 Updating package state database Done Updating package cache 1/1 Updating image state Done Creating fast lookup database Done --------------------------------------------------------------------------- NOTE: Please review release notes posted at: http://omnios.omniti.com/ReleaseNotes --------------------------------------------------------------------------- # /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server Creating Plan (Solver setup): / pkg install: No matching version of network/openssh can be installed: Reject: pkg://omnios/network/openssh at 7.2.2,5.11-0.151020:20161102T011236Z Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.10,5.11-0.151020 are rejected Reject: pkg://omnios/library/security/openssl at 1.0.2.10,5.11-0.151020:20161102T001617Z pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z Reject: pkg://omnios/network/openssh at 7.4.1,5.11-0.151020:20170202T044205Z Reason: All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.11,5.11-0.151020 are rejected Reject: pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151020:20170126T161757Z Reason: This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z No matching version of network/openssh-server can be installed: Reject: pkg://omnios/network/openssh-server at 7.2.2,5.11-0.151020:20161102T011250Z pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151020:20170202T044222Z Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151020 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161101T222456Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151020:20161230T213716Z Reason: This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20160603T025742Z This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z # From peter.tribble at gmail.com Wed Feb 22 17:32:34 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Wed, 22 Feb 2017 17:32:34 +0000 Subject: [OmniOS-discuss] ugrading r16 to r20 In-Reply-To: <88befb5f-bf8f-1b5e-50bb-57fe8d561451@will.to> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> <2b787934-762e-d8cb-238e-31a9dad81271@will.to> <88befb5f-bf8f-1b5e-50bb-57fe8d561451@will.to> Message-ID: On Wed, Feb 22, 2017 at 5:23 PM, Doug Hughes wrote: > > no luck: > > # /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject > pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh > pkg:/network/openssh pkg:/network/openssh-server > Creating Plan (Solver setup): / > pkg install: No matching version of network/openssh can be installed: > Reject: pkg://omnios/network/openssh at 7.2.2,5.11-0.151020:20161102T01 > 1236Z > So you're mixing 016 and 020 packages here. Have you switched publishers to r151020 already? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at will.to Wed Feb 22 17:36:07 2017 From: doug at will.to (Doug Hughes) Date: Wed, 22 Feb 2017 12:36:07 -0500 Subject: [OmniOS-discuss] ugrading r16 to r20 In-Reply-To: References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> <2b787934-762e-d8cb-238e-31a9dad81271@will.to> <88befb5f-bf8f-1b5e-50bb-57fe8d561451@will.to> Message-ID: <29b01d77-e1cc-6ae9-cfa5-c84640d49dad@will.to> On 2/22/2017 12:32 PM, Peter Tribble wrote: > > > On Wed, Feb 22, 2017 at 5:23 PM, Doug Hughes > wrote: > > > no luck: > > # /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh > --reject pkg:/network/ssh/ssh-key --reject > pkg:/service/network/ssh pkg:/network/openssh > pkg:/network/openssh-server > Creating Plan (Solver setup): / > pkg install: No matching version of network/openssh can be installed: > Reject: > pkg://omnios/network/openssh at 7.2.2,5.11-0.151020:20161102T011236Z > > > So you're mixing 016 and 020 packages here. > > Have you switched publishers to r151020 already? > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ oh bollocks. You nailed it.. I started and failed on the openssh, then went to try upgrade and then switched back. Ok, now the revised upgrade works! good catch. *head-desk* -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Feb 23 19:06:30 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 23 Feb 2017 14:06:30 -0500 Subject: [OmniOS-discuss] Bloody update for February 23rd (LONG!) Message-ID: <398FAB73-ABE1-4FA4-AB90-CB7153591537@omniti.com> Hello folks! Pardon the delay, I've been wrestling with what to do with install media, and I've decided to throw out Caiman and implement a simpler (and likely more primitive) installer using Kayak for ISO & USB. It is under active development right now. I HOPE to have it out in two weeks in time for the next bloody update. If I'm behind, expect the bloody update to also lag, as I really would like the next update to include Kayak for ISO/USB. Also, the feedback from BSD Loader deployment has been either positive or none-at-all, so I assume everyone's okay with it. Although the feature has been in bloody since the jump to Python2.7, we're officially committing to a new set of linked-image semantics for lipkg zones. ipkg zones remain unchanged. Per the prior thread: "On pkg(1) behavior in r151022", prior to the Python2.7 upgrade: pkg update - Updates on global zone. No others, REGARDLESS of linked-image or not. (This is considered a bug.) pkg update - Update all pkgs on global zone AND on any linked-image zones. As of now, we are officially endorsing and embracing the following new behavior: pkg update - Same as before (but now not a bug due to "-r"...) pkg update - Only updates global zone, and linked-image "If needs sync", where "needs sync" is defined by a parent-image dependency. Currently no OmniOS packages have this dependency, but before this bloody cycle closes, some will. (e.g. system/library, SUNWcs) pkg update -r - Updates on global zone AND on linked-image zones. pkg update -r - Behaves like "pkg update" on 014-020, updates all pkgs on global and linked-image zones. The following pkg(1) primitives can now take the -r flag, and the -z (certain zones) or -Z (exclude zones) also: install uninstall update change-facet change-variant So if you're an lipkg user, start including "-r" in your pkg update or install commands if you want the pre-Python2.7-wad behavior. Many users have said this is an overall improvement, so it may, during the post-022/LTS releases, become the default "ipkg" behavior as well. I believe Oracle intended these semantics for linked-images the whole time. uname -v show omnios-master-05eff6d illumos-omnios is master branch, commit 05eff6de1f5d0f947aef584ac1a3d2807198b841 (LX bits last merged with illumos-joyent commit 384c07167202f048489a38c1fd2a2f8ac5a082bd) omnios-build is master branch, commit 3d2982b721130970aa29068079386dd6fbc06378 Also new in this update: - gcc44 is up to "il-4" to build the latest illumos-gate and illumos-omnios. This came out on the repo early. - curl is up to 7.53.0, also an early arrival. - OpenSSH is now up to 7.4p1, also an early arrival. - bash is now up to 4.4p12 - nghttp2 is up to 1.19 - BIND is up to 9.10.4-P6 - SimpleJSON is up to 3.10.0 (and passes pkg5 tests!) - Some ASCII art improvements to the OmniOS Loader screen (thanks Dominik Hassler) - TCP keepalives now accepted with missing timestamps (helps with Windows interoperability) - ZFS fixes - mmap() now updates timestamps. - - SMBIOS 3.1 support - mpt_sas bugfixes - Various LX fixes - The illumos vmem() allocator now has man pages. - Loader BIOS disk fix for disks > 2TB. - IPv6 Atomic Fragments no longer exist (Per RFC 8021) unless you're using deprecated CGTP/Multirouting. - Intel 40Gig Ethernet (i40e driver) now supports multiple transmit AND receive rings. Happy updating! (And wish me luck on Kayak-for-ISO/USB...) Dan From matej at zunaj.si Fri Feb 24 07:49:08 2017 From: matej at zunaj.si (=?utf-8?Q?Matej_=C5=BDerovnik?=) Date: Fri, 24 Feb 2017 08:49:08 +0100 Subject: [OmniOS-discuss] MPT SAS Update In-Reply-To: <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> References: <527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org> <1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com> <0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com> <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com> Message-ID: <4D0D9AF2-A674-4F2A-93E6-EE06FF4B9AE4@zunaj.si> > On 22 Feb 2017, at 15:59, Dan McDonald wrote: > > >> On Feb 22, 2017, at 3:36 AM, Phil Harman wrote: >> >> This is all very good news. It would also be good to know what mpt_sas firmware is recommended with different illumos releases (an issue on other OSes too). > > You should ping the greater illumos lists on that topic. More expertise there. > And please report back:) I?m currently running r20: LSI9207 with P19 firmware LSI3008 with P12 firmware This was also running fine on r16 and r18. Servers are in production for the last year. lp, Matej -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Feb 24 18:40:00 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 24 Feb 2017 13:40:00 -0500 Subject: [OmniOS-discuss] USB3 build now updated, plus call for feedback Message-ID: The bloody+USB3 repo is now caught up with the current bloody: http://pkg.omniti.com/omnios/USB3/ You can update your USB3-happy bloody installs now. Currently it is just bloody plus two commits from Joyent (USB3 wad, and one major bugfix). If anyone has USB3 experiences to share, please do so. I'd like Joyent to upstream this at some point, and knowing it's gotten exercised outside of SmartOS never hurts. Thanks, Dan From danmcd at omniti.com Mon Feb 27 22:10:30 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 27 Feb 2017 17:10:30 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha Message-ID: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> I'm in the middle of rewhacking our PXE installer, Kayak, to ALSO provide support for an ISO-based mildly-interactive installer. Here's the new install menu: Welcome to the OmniOS installation menu 1 Find disks, create rpool, and install OmniOS 2 Install OmniOS straight on to a preconfigured rpool 3 Shell (if you need to preconfigure rpool) 4 Terminal type (currently sun-color) 5 Reboot Basically, #1 will use diskinfo(1M) to list the disks and let you select them. #2 will find an imported and online pool named "rpool" that you configured in advance, and install OmniOS on it. #3 give you a shell to do such configuration. I'm somewhat along in this process, but it's VERY rough. I have some of #2's functionality working now. If there are brave people who wish to try various stages of the new ISO installer for OmniOS (it will also be the USB one... BSD Loader makes USB construction simple once you have an ISO created), please let me know. NOTE: I do not have USB ready yet, just very VERY sketchy ISO images. :) NOTE 2: I'm ESPECIALLY interested in people on qemu or other virtualization technologies, as this installer should not have the hangups about blkdev devices that the old installer did. If diskinfo(1M) in the shell sees it, you can install on it. Thanks, Dan From stephan.budach at jvm.de Tue Feb 28 08:00:12 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Tue, 28 Feb 2017 09:00:12 +0100 (CET) Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> Message-ID: <372957988.1207.1488268775446.JavaMail.stephan.budach@stephan.budach.jvm.de> Hi Dan, would that allow me to run OmniOS on a Xen-based Oracle VM? Frankly, I didn't manage to get that one up due to restrained resources on my end - and it since hasn't been pressing enough? ;) 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 doug at will.to Tue Feb 28 12:11:26 2017 From: doug at will.to (Doug Hughes) Date: Tue, 28 Feb 2017 07:11:26 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <372957988.1207.1488268775446.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> Message-ID: I could try it on libvirt/qemu. On Feb 28, 2017 3:14 AM, "Stephan Budach" wrote: > Hi Dan, > > would that allow me to run OmniOS on a Xen-based Oracle VM? Frankly, I > didn't manage to get that one up due to restrained resources on my end - > and it since hasn't been pressing enough? ;) > > 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 danmcd at omniti.com Tue Feb 28 16:54:20 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 28 Feb 2017 11:54:20 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <372957988.1207.1488268775446.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> Message-ID: <929E9A7E-7211-4321-A589-AFA31804BEE0@omniti.com> > On Feb 28, 2017, at 3:00 AM, Stephan Budach wrote: > > Hi Dan, > > would that allow me to run OmniOS on a Xen-based Oracle VM? Frankly, I didn't manage to get that one up due to restrained resources on my end - and it since hasn't been pressing enough? ;) It MIGHT, and you're the sort of person I need to confirm/deny it. Watch for a kebe.com link later today. Dan From mir at miras.org Tue Feb 28 17:20:36 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 28 Feb 2017 18:20:36 +0100 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> Message-ID: <20170228182036.3b7e7fb1@sleipner.datanom.net> On Mon, 27 Feb 2017 17:10:30 -0500 Dan McDonald wrote: > > NOTE 2: I'm ESPECIALLY interested in people on qemu or other virtualization technologies, as this installer should not have the hangups about blkdev devices that the old installer did. If diskinfo(1M) in the shell sees it, you can install on it. > I am running Omnios in my Proxmox cluster (Debian/Ubuntu Qemu based) already so I will gladly volunteer. -- 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: semper en excretus -------------- 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 Tue Feb 28 17:22:37 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 28 Feb 2017 12:22:37 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> Message-ID: <02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com> > On Feb 27, 2017, at 5:10 PM, Dan McDonald wrote: > > If there are brave people who wish to try various stages of the new ISO installer for OmniOS (it will also be the USB one... BSD Loader makes USB construction simple once you have an ISO created), please let me know. Please download this: http://kebe.com/~danmcd/webrevs/r151021-kayak.iso md5 (r151021-kayak.iso) = e1bfabf04b6e0ebcd980c6bc1834a19a sha1 (r151021-kayak.iso) = ec8e587ea39705e7cd0f5bcc0b0c4b8cd597d21f sha256 (r151021-kayak.iso) = 6eb045fe52dd0b3cdfcdaa8c905e63b1afd9b23e6585b1c706a4ed8be363aee6 And try it out. PLEASE NOTE that menu item "1" isn't working yet, so to install OmniOS this way, you'll need to: 1.) Enter a shell using menu item "3". Because of the way I did the installer, there's no job control on the tty. 2.) Use diskinfo(1M) to list the available disks. 2a.) (Optional) Use format(1M) or whatever other tools to partition if you feel you need to do this. 3.) Create a pool called "rpool". BTW, you can use whole-disk GPT now, and that will be the new installer's default. You can use mirrors, but you cannot use RAIDz. 4.) Exit the shell. 5.) Use menu item "2" to install. You will get some questions, you can just hit RETURN to be quick, or answer them and do some customization. 6.) Reboot to your new disk. It'll be the same image we have on http://pkg.omniti.com/omnios/bloody/ It will boot via BSD Loader. Thanks, Dan From mir at miras.org Tue Feb 28 17:48:00 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 28 Feb 2017 18:48:00 +0100 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com> References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> <02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com> Message-ID: <20170228184800.4119d335@sleipner.datanom.net> On Tue, 28 Feb 2017 12:22:37 -0500 Dan McDonald wrote: > diskinfo(1M) or format(1M) No found on the iso?? -- 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: The universe is all a spin-off of the Big Bang. -------------- 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 Tue Feb 28 18:02:21 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 28 Feb 2017 13:02:21 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170228184800.4119d335@sleipner.datanom.net> References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> <02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com> <20170228184800.4119d335@sleipner.datanom.net> Message-ID: > On Feb 28, 2017, at 12:48 PM, Michael Rasmussen wrote: > > On Tue, 28 Feb 2017 12:22:37 -0500 > Dan McDonald wrote: > >> diskinfo(1M) or format(1M) > No found on the iso?? Shoot. I messed something up in this ISO's construction. Please wait, folks, Dan From danmcd at omniti.com Tue Feb 28 18:23:24 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 28 Feb 2017 13:23:24 -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> Message-ID: > 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. 2.) format is available, but not functional because of the horrid hacks I made to get the install menu working. Pardon the delay. Here are the new sums for http://kebe.com/~danmcd/webrevs/r151021-kayak.iso md5 (r151021-kayak.iso) = 82236fe8acb1c29469b7fc79423e105b sha1 (r151021-kayak.iso) = 84f1fff1374bd44678e9386f27c0f396901aa1ab sha256 (r151021-kayak.iso) = d24b2b60452179a574e8d70fa69d6deb6ea71436c8badc0a711451f664513e59 Dan From mir at miras.org Tue Feb 28 18:58:45 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 28 Feb 2017 19:58:45 +0100 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> Message-ID: <20170228195845.09f5c4bf@sleipner.datanom.net> 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 -------------- 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 Tue Feb 28 19:43:50 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 28 Feb 2017 14:43:50 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170228195845.09f5c4bf@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> Message-ID: 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 From mir at miras.org Tue Feb 28 20:12:30 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 28 Feb 2017 21:12:30 +0100 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: <20170228211230.12e605fa@sleipner.datanom.net> On Tue, 28 Feb 2017 14:43:50 -0500 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. > Installer never starts. Boot crashes due to a missing rootfs module. See screendump. -- 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 get my exercise acting as pallbearer to my friends who exercise. -- Chauncey Depew -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot at 2017-02-28 21-11-25.png Type: image/png Size: 10602 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 Tue Feb 28 20:46:54 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 28 Feb 2017 15:46:54 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170228211230.12e605fa@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> Message-ID: <7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com> I saw that error when I disconnected my virtual cd drive mid installer boot. Please check the integrity of your downloaded ISO. Thanks, Dan Sent from my iPhone (typos, autocorrect, and all) > On Feb 28, 2017, at 3:12 PM, Michael Rasmussen wrote: > > On Tue, 28 Feb 2017 14:43:50 -0500 > 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. >> > Installer never starts. Boot crashes due to a missing rootfs module. > See screendump. > > > -- > 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 get my exercise acting as pallbearer to my friends who exercise. > -- Chauncey Depew > From mir at miras.org Tue Feb 28 21:00:18 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 28 Feb 2017 22:00:18 +0100 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@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> Message-ID: <20170228220018.6705ed8e@sleipner.datanom.net> On Tue, 28 Feb 2017 15:46:54 -0500 Dan McDonald wrote: > I saw that error when I disconnected my virtual cd drive mid installer boot. Please check the integrity of your downloaded ISO. > Solved it. Initially using 512MB memory which was not enough to contain the rootfs. Increasing memory to 1GB and the installer boots;-) Is an initial requirement of 1GB memory not a bit to high? -- 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: What's the difference betweeen USL and the Graf Zeppelin? A: The Graf Zeppelin represented cutting edge technology for its time. -------------- 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 Tue Feb 28 21:15:43 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 28 Feb 2017 22:15:43 +0100 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170228220018.6705ed8e@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> Message-ID: <20170228221543.27a5db05@sleipner.datanom.net> On Tue, 28 Feb 2017 22:00:18 +0100 Michael Rasmussen wrote: > On Tue, 28 Feb 2017 15:46:54 -0500 > Dan McDonald wrote: > > > I saw that error when I disconnected my virtual cd drive mid installer boot. Please check the integrity of your downloaded ISO. > > > Solved it. > Initially using 512MB memory which was not enough to contain the rootfs. > Increasing memory to 1GB and the installer boots;-) > > Is an initial requirement of 1GB memory not a bit to high? > A new issue: Assigned to virtio disks to the VM but diskinfo only finds one? First disk: /dev/dsk/c1t0d0 /dev/rdsk/c1t0d0 both mapped to pci device No /dev/{r,}dsk/c4t0d0 but diskinfo clams a disk in c4t0d0 -- 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 woman should have compassion. -- Kirk, "Catspaw", stardate 3018.2 -------------- 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 Tue Feb 28 21:36:42 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 28 Feb 2017 16:36:42 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170228220018.6705ed8e@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> Message-ID: <6812C576-A15D-48C0-BC87-4F7400E05F38@omniti.com> > On Feb 28, 2017, at 4:00 PM, Michael Rasmussen wrote: > > Is an initial requirement of 1GB memory not a bit to high? I shoved EVERYTHING into the ramdisk image, so it's more than 512. I think 768 is doable, TBH. I haven't yet tried optimizing for lower-memory deployments (I can do this eventually, just not yet). I also thought (perhaps incorrectly) that 1GB was a fair minimum these days. Dan From mir at miras.org Tue Feb 28 21:46:37 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 28 Feb 2017 22:46:37 +0100 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170228221543.27a5db05@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> Message-ID: <20170228224637.597f060f@sleipner.datanom.net> On Tue, 28 Feb 2017 22:15:43 +0100 Michael Rasmussen wrote: > A new issue: > Assigned to virtio disks to the VM but diskinfo only finds one? > First disk: > /dev/dsk/c1t0d0 > /dev/rdsk/c1t0d0 > both mapped to pci device > No /dev/{r,}dsk/c4t0d0 > > but diskinfo clams a disk in c4t0d0 > > Testing visibility of disks to the installer: No disks/interface ide sata virtio scsi 1 1 1 1 1 n+1 n+1 n+1 1 1 -- 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: Why bother building any more nuclear warheads until we use the ones we 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 mir at miras.org Tue Feb 28 21:50:28 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 28 Feb 2017 22:50:28 +0100 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170228224637.597f060f@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> Message-ID: <20170228225028.41fb3642@sleipner.datanom.net> On Tue, 28 Feb 2017 22:46:37 +0100 Michael Rasmussen wrote: > On Tue, 28 Feb 2017 22:15:43 +0100 > Michael Rasmussen wrote: > > Testing visibility of disks to the installer: > No disks/interface ide sata virtio scsi > 1 1 1 1 1 > n+1 n+1 n+1 1 1 > Forgot to mention: qemu v. 2.7.1 -- 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: its hard being a lesbian withoutn breasts...people dont take you seriously -------------- 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 Tue Feb 28 22:16:56 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 28 Feb 2017 17:16:56 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170228225028.41fb3642@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> Message-ID: <7F0EE08D-AFA1-4D93-A773-F2D48802212D@omniti.com> > On Feb 28, 2017, at 4:50 PM, Michael Rasmussen wrote: > > On Tue, 28 Feb 2017 22:46:37 +0100 > Michael Rasmussen wrote: > >> On Tue, 28 Feb 2017 22:15:43 +0100 >> Michael Rasmussen wrote: >> >> Testing visibility of disks to the installer: >> No disks/interface ide sata virtio scsi >> 1 1 1 1 1 >> n+1 n+1 n+1 1 1 >> > Forgot to mention: qemu v. 2.7.1 Are you seeing this? https://github.com/omniti-labs/illumos-omnios/pull/10 Dan From peter.tribble at gmail.com Tue Feb 28 22:22:15 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Tue, 28 Feb 2017 22:22:15 +0000 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> Message-ID: Dan, On Mon, Feb 27, 2017 at 10:10 PM, Dan McDonald wrote: > I'm in the middle of rewhacking our PXE installer, Kayak, to ALSO provide > support for an ISO-based mildly-interactive installer. Here's the new > install menu: > > > Welcome to the OmniOS installation menu > > > 1 Find disks, create rpool, and install OmniOS > 2 Install OmniOS straight on to a preconfigured rpool > 3 Shell (if you need to preconfigure rpool) > 4 Terminal type (currently sun-color) > 5 Reboot > > > > Basically, #1 will use diskinfo(1M) to list the disks and let you select > them. #2 will find an imported and online pool named "rpool" that you > configured in advance, and install OmniOS on it. #3 give you a shell to do > such configuration. > > I'm somewhat along in this process, but it's VERY rough. I have some of > #2's functionality working now. > > If there are brave people who wish to try various stages of the new ISO > installer for OmniOS (it will also be the USB one... BSD Loader makes USB > construction simple once you have an ISO created), please let me know. > 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. Right, so you've dropped the good old solaris.zlib approach and simply gone for a single root archive. I'm thinking of doing the same, by the way, but it has consequences for RAM use and reliability (although hopefully the new loader will handle large boot archives better than grub+bios did). It looks like a 64-bit only ISO. (The image you install is dual 32/64-bit though.) The root archive is uncompressed. You could make the iso smaller by gzipping the root archive. The root archive doesn't need the root reserve or anything like as many inodes, which can save you quite a lot of space. The loader menu on the ISO ought to have a 'boot from disk' option that's removed for the installed system. The live media is a bit sparse. There's quite a bit of stuff I would normally expect on a booted system, iostat for starters, that's useful for recovery. There are some odd device links under /dev/dsk Oddly, diskinfo isn't on the installed system. 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). One advantage of the current process is that it copies the currently booted OS onto the installed system. Which (a) copies any manual hacks you've made in order to get it to work, and (b) ensures that the installed system is going to work because it's identical to the one you're running off the media. Having the installed system come from a different source breaks that connection; that may be good or bad depending on your point of view. (The live kernel and the installed kernel in this case are different, it just looks like dtrace from a quick look.) One nice option would be to have a minimal iso without the kayak dataset, but that allows you to configure minimal networking and then give it a URL to get the archive from. (The use case here is remote mounting the boot iso from my laptop via the server's LOM interface.) Shoving the kayak dataset into the root archive does make it quite large and increase the memory requirement - but it does allow quite a lot of simplification, as omnios never needs to talk to the media at all, once the loader has read the archive the media can be disposed of. That's all for this pass, I think. Thanks! -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Feb 28 22:35:57 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 28 Feb 2017 17:35:57 -0500 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com> Message-ID: <27CB83D1-4B09-436F-AA83-1D1CCCD06428@omniti.com> > 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. > and simply gone for a single root archive. I'm thinking of doing > the same, by the way, but it has consequences for RAM use and > reliability (although hopefully the new loader will handle large boot > archives better than grub+bios did). Loader makes a lot of things better. > It 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. > 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. > The root archive doesn't need the root reserve or anything like as > many inodes, which can save you quite a lot of space. > > 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. > The live media is a bit sparse. There's quite a bit of stuff I would > normally expect on a booted system, iostat for starters, that's > useful for recovery. Note the provenance of this code. It comes from the kayak PXE booter. Basically, I've been adding more to what the PXE booter sends to be complete in the ISO. > There are some odd device links under /dev/dsk > > Oddly, diskinfo isn't on the installed system. Oh, on the INSTALLED system. Yeah, that's a bug, and can be fixed in github.com:/omniti-labs/kayak. > 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. > One advantage of the current process is that it copies the currently > booted OS onto the installed system. Which (a) copies any manual > hacks you've made in order to get it to work, and (b) ensures that > the installed system is going to work because it's identical to the one > you're running off the media. Having the installed system come from > a different source breaks that connection; that may be good or bad > depending on your point of view. That's technically wrong. In practice they do come from the same source bits, but the .zfs.bz2 file COULD be generated elsewhere. > (The live kernel and the installed kernel in this case are different, > it just looks like dtrace from a quick look.) For now that's mostly true. > One nice option would be to have a minimal iso without the kayak > dataset, but that allows you to configure minimal networking and > then give it a URL to get the archive from. (The use case here is > remote mounting the boot iso from my laptop via the server's > LOM interface.) This is how kayak for PXE works now. It wouldn't be hard to not include the .zfs.bz2 and instead include a URL, and a network-bringup script. Said script would need instant-naming capability (i.e. DNS) along with DHCP configuration. Kayak for PXE grabs all of this from the DHCP server today. > Shoving the kayak dataset into the root archive does make it > quite large and increase the memory requirement - but it does > allow quite a lot of simplification, as omnios never needs to > talk to the media at all, once the loader has read the archive > the media can be disposed of. Ideally yes. > That's all for this pass, I think. 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. Thank you! Dan From mir at miras.org Tue Feb 28 22:36:09 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 28 Feb 2017 23:36:09 +0100 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <7F0EE08D-AFA1-4D93-A773-F2D48802212D@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> Message-ID: <20170228233609.0dcc738b@sleipner.datanom.net> On Tue, 28 Feb 2017 17:16:56 -0500 Dan McDonald wrote: > > Are you seeing this? > > https://github.com/omniti-labs/illumos-omnios/pull/10 > Yes, exactly. Which also have that odd side effect that a single disk rpool is created on the second disk (layered after the ide device) is chosen for the pool with the consequence that users must interfere bios boot to choose second disk to use as boot device. I will try to see whether to use sata for cd will change this oddity. Stay tuned. -- 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: Mieux vaut tard que jamais! [ Better late than never ] -------------- 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 Tue Feb 28 23:12:20 2017 From: mir at miras.org (Michael Rasmussen) Date: Wed, 1 Mar 2017 00:12:20 +0100 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170228233609.0dcc738b@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> Message-ID: <20170301001220.5fd143f1@sleipner.datanom.net> On Tue, 28 Feb 2017 23:36:09 +0100 Michael Rasmussen wrote: > On Tue, 28 Feb 2017 17:16:56 -0500 > Dan McDonald wrote: > > > > > Are you seeing this? > > > > https://github.com/omniti-labs/illumos-omnios/pull/10 > > > Yes, exactly. Which also have that odd side effect that a single disk > rpool is created on the second disk (layered after the ide device) is > chosen for the pool with the consequence that users must interfere bios > boot to choose second disk to use as boot device. > > I will try to see whether to use sata for cd will change this oddity. > Stay tuned. > No luck. Qemu (seabios) will always have this order: 1. first disk 2. DVD/CD 3. IPXE 4. second disk 5. Legacy option romm PS. Above only concerns the installer kernel. The kernel installed has no such issues so you can use the prtvtoc /dev/rdsk/c..... | fmthard -s - /dev/rdsk/c....... and zpool attach -f rpool c..... c..... after initial boot. PPS. Booting installer iso using sata or scsi will increase load speed by a factor 10. -- 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 have the simplest tastes. I am always satisfied with the best. -- Oscar Wilde -------------- 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 Tue Feb 28 23:55:30 2017 From: mir at miras.org (Michael Rasmussen) Date: Wed, 1 Mar 2017 00:55:30 +0100 Subject: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha In-Reply-To: <20170301001220.5fd143f1@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> Message-ID: <20170301005530.7e7d1316@sleipner.datanom.net> On Wed, 1 Mar 2017 00:12:20 +0100 Michael Rasmussen wrote: > > PS. Above only concerns the installer kernel. The kernel installed has > no such issues so you can use the prtvtoc /dev/rdsk/c..... | fmthard > -s - /dev/rdsk/c....... and zpool attach -f rpool c..... c..... after initial boot. > 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. -- 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: Van Roy's Law: An unbreakable toy is useful for breaking other toys. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: