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 <current-BE>" -- 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/<rpool-drive>
  rm /rpool/boot/menu.lst
  beadm activate <current-BE>  (should reconstruct /rpool/boot/menu.lst)

If you have mirrored roots, do the above installboot for each <rpool-drive>.


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/<rpool-drive>

If you have mirrored roots, use "installgrub -M /dev/rdsk/<installed-drive> /dev/rdsk/<mirror-drive>


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 <danmcd at omniti.com> 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 <danmcd at omniti.com> 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 <current-BE>" -- 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/<rpool-drive>
>   rm /rpool/boot/menu.lst
>   beadm activate <current-BE>  (should reconstruct /rpool/boot/menu.lst)
>
> If you have mirrored roots, do the above installboot for each <rpool-drive>.
>
>
> 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/<rpool-drive>
>
> If you have mirrored roots, use "installgrub -M /dev/rdsk/<installed-drive> /dev/rdsk/<mirror-drive>
>
>
> 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: <CACFEqhvAUdEEyYrXO-zZ59tRZ0Tu=X2GvurSsZg9gGHXddfvTQ@mail.gmail.com>

Thanks Dan. Have the LX zone patches been added in?

On Wed, Feb 1, 2017 at 6:58 AM Dominik Hassler <hasslerd at gmx.li> 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 <current-BE>" -- 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/<rpool-drive>
> >   rm /rpool/boot/menu.lst
> >   beadm activate <current-BE>  (should reconstruct /rpool/boot/menu.lst)
> >
> > If you have mirrored roots, do the above installboot for each
> <rpool-drive>.
> >
> >
> > 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/<rpool-drive>
> >
> > If you have mirrored roots, use "installgrub -M
> /dev/rdsk/<installed-drive> /dev/rdsk/<mirror-drive>
> >
> >
> > 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170201/290bb987/attachment-0001.html>

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: <CACFEqhvAUdEEyYrXO-zZ59tRZ0Tu=X2GvurSsZg9gGHXddfvTQ@mail.gmail.com>
References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com>
	<44FDE281-F712-4366-ABC9-939DC8616872@omniti.com>
	<7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li>
	<CACFEqhvAUdEEyYrXO-zZ59tRZ0Tu=X2GvurSsZg9gGHXddfvTQ@mail.gmail.com>
Message-ID: <C2FE6949-666C-4E1E-A5B1-BFF9B61C95E6@omniti.com>

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 <miniflowtrader at gmail.com> wrote:
> 
> Thanks Dan. Have the LX zone patches been added in?
> 
>> On Wed, Feb 1, 2017 at 6:58 AM Dominik Hassler <hasslerd at gmx.li> 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 <current-BE>" -- 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/<rpool-drive>
>> >   rm /rpool/boot/menu.lst
>> >   beadm activate <current-BE>  (should reconstruct /rpool/boot/menu.lst)
>> >
>> > If you have mirrored roots, do the above installboot for each <rpool-drive>.
>> >
>> >
>> > 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/<rpool-drive>
>> >
>> > If you have mirrored roots, use "installgrub -M /dev/rdsk/<installed-drive> /dev/rdsk/<mirror-drive>
>> >
>> >
>> > 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170201/a5c9d762/attachment.html>

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: <C2FE6949-666C-4E1E-A5B1-BFF9B61C95E6@omniti.com>
References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com>
	<44FDE281-F712-4366-ABC9-939DC8616872@omniti.com>
	<7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li>
	<CACFEqhvAUdEEyYrXO-zZ59tRZ0Tu=X2GvurSsZg9gGHXddfvTQ@mail.gmail.com>
	<C2FE6949-666C-4E1E-A5B1-BFF9B61C95E6@omniti.com>
Message-ID: <CACFEqhuTXdXjLsHNmVJzzf9p+DCdNJ3PdEh4jXEMqC5_z2oo1w@mail.gmail.com>

Has the bug we found been fixed?

On Wed, Feb 1, 2017 at 11:04 AM Dan McDonald <danmcd at omniti.com> 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 <miniflowtrader at gmail.com> wrote:
>
> Thanks Dan. Have the LX zone patches been added in?
>
> On Wed, Feb 1, 2017 at 6:58 AM Dominik Hassler <hasslerd at gmx.li> 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 <current-BE>" -- 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/<rpool-drive>
> >   rm /rpool/boot/menu.lst
> >   beadm activate <current-BE>  (should reconstruct /rpool/boot/menu.lst)
> >
> > If you have mirrored roots, do the above installboot for each
> <rpool-drive>.
> >
> >
> > 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/<rpool-drive>
> >
> > If you have mirrored roots, use "installgrub -M
> /dev/rdsk/<installed-drive> /dev/rdsk/<mirror-drive>
> >
> >
> > 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170201/a43adb36/attachment-0001.html>

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: <CACFEqhuTXdXjLsHNmVJzzf9p+DCdNJ3PdEh4jXEMqC5_z2oo1w@mail.gmail.com>
References: <56665CFC-CFC4-4E5F-B1F2-99E957A59762@omniti.com>
	<44FDE281-F712-4366-ABC9-939DC8616872@omniti.com>
	<7f84e0f4-f7a0-4c7f-7441-2175c797676c@gmx.li>
	<CACFEqhvAUdEEyYrXO-zZ59tRZ0Tu=X2GvurSsZg9gGHXddfvTQ@mail.gmail.com>
	<C2FE6949-666C-4E1E-A5B1-BFF9B61C95E6@omniti.com>
	<CACFEqhuTXdXjLsHNmVJzzf9p+DCdNJ3PdEh4jXEMqC5_z2oo1w@mail.gmail.com>
Message-ID: <1B335D76-F6F8-4E0A-8C05-CCB36E818B8F@omniti.com>


> On Feb 1, 2017, at 3:05 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CALeZrrRM2KsSbOTYsNrMnJTaNm9_7hWqmJsi+Dx+jze45mOxDQ@mail.gmail.com>
References: <CALeZrrRM2KsSbOTYsNrMnJTaNm9_7hWqmJsi+Dx+jze45mOxDQ@mail.gmail.com>
Message-ID: <CALeZrrQ2=UbPMau7toDciEwdVBd7kuhUmOZJFXF7g7MMyeYv9Q@mail.gmail.com>

---------- Forwarded message ----------
From: Schweiss, Chip <chip at innovates.com>
Date: Wed, Feb 1, 2017 at 8:58 PM
Subject: NFS server unresponsive
To: zfs <zfs at lists.illumos.org>


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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170201/e10e9173/attachment.html>

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: <CAGueQCcC_2iuLtoCwFYhYhhDDf2gR68zVBDnrHWzLtEX1ETcUQ@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170202/c4802fe3/attachment.html>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170202/d4f31c6e/attachment.bin>

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: <CALeZrrQ2=UbPMau7toDciEwdVBd7kuhUmOZJFXF7g7MMyeYv9Q@mail.gmail.com>
References: <CALeZrrRM2KsSbOTYsNrMnJTaNm9_7hWqmJsi+Dx+jze45mOxDQ@mail.gmail.com>
	<CALeZrrQ2=UbPMau7toDciEwdVBd7kuhUmOZJFXF7g7MMyeYv9Q@mail.gmail.com>
