From info.fmo at gmx.de  Mon May  1 14:41:08 2017
From: info.fmo at gmx.de (Frank M.)
Date: Mon, 1 May 2017 16:41:08 +0200
Subject: [OmniOS-discuss] network configuration script
In-Reply-To: <818292145.20170406004325@gmx.de>
References: <20170402233033.0a4747bf@sleipner.datanom.net>
	<818292145.20170406004325@gmx.de>
Message-ID: <1659697093.20170501164108@gmx.de>

Hi,

is there an update for vmware-users?
Where in the new downloaded iso I have to place my own config-script
or the py-script from Michael? I cannot find any in the iso
included files after boot/install... With the old installer there was
no problem.

Greets
Frank


Thursday, April 6, 2017, 12:43:25 AM, you wrote:

FM> Hello Michael, hello Dan,

FM> I find your idea great.
FM> Because it?s annoying to do the initial network configuration again
FM> and again in my test-installations I had integrated in my own
FM> OmniOS-ISO the Solaris-vmware-tools and a shellscript for automated
FM> installation. It is not perfect but it works for me...
FM> But it is also annoying to implement this in every new
FM> release-ISO...
FM> It would be great, if you can implement something to ease the setup
FM> for the millions of vmware-omnios users. ;-)
FM> Also your idea to implement for IPoIB is great - I also use IPoIB in
FM> some test-scenarios.

FM> Greets
FM> Frank

FM> Sunday, April 2, 2017, 11:30:33 PM, you wrote:

MR>> Hi all,

MR>> I think it is not very easy for new users coming to Omnios from various
MR>> other distros to make the initial network configuration so I have
MR>> written a small tool in Python to remedy this obstacle. The script runs
MR>> on all Omnios as of r151014. I have tested on r151014 and bloody
MR>> (r151021)

MR>> The script is not ment to be the swiss army knife for configuring
MR>> networks on Omnios so there is no support for vnic, vlan, and
MR>> aggregates. It will only support configuring a single nic given the
MR>> user the option for dhcp and static setup. The user is also asked
MR>> whether to configure dns in which case the user is asked for an IP.

MR>> Currently it will only handle ethernet but IPoIB is on my todo list. I
MR>> have attached the script here but if the file is to large it can also
MR>> be downloaded here: http://git.datanom.net/netconf.git/

MR>> PS. If I want to have it included in Omnios what license should I use?







-- 
Best regards,
 Frank                            mailto:info.fmo at gmx.de


From ozkan.goksu at usishi.com  Tue May  2 07:48:16 2017
From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=)
Date: Tue, 2 May 2017 10:48:16 +0300
Subject: [OmniOS-discuss] Why does samba use file permissions instead share
	permission?
Message-ID: <CAPu=dv3YuKgPdamoEgDJ5MzFWayKOdh3iCh2WcNJi_+KDeBaiA@mail.gmail.com>

Hello.
I want to give Share permission to my cifs share but i guess unix only able
to give file permission like:
> /usr/bin/chmod -R A+group@:full_set:fd:allow  pool/test

This is the bad way because i have couple of million file in some shares
and the job tooks almost days...
Every time i don't want to set every file in this directory.


> At Windows side file or folder has 2 different permission:
> 1- File permission.
> 2- Share permission.

> If i use Share permission i dont need to set chmod every file or folder
in directory. it tooks few seconds with that way.

Can i use the share permission on solaris?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170502/07596207/attachment.html>

From alka at hfg-gmuend.de  Tue May  2 10:42:39 2017
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Tue, 2 May 2017 12:42:39 +0200
Subject: [OmniOS-discuss] Why does samba use file permissions instead
 share permission?
In-Reply-To: <CAPu=dv3YuKgPdamoEgDJ5MzFWayKOdh3iCh2WcNJi_+KDeBaiA@mail.gmail.com>
References: <CAPu=dv3YuKgPdamoEgDJ5MzFWayKOdh3iCh2WcNJi_+KDeBaiA@mail.gmail.com>
Message-ID: <93cbab17-9a5a-1eee-087d-cb3271bcc755@hfg-gmuend.de>

Are you really using SAMBA?
SAMBA is available on Solarish but the default SMB server on Solarish is 
the kernelbased and in ZFS embedded SMB server that comes with full 
AD/nfs4 ACL support, ZFS snaps as Windows previous versions and Windows 
ntfs compatible file-based and share-based permissions.

If you only want sharebased permissions, you must set share permission 
as an ACL to the share control file pool/test/.zfs/shares/test. This 
file is automatically created when you enable SMB on a filesystem. As 
this is an additional restriction to file permission, keep filebased 
permissions unrestricted.

Gea

Am 02.05.2017 um 09:48 schrieb ?zkan G?ksu:
> Hello.
> I want to give Share permission to my cifs share but i guess unix only 
> able to give file permission like:
> > /usr/bin/chmod -R A+group@:full_set:fd:allow  pool/test
>
> This is the bad way because i have couple of million file in some 
> shares and the job tooks almost days...
> Every time i don't want to set every file in this directory.
>
>
> > At Windows side file or folder has 2 different permission:
> > 1- File permission.
> > 2- Share permission.
>
> > If i use Share permission i dont need to set chmod every file or folder in directory. it tooks few seconds with 
> that way.
>
> Can i use the share permission on solaris?
>
>
>
> _______________________________________________
> 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/20170502/12d5b1db/attachment.html>

From jimklimov at cos.ru  Tue May  2 13:45:06 2017
From: jimklimov at cos.ru (Jim Klimov)
Date: Tue, 02 May 2017 16:45:06 +0300
Subject: [OmniOS-discuss] Why does samba use file permissions instead
	share	permission?
In-Reply-To: <CAPu=dv3YuKgPdamoEgDJ5MzFWayKOdh3iCh2WcNJi_+KDeBaiA@mail.gmail.com>
References: <CAPu=dv3YuKgPdamoEgDJ5MzFWayKOdh3iCh2WcNJi_+KDeBaiA@mail.gmail.com>
Message-ID: <DAB1F6A6-62CF-4318-A28D-0515CCD4627A@cos.ru>

On May 2, 2017 10:48:16 AM GMT+03:00, "?zkan G?ksu" <ozkan.goksu at usishi.com> wrote:
>Hello.
>I want to give Share permission to my cifs share but i guess unix only
>able
>to give file permission like:
>> /usr/bin/chmod -R A+group@:full_set:fd:allow  pool/test
>
>This is the bad way because i have couple of million file in some
>shares
>and the job tooks almost days...
>Every time i don't want to set every file in this directory.
>
>
>> At Windows side file or folder has 2 different permission:
>> 1- File permission.
>> 2- Share permission.
>
>> If i use Share permission i dont need to set chmod every file or
>folder
>in directory. it tooks few seconds with that way.
>
>Can i use the share permission on solaris?

Take a look at the (normally hidden - so just go direct-access it) .zfs directory. You can set kernel-cifs share acl on datasetname/.zfs/shares/sharename object.
--
Typos courtesy of K-9 Mail on my Redmi Android

From robert at omniti.com  Tue May  2 15:47:47 2017
From: robert at omniti.com (Robert Treat)
Date: Tue, 2 May 2017 11:47:47 -0400
Subject: [OmniOS-discuss] The Future of OmniOS
In-Reply-To: <CAEgYsbF2SzZJWGvwMALL9HJNZzpy++jKXOApUHn8ASpsUrHjjg@mail.gmail.com>
References: <CA+FJ0zssZQW1mt7-wycczDfWE_=GzQonzcGgkxrE0Mk-dQBv9Q@mail.gmail.com>
	<00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org>
	<CA+FJ0zsmfxw9_BUE7HUuK8qMZQjH4HvuLo1Vsio70P6MGF+nNw@mail.gmail.com>
	<62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com>
	<CA+FJ0zuoRW12WjFdju+y3Bu9FpEkyKUXcP-PYNuYEWPppiu1pw@mail.gmail.com>
	<CAEgYsbF2SzZJWGvwMALL9HJNZzpy++jKXOApUHn8ASpsUrHjjg@mail.gmail.com>
Message-ID: <CA+FJ0ztwikagwxHwYi6qvhrxUfggN04sRRmDA5fVH5SdCKp05A@mail.gmail.com>

On Thu, Apr 27, 2017 at 4:07 PM, Peter Tribble <peter.tribble at gmail.com> wrote:
> On Thu, Apr 27, 2017 at 12:21 AM, Robert Treat <robert at omniti.com> wrote:
>>
>> I hope the answer to the best safest place is OmniOS. To that end, we have
>> no plans to stop running OmniOS at this time, and presuming the project can
>> make the jump to community maintainership, we won't need to develop any.
>
>
> So, assuming such a jump were to happen, what are we talking about?
>
> (My comments here, btw, are from me as an illumos community member
> and maintainer of another distro, rather than as an OmniOS customer.)
>
> Some items:
>
> The OmniOS name/brand
> The website/wiki
> The illumos-omnios fork (the code)
> The github repos (the infrastructure)
> The pkg repo servers
>
> What happens to those? The real question here is whether they stay,
> with community maintainership, or whether the "new" regime is an
> independent fork? I would guess the latter to be the safest course.
>
> That's assuming a world in which OmniOS-whatever remains as a separate
> entity, rather than taking the view that you throw it away and replace it
> with
> a stable branch of some other distro. I'm not entirely convinced that would
> (a) actually work, and (b) not compromise the other distro.
>
> So that gives you a newly forked project that maintains a distro based
> on the current OmniOS code (preserving the effort that the likes of
> Dan have put in to get LX running), pulling in updates from illumos
> and the other upstreams, with the same sort of release cadence
> and update approach (so you know you're going to get security updates)
> we have at the moment.
>
> Ignoring the who and how for now, would that be what people actually want?
>
> Or are people looking for a different future?
>
> My personal (illumos/Tribblix) selfishness here is twofold; first, I want
> to ensure we keep the current codebase as a going concern (as an
> unmaintained museum it's not interesting), and secondly an active
> project shows the health of the illumos ecosystem in a better light.
>

My opinion is that the most likely to succeed path forward is to keep
OmniOS as OmniOS, just with a more open / decentralized management
structure. Most of what we need is already in place:

- The code is on github, and we can either add committers into the
current group, or move it to a whole new github project space (we
actually wanted to do this, but OmniOS was taken, so it always got
back burnered).

- We can (and should) move the wiki to github. It's currently running
on some proprietary-esque software which is EOL; again, lack of round
tuits to fix this, but if anyone wants to take a stab, we believe the
following script can be used to scrape the content into a github
suitable format: https://github.com/HeinrichHartmann/trac2md

- the pkg repo is trickier, but I think the simplest answer is
probably for us to donate hosting for that for the time being,
although there may be others in a better position to offer that.

- with regard to name / brand; Right now it's sitting in a safe place,
but I think eventually the right answer would be to turn ownership
over to a non-profit, probably a small group as an affiliated project
of one of the larger open source non-profits, but it isn't worth the
hassle until we know we have a sustainable project.

What we need most at the moment are a small group of folks interested
in doing active development / code reviews for upcoming bug fixes and
such from other illumos distros, and I think a small group of people
interested in doing infrastructure management (ideally around as many
community available resources as we can).


Robert Treat
https://omniti.com

From danmcd at omniti.com  Tue May  2 15:49:44 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 2 May 2017 11:49:44 -0400
Subject: [OmniOS-discuss] Repo-only illumos-omnios update
Message-ID: <357C1E39-86CB-4280-831D-65EFEAB37610@omniti.com>

First off, thanks to Andy Fiddaman, who discovered a problem with the DEBUG packages in bloody.

I've pushed out new illumos-omnios packages for bloody on the repo server.  Most people won't strictly need to upgrade, because these only affected the debug.illumos=true variant of these packages.

You should "pkg update" your bloody boxes, however.  (And don't forget "-r" now if you've lipkg zones.)

Dan


From whorfin at gmail.com  Fri May  5 04:20:31 2017
From: whorfin at gmail.com (Rick Sayre)
Date: Thu, 4 May 2017 21:20:31 -0700
Subject: [OmniOS-discuss] git push/fsck problem on r151020
Message-ID: <fc293dc1-9e82-a4b0-d8be-14e0ddddc997@gmail.com>

$ uname -a
SunOS mybox 5.11 omnios-r151020-4151d05 i86pc i386 i86pc

$ git push
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 627 bytes | 0 bytes/s, done.
Total 7 (delta 6), reused 0 (delta 0)
remote: error: object feec1f602cb04c13c661b24f1bbe06d53c17ba70: 
fullPathname: contains full pathnames
remote: fatal: Error in object
error: unpack failed: index-pack abnormal exit
To https://github.com/whorfin/duktape.git
  ! [remote rejected] master -> master (failed)
error: failed to push some refs to 'https://github.com/whorfin/duktape.git'

$ git fsck
warning in tree feec1f602cb04c13c661b24f1bbe06d53c17ba70: fullPathname: 
contains full pathnames
Checking object directories: 100% (256/256), done.
Checking objects: 100% (47718/47718), done.

# nothing weird here
$ git rev-list --objects --all | grep 
feec1f602cb04c13c661b24f1bbe06d53c17ba70

May or may not be relevant - OpenSolaris issue reported at
http://stackoverflow.com/questions/30700947/git-fsck-error-contains-full-pathnames

So the punchline is that running git on linux or lxss on windows works
fine.

To reproduce:
fork duktape [if you're going to push]
https://github.com/svaarala/duktape
clone your fork or the above like so
$ git clone https://github.com/svaarala/duktape.git
$ cd duktape
#make an edit, in my case it was
$ vim config/platforms/platform_solaris.h.in
$ git commit -a

# Now the bad news:
$ git fsck
# and you will see what I saw
$ git push   # if you made your own fork
# also failtown

Installed git is 2.10 on r151020.  Same failure with 2.11 git from
Joyent/pkgin

git 2.7.4 on Ubuntu 16.0.4 works fine
once the change/push was done on ubuntu, pulling down the forked and
changed repo shows an ok git fsck on OmniOS.  i suspect a further change
will bork it again


Cheers
         --Rick

From danmcd at omniti.com  Fri May  5 04:31:40 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 5 May 2017 00:31:40 -0400
Subject: [OmniOS-discuss] git push/fsck problem on r151020
In-Reply-To: <fc293dc1-9e82-a4b0-d8be-14e0ddddc997@gmail.com>
References: <fc293dc1-9e82-a4b0-d8be-14e0ddddc997@gmail.com>
Message-ID: <EDCBA541-04E9-491F-AA99-AA3E5E49164D@omniti.com>

Try bloody - git is further updated there.  Thanks for the reproduction though. Time permitting I can try it on 020.

Dan

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

> On May 5, 2017, at 12:20 AM, Rick Sayre <whorfin at gmail.com> wrote:
> 
> $ uname -a
> SunOS mybox 5.11 omnios-r151020-4151d05 i86pc i386 i86pc
> 
> $ git push
> Counting objects: 7, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (7/7), done.
> Writing objects: 100% (7/7), 627 bytes | 0 bytes/s, done.
> Total 7 (delta 6), reused 0 (delta 0)
> remote: error: object feec1f602cb04c13c661b24f1bbe06d53c17ba70: fullPathname: contains full pathnames
> remote: fatal: Error in object
> error: unpack failed: index-pack abnormal exit
> To https://github.com/whorfin/duktape.git
> ! [remote rejected] master -> master (failed)
> error: failed to push some refs to 'https://github.com/whorfin/duktape.git'
> 
> $ git fsck
> warning in tree feec1f602cb04c13c661b24f1bbe06d53c17ba70: fullPathname: contains full pathnames
> Checking object directories: 100% (256/256), done.
> Checking objects: 100% (47718/47718), done.
> 
> # nothing weird here
> $ git rev-list --objects --all | grep feec1f602cb04c13c661b24f1bbe06d53c17ba70
> 
> May or may not be relevant - OpenSolaris issue reported at
> http://stackoverflow.com/questions/30700947/git-fsck-error-contains-full-pathnames
> 
> So the punchline is that running git on linux or lxss on windows works
> fine.
> 
> To reproduce:
> fork duktape [if you're going to push]
> https://github.com/svaarala/duktape
> clone your fork or the above like so
> $ git clone https://github.com/svaarala/duktape.git
> $ cd duktape
> #make an edit, in my case it was
> $ vim config/platforms/platform_solaris.h.in
> $ git commit -a
> 
> # Now the bad news:
> $ git fsck
> # and you will see what I saw
> $ git push   # if you made your own fork
> # also failtown
> 
> Installed git is 2.10 on r151020.  Same failure with 2.11 git from
> Joyent/pkgin
> 
> git 2.7.4 on Ubuntu 16.0.4 works fine
> once the change/push was done on ubuntu, pulling down the forked and
> changed repo shows an ok git fsck on OmniOS.  i suspect a further change
> will bork it again
> 
> 
> Cheers
>        --Rick
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From rjahnel at ellipseinc.com  Fri May  5 15:06:19 2017
From: rjahnel at ellipseinc.com (Richard Jahnel)
Date: Fri, 5 May 2017 15:06:19 +0000
Subject: [OmniOS-discuss] l2arc 16.0E accounting leak
Message-ID: <65DC5816D4BEE043885A89FD54E273FC71DA3B49@MAIL101.Ellipseinc.com>

Does anyone know if we pulled or backported the https://www.illumos.org/issues/7867  into r151020 yet?

We are suffering from this bug now. I'm pulling out my l2arc devices until a fix is in place, which makes me sad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170505/07a7815b/attachment.html>

From danmcd at omniti.com  Fri May  5 15:30:34 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 5 May 2017 11:30:34 -0400
Subject: [OmniOS-discuss] l2arc 16.0E accounting leak
In-Reply-To: <65DC5816D4BEE043885A89FD54E273FC71DA3B49@MAIL101.Ellipseinc.com>
References: <65DC5816D4BEE043885A89FD54E273FC71DA3B49@MAIL101.Ellipseinc.com>
Message-ID: <F45B036D-2BA3-4574-AC59-6AF878194AA0@omniti.com>

The next stable and LTS, r151022, will arrive this month and it has this fix.

Dan

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

> On May 5, 2017, at 11:06 AM, Richard Jahnel <rjahnel at ellipseinc.com> wrote:
> 
> Does anyone know if we pulled or backported the https://www.illumos.org/issues/7867  into r151020 yet?
>  
> We are suffering from this bug now. I?m pulling out my l2arc devices until a fix is in place, which makes me sad.
> _______________________________________________
> 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/20170505/89189a59/attachment.html>

From bardishe at gmail.com  Sat May  6 03:32:57 2017
From: bardishe at gmail.com (Artyom Zhandarovsky)
Date: Sat, 6 May 2017 14:32:57 +1100
Subject: [OmniOS-discuss] latest sas3ircu can detect 9300-16e using mpt_sas
	driver
Message-ID: <CAOdMvyhU9+sO-j8wKBGYLdUWc6BUFWiGEuQHkBx6XyTz2pcBng@mail.gmail.com>

Hi to every one.

I have found a way to use latst SAS3IRCU_P14.zip in OmiOS.
If to look a little bit closer into internals of the old sas3ircu you will
see the following:

===== cut ====
00000254BA: FE FF 2F 00 64 69 5F 69 ? 6E 69 74 28 29 20 66 61  ??/
di_init() fa
00000254CA: 69 6C 65 64 0A 00 6D 70 ? 74 5F 73 61 73 00 2F 64  iled?
*mpt_sas* /d

===== cut ====

if you look into newest versions

===== cut ====
00000253D5: 6F 74 2F 00 64 69 5F 69 ? 6E 69 74 28 29 20 66 61  ot/
di_init() fa
00000253E5: 69 6C 65 64 0A 00 6C 73 ? 63 00 6D 70 74 5F 73 61  iled? *lsc
mpt_sa*
00000253F5: 73 00 2F 64 65 76 69 63 ? 65 73 25 73 3A 64 65 76  *s*
/devices%s:dev
===== cut ====

yes it looks into lsc driver, but it also new about mpt_sas, but for some
reason it does not work.

So why just not to make some "hiew" )) and place mpt_sas in front of lsc

========= cut ==============
00000251C0: 6D 70 2F 72 6F 6F 74 2F ? 00 64 69 5F 69 6E 69 74  mp/root/
di_init
00000251D0: 28 29 20 66 61 69 6C 65 ? 64 0A 00 *6D 70 74 5F 73*  () failed?
*mpt_s*
00000251E0: *61 73 00* *6C 73 63* 00 2F ? 64 65 76 69 63 65 73 25  *as lsc*
/devices%
00000251F0: 73 3A 64 65 76 63 74 6C ? 00 53 41 53 32 30 30 34  s:devctl
SAS2004
========= cut ==============
 but do not use "space" between those writings cause it will write 20, and
we need 00.

Now run it

============== cut ===================
root at kxxx-xxx:/export/home/admin# ./sas3ircu 0 display
Avago Technologies SAS3 IR Configuration Utility.
*Version 14.00.00.00 (2016.07.21)*
Copyright (c) 2009-2016 Avago Technologies. All rights reserved.
Read configuration has been initiated for controller 0
------------------------------------------------------------------------
Controller information
------------------------------------------------------------------------
  Controller type                         : SAS3008
  BIOS version                            : 0.00.00.00
  Firmware version                        : 14.00.00.00
  Channel description                     : 1 Serial Attached SCSI
  Initiator ID                            : 0
  Maximum physical devices                : 1023
  Concurrent commands supported           : 10176
  Slot                                    : Unknown
  Segment                                 : 0
  Bus                                     : 13
  Device                                  : 0
  Function                                : 0
  RAID Support                            : No
------------------------------------------------------------------------
IR Volume information
------------------------------------------------------------------------
------------------------------------------------------------------------
Physical device information
------------------------------------------------------------------------
Initiator at ID #0

Device is a Hard disk
  Enclosure #                             : 2
  Slot #                                  : 0
  SAS Address                             : 5000cca-2-3c0b-d88e
  State                                   : Ready (RDY)
  Size (in MB)/(in sectors)               : 5723166/1465130645
  Manufacturer                            : HGST
  Model Number                            : HUH728060AL4204
  Firmware Revision                       : C7J0
  Serial No                               : 2RG6HYSX
  Unit Serial No(VPD)                     : 2RG6HYSX
  GUID                                    : 5000cca23c0bd88c
  Protocol                                : SAS
  Drive Type                              : SAS_HDD

Device is a Sequential access device
  Enclosure #                             : 2
  Slot #                                  : 0
  SAS Address                             : 5003048-0-0181-dafd
  State                                   : Standby (SBY)
  Manufacturer                            : LSI CORP
  Model Number                            : SAS2X28
  Firmware Revision                       : 0717
  Serial No                               : x36557230
  Unit Serial No(VPD)                     : N/A
  GUID                                    : N/A
  Protocol                                : SAS
  Drive Type                              : SAS_HDD

Device is a Hard disk
  Enclosure #                             : 2
  Slot #                                  : 1
  SAS Address                             : 5000cca-2-3c0b-d48e
  State                                   : Ready (RDY)
  Size (in MB)/(in sectors)               : 5723166/1465130645
  Manufacturer                            : HGST
  Model Number                            : HUH728060AL4204
  Firmware Revision                       : C7J0
  Serial No                               : 2RG6HPHX
  Unit Serial No(VPD)                     : 2RG6HPHX
  GUID                                    : 5000cca23c0bd48c
  Protocol                                : SAS
  Drive Type                              : SAS_HDD

Device is a Hard disk
  Enclosure #                             : 2
  Slot #                                  : 2
  SAS Address                             : 5000cca-2-3c0b-dfc2
  State                                   : Ready (RDY)
  Size (in MB)/(in sectors)               : 5723166/1465130645
  Manufacturer                            : HGST
  Model Number                            : HUH728060AL4204
  Firmware Revision                       : C7J0
  Serial No                               : 2RG6JEMX
  Unit Serial No(VPD)                     : 2RG6JEMX
  GUID                                    : 5000cca23c0bdfc0
  Protocol                                : SAS
  Drive Type                              : SAS_HDD

Device is a Hard disk
  Enclosure #                             : 2
  Slot #                                  : 3
  SAS Address                             : 5000cca-2-3c0b-ea96
  State                                   : Ready (RDY)
  Size (in MB)/(in sectors)               : 5723166/1465130645
  Manufacturer                            : HGST
  Model Number                            : HUH728060AL4204
  Firmware Revision                       : C7J0
  Serial No                               : 2RG6K4ZX
  Unit Serial No(VPD)                     : 2RG6K4ZX
  GUID                                    : 5000cca23c0bea94
  Protocol                                : SAS
  Drive Type                              : SAS_HDD

============== cut ==============




The same way you can modify the sas3flash, but it incorrectly determines
the firmware version, seems to be the problem of old mpt_sas driver

============== cut ==============

      Firmware Product ID            : 0x3860
        Firmware Version               : 127.100.219.120
        NVDATA Vendor                  : Undetermined
        NVDATA Product ID              : Undetermined
        BIOS Version                   : N/A
        UEFI BSD Version               : N/A
        FCODE Version                  : N/A
        Board Name                     : SAS9300-16e
        Board Assembly                 : H3-25520-01E
        Board Tracer Number            : SP64606278
============== cut ==============


If OmiOS would include lsc driver, i think we all will be happy. Cause i
tried to import it from 11.3 Solaris..
Yes it starts to load up, but tries to call non existent functions in
kernel and fails.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170506/26590a3d/attachment-0001.html>

From daleg at omniti.com  Sat May  6 07:17:29 2017
From: daleg at omniti.com (Dale Ghent)
Date: Sat, 6 May 2017 03:17:29 -0400
Subject: [OmniOS-discuss] latest sas3ircu can detect 9300-16e using
 mpt_sas driver
In-Reply-To: <CAOdMvyhU9+sO-j8wKBGYLdUWc6BUFWiGEuQHkBx6XyTz2pcBng@mail.gmail.com>
References: <CAOdMvyhU9+sO-j8wKBGYLdUWc6BUFWiGEuQHkBx6XyTz2pcBng@mail.gmail.com>
Message-ID: <BC281DAB-59F6-4648-9DB9-29F78C4187CB@omniti.com>


> On May 5, 2017, at 11:32 PM, Artyom Zhandarovsky <bardishe at gmail.com> wrote:
> 
> Hi to every one.
> 
> I have found a way to use latst SAS3IRCU_P14.zip in OmiOS.
> If to look a little bit closer into internals of the old sas3ircu you will see the following:
> 
> ===== cut ====
> 00000254BA: FE FF 2F 00 64 69 5F 69 ? 6E 69 74 28 29 20 66 61  ??/ di_init() fa
> 00000254CA: 69 6C 65 64 0A 00 6D 70 ? 74 5F 73 61 73 00 2F 64  iled? mpt_sas /d
> 
> ===== cut ====
> 
> if you look into newest versions
> 
> ===== cut ====
> 00000253D5: 6F 74 2F 00 64 69 5F 69 ? 6E 69 74 28 29 20 66 61  ot/ di_init() fa
> 00000253E5: 69 6C 65 64 0A 00 6C 73 ? 63 00 6D 70 74 5F 73 61  iled? lsc mpt_sa
> 00000253F5: 73 00 2F 64 65 76 69 63 ? 65 73 25 73 3A 64 65 76  s /devices%s:dev
> ===== cut ====
> 
> yes it looks into lsc driver, but it also new about mpt_sas, but for some reason it does not work.
> 
> So why just not to make some "hiew" )) and place mpt_sas in front of lsc
> 
> ========= cut ==============
> 00000251C0: 6D 70 2F 72 6F 6F 74 2F ? 00 64 69 5F 69 6E 69 74  mp/root/ di_init
> 00000251D0: 28 29 20 66 61 69 6C 65 ? 64 0A 00 6D 70 74 5F 73  () failed? mpt_s
> 00000251E0: 61 73 00 6C 73 63 00 2F ? 64 65 76 69 63 65 73 25  as lsc /devices%
> 00000251F0: 73 3A 64 65 76 63 74 6C ? 00 53 41 53 32 30 30 34  s:devctl SAS2004
> ========= cut ==============
>  but do not use "space" between those writings cause it will write 20, and we need 00.
> 
> Now run it
> 
> ============== cut ===================
> root at kxxx-xxx:/export/home/admin# ./sas3ircu 0 display
> Avago Technologies SAS3 IR Configuration Utility.
> Version 14.00.00.00 (2016.07.21)
> Copyright (c) 2009-2016 Avago Technologies. All rights reserved.
> Read configuration has been initiated for controller 0
> ------------------------------------------------------------------------
> Controller information
> ------------------------------------------------------------------------
>   Controller type                         : SAS3008
>   BIOS version                            : 0.00.00.00
>   Firmware version                        : 14.00.00.00
>   Channel description                     : 1 Serial Attached SCSI
>   Initiator ID                            : 0
>   Maximum physical devices                : 1023
>   Concurrent commands supported           : 10176
>   Slot                                    : Unknown
>   Segment                                 : 0
>   Bus                                     : 13
>   Device                                  : 0
>   Function                                : 0
>   RAID Support                            : No
> ------------------------------------------------------------------------
> IR Volume information
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> Physical device information
> ------------------------------------------------------------------------
> Initiator at ID #0
> 
> Device is a Hard disk
>   Enclosure #                             : 2
>   Slot #                                  : 0
>   SAS Address                             : 5000cca-2-3c0b-d88e
>   State                                   : Ready (RDY)
>   Size (in MB)/(in sectors)               : 5723166/1465130645
>   Manufacturer                            : HGST
>   Model Number                            : HUH728060AL4204
>   Firmware Revision                       : C7J0
>   Serial No                               : 2RG6HYSX
>   Unit Serial No(VPD)                     : 2RG6HYSX
>   GUID                                    : 5000cca23c0bd88c
>   Protocol                                : SAS
>   Drive Type                              : SAS_HDD
> 
> Device is a Sequential access device
>   Enclosure #                             : 2
>   Slot #                                  : 0
>   SAS Address                             : 5003048-0-0181-dafd
>   State                                   : Standby (SBY)
>   Manufacturer                            : LSI CORP
>   Model Number                            : SAS2X28
>   Firmware Revision                       : 0717
>   Serial No                               : x36557230
>   Unit Serial No(VPD)                     : N/A
>   GUID                                    : N/A
>   Protocol                                : SAS
>   Drive Type                              : SAS_HDD
> 
> Device is a Hard disk
>   Enclosure #                             : 2
>   Slot #                                  : 1
>   SAS Address                             : 5000cca-2-3c0b-d48e
>   State                                   : Ready (RDY)
>   Size (in MB)/(in sectors)               : 5723166/1465130645
>   Manufacturer                            : HGST
>   Model Number                            : HUH728060AL4204
>   Firmware Revision                       : C7J0
>   Serial No                               : 2RG6HPHX
>   Unit Serial No(VPD)                     : 2RG6HPHX
>   GUID                                    : 5000cca23c0bd48c
>   Protocol                                : SAS
>   Drive Type                              : SAS_HDD
> 
> Device is a Hard disk
>   Enclosure #                             : 2
>   Slot #                                  : 2
>   SAS Address                             : 5000cca-2-3c0b-dfc2
>   State                                   : Ready (RDY)
>   Size (in MB)/(in sectors)               : 5723166/1465130645
>   Manufacturer                            : HGST
>   Model Number                            : HUH728060AL4204
>   Firmware Revision                       : C7J0
>   Serial No                               : 2RG6JEMX
>   Unit Serial No(VPD)                     : 2RG6JEMX
>   GUID                                    : 5000cca23c0bdfc0
>   Protocol                                : SAS
>   Drive Type                              : SAS_HDD
> 
> Device is a Hard disk
>   Enclosure #                             : 2
>   Slot #                                  : 3
>   SAS Address                             : 5000cca-2-3c0b-ea96
>   State                                   : Ready (RDY)
>   Size (in MB)/(in sectors)               : 5723166/1465130645
>   Manufacturer                            : HGST
>   Model Number                            : HUH728060AL4204
>   Firmware Revision                       : C7J0
>   Serial No                               : 2RG6K4ZX
>   Unit Serial No(VPD)                     : 2RG6K4ZX
>   GUID                                    : 5000cca23c0bea94
>   Protocol                                : SAS
>   Drive Type                              : SAS_HDD
> 
> ============== cut ==============
> 
> 
> 
> 
> The same way you can modify the sas3flash, but it incorrectly determines the firmware version, seems to be the problem of old mpt_sas driver
> 
> ============== cut ==============
> 
>       Firmware Product ID            : 0x3860
>         Firmware Version               : 127.100.219.120
>         NVDATA Vendor                  : Undetermined
>         NVDATA Product ID              : Undetermined
>         BIOS Version                   : N/A
>         UEFI BSD Version               : N/A
>         FCODE Version                  : N/A
>         Board Name                     : SAS9300-16e
>         Board Assembly                 : H3-25520-01E
>         Board Tracer Number            : SP64606278
> ============== cut ==============
> 
> 
> If OmiOS would include lsc driver, i think we all will be happy. Cause i tried to import it from 11.3 Solaris..
> Yes it starts to load up, but tries to call non existent functions in kernel and fails.

Instead of using binaries meant for another, different OS (Oracle Solaris) to get LSI MPT HBA information and to upload firmware to the HBA, it would likely be better if the community worked on a native command-line utility to do the former, and a plugin for fwflash(1M) to do the latter.

IMO, trying to use Oracle Solaris binaries on any illumos system is not something I would consider to be a reliable proposition in the long term. Instead of trying to chase any changes there, I would prefer to invent my own.

/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/20170506/f762ea71/attachment.bin>

From danmcd at omniti.com  Mon May  8 15:11:26 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 8 May 2017 11:11:26 -0400
Subject: [OmniOS-discuss] Fwd: [smartos-discuss] Problem updating Debian 8.7
	(jessie) zone
References: <CAC-=-+5O+BD_WTvxsFW4qiAy2Qotr+yU-0hBr3mRHMnQ3Th=FA@mail.gmail.com>
Message-ID: <D96F6E8A-FAD9-4EAC-961D-F72B650551CC@omniti.com>

For anyone using Debian in an LX zone...

Dan

> Begin forwarded message:
> 
> From: "Christopher Horrell" <christopher at joyent.com>
> Subject: Re: [smartos-discuss] Problem updating Debian 8.7 (jessie) zone
> Date: May 8, 2017 at 10:11:02 AM EDT
> To: SmartOs Discuss <smartos-discuss at lists.smartos.org>
> Reply-To: smartos-discuss at lists.smartos.org
> 
> Hi Jes?s,
> 
> It looks like you are hitting something similar to this:
> 
> https://github.com/joyent/smartos-live/issues/596 <https://github.com/joyent/smartos-live/issues/596>
> 
> See the last comment for a workaround
> 
> On Sun, May 7, 2017 at 6:53 PM Jesus Cea <jcea at jcea.es <mailto:jcea at jcea.es>> wrote:
> I have a zone with Debian 8.7 (jessie) running fine for months. Upgraded
> daily with no issues. Upgrading today I see this:
> 
> """
> root at XXX:~# apt-get upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> You might want to run 'apt-get -f install' to correct these.
> The following packages have unmet dependencies:
>  systemd : Depends: udev (>= 208-8) but it is not installable
>            Recommends: libpam-systemd but it is not installed
> E: Unmet dependencies. Try using -f.
> 
> root at XXX:~# apt-get upgrade -f
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Correcting dependencies... Done
> Calculating upgrade... Done
> The following packages will be REMOVED:
>   systemd
> The following packages will be upgraded:
>   binutils ca-certificates libgnutls-deb0-28 libgnutls-openssl27
> libsystemd0 libudev1 libxslt1.1 locales multiarch-support unzip
>   vim vim-common vim-runtime vim-tiny wget
> 15 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> Need to get 0 B/16.3 MB of archives.
> After this operation, 12.4 MB disk space will be freed.
> Do you want to continue? [Y/n] y
> Preconfiguring packages ...
> (Reading database ... 26262 files and directories currently installed.)
> Removing systemd (215-17+deb8u6) ...
> systemd is the active init system, please switch to another before
> removing systemd.
> dpkg: error processing package systemd (--remove):
>  subprocess installed pre-removal script returned error exit status 1
> Failed to stop lib-init-rw.mount: Unit lib-init-rw.mount not loaded.
> addgroup: The group `systemd-journal' already exists as a system group.
> Exiting.
> unable to set CAP_SETFCAP effective capability: Operation not permitted
> Errors were encountered while processing:
>  systemd
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> """
> 
> I am using the image:
> 
> e74a9cd0-f2d0-11e6-8b69-b3acf2ef87f7  debian-8                20170214
> linux    lx-dataset    2017-02-14
> 
> How should I proceed?.
> 
> Thanks.
> 
> --
> Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
> jcea at jcea.es <mailto:jcea at jcea.es> - http://www.jcea.es/ <http://www.jcea.es/>     _/_/    _/_/  _/_/    _/_/  _/_/
> Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
> jabber / xmpp:jcea at jabber.org <mailto:xmpp%3Ajcea at jabber.org>  _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> 
> 
> 
> 
> 
> http://www.listbox.com <http://www.listbox.com/>
> -- 
> Christopher Horrell
> Joyent Inc.
> http://www.joyent.com/ <http://www.joyent.com/>
> smartos-discuss | Archives <https://www.listbox.com/member/archive/184463/=now>  <https://www.listbox.com/member/archive/rss/184463/26913185-da7c67be> | Modify <https://www.listbox.com/member/?member_id=26913185&id_secret=26913185-7b7f2b8d> Your Subscription	 <http://www.listbox.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170508/b350de5f/attachment-0001.html>

From danmcd at omniti.com  Mon May  8 19:34:25 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 8 May 2017 15:34:25 -0400
Subject: [OmniOS-discuss] Bloody update for May 8th (r151022-RC0 feeder)
Message-ID: <51D4C935-B643-47F2-A7D4-6226D26A0656@omniti.com>

I've updated bloody, and install media, today.

illumos-omnios is at d2ed2f2489, omnios-build is at b902717c6dc, both master branches.

A few merges from upstream illumos, a few small LX fixes from Joyent, and a bump of Mozilla-NSS to 3.30.2.

This master branch has been merged into r151022 branches, and will provide the basis for the last batch of install and upgrade tests.  Users who are looking for insights into r151022 should go check the in-progress release notes:

	http://omnios.omniti.com/wiki.php/ReleaseNotes/r151022

There are new, r151022-related, pages you can visit from the above.  The UPGRADE INSTRUCTIONS should be read carefully, ESPECIALLY by r151014 users, and by anyone with "ipkg" (non-linked-image, native) zones.  Note that even now, some of those pages may change more before 022 hits the servers.

Thank you!
Dan


From fabio at fabiorabelo.wiki.br  Mon May  8 19:51:48 2017
From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=)
Date: Mon, 8 May 2017 16:51:48 -0300
Subject: [OmniOS-discuss] Bloody update for May 8th (r151022-RC0 feeder)
In-Reply-To: <51D4C935-B643-47F2-A7D4-6226D26A0656@omniti.com>
References: <51D4C935-B643-47F2-A7D4-6226D26A0656@omniti.com>
Message-ID: <CAEekY64pXkVc_700Hd9Tif3JFBCR7hF7ZbpMX2aaZUXTf0j0og@mail.gmail.com>

WOW !!!!

Great news !!!

Solar Flare 10G network cards are fully supported now :?!?


F?bio Rabelo

2017-05-08 16:34 GMT-03:00 Dan McDonald <danmcd at omniti.com>:
> I've updated bloody, and install media, today.
>
> illumos-omnios is at d2ed2f2489, omnios-build is at b902717c6dc, both master branches.
>
> A few merges from upstream illumos, a few small LX fixes from Joyent, and a bump of Mozilla-NSS to 3.30.2.
>
> This master branch has been merged into r151022 branches, and will provide the basis for the last batch of install and upgrade tests.  Users who are looking for insights into r151022 should go check the in-progress release notes:
>
>         http://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
>
> There are new, r151022-related, pages you can visit from the above.  The UPGRADE INSTRUCTIONS should be read carefully, ESPECIALLY by r151014 users, and by anyone with "ipkg" (non-linked-image, native) zones.  Note that even now, some of those pages may change more before 022 hits the servers.
>
> Thank you!
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From lorban at bitronix.be  Tue May  9 09:52:27 2017
From: lorban at bitronix.be (Ludovic Orban)
Date: Tue, 9 May 2017 11:52:27 +0200
Subject: [OmniOS-discuss] LX: real ksh93 broken
Message-ID: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>

Hi,

I've installed the real ksh93 (this stuff:
https://packages.debian.org/jessie/ksh) on a r151020 LX zone running the
latest Debian (
https://images.joyent.com/images/e74a9cd0-f2d0-11e6-8b69-b3acf2ef87f7) and
it behaves strangely.

Here is what I get:

root at debian-8:~# /bin/ksh93
# ls /


^C^C
^Z^Z^Z
^\^\^\^\
Killed
root at debian-8:~#
root at debian-8:~#

(note: the "Killed" line is due to a kill -9 from another terminal).

Basically, any command I type just hangs there. Sometimes the shell reacts
to ^C and/or ^D allowing me to try a different command that also gonna
hang, and sometimes it doesn't and I have to kill the shell from another
terminal. In the latter case, ksh93 starts kind of a "fork bomb" where it
seems to fork itself in a loop.

I can reproduce this problem from a zlogin term as well as from a direct
ssh session. I've also tried ksh93 on a CentOS zone to make sure the
problem wasn't caused by Debian's build and the exact same problem arises.

Any idea what's going on?

Thanks,
Ludovic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170509/c6e59d4b/attachment.html>

From nshalman at omniti.com  Tue May  9 14:02:35 2017
From: nshalman at omniti.com (Nahum Shalman)
Date: Tue, 9 May 2017 10:02:35 -0400
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
Message-ID: <CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>

As a data point, I tested this on a very recent SmartOS and was unable to
reproduce:

root at ksh-debian:~# set -o xtrace ; /native/usr/bin/uname -a; uname -a ; cat
/etc/debian_version ; dpkg-query -l ksh | grep ksh ; /bin/ksh93
+ set -o xtrace
+ /native/usr/bin/uname -a
SunOS ksh-debian 5.11 joyent_20170427T222500Z i86pc i386 i86pc
+ uname -a
Linux ksh-debian 3.16.10 BrandZ virtual linux x86_64 GNU/Linux
+ cat /etc/debian_version
8.8
+ dpkg-query -l ksh
+ grep ksh
ii  ksh            93u+20120801-1 amd64        Real, AT&T version of the
Korn shell
+ /bin/ksh93
# ps | grep $$
77074 pts/2    00:00:00 ksh93
# exit
root at ksh-debian:~#

On Tue, May 9, 2017 at 5:52 AM, Ludovic Orban <lorban at bitronix.be> wrote:

> Hi,
>
> I've installed the real ksh93 (this stuff: https://packages.debian.org/
> jessie/ksh) on a r151020 LX zone running the latest Debian (
> https://images.joyent.com/images/e74a9cd0-f2d0-11e6-8b69-b3acf2ef87f7)
> and it behaves strangely.
>
> Here is what I get:
>
> root at debian-8:~# /bin/ksh93
> # ls /
>
>
> ^C^C
> ^Z^Z^Z
> ^\^\^\^\
> Killed
> root at debian-8:~#
> root at debian-8:~#
>
> (note: the "Killed" line is due to a kill -9 from another terminal).
>
> Basically, any command I type just hangs there. Sometimes the shell reacts
> to ^C and/or ^D allowing me to try a different command that also gonna
> hang, and sometimes it doesn't and I have to kill the shell from another
> terminal. In the latter case, ksh93 starts kind of a "fork bomb" where it
> seems to fork itself in a loop.
>
> I can reproduce this problem from a zlogin term as well as from a direct
> ssh session. I've also tried ksh93 on a CentOS zone to make sure the
> problem wasn't caused by Debian's build and the exact same problem arises.
>
> Any idea what's going on?
>
> Thanks,
> Ludovic
>
> _______________________________________________
> 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/20170509/5ac18f3c/attachment.html>

From danmcd at omniti.com  Tue May  9 14:30:31 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 9 May 2017 10:30:31 -0400
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
Message-ID: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>

When I get home I'll provide more details, but you should try bloody or still in beta r151022.

Dan

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

> On May 9, 2017, at 10:02 AM, Nahum Shalman <nshalman at omniti.com> wrote:
> 
> As a data point, I tested this on a very recent SmartOS and was unable to reproduce:
> 
> root at ksh-debian:~# set -o xtrace ; /native/usr/bin/uname -a; uname -a ; cat /etc/debian_version ; dpkg-query -l ksh | grep ksh ; /bin/ksh93
> + set -o xtrace
> + /native/usr/bin/uname -a
> SunOS ksh-debian 5.11 joyent_20170427T222500Z i86pc i386 i86pc
> + uname -a
> Linux ksh-debian 3.16.10 BrandZ virtual linux x86_64 GNU/Linux
> + cat /etc/debian_version
> 8.8
> + dpkg-query -l ksh
> + grep ksh
> ii  ksh            93u+20120801-1 amd64        Real, AT&T version of the Korn shell
> + /bin/ksh93
> # ps | grep $$
> 77074 pts/2    00:00:00 ksh93
> # exit
> root at ksh-debian:~#
> 
>> On Tue, May 9, 2017 at 5:52 AM, Ludovic Orban <lorban at bitronix.be> wrote:
>> Hi,
>> 
>> I've installed the real ksh93 (this stuff: https://packages.debian.org/jessie/ksh) on a r151020 LX zone running the latest Debian (https://images.joyent.com/images/e74a9cd0-f2d0-11e6-8b69-b3acf2ef87f7) and it behaves strangely.
>> 
>> Here is what I get:
>> 
>> root at debian-8:~# /bin/ksh93
>> # ls /
>> 
>> 
>> ^C^C
>> ^Z^Z^Z
>> ^\^\^\^\
>> Killed
>> root at debian-8:~#
>> root at debian-8:~#
>> 
>> (note: the "Killed" line is due to a kill -9 from another terminal).
>> 
>> Basically, any command I type just hangs there. Sometimes the shell reacts to ^C and/or ^D allowing me to try a different command that also gonna hang, and sometimes it doesn't and I have to kill the shell from another terminal. In the latter case, ksh93 starts kind of a "fork bomb" where it seems to fork itself in a loop.
>> 
>> I can reproduce this problem from a zlogin term as well as from a direct ssh session. I've also tried ksh93 on a CentOS zone to make sure the problem wasn't caused by Debian's build and the exact same problem arises.
>> 
>> Any idea what's going on?
>> 
>> Thanks,
>> Ludovic
>> 
>> _______________________________________________
>> 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/20170509/fa948a9d/attachment-0001.html>

From danmcd at omniti.com  Tue May  9 15:05:39 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 9 May 2017 11:05:39 -0400
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
Message-ID: <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>


> On May 9, 2017, at 10:30 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> When I get home I'll provide more details, but you should try bloody or still in beta r151022.
> 

Well shoot.  It appears I have pretty much the same problem in OmniOS bloody (and therefore r151022):

root at ubuntu-14-04-b:~# ksh93
# echo "Hello, world."
^D
^C
# ls /
bin   dev  home  lib64  mnt     opt   root  sbin  sys     tmp  var
boot  etc  lib   media  native  proc  run   srv   system  usr

^D
^C# 
# 

Any command I type that's builtin just stops.  Any command that forks outputs, but doesn't seem to properly exit.

Ouch... and when I try it again from scratch, it hangs per the original report.  And worse, ONE TIME (can't reproduce) it seemed to runaway with spawning itself.  Apparently if the first thing you type is a builtin or just RETURN, you enter a state where you can amp-off processes, but the shell itself seems to wedge until you hit ^C.  If you enter a real process right off the bat, ksh93 goes on a slow forking spree... well, sometimes.  Other times, hitting ^C in the hung shell will return you.

I wonder if I mismerged or forgot to merge something from SmartOS?

I also wonder if this mismerge or omission happened early on in the prior bloody cycle?  It's going to be hard to tell.

Whatever ksh93 is doing, it appears to be doing it in LX userspace, too:

bloody(~)[0]% ptree `pgrep ksh93`
493   /usr/sbin/sshd
  9511  /usr/sbin/sshd -R
    9515  /usr/sbin/sshd -R
      9516  -tcsh
        9555  sudo zlogin lx1
          9556  zlogin lx1
            9557  /bin/login -h zone:global -f root
              9566  -bash
                9622  ksh93
bloody(~)[0]% sudo mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc apix scsi_vhci zfs sata sd ip hook neti sockfs arp usba xhci stmf stmf_sbd mm lofs random crypto idm nfs cpc ufs logindmux ptm ipc ]
> ::ps !grep ksh
R   9622   9566   9622   9557      0 0x4a014000 ffffff1983ee5000 ksh93
> ffffff1983ee5000::ps -t
S    PID   PPID   PGID    SID    UID      FLAGS             ADDR NAME
R   9622   9566   9622   9557      0 0x4a014000 ffffff1983ee5000 ksh93
        T  0xffffff1955982c60 <TS_ONPROC>
> 0xffffff1955982c60::findstack
stack pointer for thread ffffff1955982c60: ffffff007ae157f0
  ffffff007ae15f10 0x200000()
> 

And I've no good way to know what it's doing, as the illumos-native tools aren't giving me enough data.

Sorry,
Dan


From lorban at bitronix.be  Tue May  9 15:14:28 2017
From: lorban at bitronix.be (Ludovic Orban)
Date: Tue, 9 May 2017 17:14:28 +0200
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
Message-ID: <CAN0RhANf5K2WZSYzFpzSWAk8W82DMnRX2bdc5AuTOu0oQiUe9Q@mail.gmail.com>

Don't worry too much about it, I have a workaround in place that suits me
well.

I just wanted to report this problem.

Thanks,
Ludovic

On Tue, May 9, 2017 at 5:05 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On May 9, 2017, at 10:30 AM, Dan McDonald <danmcd at omniti.com> wrote:
> >
> > When I get home I'll provide more details, but you should try bloody or
> still in beta r151022.
> >
>
> Well shoot.  It appears I have pretty much the same problem in OmniOS
> bloody (and therefore r151022):
>
> root at ubuntu-14-04-b:~# ksh93
> # echo "Hello, world."
> ^D
> ^C
> # ls /
> bin   dev  home  lib64  mnt     opt   root  sbin  sys     tmp  var
> boot  etc  lib   media  native  proc  run   srv   system  usr
>
> ^D
> ^C#
> #
>
> Any command I type that's builtin just stops.  Any command that forks
> outputs, but doesn't seem to properly exit.
>
> Ouch... and when I try it again from scratch, it hangs per the original
> report.  And worse, ONE TIME (can't reproduce) it seemed to runaway with
> spawning itself.  Apparently if the first thing you type is a builtin or
> just RETURN, you enter a state where you can amp-off processes, but the
> shell itself seems to wedge until you hit ^C.  If you enter a real process
> right off the bat, ksh93 goes on a slow forking spree... well, sometimes.
> Other times, hitting ^C in the hung shell will return you.
>
> I wonder if I mismerged or forgot to merge something from SmartOS?
>
> I also wonder if this mismerge or omission happened early on in the prior
> bloody cycle?  It's going to be hard to tell.
>
> Whatever ksh93 is doing, it appears to be doing it in LX userspace, too:
>
> bloody(~)[0]% ptree `pgrep ksh93`
> 493   /usr/sbin/sshd
>   9511  /usr/sbin/sshd -R
>     9515  /usr/sbin/sshd -R
>       9516  -tcsh
>         9555  sudo zlogin lx1
>           9556  zlogin lx1
>             9557  /bin/login -h zone:global -f root
>               9566  -bash
>                 9622  ksh93
> bloody(~)[0]% sudo mdb -k
> Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc apix
> scsi_vhci zfs sata sd ip hook neti sockfs arp usba xhci stmf stmf_sbd mm
> lofs random crypto idm nfs cpc ufs logindmux ptm ipc ]
> > ::ps !grep ksh
> R   9622   9566   9622   9557      0 0x4a014000 ffffff1983ee5000 ksh93
> > ffffff1983ee5000::ps -t
> S    PID   PPID   PGID    SID    UID      FLAGS             ADDR NAME
> R   9622   9566   9622   9557      0 0x4a014000 ffffff1983ee5000 ksh93
>         T  0xffffff1955982c60 <TS_ONPROC>
> > 0xffffff1955982c60::findstack
> stack pointer for thread ffffff1955982c60: ffffff007ae157f0
>   ffffff007ae15f10 0x200000()
> >
>
> And I've no good way to know what it's doing, as the illumos-native tools
> aren't giving me enough data.
>
> Sorry,
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170509/c736f518/attachment.html>

From danmcd at omniti.com  Tue May  9 15:15:25 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 9 May 2017 11:15:25 -0400
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
Message-ID: <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>


> On May 9, 2017, at 11:05 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> And I've no good way to know what it's doing, as the illumos-native tools aren't giving me enough data.

ksh93 appears to be looping in something:

mdb: target stopped at:
0x42adf0:       movq   +0x350129(%rip),%rax     <0x77af20>
> ::step
mdb: target stopped at:
0x42adf7:       testq  %rax,%rax
> ::step
mdb: target stopped at:
0x42adfa:       jne    +0xc     <0x42ae08>
> ::step
mdb: target stopped at:
0x42adfc:       jmp    +0x28    <0x42ae26>
> ::step
mdb: target stopped at:
0x42ae26:       addl   $0x1,%r14d
> ::step
mdb: target stopped at:
0x42ae2a:       cmpl   0x10(%rsi),%r14d
> ::step
mdb: target stopped at:
0x42ae2e:       jl     -0x40    <0x42adf0>
> ::step
mdb: target stopped at:
0x42adf0:       movq   +0x350129(%rip),%rax     <0x77af20>
> <rsi+0x10
Usage: step [ over | out ] [SIG]
> <rsi+0x10=P
                0x7fffff0470f0  
> 0x7fffff0470f0/D
0x7fffff0470f0: 2147483647      
> 0x7fffff0470f0/X
0x7fffff0470f0: 7fffffff        
> <r14d/P
mdb: failed to read data from target: no mapping for address
0x761133e5:     
> <r14d=P
                0x761133e5      
> 

Something that never seems to exit.  Hmmm... I'm guessing r14d will never be less than 0x7ffffff with a signed compare (cmpl is signed,right?).

NO idea how this happened.  :-/

Dan


From chip at innovates.com  Tue May  9 19:32:04 2017
From: chip at innovates.com (Schweiss, Chip)
Date: Tue, 9 May 2017 14:32:04 -0500
Subject: [OmniOS-discuss] OmniOS DOS'd my entire network
Message-ID: <CALeZrrR4pRNd1_vXkGADEmnLWh6UOAkpa6jsVacpWcAeOcsgoA@mail.gmail.com>

This was a first for me and extremely painful to locate.

In the middle of the night between last Friday and Saturday, I started
getting down alerts from most of my network.   It took 4 engineers
including myself 9 hours to pinpoint the source of the problem.

The problem turned out to be one of my OmniOS boxes sending out pure
garbage constantly on layer 2 out the 10G network ports.   This disrupted
ARP caches on every machine on every VLAN that was trunked on these ports,
not just the VLANs that were configured on the server.   The switches
reported every port healthy and without error.   The traffic on the bad
port was not high either, just severely disruptive.

The affected OmniOS box appear to be healthy, as it was still serving the
VM data stores for over 350 virtual machines.   However, it like every
other service on the network appeared to be up and down repeatedly, but NFS
kept on recovering gracefully.

The only thing that finally identified this server was when one of us plug
a monitor to the console and saw "WARNING: proxy ARP problem?"  happening
so fast that it took taking a cellphone picture of it a high frame rate to
read it.   Powering off this server, cleared the problem for the entire
network, and its pools were taken over by its HA sister.

Googling for that warning brings up nothing useful.

Has anyone ever seen a problem like this?   How did you locate it?

-Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170509/97e8c1cf/attachment.html>

From danmcd at omniti.com  Tue May  9 20:22:05 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 9 May 2017 16:22:05 -0400
Subject: [OmniOS-discuss] OmniOS DOS'd my entire network
In-Reply-To: <CALeZrrR4pRNd1_vXkGADEmnLWh6UOAkpa6jsVacpWcAeOcsgoA@mail.gmail.com>
References: <CALeZrrR4pRNd1_vXkGADEmnLWh6UOAkpa6jsVacpWcAeOcsgoA@mail.gmail.com>
Message-ID: <40557F43-E0F3-4671-9200-DDBCDE2FD165@omniti.com>


> On May 9, 2017, at 3:32 PM, Schweiss, Chip <chip at innovates.com> wrote:
> 
> This was a first for me and extremely painful to locate.
> 
> In the middle of the night between last Friday and Saturday, I started getting down alerts from most of my network.   It took 4 engineers including myself 9 hours to pinpoint the source of the problem.
> 
> The problem turned out to be one of my OmniOS boxes sending out pure garbage constantly on layer 2 out the 10G network ports.   This disrupted ARP caches on every machine on every VLAN that was trunked on these ports, not just the VLANs that were configured on the server.   The switches reported every port healthy and without error.   The traffic on the bad port was not high either, just severely disruptive.

Whoa!  On L2 (like non-TCP/IP ethernet frames)?

> The affected OmniOS box appear to be healthy, as it was still serving the VM data stores for over 350 virtual machines.   However, it like every other service on the network appeared to be up and down repeatedly, but NFS kept on recovering gracefully.
> 
> The only thing that finally identified this server was when one of us plug a monitor to the console and saw "WARNING: proxy ARP problem?"  happening so fast that it took taking a cellphone picture of it a high frame rate to read it.   Powering off this server, cleared the problem for the entire network, and its pools were taken over by its HA sister.

If it's easy to do so, unplug or "ifconfig down" the interface next time this happens.

> Googling for that warning brings up nothing useful.
> 
> Has anyone ever seen a problem like this?   How did you locate it?

Should search src.illumos.org, you'll find this:

	http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/inet/ip/ip_arp.c#1449

We appear to be freaking out over another node having our IP.  The only caller with AR_CN_BOGON is after ip_nce_resolve_all() returns AR_BOGON.

I wonder if some other entity had the same IP, and they fed-back-upon-each-other negatively?

The message you cite should show an IP address with it:

	"proxy ARP problem?  Node '%s' is using %s on %s",

where the %s-es are MAC-address, IP-address, and interface-name respectively.  You didn't get examples with your digital camera, did you?

Dan


From chip at innovates.com  Tue May  9 20:40:35 2017
From: chip at innovates.com (Schweiss, Chip)
Date: Tue, 9 May 2017 15:40:35 -0500
Subject: [OmniOS-discuss] OmniOS DOS'd my entire network
In-Reply-To: <40557F43-E0F3-4671-9200-DDBCDE2FD165@omniti.com>
References: <CALeZrrR4pRNd1_vXkGADEmnLWh6UOAkpa6jsVacpWcAeOcsgoA@mail.gmail.com>
	<40557F43-E0F3-4671-9200-DDBCDE2FD165@omniti.com>
Message-ID: <CALeZrrS4LQ0mS4fvAyjFqrZmtTA_r7ET5S5sk_g25Ds3j5Y2tQ@mail.gmail.com>

Here's the screen shot:

Given the rarity of this, I wouldn't be surprised it never happens again to
me.   The major difficulty was locating the offending system.   All we were
finding was very poor TCP connections everywhere on or network.  Even VLANs
that were not active on the server, but trunked on its switch ports.

That mac address corresponds to another OmniOS server, that is not part of
the same HA cluster as this one.   It has not been shut down since the
incident.

-Chip





On Tue, May 9, 2017 at 3:22 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On May 9, 2017, at 3:32 PM, Schweiss, Chip <chip at innovates.com> wrote:
> >
> > This was a first for me and extremely painful to locate.
> >
> > In the middle of the night between last Friday and Saturday, I started
> getting down alerts from most of my network.   It took 4 engineers
> including myself 9 hours to pinpoint the source of the problem.
> >
> > The problem turned out to be one of my OmniOS boxes sending out pure
> garbage constantly on layer 2 out the 10G network ports.   This disrupted
> ARP caches on every machine on every VLAN that was trunked on these ports,
> not just the VLANs that were configured on the server.   The switches
> reported every port healthy and without error.   The traffic on the bad
> port was not high either, just severely disruptive.
>
> Whoa!  On L2 (like non-TCP/IP ethernet frames)?
>
> > The affected OmniOS box appear to be healthy, as it was still serving
> the VM data stores for over 350 virtual machines.   However, it like every
> other service on the network appeared to be up and down repeatedly, but NFS
> kept on recovering gracefully.
> >
> > The only thing that finally identified this server was when one of us
> plug a monitor to the console and saw "WARNING: proxy ARP problem?"
> happening so fast that it took taking a cellphone picture of it a high
> frame rate to read it.   Powering off this server, cleared the problem for
> the entire network, and its pools were taken over by its HA sister.
>
> If it's easy to do so, unplug or "ifconfig down" the interface next time
> this happens.
>
> > Googling for that warning brings up nothing useful.
> >
> > Has anyone ever seen a problem like this?   How did you locate it?
>
> Should search src.illumos.org, you'll find this:
>
>         http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/
> common/inet/ip/ip_arp.c#1449
>
> We appear to be freaking out over another node having our IP.  The only
> caller with AR_CN_BOGON is after ip_nce_resolve_all() returns AR_BOGON.
>
> I wonder if some other entity had the same IP, and they
> fed-back-upon-each-other negatively?
>
> The message you cite should show an IP address with it:
>
>         "proxy ARP problem?  Node '%s' is using %s on %s",
>
> where the %s-es are MAC-address, IP-address, and interface-name
> respectively.  You didn't get examples with your digital camera, did you?
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170509/e7164d8c/attachment.html>

From danmcd at omniti.com  Tue May  9 20:49:51 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 9 May 2017 16:49:51 -0400
Subject: [OmniOS-discuss] OmniOS DOS'd my entire network
In-Reply-To: <CALeZrrS4LQ0mS4fvAyjFqrZmtTA_r7ET5S5sk_g25Ds3j5Y2tQ@mail.gmail.com>
References: <CALeZrrR4pRNd1_vXkGADEmnLWh6UOAkpa6jsVacpWcAeOcsgoA@mail.gmail.com>
	<40557F43-E0F3-4671-9200-DDBCDE2FD165@omniti.com>
	<CALeZrrS4LQ0mS4fvAyjFqrZmtTA_r7ET5S5sk_g25Ds3j5Y2tQ@mail.gmail.com>
Message-ID: <473587A0-4632-401B-98DE-DF0DA8C0719E@omniti.com>


> On May 9, 2017, at 4:40 PM, Schweiss, Chip <chip at innovates.com> wrote:
> 
> Here's the screen shot:

<SNIP!>

Interesting.

So notice that the IP address in question is 10.28.17.29 (uggh, the leading-0 is a Mentat-ism we need to fix in -gate already).  And notice that the other node's MAC is 0c:c4:7a:66:a0:ad ?  You should see what node that MAC belongs to.

Dan


From lorban at bitronix.be  Wed May 10 09:21:13 2017
From: lorban at bitronix.be (Ludovic Orban)
Date: Wed, 10 May 2017 11:21:13 +0200
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
Message-ID: <CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>

In x86 asm, cmpl is both signed and unsigned, it's the following jump that
decides to work signed or not. In this case it's jl "jump if less" so it's
signed (vs jb "jump if before" that is unsigned). But I digress.

I've recompiled ksh93 with debug, no stripped symbols and no optimizations
(the binary is here: https://www.dropbox.com/s/brys628g40akruv/ksh93.gz?dl=0)
and managed to figure out where that infinite loop is happening:

> ::stack
job_byjid+5()
job_alloc+0x62()
job_post+0x1a2()
_sh_fork+0x265()
sh_ntfork+0xa99()
sh_exec+0x2be8()
sh_subshell+0x982()
comsubst+0xbf0()
varsub+0x3f4()
copyto+0xa2a()
sh_mactrim+0x196()
nv_setlist+0x220()
sh_exec+0xdb7()
sh_eval+0x2b9()
sh_trap+0x29b()
ed_setup+0x7ac()
ed_viread+0xf6()
slowread+0x181()
sfrd+0x4da()
_sffilbuf+0x433()
sfreserve+0x566()
exfile+0x808()
sh_main+0xb38()
main+0x25()
>

Looking at ksh' sources, my understanding is that job_post is stuck in that
else clause:
       else
       {
              /* create a new job */
              while((pw->p_job = job_alloc()) < 0)
                     job_wait((pid_t)1);
              pw->p_nxtjob = job.pwlist;
              pw->p_nxtproc = 0;
       }

Digging into the sources and stepping though the instructions of job_alloc
and job_byjid it looks like ksh cannot allocate a job id as it believes
they're all reserved. But so far, all this code is purely working on
internal structures of ksh so a LX bug would have no impact.

I'll continue looking into this as time permits and I'll post an update if
I find anything worth mentioning.

--
Ludovic



On Tue, May 9, 2017 at 5:15 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On May 9, 2017, at 11:05 AM, Dan McDonald <danmcd at omniti.com> wrote:
> >
> > And I've no good way to know what it's doing, as the illumos-native
> tools aren't giving me enough data.
>
> ksh93 appears to be looping in something:
>
> mdb: target stopped at:
> 0x42adf0:       movq   +0x350129(%rip),%rax     <0x77af20>
> > ::step
> mdb: target stopped at:
> 0x42adf7:       testq  %rax,%rax
> > ::step
> mdb: target stopped at:
> 0x42adfa:       jne    +0xc     <0x42ae08>
> > ::step
> mdb: target stopped at:
> 0x42adfc:       jmp    +0x28    <0x42ae26>
> > ::step
> mdb: target stopped at:
> 0x42ae26:       addl   $0x1,%r14d
> > ::step
> mdb: target stopped at:
> 0x42ae2a:       cmpl   0x10(%rsi),%r14d
> > ::step
> mdb: target stopped at:
> 0x42ae2e:       jl     -0x40    <0x42adf0>
> > ::step
> mdb: target stopped at:
> 0x42adf0:       movq   +0x350129(%rip),%rax     <0x77af20>
> > <rsi+0x10
> Usage: step [ over | out ] [SIG]
> > <rsi+0x10=P
>                 0x7fffff0470f0
> > 0x7fffff0470f0/D
> 0x7fffff0470f0: 2147483647
> > 0x7fffff0470f0/X
> 0x7fffff0470f0: 7fffffff
> > <r14d/P
> mdb: failed to read data from target: no mapping for address
> 0x761133e5:
> > <r14d=P
>                 0x761133e5
> >
>
> Something that never seems to exit.  Hmmm... I'm guessing r14d will never
> be less than 0x7ffffff with a signed compare (cmpl is signed,right?).
>
> NO idea how this happened.  :-/
>
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170510/630d7280/attachment.html>

From danmcd at omniti.com  Wed May 10 13:59:57 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 10 May 2017 09:59:57 -0400
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
	<CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
Message-ID: <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>

Wow, thank you for the further deep-diving.

> On May 10, 2017, at 5:21 AM, Ludovic Orban <lorban at bitronix.be> wrote:
> 
> Looking at ksh' sources, my understanding is that job_post is stuck in that else clause:
>        else
>        {
>               /* create a new job */
>               while((pw->p_job = job_alloc()) < 0)
>                      job_wait((pid_t)1);
>               pw->p_nxtjob = job.pwlist;
>               pw->p_nxtproc = 0;
>        }
> 
> Digging into the sources and stepping though the instructions of job_alloc and job_byjid it looks like ksh cannot allocate a job id as it believes they're all reserved. But so far, all this code is purely working on internal structures of ksh so a LX bug would have no impact.
> 
> I'll continue looking into this as time permits and I'll post an update if I find anything worth mentioning.
> 

Be careful of narrowing your focus too far.  I see some things worth considering:

1.) If the "if" you're not showing me dependent on something in global state that may have been mis-initialized by an LX emulation bug?

2.) Same question as #1, but applied to job_alloc() and job_wait().

I'm guessing LX in OmniOS is failing because I mismerged or plain forgot something, given that Nahum says he can run ksh93 on SmartOS just fine.


Please make sure you're looking at the bigger picture, but THANK YOU for the further investigation.

Dan


From chip at innovates.com  Wed May 10 15:29:49 2017
From: chip at innovates.com (Schweiss, Chip)
Date: Wed, 10 May 2017 10:29:49 -0500
Subject: [OmniOS-discuss] Resilver zero progress
Message-ID: <CALeZrrQ9piv+ps8EUBLRE8477ZdgVkMd-xi_4O=cz5iy5UToXA@mail.gmail.com>

I have a pool that has had a resilver running for about an hour but the
progress status is a bit alarming.  I'm concerned for some reason it will
not resilver.   Resilvers are tuned to be faster in /etc/system.   This is
on OmniOS r151014, currently fully updated.   Any suggestions?

-Chip

from /etc/system:

set zfs:zfs_resilver_delay = 0
set zfs:zfs_scrub_delay = 0
set zfs:zfs_top_maxinflight = 64
set zfs:zfs_resilver_min_time_ms = 5000


# zpool status hcp03
  pool: hcp03
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed May 10 09:22:15 2017
    1 scanned out of 545T at 1/s, (scan is slow, no estimated time)
    0 resilvered, 0.00% done
config:

        NAME                         STATE     READ WRITE CKSUM
        hcp03                        DEGRADED     0     0     0
          raidz2-0                   DEGRADED     0     0     0
            c0t5000C500846F161Fd0    ONLINE       0     0     0
            spare-1                  UNAVAIL      0     0     0
              5676922542927845170    UNAVAIL      0     0     0  was
/dev/dsk/c0t5000C5008473DBF3d0s0
              c0t5000C500846F1823d0  ONLINE       0     0     0
            c0t5000C500846F134Fd0    ONLINE       0     0     0
            c0t5000C500846F139Fd0    ONLINE       0     0     0
            c0t5000C5008473B89Fd0    ONLINE       0     0     0
            c0t5000C500846F145Bd0    ONLINE       0     0     0
            c0t5000C5008473B6BBd0    ONLINE       0     0     0
            c0t5000C500846F131Fd0    ONLINE       0     0     0
          raidz2-1                   ONLINE       0     0     0
            c0t5000C5008473BB63d0    ONLINE       0     0     0
            c0t5000C5008473C9C7d0    ONLINE       0     0     0
            c0t5000C500846F1A17d0    ONLINE       0     0     0
            c0t5000C5008473A0A3d0    ONLINE       0     0     0
            c0t5000C5008473D047d0    ONLINE       0     0     0
            c0t5000C5008473BF63d0    ONLINE       0     0     0
            c0t5000C5008473BC83d0    ONLINE       0     0     0
            c0t5000C5008473E35Bd0    ONLINE       0     0     0
          raidz2-2                   ONLINE       0     0     0
            c0t5000C5008473ABAFd0    ONLINE       0     0     0
            c0t5000C5008473ADF3d0    ONLINE       0     0     0
            c0t5000C5008473AE77d0    ONLINE       0     0     0
            c0t5000C5008473A23Bd0    ONLINE       0     0     0
            c0t5000C5008473C907d0    ONLINE       0     0     0
            c0t5000C5008473CCABd0    ONLINE       0     0     0
            c0t5000C5008473C77Fd0    ONLINE       0     0     0
            c0t5000C5008473B6D3d0    ONLINE       0     0     0
          raidz2-3                   ONLINE       0     0     0
            c0t5000C5008473E4FFd0    ONLINE       0     0     0
            c0t5000C5008473ECFFd0    ONLINE       0     0     0
            c0t5000C5008473F4C3d0    ONLINE       0     0     0
            c0t5000C5008473F8CFd0    ONLINE       0     0     0
            c0t5000C500846F1897d0    ONLINE       0     0     0
            c0t5000C500846F14B7d0    ONLINE       0     0     0
            c0t5000C500846F1353d0    ONLINE       0     0     0
            c0t5000C5008473EEDFd0    ONLINE       0     0     0
          raidz2-4                   ONLINE       0     0     0
            c0t5000C500846F144Bd0    ONLINE       0     0     0
            c0t5000C5008473F10Fd0    ONLINE       0     0     0
            c0t5000C500846F15CBd0    ONLINE       0     0     0
            c0t5000C500846F1493d0    ONLINE       0     0     0
            c0t5000C5008473E26Fd0    ONLINE       0     0     0
            c0t5000C500846F1A0Bd0    ONLINE       0     0     0
            c0t5000C5008473EE07d0    ONLINE       0     0     0
            c0t5000C500846F1453d0    ONLINE       0     0     0
          raidz2-5                   ONLINE       0     0     0
            c0t5000C500846F153Bd0    ONLINE       0     0     0
            c0t5000C5008473F9EBd0    ONLINE       0     0     0
            c0t5000C500846F14EFd0    ONLINE       0     0     0
            c0t5000C5008473AB0Bd0    ONLINE       0     0     0
            c0t5000C500846F140Bd0    ONLINE       0     0     0
            c0t5000C5008473FC0Fd0    ONLINE       0     0     0
            c0t5000C5008473DFA3d0    ONLINE       0     0     0
            c0t5000C5008473F89Bd0    ONLINE       0     0     0
          raidz2-6                   ONLINE       0     0     0
            c0t5000C500846F19BFd0    ONLINE       0     0     0
            c0t5000C5008473D1ABd0    ONLINE       0     0     0
            c0t5000C50084739FD3d0    ONLINE       0     0     0
            c0t5000C5008473FFB7d0    ONLINE       0     0     0
            c0t5000C5008473E72Fd0    ONLINE       0     0     0
            c0t5000C5008474022Bd0    ONLINE       0     0     0
            c0t5000C5008473D293d0    ONLINE       0     0     0
            c0t5000C500846F1413d0    ONLINE       0     0     0
          raidz2-7                   ONLINE       0     0     0
            c0t5000C500846F19CBd0    ONLINE       0     0     0
            c0t5000C500846F154Bd0    ONLINE       0     0     0
            c0t5000C5008473ADC7d0    ONLINE       0     0     0
            c0t5000C500846F19EFd0    ONLINE       0     0     0
            c0t5000C500846F18EBd0    ONLINE       0     0     0
            c0t5000C5008473F9BFd0    ONLINE       0     0     0
            c0t5000C5008473F403d0    ONLINE       0     0     0
            c0t5000C500846F13DFd0    ONLINE       0     0     0
          raidz2-8                   ONLINE       0     0     0
            c0t5000C5008473F173d0    ONLINE       0     0     0
            c0t5000C500846F183Fd0    ONLINE       0     0     0
            c0t5000C500846F151Bd0    ONLINE       0     0     0
            c0t5000C500846F146Bd0    ONLINE       0     0     0
            c0t5000C5008473F3CFd0    ONLINE       0     0     0
            c0t5000C5008473C5E3d0    ONLINE       0     0     0
            c0t5000C5008473A0EFd0    ONLINE       0     0     0
            c0t5000C5008473BF0Fd0    ONLINE       0     0     0
          raidz2-9                   ONLINE       0     0     0
            c0t5000C500846F13F3d0    ONLINE       0     0     0
            c0t5000C500846F1613d0    ONLINE       0     0     0
            c0t5000C500846F19E3d0    ONLINE       0     0     0
            c0t5000C500846F18ABd0    ONLINE       0     0     0
            c0t5000C500846F1443d0    ONLINE       0     0     0
            c0t5000C5008473FF6Bd0    ONLINE       0     0     0
            c0t5000C500846F1827d0    ONLINE       0     0     0
            c0t5000C50084719733d0    ONLINE       0     0     0
        spares
          c0t5000C500846F1823d0      INUSE     currently in use

errors: No known data errors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170510/7144b1cc/attachment.html>

From danmcd at omniti.com  Wed May 10 15:44:19 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 10 May 2017 11:44:19 -0400
Subject: [OmniOS-discuss] Resilver zero progress
In-Reply-To: <CALeZrrQ9piv+ps8EUBLRE8477ZdgVkMd-xi_4O=cz5iy5UToXA@mail.gmail.com>
References: <CALeZrrQ9piv+ps8EUBLRE8477ZdgVkMd-xi_4O=cz5iy5UToXA@mail.gmail.com>
Message-ID: <ED514107-6C1A-4F47-B3C6-53E58D06446C@omniti.com>

Off the top of my head, check /var/adm/messages for drive failures or other IO blocks.

Dan

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

> On May 10, 2017, at 11:29 AM, Schweiss, Chip <chip at innovates.com> wrote:
> 
> I have a pool that has had a resilver running for about an hour but the progress status is a bit alarming.  I'm concerned for some reason it will not resilver.   Resilvers are tuned to be faster in /etc/system.   This is on OmniOS r151014, currently fully updated.   Any suggestions?
> 
> -Chip
> 
> from /etc/system:
> 
> set zfs:zfs_resilver_delay = 0
> set zfs:zfs_scrub_delay = 0
> set zfs:zfs_top_maxinflight = 64
> set zfs:zfs_resilver_min_time_ms = 5000
> 
> 
> # zpool status hcp03
>   pool: hcp03
>  state: DEGRADED
> status: One or more devices is currently being resilvered.  The pool will
>         continue to function, possibly in a degraded state.
> action: Wait for the resilver to complete.
>   scan: resilver in progress since Wed May 10 09:22:15 2017
>     1 scanned out of 545T at 1/s, (scan is slow, no estimated time)
>     0 resilvered, 0.00% done
> config:
> 
>         NAME                         STATE     READ WRITE CKSUM
>         hcp03                        DEGRADED     0     0     0
>           raidz2-0                   DEGRADED     0     0     0
>             c0t5000C500846F161Fd0    ONLINE       0     0     0
>             spare-1                  UNAVAIL      0     0     0
>               5676922542927845170    UNAVAIL      0     0     0  was /dev/dsk/c0t5000C5008473DBF3d0s0
>               c0t5000C500846F1823d0  ONLINE       0     0     0
>             c0t5000C500846F134Fd0    ONLINE       0     0     0
>             c0t5000C500846F139Fd0    ONLINE       0     0     0
>             c0t5000C5008473B89Fd0    ONLINE       0     0     0
>             c0t5000C500846F145Bd0    ONLINE       0     0     0
>             c0t5000C5008473B6BBd0    ONLINE       0     0     0
>             c0t5000C500846F131Fd0    ONLINE       0     0     0
>           raidz2-1                   ONLINE       0     0     0
>             c0t5000C5008473BB63d0    ONLINE       0     0     0
>             c0t5000C5008473C9C7d0    ONLINE       0     0     0
>             c0t5000C500846F1A17d0    ONLINE       0     0     0
>             c0t5000C5008473A0A3d0    ONLINE       0     0     0
>             c0t5000C5008473D047d0    ONLINE       0     0     0
>             c0t5000C5008473BF63d0    ONLINE       0     0     0
>             c0t5000C5008473BC83d0    ONLINE       0     0     0
>             c0t5000C5008473E35Bd0    ONLINE       0     0     0
>           raidz2-2                   ONLINE       0     0     0
>             c0t5000C5008473ABAFd0    ONLINE       0     0     0
>             c0t5000C5008473ADF3d0    ONLINE       0     0     0
>             c0t5000C5008473AE77d0    ONLINE       0     0     0
>             c0t5000C5008473A23Bd0    ONLINE       0     0     0
>             c0t5000C5008473C907d0    ONLINE       0     0     0
>             c0t5000C5008473CCABd0    ONLINE       0     0     0
>             c0t5000C5008473C77Fd0    ONLINE       0     0     0
>             c0t5000C5008473B6D3d0    ONLINE       0     0     0
>           raidz2-3                   ONLINE       0     0     0
>             c0t5000C5008473E4FFd0    ONLINE       0     0     0
>             c0t5000C5008473ECFFd0    ONLINE       0     0     0
>             c0t5000C5008473F4C3d0    ONLINE       0     0     0
>             c0t5000C5008473F8CFd0    ONLINE       0     0     0
>             c0t5000C500846F1897d0    ONLINE       0     0     0
>             c0t5000C500846F14B7d0    ONLINE       0     0     0
>             c0t5000C500846F1353d0    ONLINE       0     0     0
>             c0t5000C5008473EEDFd0    ONLINE       0     0     0
>           raidz2-4                   ONLINE       0     0     0
>             c0t5000C500846F144Bd0    ONLINE       0     0     0
>             c0t5000C5008473F10Fd0    ONLINE       0     0     0
>             c0t5000C500846F15CBd0    ONLINE       0     0     0
>             c0t5000C500846F1493d0    ONLINE       0     0     0
>             c0t5000C5008473E26Fd0    ONLINE       0     0     0
>             c0t5000C500846F1A0Bd0    ONLINE       0     0     0
>             c0t5000C5008473EE07d0    ONLINE       0     0     0
>             c0t5000C500846F1453d0    ONLINE       0     0     0
>           raidz2-5                   ONLINE       0     0     0
>             c0t5000C500846F153Bd0    ONLINE       0     0     0
>             c0t5000C5008473F9EBd0    ONLINE       0     0     0
>             c0t5000C500846F14EFd0    ONLINE       0     0     0
>             c0t5000C5008473AB0Bd0    ONLINE       0     0     0
>             c0t5000C500846F140Bd0    ONLINE       0     0     0
>             c0t5000C5008473FC0Fd0    ONLINE       0     0     0
>             c0t5000C5008473DFA3d0    ONLINE       0     0     0
>             c0t5000C5008473F89Bd0    ONLINE       0     0     0
>           raidz2-6                   ONLINE       0     0     0
>             c0t5000C500846F19BFd0    ONLINE       0     0     0
>             c0t5000C5008473D1ABd0    ONLINE       0     0     0
>             c0t5000C50084739FD3d0    ONLINE       0     0     0
>             c0t5000C5008473FFB7d0    ONLINE       0     0     0
>             c0t5000C5008473E72Fd0    ONLINE       0     0     0
>             c0t5000C5008474022Bd0    ONLINE       0     0     0
>             c0t5000C5008473D293d0    ONLINE       0     0     0
>             c0t5000C500846F1413d0    ONLINE       0     0     0
>           raidz2-7                   ONLINE       0     0     0
>             c0t5000C500846F19CBd0    ONLINE       0     0     0
>             c0t5000C500846F154Bd0    ONLINE       0     0     0
>             c0t5000C5008473ADC7d0    ONLINE       0     0     0
>             c0t5000C500846F19EFd0    ONLINE       0     0     0
>             c0t5000C500846F18EBd0    ONLINE       0     0     0
>             c0t5000C5008473F9BFd0    ONLINE       0     0     0
>             c0t5000C5008473F403d0    ONLINE       0     0     0
>             c0t5000C500846F13DFd0    ONLINE       0     0     0
>           raidz2-8                   ONLINE       0     0     0
>             c0t5000C5008473F173d0    ONLINE       0     0     0
>             c0t5000C500846F183Fd0    ONLINE       0     0     0
>             c0t5000C500846F151Bd0    ONLINE       0     0     0
>             c0t5000C500846F146Bd0    ONLINE       0     0     0
>             c0t5000C5008473F3CFd0    ONLINE       0     0     0
>             c0t5000C5008473C5E3d0    ONLINE       0     0     0
>             c0t5000C5008473A0EFd0    ONLINE       0     0     0
>             c0t5000C5008473BF0Fd0    ONLINE       0     0     0
>           raidz2-9                   ONLINE       0     0     0
>             c0t5000C500846F13F3d0    ONLINE       0     0     0
>             c0t5000C500846F1613d0    ONLINE       0     0     0
>             c0t5000C500846F19E3d0    ONLINE       0     0     0
>             c0t5000C500846F18ABd0    ONLINE       0     0     0
>             c0t5000C500846F1443d0    ONLINE       0     0     0
>             c0t5000C5008473FF6Bd0    ONLINE       0     0     0
>             c0t5000C500846F1827d0    ONLINE       0     0     0
>             c0t5000C50084719733d0    ONLINE       0     0     0
>         spares
>           c0t5000C500846F1823d0      INUSE     currently in use
> 
> errors: No known data errors
> 
> _______________________________________________
> 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/20170510/191ae8ac/attachment-0001.html>

From lorban at bitronix.be  Wed May 10 19:44:37 2017
From: lorban at bitronix.be (Ludovic Orban)
Date: Wed, 10 May 2017 21:44:37 +0200
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
	<CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
	<3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>
Message-ID: <CAN0RhAOUyn1a6noqgrNKUFZXXeqx1PiFktLn=wZotQ0kpnyxaQ@mail.gmail.com>

Okay, I found what causes ksh to misbehave. It's in sh_init(), when
shgd->lim.child_max is initialized with the results of
getconf("CHILD_MAX"), see:
https://github.com/att/ast/blob/master/src/cmd/ksh93/sh/init.c#L1289

I've commented out that line, hardcoded shgd->lim.child_max to 128, rebuilt
and voila: ksh works as it should.

Now I have to dig into that getconf() method to figure out what the
returned value is and where it's coming from. Sounds trivial, but my C is
*very* rusty, the asm gcc generates doesn't look at all what the JVM's JIT
generates (which gives me wrong reflexes as I'm used to the latter) and I'm
not very familiar with mdb.

Oh well, that turned into a nice debugging re-training session which I very
much needed. That reminds me the good old days at my first job when I was
porting Linux apps to Solaris.

Thank you for maintaining such a well-designed and pleasant to use OS!


On Wed, May 10, 2017 at 3:59 PM, Dan McDonald <danmcd at omniti.com> wrote:

> Wow, thank you for the further deep-diving.
>
> > On May 10, 2017, at 5:21 AM, Ludovic Orban <lorban at bitronix.be> wrote:
> >
> > Looking at ksh' sources, my understanding is that job_post is stuck in
> that else clause:
> >        else
> >        {
> >               /* create a new job */
> >               while((pw->p_job = job_alloc()) < 0)
> >                      job_wait((pid_t)1);
> >               pw->p_nxtjob = job.pwlist;
> >               pw->p_nxtproc = 0;
> >        }
> >
> > Digging into the sources and stepping though the instructions of
> job_alloc and job_byjid it looks like ksh cannot allocate a job id as it
> believes they're all reserved. But so far, all this code is purely working
> on internal structures of ksh so a LX bug would have no impact.
> >
> > I'll continue looking into this as time permits and I'll post an update
> if I find anything worth mentioning.
> >
>
> Be careful of narrowing your focus too far.  I see some things worth
> considering:
>
> 1.) If the "if" you're not showing me dependent on something in global
> state that may have been mis-initialized by an LX emulation bug?
>
> 2.) Same question as #1, but applied to job_alloc() and job_wait().
>
> I'm guessing LX in OmniOS is failing because I mismerged or plain forgot
> something, given that Nahum says he can run ksh93 on SmartOS just fine.
>
>
> Please make sure you're looking at the bigger picture, but THANK YOU for
> the further investigation.
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170510/e1d075b0/attachment.html>

From danmcd at omniti.com  Wed May 10 20:32:03 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 10 May 2017 16:32:03 -0400
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <CAN0RhAOUyn1a6noqgrNKUFZXXeqx1PiFktLn=wZotQ0kpnyxaQ@mail.gmail.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
	<CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
	<3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>
	<CAN0RhAOUyn1a6noqgrNKUFZXXeqx1PiFktLn=wZotQ0kpnyxaQ@mail.gmail.com>
Message-ID: <E99BABD9-900D-4FED-A0FE-550AABFA6D0E@omniti.com>

Again, thank you for the digging.  I'd be interested in why ksh's getconf() fails as well.

Thanks,
Dan

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

> On May 10, 2017, at 3:44 PM, Ludovic Orban <lorban at bitronix.be> wrote:
> 
> Okay, I found what causes ksh to misbehave. It's in sh_init(), when shgd->lim.child_max is initialized with the results of getconf("CHILD_MAX"), see: https://github.com/att/ast/blob/master/src/cmd/ksh93/sh/init.c#L1289
> 
> I've commented out that line, hardcoded shgd->lim.child_max to 128, rebuilt and voila: ksh works as it should.
> 
> Now I have to dig into that getconf() method to figure out what the returned value is and where it's coming from. Sounds trivial, but my C is *very* rusty, the asm gcc generates doesn't look at all what the JVM's JIT generates (which gives me wrong reflexes as I'm used to the latter) and I'm not very familiar with mdb.
> 
> Oh well, that turned into a nice debugging re-training session which I very much needed. That reminds me the good old days at my first job when I was porting Linux apps to Solaris.
> 
> Thank you for maintaining such a well-designed and pleasant to use OS!
> 
> 
>> On Wed, May 10, 2017 at 3:59 PM, Dan McDonald <danmcd at omniti.com> wrote:
>> Wow, thank you for the further deep-diving.
>> 
>> > On May 10, 2017, at 5:21 AM, Ludovic Orban <lorban at bitronix.be> wrote:
>> >
>> > Looking at ksh' sources, my understanding is that job_post is stuck in that else clause:
>> >        else
>> >        {
>> >               /* create a new job */
>> >               while((pw->p_job = job_alloc()) < 0)
>> >                      job_wait((pid_t)1);
>> >               pw->p_nxtjob = job.pwlist;
>> >               pw->p_nxtproc = 0;
>> >        }
>> >
>> > Digging into the sources and stepping though the instructions of job_alloc and job_byjid it looks like ksh cannot allocate a job id as it believes they're all reserved. But so far, all this code is purely working on internal structures of ksh so a LX bug would have no impact.
>> >
>> > I'll continue looking into this as time permits and I'll post an update if I find anything worth mentioning.
>> >
>> 
>> Be careful of narrowing your focus too far.  I see some things worth considering:
>> 
>> 1.) If the "if" you're not showing me dependent on something in global state that may have been mis-initialized by an LX emulation bug?
>> 
>> 2.) Same question as #1, but applied to job_alloc() and job_wait().
>> 
>> I'm guessing LX in OmniOS is failing because I mismerged or plain forgot something, given that Nahum says he can run ksh93 on SmartOS just fine.
>> 
>> 
>> Please make sure you're looking at the bigger picture, but THANK YOU for the further investigation.
>> 
>> Dan
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170510/54ab8ba4/attachment.html>

From richard.elling at richardelling.com  Wed May 10 23:22:24 2017
From: richard.elling at richardelling.com (Richard Elling)
Date: Wed, 10 May 2017 16:22:24 -0700
Subject: [OmniOS-discuss] Resilver zero progress
In-Reply-To: <CALeZrrQ9piv+ps8EUBLRE8477ZdgVkMd-xi_4O=cz5iy5UToXA@mail.gmail.com>
References: <CALeZrrQ9piv+ps8EUBLRE8477ZdgVkMd-xi_4O=cz5iy5UToXA@mail.gmail.com>
Message-ID: <5D3C2ED4-AEBC-4A90-92BF-23E80E153E77@richardelling.com>


> On May 10, 2017, at 8:29 AM, Schweiss, Chip <chip at innovates.com> wrote:
> 
> I have a pool that has had a resilver running for about an hour but the progress status is a bit alarming.  I'm concerned for some reason it will not resilver.   Resilvers are tuned to be faster in /etc/system.   This is on OmniOS r151014, currently fully updated.   Any suggestions?

mdb?s "::zfs_dbgmsg" macro shows scan progress
 ? richard

> 
> -Chip
> 
> from /etc/system:
> 
> set zfs:zfs_resilver_delay = 0
> set zfs:zfs_scrub_delay = 0
> set zfs:zfs_top_maxinflight = 64
> set zfs:zfs_resilver_min_time_ms = 5000
> 
> 
> # zpool status hcp03
>   pool: hcp03
>  state: DEGRADED
> status: One or more devices is currently being resilvered.  The pool will
>         continue to function, possibly in a degraded state.
> action: Wait for the resilver to complete.
>   scan: resilver in progress since Wed May 10 09:22:15 2017
>     1 scanned out of 545T at 1/s, (scan is slow, no estimated time)
>     0 resilvered, 0.00% done
> config:
> 
>         NAME                         STATE     READ WRITE CKSUM
>         hcp03                        DEGRADED     0     0     0
>           raidz2-0                   DEGRADED     0     0     0
>             c0t5000C500846F161Fd0    ONLINE       0     0     0
>             spare-1                  UNAVAIL      0     0     0
>               5676922542927845170    UNAVAIL      0     0     0  was /dev/dsk/c0t5000C5008473DBF3d0s0
>               c0t5000C500846F1823d0  ONLINE       0     0     0
>             c0t5000C500846F134Fd0    ONLINE       0     0     0
>             c0t5000C500846F139Fd0    ONLINE       0     0     0
>             c0t5000C5008473B89Fd0    ONLINE       0     0     0
>             c0t5000C500846F145Bd0    ONLINE       0     0     0
>             c0t5000C5008473B6BBd0    ONLINE       0     0     0
>             c0t5000C500846F131Fd0    ONLINE       0     0     0
>           raidz2-1                   ONLINE       0     0     0
>             c0t5000C5008473BB63d0    ONLINE       0     0     0
>             c0t5000C5008473C9C7d0    ONLINE       0     0     0
>             c0t5000C500846F1A17d0    ONLINE       0     0     0
>             c0t5000C5008473A0A3d0    ONLINE       0     0     0
>             c0t5000C5008473D047d0    ONLINE       0     0     0
>             c0t5000C5008473BF63d0    ONLINE       0     0     0
>             c0t5000C5008473BC83d0    ONLINE       0     0     0
>             c0t5000C5008473E35Bd0    ONLINE       0     0     0
>           raidz2-2                   ONLINE       0     0     0
>             c0t5000C5008473ABAFd0    ONLINE       0     0     0
>             c0t5000C5008473ADF3d0    ONLINE       0     0     0
>             c0t5000C5008473AE77d0    ONLINE       0     0     0
>             c0t5000C5008473A23Bd0    ONLINE       0     0     0
>             c0t5000C5008473C907d0    ONLINE       0     0     0
>             c0t5000C5008473CCABd0    ONLINE       0     0     0
>             c0t5000C5008473C77Fd0    ONLINE       0     0     0
>             c0t5000C5008473B6D3d0    ONLINE       0     0     0
>           raidz2-3                   ONLINE       0     0     0
>             c0t5000C5008473E4FFd0    ONLINE       0     0     0
>             c0t5000C5008473ECFFd0    ONLINE       0     0     0
>             c0t5000C5008473F4C3d0    ONLINE       0     0     0
>             c0t5000C5008473F8CFd0    ONLINE       0     0     0
>             c0t5000C500846F1897d0    ONLINE       0     0     0
>             c0t5000C500846F14B7d0    ONLINE       0     0     0
>             c0t5000C500846F1353d0    ONLINE       0     0     0
>             c0t5000C5008473EEDFd0    ONLINE       0     0     0
>           raidz2-4                   ONLINE       0     0     0
>             c0t5000C500846F144Bd0    ONLINE       0     0     0
>             c0t5000C5008473F10Fd0    ONLINE       0     0     0
>             c0t5000C500846F15CBd0    ONLINE       0     0     0
>             c0t5000C500846F1493d0    ONLINE       0     0     0
>             c0t5000C5008473E26Fd0    ONLINE       0     0     0
>             c0t5000C500846F1A0Bd0    ONLINE       0     0     0
>             c0t5000C5008473EE07d0    ONLINE       0     0     0
>             c0t5000C500846F1453d0    ONLINE       0     0     0
>           raidz2-5                   ONLINE       0     0     0
>             c0t5000C500846F153Bd0    ONLINE       0     0     0
>             c0t5000C5008473F9EBd0    ONLINE       0     0     0
>             c0t5000C500846F14EFd0    ONLINE       0     0     0
>             c0t5000C5008473AB0Bd0    ONLINE       0     0     0
>             c0t5000C500846F140Bd0    ONLINE       0     0     0
>             c0t5000C5008473FC0Fd0    ONLINE       0     0     0
>             c0t5000C5008473DFA3d0    ONLINE       0     0     0
>             c0t5000C5008473F89Bd0    ONLINE       0     0     0
>           raidz2-6                   ONLINE       0     0     0
>             c0t5000C500846F19BFd0    ONLINE       0     0     0
>             c0t5000C5008473D1ABd0    ONLINE       0     0     0
>             c0t5000C50084739FD3d0    ONLINE       0     0     0
>             c0t5000C5008473FFB7d0    ONLINE       0     0     0
>             c0t5000C5008473E72Fd0    ONLINE       0     0     0
>             c0t5000C5008474022Bd0    ONLINE       0     0     0
>             c0t5000C5008473D293d0    ONLINE       0     0     0
>             c0t5000C500846F1413d0    ONLINE       0     0     0
>           raidz2-7                   ONLINE       0     0     0
>             c0t5000C500846F19CBd0    ONLINE       0     0     0
>             c0t5000C500846F154Bd0    ONLINE       0     0     0
>             c0t5000C5008473ADC7d0    ONLINE       0     0     0
>             c0t5000C500846F19EFd0    ONLINE       0     0     0
>             c0t5000C500846F18EBd0    ONLINE       0     0     0
>             c0t5000C5008473F9BFd0    ONLINE       0     0     0
>             c0t5000C5008473F403d0    ONLINE       0     0     0
>             c0t5000C500846F13DFd0    ONLINE       0     0     0
>           raidz2-8                   ONLINE       0     0     0
>             c0t5000C5008473F173d0    ONLINE       0     0     0
>             c0t5000C500846F183Fd0    ONLINE       0     0     0
>             c0t5000C500846F151Bd0    ONLINE       0     0     0
>             c0t5000C500846F146Bd0    ONLINE       0     0     0
>             c0t5000C5008473F3CFd0    ONLINE       0     0     0
>             c0t5000C5008473C5E3d0    ONLINE       0     0     0
>             c0t5000C5008473A0EFd0    ONLINE       0     0     0
>             c0t5000C5008473BF0Fd0    ONLINE       0     0     0
>           raidz2-9                   ONLINE       0     0     0
>             c0t5000C500846F13F3d0    ONLINE       0     0     0
>             c0t5000C500846F1613d0    ONLINE       0     0     0
>             c0t5000C500846F19E3d0    ONLINE       0     0     0
>             c0t5000C500846F18ABd0    ONLINE       0     0     0
>             c0t5000C500846F1443d0    ONLINE       0     0     0
>             c0t5000C5008473FF6Bd0    ONLINE       0     0     0
>             c0t5000C500846F1827d0    ONLINE       0     0     0
>             c0t5000C50084719733d0    ONLINE       0     0     0
>         spares
>           c0t5000C500846F1823d0      INUSE     currently in use
> 
> errors: No known data errors
> 
> _______________________________________________
> 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/20170510/c25eb5d8/attachment-0001.html>

From josh at sysmgr.org  Wed May 10 23:44:56 2017
From: josh at sysmgr.org (Joshua M. Clulow)
Date: Wed, 10 May 2017 16:44:56 -0700
Subject: [OmniOS-discuss] Resilver zero progress
In-Reply-To: <5D3C2ED4-AEBC-4A90-92BF-23E80E153E77@richardelling.com>
References: <CALeZrrQ9piv+ps8EUBLRE8477ZdgVkMd-xi_4O=cz5iy5UToXA@mail.gmail.com>
	<5D3C2ED4-AEBC-4A90-92BF-23E80E153E77@richardelling.com>
Message-ID: <CAEwA5nJsV=EeSgPjevPSSn_aVc4KD58B2_zuXqFY3HSFV7DmVw@mail.gmail.com>

On 10 May 2017 at 16:22, Richard Elling
<richard.elling at richardelling.com> wrote:
> mdb?s "::zfs_dbgmsg" macro shows scan progress

You can also watch the messages in real-time using DTrace; e.g.,

dtrace -qn '
        BEGIN
        {
                last = walltimestamp;
        }

        zfs-dbgmsg
        /walltimestamp - last > 10000000000/
        {
                printf("\n");
        }

        zfs-dbgmsg
        {
                printf("%Y  %s\n", walltimestamp, stringof(arg0));
                last = walltimestamp;
        }
'


Cheers.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org

From lorban at bitronix.be  Thu May 11 09:11:14 2017
From: lorban at bitronix.be (Ludovic Orban)
Date: Thu, 11 May 2017 11:11:14 +0200
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <E99BABD9-900D-4FED-A0FE-550AABFA6D0E@omniti.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
	<CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
	<3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>
	<CAN0RhAOUyn1a6noqgrNKUFZXXeqx1PiFktLn=wZotQ0kpnyxaQ@mail.gmail.com>
	<E99BABD9-900D-4FED-A0FE-550AABFA6D0E@omniti.com>
Message-ID: <CAN0RhAM2JFHhhXdm4DVym7fEOWs0rdvEL5J1GbV+veH36_MDVw@mail.gmail.com>

I think I found the root cause. At least, I'm 90% certain what follows is
correct and is the cause of the problem.

 getconf("CHILD_MAX") ends up calling sysconf(_SC_CHILD_MAX) which can also
be read from a shell with ulimit -u.

Here's what I get from a few different machines:

# uname -a ; ulimit -u
SunOS omnios 5.11 omnios-r151020-4151d05 i86pc i386 i86pc
29995
#

# uname -a ; ulimit -u
Linux opensuse 4.4.27-2-default #1 SMP Thu Nov 3 14:59:54 UTC 2016
(5c21e7c) x86_64 x86_64 x86_64 GNU/Linux
1200
#

# uname -a ; ulimit -u
Linux debian-8 4.4 BrandZ virtual linux x86_64 GNU/Linux
2147483647
#

Apparently, ksh isn't very happy when CHILD_MAX equals to MAX_INT, but
that's probably a ksh bug.

If my understanding of the LX code is correct, sysconf(_SC_CHILD_MAX) ends
up being translated to lx_getrlimit() which would return the value of
zone.max-lwps. Looks like an odd default to me, but I can't say for sure.
Since I haven't configured any rctl on my lx zone, apparently the default
is MAX_INT. I assume smartos uses a different default, but I wish I could
double-check that.

Now, I'm not sure how this could or should be fixed.

--
Ludovic


On Wed, May 10, 2017 at 10:32 PM, Dan McDonald <danmcd at omniti.com> wrote:

> Again, thank you for the digging.  I'd be interested in why ksh's
> getconf() fails as well.
>
> Thanks,
> Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
> On May 10, 2017, at 3:44 PM, Ludovic Orban <lorban at bitronix.be> wrote:
>
> Okay, I found what causes ksh to misbehave. It's in sh_init(), when
> shgd->lim.child_max is initialized with the results of
> getconf("CHILD_MAX"), see: https://github.com/att/ast/
> blob/master/src/cmd/ksh93/sh/init.c#L1289
>
> I've commented out that line, hardcoded shgd->lim.child_max to 128,
> rebuilt and voila: ksh works as it should.
>
> Now I have to dig into that getconf() method to figure out what the
> returned value is and where it's coming from. Sounds trivial, but my C is
> *very* rusty, the asm gcc generates doesn't look at all what the JVM's JIT
> generates (which gives me wrong reflexes as I'm used to the latter) and I'm
> not very familiar with mdb.
>
> Oh well, that turned into a nice debugging re-training session which I
> very much needed. That reminds me the good old days at my first job when I
> was porting Linux apps to Solaris.
>
> Thank you for maintaining such a well-designed and pleasant to use OS!
>
>
> On Wed, May 10, 2017 at 3:59 PM, Dan McDonald <danmcd at omniti.com> wrote:
>
>> Wow, thank you for the further deep-diving.
>>
>> > On May 10, 2017, at 5:21 AM, Ludovic Orban <lorban at bitronix.be> wrote:
>> >
>> > Looking at ksh' sources, my understanding is that job_post is stuck in
>> that else clause:
>> >        else
>> >        {
>> >               /* create a new job */
>> >               while((pw->p_job = job_alloc()) < 0)
>> >                      job_wait((pid_t)1);
>> >               pw->p_nxtjob = job.pwlist;
>> >               pw->p_nxtproc = 0;
>> >        }
>> >
>> > Digging into the sources and stepping though the instructions of
>> job_alloc and job_byjid it looks like ksh cannot allocate a job id as it
>> believes they're all reserved. But so far, all this code is purely working
>> on internal structures of ksh so a LX bug would have no impact.
>> >
>> > I'll continue looking into this as time permits and I'll post an update
>> if I find anything worth mentioning.
>> >
>>
>> Be careful of narrowing your focus too far.  I see some things worth
>> considering:
>>
>> 1.) If the "if" you're not showing me dependent on something in global
>> state that may have been mis-initialized by an LX emulation bug?
>>
>> 2.) Same question as #1, but applied to job_alloc() and job_wait().
>>
>> I'm guessing LX in OmniOS is failing because I mismerged or plain forgot
>> something, given that Nahum says he can run ksh93 on SmartOS just fine.
>>
>>
>> Please make sure you're looking at the bigger picture, but THANK YOU for
>> the further investigation.
>>
>> Dan
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170511/204bbed9/attachment.html>

From eric.sproul at circonus.com  Thu May 11 13:47:19 2017
From: eric.sproul at circonus.com (Eric Sproul)
Date: Thu, 11 May 2017 09:47:19 -0400
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <CAN0RhAM2JFHhhXdm4DVym7fEOWs0rdvEL5J1GbV+veH36_MDVw@mail.gmail.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
	<CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
	<3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>
	<CAN0RhAOUyn1a6noqgrNKUFZXXeqx1PiFktLn=wZotQ0kpnyxaQ@mail.gmail.com>
	<E99BABD9-900D-4FED-A0FE-550AABFA6D0E@omniti.com>
	<CAN0RhAM2JFHhhXdm4DVym7fEOWs0rdvEL5J1GbV+veH36_MDVw@mail.gmail.com>
Message-ID: <CAO8hXRCwrnYCvwLLXxFacJPW_o+kv0EX-OewAMgQO-SYT3HQ=w@mail.gmail.com>

On Thu, May 11, 2017 at 5:11 AM, Ludovic Orban <lorban at bitronix.be> wrote:
> I assume smartos uses a different default, but I wish I could
> double-check that.

I have a not-too-old SmartOS box at my disposal:

Global zone:

# uname -a; ulimit -u
SunOS <redacted> 5.11 joyent_20161110T013148Z i86pc i386 i86pc
99994

In an Ubuntu 16.04 LX zone:

# uname -a; ulimit -u
Linux <redacted> 4.4 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux
2000

Eric

From danmcd at omniti.com  Thu May 11 14:15:13 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 11 May 2017 10:15:13 -0400
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <CAN0RhAM2JFHhhXdm4DVym7fEOWs0rdvEL5J1GbV+veH36_MDVw@mail.gmail.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
	<CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
	<3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>
	<CAN0RhAOUyn1a6noqgrNKUFZXXeqx1PiFktLn=wZotQ0kpnyxaQ@mail.gmail.com>
	<E99BABD9-900D-4FED-A0FE-550AABFA6D0E@omniti.com>
	<CAN0RhAM2JFHhhXdm4DVym7fEOWs0rdvEL5J1GbV+veH36_MDVw@mail.gmail.com>
Message-ID: <5960A1AB-73ED-45ED-A833-5C82CE6425F1@omniti.com>


> On May 11, 2017, at 5:11 AM, Ludovic Orban <lorban at bitronix.be> wrote:
> 
> If my understanding of the LX code is correct, sysconf(_SC_CHILD_MAX) ends up being translated to lx_getrlimit() which would return the value of zone.max-lwps. Looks like an odd default to me, but I can't say for sure. Since I haven't configured any rctl on my lx zone, apparently the default is MAX_INT. I assume smartos uses a different default, but I wish I could double-check that.
> 
> Now, I'm not sure how this could or should be fixed.

What's REALLY weird is that our implementation of lx_getrlimit() is NO DIFFERENT from illumos-joyent's.  The ONLY differences in $SRC/uts/common/brand/lx/ are lint fixes on the OmniOS side, none of which go near lx_getrlimit().

I wonder if it's a function of which libc/glibc you have?  A quick way to find out is to run the attached D script, and then run the ulimit command to see how (and if) we get here and what happens.  Here's what I get, which yields MAX_INT:

bloody(~)[1]% bg
[1]    sudo /tmp/lx-rlimit-proc.d &
bloody(~)[0]% sudo zlogin lx1 ulimit -u
CPU FUNCTION                                 
  5  -> lx_getrlimit                          
2147483647
              libc.so.6`0x7ffffe2fc0a7

              lx_brand`lx_syscall_enter+0x16f
              unix`sys_syscall+0x145

  5   | lx_getrlimit:entry                    
  5    -> lx_getrlimit_common                 
  5    <- lx_getrlimit_common                 Returns 0x0
  5    -> get_udatamodel                      
  5    <- get_udatamodel                      Returns 0x200000
  5    -> copyout                             
  5    <- kcopy                               Returns 0x0
  5  <- lx_getrlimit                          Returns 0x0
bloody(~)[0]%   6  -> lx_getrlimit                          
              0x7ffffe6fc0a7

              lx_brand`lx_syscall_enter+0x16f
              unix`sys_syscall+0x145

  6   | lx_getrlimit:entry                    
  6    -> lx_getrlimit_common                 
  6    <- lx_getrlimit_common                 Returns 0x0
  6    -> get_udatamodel                      
  6    <- get_udatamodel                      Returns 0x200000
  6    -> copyout                             
  6    <- kcopy                               Returns 0x0
  6  <- lx_getrlimit                          Returns 0x0
  6  -> lx_getrlimit                          
              0x7ffffe6fc0a7

              lx_brand`lx_syscall_enter+0x16f
              unix`sys_syscall+0x145

  6   | lx_getrlimit:entry                    
  6    -> lx_getrlimit_common                 
  6    <- lx_getrlimit_common                 Returns 0x0
  6    -> get_udatamodel                      
  6    <- get_udatamodel                      Returns 0x200000
  6    -> copyout                             
  6    <- kcopy                               Returns 0x0
  6  <- lx_getrlimit                          Returns 0x0


I'd be interested in knowing what happens on the SmartOS box.  I also wonder if SmartOS launches the zone processes with lower limits already in place or not?

Dan




From danmcd at omniti.com  Thu May 11 14:28:10 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 11 May 2017 10:28:10 -0400
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <5960A1AB-73ED-45ED-A833-5C82CE6425F1@omniti.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
	<CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
	<3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>
	<CAN0RhAOUyn1a6noqgrNKUFZXXeqx1PiFktLn=wZotQ0kpnyxaQ@mail.gmail.com>
	<E99BABD9-900D-4FED-A0FE-550AABFA6D0E@omniti.com>
	<CAN0RhAM2JFHhhXdm4DVym7fEOWs0rdvEL5J1GbV+veH36_MDVw@mail.gmail.com>
	<5960A1AB-73ED-45ED-A833-5C82CE6425F1@omniti.com>
Message-ID: <6E6CC889-4DD8-458B-8F64-DC097E4431E1@omniti.com>

SCRATCH THAT!  I figured it out.  zone.max-lwps is the resource control that ALSO caps this rlimit.

What I don't know is how SmartOS lowers theirs to 2000, as our illumos sources *appear* to be identical in these regards.  I see some things in smartos-live (which we have none of) that could explain it.  I've a note out to the Joyent folks asking about this.

One thing you can DO is this:

	set max-lwps=2000

in the zone's configuration.  I just tried this in realtime:

bloody(~/ws)[0]% sudo zlogin lx1 ulimit -u
2147483647
bloody(~/ws)[0]% sudo zonecfg -z lx1
zonecfg:lx1> set max-lwps=2000
zonecfg:lx1> exit
bloody(~/ws)[0]% sudo zlogin lx1 ulimit -u
2147483647
bloody(~/ws)[0]% sudo zoneadm -z lx1 reboot
bloody(~/ws)[0]% echo "let it boot..."
let it boot...
bloody(~/ws)[0]% sudo zlogin lx1 ulimit -u
2000
bloody(~/ws)[0]% 

You need to reboot the zone after changing the config, as you can see.

And ksh93 starts behaving itself WONDERFULLY afterwards.  I'll update the documentation.

Thanks,
Dan


From mir at miras.org  Thu May 11 14:33:29 2017
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 11 May 2017 16:33:29 +0200
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <CAN0RhAM2JFHhhXdm4DVym7fEOWs0rdvEL5J1GbV+veH36_MDVw@mail.gmail.com>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
	<CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
	<3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>
	<CAN0RhAOUyn1a6noqgrNKUFZXXeqx1PiFktLn=wZotQ0kpnyxaQ@mail.gmail.com>
	<E99BABD9-900D-4FED-A0FE-550AABFA6D0E@omniti.com>
	<CAN0RhAM2JFHhhXdm4DVym7fEOWs0rdvEL5J1GbV+veH36_MDVw@mail.gmail.com>
Message-ID: <20170511163329.40c993e4@sleipner.datanom.net>

On Thu, 11 May 2017 11:11:14 +0200
Ludovic Orban <lorban at bitronix.be> wrote:

> 
> Apparently, ksh isn't very happy when CHILD_MAX equals to MAX_INT, but
> that's probably a ksh bug.
> 
Could it be ksh interprets int as it was defined in the 32bit OS days
int = 16bit = INT_MAX 32767 and expecting to receive a signed
int?

This is obviously wrong since ISO/IEC 9899 only requires an int to be
at least 2^16 - 1. INT_MAX is defined in limits.h

-- 
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:
Witch!  Witch!  They'll burn ya!
		-- Hag, "Tomorrow is Yesterday", stardate unknown
-------------- 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/20170511/fde29ebc/attachment.bin>

From lorban at bitronix.be  Fri May 12 08:25:32 2017
From: lorban at bitronix.be (Ludovic Orban)
Date: Fri, 12 May 2017 10:25:32 +0200
Subject: [OmniOS-discuss] LX: real ksh93 broken
In-Reply-To: <20170511163329.40c993e4@sleipner.datanom.net>
References: <CAN0RhAMS4dEhG+Pk5M820qmL+M1XMrAuNThZG3kV=da-1qvR5A@mail.gmail.com>
	<CAOc1FHhPq_-s9At=w9BzWQMr+eg5HTH+=iKahzXDyBwMCNqJBw@mail.gmail.com>
	<9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com>
	<5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com>
	<8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com>
	<CAN0RhAOYJKGEqcqT8aojOk4PvdU-baiU8xLJg1FnHBvM6wLFQw@mail.gmail.com>
	<3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com>
	<CAN0RhAOUyn1a6noqgrNKUFZXXeqx1PiFktLn=wZotQ0kpnyxaQ@mail.gmail.com>
	<E99BABD9-900D-4FED-A0FE-550AABFA6D0E@omniti.com>
	<CAN0RhAM2JFHhhXdm4DVym7fEOWs0rdvEL5J1GbV+veH36_MDVw@mail.gmail.com>
	<20170511163329.40c993e4@sleipner.datanom.net>
Message-ID: <CAN0RhAN6M-fW8LQOe3Sb1EMU2uqBQTqxihs4bBBqex+jXYzthA@mail.gmail.com>

The real root cause is a plain old overflow bug in ksh, happening at that
line:
 https://github.com/att/ast/blob/master/src/cmd/ksh93/sh/jobs.c#L1869

because of the way the BYTE macro has been written:
 https://github.com/att/ast/blob/master/src/cmd/ksh93/sh/jobs.c#L101

Check this small example:

#include <stdio.h>
#include <limits.h>

#define BYTE(n)         (((n)+CHAR_BIT-1)/CHAR_BIT)

int main()
{
int i = BYTE(INT_MAX);
printf("i = %d\n", i);
}

and here is what clang warns about when you try to compile it (both 64bit
and 32bit give the exact same result):

test.c:8:10: warning: overflow in expression; result is -2147483641 with
type 'int' [-Winteger-overflow]
        int i = BYTE(INT_MAX);
                ^
test.c:4:30: note: expanded from macro 'BYTE'
#define BYTE(n)         (((n)+CHAR_BIT-1)/CHAR_BIT)
                             ^
1 warning generated.

and when you execute it, you get:

i = -268435455

In the end, the fact that BYTE() returns a negative value completely messes
up the logic in job_alloc() that doesn't guard against that. From there on,
hell starts freezing over and ksh misbehaves randomly as it believes it
cannot allocate a job while it did.

After all, my opinion is that there's no bug in LX, no bug in OmniOS, but
defaulting to INT_MAX for zone.max-lwps is IMHO a mistake. It sounds more
logical to me to default to the global zone's value of
sysconf(_SC_CHILD_MAX).

--
Ludovic



On Thu, May 11, 2017 at 4:33 PM, Michael Rasmussen <mir at miras.org> wrote:

> On Thu, 11 May 2017 11:11:14 +0200
> Ludovic Orban <lorban at bitronix.be> wrote:
>
> >
> > Apparently, ksh isn't very happy when CHILD_MAX equals to MAX_INT, but
> > that's probably a ksh bug.
> >
> Could it be ksh interprets int as it was defined in the 32bit OS days
> int = 16bit = INT_MAX 32767 and expecting to receive a signed
> int?
>
> This is obviously wrong since ISO/IEC 9899 only requires an int to be
> at least 2^16 - 1. INT_MAX is defined in limits.h
>
> --
> 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:
> Witch!  Witch!  They'll burn ya!
>                 -- Hag, "Tomorrow is Yesterday", stardate unknown
>
> _______________________________________________
> 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/20170512/ab1d6fcc/attachment.html>

From danmcd at omniti.com  Fri May 12 14:50:50 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 12 May 2017 10:50:50 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
Message-ID: <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>

As always, please start with the release notes:

	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022

And for this release, there are upgrade notes:

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

This is an LTS and Stable update.  Highlights include:

- BSD Loader is now available.  This has its own wiki page, including how to stick with GRUB if you think you need to.

- Kayak Interactive Installer --> No more Caiman, no more F-keys & curses, and no-more hacking timezone names.  Also, one less repo to maintain for OmniOS. Kayak does it all now.

- Python is now 2.7. This means an IPS/pkg(5) update too. There's a subtle, but noteworthy, update to linked-image semantics ("pkg update -r") AND upgrading non-linked-image "ipkg" zones is a bit more difficult due to the transition (chicken & egg problem with ipkg brand "attach").

- Perl is now 5.24.1.

- USB 3.0 support.

With OmniTI withdrawing funding for OmniOS-as-product, this will be the last OmniTI-pushed "release" of OmniOS. It contains all of the most recent (as of May) illumos-gate changes, AND illumos-joyent LX brand changes.

This release broke the 6-month cadence, due to Loader, Python2.7, and the need for Kayak to take over ALL installation duties.  I'm sorry for it being 1-2 months late, but I wanted to make sure these changes were comfortably in place during the 021 bloody.

Because of the sheer volume of change in this release, I had to update many OmniOS wiki pages.  Here's a list of all of those I changed nontrivially due to r151022.  Please check them out to make sure I'm not missing anything...

	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022

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

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

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

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

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

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

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

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

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

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

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

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

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

	https://omnios.omniti.com/wiki.php/illumos-tools

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

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

I'll have more to say about my departure from OmniTI in a distinct e-mail.

Thanks, and happy upgrading!
Dan


From vab at bb-c.de  Fri May 12 14:57:32 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Fri, 12 May 2017 16:57:32 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
Message-ID: <22805.52572.823257.746322@shelob.bb-c.de>

Congratulations, and thank you for all the work you did.


Best 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 May 12 15:07:01 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 12 May 2017 11:07:01 -0400
Subject: [OmniOS-discuss] To the OmniOS Community
Message-ID: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>

Dear OmniOS Community,

For the past 3+ years, it has been my pleasure and honor to be "OmniOS Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for solving problems, whether they be Home-Data-Center, service-hosting box, network filer, or other uses.

As you saw, OmniTI is turning over OmniOS completely to the community.  The decision-making was sensible for OmniTI, and I understand it completely. With r151022, OmniOS should be at a nice long-term state (022 was always intended to be LTS).

I will be around OmniTI for another week (though on Friday the 19th my availability will be spotty).  During this next week, I encourage people to start upgrading or installing r151022 on their environments.  I already have updated it on my own HDC, and it seems to be performing as it has previously.  

Thank you again, OmniOS community, for making these past three years as rewarding as I'd hoped they'd be when I joined OmniTI. And as for OmniTI, if you need web or database consulting, please keep them in mind. Still a fan, even though I'm no longer with them.

Dan McDonald -- OmniOS Engineering


From info at houseofancients.nl  Fri May 12 15:11:24 2017
From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..)
Date: Fri, 12 May 2017 15:11:24 +0000
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
Message-ID: <04B0A5C1206D824F8D310C5B3DB28CC9201F795D@vEX01.mindstorm-internet.local>

Thanks Dan,

Also for past help and all your very hard work, it really is a shame that OmniTI just pulled the plug, and you leaving them.
I certainly wish you the very best for the future, and do hope you will continue working on solarish OS'es

flrois

-----Oorspronkelijk bericht-----
Van: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] Namens Dan McDonald
Verzonden: vrijdag 12 mei 2017 16:51
Aan: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Onderwerp: [OmniOS-discuss] OmniOS r151022 is now out!

As always, please start with the release notes:

	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022

And for this release, there are upgrade notes:

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

This is an LTS and Stable update.  Highlights include:

- BSD Loader is now available.  This has its own wiki page, including how to stick with GRUB if you think you need to.

- Kayak Interactive Installer --> No more Caiman, no more F-keys & curses, and no-more hacking timezone names.  Also, one less repo to maintain for OmniOS. Kayak does it all now.

- Python is now 2.7. This means an IPS/pkg(5) update too. There's a subtle, but noteworthy, update to linked-image semantics ("pkg update -r") AND upgrading non-linked-image "ipkg" zones is a bit more difficult due to the transition (chicken & egg problem with ipkg brand "attach").

- Perl is now 5.24.1.

- USB 3.0 support.

With OmniTI withdrawing funding for OmniOS-as-product, this will be the last OmniTI-pushed "release" of OmniOS. It contains all of the most recent (as of May) illumos-gate changes, AND illumos-joyent LX brand changes.

This release broke the 6-month cadence, due to Loader, Python2.7, and the need for Kayak to take over ALL installation duties.  I'm sorry for it being 1-2 months late, but I wanted to make sure these changes were comfortably in place during the 021 bloody.

Because of the sheer volume of change in this release, I had to update many OmniOS wiki pages.  Here's a list of all of those I changed nontrivially due to r151022.  Please check them out to make sure I'm not missing anything...

	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022

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

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

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

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

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

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

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

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

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

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

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

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

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

	https://omnios.omniti.com/wiki.php/illumos-tools

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

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

I'll have more to say about my departure from OmniTI in a distinct e-mail.

Thanks, and happy upgrading!
Dan

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl

From lkateley at kateley.com  Fri May 12 15:36:25 2017
From: lkateley at kateley.com (Linda Kateley)
Date: Fri, 12 May 2017 10:36:25 -0500
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
References: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
Message-ID: <35b22551-cbcf-29ae-0096-668501b2405b@kateley.com>

Outstanding job Dan!


On 5/12/17 10:07 AM, Dan McDonald wrote:
> Dear OmniOS Community,
>
> For the past 3+ years, it has been my pleasure and honor to be "OmniOS Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for solving problems, whether they be Home-Data-Center, service-hosting box, network filer, or other uses.
>
> As you saw, OmniTI is turning over OmniOS completely to the community.  The decision-making was sensible for OmniTI, and I understand it completely. With r151022, OmniOS should be at a nice long-term state (022 was always intended to be LTS).
>
> I will be around OmniTI for another week (though on Friday the 19th my availability will be spotty).  During this next week, I encourage people to start upgrading or installing r151022 on their environments.  I already have updated it on my own HDC, and it seems to be performing as it has previously.
>
> Thank you again, OmniOS community, for making these past three years as rewarding as I'd hoped they'd be when I joined OmniTI. And as for OmniTI, if you need web or database consulting, please keep them in mind. Still a fan, even though I'm no longer with them.
>
> Dan McDonald -- OmniOS Engineering
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From an3s.annema at gmail.com  Fri May 12 15:58:58 2017
From: an3s.annema at gmail.com (Andries Annema)
Date: Fri, 12 May 2017 17:58:58 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <35b22551-cbcf-29ae-0096-668501b2405b@kateley.com>
References: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
	<35b22551-cbcf-29ae-0096-668501b2405b@kateley.com>
Message-ID: <00fc01d2cb38$aaa25c60$ffe71520$@gmail.com>

Dan,

What Linda says, times two!
*making a deep bow*

You really did a marvelous job. I sincerely hope that we, as a community,
can and will keep the ball rolling and make it even better ;-)
That said, it would be awesome if you are willing to contribute in the
future still, albeit at a lower frequency and intensity, obviously.

Thanks a lot and all the best of luck with your new challenges in life!

Cheers,
Andries


-----Original Message-----
From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On
Behalf Of Linda Kateley
Sent: vrijdag 12 mei 2017 17:36
To: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] To the OmniOS Community

Outstanding job Dan!


On 5/12/17 10:07 AM, Dan McDonald wrote:
> Dear OmniOS Community,
>
> For the past 3+ years, it has been my pleasure and honor to be "OmniOS
Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for
solving problems, whether they be Home-Data-Center, service-hosting box,
network filer, or other uses.
>
> As you saw, OmniTI is turning over OmniOS completely to the community.
The decision-making was sensible for OmniTI, and I understand it completely.
With r151022, OmniOS should be at a nice long-term state (022 was always
intended to be LTS).
>
> I will be around OmniTI for another week (though on Friday the 19th my
availability will be spotty).  During this next week, I encourage people to
start upgrading or installing r151022 on their environments.  I already have
updated it on my own HDC, and it seems to be performing as it has
previously.
>
> Thank you again, OmniOS community, for making these past three years as
rewarding as I'd hoped they'd be when I joined OmniTI. And as for OmniTI, if
you need web or database consulting, please keep them in mind. Still a fan,
even though I'm no longer with them.
>
> Dan McDonald -- OmniOS Engineering
>
> _______________________________________________
> 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 mir at miras.org  Fri May 12 16:13:32 2017
From: mir at miras.org (Michael Rasmussen)
Date: Fri, 12 May 2017 18:13:32 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <00fc01d2cb38$aaa25c60$ffe71520$@gmail.com>
References: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
	<35b22551-cbcf-29ae-0096-668501b2405b@kateley.com>
	<00fc01d2cb38$aaa25c60$ffe71520$@gmail.com>
Message-ID: <20170512181332.0e115f0e@sleipner.datanom.net>

Hi Dan,

Best of luck and thanks for all your efforts.

On Fri, 12 May 2017 17:58:58 +0200
"Andries Annema" <an3s.annema at gmail.com> wrote:

> 
> You really did a marvelous job. I sincerely hope that we, as a community,
> can and will keep the ball rolling and make it even better ;-)
> That said, it would be awesome if you are willing to contribute in the
> future still, albeit at a lower frequency and intensity, obviously.
> 
Speaking of the future. Anybody knows anything about the future of the
community efforts?

-- 
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:
Ignorance is never out of style.  It was in fashion yesterday, it is the
rage today, and it will set the pace tomorrow.
		-- Franklin K. Dane
-------------- 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/20170512/d11ed0c0/attachment.bin>

From vab at bb-c.de  Fri May 12 16:28:10 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Fri, 12 May 2017 18:28:10 +0200
Subject: [OmniOS-discuss] Heads up for people who want to clone the 151022
	repository
Message-ID: <22805.58010.577348.936777@shelob.bb-c.de>

Hello all!


If you are like me you will want to clone the new 151022 repository
locally, and then update your systems using the local copy.

Note that a plain "pkgrecv --clone" will fail on any system not
already running 022.  This is because the packages are signed with
new certificates missing on older systems.  The symptoms are lots of
"bad signature" messages and, in the end:

  pkgrecv: Pkgrepo verify found errors in the updated repository.
  The original package catalog has been restored.
  The clone operation can be retried; package content that has already been retrieved will not be downloaded again.

Here is the workaround:

Perform a rebuild:

  pkgrepo rebuild -s <path-to-your-022-repo>

Then you can see the packages inside the repository using "pkg list".


The certificates are in the package

  pkg://omnios/web/ca-bundle at 5.11-0.151022:20170510T233244Z

You need to copy OmniTI_CA2.pem and OmniTI_CA2_OmniOS.pem from the
repository and place them in the "/etc/ssl/pkg" directory.  The files
have the following hash values:

  93793132e4e2039425a415bb121e5faf26fe7785  OmniTI_CA2.pem
  654822b18d41acd317aff5ba407557638e9f1171  OmniTI_CA2_OmniOS.pem

Just unpack them directly from the repository:

  gzip -cd <path-to-your-022-repo>/publisher/omnios/file/93/93793132e4e2039425a415bb121e5faf26fe7785 > /etc/ssl/pkg/OmniTI_CA2.pem

  gzip -cd <path-to-your-022-repo>/publisher/omnios/file/65/654822b18d41acd317aff5ba407557638e9f1171 > /etc/ssl/pkg/OmniTI_CA2_OmniOS.pem

(Hope these long lines make it to the mailing list :-).

Then you can check your work with a "pkg verify".  That should just
scroll through the packages but not report any errors.


HTH -- 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 gary at genashor.com  Fri May 12 16:28:40 2017
From: gary at genashor.com (Gary Gendel)
Date: Fri, 12 May 2017 12:28:40 -0400
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
References: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
Message-ID: <78D8816FCC7B4D96A0089C8291FBA294@mail10.futurewins.com>

Dan,

Besides the people that use OmniOS for real work, I want add that the work that you and others have done with OmniOS has been a great boon for personal (hobby) users like me.  I've got a long history of Sun operating systems starting with SunOS.  I almost threw in the towel when OpenIndiana releases kept breaking.  But then I discovered OmniOS.  Today it's the backbone of my family services... mail, web, media, archival, etc..  It's sad to see the changes coming soon, but you should be very proud of what you've created.

Be well.

Gary

On 05/12/2017 11:07 AM, Dan McDonald wrote:
> Dear OmniOS Community,
>
> For the past 3+ years, it has been my pleasure and honor to be "OmniOS Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for solving problems, whether they be Home-Data-Center, service-hosting box, network filer, or other uses.
>
> As you saw, OmniTI is turning over OmniOS completely to the community.  The decision-making was sensible for OmniTI, and I understand it completely. With r151022, OmniOS should be at a nice long-term state (022 was always intended to be LTS).
>
> I will be around OmniTI for another week (though on Friday the 19th my availability will be spotty).  During this next week, I encourage people to start upgrading or installing r151022 on their environments.  I already have updated it on my own HDC, and it seems to be performing as it has previously.
>
> Thank you again, OmniOS community, for making these past three years as rewarding as I'd hoped they'd be when I joined OmniTI. And as for OmniTI, if you need web or database consulting, please keep them in mind. Still a fan, even though I'm no longer with them.
>
> Dan McDonald -- OmniOS Engineering
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



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

From vab at bb-c.de  Fri May 12 16:32:56 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Fri, 12 May 2017 18:32:56 +0200
Subject: [OmniOS-discuss] Heads up for people who want to clone the
	151022 repository
In-Reply-To: <22805.58010.577348.936777@shelob.bb-c.de>
References: <22805.58010.577348.936777@shelob.bb-c.de>
Message-ID: <22805.58296.601535.246204@shelob.bb-c.de>

Volker A. Brandt writes:
[...]
> Then you can check your work with a "pkg verify".

That was supposed to be a "pkgrepo verify".


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 richard.elling at richardelling.com  Fri May 12 16:33:39 2017
From: richard.elling at richardelling.com (Richard Elling)
Date: Fri, 12 May 2017 09:33:39 -0700
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
References: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
Message-ID: <B27AAE89-3B66-43F3-95A0-CCE6B602C4F3@richardelling.com>

Thanks for everything Dan, you?ve been a terrific asset to the OmniOS community!
 ? richard

> On May 12, 2017, at 8:07 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> Dear OmniOS Community,
> 
> For the past 3+ years, it has been my pleasure and honor to be "OmniOS Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for solving problems, whether they be Home-Data-Center, service-hosting box, network filer, or other uses.
> 
> As you saw, OmniTI is turning over OmniOS completely to the community.  The decision-making was sensible for OmniTI, and I understand it completely. With r151022, OmniOS should be at a nice long-term state (022 was always intended to be LTS).
> 
> I will be around OmniTI for another week (though on Friday the 19th my availability will be spotty).  During this next week, I encourage people to start upgrading or installing r151022 on their environments.  I already have updated it on my own HDC, and it seems to be performing as it has previously.  
> 
> Thank you again, OmniOS community, for making these past three years as rewarding as I'd hoped they'd be when I joined OmniTI. And as for OmniTI, if you need web or database consulting, please keep them in mind. Still a fan, even though I'm no longer with them.
> 
> Dan McDonald -- OmniOS Engineering
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From fpittel at gmail.com  Fri May 12 16:57:19 2017
From: fpittel at gmail.com (Frank Pittel)
Date: Fri, 12 May 2017 11:57:19 -0500
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <B27AAE89-3B66-43F3-95A0-CCE6B602C4F3@richardelling.com>
References: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
	<B27AAE89-3B66-43F3-95A0-CCE6B602C4F3@richardelling.com>
Message-ID: <CAF9Hu7P1-2wnaE+eYKhnhoj=c3LscSWH+J_JAv4bk9MhSw9BAQ@mail.gmail.com>

Dan,

I see some people beat me to thanking you for all your hard work and
support that you've provided to individuals in getting their issues with
omnios resolved. I know you won't have any issue with finding gainful
employment going forward. I also hope that you find the time to remain a
part of the community even if it's at a lower level of activity.

Frank

On Fri, May 12, 2017 at 11:33 AM, Richard Elling <
richard.elling at richardelling.com> wrote:

> Thanks for everything Dan, you?ve been a terrific asset to the OmniOS
> community!
>  ? richard
>
> > On May 12, 2017, at 8:07 AM, Dan McDonald <danmcd at omniti.com> wrote:
> >
> > Dear OmniOS Community,
> >
> > For the past 3+ years, it has been my pleasure and honor to be "OmniOS
> Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for
> solving problems, whether they be Home-Data-Center, service-hosting box,
> network filer, or other uses.
> >
> > As you saw, OmniTI is turning over OmniOS completely to the community.
> The decision-making was sensible for OmniTI, and I understand it
> completely. With r151022, OmniOS should be at a nice long-term state (022
> was always intended to be LTS).
> >
> > I will be around OmniTI for another week (though on Friday the 19th my
> availability will be spotty).  During this next week, I encourage people to
> start upgrading or installing r151022 on their environments.  I already
> have updated it on my own HDC, and it seems to be performing as it has
> previously.
> >
> > Thank you again, OmniOS community, for making these past three years as
> rewarding as I'd hoped they'd be when I joined OmniTI. And as for OmniTI,
> if you need web or database consulting, please keep them in mind. Still a
> fan, even though I'm no longer with them.
> >
> > Dan McDonald -- OmniOS Engineering
> >
> > _______________________________________________
> > 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/20170512/c9fcd728/attachment.html>

From jimklimov at cos.ru  Fri May 12 17:35:26 2017
From: jimklimov at cos.ru (Jim Klimov)
Date: Fri, 12 May 2017 20:35:26 +0300
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
References: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
Message-ID: <6C254FA9-472C-4873-938A-E7CCECC3738E@cos.ru>

On May 12, 2017 6:07:01 PM GMT+03:00, Dan McDonald <danmcd at omniti.com> wrote:
>Dear OmniOS Community,
>
>For the past 3+ years, it has been my pleasure and honor to be "OmniOS
>Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for
>solving problems, whether they be Home-Data-Center, service-hosting
>box, network filer, or other uses.
>
>As you saw, OmniTI is turning over OmniOS completely to the community. 
>The decision-making was sensible for OmniTI, and I understand it
>completely. With r151022, OmniOS should be at a nice long-term state
>(022 was always intended to be LTS).
>
>I will be around OmniTI for another week (though on Friday the 19th my
>availability will be spotty).  During this next week, I encourage
>people to start upgrading or installing r151022 on their environments. 
>I already have updated it on my own HDC, and it seems to be performing
>as it has previously.  
>
>Thank you again, OmniOS community, for making these past three years as
>rewarding as I'd hoped they'd be when I joined OmniTI. And as for
>OmniTI, if you need web or database consulting, please keep them in
>mind. Still a fan, even though I'm no longer with them.
>
>Dan McDonald -- OmniOS Engineering
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

Oh, bummer... I hope you'd be around for the community effort too every now and then. ;) Thanks for keeping that ship afloat!

Jim
--
Typos courtesy of K-9 Mail on my Redmi Android

From danmcd at omniti.com  Fri May 12 17:52:45 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 12 May 2017 13:52:45 -0400
Subject: [OmniOS-discuss] Heads up for people who want to clone the
 151022 repository
In-Reply-To: <22805.58010.577348.936777@shelob.bb-c.de>
References: <22805.58010.577348.936777@shelob.bb-c.de>
Message-ID: <404DEA8B-C098-4B3E-8B0B-433ED40A5D02@omniti.com>

Ummm, every 014-and-later release got upgraded ca-bundle packages specifically to help r151022 transition.  As I said in a prior email:

	http://lists.omniti.com/pipermail/omnios-discuss/2017-April/008650.html

Ahhh, I see, the subject line was intended for upgraders, but for people maintaining IPS repos on older revs, you should make sure you're updated too.

Dan


From grzempek at gmail.com  Fri May 12 18:18:22 2017
From: grzempek at gmail.com (Krzysztof Grzempa)
Date: Fri, 12 May 2017 20:18:22 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <6C254FA9-472C-4873-938A-E7CCECC3738E@cos.ru>
References: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com>
	<6C254FA9-472C-4873-938A-E7CCECC3738E@cos.ru>
Message-ID: <CAED-Y_D6MD1QWCn2750+iQZkwTj8x_5XbaHsbFx2334LXdeZ2Q@mail.gmail.com>

Thank you Dan, for the best Illumos distro ever!
I hope that the transfer to the community driven model will come true, and
I hope you still will be the part of it.
Now it is up to us, the 'community' to decide if we want to keep this great
project alive or let if go.... I'm ready to participate somehow financial
and with my skills...

2017-05-12 19:35 GMT+02:00 Jim Klimov <jimklimov at cos.ru>:

> On May 12, 2017 6:07:01 PM GMT+03:00, Dan McDonald <danmcd at omniti.com>
> wrote:
> >Dear OmniOS Community,
> >
> >For the past 3+ years, it has been my pleasure and honor to be "OmniOS
> >Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for
> >solving problems, whether they be Home-Data-Center, service-hosting
> >box, network filer, or other uses.
> >
> >As you saw, OmniTI is turning over OmniOS completely to the community.
> >The decision-making was sensible for OmniTI, and I understand it
> >completely. With r151022, OmniOS should be at a nice long-term state
> >(022 was always intended to be LTS).
> >
> >I will be around OmniTI for another week (though on Friday the 19th my
> >availability will be spotty).  During this next week, I encourage
> >people to start upgrading or installing r151022 on their environments.
> >I already have updated it on my own HDC, and it seems to be performing
> >as it has previously.
> >
> >Thank you again, OmniOS community, for making these past three years as
> >rewarding as I'd hoped they'd be when I joined OmniTI. And as for
> >OmniTI, if you need web or database consulting, please keep them in
> >mind. Still a fan, even though I'm no longer with them.
> >
> >Dan McDonald -- OmniOS Engineering
> >
> >_______________________________________________
> >OmniOS-discuss mailing list
> >OmniOS-discuss at lists.omniti.com
> >http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
> Oh, bummer... I hope you'd be around for the community effort too every
> now and then. ;) Thanks for keeping that ship afloat!
>
> Jim
> --
> Typos courtesy of K-9 Mail on my Redmi Android
> _______________________________________________
> 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/20170512/8d548c05/attachment-0001.html>

From natxo.asenjo at gmail.com  Fri May 12 18:40:37 2017
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 12 May 2017 20:40:37 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
Message-ID: <CAHBEJzVLBJsiWh+BekMmr6DWUWdNL7HEjxVfzdwatEvQGExtHA@mail.gmail.com>

On Fri, May 12, 2017 at 4:50 PM, Dan McDonald <danmcd at omniti.com> wrote:

> As always, please start with the release notes:
>
>         https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022


just upgraded my home box, everything went perfectly, lx zones included.

You will be missed, Dan. Thanks for your awesome work here.

-- 
regards,
Natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170512/4e50658d/attachment.html>

From mir at miras.org  Fri May 12 18:50:10 2017
From: mir at miras.org (Michael Rasmussen)
Date: Fri, 12 May 2017 20:50:10 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
Message-ID: <20170512205010.3e0385bc@sleipner.datanom.net>

On Fri, 12 May 2017 10:50:50 -0400
Dan McDonald <danmcd at omniti.com> wrote:

> 
> Thanks, and happy upgrading!
Following the upgrade notes resolved in this:
The following unexpected or editable files and directories were
salvaged while executing the requested package operation; they
have been moved to the displayed location in the image:

  var/log/install -> /tmp/tmpEwuKzS/var/pkg/lost+found/var/log/install-20170512T204527Z

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

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

root at pkg:/root# beadm list
BE                    Active Mountpoint     Space Policy Created
omniosvar             -      -              19.0K static 2016-06-19 03:59
omnios                -      -              275M  static 2016-06-19 03:59
omnios-jun            -      -              3.58M static 2016-06-19 04:28
omnios-aug            -      -              278M  static 2016-08-07 15:06
omnios-oct            -      -              4.76M static 2016-10-29 17:25
omnios-jan            -      -              278M  static 2017-01-23 17:47
omnios-jan-1          NR     /              10.4G static 2017-04-08 15:34
omnios-jan-1-backup-1 -      -              82.0K static 2017-05-11 20:34
omnios-r151014-last   -      -              36.0K static 2017-05-12 20:36
omnios-r151022        -      /tmp/tmpEwuKzS 1.64G static 2017-05-12 20:45

What to do?

-- 
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:
  Our comedies are not to be laughed at. -Samuel Goldwyn
-------------- 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/20170512/55cce2d3/attachment.bin>

From mir at miras.org  Fri May 12 18:55:34 2017
From: mir at miras.org (Michael Rasmussen)
Date: Fri, 12 May 2017 20:55:34 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <20170512205010.3e0385bc@sleipner.datanom.net>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
Message-ID: <20170512205534.33818e7e@sleipner.datanom.net>

On Fri, 12 May 2017 20:50:10 +0200
Michael Rasmussen <mir at miras.org> wrote:

>   var/log/install -> /tmp/tmpEwuKzS/var/pkg/lost+found/var/log/install-20170512T204527Z
> 
Content of install:
cat /tmp/tmpEwuKzS/var/pkg/lost+found/var/log/install-20170512T204527Z/install_log 
2016-06-19 01:58:40,424   InstallationLogger INFO       **** START ****                                   
PROGRESS REPORT: progress percent:0 Preparing for Installation
PROGRESS REPORT: progress percent:100 TargetDiscovery completed.
2016-06-19 01:59:00,674   InstallationLogger INFO       Going to perform final validation of desired target
2016-06-19 01:59:00,694   InstallationLogger.sysconfig INFO       Opening keyboard device: /dev/kbd                 
2016-06-19 01:59:00,695   InstallationLogger.sysconfig INFO       Detected following current keyboard layout: Danish
2016-06-19 01:59:00,695   InstallationLogger.sysconfig INFO       console type: Physical Console                    
2016-06-19 01:59:12,568   InstallationLogger.sysconfig INFO       Configuring NIC as: none                          
2016-06-19 03:59:00,031   InstallationLogger INFO       Installation Device Size: 31.97gbMB               
2016-06-19 03:59:00,032   InstallationLogger INFO       Minimum required size: 2.16gb                     
2016-06-19 03:59:00,032   InstallationLogger INFO       Recommended size: 4.16gb                          
2016-06-19 03:59:00,034   InstallationLogger INFO       Swap type: ZVOL                                   
2016-06-19 03:59:00,035   InstallationLogger INFO       Swap size: 1.00gb                                 
2016-06-19 03:59:00,035   InstallationLogger INFO       Dump type: ZVOL                                   
2016-06-19 03:59:00,035   InstallationLogger INFO       Dump size: 1.00gb                                 
PROGRESS REPORT: progress percent:0 Preparing for Installation
PROGRESS REPORT: progress percent:100 PrepareTransfer completed.
PROGRESS REPORT: progress percent:0 Preparing for Installation
PROGRESS REPORT: progress percent:0 Preparing for Installation
PROGRESS REPORT: progress percent:0 Preparing for Installation
PROGRESS REPORT: progress percent:1 Preparing for Installation
PROGRESS REPORT: progress percent:1 Preparing for Installation
PROGRESS REPORT: progress percent:1 Preparing for Installation
PROGRESS REPORT: progress percent:2 Preparing for Installation
PROGRESS REPORT: progress percent:2 Preparing for Installation
PROGRESS REPORT: progress percent:2 Preparing for Installation
PROGRESS REPORT: progress percent:3 Preparing for Installation
PROGRESS REPORT: progress percent:3 Preparing for Installation
PROGRESS REPORT: progress percent:3 Preparing for Installation
PROGRESS REPORT: progress percent:4 Preparing for Installation
PROGRESS REPORT: progress percent:4 Preparing for Installation
PROGRESS REPORT: progress percent:4 Preparing for Installation
PROGRESS REPORT: progress percent:5 VarSharedDataset completed.
PROGRESS REPORT: progress percent:5 TargetInitialization completed.
2016-06-19 03:59:05,687   InstallationLogger.transfer-root INFO       === Executing transfer-root Checkpoint ===        
PROGRESS REPORT: progress percent:5 Beginning CPIO transfer
2016-06-19 03:59:14,870   InstallationLogger.transfer-root INFO       Transferring files to /a                          
PROGRESS REPORT: progress percent:5 Transferring contents
PROGRESS REPORT: progress percent:6 Transferring contents
PROGRESS REPORT: progress percent:9 Transferring contents
PROGRESS REPORT: progress percent:10 Transferring contents
PROGRESS REPORT: progress percent:11 Transferring contents
PROGRESS REPORT: progress percent:12 Transferring contents
PROGRESS REPORT: progress percent:13 Transferring contents
PROGRESS REPORT: progress percent:15 Transferring contents
PROGRESS REPORT: progress percent:16 Transferring contents
PROGRESS REPORT: progress percent:18 Transferring contents
2016-06-19 03:59:23,896   InstallationLogger.transfer-root INFO       Transferring files to /a                          
PROGRESS REPORT: progress percent:19 Transferring contents
PROGRESS REPORT: progress percent:20 Transferring contents
PROGRESS REPORT: progress percent:20 Transferring contents
PROGRESS REPORT: progress percent:22 Transferring contents
PROGRESS REPORT: progress percent:23 Transferring contents
PROGRESS REPORT: progress percent:24 Transferring contents
PROGRESS REPORT: progress percent:27 Transferring contents
PROGRESS REPORT: progress percent:28 Transferring contents
PROGRESS REPORT: progress percent:29 Transferring contents
PROGRESS REPORT: progress percent:30 Transferring contents
PROGRESS REPORT: progress percent:31 Transferring contents
PROGRESS REPORT: progress percent:32 Transferring contents
PROGRESS REPORT: progress percent:34 Transferring contents
PROGRESS REPORT: progress percent:35 Transferring contents
PROGRESS REPORT: progress percent:36 Transferring contents
PROGRESS REPORT: progress percent:37 Transferring contents
PROGRESS REPORT: progress percent:39 Transferring contents
PROGRESS REPORT: progress percent:41 Transferring contents
PROGRESS REPORT: progress percent:43 Transferring contents
PROGRESS REPORT: progress percent:45 Transferring contents
PROGRESS REPORT: progress percent:48 Transferring contents
PROGRESS REPORT: progress percent:50 Transferring contents
PROGRESS REPORT: progress percent:50 Transferring contents
PROGRESS REPORT: progress percent:51 Transferring contents
PROGRESS REPORT: progress percent:52 Transferring contents
PROGRESS REPORT: progress percent:54 Transferring contents
PROGRESS REPORT: progress percent:55 Transferring contents
PROGRESS REPORT: progress percent:57 Transferring contents
PROGRESS REPORT: progress percent:58 Transferring contents
PROGRESS REPORT: progress percent:59 Transferring contents
PROGRESS REPORT: progress percent:60 Transferring contents
PROGRESS REPORT: progress percent:62 Transferring contents
PROGRESS REPORT: progress percent:63 Transferring contents
PROGRESS REPORT: progress percent:64 Transferring contents
PROGRESS REPORT: progress percent:65 Transferring contents
PROGRESS REPORT: progress percent:66 Transferring contents
PROGRESS REPORT: progress percent:69 Transferring contents
PROGRESS REPORT: progress percent:71 Transferring contents
PROGRESS REPORT: progress percent:72 Transferring contents
PROGRESS REPORT: progress percent:73 Transferring contents
PROGRESS REPORT: progress percent:74 Transferring contents
PROGRESS REPORT: progress percent:75 Transferring contents
PROGRESS REPORT: progress percent:77 Transferring contents
PROGRESS REPORT: progress percent:78 Transferring contents
PROGRESS REPORT: progress percent:79 Transferring contents
PROGRESS REPORT: progress percent:80 Transferring contents
PROGRESS REPORT: progress percent:82 Transferring contents
PROGRESS REPORT: progress percent:83 Transferring contents
PROGRESS REPORT: progress percent:84 Transferring contents
PROGRESS REPORT: progress percent:85 Transferring contents
PROGRESS REPORT: progress percent:87 Transferring contents
PROGRESS REPORT: progress percent:89 Transferring contents
PROGRESS REPORT: progress percent:90 Transferring contents
PROGRESS REPORT: progress percent:91 Transferring contents
PROGRESS REPORT: progress percent:92 Transferring contents
PROGRESS REPORT: progress percent:93 Transferring contents
2016-06-19 04:01:02,803   InstallationLogger.transfer-root INFO       Transferring files to /a                          
2016-06-19 04:01:04,353   InstallationLogger.transfer-misc INFO       === Executing transfer-misc Checkpoint ===        
PROGRESS REPORT: progress percent:93 Beginning CPIO transfer
PROGRESS REPORT: progress percent:93 Transferring contents
2016-06-19 04:01:05,891   InstallationLogger.transfer-misc INFO       Transferring files to /a                          
PROGRESS REPORT: progress percent:93 Transferring contents
PROGRESS REPORT: progress percent:95 Transferring contents
PROGRESS REPORT: progress percent:95 Transferring contents
PROGRESS REPORT: progress percent:95 Transferring contents
PROGRESS REPORT: progress percent:97 Transferring contents
2016-06-19 04:01:13,329   InstallationLogger.transfer-media INFO       === Executing transfer-media Checkpoint ===       
PROGRESS REPORT: progress percent:98 Beginning CPIO transfer
2016-06-19 04:01:13,580   InstallationLogger.transfer-media INFO       Transferring files to /a                          
PROGRESS REPORT: progress percent:98 Transferring contents
PROGRESS REPORT: progress percent:99 Transferring contents
PROGRESS REPORT: progress percent:99 generate-sc-profile completed.
PROGRESS REPORT: progress percent:99 cleanup-cpio-install completed.
PROGRESS REPORT: progress percent:99 initialize-smf completed.
2016-06-19 04:01:36,761   InstallationLogger.boot-configuration INFO       Setting console boot device property to text      
2016-06-19 04:01:36,778   InstallationLogger.boot-configuration INFO       Disabling boot loader graphical splash            
2016-06-19 04:01:36,779   InstallationLogger.boot-configuration INFO       Creating Legacy GRUB config directory:
	/rpool/boot/grub
2016-06-19 04:01:36,779   InstallationLogger.boot-configuration INFO       Installing boot loader to devices: ['/dev/rdsk/c2t0d0s0']
PROGRESS REPORT: progress percent:99 boot-configuration completed.
PROGRESS REPORT: progress percent:99 update-dump-admin completed.
PROGRESS REPORT: progress percent:99 device-config completed.
PROGRESS REPORT: progress percent:99 apply-sysconfig completed.
PROGRESS REPORT: progress percent:99 boot-archive completed.
PROGRESS REPORT: progress percent:99 transfer-ti-files completed.
PROGRESS REPORT: progress percent:99 create-snapshot completed.


-- 
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 don't know why but, suddenly, I want to discuss declining I.Q.
LEVELS with a blue ribbon SENATE SUB-COMMITTEE!
-------------- 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/20170512/eb6e27fe/attachment.bin>

From danmcd at omniti.com  Fri May 12 18:59:49 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 12 May 2017 14:59:49 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <20170512205010.3e0385bc@sleipner.datanom.net>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
Message-ID: <D62082B7-A913-4736-B8C7-27659D184B8E@omniti.com>


> On May 12, 2017, at 2:50 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Fri, 12 May 2017 10:50:50 -0400
> Dan McDonald <danmcd at omniti.com> wrote:
> 
>> 
>> Thanks, and happy upgrading!
> Following the upgrade notes resolved in this:
> The following unexpected or editable files and directories were
> salvaged while executing the requested package operation; they
> have been moved to the displayed location in the image:
> 
>  var/log/install -> /tmp/tmpEwuKzS/var/pkg/lost+found/var/log/install-20170512T204527Z

I think this may be a side-effect of the python+pkg updates.

The log is there for you to inspect and see if it matters to you.  You can always put it on your new BE by hand.

I saw these during several upgrades, and it didn't affect the new BE's functionality.

Dan


From danmcd at omniti.com  Fri May 12 19:00:43 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 12 May 2017 15:00:43 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <20170512205534.33818e7e@sleipner.datanom.net>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
	<20170512205534.33818e7e@sleipner.datanom.net>
Message-ID: <F207D4B4-988C-4170-942A-6B4157E86857@omniti.com>


> On May 12, 2017, at 2:55 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> Content of install:
> cat /tmp/tmpEwuKzS/var/pkg/lost+found/var/log/install-20170512T204527Z/install_log 

Looks like an install log from June 2016.  Probably NOT a big loss for you.

Dan


From mir at miras.org  Fri May 12 19:13:37 2017
From: mir at miras.org (Michael Rasmussen)
Date: Fri, 12 May 2017 21:13:37 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <D62082B7-A913-4736-B8C7-27659D184B8E@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
	<D62082B7-A913-4736-B8C7-27659D184B8E@omniti.com>
Message-ID: <20170512211337.26005a55@sleipner.datanom.net>

On Fri, 12 May 2017 14:59:49 -0400
Dan McDonald <danmcd at omniti.com> wrote:

> 
> I think this may be a side-effect of the python+pkg updates.
> 
> The log is there for you to inspect and see if it matters to you.  You can always put it on your new BE by hand.
> 
> I saw these during several upgrades, and it didn't affect the new BE's functionality.
> 
Doing the following:
beadm unmount omnios-r151022
Unmounted successfully

beadm activate omnios-r151022
Unable to activate omnios-r151022.
Error installing boot files.

What to do then?

-- 
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:
Write and test a big program in small pieces.
            - The Elements of Programming Style (Kernighan & Plaugher)
-------------- 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/20170512/f0fd5280/attachment.bin>

From danmcd at omniti.com  Fri May 12 19:17:30 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 12 May 2017 15:17:30 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <20170512211337.26005a55@sleipner.datanom.net>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
	<D62082B7-A913-4736-B8C7-27659D184B8E@omniti.com>
	<20170512211337.26005a55@sleipner.datanom.net>
Message-ID: <0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com>


> On May 12, 2017, at 3:13 PM, Michael Rasmussen <mir at miras.org> wrote:
>> 
> Doing the following:
> beadm unmount omnios-r151022
> Unmounted successfully
> 
> beadm activate omnios-r151022
> Unable to activate omnios-r151022.
> Error installing boot files.
> 
> What to do then?

Huh.

Some dumb questions:

1.) You're going from r151014 to r151022, right?

2.) Any non-global zones?

3.) What is your rpool comprised of?  ("zpool list -v rpool")

4.) Try "beadm activate <some-other-be>" just to make sure those still work.  (I might expect this behavior if you were going from bloody to 022).

Dan


From mir at miras.org  Fri May 12 19:21:12 2017
From: mir at miras.org (Michael Rasmussen)
Date: Fri, 12 May 2017 21:21:12 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
	<D62082B7-A913-4736-B8C7-27659D184B8E@omniti.com>
	<20170512211337.26005a55@sleipner.datanom.net>
	<0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com>
Message-ID: <20170512212112.704044c2@sleipner.datanom.net>

On Fri, 12 May 2017 15:17:30 -0400
Dan McDonald <danmcd at omniti.com> wrote:

> 
> Some dumb questions:
> 
> 1.) You're going from r151014 to r151022, right?
> 
cat /etc/release 
  OmniOS v11 r151014
  Copyright 2015 OmniTI Computer Consulting, Inc. All rights reserved.
  Use is subject to license terms.

> 2.) Any non-global zones?
> 
No zones what so ever
> 3.) What is your rpool comprised of?  ("zpool list -v rpool")
> 
zpool list -v rpool
NAME         SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
rpool       31.8G  11.2G  20.5G         -    16%    35%  1.00x  ONLINE  -
  c2t0d0s0  31.8G  11.2G  20.5G         -    16%    35%

> 4.) Try "beadm activate <some-other-be>" just to make sure those still work.  (I might expect this behavior if you were going from bloody to 022).
> 
Activating beadm created before pkg update:
beadm activate omnios-r151014-last
Activated successfully

PS. If it matters this is a VM running under KVM.

-- 
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 trouble with heart disease is that the first symptom is often hard
to deal with: death.
		-- Michael Phelps
-------------- 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/20170512/496eb617/attachment.bin>

From mir at miras.org  Fri May 12 20:00:05 2017
From: mir at miras.org (Michael Rasmussen)
Date: Fri, 12 May 2017 22:00:05 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <20170512212112.704044c2@sleipner.datanom.net>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
	<D62082B7-A913-4736-B8C7-27659D184B8E@omniti.com>
	<20170512211337.26005a55@sleipner.datanom.net>
	<0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com>
	<20170512212112.704044c2@sleipner.datanom.net>
Message-ID: <20170512220005.4ee29b8e@sleipner.datanom.net>

On Fri, 12 May 2017 21:21:12 +0200
Michael Rasmussen <mir at miras.org> wrote:

> Activating beadm created before pkg update:
> beadm activate omnios-r151014-last
> Activated successfully
> 
beadm activate -v omnios-r151022
be_do_installgrub: installgrub failed for device c2t0d0s0.
  Command: "/sbin/installgrub  /tmp/.be.9jaGlo/boot/grub/stage1 /tmp/.be.9jaGlo/boot/grub/stage2 /dev/rdsk/c2t0d0s0"
open: No such file or directory
Unable to gather device information for /dev/rdsk/c2t0d0s0
be_run_cmd: command terminated with error status: 1
Unable to activate omnios-r151022.
Error installing boot files.


-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
You can't run away forever,
But there's nothing wrong with getting a good head start.
		-- Jim Steinman, "Rock and Roll Dreams Come Through"
-------------- 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/20170512/1370c76a/attachment.bin>

From danmcd at omniti.com  Fri May 12 20:12:09 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 12 May 2017 16:12:09 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <20170512220005.4ee29b8e@sleipner.datanom.net>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
	<D62082B7-A913-4736-B8C7-27659D184B8E@omniti.com>
	<20170512211337.26005a55@sleipner.datanom.net>
	<0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com>
	<20170512212112.704044c2@sleipner.datanom.net>
	<20170512220005.4ee29b8e@sleipner.datanom.net>
Message-ID: <BC9EA7E8-A446-4D7E-B4D7-88BA1525760B@omniti.com>


> On May 12, 2017, at 4:00 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Fri, 12 May 2017 21:21:12 +0200
> Michael Rasmussen <mir at miras.org> wrote:
> 
>> Activating beadm created before pkg update:
>> beadm activate omnios-r151014-last
>> Activated successfully
>> 
> beadm activate -v omnios-r151022
> be_do_installgrub: installgrub failed for device c2t0d0s0.
>  Command: "/sbin/installgrub  /tmp/.be.9jaGlo/boot/grub/stage1 /tmp/.be.9jaGlo/boot/grub/stage2 /dev/rdsk/c2t0d0s0"
> open: No such file or directory
> Unable to gather device information for /dev/rdsk/c2t0d0s0
> be_run_cmd: command terminated with error status: 1
> Unable to activate omnios-r151022.
> Error installing boot files.

You did say you were on KVM.  I wonder if blkdev or something else is being problematic?

Try booting, but selecting the new BE using grub specifically.  (And if you still want grub, put BE_HAS_GRUB=true into /etc/default/be on the 022 one post-boot, or the next beadm will scribble loader.)

Dan


From ikaufman at eng.ucsd.edu  Fri May 12 21:15:44 2017
From: ikaufman at eng.ucsd.edu (Ian Kaufman)
Date: Fri, 12 May 2017 14:15:44 -0700
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
Message-ID: <CAPJtH1iiuoxtntKiGUAbwG85ges75KiDqAGaxRvJuqHLywG-Hw@mail.gmail.com>

Hmmm, having trouble going from 14 to 22. I cannot migrate to OpenSSH -

root at hiperq-data:/root# /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.4.1,5.11-0.151022:20170511T001844Z
  Reason:  All versions matching 'require' dependency pkg:/library/security/
openssl at 1.0.2.11,5.11-0.151022 are rejected
    Reject:  pkg://omnios/library/security/openssl at 1.0.2.11
,5.11-0.151022:20170510T232316Z
    Reason:  This version is excluded by installed incorporation
pkg://omnios/incorporation/jeos/omnios-userland at 11
,5.11-0.151014:20161221T194806Z
No matching version of network/openssh-server can be installed:
  Reject:  pkg://omnios/network/openssh-server at 7.4.1
,5.11-0.151022:20170511T001853Z
  Reason:  All versions matching 'require' dependency
pkg:/SUNWcs at 0.5.11,5.11-0.151022
are rejected
    Reject:  pkg://omnios/SUNWcs at 0.5.11,5.11-0.151022:20170510T212740Z
    Reason:  This version is excluded by installed incorporation
pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11
,5.11-0.151014:20170301T162824Z
             This version is excluded by installed incorporation
pkg://omnios/incorporation/jeos/illumos-gate at 11
,5.11-0.151014:20160804T060038Z


On Fri, May 12, 2017 at 7:50 AM, Dan McDonald <danmcd at omniti.com> wrote:

> As always, please start with the release notes:
>
>         https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
>
> And for this release, there are upgrade notes:
>
>         https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
>
> This is an LTS and Stable update.  Highlights include:
>
> - BSD Loader is now available.  This has its own wiki page, including how
> to stick with GRUB if you think you need to.
>
> - Kayak Interactive Installer --> No more Caiman, no more F-keys & curses,
> and no-more hacking timezone names.  Also, one less repo to maintain for
> OmniOS. Kayak does it all now.
>
> - Python is now 2.7. This means an IPS/pkg(5) update too. There's a
> subtle, but noteworthy, update to linked-image semantics ("pkg update -r")
> AND upgrading non-linked-image "ipkg" zones is a bit more difficult due to
> the transition (chicken & egg problem with ipkg brand "attach").
>
> - Perl is now 5.24.1.
>
> - USB 3.0 support.
>
> With OmniTI withdrawing funding for OmniOS-as-product, this will be the
> last OmniTI-pushed "release" of OmniOS. It contains all of the most recent
> (as of May) illumos-gate changes, AND illumos-joyent LX brand changes.
>
> This release broke the 6-month cadence, due to Loader, Python2.7, and the
> need for Kayak to take over ALL installation duties.  I'm sorry for it
> being 1-2 months late, but I wanted to make sure these changes were
> comfortably in place during the 021 bloody.
>
> Because of the sheer volume of change in this release, I had to update
> many OmniOS wiki pages.  Here's a list of all of those I changed
> nontrivially due to r151022.  Please check them out to make sure I'm not
> missing anything...
>
>         https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
>
>         https://omnios.omniti.com/wiki.php/Installation
>
>         https://omnios.omniti.com/wiki.php/LXZones
>
>         https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
>
>         https://omnios.omniti.com/wiki.php/NewLinkedImages
>
>         https://omnios.omniti.com/wiki.php/linked_images
>
>         https://omnios.omniti.com/wiki.php/KayakInteractive
>
>         https://omnios.omniti.com/wiki.php/BSDLoader
>
>         https://omnios.omniti.com/wiki.php/ReleaseCycle
>
>         https://omnios.omniti.com/wiki.php/Packaging
>
>         https://omnios.omniti.com/wiki.php/ReleaseNotes/
>
>         https://omnios.omniti.com/wiki.php/WikiStart
>
>         https://omnios.omniti.com/wiki.php/BuildInstructions
>
>         https://omnios.omniti.com/wiki.php/Maintainers
>
>         https://omnios.omniti.com/wiki.php/illumos-tools
>
>         https://omnios.omniti.com/wiki.php/buildctl
>
>         https://omnios.omniti.com/wiki.php/ReleaseMedia
>
> I'll have more to say about my departure from OmniTI in a distinct e-mail.
>
> Thanks, and happy upgrading!
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170512/540f3f51/attachment-0001.html>

From danmcd at omniti.com  Fri May 12 21:18:15 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 12 May 2017 17:18:15 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <CAPJtH1iiuoxtntKiGUAbwG85ges75KiDqAGaxRvJuqHLywG-Hw@mail.gmail.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<CAPJtH1iiuoxtntKiGUAbwG85ges75KiDqAGaxRvJuqHLywG-Hw@mail.gmail.com>
Message-ID: <50E3F441-E73E-436A-8992-5571FE3903B9@omniti.com>


> On May 12, 2017, at 5:15 PM, Ian Kaufman <ikaufman at eng.ucsd.edu> wrote:
> 
> Hmmm, having trouble going from 14 to 22. I cannot migrate to OpenSSH - 
> 
> root at hiperq-data:/root# /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.4.1,5.11-0.151022:20170511T001844Z
>   Reason:  All versions matching 'require' dependency pkg:/library/security/openssl at 1.0.2.11,5.11-0.151022 are rejected
>     Reject:  pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151022:20170510T232316Z
>     Reason:  This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151014:20161221T194806Z
> No matching version of network/openssh-server can be installed:
>   Reject:  pkg://omnios/network/openssh-server at 7.4.1,5.11-0.151022:20170511T001853Z
>   Reason:  All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151022 are rejected
>     Reject:  pkg://omnios/SUNWcs at 0.5.11,5.11-0.151022:20170510T212740Z
>     Reason:  This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151014:20170301T162824Z
>              This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151014:20160804T060038Z

You may need to get your 014 running OpenSSH on 014, and THEN upgrade.

Yeah... this is an IPS-ism that also affects zoneadm attach/detach.  You can't trash the old w/o bringing in the new, which aren't there anymore.

Sorry,
Dan


From mir at miras.org  Fri May 12 21:21:54 2017
From: mir at miras.org (Michael Rasmussen)
Date: Fri, 12 May 2017 23:21:54 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <BC9EA7E8-A446-4D7E-B4D7-88BA1525760B@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
	<D62082B7-A913-4736-B8C7-27659D184B8E@omniti.com>
	<20170512211337.26005a55@sleipner.datanom.net>
	<0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com>
	<20170512212112.704044c2@sleipner.datanom.net>
	<20170512220005.4ee29b8e@sleipner.datanom.net>
	<BC9EA7E8-A446-4D7E-B4D7-88BA1525760B@omniti.com>
Message-ID: <20170512232154.03e4fc1a@sleipner.datanom.net>

On Fri, 12 May 2017 16:12:09 -0400
Dan McDonald <danmcd at omniti.com> wrote:

> 
> You did say you were on KVM.  I wonder if blkdev or something else is being problematic?
> 
> Try booting, but selecting the new BE using grub specifically.  (And if you still want grub, put BE_HAS_GRUB=true into /etc/default/be on the 022 one post-boot, or the next beadm will scribble loader.)
> 
Rebooted an chose 151022 from the grub menu did boot as expected.
Rebooted again to activate the new boot loader succeeded;-) Maybe this
should be added to the upgrade notes?

-- 
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:
Linux: Because a PC is a terrible thing to waste.
(By komarimf at craft.camp.clarkson.edu, Mark Komarinski)
-------------- 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/20170512/e11cbfd1/attachment.bin>

From danmcd at omniti.com  Fri May 12 21:23:23 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 12 May 2017 17:23:23 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <20170512232154.03e4fc1a@sleipner.datanom.net>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170512205010.3e0385bc@sleipner.datanom.net>
	<D62082B7-A913-4736-B8C7-27659D184B8E@omniti.com>
	<20170512211337.26005a55@sleipner.datanom.net>
	<0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com>
	<20170512212112.704044c2@sleipner.datanom.net>
	<20170512220005.4ee29b8e@sleipner.datanom.net>
	<BC9EA7E8-A446-4D7E-B4D7-88BA1525760B@omniti.com>
	<20170512232154.03e4fc1a@sleipner.datanom.net>
Message-ID: <91D8CA2A-BB75-4CA1-9BA7-A1871C21D2C0@omniti.com>


> On May 12, 2017, at 5:21 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> Rebooted an chose 151022 from the grub menu did boot as expected.
> Rebooted again to activate the new boot loader succeeded;-) Maybe this
> should be added to the upgrade notes?

I did not have this problem you had in my 014 -> 022 update test.  I wasn't running it in KVM, either, to be fair.

Dan


From siyar.erdemli at gmail.com  Fri May 12 21:25:12 2017
From: siyar.erdemli at gmail.com (Siyar Erdemli)
Date: Sat, 13 May 2017 00:25:12 +0300
Subject: [OmniOS-discuss] OmniOS Ahci Error
Message-ID: <CAEKtCz0moSnfO9jRNi=D8GtC9skZ5x91NGLa-=v1xYbSpsJsCQ@mail.gmail.com>

Hi ,
What is this .

genunix: [ID 657156 kern.warning] WARNING: ahci1: error recovery for port 1
succeed
genunix: [ID 777486 kern.warning] WARNING: ahci1: ahci port 1 has interface
fatal error
genunix: [ID 687168 kern.warning] WARNING: ahci1: ahci port 1 is trying to
do error recovery
genunix: [ID 551337 kern.warning] WARNING: ahci1:       Transient Data
Integrity Error (T)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170513/7795680e/attachment.html>

From hakansom at ohsu.edu  Fri May 12 21:47:46 2017
From: hakansom at ohsu.edu (Marion Hakanson)
Date: Fri, 12 May 2017 14:47:46 -0700
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: Message from Krzysztof Grzempa <grzempek@gmail.com> of
	"Fri, 12 May 2017 20:18:22 +0200."
	<CAED-Y_D6MD1QWCn2750+iQZkwTj8x_5XbaHsbFx2334LXdeZ2Q@mail.gmail.com>
Message-ID: <201705122147.v4CLlkLC012344@kyklops.ohsu.edu>

I'd like to add my thanks to Dan for his valuable support of
the OmniOS community.  And to OmniTI for making the distribution
available to Solaris refugees (and ZFS & zones users) like myself.

We're a non-profit, so we found OmniTI's support costs beyond our
reach, but I believe we would be able to afford $1k or so per year
for an updates-only type of support contract that would cover the
ten or so storage servers we have here.

I wonder how many such $1k/yr customers (supporters) would be needed
to hire Dan to continue his work on behalf of the OmniOS/illumos
community.  Would 100 be enough?  200?

Regards,

Marion



> From: Krzysztof Grzempa <grzempek at gmail.com>
> Date: Fri, 12 May 2017 20:18:22 +0200
> To: <omnios-discuss at lists.omniti.com>
> Subject: Re: [OmniOS-discuss] To the OmniOS Community
> 
> Thank you Dan, for the best Illumos distro ever!
> I hope that the transfer to the community driven model will come true, and
> I hope you still will be the part of it.
> Now it is up to us, the 'community' to decide if we want to keep this great
> project alive or let if go.... I'm ready to participate somehow financial
> and with my skills...
> 
> 2017-05-12 19:35 GMT+02:00 Jim Klimov <jimklimov at cos.ru>:
> 
> > On May 12, 2017 6:07:01 PM GMT+03:00, Dan McDonald <danmcd at omniti.com>
> > wrote:
> > >Dear OmniOS Community,
> > >
> > >For the past 3+ years, it has been my pleasure and honor to be "OmniOS
> > >Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for
> > >solving problems, whether they be Home-Data-Center, service-hosting
> > >box, network filer, or other uses.
> > >
> > >As you saw, OmniTI is turning over OmniOS completely to the community.
> > >The decision-making was sensible for OmniTI, and I understand it
> > >completely. With r151022, OmniOS should be at a nice long-term state
> > >(022 was always intended to be LTS).
> > >
> > >I will be around OmniTI for another week (though on Friday the 19th my
> > >availability will be spotty).  During this next week, I encourage
> > >people to start upgrading or installing r151022 on their environments.
> > >I already have updated it on my own HDC, and it seems to be performing
> > >as it has previously.
> > >
> > >Thank you again, OmniOS community, for making these past three years as
> > >rewarding as I'd hoped they'd be when I joined OmniTI. And as for
> > >OmniTI, if you need web or database consulting, please keep them in
> > >mind. Still a fan, even though I'm no longer with them.
> > >
> > >Dan McDonald -- OmniOS Engineering
> > >
> > >_______________________________________________
> > >OmniOS-discuss mailing list
> > >OmniOS-discuss at lists.omniti.com
> > >http://lists.omniti.com/mailman/listinfo/omnios-discuss
> >
> > Oh, bummer... I hope you'd be around for the community effort too every
> > now and then. ;) Thanks for keeping that ship afloat!
> >
> > Jim
> > --
> > Typos courtesy of K-9 Mail on my Redmi Android
> > _______________________________________________
> > OmniOS-discuss mailing list
> > OmniOS-discuss at lists.omniti.com
> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> >
> 
> 



From tobi at oetiker.ch  Fri May 12 22:10:01 2017
From: tobi at oetiker.ch (Tobi Oetiker)
Date: Sat, 13 May 2017 00:10:01 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <201705122147.v4CLlkLC012344@kyklops.ohsu.edu>
References: <201705122147.v4CLlkLC012344@kyklops.ohsu.edu>
Message-ID: <401FF0B5-FA84-475C-A414-414DA68DED2E@oetiker.ch>

Hi Marion

> On 12 May 2017, at 23:47, Marion Hakanson <hakansom at ohsu.edu> wrote:
> 
> I wonder how many such $1k/yr customers (supporters) would be needed
> to hire Dan to continue his work on behalf of the OmniOS/illumos
> community.  Would 100 be enough?  200?
> 

there is a list to see how
much we could raise

https://docs.google.com/spreadsheets/d/1IyAI950a-JkPgRRLSezZm9-Rt8HkfO_nIkubd_m8d_0



> Regards,
> 
> Marion
> 
> 
> 
>> From: Krzysztof Grzempa <grzempek at gmail.com>
>> Date: Fri, 12 May 2017 20:18:22 +0200
>> To: <omnios-discuss at lists.omniti.com>
>> Subject: Re: [OmniOS-discuss] To the OmniOS Community
>> 
>> Thank you Dan, for the best Illumos distro ever!
>> I hope that the transfer to the community driven model will come true, and
>> I hope you still will be the part of it.
>> Now it is up to us, the 'community' to decide if we want to keep this great
>> project alive or let if go.... I'm ready to participate somehow financial
>> and with my skills...
>> 
>> 2017-05-12 19:35 GMT+02:00 Jim Klimov <jimklimov at cos.ru>:
>> 
>>> On May 12, 2017 6:07:01 PM GMT+03:00, Dan McDonald <danmcd at omniti.com>
>>> wrote:
>>>> Dear OmniOS Community,
>>>> 
>>>> For the past 3+ years, it has been my pleasure and honor to be "OmniOS
>>>> Engineering" at OmniTI. I hope I made OmniOS a nice platform to use for
>>>> solving problems, whether they be Home-Data-Center, service-hosting
>>>> box, network filer, or other uses.
>>>> 
>>>> As you saw, OmniTI is turning over OmniOS completely to the community.
>>>> The decision-making was sensible for OmniTI, and I understand it
>>>> completely. With r151022, OmniOS should be at a nice long-term state
>>>> (022 was always intended to be LTS).
>>>> 
>>>> I will be around OmniTI for another week (though on Friday the 19th my
>>>> availability will be spotty).  During this next week, I encourage
>>>> people to start upgrading or installing r151022 on their environments.
>>>> I already have updated it on my own HDC, and it seems to be performing
>>>> as it has previously.
>>>> 
>>>> Thank you again, OmniOS community, for making these past three years as
>>>> rewarding as I'd hoped they'd be when I joined OmniTI. And as for
>>>> OmniTI, if you need web or database consulting, please keep them in
>>>> mind. Still a fan, even though I'm no longer with them.
>>>> 
>>>> Dan McDonald -- OmniOS Engineering
>>>> 
>>>> _______________________________________________
>>>> OmniOS-discuss mailing list
>>>> OmniOS-discuss at lists.omniti.com
>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>> 
>>> Oh, bummer... I hope you'd be around for the community effort too every
>>> now and then. ;) Thanks for keeping that ship afloat!
>>> 
>>> Jim
>>> --
>>> Typos courtesy of K-9 Mail on my Redmi Android
>>> _______________________________________________
>>> 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/20170513/6d99a8ac/attachment-0001.html>

From jboren at drakecooper.com  Fri May 12 22:20:06 2017
From: jboren at drakecooper.com (Joseph Boren)
Date: Fri, 12 May 2017 16:20:06 -0600
Subject: [OmniOS-discuss] To the OmniOS Community
Message-ID: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>

Just wanted to add my thanks to Dan for the great support, and best wishes
for the future.

Cheers!


Joseph Boren

IT Specialist

+c: 208.891.2128

+ 416 S 8th St., Boise, ID 83702

+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170512/64487cd0/attachment.html>

From mir at miras.org  Sat May 13 19:34:49 2017
From: mir at miras.org (Michael Rasmussen)
Date: Sat, 13 May 2017 21:34:49 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
Message-ID: <20170513213449.00a994aa@sleipner.datanom.net>

Hi Dan and others,

On Fri, 12 May 2017 10:50:50 -0400
Dan McDonald <danmcd at omniti.com> wrote:

> As always, please start with the release notes:
> 
> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
> 
> And for this release, there are upgrade notes:
> 
> 	https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
> 
Upgraded my production server this afternoon and basically everything
went well except for a minor annoyance: /boot/solaris/bootenv.rc was
left untouched causing a system which had to be manually booted.

1) Followed update instructions to the letter.
2) Rebooted still using grub.
3) When rebooted did beadm activate r151022 to replace grub with bsd
loader. No errors reported.
4) Did a second reboot and now the walls came tumbling down on me since
bootenv.rc was not replaced (new one for bsd loader was put beside as
bootenv.rc.new) so bsd loader complained about syntax errors in
bootenv.rc and stopped in the boot environment.
5) To boot I did the following from the boot prompt:
   ok load /platform/i86pc/kernel/amd64/unix
   ok load -t rootfs /platform/i86pc/amd64/boot_archive
   ok boot
6) Next cp /boot/solaris/bootenv.rc /boot/solaris/bootenv.rc.old &&
        cp /boot/solaris/bootenv.rc.new /boot/solaris/bootenv.rc
7) Reboot

New bsd loader active, r151022 active, and system boots using loader
scripts.


-- 
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:
Here is a test to find whether your mission on earth is finished:
if you're alive, it isn't.
-------------- 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/20170513/a147de16/attachment.bin>

From omnios at citrus-it.net  Sun May 14 09:54:41 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Sun, 14 May 2017 09:54:41 +0000 (UTC)
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <20170513213449.00a994aa@sleipner.datanom.net>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170513213449.00a994aa@sleipner.datanom.net>
Message-ID: <nycvar.TFB.7.76.1705140944430.13990@erncre.pvgehf-vg.arg>


On Sat, 13 May 2017, Michael Rasmussen wrote:

; Hi Dan and others,
; ...
; Upgraded my production server this afternoon and basically everything
; went well except for a minor annoyance: /boot/solaris/bootenv.rc was
; left untouched causing a system which had to be manually booted.

Thanks for this Michael, it would have caught me too!

I suggest that people verify the checksum of /boot/solaris/bootenv.rc
before upgrading and revert it if necessary.

This is the checksum for a file which has not been modified:

# digest -a sha1 /boot/solaris/bootenv.rc
785e120126fde35eca303f7518c86e9aa2dc1e29

If the checksum is wrong, fix it with something like:

cp /boot/solaris/bootenv.rc /boot/solaris/bootenv.rc.old
curl https://pkg.omniti.com/omnios/r151020/omnios/file/0/785e120126fde35eca303f7518c86e9aa2dc1e29 | gzip -dc > /boot/solaris/bootenv.rc

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 grzempek at gmail.com  Sun May 14 15:33:56 2017
From: grzempek at gmail.com (Krzysztof Grzempa)
Date: Sun, 14 May 2017 17:33:56 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
Message-ID: <CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>

So, where are we at the moment? Any conclusions? Decisions? Plans?

regards


2017-05-13 0:20 GMT+02:00 Joseph Boren <jboren at drakecooper.com>:

> Just wanted to add my thanks to Dan for the great support, and best wishes
> for the future.
>
> Cheers!
>
>
> Joseph Boren
>
> IT Specialist
>
> +c: 208.891.2128 <(208)%20891-2128>
>
> + 416 S 8th St., Boise, ID 83702
>
> +
>
>
> _______________________________________________
> 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/20170514/b5888802/attachment.html>

From gate03 at landcroft.co.uk  Sun May 14 19:37:22 2017
From: gate03 at landcroft.co.uk (Michael Mounteney)
Date: Mon, 15 May 2017 05:37:22 +1000
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
Message-ID: <20170515053722.7c509bca@landcroft.co.uk>

On Sun, 14 May 2017 17:33:56 +0200
Krzysztof Grzempa <grzempek at gmail.com> wrote:

> So, where are we at the moment? Any conclusions? Decisions? Plans?

TBH it's not looking good.

https://gitter.im/PostOmniOS/Lobby has reached no firm conclusion.  We
certainly are well-short of a group of qualified and committed people
who could take-on management of OmniOS.

The funding poll at
https://docs.google.com/spreadsheets/d/1IyAI950a-JkPgRRLSezZm9-Rt8HkfO_nIkubd_m8d_0/edit
is short by an order of magnitude of what it needs to set-up commercial
OmniOS support.  Even the promises amount to less than a serious salary.

I hate to be negative but somebody has to say it and we have to decide
how to move on.

______________
Michael Mounteney
Landcroft Computing

From omnios at citrus-it.net  Sun May 14 21:33:38 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Sun, 14 May 2017 21:33:38 +0000 (UTC)
Subject: [OmniOS-discuss] Oddity following upgrade to r151022
Message-ID: <nycvar.TFB.7.76.1705142132340.23480@erncre.pvgehf-vg.arg>


I've upgraded some of my servers from r151020 to r151022 over the weekend.
Straightforward 'pkg update --bename', no zones on these ones.

On the first boot I saw some messages about various SVM related services
(and rex) being removed due to lack of manifest, so far so good.

SunOS Release 5.11 Version omnios-r151022-f9693432c2 64-bit
Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved.
Loading smf(5) service descriptions: 5/5
Delete service svc:/network/rpc/mdcomm as there are no supporting manifests
Delete service svc:/network/rpc/meta as there are no supporting manifests
Delete service svc:/network/rpc/rex as there are no supporting manifests
Delete service svc:/network/rpc/metamed as there are no supporting manifests
Delete service svc:/network/rpc/metamh as there are no supporting manifests
Delete service svc:/system/mdmonitor as there are no supporting manifests
Delete service svc:/system/metasync as there are no supporting manifests

but svc:/system/metainit:default is still there and is maintenance on
all servers.

bonnet# svcs -x
svc:/milestone/multi-user-server:default (multi-user plus exports milestone)
 State: offline since Sun May 14 11:09:51 2017
Reason: Unknown.
   See: http://illumos.org/msg/SMF-8000-AR
   See: init(1M)
Impact: 1 dependent service is not running.  (Use -v for list.)

svc:/system/metainit:default (SVM initialization)
 State: maintenance since Sun May 14 11:09:56 2017
Reason: Start method failed repeatedly, last exited with status 127.
   See: http://illumos.org/msg/SMF-8000-KS
   See: metainit(1M)
   See: /var/svc/log/system-metainit:default.log
Impact: This service is not running.

As you might expect, the start method is failing because the method script
is no longer there (/sbin/sh[1]: exec: /lib/svc/method/svc-metainit: not found)

There are some weird manifest-related properties in the service, could
these be why the service has stuck around after the upgrade?

bonnet# svcprop metainit | grep manifest
manifestfiles/code_omnios-151006_illumos-omnios_usr_src_cmd_lvm_util_metainit_xml astring /code/omnios-151006/illumos-omnios/usr/src/cmd/lvm/util/metainit.xml
manifestfiles/lib_svc_manifest_system_metainit_xml astring /lib/svc/manifest/system/metainit.xml

although I seem to have these on a few other services too, all
with 'omnios-151006' as part of the name.

I can delete the metainit service by hand but if I do that then
filesystem-local fails, seemingly because it tries to mount ZFS
filesystems in the wrong order. When I fix that (zfs umount; zfs mount -a)
then multi-user-server stays down with reason = Unknown.
That is because of rpc/smserver being in maintenance state. Deleting that
one clears everything and reboots seem ok.

Does anyone have any idea what's going on here? The same thing has happened
on four separate servers.

Thanks,

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 theo.schlossnagle at circonus.com  Sun May 14 23:10:32 2017
From: theo.schlossnagle at circonus.com (Theo Schlossnagle)
Date: Sun, 14 May 2017 19:10:32 -0400
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <20170515053722.7c509bca@landcroft.co.uk>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
Message-ID: <CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>

I have to chime in. Communities aren't built on money; they are built on
time. I think there has been an unhealthy focus on how much money people
are willing to pledge without considering who would even be willing to
accept that money for their time. Those willing might not require payment
at all.

Communities are built on collective need and contributed time. It comes
down to volunteering. I have yet to see anyone pledge time to do work, and
from my perspective that is what is truly needed here.

I was hoping not to be the first, but I will attempt to lead by example.
I'll pledge my time to do required security package publications on 014 and
022. As security issues with packages in core arise, I will update the
build system, re-roll the packages and publish them.

If this will be successful, other people will need to commit to do the work
and we will democratize the access to make that work possible.

Best regards,

Theo


On May 14, 2017 3:41 PM, "Michael Mounteney" <gate03 at landcroft.co.uk> wrote:

> On Sun, 14 May 2017 17:33:56 +0200
> Krzysztof Grzempa <grzempek at gmail.com> wrote:
>
> > So, where are we at the moment? Any conclusions? Decisions? Plans?
>
> TBH it's not looking good.
>
> https://gitter.im/PostOmniOS/Lobby has reached no firm conclusion.  We
> certainly are well-short of a group of qualified and committed people
> who could take-on management of OmniOS.
>
> The funding poll at
> https://docs.google.com/spreadsheets/d/1IyAI950a-
> JkPgRRLSezZm9-Rt8HkfO_nIkubd_m8d_0/edit
> is short by an order of magnitude of what it needs to set-up commercial
> OmniOS support.  Even the promises amount to less than a serious salary.
>
> I hate to be negative but somebody has to say it and we have to decide
> how to move on.
>
> ______________
> Michael Mounteney
> Landcroft Computing
> _______________________________________________
> 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/20170514/fa3394c2/attachment.html>

From danmcd at omniti.com  Mon May 15 00:21:46 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Sun, 14 May 2017 20:21:46 -0400
Subject: [OmniOS-discuss] Oddity following upgrade to r151022
In-Reply-To: <nycvar.TFB.7.76.1705142132340.23480@erncre.pvgehf-vg.arg>
References: <nycvar.TFB.7.76.1705142132340.23480@erncre.pvgehf-vg.arg>
Message-ID: <84BA8D68-7691-427B-91B1-2678B3D8659B@omniti.com>


> On May 14, 2017, at 5:33 PM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> 
> but svc:/system/metainit:default is still there and is maintenance on
> all servers.

I did multiple 020 to 022 (no-zones) upgrade tests, and I didn't see this.

> bonnet# svcprop metainit | grep manifest
> manifestfiles/code_omnios-151006_illumos-omnios_usr_src_cmd_lvm_util_metainit_xml astring /code/omnios-151006/illumos-omnios/usr/src/cmd/lvm/util/metainit.xml
> manifestfiles/lib_svc_manifest_system_metainit_xml astring /lib/svc/manifest/system/metainit.xml
> 
> although I seem to have these on a few other services too, all
> with 'omnios-151006' as part of the name.

Yeah... this may explain things.  Not unlike the bootenv.rc report from earlier, maybe having customizations in these caused some problems?



From mir at miras.org  Mon May 15 05:37:35 2017
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 15 May 2017 07:37:35 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
Message-ID: <20170515073735.53cbce9d@sleipner.datanom.net>

On Sun, 14 May 2017 19:10:32 -0400
Theo Schlossnagle <theo.schlossnagle at circonus.com> wrote:

> 
> Communities are built on collective need and contributed time. It comes
> down to volunteering. I have yet to see anyone pledge time to do work, and
> from my perspective that is what is truly needed here.
> 
This is not entirely true since I some weeks ago did exactly that
without specifying what I would do precisely.

> I was hoping not to be the first, but I will attempt to lead by example.
> I'll pledge my time to do required security package publications on 014 and
> 022. As security issues with packages in core arise, I will update the
> build system, re-roll the packages and publish them.
> 
To follow example I will commit myself to maintain the wiki and any
other web based infrastructure the project may need and choose to have.

-- 
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:
Don't patch bad code - rewrite it.
            - The Elements of Programming Style (Kernighan & Plaugher)
-------------- 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/20170515/e45a70ef/attachment.bin>

From vab at bb-c.de  Mon May 15 05:39:55 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Mon, 15 May 2017 07:39:55 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
Message-ID: <22809.16171.978855.391644@shelob.bb-c.de>

Theo Schlossnagle writes:
> I was hoping not to be the first, but I will attempt to lead by example. I'll
> pledge my time to do required security package publications on 014 and 022. As
> security issues with packages in core arise, I will update the build system,
> re-roll the packages and publish them.

I will help with packaging.  I will try to set aside 2-3 hours each
weekend to keep existing applications up to date, and to package new
applications as the need arises.

Should there be a team that manages the repository, I am willing to
be part of it.


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 natxo.asenjo at gmail.com  Mon May 15 06:05:15 2017
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Mon, 15 May 2017 08:05:15 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <22809.16171.978855.391644@shelob.bb-c.de>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<22809.16171.978855.391644@shelob.bb-c.de>
Message-ID: <CAHBEJzV67MLHEN5S7UFPTPvKxcxknUM+k=MV_vmRgUPuTggdNg@mail.gmail.com>

hi,

On Mon, May 15, 2017 at 7:39 AM, Volker A. Brandt <vab at bb-c.de> wrote:

> Theo Schlossnagle writes:
> > I was hoping not to be the first, but I will attempt to lead by example.
> I'll
> > pledge my time to do required security package publications on 014 and
> 022. As
> > security issues with packages in core arise, I will update the build
> system,
> > re-roll the packages and publish them.
>
> I will help with packaging.  I will try to set aside 2-3 hours each
> weekend to keep existing applications up to date, and to package new
> applications as the need arises.
>
> Should there be a team that manages the repository, I am willing to
> be part of it.


As a (very happy) home user, I really want Omnios to keep going. So if I'll
be happy to help with some some of my free time as well.

I have zero experience packaging software for Omnios, but I can learn (I
admin linux systems for a living, devops they call it now).

-- 
regards,
Natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170515/355d322b/attachment.html>

From tobi at oetiker.ch  Mon May 15 06:46:26 2017
From: tobi at oetiker.ch (Tobi Oetiker)
Date: Mon, 15 May 2017 08:46:26 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
Message-ID: <FED2BA79-F7FE-4BCB-9384-E739E2805518@oetiker.ch>

I will also be glad to help with packaging. 

O+P is already running a repo on pkg.oetiker.ch but we have not widely publicized it.

My main use of omnios is as a server for kvm an lxzones, so I would also be willing to help with porting updates from joyent unfortunately I have no experience with this at
all.

Tobias Oetiker
tobi at oetiker.ch
062 775 9902

> On 15 May 2017, at 01:10, Theo Schlossnagle <theo.schlossnagle at circonus.com> wrote:
> 
> I have to chime in. Communities aren't built on money; they are built on time. I think there has been an unhealthy focus on how much money people are willing to pledge without considering who would even be willing to accept that money for their time. Those willing might not require payment at all. 
> 
> Communities are built on collective need and contributed time. It comes down to volunteering. I have yet to see anyone pledge time to do work, and from my perspective that is what is truly needed here. 
> 
> I was hoping not to be the first, but I will attempt to lead by example. I'll pledge my time to do required security package publications on 014 and 022. As security issues with packages in core arise, I will update the build system, re-roll the packages and publish them.
> 
> If this will be successful, other people will need to commit to do the work and we will democratize the access to make that work possible.
> 
> Best regards, 
> 
> Theo
> 
> 
>> On May 14, 2017 3:41 PM, "Michael Mounteney" <gate03 at landcroft.co.uk> wrote:
>> On Sun, 14 May 2017 17:33:56 +0200
>> Krzysztof Grzempa <grzempek at gmail.com> wrote:
>> 
>> > So, where are we at the moment? Any conclusions? Decisions? Plans?
>> 
>> TBH it's not looking good.
>> 
>> https://gitter.im/PostOmniOS/Lobby has reached no firm conclusion.  We
>> certainly are well-short of a group of qualified and committed people
>> who could take-on management of OmniOS.
>> 
>> The funding poll at
>> https://docs.google.com/spreadsheets/d/1IyAI950a-JkPgRRLSezZm9-Rt8HkfO_nIkubd_m8d_0/edit
>> is short by an order of magnitude of what it needs to set-up commercial
>> OmniOS support.  Even the promises amount to less than a serious salary.
>> 
>> I hate to be negative but somebody has to say it and we have to decide
>> how to move on.
>> 
>> ______________
>> Michael Mounteney
>> Landcroft Computing
>> _______________________________________________
>> 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/20170515/fab780b3/attachment-0001.html>

From grzempek at gmail.com  Mon May 15 08:42:43 2017
From: grzempek at gmail.com (Krzysztof Grzempa)
Date: Mon, 15 May 2017 08:42:43 +0000
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <FED2BA79-F7FE-4BCB-9384-E739E2805518@oetiker.ch>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<FED2BA79-F7FE-4BCB-9384-E739E2805518@oetiker.ch>
Message-ID: <CAED-Y_DkEg6geyFkYGk_ok=LSmpW9QBT3xCZRYz0mLBv3qk1xA@mail.gmail.com>

I work as a devops, having  various scripting languages skills (python php
javascript), basics im c++ (learningowej proces)and 10+ years expierience
with Linux. Then i discovered solaris 8,9,10,11 and it suprised me with old
features which Linux was just starting.
Anyway, i have no expierience on packaging nor developing system itself but
im willing to Learn and help.
Thats for my statement...
Now, i belive we should make decisions on directions
- release model
- disscused mariage with OI
- governance of the project
- structure and roles in project

Etc

Regards
W dniu pon., 15.05.2017 o 08:48 Tobi Oetiker <tobi at oetiker.ch> napisa?(a):

> I will also be glad to help with packaging.
>
> O+P is already running a repo on pkg.oetiker.ch but we have not widely
> publicized it.
>
> My main use of omnios is as a server for kvm an lxzones, so I would also
> be willing to help with porting updates from joyent unfortunately I have no
> experience with this at
> all.
>
> Tobias Oetiker
> tobi at oetiker.ch
> 062 775 9902
>
> On 15 May 2017, at 01:10, Theo Schlossnagle <
> theo.schlossnagle at circonus.com> wrote:
>
> I have to chime in. Communities aren't built on money; they are built on
> time. I think there has been an unhealthy focus on how much money people
> are willing to pledge without considering who would even be willing to
> accept that money for their time. Those willing might not require payment
> at all.
>
> Communities are built on collective need and contributed time. It comes
> down to volunteering. I have yet to see anyone pledge time to do work, and
> from my perspective that is what is truly needed here.
>
> I was hoping not to be the first, but I will attempt to lead by example.
> I'll pledge my time to do required security package publications on 014 and
> 022. As security issues with packages in core arise, I will update the
> build system, re-roll the packages and publish them.
>
> If this will be successful, other people will need to commit to do the
> work and we will democratize the access to make that work possible.
>
> Best regards,
>
> Theo
>
>
> On May 14, 2017 3:41 PM, "Michael Mounteney" <gate03 at landcroft.co.uk>
> wrote:
>
>> On Sun, 14 May 2017 17:33:56 +0200
>> Krzysztof Grzempa <grzempek at gmail.com> wrote:
>>
>> > So, where are we at the moment? Any conclusions? Decisions? Plans?
>>
>> TBH it's not looking good.
>>
>> https://gitter.im/PostOmniOS/Lobby has reached no firm conclusion.  We
>> certainly are well-short of a group of qualified and committed people
>> who could take-on management of OmniOS.
>>
>> The funding poll at
>>
>> https://docs.google.com/spreadsheets/d/1IyAI950a-JkPgRRLSezZm9-Rt8HkfO_nIkubd_m8d_0/edit
>> is short by an order of magnitude of what it needs to set-up commercial
>> OmniOS support.  Even the promises amount to less than a serious salary.
>>
>> I hate to be negative but somebody has to say it and we have to decide
>> how to move on.
>>
>> ______________
>> Michael Mounteney
>> Landcroft Computing
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170515/d555efaf/attachment.html>

From omnios at citrus-it.net  Mon May 15 08:51:54 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Mon, 15 May 2017 08:51:54 +0000 (UTC)
Subject: [OmniOS-discuss] Oddity following upgrade to r151022
In-Reply-To: <84BA8D68-7691-427B-91B1-2678B3D8659B@omniti.com>
References: <nycvar.TFB.7.76.1705142132340.23480@erncre.pvgehf-vg.arg>
	<84BA8D68-7691-427B-91B1-2678B3D8659B@omniti.com>
Message-ID: <nycvar.TFB.7.76.1705150846110.29288@erncre.pvgehf-vg.arg>


On Sun, 14 May 2017, Dan McDonald wrote:

; > On May 14, 2017, at 5:33 PM, Andy Fiddaman <omnios at citrus-it.net> wrote:
; >
; > but svc:/system/metainit:default is still there and is maintenance on
; > all servers.
;
; I did multiple 020 to 022 (no-zones) upgrade tests, and I didn't see this.
;
; > bonnet# svcprop metainit | grep manifest
; > manifestfiles/code_omnios-151006_illumos-omnios_usr_src_cmd_lvm_util_metainit_xml astring /code/omnios-151006/illumos-omnios/usr/src/cmd/lvm/util/metainit.xml
; > manifestfiles/lib_svc_manifest_system_metainit_xml astring /lib/svc/manifest/system/metainit.xml
; >
; > although I seem to have these on a few other services too, all
; > with 'omnios-151006' as part of the name.
;
; Yeah... this may explain things.  Not unlike the bootenv.rc report from earlier, maybe having customizations in these caused some problems?

We have't made any local modifications to this though. The servers were
originally built on r151006 and then upgraded to each even release as it
came out. That's the only reason I can think of for the different
experience between this and upgrading from a vanilla r151020.

Anyway, 'svccfg delete metainit; svccfg delete rpc/smserver' got me back
up and running although I still can't explain the strange ZFS mount order
(child filesystems mounting before parents). That seems to be ok now
though; I'll try and replicate it again when I update the other data
centre.

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 omnios at citrus-it.net  Mon May 15 08:54:19 2017
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Mon, 15 May 2017 08:54:19 +0000 (UTC)
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
Message-ID: <nycvar.TFB.7.76.1705150852420.29288@erncre.pvgehf-vg.arg>


On Sun, 14 May 2017, Theo Schlossnagle wrote:

; I was hoping not to be the first, but I will attempt to lead by example.
; I'll pledge my time to do required security package publications on 014 and
; 022. As security issues with packages in core arise, I will update the
; build system, re-roll the packages and publish them.

We can help with packaging, merging changes from illumos, or whatever else
is required to keep this going.

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 gate03 at landcroft.co.uk  Mon May 15 09:36:29 2017
From: gate03 at landcroft.co.uk (Michael Mounteney)
Date: Mon, 15 May 2017 19:36:29 +1000
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
Message-ID: <20170515193629.5dec9842@landcroft.co.uk>

It seems my rather pessimistic assessment has started something going.
We have several volunteers making offers of various skills and I'm
happy to join them.  My skills are:

* Programming in C, C++, Java, Bash but not PHP.

* Home-user level sysadmin (configure dovecot, DHCP, NAT, KVM etc.
  without necessarily fully understanding what I'm doing).

* Testing, provided failure won't destroy data or cause other
  non-recoverable errors.

We still need a leader/coordinator.  Theo, would Robert allow you to do
that in company time?  He did say "while some of our staff may continue
contributing" which kind of implies that he might.  That would really
help, because it's quite obvious to me that unless a serious company
stands behind OmniOS, the big guns that are prepared to pay $10ks a
year for maintenance will go elsewhere.

The next step is the establishment of some sort of foundation or
committee to coordinate the efforts of the volunteers.

______________
Michael Mounteney

From alka at hfg-gmuend.de  Mon May 15 11:58:27 2017
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Mon, 15 May 2017 13:58:27 +0200
Subject: [OmniOS-discuss] To the OmniOS, OI and SmartOS community
Message-ID: <4373cbdf-3053-37f3-9eac-0ce99e89a5e4@hfg-gmuend.de>

*Its time to consider pla**n**B/C ??*
to: omnios-discuss, openindiana-discuss, smartos-discuss

The announcement of OmniTi to cancel OmniOS from now to then is a real 
disaster not only for OmniOS users but for the whole Illumos platform. 
Many users who want a free Solaris based OS especially in production 
environments selected OmniOS as their preferred Illumos platform mainly 
with use cases storage and general server applications.

The reasons:*OmniOS=**Up to date Illumos*
+ commercial support option (although way too expensive)
+ own developments like LX zones integration from SmartOS or drivers
+ stables/long term stables with very experienced full time staff 
(thanks to Dan and Dale again)

As OmniTi has released a new stable 151022, I/we have some time maybe to 
the end of the year unless OmniOS is out of sync with Illumos in a non 
tolerable amount.  Bugfixes of serious problems may be the case until 
then (hope so).

What are the/my options


*Plan A*
Hope for a continuation of OmniOS as a well maintained 
community/commercial project with further development, ongoing stables 
and bugfixes optionally with some paid contributions under the umbrella 
of a firm or at least with some experienced members that were already 
resonsible for OmniOS or an Illumos distribution and that can be trusted 
for next years.

While I hope for this, I doubt that this is a serious option. I switched 
from OpenIndiana to OmniOS three years ago as the OI community was too 
weak and development nearly stalled at that time. I am not interested in 
a new weak OmniOS community for a distribution that should be used as a 
production system. The OmniOS community will be propably too small 
forever as we already have the Illumos community project OpenIndiana 
nearly identical to OmniOS from distribution, features and use cases. 
And a very important thing: The brand OmniOS has already a very bad name 
as a dead/failed project in the press mostly affecting Illumos as well.


*Plan B*
OpenIndiana is a quite established community project for an up to date 
Illumos distribution. I would say its nearly identical to OmniOS beside 
the missing LX improvements from OmniOS but with an additional GUI 
option. I hope to see LX zones upstreamed to Illumos. OpenIndiana 
currently offers a rolling development of newest Illumos bits with 
snapshots every 6 months but without an additional stable repository 
with backported security fixes. Every update give you the newest Illumos 
fixes and features but also the newest bugs (ongoing dev, unstable).

If OmniOS has to become a community project, I undoubtly would prefer a 
merge of the two distributions up from next releases. OpenIndiana with a 
stable repo for every snapshot and with a repo as development path would 
give me what was the main advantage of OmniOS beside commercial support. 
Access to such a stable repo optionally under an OmniOS brand may be 
even a paid (if affordable) option. Such a merge would strengthen 
Illumos at first place but also free OpenSource distributions like 
OmniOS and OpenIndiana.


*Plan C*
There is another free Illumos distribution with an enterprise background 
suited for datacenter use: SmartOS. It even adds unique Cloud and 
virtualisation features like KVM, Solaris zones, Linux zones and Docker 
support. As it is running from RAM with everything important on a 
datapool it is a very stable/ easy recoverable option but it lacks some 
features in the global zone that are required for a storage server.  An 
additional plus is the pkgin repo with lots of supported long term 
stable services.

Using SmartOS would require a mechanism to allow storage services like 
SSH, Crossbow, iSCSI, NFS and SMB on the global zone with an option to 
save/restore settings from a datapool to be persistent. To be honest, a 
SmartOS that is capable to act as a storage appliance would be my dream 
option, at least as an additional option. This would require that 
SmartOS is not actively hindering this or preferable is helping to 
implement a save/restore option for global zone settings&features.


*Discuss*
But whatever option is coming, end the Illumos fragmentation for the 
sake of one strong free community distribution with a solid number of 
contributors and one freely available with a commercial background like 
SmartOS/ Samsung owned.


Any comments from OmniOS, OI, SmartOS (omnios-discuss, 
openindiana-discuss, smartos-discuss) communities?
I have send this to all three lists, so optionally answer all lists


best regards


Gea/ napp-it.org


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

From youzhong at gmail.com  Mon May 15 13:30:54 2017
From: youzhong at gmail.com (Youzhong Yang)
Date: Mon, 15 May 2017 09:30:54 -0400
Subject: [OmniOS-discuss] [smartos-discuss] To the OmniOS,
	OI and SmartOS community
In-Reply-To: <4373cbdf-3053-37f3-9eac-0ce99e89a5e4@hfg-gmuend.de>
References: <4373cbdf-3053-37f3-9eac-0ce99e89a5e4@hfg-gmuend.de>
Message-ID: <CADpNCvb6kN8ywsbR4P3603cBWg=gWFw_=GuU8xL4+0unSmQDfw@mail.gmail.com>

I would recommend Plan C. We've used SmartOS for years, with hundreds of
servers as storage backend, serving thousands of Linux/Mac/Windows clients.
Joyent has the best talented engineers and they are always willing to help.

By the way, we don't care much about packages, a stable and reliable kernel
is our requirement.

On Mon, May 15, 2017 at 7:58 AM, Guenther Alka <alka at hfg-gmuend.de> wrote:

> *Its time to consider pla**n** B/C ??*
> to: omnios-discuss, openindiana-discuss, smartos-discuss
>
> The announcement of OmniTi to cancel OmniOS from now to then is a real
> disaster not only for OmniOS users but for the whole Illumos platform. Many
> users who want a free Solaris based OS especially in production
> environments selected OmniOS as their preferred Illumos platform mainly
> with use cases storage and general server applications.
>
> The reasons:* OmniOS=**Up to date Illumos*
> + commercial support option (although way too expensive)
> + own developments like LX zones integration from SmartOS or drivers
> + stables/long term stables with very experienced full time staff (thanks
> to Dan and Dale again)
>
> As OmniTi has released a new stable 151022, I/we have some time maybe to
> the end of the year unless OmniOS is out of sync with Illumos in a non
> tolerable amount.  Bugfixes of serious problems may be the case until then
> (hope so).
>
> What are the/my options
>
>
> *Plan A*
> Hope for a continuation of OmniOS as a well maintained
> community/commercial project with further development, ongoing stables and
> bugfixes optionally with some paid contributions under the umbrella of a
> firm or at least with some experienced members that were already resonsible
> for OmniOS or an Illumos distribution and that can be trusted for next
> years.
>
> While I hope for this, I doubt that this is a serious option. I switched
> from OpenIndiana to OmniOS three years ago as the OI community was too weak
> and development nearly stalled at that time. I am not interested in a new
> weak OmniOS community for a distribution that should be used as a
> production system. The OmniOS community will be propably too small forever
> as we already have the Illumos community project OpenIndiana nearly
> identical to OmniOS from distribution, features and use cases. And a very
> important thing: The brand OmniOS has already a very bad name as a
> dead/failed project in the press mostly affecting Illumos as well.
>
>
> *Plan B*
> OpenIndiana is a quite established community project for an up to date
> Illumos distribution. I would say its nearly identical to OmniOS beside the
> missing LX improvements from OmniOS but with an additional GUI option. I
> hope to see LX zones upstreamed to Illumos. OpenIndiana currently offers a
> rolling development of newest Illumos bits with snapshots every 6 months
> but without an additional stable repository with backported security fixes.
> Every update give you the newest Illumos fixes and features but also the
> newest bugs (ongoing dev, unstable).
>
> If OmniOS has to become a community project, I undoubtly would prefer a
> merge of the two distributions up from next releases. OpenIndiana with a
> stable repo for every snapshot and with a repo as development path would
> give me what was the main advantage of OmniOS beside commercial support.
> Access to such a stable repo optionally under an OmniOS brand may be even a
> paid (if affordable) option. Such a merge would strengthen Illumos at first
> place but also free OpenSource distributions like OmniOS and OpenIndiana.
>
>
> *Plan C*
> There is another free Illumos distribution with an enterprise background
> suited for datacenter use: SmartOS. It even adds unique Cloud and
> virtualisation features like KVM, Solaris zones, Linux zones and Docker
> support. As it is running from RAM with everything important on a datapool
> it is a very stable/ easy recoverable option but it lacks some features in
> the global zone that are required for a storage server.  An additional plus
> is the pkgin repo with lots of supported long term stable services.
>
> Using SmartOS would require a mechanism to allow storage services like
> SSH, Crossbow, iSCSI, NFS and SMB on the global zone with an option to
> save/restore settings from a datapool to be persistent. To be honest, a
> SmartOS that is capable to act as a storage appliance would be my dream
> option, at least as an additional option. This would require that SmartOS
> is not actively hindering this or preferable is helping to implement a
> save/restore option for global zone settings&features.
>
>
> *Discuss*
> But whatever option is coming, end the Illumos fragmentation for the sake
> of one strong free community distribution with a solid number of
> contributors and one freely available with a commercial background like
> SmartOS/ Samsung owned.
>
>
> Any comments from OmniOS, OI, SmartOS (omnios-discuss,
> openindiana-discuss, smartos-discuss) communities?
> I have send this to all three lists, so optionally answer all lists
>
>
> best regards
>
>
> Gea/ napp-it.org
>
> *smartos-discuss* | Archives
> <https://www.listbox.com/member/archive/184463/=now>
> <https://www.listbox.com/member/archive/rss/184463/25077300-734ee1ca> |
> Modify
> <https://www.listbox.com/member/?member_id=25077300&id_secret=25077300-d8993174>
> Your Subscription <http://www.listbox.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170515/aff32497/attachment.html>

From chip at innovates.com  Mon May 15 13:37:40 2017
From: chip at innovates.com (Schweiss, Chip)
Date: Mon, 15 May 2017 08:37:40 -0500
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <20170515073735.53cbce9d@sleipner.datanom.net>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
Message-ID: <CALeZrrRvHwNe1wVjko3=A=N=c5fjobOijhnaBoww8+LN5tWVKg@mail.gmail.com>

I just added my potential in paid support for OmniOS being maintained
professionally.   This spreadsheet does reveal the realities OmniTI was
facing with OmniOS.   My guess is they were never close to turning a profit
on it.

It saddens me to see such a well developed and maintained distribution go
unsupported.   I hope there is enough commercial potential that OmniOS gets
picked up to offer a supported distribution, but I don't expect there will
be.   OmniOS is, unfortunately, a niche product, that doesn't have enough
paying customer potential. Just as many others did, I initially started
using it as a platform to run ZFS storage.  It made much
more economical sense than buying into Nexenta in order to get a supported
platform.  ZFS is now much more mature on Linux and I suspect this
drastically reduces OmniOS's demand.

Dan McDonald and OmniTI put forward an excellent run at it.
Unfortunately, OmniOS was, for the most part, a one-man show that without
Dan will, by my best prediction, die a long slow death.   I'm sure there
will be some advancement by the community for several years to come, but
not at a pace and quality that can be tolerated by users like myself.

I give the credit to Dan, for the development of such a great distribution
of Illumos, and relentless effort to support it.  I do have to criticize
OmniTI for poor execution.   We were paid supporters of OmniOS, however,
things like sending out renewal invoices were never executed in a timely
manner and requests for quotes for additional server support were difficult
to get a response on.   I think in the three years we were paid supporters,
we probably only paid for two.

Should a new company offer a paid support contract for OmniOS with the
talent to back it up, I will very quickly get Washington University on
board.  If that doesn't happen in the next few months, I will start our
plan of moving or ZFS storage to another platform, that has long-term
viability and hopefully some sort of paid support.   That may mean getting
an independent contractor or consulting firm on retainer for emergency help
or dedicated patch development/maintenance.

-Chip

On Mon, May 15, 2017 at 12:37 AM, Michael Rasmussen <mir at miras.org> wrote:

> On Sun, 14 May 2017 19:10:32 -0400
> Theo Schlossnagle <theo.schlossnagle at circonus.com> wrote:
>
> >
> > Communities are built on collective need and contributed time. It comes
> > down to volunteering. I have yet to see anyone pledge time to do work,
> and
> > from my perspective that is what is truly needed here.
> >
> This is not entirely true since I some weeks ago did exactly that
> without specifying what I would do precisely.
>
> > I was hoping not to be the first, but I will attempt to lead by example.
> > I'll pledge my time to do required security package publications on 014
> and
> > 022. As security issues with packages in core arise, I will update the
> > build system, re-roll the packages and publish them.
> >
> To follow example I will commit myself to maintain the wiki and any
> other web based infrastructure the project may need and choose to have.
>
> --
> 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:
> Don't patch bad code - rewrite it.
>             - The Elements of Programming Style (Kernighan & Plaugher)
>
> _______________________________________________
> 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/20170515/6fa02868/attachment.html>

From danmcd at omniti.com  Mon May 15 14:36:07 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 15 May 2017 10:36:07 -0400
Subject: [OmniOS-discuss] Bloody bump to r151023, and more
Message-ID: <3F9EEA8E-A222-4796-BF35-780587228307@omniti.com>

This is my last official week at OmniTI.

Besides trying to get an r151022 AWS image spun up, I'm also attempting to bump the bloody repo & master branch to r151023, so bloody can stay bloody (vs. the now-released r151022).  If all goes well, things will be up before bedtime tonight, US/Eastern.

I still run OmniOS at home, BTW.  Depending on where I land, I can spend some amount of time (the precise amount may be a function of where I land, or not... I'm honestly not sure) answering questions and helping out.  When I got to OmniTI three years ago, I had Theo and Eric right nearby to answer, "What were you thinking?" (with all sorts of inflections) when encountering various build & setup decisions.  I hope to be able to answer similar questions as people build & use OmniOS going forward.

I hope I was never too opaque in what I was doing with OmniOS during the gaps between scheduled releases.  If I didn't share, it was out of forgetfulness or old habit, not out of any intended desire to keep things close.  If there's any opacity lingering, I'm happy to remove it.  To that end, I hope to, some time this week, spell out what I had planned for the gap between 022 and 024.

Thanks!
Dan


From hasslerd at gmx.li  Mon May 15 16:49:40 2017
From: hasslerd at gmx.li (Dominik Hassler)
Date: Mon, 15 May 2017 18:49:40 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
Message-ID: <eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>

Hey,

after the upgrade, the boot loader is still GRUB.

I did the upgrade according to the upgrade notes. Rebooted once, did a:

$ sudo beadm activate omnios-r151022
WARNING: menu.lst file /rpool/boot/menu.lst does not exist,
          generating a new menu.lst file
Activated successfully

checked for a /etc/default/be file. there is none. Still the boot loader 
is GRUB instead of loader.



On 05/12/2017 04:50 PM, Dan McDonald wrote:
> As always, please start with the release notes:
>
> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
>
> And for this release, there are upgrade notes:
>
> 	https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
>
> This is an LTS and Stable update.  Highlights include:
>
> - BSD Loader is now available.  This has its own wiki page, including how to stick with GRUB if you think you need to.
>
> - Kayak Interactive Installer --> No more Caiman, no more F-keys & curses, and no-more hacking timezone names.  Also, one less repo to maintain for OmniOS. Kayak does it all now.
>
> - Python is now 2.7. This means an IPS/pkg(5) update too. There's a subtle, but noteworthy, update to linked-image semantics ("pkg update -r") AND upgrading non-linked-image "ipkg" zones is a bit more difficult due to the transition (chicken & egg problem with ipkg brand "attach").
>
> - Perl is now 5.24.1.
>
> - USB 3.0 support.
>
> With OmniTI withdrawing funding for OmniOS-as-product, this will be the last OmniTI-pushed "release" of OmniOS. It contains all of the most recent (as of May) illumos-gate changes, AND illumos-joyent LX brand changes.
>
> This release broke the 6-month cadence, due to Loader, Python2.7, and the need for Kayak to take over ALL installation duties.  I'm sorry for it being 1-2 months late, but I wanted to make sure these changes were comfortably in place during the 021 bloody.
>
> Because of the sheer volume of change in this release, I had to update many OmniOS wiki pages.  Here's a list of all of those I changed nontrivially due to r151022.  Please check them out to make sure I'm not missing anything...
>
> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
>
> 	https://omnios.omniti.com/wiki.php/Installation
>
> 	https://omnios.omniti.com/wiki.php/LXZones
>
> 	https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
>
> 	https://omnios.omniti.com/wiki.php/NewLinkedImages
>
> 	https://omnios.omniti.com/wiki.php/linked_images
>
> 	https://omnios.omniti.com/wiki.php/KayakInteractive
>
> 	https://omnios.omniti.com/wiki.php/BSDLoader
>
> 	https://omnios.omniti.com/wiki.php/ReleaseCycle
>
> 	https://omnios.omniti.com/wiki.php/Packaging
>
> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/
>
> 	https://omnios.omniti.com/wiki.php/WikiStart
>
> 	https://omnios.omniti.com/wiki.php/BuildInstructions
>
> 	https://omnios.omniti.com/wiki.php/Maintainers
>
> 	https://omnios.omniti.com/wiki.php/illumos-tools
>
> 	https://omnios.omniti.com/wiki.php/buildctl
>
> 	https://omnios.omniti.com/wiki.php/ReleaseMedia
>
> I'll have more to say about my departure from OmniTI in a distinct e-mail.
>
> Thanks, and happy upgrading!
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From mir at miras.org  Mon May 15 17:47:43 2017
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 15 May 2017 19:47:43 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
Message-ID: <5B625867-8245-4784-B325-773BB91E5F31@miras.org>

Have you rebooted once more?

On May 15, 2017 6:49:40 PM GMT+02:00, Dominik Hassler <hasslerd at gmx.li> wrote:
>Hey,
>
>after the upgrade, the boot loader is still GRUB.
>
>I did the upgrade according to the upgrade notes. Rebooted once, did a:
>
>$ sudo beadm activate omnios-r151022
>WARNING: menu.lst file /rpool/boot/menu.lst does not exist,
>          generating a new menu.lst file
>Activated successfully
>
>checked for a /etc/default/be file. there is none. Still the boot
>loader 
>is GRUB instead of loader.
>
>
>
>On 05/12/2017 04:50 PM, Dan McDonald wrote:
>> As always, please start with the release notes:
>>
>> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
>>
>> And for this release, there are upgrade notes:
>>
>> 	https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
>>
>> This is an LTS and Stable update.  Highlights include:
>>
>> - BSD Loader is now available.  This has its own wiki page, including
>how to stick with GRUB if you think you need to.
>>
>> - Kayak Interactive Installer --> No more Caiman, no more F-keys &
>curses, and no-more hacking timezone names.  Also, one less repo to
>maintain for OmniOS. Kayak does it all now.
>>
>> - Python is now 2.7. This means an IPS/pkg(5) update too. There's a
>subtle, but noteworthy, update to linked-image semantics ("pkg update
>-r") AND upgrading non-linked-image "ipkg" zones is a bit more
>difficult due to the transition (chicken & egg problem with ipkg brand
>"attach").
>>
>> - Perl is now 5.24.1.
>>
>> - USB 3.0 support.
>>
>> With OmniTI withdrawing funding for OmniOS-as-product, this will be
>the last OmniTI-pushed "release" of OmniOS. It contains all of the most
>recent (as of May) illumos-gate changes, AND illumos-joyent LX brand
>changes.
>>
>> This release broke the 6-month cadence, due to Loader, Python2.7, and
>the need for Kayak to take over ALL installation duties.  I'm sorry for
>it being 1-2 months late, but I wanted to make sure these changes were
>comfortably in place during the 021 bloody.
>>
>> Because of the sheer volume of change in this release, I had to
>update many OmniOS wiki pages.  Here's a list of all of those I changed
>nontrivially due to r151022.  Please check them out to make sure I'm
>not missing anything...
>>
>> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
>>
>> 	https://omnios.omniti.com/wiki.php/Installation
>>
>> 	https://omnios.omniti.com/wiki.php/LXZones
>>
>> 	https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
>>
>> 	https://omnios.omniti.com/wiki.php/NewLinkedImages
>>
>> 	https://omnios.omniti.com/wiki.php/linked_images
>>
>> 	https://omnios.omniti.com/wiki.php/KayakInteractive
>>
>> 	https://omnios.omniti.com/wiki.php/BSDLoader
>>
>> 	https://omnios.omniti.com/wiki.php/ReleaseCycle
>>
>> 	https://omnios.omniti.com/wiki.php/Packaging
>>
>> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/
>>
>> 	https://omnios.omniti.com/wiki.php/WikiStart
>>
>> 	https://omnios.omniti.com/wiki.php/BuildInstructions
>>
>> 	https://omnios.omniti.com/wiki.php/Maintainers
>>
>> 	https://omnios.omniti.com/wiki.php/illumos-tools
>>
>> 	https://omnios.omniti.com/wiki.php/buildctl
>>
>> 	https://omnios.omniti.com/wiki.php/ReleaseMedia
>>
>> I'll have more to say about my departure from OmniTI in a distinct
>e-mail.
>>
>> Thanks, and happy upgrading!
>> 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

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170515/f1888a70/attachment.html>

From danmcd at omniti.com  Mon May 15 18:06:45 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 15 May 2017 14:06:45 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
Message-ID: <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>


> On May 15, 2017, at 12:49 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
> 
> Hey,
> 
> after the upgrade, the boot loader is still GRUB.
> 
> I did the upgrade according to the upgrade notes. Rebooted once, did a:
> 
> $ sudo beadm activate omnios-r151022
> WARNING: menu.lst file /rpool/boot/menu.lst does not exist,
>         generating a new menu.lst file
> Activated successfully
> 
> checked for a /etc/default/be file. there is none. Still the boot loader is GRUB instead of loader.

Are you on a mirrored root pool?  It's possible the libbe code that installs loader doesn't do it to all disks in a mirrored pool...

Worst-case scenario is to explicitly install it:

	foreach (drive)
		installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/<drive>

Dan


From an3s.annema at gmail.com  Mon May 15 18:08:52 2017
From: an3s.annema at gmail.com (Andries Annema)
Date: Mon, 15 May 2017 20:08:52 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <20170515193629.5dec9842@landcroft.co.uk>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515193629.5dec9842@landcroft.co.uk>
Message-ID: <01ef60e0-722c-d99e-dbaf-f128b0f9f36f@gmail.com>

It seems indeed you did shake things up a bit.

To give my two cents in this: I am happy to help! Although I am not a 
developer - sysadmin at most, and even that is not my *primary* everyday 
function - I am always eager to learn.

My current state/skills regarding OmniOS (since 2014):

* am running two LTS (r151014 for now) boxes at home,

* non-global zones (LX zones not yet),

* KVM,

* some bash scripting skills (not even close to being an ace though),

* have done some compiling and IPS packaging while hosting it on a 
personal repo (but compiling skills are still novice)

* was/am planning to start using some Illumos-distro (preferably OmniOS) 
at my boss' office - where I'm the sysadmin - but as a result of these 
late developments I am investigating alternatives (ZFS-on-Linux, Docker, 
...) as well.

* willing to do some testing too - not too much on my production 
machines though, but I can setup some physical or virtual test environment.

* oh, and have been using Linux (Ubuntu, CentOS, OpenSUSE) since 2011.

I sincerely hope we can keep this thing going.

Regards,

Andries

On 2017-05-15 11:36, Michael Mounteney wrote:
> It seems my rather pessimistic assessment has started something going.
> We have several volunteers making offers of various skills and I'm
> happy to join them.  My skills are:
>
> * Programming in C, C++, Java, Bash but not PHP.
>
> * Home-user level sysadmin (configure dovecot, DHCP, NAT, KVM etc.
>    without necessarily fully understanding what I'm doing).
>
> * Testing, provided failure won't destroy data or cause other
>    non-recoverable errors.
>
> We still need a leader/coordinator.  Theo, would Robert allow you to do
> that in company time?  He did say "while some of our staff may continue
> contributing" which kind of implies that he might.  That would really
> help, because it's quite obvious to me that unless a serious company
> stands behind OmniOS, the big guns that are prepared to pay $10ks a
> year for maintenance will go elsewhere.
>
> The next step is the establishment of some sort of foundation or
> committee to coordinate the efforts of the volunteers.
>
> ______________
> Michael Mounteney
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From peter.tribble at gmail.com  Mon May 15 18:32:45 2017
From: peter.tribble at gmail.com (Peter Tribble)
Date: Mon, 15 May 2017 19:32:45 +0100
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
Message-ID: <CAEgYsbGh_Bpnzg95=X_QFAvyr8VE2Rd-ZYK07kBaXmA+EYF1dA@mail.gmail.com>

On Mon, May 15, 2017 at 12:10 AM, Theo Schlossnagle <
theo.schlossnagle at circonus.com> wrote:

> I have to chime in. Communities aren't built on money; they are built on
> time. I think there has been an unhealthy focus on how much money people
> are willing to pledge without considering who would even be willing to
> accept that money for their time. Those willing might not require payment
> at all.
>

Not to mention the bureaucratic technicalities and legalities of
handling payment. If there are people who do wish to contribute
financially, then supporting involvement at community events
(FOSDEM is the first one that comes to mind) is always welcome.


> Communities are built on collective need and contributed time. It comes
> down to volunteering. I have yet to see anyone pledge time to do work, and
> from my perspective that is what is truly needed here.
>
> I was hoping not to be the first, but I will attempt to lead by example.
> I'll pledge my time to do required security package publications on 014 and
> 022. As security issues with packages in core arise, I will update the
> build system, re-roll the packages and publish them.
>

Thanks for setting the example. I suspect there were a few who didn't
want to be the first either.


> If this will be successful, other people will need to commit to do the
> work and we will democratize the access to make that work possible.
>

I'm willing to help maintain, test, and develop illumos-omnios.


> Best regards,
>
> Theo
>
>
> On May 14, 2017 3:41 PM, "Michael Mounteney" <gate03 at landcroft.co.uk>
> wrote:
>
>> On Sun, 14 May 2017 17:33:56 +0200
>> Krzysztof Grzempa <grzempek at gmail.com> wrote:
>>
>> > So, where are we at the moment? Any conclusions? Decisions? Plans?
>>
>> TBH it's not looking good.
>>
>> https://gitter.im/PostOmniOS/Lobby has reached no firm conclusion.  We
>> certainly are well-short of a group of qualified and committed people
>> who could take-on management of OmniOS.
>>
>> The funding poll at
>> https://docs.google.com/spreadsheets/d/1IyAI950a-JkPgRRLSezZ
>> m9-Rt8HkfO_nIkubd_m8d_0/edit
>> is short by an order of magnitude of what it needs to set-up commercial
>> OmniOS support.  Even the promises amount to less than a serious salary.
>>
>> I hate to be negative but somebody has to say it and we have to decide
>> how to move on.
>>
>> ______________
>> Michael Mounteney
>> Landcroft Computing
>> _______________________________________________
>> 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
>
>


-- 
-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/20170515/e0468daa/attachment-0001.html>

From mir at miras.org  Mon May 15 18:38:57 2017
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 15 May 2017 20:38:57 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
	<0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>
Message-ID: <20170515203857.79076fed@sleipner.datanom.net>

On Mon, 15 May 2017 14:06:45 -0400
Dan McDonald <danmcd at omniti.com> wrote:

> 
> Are you on a mirrored root pool?  It's possible the libbe code that installs loader doesn't do it to all disks in a mirrored pool...
> 
Seems to have done it here:
zpool status rpool
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0 in 1h2m with 0 errors on Sun May  7 07:17:06 2017
config:

        NAME          STATE     READ WRITE CKSUM
        rpool         ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            c8t3d0s0  ONLINE       0     0     0
            c8t2d0s0  ONLINE       0     0     0

installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/c8t2d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)? y
bootblock version installed on /dev/rdsk/c8t2d0s0 is more recent or identical
Use -F to override or install without the -u option

installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/c8t3d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)? y
bootblock version installed on /dev/rdsk/c8t3d0s0 is more recent or identical
Use -F to override or install without the -u option


-- 
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:
If I had to live my life again, I'd make the same mistakes, only sooner.
		-- Tallulah Bankhead
-------------- 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/20170515/5a500401/attachment.bin>

From vab at bb-c.de  Mon May 15 19:47:17 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Mon, 15 May 2017 21:47:17 +0200
Subject: [OmniOS-discuss] Bloody bump to r151023, and more
In-Reply-To: <3F9EEA8E-A222-4796-BF35-780587228307@omniti.com>
References: <3F9EEA8E-A222-4796-BF35-780587228307@omniti.com>
Message-ID: <22810.1477.637911.914201@shelob.bb-c.de>

Hello all!


Dan wrote:
> Besides trying to get an r151022 AWS image spun up, I'm also attempting to
> bump the bloody repo & master branch to r151023, so bloody can stay bloody
> (vs. the now-released r151022).

This is good news.  It got me thinking a bit... a number of people,
myself included, have volunteered to take on the task of caring for
the repository, most notably Theo who will deal with security issues
in Omnios "core".

So the big question is what will happen to the repositories (022 and
bloody).  In IRC, Dan assured me that they will stay at OmniTI in
the near future, until the community decides otherwise.

This brings me to the following questions:

- What is the process of contributing something to either repo in the
  "post-Dan" era?  Send a pull request to Theo?  Someone else?  Some
  reviewed semi-automatic process? (I am still not friends with git :-)

- Who decides what goes into the repo?

- Who will sign the 022 repository packages?  (Remember that they
  currently are signed using OmniTI-owned certificates.)

- Who will maintain a mechanism to retrieve and/or store the upstream
  sources for the various open source components in OmniOS userland?

I don't care much about community governance and release model and
project structure.  I do care about a well-maintained repository
that is universally accessible and can be used by anyone anywhere
wishing to update their 022 installation to the latest software.

I have some more ideas but first things first. :-)


Best 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 tobi at oetiker.ch  Mon May 15 20:10:30 2017
From: tobi at oetiker.ch (Tobi Oetiker)
Date: Mon, 15 May 2017 22:10:30 +0200
Subject: [OmniOS-discuss] Bloody bump to r151023, and more
In-Reply-To: <22810.1477.637911.914201@shelob.bb-c.de>
References: <3F9EEA8E-A222-4796-BF35-780587228307@omniti.com>
	<22810.1477.637911.914201@shelob.bb-c.de>
Message-ID: <8172470C-A988-46E5-9923-BC2A37AC0F0F@oetiker.ch>



> On 15 May 2017, at 21:47, Volker A. Brandt <vab at bb-c.de> wrote:

> This brings me to the following questions:
> 
> - What is the process of contributing something to either repo in the "post-Dan" era?  Send a pull request to Theo?  Someone else?  Some reviewed semi-automatic process? (I am still not friends with git :-)
> 
> - Who decides what goes into the repo?

As far as github goes they have added some nice voting system recently, so PRs can be commented on and Approved or Changes requested.

I think this would work very well for omnios.

cheers
tobi

From bfriesen at simple.dallas.tx.us  Mon May 15 20:40:36 2017
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Mon, 15 May 2017 15:40:36 -0500 (CDT)
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <nycvar.TFB.7.76.1705140944430.13990@erncre.pvgehf-vg.arg>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170513213449.00a994aa@sleipner.datanom.net>
	<nycvar.TFB.7.76.1705140944430.13990@erncre.pvgehf-vg.arg>
Message-ID: <alpine.GSO.2.20.1705151533570.27552@freddy.simplesystems.org>

On Sun, 14 May 2017, Andy Fiddaman wrote:
>
> I suggest that people verify the checksum of /boot/solaris/bootenv.rc
> before upgrading and revert it if necessary.
>
> This is the checksum for a file which has not been modified:
>
> # digest -a sha1 /boot/solaris/bootenv.rc
> 785e120126fde35eca303f7518c86e9aa2dc1e29

This is what I get on both of my systems running r151020 
(014->016->018->022 on one and perhaps 018->022 on the other):

13cbcd8decbec24324e283d875da433946d6af91

Doing a diff, I see only this difference:

% diff /boot/solaris/bootenv.rc bootenv.rc
42d41
< setprop console text

Does this meant that the configuration has been somehow modified, or 
is the difference benign?

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

From mir at miras.org  Mon May 15 20:46:10 2017
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 15 May 2017 22:46:10 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <20170515073735.53cbce9d@sleipner.datanom.net>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
Message-ID: <20170515224610.08b5cc56@sleipner.datanom.net>

On Mon, 15 May 2017 07:37:35 +0200
Michael Rasmussen <mir at miras.org> wrote:

> To follow example I will commit myself to maintain the wiki and any
> other web based infrastructure the project may need and choose to have.
> 
I have found out that Omniti holds the domain name omnios.org. Will
Omniti consider handing over omnios.org to the community?

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
He hated being thought of as one of those people that wore stupid
ornamental armour. It was gilt by association.
		-- Terry Pratchett, "Night Watch"
-------------- 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/20170515/82f95dfb/attachment.bin>

From mir at miras.org  Mon May 15 20:51:10 2017
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 15 May 2017 22:51:10 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <alpine.GSO.2.20.1705151533570.27552@freddy.simplesystems.org>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<20170513213449.00a994aa@sleipner.datanom.net>
	<nycvar.TFB.7.76.1705140944430.13990@erncre.pvgehf-vg.arg>
	<alpine.GSO.2.20.1705151533570.27552@freddy.simplesystems.org>
Message-ID: <20170515225110.5a422613@sleipner.datanom.net>

On Mon, 15 May 2017 15:40:36 -0500 (CDT)
Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:

> This is what I get on both of my systems running r151020 (014->016->018->022 on one and perhaps 018->022 on the other):
> 
> 13cbcd8decbec24324e283d875da433946d6af91
> 
> Doing a diff, I see only this difference:
> 
> % diff /boot/solaris/bootenv.rc bootenv.rc
> 42d41
> < setprop console text
> 
> Does this meant that the configuration has been somehow modified, or is the difference benign?
> 
What you should do before rebooting after converting from grub to bsd
loader is to ensure that /boot/solaris/bootenv.rc.new does not exist
and if it exists copy it to /boot/solaris/bootenv.rc after you have
made a backup of the old /boot/solaris/bootenv.rc. The reason is that
the grub boot loader wants options to be included in '' while the bsd
boot loader considers '' around options a syntax error causing a boot
to fail.

-- 
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 once witnessed a long-winded, month-long flamewar over the use of
mice vs. trackballs...It was very silly."
(By Matt Welsh)
-------------- 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/20170515/6208d730/attachment.bin>

From danmcd at omniti.com  Mon May 15 20:56:23 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 15 May 2017 16:56:23 -0400
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <20170515224610.08b5cc56@sleipner.datanom.net>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
	<20170515224610.08b5cc56@sleipner.datanom.net>
Message-ID: <94317A30-BE86-4390-9E17-B98EAAB897DF@omniti.com>


> On May 15, 2017, at 4:46 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Mon, 15 May 2017 07:37:35 +0200
> Michael Rasmussen <mir at miras.org> wrote:
> 
>> To follow example I will commit myself to maintain the wiki and any
>> other web based infrastructure the project may need and choose to have.
>> 
> I have found out that Omniti holds the domain name omnios.org. Will
> Omniti consider handing over omnios.org to the community?

I believe that IS part of the plan.  Robert T. can answer that with authority, however.

Dan


From jesus at omniti.com  Mon May 15 21:08:18 2017
From: jesus at omniti.com (Theo Schlossnagle)
Date: Mon, 15 May 2017 17:08:18 -0400
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <20170515224610.08b5cc56@sleipner.datanom.net>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
	<20170515224610.08b5cc56@sleipner.datanom.net>
Message-ID: <CACLsApvptK+ySbQ3Bg5e_0AM6KGMqAXr9Wg7gBWYG6Bz=EArgA@mail.gmail.com>

My understanding from Robert's email was that they'd hand over all that
stuff.  But a "community" isn't a legal entity to which someone can hand
something over.  I'm doing some research on governance models that would
most-closely emulate community ownership.

On Mon, May 15, 2017 at 4:46 PM, Michael Rasmussen <mir at miras.org> wrote:

> On Mon, 15 May 2017 07:37:35 +0200
> Michael Rasmussen <mir at miras.org> wrote:
>
> > To follow example I will commit myself to maintain the wiki and any
> > other web based infrastructure the project may need and choose to have.
> >
> I have found out that Omniti holds the domain name omnios.org. Will
> Omniti consider handing over omnios.org to the community?
>
> --
> Hilsen/Regards
> Michael Rasmussen
>
> Get my public GnuPG keys:
> michael <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> /usr/games/fortune -es says:
> He hated being thought of as one of those people that wore stupid
> ornamental armour. It was gilt by association.
>                 -- Terry Pratchett, "Night Watch"
>
> _______________________________________________
> 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/20170515/ab7369a9/attachment.html>

From mir at miras.org  Mon May 15 21:16:39 2017
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 15 May 2017 23:16:39 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CACLsApvptK+ySbQ3Bg5e_0AM6KGMqAXr9Wg7gBWYG6Bz=EArgA@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
	<20170515224610.08b5cc56@sleipner.datanom.net>
	<CACLsApvptK+ySbQ3Bg5e_0AM6KGMqAXr9Wg7gBWYG6Bz=EArgA@mail.gmail.com>
Message-ID: <20170515231639.64159c3e@sleipner.datanom.net>

On Mon, 15 May 2017 17:08:18 -0400
Theo Schlossnagle <jesus at omniti.com> wrote:

> My understanding from Robert's email was that they'd hand over all that
> stuff.  But a "community" isn't a legal entity to which someone can hand
> something over.  I'm doing some research on governance models that would
> most-closely emulate community ownership.
> 
I think the most used way of handling something like this is either
creating a company or a trust fund which holds all trademarks, domain
names etc.

-- 
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:
"...Deep Hack Mode--that mysterious and frightening state of
consciousness where Mortal Users fear to tread."
(By Matt Welsh)
-------------- 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/20170515/12604d6c/attachment.bin>

From philipcristiano at philipcristiano.com  Mon May 15 21:20:36 2017
From: philipcristiano at philipcristiano.com (Philip Cristiano)
Date: Mon, 15 May 2017 17:20:36 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
Message-ID: <1494883236.301343.977575080.0DBF9FF5@webmail.messagingengine.com>

It looks like https://omnios.omniti.com/wiki.php/Installation should be
updated to point to the latest release. Currently it lists `r151020` as
the current stable and `r151014` as the current LTS. 

-- 
  Philip Cristiano
  philipcristiano at philipcristiano.com

On Fri, May 12, 2017, at 10:50 AM, Dan McDonald wrote:
> As always, please start with the release notes:
> 
> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
> 
> And for this release, there are upgrade notes:
> 
> 	https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
> 
> This is an LTS and Stable update.  Highlights include:
> 
> - BSD Loader is now available.  This has its own wiki page, including how
> to stick with GRUB if you think you need to.
> 
> - Kayak Interactive Installer --> No more Caiman, no more F-keys &
> curses, and no-more hacking timezone names.  Also, one less repo to
> maintain for OmniOS. Kayak does it all now.
> 
> - Python is now 2.7. This means an IPS/pkg(5) update too. There's a
> subtle, but noteworthy, update to linked-image semantics ("pkg update
> -r") AND upgrading non-linked-image "ipkg" zones is a bit more difficult
> due to the transition (chicken & egg problem with ipkg brand "attach").
> 
> - Perl is now 5.24.1.
> 
> - USB 3.0 support.
> 
> With OmniTI withdrawing funding for OmniOS-as-product, this will be the
> last OmniTI-pushed "release" of OmniOS. It contains all of the most
> recent (as of May) illumos-gate changes, AND illumos-joyent LX brand
> changes.
> 
> This release broke the 6-month cadence, due to Loader, Python2.7, and the
> need for Kayak to take over ALL installation duties.  I'm sorry for it
> being 1-2 months late, but I wanted to make sure these changes were
> comfortably in place during the 021 bloody.
> 
> Because of the sheer volume of change in this release, I had to update
> many OmniOS wiki pages.  Here's a list of all of those I changed
> nontrivially due to r151022.  Please check them out to make sure I'm not
> missing anything...
> 
> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022
> 
> 	https://omnios.omniti.com/wiki.php/Installation
> 
> 	https://omnios.omniti.com/wiki.php/LXZones
> 
> 	https://omnios.omniti.com/wiki.php/Upgrade_to_r151022
> 
> 	https://omnios.omniti.com/wiki.php/NewLinkedImages
> 
> 	https://omnios.omniti.com/wiki.php/linked_images
> 
> 	https://omnios.omniti.com/wiki.php/KayakInteractive
> 
> 	https://omnios.omniti.com/wiki.php/BSDLoader
> 
> 	https://omnios.omniti.com/wiki.php/ReleaseCycle
> 
> 	https://omnios.omniti.com/wiki.php/Packaging
> 
> 	https://omnios.omniti.com/wiki.php/ReleaseNotes/
> 
> 	https://omnios.omniti.com/wiki.php/WikiStart
> 
> 	https://omnios.omniti.com/wiki.php/BuildInstructions
> 
> 	https://omnios.omniti.com/wiki.php/Maintainers
> 
> 	https://omnios.omniti.com/wiki.php/illumos-tools
> 
> 	https://omnios.omniti.com/wiki.php/buildctl
> 
> 	https://omnios.omniti.com/wiki.php/ReleaseMedia
> 
> I'll have more to say about my departure from OmniTI in a distinct
> e-mail.
> 
> Thanks, and happy upgrading!
> Dan
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From mir at miras.org  Mon May 15 21:20:47 2017
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 15 May 2017 23:20:47 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <20170515224610.08b5cc56@sleipner.datanom.net>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
	<20170515224610.08b5cc56@sleipner.datanom.net>
Message-ID: <20170515232047.1b2a5806@sleipner.datanom.net>

On Mon, 15 May 2017 22:46:10 +0200
Michael Rasmussen <mir at miras.org> wrote:

> On Mon, 15 May 2017 07:37:35 +0200
> Michael Rasmussen <mir at miras.org> wrote:
> 
> > To follow example I will commit myself to maintain the wiki and any
> > other web based infrastructure the project may need and choose to have.
> >   
> I have found out that Omniti holds the domain name omnios.org. Will
> Omniti consider handing over omnios.org to the community?
> 
BTW. speaking of wiki, online infrastructure etc.
Any thoughts or wishes?
What about hosting? (the important parts are: wiki and/or web site,
mail list and/or forum, repository, bug tracker)
This also means deciding which software to use for the above.

-- 
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:
Standing on head makes smile of frown, but rest of face also upside
down.
-------------- 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/20170515/0d993b93/attachment.bin>

From danmcd at omniti.com  Mon May 15 21:33:27 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 15 May 2017 17:33:27 -0400
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <1494883236.301343.977575080.0DBF9FF5@webmail.messagingengine.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<1494883236.301343.977575080.0DBF9FF5@webmail.messagingengine.com>
Message-ID: <D717D80F-B840-41AC-98A0-DCDCC46DAF96@omniti.com>


> On May 15, 2017, at 5:20 PM, Philip Cristiano <philipcristiano at philipcristiano.com> wrote:
> 
> It looks like https://omnios.omniti.com/wiki.php/Installation should be
> updated to point to the latest release. Currently it lists `r151020` as
> the current stable and `r151014` as the current LTS. 

Press "Reload" on your browser, I updated that page last week.  Also, there's now an r151022 AMI (Thank you Marissa)!

Dan


From tobi at oetiker.ch  Mon May 15 21:38:20 2017
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Mon, 15 May 2017 23:38:20 +0200 (CEST)
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <20170515232047.1b2a5806@sleipner.datanom.net>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
	<20170515224610.08b5cc56@sleipner.datanom.net>
	<20170515232047.1b2a5806@sleipner.datanom.net>
Message-ID: <641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch>

----- On May 15, 2017, at 11:20 PM, Michael Rasmussen mir at miras.org wrote:

> On Mon, 15 May 2017 22:46:10 +0200
> Michael Rasmussen <mir at miras.org> wrote:
> 
>> On Mon, 15 May 2017 07:37:35 +0200
>> Michael Rasmussen <mir at miras.org> wrote:
>> 
>> > To follow example I will commit myself to maintain the wiki and any
>> > other web based infrastructure the project may need and choose to have.
>> >   
>> I have found out that Omniti holds the domain name omnios.org. Will
>> Omniti consider handing over omnios.org to the community?
>> 
> BTW. speaking of wiki, online infrastructure etc.
> Any thoughts or wishes?
> What about hosting? (the important parts are: wiki and/or web site,
> mail list and/or forum, repository, bug tracker)
> This also means deciding which software to use for the above.

I would strongly urge to keep source, issues, pull requests, wiki on github.

it is perfectly integrated, works very well, and we have one less thing to worry about.

cheers
tobi

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

From mir at miras.org  Mon May 15 22:02:48 2017
From: mir at miras.org (Michael Rasmussen)
Date: Tue, 16 May 2017 00:02:48 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
	<20170515224610.08b5cc56@sleipner.datanom.net>
	<20170515232047.1b2a5806@sleipner.datanom.net>
	<641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch>
Message-ID: <20170516000248.626eec6e@sleipner.datanom.net>

On Mon, 15 May 2017 23:38:20 +0200 (CEST)
Tobias Oetiker <tobi at oetiker.ch> wrote:

> ----- On May 15, 2017, at 11:20 PM, Michael Rasmussen mir at miras.org wrote:
> 
> > On Mon, 15 May 2017 22:46:10 +0200
> > Michael Rasmussen <mir at miras.org> wrote:
> >   
> >> On Mon, 15 May 2017 07:37:35 +0200
> >> Michael Rasmussen <mir at miras.org> wrote:
> >>   
> >> > To follow example I will commit myself to maintain the wiki and any
> >> > other web based infrastructure the project may need and choose to have.
> >> >     
> >> I have found out that Omniti holds the domain name omnios.org. Will
> >> Omniti consider handing over omnios.org to the community?
> >>   
> > BTW. speaking of wiki, online infrastructure etc.
> > Any thoughts or wishes?
> > What about hosting? (the important parts are: wiki and/or web site,
> > mail list and/or forum, repository, bug tracker)
> > This also means deciding which software to use for the above.  
> 
> I would strongly urge to keep source, issues, pull requests, wiki on github.
> 
> it is perfectly integrated, works very well, and we have one less thing to worry about.
> 
Assuming we go with github this leaves mail list and/or forum and wiki
and/or web site to be decided. This tightly coupled with the domain
name so this will have to wait for this decision.

I have a VM on DigitalOcean doing nothing else than act as backup MX
which I could throw in as hosting for 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:
To find out a girl's faults, praise her to her girl friends.
		-- Benjamin Franklin
-------------- 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/20170516/dca77c69/attachment.bin>

From jesus at omniti.com  Tue May 16 00:09:46 2017
From: jesus at omniti.com (Theo Schlossnagle)
Date: Mon, 15 May 2017 20:09:46 -0400
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
	<20170515224610.08b5cc56@sleipner.datanom.net>
	<20170515232047.1b2a5806@sleipner.datanom.net>
	<641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch>
Message-ID: <CACLsApuJETeqXdiGjxPZUR6jUS1Avn2Ud821RqWttW0aMKrwnQ@mail.gmail.com>

Couldn't agree more about github; it's where community happens.
If an org is started to manage assets, and it can likely pay for hosting
out of its operating budget.

On May 15, 2017 5:47 PM, "Tobias Oetiker" <tobi at oetiker.ch> wrote:

> ----- On May 15, 2017, at 11:20 PM, Michael Rasmussen mir at miras.org wrote:
>
> > On Mon, 15 May 2017 22:46:10 +0200
> > Michael Rasmussen <mir at miras.org> wrote:
> >
> >> On Mon, 15 May 2017 07:37:35 +0200
> >> Michael Rasmussen <mir at miras.org> wrote:
> >>
> >> > To follow example I will commit myself to maintain the wiki and any
> >> > other web based infrastructure the project may need and choose to
> have.
> >> >
> >> I have found out that Omniti holds the domain name omnios.org. Will
> >> Omniti consider handing over omnios.org to the community?
> >>
> > BTW. speaking of wiki, online infrastructure etc.
> > Any thoughts or wishes?
> > What about hosting? (the important parts are: wiki and/or web site,
> > mail list and/or forum, repository, bug tracker)
> > This also means deciding which software to use for the above.
>
> I would strongly urge to keep source, issues, pull requests, wiki on
> github.
>
> it is perfectly integrated, works very well, and we have one less thing to
> worry about.
>
> cheers
> tobi
>
> --
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
> _______________________________________________
> 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/20170515/17081dea/attachment.html>

From danmcd at omniti.com  Tue May 16 01:11:50 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 15 May 2017 21:11:50 -0400
Subject: [OmniOS-discuss] First r151023 Bloody is now out
Message-ID: <4514F965-BC97-4855-A1B2-08C635F74300@omniti.com>

The repo server is updated now, and media will be available no later than 9:30pm US/Eastern (0130 GMT), for the first r151023 bloody.  This is just the version bump, and a post-r151022 merge or two from both illumos-gate and LX bits of illumos-joyent.

Visit the Installation page for media downloads and checksums:

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

And a current r151021 bloody user can just do:

	pkg update (-r)

to get updated to the new r151023 bloody.

Happy bloody updating!
Dan


From bdha at mirrorshades.net  Tue May 16 03:13:25 2017
From: bdha at mirrorshades.net (Bryan Allen)
Date: Mon, 15 May 2017 20:13:25 -0700
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <CACLsApuJETeqXdiGjxPZUR6jUS1Avn2Ud821RqWttW0aMKrwnQ@mail.gmail.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
	<20170515224610.08b5cc56@sleipner.datanom.net>
	<20170515232047.1b2a5806@sleipner.datanom.net>
	<641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch>
	<CACLsApuJETeqXdiGjxPZUR6jUS1Avn2Ud821RqWttW0aMKrwnQ@mail.gmail.com>
Message-ID: <1494904405.377808.977833632.39936897@webmail.messagingengine.com>

I'm happy to stick mailing lists under the same umbrella that the
illumos and SmartOS lists use.
Lists would be foo at lists.omnios.org, under Topicbox, with a searchable /
discoverable web archive like
https://illumos.topicbox.com[1]

Cheers.
-- 
bdha



On Mon, May 15, 2017, at 17:09, Theo Schlossnagle wrote:
> Couldn't agree more about github; it's where community happens.
> If an org is started to manage assets, and it can likely pay for
> hosting out of its operating budget.> 
> On May 15, 2017 5:47 PM, "Tobias Oetiker" <tobi at oetiker.ch> wrote:
>> ----- On May 15, 2017, at 11:20 PM, Michael Rasmussen
>> mir at miras.org wrote:>> 
>>  > On Mon, 15 May 2017 22:46:10 +0200
>>  > Michael Rasmussen <mir at miras.org> wrote:
>>  >
>>  >> On Mon, 15 May 2017 07:37:35 +0200
>>  >> Michael Rasmussen <mir at miras.org> wrote:
>>  >>
>>  >> > To follow example I will commit myself to maintain the wiki and
>>  >> > any>>  >> > other web based infrastructure the project may need and choose
>>  >> > to have.>>  >> >
>>  >> I have found out that Omniti holds the domain name omnios.org.
>>  >> Will>>  >> Omniti consider handing over omnios.org to the community?
>>  >>
>>  > BTW. speaking of wiki, online infrastructure etc.
>>  > Any thoughts or wishes?
>>  > What about hosting? (the important parts are: wiki and/or web
>>  > site,>>  > mail list and/or forum, repository, bug tracker)
>>  > This also means deciding which software to use for the above.
>> 
>>  I would strongly urge to keep source, issues, pull requests, wiki on
>>  github.>> 
>>  it is perfectly integrated, works very well, and we have one less
>>  thing to worry about.>> 
>>  cheers
>>  tobi
>> 
>>  --
>>  Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten,
>>  Switzerland>> www.oetiker.ch tobi at oetiker.ch +41 62 775 9902[2]
>>  _______________________________________________
>>  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


Links:

  1. https://illumos.topicbox.com/
  2. tel:%2B41%2062%20775%209902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170515/0695e7e0/attachment-0001.html>

From grzempek at gmail.com  Tue May 16 08:48:15 2017
From: grzempek at gmail.com (Krzysztof Grzempa)
Date: Tue, 16 May 2017 10:48:15 +0200
Subject: [OmniOS-discuss] To the OmniOS Community
In-Reply-To: <1494904405.377808.977833632.39936897@webmail.messagingengine.com>
References: <CAGoaUhORxw8ekHYsxLe1=VGqRU1Su8t7EBNSUnkiWAm5JRvZWw@mail.gmail.com>
	<CAED-Y_AbFKe9bUM=998nEZZ3M0Hchc1=GKkhT86FrzyJXVSXBA@mail.gmail.com>
	<20170515053722.7c509bca@landcroft.co.uk>
	<CACLsApvhxNqqRvSAzbs2upD5oheUeS2-tvNawjcPfg5YRNT=LQ@mail.gmail.com>
	<20170515073735.53cbce9d@sleipner.datanom.net>
	<20170515224610.08b5cc56@sleipner.datanom.net>
	<20170515232047.1b2a5806@sleipner.datanom.net>
	<641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch>
	<CACLsApuJETeqXdiGjxPZUR6jUS1Avn2Ud821RqWttW0aMKrwnQ@mail.gmail.com>
	<1494904405.377808.977833632.39936897@webmail.messagingengine.com>
Message-ID: <CAED-Y_BuBGtCjh25_DGpvb9NN6u28SHwzM9aewwYMgdL72S9wg@mail.gmail.com>

I agree, github is the best place where the community should be gathered
around.
Topicbox looks good also..

2017-05-16 5:13 GMT+02:00 Bryan Allen <bdha at mirrorshades.net>:

> I'm happy to stick mailing lists under the same umbrella that the illumos
> and SmartOS lists use.
>
> Lists would be foo at lists.omnios.org, under Topicbox, with a searchable /
> discoverable web archive like
>
> https://illumos.topicbox.com
>
> Cheers.
> --
> bdha
>
>
>
> On Mon, May 15, 2017, at 17:09, Theo Schlossnagle wrote:
>
> Couldn't agree more about github; it's where community happens.
> If an org is started to manage assets, and it can likely pay for hosting
> out of its operating budget.
>
> On May 15, 2017 5:47 PM, "Tobias Oetiker" <tobi at oetiker.ch> wrote:
>
> ----- On May 15, 2017, at 11:20 PM, Michael Rasmussen mir at miras.org wrote:
>
> > On Mon, 15 May 2017 22:46:10 +0200
> > Michael Rasmussen <mir at miras.org> wrote:
> >
> >> On Mon, 15 May 2017 07:37:35 +0200
> >> Michael Rasmussen <mir at miras.org> wrote:
> >>
> >> > To follow example I will commit myself to maintain the wiki and any
> >> > other web based infrastructure the project may need and choose to
> have.
> >> >
> >> I have found out that Omniti holds the domain name omnios.org. Will
> >> Omniti consider handing over omnios.org to the community?
> >>
> > BTW. speaking of wiki, online infrastructure etc.
> > Any thoughts or wishes?
> > What about hosting? (the important parts are: wiki and/or web site,
> > mail list and/or forum, repository, bug tracker)
> > This also means deciding which software to use for the above.
>
> I would strongly urge to keep source, issues, pull requests, wiki on
> github.
>
> it is perfectly integrated, works very well, and we have one less thing to
> worry about.
>
> cheers
> tobi
>
> --
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
> *_______________________________________________*
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170516/b34b246e/attachment.html>

From hasslerd at gmx.li  Tue May 16 12:58:05 2017
From: hasslerd at gmx.li (Dominik Hassler)
Date: Tue, 16 May 2017 14:58:05 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <6A4F3374-1241-4ED3-9451-255AE5BBDE57@me.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
	<0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>
	<6A4F3374-1241-4ED3-9451-255AE5BBDE57@me.com>
Message-ID: <e8d21f13-67d0-7a26-69f9-99d83f046540@gmx.li>

Toomas,

using a (forced) installboot on both rpool mirror devices did the trick. 
Loader is now being used.

However there is another problem. I can boot w/o problems from the first 
device. But booting fails from the second device w/ the following message:

Can't find /boot/zfsloader

illumos/x86 boot
Default: disk-1:/boot/zfsloader
boot:


Debug info below:

$ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d

same on both devices


$ sudo format -> select disk -> fdisk
              Total disk size is 36481 cylinders
              Cylinder size is 16065 (512 byte) blocks

                                                Cylinders
       Partition   Status    Type          Start   End   Length    %
       =========   ======    ============  =====   ===   ======   ===
           1       Active    Solaris2          1  36480    36480    100

same on both devices


$ sudo prtvtoc /dev/rdsk/c10t5000CCA04103E095d0s2
* /dev/rdsk/c10t5000CCA04103E095d0s2 partition map
*
* Dimensions:
*     512 bytes/sector
*      63 sectors/track
*     255 tracks/cylinder
*   16065 sectors/cylinder
*   36480 cylinders
*   36478 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*       First     Sector    Last
*       Sector     Count    Sector
*           0     16065     16064
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
        0      2    00      16065 586003005 586019069
        2      5    01          0 586051200 586051199
        8      1    01          0     16065     16064


same on both devices


boot: status
Default: disk-1:/boot/zfsloader
boot: statusdisk devices:
     disk0:   BIOS drive C ...
       disk0a: root
       disk0i: boot
     disk1:   BIOS drive D ...
       disk1s1: Solaris 2
         disk1s1a: root
         disk1s1i: boot
....
zfs devices:
   pool: rpool
bootfs: rpool/ROOT/omnios-r151022
config:

     NAME STATE
     rpool DEGRADED
       mirror DEGRADED
         c9t5000CCA04103E0B5d0s2 ONLINE
         c10t5000CCA04103E095d0s0 OFFLINE

illumos/x86 boot
Default: disk-1:/boot/zfsloader
boot:


Any hints on how to get the system boot from both rpool devices are 
highly appreciated.


Kind regards,
Dominik

On 05/15/2017 08:40 PM, Toomas Soome wrote:
>
>> On 15. mai 2017, at 21:06, Dan McDonald <danmcd at omniti.com> wrote:
>>
>>
>>> On May 15, 2017, at 12:49 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
>>>
>>> Hey,
>>>
>>> after the upgrade, the boot loader is still GRUB.
>>>
>>> I did the upgrade according to the upgrade notes. Rebooted once, did a:
>>>
>>> $ sudo beadm activate omnios-r151022
>>> WARNING: menu.lst file /rpool/boot/menu.lst does not exist,
>>>        generating a new menu.lst file
>>> Activated successfully
>>>
>>> checked for a /etc/default/be file. there is none. Still the boot loader is GRUB instead of loader.
>>
>> Are you on a mirrored root pool?  It's possible the libbe code that installs loader doesn't do it to all disks in a mirrored pool...
>>
>> Worst-case scenario is to explicitly install it:
>>
>> 	foreach (drive)
>> 		installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/<drive>
>>
>> Dan
>>
>
> The problem you have is that beadm activate does not enforce MBR update in case of MBR+VTOC partitioning; you need to either run bootadm install-bootloader -Mfv or installboot -mv.
>
> Note that installboot and bootadm install-bootloader have slightly different flags; -v is good to have there, so you will see if the MBR was updated or not.
>
> The beadm activate and bootadm use the same mechanism to update the bootblocks on all pool member disks, bootadm does have extra flag to allow MBR update. installboot does only update specified disk.
>
> rgds,
> toomas
>

From jesus at omniti.com  Tue May 16 13:22:11 2017
From: jesus at omniti.com (Theo Schlossnagle)
Date: Tue, 16 May 2017 09:22:11 -0400
Subject: [OmniOS-discuss] Legal next steps
Message-ID: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>

My experience here is limited to the United States for approaching these
problems.  I don't mean to indicate that it is the right solution, but I
can only speak of what I know.

A legal entity must hold the assets. That can be a person, or a trust, or
an corporation or a community*, etc.  Community here is defined in such a
way by the IRS that I don't believe we would ever quality (and it's never
worth arguing). Given the history of "things" I would steer away from an
individual and I feel that given unknown nature of assets required to
operate and our weak starting point that a trust is likely not
self-sustaining.

What I would suggest is us setting up an corporation here in the US,
setting a purpose and a missions statement (that includes education and
science as we do those and they are eligible for non-profit status), elect
5-7 board members (who will be legally responsible for the entity) come up
with a small operating budget (< $10k USD) and apply for non-profit
(501(3)c).  This process would take a few hundreds of dollars.

Then we request that OmniTI donate the appropriate assets related to
OmniOS.  This organization can take donations (from basically anywhere) and
apply them to operational costs to forward its mission.  There is a chance
that this organization could be denied non-profit status as the IRS is
(sadly) a bit odd when it comes to approving that for initiatives for the
public good if their around open source software.  I don't see that as a
specific risk, it only means that donations made are not tax-deductible.

The gating factors here is can we get 5-7 people willing to participate as
legally responsible board members (I am not a lawyer, but the risk is very
lower here as there is very little money involved).

Back to my first point, if there is a better avenue outside the United
States for this, I would love to be educated about it.

Best regards,

Theo

-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170516/bdab8207/attachment.html>

From doug at will.to  Tue May 16 13:47:59 2017
From: doug at will.to (Doug Hughes)
Date: Tue, 16 May 2017 09:47:59 -0400
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
Message-ID: <fc66a15d-cc54-8aa0-dea4-c20a0b0f114c@will.to>

Having done this once before, if done in the USA, NJ and DE are somewhat
preferred states for ease of such 501c3 incorporation. lowest fees,
smallest hurdles, etc.

If NJ.US is acceptable/chosen I'm very proximate to Trenton and could
facilitate any in-person matters.


On 5/16/2017 9:22 AM, Theo Schlossnagle wrote:
> My experience here is limited to the United States for approaching
> these problems.  I don't mean to indicate that it is the right
> solution, but I can only speak of what I know.
>
> A legal entity must hold the assets. That can be a person, or a trust,
> or an corporation or a community*, etc.  Community here is defined in
> such a way by the IRS that I don't believe we would ever quality (and
> it's never worth arguing). Given the history of "things" I would steer
> away from an individual and I feel that given unknown nature of assets
> required to operate and our weak starting point that a trust is likely
> not self-sustaining.
>
> What I would suggest is us setting up an corporation here in the US,
> setting a purpose and a missions statement (that includes education
> and science as we do those and they are eligible for non-profit
> status), elect 5-7 board members (who will be legally responsible for
> the entity) come up with a small operating budget (< $10k USD) and
> apply for non-profit (501(3)c).  This process would take a few
> hundreds of dollars.
>
> Then we request that OmniTI donate the appropriate assets related to
> OmniOS.  This organization can take donations (from basically
> anywhere) and apply them to operational costs to forward its mission. 
> There is a chance that this organization could be denied non-profit
> status as the IRS is (sadly) a bit odd when it comes to approving that
> for initiatives for the public good if their around open source
> software.  I don't see that as a specific risk, it only means that
> donations made are not tax-deductible.
>
> The gating factors here is can we get 5-7 people willing to
> participate as legally responsible board members (I am not a lawyer,
> but the risk is very lower here as there is very little money involved).
>
> Back to my first point, if there is a better avenue outside the United
> States for this, I would love to be educated about it.
>
> Best regards,
>
> Theo
>
> -- 
>
> Theo Schlossnagle
>
> http://omniti.com/is/theo-schlossnagle
>
>
>
> _______________________________________________
> 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/20170516/d94cdb84/attachment-0001.html>

From hasslerd at gmx.li  Tue May 16 13:53:05 2017
From: hasslerd at gmx.li (Dominik Hassler)
Date: Tue, 16 May 2017 15:53:05 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <C0D77E70-64F6-4B35-99C1-E087A7E4C78B@me.com>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
	<0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>
	<6A4F3374-1241-4ED3-9451-255AE5BBDE57@me.com>
	<e8d21f13-67d0-7a26-69f9-99d83f046540@gmx.li>
	<C0D77E70-64F6-4B35-99C1-E087A7E4C78B@me.com>
Message-ID: <5221319a-5b73-7a5b-d030-2afef240d97f@gmx.li>

Ok, I did an installboot -mFf on both disks again (-v is not available 
for installboot)

$ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot 
/dev/rdsk/c9t5000CCA04103E0B5d0s0
bootblock written for /dev/rdsk/c9t5000CCA04103E0B5d0s0, 223 sectors 
starting at 1024 (abs 33154)
stage1 written to slice 1 sector 0 (abs 16065)
stage1 written to master boot sector

$ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot 
/dev/rdsk/c10t5000CCA04103E095d0s0
bootblock written for /dev/rdsk/c10t5000CCA04103E095d0s0, 223 sectors 
starting at 1024 (abs 33154)
stage1 written to slice 1 sector 0 (abs 16065)
stage1 written to master boot sector

checked the version:

$ installboot -i /boot/gptzfsboot
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d

and compared it to the version of both disks:

$ sudo installboot -i /dev/rdsk/c9t5000CCA04103E0B5d0s0
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d

$ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d


everything matches, but still the system boots only from one disk and 
not the other. Since it is not the latest version you mentioned I'll 
just wait until it is updated I guess. I can at least boot from one disk 
so I am not too worried about it at the moment. Still I would prefer to 
be able to boot from both.

On 05/16/2017 03:18 PM, Toomas Soome wrote:
>
>> On 16. mai 2017, at 15:58, Dominik Hassler <hasslerd at gmx.li> wrote:
>>
>> Toomas,
>>
>> using a (forced) installboot on both rpool mirror devices did the trick. Loader is now being used.
>>
>> However there is another problem. I can boot w/o problems from the first device. But booting fails from the second device w/ the following message:
>>
>> Can't find /boot/zfsloader
>>
>> illumos/x86 boot
>> Default: disk-1:/boot/zfsloader
>
> Somehow the MBR on second disk is not properly updated and I think it has wrong size recorded for stage2.
>
> The initial installboot was implemented based on installgrub source and we record the LBA with gptzfsboot start sector, and size (in sectors) into MBR.
>
> Now the copy of the MBR (the /boot/pmbr file) is also installed into partition start sector 0), and when the beadm activate is run, the boot blocks are updates, but with same logic, that with MBR+VTOC case, the MBR itself is not updated (to keep multi boot setups safe), and only partition sector 0 and stage 2 are updated. The oversight is that the MBR is loading stage2 directly, and if the gptzfsboot size was changed, the result is that not the entire gptzfsboot is read into the memory and resulting with just the output as you can see.
>
> later we did create the fix for installboot - the fixed installboot will only record the location and size (1 sector) of the partition boot recors (partition relative sector 0), and after that the MBR code will read in the partition block, the partition block will read the stage2, and so the MBR+VTOC case is not an issue any more.
>
> to fix this, run installboot -mFfv against that second disk to ensure the MBR block is properly updated - note the -v again, so you can confirm the MBR and partition block and stage2 are all updated.
>
> With installgrub we actually have the same issue, except, the grub stage2 size virtually did not change and thats why the problem was never revealed.
>
> note, if your installboot command does allow to read the version from /boot/gptzfsboot like that:
>
> $ installboot -i /boot/gptzfsboot
> Extended version string: 1.1-2017.5.6.2
> MD5 hash: 2907581de9ca6bd4d2c12695a32cb749
>
> then it has the bug fixed, and after installing MBR with such binary, the MBR is always reading the sector 0 from partition start, and the future updates are ok.
>
> also note that MBR is always updated with GPT, and hence there the issue does not appear (which why it took some time to notice it - my own test systems were all using GPT:)
>
> rgds,
> toomas
>
>> boot:
>>
>>
>> Debug info below:
>>
>> $ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
>> Extended version string: 1.1-2017.4.23.2
>> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>>
>> same on both devices
>>
>>
>> $ sudo format -> select disk -> fdisk
>>             Total disk size is 36481 cylinders
>>             Cylinder size is 16065 (512 byte) blocks
>>
>>                                               Cylinders
>>      Partition   Status    Type          Start   End   Length    %
>>      =========   ======    ============  =====   ===   ======   ===
>>          1       Active    Solaris2          1  36480    36480    100
>>
>> same on both devices
>>
>>
>> $ sudo prtvtoc /dev/rdsk/c10t5000CCA04103E095d0s2
>> * /dev/rdsk/c10t5000CCA04103E095d0s2 partition map
>> *
>> * Dimensions:
>> *     512 bytes/sector
>> *      63 sectors/track
>> *     255 tracks/cylinder
>> *   16065 sectors/cylinder
>> *   36480 cylinders
>> *   36478 accessible cylinders
>> *
>> * Flags:
>> *   1: unmountable
>> *  10: read-only
>> *
>> * Unallocated space:
>> *       First     Sector    Last
>> *       Sector     Count    Sector
>> *           0     16065     16064
>> *
>> *                          First     Sector    Last
>> * Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
>>       0      2    00      16065 586003005 586019069
>>       2      5    01          0 586051200 586051199
>>       8      1    01          0     16065     16064
>>
>>
>> same on both devices
>>
>>
>> boot: status
>> Default: disk-1:/boot/zfsloader
>> boot: statusdisk devices:
>>    disk0:   BIOS drive C ...
>>      disk0a: root
>>      disk0i: boot
>>    disk1:   BIOS drive D ...
>>      disk1s1: Solaris 2
>>        disk1s1a: root
>>        disk1s1i: boot
>> ....
>> zfs devices:
>>  pool: rpool
>> bootfs: rpool/ROOT/omnios-r151022
>> config:
>>
>>    NAME STATE
>>    rpool DEGRADED
>>      mirror DEGRADED
>>        c9t5000CCA04103E0B5d0s2 ONLINE
>>        c10t5000CCA04103E095d0s0 OFFLINE
>>
>> illumos/x86 boot
>> Default: disk-1:/boot/zfsloader
>> boot:
>>
>>
>> Any hints on how to get the system boot from both rpool devices are highly appreciated.
>>
>>
>> Kind regards,
>> Dominik
>>
>> On 05/15/2017 08:40 PM, Toomas Soome wrote:
>>>
>>>> On 15. mai 2017, at 21:06, Dan McDonald <danmcd at omniti.com> wrote:
>>>>
>>>>
>>>>> On May 15, 2017, at 12:49 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
>>>>>
>>>>> Hey,
>>>>>
>>>>> after the upgrade, the boot loader is still GRUB.
>>>>>
>>>>> I did the upgrade according to the upgrade notes. Rebooted once, did a:
>>>>>
>>>>> $ sudo beadm activate omnios-r151022
>>>>> WARNING: menu.lst file /rpool/boot/menu.lst does not exist,
>>>>>       generating a new menu.lst file
>>>>> Activated successfully
>>>>>
>>>>> checked for a /etc/default/be file. there is none. Still the boot loader is GRUB instead of loader.
>>>>
>>>> Are you on a mirrored root pool?  It's possible the libbe code that installs loader doesn't do it to all disks in a mirrored pool...
>>>>
>>>> Worst-case scenario is to explicitly install it:
>>>>
>>>> 	foreach (drive)
>>>> 		installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/<drive>
>>>>
>>>> Dan
>>>>
>>>
>>> The problem you have is that beadm activate does not enforce MBR update in case of MBR+VTOC partitioning; you need to either run bootadm install-bootloader -Mfv or installboot -mv.
>>>
>>> Note that installboot and bootadm install-bootloader have slightly different flags; -v is good to have there, so you will see if the MBR was updated or not.
>>>
>>> The beadm activate and bootadm use the same mechanism to update the bootblocks on all pool member disks, bootadm does have extra flag to allow MBR update. installboot does only update specified disk.
>>>
>>> rgds,
>>> toomas
>>>
>

From mir at miras.org  Tue May 16 14:17:24 2017
From: mir at miras.org (Michael Rasmussen)
Date: Tue, 16 May 2017 16:17:24 +0200
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
Message-ID: <20170516161724.4b73167b@sleipner.datanom.net>

On Tue, 16 May 2017 09:22:11 -0400
Theo Schlossnagle <jesus at omniti.com> wrote:

> 
> Back to my first point, if there is a better avenue outside the United
> States for this, I would love to be educated about it.
> 
You could get inspired by the FreeBSD foundation:
https://www.freebsdfoundation.org/wp-content/uploads/2015/12/FoundationBylaws.pdf

The FreeBSD foundation is US based in Colorado.

-- 
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:
	"What terrible way to die."
	"There are no good ways."
		-- Sulu and Kirk, "That Which Survives", stardate
unknown
-------------- 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/20170516/d571bc69/attachment.bin>

From mir at miras.org  Tue May 16 14:19:23 2017
From: mir at miras.org (Michael Rasmussen)
Date: Tue, 16 May 2017 16:19:23 +0200
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
Message-ID: <20170516161923.6a80f99f@sleipner.datanom.net>

On Tue, 16 May 2017 09:22:11 -0400
Theo Schlossnagle <jesus at omniti.com> wrote:

> What I would suggest is us setting up an corporation here in the US,
> setting a purpose and a missions statement (that includes education and
> science as we do those and they are eligible for non-profit status), elect
> 5-7 board members (who will be legally responsible for the entity) come up
> with a small operating budget (< $10k USD) and apply for non-profit
> (501(3)c).  This process would take a few hundreds of dollars.
> 
The letter stating FreeBSD foundation is free of federal income tax:
https://www.freebsdfoundation.org/wp-content/uploads/2015/12/DeterminationLetter.pdf

-- 
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:
	"What terrible way to die."
	"There are no good ways."
		-- Sulu and Kirk, "That Which Survives", stardate
unknown
-------------- 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/20170516/c8b285cf/attachment.bin>

From tobi at oetiker.ch  Tue May 16 14:19:40 2017
From: tobi at oetiker.ch (Tobi Oetiker)
Date: Tue, 16 May 2017 16:19:40 +0200
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <fc66a15d-cc54-8aa0-dea4-c20a0b0f114c@will.to>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
	<fc66a15d-cc54-8aa0-dea4-c20a0b0f114c@will.to>
Message-ID: <680C52D7-4157-4F9E-AB69-375380CF4E7C@oetiker.ch>

In switzerland, any three people
can found an association by stating that they do so and creating a bylaws document. no fees. no official registration necessary. only if substantial money is handled or if there is profit, the association has to talk to the swiss irs.

https://en.wikipedia.org/wiki/Swiss_association

I'll be glad to help :)

cheers
tobi

Tobias Oetiker
tobi at oetiker.ch
062 775 9902

> On 16 May 2017, at 15:47, Doug Hughes <doug at will.to> wrote:
> 
> Having done this once before, if done in the USA, NJ and DE are somewhat preferred states for ease of such 501c3 incorporation. lowest fees, smallest hurdles, etc.
> 
> If NJ.US is acceptable/chosen I'm very proximate to Trenton and could facilitate any in-person matters.
> 
>> On 5/16/2017 9:22 AM, Theo Schlossnagle wrote:
>> My experience here is limited to the United States for approaching these problems.  I don't mean to indicate that it is the right solution, but I can only speak of what I know.
>> 
>> A legal entity must hold the assets. That can be a person, or a trust, or an corporation or a community*, etc.  Community here is defined in such a way by the IRS that I don't believe we would ever quality (and it's never worth arguing). Given the history of "things" I would steer away from an individual and I feel that given unknown nature of assets required to operate and our weak starting point that a trust is likely not self-sustaining.
>> 
>> What I would suggest is us setting up an corporation here in the US, setting a purpose and a missions statement (that includes education and science as we do those and they are eligible for non-profit status), elect 5-7 board members (who will be legally responsible for the entity) come up with a small operating budget (< $10k USD) and apply for non-profit (501(3)c).  This process would take a few hundreds of dollars.
>> 
>> Then we request that OmniTI donate the appropriate assets related to OmniOS.  This organization can take donations (from basically anywhere) and apply them to operational costs to forward its mission.  There is a chance that this organization could be denied non-profit status as the IRS is (sadly) a bit odd when it comes to approving that for initiatives for the public good if their around open source software.  I don't see that as a specific risk, it only means that donations made are not tax-deductible.
>> 
>> The gating factors here is can we get 5-7 people willing to participate as legally responsible board members (I am             not a lawyer, but the risk is very lower here as there is very little money involved).
>> 
>> Back to my first point, if there is a better avenue outside the United States for this, I would love to be educated about it.
>> 
>> Best regards,
>> 
>> Theo
>> 
>> -- 
>> Theo Schlossnagle
>> 
>> http://omniti.com/is/theo-schlossnagle
>> 
>> 
>> 
>> _______________________________________________
>> 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/20170516/731c72ef/attachment-0001.html>

From groups at tierarzt-mueller.de  Tue May 16 14:53:13 2017
From: groups at tierarzt-mueller.de (Alexander Lesle)
Date: Tue, 16 May 2017 16:53:13 +0200
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <680C52D7-4157-4F9E-AB69-375380CF4E7C@oetiker.ch>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
	<fc66a15d-cc54-8aa0-dea4-c20a0b0f114c@will.to>
	<680C52D7-4157-4F9E-AB69-375380CF4E7C@oetiker.ch>
Message-ID: <128752415.20170516165313@tierarzt-mueller.de>

Hello,

Switzerland or EU sounds good.

No NSA or U.S. laws pressure to code a backdoor for them.

On 16. May 2017 at 16:19 <Tobi Oetiker> wrote
in mid:680C52D7-4157-4F9E-AB69-375380CF4E7C at oetiker.ch :
> In switzerland, any three people
> can found an association by stating that they do so and
> creating a bylaws document. no fees. no official registration
> necessary. only if substantial money is handled or if there is
> profit, the association has to talk to the swiss irs.


> https://en.wikipedia.org/wiki/Swiss_association


> I'll be glad to help :)


> cheers
> tobi


> Tobias Oetiker
> tobi at oetiker.ch
> 062 775 9902

> On 16 May 2017, at 15:47, Doug Hughes <doug at will.to> wrote:


>      
> Having done this once before, if done in the USA, NJ and DE
> are       somewhat preferred states for ease of such 501c3
> incorporation.       lowest fees, smallest hurdles, etc.
> If NJ.US is acceptable/chosen I'm very proximate to Trenton
> and       could facilitate any in-person matters.


> On 5/16/2017 9:22 AM, Theo Schlossnagle       wrote:
> My experience here is limited to the United States         for
> approaching these problems.  I don't mean to indicate that     
> it is the right solution, but I can only speak of what I know.  

>     
> A legal entity must hold the assets. That can be a person,    
> or a trust, or an corporation or a community*, etc.  Community 
> here is defined in such a way by the IRS that I don't believe  
> we would ever quality (and it's never worth arguing). Given    
> the history of "things" I would steer away from an individual  
> and I feel that given unknown nature of assets required to     
> operate and our weak starting point that a trust is likely not  self-sustaining.
>   

>     
> What I would suggest is us setting up an corporation here     
> in the US, setting a purpose and a missions statement (that    
> includes education and science as we do those and they are     
> eligible for non-profit status), elect 5-7 board members       
> (who will be legally responsible for the entity) come up       
> with a small operating budget (< $10k USD) and apply for       
> non-profit (501(3)c).  This process would take a few            hundreds of dollars.

>     
> Then we request that OmniTI donate the appropriate assets     
> related to OmniOS.  This organization can take donations       
> (from basically anywhere) and apply them to operational        
> costs to forward its mission.  There is a chance that this     
> organization could be denied non-profit status as the IRS is   
> (sadly) a bit odd when it comes to approving that for          
> initiatives for the public good if their around open source    
> software.  I don't see that as a specific risk, it only        
> means that donations made are not tax-deductible.  

>     
> The gating factors here is can we get 5-7 people willing      
> to participate as legally responsible board members (I am      
> not a lawyer, but the risk is very lower here as there is       very little money involved).

>     
> Back to my first point, if there is a better avenue           
> outside the United States for this, I would love to be          educated about it.

>     
> Best regards,  

>     
> Theo  

>              -- 
>   
>   
> Theo Schlossnagle
>   
> http://omniti.com/is/theo-schlossnagle
>       


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

>  

-- 
Mit freundlichem Gruss
Alexander
mailto:groups at tierarzt-mueller.de
eMail geschrieben mit: The Bat! 7.4.16
unter Windows 10 Pro x64 Build 14393



From vab at bb-c.de  Tue May 16 15:20:34 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Tue, 16 May 2017 17:20:34 +0200
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <128752415.20170516165313@tierarzt-mueller.de>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
	<fc66a15d-cc54-8aa0-dea4-c20a0b0f114c@will.to>
	<680C52D7-4157-4F9E-AB69-375380CF4E7C@oetiker.ch>
	<128752415.20170516165313@tierarzt-mueller.de>
Message-ID: <22811.6338.627688.902994@shelob.bb-c.de>

> Switzerland or EU sounds good.
>
> No NSA or U.S. laws pressure to code a backdoor for them.
>
> On 16. May 2017 at 16:19 <Tobi Oetiker> wrote
> in mid:680C52D7-4157-4F9E-AB69-375380CF4E7C at oetiker.ch :
> > In switzerland, any three people
> > can found an association by stating that they do so and
> > creating a bylaws document. no fees. no official registration
> > necessary. only if substantial money is handled or if there is
> > profit, the association has to talk to the swiss irs.

This does indeed sound good.


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

"When logic and proportion have fallen sloppy dead"

From danmcd at omniti.com  Tue May 16 15:27:58 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 16 May 2017 11:27:58 -0400
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <128752415.20170516165313@tierarzt-mueller.de>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
	<fc66a15d-cc54-8aa0-dea4-c20a0b0f114c@will.to>
	<680C52D7-4157-4F9E-AB69-375380CF4E7C@oetiker.ch>
	<128752415.20170516165313@tierarzt-mueller.de>
Message-ID: <1731185F-79B3-4B1A-B5A4-79F025F919B0@omniti.com>


> On May 16, 2017, at 10:53 AM, Alexander Lesle <groups at tierarzt-mueller.de> wrote:
> 
> No NSA or U.S. laws pressure to code a backdoor for them.

As someone who worked in the shadow of such a threat for many years (Building IPsec both at NRL, and pre-OpenSolaris Sun), the open-source nature of OmniOS mitigates (at least partially) explicit pressure as a concern.  Open-source code has a strong (albeit not fully court-tested) 1st amendment defense -- see here:

	https://en.wikipedia.org/wiki/Bernstein_v._United_States

There may be good reasons to have an outside-the-US foundation, but backdoor concerns is not one of them.

Dan

p.s. I have good 90s-crypto-wars stories.


From hasslerd at gmx.li  Tue May 16 15:50:04 2017
From: hasslerd at gmx.li (Dominik Hassler)
Date: Tue, 16 May 2017 17:50:04 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <5221319a-5b73-7a5b-d030-2afef240d97f@gmx.li>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
	<0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>
	<6A4F3374-1241-4ED3-9451-255AE5BBDE57@me.com>
	<e8d21f13-67d0-7a26-69f9-99d83f046540@gmx.li>
	<C0D77E70-64F6-4B35-99C1-E087A7E4C78B@me.com>
	<5221319a-5b73-7a5b-d030-2afef240d97f@gmx.li>
Message-ID: <15671b7a-61fe-1e7c-44e4-6645c6031ce9@gmx.li>

Addendum:

Just upgraded another system and there booting from both rpool devices 
works.

This system has a different mainboard, so I wonder if it is BIOS related 
and a BIOS upgrade on system 1 could help?

Another difference:

System 1 has been set-up in summer 2013, so it went r06 -> r08 -> ... -> r22
System 2 has been set-up in end of 2014, so it went r12 -> R14 -> ... -> r22

Not sure if that might have an impact, when OmniOS was set-up first 
(e.g. how partitions are created by installer)

On 05/16/2017 03:53 PM, Dominik Hassler wrote:
> Ok, I did an installboot -mFf on both disks again (-v is not available
> for installboot)
>
> $ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot
> /dev/rdsk/c9t5000CCA04103E0B5d0s0
> bootblock written for /dev/rdsk/c9t5000CCA04103E0B5d0s0, 223 sectors
> starting at 1024 (abs 33154)
> stage1 written to slice 1 sector 0 (abs 16065)
> stage1 written to master boot sector
>
> $ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot
> /dev/rdsk/c10t5000CCA04103E095d0s0
> bootblock written for /dev/rdsk/c10t5000CCA04103E095d0s0, 223 sectors
> starting at 1024 (abs 33154)
> stage1 written to slice 1 sector 0 (abs 16065)
> stage1 written to master boot sector
>
> checked the version:
>
> $ installboot -i /boot/gptzfsboot
> Extended version string: 1.1-2017.4.23.2
> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>
> and compared it to the version of both disks:
>
> $ sudo installboot -i /dev/rdsk/c9t5000CCA04103E0B5d0s0
> Extended version string: 1.1-2017.4.23.2
> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>
> $ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
> Extended version string: 1.1-2017.4.23.2
> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>
>
> everything matches, but still the system boots only from one disk and
> not the other. Since it is not the latest version you mentioned I'll
> just wait until it is updated I guess. I can at least boot from one disk
> so I am not too worried about it at the moment. Still I would prefer to
> be able to boot from both.
>
> On 05/16/2017 03:18 PM, Toomas Soome wrote:
>>
>>> On 16. mai 2017, at 15:58, Dominik Hassler <hasslerd at gmx.li> wrote:
>>>
>>> Toomas,
>>>
>>> using a (forced) installboot on both rpool mirror devices did the
>>> trick. Loader is now being used.
>>>
>>> However there is another problem. I can boot w/o problems from the
>>> first device. But booting fails from the second device w/ the
>>> following message:
>>>
>>> Can't find /boot/zfsloader
>>>
>>> illumos/x86 boot
>>> Default: disk-1:/boot/zfsloader
>>
>> Somehow the MBR on second disk is not properly updated and I think it
>> has wrong size recorded for stage2.
>>
>> The initial installboot was implemented based on installgrub source
>> and we record the LBA with gptzfsboot start sector, and size (in
>> sectors) into MBR.
>>
>> Now the copy of the MBR (the /boot/pmbr file) is also installed into
>> partition start sector 0), and when the beadm activate is run, the
>> boot blocks are updates, but with same logic, that with MBR+VTOC case,
>> the MBR itself is not updated (to keep multi boot setups safe), and
>> only partition sector 0 and stage 2 are updated. The oversight is that
>> the MBR is loading stage2 directly, and if the gptzfsboot size was
>> changed, the result is that not the entire gptzfsboot is read into the
>> memory and resulting with just the output as you can see.
>>
>> later we did create the fix for installboot - the fixed installboot
>> will only record the location and size (1 sector) of the partition
>> boot recors (partition relative sector 0), and after that the MBR code
>> will read in the partition block, the partition block will read the
>> stage2, and so the MBR+VTOC case is not an issue any more.
>>
>> to fix this, run installboot -mFfv against that second disk to ensure
>> the MBR block is properly updated - note the -v again, so you can
>> confirm the MBR and partition block and stage2 are all updated.
>>
>> With installgrub we actually have the same issue, except, the grub
>> stage2 size virtually did not change and thats why the problem was
>> never revealed.
>>
>> note, if your installboot command does allow to read the version from
>> /boot/gptzfsboot like that:
>>
>> $ installboot -i /boot/gptzfsboot
>> Extended version string: 1.1-2017.5.6.2
>> MD5 hash: 2907581de9ca6bd4d2c12695a32cb749
>>
>> then it has the bug fixed, and after installing MBR with such binary,
>> the MBR is always reading the sector 0 from partition start, and the
>> future updates are ok.
>>
>> also note that MBR is always updated with GPT, and hence there the
>> issue does not appear (which why it took some time to notice it - my
>> own test systems were all using GPT:)
>>
>> rgds,
>> toomas
>>
>>> boot:
>>>
>>>
>>> Debug info below:
>>>
>>> $ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
>>> Extended version string: 1.1-2017.4.23.2
>>> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>>>
>>> same on both devices
>>>
>>>
>>> $ sudo format -> select disk -> fdisk
>>>             Total disk size is 36481 cylinders
>>>             Cylinder size is 16065 (512 byte) blocks
>>>
>>>                                               Cylinders
>>>      Partition   Status    Type          Start   End   Length    %
>>>      =========   ======    ============  =====   ===   ======   ===
>>>          1       Active    Solaris2          1  36480    36480    100
>>>
>>> same on both devices
>>>
>>>
>>> $ sudo prtvtoc /dev/rdsk/c10t5000CCA04103E095d0s2
>>> * /dev/rdsk/c10t5000CCA04103E095d0s2 partition map
>>> *
>>> * Dimensions:
>>> *     512 bytes/sector
>>> *      63 sectors/track
>>> *     255 tracks/cylinder
>>> *   16065 sectors/cylinder
>>> *   36480 cylinders
>>> *   36478 accessible cylinders
>>> *
>>> * Flags:
>>> *   1: unmountable
>>> *  10: read-only
>>> *
>>> * Unallocated space:
>>> *       First     Sector    Last
>>> *       Sector     Count    Sector
>>> *           0     16065     16064
>>> *
>>> *                          First     Sector    Last
>>> * Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
>>>       0      2    00      16065 586003005 586019069
>>>       2      5    01          0 586051200 586051199
>>>       8      1    01          0     16065     16064
>>>
>>>
>>> same on both devices
>>>
>>>
>>> boot: status
>>> Default: disk-1:/boot/zfsloader
>>> boot: statusdisk devices:
>>>    disk0:   BIOS drive C ...
>>>      disk0a: root
>>>      disk0i: boot
>>>    disk1:   BIOS drive D ...
>>>      disk1s1: Solaris 2
>>>        disk1s1a: root
>>>        disk1s1i: boot
>>> ....
>>> zfs devices:
>>>  pool: rpool
>>> bootfs: rpool/ROOT/omnios-r151022
>>> config:
>>>
>>>    NAME STATE
>>>    rpool DEGRADED
>>>      mirror DEGRADED
>>>        c9t5000CCA04103E0B5d0s2 ONLINE
>>>        c10t5000CCA04103E095d0s0 OFFLINE
>>>
>>> illumos/x86 boot
>>> Default: disk-1:/boot/zfsloader
>>> boot:
>>>
>>>
>>> Any hints on how to get the system boot from both rpool devices are
>>> highly appreciated.
>>>
>>>
>>> Kind regards,
>>> Dominik
>>>
>>> On 05/15/2017 08:40 PM, Toomas Soome wrote:
>>>>
>>>>> On 15. mai 2017, at 21:06, Dan McDonald <danmcd at omniti.com> wrote:
>>>>>
>>>>>
>>>>>> On May 15, 2017, at 12:49 PM, Dominik Hassler <hasslerd at gmx.li>
>>>>>> wrote:
>>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> after the upgrade, the boot loader is still GRUB.
>>>>>>
>>>>>> I did the upgrade according to the upgrade notes. Rebooted once,
>>>>>> did a:
>>>>>>
>>>>>> $ sudo beadm activate omnios-r151022
>>>>>> WARNING: menu.lst file /rpool/boot/menu.lst does not exist,
>>>>>>       generating a new menu.lst file
>>>>>> Activated successfully
>>>>>>
>>>>>> checked for a /etc/default/be file. there is none. Still the boot
>>>>>> loader is GRUB instead of loader.
>>>>>
>>>>> Are you on a mirrored root pool?  It's possible the libbe code that
>>>>> installs loader doesn't do it to all disks in a mirrored pool...
>>>>>
>>>>> Worst-case scenario is to explicitly install it:
>>>>>
>>>>>     foreach (drive)
>>>>>         installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/<drive>
>>>>>
>>>>> Dan
>>>>>
>>>>
>>>> The problem you have is that beadm activate does not enforce MBR
>>>> update in case of MBR+VTOC partitioning; you need to either run
>>>> bootadm install-bootloader -Mfv or installboot -mv.
>>>>
>>>> Note that installboot and bootadm install-bootloader have slightly
>>>> different flags; -v is good to have there, so you will see if the
>>>> MBR was updated or not.
>>>>
>>>> The beadm activate and bootadm use the same mechanism to update the
>>>> bootblocks on all pool member disks, bootadm does have extra flag to
>>>> allow MBR update. installboot does only update specified disk.
>>>>
>>>> rgds,
>>>> toomas
>>>>
>>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From tobi at oetiker.ch  Tue May 16 16:04:00 2017
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Tue, 16 May 2017 18:04:00 +0200 (CEST)
Subject: [OmniOS-discuss] how about https://github.com/omniosorg
Message-ID: <6169854.203395.1494950640248.JavaMail.zimbra@oetiker.ch>

since omnios is already taken .... how about 

https://github.com/omniosorg 

cheers 
tobi 


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

From vab at bb-c.de  Tue May 16 17:07:42 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Tue, 16 May 2017 19:07:42 +0200
Subject: [OmniOS-discuss] how about https://github.com/omniosorg
In-Reply-To: <6169854.203395.1494950640248.JavaMail.zimbra@oetiker.ch>
References: <6169854.203395.1494950640248.JavaMail.zimbra@oetiker.ch>
Message-ID: <22811.12766.292602.481829@shelob.bb-c.de>

> since omnios is already taken .... how about
> 
> https://github.com/omniosorg

Go for it!  :-)


Viele Gr??e -- 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 lkateley at kateley.com  Tue May 16 17:45:51 2017
From: lkateley at kateley.com (Linda Kateley)
Date: Tue, 16 May 2017 12:45:51 -0500
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <1731185F-79B3-4B1A-B5A4-79F025F919B0@omniti.com>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
	<fc66a15d-cc54-8aa0-dea4-c20a0b0f114c@will.to>
	<680C52D7-4157-4F9E-AB69-375380CF4E7C@oetiker.ch>
	<128752415.20170516165313@tierarzt-mueller.de>
	<1731185F-79B3-4B1A-B5A4-79F025F919B0@omniti.com>
Message-ID: <92e413df-88d2-fb81-37b2-6c73a89ed2a2@kateley.com>

I would be happy to be part of any board or committee. I have alot of 
experience with a number of different communities and what's successful 
and what's not. The one that fascinates me is open stack, mostly with 
the funding and participation they get...

And Dan would love to hear all the stories

lk


On 5/16/17 10:27 AM, Dan McDonald wrote:
>> On May 16, 2017, at 10:53 AM, Alexander Lesle <groups at tierarzt-mueller.de> wrote:
>>
>> No NSA or U.S. laws pressure to code a backdoor for them.
> As someone who worked in the shadow of such a threat for many years (Building IPsec both at NRL, and pre-OpenSolaris Sun), the open-source nature of OmniOS mitigates (at least partially) explicit pressure as a concern.  Open-source code has a strong (albeit not fully court-tested) 1st amendment defense -- see here:
>
> 	https://en.wikipedia.org/wiki/Bernstein_v._United_States
>
> There may be good reasons to have an outside-the-US foundation, but backdoor concerns is not one of them.
>
> Dan
>
> p.s. I have good 90s-crypto-wars stories.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From an3s.annema at gmail.com  Tue May 16 19:12:14 2017
From: an3s.annema at gmail.com (Andries Annema)
Date: Tue, 16 May 2017 21:12:14 +0200
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <22811.6338.627688.902994@shelob.bb-c.de>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
	<fc66a15d-cc54-8aa0-dea4-c20a0b0f114c@will.to>
	<680C52D7-4157-4F9E-AB69-375380CF4E7C@oetiker.ch>
	<128752415.20170516165313@tierarzt-mueller.de>
	<22811.6338.627688.902994@shelob.bb-c.de>
Message-ID: <65004f64-1a03-2de9-8084-1f629dcf0162@gmail.com>

If we have the choice, I guess I would prefer EU-based as well.

Andries


On 2017-05-16 17:20, Volker A. Brandt wrote:
>> Switzerland or EU sounds good.
>>
>> No NSA or U.S. laws pressure to code a backdoor for them.
>>
>> On 16. May 2017 at 16:19 <Tobi Oetiker> wrote
>> in mid:680C52D7-4157-4F9E-AB69-375380CF4E7C at oetiker.ch :
>>> In switzerland, any three people
>>> can found an association by stating that they do so and
>>> creating a bylaws document. no fees. no official registration
>>> necessary. only if substantial money is handled or if there is
>>> profit, the association has to talk to the swiss irs.
> This does indeed sound good.
>
>
> Regards -- Volker


From henson at acm.org  Tue May 16 19:12:27 2017
From: henson at acm.org (Paul B. Henson)
Date: Tue, 16 May 2017 12:12:27 -0700
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <15671b7a-61fe-1e7c-44e4-6645c6031ce9@gmx.li>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>	<0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>	<6A4F3374-1241-4ED3-9451-255AE5BBDE57@me.com>	<e8d21f13-67d0-7a26-69f9-99d83f046540@gmx.li>	<C0D77E70-64F6-4B35-99C1-E087A7E4C78B@me.com>	<5221319a-5b73-7a5b-d030-2afef240d97f@gmx.li>
	<15671b7a-61fe-1e7c-44e4-6645c6031ce9@gmx.li>
Message-ID: <0b1b01d2ce78$5bcf5f00$136e1d00$@acm.org>

> From: Dominik Hassler
> Sent: Tuesday, May 16, 2017 8:50 AM
> 
> This system has a different mainboard, so I wonder if it is BIOS related
> and a BIOS upgrade on system 1 could help?

Perhaps a silly question, but had you tested booting from both drives before
the upgrade :)?


From peter.tribble at gmail.com  Tue May 16 19:18:59 2017
From: peter.tribble at gmail.com (Peter Tribble)
Date: Tue, 16 May 2017 20:18:59 +0100
Subject: [OmniOS-discuss] Legal next steps
In-Reply-To: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
References: <CACLsAptb=1A57_PTDLLUhe381oxZ6FoRvUMRH6Z2Z1NU9KST1g@mail.gmail.com>
Message-ID: <CAEgYsbESSbX9-MtfyBK4m0doncuTpVTnJJ4QasCgzzkS1wifnA@mail.gmail.com>

On Tue, May 16, 2017 at 2:22 PM, Theo Schlossnagle <jesus at omniti.com> wrote:

> My experience here is limited to the United States for approaching these
> problems.  I don't mean to indicate that it is the right solution, but I
> can only speak of what I know.
>
> A legal entity must hold the assets. That can be a person, or a trust, or
> an corporation or a community*, etc.  Community here is defined in such a
> way by the IRS that I don't believe we would ever quality (and it's never
> worth arguing). Given the history of "things" I would steer away from an
> individual and I feel that given unknown nature of assets required to
> operate and our weak starting point that a trust is likely not
> self-sustaining.
>
> What I would suggest is us setting up an corporation here in the US,
> setting a purpose and a missions statement (that includes education and
> science as we do those and they are eligible for non-profit status), elect
> 5-7 board members (who will be legally responsible for the entity) come up
> with a small operating budget (< $10k USD) and apply for non-profit
> (501(3)c).  This process would take a few hundreds of dollars.
>

My question here would be: Do it yourself, or apply to something like the
Software Freedom Conservancy

https://sfconservancy.org/about/

and let them deal with the paperwork?

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/20170516/50b4280f/attachment.html>

From hasslerd at gmx.li  Tue May 16 20:35:44 2017
From: hasslerd at gmx.li (Dominik Hassler)
Date: Tue, 16 May 2017 22:35:44 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <0b1b01d2ce78$5bcf5f00$136e1d00$@acm.org>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
	<0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>
	<6A4F3374-1241-4ED3-9451-255AE5BBDE57@me.com>
	<e8d21f13-67d0-7a26-69f9-99d83f046540@gmx.li>
	<C0D77E70-64F6-4B35-99C1-E087A7E4C78B@me.com>
	<5221319a-5b73-7a5b-d030-2afef240d97f@gmx.li>
	<15671b7a-61fe-1e7c-44e4-6645c6031ce9@gmx.li>
	<0b1b01d2ce78$5bcf5f00$136e1d00$@acm.org>
Message-ID: <1240838b-66dc-a420-152e-bac61c5dcbcb@gmx.li>



On 05/16/2017 09:12 PM, Paul B. Henson wrote:
>> From: Dominik Hassler
>> Sent: Tuesday, May 16, 2017 8:50 AM
>>
>> This system has a different mainboard, so I wonder if it is BIOS related
>> and a BIOS upgrade on system 1 could help?
>
> Perhaps a silly question, but had you tested booting from both drives before
> the upgrade :)?
>

Not a silly question at all. Yes I did, and the device that fails was 
the primary boot device before; so when the initial boot after enabling 
loader failed I tried the second and since that one worked I changed 
primary and secondary now.

From mir at miras.org  Tue May 16 20:44:42 2017
From: mir at miras.org (Michael Rasmussen)
Date: Tue, 16 May 2017 22:44:42 +0200
Subject: [OmniOS-discuss] OmniOS r151022 is now out!
In-Reply-To: <1240838b-66dc-a420-152e-bac61c5dcbcb@gmx.li>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
	<0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>
	<6A4F3374-1241-4ED3-9451-255AE5BBDE57@me.com>
	<e8d21f13-67d0-7a26-69f9-99d83f046540@gmx.li>
	<C0D77E70-64F6-4B35-99C1-E087A7E4C78B@me.com>
	<5221319a-5b73-7a5b-d030-2afef240d97f@gmx.li>
	<15671b7a-61fe-1e7c-44e4-6645c6031ce9@gmx.li>
	<0b1b01d2ce78$5bcf5f00$136e1d00$@acm.org>
	<1240838b-66dc-a420-152e-bac61c5dcbcb@gmx.li>
Message-ID: <D5C0A8F7-3741-4AF9-8103-CB1C680998E6@miras.org>

Could it be bad sectors in the boot block?

On May 16, 2017 10:35:44 PM GMT+02:00, Dominik Hassler <hasslerd at gmx.li> wrote:
>
>
>On 05/16/2017 09:12 PM, Paul B. Henson wrote:
>>> From: Dominik Hassler
>>> Sent: Tuesday, May 16, 2017 8:50 AM
>>>
>>> This system has a different mainboard, so I wonder if it is BIOS
>related
>>> and a BIOS upgrade on system 1 could help?
>>
>> Perhaps a silly question, but had you tested booting from both drives
>before
>> the upgrade :)?
>>
>
>Not a silly question at all. Yes I did, and the device that fails was 
>the primary boot device before; so when the initial boot after enabling
>
>loader failed I tried the second and since that one worked I changed 
>primary and secondary now.
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

----

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


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

From danmcd at omniti.com  Tue May 16 21:22:45 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 16 May 2017 17:22:45 -0400
Subject: [OmniOS-discuss] COMMUNITY EXERCISE: illumos 7590
Message-ID: <40553AEA-2445-4B96-B64A-3F0ED8C8FC33@omniti.com>

THIS IS A LONG EMAIL WITH SOME COMMAND TRANSCRIPTS!  PLEASE READ IT ALL IF YOU CARE ABOUT PUSHING OmniOS FORWARD!  LOOK FOR "YOUR HOMEWORK" to see the actual exercises for the community.

.  .  .

Earlier today, I RTI-approved and pushed illumos bug 7590:

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

It was reported by the Samba team, and it appears to be a barrier to using Samba on illumos distros.  Were I moving forward with OmniOS maintenance, I'd tag this one as a backport candidate for r151022.

INSTEAD, I'm going to start the ball rolling as publicly as possible about how one would pick a post-release illumos bugfix for backporting into a stable or even LTS release.

So let's outline the steps for backporting an illumos fix into an existing release.  I picked this one because it's HARD.  It spreads its tentacles across multiple packages, and even changes a public header file!

0.) While doing the steps below, keep in mind whether or not this is really worth tagging by itself, or whether or not it should wait until other updates also seem to be backport candidates.

YOUR HOMEWORK PART 0:  Figure this out.

1.) Get the master branch of illumos-omnios merged with the very latest illumos-gate, which will bring the bug into illumos-omnios:master.

That is the easiest part of this.  Going forward, illumos-omnios:master should be periodically updated with "git merge upstream" commands after illumos-omnios:upstream has been resynched with illumos-gate.  This is all detailed in the first part of this page:

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

Since this is easy, I'm going ahead and doing it:

========================
bloody(~)[0]% illumos-update 
HEY -- pay attention in case any of these FUBAR somehow.
~/ws/illumos-gate ~
Fetching origin
remote: Counting objects: 163, done.
remote: Compressing objects: 100% (66/66), done.
remote: Total 163 (delta 102), reused 77 (delta 77), pack-reused 13
Receiving objects: 100% (163/163), 173.54 KiB | 0 bytes/s, done.
Resolving deltas: 100% (102/102), completed with 76 local objects.
From https://github.com/illumos/illumos-gate
   49bf4c2bcf..f012ee0c3d  master     -> origin/master
Updating 49bf4c2bcf..f012ee0c3d
Fast-forward
 exception_lists/cstyle                             |   4 +
 usr/src/lib/libdscfg/common/cfg.c                  | 290 +++++++++---------
 usr/src/lib/libndmp/common/libndmp_prop.c          |   3 +-
 .../lib/print/libpapi-common/common/attribute.c    | 171 +++++------
 usr/src/man/man3nsl/xdr_admin.3nsl                 |  21 +-
 usr/src/pkg/manifests/system-test-ostest.mf        |   9 +-
 usr/src/test/os-tests/runfiles/default.run         |   8 +
 usr/src/test/os-tests/tests/Makefile               |   4 +-
 usr/src/test/os-tests/tests/sockfs/Makefile        |  54 ++++
 usr/src/test/os-tests/tests/sockfs/conn.c          | 220 ++++++++++++++
 usr/src/test/os-tests/tests/sockfs/dgram.c         | 182 ++++++++++++
 usr/src/test/os-tests/tests/sockfs/drop_priv.c     | 330 +++++++++++++++++++++
 usr/src/test/os-tests/tests/sockfs/sockpair.c      | 168 +++++++++++
 usr/src/test/os-tests/tests/stress/Makefile        |  42 +++
 usr/src/test/os-tests/tests/stress/dladm-kstat.sh  |  67 +++++
 usr/src/uts/common/avs/ns/sdbc/sd_bio.c            |  11 +-
 usr/src/uts/common/fs/autofs/auto_vfsops.c         |   5 +-
 usr/src/uts/common/fs/autofs/auto_vnops.c          |   4 +-
 usr/src/uts/common/fs/dcfs/dc_vnops.c              |   6 +-
 usr/src/uts/common/fs/dev/sdev_subr.c              |   9 +-
 usr/src/uts/common/fs/dev/sdev_vfsops.c            |   9 +-
 usr/src/uts/common/fs/devfs/devfs_vnops.c          |   7 +-
 usr/src/uts/common/fs/dnlc.c                       |  17 +-
 usr/src/uts/common/fs/doorfs/door_vnops.c          |  23 +-
 usr/src/uts/common/fs/fd/fdops.c                   |  22 +-
 usr/src/uts/common/fs/fifofs/fifovnops.c           |  40 ++-
 usr/src/uts/common/fs/gfs.c                        |   7 +-
 usr/src/uts/common/fs/hsfs/hsfs_vnops.c            | 209 ++++---------
 usr/src/uts/common/fs/lofs/lofs_subr.c             |  11 +-
 usr/src/uts/common/fs/namefs/namevfs.c             |   4 +-
 usr/src/uts/common/fs/namefs/namevno.c             |  36 +--
 usr/src/uts/common/fs/nfs/nfs4_client.c            |  12 +-
 usr/src/uts/common/fs/nfs/nfs4_rnode.c             |  13 +-
 usr/src/uts/common/fs/nfs/nfs4_shadow.c            |   5 +-
 usr/src/uts/common/fs/nfs/nfs_subr.c               |  14 +-
 usr/src/uts/common/fs/pcfs/pc_node.c               |   5 +-
 usr/src/uts/common/fs/pcfs/pc_vnops.c              |   3 +-
 usr/src/uts/common/fs/proc/prvnops.c               |   3 +-
 usr/src/uts/common/fs/smbclnt/smbfs/smbfs_subr2.c  |  15 +-
 usr/src/uts/common/fs/sockfs/sockcommon_vnops.c    |   9 +-
 usr/src/uts/common/fs/sockfs/socksubr.c            |  16 +-
 usr/src/uts/common/fs/sockfs/socktpi.c             | 234 +++++++++++----
 usr/src/uts/common/fs/sockfs/socktpi.h             |   9 +-
 usr/src/uts/common/fs/specfs/specvnops.c           |   7 +-
 usr/src/uts/common/fs/tmpfs/tmp_vnops.c            |   3 +-
 usr/src/uts/common/fs/udfs/udf_inode.c             |  21 +-
 usr/src/uts/common/fs/ufs/ufs_inode.c              |  10 +-
 usr/src/uts/common/fs/ufs/ufs_thread.c             |  13 +-
 usr/src/uts/common/fs/vnode.c                      |  13 +-
 usr/src/uts/common/fs/xattr.c                      |  25 +-
 usr/src/uts/common/fs/zfs/zfs_ctldir.c             |   4 +-
 usr/src/uts/common/fs/zfs/zfs_vnops.c              |   6 +-
 usr/src/uts/common/fs/zfs/zfs_znode.c              |   4 +-
 usr/src/uts/common/io/dls/dls_mgmt.c               |  60 ++--
 usr/src/uts/common/os/contract.c                   |   5 +-
 usr/src/uts/common/os/driver.c                     |  11 +-
 usr/src/uts/common/sys/fs/sdev_impl.h              |   9 +-
 usr/src/uts/common/sys/socket.h                    |   5 +-
 usr/src/uts/common/sys/vnode.h                     |  39 ++-
 59 files changed, 1855 insertions(+), 711 deletions(-)
 create mode 100644 usr/src/test/os-tests/tests/sockfs/Makefile
 create mode 100644 usr/src/test/os-tests/tests/sockfs/conn.c
 create mode 100644 usr/src/test/os-tests/tests/sockfs/dgram.c
 create mode 100644 usr/src/test/os-tests/tests/sockfs/drop_priv.c
 create mode 100644 usr/src/test/os-tests/tests/sockfs/sockpair.c
 create mode 100644 usr/src/test/os-tests/tests/stress/Makefile
 create mode 100755 usr/src/test/os-tests/tests/stress/dladm-kstat.sh
~
~/ws/illumos-omnios ~
Fetching origin
From https://github.com/omniti-labs/illumos-omnios
   3f784048a3..8b31933c62  master          -> origin/master
   5806135a39..49bf4c2bcf  upstream        -> origin/upstream
   7f03e7512c..f6eee9d5d9  upstream_joyent -> origin/upstream_joyent
Already up-to-date.
Switched to branch 'upstream'
Your branch is up-to-date with 'origin/upstream'.
remote: Counting objects: 163, done.
remote: Compressing objects: 100% (51/51), done.
remote: Total 163 (delta 132), reused 133 (delta 102)
Receiving objects: 100% (163/163), 27.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (132/132), completed with 94 local objects.
From /export/home/danmcd/ws/illumos-gate
 * branch                  HEAD       -> FETCH_HEAD
Updating 49bf4c2bcf..f012ee0c3d
Fast-forward
 exception_lists/cstyle                             |   4 +
 usr/src/lib/libdscfg/common/cfg.c                  | 290 +++++++++---------
 usr/src/lib/libndmp/common/libndmp_prop.c          |   3 +-
 .../lib/print/libpapi-common/common/attribute.c    | 171 +++++------
 usr/src/man/man3nsl/xdr_admin.3nsl                 |  21 +-
 usr/src/pkg/manifests/system-test-ostest.mf        |   9 +-
 usr/src/test/os-tests/runfiles/default.run         |   8 +
 usr/src/test/os-tests/tests/Makefile               |   4 +-
 usr/src/test/os-tests/tests/sockfs/Makefile        |  54 ++++
 usr/src/test/os-tests/tests/sockfs/conn.c          | 220 ++++++++++++++
 usr/src/test/os-tests/tests/sockfs/dgram.c         | 182 ++++++++++++
 usr/src/test/os-tests/tests/sockfs/drop_priv.c     | 330 +++++++++++++++++++++
 usr/src/test/os-tests/tests/sockfs/sockpair.c      | 168 +++++++++++
 usr/src/test/os-tests/tests/stress/Makefile        |  42 +++
 usr/src/test/os-tests/tests/stress/dladm-kstat.sh  |  67 +++++
 usr/src/uts/common/avs/ns/sdbc/sd_bio.c            |  11 +-
 usr/src/uts/common/fs/autofs/auto_vfsops.c         |   5 +-
 usr/src/uts/common/fs/autofs/auto_vnops.c          |   4 +-
 usr/src/uts/common/fs/dcfs/dc_vnops.c              |   6 +-
 usr/src/uts/common/fs/dev/sdev_subr.c              |   9 +-
 usr/src/uts/common/fs/dev/sdev_vfsops.c            |   9 +-
 usr/src/uts/common/fs/devfs/devfs_vnops.c          |   7 +-
 usr/src/uts/common/fs/dnlc.c                       |  17 +-
 usr/src/uts/common/fs/doorfs/door_vnops.c          |  23 +-
 usr/src/uts/common/fs/fd/fdops.c                   |  22 +-
 usr/src/uts/common/fs/fifofs/fifovnops.c           |  40 ++-
 usr/src/uts/common/fs/gfs.c                        |   7 +-
 usr/src/uts/common/fs/hsfs/hsfs_vnops.c            | 209 ++++---------
 usr/src/uts/common/fs/lofs/lofs_subr.c             |  11 +-
 usr/src/uts/common/fs/namefs/namevfs.c             |   4 +-
 usr/src/uts/common/fs/namefs/namevno.c             |  36 +--
 usr/src/uts/common/fs/nfs/nfs4_client.c            |  12 +-
 usr/src/uts/common/fs/nfs/nfs4_rnode.c             |  13 +-
 usr/src/uts/common/fs/nfs/nfs4_shadow.c            |   5 +-
 usr/src/uts/common/fs/nfs/nfs_subr.c               |  14 +-
 usr/src/uts/common/fs/pcfs/pc_node.c               |   5 +-
 usr/src/uts/common/fs/pcfs/pc_vnops.c              |   3 +-
 usr/src/uts/common/fs/proc/prvnops.c               |   3 +-
 usr/src/uts/common/fs/smbclnt/smbfs/smbfs_subr2.c  |  15 +-
 usr/src/uts/common/fs/sockfs/sockcommon_vnops.c    |   9 +-
 usr/src/uts/common/fs/sockfs/socksubr.c            |  16 +-
 usr/src/uts/common/fs/sockfs/socktpi.c             | 234 +++++++++++----
 usr/src/uts/common/fs/sockfs/socktpi.h             |   9 +-
 usr/src/uts/common/fs/specfs/specvnops.c           |   7 +-
 usr/src/uts/common/fs/tmpfs/tmp_vnops.c            |   3 +-
 usr/src/uts/common/fs/udfs/udf_inode.c             |  21 +-
 usr/src/uts/common/fs/ufs/ufs_inode.c              |  10 +-
 usr/src/uts/common/fs/ufs/ufs_thread.c             |  13 +-
 usr/src/uts/common/fs/vnode.c                      |  13 +-
 usr/src/uts/common/fs/xattr.c                      |  25 +-
 usr/src/uts/common/fs/zfs/zfs_ctldir.c             |   4 +-
 usr/src/uts/common/fs/zfs/zfs_vnops.c              |   6 +-
 usr/src/uts/common/fs/zfs/zfs_znode.c              |   4 +-
 usr/src/uts/common/io/dls/dls_mgmt.c               |  60 ++--
 usr/src/uts/common/os/contract.c                   |   5 +-
 usr/src/uts/common/os/driver.c                     |  11 +-
 usr/src/uts/common/sys/fs/sdev_impl.h              |   9 +-
 usr/src/uts/common/sys/socket.h                    |   5 +-
 usr/src/uts/common/sys/vnode.h                     |  39 ++-
 59 files changed, 1855 insertions(+), 711 deletions(-)
 create mode 100644 usr/src/test/os-tests/tests/sockfs/Makefile
 create mode 100644 usr/src/test/os-tests/tests/sockfs/conn.c
 create mode 100644 usr/src/test/os-tests/tests/sockfs/dgram.c
 create mode 100644 usr/src/test/os-tests/tests/sockfs/drop_priv.c
 create mode 100644 usr/src/test/os-tests/tests/sockfs/sockpair.c
 create mode 100644 usr/src/test/os-tests/tests/stress/Makefile
 create mode 100755 usr/src/test/os-tests/tests/stress/dladm-kstat.sh
Checking out files: 100% (811/811), done.
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

So far so good... I'm going to give you a chance to ^C out of here before
I 'git merge upstream'.  At this point, illumos-omnios's 'upstream'
branch is up to date with illumos-gate, but the master branch is checked
out.

Press RETURN to continue.

Auto-merging usr/src/uts/common/sys/vnode.h
CONFLICT (content): Merge conflict in usr/src/uts/common/sys/vnode.h
Auto-merging usr/src/uts/common/sys/socket.h
Auto-merging usr/src/uts/common/os/contract.c
Auto-merging usr/src/uts/common/io/dls/dls_mgmt.c
Auto-merging usr/src/uts/common/fs/zfs/zfs_vnops.c
Auto-merging usr/src/uts/common/fs/vnode.c
Auto-merging usr/src/uts/common/fs/tmpfs/tmp_vnops.c
Auto-merging usr/src/uts/common/fs/sockfs/socksubr.c
CONFLICT (content): Merge conflict in usr/src/uts/common/fs/sockfs/socksubr.c
Auto-merging usr/src/uts/common/fs/proc/prvnops.c
Auto-merging usr/src/uts/common/fs/pcfs/pc_vnops.c
Auto-merging usr/src/uts/common/fs/dev/sdev_subr.c
Auto-merging usr/src/test/os-tests/tests/Makefile
CONFLICT (content): Merge conflict in usr/src/test/os-tests/tests/Makefile
Auto-merging usr/src/test/os-tests/runfiles/default.run
CONFLICT (content): Merge conflict in usr/src/test/os-tests/runfiles/default.run
Auto-merging usr/src/pkg/manifests/system-test-ostest.mf
CONFLICT (content): Merge conflict in usr/src/pkg/manifests/system-test-ostest.mf
Automatic merge failed; fix conflicts and then commit the result.
~
bloody(~)[0]% 
========================

OH SNAP!  Looks like it's not so easy.  I see five conflicts, and all of them I'll bet are related to LX-brand changes we imported into OmniOS.  Now I'm going to resolve the conflicts, and summarize them here.

* Two sets of new tests from -gate collided with a timer test that was brought in with LX.

* Simple copyright-collisions for the two in-kernel.  (Both contain LX enhancements, so they have more recent Joyent copyrights that what's in -gate).

The tests are collidy-enough where I'm running an illumos-omnios build before I push them.  For now, let's assume it works and I push these upstream to the illumos-omnios repo.


2.) Cherrypick the commit from master into the r151022 branch.

Like with merging from upstream, there's a good chance we'll have collisions, and they may very well be the same as the merge from -gate.  The "--strategy=3-way" flag may be useful here, as you'll get collision indicators.  Since I'm not done yet with the illumos-omnios test build, I'll hold off.

3.) Build r151022 to make sure it actually builds!

With sufficient hardware, this is less than an hour using ALL the build flags you need.

4.) Figure out either which packages need updating, OR resign yourself to a full-illumos update.

The full-illumos update is easier, but requires FAR more package transfers & signatures.  You basically run the omnios-build/build/illumos/build.sh script with a PREBUILT_ILLUMOS set to whatever you did in step 3, setting PKGSRVR to somewhere nice (make sure omnios-build is on branch r151022):

	pkgrepo create -s /tmp/staging.repo
	pkgrepo add-publisher -s /tmp/staging.repo omnios
	cd $PATH/omnios-build/build/illumos
	PREBUILT_ILLUMOS=$PATH/build/illumos-omnios PKGSRVR=/tmp/staging.repo ./build.sh -lb

Figuring out which packages requires you look at the commit to see what packages get touched.  Also, you need to figure out if this is a require-reboot update or not, and finally, you need to ask if it's worth respinning the "uname -v" string, which requires system/kernel/platform to be updated as well.

YOUR HOMEWORK PART 1:  Figure out what packages illumos 7590 touches.

5.) Get packages signed.
6.) Push packages out.

For now, these involves OmniTI's help.  I'm sure that won't be a problem.

7.) Decide if you need to build media again.

IMHO for this one you don't.  But...

YOUR HOMEWORK PART 2:  Figure out if illumos 7590 is worth a media spin, or just tell users to "pkg update"?

8.) Build media.

You can only do this after the packages are pushed on to the repo servers.  Luckily, it's pretty easy these days, esp. if you have your PREBUILT_ILLUMOS from step 3:

	cd $PATH/kayak
		(Make sure you're on branch r151022)
	sudo zfs destroy -R rpool/kayak_image    (NOTE: Can use different one)
	sudo zfs create rpool/kayak_image
	sudo gmake BUILDSEND=rpool/kayak_image PREBUILT_ILLUMOS=$PATH/build/illumos-omnios install-iso

The media will all be in /rpool/kayak_image.


Ask away if you've questions or (more likely) if I missed something.

Thanks,
Dan


From danmcd at omniti.com  Tue May 16 21:24:33 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 16 May 2017 17:24:33 -0400
Subject: [OmniOS-discuss] COMMUNITY EXERCISE: illumos 7590
In-Reply-To: <40553AEA-2445-4B96-B64A-3F0ED8C8FC33@omniti.com>
References: <40553AEA-2445-4B96-B64A-3F0ED8C8FC33@omniti.com>
Message-ID: <215F922B-DF69-4C86-8AC7-C516D8737EC9@omniti.com>

Found my first error

> On May 16, 2017, at 5:22 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> YOUR HOMEWORK PART 0:  Figure this out.


Correction:  "Figure out whether or not illumos 7590 is worth a backport all by itself."


Dan


From danmcd at omniti.com  Wed May 17 05:31:55 2017
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 17 May 2017 01:31:55 -0400
Subject: [OmniOS-discuss] COMMUNITY EXERCISE: illumos 7590
In-Reply-To: <40553AEA-2445-4B96-B64A-3F0ED8C8FC33@omniti.com>
References: <40553AEA-2445-4B96-B64A-3F0ED8C8FC33@omniti.com>
Message-ID: <D2DC3E3E-B81E-42C2-AEE0-26BCC6A5B4D7@omniti.com>


> On May 16, 2017, at 5:22 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> The tests are collidy-enough where I'm running an illumos-omnios build before I push them.  For now, let's assume it works and I push these upstream to the illumos-omnios repo.

The illumos-omnios build worked for bloody, and now the master and upstream branches are updated.

Dan


From paladinemishakal at gmail.com  Wed May 17 07:06:50 2017
From: paladinemishakal at gmail.com (Lawrence Giam)
Date: Wed, 17 May 2017 15:06:50 +0800
Subject: [OmniOS-discuss] What version of SMB
Message-ID: <CAGueQCdKT0A92RviaM2wG-ho1U_4WRdrTjFweb3nqfrGNp_RXg@mail.gmail.com>

Hi All,

I would like to know if OmniOS support what version of SMB for it's CIFS
implementation? In view of the WannaCry ransomware, I would like to check
what SMB version is in my OmniOS server setup.

I have OmniOS server serving CIFS to Windows domain users and I tried
testing turning off SMBv1 my Win 7 client and the client cannot see the
CIFS shares and cannot access it too.

Is there a way to set the CIFS to use SMBv2?

Thanks & Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170517/5d6ef77b/attachment.html>

From alka at hfg-gmuend.de  Wed May 17 07:43:19 2017
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Wed, 17 May 2017 09:43:19 +0200
Subject: [OmniOS-discuss] What version of SMB
In-Reply-To: <CAGueQCdKT0A92RviaM2wG-ho1U_4WRdrTjFweb3nqfrGNp_RXg@mail.gmail.com>
References: <CAGueQCdKT0A92RviaM2wG-ho1U_4WRdrTjFweb3nqfrGNp_RXg@mail.gmail.com>
Message-ID: <3fca71ba-e7ac-34ef-2d7a-f1dc1af16794@hfg-gmuend.de>

OmniOS (151018+) supports SMB 2.1 per default.
You can check on serverside with sharectl get smb
(look for max_protocol) and reduce it via sharectrl set -p 
max_protocol=1 smb(+ restart smb)

Gea



  17.05.2017 um 09:06 schrieb Lawrence Giam:
> Hi All,
>
> I would like to know if OmniOS support what version of SMB for it's 
> CIFS implementation? In view of the WannaCry ransomware, I would like 
> to check what SMB version is in my OmniOS server setup.
>
> I have OmniOS server serving CIFS to Windows domain users and I tried 
> testing turning off SMBv1 my Win 7 client and the client cannot see 
> the CIFS shares and cannot access it too.
>
> Is there a way to set the CIFS to use SMBv2?
>
> Thanks & Regards.
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 

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

From alka at hfg-gmuend.de  Wed May 17 11:06:39 2017
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Wed, 17 May 2017 13:06:39 +0200
Subject: [OmniOS-discuss] OmniOS Mirror
In-Reply-To: <D5C0A8F7-3741-4AF9-8103-CB1C680998E6@miras.org>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com>
	<eadb675c-180e-bd58-5867-de484895d6e4@gmx.li>
	<0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com>
	<6A4F3374-1241-4ED3-9451-255AE5BBDE57@me.com>
	<e8d21f13-67d0-7a26-69f9-99d83f046540@gmx.li>
	<C0D77E70-64F6-4B35-99C1-E087A7E4C78B@me.com>
	<5221319a-5b73-7a5b-d030-2afef240d97f@gmx.li>
	<15671b7a-61fe-1e7c-44e4-6645c6031ce9@gmx.li>
	<0b1b01d2ce78$5bcf5f00$136e1d00$@acm.org>
	<1240838b-66dc-a420-152e-bac61c5dcbcb@gmx.li>
	<D5C0A8F7-3741-4AF9-8103-CB1C680998E6@miras.org>
Message-ID: <2fc37fb9-a111-fa31-879e-70d4ccae1ac4@hfg-gmuend.de>

Update

I have updated my OmniOS/OI edu mirror:
http://openzfs.hfg-gmuend.de/omnios/

- all isos
- all repositories 15106/14/18/20/22/23
(online repo and downloadable as zip)
- main wiki pages

Gea


From stephan.budach at jvm.de  Wed May 17 12:01:22 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Wed, 17 May 2017 14:01:22 +0200 (CEST)
Subject: [OmniOS-discuss] OmniOS Mirror
In-Reply-To: <2fc37fb9-a111-fa31-879e-70d4ccae1ac4@hfg-gmuend.de>
References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com>
	<C0D77E70-64F6-4B35-99C1-E087A7E4C78B@me.com>
	<5221319a-5b73-7a5b-d030-2afef240d97f@gmx.li>
	<15671b7a-61fe-1e7c-44e4-6645c6031ce9@gmx.li>
	<0b1b01d2ce78$5bcf5f00$136e1d00$@acm.org>
	<1240838b-66dc-a420-152e-bac61c5dcbcb@gmx.li>
	<D5C0A8F7-3741-4AF9-8103-CB1C680998E6@miras.org>
	<2fc37fb9-a111-fa31-879e-70d4ccae1ac4@hfg-gmuend.de>
Message-ID: <1436813382.197.1495022488969.JavaMail.stephan.budach@stephan.budach.jvm.de>

Hi Gea,


----- Urspr?ngliche Mail -----
> Von: "Guenther Alka" <alka at hfg-gmuend.de>
> An: omnios-discuss at lists.omniti.com
> Gesendet: Mittwoch, 17. Mai 2017 13:06:39
> Betreff: [OmniOS-discuss] OmniOS Mirror
> 
> Update
> 
> I have updated my OmniOS/OI edu mirror:
> http://openzfs.hfg-gmuend.de/omnios/
> 
> - all isos
> - all repositories 15106/14/18/20/22/23
> (online repo and downloadable as zip)
> - main wiki pages
> 
> Gea

how much storage capacity accounts that for? We will transision to a 1GbE IPA in the coming weeks and I could also offer to host a mirror.

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/20170517/36a16274/attachment-0001.bin>

From danmcd at kebe.com  Wed May 17 14:28:48 2017
From: danmcd at kebe.com (Dan McDonald)
Date: Wed, 17 May 2017 10:28:48 -0400
Subject: [OmniOS-discuss] Test
Message-ID: <20170517142848.GA2816@everywhere.local>

This is only a test.

Dan

From alka at hfg-gmuend.de  Thu May 18 09:15:04 2017
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Thu, 18 May 2017 11:15:04 +0200
Subject: [OmniOS-discuss] To the OmniOS, OI and SmartOS community
In-Reply-To: <4373cbdf-3053-37f3-9eac-0ce99e89a5e4@hfg-gmuend.de>
References: <4373cbdf-3053-37f3-9eac-0ce99e89a5e4@hfg-gmuend.de>
Message-ID: <592404a7-29b4-05d2-aee9-93c3df7a25aa@hfg-gmuend.de>

News about OmniOS and Discuss about free Illumos distributions and 
future OmniOS/OI options

I have started a thread in a popular forum with a strong ZFS focus to 
discuss this
also with regular users outside the maillists.

https://forums.servethehome.com/index.php?threads/omnios-151022-long-term-stable.14367/page-2

I would like to hear your comments about my opinions, good, bad, 
illusional or whatever

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

From alka at hfg-gmuend.de  Thu May 18 18:30:09 2017
From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=)
Date: Thu, 18 May 2017 20:30:09 +0200
Subject: [OmniOS-discuss] [OpenIndiana-discuss] To the OmniOS,
	OI and SmartOS community
In-Reply-To: <25ca1497-066d-99b3-ebd3-ea60b59b4a75@gmail.com>
References: <4373cbdf-3053-37f3-9eac-0ce99e89a5e4@hfg-gmuend.de>
	<25ca1497-066d-99b3-ebd3-ea60b59b4a75@gmail.com>
Message-ID: <280a13de-3bda-ffc8-49d3-71cfef9bc549@hfg-gmuend.de>

hello Till

My napp-it storage appliance add-on is currently running and supported 
on OmniOS, OpenIndiana Hipster, Solaris and partly ZoL. I would be very 
glad to add SmartOS but this would require a mechanism to  install 
storage services to global zone, load settings like users or (SMB) 
groups on powerup from datapool and save them on demand to make them 
persistent.

If you ask what I and many users need or want from a free distribution 
compared to OpenIndiana, the answer is a Illumos distribution with 
stables and long term stables, each based on its own repository with 
backported security fixes on the long term stable. This allows to 
evaluate a release and use it with the option to add security or 
bugfixes without jumping to a newer release with newer features and 
possible incompatibilities or new bugs. This is what OmniOS is and for 
me this is what I and many users want. My hope is that this will be 
based on OI snapshots in future as I do not believe that a second fully 
independent community backed Illumos distribution can survice on the 
long run. It will only weaken Illumos in case of a failure and OI in the 
meantime.

SmartOS with a solid commercial background and one additional community 
based Illumos alternative is what I hope for. And the last can only mean 
OpenIndiana + stable add-on.

best regards


Gea

Am 18.05.2017 um 18:31 schrieb Till Wegm?ller:
> Hello Guenther
>
> I would pretty much suggest using OpenIndiana to develop solutions 
> like napp-it on top of.
>
> Main reason being that appart from certain vlan taging and lx zone 
> features we have all the technical bells ans whistels that OmniOs and 
> SmartOS have. We just have some different tools. We use the ones 
> Solaris used and don't have high level wrappers like vmadm.
>
>
> If you want to use it to base your napp-it I definately would support 
> you with what I know about the distribution. I could tell you about 
> the Image creation system and other stuff. And I'm sure that others 
> would help out with insights aswell.
>
> What would you need from a Distribution to build your Application on 
> top? Would be interesting to know.
>
> ---
> Greetings
> Till
>
> On 15.05.2017 13:58, Guenther Alka wrote:
>> *Its time to consider pla**n**B/C ??*
>> to: omnios-discuss, openindiana-discuss, smartos-discuss
>>
>> The announcement of OmniTi to cancel OmniOS from now to then is a 
>> real disaster not only for OmniOS users but for the whole Illumos 
>> platform. Many users who want a free Solaris based OS especially in 
>> production environments selected OmniOS as their preferred Illumos 
>> platform mainly with use cases storage and general server applications.
>>
>> The reasons:*OmniOS=**Up to date Illumos*
>> + commercial support option (although way too expensive)
>> + own developments like LX zones integration from SmartOS or drivers
>> + stables/long term stables with very experienced full time staff 
>> (thanks to Dan and Dale again)
>>
>> As OmniTi has released a new stable 151022, I/we have some time maybe 
>> to the end of the year unless OmniOS is out of sync with Illumos in a 
>> non tolerable amount.  Bugfixes of serious problems may be the case 
>> until then (hope so).
>>
>> What are the/my options
>>
>>
>> *Plan A*
>> Hope for a continuation of OmniOS as a well maintained 
>> community/commercial project with further development, ongoing 
>> stables and bugfixes optionally with some paid contributions under 
>> the umbrella of a firm or at least with some experienced members that 
>> were already resonsible for OmniOS or an Illumos distribution and 
>> that can be trusted for next years.
>>
>> While I hope for this, I doubt that this is a serious option. I 
>> switched from OpenIndiana to OmniOS three years ago as the OI 
>> community was too weak and development nearly stalled at that time. I 
>> am not interested in a new weak OmniOS community for a distribution 
>> that should be used as a production system. The OmniOS community will 
>> be propably too small forever as we already have the Illumos 
>> community project OpenIndiana nearly identical to OmniOS from 
>> distribution, features and use cases. And a very important thing: The 
>> brand OmniOS has already a very bad name as a dead/failed project in 
>> the press mostly affecting Illumos as well.
>>
>>
>> *Plan B*
>> OpenIndiana is a quite established community project for an up to 
>> date Illumos distribution. I would say its nearly identical to OmniOS 
>> beside the missing LX improvements from OmniOS but with an additional 
>> GUI option. I hope to see LX zones upstreamed to Illumos. OpenIndiana 
>> currently offers a rolling development of newest Illumos bits with 
>> snapshots every 6 months but without an additional stable repository 
>> with backported security fixes. Every update give you the newest 
>> Illumos fixes and features but also the newest bugs (ongoing dev, 
>> unstable).
>>
>> If OmniOS has to become a community project, I undoubtly would prefer 
>> a merge of the two distributions up from next releases. OpenIndiana 
>> with a stable repo for every snapshot and with a repo as development 
>> path would give me what was the main advantage of OmniOS beside 
>> commercial support. Access to such a stable repo optionally under an 
>> OmniOS brand may be even a paid (if affordable) option. Such a merge 
>> would strengthen Illumos at first place but also free OpenSource 
>> distributions like OmniOS and OpenIndiana.
>>
>>
>> *Plan C*
>> There is another free Illumos distribution with an enterprise 
>> background suited for datacenter use: SmartOS. It even adds unique 
>> Cloud and virtualisation features like KVM, Solaris zones, Linux 
>> zones and Docker support. As it is running from RAM with everything 
>> important on a datapool it is a very stable/ easy recoverable option 
>> but it lacks some features in the global zone that are required for a 
>> storage server.  An additional plus is the pkgin repo with lots of 
>> supported long term stable services.
>>
>> Using SmartOS would require a mechanism to allow storage services 
>> like SSH, Crossbow, iSCSI, NFS and SMB on the global zone with an 
>> option to save/restore settings from a datapool to be persistent. To 
>> be honest, a SmartOS that is capable to act as a storage appliance 
>> would be my dream option, at least as an additional option. This 
>> would require that SmartOS is not actively hindering this or 
>> preferable is helping to implement a save/restore option for global 
>> zone settings&features.
>>
>>
>> *Discuss*
>> But whatever option is coming, end the Illumos fragmentation for the 
>> sake of one strong free community distribution with a solid number of 
>> contributors and one freely available with a commercial background 
>> like SmartOS/ Samsung owned.
>>
>>
>> Any comments from OmniOS, OI, SmartOS (omnios-discuss, 
>> openindiana-discuss, smartos-discuss) communities?
>> I have send this to all three lists, so optionally answer all lists
>>
>>
>> best regards
>>
>>
>> Gea/ napp-it.org
>>
>>
>> _______________________________________________
>> openindiana-discuss mailing list
>> openindiana-discuss at openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss


From geoffn at gnaa.net  Thu May 18 19:55:51 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Thu, 18 May 2017 12:55:51 -0700
Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed
Message-ID: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net>

Hi.

I upgraded to the latest r151022 version.  The upgrade went fine, 
rebooted the machine, then upgraded to the new loader.

When i rebooted after the loader upgrade, I got an error message:

panic: bd_strategy: 512 bytes I/O not multiple of block size.

press a key on the console to reboot....

Rebooting...

panic free: guard1 fail @ 0x2e2e2e67 from ../../common/devopen.c:64

The boot disk is an 80GB intel ssd.

Any thoughts?

thanks,

Geoff


From natxo.asenjo at gmail.com  Thu May 18 19:56:12 2017
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Thu, 18 May 2017 21:56:12 +0200
Subject: [OmniOS-discuss] What version of SMB
In-Reply-To: <3fca71ba-e7ac-34ef-2d7a-f1dc1af16794@hfg-gmuend.de>
References: <CAGueQCdKT0A92RviaM2wG-ho1U_4WRdrTjFweb3nqfrGNp_RXg@mail.gmail.com>
	<3fca71ba-e7ac-34ef-2d7a-f1dc1af16794@hfg-gmuend.de>
Message-ID: <CAHBEJzWpuTgxfjrxre3esqD=3nctd0W63Qay_A4CuRQ-381YQg@mail.gmail.com>

hi,

On Wed, May 17, 2017 at 9:43 AM, Guenther Alka <alka at hfg-gmuend.de> wrote:

> OmniOS (151018+) supports SMB 2.1 per default.
> You can check on serverside with sharectl get smb
> (look for max_protocol) and reduce it via sharectrl set -p max_protocol=1
> smb (+ restart smb)
>
That way you can downgrade the protocol to only accept smb v1, I think.

I do not know how to disable smb v1. Right now you can downgrade the
connection to smbv1 from the client as well:

$ smbclient //zfstank/test -U anonymous --max-protocol=NT1
Enter anonymous's password:
Domain=[WORKGROUP] OS=[SunOS 5.11 omnios-r151022-f9693] Server=[Native SMB
service]
smb: \> dir
  .                                  DA        0  Thu Dec  1 07:00:55 2016
  ..                                 DA        0  Thu Dec  1 07:00:55 2016
  .zfs                                D        0  Mon May  6 20:46:21 2013

There should be a way to disable smb v1 altogether, although it could break
older equipment (printers, scanners, etc).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170518/3665e7e1/attachment.html>

From danmcd at kebe.com  Thu May 18 20:06:26 2017
From: danmcd at kebe.com (Dan McDonald)
Date: Thu, 18 May 2017 16:06:26 -0400
Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed
In-Reply-To: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net>
References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net>
Message-ID: <E3E7DE74-256A-4913-A0E7-43231D42088B@kebe.com>


> On May 18, 2017, at 3:55 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
> 
> Hi.
> 
> I upgraded to the latest r151022 version.  The upgrade went fine, rebooted the machine, then upgraded to the new loader.
> 
> When i rebooted after the loader upgrade, I got an error message:
> 
> panic: bd_strategy: 512 bytes I/O not multiple of block size.
> 
> press a key on the console to reboot....
> 
> Rebooting...
> 
> panic free: guard1 fail @ 0x2e2e2e67 from ../../common/devopen.c:64
> 
> The boot disk is an 80GB intel ssd.
> 
> Any thoughts?

Looks like you may have one of those 512b or 4k sector problems.

I'm Bcc:ing the loader person, in case this is familiar to him.

Dan


From geoffn at gnaa.net  Thu May 18 20:31:50 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Thu, 18 May 2017 13:31:50 -0700
Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed
In-Reply-To: <E3E7DE74-256A-4913-A0E7-43231D42088B@kebe.com>
References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net>
	<E3E7DE74-256A-4913-A0E7-43231D42088B@kebe.com>
Message-ID: <74198f44-be84-264f-9b75-a39cef48b610@gnaa.net>



On 2017-05-18 01:06 PM, Dan McDonald wrote:
>> On May 18, 2017, at 3:55 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
>>
>> Hi.
>>
>> I upgraded to the latest r151022 version.  The upgrade went fine, rebooted the machine, then upgraded to the new loader.
>>
>> When i rebooted after the loader upgrade, I got an error message:
>>
>> panic: bd_strategy: 512 bytes I/O not multiple of block size.
>>
>> press a key on the console to reboot....
>>
>> Rebooting...
>>
>> panic free: guard1 fail @ 0x2e2e2e67 from ../../common/devopen.c:64
>>
>> The boot disk is an 80GB intel ssd.
>>
>> Any thoughts?
> Looks like you may have one of those 512b or 4k sector problems.
>
> I'm Bcc:ing the loader person, in case this is familiar to him.
>
> Dan

Thanks Dan.

This system does have some 4K disks in it, but the boot disk is a 
SSDSC2BB080G6.

Have a great day!!
Geoff

From sriramnrn at gmail.com  Wed May 24 03:56:55 2017
From: sriramnrn at gmail.com (Sriram Narayanan)
Date: Wed, 24 May 2017 11:56:55 +0800
Subject: [OmniOS-discuss] COMMUNITY EXERCISE: illumos 7590
In-Reply-To: <D2DC3E3E-B81E-42C2-AEE0-26BCC6A5B4D7@omniti.com>
References: <40553AEA-2445-4B96-B64A-3F0ED8C8FC33@omniti.com>
	<D2DC3E3E-B81E-42C2-AEE0-26BCC6A5B4D7@omniti.com>
Message-ID: <CANiY96Zzuhv908WRob2hA=eOzKgp0881zNr69Zpxk2-H6E0mWg@mail.gmail.com>

Thanks for the walkthrough, Dan.

-- Ram

On Wed, May 17, 2017 at 1:31 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On May 16, 2017, at 5:22 PM, Dan McDonald <danmcd at omniti.com> wrote:
> >
> > The tests are collidy-enough where I'm running an illumos-omnios build
> before I push them.  For now, let's assume it works and I push these
> upstream to the illumos-omnios repo.
>
> The illumos-omnios build worked for bloody, and now the master and
> upstream branches are updated.
>
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170524/50d6bb58/attachment.html>

From jimklimov at cos.ru  Wed May 24 12:07:45 2017
From: jimklimov at cos.ru (Jim Klimov)
Date: Wed, 24 May 2017 14:07:45 +0200
Subject: [OmniOS-discuss] Fwd: [OpenIndiana-discuss] The team I work in is
	now hiring OpenSource	developers
In-Reply-To: <fc1e7db016ea.591a47a2@cos.ru>
References: <fc1e7db016ea.591a47a2@cos.ru>
Message-ID: <7DACF345-644A-467C-A16F-320B68F9E39B@cos.ru>

It seems the mailing lists do not know all my aliases, so I'd like to re-post my call for new colleagues in a commercial FOSS project ;)

Jim


-------- Original Message --------
From: Jim Klimov <jim at cos.ru>
Sent: May 16, 2017 12:28:18 AM GMT+02:00
To: OpenIndiana Developer mailing list <oi-dev at openindiana.org>, omnios-discuss at lists.omniti.com, openindiana-discuss at openindiana.org
Cc: EvgenyKlimov at eaton.com
Subject: [OpenIndiana-discuss] The team I work in is now hiring OpenSource	developers


Hello friends,

I hope this is not too much of an off-topic, but if anyone on these lists is looking for a job (if only to support their tinkering on illumos projects in spare time ? rather than walk away from what they love in these turbulent times), my employer is looking for software developers at EEIC (Eaton European Innovation Center) located near Prague, CZ. This is a full-time day-job in office, although a moderate portion of home-office is arrangeable. The company is quite open and helpful to specialists relocating from abroad (with the first hundred people in the facility we had about 20 countries and almost all continents represented), so don?t be shy if you want to see the world and move to the Prague region from afar.

We currently have vacancies in the OpenSource team where I work (mostly C/C++/Linux), as well as in other Enterprise Software teams (including a C#/Azure project). Seasoned developers as well as strong graduates are welcome; FOSS enthusiasts with experience in datacenter management and automation - even more so.

Feel free to drop me a line privately if interested in more details, and prepare a CV (in English) so I can fast-track you to our HR :) And, again, I ask forgiveness from those who would consider such a message as too much off-topic... please just don't start a flame-war due to this then.




Hope to meet some of you guys in person and work next table one day,
Jim Klimov
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss at openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

--
Typos courtesy of K-9 Mail on my Redmi Android

From danmcd at kebe.com  Wed May 24 17:00:48 2017
From: danmcd at kebe.com (Dan McDonald)
Date: Wed, 24 May 2017 13:00:48 -0400
Subject: [OmniOS-discuss] Fix for no UUID in Kayak-installed BE?
Message-ID: <B80931E7-62F1-48E9-A1D0-F591381CF5A2@kebe.com>

Given the "uuidgen" binary has WAY too many libraries, and the uniqueness of the UUID doesn't need to be super-special for the installed BE, I put together this patch using the existing miniroot tools:


diff --git a/install_help.sh b/install_help.sh
index 7ad5ab1..7095536 100644
--- a/install_help.sh
+++ b/install_help.sh
@@ -115,6 +115,11 @@ BuildBE() {
   $GRAB $MEDIA | pv -B 128m -w 78 | $DECOMP | zfs receive -u $RPOOL/ROOT/omnios
   zfs set canmount=noauto $RPOOL/ROOT/omnios
   zfs set mountpoint=legacy $RPOOL/ROOT/omnios
+  # Generate UUID for BE using existing tools...
+  prtconf -v | md5sum | awk '{print $1}' > /tmp/bits
+  echo "`cut -b1-8 < /tmp/bits`-`cut -b9-12 < /tmp/bits`-`cut -b13-16 < /tmp/bits`-`cut -b17-20 < /tmp/bits`-`cut -b21-32 < /tmp/bits`" > /tmp/uuid
+  zfs set org.opensolaris.libbe:uuid=`cat /tmp/uuid` $RPOOL/ROOT/omnios
+  zfs set org.opensolaris.libbe:policy=static $RPOOL/ROOT/omnios
   log "Cleaning up boot environment"
   beadm mount omnios /mnt
   ALTROOT=/mnt


I initially tested by invoking the prtconf & echo commands, to make sure the resultant UUID looked correct.  I am spinning a bloody ISO as I type this to try and make sure it ACTUALLY works.

Thanks,
Dan



From ozkan.goksu at usishi.com  Thu May 25 13:32:01 2017
From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=)
Date: Thu, 25 May 2017 16:32:01 +0300
Subject: [OmniOS-discuss] NFS & SMB connection freezes 30-40 second
	sometimes.
Message-ID: <CAPu=dv2=UNg-vTOv25_kTgp3hrk7d_4a8EY8nX9=z3Q58ySJJA@mail.gmail.com>

Hello.

I use "omnios-r151020-b5b8c75" and I have small healthy ZFS storage (Zpool
status & Zfs list link <http://healthy>)
The system has been running for about 5 months and  2 times the issue has
occurred.

SMB & NFS both freezes. All jobs are freezes. Vmware freezes.
If i try a new SMB or NFS connection its just waiting... It's like the
whole world is frozen.
But after 30-40 second...... Everything continues as it is and working
properly.

I did a very deep log search, but I could not find anything...
Dmesg clear,
/var/adm/messages clear..
/var/log/syslog clear..

There is not even one log!
Have you ever experienced this problem before?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170525/d12dcaa3/attachment.html>

From danmcd at kebe.com  Thu May 25 13:46:26 2017
From: danmcd at kebe.com (Dan McDonald)
Date: Thu, 25 May 2017 09:46:26 -0400
Subject: [OmniOS-discuss] NFS & SMB connection freezes 30-40 second
 sometimes.
In-Reply-To: <CAPu=dv2=UNg-vTOv25_kTgp3hrk7d_4a8EY8nX9=z3Q58ySJJA@mail.gmail.com>
References: <CAPu=dv2=UNg-vTOv25_kTgp3hrk7d_4a8EY8nX9=z3Q58ySJJA@mail.gmail.com>
Message-ID: <7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com>

r151022 is out now.  Please upgrade to that and see if the problem manifests.

Dan


From ozkan.goksu at usishi.com  Thu May 25 14:09:18 2017
From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=)
Date: Thu, 25 May 2017 17:09:18 +0300
Subject: [OmniOS-discuss] NFS & SMB connection freezes 30-40 second
	sometimes.
In-Reply-To: <7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com>
References: <CAPu=dv2=UNg-vTOv25_kTgp3hrk7d_4a8EY8nX9=z3Q58ySJJA@mail.gmail.com>
	<7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com>
Message-ID: <CAPu=dv3UTA=SNvzH5YyvFHvjmqXqyKorBEL=PgkedHeG4ZWdug@mail.gmail.com>

I will update ofc but i can't shut down right now a storage unit..
Only 2 times in 5 months the problem occurred so i can not track the
problem. I should be ready to find out what it is next time.
I need to solve the issue completely and to solve the problem I need to
understand WHY its happening. Right now I have no idea...

BTW: while the problem occurs I tried to ping my server and Guess what? My
network alives.
BTW 2: I'm using active-active LACP. Could this be the reason?



*?zkan G?KSU* | *Tekn. Geli?tirme* | ozkan.goksu at usishi.com
<goktug.yildirim at usishi.com>
C : +90 555 449 88 71 | T : +90 (216) 442 7070 |
http://www.usishi.com


2017-05-25 16:46 GMT+03:00 Dan McDonald <danmcd at kebe.com>:

> r151022 is out now.  Please upgrade to that and see if the problem
> manifests.
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170525/68b43c7d/attachment.html>

From stephan.budach at jvm.de  Thu May 25 17:35:45 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Thu, 25 May 2017 19:35:45 +0200 (CEST)
Subject: [OmniOS-discuss] NFS & SMB connection freezes 30-40
	second	sometimes.
In-Reply-To: <CAPu=dv3UTA=SNvzH5YyvFHvjmqXqyKorBEL=PgkedHeG4ZWdug@mail.gmail.com>
References: <CAPu=dv2=UNg-vTOv25_kTgp3hrk7d_4a8EY8nX9=z3Q58ySJJA@mail.gmail.com>
	<7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com>
	<CAPu=dv3UTA=SNvzH5YyvFHvjmqXqyKorBEL=PgkedHeG4ZWdug@mail.gmail.com>
Message-ID: <1629457341.396.1495733753931.JavaMail.stephan.budach@stephanbudach.local>

----- Urspr?ngliche Mail ----- 
Hi ?zkan,

> Von: "?zkan G?ksu" <ozkan.goksu at usishi.com>
> An: "Dan McDonald" <danmcd at kebe.com>
> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Donnerstag, 25. Mai 2017 16:09:18
> Betreff: Re: [OmniOS-discuss] NFS & SMB connection freezes 30-40
> second sometimes.

> I will update ofc but i can't shut down right now a storage unit..
> Only 2 times in 5 months the problem occurred so i can not track the
> problem. I should be ready to find out what it is next time.
> I need to solve the issue completely and to solve the problem I need
> to understand WHY its happening. Right now I have no idea...

> BTW: while the problem occurs I tried to ping my server and Guess
> what? My network alives.

I don't seem to understand. Did your host not respond to the pings you sent to it?
I do run a couple of r020 boxes which are part of a RSF-1 cluster and which are serving NFS to a bunch of clients: OracleVM and VMWare. I also have all of my storage/client conencts as "active" LACP connects and I don't have any issues with those.

If you are experiencing network issues, than the rest of your issue might well be caused by that, of course.

> BTW 2: I'm using active-active LACP. Could this be the reason?

> > ?zkan G?KSU | Tekn. Geli?tirme | ozkan.goksu at usishi.com
> 
> > C : +90 555 449 88 71 | T : +90 (216) 442 7070 |
> 
> > http://www.usishi.com
> 

> 2017-05-25 16:46 GMT+03:00 Dan McDonald < danmcd at kebe.com > :

> > r151022 is out now. Please upgrade to that and see if the problem
> > manifests.
> 

> > Dan
> 

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/20170525/711b9b8a/attachment-0001.bin>

From apenner.it at gmail.com  Thu May 25 20:40:31 2017
From: apenner.it at gmail.com (Artem Penner)
Date: Thu, 25 May 2017 23:40:31 +0300
Subject: [OmniOS-discuss] NFS & SMB connection freezes 30-40 second
	sometimes.
In-Reply-To: <CAPu=dv3UTA=SNvzH5YyvFHvjmqXqyKorBEL=PgkedHeG4ZWdug@mail.gmail.com>
References: <CAPu=dv2=UNg-vTOv25_kTgp3hrk7d_4a8EY8nX9=z3Q58ySJJA@mail.gmail.com>
	<7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com>
	<CAPu=dv3UTA=SNvzH5YyvFHvjmqXqyKorBEL=PgkedHeG4ZWdug@mail.gmail.com>
Message-ID: <CAE9csxOrKB8SDRmysW1OxhZt5xVVpZDswAABSbpGpNuYuLEyhw@mail.gmail.com>

Gather network statistics while issue accrue.

*netstat -Td -s 1|awk '/tcpRetrans/||/tcp.*Dup/||/ AM / || / PM /'*


Also check differences between nfs latency and zfs
https://bitbucket.org/d-helios/dtrace/raw/7b479a97099f3146b4d08652315b03d1dfc28f9c/zfs/iomon.d



2017-05-25 17:09 GMT+03:00 ?zkan G?ksu <ozkan.goksu at usishi.com>:

> I will update ofc but i can't shut down right now a storage unit..
> Only 2 times in 5 months the problem occurred so i can not track the
> problem. I should be ready to find out what it is next time.
> I need to solve the issue completely and to solve the problem I need to
> understand WHY its happening. Right now I have no idea...
>
> BTW: while the problem occurs I tried to ping my server and Guess what? My
> network alives.
> BTW 2: I'm using active-active LACP. Could this be the reason?
>
>
>
> *?zkan G?KSU* | *Tekn. Geli?tirme* | ozkan.goksu at usishi.com
> <goktug.yildirim at usishi.com>
> C : +90 555 449 88 71 | T : +90 (216) 442 7070 |
> http://www.usishi.com
>
>
> 2017-05-25 16:46 GMT+03:00 Dan McDonald <danmcd at kebe.com>:
>
>> r151022 is out now.  Please upgrade to that and see if the problem
>> manifests.
>>
>> Dan
>>
>>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170525/ee3b8f5d/attachment.html>

From vab at bb-c.de  Thu May 25 20:51:18 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Thu, 25 May 2017 22:51:18 +0200
Subject: [OmniOS-discuss] Pull request?
Message-ID: <22823.17350.806040.749253@shelob.bb-c.de>

Hello all!


As I pointed out in March, the package service/network/ntp is broken.
Back then, I was told to submit a pull request.  Even though I find it
a bit much to deal with setting up all that infrastrucure at Github
for 14 characters (" overlay=allow") in an IPS manifest, I guess it
is a given that further OmniOS development happens in Github, so there
is no way around it.

Assuming I do have a pull request, what would happen then?  Would 
someone be willing and able to accept it?  Would the fix have to go 
into Bloody first?  Would there be an eventual update to 022 at some
later date?  Who would build and sign the package and roll it out
into the repository?


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

"When logic and proportion have fallen sloppy dead"

From vab at bb-c.de  Fri May 26 07:05:27 2017
From: vab at bb-c.de (Volker A. Brandt)
Date: Fri, 26 May 2017 09:05:27 +0200
Subject: [OmniOS-discuss] Fix for no UUID in Kayak-installed BE?
In-Reply-To: <B80931E7-62F1-48E9-A1D0-F591381CF5A2@kebe.com>
References: <B80931E7-62F1-48E9-A1D0-F591381CF5A2@kebe.com>
Message-ID: <22823.54199.538156.969291@shelob.bb-c.de>

Hi Dan!


> Given the "uuidgen" binary has WAY too many libraries, and the uniqueness of
> the UUID doesn't need to be super-special for the installed BE, I put
> together this patch using the existing miniroot tools: 

BTW your generated UUIDs do not comply with RFC 4122 section 4.4. :-)

I have thought a bit more about this.  We have just installed an entire
operating system, and it's just sitting there in /mnt.  Why can't we
just do a

  LD_LIBRARY_PATH=/mnt/lib:/mnt/usr/lib /mnt/usr/bin/uuidgen ...

?


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

"When logic and proportion have fallen sloppy dead"

From peter.tribble at gmail.com  Fri May 26 10:02:31 2017
From: peter.tribble at gmail.com (Peter Tribble)
Date: Fri, 26 May 2017 11:02:31 +0100
Subject: [OmniOS-discuss] Fix for no UUID in Kayak-installed BE?
In-Reply-To: <B80931E7-62F1-48E9-A1D0-F591381CF5A2@kebe.com>
References: <B80931E7-62F1-48E9-A1D0-F591381CF5A2@kebe.com>
Message-ID: <CAEgYsbH-KrkNBn=kH8jgzbF9HV=oenbEQ9uQEYHW4wLyiWHFBQ@mail.gmail.com>

On Wed, May 24, 2017 at 6:00 PM, Dan McDonald <danmcd at kebe.com> wrote:

> Given the "uuidgen" binary has WAY too many libraries, and the uniqueness
> of the UUID doesn't need to be super-special for the installed BE, I put
> together this patch using the existing miniroot tools:
>
>
> diff --git a/install_help.sh b/install_help.sh
> index 7ad5ab1..7095536 100644
> --- a/install_help.sh
> +++ b/install_help.sh
> @@ -115,6 +115,11 @@ BuildBE() {
>    $GRAB $MEDIA | pv -B 128m -w 78 | $DECOMP | zfs receive -u
> $RPOOL/ROOT/omnios
>    zfs set canmount=noauto $RPOOL/ROOT/omnios
>    zfs set mountpoint=legacy $RPOOL/ROOT/omnios
> +  # Generate UUID for BE using existing tools...
> +  prtconf -v | md5sum | awk '{print $1}' > /tmp/bits
> +  echo "`cut -b1-8 < /tmp/bits`-`cut -b9-12 < /tmp/bits`-`cut -b13-16 <
> /tmp/bits`-`cut -b17-20 < /tmp/bits`-`cut -b21-32 < /tmp/bits`" > /tmp/uuid
> +  zfs set org.opensolaris.libbe:uuid=`cat /tmp/uuid` $RPOOL/ROOT/omnios
> +  zfs set org.opensolaris.libbe:policy=static $RPOOL/ROOT/omnios
>    log "Cleaning up boot environment"
>    beadm mount omnios /mnt
>    ALTROOT=/mnt
>
>
> I initially tested by invoking the prtconf & echo commands, to make sure
> the resultant UUID looked correct.  I am spinning a bloody ISO as I type
> this to try and make sure it ACTUALLY works.
>

ptrconf -v isn't terribly random - it looks like you get a fairly small set.

My version (lifted from Tribblix) would look like

head -c 32 /dev/urandom | md5sum | awk '{print $1}' > /tmp/bits
echo "`cut -b1-8 < /tmp/bits`-`cut -b9-12 < /tmp/bits`-5`cut -b14-16 <
/tmp/bits`-9`cut -b18-20 < /tmp/bits`-`cut -b21-32 < /tmp/bits`" > /tmp/uuid

-- 
-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/20170526/45d6462d/attachment.html>

From ozkan.goksu at usishi.com  Fri May 26 12:15:41 2017
From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=)
Date: Fri, 26 May 2017 15:15:41 +0300
Subject: [OmniOS-discuss] NFS & SMB connection freezes 30-40 second
	sometimes.
In-Reply-To: <1629457341.396.1495733753931.JavaMail.stephan.budach@stephanbudach.local>
References: <CAPu=dv2=UNg-vTOv25_kTgp3hrk7d_4a8EY8nX9=z3Q58ySJJA@mail.gmail.com>
	<7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com>
	<CAPu=dv3UTA=SNvzH5YyvFHvjmqXqyKorBEL=PgkedHeG4ZWdug@mail.gmail.com>
	<1629457341.396.1495733753931.JavaMail.stephan.budach@stephanbudach.local>
Message-ID: <CAPu=dv3k+Jj7wwD5tTSWAs1VDE=kGTH8JTfH810GMO_EhDHT3g@mail.gmail.com>

Hello Stephan.

My english ain't good sorry for that.
Host responding and i dont see any problem but NFS & Cifs Shares not
responding..
I could not telnet because there was not enough time for test. Everything
is happening in 15-45 seconds.

@Artem Penner
Thank you for the command and link. I will do that next time.


*?zkan G?KSU* | *Tekn. Geli?tirme* | ozkan.goksu at usishi.com
<goktug.yildirim at usishi.com>
C : +90 555 449 88 71 | T : +90 (216) 442 7070 |
http://www.usishi.com


2017-05-25 20:35 GMT+03:00 Stephan Budach <stephan.budach at jvm.de>:

> ----- Urspr?ngliche Mail -----
> Hi ?zkan,
>
> > Von: "?zkan G?ksu" <ozkan.goksu at usishi.com>
> > An: "Dan McDonald" <danmcd at kebe.com>
> > CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> > Gesendet: Donnerstag, 25. Mai 2017 16:09:18
> > Betreff: Re: [OmniOS-discuss] NFS & SMB connection freezes 30-40
> > second sometimes.
>
> > I will update ofc but i can't shut down right now a storage unit..
> > Only 2 times in 5 months the problem occurred so i can not track the
> > problem. I should be ready to find out what it is next time.
> > I need to solve the issue completely and to solve the problem I need
> > to understand WHY its happening. Right now I have no idea...
>
> > BTW: while the problem occurs I tried to ping my server and Guess
> > what? My network alives.
>
> I don't seem to understand. Did your host not respond to the pings you
> sent to it?
> I do run a couple of r020 boxes which are part of a RSF-1 cluster and
> which are serving NFS to a bunch of clients: OracleVM and VMWare. I also
> have all of my storage/client conencts as "active" LACP connects and I
> don't have any issues with those.
>
> If you are experiencing network issues, than the rest of your issue might
> well be caused by that, of course.
>
> > BTW 2: I'm using active-active LACP. Could this be the reason?
>
> > > ?zkan G?KSU | Tekn. Geli?tirme | ozkan.goksu at usishi.com
> >
> > > C : +90 555 449 88 71 | T : +90 (216) 442 7070 |
> >
> > > http://www.usishi.com
> >
>
> > 2017-05-25 16:46 GMT+03:00 Dan McDonald < danmcd at kebe.com > :
>
> > > r151022 is out now. Please upgrade to that and see if the problem
> > > manifests.
> >
>
> > > Dan
> >
>
> Cheers,
> Stephan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170526/7fbf3ae4/attachment-0001.html>

From stephan.budach at jvm.de  Fri May 26 12:18:07 2017
From: stephan.budach at jvm.de (Stephan Budach)
Date: Fri, 26 May 2017 14:18:07 +0200 (CEST)
Subject: [OmniOS-discuss] =?utf-8?q?Trying_to_update_r018_to_r022=2C_but_p?=
	=?utf-8?q?kg_responds=E2=80=A6?=
In-Reply-To: <219333932.564.1495801071780.JavaMail.stephan.budach@stephanbudach.local>
Message-ID: <333568090.569.1495801094705.JavaMail.stephan.budach@stephanbudach.local>

?No updates available for this image. 



I am pretty sure, that I did try the update just the same way, I always did: 



pkg set-publisher -G '*' -g https://pkg.omniti.com/omnios/r151022/ omnios 
pkg refresh --full 
pkg update -v --be-name=OmniOS-r151022 entire 




What did I miss? 


Thx, 
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170526/edc7ce31/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/20170526/edc7ce31/attachment.bin>

From tobi at oetiker.ch  Fri May 26 12:37:34 2017
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Fri, 26 May 2017 14:37:34 +0200 (CEST)
Subject: [OmniOS-discuss] NFS & SMB connection freezes 30-40
	second	sometimes.
In-Reply-To: <CAPu=dv3k+Jj7wwD5tTSWAs1VDE=kGTH8JTfH810GMO_EhDHT3g@mail.gmail.com>
References: <CAPu=dv2=UNg-vTOv25_kTgp3hrk7d_4a8EY8nX9=z3Q58ySJJA@mail.gmail.com>
	<7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com>
	<CAPu=dv3UTA=SNvzH5YyvFHvjmqXqyKorBEL=PgkedHeG4ZWdug@mail.gmail.com>
	<1629457341.396.1495733753931.JavaMail.stephan.budach@stephanbudach.local>
	<CAPu=dv3k+Jj7wwD5tTSWAs1VDE=kGTH8JTfH810GMO_EhDHT3g@mail.gmail.com>
Message-ID: <2118474247.574515.1495802254743.JavaMail.zimbra@oetiker.ch>

Hi ?zkan, 

you are not by any chance running rcapd ? 

if so, try to NOT do that ... 

cheers 
tobi 

----- On May 26, 2017, at 2:15 PM, ?zkan G?ksu <ozkan.goksu at usishi.com> wrote: 

> Hello Stephan.
> My english ain't good sorry for that.
> Host responding and i dont see any problem but NFS & Cifs Shares not
> responding..
> I could not telnet because there was not enough time for test. Everything is
> happening in 15-45 seconds.

> @Artem Penner
> Thank you for the command and link. I will do that next time.

>>		?zkan G?KSU | Tekn. Geli?tirme | [ mailto:goktug.yildirim at usishi.com |
>> 		ozkan.goksu at usishi.com ]
>> C : +90 555 449 88 71 | T : +90 (216) 442 7070 |
>> [ http://www.usishi.com/ | http://www.usishi.com ]

> 2017-05-25 20:35 GMT+03:00 Stephan Budach < [ mailto:stephan.budach at jvm.de |
> stephan.budach at jvm.de ] > :

>> ----- Urspr?ngliche Mail -----
>> Hi ?zkan,

>>> Von: "?zkan G?ksu" < [ mailto:ozkan.goksu at usishi.com | ozkan.goksu at usishi.com ]
>> > >
>> > An: "Dan McDonald" < [ mailto:danmcd at kebe.com | danmcd at kebe.com ] >
>>> CC: "omnios-discuss" < [ mailto:omnios-discuss at lists.omniti.com |
>> > omnios-discuss at lists.omniti.com ] >
>> > Gesendet: Donnerstag, 25. Mai 2017 16:09:18
>> > Betreff: Re: [OmniOS-discuss] NFS & SMB connection freezes 30-40
>> > second sometimes.

>> > I will update ofc but i can't shut down right now a storage unit..
>> > Only 2 times in 5 months the problem occurred so i can not track the
>> > problem. I should be ready to find out what it is next time.
>> > I need to solve the issue completely and to solve the problem I need
>> > to understand WHY its happening. Right now I have no idea...

>> > BTW: while the problem occurs I tried to ping my server and Guess
>> > what? My network alives.

>> I don't seem to understand. Did your host not respond to the pings you sent to
>> it?
>> I do run a couple of r020 boxes which are part of a RSF-1 cluster and which are
>> serving NFS to a bunch of clients: OracleVM and VMWare. I also have all of my
>> storage/client conencts as "active" LACP connects and I don't have any issues
>> with those.

>> If you are experiencing network issues, than the rest of your issue might well
>> be caused by that, of course.

>> > BTW 2: I'm using active-active LACP. Could this be the reason?

>>> > ?zkan G?KSU | Tekn. Geli?tirme | [ mailto:ozkan.goksu at usishi.com |
>> > > ozkan.goksu at usishi.com ]

>>> > C : [ tel:%2B90%20555%20449%2088%2071 | +90 555 449 88 71 ] | T : [
>> > > tel:%2B90%20%28216%29%20442%207070 | +90 (216) 442 7070 ] |

>> > > [ http://www.usishi.com/ | http://www.usishi.com ]


>>> 2017-05-25 16:46 GMT+03:00 Dan McDonald < [ mailto:danmcd at kebe.com |
>> > danmcd at kebe.com ] > :

>> > > r151022 is out now. Please upgrade to that and see if the problem
>> > > manifests.


>> > > Dan


>> Cheers,
>> Stephan

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

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

From peter at ifm.liu.se  Mon May 29 06:50:34 2017
From: peter at ifm.liu.se (Peter Eriksson)
Date: Mon, 29 May 2017 08:50:34 +0200
Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed
In-Reply-To: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net>
References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net>
Message-ID: <A2597F87-081A-460E-A7A4-9EFAF0713D2F@ifm.liu.se>

For what it?s worth I?ve seen the same error message on a Dell server that happened to have 10TB-drives (not the boot disks!) that was formatted using 4104-bytes sectors in order to support the T10-PI/DIF & T10-DIF standards. The errors started to occur when we replaced the RAID controller with an HBA. Non 512/4096-bytes sectors apparently confused the boot loader when scanning the drives for the boot zpool. This was on a FreeBSD system though. The solution was to perform a low level reformatting of the drives in to standard 4096 byte sectors.


https://en.wikipedia.org/wiki/Data_Integrity_Field <https://en.wikipedia.org/wiki/Data_Integrity_Field>

https://access.redhat.com/solutions/41548

http://www.enterprisestorageforum.com/storage-technology/sas-vs.-sata-4.html <http://www.enterprisestorageforum.com/storage-technology/sas-vs.-sata-4.html>


?
[L?.U] System Administrator ITI-NET IT.LiU.SE +46-13-28 2786

> On 18 May 2017, at 21:55, Geoff Nordli <geoffn at gnaa.net> wrote:
> 
> Hi.
> 
> I upgraded to the latest r151022 version.  The upgrade went fine, rebooted the machine, then upgraded to the new loader.
> 
> When i rebooted after the loader upgrade, I got an error message:
> 
> panic: bd_strategy: 512 bytes I/O not multiple of block size.
> 
> press a key on the console to reboot....
> 
> Rebooting...
> 
> panic free: guard1 fail @ 0x2e2e2e67 from ../../common/devopen.c:64
> 
> The boot disk is an 80GB intel ssd.
> 
> Any thoughts?
> 
> thanks,
> 
> Geoff
> 
> _______________________________________________
> 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/20170529/b7c3f123/attachment-0001.html>

From grzempek at gmail.com  Tue May 30 18:44:29 2017
From: grzempek at gmail.com (Krzysztof Grzempa)
Date: Tue, 30 May 2017 20:44:29 +0200
Subject: [OmniOS-discuss] mod_wsgi for apache24
Message-ID: <CAED-Y_CVOA9YUQ0r7VyK8aBcYHXD_uq3AqNeeVdApG+afie_hw@mail.gmail.com>

Hi,
I need mod_wsgi for apache24 as it is required by django to work with. The
only mod_wsgi i found is for apache22. Anyone knows where can i get
apache24 version?

root at mojvps:/root# pkg search wsgi
INDEX       ACTION VALUE                                     PACKAGE
pkg.descr   set    Python WSGI adapter module for Apache 2.2
pkg:/omniti/server/apache22/mod_wsgi at 3.3-0.151014
pkg.summary set    Python WSGI adapter module for Apache 2.2
pkg:/omniti/server/apache22/mod_wsgi at 3.3-0.151014

Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170530/fbaab53f/attachment.html>

From mailinglists at qutic.com  Tue May 30 20:18:41 2017
From: mailinglists at qutic.com (qutic development)
Date: Tue, 30 May 2017 22:18:41 +0200
Subject: [OmniOS-discuss] mod_wsgi for apache24
In-Reply-To: <CAED-Y_CVOA9YUQ0r7VyK8aBcYHXD_uq3AqNeeVdApG+afie_hw@mail.gmail.com>
References: <CAED-Y_CVOA9YUQ0r7VyK8aBcYHXD_uq3AqNeeVdApG+afie_hw@mail.gmail.com>
Message-ID: <A116A028-BF2C-415D-8864-FDAC364D5AAF@qutic.com>

> I need mod_wsgi for apache24 as it is required by django to work with. The only mod_wsgi i found is for apache22. Anyone knows where can i get apache24 version? 

pkgsrc has it in the current repo:

http://pkgsrc.joyent.com/packages/SmartOS/2017Q1/multiarch/All/

- Stefan

From alka at hfg-gmuend.de  Tue May 30 20:28:42 2017
From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=)
Date: Tue, 30 May 2017 22:28:42 +0200
Subject: [OmniOS-discuss] mod_wsgi for apache24
In-Reply-To: <CAED-Y_CVOA9YUQ0r7VyK8aBcYHXD_uq3AqNeeVdApG+afie_hw@mail.gmail.com>
References: <CAED-Y_CVOA9YUQ0r7VyK8aBcYHXD_uq3AqNeeVdApG+afie_hw@mail.gmail.com>
Message-ID: <d711cc79-e46f-ce89-bbce-042d29fd40ab@hfg-gmuend.de>

py27-ap24-mod_wsgi-4.4.12.tgz from

https://pkgsrc.joyent.com/packages/SmartOS/2017Q1/x86_64/All/
setup, https://pkgsrc.joyent.com/install-on-illumos/ (work on OmniOS)

Gea

Am 30.05.2017 um 20:44 schrieb Krzysztof Grzempa:
> Hi,
> I need mod_wsgi for apache24 as it is required by django to work with. 
> The only mod_wsgi i found is for apache22. Anyone knows where can i 
> get apache24 version?
>
> root at mojvps:/root# pkg search wsgi
> INDEX       ACTION VALUE PACKAGE
> pkg.descr   set    Python WSGI adapter module for Apache 2.2 
> pkg:/omniti/server/apache22/mod_wsgi at 3.3-0.151014
> pkg.summary set    Python WSGI adapter module for Apache 2.2 
> pkg:/omniti/server/apache22/mod_wsgi at 3.3-0.151014
>
> Regards,
> Chris
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

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

From geoffn at gnaa.net  Tue May 30 21:34:04 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Tue, 30 May 2017 14:34:04 -0700
Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed
In-Reply-To: <A2597F87-081A-460E-A7A4-9EFAF0713D2F@ifm.liu.se>
References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net>
	<A2597F87-081A-460E-A7A4-9EFAF0713D2F@ifm.liu.se>
Message-ID: <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net>



On 2017-05-28 11:50 PM, Peter Eriksson wrote:
> For what it?s worth I?ve seen the same error message on a Dell server 
> that happened to have 10TB-drives (not the boot disks!) that was 
> formatted using 4104-bytes sectors in order to support the T10-PI/DIF 
> & T10-DIF standards. The errors started to occur when we replaced the 
> RAID controller with an HBA. Non 512/4096-bytes sectors apparently 
> confused the boot loader when scanning the drives for the boot zpool. 
> This was on a FreeBSD system though. The solution was to perform a low 
> level reformatting of the drives in to standard 4096 byte sectors.
>
>
> https://en.wikipedia.org/wiki/Data_Integrity_Field
>
> https://access.redhat.com/solutions/41548
>
> http://www.enterprisestorageforum.com/storage-technology/sas-vs.-sata-4.html
>
>
> ?
> [L?.U] System Administrator ITI-NET IT.LiU.SE +46-13-28 2786
>
>> On 18 May 2017, at 21:55, Geoff Nordli <geoffn at gnaa.net 
>> <mailto:geoffn at gnaa.net>> wrote:
>>
>> Hi.
>>
>> I upgraded to the latest r151022 version.  The upgrade went fine, 
>> rebooted the machine, then upgraded to the new loader.
>>
>> When i rebooted after the loader upgrade, I got an error message:
>>
>> panic: bd_strategy: 512 bytes I/O not multiple of block size.
>>
>> press a key on the console to reboot....
>>
>> Rebooting...
>>
>> panic free: guard1 fail @ 0x2e2e2e67 from ../../common/devopen.c:64
>>
>> The boot disk is an 80GB intel ssd.
>>
>> Any thoughts?
>>
>> thanks,
>>
>> Geoff


follow up on this.

The issue is with 4kn disks.

Toomas provided an updated boot loader and I was able to get the system 
back online again.

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

thanks,
Geoff


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

From henson at acm.org  Tue May 30 22:23:55 2017
From: henson at acm.org (Paul B. Henson)
Date: Tue, 30 May 2017 15:23:55 -0700
Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed
In-Reply-To: <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net>
References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net>
	<A2597F87-081A-460E-A7A4-9EFAF0713D2F@ifm.liu.se>
	<9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net>
Message-ID: <20170530222354.GM20300@bender.unx.cpp.edu>

On Tue, May 30, 2017 at 02:34:04PM -0700, Geoff Nordli wrote:

> The issue is with 4kn disks.

To clarify, any OmniOS system with 4K sector disks, even if they're *not*
used for the rpool, won't boot after upgrading to r151022?


From geoffn at gnaa.net  Wed May 31 02:57:21 2017
From: geoffn at gnaa.net (Geoff Nordli)
Date: Tue, 30 May 2017 19:57:21 -0700
Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed
In-Reply-To: <20170530222354.GM20300@bender.unx.cpp.edu>
References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net>
	<A2597F87-081A-460E-A7A4-9EFAF0713D2F@ifm.liu.se>
	<9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net>
	<20170530222354.GM20300@bender.unx.cpp.edu>
Message-ID: <ebb83842-5aef-1d78-7e40-78377e9c1a75@gnaa.net>


On 2017-05-30 03:23 PM, Paul B. Henson wrote:
> On Tue, May 30, 2017 at 02:34:04PM -0700, Geoff Nordli wrote:
>
>> The issue is with 4kn disks.
> To clarify, any OmniOS system with 4K sector disks, even if they're *not*
> used for the rpool, won't boot after upgrading to r151022?
>

Right, it will not boot after upgrading to the new loader; even if the 
4K disks are not part of the rpool.




