From alka at hfg-gmuend.de Sat Jul 1 00:14:21 2017 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Sat, 1 Jul 2017 02:14:21 +0200 Subject: [OmniOS-discuss] Bug ? In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <767138E0D064A148B03FE8EC1E9325A20125BE86A9@GEDAEVW01.a.space.corp> Message-ID: <0bd5a3d9-b4fc-7e45-be8b-3d5c14dd788c@hfg-gmuend.de> Why should one as there remain enough free or nonfree Solaris based options that I see as a mostly superiour option for ZFS storage. Or would you switch (as a Linux user) to BSD or Solaris if RedHat would close the door when there are many other Linux options but without commercial support available. If commercial support was your reason for OmniOS, Nexenta and Solaris remain an option. If OpenSource is ok, use OI or SmartOS or one of the other and hope or help that we/you/they find a way to continue the idea of a minimal stable or LTS distribution based on Illumos.Commercial support with SLA is not really needed for me and many. We want NetApp alike features without the costs. I second Aur?lian coming from the OpenIndiana community with the idea to look at OI with its stronger and already working community like a OmniOS bloody to create a stable subset/freeze named OmniOS upon. Gea @napp-it.org Am 01.07.2017 um 01:36 schrieb Mini Trader: > Is it going to be FreeBSD or Linux? > > On Thu, Jun 29, 2017 at 3:16 AM Oliver Weinmann > > wrote: > > Ohh that is bad news. > > I have a productions system that somehow fails to join AD and I > don?t know what is causing this. We had a similar issue on our > nexenta system and they provided us a patch that solved it. > > Idmap: > > additional info: SASL(-1): generic failure: GSSAPI Error: > Unspecified GSS failure. Minor code may provide more information > (Client not found in Kerberos database) > > adutils: ldap_lookup_init failed > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de > > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller > > *From:* Paul B. Henson [mailto:henson at acm.org > ] > *Sent:* Donnerstag, 29. Juni 2017 08:51 > *To:* Oliver Weinmann > > *Cc:* omnios-discuss > > *Subject:* Re: [OmniOS-discuss] Bug ? > > Unfortunately OmniTI no longer offers support contracts for > OmniOS. We actually have a contract that's still good through I > think November, but given their main support engineer is no longer > with the company and the OS appears to be in limbo at the moment > I'm not sure what good that does us ;). > > If you think you've found a bug, your best bet at the moment is to > just report it to this list, possibly to the upstream illumos > developer list if you can detail it reasonably technically, and > perhaps open an issue on the illumos issue tracker. > > > On Jun 28, 2017, at 11:29 PM, Oliver Weinmann > > wrote: > > Hi, > > What if I would like to report a possible bug? Do I need a > valid support contract for this? > > Best Regards, > > Oliver > > > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de > > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register > court/Registergericht: Darmstadt, HRB 89231; Managing > Director/Gesch?ftsf?hrer: Sigmar Keller > > _______________________________________________ > 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 2232491716 at qq.com Sat Jul 1 04:24:55 2017 From: 2232491716 at qq.com (=?ISO-8859-1?B?QXJpZXM=?=) Date: Sat, 1 Jul 2017 12:24:55 +0800 Subject: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 In-Reply-To: <09d0dbec-20e9-d1d7-68ef-6dce71515a8b@hfg-gmuend.de> References: <09d0dbec-20e9-d1d7-68ef-6dce71515a8b@hfg-gmuend.de> Message-ID: Thank you for replay and your effort on napp-it. I really love it! Actually the Dell H330 only has one hybrid mode firmware which can be switched between raid and HBA modes. All the distributions include Solaris and linux regard this kind firmware of H330 as IR mode regardless of the raid or HBA mode. Although I always put it in HBA mode, the mr_sas or something similar is used. Therefore when I read the release note of r151022, I was surprised that OmniOS started to support H330 via mpt_sas. However the test result seems a bit disappointing. By the way, do you notice any performance decreases in the release r151022? Regrads, Aries ------------------ Original ------------------ From: "G?nther Alka";; Date: Sat, Jul 1, 2017 03:34 AM To: "omnios-discuss"; Subject: Re: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 The driver is related to the firmware. I suppose you are on an IR/Raid firmware. The better one would be a raidless and often faster IT firmware (mpt_sas). But I cannot say if its available from Dell or if the one from LSI is working. Gea @napp-it.org Am 30.06.2017 um 18:53 schrieb Aries: Hello, I noticed that the r151022 starts to support the Dell H330 via mpt_sas driver. So I installed the r151022 fresh on my Dell T630 server with H330 as a VM on ESXi. The H330 was PCI-E passthrough with 8x 7k2 disks in raid z2. However when I ran the command dmesg | grep sas, it seems that the mr_sas was used for the H330 adapter which is just as same as the r151020 and r151014 version. I also discovered that the disk performance was worse than the r151020. To compare, I ran all the tests via napp-it filebench. For example, for the fivestreamwrite test, the result of r151020 and r151014 is around 1100mb/s, but the r151022 only shows 650mb/s. I tried multiple combinations like creating the pool in one version and import into another version. The issue seems not related to the creation of the pool but the version which runs the pool. Did I miss something in the setup that leads the H330 to run with the wrong driver? Could you please give me some advices? Thank you in advance. Best regards, Aries _______________________________________________ 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 oliver.weinmann at icloud.com Sat Jul 1 08:59:41 2017 From: oliver.weinmann at icloud.com (Oliver Weinmann) Date: Sat, 01 Jul 2017 10:59:41 +0200 Subject: [OmniOS-discuss] zfs receive -x parameter missing? Message-ID: <09ff226e-ac1a-0333-4af0-32603953b0c1@me.com> Hi, We have a nexenta system and this has a few additional parameters for zfs send an receive. These do not exist on omnios or open Indiana. I found a very old feature request for this: https://www.illumos.org/issues/2745 The main reason for this is to ensure that the replicated ZFS folders are not shared e.g. Best regards, Oliver From danmcd at kebe.com Sat Jul 1 14:10:18 2017 From: danmcd at kebe.com (Dan McDonald) Date: Sat, 1 Jul 2017 10:10:18 -0400 Subject: [OmniOS-discuss] zfs receive -x parameter missing? In-Reply-To: <09ff226e-ac1a-0333-4af0-32603953b0c1@me.com> References: <09ff226e-ac1a-0333-4af0-32603953b0c1@me.com> Message-ID: <1D605256-9345-4D70-8536-C0E3E32E5171@kebe.com> > On Jul 1, 2017, at 4:59 AM, Oliver Weinmann wrote: > > Hi, > > We have a nexenta system and this has a few additional parameters for zfs send an receive. These do not exist on omnios or open Indiana. I found a very old feature request for this: > > https://www.illumos.org/issues/2745 > > The main reason for this is to ensure that the replicated ZFS folders are not shared e.g. Your best bet is to engage with the OpenZFS folks to get it upstreamed. If Nexenta already did it, it SHOULD be a matter of moving it in. And the OpenZFS test rigs can confirm/deny it works. It's also possible someone will need to write the tests for it, too. Dan From alka at hfg-gmuend.de Sun Jul 2 09:37:13 2017 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Sun, 2 Jul 2017 11:37:13 +0200 Subject: [OmniOS-discuss] About OmniOS and napp-it In-Reply-To: <0bd5a3d9-b4fc-7e45-be8b-3d5c14dd788c@hfg-gmuend.de> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <767138E0D064A148B03FE8EC1E9325A20125BE86A9@GEDAEVW01.a.space.corp> <0bd5a3d9-b4fc-7e45-be8b-3d5c14dd788c@hfg-gmuend.de> Message-ID: About OmniOS and napp-it https://forums.servethehome.com/index.php?threads/omnios-151022-long-term-stable.14367/page-4 Gea @napp-it.org From omnios at citrus-it.net Sun Jul 2 10:09:24 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Sun, 2 Jul 2017 10:09:24 +0000 (UTC) Subject: [OmniOS-discuss] Bug ? In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> Message-ID: On Thu, 29 Jun 2017, Guenther Alka wrote: ; Unless there are news regarding OmniOS my stance is ; ; - OmniOS 151022 is a freeze of current Illumos + LX. At the moment it is the ; most stable and feature rich free Illumos general use server distribution with ; the addition LX zones. As there is no repo and development outside OmniTi it ; is freezed. There are no signs from OmniTi to add any fixes. As packages are ; signed it does not work outside OmniTi. As OmniOS 151023 is identical without ; signed packages a community based repo based on it with possible fixes as ; 151022ce (community edition) is a suggestion (but sadly I am not an OS ; developer). Momentum does appear to be lacking unfortunately. Here at Citrus we have forked the OmniOS repositories and are continuing to maintain them for internal use while we consider options. We have kept omnios-build packages up-to-date where there are security fixes (two Bind updates, 7-zip CVE patch, OpenSSL [IIRC]) and backported a handful of illumos changes that are relevant to us. We can keep going like this for a good while and I still hope that a community OmniOS will get going (we've offered to contribute engineering resource as have others) and we can make the switch. Since we use LX zones to an extent, SmartOS is the other route we are evaluating at the moment. 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 tobi at oetiker.ch Sun Jul 2 11:09:39 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Sun, 2 Jul 2017 13:09:39 +0200 (CEST) Subject: [OmniOS-discuss] Bug ? In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> Message-ID: <1923416080.624118.1498993779449.JavaMail.zimbra@oetiker.ch> ----- On Jul 2, 2017, at 12:09 PM, Andy Fiddaman omnios at citrus-it.net wrote: > On Thu, 29 Jun 2017, Guenther Alka wrote: > > ; Unless there are news regarding OmniOS my stance is > ; > ; - OmniOS 151022 is a freeze of current Illumos + LX. At the moment it is the > ; most stable and feature rich free Illumos general use server distribution with > ; the addition LX zones. As there is no repo and development outside OmniTi it > ; is freezed. There are no signs from OmniTi to add any fixes. As packages are > ; signed it does not work outside OmniTi. As OmniOS 151023 is identical without > ; signed packages a community based repo based on it with possible fixes as > ; 151022ce (community edition) is a suggestion (but sadly I am not an OS > ; developer). > > Momentum does appear to be lacking unfortunately. Here at Citrus we have > forked the OmniOS repositories and are continuing to maintain them for > internal use while we consider options. > > We have kept omnios-build packages up-to-date where there are security > fixes (two Bind updates, 7-zip CVE patch, OpenSSL [IIRC]) and backported a > handful of illumos changes that are relevant to us. We can keep going like > this for a good while and I still hope that a community OmniOS will get > going (we've offered to contribute engineering resource as have others) > and we can make the switch. > > Since we use LX zones to an extent, SmartOS is the other route we are > evaluating at the moment. > not to join forces seem to be a pitty ... how about hosting that fork on https://github.com/omniosorg and starting to accept PRs there at least from what I can see there is a total lack of communication from omniti regarding how they envision that transition of omnios to community maintainership so I guess we have to take the initiative. I have had a look at smartos, for kvm and lx it would be great but it seems that serving smb, nfs and iscsi is not a focus on joyents side (but maybe I have just not looked correctly). there is a gitter chat associated with the github omniosorg repo https://gitter.im/omniosorg/Lobby 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 omnios at citrus-it.net Sun Jul 2 15:45:59 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Sun, 2 Jul 2017 15:45:59 +0000 (UTC) Subject: [OmniOS-discuss] Bug ? In-Reply-To: <1923416080.624118.1498993779449.JavaMail.zimbra@oetiker.ch> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <1923416080.624118.1498993779449.JavaMail.zimbra@oetiker.ch> Message-ID: On Sun, 2 Jul 2017, Tobias Oetiker wrote: ; not to join forces seem to be a pitty ... how about hosting that fork on ; https://github.com/omniosorg and starting to accept PRs there At the moment the fork is very much driven by our requirements and not considering a wider community. We're ignoring fixes that don't directly affect us and pulling others that would historically only have made it into bloody. I do think we need to set up a fork on github.com/omniosorg but this one probably isn't it. I'm on the gitter chat but the last thing you said on there was "I have also on purpose NOT forked the omnios repo into the omnios org thing yet". I'll take the conversation over there. Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From danmcd at kebe.com Mon Jul 3 13:35:50 2017 From: danmcd at kebe.com (Dan McDonald) Date: Mon, 3 Jul 2017 09:35:50 -0400 Subject: [OmniOS-discuss] [danmcd@joyent.com: Missed FLAG DAY for OmniOS r151022 users of ONU and illumos-gate] Message-ID: <20170703133550.GA43536@everywhere.local> Sending from kebe.com, as that's how I interact with OmniOS. And again, SORRY for missing this upon r151022's release. Dan ----- Forwarded message from Dan McDonald ----- Date: Mon, 3 Jul 2017 09:33:20 -0400 From: Dan McDonald To: illumos-developer Cc: Dan McDonald , Dan McDonald Subject: Missed FLAG DAY for OmniOS r151022 users of ONU and illumos-gate X-Mailer: Apple Mail (2.3273) If you are compiling illumos-gate under OmniOS r151022 or later to use for ONU-ing on top of an OmniOS r151022 or later image, there are some new things with r151022 that I didn't get to test until after I left OmniTI. (Thank you Ryan Z. for pointing these out to me.) 1.) New value for PERL_PKGVERS: "". >From now on, you must set PERL_PKGVERS="" in your .env file for illumos-gate building. This is due to things changing in OmniOS as part of the Perl 5.24.1 upgrade, I believe. 2.) Reminder: intrd will fail on an ONU'ed OmniOS-to-illumos-gate ONU. If you need intrd, you need to modify things so it can work w/o looking for a 64-bit set of illumos perl modules like OmniOS provides. I apologize for missing that test and this flag-day when r151022 came out. Dan ----- End forwarded message ----- From jcoombs at staff.gwi.net Mon Jul 3 14:21:47 2017 From: jcoombs at staff.gwi.net (Josh Coombs) Date: Mon, 3 Jul 2017 10:21:47 -0400 Subject: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 In-Reply-To: References: <09d0dbec-20e9-d1d7-68ef-6dce71515a8b@hfg-gmuend.de> Message-ID: I'd have to poke at the release notes and relevant patches, but I wonder if it's a matter of updating /etc/driver_aliases to change the binding to mpt_sas for that specific PCI ID? Joshua Coombs GWI *office* 207-494-2140 www.gwi.net On Sat, Jul 1, 2017 at 12:24 AM, Aries <2232491716 at qq.com> wrote: > Thank you for replay and your effort on napp-it. I really love it! > > Actually the Dell H330 only has one hybrid mode firmware which can be > switched between raid and HBA modes. All the distributions include Solaris > and linux regard this kind firmware of H330 as IR mode regardless of the > raid or HBA mode. Although I always put it in HBA mode, the mr_sas or > something similar is used. Therefore when I read the release note of > r151022, I was surprised that OmniOS started to support H330 via mpt_sas. > However the test result seems a bit disappointing. > > By the way, do you notice any performance decreases in the release r151022? > > Regrads, > Aries > > > ------------------ Original ------------------ > *From: * "G?nther Alka";; > *Date: * Sat, Jul 1, 2017 03:34 AM > *To: * "omnios-discuss"; > *Subject: * Re: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 > > The driver is related to the firmware. > I suppose you are on an IR/Raid firmware. The better one would be a > raidless and often faster IT firmware (mpt_sas). But I cannot say if its > available from Dell or if the one from LSI is working. > > Gea > @napp-it.org > > > Am 30.06.2017 um 18:53 schrieb Aries: > > Hello, > > I noticed that the r151022 starts to support the Dell H330 via mpt_sas > driver. So I installed the r151022 fresh on my Dell T630 server with H330 > as a VM on ESXi. The H330 was PCI-E passthrough with 8x 7k2 disks in raid > z2. > > However when I ran the command dmesg | grep sas, it seems that the mr_sas > was used for the H330 adapter which is just as same as the r151020 and r > 151014 version. > > I also discovered that the disk performance was worse than the r151020. > To compare, I ran all the tests via napp-it filebench. For example, for the > fivestreamwrite test, the result of r151020 and r151014 is around > 1100mb/s, but the r151022 only shows 650mb/s. I tried multiple > combinations like creating the pool in one version and import into another > version. The issue seems not related to the creation of the pool but the > version which runs the pool. > > Did I miss something in the setup that leads the H330 to run with the > wrong driver? Could you please give me some advices? Thank you in advance. > > Best regards, > Aries > > > _______________________________________________ > OmniOS-discuss mailing listOmniOS-discuss at lists.omniti.comhttp://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 Mon Jul 3 14:41:31 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Mon, 03 Jul 2017 14:41:31 +0000 Subject: [OmniOS-discuss] Bug ? In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <277101d2f114$1ae1a0c0$50a4e240$@acm.org> <04B0A5C1206D824F8D310C5B3DB28CC920270706@vEX01.mindstorm-internet.local> Message-ID: <6F83F6FA-0C5A-4A17-BF18-C7C757B8A930@cos.ru> On July 1, 2017 1:02:30 AM GMT+02:00, "Aur?lien Larcher" wrote: >I guess one should remind the little elves of the magical forest that >they need to take over the maintenance, they were quite busy with >Midsummer apparently. > >Otherwise, basically Guenther's advice is the way to go: >- for illumos specific issues: https://www.illumos.org/issues, >- for software package bugs we could look at it in OpenIndiana and >someone could backport the fix to OmniOS afterwards (when >infrastructure is fixed). > >I hoped that we could have a virtuous relationship with OpenIndiana >Hipster acting as a "bloody" and OmniOS continuing as a stable subset, >similarly to the current scheme (also benefiting from the current >Hipster CI setup to avoid losing momentum). >There is apparently no interest following the discussion which was >initiated right after the announcement, this is a bit disappointing. > >I hope that people will join forces to consolidate the landscape of >community-supported illumos distros. >At some point one needs to stop talking theory and tragedy, there are >pragmatic solutions to implement: there are infrastructures in place >in both OI and OmniOS-land, there are overall directions and goals in >both (rolling dev vs stable), there is a solid release engineering >practice in OmniOS, it does not seem like we swim in complete >abstraction. >Contributing software packages can be easy, the difficulty seems to >get people to figure out that maintaining even one package is a >meaningful contribution. > >(I maintain a bunch of packages for OpenIndiana and I do not work in >IT) > >Kind regards, > >? Jeudi 29 juin 2017, Davide Poletto a ?crit : >> The more I think *how fast* that's (supposedly) happening the more I >feel >> shocked. >> >> On Jun 29, 2017 10:33 PM, "Floris van Essen ..:: House of Ancients >Amstafs >> ::.." wrote: >> >> Hi All, >> >> With pain in my heart, i fear OmniOs has started it's slow descent to >death >> :-( >> >> >> >> -----Oorspronkelijk bericht----- >> Van: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] >Namens >> Paul B. Henson >> Verzonden: donderdag 29 juni 2017 22:13 >> Aan: 'Guenther Alka' ; >omnios-discuss at lists.omniti.com >> Onderwerp: Re: [OmniOS-discuss] Bug ? >> >> > From: Guenther Alka >> > Sent: Thursday, June 29, 2017 12:33 AM >> > >> > There are no signs from OmniTi to add any fixes. >> >> An OmniTI person posted an intention to back port security fixes to >r151022 >> for one year, although I'm not sure whether that was under the >auspices of >> OmniTI employment or just on his personal time. So far though, there >have >> been no new commits in the r151022 repo since Dan's last one on >5/10.. >> >> >> _______________________________________________ >> 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 >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > >-- >Thanks for sailing Jolla :) >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss Among technological differences between OI and OO, a notable benefit is LX zones. It was often stated that OI community has not enough resources to deviate from upstream illumos-gate, since maintaining a fork beyond a branding patch or so is indeed complicated. I got wondering if it is possible to take omnios-gate and build just the LX-related bits for the sake of adding the LX brand support as a few packages installable to "vanilla" illumos-gate os/net? In the binary end, it does add just some modules, tools and scripts, right? At least, if this works, it might help until LX is upstreamed... Jim -- Typos courtesy of K-9 Mail on my Redmi Android From danmcd at kebe.com Mon Jul 3 15:18:42 2017 From: danmcd at kebe.com (Dan McDonald) Date: Mon, 3 Jul 2017 11:18:42 -0400 Subject: [OmniOS-discuss] Bug ? In-Reply-To: <6F83F6FA-0C5A-4A17-BF18-C7C757B8A930@cos.ru> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <277101d2f114$1ae1a0c0$50a4e240$@acm.org> <04B0A5C1206D824F8D310C5B3DB28CC920270706@vEX01.mindstorm-internet.local> <6F83F6FA-0C5A-4A17-BF18-C7C757B8A930@cos.ru> Message-ID: > On Jul 3, 2017, at 10:41 AM, Jim Klimov wrote: > > > Among technological differences between OI and OO, a notable benefit is LX zones. It was often stated that OI community has not enough resources to deviate from upstream illumos-gate, since maintaining a fork beyond a branding patch or so is indeed complicated. > > I got wondering if it is possible to take omnios-gate and build just the LX-related bits for the sake of adding the LX brand support as a few packages installable to "vanilla" illumos-gate os/net? In the binary end, it does add just some modules, tools and scripts, right? At least, if this works, it might help until LX is upstreamed... The LX port data (lists of commits from illumos-joyent I did and did not take), including the semi-automatic scripting I have for merging is all tarred up here: https://omnios.omniti.com/wiki.php/Maintainers Dan From aurelien.larcher at gmail.com Mon Jul 3 15:21:35 2017 From: aurelien.larcher at gmail.com (=?UTF-8?Q?Aur=c3=a9lien_Larcher?=) Date: Mon, 3 Jul 2017 17:21:35 +0200 Subject: [OmniOS-discuss] Bug ? In-Reply-To: <6F83F6FA-0C5A-4A17-BF18-C7C757B8A930@cos.ru> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <277101d2f114$1ae1a0c0$50a4e240$@acm.org> <04B0A5C1206D824F8D310C5B3DB28CC920270706@vEX01.mindstorm-internet.local> <6F83F6FA-0C5A-4A17-BF18-C7C757B8A930@cos.ru> Message-ID: <90fc72f7-7297-63a9-d4ca-bd54616088b9@gmail.com> On 03/07/2017 16:41, Jim Klimov wrote: > On July 1, 2017 1:02:30 AM GMT+02:00, "Aur?lien Larcher" wrote: >> I guess one should remind the little elves of the magical forest that >> they need to take over the maintenance, they were quite busy with >> Midsummer apparently. >> >> Otherwise, basically Guenther's advice is the way to go: >> - for illumos specific issues: https://www.illumos.org/issues, >> - for software package bugs we could look at it in OpenIndiana and >> someone could backport the fix to OmniOS afterwards (when >> infrastructure is fixed). >> >> I hoped that we could have a virtuous relationship with OpenIndiana >> Hipster acting as a "bloody" and OmniOS continuing as a stable subset, >> similarly to the current scheme (also benefiting from the current >> Hipster CI setup to avoid losing momentum). >> There is apparently no interest following the discussion which was >> initiated right after the announcement, this is a bit disappointing. >> >> I hope that people will join forces to consolidate the landscape of >> community-supported illumos distros. >> At some point one needs to stop talking theory and tragedy, there are >> pragmatic solutions to implement: there are infrastructures in place >> in both OI and OmniOS-land, there are overall directions and goals in >> both (rolling dev vs stable), there is a solid release engineering >> practice in OmniOS, it does not seem like we swim in complete >> abstraction. >> Contributing software packages can be easy, the difficulty seems to >> get people to figure out that maintaining even one package is a >> meaningful contribution. >> >> (I maintain a bunch of packages for OpenIndiana and I do not work in >> IT) >> >> Kind regards, >> >> ? Jeudi 29 juin 2017, Davide Poletto a ?crit : >>> The more I think *how fast* that's (supposedly) happening the more I >> feel >>> shocked. >>> >>> On Jun 29, 2017 10:33 PM, "Floris van Essen ..:: House of Ancients >> Amstafs >>> ::.." wrote: >>> >>> Hi All, >>> >>> With pain in my heart, i fear OmniOs has started it's slow descent to >> death >>> :-( >>> >>> >>> >>> -----Oorspronkelijk bericht----- >>> Van: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] >> Namens >>> Paul B. Henson >>> Verzonden: donderdag 29 juni 2017 22:13 >>> Aan: 'Guenther Alka' ; >> omnios-discuss at lists.omniti.com >>> Onderwerp: Re: [OmniOS-discuss] Bug ? >>> >>>> From: Guenther Alka >>>> Sent: Thursday, June 29, 2017 12:33 AM >>>> >>>> There are no signs from OmniTi to add any fixes. >>> An OmniTI person posted an intention to back port security fixes to >> r151022 >>> for one year, although I'm not sure whether that was under the >> auspices of >>> OmniTI employment or just on his personal time. So far though, there >> have >>> been no new commits in the r151022 repo since Dan's last one on >> 5/10.. >>> >>> _______________________________________________ >>> 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 >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >> -- >> Thanks for sailing Jolla :) >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > Among technological differences between OI and OO, a notable benefit is LX zones. It was often stated that OI community has not enough resources to deviate from upstream illumos-gate, since maintaining a fork beyond a branding patch or so is indeed complicated. I guess it is more a matter of priority: we had the userland migration ongoing and updating/integrating quite many components in the process was very time consuming. Last time we discussed LX the conclusion was that we need one person dedicated to the task, and otherwise it is pointless to push it out if we cannot guarantee that version will be updated following a regular schedule. > I got wondering if it is possible to take omnios-gate and build just the LX-related bits for the sake of adding the LX brand support as a few packages installable to "vanilla" illumos-gate os/net? In the binary end, it does add just some modules, tools and scripts, right? At least, if this works, it might help until LX is upstreamed... Last year I rebased illumos-omnios, added some stuff (iwn + loader) and built it on Hipster just to see how it is done , but I have not had enough interest otherwise. I am more interested in compiler migration and parallel (scientific) computing tools as you know. I wonder what is the most time consuming? 1) sharing one userland and getting illumos-omnios to build on both OmniOS and OI, 2) keeping illumos-omnios as it is and duplicate userland. Beyond the maintenance the question is: how do you provide a stable system without a testing branch? If everybody is interested in using a stable OmniOS, who is developing and testing "Bloody"? For instance: - who will take care of the migration to recent GCC? - will this task be a duplicate of what is done in oi-userland or will there be some level of collaboration? - if the tools are different, how should this be implemented? These questions should be addressed as soon as possible to facilitate any transition that may be required. I understand that it is tempting to keep things as they are, but one should consider if the direction is viable in the long term. Maintaining the current r22 is one thing, preparing the next cycle is another problem: if goals and timeline are not set according to available resources, one may end up with nothing. Again, I am not directly involved and my point of view is very naive, I am just interested in people thoughts on the topic. Usually it *just* starts with somebody taking the initiative, sit and deal with the code. ;) > > Jim > -- > Typos courtesy of K-9 Mail on my Redmi Android From jdg117 at elvis.arl.psu.edu Mon Jul 3 20:03:20 2017 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Mon, 03 Jul 2017 16:03:20 -0400 Subject: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 In-Reply-To: Your message of "Sat, 01 Jul 2017 12:24:55 +0800." References: <09d0dbec-20e9-d1d7-68ef-6dce71515a8b@hfg-gmuend.de> Message-ID: <201707032003.v63K3KYB027767@elvis.arl.psu.edu> In message , =?ISO-8859-1?B?QXJpZXM=?= writes: >Actually the Dell H330 only has one hybrid mode firmware which can be switched > between raid and HBA modes. All the distributions include Solaris and linux r >egard this kind firmware of H330 as IR mode regardless of the raid or HBA mode >. Although I always put it in HBA mode, the mr_sas or something similar is use >d. Therefore when I read the release note of r151022, I was surprised that Omn >iOS started to support H330 via mpt_sas. However the test result seems a bit d >isappointing. The H330 looks awfully like Broadcom/LSI's 9300-8i: What happens when you sas3flash the Dell HBA with the LSI SAS3008 IT firmware? Also, what's the PCI ID for the H330? John groenveld at acm.org From 2232491716 at qq.com Tue Jul 4 13:55:57 2017 From: 2232491716 at qq.com (=?gb18030?B?QXJpZXM=?=) Date: Tue, 4 Jul 2017 21:55:57 +0800 Subject: [OmniOS-discuss] =?gb18030?b?u9i4tKO6ICBEZWxsIEgzMzAgYW5kIG1wdF9z?= =?gb18030?q?as_on_r151022?= In-Reply-To: References: <09d0dbec-20e9-d1d7-68ef-6dce71515a8b@hfg-gmuend.de> Message-ID: Thank you for replay. I've tried googling and searching the mail archive myself. However I didn't find anything related to Dell H330. On the other hand, I think the SAS3008 was supported via mpt_sas long before this release and should not be mentioned in the notes. I also tried rebuilding the driver_aliases according to the Solaris document. But it seems that the mpt_sas cannot handle the H330 card. The driver just complains and it simply not load. Could you please tell me where should I find the specific patches? Thank you very much. Regards, Aries ------------------ ???? ------------------ ???: "Josh Coombs";; ????: 2017?7?3?(???) ??10:21 ???: "Aries"<2232491716 at qq.com>; ??: "G?nther Alka"; "omnios-discuss"; ??: Re: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 I'd have to poke at the release notes and relevant patches, but I wonder if it's a matter of updating /etc/driver_aliases to change the binding to mpt_sas for that specific PCI ID? Joshua CoombsGWI office 207-494-2140 www.gwi.net On Sat, Jul 1, 2017 at 12:24 AM, Aries <2232491716 at qq.com> wrote: Thank you for replay and your effort on napp-it. I really love it! Actually the Dell H330 only has one hybrid mode firmware which can be switched between raid and HBA modes. All the distributions include Solaris and linux regard this kind firmware of H330 as IR mode regardless of the raid or HBA mode. Although I always put it in HBA mode, the mr_sas or something similar is used. Therefore when I read the release note of r151022, I was surprised that OmniOS started to support H330 via mpt_sas. However the test result seems a bit disappointing. By the way, do you notice any performance decreases in the release r151022? Regrads, Aries ------------------ Original ------------------ From: "G?nther Alka";; Date: Sat, Jul 1, 2017 03:34 AM To: "omnios-discuss"; Subject: Re: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 The driver is related to the firmware. I suppose you are on an IR/Raid firmware. The better one would be a raidless and often faster IT firmware (mpt_sas). But I cannot say if its available from Dell or if the one from LSI is working. Gea @napp-it.org Am 30.06.2017 um 18:53 schrieb Aries: Hello, I noticed that the r151022 starts to support the Dell H330 via mpt_sas driver. So I installed the r151022 fresh on my Dell T630 server with H330 as a VM on ESXi. The H330 was PCI-E passthrough with 8x 7k2 disks in raid z2. However when I ran the command dmesg | grep sas, it seems that the mr_sas was used for the H330 adapter which is just as same as the r151020 and r151014 version. I also discovered that the disk performance was worse than the r151020. To compare, I ran all the tests via napp-it filebench. For example, for the fivestreamwrite test, the result of r151020 and r151014 is around 1100mb/s, but the r151022 only shows 650mb/s. I tried multiple combinations like creating the pool in one version and import into another version. The issue seems not related to the creation of the pool but the version which runs the pool. Did I miss something in the setup that leads the H330 to run with the wrong driver? Could you please give me some advices? Thank you in advance. Best regards, Aries _______________________________________________ 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 2232491716 at qq.com Tue Jul 4 16:50:11 2017 From: 2232491716 at qq.com (=?ISO-8859-1?B?QXJpZXM=?=) Date: Wed, 5 Jul 2017 00:50:11 +0800 Subject: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 In-Reply-To: <201707032003.v63K3KYB027767@elvis.arl.psu.edu> References: <09d0dbec-20e9-d1d7-68ef-6dce71515a8b@hfg-gmuend.de> <201707032003.v63K3KYB027767@elvis.arl.psu.edu> Message-ID: Thank you for replay. Yes. AFAIK, the hardware of H330 should be as same as the LSI SAS3008. But as it is an OEM Dell branded card with choppy firmware, sadly, it's not supported by the sas3flash utility. Unlike the 2008 series, I cannot find a way to crossflash it to the IT firmware for the moment. The PCI-id is 1000 005f which is a MegaRaid. Maybe I should go for a proper 3008 card or a Dell HBA330 card to save some time... Cheers, Aries ------------------ Original ------------------ From: "John D Groenveld";; Date: Jul 4, 2017 To: "omnios-discuss"; Subject: Re: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 In message , =?ISO-8859-1?B?QXJpZXM=?= writes: >Actually the Dell H330 only has one hybrid mode firmware which can be switched > between raid and HBA modes. All the distributions include Solaris and linux r >egard this kind firmware of H330 as IR mode regardless of the raid or HBA mode >. Although I always put it in HBA mode, the mr_sas or something similar is use >d. Therefore when I read the release note of r151022, I was surprised that Omn >iOS started to support H330 via mpt_sas. However the test result seems a bit d >isappointing. The H330 looks awfully like Broadcom/LSI's 9300-8i: What happens when you sas3flash the Dell HBA with the LSI SAS3008 IT firmware? Also, what's the PCI ID for the H330? John groenveld at acm.org _______________________________________________ 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 Jul 5 14:05:51 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Wed, 5 Jul 2017 16:05:51 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - Message-ID: *about OmniOS**and the silence for weeks* For my own future, I have already decided to switch back to OpenIndiana, the community based sister project of OmniOS. But like many users, I have yet OmniOS installations running perfectly. For them, it is essential to ask about the future for the next months or year and needed next steps (can wait some time or switch as soon as possible). *@**OmniTi* The end of OmniOS at OmniTi seems final. - How long will the website and the repo remain online? - Is there an option to fix serious bugsor problems in OmniOS @OmniTi for a limited time like 1 year or at least end of the year? - Are you willing to transfer the website/name either to a new OmniOS community project (I cannot see this as an option regarding the silence about) or to the OpenIndiana community to use it as a name for a possible stable like OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable subset? (if OI is willing to go that route but the request or offer must come from OmniTi or OmniOS people). OmniOS has a very strong reputation regarding production quality and stability, so such a step would help both if OpenIndiana and OmniOS would cooperate in a common project. Seems a pity if the name would die or remain as a name for a failed project. *@OmniOS developers*(current or former - you have done a very good job!) - Is there an option to fix serious bugs or problems in OmniOS for a limited time like 1 year or at least end of the year? This would help until a sucessor (less likely OmniOS 151024, maybe next OpenIndiana snap with a stable subset) is available. LX would then remain an OmniOS option in the meantime (I would not dare to ask about an upstream). *@all* comments? Gea @napp-it.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From omnios at citrus-it.net Wed Jul 5 14:20:15 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Wed, 5 Jul 2017 14:20:15 +0000 (UTC) Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: Message-ID: On Wed, 5 Jul 2017, Guenther Alka wrote: ; - Is there an option to fix serious bugs or problems in OmniOS for a limited ; time like 1 year or at least end of the year? This would help until a sucessor ; (less likely OmniOS 151024, maybe next OpenIndiana snap with a stable subset) ; is available. LX would then remain an OmniOS option in the meantime (I would ; not dare to ask about an upstream). OmniOSce (community edition) is gaining momentum. I would expect updated r151022 and bloody repositories to be online in the next few weeks and an r151024 to follow in due course. It's early days and the release model hasn't been discussed in detail yet but join in at https://gitter.im/omniosorg/Lobby Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From tobi at oetiker.ch Wed Jul 5 14:30:47 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 5 Jul 2017 16:30:47 +0200 (CEST) Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: Message-ID: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> Gea, the king is dead, long live the king https://gitter.im/omniosorg/Lobby www.omniosce.org the story continues ... cheers tobi ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka wrote: > about OmniOS and the silence for weeks > For my own future, I have already decided to switch back to OpenIndiana, the > community based sister project of OmniOS. But like many users, I have yet > OmniOS installations running perfectly. For them, it is essential to ask about > the future for the next months or year and needed next steps (can wait some > time or switch as soon as possible). > @ OmniTi > The end of OmniOS at OmniTi seems final. > - How long will the website and the repo remain online? > - Is there an option to fix serious bugs or problems in OmniOS @OmniTi for > a limited time like 1 year or at least end of the year? > - Are you willing to transfer the website/name either to a new OmniOS community > project (I cannot see this as an option regarding the silence about) or to the > OpenIndiana community to use it as a name for a possible stable like > OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable subset? (if OI is > willing to go that route but the request or offer must come from OmniTi or > OmniOS people). > OmniOS has a very strong reputation regarding production quality and stability, > so such a step would help both if OpenIndiana and OmniOS would cooperate in a > common project. Seems a pity if the name would die or remain as a name for a > failed project. > @OmniOS developers (current or former - you have done a very good job!) > - Is there an option to fix serious bugs or problems in OmniOS for a limited > time like 1 year or at least end of the year? This would help until a sucessor > (less likely OmniOS 151024 , maybe next OpenIndiana snap with a stable subset) > is available. LX would then remain an OmniOS option in the meantime (I would > not dare to ask about an upstream). > @all > comments? > Gea > @napp-it.org > _______________________________________________ > 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 alka at hfg-gmuend.de Wed Jul 5 14:48:15 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Wed, 5 Jul 2017 16:48:15 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> Message-ID: hello Tobi and Andy the first good news for 10 Weeks! cheers Gea Am 05.07.2017 um 16:30 schrieb Tobias Oetiker: > Gea, > > the king is dead, long live the king > > https://gitter.im/omniosorg/Lobby > > www.omniosce.org > > the story continues ... > > cheers > tobi > > ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka > wrote: > > *about OmniOS**and the silence for weeks* > > For my own future, I have already decided to switch back to > OpenIndiana, the community based sister project of OmniOS. But > like many users, I have yet OmniOS installations running > perfectly. For them, it is essential to ask about the future for > the next months or year and needed next steps (can wait some time > or switch as soon as possible). > > > *@**OmniTi* > The end of OmniOS at OmniTi seems final. > > - How long will the website and the repo remain online? > > - Is there an option to fix serious bugsor problems in OmniOS > @OmniTi for > a limited time like 1 year or at least end of the year? > > - Are you willing to transfer the website/name either to a new > OmniOS community project (I cannot see this as an option regarding > the silence about) or to the OpenIndiana community to use it as a > name for a possible stable like OpenIndiana Hipster=dev and > OpenIndiana OmniOS as a stable subset? (if OI is willing to go > that route but the request or offer must come from OmniTi or > OmniOS people). > > OmniOS has a very strong reputation regarding production quality > and stability, so such a step would help both if OpenIndiana and > OmniOS would cooperate in a common project. Seems a pity if the > name would die or remain as a name for a failed project. > > > *@OmniOS developers*(current or former - you have done a very good > job!) > > - Is there an option to fix serious bugs or problems in OmniOS for > a limited time like 1 year or at least end of the year? This would > help until a sucessor (less likely OmniOS 151024, maybe next > OpenIndiana snap with a stable subset) is available. LX would then > remain an OmniOS option in the meantime (I would not dare to ask > about an upstream). > > > > *@all* > comments? > > > > Gea > @napp-it.org > > > _______________________________________________ > 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 an3s.annema at gmail.com Wed Jul 5 15:28:46 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Wed, 5 Jul 2017 17:28:46 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> Message-ID: Wow, indeed! I see I have to catch up on reading the latest developments on the "lobby" discussion and see when and where I can jump in. *thumbs up* Andries On 2017-07-05 16:48, Guenther Alka wrote: > > hello Tobi and Andy > the first good news for 10 Weeks! > > cheers > > Gea > > > Am 05.07.2017 um 16:30 schrieb Tobias Oetiker: >> Gea, >> >> the king is dead, long live the king >> >> https://gitter.im/omniosorg/Lobby >> >> www.omniosce.org >> >> the story continues ... >> >> cheers >> tobi >> >> ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka >> wrote: >> >> *about OmniOS**and the silence for weeks* >> >> For my own future, I have already decided to switch back to >> OpenIndiana, the community based sister project of OmniOS. But >> like many users, I have yet OmniOS installations running >> perfectly. For them, it is essential to ask about the future for >> the next months or year and needed next steps (can wait some time >> or switch as soon as possible). >> >> >> *@**OmniTi* >> The end of OmniOS at OmniTi seems final. >> >> - How long will the website and the repo remain online? >> >> - Is there an option to fix serious bugsor problems in OmniOS >> @OmniTi for >> a limited time like 1 year or at least end of the year? >> >> - Are you willing to transfer the website/name either to a new >> OmniOS community project (I cannot see this as an option >> regarding the silence about) or to the OpenIndiana community to >> use it as a name for a possible stable like OpenIndiana >> Hipster=dev and OpenIndiana OmniOS as a stable subset? (if OI is >> willing to go that route but the request or offer must come from >> OmniTi or OmniOS people). >> >> OmniOS has a very strong reputation regarding production quality >> and stability, so such a step would help both if OpenIndiana and >> OmniOS would cooperate in a common project. Seems a pity if the >> name would die or remain as a name for a failed project. >> >> >> *@OmniOS developers*(current or former - you have done a very >> good job!) >> >> - Is there an option to fix serious bugs or problems in OmniOS >> for a limited time like 1 year or at least end of the year? This >> would help until a sucessor (less likely OmniOS 151024, maybe >> next OpenIndiana snap with a stable subset) is available. LX >> would then remain an OmniOS option in the meantime (I would not >> dare to ask about an upstream). >> >> >> >> *@all* >> comments? >> >> >> >> Gea >> @napp-it.org >> >> >> _______________________________________________ >> 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 info at houseofancients.nl Thu Jul 6 09:34:44 2017 From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..) Date: Thu, 6 Jul 2017 09:34:44 +0000 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> Message-ID: <04B0A5C1206D824F8D310C5B3DB28CC920273FAE@vEX01.mindstorm-internet.local> Hi All, Fully agree with Gea! Kr, Floris Van: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] Namens Guenther Alka Verzonden: woensdag 5 juli 2017 16:48 Aan: omnios-discuss Onderwerp: Re: [OmniOS-discuss] Questions about - End the uncertainty - hello Tobi and Andy the first good news for 10 Weeks! cheers Gea Am 05.07.2017 um 16:30 schrieb Tobias Oetiker: Gea, the king is dead, long live the king https://gitter.im/omniosorg/Lobby www.omniosce.org the story continues ... cheers tobi ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka wrote: about OmniOS and the silence for weeks For my own future, I have already decided to switch back to OpenIndiana, the community based sister project of OmniOS. But like many users, I have yet OmniOS installations running perfectly. For them, it is essential to ask about the future for the next months or year and needed next steps (can wait some time or switch as soon as possible). @OmniTi The end of OmniOS at OmniTi seems final. - How long will the website and the repo remain online? - Is there an option to fix serious bugs or problems in OmniOS @OmniTi for a limited time like 1 year or at least end of the year? - Are you willing to transfer the website/name either to a new OmniOS community project (I cannot see this as an option regarding the silence about) or to the OpenIndiana community to use it as a name for a possible stable like OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable subset? (if OI is willing to go that route but the request or offer must come from OmniTi or OmniOS people). OmniOS has a very strong reputation regarding production quality and stability, so such a step would help both if OpenIndiana and OmniOS would cooperate in a common project. Seems a pity if the name would die or remain as a name for a failed project. @OmniOS developers (current or former - you have done a very good job!) - Is there an option to fix serious bugs or problems in OmniOS for a limited time like 1 year or at least end of the year? This would help until a sucessor (less likely OmniOS 151024, maybe next OpenIndiana snap with a stable subset) is available. LX would then remain an OmniOS option in the meantime (I would not dare to ask about an upstream). @all comments? Gea @napp-it.org _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aurelien.larcher at gmail.com Thu Jul 6 23:47:07 2017 From: aurelien.larcher at gmail.com (=?UTF-8?Q?Aur=C3=A9lien_Larcher?=) Date: Fri, 7 Jul 2017 01:47:07 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> Message-ID: Gea, > > the king is dead, long live the king > > https://gitter.im/omniosorg/Lobby > > www.omniosce.org > > the story continues ... > It is good news, but I would engage you to discuss about reducing the fragmentation in the illumos community. We have a few distros maintained by 1-3 guys without any or much momentum and much duplication of efforts (Debian has 1000+ devs working together and we are barely able to have more than 10). We should join our efforts like, as I suggested, basing on common tools and userland. I do not see how wasting energy in duplicate efforts will help us keep/gain momentum. I mentioned earlier the possibility of a virtuous circle with OI as the rolling testing and OmniOS the stable: to be honest I see very little sense in maintaining two "testing" with such a small manpower. In the long term this does not seem sustainable. At least some degree of collaboration should be maintained on documentation, pkg(5) and updates of Python/Perl/GCC with the same source repository. Of course this is not "right now", as you need to maintain continuity, but we should plan the next 6 month cycle to decide on common requirements and make it happen. I saw Peter has built illumos-omnios on Tribblix, I think we should do the same on OpenIndiana: the issue is not about doing it once (I did it last year) but having a person commited to maintain it. Convergence is necessary, at least to some extent, discussion is open. :) Kind regards Aur?lien > > cheers > tobi > > ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka > wrote: > > *about OmniOS** and the silence for weeks* > > For my own future, I have already decided to switch back to OpenIndiana, > the community based sister project of OmniOS. But like many users, I have > yet OmniOS installations running perfectly. For them, it is essential to > ask about the future for the next months or year and needed next steps (can > wait some time or switch as soon as possible). > > > *@**OmniTi* > The end of OmniOS at OmniTi seems final. > > - How long will the website and the repo remain online? > > - Is there an option to fix serious bugs or problems in OmniOS @OmniTi > for > a limited time like 1 year or at least end of the year? > > - Are you willing to transfer the website/name either to a new OmniOS > community project (I cannot see this as an option regarding the silence > about) or to the OpenIndiana community to use it as a name for a possible > stable like OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable > subset? (if OI is willing to go that route but the request or offer must > come from OmniTi or OmniOS people). > > OmniOS has a very strong reputation regarding production quality and > stability, so such a step would help both if OpenIndiana and OmniOS would > cooperate in a common project. Seems a pity if the name would die or > remain as a name for a failed project. > > > *@OmniOS developers* (current or former - you have done a very good job!) > > - Is there an option to fix serious bugs or problems in OmniOS for a > limited time like 1 year or at least end of the year? This would help until > a sucessor (less likely OmniOS 151024, maybe next OpenIndiana snap with a > stable subset) is available. LX would then remain an OmniOS option in the > meantime (I would not dare to ask about an upstream). > > > > *@all* > comments? > > > > Gea > @napp-it.org > > > _______________________________________________ > 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 <+41%2062%20775%2099%2002> > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -- --- Praise the Caffeine embeddings -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Fri Jul 7 05:21:37 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 7 Jul 2017 07:21:37 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> Message-ID: <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> Hi Aur?lien the motivation behind OmniOSce is that we have come to love the the stability and tight focus of OmniOS. Many of us are running large servers that form critical pieces of our infrastructure. Loosing OmniOS was simply not an option for us. Since OmniTI gave up on this we were forced start doing the work on our own. for now our focus is in building on Dan's excellent work, both in updating r022 as well as pulling in new stuff from both upstream illumos and joyents lx work. we are happy for anyone to join us in our effort, for example also in providing a more end user focussed repo that goes along with omnios, providing a desktop environment for those who want to use the os in that capacity. www.omniosce.org gitter.im/omniosorg/Lobby Tobias Oetiker > On 7 Jul 2017, at 01:47, Aur?lien Larcher wrote: > > > >> Gea, >> >> the king is dead, long live the king >> >> https://gitter.im/omniosorg/Lobby >> >> www.omniosce.org >> >> the story continues ... > > It is good news, but I would engage you to discuss about reducing the fragmentation in the illumos community. > We have a few distros maintained by 1-3 guys without any or much momentum and much duplication of efforts (Debian has 1000+ devs working together and we are barely able to have more than 10). > > We should join our efforts like, as I suggested, basing on common tools and userland. > I do not see how wasting energy in duplicate efforts will help us keep/gain momentum. > I mentioned earlier the possibility of a virtuous circle with OI as the rolling testing and OmniOS the stable: to be honest I see very little sense in maintaining two "testing" with such a small manpower. In the long term this does not seem sustainable. > > At least some degree of collaboration should be maintained on documentation, pkg(5) and updates of Python/Perl/GCC with the same source repository. > > Of course this is not "right now", as you need to maintain continuity, but we should plan the next 6 month cycle to decide on common requirements and make it happen. > I saw Peter has built illumos-omnios on Tribblix, I think we should do the same on OpenIndiana: the issue is not about doing it once (I did it last year) but having a person commited to maintain it. > > Convergence is necessary, at least to some extent, discussion is open. :) > > Kind regards > > Aur?lien > >> >> cheers >> tobi >> >> ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka wrote: >> about OmniOS and the silence for weeks >> >> For my own future, I have already decided to switch back to OpenIndiana, the community based sister project of OmniOS. But like many users, I have yet OmniOS installations running perfectly. For them, it is essential to ask about the future for the next months or year and needed next steps (can wait some time or switch as soon as possible). >> >> >> @OmniTi >> The end of OmniOS at OmniTi seems final. >> >> - How long will the website and the repo remain online? >> >> - Is there an option to fix serious bugs or problems in OmniOS @OmniTi for >> a limited time like 1 year or at least end of the year? >> >> - Are you willing to transfer the website/name either to a new OmniOS community project (I cannot see this as an option regarding the silence about) or to the OpenIndiana community to use it as a name for a possible stable like OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable subset? (if OI is willing to go that route but the request or offer must come from OmniTi or OmniOS people). >> >> OmniOS has a very strong reputation regarding production quality and stability, so such a step would help both if OpenIndiana and OmniOS would cooperate in a common project. Seems a pity if the name would die or remain as a name for a failed project. >> >> >> @OmniOS developers (current or former - you have done a very good job!) >> >> - Is there an option to fix serious bugs or problems in OmniOS for a limited time like 1 year or at least end of the year? This would help until a sucessor (less likely OmniOS 151024, maybe next OpenIndiana snap with a stable subset) is available. LX would then remain an OmniOS option in the meantime (I would not dare to ask about an upstream). >> >> >> >> @all >> comments? >> >> >> >> Gea >> @napp-it.org >> >> _______________________________________________ >> 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 >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > > > > -- > --- > Praise the Caffeine embeddings -------------- next part -------------- An HTML attachment was scrubbed... URL: From aurelien.larcher at gmail.com Fri Jul 7 05:55:58 2017 From: aurelien.larcher at gmail.com (=?UTF-8?Q?Aur=C3=A9lien_Larcher?=) Date: Fri, 7 Jul 2017 07:55:58 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> Message-ID: On Fri, Jul 7, 2017 at 7:21 AM, Tobias Oetiker wrote: > Hi Aur?lien > > the motivation behind OmniOSce is that we have come to love the the > stability and > tight focus of OmniOS. Many of us are running large servers that form > critical pieces of our infrastructure. Loosing OmniOS was simply not an > option for us. Since OmniTI gave up on this we were forced start doing the > work on our own. > Your answer makes me think I was not clear enough or that we are discussing two different things ... My point was about collaboration not about losing what you like. > > for now our focus is in building on Dan's excellent work, both in updating > r022 as well as pulling in new stuff from both upstream illumos and joyents > lx work. > Which is understandable ;) On the other hand I raised a few questions about collaboration and perspectives which I thought could be worth discussing beyond the current state of affairs. > we are happy for anyone to join us in our effort, for example also in > providing a more end user focussed repo that goes along with omnios, > providing a desktop environment for those who want to use the os in that > capacity. > If we want another general-purpose distro with 2 maintainers and 10 users that's certainly the way to go ;) > > www.omniosce.org > gitter.im/omniosorg/Lobby > > Tobias Oetiker > > On 7 Jul 2017, at 01:47, Aur?lien Larcher > wrote: > > > > Gea, >> >> the king is dead, long live the king >> >> https://gitter.im/omniosorg/Lobby >> >> www.omniosce.org >> >> the story continues ... >> > > It is good news, but I would engage you to discuss about reducing the > fragmentation in the illumos community. > We have a few distros maintained by 1-3 guys without any or much momentum > and much duplication of efforts (Debian has 1000+ devs working together and > we are barely able to have more than 10). > > We should join our efforts like, as I suggested, basing on common tools > and userland. > I do not see how wasting energy in duplicate efforts will help us > keep/gain momentum. > I mentioned earlier the possibility of a virtuous circle with OI as the > rolling testing and OmniOS the stable: to be honest I see very little sense > in maintaining two "testing" with such a small manpower. In the long term > this does not seem sustainable. > > At least some degree of collaboration should be maintained on > documentation, pkg(5) and updates of Python/Perl/GCC with the same source > repository. > > Of course this is not "right now", as you need to maintain continuity, but > we should plan the next 6 month cycle to decide on common requirements and > make it happen. > I saw Peter has built illumos-omnios on Tribblix, I think we should do the > same on OpenIndiana: the issue is not about doing it once (I did it last > year) but having a person commited to maintain it. > > Convergence is necessary, at least to some extent, discussion is open. :) > > Kind regards > > Aur?lien > > >> >> cheers >> tobi >> >> ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka >> wrote: >> >> *about OmniOS** and the silence for weeks* >> >> For my own future, I have already decided to switch back to OpenIndiana, >> the community based sister project of OmniOS. But like many users, I have >> yet OmniOS installations running perfectly. For them, it is essential to >> ask about the future for the next months or year and needed next steps (can >> wait some time or switch as soon as possible). >> >> >> *@**OmniTi* >> The end of OmniOS at OmniTi seems final. >> >> - How long will the website and the repo remain online? >> >> - Is there an option to fix serious bugs or problems in OmniOS @OmniTi >> for >> a limited time like 1 year or at least end of the year? >> >> - Are you willing to transfer the website/name either to a new OmniOS >> community project (I cannot see this as an option regarding the silence >> about) or to the OpenIndiana community to use it as a name for a possible >> stable like OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable >> subset? (if OI is willing to go that route but the request or offer must >> come from OmniTi or OmniOS people). >> >> OmniOS has a very strong reputation regarding production quality and >> stability, so such a step would help both if OpenIndiana and OmniOS would >> cooperate in a common project. Seems a pity if the name would die or >> remain as a name for a failed project. >> >> >> *@OmniOS developers* (current or former - you have done a very good job!) >> >> - Is there an option to fix serious bugs or problems in OmniOS for a >> limited time like 1 year or at least end of the year? This would help until >> a sucessor (less likely OmniOS 151024, maybe next OpenIndiana snap with >> a stable subset) is available. LX would then remain an OmniOS option in >> the meantime (I would not dare to ask about an upstream). >> >> >> >> *@all* >> comments? >> >> >> >> Gea >> @napp-it.org >> >> >> _______________________________________________ >> 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 <+41%2062%20775%2099%2002> >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> > > > -- > --- > Praise the Caffeine embeddings > > -- --- Praise the Caffeine embeddings -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Fri Jul 7 06:04:45 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 7 Jul 2017 08:04:45 +0200 (CEST) Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> Message-ID: <353549195.775282.1499407485409.JavaMail.zimbra@oetiker.ch> Hi Aur?lien, ----- On Jul 7, 2017, at 7:55 AM, Aur?lien Larcher wrote: > On Fri, Jul 7, 2017 at 7:21 AM, Tobias Oetiker < [ mailto:tobi at oetiker.ch | > tobi at oetiker.ch ] > wrote: >> Hi Aur?lien >> the motivation behind OmniOSce is that we have come to love the the stability >> and >> tight focus of OmniOS. Many of us are running large servers that form critical >> pieces of our infrastructure. Loosing OmniOS was simply not an option for us. >> Since OmniTI gave up on this we were forced start doing the work on our own. > Your answer makes me think I was not clear enough or that we are discussing two > different things ... > My point was about collaboration not about losing what you like. nothing against collaboration, on the contrary ... when looking at omnios now (with the focus of it being a server os) what do you see that is missing which oi folks could contribute, or which we could pull from oi ? >> we are happy for anyone to join us in our effort, for example also in providing >> a more end user focussed repo that goes along with omnios, providing a desktop >> environment for those who want to use the os in that capacity. > If we want another general-purpose distro with 2 maintainers and 10 users that's > certainly the way to go ;) we are not general purpose in that sense. cheers tobi >> [ http://www.omniosce.org/ | www.omniosce.org ] >> [ http://gitter.im/omniosorg/Lobby | gitter.im/omniosorg/Lobby ] >> Tobias Oetiker >> On 7 Jul 2017, at 01:47, Aur?lien Larcher < [ mailto:aurelien.larcher at gmail.com >> | aurelien.larcher at gmail.com ] > wrote: >>>> Gea, >>>> the king is dead, long live the king >>>> [ https://gitter.im/omniosorg/Lobby | https://gitter.im/omniosorg/Lobby ] >>>> [ http://www.omniosce.org/ | www.omniosce.org ] >>>> the story continues ... >>> It is good news, but I would engage you to discuss about reducing the >>> fragmentation in the illumos community. >>> We have a few distros maintained by 1-3 guys without any or much momentum and >>> much duplication of efforts (Debian has 1000+ devs working together and we are >>> barely able to have more than 10). >>> We should join our efforts like, as I suggested, basing on common tools and >>> userland. >>> I do not see how wasting energy in duplicate efforts will help us keep/gain >>> momentum. >>> I mentioned earlier the possibility of a virtuous circle with OI as the rolling >>> testing and OmniOS the stable: to be honest I see very little sense in >>> maintaining two "testing" with such a small manpower. In the long term this >>> does not seem sustainable. >>> At least some degree of collaboration should be maintained on documentation, >>> pkg(5) and updates of Python/Perl/GCC with the same source repository. >>> Of course this is not "right now", as you need to maintain continuity, but we >>> should plan the next 6 month cycle to decide on common requirements and make it >>> happen. >>> I saw Peter has built illumos-omnios on Tribblix, I think we should do the same >>> on OpenIndiana: the issue is not about doing it once (I did it last year) but >>> having a person commited to maintain it. >>> Convergence is necessary, at least to some extent, discussion is open. :) >>> Kind regards >>> Aur?lien >>>> cheers >>>> tobi >>>> ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka < [ mailto:alka at hfg-gmuend.de | >>>> alka at hfg-gmuend.de ] > wrote: >>>>> about OmniOS and the silence for weeks >>>>> For my own future, I have already decided to switch back to OpenIndiana, the >>>>> community based sister project of OmniOS. But like many users, I have yet >>>>> OmniOS installations running perfectly. For them, it is essential to ask about >>>>> the future for the next months or year and needed next steps (can wait some >>>>> time or switch as soon as possible). >>>>> @ OmniTi >>>>> The end of OmniOS at OmniTi seems final. >>>>> - How long will the website and the repo remain online? >>>>> - Is there an option to fix serious bugs or problems in OmniOS @OmniTi for >>>>> a limited time like 1 year or at least end of the year? >>>>> - Are you willing to transfer the website/name either to a new OmniOS community >>>>> project (I cannot see this as an option regarding the silence about) or to the >>>>> OpenIndiana community to use it as a name for a possible stable like >>>>> OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable subset? (if OI is >>>>> willing to go that route but the request or offer must come from OmniTi or >>>>> OmniOS people). >>>>> OmniOS has a very strong reputation regarding production quality and stability, >>>>> so such a step would help both if OpenIndiana and OmniOS would cooperate in a >>>>> common project. Seems a pity if the name would die or remain as a name for a >>>>> failed project. >>>>> @OmniOS developers (current or former - you have done a very good job!) >>>>> - Is there an option to fix serious bugs or problems in OmniOS for a limited >>>>> time like 1 year or at least end of the year? This would help until a sucessor >>>>> (less likely OmniOS 151024 , maybe next OpenIndiana snap with a stable subset) >>>>> is available. LX would then remain an OmniOS option in the meantime (I would >>>>> not dare to ask about an upstream). >>>>> @all >>>>> comments? >>>>> Gea >>>>> @ [ http://napp-it.org/ | napp-it.org ] >>>>> _______________________________________________ >>>>> OmniOS-discuss mailing list >>>>> [ mailto:OmniOS-discuss at lists.omniti.com | OmniOS-discuss at lists.omniti.com ] >>>>> [ http://lists.omniti.com/mailman/listinfo/omnios-discuss | >>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss ] >>>> -- >>>> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland >>>> [ http://www.oetiker.ch/ | www.oetiker.ch ] [ mailto:tobi at oetiker.ch | >>>> tobi at oetiker.ch ] [ tel:+41%2062%20775%2099%2002 | +41 62 775 9902 ] >>>> _______________________________________________ >>>> OmniOS-discuss mailing list >>>> [ mailto:OmniOS-discuss at lists.omniti.com | OmniOS-discuss at lists.omniti.com ] >>>> [ http://lists.omniti.com/mailman/listinfo/omnios-discuss | >>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss ] >>> -- >>> --- >>> Praise the Caffeine embeddings > -- > --- > Praise the Caffeine embeddings -- 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.tribble at gmail.com Fri Jul 7 08:24:01 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Fri, 7 Jul 2017 09:24:01 +0100 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> Message-ID: On Fri, Jul 7, 2017 at 12:47 AM, Aur?lien Larcher < aurelien.larcher at gmail.com> wrote: > It is good news, but I would engage you to discuss about reducing the > fragmentation in the illumos community. > We have a few distros maintained by 1-3 guys without any or much momentum > and much duplication of efforts (Debian has 1000+ devs working together and > we are barely able to have more than 10). > > We should join our efforts like, as I suggested, basing on common tools > and userland. > I do not see how wasting energy in duplicate efforts will help us > keep/gain momentum. > I don't actually see significant duplication of effort. In the case of OI and OmniOS, there's not much overlap because the work is in completely separate areas. Each community or distro does work that largely falls into 2 categories: work that's only relevant to that community, or work that, because it's all open source and published, can easily be picked up by someone else. > I mentioned earlier the possibility of a virtuous circle with OI as the > rolling testing and OmniOS the stable: to be honest I see very little sense > in maintaining two "testing" with such a small manpower. In the long term > this does not seem sustainable. > Attempting to coerce 2 projects together is even worse; each is then compromised by having to work not only to its own rules and schedule but has to fit in with the other project too. You have the relationship between OI and OmniOS inverted, I think. The only merge I can see making sense is for OI to rebase on illumos-omnios rather than illumos-gate - in which case OI is a downstream derivative of OmniOS. (The situation of OmniOS being the "stable" branch of OI is unlikely to work. Apart from the philosophical and technical incompatibilities, it's relatively easy to have an unstable/testing branch of a stable project, but it's hard to take a rolling testing project and build a stable project on top of it. Besides, that would require OI to do an awful lot of work in terms of backporting/release engineering/testing and the like that isn't directly relevant to them which would then have to be duplicated downstream as well.) Generally, if you have mature intelligent people forming communities they will naturally form reasonably optimal structures. People tend to make choices that make it easier for them to make progress. (Yes, it's a local maximum rather than a global one.) Telling people what they ought to do tends not to be well received; if you want to change the behaviour of people or the structure then you need to game the system to give people better options than the one they've currently chosen. Cheers, -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aurelien.larcher at gmail.com Fri Jul 7 09:21:26 2017 From: aurelien.larcher at gmail.com (=?UTF-8?Q?Aur=C3=A9lien_Larcher?=) Date: Fri, 7 Jul 2017 11:21:26 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> Message-ID: On Fri, Jul 7, 2017 at 10:24 AM, Peter Tribble wrote: > > > On Fri, Jul 7, 2017 at 12:47 AM, Aur?lien Larcher < > aurelien.larcher at gmail.com> wrote: > >> It is good news, but I would engage you to discuss about reducing the >> fragmentation in the illumos community. >> We have a few distros maintained by 1-3 guys without any or much momentum >> and much duplication of efforts (Debian has 1000+ devs working together and >> we are barely able to have more than 10). >> >> We should join our efforts like, as I suggested, basing on common tools >> and userland. >> I do not see how wasting energy in duplicate efforts will help us >> keep/gain momentum. >> > > I don't actually see significant duplication of effort. In the case of OI > and OmniOS, there's not much overlap because the work is in > completely separate areas. > Not much overlap as in server use? > > Each community or distro does work that largely falls into 2 categories: > work that's only relevant to that community, or work that, because it's > all open source and published, can easily be picked up by someone else. > How about lowering the barrier to make "easily" easier? > > >> I mentioned earlier the possibility of a virtuous circle with OI as the >> rolling testing and OmniOS the stable: to be honest I see very little sense >> in maintaining two "testing" with such a small manpower. In the long term >> this does not seem sustainable. >> > > Attempting to coerce 2 projects together is even worse; each is then > compromised by having to work not only to its own rules and schedule > but has to fit in with the other project too. > > You have the relationship between OI and OmniOS inverted, I think. > The only merge I can see making sense is for OI to rebase on > illumos-omnios rather than illumos-gate - in which case OI is a downstream > derivative of OmniOS. > Interesting > > (The situation of OmniOS being the "stable" branch of OI is unlikely to > work. Apart from the philosophical and technical incompatibilities, it's > relatively easy to have an unstable/testing branch of a stable project, > but it's hard to take a rolling testing project and build a stable project > on top of it. Besides, that would require OI to do an awful lot of work > in terms of backporting/release engineering/testing and the like that > isn't directly relevant to them which would then have to be duplicated > downstream as well.) > > Generally, if you have mature intelligent people forming communities > they will naturally form reasonably optimal structures. People tend to > make choices that make it easier for them to make progress. (Yes, it's > a local maximum rather than a global one.) Telling people what they > ought to do tends not to be well received; if you want to change the > behaviour of people or the structure then you need to game the system > to give people better options than the one they've currently chosen. > Being too enthusiastic can be interpreted in a negative way. Discussing the possibilities seems is indeed unreasonable since coercion should be avoided at all cost and most likely nothing will work out. You are right, sorry for the disturbance. Let us move along in the saddle point. Kind regards, Aur?lien Cheers, > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > -- --- Praise the Caffeine embeddings -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimklimov at cos.ru Fri Jul 7 11:16:36 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Fri, 07 Jul 2017 11:16:36 +0000 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> Message-ID: On July 7, 2017 7:21:37 AM GMT+02:00, Tobias Oetiker wrote: >Hi Aur?lien > >the motivation behind OmniOSce is that we have come to love the the >stability and >tight focus of OmniOS. Many of us are running large servers that form >critical pieces of our infrastructure. Loosing OmniOS was simply not an >option for us. Since OmniTI gave up on this we were forced start doing >the work on our own. > >for now our focus is in building on Dan's excellent work, both in >updating r022 as well as pulling in new stuff from both upstream >illumos and joyents lx work. > >we are happy for anyone to join us in our effort, for example also in >providing a more end user focussed repo that goes along with omnios, >providing a desktop environment for those who want to use the os in >that capacity. > >www.omniosce.org >gitter.im/omniosorg/Lobby > >Tobias Oetiker > >> On 7 Jul 2017, at 01:47, Aur?lien Larcher > wrote: >> >> >> >>> Gea, >>> >>> the king is dead, long live the king >>> >>> https://gitter.im/omniosorg/Lobby >>> >>> www.omniosce.org >>> >>> the story continues ... >> >> It is good news, but I would engage you to discuss about reducing the >fragmentation in the illumos community. >> We have a few distros maintained by 1-3 guys without any or much >momentum and much duplication of efforts (Debian has 1000+ devs working >together and we are barely able to have more than 10). >> >> We should join our efforts like, as I suggested, basing on common >tools and userland. >> I do not see how wasting energy in duplicate efforts will help us >keep/gain momentum. >> I mentioned earlier the possibility of a virtuous circle with OI as >the rolling testing and OmniOS the stable: to be honest I see very >little sense in maintaining two "testing" with such a small manpower. >In the long term this does not seem sustainable. >> >> At least some degree of collaboration should be maintained on >documentation, pkg(5) and updates of Python/Perl/GCC with the same >source repository. >> >> Of course this is not "right now", as you need to maintain >continuity, but we should plan the next 6 month cycle to decide on >common requirements and make it happen. >> I saw Peter has built illumos-omnios on Tribblix, I think we should >do the same on OpenIndiana: the issue is not about doing it once (I did >it last year) but having a person commited to maintain it. >> >> Convergence is necessary, at least to some extent, discussion is >open. :) >> >> Kind regards >> >> Aur?lien >> >>> >>> cheers >>> tobi >>> >>> ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka >wrote: >>> about OmniOS and the silence for weeks >>> >>> For my own future, I have already decided to switch back to >OpenIndiana, the community based sister project of OmniOS. But like >many users, I have yet OmniOS installations running perfectly. For >them, it is essential to ask about the future for the next months or >year and needed next steps (can wait some time or switch as soon as >possible). >>> >>> >>> @OmniTi >>> The end of OmniOS at OmniTi seems final. >>> >>> - How long will the website and the repo remain online? >>> >>> - Is there an option to fix serious bugs or problems in OmniOS >@OmniTi for >>> a limited time like 1 year or at least end of the year? >>> >>> - Are you willing to transfer the website/name either to a new >OmniOS community project (I cannot see this as an option regarding the >silence about) or to the OpenIndiana community to use it as a name for >a possible stable like OpenIndiana Hipster=dev and OpenIndiana OmniOS >as a stable subset? (if OI is willing to go that route but the request >or offer must come from OmniTi or OmniOS people). >>> >>> OmniOS has a very strong reputation regarding production quality and >stability, so such a step would help both if OpenIndiana and OmniOS >would cooperate in a common project. Seems a pity if the name would die >or remain as a name for a failed project. >>> >>> >>> @OmniOS developers (current or former - you have done a very good >job!) >>> >>> - Is there an option to fix serious bugs or problems in OmniOS for a >limited time like 1 year or at least end of the year? This would help >until a sucessor (less likely OmniOS 151024, maybe next OpenIndiana >snap with a stable subset) is available. LX would then remain an OmniOS >option in the meantime (I would not dare to ask about an upstream). >>> >>> >>> >>> @all >>> comments? >>> >>> >>> >>> Gea >>> @napp-it.org >>> >>> _______________________________________________ >>> 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 >>> >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >> >> >> >> -- >> --- >> Praise the Caffeine embeddings Hello all, I posted my opinion and advice in the lobby, but just in case the mailing list has more visibility so far, would like to repeat or expand a few points here. Especially as I tinker with both OpenIndiana and OmniOS based systems so can hopefully see how to bridge some gaps and benefit from commonalities. First of all - kudos and best of luck in your effort. Indeed, keeping existing systems afloat and up-to-date is an important priority, and there are quite a few interesting and important technical issues to take care of even if the workflow and system structure stays as unchanged as possible. Also, the well-earned perception of OmniOS releases as a dependable, feature-full and unbloated OS, both for use "as is" and as a foundation for further value-added products that some teams work on, is also valuable to keep and uphold. Unfortunately, as seen from these recent discussions too, this stance sort of robs away most of the same values, unjustly, from OpenIndiana (we mean rolling Hipster, not old stale "dev"). Kind of childish "we are good, so others must be worse or outright bad" and kind of misinformed "we know little of that, so it must be unworthy of attention" or that it is a bloated desktop distro vs. minimal server one. These two general-purpose distros share more than what they differ in, compared to say SmartOS or Delphix or Nexenta who chose to excel in particular directions and sort of neglect or forbid others (e.g. installation of random software on a filer, making it also a big-data processing machine or a standalone home firewall, dev rig, webserver and downloader of stuff). For my part, I don't want to keep choosing which of the two distros to base my next rig on, given they are almost the same except this tiny bit here or there... In fact, OI never was 'just a desktop distro' of arguable stability. The "dev" version is dead-stable ;) while the current focus of activity, OI Hipster, is very comparable to OmniOS Bloody - just a lot more active, with dozens of PRs monthly from several contributors to update packages following upstream releases and CVEs. Still, not many enough to even get started tackling some goals. OI is a general purpose set, usable both headless with small footprint, and with GUIs out of the box, depending on which set of packages (pre-selected as incorporations or manually picked) you install into a BE. Granted, it does have a lot more packages than omnios in main repo - bit no-one forces you to install them all at once ;) The os/net in particular builds on vanilla illumos-gate I guess on purpose - to have no more and no less than the codebase which passed the RTI process. And because there's not enough manpower to dedicate to picking bits and staying on top of bugs, on a daily basis. So it's as stable as it gets, and as soon as that lands. If someone commits to maintaining a stable and up-to-date fork like omnios-gate (which needs to be done even if the teams do stay apart), I don't think there would be much opposition to serving those osnet packages as part of OI instead of vanilla illumos-gate. Perhaps it might be possible to use pkg(5) features like facets or variants to provide a vanilla (oi) or patched (oo) os/net packages in same repo... When there's breakage in OI, that's usually after GUI libs and pkgs upgrades; the 'server-only' SW is less interwoven. It is also quite stable that people entrust their production services to it and can carelessly update at will - especially if they do only care for (and install) the server-oriented subset of packages. Of course, corner cases can happen on any platform, but they are not the norm :) I guess the issue of manpower also applies to amount of releases (namely - just the bloody one). Keeping up a stable release (or several) with hotfixes and little turbulence feature-wise, until a scheduled another one comes out, is also quite an effort, and a mindset for people involved... That's again where cooperation of OpenIndiana and OmniOS teams can be fruitful. Someone to pioneer the hordes of changes... and someone to cherry-pick the good ones as stable. If the projects were to unite efforts - or further pose as different facets of the same effort with same underlying technologies, the 'omnios server' set of packages is IMHO just a matter of defining an incorporation that depends on said packages. Which may be close to what OI minimal/text already are (at least assuming that actual third-party software versions are close enough). Of course, even if the projects and teams do choose to converge, it ain't a single-day effort. Some packages are bound to be named differently, some default settings or OS accounts can differ... the unfortunate difference in naming and behavior of linked and non-linked zones would bite us, the osnet mentioned above... But at least we might avoid the duplicate effort of updating third-party packages like bind, openssl et al as their cve's come into spotlight ;) Regarding approaches to building userland, I think it is even a lot more a question about the 'engine' to build userland than about the particular components' recipes (desktop or not). And about the convenience to use and change and share those recipes (and the engine too). OmniOS approach with small core and BYOSW for everything else encourages repetition of effort for every user. The OI approach allows one to build particular packages locally (e.g. with custom settings or patches) using a clone of the common recipe repo, and install them from local pkgrepo as a preferred source, keeping the ability to pull updates from common upstream and have ypur local Jenkins build them automatically. Finally it is easy to share back recipes for components that are not there yet (or your updates to recipes) - and get PR feedback from additional eyeballs - and switch your IPS packaging back to use the component from common repos and get updates as *other* people keep improving it. I'd say oi-userland is more welcoming to cooperation and in particular to getting started with - as more new people have shaved away the rough edges in common docs and scripts in recent history. So to answer one of the latest excellent questions in the lobby - "what is it, that OmniOSce should be pulling/merging from OI to make it even cooler?" - I think it would be more about sharing and cross-pollinating to erode the few differences until the inner workings are indistinguishable :) It may be more about adopting some backend/distro-building procedures than pulling this and that bit of code. Of course, about sharing the load over more people eager to be active in the same area. Ultimately, reaping the fruits of an effort done anyway to update the same pieces of code (such as updating and hot-fixing third-party packages), with this effort in OI being perhaps more intensive and public than what OmniOS has seen as part of a "corporate" effort. Possibly, it could bring benefits of an already established and automated procedure to build and publish the updated userland in a way that may be more simple and scalable and shareable than omnios's (though, this may be subjective until proven objective ;)). The coolness for OmniOSce might be to have more sharing of work done anyway by people who want just the stable core and then some (surprisingly same) BYO packages. The benefit for OI might be LX zones and growing a stable release. Ultimately, people from both projects would gain to do less of the same with the limited amount of man-hours we have in both communities, and free up resources to do more of different and new and exciting. Jim Klimov -- Typos courtesy of K-9 Mail on my Redmi Android From alka at hfg-gmuend.de Fri Jul 7 14:31:41 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Fri, 7 Jul 2017 16:31:41 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> Message-ID: Hello Jim and @all I am using OmniOS and OI for years and I fully agree with you. Your position and that of Aur?lian and Tobi are not identical but not too far away and may be the base to find a solution for a win-win situation for all that suits the needs and wants of all. In the current lifecycle, no question; we need a continuation of OmniOS 151022 and OI in their current state as there are many users around. But then it seems increditable stupid if the next OmniOS and OpenIndiana are based on a whole different base, distribution, infrastructure or promotion and this discussion really offers some new oportunities due the "revival" on OmniOS-ce side. I am not involved in either OS distribution so you may correct me on wrong statements but as I see: *OmniOS and OI Hipster Text are nearly identical in core functions and stability as this is inherited from Illumos* OI is quite vanilla Illumos while OmniOS is based on a copy as a freeze or subset of Vanilla Illumos with LX as addon? If this is right, the more valuable part is the OmniOS clone when it comes to LX, continuation and stablity. Using OI current as common base would require to create a new stable clone and work to integrate LX, much more work to do and we have this aleady done in OmniOS. Adding the current OI featureset seems possible on top of Vanilla Ilumos and OmniOS Illumos. *Is this possible or an option?* *What is the stance of OI to use OmniOS-Illumos as source instead of Vanilla Illumos?* This will give both the current stable base where common work is done while OI has the option to add the full set of its current add-ons via a repository, not to forget that for me a GUI for local filemanagement and storagemanagement is a very valuable add-on for a server. Both are using in such a scenario one stable core stable/lts repository every 6 months like currently - similar or smaller than the current OmniOS and adds extra functionalities by an extended repository that adds an enhanced featureset. The rest is simple *OI is an established distribution with a small but working team to maintain and build a distribution, a known name and website, **a wiki, download and repo mirrors etc, a common project should be based upon using OpenIndiana as common roof? The difference may be only in OI-Hipster (general use server or desktop) vs OI-OmniOS_ce (minimal stable storage server) with two distributions Text (OI-OmniOS_ce and a base repo) and GUI (OI Hipster, the same but with GUI and other services due an additional enhanced repo)* No need to duplicate work. Even if both sides are requested to compromise, both wins. All current and new manpower can be used to make the common project better or extend it for more use cases. Maybe a switch to the OI installer is desirable as it offers a network setting option on initial setup. The OmniOS installer is annoying regarding this comments? Gea @napp-it.org > Hello all, > > I posted my opinion and advice in the lobby, but just in case the mailing list has more visibility so far, would like to repeat or expand a few points here. Especially as I tinker with both OpenIndiana and OmniOS based systems so can hopefully see how to bridge some gaps and benefit from commonalities. > > First of all - kudos and best of luck in your effort. Indeed, keeping existing systems afloat and up-to-date is an important priority, and there are quite a few interesting and important technical issues to take care of even if the workflow and system structure stays as unchanged as possible. > > Also, the well-earned perception of OmniOS releases as a dependable, feature-full and unbloated OS, both for use "as is" and as a foundation for further value-added products that some teams work on, is also valuable to keep and uphold. Unfortunately, as seen from these recent discussions too, this stance sort of robs away most of the same values, unjustly, from OpenIndiana (we mean rolling Hipster, not old stale "dev"). Kind of childish "we are good, so others must be worse or outright bad" and kind of misinformed "we know little of that, so it must be unworthy of attention" or that it is a bloated desktop distro vs. minimal server one. > > These two general-purpose distros share more than what they differ in, compared to say SmartOS or Delphix or Nexenta who chose to excel in particular directions and sort of neglect or forbid others (e.g. installation of random software on a filer, making it also a big-data processing machine or a standalone home firewall, dev rig, webserver and downloader of stuff). For my part, I don't want to keep choosing which of the two distros to base my next rig on, given they are almost the same except this tiny bit here or there... > > In fact, OI never was 'just a desktop distro' of arguable stability. The "dev" version is dead-stable ;) while the current focus of activity, OI Hipster, is very comparable to OmniOS Bloody - just a lot more active, with dozens of PRs monthly from several contributors to update packages following upstream releases and CVEs. Still, not many enough to even get started tackling some goals. > > OI is a general purpose set, usable both headless with small footprint, and with GUIs out of the box, depending on which set of packages (pre-selected as incorporations or manually picked) you install into a BE. Granted, it does have a lot more packages than omnios in main repo - bit no-one forces you to install them all at once ;) > > The os/net in particular builds on vanilla illumos-gate I guess on purpose - to have no more and no less than the codebase which passed the RTI process. And because there's not enough manpower to dedicate to picking bits and staying on top of bugs, on a daily basis. So it's as stable as it gets, and as soon as that lands. > > If someone commits to maintaining a stable and up-to-date fork like omnios-gate (which needs to be done even if the teams do stay apart), I don't think there would be much opposition to serving those osnet packages as part of OI instead of vanilla illumos-gate. Perhaps it might be possible to use pkg(5) features like facets or variants to provide a vanilla (oi) or patched (oo) os/net packages in same repo... > > When there's breakage in OI, that's usually after GUI libs and pkgs upgrades; the 'server-only' SW is less interwoven. It is also quite stable that people entrust their production services to it and can carelessly update at will - especially if they do only care for (and install) the server-oriented subset of packages. Of course, corner cases can happen on any platform, but they are not the norm :) > > I guess the issue of manpower also applies to amount of releases (namely - just the bloody one). Keeping up a stable release (or several) with hotfixes and little turbulence feature-wise, until a scheduled another one comes out, is also quite an effort, and a mindset for people involved... That's again where cooperation of OpenIndiana and OmniOS teams can be fruitful. Someone to pioneer the hordes of changes... and someone to cherry-pick the good ones as stable. > > If the projects were to unite efforts - or further pose as different facets of the same effort with same underlying technologies, the 'omnios server' set of packages is IMHO just a matter of defining an incorporation that depends on said packages. Which may be close to what OI minimal/text already are (at least assuming that actual third-party software versions are close enough). > > Of course, even if the projects and teams do choose to converge, it ain't a single-day effort. Some packages are bound to be named differently, some default settings or OS accounts can differ... the unfortunate difference in naming and behavior of linked and non-linked zones would bite us, the osnet mentioned above... But at least we might avoid the duplicate effort of updating third-party packages like bind, openssl et al as their cve's come into spotlight ;) > > Regarding approaches to building userland, I think it is even a lot more a question about the 'engine' to build userland than about the particular components' recipes (desktop or not). And about the convenience to use and change and share those recipes (and the engine too). OmniOS approach with small core and BYOSW for everything else encourages repetition of effort for every user. The OI approach allows one to build particular packages locally (e.g. with custom settings or patches) using a clone of the common recipe repo, and install them from local pkgrepo as a preferred source, keeping the ability to pull updates from common upstream and have ypur local Jenkins build them automatically. Finally it is easy to share back recipes for components that are not there yet (or your updates to recipes) - and get PR feedback from additional eyeballs - and switch your IPS packaging back to use the component from common repos and get updates as *other* people keep improving it. I'd say oi-userland is more welcoming to cooperation and in particular to getting started with - as more new people have shaved away the rough edges in common docs and scripts in recent history. > > So to answer one of the latest excellent questions in the lobby - "what is it, that OmniOSce should be pulling/merging from OI to make it even cooler?" - I think it would be more about sharing and cross-pollinating to erode the few differences until the inner workings are indistinguishable :) It may be more about adopting some backend/distro-building procedures than pulling this and that bit of code. Of course, about sharing the load over more people eager to be active in the same area. Ultimately, reaping the fruits of an effort done anyway to update the same pieces of code (such as updating and hot-fixing third-party packages), with this effort in OI being perhaps more intensive and public than what OmniOS has seen as part of a "corporate" effort. Possibly, it could bring benefits of an already established and automated procedure to build and publish the updated userland in a way that may be more simple and scalable and shareable than omnios's (though, this may be subjective until proven objective ;)). The coolness for OmniOSce might be to have more sharing of work done anyway by people who want just the stable core and then some (surprisingly same) BYO packages. The benefit for OI might be LX zones and growing a stable release. Ultimately, people from both projects would gain to do less of the same with the limited amount of man-hours we have in both communities, and free up resources to do more of different and new and exciting. > > Jim Klimov > -- > 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 mir at miras.org Fri Jul 7 15:01:59 2017 From: mir at miras.org (Michael Rasmussen) Date: Fri, 7 Jul 2017 17:01:59 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> Message-ID: <20170707170159.3b802ed1@sleipner.datanom.net> On Fri, 7 Jul 2017 16:31:41 +0200 Guenther Alka wrote: > > Maybe a switch to the OI installer is desirable as it offers a network setting option on initial setup. > The OmniOS installer is annoying regarding this > > I have raised an issue against the kayak installer regarding this and a solution as well. See https://github.com/omniosorg/kayak/issues/1 -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: Q: "What is the burning question on the mind of every dyslexic existentialist?" A: "Is there a dog?" -------------- 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 kebe.com Fri Jul 7 15:14:25 2017 From: danmcd at kebe.com (Dan McDonald) Date: Fri, 7 Jul 2017 11:14:25 -0400 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <20170707170159.3b802ed1@sleipner.datanom.net> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> Message-ID: <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> > On Jul 7, 2017, at 11:01 AM, Michael Rasmussen wrote: > >> Maybe a switch to the OI installer is desirable as it offers a network setting option on initial setup. >> The OmniOS installer is annoying regarding this I switched the OmniOS installer AWAY from Caiman because I wanted to disentangle from Python. During the r151024 timeframe, one of the things on my plate was going to be a "install postprocessing" menu option on the Kayak menu. The idea would be if you wanted to get things set prior to your next boot, you'd go into that. It seemed appropriate for an interactive installer, while still keeping the spirit of REALLY FAST, DAMMIT that Kayak embodied. My suggestion, and you can dismiss it of course, it to build the postprocessing menu option. It'd bring up a new screen, full of choices like "configure networking", "Set root password", "Add users", etc. etc. Dan From alka at hfg-gmuend.de Fri Jul 7 15:42:33 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Fri, 7 Jul 2017 17:42:33 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> Message-ID: <347d2394-f535-46f4-c42a-0647cc64303b@hfg-gmuend.de> hello Dan Thanks for jumping in. You are the person with the very best insights in OmniOSand Illumos and propably OI. Can you please comment about the options to cooperate with OI. Is this doable and wishable from your point of viewand how or do you have an alternative idea for a positive future of OmniOS ce or free Illumos based general use servers in general.Are there concerns for a project merge? best regards Gea @napp-it.org Am 07.07.2017 um 17:14 schrieb Dan McDonald: >> On Jul 7, 2017, at 11:01 AM, Michael Rasmussen wrote: >> >>> Maybe a switch to the OI installer is desirable as it offers a network setting option on initial setup. >>> The OmniOS installer is annoying regarding this > I switched the OmniOS installer AWAY from Caiman because I wanted to disentangle from Python. > > During the r151024 timeframe, one of the things on my plate was going to be a "install postprocessing" menu option on the Kayak menu. The idea would be if you wanted to get things set prior to your next boot, you'd go into that. It seemed appropriate for an interactive installer, while still keeping the spirit of REALLY FAST, DAMMIT that Kayak embodied. > > My suggestion, and you can dismiss it of course, it to build the postprocessing menu option. It'd bring up a new screen, full of choices like "configure networking", "Set root password", "Add users", etc. etc. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- From danmcd at kebe.com Fri Jul 7 18:02:28 2017 From: danmcd at kebe.com (Dan McDonald) Date: Fri, 7 Jul 2017 14:02:28 -0400 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <347d2394-f535-46f4-c42a-0647cc64303b@hfg-gmuend.de> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> <347d2394-f535-46f4-c42a-0647cc64303b@hfg-gmuend.de> Message-ID: <7635082A-0EC2-4C76-B692-1E930F13A484@kebe.com> > On Jul 7, 2017, at 11:42 AM, Guenther Alka wrote: > > hello Dan > > Thanks for jumping in. > You are the person with the very best insights in OmniOSand Illumos > and propably OI. Can you please comment about the options to cooperate with OI. > > Is this doable and wishable from your point of viewand how or do you have > an alternative idea for a positive future of OmniOS ce or free Illumos > based general use servers in general.Are there concerns for a project merge? I had a unicast chat session with someone about this recently. it's *POSSIBLE*, but remember the half the reason OmniOS happened in the first place was because OI focussed way too much on the desktop and all that accompanies it. (The other half, not keeping up with upstream, was fixed by Hipster.) I don't have the cycles to spell out how an OI/OmniOS merge MIGHT happen. There are three big technical problems that come to mind: 1.) Package naming: There are some subtle differences in IPS package names outside of illumos between the two. 2.) Perl & Python: OmniOS picked dual-mode perl and dual-mode Python (64 and 32 bit). Not sure what OI does. 3.) Installer: I chose to abandon Caiman in no small part because it was far more bloated than it needed to be for OmniOS. I wish I'd done Kayak for ISO sooner (or Theo or Eric did). I believe there is a decent post-processing step that can be done for Kayak Interactive that can provide the functionality of the old Caiman or OI/slim_install. Beyond that, there's the headaches of community coordination, etc. All of this I don't have cycles for, I can say for sure. Sorry, Dan From mir at miras.org Fri Jul 7 18:52:16 2017 From: mir at miras.org (Michael Rasmussen) Date: Fri, 7 Jul 2017 20:52:16 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> Message-ID: <20170707205216.2338d6d9@sleipner.datanom.net> On Fri, 7 Jul 2017 11:14:25 -0400 Dan McDonald wrote: > During the r151024 timeframe, one of the things on my plate was going to be a "install postprocessing" menu option on the Kayak menu. The idea would be if you wanted to get things set prior to your next boot, you'd go into that. It seemed appropriate for an interactive installer, while still keeping the spirit of REALLY FAST, DAMMIT that Kayak embodied. > > My suggestion, and you can dismiss it of course, it to build the postprocessing menu option. It'd bring up a new screen, full of choices like "configure networking", "Set root password", "Add users", etc. etc. > This is exactly the same ideas I have;-) Add to this that the user should be able to apply a preseed to the installer (Think of Debian) to have all that done automatically - imagine being able to remote install through PXE both Omnios and detailed configuration and installation of extra stuff. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: I have a rock garden. Last week three of them died. -- Richard Diran -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lkateley at kateley.com Fri Jul 7 18:58:00 2017 From: lkateley at kateley.com (Linda Kateley) Date: Fri, 7 Jul 2017 13:58:00 -0500 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <20170707205216.2338d6d9@sleipner.datanom.net> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> <20170707205216.2338d6d9@sleipner.datanom.net> Message-ID: <0c0d48c3-2305-16df-af13-40a74943bc8f@kateley.com> On 7/7/17 1:52 PM, Michael Rasmussen wrote: > On Fri, 7 Jul 2017 11:14:25 -0400 > Dan McDonald wrote: > >> During the r151024 timeframe, one of the things on my plate was going to be a "install postprocessing" menu option on the Kayak menu. The idea would be if you wanted to get things set prior to your next boot, you'd go into that. It seemed appropriate for an interactive installer, while still keeping the spirit of REALLY FAST, DAMMIT that Kayak embodied. >> >> My suggestion, and you can dismiss it of course, it to build the postprocessing menu option. It'd bring up a new screen, full of choices like "configure networking", "Set root password", "Add users", etc. etc. >> > This is exactly the same ideas I have;-) > > Add to this that the user should be able to apply a preseed to the > installer (Think of Debian) to have all that done automatically - > imagine being able to remote install through PXE both Omnios and > detailed configuration and installation of extra stuff. Yea, I thought that was what AI was? > > > _______________________________________________ > 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 Fri Jul 7 19:25:04 2017 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Fri, 7 Jul 2017 21:25:04 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <7635082A-0EC2-4C76-B692-1E930F13A484@kebe.com> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> <347d2394-f535-46f4-c42a-0647cc64303b@hfg-gmuend.de> <7635082A-0EC2-4C76-B692-1E930F13A484@kebe.com> Message-ID: <1853af02-6992-84ed-9940-62a5b6909fbc@hfg-gmuend.de> Thank you Dan Does this mean - the problems around a cooperatione with OmniOS were mainly in the past prior OI Hipster? - A a merge would introduce conflicts. This would require work to solve or both sides agree to use one or the other as base? Each choice would require work to maintain the current features. Installer seems irrelevant for me unless it offers what is needed. Your last comment is the core of the problem. How to coordinate communities! Gea @napp-it.org Am 07.07.2017 um 20:02 schrieb Dan McDonald: >> On Jul 7, 2017, at 11:42 AM, Guenther Alka wrote: >> >> hello Dan >> >> Thanks for jumping in. >> You are the person with the very best insights in OmniOSand Illumos >> and propably OI. Can you please comment about the options to cooperate with OI. >> >> Is this doable and wishable from your point of viewand how or do you have >> an alternative idea for a positive future of OmniOS ce or free Illumos >> based general use servers in general.Are there concerns for a project merge? > I had a unicast chat session with someone about this recently. > > it's *POSSIBLE*, but remember the half the reason OmniOS happened in the first place was because OI focussed way too much on the desktop and all that accompanies it. (The other half, not keeping up with upstream, was fixed by Hipster.) > > I don't have the cycles to spell out how an OI/OmniOS merge MIGHT happen. There are three big technical problems that come to mind: > > 1.) Package naming: There are some subtle differences in IPS package names outside of illumos between the two. > > 2.) Perl & Python: OmniOS picked dual-mode perl and dual-mode Python (64 and 32 bit). Not sure what OI does. > > 3.) Installer: I chose to abandon Caiman in no small part because it was far more bloated than it needed to be for OmniOS. I wish I'd done Kayak for ISO sooner (or Theo or Eric did). I believe there is a decent post-processing step that can be done for Kayak Interactive that can provide the functionality of the old Caiman or OI/slim_install. > > Beyond that, there's the headaches of community coordination, etc. > > All of this I don't have cycles for, I can say for sure. > > Sorry, > Dan > From eric.sproul at circonus.com Fri Jul 7 19:29:27 2017 From: eric.sproul at circonus.com (Eric Sproul) Date: Fri, 7 Jul 2017 15:29:27 -0400 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <20170707205216.2338d6d9@sleipner.datanom.net> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> <20170707205216.2338d6d9@sleipner.datanom.net> Message-ID: On Fri, Jul 7, 2017 at 2:52 PM, Michael Rasmussen wrote: > Add to this that the user should be able to apply a preseed to the > installer (Think of Debian) to have all that done automatically - > imagine being able to remote install through PXE both Omnios and > detailed configuration and installation of extra stuff. This is already possible via the `Postboot` functionality in Kayak, e.g.: Postboot '/sbin/ipadm create-addr -T dhcp e1000g0/v4' Just as with the old Solaris Jumpstart or AI, you can do this in configs that are specific to a single machine (by MAC address) or multiple machines (MAC prefix). You can do pretty much any commands here, and they get run by the once-at-first-boot service, svc:/system/initial-boot [1][2] One caveat is that this runs after the single-user milestone, so pretty early in the boot, before networking and all filesystems are available. If you need to install additional packages, for instance, you should look into some supplemental method of configuration management. Eric [1] SMF manifest: https://github.com/omniosorg/illumos-omnios/blob/master/usr/src/cmd/svc/milestone/initial-boot.xml [2] SMF method script: https://github.com/omniosorg/illumos-omnios/blob/master/usr/src/cmd/svc/milestone/initial-boot From jimklimov at cos.ru Fri Jul 7 19:28:46 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Fri, 07 Jul 2017 19:28:46 +0000 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <20170707170159.3b802ed1@sleipner.datanom.net> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> Message-ID: <6BC553A4-411A-4F72-A9B7-42F91D58ADA8@cos.ru> On July 7, 2017 5:01:59 PM GMT+02:00, Michael Rasmussen wrote: >On Fri, 7 Jul 2017 16:31:41 +0200 >Guenther Alka wrote: > >> >> Maybe a switch to the OI installer is desirable as it offers a >network setting option on initial setup. >> The OmniOS installer is annoying regarding this >> >> >I have raised an issue against the kayak installer regarding this and a >solution as well. See https://github.com/omniosorg/kayak/issues/1 Ironically, IMHO the choice of installers is the least of our problems here :) I mean, IMHO this only(?) plays a role during distro-construction, so it is a matter of one or another tweak in a recipe - of which we can have several for different media sets - with same repo (fruit of same shared effort) used for os/net (variants?) and for other application packages. Perhaps in the end we can just improve to common taste and keep one installer. But are not bound to do so. Jim -- Typos courtesy of K-9 Mail on my Redmi Android From alka at hfg-gmuend.de Fri Jul 7 19:51:04 2017 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Fri, 7 Jul 2017 21:51:04 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <0c0d48c3-2305-16df-af13-40a74943bc8f@kateley.com> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> <20170707205216.2338d6d9@sleipner.datanom.net> <0c0d48c3-2305-16df-af13-40a74943bc8f@kateley.com> Message-ID: <11eb7b1a-9b86-42c9-8a33-4f86d13e7b18@hfg-gmuend.de> Only a personal stance I am from Germany where a re-unification of Germany happened some year ago. When this happened there were a lot of different interest involved but luckily Cancellor Kohl simply declared this as a golden common future for East and West Germany and he succeeded. A lot went wrong afterwards and for some it was indeed not the golden future. But in general, Germany is seen now much better than in any other history. Mr Kohl dies recently with the honour of the first funeral as a European state ceremony. Illumos is not nearly as relevant like the future of nations involved in wars. But the mood of the persons and the needed decisions are similar. Lets repeat a similar success with OI + OmniOS despite the problems and differences. They are sisters and want basically the same. In the end both will be better off. Just do it. Gea @napp-it.org From mailinglists at qutic.com Sat Jul 8 15:34:15 2017 From: mailinglists at qutic.com (qutic development) Date: Sat, 8 Jul 2017 17:34:15 +0200 Subject: [OmniOS-discuss] Python conflicts in upgrade from 20 to 22 In-Reply-To: <3BE0DEED8863E5429BAE4CAEDF62456504048D050D1A@AIRA-SRV.aira.local> References: <3BE0DEED8863E5429BAE4CAEDF62456504048D050D1A@AIRA-SRV.aira.local> Message-ID: <5619B849-471F-4832-8676-5CBE18069C88@qutic.com> I do have the same issues. The upgrade to r151022 fails with the described python conflict. Any hint how to fix it is appreciated :) > Hello, > > I?m doing upgrade from version 20 to 22 LTS, and when I run pkg updade (after changing Publisher), I?m receiving many conflicts between Python 2.6 and 2.7 which prevents me in upgrade. > Can anyone please help me, how to correctly do upgrade with replacing Python 2.6 with Python 2.7? > > Thank you very much, > Filip > > ---- > pkg update: The requested change to the system attempts to install multiple actions > for link 'usr/bin/amd64/python-config' with conflicting attributes: > > 1 package delivers 'link path=usr/bin/amd64/python-config target=python2-config': > pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z > 1 package delivers 'link path=usr/bin/amd64/python-config target=python2.6-config': > pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z > > These packages may not be installed together. Any non-conflicting set may > be, or the packages must be corrected before they can be installed. > > The following packages all deliver file actions to usr/bin/smtpd.py: > > pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z > pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z > > ?and many more > --- > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From mtalbott at lji.org Sat Jul 8 21:52:49 2017 From: mtalbott at lji.org (Michael Talbott) Date: Sat, 8 Jul 2017 14:52:49 -0700 Subject: [OmniOS-discuss] Python conflicts in upgrade from 20 to 22 In-Reply-To: <5619B849-471F-4832-8676-5CBE18069C88@qutic.com> References: <3BE0DEED8863E5429BAE4CAEDF62456504048D050D1A@AIRA-SRV.aira.local> <5619B849-471F-4832-8676-5CBE18069C88@qutic.com> Message-ID: <237D8DC8-535F-45BC-8525-46E77085F677@lji.org> I ran into this as well. Turns out if you update the publisher to the new version and then do a: pkg update entire it'll fail with that error. But... if you just do a pkg update it'll succeed without error (and update all 379 packages instead of 377 in my case). I'm guessing there's some dependency incorrectly specified somewhere that is causing this specific issue. But I'm not a package maintainer so I can't say for certain. Hope this helps! Michael Sent from my iPhone > On Jul 8, 2017, at 8:34 AM, qutic development wrote: > > I do have the same issues. The upgrade to r151022 fails with the described python conflict. > > Any hint how to fix it is appreciated :) > >> Hello, >> >> I?m doing upgrade from version 20 to 22 LTS, and when I run pkg updade (after changing Publisher), I?m receiving many conflicts between Python 2.6 and 2.7 which prevents me in upgrade. >> Can anyone please help me, how to correctly do upgrade with replacing Python 2.6 with Python 2.7? >> >> Thank you very much, >> Filip >> >> ---- >> pkg update: The requested change to the system attempts to install multiple actions >> for link 'usr/bin/amd64/python-config' with conflicting attributes: >> >> 1 package delivers 'link path=usr/bin/amd64/python-config target=python2-config': >> pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z >> 1 package delivers 'link path=usr/bin/amd64/python-config target=python2.6-config': >> pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z >> >> These packages may not be installed together. Any non-conflicting set may >> be, or the packages must be corrected before they can be installed. >> >> The following packages all deliver file actions to usr/bin/smtpd.py: >> >> pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z >> pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z >> >> ?and many more >> --- >> _______________________________________________ >> 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 groups at tierarzt-mueller.de Mon Jul 10 08:37:29 2017 From: groups at tierarzt-mueller.de (Alexander Lesle) Date: Mon, 10 Jul 2017 10:37:29 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <20170707205216.2338d6d9@sleipner.datanom.net> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> <20170707205216.2338d6d9@sleipner.datanom.net> Message-ID: <1075554588.20170710103729@tierarzt-mueller.de> Hello @all, Is there a option to add the rpool_Customize https://omnios.omniti.com/wiki.php/ISOrpoolCustomize in the installer too? On Juli, 07 2017, 20:52 wrote in [1]: > On Fri, 7 Jul 2017 11:14:25 -0400 > Dan McDonald wrote: >> During the r151024 timeframe, one of the things on my plate was going to be a "install postprocessing" menu option on the Kayak menu. The idea would be if you wanted to get things set prior to your next boot, you'd go into that. It seemed appropriate for an interactive installer, while still keeping the spirit of REALLY FAST, DAMMIT that Kayak embodied. >> >> My suggestion, and you can dismiss it of course, it to build the postprocessing menu option. It'd bring up a new screen, full of choices like "configure networking", "Set root password", "Add users", etc. etc. >> > This is exactly the same ideas I have;-) > Add to this that the user should be able to apply a preseed to the > installer (Think of Debian) to have all that done automatically - > imagine being able to remote install through PXE both Omnios and > detailed configuration and installation of extra stuff. -- Best Regards Alexander Juli, 10 2017 ........ [1] mid:20170707205216.2338d6d9 at sleipner.datanom.net ........ From davide.poletto at gmail.com Mon Jul 10 08:54:40 2017 From: davide.poletto at gmail.com (Davide Poletto) Date: Mon, 10 Jul 2017 10:54:40 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: <1075554588.20170710103729@tierarzt-mueller.de> References: <897363981.716794.1499265047416.JavaMail.zimbra@oetiker.ch> <6B9998B7-AE5A-460B-9B08-7F5A1AAA0298@oetiker.ch> <20170707170159.3b802ed1@sleipner.datanom.net> <2CE9AE74-5DEA-4561-9505-9362D6A0921F@kebe.com> <20170707205216.2338d6d9@sleipner.datanom.net> <1075554588.20170710103729@tierarzt-mueller.de> Message-ID: If I recall correctly, I proposed to include that new feature in Caiman on the "Extending the installer" thread which was started on the list at end of February 2016. See here: http://lists.omniti.com/pipermail/omnios-discuss/2016-February/006446.html and my 2 cents about that at that time: http://lists.omniti.com/pipermail/omnios-discuss/2016-February/006455.html Best regards, Davide. On Mon, Jul 10, 2017 at 10:37 AM, Alexander Lesle < groups at tierarzt-mueller.de> wrote: > Hello @all, > > Is there a option to add the rpool_Customize > https://omnios.omniti.com/wiki.php/ISOrpoolCustomize > in the installer too? > > On Juli, 07 2017, 20:52 wrote in [1]: > > > On Fri, 7 Jul 2017 11:14:25 -0400 > > Dan McDonald wrote: > > >> During the r151024 timeframe, one of the things on my plate was going > to be a "install postprocessing" menu option on the Kayak menu. The idea > would be if you wanted to get things set prior to your next boot, you'd go > into that. It seemed appropriate for an interactive installer, while still > keeping the spirit of REALLY FAST, DAMMIT that Kayak embodied. > >> > >> My suggestion, and you can dismiss it of course, it to build the > postprocessing menu option. It'd bring up a new screen, full of choices > like "configure networking", "Set root password", "Add users", etc. etc. > >> > > > This is exactly the same ideas I have;-) > > > Add to this that the user should be able to apply a preseed to the > > installer (Think of Debian) to have all that done automatically - > > imagine being able to remote install through PXE both Omnios and > > detailed configuration and installation of extra stuff. > > > -- > Best Regards > Alexander > Juli, 10 2017 > ........ > [1] mid:20170707205216.2338d6d9 at sleipner.datanom.net > ........ > > _______________________________________________ > 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 kebe.com Tue Jul 11 13:06:56 2017 From: danmcd at kebe.com (Dan McDonald) Date: Tue, 11 Jul 2017 09:06:56 -0400 Subject: [OmniOS-discuss] BE CAREFUL with version-bump upgrades Message-ID: I will later today forward a list from my notes (once I get settled in and can punchin to home) of packages that I effectively froze because for some reason or another, they couldn't be upgraded. There's a rash of version-bump upgrades happening on the OmniOSce omnios-build repo, and some of them can easily just happen, but not all of them. FYI, Dan From omnios at citrus-it.net Tue Jul 11 14:26:30 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Tue, 11 Jul 2017 14:26:30 +0000 (UTC) Subject: [OmniOS-discuss] BE CAREFUL with version-bump upgrades In-Reply-To: References: Message-ID: On Tue, 11 Jul 2017, Dan McDonald wrote: ; I will later today forward a list from my notes (once I get settled in and ; can punchin to home) of packages that I effectively froze because for some ; reason or another, they couldn't be upgraded. There's a rash of version-bump ; upgrades happening on the OmniOSce omnios-build repo, and some of them can ; easily just happen, but not all of them. Thanks Dan, that would be much appreciated. To be clear, there's a slew of /Issues/ being created for packages which are out of date so that we can consider each one in turn and track the decision on each with an audit trail for the future. The fact that the Issue has been raised does not necessarily mean that the upgrade will happen. Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From robert at omniti.com Tue Jul 11 21:26:43 2017 From: robert at omniti.com (Robert Treat) Date: Tue, 11 Jul 2017 17:26:43 -0400 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: Message-ID: On Wed, Jul 5, 2017 at 10:05 AM, Guenther Alka wrote: > about OmniOS and the silence for weeks > > For my own future, I have already decided to switch back to OpenIndiana, the > community based sister project of OmniOS. But like many users, I have yet > OmniOS installations running perfectly. For them, it is essential to ask > about the future for the next months or year and needed next steps (can wait > some time or switch as soon as possible). > > > @OmniTi > The end of OmniOS at OmniTi seems final. > People see what they want to see. We still have a lot of OmniOS running at OmniTI, that is not expected to change anytime soon. > - How long will the website and the repo remain online? > Indefinitely. The majority of repos on github are publicly available, and probably won't ever be taken down. At some point we will need to reconfigure our internal processes to move towards a community repo rather than the one current housed under omniti-labs (Sadly, we never were able to secure OmniOS as a project from github, even with trademark rights, but ce la vie) but for now we are posting updates there when we can. As for the wiki, what we would like to see is the wiki recreated in a github project; right now it runs on a set of wiki software that is essentially closed source and we cannot open it, so a scrape/rebuild of the existing wiki seems to be the best option. I think the software at https://github.com/HeinrichHartmann/trac2md can go towards making that happen, but haven't seen anyone take that to completion. > - Is there an option to fix serious bugs or problems in OmniOS @OmniTi for > a limited time like 1 year or at least end of the year? > We will fix issues for ourselves and our customers as long as needed. We're happy to look at pull requests as well, but eventually that effort should move toward a community managed repo. > - Are you willing to transfer the website/name either to a new OmniOS > community project (I cannot see this as an option regarding the silence > about) or to the OpenIndiana community to use it as a name for a possible > stable like OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable > subset? (if OI is willing to go that route but the request or offer must > come from OmniTi or OmniOS people). > > OmniOS has a very strong reputation regarding production quality and > stability, so such a step would help both if OpenIndiana and OmniOS would > cooperate in a common project. Seems a pity if the name would die or remain > as a name for a failed project. We have stated this publicly before, but happy to say it again. We are willing to transfer "everything" (omnios.org domain, trademark rights, etc...) once a suitable group for stewardship emerges. My personal feeling is that people have gotten caught up in the drama of this far more than focusing on the work needed to move things forward. Right now the primary focus of those who want to see OmniOS move forward is setting up a new development process and identifying how that will work and who the people with appropriate commit bits will be. That should be coupled with a conversion of the wiki so that we have a way to push forward changes / releases. This can all be accomplished using github as the community provider for resources/hosting as a first step. After that individual pieces like a new domain, new websites, moving mailing lists, twitter accounts and such, can be taken on as individual projects. The big upside here is that almost all of this process can be (and probably should be) lifted from the existing OmniOS project, with regard to scope, direction, versioning, etc... In the meantime, talk of project merges and such is mostly a distraction IMHO. > > > @OmniOS developers (current or former - you have done a very good job!) > > - Is there an option to fix serious bugs or problems in OmniOS for a limited > time like 1 year or at least end of the year? This would help until a > sucessor (less likely OmniOS 151024, maybe next OpenIndiana snap with a > stable subset) is available. LX would then remain an OmniOS option in the > meantime (I would not dare to ask about an upstream). > Personally, I think the successor is going to151024 built out of the CE repo. A good test would be to see if that can be done in September, address just the goal of building a new release from community driven inputs, and solving the few tricky issues that come up with that (package signing comes to mind). Robert Treat https://omniti.com From svavar at pipar-tbwa.is Wed Jul 12 09:56:21 2017 From: svavar at pipar-tbwa.is (=?utf-8?Q?Svavar_=C3=96rn_Eysteinsson?=) Date: Wed, 12 Jul 2017 09:56:21 +0000 Subject: [OmniOS-discuss] Connect single USB disk to OmniOS ? Filesystem options? Message-ID: <7791F5C4-3038-49C7-BC52-FC379BE1B878@pipar-tbwa.is> Hello. I need to connect a single USB disk to my HP Microserver NL54 running OmniOS. Going to utilize it as a backup disk for some resources on my home LAN. The Microserver does have many USB ports that would be fine to utilize, as I have filled the 3.5" slots in the server in RAIDZ modes. The thing is, what options do I have as formating the disk? Is it only the ancient UFS and the FAT32 which is not going to do it's job because of file size limit ? And correct me if I'm wrong, ZFS on a single disk is not a nice job. btw, I do have 16GB ECC memory on the HP Microserver. As OpenIndiana distro has the NTFS fuse modules available, but there isn't any available for OmniOS. Any reason why? So my options are what, UFS and FAT32 ? Thank you kindly all. Best regards, Svavar Orn Reykjavik - Iceland From peter.tribble at gmail.com Wed Jul 12 10:10:38 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Wed, 12 Jul 2017 11:10:38 +0100 Subject: [OmniOS-discuss] Connect single USB disk to OmniOS ? Filesystem options? In-Reply-To: <7791F5C4-3038-49C7-BC52-FC379BE1B878@pipar-tbwa.is> References: <7791F5C4-3038-49C7-BC52-FC379BE1B878@pipar-tbwa.is> Message-ID: On Wed, Jul 12, 2017 at 10:56 AM, Svavar ?rn Eysteinsson < svavar at pipar-tbwa.is> wrote: > > Hello. > > I need to connect a single USB disk to my HP Microserver NL54 running > OmniOS. > Going to utilize it as a backup disk for some resources on my home LAN. > The Microserver does have many USB ports that would be fine to utilize, as > I have filled the 3.5" slots in the server > in RAIDZ modes. > > The thing is, what options do I have as formating the disk? Is it only the > ancient UFS and > the FAT32 which is not going to do it's job because of file size limit ? > > And correct me if I'm wrong, ZFS on a single disk is not a nice job. > Why not? ZFS is better than UFS or FAT. It'll tell you when your data is corrupted, which the others won't. If you want extra protection and have enough space then set copies=2 (lose the space, but you get self-healing back). Do set LZ4 compression, there's no reason not to these days. Just because you can't take advantage of all of the ZFS benefits doesn't immediately make it unsuitable, when the alternatives don't even have those features at all. > btw, I do have 16GB ECC memory on the HP Microserver. > > As OpenIndiana distro has the NTFS fuse modules available, but there isn't > any available > for OmniOS. Any reason why? > > So my options are what, UFS and FAT32 ? > ZFS. Although the one consideration for a backup drive is what you're going to connect it to. (Which again says ZFS, because you can then import the pool on another system pretty easily.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From svavar at pipar-tbwa.is Wed Jul 12 10:23:17 2017 From: svavar at pipar-tbwa.is (=?utf-8?Q?Svavar_=C3=96rn_Eysteinsson?=) Date: Wed, 12 Jul 2017 10:23:17 +0000 Subject: [OmniOS-discuss] Connect single USB disk to OmniOS ? Filesystem options? In-Reply-To: References: <7791F5C4-3038-49C7-BC52-FC379BE1B878@pipar-tbwa.is> Message-ID: Thanks for the reply. I just read on many different places on the net that single disk zpool was not a wise choice.. for an example : "single disk ZFS is so pointless it's actually worse than not using ZFS". Technically you can do deduplication and compression. But there is no protection from corruption since there is no redundancy. So any error can be detected, but cannot be corrected. This sounds like an acceptable compromise, but its actually not. The reason its not is that ZFS' metadata cannot be allowed to be corrupted. If it is it is likely the zpool will be impossible to mount (and will probably crash the system once the corruption is found). So a couple of bad sectors in the right place will mean that all data on the zpool will be lost. Not some, all. Also there's no ZFS recovery tools, so you cannot recover any data on the drives. You cannot use the standard recovery tools that are designed for NTFS, FAT32, etc either. They don't work correctly. So what does all of this mean? It means that you run the risk of everything being just fine, and then suddenly (and without warning) all of the data is irretrievably lost. This is obviously much worse than using something like NTFS which, when faced with corruption, will simply delete the offending entries (so some data will be lost, but not necessarily everything). You can also do some amount of recovery with things like chkdsk (no equivalent exists in the ZFS world). You can also use some recovery tools that exist if things get really bad (no equivalent exists in the ZFS world). So can you do what you want? Yep. But doing it is worse than simply using NTFS or whatever "legacy" file system you choose. I could easily argue that if your data is that unimportant you should simply delete it. Just wanted to double check the people opinions on this matter. > On 12 Jul 2017, at 10:10, Peter Tribble wrote: > > > > On Wed, Jul 12, 2017 at 10:56 AM, Svavar ?rn Eysteinsson > wrote: > > Hello. > > I need to connect a single USB disk to my HP Microserver NL54 running OmniOS. > Going to utilize it as a backup disk for some resources on my home LAN. > The Microserver does have many USB ports that would be fine to utilize, as I have filled the 3.5" slots in the server > in RAIDZ modes. > > The thing is, what options do I have as formating the disk? Is it only the ancient UFS and > the FAT32 which is not going to do it's job because of file size limit ? > > And correct me if I'm wrong, ZFS on a single disk is not a nice job. > > Why not? > > ZFS is better than UFS or FAT. It'll tell you when your data is corrupted, > which the others won't. If you want extra protection and have enough > space then set copies=2 (lose the space, but you get self-healing back). > Do set LZ4 compression, there's no reason not to these days. > > Just because you can't take advantage of all of the ZFS benefits doesn't > immediately make it unsuitable, when the alternatives don't even have > those features at all. > > btw, I do have 16GB ECC memory on the HP Microserver. > > As OpenIndiana distro has the NTFS fuse modules available, but there isn't any available > for OmniOS. Any reason why? > > So my options are what, UFS and FAT32 ? > > ZFS. Although the one consideration for a backup drive is what you're > going to connect it to. (Which again says ZFS, because you can then > import the pool on another system pretty easily.) > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From illumos at cucumber.demon.co.uk Wed Jul 12 10:29:09 2017 From: illumos at cucumber.demon.co.uk (Andrew Gabriel) Date: Wed, 12 Jul 2017 11:29:09 +0100 Subject: [OmniOS-discuss] Connect single USB disk to OmniOS ? Filesystem options? In-Reply-To: <7791F5C4-3038-49C7-BC52-FC379BE1B878@pipar-tbwa.is> References: <7791F5C4-3038-49C7-BC52-FC379BE1B878@pipar-tbwa.is> Message-ID: <28acbc11-0cff-91d1-b67c-b7bccea1dcd7@cucumber.demon.co.uk> On 12/07/2017 10:56, Svavar ?rn Eysteinsson wrote: > Hello. > > I need to connect a single USB disk to my HP Microserver NL54 running OmniOS. > Going to utilize it as a backup disk for some resources on my home LAN. > The Microserver does have many USB ports that would be fine to utilize, as I have filled the 3.5" slots in the server > in RAIDZ modes. > > The thing is, what options do I have as formating the disk? Is it only the ancient UFS and > the FAT32 which is not going to do it's job because of file size limit ? > > And correct me if I'm wrong, ZFS on a single disk is not a nice job. ZFS on a single disk is just fine. Its options for recovery from corruptions are limited compared with redundant RAID setups, but still much better than any of the other filesystems you mention on a single disk (metadata is all two or more copies), and you have the option to scrub and find all corruptions, which none of the others have. I actually run the next generation of microserver with rpool on a 64GB USB thumb drive (although I do run it with copies=2, and that's Solaris 11.3 rather than OmniOS, but I don't think that will make any difference in this case). > btw, I do have 16GB ECC memory on the HP Microserver. > > As OpenIndiana distro has the NTFS fuse modules available, but there isn't any available > for OmniOS. Any reason why? > > So my options are what, UFS and FAT32 ? > > > Thank you kindly all. > Best regards, > > Svavar Orn > Reykjavik - Iceland From tobi at oetiker.ch Wed Jul 12 15:32:24 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 12 Jul 2017 17:32:24 +0200 (CEST) Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h Message-ID: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> # OmniOS Community Edition On April 21st 2017, OmniTI announced that they would suspend active development of OmniOS and support contracts would not be renewed. While this announcement left many users stunned, others focused more on the fact that OmniTI in their announcement also expressed the hope that "the community" would take up further development of the OS. 14 weeks later, OmniOS Community Edition is a reality. Andy Fiddaman (www.citrus-it.net), Tobias Oetiker (www.oetiker.ch) and Dominik Hassler have spent some quality time setting up the systems and procedures allowing us to take over maintenance and development of OmniOS. In this endeavour we were supported by many. Special thanks to Stefan Husch (www.qutic.com), Peter Tribble (www.petertribble.co.uk), Dan McDonald and Theo Schlossnagle (www.circonus.com). We have forked the OmniOS repos and pulled in bugfixes and security fixes that have been published since the release of OmniOS r151022. After setting up our own package repository and updating the build infrastructure, we are finally ready to go public. We are following the established OmniOS release naming scheme by releasing ## OmniOSce r151022h, 12th July 2017 The new release contains the following fixes: - expat updated to version 2.2.1 (fixes CVE-2017-9233) - openssl updated to version 1.0.2l - curl updated to version 7.54.1 - bind updated to version 9.10.5-P3 - p7zip updated to fix CVE-2016-9296 - web/ca-bundle updated to include OmniOSce Certificate Authority certificate `uname -a` shows omnios-r151022-f9693432c2 (no change in this release) Our work does not stop here though. First we are committed to quickly releasing updates for r151022 as the need arises. We are also working towards releasing r151024 on schedule. To that end, we have already updated the bloody environment with all the latest goodies from upstream illumos and joyent-lx repositories. OmniOS community edition hosts its sources on https://github.com/omniosorg/ and if you want to get in touch, you can find us on https://gitter.im/omniosorg/Lobby ## Release Schedule The intention is for new stable releases to continue to come out every 26 weeks. Interim, "weekly" updates to stable follow a fixed schedule denoted by letters, one per week. Weekly releases are made as needed, so there may not be a release each week. The first release of a new stable version is synonymous with weekly release "a", though the letter is not used. During the intervals between stable releases, Bloody moves forward rapidly, picking up changes from upstream illumos-gate and illumos-joyent as well as updating various userland packages. In general, upstream merges will be performed on a Thursday/Friday each week and weekly releases will be published on a Monday. Bloody releases will be published on an ad-hoc basis but may be as frequent as every week. Security fixes are excluded from the schedule and handled with priority as they occur. ## How to Upgrade All OmniOS packages are signed and the pkg installer is configured to only allow trusted sources for the core packages. In order to upgrade to the new OmniOS community edition, you have to let your box know that the updates will be coming from a new trusted source. This means you will have to import our CA certificate into your system. 1. Get a copy of the new certificate ``` # /usr/bin/wget -P /etc/ssl/pkg \ https://downloads.omniosce.org/ssl/omniosce-ca.cert.pem ``` 2. Check the certificate fingerprint ``` # /usr/bin/openssl x509 -fingerprint \ -in /etc/ssl/pkg/omniosce-ca.cert.pem -noout ``` `8D:CD:F9:D0:76:CD:AF:C1:62:AF:89:51:AF:8A:0E:35:24:4C:66:6D` 3. Change the publisher to our new repo ``` # /usr/bin/pkg set-publisher -P \ -G https://pkg.omniti.com/omnios/r151022/ \ -g https://pkg.omniosce.org/r151022/core/ omnios ``` 4. For each native zone (if you have any), run ``` # /usr/bin/pkg -R set-publisher -P \ -G https://pkg.omniti.com/omnios/r151022/ \ -g https://pkg.omniosce.org/r151022/core/ omnios ``` (get a list of all your zones by running `zoneadm list -cv` for the ``, add `/root` to the PATH given in the list.) 5. Install the new ca-bundle containing our new CA ``` # /usr/bin/pkg update -rv web/ca-bundle ``` 6. Remove the CA file imported by hand ``` # rm /etc/ssl/pkg/omniosce-ca.cert.pem ``` 7. Finally update as usual ``` # /usr/bin/pkg update -rv ``` ## About OmniOS Community Edition Association OmniOS Community Edition Association (OmniOSce) is a Swiss association, dedicated to the continued support and release of OmniOS for the benefit of all parties involved. The board of OmniOSce controls access to the OmniOS CA. Current board members are: Tobias Oetiker (President), Andy Fiddaman (Development), Dominik Hassler (Treasurer). ## About Citrus-IT Citrus IT is a UK company that provides a managed email service platform to companies around the world. For many years they ran their systems on Solaris with SPARC hardware but transitioned to OmniOS in 2012. www.citrus-it.net ## About OETIKER+PARTNER AG OETIKER+PARTNER is a Swiss system management and software development company. Employees from O+P are involved in many Open Source Software projects. O+P runs most of their server hardware on OmniOS. www.oetiker.ch Press inquiries to info at omniosce.org Published July 12, 2017 OmniOSce Aarweg 17 4600 Olten Switzerland http://www.omniosce.org -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From sjorge+ml at blackdot.be Wed Jul 12 16:14:38 2017 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Wed, 12 Jul 2017 18:14:38 +0200 Subject: [OmniOS-discuss] [smartos-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: <2b2bfe5faa2be5a118794ad722f03af9@blackdot.be> Congrats guys! May many releases follow! On 2017-07-12 17:32, Tobias Oetiker wrote: > # OmniOS Community Edition > > On April 21st 2017, OmniTI announced that they would suspend active > development of OmniOS and support contracts would not be renewed. > > While this announcement left many users stunned, others focused more > on the fact that OmniTI in their announcement also expressed the hope > that "the community" would take up further development of the OS. 14 > weeks later, OmniOS Community Edition is a reality. > > Andy Fiddaman (www.citrus-it.net), Tobias Oetiker (www.oetiker.ch) and > Dominik Hassler have spent some quality time setting up the systems > and procedures allowing us to take over maintenance and development of > OmniOS. In this endeavour we were supported by many. Special thanks to > Stefan Husch (www.qutic.com), Peter Tribble (www.petertribble.co.uk), > Dan McDonald and Theo Schlossnagle (www.circonus.com). > > We have forked the OmniOS repos and pulled in bugfixes and security > fixes that have been published since the release of OmniOS r151022. > After setting up our own package repository and updating the build > infrastructure, we are finally ready to go public. We are following > the established OmniOS release naming scheme by releasing > > > ## OmniOSce r151022h, 12th July 2017 > > The new release contains the following fixes: > > - expat updated to version 2.2.1 (fixes CVE-2017-9233) > - openssl updated to version 1.0.2l > - curl updated to version 7.54.1 > - bind updated to version 9.10.5-P3 > - p7zip updated to fix CVE-2016-9296 > - web/ca-bundle updated to include OmniOSce Certificate Authority > certificate > > `uname -a` shows omnios-r151022-f9693432c2 (no change in this release) > > Our work does not stop here though. First we are committed to quickly > releasing updates for r151022 as the need arises. We are also working > towards releasing r151024 on schedule. To that end, we have already > updated the bloody environment with all the latest goodies from > upstream illumos and joyent-lx repositories. > > OmniOS community edition hosts its sources on > https://github.com/omniosorg/ and if you want to get in touch, you can > find us on https://gitter.im/omniosorg/Lobby > > > ## Release Schedule > > The intention is for new stable releases to continue to come out every > 26 weeks. Interim, "weekly" updates to stable follow a fixed schedule > denoted by letters, one per week. Weekly releases are made as needed, > so there may not be a release each week. The first release of a new > stable version is synonymous with weekly release "a", though the > letter is not used. > > During the intervals between stable releases, Bloody moves forward > rapidly, picking up changes from upstream illumos-gate and > illumos-joyent as well as updating various userland packages. In > general, upstream merges will be performed on a Thursday/Friday each > week and weekly releases will be published on a Monday. > > Bloody releases will be published on an ad-hoc basis but may be as > frequent as every week. > > Security fixes are excluded from the schedule and handled with > priority as they occur. > > > ## How to Upgrade > > All OmniOS packages are signed and the pkg installer is configured to > only allow trusted sources for the core packages. In order to upgrade > to the new OmniOS community edition, you have to let your box know > that the updates will be coming from a new trusted source. This means > you will have to import our CA certificate into your system. > > 1. Get a copy of the new certificate > > ``` > # /usr/bin/wget -P /etc/ssl/pkg \ > https://downloads.omniosce.org/ssl/omniosce-ca.cert.pem > ``` > > 2. Check the certificate fingerprint > > ``` > # /usr/bin/openssl x509 -fingerprint \ > -in /etc/ssl/pkg/omniosce-ca.cert.pem -noout > ``` > > `8D:CD:F9:D0:76:CD:AF:C1:62:AF:89:51:AF:8A:0E:35:24:4C:66:6D` > > > 3. Change the publisher to our new repo > > ``` > # /usr/bin/pkg set-publisher -P \ > -G https://pkg.omniti.com/omnios/r151022/ \ > -g https://pkg.omniosce.org/r151022/core/ omnios > ``` > > 4. For each native zone (if you have any), run > > ``` > # /usr/bin/pkg -R set-publisher -P \ > -G https://pkg.omniti.com/omnios/r151022/ \ > -g https://pkg.omniosce.org/r151022/core/ omnios > ``` > > (get a list of all your zones by running `zoneadm list -cv` for the > ``, add `/root` to the PATH given in the list.) > > > 5. Install the new ca-bundle containing our new CA > > ``` > # /usr/bin/pkg update -rv web/ca-bundle > ``` > > 6. Remove the CA file imported by hand > > ``` > # rm /etc/ssl/pkg/omniosce-ca.cert.pem > ``` > > 7. Finally update as usual > > ``` > # /usr/bin/pkg update -rv > ``` > > > ## About OmniOS Community Edition Association > > OmniOS Community Edition Association (OmniOSce) is a Swiss > association, dedicated to the continued support and release of OmniOS > for the benefit of all parties involved. The board of OmniOSce > controls access to the OmniOS CA. Current board members are: Tobias > Oetiker (President), Andy Fiddaman (Development), Dominik Hassler > (Treasurer). > > > ## About Citrus-IT > > Citrus IT is a UK company that provides a managed email service > platform to companies around the world. For many years they ran their > systems on Solaris with SPARC hardware but transitioned to OmniOS in > 2012. www.citrus-it.net > > > ## About OETIKER+PARTNER AG > > OETIKER+PARTNER is a Swiss system management and software development > company. Employees from O+P are involved in many Open Source Software > projects. O+P runs most of their server hardware on OmniOS. > www.oetiker.ch > > > Press inquiries to info at omniosce.org > > Published July 12, 2017 > > OmniOSce > Aarweg 17 > 4600 Olten > Switzerland > > http://www.omniosce.org From mir at miras.org Wed Jul 12 16:24:36 2017 From: mir at miras.org (Michael Rasmussen) Date: Wed, 12 Jul 2017 18:24:36 +0200 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: <20170712182436.68669f77@sleipner.datanom.net> On Wed, 12 Jul 2017 17:32:24 +0200 (CEST) Tobias Oetiker wrote: > ``` > # /usr/bin/pkg update -rv > ``` > Maybe the update message should be changed? --------------------------------------------------------------------------- NOTE: Please review release notes posted at: http://omnios.omniti.com/ReleaseNotes --------------------------------------------------------------------------- -- 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: Alaska: A prelude to "No." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From bfriesen at simple.dallas.tx.us Wed Jul 12 18:51:09 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 12 Jul 2017 13:51:09 -0500 (CDT) Subject: [OmniOS-discuss] Connect single USB disk to OmniOS ? Filesystem options? In-Reply-To: References: <7791F5C4-3038-49C7-BC52-FC379BE1B878@pipar-tbwa.is> Message-ID: On Wed, 12 Jul 2017, Svavar ?rn Eysteinsson wrote: > But there is no protection from corruption since there is no > redundancy. So any error can be detected, but cannot be corrected. There is in fact redundancy for essential elements of zfs, but just not for user data by default. Additional redundancy for user data can be enabled. There is little reason to believe that zfs on one disk is less reliable than some other filesystem on one disk other than with the other filesystem you might not know that your files have become corrupt. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From jimklimov at cos.ru Wed Jul 12 20:06:19 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Wed, 12 Jul 2017 20:06:19 +0000 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: <5B5090FC-B382-4462-9EE5-A0D0BA41636C@cos.ru> On July 12, 2017 5:32:24 PM GMT+02:00, Tobias Oetiker wrote: ># OmniOS Community Edition > >On April 21st 2017, OmniTI announced that they would suspend active >development of OmniOS and support contracts would not be renewed. > >While this announcement left many users stunned, others focused more on >the fact that OmniTI in their announcement also expressed the hope that >"the community" would take up further development of the OS. 14 weeks >later, OmniOS Community Edition is a reality. > >Andy Fiddaman (www.citrus-it.net), Tobias Oetiker (www.oetiker.ch) and >Dominik Hassler have spent some quality time setting up the systems and >procedures allowing us to take over maintenance and development of >OmniOS. In this endeavour we were supported by many. Special thanks to >Stefan Husch (www.qutic.com), Peter Tribble (www.petertribble.co.uk), >Dan McDonald and Theo Schlossnagle (www.circonus.com). > >We have forked the OmniOS repos and pulled in bugfixes and security >fixes that have been published since the release of OmniOS r151022. >After setting up our own package repository and updating the build >infrastructure, we are finally ready to go public. We are following the >established OmniOS release naming scheme by releasing > > >## OmniOSce r151022h, 12th July 2017 > >The new release contains the following fixes: > >- expat updated to version 2.2.1 (fixes CVE-2017-9233) >- openssl updated to version 1.0.2l >- curl updated to version 7.54.1 >- bind updated to version 9.10.5-P3 >- p7zip updated to fix CVE-2016-9296 >- web/ca-bundle updated to include OmniOSce Certificate Authority >certificate > >`uname -a` shows omnios-r151022-f9693432c2 (no change in this release) > >Our work does not stop here though. First we are committed to quickly >releasing updates for r151022 as the need arises. We are also working >towards releasing r151024 on schedule. To that end, we have already >updated the bloody environment with all the latest goodies from >upstream illumos and joyent-lx repositories. > >OmniOS community edition hosts its sources on >https://github.com/omniosorg/ and if you want to get in touch, you can >find us on https://gitter.im/omniosorg/Lobby > > >## Release Schedule > >The intention is for new stable releases to continue to come out every >26 weeks. Interim, "weekly" updates to stable follow a fixed schedule >denoted by letters, one per week. Weekly releases are made as needed, >so there may not be a release each week. The first release of a new >stable version is synonymous with weekly release "a", though the letter >is not used. > >During the intervals between stable releases, Bloody moves forward >rapidly, picking up changes from upstream illumos-gate and >illumos-joyent as well as updating various userland packages. In >general, upstream merges will be performed on a Thursday/Friday each >week and weekly releases will be published on a Monday. > >Bloody releases will be published on an ad-hoc basis but may be as >frequent as every week. > >Security fixes are excluded from the schedule and handled with priority >as they occur. > > >## How to Upgrade > >All OmniOS packages are signed and the pkg installer is configured to >only allow trusted sources for the core packages. In order to upgrade >to the new OmniOS community edition, you have to let your box know that >the updates will be coming from a new trusted source. This means you >will have to import our CA certificate into your system. > >1. Get a copy of the new certificate > >``` ># /usr/bin/wget -P /etc/ssl/pkg \ > https://downloads.omniosce.org/ssl/omniosce-ca.cert.pem >``` > >2. Check the certificate fingerprint > >``` ># /usr/bin/openssl x509 -fingerprint \ > -in /etc/ssl/pkg/omniosce-ca.cert.pem -noout >``` > >`8D:CD:F9:D0:76:CD:AF:C1:62:AF:89:51:AF:8A:0E:35:24:4C:66:6D` > > >3. Change the publisher to our new repo > >``` ># /usr/bin/pkg set-publisher -P \ > -G https://pkg.omniti.com/omnios/r151022/ \ > -g https://pkg.omniosce.org/r151022/core/ omnios >``` > >4. For each native zone (if you have any), run > >``` ># /usr/bin/pkg -R set-publisher -P \ > -G https://pkg.omniti.com/omnios/r151022/ \ > -g https://pkg.omniosce.org/r151022/core/ omnios >``` > >(get a list of all your zones by running `zoneadm list -cv` for the >``, add `/root` to the PATH given in the list.) > > >5. Install the new ca-bundle containing our new CA > >``` ># /usr/bin/pkg update -rv web/ca-bundle >``` > >6. Remove the CA file imported by hand > >``` ># rm /etc/ssl/pkg/omniosce-ca.cert.pem >``` > >7. Finally update as usual > >``` ># /usr/bin/pkg update -rv >``` > > >## About OmniOS Community Edition Association > >OmniOS Community Edition Association (OmniOSce) is a Swiss association, >dedicated to the continued support and release of OmniOS for the >benefit of all parties involved. The board of OmniOSce controls access >to the OmniOS CA. Current board members are: Tobias Oetiker >(President), Andy Fiddaman (Development), Dominik Hassler (Treasurer). > > >## About Citrus-IT > >Citrus IT is a UK company that provides a managed email service >platform to companies around the world. For many years they ran their >systems on Solaris with SPARC hardware but transitioned to OmniOS in >2012. www.citrus-it.net > > >## About OETIKER+PARTNER AG > >OETIKER+PARTNER is a Swiss system management and software development >company. Employees from O+P are involved in many Open Source Software >projects. O+P runs most of their server hardware on OmniOS. >www.oetiker.ch > > >Press inquiries to info at omniosce.org > >Published July 12, 2017 > >OmniOSce >Aarweg 17 >4600 Olten >Switzerland > >http://www.omniosce.org Wholehearted congratulations on this achievement! Whichever way the development pans out respective to our recent discussions, this is definitely a strong and successful step to rebuild brand confidence and peace of mind for existing users! ;) Jim -- Typos courtesy of K-9 Mail on my Redmi Android From serge.fonville at gmail.com Wed Jul 12 21:05:37 2017 From: serge.fonville at gmail.com (Serge Fonville) Date: Wed, 12 Jul 2017 23:05:37 +0200 Subject: [OmniOS-discuss] Global zone has a newer version: pkg://omnios/package/pkg@0.5.11, 5.11-0.151022:20170510T220631Z Message-ID: Hi, While trying to update omnios to the new version, I receive the error I cannot upgrade since "Global zone has a newer version: pkg://omnios/package/pkg" How do I fix this,. so I can update omnios to the newest version? Thanks a lot in advance! Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From vab at bb-c.de Wed Jul 12 22:24:19 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Thu, 13 Jul 2017 00:24:19 +0200 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: <22886.41363.550765.642625@urukhai.local> Tobias Oetiker writes: > We have forked the OmniOS repos and pulled in bugfixes and security fixes > that have been published since the release of OmniOS r151022. After setting > up our own package repository and updating the build infrastructure, we are > finally ready to go public. We are following the established OmniOS release > naming scheme by releasing > > > ## OmniOSce r151022h, 12th July 2017 Very nice work!! Well done guys. 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 info at houseofancients.nl Wed Jul 12 22:26:37 2017 From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..) Date: Wed, 12 Jul 2017 22:26:37 +0000 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: <04B0A5C1206D824F8D310C5B3DB28CC92027672B@vEX01.mindstorm-internet.local> Congratulations guys ! -----Oorspronkelijk bericht----- Van: Tobias Oetiker [mailto:tobi at oetiker.ch] Verzonden: woensdag 12 juli 2017 17:32 Aan: omnios-discuss CC: SmartOs Discuss Onderwerp: [smartos-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h # OmniOS Community Edition On April 21st 2017, OmniTI announced that they would suspend active development of OmniOS and support contracts would not be renewed. While this announcement left many users stunned, others focused more on the fact that OmniTI in their announcement also expressed the hope that "the community" would take up further development of the OS. 14 weeks later, OmniOS Community Edition is a reality. Andy Fiddaman (www.citrus-it.net), Tobias Oetiker (www.oetiker.ch) and Dominik Hassler have spent some quality time setting up the systems and procedures allowing us to take over maintenance and development of OmniOS. In this endeavour we were supported by many. Special thanks to Stefan Husch (www.qutic.com), Peter Tribble (www.petertribble.co.uk), Dan McDonald and Theo Schlossnagle (www.circonus.com). We have forked the OmniOS repos and pulled in bugfixes and security fixes that have been published since the release of OmniOS r151022. After setting up our own package repository and updating the build infrastructure, we are finally ready to go public. We are following the established OmniOS release naming scheme by releasing ## OmniOSce r151022h, 12th July 2017 The new release contains the following fixes: - expat updated to version 2.2.1 (fixes CVE-2017-9233) - openssl updated to version 1.0.2l - curl updated to version 7.54.1 - bind updated to version 9.10.5-P3 - p7zip updated to fix CVE-2016-9296 - web/ca-bundle updated to include OmniOSce Certificate Authority certificate `uname -a` shows omnios-r151022-f9693432c2 (no change in this release) Our work does not stop here though. First we are committed to quickly releasing updates for r151022 as the need arises. We are also working towards releasing r151024 on schedule. To that end, we have already updated the bloody environment with all the latest goodies from upstream illumos and joyent-lx repositories. OmniOS community edition hosts its sources on https://github.com/omniosorg/ and if you want to get in touch, you can find us on https://gitter.im/omniosorg/Lobby ## Release Schedule The intention is for new stable releases to continue to come out every 26 weeks. Interim, "weekly" updates to stable follow a fixed schedule denoted by letters, one per week. Weekly releases are made as needed, so there may not be a release each week. The first release of a new stable version is synonymous with weekly release "a", though the letter is not used. During the intervals between stable releases, Bloody moves forward rapidly, picking up changes from upstream illumos-gate and illumos-joyent as well as updating various userland packages. In general, upstream merges will be performed on a Thursday/Friday each week and weekly releases will be published on a Monday. Bloody releases will be published on an ad-hoc basis but may be as frequent as every week. Security fixes are excluded from the schedule and handled with priority as they occur. ## How to Upgrade All OmniOS packages are signed and the pkg installer is configured to only allow trusted sources for the core packages. In order to upgrade to the new OmniOS community edition, you have to let your box know that the updates will be coming from a new trusted source. This means you will have to import our CA certificate into your system. 1. Get a copy of the new certificate ``` # /usr/bin/wget -P /etc/ssl/pkg \ https://downloads.omniosce.org/ssl/omniosce-ca.cert.pem ``` 2. Check the certificate fingerprint ``` # /usr/bin/openssl x509 -fingerprint \ -in /etc/ssl/pkg/omniosce-ca.cert.pem -noout ``` `8D:CD:F9:D0:76:CD:AF:C1:62:AF:89:51:AF:8A:0E:35:24:4C:66:6D` 3. Change the publisher to our new repo ``` # /usr/bin/pkg set-publisher -P \ -G https://pkg.omniti.com/omnios/r151022/ \ -g https://pkg.omniosce.org/r151022/core/ omnios ``` 4. For each native zone (if you have any), run ``` # /usr/bin/pkg -R set-publisher -P \ -G https://pkg.omniti.com/omnios/r151022/ \ -g https://pkg.omniosce.org/r151022/core/ omnios ``` (get a list of all your zones by running `zoneadm list -cv` for the ``, add `/root` to the PATH given in the list.) 5. Install the new ca-bundle containing our new CA ``` # /usr/bin/pkg update -rv web/ca-bundle ``` 6. Remove the CA file imported by hand ``` # rm /etc/ssl/pkg/omniosce-ca.cert.pem ``` 7. Finally update as usual ``` # /usr/bin/pkg update -rv ``` ## About OmniOS Community Edition Association OmniOS Community Edition Association (OmniOSce) is a Swiss association, dedicated to the continued support and release of OmniOS for the benefit of all parties involved. The board of OmniOSce controls access to the OmniOS CA. Current board members are: Tobias Oetiker (President), Andy Fiddaman (Development), Dominik Hassler (Treasurer). ## About Citrus-IT Citrus IT is a UK company that provides a managed email service platform to companies around the world. For many years they ran their systems on Solaris with SPARC hardware but transitioned to OmniOS in 2012. www.citrus-it.net ## About OETIKER+PARTNER AG OETIKER+PARTNER is a Swiss system management and software development company. Employees from O+P are involved in many Open Source Software projects. O+P runs most of their server hardware on OmniOS. www.oetiker.ch Press inquiries to info at omniosce.org Published July 12, 2017 OmniOSce Aarweg 17 4600 Olten Switzerland http://www.omniosce.org -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/23995794-b2f92329 Modify Your Subscription: https://www.listbox.com/member/?member_id=23995794&id_secret=23995794-d0ccab55 Powered by Listbox: http://www.listbox.com ...:: 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 henson at acm.org Wed Jul 12 22:29:55 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 12 Jul 2017 15:29:55 -0700 Subject: [OmniOS-discuss] [smartos-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: <011a01d2fb5e$639914c0$2acb3e40$@acm.org> > From: Tobias Oetiker [mailto:tobi at oetiker.ch] > Sent: Wednesday, July 12, 2017 8:32 AM > > ## OmniOSce r151022h, 12th July 2017 Much thanks and appreciation for your efforts, it is good to know that the legacy of omnios will carry on. From jesus at omniti.com Wed Jul 12 22:31:45 2017 From: jesus at omniti.com (Theo Schlossnagle) Date: Wed, 12 Jul 2017 18:31:45 -0400 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <22886.41363.550765.642625@urukhai.local> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> <22886.41363.550765.642625@urukhai.local> Message-ID: Nice! On Jul 12, 2017 6:28 PM, "Volker A. Brandt" wrote: > Tobias Oetiker writes: > > We have forked the OmniOS repos and pulled in bugfixes and security fixes > > that have been published since the release of OmniOS r151022. After > setting > > up our own package repository and updating the build infrastructure, we > are > > finally ready to go public. We are following the established OmniOS > release > > naming scheme by releasing > > > > > > ## OmniOSce r151022h, 12th July 2017 > > Very nice work!! Well done guys. > > > 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" > _______________________________________________ > 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 Thu Jul 13 06:23:51 2017 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Thu, 13 Jul 2017 08:23:51 +0200 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: <39dacc78-a1a8-ccfe-ac67-742d9106ce9a@hfg-gmuend.de> Thanks for your work! I nearly lost hope for a ce edition. Gea @napp-it.org From al.slater at scluk.com Thu Jul 13 06:47:36 2017 From: al.slater at scluk.com (Al Slater) Date: Thu, 13 Jul 2017 07:47:36 +0100 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: Congratulations and thank you for your efforts!! On 12/07/2017 16:32, Tobias Oetiker wrote: > # OmniOS Community Edition > > On April 21st 2017, OmniTI announced that they would suspend active development of OmniOS and support contracts would not be renewed. > > While this announcement left many users stunned, others focused more on the fact that OmniTI in their announcement also expressed the hope that "the community" would take up further development of the OS. 14 weeks later, OmniOS Community Edition is a reality. > > Andy Fiddaman (www.citrus-it.net), Tobias Oetiker (www.oetiker.ch) and Dominik Hassler have spent some quality time setting up the systems and procedures allowing us to take over maintenance and development of OmniOS. In this endeavour we were supported by many. Special thanks to Stefan Husch (www.qutic.com), Peter Tribble (www.petertribble.co.uk), Dan McDonald and Theo Schlossnagle (www.circonus.com). > > We have forked the OmniOS repos and pulled in bugfixes and security fixes that have been published since the release of OmniOS r151022. After setting up our own package repository and updating the build infrastructure, we are finally ready to go public. We are following the established OmniOS release naming scheme by releasing > > > ## OmniOSce r151022h, 12th July 2017 > > The new release contains the following fixes: > > - expat updated to version 2.2.1 (fixes CVE-2017-9233) > - openssl updated to version 1.0.2l > - curl updated to version 7.54.1 > - bind updated to version 9.10.5-P3 > - p7zip updated to fix CVE-2016-9296 > - web/ca-bundle updated to include OmniOSce Certificate Authority certificate > > `uname -a` shows omnios-r151022-f9693432c2 (no change in this release) > > Our work does not stop here though. First we are committed to quickly releasing updates for r151022 as the need arises. We are also working towards releasing r151024 on schedule. To that end, we have already updated the bloody environment with all the latest goodies from upstream illumos and joyent-lx repositories. > > OmniOS community edition hosts its sources on https://github.com/omniosorg/ and if you want to get in touch, you can find us on https://gitter.im/omniosorg/Lobby > > https://pkg.omniosce.org/r151022/core/ > ## Release Schedule > > The intention is for new stable releases to continue to come out every 26 weeks. Interim, "weekly" updates to stable follow a fixed schedule denoted by letters, one per week. Weekly releases are made as needed, so there may not be a release each week. The first release of a new stable version is synonymous with weekly release "a", though the letter is not used. > > During the intervals between stable releases, Bloody moves forward rapidly, picking up changes from upstream illumos-gate and illumos-joyent as well as updating various userland packages. In general, upstream merges will be performed on a Thursday/Friday each week and weekly releases will be published on a Monday. > > Bloody releases will be published on an ad-hoc basis but may be as frequent as every week. > > Security fixes are excluded from the schedule and handled with priority as they occur. > > > ## How to Upgrade > > All OmniOS packages are signed and the pkg installer is configured to only allow trusted sources for the core packages. In order to upgrade to the new OmniOS community edition, you have to let your box know that the updates will be coming from a new trusted source. This means you will have to import our CA certificate into your system. > > 1. Get a copy of the new certificate > > ``` > # /usr/bin/wget -P /etc/ssl/pkg \ > https://downloads.omniosce.org/ssl/omniosce-ca.cert.pem > ``` > https://pkg.omniosce.org/r151022/core/ > 2. Check the certificate fingerprint > > ``` > # /usr/bin/openssl x509 -fingerprint \ > -in /etc/ssl/pkg/omniosce-ca.cert.pem -noout > ``` > > `8D:CD:F9:D0:76:CD:AF:C1:62:AF:89:51:AF:8A:0E:35:24:4C:66:6D` > > > 3. Change the publisher to our new repo > > ``` > # /usr/bin/pkg set-publisher -P \ > -G https://pkg.omniti.com/omnios/r151022/ \ > -g https://pkg.omniosce.org/r151022/core/ omnios > ``` > > 4. For each native zone (if you have any), run > https://pkg.omniosce.org/r151022/core/ > ``` > # /usr/bin/pkg -R set-publisher -P \ > -G https://pkg.omniti.com/omnios/r151022/ \ > -g https://pkg.omniosce.org/r151022/core/ omnios > ``` > > (get a list of all your zones by running `zoneadm list -cv` for the ``, add `/root` to the PATH given in the list.) > > > 5. Install the new ca-bundle containing our new CA > > ``` > # /usr/bin/pkg update -rv web/ca-bundle > ``` > > 6. Remove the CA file imported by hand > > ``` > # rm /etc/ssl/pkg/omniosce-ca.cert.pem > ``` > > 7. Finally update as usual > > ```https://pkg.omniosce.org/r151022/core/ > # /usr/bin/pkg update -rv > ``` > > > ## About OmniOS Community Edition Association > > OmniOS Community Edition Association (OmniOSce) is a Swiss association, dedicated to the continued support and release of OmniOS for the benefit of all parties involved. The board of OmniOSce controls access to the OmniOS CA. Current board members are: Tobias Oetiker (President), Andy Fiddaman (Development), Dominik Hassler (Treasurer). > > > ## About Citrus-IT > > Citrus IT is a UK company that provides a managed email service platform to companies around the world. For many years they ran their systems on Solaris with SPARC hardware but transitioned to OmniOS in 2012. www.citrus-it.net > > > ## About OETIKER+PARTNER AG > > OETIKER+PARTNER is a Swiss system management and software development company. Employees from O+P are involved in many Open Source Software projects. O+P runs most of their server hardware on OmniOS. www.oetiker.ch > > > Press inquiries to info at omniosce.org > > Published July 12, 2017 > > OmniOSce > Aarweg 17 > 4600 Olten > Switzerland > > http://www.omniosce.org > > -- Al Slater Technical Director SCL Phone : +44 (0)1273 666607 Fax : +44 (0)1273 666601 email : al.slater at scluk.com Stanton Consultancy Ltd Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU Registered in England Company number: 1957652 VAT number: GB 760 2433 55 From svavar at pipar-tbwa.is Thu Jul 13 11:42:34 2017 From: svavar at pipar-tbwa.is (=?utf-8?Q?Svavar_=C3=96rn_Eysteinsson?=) Date: Thu, 13 Jul 2017 11:42:34 +0000 Subject: [OmniOS-discuss] Upgrade from r151020 to r151022 - python conflicts and fails. Message-ID: As anyone encounter a upgrade fail from 20 to 22 ? I'm unable and get conflicts regarding python. Current system is : OmniOS v11 r151020 OmniOS 5.11 omnios-r151020-4151d05 March 2017 Before I did as the upgrade instructions stated, : /usr/bin/pkg unset-publisher omnios /usr/bin/pkg set-publisher -P --set-property signature-policy=require-signatures -g https://pkg.omniti.com/omnios/r151022/ omnios And my current publishers are : PUBLISHER TYPE STATUS P LOCATION omnios origin online F https://pkg.omniti.com/omnios/r151022 root at blackbox:/# /usr/bin/pkg update --be-name=omnios-r151022 entire at 11,5.11-0.151022 Creating Plan (Checking for conflicting actions): / pkg update: The requested change to the system attempts to install multiple actions for link 'usr/bin/amd64/python-config' with conflicting attributes: 1 package delivers 'link path=usr/bin/amd64/python-config target=python2-config': pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z 1 package delivers 'link path=usr/bin/amd64/python-config target=python2.6-config': pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/smtpd.py: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/pydoc: pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The requested change to the system attempts to install multiple actions for link 'usr/bin/python' with conflicting attributes: 1 package delivers 'link path=usr/bin/python target=python2.6': pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z 1 package delivers 'link path=usr/bin/python target=python2.7': pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/amd64/2to3: pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/amd64/idle: pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/i386/idle: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/i386/pydoc: pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/python-config: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/idle: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/amd64/pydoc: pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/i386/2to3: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/i386/smtpd.py: pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/amd64/smtpd.py: pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages deliver conflicting action types to usr/share/man/man1/python.1: link: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z file: pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The requested change to the system attempts to install multiple actions for link 'usr/bin/i386/python-config' with conflicting attributes: 1 package delivers 'link path=usr/bin/i386/python-config target=python2-config': pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z 1 package delivers 'link path=usr/bin/i386/python-config target=python2.6-config': pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/2to3: pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. From omnios at citrus-it.net Thu Jul 13 11:48:53 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Thu, 13 Jul 2017 11:48:53 +0000 (UTC) Subject: [OmniOS-discuss] Upgrade from r151020 to r151022 - python conflicts and fails. In-Reply-To: References: Message-ID: On Thu, 13 Jul 2017, Svavar ?rn Eysteinsson wrote: ; As anyone encounter a upgrade fail from 20 to 22 ? ; I'm unable and get conflicts regarding python. ; ; Current system is : ; OmniOS v11 r151020 ; OmniOS 5.11 omnios-r151020-4151d05 March 2017 ; ; Before I did as the upgrade instructions stated, : ; ; ; /usr/bin/pkg unset-publisher omnios ; /usr/bin/pkg set-publisher -P --set-property signature-policy=require-signatures -g https://pkg.omniti.com/omnios/r151022/ omnios ; ; ; And my current publishers are : ; ; PUBLISHER TYPE STATUS P LOCATION ; omnios origin online F https://pkg.omniti.com/omnios/r151022 What are the versions of of your web/ca-bundle ad package/pkg packages? Does this system have any zones? If so, what brand? It is worth making sure that 'pkg' is up-to-date before attempting the upgrade: > pkg install pkg:/package/pkg and the release notes state that web/ca-bundle must be up-to-date. > https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From svavar at pipar-tbwa.is Thu Jul 13 11:52:30 2017 From: svavar at pipar-tbwa.is (=?utf-8?Q?Svavar_=C3=96rn_Eysteinsson?=) Date: Thu, 13 Jul 2017 11:52:30 +0000 Subject: [OmniOS-discuss] Upgrade from r151020 to r151022 - python conflicts and fails. In-Reply-To: References: Message-ID: <20D46308-D975-4E8A-8B6D-E7706962A933@pipar-tbwa.is> Thx for the reply Andy. No zones on this box. My ca-bundle is april 2017 : pkg://omnios/web/ca-bundle at 5.11-0.151020:20170414T020145Z No updates needed for pkg, : pkg install pkg:/package/pkg No updates necessary for this image. Strange... > On 13 Jul 2017, at 11:48, Andy Fiddaman wrote: > > > > On Thu, 13 Jul 2017, Svavar ?rn Eysteinsson wrote: > > ; As anyone encounter a upgrade fail from 20 to 22 ? > ; I'm unable and get conflicts regarding python. > ; > ; Current system is : > ; OmniOS v11 r151020 > ; OmniOS 5.11 omnios-r151020-4151d05 March 2017 > ; > ; Before I did as the upgrade instructions stated, : > ; > ; > ; /usr/bin/pkg unset-publisher omnios > ; /usr/bin/pkg set-publisher -P --set-property signature-policy=require-signatures -g https://pkg.omniti.com/omnios/r151022/ omnios > ; > ; > ; And my current publishers are : > ; > ; PUBLISHER TYPE STATUS P LOCATION > ; omnios origin online F https://pkg.omniti.com/omnios/r151022 > > What are the versions of of your web/ca-bundle ad package/pkg packages? > Does this system have any zones? If so, what brand? > > It is worth making sure that 'pkg' is up-to-date before attempting the upgrade: > >> pkg install pkg:/package/pkg > > and the release notes state that web/ca-bundle must be up-to-date. > >> https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 > > Andy > > -- > Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 > From an3s.annema at gmail.com Thu Jul 13 12:02:34 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Thu, 13 Jul 2017 14:02:34 +0200 Subject: [OmniOS-discuss] Upgrade from r151020 to r151022 - python conflicts and fails. In-Reply-To: <20D46308-D975-4E8A-8B6D-E7706962A933@pipar-tbwa.is> References: <20D46308-D975-4E8A-8B6D-E7706962A933@pipar-tbwa.is> Message-ID: Contrary to the instructions, you might wanna try the suggestion from Michael Talbott earlier on this list (look for a discussion titled "[OmniOS-discuss] Python conflicts in upgrade from 20 to 22"): Instead of entering ... /usr/bin/pkg update --be-name=omnios-r151022entire at 11,5.11-0.151022 ... you should enter: /usr/bin/pkg update --be-name=omnios-r151022 This suggestion helped me around this issue as well, two days ago. Regards, Andries On 2017-07-13 13:52, Svavar ?rn Eysteinsson wrote: > Thx for the reply Andy. > > > > > > No zones on this box. > > My ca-bundle is april 2017 : > > pkg://omnios/web/ca-bundle at 5.11-0.151020:20170414T020145Z > > No updates needed for pkg, : > > pkg install pkg:/package/pkg > No updates necessary for this image. > > Strange... > > > > > >> On 13 Jul 2017, at 11:48, Andy Fiddaman wrote: >> >> >> >> On Thu, 13 Jul 2017, Svavar ?rn Eysteinsson wrote: >> >> ; As anyone encounter a upgrade fail from 20 to 22 ? >> ; I'm unable and get conflicts regarding python. >> ; >> ; Current system is : >> ; OmniOS v11 r151020 >> ; OmniOS 5.11 omnios-r151020-4151d05 March 2017 >> ; >> ; Before I did as the upgrade instructions stated, : >> ; >> ; >> ; /usr/bin/pkg unset-publisher omnios >> ; /usr/bin/pkg set-publisher -P --set-property signature-policy=require-signatures -g https://pkg.omniti.com/omnios/r151022/ omnios >> ; >> ; >> ; And my current publishers are : >> ; >> ; PUBLISHER TYPE STATUS P LOCATION >> ; omnios origin online F https://pkg.omniti.com/omnios/r151022 >> >> What are the versions of of your web/ca-bundle ad package/pkg packages? >> Does this system have any zones? If so, what brand? >> >> It is worth making sure that 'pkg' is up-to-date before attempting the upgrade: >> >>> pkg install pkg:/package/pkg >> and the release notes state that web/ca-bundle must be up-to-date. >> >>> https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 >> Andy >> >> -- >> Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk >> Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ >> Registered in England and Wales | Company number 4899123 >> > > _______________________________________________ > 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 kebe.com Thu Jul 13 13:12:49 2017 From: danmcd at kebe.com (Dan McDonald) Date: Thu, 13 Jul 2017 09:12:49 -0400 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: Thank you all for your efforts. Dan From svavar at pipar-tbwa.is Thu Jul 13 14:46:49 2017 From: svavar at pipar-tbwa.is (=?utf-8?Q?Svavar_=C3=96rn_Eysteinsson?=) Date: Thu, 13 Jul 2017 14:46:49 +0000 Subject: [OmniOS-discuss] Upgrade from r151020 to r151022 - python conflicts and fails. In-Reply-To: References: <20D46308-D975-4E8A-8B6D-E7706962A933@pipar-tbwa.is> Message-ID: <3CA65338-244D-4A35-B4A2-434B259AE3A6@pipar-tbwa.is> Thanks allot Andries. It works. > On 13 Jul 2017, at 12:02, Andries Annema wrote: > > Contrary to the instructions, you might wanna try the suggestion from Michael Talbott earlier on this list (look for a discussion titled "[OmniOS-discuss] Python conflicts in upgrade from 20 to 22"): > > Instead of entering ... > > /usr/bin/pkg update --be-name=omnios-r151022 entire at 11,5.11-0.151022 > ... you should enter: > /usr/bin/pkg update --be-name=omnios-r151022 > This suggestion helped me around this issue as well, two days ago. > > Regards, > Andries > > > On 2017-07-13 13:52, Svavar ?rn Eysteinsson wrote: >> Thx for the reply Andy. >> >> >> >> >> >> No zones on this box. >> >> My ca-bundle is april 2017 : >> >> pkg://omnios/web/ca-bundle at 5.11-0.151020:20170414T020145Z >> >> No updates needed for pkg, : >> >> pkg install pkg:/package/pkg >> No updates necessary for this image. >> >> Strange... >> >> >> >> >> >>> On 13 Jul 2017, at 11:48, Andy Fiddaman wrote: >>> >>> >>> >>> On Thu, 13 Jul 2017, Svavar ?rn Eysteinsson wrote: >>> >>> ; As anyone encounter a upgrade fail from 20 to 22 ? >>> ; I'm unable and get conflicts regarding python. >>> ; >>> ; Current system is : >>> ; OmniOS v11 r151020 >>> ; OmniOS 5.11 omnios-r151020-4151d05 March 2017 >>> ; >>> ; Before I did as the upgrade instructions stated, : >>> ; >>> ; >>> ; /usr/bin/pkg unset-publisher omnios >>> ; /usr/bin/pkg set-publisher -P --set-property signature-policy=require-signatures -g https://pkg.omniti.com/omnios/r151022/ omnios >>> ; >>> ; >>> ; And my current publishers are : >>> ; >>> ; PUBLISHER TYPE STATUS P LOCATION >>> ; omnios origin online F https://pkg.omniti.com/omnios/r151022 >>> >>> What are the versions of of your web/ca-bundle ad package/pkg packages? >>> Does this system have any zones? If so, what brand? >>> >>> It is worth making sure that 'pkg' is up-to-date before attempting the upgrade: >>> >>>> pkg install pkg:/package/pkg >>> and the release notes state that web/ca-bundle must be up-to-date. >>> >>>> https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 >>> Andy >>> >>> -- >>> Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk >>> Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ >>> Registered in England and Wales | Company number 4899123 >>> >> >> _______________________________________________ >> 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 an3s.annema at gmail.com Thu Jul 13 17:41:10 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Thu, 13 Jul 2017 19:41:10 +0200 Subject: [OmniOS-discuss] pkglint: Python 2.7 MemoryError Message-ID: <52dddb24-3ebf-4de1-36b8-c88715c8b0b0@gmail.com> Hi guys, I've got a freshly installed r151022 VM here (under VMWare Workstation) to fiddle around a bit. Very clean, no extra packages installed yet, not even NFS- or SMB-shares. Only two non-global zones: one to host a repository and one as build environment for some packages I use myself. I have done all this on r151014 machines (VM/test as well as physical/production) as well, but have never bumped into the error I'm getting now. Not sure if it is package-specific or more of a general error - I assume the latter - but for completeness sake, I'm trying to put Znapzend 0.17.0 into a neat IPS packages. .configure, gmake, gmake install, as well as creating the SMF method and manifest files, and the IPS package manifest go just like I got before on r151014, but now on r151022 the "pkglint" process fails. This is what it throws at me: ==begin quote== builder at vm09ngz02build:/tank/build/1_scratch$ sudo pkglint -c ./lint-cache -r http:// znapzend.p5m.3.res Lint engine setup... Ignoring -r option, existing image found. Lint setup 3 1485/1838Traceback (most recent call last): File "/usr/bin/pkglint", line 317, in __ret = main_func() File "/usr/bin/pkglint", line 148, in main_func release=opts.release) File "/usr/lib/python2.7/vendor-packages/pkg/lint/engine.py", line 607, in setup checker.startup(self) File "/usr/lib/python2.7/vendor-packages/pkg/lint/pkglint_action.py", line 174, in startup seed_dict(manifest, "path", self.ref_paths) File "/usr/lib/python2.7/vendor-packages/pkg/lint/pkglint_action.py", line 126, in seed_dict for action in mf_gen(atype): File "/usr/lib/python2.7/vendor-packages/pkg/lint/pkglint_action.py", line 123, in mf_gen for a in mf.gen_actions(): File "/usr/lib/python2.7/vendor-packages/pkg/manifest.py", line 1898, in gen_actions File "/usr/lib/python2.7/vendor-packages/pkg/manifest.py", line 1563, in __load self.set_content(excludes=self.excludes, pathname=self.pathname) File "/usr/lib/python2.7/vendor-packages/pkg/manifest.py", line 1052, in set_content self.add_action(action, excludes) File "/usr/lib/python2.7/vendor-packages/pkg/manifest.py", line 1094, in add_action self.actions.append(action) MemoryError Error: This is an internal error in pkg(5) version 1493165709. Please log a Service Request about this issue including the information above and this message. ==end quote== Any ideas? Am I doing something wrong or is there a bug in Python 2.7 or even pkg(5)? Assuming it simply had not enough memory to get the job done, I tried increasing the VM's assigned memory from 1 to 2, even to 4GB. But that didn't help. This proves I'm still a novice on compiling and maintaining packages... *sigh* Anyway, any hints appreciated! Tnx. Regards, Andries From serge.fonville at gmail.com Thu Jul 13 17:57:23 2017 From: serge.fonville at gmail.com (Serge Fonville) Date: Thu, 13 Jul 2017 19:57:23 +0200 Subject: [OmniOS-discuss] Global zone has a newer version: pkg://omnios/package/pkg@0.5.11, 5.11-0.151022:20170510T220631Z In-Reply-To: References: Message-ID: Hi, The issue is fixed. I detached all zones and then attached all zones with -u. after running pkg update again, it finally updated all the zones. Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl 2017-07-12 23:05 GMT+02:00 Serge Fonville : > Hi, > > While trying to update omnios to the new version, I receive the error I > cannot upgrade since "Global zone has a newer version: > pkg://omnios/package/pkg" > > How do I fix this,. so I can update omnios to the newest version? > > Thanks a lot in advance! > > Kind regards/met vriendelijke groet, > > Serge Fonville > > http://www.sergefonville.nl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary at genashor.com Thu Jul 13 22:49:03 2017 From: gary at genashor.com (Gary Gendel) Date: Thu, 13 Jul 2017 18:49:03 -0400 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: This is very exciting. Thanks for the hard work to get things going. Gary On 7/12/2017 11:32 AM, Tobias Oetiker wrote: > # OmniOS Community Edition > > On April 21st 2017, OmniTI announced that they would suspend active development of OmniOS and support contracts would not be renewed. > > While this announcement left many users stunned, others focused more on the fact that OmniTI in their announcement also expressed the hope that "the community" would take up further development of the OS. 14 weeks later, OmniOS Community Edition is a reality. > > Andy Fiddaman (www.citrus-it.net), Tobias Oetiker (www.oetiker.ch) and Dominik Hassler have spent some quality time setting up the systems and procedures allowing us to take over maintenance and development of OmniOS. In this endeavour we were supported by many. Special thanks to Stefan Husch (www.qutic.com), Peter Tribble (www.petertribble.co.uk), Dan McDonald and Theo Schlossnagle (www.circonus.com). > > We have forked the OmniOS repos and pulled in bugfixes and security fixes that have been published since the release of OmniOS r151022. After setting up our own package repository and updating the build infrastructure, we are finally ready to go public. We are following the established OmniOS release naming scheme by releasing > > > ## OmniOSce r151022h, 12th July 2017 > > The new release contains the following fixes: > > - expat updated to version 2.2.1 (fixes CVE-2017-9233) > - openssl updated to version 1.0.2l > - curl updated to version 7.54.1 > - bind updated to version 9.10.5-P3 > - p7zip updated to fix CVE-2016-9296 > - web/ca-bundle updated to include OmniOSce Certificate Authority certificate > > `uname -a` shows omnios-r151022-f9693432c2 (no change in this release) > > Our work does not stop here though. First we are committed to quickly releasing updates for r151022 as the need arises. We are also working towards releasing r151024 on schedule. To that end, we have already updated the bloody environment with all the latest goodies from upstream illumos and joyent-lx repositories. > > OmniOS community edition hosts its sources on https://github.com/omniosorg/ and if you want to get in touch, you can find us on https://gitter.im/omniosorg/Lobby > > > ## Release Schedule > > The intention is for new stable releases to continue to come out every 26 weeks. Interim, "weekly" updates to stable follow a fixed schedule denoted by letters, one per week. Weekly releases are made as needed, so there may not be a release each week. The first release of a new stable version is synonymous with weekly release "a", though the letter is not used. > > During the intervals between stable releases, Bloody moves forward rapidly, picking up changes from upstream illumos-gate and illumos-joyent as well as updating various userland packages. In general, upstream merges will be performed on a Thursday/Friday each week and weekly releases will be published on a Monday. > > Bloody releases will be published on an ad-hoc basis but may be as frequent as every week. > > Security fixes are excluded from the schedule and handled with priority as they occur. > > > ## How to Upgrade > > All OmniOS packages are signed and the pkg installer is configured to only allow trusted sources for the core packages. In order to upgrade to the new OmniOS community edition, you have to let your box know that the updates will be coming from a new trusted source. This means you will have to import our CA certificate into your system. > > 1. Get a copy of the new certificate > > ``` > # /usr/bin/wget -P /etc/ssl/pkg \ > https://downloads.omniosce.org/ssl/omniosce-ca.cert.pem > ``` > > 2. Check the certificate fingerprint > > ``` > # /usr/bin/openssl x509 -fingerprint \ > -in /etc/ssl/pkg/omniosce-ca.cert.pem -noout > ``` > > `8D:CD:F9:D0:76:CD:AF:C1:62:AF:89:51:AF:8A:0E:35:24:4C:66:6D` > > > 3. Change the publisher to our new repo > > ``` > # /usr/bin/pkg set-publisher -P \ > -G https://pkg.omniti.com/omnios/r151022/ \ > -g https://pkg.omniosce.org/r151022/core/ omnios > ``` > > 4. For each native zone (if you have any), run > > ``` > # /usr/bin/pkg -R set-publisher -P \ > -G https://pkg.omniti.com/omnios/r151022/ \ > -g https://pkg.omniosce.org/r151022/core/ omnios > ``` > > (get a list of all your zones by running `zoneadm list -cv` for the ``, add `/root` to the PATH given in the list.) > > > 5. Install the new ca-bundle containing our new CA > > ``` > # /usr/bin/pkg update -rv web/ca-bundle > ``` > > 6. Remove the CA file imported by hand > > ``` > # rm /etc/ssl/pkg/omniosce-ca.cert.pem > ``` > > 7. Finally update as usual > > ``` > # /usr/bin/pkg update -rv > ``` > > > ## About OmniOS Community Edition Association > > OmniOS Community Edition Association (OmniOSce) is a Swiss association, dedicated to the continued support and release of OmniOS for the benefit of all parties involved. The board of OmniOSce controls access to the OmniOS CA. Current board members are: Tobias Oetiker (President), Andy Fiddaman (Development), Dominik Hassler (Treasurer). > > > ## About Citrus-IT > > Citrus IT is a UK company that provides a managed email service platform to companies around the world. For many years they ran their systems on Solaris with SPARC hardware but transitioned to OmniOS in 2012. www.citrus-it.net > > > ## About OETIKER+PARTNER AG > > OETIKER+PARTNER is a Swiss system management and software development company. Employees from O+P are involved in many Open Source Software projects. O+P runs most of their server hardware on OmniOS. www.oetiker.ch > > > Press inquiries to info at omniosce.org > > Published July 12, 2017 > > OmniOSce > Aarweg 17 > 4600 Olten > Switzerland > > http://www.omniosce.org > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3990 bytes Desc: not available URL: From miniflowtrader at gmail.com Fri Jul 14 01:31:51 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Fri, 14 Jul 2017 01:31:51 +0000 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: Cool! Can the new boot loader handle 4K drives with this release? On Thu, Jul 13, 2017 at 6:51 PM Gary Gendel wrote: > This is very exciting. Thanks for the hard work to get things going. > > Gary > On 7/12/2017 11:32 AM, Tobias Oetiker wrote: > > # OmniOS Community Edition > > > > On April 21st 2017, OmniTI announced that they would suspend active > development of OmniOS and support contracts would not be renewed. > > > > While this announcement left many users stunned, others focused more on > the fact that OmniTI in their announcement also expressed the hope that > "the community" would take up further development of the OS. 14 weeks > later, OmniOS Community Edition is a reality. > > > > Andy Fiddaman (www.citrus-it.net), Tobias Oetiker (www.oetiker.ch) and > Dominik Hassler have spent some quality time setting up the systems and > procedures allowing us to take over maintenance and development of OmniOS. > In this endeavour we were supported by many. Special thanks to Stefan Husch > (www.qutic.com), Peter Tribble (www.petertribble.co.uk), Dan McDonald and > Theo Schlossnagle (www.circonus.com). > > > > We have forked the OmniOS repos and pulled in bugfixes and security > fixes that have been published since the release of OmniOS r151022. After > setting up our own package repository and updating the build > infrastructure, we are finally ready to go public. We are following the > established OmniOS release naming scheme by releasing > > > > > > ## OmniOSce r151022h, 12th July 2017 > > > > The new release contains the following fixes: > > > > - expat updated to version 2.2.1 (fixes CVE-2017-9233) > > - openssl updated to version 1.0.2l > > - curl updated to version 7.54.1 > > - bind updated to version 9.10.5-P3 > > - p7zip updated to fix CVE-2016-9296 > > - web/ca-bundle updated to include OmniOSce Certificate Authority > certificate > > > > `uname -a` shows omnios-r151022-f9693432c2 (no change in this release) > > > > Our work does not stop here though. First we are committed to quickly > releasing updates for r151022 as the need arises. We are also working > towards releasing r151024 on schedule. To that end, we have already updated > the bloody environment with all the latest goodies from upstream illumos > and joyent-lx repositories. > > > > OmniOS community edition hosts its sources on > https://github.com/omniosorg/ and if you want to get in touch, you can > find us on https://gitter.im/omniosorg/Lobby > > > > > > ## Release Schedule > > > > The intention is for new stable releases to continue to come out every > 26 weeks. Interim, "weekly" updates to stable follow a fixed schedule > denoted by letters, one per week. Weekly releases are made as needed, so > there may not be a release each week. The first release of a new stable > version is synonymous with weekly release "a", though the letter is not > used. > > > > During the intervals between stable releases, Bloody moves forward > rapidly, picking up changes from upstream illumos-gate and illumos-joyent > as well as updating various userland packages. In general, upstream merges > will be performed on a Thursday/Friday each week and weekly releases will > be published on a Monday. > > > > Bloody releases will be published on an ad-hoc basis but may be as > frequent as every week. > > > > Security fixes are excluded from the schedule and handled with priority > as they occur. > > > > > > ## How to Upgrade > > > > All OmniOS packages are signed and the pkg installer is configured to > only allow trusted sources for the core packages. In order to upgrade to > the new OmniOS community edition, you have to let your box know that the > updates will be coming from a new trusted source. This means you will have > to import our CA certificate into your system. > > > > 1. Get a copy of the new certificate > > > > ``` > > # /usr/bin/wget -P /etc/ssl/pkg \ > > https://downloads.omniosce.org/ssl/omniosce-ca.cert.pem > > ``` > > > > 2. Check the certificate fingerprint > > > > ``` > > # /usr/bin/openssl x509 -fingerprint \ > > -in /etc/ssl/pkg/omniosce-ca.cert.pem -noout > > ``` > > > > `8D:CD:F9:D0:76:CD:AF:C1:62:AF:89:51:AF:8A:0E:35:24:4C:66:6D` > > > > > > 3. Change the publisher to our new repo > > > > ``` > > # /usr/bin/pkg set-publisher -P \ > > -G https://pkg.omniti.com/omnios/r151022/ \ > > -g https://pkg.omniosce.org/r151022/core/ omnios > > ``` > > > > 4. For each native zone (if you have any), run > > > > ``` > > # /usr/bin/pkg -R set-publisher -P \ > > -G https://pkg.omniti.com/omnios/r151022/ \ > > -g https://pkg.omniosce.org/r151022/core/ omnios > > ``` > > > > (get a list of all your zones by running `zoneadm list -cv` for the > ``, add `/root` to the PATH given in the list.) > > > > > > 5. Install the new ca-bundle containing our new CA > > > > ``` > > # /usr/bin/pkg update -rv web/ca-bundle > > ``` > > > > 6. Remove the CA file imported by hand > > > > ``` > > # rm /etc/ssl/pkg/omniosce-ca.cert.pem > > ``` > > > > 7. Finally update as usual > > > > ``` > > # /usr/bin/pkg update -rv > > ``` > > > > > > ## About OmniOS Community Edition Association > > > > OmniOS Community Edition Association (OmniOSce) is a Swiss association, > dedicated to the continued support and release of OmniOS for the benefit of > all parties involved. The board of OmniOSce controls access to the OmniOS > CA. Current board members are: Tobias Oetiker (President), Andy Fiddaman > (Development), Dominik Hassler (Treasurer). > > > > > > ## About Citrus-IT > > > > Citrus IT is a UK company that provides a managed email service platform > to companies around the world. For many years they ran their systems on > Solaris with SPARC hardware but transitioned to OmniOS in 2012. > www.citrus-it.net > > > > > > ## About OETIKER+PARTNER AG > > > > OETIKER+PARTNER is a Swiss system management and software development > company. Employees from O+P are involved in many Open Source Software > projects. O+P runs most of their server hardware on OmniOS. www.oetiker.ch > > > > > > Press inquiries to info at omniosce.org > > > > Published July 12, 2017 > > > > OmniOSce > > Aarweg 17 > > 4600 Olten > > Switzerland > > > > http://www.omniosce.org > > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Fri Jul 14 01:48:07 2017 From: henson at acm.org (Paul B. Henson) Date: Thu, 13 Jul 2017 18:48:07 -0700 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> Message-ID: <20170714014806.GB4077@bender.it-sys.cpp.edu> On Fri, Jul 14, 2017 at 01:31:51AM +0000, Mini Trader wrote: > Can the new boot loader handle 4K drives with this release? The fix for illumos issue 8303 appears to have been commited to the r151022 branch of the omniosorg illumos-omnios repo on 7/8, and r151022h was released 7/12, so I'd guess yes. But it's just a guess :). Great to see backports hitting r151022 LTS code... > > > ## OmniOSce r151022h, 12th July 2017 From tobi at oetiker.ch Fri Jul 14 08:59:07 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 14 Jul 2017 10:59:07 +0200 (CEST) Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <20170714014806.GB4077@bender.it-sys.cpp.edu> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> <20170714014806.GB4077@bender.it-sys.cpp.edu> Message-ID: <71286095.33634.1500022747925.JavaMail.zimbra@oetiker.ch> Our first release only contained userland updates (careful as we are) the next one (r151022i) will also feature actual illumos things like the loader. cheers tobi ----- On Jul 14, 2017, at 3:48 AM, Paul B. Henson henson at acm.org wrote: > On Fri, Jul 14, 2017 at 01:31:51AM +0000, Mini Trader wrote: > >> Can the new boot loader handle 4K drives with this release? > > The fix for illumos issue 8303 appears to have been commited to the > r151022 branch of the omniosorg illumos-omnios repo on 7/8, and r151022h > was released 7/12, so I'd guess yes. But it's just a guess :). Great to > see backports hitting r151022 LTS code... > >> > > ## OmniOSce r151022h, 12th July 2017 > > _______________________________________________ > 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 From an3s.annema at gmail.com Fri Jul 14 12:45:07 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Fri, 14 Jul 2017 14:45:07 +0200 Subject: [OmniOS-discuss] Postfix service: syslog reports "fatal: the Postfix mail system is already running" every second Message-ID: <968cced0-05d0-a975-2ddf-134fe3a6656a@gmail.com> Hi all, Have been running postfix from the "ms.omniti.com" publisher for some years now on r151014 without issues. Last week I updated my October 2016 r151014 system to the latest r151014-status, as a first step in the direction of upgrading to the latest LTS. I'm not actually there yet to upgrade to r151022; first I want to make sure all my services and packages run flawlessly on that version. Turns out that being careful pays off. In this update process, postfix got updated to 2.11.9-0.151014:20170214T224831Z. It still works, but /var/log/syslog is filled with a new line ever second stating: ".... [ID 947731 mail.crit] fatal: the Postfix mail system is already running" And /var/svc/log/network-smtp-postfix:default.log is repeatedly filled with line pairs like: "[ Jul 14 13:48:50 Executing start method ("/opt/omni/sbin/postfix start"). ] [ Jul 14 13:48:51 Stopping because service exited with an error. ] [ Jul 14 13:48:51 Executing start method ("/opt/omni/sbin/postfix start"). ] [ Jul 14 13:48:51 Stopping because service exited with an error. ] [ Jul 14 13:48:51 Failing too quickly, throttling. ]" Simply disabling and re-enabling the SMF service does not help. What did help was this: $ sudo svcadm disable postfix $ sudo fuser -k /var/lib/postfix/master.lock $ sudo rm /var/lib/postfix/master.lock $ sudo rm /var/spool/postfix/pid/master.pid $ sudo svcadm enable postfix That, however, was on r151014. On a separate, freshly installed r151022 test-system, I installed this same postfix 2.11.9 package and the same issue emerged. However, the fix that worked on r151014, does not seem to work on r151022. Rebooting doesn't help either. Funny thing is: it does deliver email nicely, despite this restarting issue. I tried downgrading to postfix 2.10.10: problem still exists. Tried downgrading further, to 2.10.2: not possible, because the manifest states a "incorporate" dependency on the "entire at 11-0.151014" package. Hm, right... now I'm out of ideas. Any clues? Regards, Andries From miniflowtrader at gmail.com Fri Jul 14 20:38:39 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Fri, 14 Jul 2017 20:38:39 +0000 Subject: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h In-Reply-To: <71286095.33634.1500022747925.JavaMail.zimbra@oetiker.ch> References: <878038353.950126.1499873544809.JavaMail.zimbra@oetiker.ch> <20170714014806.GB4077@bender.it-sys.cpp.edu> <71286095.33634.1500022747925.JavaMail.zimbra@oetiker.ch> Message-ID: Sweet! This is all great news. On Fri, Jul 14, 2017 at 4:59 AM Tobias Oetiker wrote: > Our first release only contained userland updates (careful as we are) > the next one (r151022i) will also feature actual illumos things like > the loader. > > cheers > tobi > > ----- On Jul 14, 2017, at 3:48 AM, Paul B. Henson henson at acm.org wrote: > > > On Fri, Jul 14, 2017 at 01:31:51AM +0000, Mini Trader wrote: > > > >> Can the new boot loader handle 4K drives with this release? > > > > The fix for illumos issue 8303 appears to have been commited to the > > r151022 branch of the omniosorg illumos-omnios repo on 7/8, and r151022h > > was released 7/12, so I'd guess yes. But it's just a guess :). Great to > > see backports hitting r151022 LTS code... > > > >> > > ## OmniOSce r151022h, 12th July 2017 > > > > _______________________________________________ > > 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 danmcd at kebe.com Sat Jul 15 21:38:15 2017 From: danmcd at kebe.com (Dan McDonald) Date: Sat, 15 Jul 2017 17:38:15 -0400 Subject: [OmniOS-discuss] Broken upgrade list Message-ID: <24D2C326-9D43-421A-97A8-16F50FEE132D@kebe.com> From my notes when I finished r151022, here are a list of "STUCK" packages and some other didn't-update ones. Dan ================ binutils/ STUCK on 2.25 (vs. 2.26) stupid relocation type 0x2a/42 STT_GNU_IFUNC breaks all sorts of other package builds. AHA!!! SEE https://www.illumos.org/issues/6653 cdrtools/ STUCK on 3.00 (not worth cost of investigating 3.01) glib/ STUCK on 2.34.3 (2.50 HAD POSSIBLE PROBLEM...) idnkit/ NO UPDATE (There is 2.3 available, but it's "idnkit2".) ipmitool/ BLOCKED, could be 1.8.17 with work... isc-dhcp/ NO UPDATE (NOTE: ISC now has "Kea" DHCP server replacement) open-vm-tools/ STUCK on 9.4.0 (really weird stuff...) python-cherrypy/ STUCK on 3.2.2 (breaks IPS on upgrade) python-m2crypto/ STUCK ON 0.24.0 (0.25.1 update broke IPS pkgsign) python-pyopenssl/ STUCK ON 0.11 --> never-ending python package pull to update! python-setuptools/ STUCK ON 0.6.11 (NO IDEA) sudo/ STUCK on 1.8.7 (Oracle Solaris-isms, among other things) swig/ STUCK on 2.0.12 (3.0.x breaks M2Crypto, among other things...) trousers/ STUCK on 0.3.8 (no idea why...) From omnios at citrus-it.net Sat Jul 15 22:08:08 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Sat, 15 Jul 2017 22:08:08 +0000 (UTC) Subject: [OmniOS-discuss] Broken upgrade list In-Reply-To: <24D2C326-9D43-421A-97A8-16F50FEE132D@kebe.com> References: <24D2C326-9D43-421A-97A8-16F50FEE132D@kebe.com> Message-ID: On Sat, 15 Jul 2017, Dan McDonald wrote: ; From my notes when I finished r151022, here are a list of "STUCK" packages and some other didn't-update ones. ; ; Dan - snip - Thank you Dan, that's very useful stuff! Of that list, we have open issues to look at binutils, ipmitool, sudo and python. We'd already pruned the others from the update candidates. Looks like binutils is a non-starter until the symbol table issue is resolved at one end or the other and python will likely not be tackled for a while as it looks like a big job. Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From mailinglists at qutic.com Sun Jul 16 10:57:03 2017 From: mailinglists at qutic.com (qutic development) Date: Sun, 16 Jul 2017 12:57:03 +0200 Subject: [OmniOS-discuss] Questions about - End the uncertainty - In-Reply-To: References: Message-ID: > Am 11.07.2017 um 23:26 schrieb Robert Treat : > > As for the wiki, what we would like to see is the wiki recreated in a > github project; I converted the wiki to github using pandoc for the wiki -> markdown conversion. Fixed the links to be usable with a github repo and updated the current repo paths to omniosce. If you find any issues please send pull requests: https://github.com/jfqd/OmniOSce-wiki - Stefan From mikeowens at gmail.com Mon Jul 17 02:27:10 2017 From: mikeowens at gmail.com (Mike Owens) Date: Sun, 16 Jul 2017 21:27:10 -0500 Subject: [OmniOS-discuss] Unable to install zone Message-ID: I am running OmniOs within KVM. I have tried both releases and in all cases I when I try to install a new zone I get the following error: 'ERROR: unable to determine global zone boot environment.' I've googled for answers and I cannot find anything useful. Any help/suggestions appreciated. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From paladinemishakal at gmail.com Mon Jul 17 05:12:07 2017 From: paladinemishakal at gmail.com (Lawrence Giam) Date: Mon, 17 Jul 2017 13:12:07 +0800 Subject: [OmniOS-discuss] How to check which SSH is installed Message-ID: Hi All, I am trying to do a test upgrade from 151014 to 151022 and saw that there is a step which involve switching from SunSSH to OpenSSH. I have mainly use x86 system so I would like to know how can I check what SSH is installed by default on OmniOS R151014? Thanks & Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From omnios at citrus-it.net Mon Jul 17 06:23:41 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Mon, 17 Jul 2017 06:23:41 +0000 (UTC) Subject: [OmniOS-discuss] Unable to install zone In-Reply-To: References: Message-ID: On Sun, 16 Jul 2017, Mike Owens wrote: ; I am running OmniOs within KVM. I have tried both releases and in all cases ; I when I try to install a new zone I get the following error: ; ; 'ERROR: unable to determine global zone boot environment.' You need to assign a UUID to the root BE. Try these commands: zfs set org.opensolaris.libbe:uuid=`uuidgen` rpool/ROOT/omnios zfs set org.opensolaris.libbe:policy=static rpool/ROOT/omnios Assuming your root pool is called 'rpool' and the current boot environment is 'omnios'. This bug has recently been fixed in the installer but the installation media has not yet been updated. Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From mailinglists at qutic.com Mon Jul 17 06:48:47 2017 From: mailinglists at qutic.com (qutic development) Date: Mon, 17 Jul 2017 08:48:47 +0200 Subject: [OmniOS-discuss] How to check which SSH is installed In-Reply-To: References: Message-ID: <09782C39-A9C1-425D-BE48-F3F3CE6D755E@qutic.com> > I am trying to do a test upgrade from 151014 to 151022 and saw that there is a step which involve switching from SunSSH to OpenSSH. I have mainly use x86 system so I would like to know how can I check what SSH is installed by default on OmniOS R151014? r151014 has SunSSH: # pkg list |grep ssh network/ssh 0.5.11-0.151014 i-- network/ssh/ssh-key 0.5.11-0.151014 i-- service/network/ssh 0.5.11-0.151014 i-- After the switch to OpenSSH it looks like: # pkg list | grep ssh network/openssh 7.4.1-0.151014 i-- network/openssh-server 7.4.1-0.151014 i-- - Stefan From skeltonr at btconnect.com Mon Jul 17 06:55:39 2017 From: skeltonr at btconnect.com (Richard Skelton) Date: Mon, 17 Jul 2017 07:55:39 +0100 Subject: [OmniOS-discuss] How to check which SSH is installed In-Reply-To: References: Message-ID: <596C5F6B.5040609@btconnect.com> Hi Lawrence, You can see the version of ssh on my r151022 system:- root at ml110:~# ssh -V OpenSSH_7.4p1, OpenSSL 1.0.2k 26 Jan 2017 Older systems were using Sun_SSH something like ;- rich: ssh -V Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080bf Lawrence Giam wrote: > Hi All, > > I am trying to do a test upgrade from 151014 to 151022 and saw that > there is a step which involve switching from SunSSH to OpenSSH. I have > mainly use x86 system so I would like to know how can I check what SSH > is installed by default on OmniOS R151014? > > 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 paladinemishakal at gmail.com Mon Jul 17 12:22:30 2017 From: paladinemishakal at gmail.com (Lawrence Giam) Date: Mon, 17 Jul 2017 20:22:30 +0800 Subject: [OmniOS-discuss] Latest version of R151014 download from website Message-ID: Hi All, I am looking at downloading the latest R151014 at 2fb9a48 from OmniOS website at https://omnios.omniti.com/media/ but looking at the list, I do not know which one is it. Does anybody know which one I should download? Thanks & Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikeowens at gmail.com Mon Jul 17 12:48:45 2017 From: mikeowens at gmail.com (Mike Owens) Date: Mon, 17 Jul 2017 07:48:45 -0500 Subject: [OmniOS-discuss] Unable to install zone In-Reply-To: References: Message-ID: Worked perfectly. Thank you so much. On Mon, Jul 17, 2017 at 1:23 AM, Andy Fiddaman wrote: > > On Sun, 16 Jul 2017, Mike Owens wrote: > > ; I am running OmniOs within KVM. I have tried both releases and in all > cases > ; I when I try to install a new zone I get the following error: > ; > ; 'ERROR: unable to determine global zone boot environment.' > > You need to assign a UUID to the root BE. Try these commands: > > zfs set org.opensolaris.libbe:uuid=`uuidgen` rpool/ROOT/omnios > zfs set org.opensolaris.libbe:policy=static rpool/ROOT/omnios > > Assuming your root pool is called 'rpool' and the current boot environment > is 'omnios'. > > This bug has recently been fixed in the installer but the installation > media has not yet been updated. > > Andy > > -- > Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 > > -- Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Mon Jul 17 12:56:44 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 17 Jul 2017 14:56:44 +0200 (CEST) Subject: [OmniOS-discuss] ANNOUNCEMENT - OmniOSce r151022i is out Message-ID: <368786009.151588.1500296203999.JavaMail.zimbra@oetiker.ch> OmniOSce r151022i OmniOS Community Edition is releasing the second update to the OmniOS r151022 LTS release. This update, in accordance with the release naming policy is carrying the letter 'i'. If you are still running vanilla OmniOS r151022 and are contemplating upgrading to OmniOS Community Edition now, you can find instructions on how to do that at the end of the release notes linked below. This time around we are providing non-userland updates for the first time so this update will require you to reboot OmniOS after installation. Updated release media will also be available later this week. This release includes a security fix to the expat library, an updated mr_sas driver with better reset behaviour, improvements in the svcs command when non-native zones are installed and several stability and bug fixes in the kernel and LX zones. The loader screen and pkg(5) command have also been updated to reflect the new community edition. Full release notes can be found at https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md To upgrade, utter: pkg update -r package/pkg pkg update -r --be-name=r151022i We are also hard at work to publish a new bloody release with all the latest merges from the upstream illumos and joyent repos. A separate announcement on this will follow. About OmniOS Community Edition Association OmniOS Community Edition Association (OmniOSce) is a Swiss association, dedicated to the continued support and release of OmniOS for the benefit of all parties involved. The board of OmniOSce controls access to the OmniOS CA. Current board members are: Tobias Oetiker (President), Andy Fiddaman (Development), Dominik Hassler (Treasurer). Press inquiries to info at omniosce.org Published July 17, 2017 OmniOSce Aarweg 17 4600 Olten Switzerland -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Mon Jul 17 17:27:42 2017 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 17 Jul 2017 19:27:42 +0200 Subject: [OmniOS-discuss] ANNOUNCEMENT - OmniOSce r151022i is out In-Reply-To: <368786009.151588.1500296203999.JavaMail.zimbra@oetiker.ch> References: <368786009.151588.1500296203999.JavaMail.zimbra@oetiker.ch> Message-ID: On Mon, Jul 17, 2017 at 2:56 PM, Tobias Oetiker wrote: > OmniOSce r151022i > > OmniOS Community Edition is releasing the second update to the OmniOS > r151022 LTS release. This update, in accordance with the release naming > policy is carrying the letter 'i'. > > If you are still running vanilla OmniOS r151022 and are contemplating > upgrading to OmniOS Community Edition now, you can find instructions on how > to do that at the end of the release notes linked below. > just updated my home microserver from vanilla omnios, everything went perfectly. Nice work. Thanks! -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From an3s.annema at gmail.com Mon Jul 17 17:57:48 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Mon, 17 Jul 2017 19:57:48 +0200 Subject: [OmniOS-discuss] Latest version of R151014 download from website In-Reply-To: References: Message-ID: <87afa694-ccb0-5d19-daa0-eab00a215246@gmail.com> Based on the current r151022 installation media as listed on this page ... https://omnios.omniti.com/wiki.php/Installation ... or even better the now current OmniOSce wiki as transfered here: https://github.com/jfqd/OmniOSce-wiki/blob/master/Installation.md ... I guess - if you really specifically want the previous LTS version - you should get this one: https://omnios.omniti.com/media/OmniOS_Text_r151014.iso Hope this helps. Regards, Andries On 2017-07-17 14:22, Lawrence Giam wrote: > Hi All, > > I am looking at downloading the latest R151014 at 2fb9a48 from OmniOS > website at https://omnios.omniti.com/media/ but looking at the list, I > do not know which one is it. > > Does anybody know which one I should download? > > 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 svavar at pipar-tbwa.is Tue Jul 18 09:53:33 2017 From: svavar at pipar-tbwa.is (=?iso-8859-1?Q?Svavar_=D6rn_Eysteinsson?=) Date: Tue, 18 Jul 2017 09:53:33 +0000 Subject: [OmniOS-discuss] Ang: [developer] Re: Strange bge0 messages in syslog. interrupt, flags - not updated? In-Reply-To: References: <1E032AB6-8E23-4466-B5BB-3DD80849C0AD@pipar-tbwa.is> <433A63C1-4A65-4948-AFA2-F4C626B3E288@pipar-tbwa.is> <5A0ECE59-010C-47C3-8F92-54B13D5CE9E8@omniti.com> Message-ID: <8964303A-A274-4121-8C73-CF4A6CFAB9DF@pipar-tbwa.is> Hello list. Has there been any more update on the bge driver last 2years or so? Since 2015 I'm still getting allot of those, like always when utilizing the interface on my server. Jul 17 13:10:57 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x8d - not updated? Jul 17 13:10:57 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa2 - not updated? Jul 17 13:10:57 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe - not updated? Jul 17 13:10:59 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x7b - not updated? Jul 17 13:10:59 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x7f - not updated? Jul 17 13:10:59 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x92 - not updated? Jul 17 13:10:59 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xdd - not updated? Jul 17 13:11:10 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe6 - not updated? Jul 17 13:11:12 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xcf - not updated? Jul 17 13:11:12 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5a - not updated? Jul 17 13:11:15 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3b - not updated? Jul 17 13:11:15 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x49 - not updated? Jul 17 13:11:15 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x9a - not updated? Jul 17 13:11:15 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa1 - not updated? Jul 17 13:11:15 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbd - not updated? Jul 17 13:11:22 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x55 - not updated? Jul 17 13:11:22 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb4 - not updated? Jul 17 13:11:22 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xc6 - not updated? Jul 17 13:11:27 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x59 - not updated? Jul 17 13:11:27 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x7f - not updated? Jul 17 13:11:27 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x14 - not updated? Jul 17 13:11:27 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x60 - not updated? Jul 17 13:11:31 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x4 - not updated? Jul 17 13:11:31 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x16 - not updated? Jul 17 13:11:31 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x9f - not updated? Jul 17 13:11:31 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xc8 - not updated? Jul 17 13:11:31 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x0 - not updated? Jul 17 13:11:47 blackbox bge: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x66 - not updated? messages, mostly when my server has some traffic going through. Often the interface stalls, and throughput is degraded. My current setup as for now is(since last week) OmniOS r151022 omnios-r151022-f9693432c and those messages still appears. Any help and or suggestions much appreciated. Best regards, Svavar O Reykjavik - Iceland > On 08 Apr 2015, at 18:19, Johan Kragsterman wrote: > > Hi! > > -----Svavar ?rn Eysteinsson skrev: ----- > Till: Dan McDonald > Fr?n: Svavar ?rn Eysteinsson > Datum: 2015-04-08 17:41 > Kopia: "omnios-discuss at lists.omniti.com" , _illumos-dev > ?rende: [developer] Re: [OmniOS-discuss] Strange bge0 messages in syslog. interrupt, flags - not updated? > > Thanks for the quick reply. > > Here's my prtconf from the HP microserver : > > System Configuration: Oracle Corporation i86pc > Memory size: 16352 Megabytes > System Peripherals (Software Nodes): > > i86pc > scsi_vhci, instance #0 > pci, instance #0 > pci103c,1609 (pciex1022,9601) [Advanced Micro Devices, Inc. [AMD] RS880 Host Bridge] (driver not attached) > pci103c,9602 (pciex103c,9602) [Hewlett-Packard Company unknown device], instance #0 > display (pci1002,9712) [Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250]], instance #0 > pci1022,9606 (pciex1022,9606) [Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (PCIE port 2)], instance #0 > pci103c,705d (pciex14e4,165b) [Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe], instance #0 > > > Thanks again. > > BR, > > Svavar O > > > > > > > I actually got the same msg on one of my boxes, a Dell T5500 workstation, westmere CPU's. The machine was running for a couple of hours, before I started som heavier work, involving the bge interface. There were no logs about this before I started the more serious work. After I started it, they showed up, but not in great numbers. Like this: > > > pr 8 20:04:33 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x33 - not updated? > Apr 8 20:05:09 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd8 - not updated? > Apr 8 20:06:01 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x4 - not updated? > Apr 8 20:06:33 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x7e - not updated? > Apr 8 20:10:04 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xac - not updated? > Apr 8 20:10:22 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x22 - not updated? > Apr 8 20:10:25 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x54 - not updated? > Apr 8 20:19:55 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? > Apr 8 20:20:46 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xf1 - not updated? > Apr 8 20:20:51 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x59 - not updated? > > > > > > > > >> On 8. apr. 2015, at 14:33, Dan McDonald wrote: >> >> What does "prtconf -d" say about which model number your Broadcom/bge is? >> >> There was a massive bge update in the 014 release. Perhaps some error path should be less chatty? >> >> I'm including the illumos developer's list, just in case. >> >> Pardon the top-post, >> Dan >> >> >>> On Apr 8, 2015, at 5:36 AM, Svavar ?rn Eysteinsson wrote: >>> >>> >>> Hello List. >>> >>> I recently upgraded my OmniOS installation from 1012 to 1014 on my HP Microserver N40L. >>> Everything went smooth and everything seems OK and solid. >>> >>> There are tho, these messages that appear in my logs every now and then regarding the network controller (bge0) : >>> >>> Apr 7 15:12:33 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2c - not updated? >>> Apr 7 15:15:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x86 - not updated? >>> Apr 7 15:17:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x94 - not updated? >>> Apr 7 15:22:46 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xc2 - not updated? >>> Apr 7 15:36:25 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6a - not updated? >>> Apr 7 15:37:57 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x4b - not updated? >>> Apr 7 15:42:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x68 - not updated? >>> Apr 7 15:42:14 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? >>> Apr 7 15:42:38 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6 - not updated? >>> Apr 7 15:44:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa8 - not updated? >>> Apr 7 15:45:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? >>> Apr 7 15:48:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? >>> Apr 7 15:50:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? >>> Apr 7 15:50:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x62 - not updated? >>> Apr 7 15:52:08 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x26 - not updated? >>> Apr 7 15:52:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? >>> Apr 7 15:53:10 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? >>> Apr 7 15:54:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe8 - not updated? >>> Apr 7 15:54:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe2 - not updated? >>> Apr 7 15:55:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xab - not updated? >>> Apr 7 16:01:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x1c - not updated? >>> Apr 7 17:53:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? >>> Apr 7 18:24:48 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x65 - not updated? >>> Apr 7 18:51:17 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd7 - not updated? >>> Apr 7 18:51:27 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xea - not updated? >>> Apr 7 18:52:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb - not updated? >>> Apr 7 18:57:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xaf - not updated? >>> Apr 7 18:58:22 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3d - not updated? >>> Apr 7 18:58:50 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? >>> Apr 7 18:59:37 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? >>> Apr 7 19:00:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa4 - not updated? >>> Apr 7 19:01:02 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xae - not updated? >>> Apr 7 19:01:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xdd - not updated? >>> Apr 7 19:15:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? >>> Apr 7 19:19:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x50 - not updated? >>> Apr 7 19:59:40 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x80 - not updated? >>> Apr 7 20:00:31 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x30 - not updated? >>> Apr 7 20:01:30 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? >>> Apr 7 20:06:51 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb2 - not updated? >>> Apr 7 20:17:15 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? >>> Apr 7 20:30:29 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x41 - not updated? >>> Apr 7 21:11:20 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x8 - not updated? >>> Apr 7 21:33:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? >>> Apr 7 21:39:59 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe6 - not updated? >>> Apr 7 21:51:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5b - not updated? >>> Apr 7 21:59:47 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe9 - not updated? >>> Apr 7 22:05:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x88 - not updated? >>> Apr 7 22:30:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xfb - not updated? >>> Apr 7 22:52:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb4 - not updated? >>> Apr 7 22:56:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? >>> Apr 7 23:03:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5c - not updated? >>> Apr 8 00:34:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2e - not updated? >>> Apr 8 01:00:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd2 - not updated? >>> Apr 8 03:20:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? >>> Apr 8 03:55:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x24 - not updated? >>> Apr 8 05:00:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xcd - not updated? >>> Apr 8 08:42:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x48 - not updated? >>> >>> Does anyone know what these interrupt - not updates messages mean ? >>> I have never seen them before, until after the 1014 update. >>> >>> dladm shows : >>> LINK MEDIA STATE SPEED DUPLEX DEVICE >>> bge0 Ethernet up 1000 full bge0 >>> >>> dladm show-link -s : >>> LINK IPACKETS RBYTES IERRORS OPACKETS OBYTES OERRORS >>> bge0 13344422 2915541511 0 15403475 1025837411 0 >>> >>> >>> Thanks in advance. >>> >>> Best regards, >>> >>> Svavar O >>> Reykjavik - Iceland >>> >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > > > > ------------------------------------------- > illumos-developer > Archives: https://www.listbox.com/member/archive/182179/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182179/23755348-1998767f > Modify Your Subscription: https://www.listbox.com/member/?member_id=23755348&id_secret=23755348-0bb51dcb > Powered by Listbox: http://www.listbox.com > > From mailinglists at qutic.com Tue Jul 18 10:25:12 2017 From: mailinglists at qutic.com (qutic development) Date: Tue, 18 Jul 2017 12:25:12 +0200 Subject: [OmniOS-discuss] Python conflicts in upgrade from 20 to 22 In-Reply-To: <237D8DC8-535F-45BC-8525-46E77085F677@lji.org> References: <3BE0DEED8863E5429BAE4CAEDF62456504048D050D1A@AIRA-SRV.aira.local> <5619B849-471F-4832-8676-5CBE18069C88@qutic.com> <237D8DC8-535F-45BC-8525-46E77085F677@lji.org> Message-ID: <72DE8F24-7840-4A9B-ABD5-3DD10D9CCB6C@qutic.com> Thanks Michael, I added the hint to the wiki: https://github.com/jfqd/OmniOSce-wiki/blob/master/Upgrade_to_r151022.md#performing-the-upgrade-ipkg-zones-only---new-method - Stefan > I ran into this as well. Turns out if you update the publisher to the new version and then do a: > > pkg update entire > > it'll fail with that error. But... if you just do a > > pkg update > > it'll succeed without error (and update all 379 packages instead of 377 in my case). I'm guessing there's some dependency incorrectly specified somewhere that is causing this specific issue. But I'm not a package maintainer so I can't say for certain. > > Hope this helps! From an3s.annema at gmail.com Tue Jul 18 19:47:45 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Tue, 18 Jul 2017 21:47:45 +0200 Subject: [OmniOS-discuss] ANNOUNCEMENT - OmniOSce r151022i is out In-Reply-To: References: <368786009.151588.1500296203999.JavaMail.zimbra@oetiker.ch> Message-ID: <6665e6f5-0c0b-5db8-4c12-864213925ac2@gmail.com> How did you handle any non-global (especially ipkg) zones? If I'm not mistaken, the procedure written here ... https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md#upgrading-from-omniti-released-r151022 ... is far from complete regarding zones. I gave a virtual OmniOS-instance a go with it, but my zones didn't get along as I thought they might because of the "-r" option in the "pkg update -rv" commands. Shouldn't all the steps be done in every zone as well? And if true, how can this be easily done from the global zone? With something like this, I guess: # for i in $(zoneadm list | grep -v global | sort); do echo $i && zlogin $i ; done And is any "zoneadm -z detach" and "zoneadm -z attach -u" needed as well or does that only apply to larger upgrades like r151020 -> r151022? Any clarification in the procedure on github is greatly appreciated. Tnx. Regards, Andries On 2017-07-17 19:27, Natxo Asenjo wrote: > > > On Mon, Jul 17, 2017 at 2:56 PM, Tobias Oetiker > wrote: > > OmniOSce r151022i > > OmniOS Community Edition is releasing the second update to the > OmniOS r151022 LTS release. This update, in accordance with the > release naming policy is carrying the letter 'i'. > > If you are still running vanilla OmniOS r151022 and are > contemplating upgrading to OmniOS Community Edition now, you can > find instructions on how to do that at the end of the release > notes linked below. > > > just updated my home microserver from vanilla omnios, everything went > perfectly. > > Nice work. Thanks! > > -- > regards, > natxo > > > _______________________________________________ > 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 kebe.com Tue Jul 18 20:01:39 2017 From: danmcd at kebe.com (Dan McDonald) Date: Tue, 18 Jul 2017 16:01:39 -0400 Subject: [OmniOS-discuss] ANNOUNCEMENT - OmniOSce r151022i is out In-Reply-To: <6665e6f5-0c0b-5db8-4c12-864213925ac2@gmail.com> References: <368786009.151588.1500296203999.JavaMail.zimbra@oetiker.ch> <6665e6f5-0c0b-5db8-4c12-864213925ac2@gmail.com> Message-ID: For non linked image (ipkg) zones, you'll have to likely do the detach/attach -u method. Same as the OmniTI OmniOS wiki said. Dan Sent from my iPhone (typos, autocorrect, and all) > On Jul 18, 2017, at 3:47 PM, Andries Annema wrote: > > How did you handle any non-global (especially ipkg) zones? > > If I'm not mistaken, the procedure written here ... > > https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md#upgrading-from-omniti-released-r151022 > > ... is far from complete regarding zones. > I gave a virtual OmniOS-instance a go with it, but my zones didn't get along as I thought they might because of the "-r" option in the "pkg update -rv" commands. > Shouldn't all the steps be done in every zone as well? And if true, how can this be easily done from the global zone? With something like this, I guess: > # for i in $(zoneadm list | grep -v global | sort); do echo $i && zlogin $i ; done > And is any "zoneadm -z detach" and "zoneadm -z attach -u" needed as well or does that only apply to larger upgrades like r151020 -> r151022? > Any clarification in the procedure on github is greatly appreciated. Tnx. > > Regards, > Andries > >> On 2017-07-17 19:27, Natxo Asenjo wrote: >> >> >>> On Mon, Jul 17, 2017 at 2:56 PM, Tobias Oetiker wrote: >>> OmniOSce r151022i >>> >>> OmniOS Community Edition is releasing the second update to the OmniOS r151022 LTS release. This update, in accordance with the release naming policy is carrying the letter 'i'. >>> >>> If you are still running vanilla OmniOS r151022 and are contemplating upgrading to OmniOS Community Edition now, you can find instructions on how to do that at the end of the release notes linked below. >> >> just updated my home microserver from vanilla omnios, everything went perfectly. >> >> Nice work. Thanks! >> >> -- >> regards, >> natxo >> >> >> _______________________________________________ >> 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 natxo.asenjo at gmail.com Tue Jul 18 21:04:22 2017 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 18 Jul 2017 23:04:22 +0200 Subject: [OmniOS-discuss] ANNOUNCEMENT - OmniOSce r151022i is out In-Reply-To: <6665e6f5-0c0b-5db8-4c12-864213925ac2@gmail.com> References: <368786009.151588.1500296203999.JavaMail.zimbra@oetiker.ch> <6665e6f5-0c0b-5db8-4c12-864213925ac2@gmail.com> Message-ID: hi, On Tue, Jul 18, 2017 at 9:47 PM, Andries Annema wrote: > How did you handle any non-global (especially ipkg) zones? > I just have one ipkg zone and re-did the procedure manually. I forgot to do it for a few hours, and the zone was running ok after rebooting, so I had not noticed ;-) -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge.fonville at gmail.com Thu Jul 20 15:11:56 2017 From: serge.fonville at gmail.com (Serge Fonville) Date: Thu, 20 Jul 2017 17:11:56 +0200 Subject: [OmniOS-discuss] VNICs disappear after reboot Message-ID: Hi, I have been a happy user of OmniOS for some time now, but one thing has been bothering me. Sometimes when I reboot the server, all VNICs seem to disappear . Usually when I reboot the server a couple of times, they are back. Do I need to do something for them to appear automatically after boot? When I run dladm show-vnic they are not there, but when I try to add them, I get the error the VNIC already exists. Any help is greatly appreciated. Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk.willems at exitas.be Thu Jul 20 16:11:13 2017 From: dirk.willems at exitas.be (Dirk Willems) Date: Thu, 20 Jul 2017 18:11:13 +0200 Subject: [OmniOS-discuss] ANNOUNCEMENT - OmniOSce r151022i is out In-Reply-To: <368786009.151588.1500296203999.JavaMail.zimbra@oetiker.ch> References: <368786009.151588.1500296203999.JavaMail.zimbra@oetiker.ch> Message-ID: Hello OmniOS Community, First of all Much Congratulations and Appreciation for all your efforts and continue with the OmniOS Community. Specially thanks for Tobias Andy and Dominik for leading this Community. Also Special thanks for Dan for keeping up the great help and support. I have upgraded to OmnioSce omnios-r151022-5e982daae6 without any problems everything went very smooth :) I was very scared for loosing OmniOS but thanks to all of you I'm a very happy and satisfied SystemAdmin. Keep up the good work my friends !!! Kind Regards, Dirk Willems On 17-07-17 14:56, Tobias Oetiker wrote: > OmniOSce r151022i > > OmniOS Community Edition is releasing the second update to the OmniOS > r151022 LTS release. This update, in accordance with the release > naming policy is carrying the letter 'i'. > > If you are still running vanilla OmniOS r151022 and are contemplating > upgrading to OmniOS Community Edition now, you can find instructions > on how to do that at the end of the release notes linked below. > > This time around we are providing non-userland updates for the first > time so this update will require you to reboot OmniOS after > installation. Updated release media will also be available later this > week. > > This release includes a security fix to the expat library, an updated > mr_sas driver with better reset behaviour, improvements in the svcs > command when non-native zones are installed and several stability and > bug fixes in the kernel and LX zones. The loader screen and pkg(5) > command have also been updated to reflect the new community edition. > > Full release notes can be found at > > https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md > > To upgrade, utter: > > pkg update -r package/pkg > pkg update -r --be-name=r151022i > > We are also hard at work to publish a new bloody release with all the > latest merges from the upstream illumos and joyent repos. A separate > announcement on this will follow. > > About OmniOS Community Edition Association > OmniOS Community Edition Association (OmniOSce) is a Swiss > association, dedicated to the continued support and release of OmniOS > for the benefit of all parties involved. The board of OmniOSce > controls access to the OmniOS CA. Current board members are: Tobias > Oetiker (President), Andy Fiddaman (Development), Dominik Hassler > (Treasurer). > > Press inquiries to info at omniosce.org > Published July 17, 2017 > > OmniOSce > Aarweg 17 > 4600 Olten > Switzerland > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Dirk Willems System Engineer +32 (0)3 443 12 38 Dirk.Willems at exitas.be Quality. Passion. Personality www.exitas.be | Veldkant 31 | 2550 Kontich Illumos OmniOS Installation and Configuration Implementation Specialist. Oracle Solaris 11 Installation and Configuration Certified Implementation Specialist. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SmallPhoenixLogotypeRGB.png Type: image/png Size: 4648 bytes Desc: not available URL: From danmcd at kebe.com Fri Jul 21 01:53:35 2017 From: danmcd at kebe.com (Dan McDonald) Date: Thu, 20 Jul 2017 21:53:35 -0400 Subject: [OmniOS-discuss] Using OmniOSce with other publishers? Message-ID: <20170721015335.GA2200@everywhere.local> I have an OmniOS r151022 box. (You may have heard me talk about it from time to time. :) ) Some of its zones use other publishers for some things. In particular, the omniti-ms and niksula.hut.fi publishers. Has anyone who's already made the jump done so and successfully continued to use software from those other publishers? I'm *guessing* yes, but I'd like confirmation if possible before I attempt a jump. Thanks, Dan From doug at will.to Fri Jul 21 02:40:08 2017 From: doug at will.to (Doug Hughes) Date: Thu, 20 Jul 2017 22:40:08 -0400 Subject: [OmniOS-discuss] Using OmniOSce with other publishers? In-Reply-To: <20170721015335.GA2200@everywhere.local> References: <20170721015335.GA2200@everywhere.local> Message-ID: <7050d900-2284-c9d0-0485-5aa029fcf74c@will.to> Not myself, yet, but I have the same setup, coincidentally or not, and would be interested in the answer as well. On 7/20/2017 9:53 PM, Dan McDonald wrote: > I have an OmniOS r151022 box. (You may have heard me talk about it from time > to time. :) ) Some of its zones use other publishers for some things. In > particular, the omniti-ms and niksula.hut.fi publishers. > > Has anyone who's already made the jump done so and successfully continued to > use software from those other publishers? I'm *guessing* yes, but I'd like > confirmation if possible before I attempt a jump. > > Thanks, > Dan > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at kebe.com Fri Jul 21 03:20:55 2017 From: danmcd at kebe.com (Dan McDonald) Date: Thu, 20 Jul 2017 23:20:55 -0400 Subject: [OmniOS-discuss] Using OmniOSce with other publishers? In-Reply-To: <20170721015335.GA2200@everywhere.local> References: <20170721015335.GA2200@everywhere.local> Message-ID: <0BB3B263-9827-4F12-ACD5-CBED666319F7@kebe.com> > On Jul 20, 2017, at 9:53 PM, Dan McDonald wrote: > > Has anyone who's already made the jump done so and successfully continued to > use software from those other publishers? I'm *guessing* yes, but I'd like > confirmation if possible before I attempt a jump. I created an alternate BE and updated it to the CE r151022 server and packages. Will boot into it after this thread finishes. Dan Sent from my iPhone (typos, autocorrect, and all) From jimklimov at cos.ru Fri Jul 21 08:22:51 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Fri, 21 Jul 2017 08:22:51 +0000 Subject: [OmniOS-discuss] Local zone regression in CE bloody Message-ID: Hi all, I have an OmniOS bloody box that was last running 151023. Yesterday I updated it to latest available original omnios from May 15 or so, and updated that BE to omniosce bloody. Between the two, zone shutdown stopped working for me (both ipkg and lx), with the ce variant claiming that "datalinks remain in zone after shutdown / unable to unconfigure network interfaces in zone / unable to destroy zone". When the zone boots it seems okay and usable, but when trying to halt it - becomes "down" and I can not change the state (no boot/mount/ready/... options succeed); killing its zoneadmd and wiping then/var/run/zones also does not help - only GZ reboot. Jim -- Typos courtesy of K-9 Mail on my Android From omnios at citrus-it.net Fri Jul 21 10:17:35 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Fri, 21 Jul 2017 10:17:35 +0000 (UTC) Subject: [OmniOS-discuss] Local zone regression in CE bloody In-Reply-To: References: Message-ID: On Fri, 21 Jul 2017, Jim Klimov wrote: ; Hi all, ; ; I have an OmniOS bloody box that was last running 151023. Yesterday I updated it to latest available original omnios from May 15 or so, and updated that BE to omniosce bloody. Between the two, zone shutdown stopped working for me (both ipkg and lx), with the ce variant claiming that "datalinks remain in zone after shutdown / unable to unconfigure network interfaces in zone / unable to destroy zone". ; ; When the zone boots it seems okay and usable, but when trying to halt it - becomes "down" and I can not change the state (no boot/mount/ready/... options succeed); killing its zoneadmd and wiping then/var/run/zones also does not help - only GZ reboot. Thanks Jim, confirmed here too. We are building a new bloody at the moment so will test with that and then work on a fix. I've opened an issue for this at https://github.com/omniosorg/illumos-omnios/issues/18 Regards, Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From paladinemishakal at gmail.com Fri Jul 21 14:10:12 2017 From: paladinemishakal at gmail.com (Lawrence Giam) Date: Fri, 21 Jul 2017 22:10:12 +0800 Subject: [OmniOS-discuss] AD krb5.keytab problem Message-ID: Hi All, I have just setup an OmniOS r151014 and join it to an AD, after that I keep seeing alot of this error: idmap[544]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unsupported key table format version number) I tried to follow this post http://solariscat.blogspot.my/2015/01/solaris-11-samba-zfs-configuration-with.html but I got an Aborted message. C:\temp>ktpass -princ host/mysan3.domain.internal at DOMAIN.INTERNAL -mapuser domain\serviceuser -crypto All -pass XXXXXXX -ptype KRB5_NT_PRINCIPAL -out mysan3.keytab Targeting domain controller: mydc01.domain.internal Using legacy password setting method Successfully mapped host/mysan3.domain.internal to serviceuser. Aborted. No mysan3.keytab file was generated. Any one got any idea how to solve this or is it ok to ignore? Thanks & Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From russhan at new-swankton.net Fri Jul 21 15:28:30 2017 From: russhan at new-swankton.net (russhan at new-swankton.net) Date: Fri, 21 Jul 2017 08:28:30 -0700 Subject: [OmniOS-discuss] AD krb5.keytab problem In-Reply-To: References: Message-ID: <2007540e16bd3878ba6a318a510ddad7@new-swankton.net> On 2017-07-21 07:10, Lawrence Giam wrote: > Hi All, > > I have just setup an OmniOS r151014 and join it to an AD, after that I > keep seeing alot of this error: > idmap[544]: GSSAPI Error: Unspecified GSS failure. Minor code may > provide more information (Unsupported key table format version number) > > I tried to follow this post > http://solariscat.blogspot.my/2015/01/solaris-11-samba-zfs-configuration-with.html > but I got an Aborted message. > > C:\temp>ktpass -princ host/mysan3.domain.internal at DOMAIN.INTERNAL > -mapuser domain\serviceuser -crypto All -pass XXXXXXX -ptype > KRB5_NT_PRINCIPAL -out mysan3.keytab > Targeting domain controller: mydc01.domain.internal > Using legacy password setting method > Successfully mapped host/mysan3.domain.internal to serviceuser. > Aborted. > > No mysan3.keytab file was generated. > > Any one got any idea how to solve this or is it ok to ignore? > > Thanks & Regards. I'm not sure but the "Using legacy password setting method" seems to indicate a SNAFU between how ktpass is processing the password and what AD is expecting. I don't know enough about Windows and AD to know where to even begin addressing that. However, I can chime in with what I do for my Solaris 11 systems at work: I create a machine account (ex. COMPUTERNAME) in AD. C:\temp> ktpass /princ host/computername.domain.tld at DOMAIN.TLD -mapuser DOMAIN\COMPUTERNAME$ +rndPass /crypto All /out computername.keytab I personally like having the systems show up in AD as machines instead of users. And with the +rndPass it's one less password I have to know and worry about. -Russ From ryan at zinascii.com Fri Jul 21 23:11:46 2017 From: ryan at zinascii.com (Ryan Zezeski) Date: Fri, 21 Jul 2017 19:11:46 -0400 Subject: [OmniOS-discuss] Local zone regression in CE bloody In-Reply-To: References: Message-ID: <1500678706.3706324.1048770064.5AB4DCDF@webmail.messagingengine.com> Hey everyone, I've been trying to reproduce this but can't seem to get my omniosce onto bloody. I see the following: root at midgar:~# pkg unset-publisher omnios Updating package cache 1/1 root at midgar:~# pkg set-publisher -P --set-property signature-policy=require-signatures -g https://pkg.omniosce.org/bloody/core/ omnios root at midgar:~# pkg update --be-name=bloody -rv pkg update: The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/locale/gu at 0.5.11,5.11-0.151023:20170718T063512Z. Should I change the signature-policy? -Ryan On Fri, Jul 21, 2017, at 06:17 AM, Andy Fiddaman wrote: > > > On Fri, 21 Jul 2017, Jim Klimov wrote: > > ; Hi all, > ; > ; I have an OmniOS bloody box that was last running 151023. Yesterday I > updated it to latest available original omnios from May 15 or so, and > updated that BE to omniosce bloody. Between the two, zone shutdown > stopped working for me (both ipkg and lx), with the ce variant claiming > that "datalinks remain in zone after shutdown / unable to unconfigure > network interfaces in zone / unable to destroy zone". > ; > ; When the zone boots it seems okay and usable, but when trying to halt > it - becomes "down" and I can not change the state (no > boot/mount/ready/... options succeed); killing its zoneadmd and wiping > then/var/run/zones also does not help - only GZ reboot. > > Thanks Jim, confirmed here too. > We are building a new bloody at the moment so will test with that and > then > work on a fix. I've opened an issue for this at > > https://github.com/omniosorg/illumos-omnios/issues/18 > > Regards, > > Andy > > -- > Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at kebe.com Sat Jul 22 00:54:05 2017 From: danmcd at kebe.com (Dan McDonald) Date: Fri, 21 Jul 2017 20:54:05 -0400 Subject: [OmniOS-discuss] Local zone regression in CE bloody In-Reply-To: <1500678706.3706324.1048770064.5AB4DCDF@webmail.messagingengine.com> References: <1500678706.3706324.1048770064.5AB4DCDF@webmail.messagingengine.com> Message-ID: In the past, bloody was never signed. Has CE changed that policy? Dan Sent from my iPhone (typos, autocorrect, and all) > On Jul 21, 2017, at 7:11 PM, Ryan Zezeski wrote: > > Hey everyone, > > I've been trying to reproduce this but can't seem to get my omniosce > onto bloody. I see the following: > > root at midgar:~# pkg unset-publisher omnios > Updating package cache 1/1 > root at midgar:~# pkg set-publisher -P --set-property > signature-policy=require-signatures -g > https://pkg.omniosce.org/bloody/core/ omnios > root at midgar:~# pkg update --be-name=bloody -rv > > pkg update: The policy for omnios requires signatures to be present but > no signature was found in > pkg://omnios/locale/gu at 0.5.11,5.11-0.151023:20170718T063512Z. > > Should I change the signature-policy? > > -Ryan > >> On Fri, Jul 21, 2017, at 06:17 AM, Andy Fiddaman wrote: >> >> >> On Fri, 21 Jul 2017, Jim Klimov wrote: >> >> ; Hi all, >> ; >> ; I have an OmniOS bloody box that was last running 151023. Yesterday I >> updated it to latest available original omnios from May 15 or so, and >> updated that BE to omniosce bloody. Between the two, zone shutdown >> stopped working for me (both ipkg and lx), with the ce variant claiming >> that "datalinks remain in zone after shutdown / unable to unconfigure >> network interfaces in zone / unable to destroy zone". >> ; >> ; When the zone boots it seems okay and usable, but when trying to halt >> it - becomes "down" and I can not change the state (no >> boot/mount/ready/... options succeed); killing its zoneadmd and wiping >> then/var/run/zones also does not help - only GZ reboot. >> >> Thanks Jim, confirmed here too. >> We are building a new bloody at the moment so will test with that and >> then >> work on a fix. I've opened an issue for this at >> >> https://github.com/omniosorg/illumos-omnios/issues/18 >> >> Regards, >> >> Andy >> >> -- >> Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk >> Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ >> Registered in England and Wales | Company number 4899123 >> >> _______________________________________________ >> 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 danmcd at kebe.com Sat Jul 22 00:55:48 2017 From: danmcd at kebe.com (Dan McDonald) Date: Fri, 21 Jul 2017 20:55:48 -0400 Subject: [OmniOS-discuss] Local zone regression in CE bloody In-Reply-To: <1500678706.3706324.1048770064.5AB4DCDF@webmail.messagingengine.com> References: <1500678706.3706324.1048770064.5AB4DCDF@webmail.messagingengine.com> Message-ID: <79C13C9E-55AA-4741-A92E-77EA02AE47EC@kebe.com> Oops, should've read more carefully. YES, bloody isn't signed. I often create an alternat BE First, mount it, then use "pkg -R" to keep the original stable BE safe. Dan Sent from my iPhone (typos, autocorrect, and all) > On Jul 21, 2017, at 7:11 PM, Ryan Zezeski wrote: > > Should I change the signature-policy? From ryan at zinascii.com Sat Jul 22 00:57:34 2017 From: ryan at zinascii.com (Ryan Zezeski) Date: Fri, 21 Jul 2017 20:57:34 -0400 Subject: [OmniOS-discuss] Local zone regression in CE bloody In-Reply-To: References: <1500678706.3706324.1048770064.5AB4DCDF@webmail.messagingengine.com> Message-ID: <1500685054.3723606.1048824976.1916DB06@webmail.messagingengine.com> I couldn't find any specific instructions for moving to bloody so I kind of made them up based on the previous omnios upgrade instructions. I went ahead and set the signature-policy to ignore and now I'm good. On Fri, Jul 21, 2017, at 08:54 PM, Dan McDonald wrote: > In the past, bloody was never signed. Has CE changed that policy? > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > > On Jul 21, 2017, at 7:11 PM, Ryan Zezeski wrote: > > > > Hey everyone, > > > > I've been trying to reproduce this but can't seem to get my omniosce > > onto bloody. I see the following: > > > > root at midgar:~# pkg unset-publisher omnios > > Updating package cache 1/1 > > root at midgar:~# pkg set-publisher -P --set-property > > signature-policy=require-signatures -g > > https://pkg.omniosce.org/bloody/core/ omnios > > root at midgar:~# pkg update --be-name=bloody -rv > > > > pkg update: The policy for omnios requires signatures to be present but > > no signature was found in > > pkg://omnios/locale/gu at 0.5.11,5.11-0.151023:20170718T063512Z. > > > > Should I change the signature-policy? > > > > -Ryan > > > >> On Fri, Jul 21, 2017, at 06:17 AM, Andy Fiddaman wrote: > >> > >> > >> On Fri, 21 Jul 2017, Jim Klimov wrote: > >> > >> ; Hi all, > >> ; > >> ; I have an OmniOS bloody box that was last running 151023. Yesterday I > >> updated it to latest available original omnios from May 15 or so, and > >> updated that BE to omniosce bloody. Between the two, zone shutdown > >> stopped working for me (both ipkg and lx), with the ce variant claiming > >> that "datalinks remain in zone after shutdown / unable to unconfigure > >> network interfaces in zone / unable to destroy zone". > >> ; > >> ; When the zone boots it seems okay and usable, but when trying to halt > >> it - becomes "down" and I can not change the state (no > >> boot/mount/ready/... options succeed); killing its zoneadmd and wiping > >> then/var/run/zones also does not help - only GZ reboot. > >> > >> Thanks Jim, confirmed here too. > >> We are building a new bloody at the moment so will test with that and > >> then > >> work on a fix. I've opened an issue for this at > >> > >> https://github.com/omniosorg/illumos-omnios/issues/18 > >> > >> Regards, > >> > >> Andy > >> > >> -- > >> Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk > >> Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > >> Registered in England and Wales | Company number 4899123 > >> > >> _______________________________________________ > >> 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 omnios at citrus-it.net Sat Jul 22 06:40:58 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Sat, 22 Jul 2017 06:40:58 +0000 (UTC) Subject: [OmniOS-discuss] Local zone regression in CE bloody In-Reply-To: <1500685054.3723606.1048824976.1916DB06@webmail.messagingengine.com> References: <1500678706.3706324.1048770064.5AB4DCDF@webmail.messagingengine.com> <1500685054.3723606.1048824976.1916DB06@webmail.messagingengine.com> Message-ID: On Fri, 21 Jul 2017, Ryan Zezeski wrote: ; I couldn't find any specific instructions for moving to bloody so I kind ; of made them up based on the previous omnios upgrade instructions. I ; went ahead and set the signature-policy to ignore and now I'm good. Sorry for the delay, timezone difference! Yes, Dan's right, we haven't changed the signing policy for bloody, it is not signed. Note that we have reverted this so if you want to install the broken version you will have to explicitly install pkg://omnios/SUNWcs at 0.5.11-0.151023:20170718T063046Z Some more analysis can be found in our issue at https://github.com/omniosorg/illumos-omnios/issues/18 and here's some more dtrace output with the broken version. bloody# ./dl.d dtrace: script './dl.d' matched 3 probes CPU ID FUNCTION:NAME 6 88316 dlmgmt_setzoneid:entry dlmgmtd`dlmgmt_setzoneid dlmgmtd`dlmgmt_handler+0x96 libc.so.1`__door_return+0x3d Zone ID: 0 New zone id: 0 6 88318 dlmgmt_setzoneid:return Old zone id: 1 Err: 17 Regards, Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From tobi at oetiker.ch Mon Jul 24 05:41:01 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 24 Jul 2017 07:41:01 +0200 (CEST) Subject: [OmniOS-discuss] ANNOUNCEMENT First OmniOSce Bloody Update Message-ID: <683173389.375638.1500874861992.JavaMail.zimbra@oetiker.ch> OmniOSce Bloody With the urgent security updates and bug fixes for r151022 out of the way we have spent the last week concentrating on getting bloody updated, including new ISO, USB and PXE images. In addition to bringing us up-to-date with the latest from illumos, we have also bumped many of the userland packages to their latest released versions. They?ve passed initial regression testing, but we could use your help in putting them through their paces a bit more, so if you have some spare cycles please grab the ISO and set up a bloody system for testing. Downloads can be found at https://downloads.omniosce.org/media/bloody/ We have also started enabling test suites for userland packages where one is available in the hope of catching more regressions early and automatically. This release also contains the first core bugfix in OmniOSce history. We got a report to our issue tracker that both lx and native zones were not shutting down properly. Andy quickly identified the likely culprit and backed out the offending commit and published an updated within hours. If you have not visited our website at http://www.omniosce.org/ lately, it looks much better now than a few days ago and it comes with much more content. We already integrated two contributions from Rich Murphey @rich-murphey (thank you). If you would also like to contribute, please send us your pull requests ... the source of the website btw is on https://github.com/omniosorg/omniosorg.github.com bloody update 20170721: uname -v shows omnios-master-fab442e53b Updated packages: iso-codes 3.74 -> 3.75 sqlite 3.3.18 -> 3.19.3 automake 1.15.0 -> 1.15.1 git 2.13.0 -> 2.13.3 mercurial 4.1.3 -> 4.2.2 vim 8.0.567 -> 8.0.586 expat 2.2.0 -> 2.2.2 nghttp2 1.21.1 -> 1.24.0 pcre 8.40 -> 8.41 openssl 1.0.2k -> 1.0.2l bind 9.10.4P8 -> 9.10.5P3 openssh 7.4p1 -> 7.5p1 sudo 1.8.7 -> 8.20.2 pipe-viewer 1.6.0 -> 1.6.6 dbus 1.11.12 -> 1.11.14 ipmitool 1.8.16 -> 1.8.18 pciutils 3.5.4 -> 3.5.5 screen 4.5.1 -> 4.6.1 tmux 2.3 -> 2.5 gnu-diffutils 3.5 -> 3.6 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 davide.poletto at gmail.com Mon Jul 24 13:56:40 2017 From: davide.poletto at gmail.com (Davide Poletto) Date: Mon, 24 Jul 2017 15:56:40 +0200 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH Message-ID: Hello all, I'm facing a strange issue on a pretty standard OmniOS r151014 LTS box fully updated (only Global Zone), following the "Upgrading to r151022" instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 required before any jump to OmniOS r151022 (my final target is OmniOS Community Edition r151022i) I found that I'm unable to switch to OpenSSH as per "Upgrading to OpenSSH from SunSSH" instructions on the same page: Preliminary checks: root at nas01:/root# uname -ar SunOS nas01 5.11 omnios-2fb9a48 i86pc i386 i86pc root at nas01:/root# zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / ipkg shared root at nas01:/root# pkg publisher PUBLISHER TYPE STATUS P LOCATION omnios origin online F http://pkg.omniti.com/omnios/r151014/ root at nas01:/root# pkg refresh --full root at nas01:/root# pkg update -nv No updates available for this image. root at nas01:/root# pkg list -v ca-bundle FMRI IFO pkg://omnios/web/ca-bundle at 5.11-0.151014:20170414T020006Z i-- root at nas01:/root# pkg publisher PUBLISHER TYPE STATUS P LOCATION omnios origin online F http://pkg.omniti.com/omnios/r151014/ To be sure I unset the "uulm.mawi" publisher the box had with: root at nas01:/root# /usr/bin/pkg unset-publisher uulm.mawi executing the suggested command: root at nas01:/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 fails with the message: pkg install: The following pattern(s) did not match any allowable packages. Try using a different matching pattern, or refreshing publisher information: pkg:/service/network/ssh-common Note that: root at nas01:/root# ssh -v Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x100020bf root at nas01:/root# pkg list ssh NAME (PUBLISHER) VERSION IFO network/ssh 0.5.11-0.151014 i-- service/network/ssh 0.5.11-0.151014 i-- Package search of "ssh-common" package provides no entry. Blindly I tried to omit the specific "ssh-common" package reject but the result is not conforting me (maybe I tried a command in a totally wrong way not understanding what the --reject options really mean): root at nas01:/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:/network/openssh pkg:/network/openssh-server Creating Plan (Solver setup): | pkg install: The installed package entire is not permissible. Reject: pkg://omnios/entire at 11,5.11-0.151014:20161027T172955Z Reason: All versions matching 'require-any' dependency pkg:/network/ssh/ssh-key at 0.5.11,5.11-0.151014 are rejected Reject: pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20150402T175220Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20150417T182416Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20150727T054652Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20150818T161037Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20150913T201552Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20150914T195001Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20150929T225330Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20151112T210044Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20160420T161546Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20160603T031106Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20161027T152421Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20161230T212428Z pkg://omnios/network/ssh/ssh-key at 0.5.11 ,5.11-0.151014:20170301T162855Z Reason: This version rejected by user request 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 What options I have at this point? Thanks for any help, Davide. -------------- next part -------------- An HTML attachment was scrubbed... URL: From omnios at citrus-it.net Mon Jul 24 14:06:18 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Mon, 24 Jul 2017 14:06:18 +0000 (UTC) Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: Message-ID: On Mon, 24 Jul 2017, Davide Poletto wrote: ; executing the suggested command: ; ; root at nas01:/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 ; ; fails with the message: ; ; pkg install: The following pattern(s) did not match any allowable ; packages. Try ; using a different matching pattern, or refreshing publisher information: ; ; pkg:/service/network/ssh-common The release notes for r151014 ( https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 ) say to run this command to achieve the switch and I remember doing this successfully when it first came out. /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server This assumes you are still on the r151014 publisher. Your second command was close but you should remove the --reject at well as the ssh-common component. Regards, Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From peter.tribble at gmail.com Mon Jul 24 14:21:33 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Mon, 24 Jul 2017 15:21:33 +0100 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: Message-ID: On Mon, Jul 24, 2017 at 2:56 PM, Davide Poletto wrote: > Hello all, > > I'm facing a strange issue on a pretty standard OmniOS r151014 LTS box > fully updated (only Global Zone), following the "Upgrading to r151022" > instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 > required before any jump to OmniOS r151022 (my final target is OmniOS > Community Edition r151022i) I found that I'm unable to switch to OpenSSH as > per "Upgrading to OpenSSH from SunSSH" instructions on the same page: > > executing the suggested command: > > root at nas01:/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 > > fails with the message: > > pkg install: The following pattern(s) did not match any allowable > packages. Try > using a different matching pattern, or refreshing publisher information: > > pkg:/service/network/ssh-common > The r151014 release notes https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 say /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server Blindly I tried to omit the specific "ssh-common" package reject > I think you were on the right track. > but the result is not conforting me (maybe I tried a command in a totally > wrong way not understanding what the --reject options really mean): > > root at nas01:/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:/network/openssh > pkg:/network/openssh-server > I think you have an extra --reject in there, so you've told it not to install openssh. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.poletto at gmail.com Mon Jul 24 14:56:14 2017 From: davide.poletto at gmail.com (Davide Poletto) Date: Mon, 24 Jul 2017 16:56:14 +0200 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: Message-ID: Gosh, totally my fault in not reading the right Release Note, yes the Publisher is still the r151014 (as reported)...that did the trick: root at nas01:/root# /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server Packages to remove: 3 Packages to install: 2 Services to change: 2 Create boot environment: No Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 5/5 35/35 2.1/2.1 509k/s PHASE ITEMS Removing old actions 73/73 Installing new actions 53/53 Updating modified actions 24/24 Updating package state database Done Updating package cache 3/3 Updating image state Done Creating fast lookup database Done Reading search index Done Updating search index 5/5 Thanks! On Mon, Jul 24, 2017 at 4:06 PM, Andy Fiddaman wrote: > > > On Mon, 24 Jul 2017, Davide Poletto wrote: > > ; executing the suggested command: > ; > ; root at nas01:/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 > ; > ; fails with the message: > ; > ; pkg install: The following pattern(s) did not match any allowable > ; packages. Try > ; using a different matching pattern, or refreshing publisher information: > ; > ; pkg:/service/network/ssh-common > > The release notes for r151014 > ( https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 ) > say to run this command to achieve the switch and I remember doing this > successfully when it first came out. > > /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject > pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh > pkg:/network/openssh pkg:/network/openssh-server > > This assumes you are still on the r151014 publisher. > > Your second command was close but you should remove the --reject at well as > the ssh-common component. > > Regards, > > Andy > > -- > Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.poletto at gmail.com Mon Jul 24 15:01:30 2017 From: davide.poletto at gmail.com (Davide Poletto) Date: Mon, 24 Jul 2017 17:01:30 +0200 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: Message-ID: Thanks Andy, thanks Peter. So now OpenSSH is installed: root at nas01:/root# pkg list | grep ssh network/openssh 7.4.1-0.151014 i-- network/openssh-server 7.4.1-0.151014 i-- root at nas01:/root# ssh -V OpenSSH_7.4p1, OpenSSL 1.0.2k 26 Jan 2017 Totally my fault in not following the right Release Notes (I thought I should have followed the destination version - r151022 - Release Notes instead the one from where the upgrade process has to start, r151014 in my case). Thanks again for pointing me on the right track. Best regards, Davide. On Mon, Jul 24, 2017 at 4:21 PM, Peter Tribble wrote: > > > On Mon, Jul 24, 2017 at 2:56 PM, Davide Poletto > wrote: > >> Hello all, >> >> I'm facing a strange issue on a pretty standard OmniOS r151014 LTS box >> fully updated (only Global Zone), following the "Upgrading to r151022" >> instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 >> required before any jump to OmniOS r151022 (my final target is OmniOS >> Community Edition r151022i) I found that I'm unable to switch to OpenSSH as >> per "Upgrading to OpenSSH from SunSSH" instructions on the same page: >> >> executing the suggested command: >> >> root at nas01:/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 >> >> fails with the message: >> >> pkg install: The following pattern(s) did not match any allowable >> packages. Try >> using a different matching pattern, or refreshing publisher information: >> >> pkg:/service/network/ssh-common >> > > The r151014 release notes > > https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 > > say > > /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject > pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh > pkg:/network/openssh pkg:/network/openssh-server > > Blindly I tried to omit the specific "ssh-common" package reject >> > > I think you were on the right track. > > >> but the result is not conforting me (maybe I tried a command in a totally >> wrong way not understanding what the --reject options really mean): >> >> root at nas01:/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:/network/openssh >> pkg:/network/openssh-server >> > > I think you have an extra --reject in there, so you've told it not to > install openssh. > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cks at cs.toronto.edu Tue Jul 25 20:59:58 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Tue, 25 Jul 2017 16:59:58 -0400 Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? Message-ID: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> The OmniOS CE release announcement here on the mailing list covered the broad plans for the (non-Bloody) release schedule: The intention is for new stable releases to continue to come out every 26 weeks. Interim, "weekly" updates to stable follow a fixed schedule denoted by letters, one per week. Weekly releases are made as needed, so there may not be a release each week. [...] My assumption is that normally, each regular stable release only receives updates until the next regular stable release comes out; when the next stable release comes out, you are expected to update to it and then start tracking the interim weekly updates to the new stable. This raises two closely related questions: First, is this understanding of updates to stable releases accurate? Second, if it is, are there any plans for a 'LTS' stable release with an extended period of at least security updates for that LTS release? Is this in fact the current r151022 release, which I've seen some CE messages describe as 'OmniOS r151022 LTS' (eg in the announcement of r151022i)? Thanks in advance, and my apologies if I've overlooked a discussion of this on the mailing list (or a mention of this on the OmniOS CE website). - cks From pasztor at sagv5.gyakg.u-szeged.hu Wed Jul 26 00:51:12 2017 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Wed, 26 Jul 2017 02:51:12 +0200 Subject: [OmniOS-discuss] omnios vs xen experiences Message-ID: <20170726005112.GA7360@linux.gyakg.u-szeged.hu> Hi, Recently I started to build a new home nas, and I thought it would be a good idea to use xen on the bare metal. On my previous nas (Microserver Gen7 with amd's NL54 cpu -> no kvm) I used virtualbox, to run VMs. My new motherboard is a supermicro with integrated intel cards supporting pci sr-iov and other fancy stuff. I looked around, and alpine linux (3.6.2) seemed a good choice for dom0 os: small, can run from ramdisk (os can be on a pendrive), etc. and they have a really fresh xen. That's where the problems started. Following old google hits and my old memories, I was able to install omnios in both pv and hvm mode into a vm. The only thing what didn't really worked: networking. igbevf and ixgbevf drivers seems missing from illumos. xnf driver just crashed. First I thought it's xnf's problem, so I tried older omnios, latest openindiana build, etc. if it worked somewhere, but it always crashed. Then I tried to find out which xen version brought in a change which broke illumos's xnf driver, so I tried alpine 2.6, 3.0 -> xnf worked. alpine 3.3 didn't even boot. (maybe didn't like supermicro's virtual cd emulation) alpine 3.4 with xen 4.6 -> fail alpine 3.2 with xen 4.5.1 -> still works. So something happened with xen's interface between 4.5.1 and 4.6 which makes illumos's xnf driver crashing. If I can get some mentorship from one of the omniosce developers, I'd be glad if I can fix the problem in illumos. Would someone help me on this? Now plan to put some local disk into the new nas (that's the only part, what I don't have yet :D) and setup a build environment. I saw, that there is a complete wiki article about that in the omniti wiki. It's not urgent for me to "upgrade" to the new nas. It's completely fine for me if it won't go into "production" for a couple of months. Btw.: I tried to directly assign a complete (not a vf) card, and that worked with the ixgbe driver perfectly. Another foggy part: https://wiki.xenproject.org/wiki/Storage_driver_domains Here the doc write it works with FreeBSD oob. It seems, it's also problematic with OmniOS. I tried that with the 3.6.2 alpine which has xen 4.8.1 Regards, Gyu From tobi at oetiker.ch Wed Jul 26 18:16:51 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 26 Jul 2017 20:16:51 +0200 (CEST) Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? In-Reply-To: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> References: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> Message-ID: <1949148196.444683.1501093011240.JavaMail.zimbra@oetiker.ch> Hi Chris, we have discussed this in the core team and found that no one of us has been using LTS until now and no one is planning to do so in the future ... What we intend, is to support the current and previous release with an emphasis on the current release going forward from r151022. That said, maybe someone will step up and take up the LTS mantel. The build process for r151022 is in better shape than ever, now that Andy and Dominik have lavished all that love on it. SO if this is of interest to you, we will be glad to hear your ideas and also help out if someone wants to step up. Let's discuss in https://gitter.im/omniosorg/Lobby cheers tobi ----- On Jul 25, 2017, at 11:59 PM, Chris Siebenmann cks at cs.toronto.edu wrote: > The OmniOS CE release announcement here on the mailing list covered > the broad plans for the (non-Bloody) release schedule: > > The intention is for new stable releases to continue to come > out every 26 weeks. Interim, "weekly" updates to stable follow a > fixed schedule denoted by letters, one per week. Weekly releases > are made as needed, so there may not be a release each week. [...] > > My assumption is that normally, each regular stable release only > receives updates until the next regular stable release comes out; when > the next stable release comes out, you are expected to update to it and > then start tracking the interim weekly updates to the new stable. This > raises two closely related questions: > > First, is this understanding of updates to stable releases accurate? > > Second, if it is, are there any plans for a 'LTS' stable release with > an extended period of at least security updates for that LTS release? > Is this in fact the current r151022 release, which I've seen some CE > messages describe as 'OmniOS r151022 LTS' (eg in the announcement of > r151022i)? > > Thanks in advance, and my apologies if I've overlooked a discussion > of this on the mailing list (or a mention of this on the OmniOS CE > website). > > - cks > _______________________________________________ > 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 From bfriesen at simple.dallas.tx.us Wed Jul 26 18:50:23 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 26 Jul 2017 13:50:23 -0500 (CDT) Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? In-Reply-To: <1949148196.444683.1501093011240.JavaMail.zimbra@oetiker.ch> References: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> <1949148196.444683.1501093011240.JavaMail.zimbra@oetiker.ch> Message-ID: On Wed, 26 Jul 2017, Tobias Oetiker wrote: > we have discussed this in the core team and found that no one of us has been > using LTS until now and no one is planning to do so in the future ... This would be a great way for a commercial outfit which offers paid support contracts to get involved. LTS releases are quite a lot of commitment and work but a commercial support company might be able to commit to doing this work. Alternatively, a different set of volunteers could focus on LTS. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From peter.tribble at gmail.com Wed Jul 26 19:27:28 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Wed, 26 Jul 2017 20:27:28 +0100 Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? In-Reply-To: References: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> <1949148196.444683.1501093011240.JavaMail.zimbra@oetiker.ch> Message-ID: On Wed, Jul 26, 2017 at 7:50 PM, Bob Friesenhahn < bfriesen at simple.dallas.tx.us> wrote: > On Wed, 26 Jul 2017, Tobias Oetiker wrote: > > we have discussed this in the core team and found that no one of us has >> been >> using LTS until now and no one is planning to do so in the future ... >> > A couple of points here: The first is that while the project is finding its feet, making decisions about what the detailed support model might look like in 6 months to 2 years time is somewhat premature. The second is that the support model doesn't have to be an exact mirror of the schedule that OmniTI put in place. There's no reason you couldn't adjust the cadence and level of releases. Now the current release (151022) is marked as LTS. So at least you're in a reasonably stable place right now and have options, with no need to commit to anythjing for a few months. Which does open the question: how many people need LTS? (And what does LTS mean for them - in terms of how long support would be needed, and what level of support/backports they expect.) Perhaps Chris could chip in here, but I know that with my $DAYJOB hat on the idea of dropping security updates for release X as soon as release Y comes out is a bit of a non-starter. > This would be a great way for a commercial outfit which offers paid > support contracts to get involved. LTS releases are quite a lot of > commitment and work but a commercial support company might be able to > commit to doing this work. > I think we've already concluded that doing this isn't a viable commercial proposition. > Alternatively, a different set of volunteers could focus on LTS. > Well quite - community projects tend to have their direction set by those actually doing the work. Doing LTS "properly" is a heck of a lot of work (and the amount of work increases rapidly over time as you diverge from mainstream). But I can imagine an LTS-lite extended support model with just crucial security fixes would be a lot easier (and might be what customers want anyway). -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Wed Jul 26 19:35:54 2017 From: tobi at oetiker.ch (Tobi Oetiker) Date: Wed, 26 Jul 2017 22:35:54 +0300 Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? In-Reply-To: References: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> <1949148196.444683.1501093011240.JavaMail.zimbra@oetiker.ch> Message-ID: <23FDF64A-5B1F-46BE-AC83-17BA30011B4D@oetiker.ch> > On 26 Jul 2017, at 22:27, Peter Tribble wrote: > [...] > but I know that with my $DAYJOB hat on the idea of > dropping security updates for release X as soon as release Y comes out > is a bit of a non-starter. our idea is to support X as well as X-1 so there would be half a year overlap. and I bet that if many people step up with checkbook or spare time and abilities in hand for LTS releases, that is certainly doable. cheers tobi From cks at cs.toronto.edu Wed Jul 26 19:46:37 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Wed, 26 Jul 2017 15:46:37 -0400 Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? In-Reply-To: peter.tribble's message of Wed, 26 Jul 2017 20:27:28 +0100. Message-ID: <20170726194637.43CDF5A12A9@apps1.cs.toronto.edu> > Which does open the question: how many people need LTS? (And what does > LTS mean for them - in terms of how long support would be needed, and > what level of support/backports they expect.) Perhaps Chris could chip > in here, but I know that with my $DAYJOB hat on the idea of dropping > security updates for release X as soon as release Y comes out is a bit > of a non-starter. We care almost entirely about security updates. It would be nice to get updates for data-loss or panic-your-system problems as well, but it's not as essential as we very much hope not to hit one once we have qualified a production environment, and some of them will make applying updates more dangerous (since you're talking about more changes and changes to things like the kernel). We need this for at least two years per release, ideally with six months or so overlap of security updates between LTS releases. We need such a long support period (and the overlap) because in our environment, qualifying and rolling out a new release is not something that we can do easily, rapidly, or very often. OmniOS sits at the center of our fileserver infrastructure, which sits at the center of our entire environment; if a fileserver has problems, *everything* has problems (and then a bunch of professors and graduate students get angry at us, which has various bad consequences for everyone). (This also applies to some updates within a single release, especially kernel updates. An updated kernel is not too far off from a new release unless it only has very narrow and very specific fixes that we can be highly confident in.) A few months ago (when the initial OmniOS news broke) I wrote more about our needs here: https://utcc.utoronto.ca/~cks/space/blog/solaris/IllumosDistributionNeeds Background on our fileserver environment is here: https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSFileserverSetupII - cks From omnios at citrus-it.net Wed Jul 26 19:48:18 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Wed, 26 Jul 2017 19:48:18 +0000 (UTC) Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? In-Reply-To: References: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> <1949148196.444683.1501093011240.JavaMail.zimbra@oetiker.ch> Message-ID: On Wed, 26 Jul 2017, Peter Tribble wrote: ; Now the current release (151022) is marked as LTS. So at least you're in ; a reasonably stable place right now and have options, with no need to ; commit to anythjing for a few months. Just to be clear, r151022 was marked as LTS by OmniTI. Those three letters did make it into one of our announcements (the second one I think) but we are not currently considering r151022 to be an LTS release. r151024 is currently pencilled in for late November (6 months after the release of r151022) and once it arrives, r22 will continue to be supported for 6 months, until r26 lands. We would encourage people to move to r24 during that time rather than waiting until r22 stops being supported. As Tobi has said, we're open to discussion and interested in people's views https://gitter.im/omniosorg/Lobby Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From bfriesen at simple.dallas.tx.us Wed Jul 26 20:18:56 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 26 Jul 2017 15:18:56 -0500 (CDT) Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? In-Reply-To: References: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> <1949148196.444683.1501093011240.JavaMail.zimbra@oetiker.ch> Message-ID: On Wed, 26 Jul 2017, Peter Tribble wrote: > On Wed, Jul 26, 2017 at 7:50 PM, Bob Friesenhahn < > bfriesen at simple.dallas.tx.us> wrote: >> This would be a great way for a commercial outfit which offers paid >> support contracts to get involved. LTS releases are quite a lot of >> commitment and work but a commercial support company might be able to >> commit to doing this work. > > I think we've already concluded that doing this isn't a viable commercial > proposition. I think that being a viable commercial proposition depends on the cost structure and customer expectations. OmniTI has a high cost model with presumably highly-compensated individuals living in presumably high cost of living areas. A small company in Slovakia could likely accomplish what a company in the San Francisco bay area could not. 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 Wed Jul 26 20:37:13 2017 From: mir at miras.org (Michael Rasmussen) Date: Wed, 26 Jul 2017 22:37:13 +0200 Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? In-Reply-To: References: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> <1949148196.444683.1501093011240.JavaMail.zimbra@oetiker.ch> Message-ID: <20170726223713.4ccb42c5@sleipner.datanom.net> On Wed, 26 Jul 2017 20:27:28 +0100 Peter Tribble wrote: > > Which does open the question: how many people need LTS? (And what > does LTS mean for them - in terms of how long support would be needed, > and what level of support/backports they expect.) Perhaps Chris could > chip in here, but I know that with my $DAYJOB hat on the idea of > dropping security updates for release X as soon as release Y comes out > is a bit of a non-starter. > The reason I highly favor LTS releases are as follows: 1) Omnios(ce) is used as storage server for a virtualized environment. 2) Omnios(ce) does not have a cluster solution within reach of my pocket book. 3) Every kernel upgrade means every VM except for infrastructure VM's which run on other hardware faces downtime which means disruption of service. 4) Because of this I want to minimize kernel upgrades. 5) An Omnios(ce) upgrade always includes a kernel upgrade. I guess the above reasons apply to many data center installations an especially data center installations for virtualized environments. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: No matter how much you do you never do enough. -------------- 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 Wed Jul 26 20:47:27 2017 From: mir at miras.org (Michael Rasmussen) Date: Wed, 26 Jul 2017 22:47:27 +0200 Subject: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release? In-Reply-To: References: <20170725205958.5E54E5A03A8@apps1.cs.toronto.edu> <1949148196.444683.1501093011240.JavaMail.zimbra@oetiker.ch> Message-ID: <20170726224727.1c7bd929@sleipner.datanom.net> On Wed, 26 Jul 2017 20:27:28 +0100 Peter Tribble wrote: > > Which does open the question: how many people need LTS? (And what > does LTS mean for them - in terms of how long support would be needed, > and what level of support/backports they expect.) Perhaps Chris could > chip in here, but I know that with my $DAYJOB hat on the idea of > dropping security updates for release X as soon as release Y comes out > is a bit of a non-starter. > I forgot one other important reason: 6) Hardware is acquired only if it is 100% supported by LTS release and a 3 years support period nicely fits the expected lifetime for hardware. -- 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 al.slater at scluk.com Thu Jul 27 11:17:15 2017 From: al.slater at scluk.com (Al Slater) Date: Thu, 27 Jul 2017 12:17:15 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS Message-ID: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> Hi, I wish to run up a number of OmniOS instances in AWS. The current OmniOS AMIs in AWS seem to use pv virtualization, precluding their use on the t2 and m4 instance types that I want to use. So, I thought I would try to produce my own AMI with hvm virtualization. I am looking to use omniosce r151022, is this likely to work at all? I have read https://omnios.omniti.com/wiki.php/Ec2Ami, does anyone know how that procedure would be amended to cater for loader/hvm instead of pv-grub? -- Al Slater From grzempek at gmail.com Thu Jul 27 20:14:04 2017 From: grzempek at gmail.com (Krzysztof Grzempa) Date: Thu, 27 Jul 2017 22:14:04 +0200 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: Message-ID: Guys, I will grab this thread as it is somehow similiar. I want to upgrade from r151014 to r151022. I went throught all steps of: https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 but when Im performing upgrade: # /usr/bin/pkg update --be-name r151022 i got: root at mojvps:/root# /usr/bin/pkg update --be-name r151022 Creating Plan (Running solver): | pkg update: No solution was found to satisfy constraints Plan Creation: Package solver has not found a solution to update to latest available versions. This may indicate an overly constrained set of packages are installed. latest incorporations: pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z pkg://omnios/incorporation/jeos/illumos-gate at 11 ,5.11-0.151022:20170510T210757Z pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11 ,5.11-0.151022:20170510T212740Z pkg://omnios/incorporation/jeos/omnios-userland at 11 ,5.11-0.151022:20170511T001737Z Dependency analysis is unable to determine exact cause. Try specifying expected results to obtain more detailed error messages. I set publisher correctly IHMO: root at mojvps:/root# pkg publisher PUBLISHER TYPE STATUS P LOCATION omnios origin online F https://pkg.omniti.com/omnios/r151022/ Any ideas ? I want to upgrade to CE after that. Thanks in advance Kris 2017-07-24 17:01 GMT+02:00 Davide Poletto : > Thanks Andy, thanks Peter. > > So now OpenSSH is installed: > > root at nas01:/root# pkg list | grep ssh > network/openssh > 7.4.1-0.151014 i-- > network/openssh-server > 7.4.1-0.151014 i-- > root at nas01:/root# ssh -V > OpenSSH_7.4p1, OpenSSL 1.0.2k 26 Jan 2017 > > Totally my fault in not following the right Release Notes (I thought I > should have followed the destination version - r151022 - Release Notes > instead the one from where the upgrade process has to start, r151014 in my > case). > > Thanks again for pointing me on the right track. > > Best regards, Davide. > > On Mon, Jul 24, 2017 at 4:21 PM, Peter Tribble > wrote: > >> >> >> On Mon, Jul 24, 2017 at 2:56 PM, Davide Poletto > > wrote: >> >>> Hello all, >>> >>> I'm facing a strange issue on a pretty standard OmniOS r151014 LTS box >>> fully updated (only Global Zone), following the "Upgrading to r151022" >>> instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 >>> required before any jump to OmniOS r151022 (my final target is OmniOS >>> Community Edition r151022i) I found that I'm unable to switch to OpenSSH as >>> per "Upgrading to OpenSSH from SunSSH" instructions on the same page: >>> >>> executing the suggested command: >>> >>> root at nas01:/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 >>> >>> fails with the message: >>> >>> pkg install: The following pattern(s) did not match any allowable >>> packages. Try >>> using a different matching pattern, or refreshing publisher information: >>> >>> pkg:/service/network/ssh-common >>> >> >> The r151014 release notes >> >> https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 >> >> say >> >> /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject >> pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh >> pkg:/network/openssh pkg:/network/openssh-server >> >> Blindly I tried to omit the specific "ssh-common" package reject >>> >> >> I think you were on the right track. >> >> >>> but the result is not conforting me (maybe I tried a command in a >>> totally wrong way not understanding what the --reject options really mean): >>> >>> root at nas01:/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:/network/openssh >>> pkg:/network/openssh-server >>> >> >> I think you have an extra --reject in there, so you've told it not to >> install openssh. >> >> -- >> -Peter Tribble >> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ >> > > > _______________________________________________ > 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 kebe.com Thu Jul 27 20:28:04 2017 From: danmcd at kebe.com (Dan McDonald) Date: Thu, 27 Jul 2017 16:28:04 -0400 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: Message-ID: <2E9975D3-0B47-469F-928B-0FE7D1D6AA5C@kebe.com> You're sure you're on the very latest 014? Could be lack of updated certificates... Dan Sent from my iPhone (typos, autocorrect, and all) > On Jul 27, 2017, at 4:14 PM, Krzysztof Grzempa wrote: > > Guys, > I will grab this thread as it is somehow similiar. I want to upgrade from r151014 to r151022. I went throught all steps of: > https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 > but when Im performing upgrade: > > # /usr/bin/pkg update --be-name r151022 > > i got: > > root at mojvps:/root# /usr/bin/pkg update --be-name r151022 > Creating Plan (Running solver): | > pkg update: No solution was found to satisfy constraints > Plan Creation: Package solver has not found a solution to update to latest available versions. > This may indicate an overly constrained set of packages are installed. > > latest incorporations: > > pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z > pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z > pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z > pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151022:20170511T001737Z > Dependency analysis is unable to determine exact cause. > Try specifying expected results to obtain more detailed error messages. > > > I set publisher correctly IHMO: > > root at mojvps:/root# pkg publisher > PUBLISHER TYPE STATUS P LOCATION > omnios origin online F https://pkg.omniti.com/omnios/r151022/ > > > Any ideas ? > > I want to upgrade to CE after that. > > Thanks in advance > Kris > > 2017-07-24 17:01 GMT+02:00 Davide Poletto : >> Thanks Andy, thanks Peter. >> >> So now OpenSSH is installed: >> >> root at nas01:/root# pkg list | grep ssh >> network/openssh 7.4.1-0.151014 i-- >> network/openssh-server 7.4.1-0.151014 i-- >> root at nas01:/root# ssh -V >> OpenSSH_7.4p1, OpenSSL 1.0.2k 26 Jan 2017 >> >> Totally my fault in not following the right Release Notes (I thought I should have followed the destination version - r151022 - Release Notes instead the one from where the upgrade process has to start, r151014 in my case). >> >> Thanks again for pointing me on the right track. >> >> Best regards, Davide. >> >>> On Mon, Jul 24, 2017 at 4:21 PM, Peter Tribble wrote: >>> >>> >>>> On Mon, Jul 24, 2017 at 2:56 PM, Davide Poletto wrote: >>>> Hello all, >>>> >>>> I'm facing a strange issue on a pretty standard OmniOS r151014 LTS box fully updated (only Global Zone), following the "Upgrading to r151022" instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 required before any jump to OmniOS r151022 (my final target is OmniOS Community Edition r151022i) I found that I'm unable to switch to OpenSSH as per "Upgrading to OpenSSH from SunSSH" instructions on the same page: >>>> >>>> executing the suggested command: >>>> >>>> root at nas01:/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 >>>> >>>> fails with the message: >>>> >>>> pkg install: The following pattern(s) did not match any allowable packages. Try >>>> using a different matching pattern, or refreshing publisher information: >>>> >>>> pkg:/service/network/ssh-common >>> >>> The r151014 release notes >>> >>> https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 >>> >>> say >>> >>> /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server >>> >>>> Blindly I tried to omit the specific "ssh-common" package reject >>> >>> I think you were on the right track. >>> >>>> but the result is not conforting me (maybe I tried a command in a totally wrong way not understanding what the --reject options really mean): >>>> >>>> root at nas01:/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:/network/openssh pkg:/network/openssh-server >>> >>> I think you have an extra --reject in there, so you've told it not to >>> install openssh. >>> >>> -- >>> -Peter Tribble >>> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ >> >> >> _______________________________________________ >> 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 pasztor at sagv5.gyakg.u-szeged.hu Thu Jul 27 21:47:12 2017 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Thu, 27 Jul 2017 23:47:12 +0200 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> Message-ID: <20170727214712.GB32230@linux.gyakg.u-szeged.hu> Hi, "Al Slater" ?rta 2017-07-27 12:17-kor: > So, I thought I would try to produce my own AMI with hvm virtualization. > > I am looking to use omniosce r151022, is this likely to work at all? I haven't tryed to upgrade my r151022 with the ce updates, but I'm pretty sure that it must work. > I have read https://omnios.omniti.com/wiki.php/Ec2Ami, does anyone know > how that procedure would be amended to cater for loader/hvm instead of > pv-grub? If you use hvm, then there is no need for an extra loader. Just install omnios, as you would onto the "virtual" hdd. However, I never tried amazon's env. I experimenting with omnios on my home nas. (See my mail two days ago) The only drawback what I found: if the xen hypervisor is >=4.6 (or >4.5.1 I don't know yet), then the pv network driver won't work. Cheers, Gyu From grzempek at gmail.com Fri Jul 28 08:50:28 2017 From: grzempek at gmail.com (Krzysztof Grzempa) Date: Fri, 28 Jul 2017 10:50:28 +0200 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: <9932A3BD-813B-42AA-8A02-98E896A1328D@kebe.com> References: <2E9975D3-0B47-469F-928B-0FE7D1D6AA5C@kebe.com> <9932A3BD-813B-42AA-8A02-98E896A1328D@kebe.com> Message-ID: HI, So, any other ideas ? I would like to avoid plain new installation scenario :) Regards, Kris 2017-07-28 1:29 GMT+02:00 Dan McDonald : > Yeah that's right. Sorry -- had to ask. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Jul 27, 2017, at 4:36 PM, Krzysztof Grzempa wrote: > > Hi Dan, > I had done prerequsities before i started: > > root at mojvps:/root# pkg list -v ca-bundle > FMRI > IFO > pkg://omnios/web/ca-bundle at 5.11-0.151014:20170414T020006Z > i-- > > there is 'April' certificates..right ? > > Kris > > 2017-07-27 22:28 GMT+02:00 Dan McDonald : > >> You're sure you're on the very latest 014? Could be lack of updated >> certificates... >> >> Dan >> >> Sent from my iPhone (typos, autocorrect, and all) >> >> On Jul 27, 2017, at 4:14 PM, Krzysztof Grzempa >> wrote: >> >> Guys, >> I will grab this thread as it is somehow similiar. I want to upgrade from >> r151014 to r151022. I went throught all steps of: >> https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 >> but when Im performing upgrade: >> >> # /usr/bin/pkg update --be-name r151022 >> >> i got: >> >> root at mojvps:/root# /usr/bin/pkg update --be-name r151022 >> Creating Plan (Running solver): | >> pkg update: No solution was found to satisfy constraints >> Plan Creation: Package solver has not found a solution to update to >> latest available versions. >> This may indicate an overly constrained set of packages are installed. >> >> latest incorporations: >> >> pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z >> pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.15102 >> 2:20170510T210757Z >> pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11, >> 5.11-0.151022:20170510T212740Z >> pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0. >> 151022:20170511T001737Z >> Dependency analysis is unable to determine exact cause. >> Try specifying expected results to obtain more detailed error messages. >> >> >> I set publisher correctly IHMO: >> >> root at mojvps:/root# pkg publisher >> PUBLISHER TYPE STATUS P LOCATION >> omnios origin online F >> https://pkg.omniti.com/omnios/r151022/ >> >> >> Any ideas ? >> >> I want to upgrade to CE after that. >> >> Thanks in advance >> Kris >> >> 2017-07-24 17:01 GMT+02:00 Davide Poletto : >> >>> Thanks Andy, thanks Peter. >>> >>> So now OpenSSH is installed: >>> >>> root at nas01:/root# pkg list | grep ssh >>> network/openssh >>> 7.4.1-0.151014 i-- >>> network/openssh-server >>> 7.4.1-0.151014 i-- >>> root at nas01:/root# ssh -V >>> OpenSSH_7.4p1, OpenSSL 1.0.2k 26 Jan 2017 >>> >>> Totally my fault in not following the right Release Notes (I thought I >>> should have followed the destination version - r151022 - Release Notes >>> instead the one from where the upgrade process has to start, r151014 in my >>> case). >>> >>> Thanks again for pointing me on the right track. >>> >>> Best regards, Davide. >>> >>> On Mon, Jul 24, 2017 at 4:21 PM, Peter Tribble >>> wrote: >>> >>>> >>>> >>>> On Mon, Jul 24, 2017 at 2:56 PM, Davide Poletto < >>>> davide.poletto at gmail.com> wrote: >>>> >>>>> Hello all, >>>>> >>>>> I'm facing a strange issue on a pretty standard OmniOS r151014 LTS box >>>>> fully updated (only Global Zone), following the "Upgrading to r151022" >>>>> instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 >>>>> required before any jump to OmniOS r151022 (my final target is OmniOS >>>>> Community Edition r151022i) I found that I'm unable to switch to OpenSSH as >>>>> per "Upgrading to OpenSSH from SunSSH" instructions on the same page: >>>>> >>>>> executing the suggested command: >>>>> >>>>> root at nas01:/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 >>>>> >>>>> fails with the message: >>>>> >>>>> pkg install: The following pattern(s) did not match any allowable >>>>> packages. Try >>>>> using a different matching pattern, or refreshing publisher >>>>> information: >>>>> >>>>> pkg:/service/network/ssh-common >>>>> >>>> >>>> The r151014 release notes >>>> >>>> https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 >>>> >>>> say >>>> >>>> /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject >>>> pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh >>>> pkg:/network/openssh pkg:/network/openssh-server >>>> >>>> Blindly I tried to omit the specific "ssh-common" package reject >>>>> >>>> >>>> I think you were on the right track. >>>> >>>> >>>>> but the result is not conforting me (maybe I tried a command in a >>>>> totally wrong way not understanding what the --reject options really mean): >>>>> >>>>> root at nas01:/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:/network/openssh >>>>> pkg:/network/openssh-server >>>>> >>>> >>>> I think you have an extra --reject in there, so you've told it not to >>>> install openssh. >>>> >>>> -- >>>> -Peter Tribble >>>> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ >>>> >>> >>> >>> _______________________________________________ >>> 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 peter.tribble at gmail.com Fri Jul 28 21:37:40 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Fri, 28 Jul 2017 22:37:40 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> Message-ID: > > I wish to run up a number of OmniOS instances in AWS. > > The current OmniOS AMIs in AWS seem to use pv virtualization, precluding > their use on the t2 and m4 instance types that I want to use. > Worse; newer regions only support hvm. In my case, this rules out London. > So, I thought I would try to produce my own AMI with hvm virtualization. > > I am looking to use omniosce r151022, is this likely to work at all? > > I have read https://omnios.omniti.com/wiki.php/Ec2Ami, does anyone know > how that procedure would be amended to cater for loader/hvm instead of > pv-grub? > The following should get you going: https://www.prakashsurya.com/post/2017-02-06-creating-a-custom-amazon-ec2-ami-from-iso/ Essentially, if you install any illumos distro you can send the disk image up to AWS and create an AMI. If you create the image by installing using Xen *exactly* as described, you're done. If you're getting the image from somewhere else then the phys_path to the disk embedded in the pool will be wrong and need to be rewritten, which basically means going into Xen again. (I don't have Xen, so I'm currently at the stage where my hvm AMI panics on boot because the pool has got the wrong labels. That's for Tribblix, but the procedure is identical for any illumos distro. You have a similar issue if you try and convert the pv AMI to hvm; it panics because the hardware has changed underneath. I'm close, but not there yet.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bauernfeind at ipk-gatersleben.de Fri Jul 28 22:28:42 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Fri, 28 Jul 2017 22:28:42 +0000 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: <2E9975D3-0B47-469F-928B-0FE7D1D6AA5C@kebe.com> <9932A3BD-813B-42AA-8A02-98E896A1328D@kebe.com>, Message-ID: Hi, what happens when you just try to update entire? pkg update -nv entire or pkg install -nv entire Best Regards, Jens ________________________________________ From: OmniOS-discuss [omnios-discuss-bounces at lists.omniti.com] on behalf of Krzysztof Grzempa [grzempek at gmail.com] Sent: Friday, July 28, 2017 10:50 To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH HI, So, any other ideas ? I would like to avoid plain new installation scenario :) Regards, Kris 2017-07-28 1:29 GMT+02:00 Dan McDonald >: Yeah that's right. Sorry -- had to ask. Dan Sent from my iPhone (typos, autocorrect, and all) On Jul 27, 2017, at 4:36 PM, Krzysztof Grzempa > wrote: Hi Dan, I had done prerequsities before i started: root at mojvps:/root# pkg list -v ca-bundle FMRI IFO pkg://omnios/web/ca-bundle at 5.11-0.151014:20170414T020006Z i-- there is 'April' certificates..right ? Kris 2017-07-27 22:28 GMT+02:00 Dan McDonald >: You're sure you're on the very latest 014? Could be lack of updated certificates... Dan Sent from my iPhone (typos, autocorrect, and all) On Jul 27, 2017, at 4:14 PM, Krzysztof Grzempa > wrote: Guys, I will grab this thread as it is somehow similiar. I want to upgrade from r151014 to r151022. I went throught all steps of: https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 but when Im performing upgrade: # /usr/bin/pkg update --be-name r151022 i got: root at mojvps:/root# /usr/bin/pkg update --be-name r151022 Creating Plan (Running solver): | pkg update: No solution was found to satisfy constraints Plan Creation: Package solver has not found a solution to update to latest available versions. This may indicate an overly constrained set of packages are installed. latest incorporations: pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151022:20170511T001737Z Dependency analysis is unable to determine exact cause. Try specifying expected results to obtain more detailed error messages. I set publisher correctly IHMO: root at mojvps:/root# pkg publisher PUBLISHER TYPE STATUS P LOCATION omnios origin online F https://pkg.omniti.com/omnios/r151022/ Any ideas ? I want to upgrade to CE after that. Thanks in advance Kris 2017-07-24 17:01 GMT+02:00 Davide Poletto >: Thanks Andy, thanks Peter. So now OpenSSH is installed: root at nas01:/root# pkg list | grep ssh network/openssh 7.4.1-0.151014 i-- network/openssh-server 7.4.1-0.151014 i-- root at nas01:/root# ssh -V OpenSSH_7.4p1, OpenSSL 1.0.2k 26 Jan 2017 Totally my fault in not following the right Release Notes (I thought I should have followed the destination version - r151022 - Release Notes instead the one from where the upgrade process has to start, r151014 in my case). Thanks again for pointing me on the right track. Best regards, Davide. On Mon, Jul 24, 2017 at 4:21 PM, Peter Tribble > wrote: On Mon, Jul 24, 2017 at 2:56 PM, Davide Poletto > wrote: Hello all, I'm facing a strange issue on a pretty standard OmniOS r151014 LTS box fully updated (only Global Zone), following the "Upgrading to r151022" instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 required before any jump to OmniOS r151022 (my final target is OmniOS Community Edition r151022i) I found that I'm unable to switch to OpenSSH as per "Upgrading to OpenSSH from SunSSH" instructions on the same page: executing the suggested command: root at nas01:/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 fails with the message: pkg install: The following pattern(s) did not match any allowable packages. Try using a different matching pattern, or refreshing publisher information: pkg:/service/network/ssh-common The r151014 release notes https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 say /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server Blindly I tried to omit the specific "ssh-common" package reject I think you were on the right track. but the result is not conforting me (maybe I tried a command in a totally wrong way not understanding what the --reject options really mean): root at nas01:/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:/network/openssh pkg:/network/openssh-server I think you have an extra --reject in there, so you've told it not to install openssh. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ 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 al.slater at scluk.com Sat Jul 29 08:42:35 2017 From: al.slater at scluk.com (Al Slater) Date: Sat, 29 Jul 2017 09:42:35 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: <20170727214712.GB32230@linux.gyakg.u-szeged.hu> References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> <20170727214712.GB32230@linux.gyakg.u-szeged.hu> Message-ID: <91096055-fa61-ce7d-6365-cb38d2c63641@scluk.com> Thank you, that clarified my understanding. Al On 27/07/17 22:47, P?SZTOR Gy?rgy wrote: > Hi, > > "Al Slater" ?rta 2017-07-27 12:17-kor: >> So, I thought I would try to produce my own AMI with hvm virtualization. >> >> I am looking to use omniosce r151022, is this likely to work at all? > > I haven't tryed to upgrade my r151022 with the ce updates, but I'm pretty > sure that it must work. > >> I have read https://omnios.omniti.com/wiki.php/Ec2Ami, does anyone know >> how that procedure would be amended to cater for loader/hvm instead of >> pv-grub? > > If you use hvm, then there is no need for an extra loader. Just install > omnios, as you would onto the "virtual" hdd. > However, I never tried amazon's env. I experimenting with omnios on my home > nas. (See my mail two days ago) > > The only drawback what I found: if the xen hypervisor is >=4.6 (or >4.5.1 I > don't know yet), then the pv network driver won't work. > > Cheers, > Gyu > -- Al Slater Technical Director SCL Phone : +44 (0)1273 666607 Fax : +44 (0)1273 666601 email : al.slater at scluk.com Stanton Consultancy Ltd Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU From al.slater at scluk.com Sat Jul 29 08:53:57 2017 From: al.slater at scluk.com (Al Slater) Date: Sat, 29 Jul 2017 09:53:57 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> Message-ID: Hi Peter, On 28/07/17 22:37, Peter Tribble wrote: > I wish to run up a number of OmniOS instances in AWS. > > The current OmniOS AMIs in AWS seem to use pv virtualization, precluding > their use on the t2 and m4 instance types that I want to use. > > > Worse; newer regions only support hvm. In my case, this rules out London. That is precisely where I want to run my instances. > So, I thought I would try to produce my own AMI with hvm virtualization. > > I am looking to use omniosce r151022, is this likely to work at all? > > I have read https://omnios.omniti.com/wiki.php/Ec2Ami > , does anyone know > how that procedure would be amended to cater for loader/hvm instead of > pv-grub? > > > The following should get you going: > > https://www.prakashsurya.com/post/2017-02-06-creating-a-custom-amazon-ec2-ami-from-iso/ That looks very helpful, thank you for the link. > Essentially, if you install any illumos distro you can send the disk > image up > to AWS and create an AMI. If you create the image by installing using Xen > *exactly* as described, you're done. If you're getting the image from > somewhere > else then the phys_path to the disk embedded in the pool will be wrong > and need > to be rewritten, which basically means going into Xen again. I will be using xen so hopefully all will be good... -- Al Slater From daniil.landau at gmail.com Sat Jul 29 10:47:40 2017 From: daniil.landau at gmail.com (=?utf-8?B?0JTQsNC90LjQuNC7INCb0LDQvdC00LDRgw==?=) Date: Sat, 29 Jul 2017 13:47:40 +0300 Subject: [OmniOS-discuss] Problem with upgrade from r151014 to r151022 Message-ID: <02314418-5ED8-4101-803B-527E5BC9CB3F@gmail.com> Hello! I?m trying to upgrade my small home server with 3 lipkg zones from r151014 to r151022. I?ve moved from SunSSH to OpenSSH (in global and all lipkg zones): # pkg list |grep ssh network/openssh 7.4.1-0.151014 i-- network/openssh-server 7.4.1-0.151014 i-- Also I changed publisher to r151022 (in global and lipkg zones also): # pkg publisher PUBLISHER TYPE STATUS P LOCATION omnios origin online F https://pkg.omniti.com/omnios/r151022/ ms.omniti.com origin online F http://pkg.omniti.com/omniti-ms/ But when I run "pkg update" from global zone or from a lipkg zone I get errors (please see at the end of the message). It looks very strange for me. Did I missed something in upgrade plan or, may be, there are some other issues? Thank you for help! Daniil Creating Plan (Running solver): | pkg update: No solution was found to satisfy constraints Plan Creation: Package solver has not found a solution to update to latest available versions. This may indicate an overly constrained set of packages are installed. latest incorporations: pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151022:20170511T001737Z The following indicates why the system cannot update to the latest version: No suitable version of required package pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z found: Reject: pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z Reason: A version for 'incorporate' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z found: Reject: pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z Reason: A version for 'incorporate' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z found: Reject: pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/shell/zsh at 5.3.1,5.11-0.151022:20170510T233501Z found: Reject: pkg://omnios/shell/zsh at 5.3.1,5.11-0.151022:20170510T233501Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/management/snmp/net-snmp at 5.7.3,5.11-0.151022:20170511T003113Z found: Reject: pkg://omnios/system/management/snmp/net-snmp at 5.7.3,5.11-0.151022:20170511T003113Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/security/sudo at 1.8.7,5.11-0.151022:20170511T001935Z found: Reject: pkg://omnios/security/sudo at 1.8.7,5.11-0.151022:20170511T001935Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/libxslt at 1.1.29,5.11-0.151022:20170511T003321Z found: Reject: pkg://omnios/library/libxslt at 1.1.29,5.11-0.151022:20170511T003321Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/compress/p7zip at 16.2,5.11-0.151022:20170510T225314Z found: Reject: pkg://omnios/compress/p7zip at 16.2,5.11-0.151022:20170510T225314Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/compress/gzip at 1.8,5.11-0.151022:20170510T233218Z found: Reject: pkg://omnios/compress/gzip at 1.8,5.11-0.151022:20170510T233218Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/mozilla-nss at 3.30.2,5.11-0.151022:20170510T212137Z found: Reject: pkg://omnios/system/library/mozilla-nss at 3.30.2,5.11-0.151022:20170510T212137Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/web/wget at 1.19.1,5.11-0.151022:20170510T205111Z found: Reject: pkg://omnios/web/wget at 1.19.1,5.11-0.151022:20170510T205111Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/python-2/m2crypto-27 at 0.24.0,5.11-0.151022:20170511T005404Z found: Reject: pkg://omnios/library/python-2/m2crypto-27 at 0.24.0,5.11-0.151022:20170511T005404Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/libxml2 at 2.9.4,5.11-0.151022:20170510T210749Z found: Reject: pkg://omnios/library/libxml2 at 2.9.4,5.11-0.151022:20170510T210749Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/gcc-5-runtime at 5.1.0,5.11-0.151022:20170510T230623Z found: Reject: pkg://omnios/system/library/gcc-5-runtime at 5.1.0,5.11-0.151022:20170510T230623Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/runtime/perl at 5.24.1,5.11-0.151022:20170510T225831Z found: Reject: pkg://omnios/runtime/perl at 5.24.1,5.11-0.151022:20170510T225831Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/python-2/pycurl-27 at 7.43.0,5.11-0.151022:20170511T001958Z found: Reject: pkg://omnios/library/python-2/pycurl-27 at 7.43.0,5.11-0.151022:20170511T001958Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z found: Reject: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/text/less at 487,5.11-0.151022:20170510T234140Z found: Reject: pkg://omnios/text/less at 487,5.11-0.151022:20170510T234140Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/expat at 2.2.0,5.11-0.151022:20170510T232549Z found: Reject: pkg://omnios/library/expat at 2.2.0,5.11-0.151022:20170510T232549Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/g++-5-runtime at 5.1.0,5.11-0.151022:20170511T004619Z found: Reject: pkg://omnios/system/library/g++-5-runtime at 5.1.0,5.11-0.151022:20170511T004619Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/text/gawk at 4.1.4,5.11-0.151022:20170510T233403Z found: Reject: pkg://omnios/text/gawk at 4.1.4,5.11-0.151022:20170510T233403Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/nghttp2 at 1.21.1,5.11-0.151022:20170510T210518Z found: Reject: pkg://omnios/library/nghttp2 at 1.21.1,5.11-0.151022:20170510T210518Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/iconv/utf-8 at 0.5.11,5.11-0.151022:20170510T220359Z found: Reject: pkg://omnios/system/library/iconv/utf-8 at 0.5.11,5.11-0.151022:20170510T220359Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/libidn at 1.33,5.11-0.151022:20170510T225041Z found: Reject: pkg://omnios/library/libidn at 1.33,5.11-0.151022:20170510T225041Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/text/gnu-diffutils at 3.5,5.11-0.151022:20170510T224850Z found: Reject: pkg://omnios/text/gnu-diffutils at 3.5,5.11-0.151022:20170510T224850Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/runtime/java at 1.7.0.101.0,5.11-0.151022:20170510T224552Z found: Reject: pkg://omnios/runtime/java at 1.7.0.101.0,5.11-0.151022:20170510T224552Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151022:20170510T232316Z found: Reject: pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151022:20170510T232316Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/text/gnu-sed at 4.4,5.11-0.151022:20170511T003400Z found: Reject: pkg://omnios/text/gnu-sed at 4.4,5.11-0.151022:20170511T003400Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/c++/sigcpp at 2.99.8,5.11-0.151022:20170510T220716Z found: Reject: pkg://omnios/library/c++/sigcpp at 2.99.8,5.11-0.151022:20170510T220716Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/ncurses at 6.0,5.11-0.151022:20170511T004907Z found: Reject: pkg://omnios/library/ncurses at 6.0,5.11-0.151022:20170511T004907Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/network/dns/bind at 9.10.4.8,5.11-0.151022:20170510T224739Z found: Reject: pkg://omnios/network/dns/bind at 9.10.4.8,5.11-0.151022:20170510T224739Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/python-2/numpy-27 at 1.12.1,5.11-0.151022:20170510T210429Z found: Reject: pkg://omnios/library/python-2/numpy-27 at 1.12.1,5.11-0.151022:20170510T210429Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/libdbus at 1.11.12,5.11-0.151022:20170510T230926Z found: Reject: pkg://omnios/system/library/libdbus at 1.11.12,5.11-0.151022:20170510T230926Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/compress/unzip at 6.0,5.11-0.151022:20170510T234151Z found: Reject: pkg://omnios/compress/unzip at 6.0,5.11-0.151022:20170510T234151Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/compress/bzip2 at 1.0.6,5.11-0.151022:20170510T234120Z found: Reject: pkg://omnios/compress/bzip2 at 1.0.6,5.11-0.151022:20170510T234120Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/unixodbc at 2.3.4,5.11-0.151022:20170511T002415Z found: Reject: pkg://omnios/library/unixodbc at 2.3.4,5.11-0.151022:20170511T002415Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/glib2 at 2.34.3,5.11-0.151022:20170511T002730Z found: Reject: pkg://omnios/library/glib2 at 2.34.3,5.11-0.151022:20170511T002730Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/libtool/libltdl at 2.4.6,5.11-0.151022:20170511T003148Z found: Reject: pkg://omnios/library/libtool/libltdl at 2.4.6,5.11-0.151022:20170511T003148Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/readline at 7.0,5.11-0.151022:20170510T215815Z found: Reject: pkg://omnios/library/readline at 7.0,5.11-0.151022:20170510T215815Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/shell/tcsh at 6.20.0,5.11-0.151022:20170510T234205Z found: Reject: pkg://omnios/shell/tcsh at 6.20.0,5.11-0.151022:20170510T234205Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/database/sqlite-3 at 3.18.0,5.11-0.151022:20170510T215403Z found: Reject: pkg://omnios/database/sqlite-3 at 3.18.0,5.11-0.151022:20170510T215403Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/text/groff at 1.22.3,5.11-0.151022:20170511T002510Z found: Reject: pkg://omnios/text/groff at 1.22.3,5.11-0.151022:20170511T002510Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/zlib at 1.2.11,5.11-0.151022:20170510T215452Z found: Reject: pkg://omnios/library/zlib at 1.2.11,5.11-0.151022:20170510T215452Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/file/gnu-coreutils at 8.27,5.11-0.151022:20170510T231545Z found: Reject: pkg://omnios/file/gnu-coreutils at 8.27,5.11-0.151022:20170510T231545Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/kvm at 1.0.5.11,5.11-0.151022:20170510T215230Z found: Reject: pkg://omnios/system/kvm at 1.0.5.11,5.11-0.151022:20170510T215230Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/text/gnu-grep at 3.0,5.11-0.151022:20170511T003601Z found: Reject: pkg://omnios/text/gnu-grep at 3.0,5.11-0.151022:20170511T003601Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/gmp at 6.1.2,5.11-0.151022:20170510T233611Z found: Reject: pkg://omnios/library/gmp at 6.1.2,5.11-0.151022:20170510T233611Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/terminal/screen at 4.5.1,5.11-0.151022:20170511T002046Z found: Reject: pkg://omnios/terminal/screen at 4.5.1,5.11-0.151022:20170511T002046Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/editor/vim at 8.0.567,5.11-0.151022:20170510T210550Z found: Reject: pkg://omnios/editor/vim at 8.0.567,5.11-0.151022:20170510T210550Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/text/gnu-patch at 2.7.5,5.11-0.151022:20170510T233649Z found: Reject: pkg://omnios/text/gnu-patch at 2.7.5,5.11-0.151022:20170510T233649Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/libffi at 3.2.1,5.11-0.151022:20170511T005527Z found: Reject: pkg://omnios/library/libffi at 3.2.1,5.11-0.151022:20170511T005527Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/shell/bash at 4.4.12,5.11-0.151022:20170510T210855Z found: Reject: pkg://omnios/shell/bash at 4.4.12,5.11-0.151022:20170510T210855Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/python-2/pyopenssl-27 at 0.11,5.11-0.151022:20170511T001751Z found: Reject: pkg://omnios/library/python-2/pyopenssl-27 at 0.11,5.11-0.151022:20170511T001751Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/compress/zip at 3.0,5.11-0.151022:20170511T002127Z found: Reject: pkg://omnios/compress/zip at 3.0,5.11-0.151022:20170511T002127Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/python-2/simplejson-27 at 3.10.0,5.11-0.151022:20170511T002201Z found: Reject: pkg://omnios/library/python-2/simplejson-27 at 3.10.0,5.11-0.151022:20170511T002201Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/nspr at 4.14,5.11-0.151022:20170510T212157Z found: Reject: pkg://omnios/library/nspr at 4.14,5.11-0.151022:20170510T212157Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/driver/virtualization/kvm at 1.0.5.11,5.11-0.151022:20170510T215139Z found: Reject: pkg://omnios/driver/virtualization/kvm at 1.0.5.11,5.11-0.151022:20170510T215139Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/pcre at 8.40,5.11-0.151022:20170511T004716Z found: Reject: pkg://omnios/library/pcre at 8.40,5.11-0.151022:20170511T004716Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/service/network/ntp at 4.2.8.10,5.11-0.151022:20170511T003515Z found: Reject: pkg://omnios/service/network/ntp at 4.2.8.10,5.11-0.151022:20170511T003515Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/web/curl at 7.54.0,5.11-0.151022:20170510T231134Z found: Reject: pkg://omnios/web/curl at 7.54.0,5.11-0.151022:20170510T231134Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/text/gnu-gettext at 0.19.8.1,5.11-0.151022:20170510T234103Z found: Reject: pkg://omnios/text/gnu-gettext at 0.19.8.1,5.11-0.151022:20170510T234103Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/compress/xz at 5.2.3,5.11-0.151022:20170510T225237Z found: Reject: pkg://omnios/compress/xz at 5.2.3,5.11-0.151022:20170510T225237Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/python-2/cherrypy-27 at 3.2.2,5.11-0.151022:20170511T003155Z found: Reject: pkg://omnios/library/python-2/cherrypy-27 at 3.2.2,5.11-0.151022:20170511T003155Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/libdbus-glib at 0.108,5.11-0.151022:20170510T215438Z found: Reject: pkg://omnios/system/library/libdbus-glib at 0.108,5.11-0.151022:20170510T215438Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/security/trousers at 0.3.8,5.11-0.151022:20170510T212349Z found: Reject: pkg://omnios/library/security/trousers at 0.3.8,5.11-0.151022:20170510T212349Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/developer/macro/gnu-m4 at 1.4.18,5.11-0.151022:20170511T005449Z found: Reject: pkg://omnios/developer/macro/gnu-m4 at 1.4.18,5.11-0.151022:20170511T005449Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/shell/pipe-viewer at 1.6.0,5.11-0.151022:20170511T002014Z found: Reject: pkg://omnios/shell/pipe-viewer at 1.6.0,5.11-0.151022:20170511T002014Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/file/gnu-findutils at 4.6.0,5.11-0.151022:20170511T001638Z found: Reject: pkg://omnios/file/gnu-findutils at 4.6.0,5.11-0.151022:20170511T001638Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/security/gss at 0.5.11,5.11-0.151022:20170510T212852Z found: Reject: pkg://omnios/system/library/security/gss at 0.5.11,5.11-0.151022:20170510T212852Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/service/storage/fibre-channel/fc-fabric at 0.5.11,5.11-0.151022:20170510T212836Z found: Reject: pkg://omnios/service/storage/fibre-channel/fc-fabric at 0.5.11,5.11-0.151022:20170510T212836Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/libdiskmgt at 0.5.11,5.11-0.151022:20170510T212849Z found: Reject: pkg://omnios/system/library/libdiskmgt at 0.5.11,5.11-0.151022:20170510T212849Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/developer/build/make at 0.5.11,5.11-0.151022:20170510T212743Z found: Reject: pkg://omnios/developer/build/make at 0.5.11,5.11-0.151022:20170510T212743Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/math at 0.5.11,5.11-0.151022:20170510T212850Z found: Reject: pkg://omnios/system/library/math at 0.5.11,5.11-0.151022:20170510T212850Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/storage/fibre-channel/libsun_fc at 0.5.11,5.11-0.151022:20170510T212853Z found: Reject: pkg://omnios/system/library/storage/fibre-channel/libsun_fc at 0.5.11,5.11-0.151022:20170510T212853Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/library/libtecla at 1.6.0,5.11-0.151022:20170510T212815Z found: Reject: pkg://omnios/library/libtecla at 1.6.0,5.11-0.151022:20170510T212815Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/policykit at 0.5.11,5.11-0.151022:20170510T212851Z found: Reject: pkg://omnios/system/library/policykit at 0.5.11,5.11-0.151022:20170510T212851Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/storage/ima/header-ima at 0.5.11,5.11-0.151022:20170510T212853Z found: Reject: pkg://omnios/system/library/storage/ima/header-ima at 0.5.11,5.11-0.151022:20170510T212853Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/storage/scsi-plugins at 0.5.11,5.11-0.151022:20170510T212854Z found: Reject: pkg://omnios/system/library/storage/scsi-plugins at 0.5.11,5.11-0.151022:20170510T212854Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/service/fault-management at 0.5.11,5.11-0.151022:20170510T212831Z found: Reject: pkg://omnios/service/fault-management at 0.5.11,5.11-0.151022:20170510T212831Z Reason: A version for 'require' dependency on pkg:/system/file-system/zfs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/security/libsasl at 0.5.11,5.11-0.151022:20170510T212852Z found: Reject: pkg://omnios/system/library/security/libsasl at 0.5.11,5.11-0.151022:20170510T212852Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/service/security/kerberos-5 at 0.5.11,5.11-0.151022:20170510T212835Z found: Reject: pkg://omnios/service/security/kerberos-5 at 0.5.11,5.11-0.151022:20170510T212835Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/network/mailwrapper at 0.5.11,5.11-0.151022:20170510T212857Z found: Reject: pkg://omnios/system/network/mailwrapper at 0.5.11,5.11-0.151022:20170510T212857Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/storage/ima at 0.5.11,5.11-0.151022:20170510T212854Z found: Reject: pkg://omnios/system/library/storage/ima at 0.5.11,5.11-0.151022:20170510T212854Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/package/svr4 at 0.5.11,5.11-0.151022:20170510T212829Z found: Reject: pkg://omnios/package/svr4 at 0.5.11,5.11-0.151022:20170510T212829Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/zones at 0.5.11,5.11-0.151022:20170510T212906Z found: Reject: pkg://omnios/system/zones at 0.5.11,5.11-0.151022:20170510T212906Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/data/keyboard/keytables at 0.5.11,5.11-0.151022:20170510T212840Z found: Reject: pkg://omnios/system/data/keyboard/keytables at 0.5.11,5.11-0.151022:20170510T212840Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/storage/fibre-channel/hbaapi at 0.5.11,5.11-0.151022:20170510T212853Z found: Reject: pkg://omnios/system/library/storage/fibre-channel/hbaapi at 0.5.11,5.11-0.151022:20170510T212853Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/storage/luxadm at 0.5.11,5.11-0.151022:20170510T212901Z found: Reject: pkg://omnios/system/storage/luxadm at 0.5.11,5.11-0.151022:20170510T212901Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/security/gss/spnego at 0.5.11,5.11-0.151022:20170510T212852Z found: Reject: pkg://omnios/system/library/security/gss/spnego at 0.5.11,5.11-0.151022:20170510T212852Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/boot/wanboot at 0.5.11,5.11-0.151022:20170510T212840Z found: Reject: pkg://omnios/system/boot/wanboot at 0.5.11,5.11-0.151022:20170510T212840Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/runtime/perl/module/sun-solaris at 0.5.11,5.11-0.151022:20170510T212830Z found: Reject: pkg://omnios/runtime/perl/module/sun-solaris at 0.5.11,5.11-0.151022:20170510T212830Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/library/security/gss/diffie-hellman at 0.5.11,5.11-0.151022:20170510T212852Z found: Reject: pkg://omnios/system/library/security/gss/diffie-hellman at 0.5.11,5.11-0.151022:20170510T212852Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/system/man at 0.5.11,5.11-0.151022:20170510T212855Z found: Reject: pkg://omnios/system/man at 0.5.11,5.11-0.151022:20170510T212855Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/service/security/gss at 0.5.11,5.11-0.151022:20170510T212835Z found: Reject: pkg://omnios/service/security/gss at 0.5.11,5.11-0.151022:20170510T212835Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/network/bridging at 0.5.11,5.11-0.151022:20170510T212828Z found: Reject: pkg://omnios/network/bridging at 0.5.11,5.11-0.151022:20170510T212828Z Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found No suitable version of required package pkg://omnios/developer/java/jdk at 1.7.0.101.0,5.11-0.151022:20170510T224621Z found: Reject: pkg://omnios/developer/java/jdk at 1.7.0.101.0,5.11-0.151022:20170510T224621Z Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at qutic.com Sat Jul 29 18:25:46 2017 From: mailinglists at qutic.com (qutic development) Date: Sat, 29 Jul 2017 20:25:46 +0200 Subject: [OmniOS-discuss] Problem with upgrade from r151014 to r151022 In-Reply-To: <02314418-5ED8-4101-803B-527E5BC9CB3F@gmail.com> References: <02314418-5ED8-4101-803B-527E5BC9CB3F@gmail.com> Message-ID: <30641B34-FF63-4BA0-BC91-1A4079715FC5@qutic.com> Have you done a "pkg update" to get the latest updates from r151014 before switching the publisher to r151022? - Stefan > Am 29.07.2017 um 12:47 schrieb ?????? ?????? : > > Hello! > > I?m trying to upgrade my small home server with 3 lipkg zones from r151014 to r151022. > > I?ve moved from SunSSH to OpenSSH (in global and all lipkg zones): > > # pkg list |grep ssh > network/openssh 7.4.1-0.151014 i-- > network/openssh-server 7.4.1-0.151014 i-- > > > Also I changed publisher to r151022 (in global and lipkg zones also): > > # pkg publisher > PUBLISHER TYPE STATUS P LOCATION > omnios origin online F https://pkg.omniti.com/omnios/r151022/ > ms.omniti.com origin online F http://pkg.omniti.com/omniti-ms/ > > > But when I run "pkg update" from global zone or from a lipkg zone I get errors (please see at the end of the message). It looks very strange for me. Did I missed something in upgrade plan or, may be, there are some other issues? > > Thank you for help! > > Daniil > > > > Creating Plan (Running solver): | > pkg update: No solution was found to satisfy constraints > Plan Creation: Package solver has not found a solution to update to latest available versions. > This may indicate an overly constrained set of packages are installed. > > latest incorporations: > > pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z > pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z > pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z > pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151022:20170511T001737Z > > The following indicates why the system cannot update to the latest version: > > No suitable version of required package pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z found: > Reject: pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z > Reason: A version for 'incorporate' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z found: > Reject: pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z > Reason: A version for 'incorporate' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z found: > Reject: pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/shell/zsh at 5.3.1,5.11-0.151022:20170510T233501Z found: > Reject: pkg://omnios/shell/zsh at 5.3.1,5.11-0.151022:20170510T233501Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/management/snmp/net-snmp at 5.7.3,5.11-0.151022:20170511T003113Z found: > Reject: pkg://omnios/system/management/snmp/net-snmp at 5.7.3,5.11-0.151022:20170511T003113Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/security/sudo at 1.8.7,5.11-0.151022:20170511T001935Z found: > Reject: pkg://omnios/security/sudo at 1.8.7,5.11-0.151022:20170511T001935Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/libxslt at 1.1.29,5.11-0.151022:20170511T003321Z found: > Reject: pkg://omnios/library/libxslt at 1.1.29,5.11-0.151022:20170511T003321Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/compress/p7zip at 16.2,5.11-0.151022:20170510T225314Z found: > Reject: pkg://omnios/compress/p7zip at 16.2,5.11-0.151022:20170510T225314Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/compress/gzip at 1.8,5.11-0.151022:20170510T233218Z found: > Reject: pkg://omnios/compress/gzip at 1.8,5.11-0.151022:20170510T233218Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/mozilla-nss at 3.30.2,5.11-0.151022:20170510T212137Z found: > Reject: pkg://omnios/system/library/mozilla-nss at 3.30.2,5.11-0.151022:20170510T212137Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/web/wget at 1.19.1,5.11-0.151022:20170510T205111Z found: > Reject: pkg://omnios/web/wget at 1.19.1,5.11-0.151022:20170510T205111Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/python-2/m2crypto-27 at 0.24.0,5.11-0.151022:20170511T005404Z found: > Reject: pkg://omnios/library/python-2/m2crypto-27 at 0.24.0,5.11-0.151022:20170511T005404Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/libxml2 at 2.9.4,5.11-0.151022:20170510T210749Z found: > Reject: pkg://omnios/library/libxml2 at 2.9.4,5.11-0.151022:20170510T210749Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/gcc-5-runtime at 5.1.0,5.11-0.151022:20170510T230623Z found: > Reject: pkg://omnios/system/library/gcc-5-runtime at 5.1.0,5.11-0.151022:20170510T230623Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/runtime/perl at 5.24.1,5.11-0.151022:20170510T225831Z found: > Reject: pkg://omnios/runtime/perl at 5.24.1,5.11-0.151022:20170510T225831Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/python-2/pycurl-27 at 7.43.0,5.11-0.151022:20170511T001958Z found: > Reject: pkg://omnios/library/python-2/pycurl-27 at 7.43.0,5.11-0.151022:20170511T001958Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z found: > Reject: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/text/less at 487,5.11-0.151022:20170510T234140Z found: > Reject: pkg://omnios/text/less at 487,5.11-0.151022:20170510T234140Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/expat at 2.2.0,5.11-0.151022:20170510T232549Z found: > Reject: pkg://omnios/library/expat at 2.2.0,5.11-0.151022:20170510T232549Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/g++-5-runtime at 5.1.0,5.11-0.151022:20170511T004619Z found: > Reject: pkg://omnios/system/library/g++-5-runtime at 5.1.0,5.11-0.151022:20170511T004619Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/text/gawk at 4.1.4,5.11-0.151022:20170510T233403Z found: > Reject: pkg://omnios/text/gawk at 4.1.4,5.11-0.151022:20170510T233403Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/nghttp2 at 1.21.1,5.11-0.151022:20170510T210518Z found: > Reject: pkg://omnios/library/nghttp2 at 1.21.1,5.11-0.151022:20170510T210518Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/iconv/utf-8 at 0.5.11,5.11-0.151022:20170510T220359Z found: > Reject: pkg://omnios/system/library/iconv/utf-8 at 0.5.11,5.11-0.151022:20170510T220359Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/libidn at 1.33,5.11-0.151022:20170510T225041Z found: > Reject: pkg://omnios/library/libidn at 1.33,5.11-0.151022:20170510T225041Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/text/gnu-diffutils at 3.5,5.11-0.151022:20170510T224850Z found: > Reject: pkg://omnios/text/gnu-diffutils at 3.5,5.11-0.151022:20170510T224850Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/runtime/java at 1.7.0.101.0,5.11-0.151022:20170510T224552Z found: > Reject: pkg://omnios/runtime/java at 1.7.0.101.0,5.11-0.151022:20170510T224552Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151022:20170510T232316Z found: > Reject: pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151022:20170510T232316Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/text/gnu-sed at 4.4,5.11-0.151022:20170511T003400Z found: > Reject: pkg://omnios/text/gnu-sed at 4.4,5.11-0.151022:20170511T003400Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/c++/sigcpp at 2.99.8,5.11-0.151022:20170510T220716Z found: > Reject: pkg://omnios/library/c++/sigcpp at 2.99.8,5.11-0.151022:20170510T220716Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/ncurses at 6.0,5.11-0.151022:20170511T004907Z found: > Reject: pkg://omnios/library/ncurses at 6.0,5.11-0.151022:20170511T004907Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/network/dns/bind at 9.10.4.8,5.11-0.151022:20170510T224739Z found: > Reject: pkg://omnios/network/dns/bind at 9.10.4.8,5.11-0.151022:20170510T224739Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/python-2/numpy-27 at 1.12.1,5.11-0.151022:20170510T210429Z found: > Reject: pkg://omnios/library/python-2/numpy-27 at 1.12.1,5.11-0.151022:20170510T210429Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/libdbus at 1.11.12,5.11-0.151022:20170510T230926Z found: > Reject: pkg://omnios/system/library/libdbus at 1.11.12,5.11-0.151022:20170510T230926Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/compress/unzip at 6.0,5.11-0.151022:20170510T234151Z found: > Reject: pkg://omnios/compress/unzip at 6.0,5.11-0.151022:20170510T234151Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/compress/bzip2 at 1.0.6,5.11-0.151022:20170510T234120Z found: > Reject: pkg://omnios/compress/bzip2 at 1.0.6,5.11-0.151022:20170510T234120Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/unixodbc at 2.3.4,5.11-0.151022:20170511T002415Z found: > Reject: pkg://omnios/library/unixodbc at 2.3.4,5.11-0.151022:20170511T002415Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/glib2 at 2.34.3,5.11-0.151022:20170511T002730Z found: > Reject: pkg://omnios/library/glib2 at 2.34.3,5.11-0.151022:20170511T002730Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/libtool/libltdl at 2.4.6,5.11-0.151022:20170511T003148Z found: > Reject: pkg://omnios/library/libtool/libltdl at 2.4.6,5.11-0.151022:20170511T003148Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/readline at 7.0,5.11-0.151022:20170510T215815Z found: > Reject: pkg://omnios/library/readline at 7.0,5.11-0.151022:20170510T215815Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/shell/tcsh at 6.20.0,5.11-0.151022:20170510T234205Z found: > Reject: pkg://omnios/shell/tcsh at 6.20.0,5.11-0.151022:20170510T234205Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/database/sqlite-3 at 3.18.0,5.11-0.151022:20170510T215403Z found: > Reject: pkg://omnios/database/sqlite-3 at 3.18.0,5.11-0.151022:20170510T215403Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/text/groff at 1.22.3,5.11-0.151022:20170511T002510Z found: > Reject: pkg://omnios/text/groff at 1.22.3,5.11-0.151022:20170511T002510Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/zlib at 1.2.11,5.11-0.151022:20170510T215452Z found: > Reject: pkg://omnios/library/zlib at 1.2.11,5.11-0.151022:20170510T215452Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/file/gnu-coreutils at 8.27,5.11-0.151022:20170510T231545Z found: > Reject: pkg://omnios/file/gnu-coreutils at 8.27,5.11-0.151022:20170510T231545Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/kvm at 1.0.5.11,5.11-0.151022:20170510T215230Z found: > Reject: pkg://omnios/system/kvm at 1.0.5.11,5.11-0.151022:20170510T215230Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/text/gnu-grep at 3.0,5.11-0.151022:20170511T003601Z found: > Reject: pkg://omnios/text/gnu-grep at 3.0,5.11-0.151022:20170511T003601Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/gmp at 6.1.2,5.11-0.151022:20170510T233611Z found: > Reject: pkg://omnios/library/gmp at 6.1.2,5.11-0.151022:20170510T233611Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/terminal/screen at 4.5.1,5.11-0.151022:20170511T002046Z found: > Reject: pkg://omnios/terminal/screen at 4.5.1,5.11-0.151022:20170511T002046Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/editor/vim at 8.0.567,5.11-0.151022:20170510T210550Z found: > Reject: pkg://omnios/editor/vim at 8.0.567,5.11-0.151022:20170510T210550Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/text/gnu-patch at 2.7.5,5.11-0.151022:20170510T233649Z found: > Reject: pkg://omnios/text/gnu-patch at 2.7.5,5.11-0.151022:20170510T233649Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/libffi at 3.2.1,5.11-0.151022:20170511T005527Z found: > Reject: pkg://omnios/library/libffi at 3.2.1,5.11-0.151022:20170511T005527Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/shell/bash at 4.4.12,5.11-0.151022:20170510T210855Z found: > Reject: pkg://omnios/shell/bash at 4.4.12,5.11-0.151022:20170510T210855Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/python-2/pyopenssl-27 at 0.11,5.11-0.151022:20170511T001751Z found: > Reject: pkg://omnios/library/python-2/pyopenssl-27 at 0.11,5.11-0.151022:20170511T001751Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/compress/zip at 3.0,5.11-0.151022:20170511T002127Z found: > Reject: pkg://omnios/compress/zip at 3.0,5.11-0.151022:20170511T002127Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/python-2/simplejson-27 at 3.10.0,5.11-0.151022:20170511T002201Z found: > Reject: pkg://omnios/library/python-2/simplejson-27 at 3.10.0,5.11-0.151022:20170511T002201Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/nspr at 4.14,5.11-0.151022:20170510T212157Z found: > Reject: pkg://omnios/library/nspr at 4.14,5.11-0.151022:20170510T212157Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/driver/virtualization/kvm at 1.0.5.11,5.11-0.151022:20170510T215139Z found: > Reject: pkg://omnios/driver/virtualization/kvm at 1.0.5.11,5.11-0.151022:20170510T215139Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/pcre at 8.40,5.11-0.151022:20170511T004716Z found: > Reject: pkg://omnios/library/pcre at 8.40,5.11-0.151022:20170511T004716Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/service/network/ntp at 4.2.8.10,5.11-0.151022:20170511T003515Z found: > Reject: pkg://omnios/service/network/ntp at 4.2.8.10,5.11-0.151022:20170511T003515Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/web/curl at 7.54.0,5.11-0.151022:20170510T231134Z found: > Reject: pkg://omnios/web/curl at 7.54.0,5.11-0.151022:20170510T231134Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/text/gnu-gettext at 0.19.8.1,5.11-0.151022:20170510T234103Z found: > Reject: pkg://omnios/text/gnu-gettext at 0.19.8.1,5.11-0.151022:20170510T234103Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/compress/xz at 5.2.3,5.11-0.151022:20170510T225237Z found: > Reject: pkg://omnios/compress/xz at 5.2.3,5.11-0.151022:20170510T225237Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/python-2/cherrypy-27 at 3.2.2,5.11-0.151022:20170511T003155Z found: > Reject: pkg://omnios/library/python-2/cherrypy-27 at 3.2.2,5.11-0.151022:20170511T003155Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/libdbus-glib at 0.108,5.11-0.151022:20170510T215438Z found: > Reject: pkg://omnios/system/library/libdbus-glib at 0.108,5.11-0.151022:20170510T215438Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/security/trousers at 0.3.8,5.11-0.151022:20170510T212349Z found: > Reject: pkg://omnios/library/security/trousers at 0.3.8,5.11-0.151022:20170510T212349Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/developer/macro/gnu-m4 at 1.4.18,5.11-0.151022:20170511T005449Z found: > Reject: pkg://omnios/developer/macro/gnu-m4 at 1.4.18,5.11-0.151022:20170511T005449Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/shell/pipe-viewer at 1.6.0,5.11-0.151022:20170511T002014Z found: > Reject: pkg://omnios/shell/pipe-viewer at 1.6.0,5.11-0.151022:20170511T002014Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/file/gnu-findutils at 4.6.0,5.11-0.151022:20170511T001638Z found: > Reject: pkg://omnios/file/gnu-findutils at 4.6.0,5.11-0.151022:20170511T001638Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/security/gss at 0.5.11,5.11-0.151022:20170510T212852Z found: > Reject: pkg://omnios/system/library/security/gss at 0.5.11,5.11-0.151022:20170510T212852Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/service/storage/fibre-channel/fc-fabric at 0.5.11,5.11-0.151022:20170510T212836Z found: > Reject: pkg://omnios/service/storage/fibre-channel/fc-fabric at 0.5.11,5.11-0.151022:20170510T212836Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/libdiskmgt at 0.5.11,5.11-0.151022:20170510T212849Z found: > Reject: pkg://omnios/system/library/libdiskmgt at 0.5.11,5.11-0.151022:20170510T212849Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/developer/build/make at 0.5.11,5.11-0.151022:20170510T212743Z found: > Reject: pkg://omnios/developer/build/make at 0.5.11,5.11-0.151022:20170510T212743Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/math at 0.5.11,5.11-0.151022:20170510T212850Z found: > Reject: pkg://omnios/system/library/math at 0.5.11,5.11-0.151022:20170510T212850Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/storage/fibre-channel/libsun_fc at 0.5.11,5.11-0.151022:20170510T212853Z found: > Reject: pkg://omnios/system/library/storage/fibre-channel/libsun_fc at 0.5.11,5.11-0.151022:20170510T212853Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/library/libtecla at 1.6.0,5.11-0.151022:20170510T212815Z found: > Reject: pkg://omnios/library/libtecla at 1.6.0,5.11-0.151022:20170510T212815Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/policykit at 0.5.11,5.11-0.151022:20170510T212851Z found: > Reject: pkg://omnios/system/library/policykit at 0.5.11,5.11-0.151022:20170510T212851Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/storage/ima/header-ima at 0.5.11,5.11-0.151022:20170510T212853Z found: > Reject: pkg://omnios/system/library/storage/ima/header-ima at 0.5.11,5.11-0.151022:20170510T212853Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/storage/scsi-plugins at 0.5.11,5.11-0.151022:20170510T212854Z found: > Reject: pkg://omnios/system/library/storage/scsi-plugins at 0.5.11,5.11-0.151022:20170510T212854Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/service/fault-management at 0.5.11,5.11-0.151022:20170510T212831Z found: > Reject: pkg://omnios/service/fault-management at 0.5.11,5.11-0.151022:20170510T212831Z > Reason: A version for 'require' dependency on pkg:/system/file-system/zfs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/security/libsasl at 0.5.11,5.11-0.151022:20170510T212852Z found: > Reject: pkg://omnios/system/library/security/libsasl at 0.5.11,5.11-0.151022:20170510T212852Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/service/security/kerberos-5 at 0.5.11,5.11-0.151022:20170510T212835Z found: > Reject: pkg://omnios/service/security/kerberos-5 at 0.5.11,5.11-0.151022:20170510T212835Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/network/mailwrapper at 0.5.11,5.11-0.151022:20170510T212857Z found: > Reject: pkg://omnios/system/network/mailwrapper at 0.5.11,5.11-0.151022:20170510T212857Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/storage/ima at 0.5.11,5.11-0.151022:20170510T212854Z found: > Reject: pkg://omnios/system/library/storage/ima at 0.5.11,5.11-0.151022:20170510T212854Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/package/svr4 at 0.5.11,5.11-0.151022:20170510T212829Z found: > Reject: pkg://omnios/package/svr4 at 0.5.11,5.11-0.151022:20170510T212829Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/zones at 0.5.11,5.11-0.151022:20170510T212906Z found: > Reject: pkg://omnios/system/zones at 0.5.11,5.11-0.151022:20170510T212906Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/data/keyboard/keytables at 0.5.11,5.11-0.151022:20170510T212840Z found: > Reject: pkg://omnios/system/data/keyboard/keytables at 0.5.11,5.11-0.151022:20170510T212840Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/storage/fibre-channel/hbaapi at 0.5.11,5.11-0.151022:20170510T212853Z found: > Reject: pkg://omnios/system/library/storage/fibre-channel/hbaapi at 0.5.11,5.11-0.151022:20170510T212853Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/storage/luxadm at 0.5.11,5.11-0.151022:20170510T212901Z found: > Reject: pkg://omnios/system/storage/luxadm at 0.5.11,5.11-0.151022:20170510T212901Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/security/gss/spnego at 0.5.11,5.11-0.151022:20170510T212852Z found: > Reject: pkg://omnios/system/library/security/gss/spnego at 0.5.11,5.11-0.151022:20170510T212852Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/boot/wanboot at 0.5.11,5.11-0.151022:20170510T212840Z found: > Reject: pkg://omnios/system/boot/wanboot at 0.5.11,5.11-0.151022:20170510T212840Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/runtime/perl/module/sun-solaris at 0.5.11,5.11-0.151022:20170510T212830Z found: > Reject: pkg://omnios/runtime/perl/module/sun-solaris at 0.5.11,5.11-0.151022:20170510T212830Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/library/security/gss/diffie-hellman at 0.5.11,5.11-0.151022:20170510T212852Z found: > Reject: pkg://omnios/system/library/security/gss/diffie-hellman at 0.5.11,5.11-0.151022:20170510T212852Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/system/man at 0.5.11,5.11-0.151022:20170510T212855Z found: > Reject: pkg://omnios/system/man at 0.5.11,5.11-0.151022:20170510T212855Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/service/security/gss at 0.5.11,5.11-0.151022:20170510T212835Z found: > Reject: pkg://omnios/service/security/gss at 0.5.11,5.11-0.151022:20170510T212835Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/network/bridging at 0.5.11,5.11-0.151022:20170510T212828Z found: > Reject: pkg://omnios/network/bridging at 0.5.11,5.11-0.151022:20170510T212828Z > Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found > No suitable version of required package pkg://omnios/developer/java/jdk at 1.7.0.101.0,5.11-0.151022:20170510T224621Z found: > Reject: pkg://omnios/developer/java/jdk at 1.7.0.101.0,5.11-0.151022:20170510T224621Z > Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From daniil.landau at gmail.com Sat Jul 29 19:08:42 2017 From: daniil.landau at gmail.com (=?utf-8?B?0JTQsNC90LjQuNC7INCb0LDQvdC00LDRgw==?=) Date: Sat, 29 Jul 2017 22:08:42 +0300 Subject: [OmniOS-discuss] Problem with upgrade from r151014 to r151022 In-Reply-To: <30641B34-FF63-4BA0-BC91-1A4079715FC5@qutic.com> References: <02314418-5ED8-4101-803B-527E5BC9CB3F@gmail.com> <30641B34-FF63-4BA0-BC91-1A4079715FC5@qutic.com> Message-ID: <8564F2CD-9672-4D46-8C73-EC55BB9F7315@gmail.com> Thank you for your response! Yes, I?ve applied the latest updates for r151014 before publisher changing. Also just changed publisher back to r151014 and checked it once again. No updates available. Daniil > 29 ???? 2017 ?., ? 21:25, qutic development ???????(?): > > Have you done a "pkg update" to get the latest updates from r151014 before switching the publisher to r151022? > > - Stefan > >> Am 29.07.2017 um 12:47 schrieb ?????? ?????? : >> >> Hello! >> >> I?m trying to upgrade my small home server with 3 lipkg zones from r151014 to r151022. >> >> I?ve moved from SunSSH to OpenSSH (in global and all lipkg zones): >> >> # pkg list |grep ssh >> network/openssh 7.4.1-0.151014 i-- >> network/openssh-server 7.4.1-0.151014 i-- >> >> >> Also I changed publisher to r151022 (in global and lipkg zones also): >> >> # pkg publisher >> PUBLISHER TYPE STATUS P LOCATION >> omnios origin online F https://pkg.omniti.com/omnios/r151022/ >> ms.omniti.com origin online F http://pkg.omniti.com/omniti-ms/ >> >> >> But when I run "pkg update" from global zone or from a lipkg zone I get errors (please see at the end of the message). It looks very strange for me. Did I missed something in upgrade plan or, may be, there are some other issues? >> >> Thank you for help! >> >> Daniil >> >> >> >> Creating Plan (Running solver): | >> pkg update: No solution was found to satisfy constraints >> Plan Creation: Package solver has not found a solution to update to latest available versions. >> This may indicate an overly constrained set of packages are installed. >> >> latest incorporations: >> >> pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z >> pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z >> pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z >> pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151022:20170511T001737Z >> >> The following indicates why the system cannot update to the latest version: >> >> No suitable version of required package pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z found: >> Reject: pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z >> Reason: A version for 'incorporate' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z found: >> Reject: pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z >> Reason: A version for 'incorporate' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z found: >> Reject: pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/shell/zsh at 5.3.1,5.11-0.151022:20170510T233501Z found: >> Reject: pkg://omnios/shell/zsh at 5.3.1,5.11-0.151022:20170510T233501Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/management/snmp/net-snmp at 5.7.3,5.11-0.151022:20170511T003113Z found: >> Reject: pkg://omnios/system/management/snmp/net-snmp at 5.7.3,5.11-0.151022:20170511T003113Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/security/sudo at 1.8.7,5.11-0.151022:20170511T001935Z found: >> Reject: pkg://omnios/security/sudo at 1.8.7,5.11-0.151022:20170511T001935Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/libxslt at 1.1.29,5.11-0.151022:20170511T003321Z found: >> Reject: pkg://omnios/library/libxslt at 1.1.29,5.11-0.151022:20170511T003321Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/compress/p7zip at 16.2,5.11-0.151022:20170510T225314Z found: >> Reject: pkg://omnios/compress/p7zip at 16.2,5.11-0.151022:20170510T225314Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/compress/gzip at 1.8,5.11-0.151022:20170510T233218Z found: >> Reject: pkg://omnios/compress/gzip at 1.8,5.11-0.151022:20170510T233218Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/mozilla-nss at 3.30.2,5.11-0.151022:20170510T212137Z found: >> Reject: pkg://omnios/system/library/mozilla-nss at 3.30.2,5.11-0.151022:20170510T212137Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/web/wget at 1.19.1,5.11-0.151022:20170510T205111Z found: >> Reject: pkg://omnios/web/wget at 1.19.1,5.11-0.151022:20170510T205111Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/python-2/m2crypto-27 at 0.24.0,5.11-0.151022:20170511T005404Z found: >> Reject: pkg://omnios/library/python-2/m2crypto-27 at 0.24.0,5.11-0.151022:20170511T005404Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/libxml2 at 2.9.4,5.11-0.151022:20170510T210749Z found: >> Reject: pkg://omnios/library/libxml2 at 2.9.4,5.11-0.151022:20170510T210749Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/gcc-5-runtime at 5.1.0,5.11-0.151022:20170510T230623Z found: >> Reject: pkg://omnios/system/library/gcc-5-runtime at 5.1.0,5.11-0.151022:20170510T230623Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/runtime/perl at 5.24.1,5.11-0.151022:20170510T225831Z found: >> Reject: pkg://omnios/runtime/perl at 5.24.1,5.11-0.151022:20170510T225831Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/python-2/pycurl-27 at 7.43.0,5.11-0.151022:20170511T001958Z found: >> Reject: pkg://omnios/library/python-2/pycurl-27 at 7.43.0,5.11-0.151022:20170511T001958Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z found: >> Reject: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/text/less at 487,5.11-0.151022:20170510T234140Z found: >> Reject: pkg://omnios/text/less at 487,5.11-0.151022:20170510T234140Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/expat at 2.2.0,5.11-0.151022:20170510T232549Z found: >> Reject: pkg://omnios/library/expat at 2.2.0,5.11-0.151022:20170510T232549Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/g++-5-runtime at 5.1.0,5.11-0.151022:20170511T004619Z found: >> Reject: pkg://omnios/system/library/g++-5-runtime at 5.1.0,5.11-0.151022:20170511T004619Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/text/gawk at 4.1.4,5.11-0.151022:20170510T233403Z found: >> Reject: pkg://omnios/text/gawk at 4.1.4,5.11-0.151022:20170510T233403Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/nghttp2 at 1.21.1,5.11-0.151022:20170510T210518Z found: >> Reject: pkg://omnios/library/nghttp2 at 1.21.1,5.11-0.151022:20170510T210518Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/iconv/utf-8 at 0.5.11,5.11-0.151022:20170510T220359Z found: >> Reject: pkg://omnios/system/library/iconv/utf-8 at 0.5.11,5.11-0.151022:20170510T220359Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/libidn at 1.33,5.11-0.151022:20170510T225041Z found: >> Reject: pkg://omnios/library/libidn at 1.33,5.11-0.151022:20170510T225041Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/text/gnu-diffutils at 3.5,5.11-0.151022:20170510T224850Z found: >> Reject: pkg://omnios/text/gnu-diffutils at 3.5,5.11-0.151022:20170510T224850Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/runtime/java at 1.7.0.101.0,5.11-0.151022:20170510T224552Z found: >> Reject: pkg://omnios/runtime/java at 1.7.0.101.0,5.11-0.151022:20170510T224552Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151022:20170510T232316Z found: >> Reject: pkg://omnios/library/security/openssl at 1.0.2.11,5.11-0.151022:20170510T232316Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/text/gnu-sed at 4.4,5.11-0.151022:20170511T003400Z found: >> Reject: pkg://omnios/text/gnu-sed at 4.4,5.11-0.151022:20170511T003400Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/c++/sigcpp at 2.99.8,5.11-0.151022:20170510T220716Z found: >> Reject: pkg://omnios/library/c++/sigcpp at 2.99.8,5.11-0.151022:20170510T220716Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/ncurses at 6.0,5.11-0.151022:20170511T004907Z found: >> Reject: pkg://omnios/library/ncurses at 6.0,5.11-0.151022:20170511T004907Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/network/dns/bind at 9.10.4.8,5.11-0.151022:20170510T224739Z found: >> Reject: pkg://omnios/network/dns/bind at 9.10.4.8,5.11-0.151022:20170510T224739Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/python-2/numpy-27 at 1.12.1,5.11-0.151022:20170510T210429Z found: >> Reject: pkg://omnios/library/python-2/numpy-27 at 1.12.1,5.11-0.151022:20170510T210429Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/libdbus at 1.11.12,5.11-0.151022:20170510T230926Z found: >> Reject: pkg://omnios/system/library/libdbus at 1.11.12,5.11-0.151022:20170510T230926Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/compress/unzip at 6.0,5.11-0.151022:20170510T234151Z found: >> Reject: pkg://omnios/compress/unzip at 6.0,5.11-0.151022:20170510T234151Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/compress/bzip2 at 1.0.6,5.11-0.151022:20170510T234120Z found: >> Reject: pkg://omnios/compress/bzip2 at 1.0.6,5.11-0.151022:20170510T234120Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/unixodbc at 2.3.4,5.11-0.151022:20170511T002415Z found: >> Reject: pkg://omnios/library/unixodbc at 2.3.4,5.11-0.151022:20170511T002415Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/glib2 at 2.34.3,5.11-0.151022:20170511T002730Z found: >> Reject: pkg://omnios/library/glib2 at 2.34.3,5.11-0.151022:20170511T002730Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/libtool/libltdl at 2.4.6,5.11-0.151022:20170511T003148Z found: >> Reject: pkg://omnios/library/libtool/libltdl at 2.4.6,5.11-0.151022:20170511T003148Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/readline at 7.0,5.11-0.151022:20170510T215815Z found: >> Reject: pkg://omnios/library/readline at 7.0,5.11-0.151022:20170510T215815Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/shell/tcsh at 6.20.0,5.11-0.151022:20170510T234205Z found: >> Reject: pkg://omnios/shell/tcsh at 6.20.0,5.11-0.151022:20170510T234205Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/database/sqlite-3 at 3.18.0,5.11-0.151022:20170510T215403Z found: >> Reject: pkg://omnios/database/sqlite-3 at 3.18.0,5.11-0.151022:20170510T215403Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/text/groff at 1.22.3,5.11-0.151022:20170511T002510Z found: >> Reject: pkg://omnios/text/groff at 1.22.3,5.11-0.151022:20170511T002510Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/zlib at 1.2.11,5.11-0.151022:20170510T215452Z found: >> Reject: pkg://omnios/library/zlib at 1.2.11,5.11-0.151022:20170510T215452Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/file/gnu-coreutils at 8.27,5.11-0.151022:20170510T231545Z found: >> Reject: pkg://omnios/file/gnu-coreutils at 8.27,5.11-0.151022:20170510T231545Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/kvm at 1.0.5.11,5.11-0.151022:20170510T215230Z found: >> Reject: pkg://omnios/system/kvm at 1.0.5.11,5.11-0.151022:20170510T215230Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/text/gnu-grep at 3.0,5.11-0.151022:20170511T003601Z found: >> Reject: pkg://omnios/text/gnu-grep at 3.0,5.11-0.151022:20170511T003601Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/gmp at 6.1.2,5.11-0.151022:20170510T233611Z found: >> Reject: pkg://omnios/library/gmp at 6.1.2,5.11-0.151022:20170510T233611Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/terminal/screen at 4.5.1,5.11-0.151022:20170511T002046Z found: >> Reject: pkg://omnios/terminal/screen at 4.5.1,5.11-0.151022:20170511T002046Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/editor/vim at 8.0.567,5.11-0.151022:20170510T210550Z found: >> Reject: pkg://omnios/editor/vim at 8.0.567,5.11-0.151022:20170510T210550Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/text/gnu-patch at 2.7.5,5.11-0.151022:20170510T233649Z found: >> Reject: pkg://omnios/text/gnu-patch at 2.7.5,5.11-0.151022:20170510T233649Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/libffi at 3.2.1,5.11-0.151022:20170511T005527Z found: >> Reject: pkg://omnios/library/libffi at 3.2.1,5.11-0.151022:20170511T005527Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/shell/bash at 4.4.12,5.11-0.151022:20170510T210855Z found: >> Reject: pkg://omnios/shell/bash at 4.4.12,5.11-0.151022:20170510T210855Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/python-2/pyopenssl-27 at 0.11,5.11-0.151022:20170511T001751Z found: >> Reject: pkg://omnios/library/python-2/pyopenssl-27 at 0.11,5.11-0.151022:20170511T001751Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/compress/zip at 3.0,5.11-0.151022:20170511T002127Z found: >> Reject: pkg://omnios/compress/zip at 3.0,5.11-0.151022:20170511T002127Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/python-2/simplejson-27 at 3.10.0,5.11-0.151022:20170511T002201Z found: >> Reject: pkg://omnios/library/python-2/simplejson-27 at 3.10.0,5.11-0.151022:20170511T002201Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/nspr at 4.14,5.11-0.151022:20170510T212157Z found: >> Reject: pkg://omnios/library/nspr at 4.14,5.11-0.151022:20170510T212157Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/driver/virtualization/kvm at 1.0.5.11,5.11-0.151022:20170510T215139Z found: >> Reject: pkg://omnios/driver/virtualization/kvm at 1.0.5.11,5.11-0.151022:20170510T215139Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/pcre at 8.40,5.11-0.151022:20170511T004716Z found: >> Reject: pkg://omnios/library/pcre at 8.40,5.11-0.151022:20170511T004716Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/service/network/ntp at 4.2.8.10,5.11-0.151022:20170511T003515Z found: >> Reject: pkg://omnios/service/network/ntp at 4.2.8.10,5.11-0.151022:20170511T003515Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/web/curl at 7.54.0,5.11-0.151022:20170510T231134Z found: >> Reject: pkg://omnios/web/curl at 7.54.0,5.11-0.151022:20170510T231134Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/text/gnu-gettext at 0.19.8.1,5.11-0.151022:20170510T234103Z found: >> Reject: pkg://omnios/text/gnu-gettext at 0.19.8.1,5.11-0.151022:20170510T234103Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/compress/xz at 5.2.3,5.11-0.151022:20170510T225237Z found: >> Reject: pkg://omnios/compress/xz at 5.2.3,5.11-0.151022:20170510T225237Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/python-2/cherrypy-27 at 3.2.2,5.11-0.151022:20170511T003155Z found: >> Reject: pkg://omnios/library/python-2/cherrypy-27 at 3.2.2,5.11-0.151022:20170511T003155Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/libdbus-glib at 0.108,5.11-0.151022:20170510T215438Z found: >> Reject: pkg://omnios/system/library/libdbus-glib at 0.108,5.11-0.151022:20170510T215438Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/security/trousers at 0.3.8,5.11-0.151022:20170510T212349Z found: >> Reject: pkg://omnios/library/security/trousers at 0.3.8,5.11-0.151022:20170510T212349Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/developer/macro/gnu-m4 at 1.4.18,5.11-0.151022:20170511T005449Z found: >> Reject: pkg://omnios/developer/macro/gnu-m4 at 1.4.18,5.11-0.151022:20170511T005449Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/shell/pipe-viewer at 1.6.0,5.11-0.151022:20170511T002014Z found: >> Reject: pkg://omnios/shell/pipe-viewer at 1.6.0,5.11-0.151022:20170511T002014Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/file/gnu-findutils at 4.6.0,5.11-0.151022:20170511T001638Z found: >> Reject: pkg://omnios/file/gnu-findutils at 4.6.0,5.11-0.151022:20170511T001638Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/security/gss at 0.5.11,5.11-0.151022:20170510T212852Z found: >> Reject: pkg://omnios/system/library/security/gss at 0.5.11,5.11-0.151022:20170510T212852Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/service/storage/fibre-channel/fc-fabric at 0.5.11,5.11-0.151022:20170510T212836Z found: >> Reject: pkg://omnios/service/storage/fibre-channel/fc-fabric at 0.5.11,5.11-0.151022:20170510T212836Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/libdiskmgt at 0.5.11,5.11-0.151022:20170510T212849Z found: >> Reject: pkg://omnios/system/library/libdiskmgt at 0.5.11,5.11-0.151022:20170510T212849Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/developer/build/make at 0.5.11,5.11-0.151022:20170510T212743Z found: >> Reject: pkg://omnios/developer/build/make at 0.5.11,5.11-0.151022:20170510T212743Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/math at 0.5.11,5.11-0.151022:20170510T212850Z found: >> Reject: pkg://omnios/system/library/math at 0.5.11,5.11-0.151022:20170510T212850Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/storage/fibre-channel/libsun_fc at 0.5.11,5.11-0.151022:20170510T212853Z found: >> Reject: pkg://omnios/system/library/storage/fibre-channel/libsun_fc at 0.5.11,5.11-0.151022:20170510T212853Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/library/libtecla at 1.6.0,5.11-0.151022:20170510T212815Z found: >> Reject: pkg://omnios/library/libtecla at 1.6.0,5.11-0.151022:20170510T212815Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/policykit at 0.5.11,5.11-0.151022:20170510T212851Z found: >> Reject: pkg://omnios/system/library/policykit at 0.5.11,5.11-0.151022:20170510T212851Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/storage/ima/header-ima at 0.5.11,5.11-0.151022:20170510T212853Z found: >> Reject: pkg://omnios/system/library/storage/ima/header-ima at 0.5.11,5.11-0.151022:20170510T212853Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/storage/scsi-plugins at 0.5.11,5.11-0.151022:20170510T212854Z found: >> Reject: pkg://omnios/system/library/storage/scsi-plugins at 0.5.11,5.11-0.151022:20170510T212854Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/service/fault-management at 0.5.11,5.11-0.151022:20170510T212831Z found: >> Reject: pkg://omnios/service/fault-management at 0.5.11,5.11-0.151022:20170510T212831Z >> Reason: A version for 'require' dependency on pkg:/system/file-system/zfs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/security/libsasl at 0.5.11,5.11-0.151022:20170510T212852Z found: >> Reject: pkg://omnios/system/library/security/libsasl at 0.5.11,5.11-0.151022:20170510T212852Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/service/security/kerberos-5 at 0.5.11,5.11-0.151022:20170510T212835Z found: >> Reject: pkg://omnios/service/security/kerberos-5 at 0.5.11,5.11-0.151022:20170510T212835Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/network/mailwrapper at 0.5.11,5.11-0.151022:20170510T212857Z found: >> Reject: pkg://omnios/system/network/mailwrapper at 0.5.11,5.11-0.151022:20170510T212857Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/storage/ima at 0.5.11,5.11-0.151022:20170510T212854Z found: >> Reject: pkg://omnios/system/library/storage/ima at 0.5.11,5.11-0.151022:20170510T212854Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/package/svr4 at 0.5.11,5.11-0.151022:20170510T212829Z found: >> Reject: pkg://omnios/package/svr4 at 0.5.11,5.11-0.151022:20170510T212829Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/zones at 0.5.11,5.11-0.151022:20170510T212906Z found: >> Reject: pkg://omnios/system/zones at 0.5.11,5.11-0.151022:20170510T212906Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/data/keyboard/keytables at 0.5.11,5.11-0.151022:20170510T212840Z found: >> Reject: pkg://omnios/system/data/keyboard/keytables at 0.5.11,5.11-0.151022:20170510T212840Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/storage/fibre-channel/hbaapi at 0.5.11,5.11-0.151022:20170510T212853Z found: >> Reject: pkg://omnios/system/library/storage/fibre-channel/hbaapi at 0.5.11,5.11-0.151022:20170510T212853Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/storage/luxadm at 0.5.11,5.11-0.151022:20170510T212901Z found: >> Reject: pkg://omnios/system/storage/luxadm at 0.5.11,5.11-0.151022:20170510T212901Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/security/gss/spnego at 0.5.11,5.11-0.151022:20170510T212852Z found: >> Reject: pkg://omnios/system/library/security/gss/spnego at 0.5.11,5.11-0.151022:20170510T212852Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/boot/wanboot at 0.5.11,5.11-0.151022:20170510T212840Z found: >> Reject: pkg://omnios/system/boot/wanboot at 0.5.11,5.11-0.151022:20170510T212840Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/runtime/perl/module/sun-solaris at 0.5.11,5.11-0.151022:20170510T212830Z found: >> Reject: pkg://omnios/runtime/perl/module/sun-solaris at 0.5.11,5.11-0.151022:20170510T212830Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/library/security/gss/diffie-hellman at 0.5.11,5.11-0.151022:20170510T212852Z found: >> Reject: pkg://omnios/system/library/security/gss/diffie-hellman at 0.5.11,5.11-0.151022:20170510T212852Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/system/man at 0.5.11,5.11-0.151022:20170510T212855Z found: >> Reject: pkg://omnios/system/man at 0.5.11,5.11-0.151022:20170510T212855Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/service/security/gss at 0.5.11,5.11-0.151022:20170510T212835Z found: >> Reject: pkg://omnios/service/security/gss at 0.5.11,5.11-0.151022:20170510T212835Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/network/bridging at 0.5.11,5.11-0.151022:20170510T212828Z found: >> Reject: pkg://omnios/network/bridging at 0.5.11,5.11-0.151022:20170510T212828Z >> Reason: A version for 'require' dependency on pkg:/system/library at 0.5.11,5.11-0.151022 cannot be found >> No suitable version of required package pkg://omnios/developer/java/jdk at 1.7.0.101.0,5.11-0.151022:20170510T224621Z found: >> Reject: pkg://omnios/developer/java/jdk at 1.7.0.101.0,5.11-0.151022:20170510T224621Z >> Reason: A version for 'require' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151022 cannot be found >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > From an3s.annema at gmail.com Sun Jul 30 15:42:31 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Sun, 30 Jul 2017 17:42:31 +0200 Subject: [OmniOS-discuss] Postfix service: syslog reports "fatal: the Postfix mail system is already running" every second In-Reply-To: <968cced0-05d0-a975-2ddf-134fe3a6656a@gmail.com> References: <968cced0-05d0-a975-2ddf-134fe3a6656a@gmail.com> Message-ID: In the mean time I tried upgrading the separate test-system from r151022 "vanilla" to the CE-edition - r151022i by now - hoping this might somehow also solve the below postfix "already running" error. But, it didn't. Again I tried the solution that worked on r151014 and also a reboot, but without success. This "Postfix mail system is already running"-issue is all over the internet - not specifically on Solarish-systems, that is - but I am clearly missing something here, as I don't seem to get the issue out of there. Is there anyone out there with some ideas on this, pretty please? Thanks. Andries On 2017-07-14 14:45, Andries Annema wrote: > Hi all, > > Have been running postfix from the "ms.omniti.com" publisher for some > years now on r151014 without issues. > Last week I updated my October 2016 r151014 system to the latest > r151014-status, as a first step in the direction of upgrading to the > latest LTS. I'm not actually there yet to upgrade to r151022; first I > want to make sure all my services and packages run flawlessly on that > version. Turns out that being careful pays off. > > In this update process, postfix got updated to > 2.11.9-0.151014:20170214T224831Z. > It still works, but /var/log/syslog is filled with a new line ever > second stating: > > ".... [ID 947731 mail.crit] fatal: the Postfix mail system is already > running" > > And /var/svc/log/network-smtp-postfix:default.log is repeatedly filled > with line pairs like: > "[ Jul 14 13:48:50 Executing start method ("/opt/omni/sbin/postfix > start"). ] > [ Jul 14 13:48:51 Stopping because service exited with an error. ] > [ Jul 14 13:48:51 Executing start method ("/opt/omni/sbin/postfix > start"). ] > [ Jul 14 13:48:51 Stopping because service exited with an error. ] > [ Jul 14 13:48:51 Failing too quickly, throttling. ]" > > Simply disabling and re-enabling the SMF service does not help. > What did help was this: > $ sudo svcadm disable postfix > $ sudo fuser -k /var/lib/postfix/master.lock > $ sudo rm /var/lib/postfix/master.lock > $ sudo rm /var/spool/postfix/pid/master.pid > $ sudo svcadm enable postfix > > That, however, was on r151014. > On a separate, freshly installed r151022 test-system, I installed this > same postfix 2.11.9 package and the same issue emerged. > However, the fix that worked on r151014, does not seem to work on > r151022. > Rebooting doesn't help either. > > Funny thing is: it does deliver email nicely, despite this restarting > issue. > > I tried downgrading to postfix 2.10.10: problem still exists. > Tried downgrading further, to 2.10.2: not possible, because the > manifest states a "incorporate" dependency on the "entire at 11-0.151014" > package. Hm, right... now I'm out of ideas. > Any clues? > > Regards, > Andries > From peter.tribble at gmail.com Sun Jul 30 19:15:08 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Sun, 30 Jul 2017 20:15:08 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> Message-ID: Hi, > The current OmniOS AMIs in AWS seem to use pv virtualization, > precluding > > their use on the t2 and m4 instance types that I want to use. > > > > > The following should get you going: > > > > https://www.prakashsurya.com/post/2017-02-06-creating-a- > custom-amazon-ec2-ami-from-iso/ Just to say that I successfully created a hvmAMI for my own distro (Tribblix) using those instructions. Almost all my problems were on the xen side. Other than having to work out how to reset the BIOS password on my test PC to enable the VT-x extensions needed for hvm support, the other problem I had is that illumos panics when trying to use the xen network. So I had to create a VM without a network interface, install the OS, then enable nwam and ensure I had a valid user I could ssh to so I could run up the AMI on EC2, log in using the temporary account, and do the rest of the configuration while running on EC2 to create the final AMI. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at sysmgr.org Sun Jul 30 19:38:27 2017 From: josh at sysmgr.org (Joshua M. Clulow) Date: Sun, 30 Jul 2017 12:38:27 -0700 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> Message-ID: On 30 July 2017 at 12:15, Peter Tribble wrote: > illumos panics when trying to use the xen network. Do you have a crash dump, or at least a stack trace, for this? We should probably get a ticket filed. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From peter.tribble at gmail.com Sun Jul 30 19:49:26 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Sun, 30 Jul 2017 20:49:26 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> Message-ID: On Sun, Jul 30, 2017 at 8:38 PM, Joshua M. Clulow wrote: > On 30 July 2017 at 12:15, Peter Tribble wrote: > > illumos panics when trying to use the xen network. > > Do you have a crash dump, or at least a stack trace, for this? We > should probably get a ticket filed. > It was essentially similar to some of the crashes here: https://www.illumos.org/issues/7186 I have a recording of the vnc session, if you're interested. This is the last frame: [image: Inline image 1] -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xen-panic.png Type: image/png Size: 33969 bytes Desc: not available URL: From jimklimov at cos.ru Sun Jul 30 20:00:02 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Sun, 30 Jul 2017 20:00:02 +0000 Subject: [OmniOS-discuss] Postfix service: syslog reports "fatal: the Postfix mail system is already running" every second In-Reply-To: References: <968cced0-05d0-a975-2ddf-134fe3a6656a@gmail.com> Message-ID: On July 30, 2017 5:42:31 PM GMT+02:00, Andries Annema wrote: >In the mean time I tried upgrading the separate test-system from >r151022 >"vanilla" to the CE-edition - r151022i by now - hoping this might >somehow also solve the below postfix "already running" error. But, it >didn't. > >Again I tried the solution that worked on r151014 and also a reboot, >but >without success. > >This "Postfix mail system is already running"-issue is all over the >internet - not specifically on Solarish-systems, that is - but I am >clearly missing something here, as I don't seem to get the issue out of > >there. > >Is there anyone out there with some ideas on this, pretty please? > >Thanks. > >Andries > > >On 2017-07-14 14:45, Andries Annema wrote: >> Hi all, >> >> Have been running postfix from the "ms.omniti.com" publisher for some > >> years now on r151014 without issues. >> Last week I updated my October 2016 r151014 system to the latest >> r151014-status, as a first step in the direction of upgrading to the >> latest LTS. I'm not actually there yet to upgrade to r151022; first I > >> want to make sure all my services and packages run flawlessly on that > >> version. Turns out that being careful pays off. >> >> In this update process, postfix got updated to >> 2.11.9-0.151014:20170214T224831Z. >> It still works, but /var/log/syslog is filled with a new line ever >> second stating: >> >> ".... [ID 947731 mail.crit] fatal: the Postfix mail system is already > >> running" >> >> And /var/svc/log/network-smtp-postfix:default.log is repeatedly >filled >> with line pairs like: >> "[ Jul 14 13:48:50 Executing start method ("/opt/omni/sbin/postfix >> start"). ] >> [ Jul 14 13:48:51 Stopping because service exited with an error. ] >> [ Jul 14 13:48:51 Executing start method ("/opt/omni/sbin/postfix >> start"). ] >> [ Jul 14 13:48:51 Stopping because service exited with an error. ] >> [ Jul 14 13:48:51 Failing too quickly, throttling. ]" >> >> Simply disabling and re-enabling the SMF service does not help. >> What did help was this: >> $ sudo svcadm disable postfix >> $ sudo fuser -k /var/lib/postfix/master.lock >> $ sudo rm /var/lib/postfix/master.lock >> $ sudo rm /var/spool/postfix/pid/master.pid >> $ sudo svcadm enable postfix >> >> That, however, was on r151014. >> On a separate, freshly installed r151022 test-system, I installed >this >> same postfix 2.11.9 package and the same issue emerged. >> However, the fix that worked on r151014, does not seem to work on >> r151022. >> Rebooting doesn't help either. >> >> Funny thing is: it does deliver email nicely, despite this restarting > >> issue. >> >> I tried downgrading to postfix 2.10.10: problem still exists. >> Tried downgrading further, to 2.10.2: not possible, because the >> manifest states a "incorporate" dependency on the >"entire at 11-0.151014" >> package. Hm, right... now I'm out of ideas. >> Any clues? >> >> Regards, >> Andries >> > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss IIRC the root problem was that some pid-file was left in place before restarting, e.g. by ungraceful reboot or timed-out stop with a kill. -- Typos courtesy of K-9 Mail on my Android From miniflowtrader at gmail.com Sun Jul 30 20:14:42 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Sun, 30 Jul 2017 16:14:42 -0400 Subject: [OmniOS-discuss] Loader On Mirrored Setup Message-ID: Hello all, If moving to Loader and using a mirrored setup is there anything that must be done to ensure that Loader is installed on both drives? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at miras.org Sun Jul 30 20:32:34 2017 From: mir at miras.org (Michael Rasmussen) Date: Sun, 30 Jul 2017 22:32:34 +0200 Subject: [OmniOS-discuss] Loader On Mirrored Setup In-Reply-To: References: Message-ID: <20170730223234.3f59ba30@sleipner.datanom.net> On Sun, 30 Jul 2017 16:14:42 -0400 Mini Trader wrote: > Hello all, > > If moving to Loader and using a mirrored setup is there anything that must > be done to ensure that Loader is installed on both drives? > > Thanks! I did the conversion from grub to loader on a mirrored rpool with success. The boot loader is automatically added to both disks in the mirror and testing by bios to change boot disk verified that I was able to boot from both disks in the mirror. -- 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 judge fined the jaywalker fifty dollars and told him if he was caught again, he would be thrown in jail. Fine today, cooler tomorrow. -------------- 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 Jul 30 23:13:42 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Sun, 30 Jul 2017 23:13:42 +0000 (UTC) Subject: [OmniOS-discuss] ANNOUNCEMENT - OmniOSce r151022k is out Message-ID: OmniOSce r151022k update now available. This is the weekly update for w/c 31st of July 2017 and contains security updates for the ncurses and bind userland packages. A reboot is not required although any applications using the ncurses or bind libraries should be restarted to pick up the changes. Full release notes can be found at https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md Any problems or questions, please get in touch via the Lobby at https://gitter.im/omniosorg/Lobby Happy updating, Andy and the rest of the OmniOSce team. -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From oliver.weinmann at telespazio-vega.de Mon Jul 31 07:05:14 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Mon, 31 Jul 2017 07:05:14 +0000 Subject: [OmniOS-discuss] Ldap crash causing system to hang fixed in illumos... Message-ID: <767138E0D064A148B03FE8EC1E9325A201343E3FCC@gedaevw60.a.space.corp> Hi Guys, I'm currently facing this bug under OmniOS 151022 and I just got informed that this has been fixed: https://www.illumos.org/issues/8543 As this bug is causing a complete system hang only a reboot helps. Can this maybe be implemented? Best Regards, Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From grzempek at gmail.com Mon Jul 31 08:25:36 2017 From: grzempek at gmail.com (Krzysztof Grzempa) Date: Mon, 31 Jul 2017 10:25:36 +0200 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: <2E9975D3-0B47-469F-928B-0FE7D1D6AA5C@kebe.com> <9932A3BD-813B-42AA-8A02-98E896A1328D@kebe.com> Message-ID: Hello Jens Currenty im out of home. I will try it out tommorow and report results... Thanks Chris 29.07.2017 00:28 "Jens Bauernfeind" napisa?(a): > Hi, > > what happens when you just try to update entire? > pkg update -nv entire > or > pkg install -nv entire > > Best Regards, > Jens > ________________________________________ > From: OmniOS-discuss [omnios-discuss-bounces at lists.omniti.com] on behalf > of Krzysztof Grzempa [grzempek at gmail.com] > Sent: Friday, July 28, 2017 10:50 > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] OmniOS r151014: failed to switch from > SunSSH to OpenSSH > > HI, > So, any other ideas ? I would like to avoid plain new installation > scenario :) > > Regards, > Kris > > 2017-07-28 1:29 GMT+02:00 Dan McDonald @kebe.com>>: > Yeah that's right. Sorry -- had to ask. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Jul 27, 2017, at 4:36 PM, Krzysztof Grzempa grzempek at gmail.com>> wrote: > > Hi Dan, > I had done prerequsities before i started: > > root at mojvps:/root# pkg list -v ca-bundle > FMRI > IFO > pkg://omnios/web/ca-bundle at 5.11-0.151014:20170414T020006Z > i-- > > there is 'April' certificates..right ? > > Kris > > 2017-07-27 22:28 GMT+02:00 Dan McDonald @kebe.com>>: > You're sure you're on the very latest 014? Could be lack of updated > certificates... > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Jul 27, 2017, at 4:14 PM, Krzysztof Grzempa grzempek at gmail.com>> wrote: > > Guys, > I will grab this thread as it is somehow similiar. I want to upgrade from > r151014 to r151022. I went throught all steps of: > https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 > but when Im performing upgrade: > > # /usr/bin/pkg update --be-name r151022 > > i got: > > root at mojvps:/root# /usr/bin/pkg update --be-name r151022 > Creating Plan (Running solver): | > pkg update: No solution was found to satisfy constraints > Plan Creation: Package solver has not found a solution to update to latest > available versions. > This may indicate an overly constrained set of packages are installed. > > latest incorporations: > > pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z > pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0. > 151022:20170510T210757Z > pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5. > 11,5.11-0.151022:20170510T212740Z > pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11- > 0.151022:20170511T001737Z > Dependency analysis is unable to determine exact cause. > Try specifying expected results to obtain more detailed error messages. > > > I set publisher correctly IHMO: > > root at mojvps:/root# pkg publisher > PUBLISHER TYPE STATUS P LOCATION > omnios origin online F > https://pkg.omniti.com/omnios/r151022/ > > > Any ideas ? > > I want to upgrade to CE after that. > > Thanks in advance > Kris > > 2017-07-24 17:01 GMT+02:00 Davide Poletto mailto:davide.poletto at gmail.com>>: > Thanks Andy, thanks Peter. > > So now OpenSSH is installed: > > root at nas01:/root# pkg list | grep ssh > network/openssh 7.4.1-0.151014 > i-- > network/openssh-server 7.4.1-0.151014 > i-- > root at nas01:/root# ssh -V > OpenSSH_7.4p1, OpenSSL 1.0.2k 26 Jan 2017 > > Totally my fault in not following the right Release Notes (I thought I > should have followed the destination version - r151022 - Release Notes > instead the one from where the upgrade process has to start, r151014 in my > case). > > Thanks again for pointing me on the right track. > > Best regards, Davide. > > On Mon, Jul 24, 2017 at 4:21 PM, Peter Tribble mailto:peter.tribble at gmail.com>> wrote: > > > On Mon, Jul 24, 2017 at 2:56 PM, Davide Poletto mailto:davide.poletto at gmail.com>> wrote: > Hello all, > > I'm facing a strange issue on a pretty standard OmniOS r151014 LTS box > fully updated (only Global Zone), following the "Upgrading to r151022" > instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 > required before any jump to OmniOS r151022 (my final target is OmniOS > Community Edition r151022i) I found that I'm unable to switch to OpenSSH as > per "Upgrading to OpenSSH from SunSSH" instructions on the same page: > > executing the suggested command: > > root at nas01:/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 > > fails with the message: > > pkg install: The following pattern(s) did not match any allowable > packages. Try > using a different matching pattern, or refreshing publisher information: > > pkg:/service/network/ssh-common > > The r151014 release notes > > https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 > > say > > /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject > pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh > pkg:/network/openssh pkg:/network/openssh-server > > Blindly I tried to omit the specific "ssh-common" package reject > > I think you were on the right track. > > but the result is not conforting me (maybe I tried a command in a totally > wrong way not understanding what the --reject options really mean): > > root at nas01:/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:/network/openssh > pkg:/network/openssh-server > > I think you have an extra --reject in there, so you've told it not to > install openssh. > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > > > _______________________________________________ > 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 Jul 31 09:19:29 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Mon, 31 Jul 2017 09:19:29 +0000 (UTC) Subject: [OmniOS-discuss] Ldap crash causing system to hang fixed in illumos... In-Reply-To: <767138E0D064A148B03FE8EC1E9325A201343E3FCC@gedaevw60.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A201343E3FCC@gedaevw60.a.space.corp> Message-ID: On Mon, 31 Jul 2017, Oliver Weinmann wrote: ; Hi Guys, ; ; I'm currently facing this bug under OmniOS 151022 and I just got informed that this has been fixed: ; ; https://www.illumos.org/issues/8543 ; ; As this bug is causing a complete system hang only a reboot helps. Can this maybe be implemented? ; ; Best Regards, ; Oliver Hi Oliver, I've opened an issue for you at https://github.com/omniosorg/illumos-omnios/issues/26 and you can track progress there. We plan to include this fix in next Monday's release but we're building a test update today and somebody will be in touch directly if you want to test it early. Regards, Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From oliver.weinmann at telespazio-vega.de Mon Jul 31 09:26:20 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Mon, 31 Jul 2017 09:26:20 +0000 Subject: [OmniOS-discuss] Ldap crash causing system to hang fixed in illumos... In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A201343E3FCC@gedaevw60.a.space.corp> Message-ID: <767138E0D064A148B03FE8EC1E9325A201343E811D@gedaevw60.a.space.corp> Hi Andy, These are great news. Thanks a lot. I'm happy to test. :) But first I guess I have to upgrade my current omnios 151022 to latest omniosce. Best Regards, Oliver -----Original Message----- From: Andy Fiddaman [mailto:omnios at citrus-it.net] Sent: Montag, 31. Juli 2017 11:19 To: Oliver Weinmann Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Ldap crash causing system to hang fixed in illumos... On Mon, 31 Jul 2017, Oliver Weinmann wrote: ; Hi Guys, ; ; I'm currently facing this bug under OmniOS 151022 and I just got informed that this has been fixed: ; ; https://www.illumos.org/issues/8543 ; ; As this bug is causing a complete system hang only a reboot helps. Can this maybe be implemented? ; ; Best Regards, ; Oliver Hi Oliver, I've opened an issue for you at https://github.com/omniosorg/illumos-omnios/issues/26 and you can track progress there. We plan to include this fix in next Monday's release but we're building a test update today and somebody will be in touch directly if you want to test it early. Regards, Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From al.slater at scluk.com Mon Jul 31 10:09:21 2017 From: al.slater at scluk.com (Al Slater) Date: Mon, 31 Jul 2017 11:09:21 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> Message-ID: <88df57e7-1849-5d65-6137-587c57940974@scluk.com> On 31/07/2017 11:07, Al Slater wrote: > On 30/07/2017 20:15, Peter Tribble wrote: >> > The following should get you going: >> > >> > https://www.prakashsurya.com/post/2017-02-06-creating-a-custom-amazon-ec2-ami-from-iso/ >> > > OK, I followed the above procedure and have produced an AMI. > > When I create an instance and try to boot it, I get the following in the > system log: SunOS Release 5.11 Version omnios-r151022-f9693432c2 64-bit Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. NOTICE: Cannot read the pool label from '/xpvd/xdf at 51728:a' NOTICE: spa_import_rootpool: error 5 Cannot mount root on /xpvd/xdf at 51728:a fstype zfs panic[cpu0]/thread=fffffffffbc38560: vfs_mountroot: cannot mount root Warning - stack not written to the dump buffer fffffffffbc7ad70 genunix:vfs_mountroot+39b () fffffffffbc7adb0 genunix:main+138 () fffffffffbc7adc0 unix:_locore_start+90 () How can I fix this? -- Al Slater From peter.tribble at gmail.com Mon Jul 31 10:39:15 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Mon, 31 Jul 2017 11:39:15 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: <88df57e7-1849-5d65-6137-587c57940974@scluk.com> References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> <88df57e7-1849-5d65-6137-587c57940974@scluk.com> Message-ID: On Mon, Jul 31, 2017 at 11:09 AM, Al Slater wrote: > On 31/07/2017 11:07, Al Slater wrote: > > On 30/07/2017 20:15, Peter Tribble wrote: > >> > The following should get you going: > >> > > >> > https://www.prakashsurya.com/post/2017-02-06-creating-a- > custom-amazon-ec2-ami-from-iso/ > >> custom-amazon-ec2-ami-from-iso/> > > > > OK, I followed the above procedure and have produced an AMI. > > > > When I create an instance and try to boot it, I get the following in the > > system log: > > SunOS Release 5.11 Version omnios-r151022-f9693432c2 64-bit > > Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights > reserved. > > NOTICE: Cannot read the pool label from '/xpvd/xdf at 51728:a' > NOTICE: spa_import_rootpool: error 5 > > Cannot mount root on /xpvd/xdf at 51728:a fstype zfs > panic[cpu0]/thread=fffffffffbc38560: vfs_mountroot: cannot mount root > Warning - stack not written to the dump buffer > fffffffffbc7ad70 genunix:vfs_mountroot+39b () > fffffffffbc7adb0 genunix:main+138 () > fffffffffbc7adc0 unix:_locore_start+90 () > > > How can I fix this? > You're likely the first person down this path. Generically, this means that the device paths embedded in the pool don't match those provided by the "hardware" you're booting on. So the system thinks it should have a disk at /xpvd/xdf at 51728:a On my instance, I have: /dev/rdsk/c2t0d0s0 -> ../../devices/xpvd/xdf at 51712:a,raw In other words, 51712 not 51728. For this to work, you have to set up your xen instance to exactly mirror what EC2 provides. Somehow it's gotten mixed up. In your configuration, did you use xvda? I think 51728 is what you get if you use xvdb for the disk, which won't work. I had: disk=[ 'file:/home/ptribble/iso/tribblix-0m20.1.iso,hdb:cdrom,r', 'file:/root/ami-template.img,xvda,w' ] -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From al.slater at scluk.com Mon Jul 31 10:58:24 2017 From: al.slater at scluk.com (Al Slater) Date: Mon, 31 Jul 2017 11:58:24 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> <88df57e7-1849-5d65-6137-587c57940974@scluk.com> Message-ID: <16c1350b-7284-e4f6-40ad-1a66b03b484a@scluk.com> On 31/07/2017 11:39, Peter Tribble wrote: > > > On Mon, Jul 31, 2017 at 11:09 AM, Al Slater > wrote: > > On 31/07/2017 11:07, Al Slater wrote: > > On 30/07/2017 20:15, Peter Tribble wrote: > >> > The following should get you going: > >> > > >> > https://www.prakashsurya.com/post/2017-02-06-creating-a-custom-amazon-ec2-ami-from-iso/ > > >> > > > > > OK, I followed the above procedure and have produced an AMI. > > > > When I create an instance and try to boot it, I get the following in the > > system log: > > SunOS Release 5.11 Version omnios-r151022-f9693432c2 64-bit > > Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights > reserved. > > NOTICE: Cannot read the pool label from '/xpvd/xdf at 51728:a' > NOTICE: spa_import_rootpool: error 5 > > Cannot mount root on /xpvd/xdf at 51728:a fstype zfs > panic[cpu0]/thread=fffffffffbc38560: vfs_mountroot: cannot mount root > Warning - stack not written to the dump buffer > fffffffffbc7ad70 genunix:vfs_mountroot+39b () > fffffffffbc7adb0 genunix:main+138 () > fffffffffbc7adc0 unix:_locore_start+90 () > > > How can I fix this? > > > You're likely the first person down this path. > > Generically, this means that the device paths embedded in the pool > don't match those provided by the "hardware" you're booting on. > > So the system thinks it should have a disk at /xpvd/xdf at 51728:a > > On my instance, I have: > > /dev/rdsk/c2t0d0s0 -> ../../devices/xpvd/xdf at 51712:a,raw > > In other words, 51712 not 51728. > > For this to work, you have to set up your xen instance to exactly mirror > what EC2 provides. Somehow it's gotten mixed up. In your configuration, > did you use xvda? I think 51728 is what you get if you use xvdb for the > disk, > which won't work. I had: > > disk=[ 'file:/home/ptribble/iso/tribblix-0m20.1.iso,hdb:cdrom,r', > 'file:/root/ami-template.img,xvda,w' ] > Thanks Peter, I see what happened... I started off with the instructions from https://wiki.openindiana.org/oi/Creating+OpenIndiana+EC2+image Then changed to following the instructions at https://www.prakashsurya.com/post/2017-02-06-creating-a-custom-amazon-ec2-ami-from-iso/ while neglecting to change the disks line in my xen config. Oh well, starting again... -- Al Slater From hasslerd at gmx.li Mon Jul 31 12:18:06 2017 From: hasslerd at gmx.li (Dominik Hassler) Date: Mon, 31 Jul 2017 14:18:06 +0200 Subject: [OmniOS-discuss] Ldap crash causing system to hang fixed in illumos... In-Reply-To: <767138E0D064A148B03FE8EC1E9325A201343E811D@gedaevw60.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A201343E3FCC@gedaevw60.a.space.corp> <767138E0D064A148B03FE8EC1E9325A201343E811D@gedaevw60.a.space.corp> Message-ID: Hi Oliver, a pkg archive containing an updated system/library is available: https://downloads.omniosce.org/pkg/system_library_8543.p5p Please provide feedback as soon as you could test it. Thanks. Regards, Dominik On 07/31/2017 11:26 AM, Oliver Weinmann wrote: > Hi Andy, > > These are great news. Thanks a lot. I'm happy to test. :) > > But first I guess I have to upgrade my current omnios 151022 to latest omniosce. > > Best Regards, > Oliver > > -----Original Message----- > From: Andy Fiddaman [mailto:omnios at citrus-it.net] > Sent: Montag, 31. Juli 2017 11:19 > To: Oliver Weinmann > Cc: omnios-discuss > Subject: Re: [OmniOS-discuss] Ldap crash causing system to hang fixed in illumos... > > > On Mon, 31 Jul 2017, Oliver Weinmann wrote: > > ; Hi Guys, > ; > ; I'm currently facing this bug under OmniOS 151022 and I just got informed that this has been fixed: > ; > ; https://www.illumos.org/issues/8543 > ; > ; As this bug is causing a complete system hang only a reboot helps. Can this maybe be implemented? > ; > ; Best Regards, > ; Oliver > > Hi Oliver, > > I've opened an issue for you at > https://github.com/omniosorg/illumos-omnios/issues/26 > and you can track progress there. > > We plan to include this fix in next Monday's release but we're building a test update today and somebody will be in touch directly if you want to test it early. > > Regards, > > Andy > > -- > Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From davide.poletto at gmail.com Mon Jul 31 15:14:35 2017 From: davide.poletto at gmail.com (Davide Poletto) Date: Mon, 31 Jul 2017 17:14:35 +0200 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: <2E9975D3-0B47-469F-928B-0FE7D1D6AA5C@kebe.com> <9932A3BD-813B-42AA-8A02-98E896A1328D@kebe.com> Message-ID: Hello all, just a follow up about the upgrade from OmniOS r151014 to OmniOSce r151022 (r151022i) via OmniOS r151022: it was flawless in my case...the only additional step it required before the final pkg update -rv documented step (so the system was still on OmniOS r151022) was the mandatory update of pkg(5) package: /usr/bin/pkg update -rv WARNING: pkg(5) appears to be out of date, and should be updated before running update. Please update pkg(5) by executing 'pkg install pkg:/package/pkg' as a privileged user and then retry the update. root at nas01:~# pkg install pkg:/package/pkg Packages to update: 1 Create boot environment: No Create backup boot environment: Yes DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 1/1 42/42 1.2/1.2 430k/s PHASE ITEMS Removing old actions 1/1 Installing new actions 1/1 Updating modified actions 43/43 Updating package state database Done Updating package cache 1/1 Updating image state Done Creating fast lookup database Done Reading search index Done Updating search index 1/1 Updating package cache 1/1 I'm pretty sure that, when the system still was on OmniOS r151022 (so when the publisher was still pkg.omniti.com/omnios/r151022/), the system was also fully up-to-date...I remember I did a pkg update -nv to check its status...but no updates were necessary (so the pkg(5) update's requirement reported above probably is a direct consequence of the publisher repository change from pkg.omniti.com/omnios/r151022/ to pkg.omniosce.org/r151022/core/ which is the mandatory step prior of the final pkg update -rv command execution). Worth to mention that additional step on the https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md#upgrading-from-omniti-released-r151022 paragraph? Davide. On Mon, Jul 31, 2017 at 10:25 AM, Krzysztof Grzempa wrote: > Hello Jens > Currenty im out of home. > I will try it out tommorow and report results... > > Thanks > Chris > > 29.07.2017 00:28 "Jens Bauernfeind" > napisa?(a): > >> Hi, >> >> what happens when you just try to update entire? >> pkg update -nv entire >> or >> pkg install -nv entire >> >> Best Regards, >> Jens >> ________________________________________ >> From: OmniOS-discuss [omnios-discuss-bounces at lists.omniti.com] on behalf >> of Krzysztof Grzempa [grzempek at gmail.com] >> Sent: Friday, July 28, 2017 10:50 >> To: omnios-discuss at lists.omniti.com >> Subject: Re: [OmniOS-discuss] OmniOS r151014: failed to switch from >> SunSSH to OpenSSH >> >> HI, >> So, any other ideas ? I would like to avoid plain new installation >> scenario :) >> >> Regards, >> Kris >> >> 2017-07-28 1:29 GMT+02:00 Dan McDonald > @kebe.com>>: >> Yeah that's right. Sorry -- had to ask. >> >> Dan >> >> Sent from my iPhone (typos, autocorrect, and all) >> >> On Jul 27, 2017, at 4:36 PM, Krzysztof Grzempa > > wrote: >> >> Hi Dan, >> I had done prerequsities before i started: >> >> root at mojvps:/root# pkg list -v ca-bundle >> FMRI >> IFO >> pkg://omnios/web/ca-bundle at 5.11-0.151014:20170414T020006Z >> i-- >> >> there is 'April' certificates..right ? >> >> Kris >> >> 2017-07-27 22:28 GMT+02:00 Dan McDonald > @kebe.com>>: >> You're sure you're on the very latest 014? Could be lack of updated >> certificates... >> >> Dan >> >> Sent from my iPhone (typos, autocorrect, and all) >> >> On Jul 27, 2017, at 4:14 PM, Krzysztof Grzempa > > wrote: >> >> Guys, >> I will grab this thread as it is somehow similiar. I want to upgrade from >> r151014 to r151022. I went throught all steps of: >> https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 >> but when Im performing upgrade: >> >> # /usr/bin/pkg update --be-name r151022 >> >> i got: >> >> root at mojvps:/root# /usr/bin/pkg update --be-name r151022 >> Creating Plan (Running solver): | >> pkg update: No solution was found to satisfy constraints >> Plan Creation: Package solver has not found a solution to update to >> latest available versions. >> This may indicate an overly constrained set of packages are installed. >> >> latest incorporations: >> >> pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z >> pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.15102 >> 2:20170510T210757Z >> pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11, >> 5.11-0.151022:20170510T212740Z >> pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0. >> 151022:20170511T001737Z >> Dependency analysis is unable to determine exact cause. >> Try specifying expected results to obtain more detailed error messages. >> >> >> I set publisher correctly IHMO: >> >> root at mojvps:/root# pkg publisher >> PUBLISHER TYPE STATUS P LOCATION >> omnios origin online F >> https://pkg.omniti.com/omnios/r151022/ >> >> >> Any ideas ? >> >> I want to upgrade to CE after that. >> >> Thanks in advance >> Kris >> >> 2017-07-24 17:01 GMT+02:00 Davide Poletto > to:davide.poletto at gmail.com>>: >> Thanks Andy, thanks Peter. >> >> So now OpenSSH is installed: >> >> root at nas01:/root# pkg list | grep ssh >> network/openssh 7.4.1-0.151014 >> i-- >> network/openssh-server 7.4.1-0.151014 >> i-- >> root at nas01:/root# ssh -V >> OpenSSH_7.4p1, OpenSSL 1.0.2k 26 Jan 2017 >> >> Totally my fault in not following the right Release Notes (I thought I >> should have followed the destination version - r151022 - Release Notes >> instead the one from where the upgrade process has to start, r151014 in my >> case). >> >> Thanks again for pointing me on the right track. >> >> Best regards, Davide. >> >> On Mon, Jul 24, 2017 at 4:21 PM, Peter Tribble > > wrote: >> >> >> On Mon, Jul 24, 2017 at 2:56 PM, Davide Poletto > > wrote: >> Hello all, >> >> I'm facing a strange issue on a pretty standard OmniOS r151014 LTS box >> fully updated (only Global Zone), following the "Upgrading to r151022" >> instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 >> required before any jump to OmniOS r151022 (my final target is OmniOS >> Community Edition r151022i) I found that I'm unable to switch to OpenSSH as >> per "Upgrading to OpenSSH from SunSSH" instructions on the same page: >> >> executing the suggested command: >> >> root at nas01:/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 >> >> fails with the message: >> >> pkg install: The following pattern(s) did not match any allowable >> packages. Try >> using a different matching pattern, or refreshing publisher information: >> >> pkg:/service/network/ssh-common >> >> The r151014 release notes >> >> https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 >> >> say >> >> /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject >> pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh >> pkg:/network/openssh pkg:/network/openssh-server >> >> Blindly I tried to omit the specific "ssh-common" package reject >> >> I think you were on the right track. >> >> but the result is not conforting me (maybe I tried a command in a totally >> wrong way not understanding what the --reject options really mean): >> >> root at nas01:/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:/network/openssh >> pkg:/network/openssh-server >> >> I think you have an extra --reject in there, so you've told it not to >> install openssh. >> >> -- >> -Peter Tribble >> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ >> >> >> _______________________________________________ >> 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 peter.tribble at gmail.com Mon Jul 31 15:15:08 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Mon, 31 Jul 2017 16:15:08 +0100 Subject: [OmniOS-discuss] Loader On Mirrored Setup In-Reply-To: References: Message-ID: On Sun, Jul 30, 2017 at 9:14 PM, Mini Trader wrote: > Hello all, > > If moving to Loader and using a mirrored setup is there anything that must > be done to ensure that Loader is installed on both drives? > This should be automatic. Note that the bootadm install-bootloader command works on pools, not disks, so if you have a mirrored pool it will do all sides of the mirror. If you replace one of the drives then you'll have to run bootadm install-bootloader on the pool again and it will put the loader on the replacement drive for you. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Mon Jul 31 15:37:44 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 31 Jul 2017 15:37:44 +0000 Subject: [OmniOS-discuss] Loader On Mirrored Setup In-Reply-To: References: Message-ID: Is this the suggested command to use because it wasn't mentioned anywhere on the loader wiki. On Mon, Jul 31, 2017 at 11:15 AM Peter Tribble wrote: > > > On Sun, Jul 30, 2017 at 9:14 PM, Mini Trader > wrote: > >> Hello all, >> >> If moving to Loader and using a mirrored setup is there anything that >> must be done to ensure that Loader is installed on both drives? >> > > This should be automatic. Note that the bootadm install-bootloader > command works on pools, not disks, so if you have a mirrored pool > it will do all sides of the mirror. > > If you replace one of the drives then you'll have to run bootadm > install-bootloader > on the pool again and it will put the loader on the replacement drive for > you. > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From an3s.annema at gmail.com Mon Jul 31 17:54:51 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Mon, 31 Jul 2017 19:54:51 +0200 Subject: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH In-Reply-To: References: <2E9975D3-0B47-469F-928B-0FE7D1D6AA5C@kebe.com> <9932A3BD-813B-42AA-8A02-98E896A1328D@kebe.com> Message-ID: Could this be in any way related to the issue I reported recently (http://lists.omniti.com/pipermail/omnios-discuss/2017-July/009079.html) where I tried to run "pkglint" in order to prepare an IPS package and got a "MemoryError" with the specific statement that "This is an internal error in pkg(5) version ..."? Not sure if it does, because I got this error on a freshly installed r151022 "vanilla" system, so no upgrade from r151014 or anything. Also, if I run "pkg install pkg:/package/pkg" now on that system, it responds with "No updates necessary for this image", so I doubt it is really related. However, I couldn't help but ask, as I haven't received any response on the other matter yet and both are related to "pkg"... Andries On 2017-07-31 17:14, Davide Poletto wrote: > Hello all, just a follow up about the upgrade from OmniOS r151014 to > OmniOSce r151022 (r151022i) via OmniOS r151022: it was flawless in my > case...the only additional step it required before the final pkg > update -rv documented step (so the system was still on OmniOS r151022) > was the mandatory update of pkg(5) package: > > /usr/bin/pkg update -rv > WARNING: pkg(5) appears to be out of date, and should be updated before > running update. Please update pkg(5) by executing 'pkg install > pkg:/package/pkg' as a privileged user and then retry the update. > > root at nas01:~# pkg install pkg:/package/pkg > Packages to update: 1 > Create boot environment: No > Create backup boot environment: Yes > > DOWNLOAD PKGS FILES XFER (MB) SPEED > Completed 1/1 42/42 1.2/1.2 430k/s > > PHASE ITEMS > Removing old actions 1/1 > Installing new actions 1/1 > Updating modified actions 43/43 > Updating package state database Done > Updating package cache 1/1 > Updating image state Done > Creating fast lookup database Done > Reading search index Done > Updating search index 1/1 > Updating package cache 1/1 > > I'm pretty sure that, when the system still was on OmniOS r151022 (so > when the publisher was still pkg.omniti.com/omnios/r151022/ > ), the system was also fully > up-to-date...I remember I did a pkg update -nv to check its > status...but no updates were necessary (so the pkg(5) update's > requirement reported above probably is a direct consequence of the > publisher repository change from pkg.omniti.com/omnios/r151022/ > to > pkg.omniosce.org/r151022/core/ > which is the mandatory step prior of the final pkg update -rv command > execution). > > Worth to mention that additional step on the > https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md#upgrading-from-omniti-released-r151022 > paragraph? > > Davide. > > On Mon, Jul 31, 2017 at 10:25 AM, Krzysztof Grzempa > > wrote: > > Hello Jens > Currenty im out of home. > I will try it out tommorow and report results... > > Thanks > Chris > > 29.07.2017 00:28 "Jens Bauernfeind" > > napisa?(a): > > Hi, > > what happens when you just try to update entire? > pkg update -nv entire > or > pkg install -nv entire > > Best Regards, > Jens > ________________________________________ > From: OmniOS-discuss [omnios-discuss-bounces at lists.omniti.com > ] on behalf of > Krzysztof Grzempa [grzempek at gmail.com ] > Sent: Friday, July 28, 2017 10:50 > To: omnios-discuss at lists.omniti.com > > Subject: Re: [OmniOS-discuss] OmniOS r151014: failed to switch > from SunSSH to OpenSSH > > HI, > So, any other ideas ? I would like to avoid plain new > installation scenario :) > > Regards, > Kris > > 2017-07-28 1:29 GMT+02:00 Dan McDonald >>: > Yeah that's right. Sorry -- had to ask. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Jul 27, 2017, at 4:36 PM, Krzysztof Grzempa > >> wrote: > > Hi Dan, > I had done prerequsities before i started: > > root at mojvps:/root# pkg list -v ca-bundle > FMRI IFO > pkg://omnios/web/ca-bundle at 5.11-0.151014:20170414T020006Z > i-- > > there is 'April' certificates..right ? > > Kris > > 2017-07-27 22:28 GMT+02:00 Dan McDonald >>: > You're sure you're on the very latest 014? Could be lack of > updated certificates... > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Jul 27, 2017, at 4:14 PM, Krzysztof Grzempa > >> wrote: > > Guys, > I will grab this thread as it is somehow similiar. I want to > upgrade from r151014 to r151022. I went throught all steps of: > https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 > > but when Im performing upgrade: > > # /usr/bin/pkg update --be-name r151022 > > i got: > > root at mojvps:/root# /usr/bin/pkg update --be-name r151022 > Creating Plan (Running solver): | > pkg update: No solution was found to satisfy constraints > Plan Creation: Package solver has not found a solution to > update to latest available versions. > This may indicate an overly constrained set of packages are > installed. > > latest incorporations: > > pkg://omnios/entire at 11,5.11-0.151022:20170511T002513Z > > pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151022:20170510T210757Z > > pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151022:20170510T212740Z > > pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151022:20170511T001737Z > Dependency analysis is unable to determine exact cause. > Try specifying expected results to obtain more detailed error > messages. > > > I set publisher correctly IHMO: > > root at mojvps:/root# pkg publisher > PUBLISHER TYPE STATUS P LOCATION > omnios origin online F > https://pkg.omniti.com/omnios/r151022/ > > > > Any ideas ? > > I want to upgrade to CE after that. > > Thanks in advance > Kris > > 2017-07-24 17:01 GMT+02:00 Davide Poletto > >>: > Thanks Andy, thanks Peter. > > So now OpenSSH is installed: > > root at nas01:/root# pkg list | grep ssh > network/openssh 7.4.1-0.151014 i-- > network/openssh-server 7.4.1-0.151014 i-- > root at nas01:/root# ssh -V > OpenSSH_7.4p1, OpenSSL 1.0.2k 26 Jan 2017 > > Totally my fault in not following the right Release Notes (I > thought I should have followed the destination version - > r151022 - Release Notes instead the one from where the upgrade > process has to start, r151014 in my case). > > Thanks again for pointing me on the right track. > > Best regards, Davide. > > On Mon, Jul 24, 2017 at 4:21 PM, Peter Tribble > >> wrote: > > > On Mon, Jul 24, 2017 at 2:56 PM, Davide Poletto > >> wrote: > Hello all, > > I'm facing a strange issue on a pretty standard OmniOS r151014 > LTS box fully updated (only Global Zone), following the > "Upgrading to r151022" instructions at > https://omnios.omniti.com/wiki.php/Upgrade_to_r151022 > > required before any jump to OmniOS r151022 (my final target is > OmniOS Community Edition r151022i) I found that I'm unable to > switch to OpenSSH as per "Upgrading to OpenSSH from SunSSH" > instructions on the same page: > > executing the suggested command: > > root at nas01:/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 > > fails with the message: > > pkg install: The following pattern(s) did not match any > allowable packages. Try > using a different matching pattern, or refreshing publisher > information: > > pkg:/service/network/ssh-common > > The r151014 release notes > > https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 > > > say > > /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh > --reject pkg:/network/ssh/ssh-key --reject > pkg:/service/network/ssh pkg:/network/openssh > pkg:/network/openssh-server > > Blindly I tried to omit the specific "ssh-common" package reject > > I think you were on the right track. > > but the result is not conforting me (maybe I tried a command > in a totally wrong way not understanding what the --reject > options really mean): > > root at nas01:/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:/network/openssh > pkg:/network/openssh-server > > I think you have an extra --reject in there, so you've told it > not to > install openssh. > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > > > _______________________________________________ > 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 > > > > > > _______________________________________________ > 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 an3s.annema at gmail.com Mon Jul 31 18:21:28 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Mon, 31 Jul 2017 20:21:28 +0200 Subject: [OmniOS-discuss] Postfix service: syslog reports "fatal: the Postfix mail system is already running" every second In-Reply-To: References: <968cced0-05d0-a975-2ddf-134fe3a6656a@gmail.com> Message-ID: <3b467cec-0599-8374-7d6a-22e9a20955a6@gmail.com> Thanks, Jim. That is indeed the suggested cause that I find all over the web, however even if I stop the postfix-service, then manually delete the .pid and .lock file and then restart the service, it still reports that it's already running. I don't see how it could be. Also, the very same package worked flawlessly on r151014, but now on r151022 it starts bugging me. On 2017-07-30 22:00, Jim Klimov wrote: > On July 30, 2017 5:42:31 PM GMT+02:00, Andries Annema wrote: >> In the mean time I tried upgrading the separate test-system from >> r151022 >> "vanilla" to the CE-edition - r151022i by now - hoping this might >> somehow also solve the below postfix "already running" error. But, it >> didn't. >> >> Again I tried the solution that worked on r151014 and also a reboot, >> but >> without success. >> >> This "Postfix mail system is already running"-issue is all over the >> internet - not specifically on Solarish-systems, that is - but I am >> clearly missing something here, as I don't seem to get the issue out of >> >> there. >> >> Is there anyone out there with some ideas on this, pretty please? >> >> Thanks. >> >> Andries >> >> >> On 2017-07-14 14:45, Andries Annema wrote: >>> Hi all, >>> >>> Have been running postfix from the "ms.omniti.com" publisher for some >>> years now on r151014 without issues. >>> Last week I updated my October 2016 r151014 system to the latest >>> r151014-status, as a first step in the direction of upgrading to the >>> latest LTS. I'm not actually there yet to upgrade to r151022; first I >>> want to make sure all my services and packages run flawlessly on that >>> version. Turns out that being careful pays off. >>> >>> In this update process, postfix got updated to >>> 2.11.9-0.151014:20170214T224831Z. >>> It still works, but /var/log/syslog is filled with a new line ever >>> second stating: >>> >>> ".... [ID 947731 mail.crit] fatal: the Postfix mail system is already >>> running" >>> >>> And /var/svc/log/network-smtp-postfix:default.log is repeatedly >> filled >>> with line pairs like: >>> "[ Jul 14 13:48:50 Executing start method ("/opt/omni/sbin/postfix >>> start"). ] >>> [ Jul 14 13:48:51 Stopping because service exited with an error. ] >>> [ Jul 14 13:48:51 Executing start method ("/opt/omni/sbin/postfix >>> start"). ] >>> [ Jul 14 13:48:51 Stopping because service exited with an error. ] >>> [ Jul 14 13:48:51 Failing too quickly, throttling. ]" >>> >>> Simply disabling and re-enabling the SMF service does not help. >>> What did help was this: >>> $ sudo svcadm disable postfix >>> $ sudo fuser -k /var/lib/postfix/master.lock >>> $ sudo rm /var/lib/postfix/master.lock >>> $ sudo rm /var/spool/postfix/pid/master.pid >>> $ sudo svcadm enable postfix >>> >>> That, however, was on r151014. >>> On a separate, freshly installed r151022 test-system, I installed >> this >>> same postfix 2.11.9 package and the same issue emerged. >>> However, the fix that worked on r151014, does not seem to work on >>> r151022. >>> Rebooting doesn't help either. >>> >>> Funny thing is: it does deliver email nicely, despite this restarting >>> issue. >>> >>> I tried downgrading to postfix 2.10.10: problem still exists. >>> Tried downgrading further, to 2.10.2: not possible, because the >>> manifest states a "incorporate" dependency on the >> "entire at 11-0.151014" >>> package. Hm, right... now I'm out of ideas. >>> Any clues? >>> >>> Regards, >>> Andries >>> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > IIRC the root problem was that some pid-file was left in place before restarting, e.g. by ungraceful reboot or timed-out stop with a kill. > -- > Typos courtesy of K-9 Mail on my Android From al.slater at scluk.com Mon Jul 31 20:05:17 2017 From: al.slater at scluk.com (Al Slater) Date: Mon, 31 Jul 2017 21:05:17 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: <16c1350b-7284-e4f6-40ad-1a66b03b484a@scluk.com> References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> <88df57e7-1849-5d65-6137-587c57940974@scluk.com> <16c1350b-7284-e4f6-40ad-1a66b03b484a@scluk.com> Message-ID: On 31/07/17 11:58, Al Slater wrote: > On 31/07/2017 11:39, Peter Tribble wrote: >> >> >> On Mon, Jul 31, 2017 at 11:09 AM, Al Slater > > wrote: >> >> On 31/07/2017 11:07, Al Slater wrote: >> > On 30/07/2017 20:15, Peter Tribble wrote: >> >> > The following should get you going: >> >> > >> >> > https://www.prakashsurya.com/post/2017-02-06-creating-a-custom-amazon-ec2-ami-from-iso/ >> >> >> > > >> > >> > OK, I followed the above procedure and have produced an AMI. >> > >> > When I create an instance and try to boot it, I get the following in the >> > system log: >> >> SunOS Release 5.11 Version omnios-r151022-f9693432c2 64-bit >> >> Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights >> reserved. >> >> NOTICE: Cannot read the pool label from '/xpvd/xdf at 51728:a' >> NOTICE: spa_import_rootpool: error 5 >> >> Cannot mount root on /xpvd/xdf at 51728:a fstype zfs >> panic[cpu0]/thread=fffffffffbc38560: vfs_mountroot: cannot mount root >> Warning - stack not written to the dump buffer >> fffffffffbc7ad70 genunix:vfs_mountroot+39b () >> fffffffffbc7adb0 genunix:main+138 () >> fffffffffbc7adc0 unix:_locore_start+90 () >> >> >> How can I fix this? >> >> >> You're likely the first person down this path. >> >> Generically, this means that the device paths embedded in the pool >> don't match those provided by the "hardware" you're booting on. >> >> So the system thinks it should have a disk at /xpvd/xdf at 51728:a >> >> On my instance, I have: >> >> /dev/rdsk/c2t0d0s0 -> ../../devices/xpvd/xdf at 51712:a,raw >> >> In other words, 51712 not 51728. >> >> For this to work, you have to set up your xen instance to exactly mirror >> what EC2 provides. Somehow it's gotten mixed up. In your configuration, >> did you use xvda? I think 51728 is what you get if you use xvdb for the >> disk, >> which won't work. I had: >> >> disk=[ 'file:/home/ptribble/iso/tribblix-0m20.1.iso,hdb:cdrom,r', >> 'file:/root/ami-template.img,xvda,w' ] >> > > Thanks Peter, I see what happened... > > I started off with the instructions from > https://wiki.openindiana.org/oi/Creating+OpenIndiana+EC2+image > > Then changed to following the instructions at > https://www.prakashsurya.com/post/2017-02-06-creating-a-custom-amazon-ec2-ami-from-iso/ > > while neglecting to change the disks line in my xen config. > > Oh well, starting again... An update for the list... With the correct disks line in the xen config file, the procedure above, with Peter's workaround for the xen networking panic, works fine. I have a working AMI now. One more question though, is there any way to enable an SMF service for the next reboot, but not immediately. Specifically, I want to enable the initial-boot service with a .initialboot file in place, then create a new AMI. I wist to use .initialboot to grab the instance configuration from amazon (hostname, root keys etc) and configure appropriately when the new instance starts. -- Al Slater From eric.sproul at circonus.com Mon Jul 31 20:30:56 2017 From: eric.sproul at circonus.com (Eric Sproul) Date: Mon, 31 Jul 2017 16:30:56 -0400 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> <88df57e7-1849-5d65-6137-587c57940974@scluk.com> <16c1350b-7284-e4f6-40ad-1a66b03b484a@scluk.com> Message-ID: On Mon, Jul 31, 2017 at 4:05 PM, Al Slater wrote: > One more question though, is there any way to enable an SMF service for > the next reboot, but not immediately. Specifically, I want to enable > the initial-boot service with a .initialboot file in place, then create > a new AMI. > > I wist to use .initialboot to grab the instance configuration from > amazon (hostname, root keys etc) and configure appropriately when the > new instance starts. Hi Al, The initial-boot service isn't really suitable for this sort of thing. You might want to check out pkg://omnios/system/management/ec2-credential which specifically handles setting up the credentials at first boot. That could be trivially extended[1] to set the system hostname and probably any other "standard" thing that operators want. Eric [1] https://github.com/omniosorg/omnios-build/blob/master/build/ec2-credential/files/install-ec2-credential From pasztor at sagv5.gyakg.u-szeged.hu Mon Jul 31 20:49:05 2017 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Mon, 31 Jul 2017 22:49:05 +0200 Subject: [OmniOS-discuss] initialboot Message-ID: <20170731204905.GB3872@linux.gyakg.u-szeged.hu> Hi, I hope you don't mind, but I started a new thread with this, since it seems a completly new topic. "Al Slater" ?rta 2017-07-31 21:05-kor: > One more question though, is there any way to enable an SMF service for > the next reboot, but not immediately. Specifically, I want to enable > the initial-boot service with a .initialboot file in place, then create > a new AMI. I don't completely understand. You want to enable initialboot after the boot was complete, and only after a certain amount of time? I'm not sure, what this initialboot exactly does, but it seems not a simple service, it's a milestone. Maybe, I would not mess with it. Otherwise, if I need a delay between the service and the boot, and it's important to remain "disabled" while it's not enabled: Create an @reboot cronjob. I don't remember which cron implementation is the default. On linux's vixie's cron the time can be @reboot. > I wist to use .initialboot to grab the instance configuration from > amazon (hostname, root keys etc) and configure appropriately when the > new instance starts. Again: I don't completely understand your scenario. You created one ami, and you want to "close it back", and clone it several times, so after it's first reboot, it should do the initalboot steps? Why do you want to wait? What I just found about the /.initialboot, it's a simple shell script. If you need to wait here, why not just put a sleep command into the beginning of the script? Or if you have to wait for some specific resource: Why don't poll it once per every 5 sec or so? Cheers, Gyu From al.slater at scluk.com Mon Jul 31 20:51:34 2017 From: al.slater at scluk.com (Al Slater) Date: Mon, 31 Jul 2017 21:51:34 +0100 Subject: [OmniOS-discuss] Omios, hvm and AWS In-Reply-To: References: <530a2705-2a3f-05a1-68f0-f3b83d695be4@scluk.com> <88df57e7-1849-5d65-6137-587c57940974@scluk.com> <16c1350b-7284-e4f6-40ad-1a66b03b484a@scluk.com> Message-ID: <69e3cbfe-4cc4-d630-b953-133cc0be8aab@scluk.com> On 31/07/17 21:30, Eric Sproul wrote: > On Mon, Jul 31, 2017 at 4:05 PM, Al Slater wrote: >> One more question though, is there any way to enable an SMF service for >> the next reboot, but not immediately. Specifically, I want to enable >> the initial-boot service with a .initialboot file in place, then create >> a new AMI. >> >> I wist to use .initialboot to grab the instance configuration from >> amazon (hostname, root keys etc) and configure appropriately when the >> new instance starts. > > Hi Al, > The initial-boot service isn't really suitable for this sort of thing. > You might want to check out > pkg://omnios/system/management/ec2-credential which specifically > handles setting up the credentials at first boot. That could be > trivially extended[1] to set the system hostname and probably any > other "standard" thing that operators want. > > Eric > > [1] https://github.com/omniosorg/omnios-build/blob/master/build/ec2-credential/files/install-ec2-credential Thanks for the pointer Eric. -- Al Slater From al.slater at scluk.com Mon Jul 31 21:24:57 2017 From: al.slater at scluk.com (Al Slater) Date: Mon, 31 Jul 2017 22:24:57 +0100 Subject: [OmniOS-discuss] initialboot In-Reply-To: <20170731204905.GB3872@linux.gyakg.u-szeged.hu> References: <20170731204905.GB3872@linux.gyakg.u-szeged.hu> Message-ID: <9b444d46-0b28-66c8-0f53-d8cbcb9cc77a@scluk.com> Hi, Sorry, I clearly didn't explain well enough. Normally, initial-boot is enabled in the iso/kayak image that is installed. When it is started on the first boot it runs /.initialboot and then disables itself. I was thinking that if there was some way to "re-enable" initial-boot, then I could drop a /.initialboot script, re-enable initial-boot and then shutdown before creating new AMI, such that when an instance based upon the new AMI was launched, it would run .initialboot. The problem is, enabling initial-boot immediately runs the .initialboot script and then disables itself. So, I hoped there was a way to enable the service such that it did not immediately enable, but was enabled so it would start after the next reboot. Al On 31/07/17 21:49, P?SZTOR Gy?rgy wrote: > Hi, > > I hope you don't mind, but I started a new thread with this, since it seems > a completly new topic. > > "Al Slater" ?rta 2017-07-31 21:05-kor: >> One more question though, is there any way to enable an SMF service for >> the next reboot, but not immediately. Specifically, I want to enable >> the initial-boot service with a .initialboot file in place, then create >> a new AMI. > > I don't completely understand. You want to enable initialboot after the > boot was complete, and only after a certain amount of time? > I'm not sure, what this initialboot exactly does, but it seems not a simple > service, it's a milestone. Maybe, I would not mess with it. > Otherwise, if I need a delay between the service and the boot, and it's > important to remain "disabled" while it's not enabled: > Create an @reboot cronjob. I don't remember which cron implementation is > the default. On linux's vixie's cron the time can be @reboot. > >> I wist to use .initialboot to grab the instance configuration from >> amazon (hostname, root keys etc) and configure appropriately when the >> new instance starts. > > Again: I don't completely understand your scenario. > You created one ami, and you want to "close it back", and clone it several > times, so after it's first reboot, it should do the initalboot steps? > Why do you want to wait? > What I just found about the /.initialboot, it's a simple shell script. > If you need to wait here, why not just put a sleep command into the > beginning of the script? > Or if you have to wait for some specific resource: Why don't poll it once > per every 5 sec or so? > > Cheers, > Gyu > From pasztor at sagv5.gyakg.u-szeged.hu Mon Jul 31 23:01:01 2017 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Tue, 1 Aug 2017 01:01:01 +0200 Subject: [OmniOS-discuss] initialboot In-Reply-To: <9b444d46-0b28-66c8-0f53-d8cbcb9cc77a@scluk.com> References: <20170731204905.GB3872@linux.gyakg.u-szeged.hu> <9b444d46-0b28-66c8-0f53-d8cbcb9cc77a@scluk.com> Message-ID: <20170731230101.GA4170@linux.gyakg.u-szeged.hu> Hi, "Al Slater" ?rta 2017-07-31 22:24-kor: > I was thinking that if there was some way to "re-enable" initial-boot, > then I could drop a /.initialboot script, re-enable initial-boot and > then shutdown before creating new AMI, such that when an instance based > upon the new AMI was launched, it would run .initialboot. > > The problem is, enabling initial-boot immediately runs the .initialboot > script and then disables itself. So, I hoped there was a way to enable > the service such that it did not immediately enable, but was enabled so > it would start after the next reboot. It's much cleaner now. I saw sg. in svcadm's man, about marking a service temporarily... which is in effect until the next reboot. But, a much simpler solution what I tested: I started my script with this: trap 'rm /tmp/x' SIGINT trap 'rm /tmp/x' SIGTERM while [ -f /tmp/x ]; do sleep 5 done And here follows your real script. Before you'd enable again initial-boot, just touch /tmp/x Maybe not the best workaround, but at least it works! ;) Cheers, Gyu