Message-ID: <20170202074414.243832c6@sleipner.datanom.net>

On Wed, 1 Feb 2017 20:59:24 -0600
"Schweiss, Chip" <chip at innovates.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170202/4d81485e/attachment.bin>

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<mailto:leonard_deguzman at comcast.com>
W:  https://icollaborate.webex.com/join/leonard_deguzman

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

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 <vab at bb-c.de> 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: <alpine.GSO.2.20.1702031726001.27037@freddy.simplesystems.org>

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: <EBB756DF-8A70-4C62-8F48-40CC375597B1@omniti.com>

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: <CABv8qqtKEVz0p_2h+ZyKDRGeNatzNCnhac9g0PQ3Aj6m7JEKrw@mail.gmail.com>
References: <EBB756DF-8A70-4C62-8F48-40CC375597B1@omniti.com>
	<CABv8qqtKEVz0p_2h+ZyKDRGeNatzNCnhac9g0PQ3Aj6m7JEKrw@mail.gmail.com>
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 <sebastien.roy at delphix.com> 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 <danmcd at omniti.com> 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: <EBB756DF-8A70-4C62-8F48-40CC375597B1@omniti.com>
References: <EBB756DF-8A70-4C62-8F48-40CC375597B1@omniti.com>
Message-ID: <4DC47804-3336-4EFC-BAC4-63AAF89FE96B@omniti.com>


> On Feb 8, 2017, at 4:40 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> I'm expecting yes for r151020, but I'm not sure about r151014 (LTS).

<SNIP!>

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

<http://www.exitas.be/>

	
	

**Dirk Willems* *
System Engineer

	

*+32 (0)3 443 12 38* <tel:003234431238>

	

*dirk.willems at exitas.be* <mailto:dirk.willems at exitas.be>

	

*Veldkant 31 - 2550 Kontich* <https://goo.gl/maps/2fuSkEZe3Lz>

	

*www.exitas.be* <http://www.exitas.be>

*Disclaimer* <http://www.exitas.be/legal/disclaimer/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/5922eedb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exitas_PMS.png
Type: image/png
Size: 8486 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/5922eedb/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gsm.png
Type: image/png
Size: 524 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/5922eedb/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mail.png
Type: image/png
Size: 791 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/5922eedb/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plaats.png
Type: image/png
Size: 803 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/5922eedb/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: huis.png
Type: image/png
Size: 796 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/5922eedb/attachment-0009.png>

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>
	<CACFEqhvAUdEEyYrXO-zZ59tRZ0Tu=X2GvurSsZg9gGHXddfvTQ@mail.gmail.com>
	<C2FE6949-666C-4E1E-A5B1-BFF9B61C95E6@omniti.com>
	<CACFEqhuTXdXjLsHNmVJzzf9p+DCdNJ3PdEh4jXEMqC5_z2oo1w@mail.gmail.com>
	<1B335D76-F6F8-4E0A-8C05-CCB36E818B8F@omniti.com>
	<CAED-Y_D44jseVxEWfix+ff0adcJGxgou-ntbwusGHC2Fhz4gKg@mail.gmail.com>
	<08F8EEAB-294F-4B71-AF02-AB0D5AF63C5A@omniti.com>
Message-ID: <CAED-Y_C6DxxB=ahP3Lm90=aD0hj=KuvHHNFQsyPaL7Q1bMMegw@mail.gmail.com>

OK. Thanks for quick reply.

Cheers,
Krzysztof

2017-02-09 17:14 GMT+01:00 Dan McDonald <danmcd at omniti.com>:

>
> > On Feb 9, 2017, at 5:09 AM, Krzysztof Grzempa <grzempek at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/706a4896/attachment.html>

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: <FEE044C7-26B9-4187-A98D-6BB84E3B8634@omniti.com>


> On Feb 9, 2017, at 11:28 AM, Dirk Willems <dirk.willems at exitas.be> 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: <FEE044C7-26B9-4187-A98D-6BB84E3B8634@omniti.com>
References: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be>
	<FEE044C7-26B9-4187-A98D-6BB84E3B8634@omniti.com>
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 <dirk.willems at exitas.be> 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
>

-- 

<http://www.exitas.be/>

	
	

**Dirk Willems* *
System Engineer

	

*+32 (0)3 443 12 38* <tel:003234431238>

	

*dirk.willems at exitas.be* <mailto:dirk.willems at exitas.be>

	

*Veldkant 31 - 2550 Kontich* <https://goo.gl/maps/2fuSkEZe3Lz>

	

*www.exitas.be* <http://www.exitas.be>

*Disclaimer* <http://www.exitas.be/legal/disclaimer/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/fcec1534/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exitas_PMS.png
Type: image/png
Size: 8486 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/fcec1534/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gsm.png
Type: image/png
Size: 524 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/fcec1534/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mail.png
Type: image/png
Size: 791 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/fcec1534/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plaats.png
Type: image/png
Size: 803 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/fcec1534/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: huis.png
Type: image/png
Size: 796 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170209/fcec1534/attachment-0009.png>

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: <alpine.GSO.2.20.1702092009130.2297@freddy.simplesystems.org>

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: <alpine.GSO.2.20.1702092048490.2297@freddy.simplesystems.org>

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: <alpine.GSO.2.20.1702092048490.2297@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1702092048490.2297@freddy.simplesystems.org>
Message-ID: <CAEwA5n+fppFrUvW_099Kr8q4FU3sjtHKdfLrNXvbj2AfwK_qYw@mail.gmail.com>

On 9 February 2017 at 18:58, Bob Friesenhahn
<bfriesen at simple.dallas.tx.us> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170210/6f36cd83/attachment.html>

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 <andre at ak47.co.za> 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: <CAEwA5n+fppFrUvW_099Kr8q4FU3sjtHKdfLrNXvbj2AfwK_qYw@mail.gmail.com>
References: <alpine.GSO.2.20.1702092048490.2297@freddy.simplesystems.org>
	<CAEwA5n+fppFrUvW_099Kr8q4FU3sjtHKdfLrNXvbj2AfwK_qYw@mail.gmail.com>
Message-ID: <alpine.GSO.2.20.1702100828550.2297@freddy.simplesystems.org>

On Thu, 9 Feb 2017, Joshua M. Clulow wrote:

> On 9 February 2017 at 18:58, Bob Friesenhahn
> <bfriesen at simple.dallas.tx.us> 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: <alpine.GSO.2.20.1702092009130.2297@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1702092009130.2297@freddy.simplesystems.org>
Message-ID: <A0737B2B-8EC6-442A-A537-7EAB7EA958F1@omniti.com>


> On Feb 9, 2017, at 9:13 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170210/b9c3254a/attachment.bin>

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>
	<FEE044C7-26B9-4187-A98D-6BB84E3B8634@omniti.com>
	<440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be>
Message-ID: <FD52BDFF-4B20-430C-A4F3-6958A2A8C6C7@cos.ru>

