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: 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: 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: References: 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: 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: References: Message-ID: On May 2, 2017 10:48:16 AM GMT+03:00, "?zkan G?ksu" 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: References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> Message-ID: On Thu, Apr 27, 2017 at 4:07 PM, Peter Tribble wrote: > On Thu, Apr 27, 2017 at 12:21 AM, Robert Treat 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: $ 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: References: Message-ID: 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 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: 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: 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 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: 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: 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: 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: References: Message-ID: > On May 5, 2017, at 11:32 PM, Artyom Zhandarovsky 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: 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: Message-ID: For anyone using Debian in an LX zone... Dan > Begin forwarded message: > > From: "Christopher Horrell" > Subject: Re: [smartos-discuss] Problem updating Debian 8.7 (jessie) zone > Date: May 8, 2017 at 10:11:02 AM EDT > To: SmartOs Discuss > 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 > > See the last comment for a workaround > > On Sun, May 7, 2017 at 6:53 PM Jesus Cea > 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 - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ > Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ > jabber / xmpp:jcea 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 > -- > Christopher Horrell > Joyent Inc. > http://www.joyent.com/ > smartos-discuss | Archives | Modify Your Subscription -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: 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 : > 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: 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: 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: References: Message-ID: 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 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: 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: References: 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 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 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: 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: <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 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 > 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: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> Message-ID: 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 wrote: > > > On May 9, 2017, at 10:30 AM, Dan McDonald 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 > > 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: 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: <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 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> > 0x7fffff0470f0/D 0x7fffff0470f0: 2147483647 > 0x7fffff0470f0/X 0x7fffff0470f0: 7fffffff > 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: 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: 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: References: Message-ID: <40557F43-E0F3-4671-9200-DDBCDE2FD165@omniti.com> > On May 9, 2017, at 3:32 PM, Schweiss, Chip 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: <40557F43-E0F3-4671-9200-DDBCDE2FD165@omniti.com> Message-ID: 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 wrote: > > > On May 9, 2017, at 3:32 PM, Schweiss, Chip 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: 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: References: <40557F43-E0F3-4671-9200-DDBCDE2FD165@omniti.com> Message-ID: <473587A0-4632-401B-98DE-DF0DA8C0719E@omniti.com> > On May 9, 2017, at 4:40 PM, Schweiss, Chip wrote: > > Here's the screen shot: 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: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com> Message-ID: 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 wrote: > > > On May 9, 2017, at 11:05 AM, Dan McDonald 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> > > Usage: step [ over | out ] [SIG] > > 0x7fffff0470f0 > > 0x7fffff0470f0/D > 0x7fffff0470f0: 2147483647 > > 0x7fffff0470f0/X > 0x7fffff0470f0: 7fffffff > > mdb: failed to read data from target: no mapping for address > 0x761133e5: > > 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: 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: References: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.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 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: 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: 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: References: Message-ID: 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 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: 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: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com> <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com> Message-ID: 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 wrote: > Wow, thank you for the further deep-diving. > > > On May 10, 2017, at 5:21 AM, Ludovic Orban 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: 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: References: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com> <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com> Message-ID: 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 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 wrote: >> Wow, thank you for the further deep-diving. >> >> > On May 10, 2017, at 5:21 AM, Ludovic Orban 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: 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: References: Message-ID: <5D3C2ED4-AEBC-4A90-92BF-23E80E153E77@richardelling.com> > On May 10, 2017, at 8:29 AM, Schweiss, Chip 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: 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: <5D3C2ED4-AEBC-4A90-92BF-23E80E153E77@richardelling.com> Message-ID: On 10 May 2017 at 16:22, Richard Elling 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: References: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com> <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com> Message-ID: 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 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 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 wrote: > >> Wow, thank you for the further deep-diving. >> >> > On May 10, 2017, at 5:21 AM, Ludovic Orban 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: 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: References: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com> <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com> Message-ID: On Thu, May 11, 2017 at 5:11 AM, Ludovic Orban 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 5.11 joyent_20161110T013148Z i86pc i386 i86pc 99994 In an Ubuntu 16.04 LX zone: # uname -a; ulimit -u Linux 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: References: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com> <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com> Message-ID: <5960A1AB-73ED-45ED-A833-5C82CE6425F1@omniti.com> > On May 11, 2017, at 5:11 AM, Ludovic Orban 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: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com> <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.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: References: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com> <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com> Message-ID: <20170511163329.40c993e4@sleipner.datanom.net> On Thu, 11 May 2017 11:11:14 +0200 Ludovic Orban 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: <9095028D-7EC9-4C5A-B4D3-D42CC5AA39F0@omniti.com> <5D760A9E-FE7B-4E74-91C3-DDC786D48697@omniti.com> <8CF86E2B-0A51-4C17-963E-752EB8489A67@omniti.com> <3083CFD0-3070-42B7-8868-C2B813D9399A@omniti.com> <20170511163329.40c993e4@sleipner.datanom.net> Message-ID: 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 #include #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 wrote: > On Thu, 11 May 2017 11:11:14 +0200 > Ludovic Orban 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 rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > /usr/games/fortune -es says: > 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: 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 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" 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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 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 /publisher/omnios/file/93/93793132e4e2039425a415bb121e5faf26fe7785 > /etc/ssl/pkg/OmniTI_CA2.pem gzip -cd /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: 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: 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 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: References: <8ADE0BAB-6590-449C-81CD-B401D4C0CF90@omniti.com> Message-ID: 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 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: 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 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: 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 : > On May 12, 2017 6:07:01 PM GMT+03:00, 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 > > 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: 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: On Fri, May 12, 2017 at 4:50 PM, Dan McDonald 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: 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: ... I 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: 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: > On May 12, 2017, at 2:50 PM, Michael Rasmussen wrote: > > On Fri, 12 May 2017 10:50:50 -0400 > Dan McDonald 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: > On May 12, 2017, at 2:55 PM, Michael Rasmussen 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: References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com> <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com> <20170512205010.3e0385bc@sleipner.datanom.net> Message-ID: <20170512211337.26005a55@sleipner.datanom.net> On Fri, 12 May 2017 14:59:49 -0400 Dan McDonald 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <20170512211337.26005a55@sleipner.datanom.net> Message-ID: <0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com> > On May 12, 2017, at 3:13 PM, Michael Rasmussen 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 " 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> <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 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 " 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: The 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: 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> <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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <20170512211337.26005a55@sleipner.datanom.net> <0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com> <20170512212112.704044c2@sleipner.datanom.net> <20170512220005.4ee29b8e@sleipner.datanom.net> Message-ID: > On May 12, 2017, at 4:00 PM, Michael Rasmussen wrote: > > On Fri, 12 May 2017 21:21:12 +0200 > Michael Rasmussen 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: 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 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: 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: References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com> <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com> Message-ID: <50E3F441-E73E-436A-8992-5571FE3903B9@omniti.com> > On May 12, 2017, at 5:15 PM, Ian Kaufman 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: References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com> <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com> <20170512205010.3e0385bc@sleipner.datanom.net> <20170512211337.26005a55@sleipner.datanom.net> <0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com> <20170512212112.704044c2@sleipner.datanom.net> <20170512220005.4ee29b8e@sleipner.datanom.net> Message-ID: <20170512232154.03e4fc1a@sleipner.datanom.net> On Fri, 12 May 2017 16:12:09 -0400 Dan McDonald 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <20170512211337.26005a55@sleipner.datanom.net> <0F2E2DB8-6701-4C0F-BC81-C63AB6BCB4A9@omniti.com> <20170512212112.704044c2@sleipner.datanom.net> <20170512220005.4ee29b8e@sleipner.datanom.net> <20170512232154.03e4fc1a@sleipner.datanom.net> Message-ID: <91D8CA2A-BB75-4CA1-9BA7-A1871C21D2C0@omniti.com> > On May 12, 2017, at 5:21 PM, Michael Rasmussen 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: 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: 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 of "Fri, 12 May 2017 20:18:22 +0200." 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 > Date: Fri, 12 May 2017 20:18:22 +0200 > To: > 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 : > > > On May 12, 2017 6:07:01 PM GMT+03:00, 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 > > > > 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 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 >> Date: Fri, 12 May 2017 20:18:22 +0200 >> To: >> 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 : >> >>> On May 12, 2017 6:07:01 PM GMT+03:00, 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 >>> >>> 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: 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: 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: 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: 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: References: Message-ID: So, where are we at the moment? Any conclusions? Decisions? Plans? regards 2017-05-13 0:20 GMT+02:00 Joseph Boren : > 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: 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: References: Message-ID: <20170515053722.7c509bca@landcroft.co.uk> On Sun, 14 May 2017 17:33:56 +0200 Krzysztof Grzempa 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: 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: <20170515053722.7c509bca@landcroft.co.uk> Message-ID: 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" wrote: > On Sun, 14 May 2017 17:33:56 +0200 > Krzysztof Grzempa 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: 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: References: Message-ID: <84BA8D68-7691-427B-91B1-2678B3D8659B@omniti.com> > On May 14, 2017, at 5:33 PM, Andy Fiddaman 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: References: <20170515053722.7c509bca@landcroft.co.uk> Message-ID: <20170515073735.53cbce9d@sleipner.datanom.net> On Sun, 14 May 2017 19:10:32 -0400 Theo Schlossnagle 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: References: <20170515053722.7c509bca@landcroft.co.uk> 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: <20170515053722.7c509bca@landcroft.co.uk> <22809.16171.978855.391644@shelob.bb-c.de> Message-ID: hi, On Mon, May 15, 2017 at 7:39 AM, Volker A. Brandt 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: 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: References: <20170515053722.7c509bca@landcroft.co.uk> Message-ID: 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 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" wrote: >> On Sun, 14 May 2017 17:33:56 +0200 >> Krzysztof Grzempa 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: 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: References: <20170515053722.7c509bca@landcroft.co.uk> Message-ID: 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 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" > wrote: > >> On Sun, 14 May 2017 17:33:56 +0200 >> Krzysztof Grzempa 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: 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: <84BA8D68-7691-427B-91B1-2678B3D8659B@omniti.com> Message-ID: On Sun, 14 May 2017, Dan McDonald wrote: ; > On May 14, 2017, at 5:33 PM, Andy Fiddaman 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: References: <20170515053722.7c509bca@landcroft.co.uk> Message-ID: 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: References: <20170515053722.7c509bca@landcroft.co.uk> 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: 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: 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 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 > > | > Modify > > Your Subscription > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <20170515053722.7c509bca@landcroft.co.uk> <20170515073735.53cbce9d@sleipner.datanom.net> Message-ID: 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 wrote: > On Sun, 14 May 2017 19:10:32 -0400 > Theo Schlossnagle 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 rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > /usr/games/fortune -es says: > 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: 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: 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: References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com> <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com> 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 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: 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: References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com> <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com> Message-ID: <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com> > On May 15, 2017, at 12:49 PM, Dominik Hassler 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/ 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: <20170515053722.7c509bca@landcroft.co.uk> <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: References: <20170515053722.7c509bca@landcroft.co.uk> Message-ID: 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" > wrote: > >> On Sun, 14 May 2017 17:33:56 +0200 >> Krzysztof Grzempa 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: 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> <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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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 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: References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com> <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com> <20170513213449.00a994aa@sleipner.datanom.net> Message-ID: 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: <20170515053722.7c509bca@landcroft.co.uk> <20170515073735.53cbce9d@sleipner.datanom.net> Message-ID: <20170515224610.08b5cc56@sleipner.datanom.net> On Mon, 15 May 2017 07:37:35 +0200 Michael Rasmussen 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: He 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: 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: References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com> <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com> <20170513213449.00a994aa@sleipner.datanom.net> Message-ID: <20170515225110.5a422613@sleipner.datanom.net> On Mon, 15 May 2017 15:40:36 -0500 (CDT) Bob Friesenhahn 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: "I 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: 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: <20170515053722.7c509bca@landcroft.co.uk> <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 wrote: > > On Mon, 15 May 2017 07:37:35 +0200 > Michael Rasmussen 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: <20170515053722.7c509bca@landcroft.co.uk> <20170515073735.53cbce9d@sleipner.datanom.net> <20170515224610.08b5cc56@sleipner.datanom.net> Message-ID: 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 wrote: > On Mon, 15 May 2017 07:37:35 +0200 > Michael Rasmussen 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 rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > /usr/games/fortune -es says: > He 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: 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: References: <20170515053722.7c509bca@landcroft.co.uk> <20170515073735.53cbce9d@sleipner.datanom.net> <20170515224610.08b5cc56@sleipner.datanom.net> Message-ID: <20170515231639.64159c3e@sleipner.datanom.net> On Mon, 15 May 2017 17:08:18 -0400 Theo Schlossnagle 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: "...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: 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: <20170515053722.7c509bca@landcroft.co.uk> <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 wrote: > On Mon, 15 May 2017 07:37:35 +0200 > Michael Rasmussen 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: > On May 15, 2017, at 5:20 PM, Philip Cristiano 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: <20170515053722.7c509bca@landcroft.co.uk> <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 wrote: > >> On Mon, 15 May 2017 07:37:35 +0200 >> Michael Rasmussen 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: <20170515053722.7c509bca@landcroft.co.uk> <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 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 wrote: > > > >> On Mon, 15 May 2017 07:37:35 +0200 > >> Michael Rasmussen 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: To 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: 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: <20170515053722.7c509bca@landcroft.co.uk> <20170515073735.53cbce9d@sleipner.datanom.net> <20170515224610.08b5cc56@sleipner.datanom.net> <20170515232047.1b2a5806@sleipner.datanom.net> <641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch> Message-ID: 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" 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 wrote: > > > >> On Mon, 15 May 2017 07:37:35 +0200 > >> Michael Rasmussen 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: 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: References: <20170515053722.7c509bca@landcroft.co.uk> <20170515073735.53cbce9d@sleipner.datanom.net> <20170515224610.08b5cc56@sleipner.datanom.net> <20170515232047.1b2a5806@sleipner.datanom.net> <641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch> 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" 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 wrote: >> > >> >> On Mon, 15 May 2017 07:37:35 +0200 >> >> Michael Rasmussen 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: 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: <20170515053722.7c509bca@landcroft.co.uk> <20170515073735.53cbce9d@sleipner.datanom.net> <20170515224610.08b5cc56@sleipner.datanom.net> <20170515232047.1b2a5806@sleipner.datanom.net> <641510339.173331.1494884300293.JavaMail.zimbra@oetiker.ch> <1494904405.377808.977833632.39936897@webmail.messagingengine.com> Message-ID: 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 : > 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" 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 wrote: > > > >> On Mon, 15 May 2017 07:37:35 +0200 > >> Michael Rasmussen 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: 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> <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com> <6A4F3374-1241-4ED3-9451-255AE5BBDE57@me.com> Message-ID: 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 wrote: >> >> >>> On May 15, 2017, at 12:49 PM, Dominik Hassler 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/ >> >> 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: 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: 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: References: Message-ID: 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: 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: References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com> <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com> <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com> <6A4F3374-1241-4ED3-9451-255AE5BBDE57@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 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 wrote: >>>> >>>> >>>>> On May 15, 2017, at 12:49 PM, Dominik Hassler 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/ >>>> >>>> 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: References: Message-ID: <20170516161724.4b73167b@sleipner.datanom.net> On Tue, 16 May 2017 09:22:11 -0400 Theo Schlossnagle 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: "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: 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: References: Message-ID: <20170516161923.6a80f99f@sleipner.datanom.net> On Tue, 16 May 2017 09:22:11 -0400 Theo Schlossnagle 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: "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: 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: References: 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 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: 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: <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 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 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: <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 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: <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 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> <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com> <6A4F3374-1241-4ED3-9451-255AE5BBDE57@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 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 wrote: >>>>> >>>>> >>>>>> On May 15, 2017, at 12:49 PM, Dominik Hassler >>>>>> 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/ >>>>> >>>>> 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: 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: <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 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: <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 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> <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com> <6A4F3374-1241-4ED3-9451-255AE5BBDE57@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: References: Message-ID: On Tue, May 16, 2017 at 2:22 PM, 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. > 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: 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> <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com> <6A4F3374-1241-4ED3-9451-255AE5BBDE57@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> <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com> <6A4F3374-1241-4ED3-9451-255AE5BBDE57@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: Could it be bad sectors in the boot block? On May 16, 2017 10:35:44 PM GMT+02:00, Dominik Hassler 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: 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 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: > On May 16, 2017, at 5:22 PM, Dan McDonald 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: 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: 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: References: 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: 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: References: <74FA8364-13BF-47BC-B02C-7E1588CF1B8D@omniti.com> <95BF27D0-1DA7-4455-806F-9A04F4209EFF@omniti.com> <0B35DB80-8363-40EC-AA4C-A68D988E9016@omniti.com> <6A4F3374-1241-4ED3-9451-255AE5BBDE57@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: <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> <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> <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" > 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: 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: 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: <3fca71ba-e7ac-34ef-2d7a-f1dc1af16794@hfg-gmuend.de> Message-ID: hi, On Wed, May 17, 2017 at 9:43 AM, Guenther Alka 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: 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: > On May 18, 2017, at 3:55 PM, Geoff Nordli 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: References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net> 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 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: References: <40553AEA-2445-4B96-B64A-3F0ED8C8FC33@omniti.com> Message-ID: Thanks for the walkthrough, Dan. -- Ram On Wed, May 17, 2017 at 1:31 PM, Dan McDonald wrote: > > > On May 16, 2017, at 5:22 PM, Dan McDonald 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: 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: References: 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 Sent: May 16, 2017 12:28:18 AM GMT+02:00 To: OpenIndiana Developer mailing list , 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: 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: Hello. I use "omnios-r151020-b5b8c75" and I have small healthy ZFS storage (Zpool status & Zfs list link ) 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: 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: References: 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: <7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com> Message-ID: 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 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 : > r151022 is out now. Please upgrade to that and see if the problem > manifests. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com> Message-ID: <1629457341.396.1495733753931.JavaMail.stephan.budach@stephanbudach.local> ----- Urspr?ngliche Mail ----- Hi ?zkan, > Von: "?zkan G?ksu" > An: "Dan McDonald" > CC: "omnios-discuss" > 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: 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: References: <7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com> Message-ID: 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 : > 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 > > 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 : > >> 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: 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: References: 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: References: Message-ID: On Wed, May 24, 2017 at 6:00 PM, Dan McDonald 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: 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: <7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com> <1629457341.396.1495733753931.JavaMail.stephan.budach@stephanbudach.local> Message-ID: 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 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 : > ----- Urspr?ngliche Mail ----- > Hi ?zkan, > > > Von: "?zkan G?ksu" > > An: "Dan McDonald" > > CC: "omnios-discuss" > > 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: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From tobi at oetiker.ch Fri 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: References: <7CD73565-15D9-43B4-82C6-D89764ADB216@kebe.com> <1629457341.396.1495733753931.JavaMail.stephan.budach@stephanbudach.local> 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 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: 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: 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 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: 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: 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: 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: References: Message-ID: > 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: References: Message-ID: 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: 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: References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net> 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 > > 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: 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> <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> <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> Message-ID: 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.