9 ??????? 2017??. 18:09:04 CET, Dirk Willems <dirk.willems at 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 <dirk.willems at exitas.be>
>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: <FD52BDFF-4B20-430C-A4F3-6958A2A8C6C7@cos.ru>
References: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be>
	<FEE044C7-26B9-4187-A98D-6BB84E3B8634@omniti.com>
	<440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be>
	<FD52BDFF-4B20-430C-A4F3-6958A2A8C6C7@cos.ru>
Message-ID: <bd258be6-0d52-3dbc-0b3e-3579200a332f@exitas.be>

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 <dirk.willems at 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 <dirk.willems at exitas.be>
>> 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

-- 

<http://www.exitas.be/>

	
	

**Dirk Willems* *
System Engineer

	

*+32 (0)3 443 12 38* <tel:003234431238>

	

*dirk.willems at exitas.be* <mailto:dirk.willems at exitas.be>

	

*Veldkant 31 - 2550 Kontich* <https://goo.gl/maps/2fuSkEZe3Lz>

	

*www.exitas.be* <http://www.exitas.be>

*Disclaimer* <http://www.exitas.be/legal/disclaimer/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/9b71c219/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exitas_PMS.png
Type: image/png
Size: 8486 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/9b71c219/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gsm.png
Type: image/png
Size: 524 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/9b71c219/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mail.png
Type: image/png
Size: 791 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/9b71c219/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plaats.png
Type: image/png
Size: 803 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/9b71c219/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: huis.png
Type: image/png
Size: 796 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/9b71c219/attachment-0009.png>

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: <bd258be6-0d52-3dbc-0b3e-3579200a332f@exitas.be>
References: <7b9e010b-5ec3-919d-fe1d-1af554eba3bb@exitas.be>
	<FEE044C7-26B9-4187-A98D-6BB84E3B8634@omniti.com>
	<440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be>
	<FD52BDFF-4B20-430C-A4F3-6958A2A8C6C7@cos.ru>
	<bd258be6-0d52-3dbc-0b3e-3579200a332f@exitas.be>
Message-ID: <35F3CBA5-0E03-4E96-B419-7D50203BE4D9@cos.ru>

12 ??????? 2017??. 16:08:11 CET, Dirk Willems <dirk.willems at exitas.be> ?????:
>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 <dirk.willems at 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 <dirk.willems at exitas.be>
>>> 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>
	<FEE044C7-26B9-4187-A98D-6BB84E3B8634@omniti.com>
	<440a6f3d-0f25-68a1-2b55-24dff25eda99@exitas.be>
	<FD52BDFF-4B20-430C-A4F3-6958A2A8C6C7@cos.ru>
	<bd258be6-0d52-3dbc-0b3e-3579200a332f@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 <dirk.willems at exitas.be> ?????:
>> 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 <dirk.willems at 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 <dirk.willems at exitas.be>
>>>> 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

-- 

<http://www.exitas.be/>

	
	

**Dirk Willems* *
System Engineer

	

*+32 (0)3 443 12 38* <tel:003234431238>

	

*dirk.willems at exitas.be* <mailto:dirk.willems at exitas.be>

	

*Veldkant 31 - 2550 Kontich* <https://goo.gl/maps/2fuSkEZe3Lz>

	

*www.exitas.be* <http://www.exitas.be>

*Disclaimer* <http://www.exitas.be/legal/disclaimer/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/68380c8e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exitas_PMS.png
Type: image/png
Size: 8486 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/68380c8e/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gsm.png
Type: image/png
Size: 524 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/68380c8e/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mail.png
Type: image/png
Size: 791 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/68380c8e/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plaats.png
Type: image/png
Size: 803 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/68380c8e/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: huis.png
Type: image/png
Size: 796 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170212/68380c8e/attachment-0009.png>

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: <d437894f-aa1f-084a-f286-95345777b45e@ak47.co.za>
References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za>
	<07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com>
	<d437894f-aa1f-084a-f286-95345777b45e@ak47.co.za>
Message-ID: <fa6b3335-ff5f-d6cc-dcd8-4131623130a9@ak47.co.za>



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<andre at ak47.co.za>  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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170214/67c3cb1e/attachment.html>

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: <fa6b3335-ff5f-d6cc-dcd8-4131623130a9@ak47.co.za>
References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za>
	<07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com>
	<d437894f-aa1f-084a-f286-95345777b45e@ak47.co.za>
	<fa6b3335-ff5f-d6cc-dcd8-4131623130a9@ak47.co.za>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170214/855fd68b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170214/855fd68b/attachment.bin>

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>
	<d437894f-aa1f-084a-f286-95345777b45e@ak47.co.za>
	<fa6b3335-ff5f-d6cc-dcd8-4131623130a9@ak47.co.za>
	<943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de>
Message-ID: <b01e66d7-6f41-1f00-288b-14407202b6c1@ak47.co.za>



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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170214/32e1095f/attachment-0001.html>

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: <fa6b3335-ff5f-d6cc-dcd8-4131623130a9@ak47.co.za>
References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za>
	<07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com>
	<d437894f-aa1f-084a-f286-95345777b45e@ak47.co.za>
	<fa6b3335-ff5f-d6cc-dcd8-4131623130a9@ak47.co.za>
Message-ID: <6DCE930B-F26C-41E1-9B4A-E0822A4E9856@omniti.com>


> On Feb 14, 2017, at 7:02 AM, Andre Kruger <andre at ak47.co.za> 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: <b01e66d7-6f41-1f00-288b-14407202b6c1@ak47.co.za>
References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za>
	<07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com>
	<d437894f-aa1f-084a-f286-95345777b45e@ak47.co.za>
	<fa6b3335-ff5f-d6cc-dcd8-4131623130a9@ak47.co.za>
	<943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<b01e66d7-6f41-1f00-288b-14407202b6c1@ak47.co.za>
Message-ID: <35F997F1-A0D7-4808-987A-78EF7AD82B07@polarshift.fi>


> On 14 Feb 2017, at 16.06, Andre Kruger <andre at ak47.co.za> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170214/fcbc6418/attachment.html>

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: <b01e66d7-6f41-1f00-288b-14407202b6c1@ak47.co.za>
References: <9c7ba38c-9526-52f4-f7fd-778e1bda4463@ak47.co.za>
	<07C88117-83C8-4307-A9AB-FB813D75134D@omniti.com>
	<d437894f-aa1f-084a-f286-95345777b45e@ak47.co.za>
	<fa6b3335-ff5f-d6cc-dcd8-4131623130a9@ak47.co.za>
	<943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<b01e66d7-6f41-1f00-288b-14407202b6c1@ak47.co.za>
Message-ID: <CEBD8A58-0ACA-4FFF-A6F9-9821FB0A1A73@cos.ru>

14 ??????? 2017??. 15:06:37 CET, Andre Kruger <andre at ak47.co.za> ?????:
>
>
>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: <CAOAS_++XthB-Q5Ow4k8E-pzS8--6FXLSj2sNee2mF_pQdGBwSg@mail.gmail.com>

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: <CAOAS_++XthB-Q5Ow4k8E-pzS8--6FXLSj2sNee2mF_pQdGBwSg@mail.gmail.com>
References: <CAOAS_++XthB-Q5Ow4k8E-pzS8--6FXLSj2sNee2mF_pQdGBwSg@mail.gmail.com>
Message-ID: <68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com>


> On Feb 14, 2017, at 12:19 PM, Serge Fonville <serge.fonville at gmail.com> 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: <CAOAS_++XthB-Q5Ow4k8E-pzS8--6FXLSj2sNee2mF_pQdGBwSg@mail.gmail.com>
	<68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com>
Message-ID: <CAOAS_++EYVpAwTdRYxV7-3jnP4SqcV1Tiz2=6=Vtf7_ho=4xEQ@mail.gmail.com>

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 <danmcd at omniti.com>:
>
>> On Feb 14, 2017, at 12:19 PM, Serge Fonville <serge.fonville at gmail.com> 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: <CAOAS_++EYVpAwTdRYxV7-3jnP4SqcV1Tiz2=6=Vtf7_ho=4xEQ@mail.gmail.com>
References: <CAOAS_++XthB-Q5Ow4k8E-pzS8--6FXLSj2sNee2mF_pQdGBwSg@mail.gmail.com>
	<68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com>
	<CAOAS_++EYVpAwTdRYxV7-3jnP4SqcV1Tiz2=6=Vtf7_ho=4xEQ@mail.gmail.com>
Message-ID: <9ED05CC5-F0E4-4C44-9AAE-4D17DF3E3577@omniti.com>


> On Feb 14, 2017, at 1:28 PM, Serge Fonville <serge.fonville at gmail.com> 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>
	<d437894f-aa1f-084a-f286-95345777b45e@ak47.co.za>
	<fa6b3335-ff5f-d6cc-dcd8-4131623130a9@ak47.co.za>
	<943536713.30.1487079456479.JavaMail.stephan.budach@stephan.budach.jvm.de>
	<b01e66d7-6f41-1f00-288b-14407202b6c1@ak47.co.za>
	<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 <andre at ak47.co.za 
>> <mailto:andre at ak47.co.za>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170214/bea20a98/attachment.html>

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: <CAOAS_++XthB-Q5Ow4k8E-pzS8--6FXLSj2sNee2mF_pQdGBwSg@mail.gmail.com>
	<68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com>
	<CAOAS_++EYVpAwTdRYxV7-3jnP4SqcV1Tiz2=6=Vtf7_ho=4xEQ@mail.gmail.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 <danmcd at omniti.com> 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: <CAOAS_++XthB-Q5Ow4k8E-pzS8--6FXLSj2sNee2mF_pQdGBwSg@mail.gmail.com>
	<68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com>
	<CAOAS_++EYVpAwTdRYxV7-3jnP4SqcV1Tiz2=6=Vtf7_ho=4xEQ@mail.gmail.com>
	<9ED05CC5-F0E4-4C44-9AAE-4D17DF3E3577@omniti.com>
	<97896EAC-D540-478F-AE32-60605E59B4DE@omniti.com>
Message-ID: <CAOAS_+LSe6g2eNVDL_aoXF5UiyGrg-zW+obbvDC9965OeLwnFQ@mail.gmail.com>

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 <danmcd at omniti.com>:
>
>> On Feb 14, 2017, at 1:39 PM, Dan McDonald <danmcd at omniti.com> 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: <CAOAS_+LSe6g2eNVDL_aoXF5UiyGrg-zW+obbvDC9965OeLwnFQ@mail.gmail.com>
References: <CAOAS_++XthB-Q5Ow4k8E-pzS8--6FXLSj2sNee2mF_pQdGBwSg@mail.gmail.com>
	<68956BEB-05D5-4502-8E34-5790BB5610E6@omniti.com>
	<CAOAS_++EYVpAwTdRYxV7-3jnP4SqcV1Tiz2=6=Vtf7_ho=4xEQ@mail.gmail.com>
	<9ED05CC5-F0E4-4C44-9AAE-4D17DF3E3577@omniti.com>
	<97896EAC-D540-478F-AE32-60605E59B4DE@omniti.com>
	<CAOAS_+LSe6g2eNVDL_aoXF5UiyGrg-zW+obbvDC9965OeLwnFQ@mail.gmail.com>
Message-ID: <f9660313-a40f-a806-4097-8411f010f9a5@marzocchi.net>

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 <danmcd at omniti.com>:
>>
>>> On Feb 14, 2017, at 1:39 PM, Dan McDonald <danmcd at omniti.com> 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: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>

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: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
References: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
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: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
References: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
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: <mailman.1232.1487178987.6317.omnios-discuss@lists.omniti.com>
References: <mailman.1232.1487178987.6317.omnios-discuss@lists.omniti.com>
Message-ID: <aaa490d9-cfbc-852b-ae71-650b4a0b7c56@iis.ee.ethz.ch>



On 15/02/17 18:16, omnios-discuss-request at lists.omniti.com wrote:
> From: F?bio Rabelo <fabio at fabiorabelo.wiki.br>
> To: omnios-discuss <omnios-discuss at lists.omniti.com>
> Subject: [OmniOS-discuss] SMB and Netatalk
> Message-ID:
> 	<CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA at mail.gmail.com>
> 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: <aaa490d9-cfbc-852b-ae71-650b4a0b7c56@iis.ee.ethz.ch>
References: <mailman.1232.1487178987.6317.omnios-discuss@lists.omniti.com>
	<aaa490d9-cfbc-852b-ae71-650b4a0b7c56@iis.ee.ethz.ch>
Message-ID: <911825537.794.1487237636308.JavaMail.stephan.budach@stephanbudach.local>



----- Urspr?ngliche Mail -----
Von: "Adam Feigin" <feigin at iis.ee.ethz.ch>
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 <fabio at fabiorabelo.wiki.br>
> To: omnios-discuss <omnios-discuss at lists.omniti.com>
> Subject: [OmniOS-discuss] SMB and Netatalk
> Message-ID:
> 	<CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA at mail.gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170216/1ae6ca2a/attachment.bin>

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: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
References: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
Message-ID: <CANKMAMZxLnPoGyjQpwZK=j4kB5jFAebZseRHeavVYXx7m8x-1A@mail.gmail.com>

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 <fabio at fabiorabelo.wiki.br>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170216/6e9c1659/attachment-0001.html>

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: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
References: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
Message-ID: <DB38F378-B417-4826-88CB-80241C326050@ferebee.net>

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.

	<https://sourceforge.net/p/netatalk/mailman/message/32660961/>

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 <fabio at fabiorabelo.wiki.br>:
> 
> 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: <DB38F378-B417-4826-88CB-80241C326050@ferebee.net>
References: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
	<DB38F378-B417-4826-88CB-80241C326050@ferebee.net>
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" <omnios-discuss-bounces at lists.omniti.com on behalf of cf at ferebee.net> 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.
    
    	<https://sourceforge.net/p/netatalk/mailman/message/32660961/>
    
    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 <fabio at fabiorabelo.wiki.br>:
    > 
    > 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: <CANKMAMZxLnPoGyjQpwZK=j4kB5jFAebZseRHeavVYXx7m8x-1A@mail.gmail.com>
References: <CAEekY64bHSOJnQ1n+Ct7gyj5KgAKaGALzJPabEycBWjq+E70wA@mail.gmail.com>
	<CANKMAMZxLnPoGyjQpwZK=j4kB5jFAebZseRHeavVYXx7m8x-1A@mail.gmail.com>
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 <davide.poletto at gmail.com> 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
><fabio at fabiorabelo.wiki.br>
>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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170216/3c95e634/attachment.html>

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: <alpine.GSO.2.00.1702161205380.25111@erncre.pvgehf-vg.arg>


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: <alpine.GSO.2.00.1702161205380.25111@erncre.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1702161205380.25111@erncre.pvgehf-vg.arg>
Message-ID: <61E0D396-F530-4AAB-8217-F4ADA1968C7D@omniti.com>


> On Feb 16, 2017, at 7:06 AM, Andy Fiddaman <omnios at citrus-it.net> 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] (<solaris_install.data_object.cache.DataObjectCache object at 0x7ffffdc96a90>)
        -> [persistent] (DataObjectCacheChild: persistent)
                -> [sysconfig] (<solaris_install.sysconfig.profile.ConfigProfile object at 0x7ffffb5d1710>)
                -> [discovered] (<solaris_install.target.Target object at 0x7ffffb480690>)
                        -> [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] (<solaris_install.engine.EngineData object at 0x7ffffb480cd0>)
                        -> [TargetDiscovery] (<solaris_install.engine.checkpoint_data.CheckpointRegistrationData object at 0x7ffffb5ed710>)
                -> [desired] (<solaris_install.target.Target object at 0x7ffffb480910>)
                        -> [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] (<solaris_install.data_object.data_dict.DataObjectDict object at 0x7ffffb5d1790>)
                -> [transfer-ti-files] (<solaris_install.data_object.data_dict.DataObjectDict object at 0x7ffffb4de450>)
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 <Unknown-Unknown-0001 cyl 2088 alt 0 hd 255 sec 63>
          /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: <F73614BF-F7F4-4D90-9EAF-755BC73B6027@omniti.com>

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 <lukasstraub2 at web.de> 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] (<solaris_install.data_object.cache.DataObjectCache object at 0x7ffffdc96a90>)
>        -> [persistent] (DataObjectCacheChild: persistent)
>                -> [sysconfig] (<solaris_install.sysconfig.profile.ConfigProfile object at 0x7ffffb5d1710>)
>                -> [discovered] (<solaris_install.target.Target object at 0x7ffffb480690>)
>                        -> [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] (<solaris_install.engine.EngineData object at 0x7ffffb480cd0>)
>                        -> [TargetDiscovery] (<solaris_install.engine.checkpoint_data.CheckpointRegistrationData object at 0x7ffffb5ed710>)
>                -> [desired] (<solaris_install.target.Target object at 0x7ffffb480910>)
>                        -> [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] (<solaris_install.data_object.data_dict.DataObjectDict object at 0x7ffffb5d1790>)
>                -> [transfer-ti-files] (<solaris_install.data_object.data_dict.DataObjectDict object at 0x7ffffb4de450>)
> 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 <Unknown-Unknown-0001 cyl 2088 alt 0 hd 255 sec 63>
>          /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: <OFCD3C7C85.888E34BC-ONC12580CC.002B57A3-C12580CC.002C93F3@inse.com>

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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>

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 <https://www.illumos.org/issues/5698>
via this commit:
https://github.com/illumos/illumos-gate/commit/2482ae1b96a558eec551575934d5f06c87b807af <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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170219/1cbe4bb1/attachment.html>

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: <OFCD3C7C85.888E34BC-ONC12580CC.002B57A3-C12580CC.002C93F3@inse.com>
References: <OFCD3C7C85.888E34BC-ONC12580CC.002B57A3-C12580CC.002C93F3@inse.com>
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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
References: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
Message-ID: <AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>


> On Feb 19, 2017, at 9:13 PM, Michael Talbott <mtalbott at lji.org> 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: <AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
References: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
Message-ID: <20170220171742.67f665b5@sleipner.datanom.net>

On Mon, 20 Feb 2017 10:51:18 -0500
Dan McDonald <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
No animal should ever jump on the dining room furniture unless
absolutely certain he can hold his own in conversation.
		-- Fran Lebowitz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170220/a9254c4e/attachment.bin>

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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<20170220171742.67f665b5@sleipner.datanom.net>
Message-ID: <44AC1854-BD5F-42E8-A4A7-77048BBF9B6E@omniti.com>


> On Feb 20, 2017, at 11:17 AM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Mon, 20 Feb 2017 10:51:18 -0500
> Dan McDonald <danmcd at omniti.com> 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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<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 <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170220/58e12624/attachment.bin>

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>,
	<OFCD3C7C85.888E34BC-ONC12580CC.002B57A3-C12580CC.002C93F3@inse.com>
Message-ID: <OFDA2A1BE2.BB1F396B-ONC12580CD.005B6EFE-C12580CD.005C7801@inse.com>


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 <danmcd at omniti.com> skrev: -----
Till: Johan Kragsterman <johan.kragsterman at capvert.se>
Fr?n: Dan McDonald <danmcd at omniti.com>
Datum: 2017-02-20 16:33
Kopia: omnios-discuss <omnios-discuss at lists.omniti.com>, Dan McDonald <danmcd at omniti.com>
?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: <OFDA2A1BE2.BB1F396B-ONC12580CD.005B6EFE-C12580CD.005C7801@inse.com>
References: <0D0272FD-3929-4E9D-AF21-1D283A53023B@omniti.com>
	<OFCD3C7C85.888E34BC-ONC12580CC.002B57A3-C12580CC.002C93F3@inse.com>
	<OFDA2A1BE2.BB1F396B-ONC12580CD.005B6EFE-C12580CD.005C7801@inse.com>
Message-ID: <F2AD0100-7CCC-431E-AC24-AD0CE76F6439@omniti.com>


> On Feb 20, 2017, at 11:50 AM, Johan Kragsterman <johan.kragsterman at capvert.se> 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: <F2AD0100-7CCC-431E-AC24-AD0CE76F6439@omniti.com>
References: <F2AD0100-7CCC-431E-AC24-AD0CE76F6439@omniti.com>,
	<0D0272FD-3929-4E9D-AF21-1D283A53023B@omniti.com>
	<OFCD3C7C85.888E34BC-ONC12580CC.002B57A3-C12580CC.002C93F3@inse.com>
	<OFDA2A1BE2.BB1F396B-ONC12580CD.005B6EFE-C12580CD.005C7801@inse.com>
Message-ID: <OF953EFF48.41F84F53-ONC12580CD.005E706A-C12580CD.005ED031@inse.com>


Hi!


-----Dan McDonald <danmcd at omniti.com> skrev: -----
Till: Johan Kragsterman <johan.kragsterman at capvert.se>
Fr?n: Dan McDonald <danmcd at omniti.com>
Datum: 2017-02-20 17:54
Kopia: omnios-discuss <omnios-discuss at lists.omniti.com>, Dan McDonald <danmcd at omniti.com>
?rende: Re: Ang: Re: [OmniOS-discuss] updating to openssh in ipkg zone

> On Feb 20, 2017, at 11:50 AM, Johan Kragsterman <johan.kragsterman at capvert.se> 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: <OF953EFF48.41F84F53-ONC12580CD.005E706A-C12580CD.005ED031@inse.com>
References: <F2AD0100-7CCC-431E-AC24-AD0CE76F6439@omniti.com>
	<0D0272FD-3929-4E9D-AF21-1D283A53023B@omniti.com>
	<OFCD3C7C85.888E34BC-ONC12580CC.002B57A3-C12580CC.002C93F3@inse.com>
	<OFDA2A1BE2.BB1F396B-ONC12580CD.005B6EFE-C12580CD.005C7801@inse.com>
	<OF953EFF48.41F84F53-ONC12580CD.005E706A-C12580CD.005ED031@inse.com>
Message-ID: <96980531-895C-4C8D-9F76-481C923F1318@omniti.com>


> On Feb 20, 2017, at 12:15 PM, Johan Kragsterman <johan.kragsterman at capvert.se> 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 <mailinglists at qutic.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170220/2704173e/attachment.bin>

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 <mir at miras.org> 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: <AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
References: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
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 <danmcd at omniti.com> 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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<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 <mtalbott at lji.org> 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: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>

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 <pkg>
- Updates <pkg> 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 <pkg>
- 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 <pkg>
- Updates <pkg> 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: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
References: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
Message-ID: <CACLsAptfVsnm8Pjp1bOVdm3P39Ymm=01+KpLh3dSMGL35Exr_g@mail.gmail.com>

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 <danmcd at omniti.com> 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 <pkg>
> - Updates <pkg> 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 <pkg>
> - 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 <pkg>
> - Updates <pkg> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170220/daaf9b04/attachment-0001.html>

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: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
References: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
Message-ID: <alpine.GSO.2.20.1702201643330.10843@scrappy.simplesystems.org>

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: <CACLsAptfVsnm8Pjp1bOVdm3P39Ymm=01+KpLh3dSMGL35Exr_g@mail.gmail.com>
References: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
	<CACLsAptfVsnm8Pjp1bOVdm3P39Ymm=01+KpLh3dSMGL35Exr_g@mail.gmail.com>
Message-ID: <4046678E-CF50-41A0-BBC1-FAFA4F10C86B@omniti.com>


> On Feb 20, 2017, at 5:37 PM, Theo Schlossnagle <jesus at omniti.com> 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: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
References: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
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: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
	<130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com>
Message-ID: <alpine.GSO.2.20.1702201711060.10843@scrappy.simplesystems.org>

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: <alpine.GSO.2.20.1702201711060.10843@scrappy.simplesystems.org>
References: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
	<130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com>
	<alpine.GSO.2.20.1702201711060.10843@scrappy.simplesystems.org>
Message-ID: <2EE1453A-48C3-40CB-B9FF-6C7E5E0A6EB8@omniti.com>


> On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
	<130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com>
	<alpine.GSO.2.20.1702201711060.10843@scrappy.simplesystems.org>
	<2EE1453A-48C3-40CB-B9FF-6C7E5E0A6EB8@omniti.com>
Message-ID: <alpine.GSO.2.20.1702202023260.9710@freddy.simplesystems.org>

On Mon, 20 Feb 2017, Dan McDonald wrote:

>
>> On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
	<130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com>
Message-ID: <D9BD05BD-A550-44F3-8C14-312542CA3366@polarshift.fi>


> On 2017-02-21, at 1.03, Dan McDonald <danmcd at omniti.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170221/f19a1475/attachment.html>

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: <alpine.GSO.2.20.1702202023260.9710@freddy.simplesystems.org>
References: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
	<130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com>
	<alpine.GSO.2.20.1702201711060.10843@scrappy.simplesystems.org>
	<2EE1453A-48C3-40CB-B9FF-6C7E5E0A6EB8@omniti.com>
	<alpine.GSO.2.20.1702202023260.9710@freddy.simplesystems.org>
Message-ID: <C4B15A22-20D2-4F9C-A3A9-583EFD80A34A@cos.ru>

21 ??????? 2017??. 3:24:58 CET, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> ?????:
>On Mon, 20 Feb 2017, Dan McDonald wrote:
>
>>
>>> On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn
><bfriesen at simple.dallas.tx.us> 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: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
	<130636BD-3399-4857-BE23-F1138D1BCAAA@omniti.com>
Message-ID: <alpine.GSO.2.00.1702211028300.11522@erncre.pvgehf-vg.arg>


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 <lkateley at kateley.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170221/53b8fa37/attachment.bin>

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: <d0cce392-6c12-95f0-da96-9bea9b08a299@kateley.com>

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 <lkateley at kateley.com> 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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
Message-ID: <D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>

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 <danmcd at omniti.com> wrote:
> 
> 
>> On Feb 20, 2017, at 1:39 PM, Michael Talbott <mtalbott at lji.org> 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: <D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
References: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
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 <mtalbott at lji.org> 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 <danmcd at omniti.com> wrote:
>> 
>> 
>>> On Feb 20, 2017, at 1:39 PM, Michael Talbott <mtalbott at lji.org> 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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
Message-ID: <F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>

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 <danmcd at omniti.com> 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 <mtalbott at lji.org> 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 <danmcd at omniti.com> wrote:
>>> 
>>> 
>>>> On Feb 20, 2017, at 1:39 PM, Michael Talbott <mtalbott at lji.org> 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: <CAHyo4tmBCm3fVm8AwnvuzChmqrNVsM+RNfbp0RyypezPgZRaqQ@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170222/7856fb45/attachment-0001.html>

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: <CAHyo4tmBCm3fVm8AwnvuzChmqrNVsM+RNfbp0RyypezPgZRaqQ@mail.gmail.com>
References: <CAHyo4tmBCm3fVm8AwnvuzChmqrNVsM+RNfbp0RyypezPgZRaqQ@mail.gmail.com>
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: <B1AE3F46-617E-4D04-81D1-0B1D2B4A5C36@gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170222/779308a5/attachment.html>

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: <F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>
References: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>
Message-ID: <8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com>


> On Feb 22, 2017, at 3:36 AM, Phil Harman <phil.harman at gmail.com> 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: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
References: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
Message-ID: <CAEgYsbE21ZkhECDTzcFj4zo2YLYQnZR+_h63MKYvk7OYT=uwFQ@mail.gmail.com>

On Mon, Feb 20, 2017 at 10:28 PM, Dan McDonald <danmcd at omniti.com> 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 <pkg>
> - Updates <pkg> 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 <pkg>
> - 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 <pkg>
> - Updates <pkg> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170222/cf803f4e/attachment.html>

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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.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 <phil.harman at gmail.com> 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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>
	<8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com>
	<2b787934-762e-d8cb-238e-31a9dad81271@will.to>
Message-ID: <a9649e27-8d7f-beb4-39d9-599ead701d21@will.to>

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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>
	<8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com>
	<2b787934-762e-d8cb-238e-31a9dad81271@will.to>
Message-ID: <AA56FFC2-DABE-4C88-A64B-B64CF5ECAF18@omniti.com>


> On Feb 22, 2017, at 11:55 AM, Doug Hughes <doug at will.to> 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: <CAEgYsbE21ZkhECDTzcFj4zo2YLYQnZR+_h63MKYvk7OYT=uwFQ@mail.gmail.com>
References: <BC89B33A-04AF-43ED-9977-678FD7D2F43F@omniti.com>
	<CAEgYsbE21ZkhECDTzcFj4zo2YLYQnZR+_h63MKYvk7OYT=uwFQ@mail.gmail.com>
Message-ID: <14832825-5E06-4B36-BC23-0ED5FBEDBC86@omniti.com>


> On Feb 22, 2017, at 11:35 AM, Peter Tribble <peter.tribble at gmail.com> 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 <specific-package>".


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: <AA56FFC2-DABE-4C88-A64B-B64CF5ECAF18@omniti.com>
References: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>
	<8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com>
	<2b787934-762e-d8cb-238e-31a9dad81271@will.to>
	<AA56FFC2-DABE-4C88-A64B-B64CF5ECAF18@omniti.com>
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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>
	<8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com>
	<2b787934-762e-d8cb-238e-31a9dad81271@will.to>
	<AA56FFC2-DABE-4C88-A64B-B64CF5ECAF18@omniti.com>
	<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 <doug at will.to> 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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>
	<8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com>
	<2b787934-762e-d8cb-238e-31a9dad81271@will.to>
	<AA56FFC2-DABE-4C88-A64B-B64CF5ECAF18@omniti.com>
	<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 <doug at will.to> 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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>
	<8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com>
	<2b787934-762e-d8cb-238e-31a9dad81271@will.to>
	<AA56FFC2-DABE-4C88-A64B-B64CF5ECAF18@omniti.com>
	<88befb5f-bf8f-1b5e-50bb-57fe8d561451@will.to>
Message-ID: <CAEgYsbEsHFVUfjiTkPTH=k4DnF66MpViBCZpZKgMq1kpLQufiQ@mail.gmail.com>

On Wed, Feb 22, 2017 at 5:23 PM, Doug Hughes <doug at will.to> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170222/6fc8c232/attachment.html>

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: <CAEgYsbEsHFVUfjiTkPTH=k4DnF66MpViBCZpZKgMq1kpLQufiQ@mail.gmail.com>
References: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.com>
	<8AC16C62-9916-4CEB-B7BD-24318397BFFC@omniti.com>
	<2b787934-762e-d8cb-238e-31a9dad81271@will.to>
	<AA56FFC2-DABE-4C88-A64B-B64CF5ECAF18@omniti.com>
	<88befb5f-bf8f-1b5e-50bb-57fe8d561451@will.to>
	<CAEgYsbEsHFVUfjiTkPTH=k4DnF66MpViBCZpZKgMq1kpLQufiQ@mail.gmail.com>
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 <doug at will.to 
> <mailto:doug at will.to>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170222/4c5f31e9/attachment.html>

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 <pkg>
- Updates <pkg> 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 <pkg>
- 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 <pkg>
- Updates <pkg> 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: <CC93A6B1-4234-4864-B47B-826DDECBE6D1@lji.org>
	<AFD2EE1F-7883-4E63-AE03-0B71FD472D98@omniti.com>
	<527F2A6B-02FD-4328-BD31-A4A9051ABC8D@lji.org>
	<1E8557C1-EC1D-43B0-BE72-FA70BC669865@omniti.com>
	<D34F2D26-B0C4-4DB3-ABF2-EFE6AFF9FE9B@lji.org>
	<0C204DBF-7F4E-4167-9526-661335EEDCD4@omniti.com>
	<F94C9D74-91D3-4CC4-B3FA-E32C080EC182@gmail.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 <danmcd at omniti.com> wrote:
> 
> 
>> On Feb 22, 2017, at 3:36 AM, Phil Harman <phil.harman at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170224/c15749f3/attachment.html>

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: <E7B92B14-779A-42A3-A935-0B433EE6F38F@omniti.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/f824bc30/attachment.bin>

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: <CAOpmc6xnMVG7RaWCvFtwOpP_zqhrSEGh4D2idNz-dOpThKpsfw@mail.gmail.com>

I could try it on libvirt/qemu.

On Feb 28, 2017 3:14 AM, "Stephan Budach" <stephan.budach at jvm.de> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/1c88026d/attachment.html>

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 <stephan.budach at jvm.de> 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 <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/6e9db4fd/attachment.bin>

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 <danmcd at omniti.com> 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 <danmcd at omniti.com> wrote:

> diskinfo(1M) or format(1M)
No found on the iso??

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/327bdc81/attachment.bin>

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: <F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>


> On Feb 28, 2017, at 12:48 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Tue, 28 Feb 2017 12:22:37 -0500
> Dan McDonald <danmcd at omniti.com> 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: <F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
Message-ID: <DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>


> On Feb 28, 2017, at 1:02 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> I messed something up in this ISO's construction.  Please wait, folks,

Okay...

1.) I've reconstructed the ISO, and diskinfo is available in the shell.

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: <DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
Message-ID: <20170228195845.09f5c4bf@sleipner.datanom.net>

On Tue, 28 Feb 2017 13:23:24 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> > On Feb 28, 2017, at 1:02 PM, Dan McDonald <danmcd at omniti.com> wrote:
> > 
> > I messed something up in this ISO's construction.  Please wait, folks,  
> 
> Okay...
> 
> 1.) I've reconstructed the ISO, and diskinfo is available in the shell.
> 
How should diskinfo be invoked?
When pressing menu '3' I see:
ok _
Doing
ok diskinfo gives:
  not found


-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
All generalizations are false, including this one.
		-- Mark Twain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/c74c36e7/attachment.bin>

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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
Message-ID: <A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>

I meant on the installer, not on LOADER.  Press return on loader (that's the GRUB repoacment) to boot illumos and then the installer.  You should see the SunOS banner THEN look for the OmniOS installation menu.

Dan

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

> On Feb 28, 2017, at 1:58 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Tue, 28 Feb 2017 13:23:24 -0500
> Dan McDonald <danmcd at omniti.com> wrote:
> 
>>> On Feb 28, 2017, at 1:02 PM, Dan McDonald <danmcd at omniti.com> wrote:
>>> 
>>> I messed something up in this ISO's construction.  Please wait, folks,  
>> 
>> Okay...
>> 
>> 1.) I've reconstructed the ISO, and diskinfo is available in the shell.
>> 
> How should diskinfo be invoked?
> When pressing menu '3' I see:
> ok _
> Doing
> ok diskinfo gives:
>  not found
> 
> 
> -- 
> Hilsen/Regards
> Michael Rasmussen
> 
> Get my public GnuPG keys:
> michael <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> /usr/games/fortune -es says:
> All generalizations are false, including this one.
>        -- Mark Twain
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

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: <A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<02C5C28D-790F-48FC-BB05-1A1444AF065D@omniti.com>
	<20170228184800.4119d335@sleipner.datanom.net>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
Message-ID: <20170228211230.12e605fa@sleipner.datanom.net>

On Tue, 28 Feb 2017 14:43:50 -0500
Dan McDonald <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
I 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/997fcc8b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/997fcc8b/attachment-0001.bin>

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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
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 <mir at miras.org> wrote:
> 
> On Tue, 28 Feb 2017 14:43:50 -0500
> Dan McDonald <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> /usr/games/fortune -es says:
> I get my exercise acting as pallbearer to my friends who exercise.
>        -- Chauncey Depew
> <Screenshot at 2017-02-28 21-11-25.png>

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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
Message-ID: <20170228220018.6705ed8e@sleipner.datanom.net>

On Tue, 28 Feb 2017 15:46:54 -0500
Dan McDonald <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
Q:	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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/70be5e63/attachment.bin>

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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
Message-ID: <20170228221543.27a5db05@sleipner.datanom.net>

On Tue, 28 Feb 2017 22:00:18 +0100
Michael Rasmussen <mir at miras.org> wrote:

> On Tue, 28 Feb 2017 15:46:54 -0500
> Dan McDonald <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
A 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/abe50e59/attachment.bin>

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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
Message-ID: <6812C576-A15D-48C0-BC87-4F7400E05F38@omniti.com>


> On Feb 28, 2017, at 4:00 PM, Michael Rasmussen <mir at miras.org> 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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
	<20170228221543.27a5db05@sleipner.datanom.net>
Message-ID: <20170228224637.597f060f@sleipner.datanom.net>

On Tue, 28 Feb 2017 22:15:43 +0100
Michael Rasmussen <mir at miras.org> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/2907cd8e/attachment.bin>

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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
	<20170228221543.27a5db05@sleipner.datanom.net>
	<20170228224637.597f060f@sleipner.datanom.net>
Message-ID: <20170228225028.41fb3642@sleipner.datanom.net>

On Tue, 28 Feb 2017 22:46:37 +0100
Michael Rasmussen <mir at miras.org> wrote:

> On Tue, 28 Feb 2017 22:15:43 +0100
> Michael Rasmussen <mir at miras.org> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
<frogbert> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/73346899/attachment-0001.bin>

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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
	<20170228221543.27a5db05@sleipner.datanom.net>
	<20170228224637.597f060f@sleipner.datanom.net>
	<20170228225028.41fb3642@sleipner.datanom.net>
Message-ID: <7F0EE08D-AFA1-4D93-A773-F2D48802212D@omniti.com>


> On Feb 28, 2017, at 4:50 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Tue, 28 Feb 2017 22:46:37 +0100
> Michael Rasmussen <mir at miras.org> wrote:
> 
>> On Tue, 28 Feb 2017 22:15:43 +0100
>> Michael Rasmussen <mir at miras.org> 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: <CAEgYsbGiW_pvB-01zmJ2tOhO8mzujp3tF7rSMJtj+VTRWz4VFQ@mail.gmail.com>

Dan,

On Mon, Feb 27, 2017 at 10:10 PM, Dan McDonald <danmcd at omniti.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/62200a57/attachment.html>

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: <CAEgYsbGiW_pvB-01zmJ2tOhO8mzujp3tF7rSMJtj+VTRWz4VFQ@mail.gmail.com>
References: <8F6C3B1D-5F7E-45DB-84F9-DA237D4E9F10@omniti.com>
	<CAEgYsbGiW_pvB-01zmJ2tOhO8mzujp3tF7rSMJtj+VTRWz4VFQ@mail.gmail.com>
Message-ID: <27CB83D1-4B09-436F-AA83-1D1CCCD06428@omniti.com>


> On Feb 28, 2017, at 5:22 PM, Peter Tribble <peter.tribble at gmail.com> wrote:
> 
> Dan,

<SNIP!>

> Ok, some comments (I'm wearing 2 hats here, one as an omnios
> customer, the other as someone who's actually written an installer):
> 
> Overall, I think I prefer it to Caiman. But then I was never a
> fan of Caiman, it was all so slow and klunky. 
> 
> The ISO is, how can I say this, rather bigger than before.

Yes.  This is because I wanted to get it running first.

I will note that if I used 7z instead of bzip2, I can shrink the ZFS image that lives in the ISO.

> Right, so you've dropped the good old solaris.zlib approach

Oddly enough, solaris.zlib uses 7z, IIRC.

> 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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
	<20170228221543.27a5db05@sleipner.datanom.net>
	<20170228224637.597f060f@sleipner.datanom.net>
	<20170228225028.41fb3642@sleipner.datanom.net>
	<7F0EE08D-AFA1-4D93-A773-F2D48802212D@omniti.com>
Message-ID: <20170228233609.0dcc738b@sleipner.datanom.net>

On Tue, 28 Feb 2017 17:16:56 -0500
Dan McDonald <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170228/05389761/attachment-0001.bin>

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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
	<20170228221543.27a5db05@sleipner.datanom.net>
	<20170228224637.597f060f@sleipner.datanom.net>
	<20170228225028.41fb3642@sleipner.datanom.net>
	<7F0EE08D-AFA1-4D93-A773-F2D48802212D@omniti.com>
	<20170228233609.0dcc738b@sleipner.datanom.net>
Message-ID: <20170301001220.5fd143f1@sleipner.datanom.net>

On Tue, 28 Feb 2017 23:36:09 +0100
Michael Rasmussen <mir at miras.org> wrote:

> On Tue, 28 Feb 2017 17:16:56 -0500
> Dan McDonald <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
I have 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170301/c2397c09/attachment.bin>

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>
	<F28785E5-CDB2-4D86-B842-197C92E9C357@omniti.com>
	<DA9969CB-0FB5-49F1-A656-4A9A5DE0AB37@omniti.com>
	<20170228195845.09f5c4bf@sleipner.datanom.net>
	<A69A6534-C1A6-4832-B12E-1E253DA40074@omniti.com>
	<20170228211230.12e605fa@sleipner.datanom.net>
	<7ECB58D6-8D3C-424B-9B8C-3ED9727D87A0@omniti.com>
	<20170228220018.6705ed8e@sleipner.datanom.net>
	<20170228221543.27a5db05@sleipner.datanom.net>
	<20170228224637.597f060f@sleipner.datanom.net>
	<20170228225028.41fb3642@sleipner.datanom.net>
	<7F0EE08D-AFA1-4D93-A773-F2D48802212D@omniti.com>
	<20170228233609.0dcc738b@sleipner.datanom.net>
	<20170301001220.5fd143f1@sleipner.datanom.net>
Message-ID: <20170301005530.7e7d1316@sleipner.datanom.net>

On Wed, 1 Mar 2017 00:12:20 +0100
Michael Rasmussen <mir at miras.org> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170301/f4b99b10/attachment.bin>

