Re: [OmniOS-discuss] OmniOS r1510

[Dan McDonald]

> On Jul 9, 2018, at 6:33 AM, Lawrence Giam  wrote:
> 
> Hi All,
> 
> Can I check if Seagate 1200.2 (ST200FM0133) is supported by OmniOS R151014?

Even if OmniTI were still supporting OmniOS, r151014 would've been EOSLed by 
now.  See this old page:

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

for example.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] VEEAM backups to CIFS fail only on OmniOS hypercongerged VM

[Dan McDonald]

> On Jun 14, 2018, at 3:04 AM, Oliver Weinmann  wrote:
> I would be more than happy to use a zone instead of a full blown VM but since 
> there is no ISCSI and NFS server support in a Zone I have to stick with the 
> VM as we need NFS since the VM is also a datastore for a few VMs.

You rambled a bit here, so I'm not sure what exactly you're asking.  I do know 
that:

- CIFS-server-in-a-zone should work

- NFS-server-in-a-zone and iSCSI-target-in-a-zone are both not available right 
now.

There is purported to be a prototype of NFS-server-in-a-zone kicking around 
*somewhere* but that may have been tied up.  I'd watch distros, especially 
those working on file service, to see if that shows up at some point, where it 
can be upstreamed to illumos-gate (and then back down to illumos-omnios).

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Certificate weirdness with omniti-ms?

[Dan McDonald]

On Mon, May 07, 2018 at 10:14:40AM -0400, Dan McDonald wrote:
> I'd guess I need a new root CA cert for OmniTI-MS.  Where may I find this?

And the answer is:  Use the old one:

https://github.com/omniosorg/omnios-build/tree/r151022/build/ca-bundle/files

Thanks Andy F. for reminding me of that.

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Certificate weirdness with omniti-ms?

[Dan McDonald]

For OmniTI folks...

I'm trying to update my yes-still-uses-Omniti-MS home server to CE's new
r151026.  I encounter this, alas:

Planning linked: 0/4 done; 1 working: zone:webserver
Linked progress: -pkg: update failed (linked image exception(s)):

A 'update' operation failed for child 'zone:webserver' with an unexpected
return value of 1 and generated the following output:

pkg update: The certificate which issued this certificate: 
/C=US/ST=Maryland/O=OmniTI/OU=OmniTI Managed Services/CN=OmniTI Managed 
Services RPackage Signing Certificate/emailAddress=i...@omniti.com could not be 
found. The issuer is: /C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate 
Authority
The package involved is 
pkg://ms.omniti.com/omniti/server/apache24@2.4.33,5.11-0.151014:20180403T150105Z


I hadn't noticed this earlier because the newest Apache 2.4 update depends on
libxml 2.9.7 (which isn't in r151024).

I'd guess I need a new root CA cert for OmniTI-MS.  Where may I find this?

Thanks,
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Cannot install Non-Global Zone

[Dan McDonald]

You may have software installed dependent on a specific version of entire.  I 
can't tell you which one off the top of my head, but there are some well-known 
offenders in the old ms.omniti.com repo.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Cannot install Non-Global Zone

[Dan McDonald]

Use the -lv flags for pkg list.

Dan

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

> On Feb 19, 2018, at 3:02 PM, Software Information 
>  wrote:
> 
> Hi All 
> I have been trying to understand the reason for an error I have been getting 
> when I try to install a non-global zone. The error is below
> 
> pkg install: The following pattern(s) did not match any allowable packages.  
> Try
> using a different matching pattern, or refreshing publisher information:
> 
> entire@11-0.151022:20180108T221634Z
> ERROR: failed to install package
> 
> I did some research and I still don't understand why this is happening. I did 
> a pkg list entire in the Global and Non-Global zones and the version is the 
> same.
> 
> # pkg list entire
> NAME (PUBLISHER)  VERSION
> IFO
> entire11-0.151022
> i--
> 
> Could anyone help me out please?
> 
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Update error

[Dan McDonald]

Check the output of "pkg publisher" in both global and each lipkg zone.  Maybe 
you have one "omnios" publisher pointing to a different URL?

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Running on latest Xeon-Skylake servers?

[Dan McDonald]

Curious... has anyone here in OmniOS-land run bloody or current-stable on
very recent Intel Skylake server hardware?  For example:

https://www.supermicro.com/products/motherboard/Xeon/C620/X11DPi-NT.cfm

We're seeing some weirdness with SmartOS, and wanted to know if similar
weirdness was happening with anyone out there?

Thanks,
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Zone welcome messsage

[Dan McDonald]

On Mon, Jan 22, 2018 at 09:13:00PM -0500, Software Information wrote:
> Hi All
> I was just  wondering. I recently updated my host machine from r151020 to
> r151022.
> The welcome message on the host machine is fine but when I log on to the
> non-global zone, I still see the welcome message for r151020 below.
> 
> OmniOS 5.11 omnios-r151020-4151d05  March 2017
> 
> But whe I do a uname -a, in the non-global zone, I get :
> SunOS test-zone 5.11 omnios-r151022-f9693432c2 i86pc i386 i86pc
> 
> Is there any way to make the non-global zone show the correct welcome
> message?

If it's an ipkg zone, you'll have to "pkg update" inside the zone (and
possibly reboot it).  If it's an lipkg zone, make sure you're using the "-r"
flag when updating the global, OR use "pkg update" inside like an ipkg zone.

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Best way to share files with Mac?

[Dan McDonald]

I use NFS.

I either use automounter on MacOS  (i.e. /net/server//...) or now that I 
have Carbon Copy Cloner, I also use NFS URLs (nfs://server/), though I 
set up distinct ZFS datasets for CCC.

I see problems occasionally, but less so as time has gone on.  Seeing the 
._filename files (where Mac resource fork data is kept) on the OmniOS side of 
things is always weird, but not THAT weird.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] PERL booleans?

[Dan McDonald]

I upgraded my HDC to OmniOSce r151024, and did some nightly builds.  After 
re-rewhacking PERL_VERS, I managed to get a MOSTLY clean build save for:

> Begin forwarded message:
> 
> From: Dan McDonald 
> Subject: Nightly i386 Build of illumos-gate Failed.
> Date: November 6, 2017 at 11:41:49 PM EST
> To: dan...@nowhere.kebe.com
> 
> 
>  Nightly distributed build started:   Mon Nov  6 22:34:21 EST 2017 
>  Nightly distributed build completed: Mon Nov  6 23:41:49 EST 2017 
> 
>  Total build time 
> 
> real1:07:28
> 
>  Build environment 
> 
> /usr/bin/uname
> SunOS nowhere 5.11 omnios-r151024-c2a1589567 i86pc i386 i86pc



>  Build warnings (non-DEBUG) 
> 
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
> 
>  Elapsed build time (non-DEBUG) 

The file $SRC/cmd/hal/hald/hald_marshal.list uses "BOOL" and under an updated 
glib (which is in the new OmniOS) should be "BOOLEAN".

OmniOS has this fix now:

commit f1311a377c43d15cc090269298266c6daacb47ac
Author: citrus-it 
Date:   Wed Sep 20 07:59:04 2017 +

Replace deprecated glob marshal BOOL with BOOLEAN

I was curious if anyone who's not building on OmniOS has tried making this 
change? It should be a NOP on SmartOS because we don't use or even manifest 
hald.

Thanks,
Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Just enough X?

[Dan McDonald]

> On Nov 4, 2017, at 4:04 PM, Bob Friesenhahn  
> wrote:
> 
> I have X11 (without twm installed) from pkgsrc which is enough to run and 
> compile X11 programs.  It is not clear to me if you want the server-side of 
> X11, or want to use XDM, or if X11-client only is ok.

Sorry, I should've been clear.  i want the server-side of X11.  I have a 
1920x1200 monitor KVM'ed to my home server.  When I switch to it, I'd like to 
see all of the consoles for my zones (including global).

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Just enough X?

[Dan McDonald]

I apologize in advance for asking the community this in lieu of figuring it out 
myself.

I wish to run "Just enough X" on OmniOS to run twm and xterm.  Basically, I'd 
like console windows for all of my zones readily available.  I used to do this 
when I ran OI on my home server, and occasionally I miss that functionality.  
Please PLEASE do not turn this into a thread about window managers and, "WTF do 
you want to use twm, Dan?"  Any reasonable window manager can be swapped in for 
TWM, but I know TWM is simple and lightweight.

I'm thinking it's either pkgsrc, or an alternate IPS publisher exists.  Either 
works, but I'd like to hear from folks who've actually done it, if any exist.

Thanks,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS R151014 hardware support

[Dan McDonald]

> On Nov 2, 2017, at 5:56 AM, Lawrence Giam  wrote:
> 
> Hi All,
> 
> I know that OmniOS R151014 is old but I still have to use it. I am looking at 
> running OmniOS on top of ESXi 5.5 or 6.

I have to ask, why do you have to use '014?  What specific thing is tying you 
to it?  I can't think of anything rational that isn't old hardware.

> I would like to know if illumos support the new Intel Xeon Scalable and also 
> Intel C620 chipset?

I believe '014 supports the C620 chipset (620 is an older one, Sandy Bridge 
era, IIRC).

> I am stuck at choosing either a Dell PowerEdge R530 or PowerEdge R740.

R530 should be fine with '014 (modulo some possible edge-cases).  Not sure 
about the R740 with 014, though.

Seriously, if you're getting new HW, what's to stop you from upgrading OmniOS?

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Release 14 repo

[Dan McDonald]

Shoot.  Someone at OmniTI may need to whack the front ends or something else.

Dan

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

> On Oct 28, 2017, at 5:25 PM, Machine Man  wrote:
> 
> Thanks,
> 
> 
> I tried it and still getting:
> 
> 
> pkg: 0/1 catalogs successfully updated:
> 
> http protocol error: code: 404 reason: Not Found
> URL: 
> 'http://pkg.omniti.com/omnios/r151014/omnios/catalog/1/update.20170301T19Z.   
>      
> 
> C' (happened 4 times)
> 
> From: Dan McDonald 
> Sent: Saturday, October 28, 2017 3:31:47 PM
> To: Machine Man
> Cc: omnios-discuss@lists.omniti.com; Dan McDonald
> Subject: Re: [OmniOS-discuss] Release 14 repo
>  
> 
> 
> > On Oct 28, 2017, at 3:18 PM, Machine Man  wrote:
> > 
> > Is this still online? I am not able to update my last two machines by 
> > change over to OpenSSH before upgrading to OmniOS CE r22.
> 
> I see:
> 
> http://pkg.omniti.com/omnios/r151014/
> 
> is giving me an appropriate response.
> 
> > Are there any other hosted repos I can point to just to get the change over 
> > to openssh completed?
> > Is there a workaround?
> > I just updated a machines this past Sunday and it was still working.
> 
> I'd stop-and-restart the "pkg update" you were doing.  Maybe the 
> pkg.omniti.com server moved?
> 
> Dan
> 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Release 14 repo

[Dan McDonald]

> On Oct 28, 2017, at 3:18 PM, Machine Man  wrote:
> 
> Is this still online? I am not able to update my last two machines by change 
> over to OpenSSH before upgrading to OmniOS CE r22.

I see:

http://pkg.omniti.com/omnios/r151014/

is giving me an appropriate response.

> Are there any other hosted repos I can point to just to get the change over 
> to openssh completed?
> Is there a workaround?
> I just updated a machines this past Sunday and it was still working.

I'd stop-and-restart the "pkg update" you were doing.  Maybe the pkg.omniti.com 
server moved?

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] a few questions about omniosce/illumos/hardware

[Dan McDonald]

On Tue, Oct 10, 2017 at 09:39:59PM +, Jeff Stockett wrote:
> Tyan is making a new EPYC based server chassis that looks pretty slick (24 
> hotswap U.2 nvme drives directly connected to the CPU - no PLX expanders 
> required):
> 
> http://tyan.com/Barebones_TN70AB8026_B8026T70AE24HR



You may wish to expand the audience of this and ask on one of the illumos
lists.  What works there will work for OmniOS for sure.

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Fwd: Reminder & update: Oct 12 SmartOS/OmniOS/OI/illumos user meeting at Erlangen, Germany

[Dan McDonald]

Von: Peter Kelm 
Betreff: Reminder & update: Oct 12 SmartOS/OmniOS/OI/illumos user meeting at 
Erlangen, Germany
Datum: 3. Oktober 2017 um 11:43:25 MESZ
An: openindiana-discuss-ow...@openindiana.org, 
smartos-disc...@lists.smartos.org, omnios-discuss@lists.omniti.com


All,

Some momentum has built over the past weeks around the 
SmartOS/OmniOS/OI/illumos meetup. Erigones, a software company from Bratislava, 
Slovakia will join us to talk about their Danube Cloud product. This software 
is built upon SmartOS/ZFS/crossbow. Certainly an interesting alternative to 
Joyent Triton or Project FiFo…

Additionally we will talk about our experience deploying SmartOS for small size 
businesses, e.g. as an alternative to established VMWare setups.

Don’t miss out attending this event! Register today directly via meetup: 
https://www.meetup.com/de-DE/illumos-Meetup/ 
 or via eMail to: 
illumos-mee...@kelmmoyles.com 

Location:
  KelmMoyles office (at the IGZ Erlangen)
  Am Weichselgarten 7
  91058 Erlangen
  Germany

Date/Time:
  Oct 12, 2017, starting at 6:00pm

Participation is free.

Looking forward to seeing you at the event!

Best regards,

Peter

> Am 15.09.2017 um 11:15 schrieb Peter Kelm  >:
> 
> All,
> 
> We’d like to invite you to the SmartOS/OmniOS/OI/illumos user meeting at 
> Erlangen on Oct 12, 2017.
> 
> Location:
>   KelmMoyles office (at the IGZ Erlangen)
>   Am Weichselgarten 7
>   91058 Erlangen
>   Germany
> 
> Date/Time:
>   Oct 12, 2017, starting at 6:00pm
> 
> There is no firm agenda yet but please let us know what topics you’d be 
> interested in to make this meeting as productive and useful as it can be. 
> Your contributions are highly appreciated!
> 
> I’d expect that some of the questions below might come up:
> - How do you use SmartOS/OmniOS/OI/illumos today or how do you intend to use 
> it „tomorrow“?
> - What are the factors that drive your interest? Where do you see strengths 
> and weaknesses (vs. competing solutions)?
> - What are the „best practices“ that you’d like to share? (E.g. how do you 
> handle maintenance and updates for your deployment?)
> 
> Participation is of course free but we’d like to ask you to register via 
> eMail to: illumos-mee...@kelmmoyles.com 
> 
> FYI: The timing coincides with the IT-SA fair at Nuremberg, so you might want 
> to consider spending the day there before heading over to us: 
> https://www.it-sa.de 
> 
> We are very open to additional thoughts and suggestions, so please let us 
> know.
> 
> Looking forward to seeing you in October!
> 
> Peter
> 
> P.S. We haven’t setup a „meetup" group yet. Any volunteers?
> 
> Dipl.-Ing. Peter Kelm
> KelmMoyles - Tailored Engineering Marketing
> Am Weichselgarten 7 
> 91058 Erlangen
> T +49 (9132) 9060595 
> F +49 (9132) 9060596
> E peter.k...@kelmmoyles.com 
> 





___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Apache update on omniti-ms?

[Dan McDonald]

Some of us still use omniti-ms for things.  I know it's not a supported
publisher, but I'm curious about this Apache bug:

https://blog.fuzzing-project.org/60-Optionsbleed-HTTP-OPTIONS-method-can-leak-Apaches-server-memory.html

And whether or not the apache24 package will get a bump to fix this?

Thanks,
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Fwd: Invitation to the SmartOS/OmniOS/OI/illumos user meeting at Erlangen, Germany on October 12

[Dan McDonald]

Peter asked me to forward this to the list.

Dan

=

Von: Peter Kelm mailto:peter.k...@peterkelm.com>>
Betreff: Invitation to the SmartOS/OmniOS/OI/illumos user meeting at Erlangen, 
Germany on October 12
Datum: 15. September 2017 um 11:15:28 MESZ
An: openindiana-discuss-ow...@openindiana.org 
, 
smartos-disc...@lists.smartos.org , 
omnios-discuss@lists.omniti.com 


All,

We’d like to invite you to the SmartOS/OmniOS/OI/illumos user meeting at 
Erlangen on Oct 12, 2017.

Location:
  KelmMoyles office (at the IGZ Erlangen)
  Am Weichselgarten 7
  91058 Erlangen
  Germany

Date/Time:
  Oct 12, 2017, starting at 6:00pm

There is no firm agenda yet but please let us know what topics you’d be 
interested in to make this meeting as productive and useful as it can be. Your 
contributions are highly appreciated!

I’d expect that some of the questions below might come up:
- How do you use SmartOS/OmniOS/OI/illumos today or how do you intend to use it 
„tomorrow“?
- What are the factors that drive your interest? Where do you see strengths and 
weaknesses (vs. competing solutions)?
- What are the „best practices“ that you’d like to share? (E.g. how do you 
handle maintenance and updates for your deployment?)

Participation is of course free but we’d like to ask you to register via eMail 
to: illumos-mee...@kelmmoyles.com 

FYI: The timing coincides with the IT-SA fair at Nuremberg, so you might want 
to consider spending the day there before heading over to us: 
https://www.it-sa.de 

We are very open to additional thoughts and suggestions, so please let us know.

Looking forward to seeing you in October!

Peter

P.S. We haven’t setup a „meetup" group yet. Any volunteers?

Dipl.-Ing. Peter Kelm
KelmMoyles - Tailored Engineering Marketing
Am Weichselgarten 7 
91058 Erlangen
T +49 (9132) 9060595 
F +49 (9132) 9060596
E peter.k...@kelmmoyles.com 





___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Supported architectures

[Dan McDonald]

On Mon, Sep 11, 2017 at 06:27:12PM +0200, Sylvain Leroux wrote:
> I was asked about the supported architecture for OmniOSce.
> 
> As far as I can tell, this was not mentioned on the
> http://www.omniosce.org website. So, I assume x86_64.
> 
> But, I *think* OmniOS did support x86_32 too. Is this the case for
> OmniOSce? What about the SPARC architecture?

Pre-ce, OmniOS could boot on 32-bit x86, but OmniTI would not provide support
for 32-bit boots.  SPARC was always unsupported and unbuilt.

I assume the new community management will not change any of that.  Your
32-bit x86 apps, BTW, will continue to run on an amd64/x64/x86_64 boot just
fine.

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] networking between zones

[Dan McDonald]

On Fri, Sep 08, 2017 at 03:40:44PM +0100, David Ledger wrote:
> 
> Knowing that certainly helps, thanks. Can I also ignore those online
> documents that say it’s all done by configurations within the svcs setup and
> that I need to disable one version of ipfilter and enable another?

I use stock ipfilter (ipnat only, to be honest) in its own zone.  I didn't
use SMF magic to configure it, save "svcadm enable ipfilter" once had
/etc/ipf/ipnat.conf where I wanted it.

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] networking between zones

[Dan McDonald]

On Fri, Sep 08, 2017 at 03:21:30PM +0100, David Ledger wrote:
> 



> We now need to set up a couple of zones that have their own subnet, but talk
> to the outside world through the global zone. These will need to be network
> isolated from the existing zones and with access controlled, presumably by
> ipf/ipnat filtering done in the global zone. I’m having difficulty setting
> this up. It is readily admitted on the ‘net that Solaris network config is
> different to anything else, and that it has moved on in stages from the old
> hosts, hostname etc. files that were so easy back in the 80’s.

I think you wish to create an etherstub (in-machine "LAN" as it were).  From
global:

dladm create-etherstub internal0

And once created, you create vnics attached to that etherstub:

dladm create-vnic -l internal0 stubnet0
dladm create-vnic -l internal0 stubnet1
...

And then you assign the vnics to your "have their own subnet" zones like you
would any other nic.  You will also need your global, or even a dedicated
router zone, attach to both the etherstub and the external network (running
ipf or whatever else).

Does this help?

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ip not persistent?

[Dan McDonald]

On Thu, Aug 31, 2017 at 03:05:16PM -0400, Linda Kateley wrote:
> I am doing it with -T?

-T is "type" for the create-addr command:

   ipadm create-addr -T dhcp zonevnic0/v4

The above example should persist across boots.

-t is "Temporary"

   ipadm create-addr -t -T dhcp zonevnic0/v4

The above example will not persist across boots.

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ip not persistent?

[Dan McDonald]

On Thu, Aug 31, 2017 at 02:43:46PM -0400, Linda Kateley wrote:
> All,
> 
> Has anyone ever run into a case where ipadm details are persistent across
> reboot? I am seeing this intermittently in zones.

ipadm(1M) is SUPPOSED TO be persisten across reboots.  Unless you specify
with -t.

Or are you seeing things that are NOT persistent that should be?

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Upgrade from 151022 to CE bootadm error

[Dan McDonald]

Three swaps are three mountpoints using tmpfs.  Please share "zfs list" and 
"beadm list" again, please?

Dan

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

> On Aug 28, 2017, at 11:36 PM, Jim Oltman  wrote:
> 
> 
> 
> On Aug 27, 2017 9:34 AM, "Jim Klimov"  wrote:
> On August 27, 2017 3:43:53 PM GMT+02:00, Bob Friesenhahn 
>  wrote:
> >On Sat, 26 Aug 2017, Jim Oltman wrote:
> >
> >> I rebooted then on bootup received an error about /usr mount fatally
> >> failed.  I was able to boot to the previous BE.  I tried the update
> >again
> >> and received the same bootadm error as above.  I'm not sure where to
> >go
> >> from here.  Hope someone can help.  Thanks!
> >
> >Make sure that you did not split /usr into its own filesystem outside
> >of the root filesystem.  OmniOS is not prepared for that.  I made this
> >mistake before.
> >
> >Bob
> 
> Or if you did - make sure the new system is prepared to handle this.
> 
> My system layout managed by scripts below went through several OmniOS 
> upgrades (finally to Bloody CE) just fine. It ain't every year that something 
> has to be re-patched with them.
> 
> https://github.com/jimklimov/illumos-splitroot-scripts
> 
> --
> Typos courtesy of K-9 Mail on my Android
> 
> 
> No spilt in the filesystem.  Tank is a separate mount:
> 
> Last login: Sat Aug 26 14:59:17 2017 from 10.0.0.200
> OmniOS 5.11 omnios-r151022-f9693432c2   May 2017
> joltman@OmniOS-NAS:/export/home/joltman$ sudo df -h
> Password:
> Filesystem Size  Used Avail Use% Mounted on
> rpool/ROOT/20170826_Pre_OmniOS-CE  2.7G  2.6G   88M  97% /
> swap   4.7G  332K  4.7G   1% /etc/svc/volatile
> swap   4.7G 0  4.7G   0% /tmp
> swap   4.7G   76K  4.7G   1% /var/run
> rpool/export88M   23K   88M   1% /export
> rpool/export/home  115M   27M   88M  24% /export/home
> rpool   88M   31K   88M   1% /rpool
> tank   1.1T   36K  1.1T   1% /tank
> 
> This is a default install I did a few months back.  I didn't do any funky 
> partitioning. I'm not sure why I see 3 swaps.
> 
> Jim
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Upgrade to 151022m from 014 - horrible NFS performance

[Dan McDonald]

> On Aug 24, 2017, at 8:41 AM, Schweiss, Chip  wrote:
> 
> I just move one of my production systems to OmniOS CE 151022m from 151014 and 
> my NFS performance has tanked.  
> 
> Here's a snapshot of nfssvrtop:
> 
> 2017 Aug 24 07:34:39, load: 1.54, read: 5427 KB, swrite: 104  KB, 
> awrite: 9634 KB
> Ver Client   NFSOPS   Reads SWrites AWrites Commits   Rd_bw  
> SWr_bw  AWr_bwRd_t   SWr_t   AWr_t   Com_t  Align%
> 3   10.28.17.10   0   0   0   0   0   
> 0   0   0   0   0   0   0
> 3   all   0   0   0   0   0   0   
> 0   0   0   0   0   0   0
> 4   10.28.17.19   0   0   0   0   0   
> 0   0   0   0   0   0   0
> 4   10.28.16.160 17   0   0   0   0   0   
> 0   0   0   0   0   0   0
> 4   10.28.16.127 20   0   0   0   0   0   
> 0   0   0   0   0   0   0
> 4   10.28.16.113 74   6   6   0   0  48  
> 56   01366   20824   0   0 100
> 4   10.28.16.64 338  16   0  36   3 476   
> 01065 120   0 130  117390 100
> 4   10.28.16.54 696  68   0  91   52173   
> 02916  52   0  93  142083 100
> 4   all1185  90   6 127   82697  
> 563996 151   20824 104  133979 100
> 
> The pool is not doing anything but serving NFS.   Before the upgrade, the 
> pool would sustain 20k NFS ops.   
> 
> Is there some significant change in NFS that I need to adjust its tuning?

Oh my.

I'd start pinging the illumos list on this.  Also, are there any special tweaks 
you made in the 014 configuration?  IF you did, I'd start back removing them 
and seeing what a default system does, just in case.

I know Delphix and Nexenta still care about NFS quite a bit, so I can't believe 
something would be that bad.

Maintainers:  Check for NFS changes RIGHT AFTER 022 closed for blanket upstream 
pull-ins.  Maybe it closed during a poor-performance window?

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] new boot environment

[Dan McDonald]

"beadm create newBEname"

Read the beadm(1M) man page for more details.

Dan

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

> On Aug 20, 2017, at 7:02 PM, Fábio Rabelo  wrote:
> 
> Hi to all
> 
> There are a way to force the creation of a new boot environment ?
> 
> 
> Thanks in advance
> 
> 
> Fábio Rabelo
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] NFSv4 (client) strange behaviour

[Dan McDonald]

1.) Which OmniOS release?  Make sure it's a recent one before drawing 
conclusions.

2.) Have you queried the larger illumos mailing list?  I know there are several 
open NFSv4 issues still there, and if you have a reproducible test case, it may 
be helpful.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH

[Dan McDonald]

MANY of the OmniTI-Ms packages have hard coded version dependencies (e.g. ONLY 
r151014, not at least r151014).  I tried to fix this, but many packages there 
remained unbuilt to the new, looser, dependencies.

I'd remove ALL OmniTI-Ms packages before upgrading, and then put them back.

Dan

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

> On Aug 13, 2017, at 9:30 AM, Krzysztof Grzempa  wrote:
> 
> root@mojvps:/# pkg uninstall python-26
> 
> pkg uninstall: 'python-26' matches multiple packages
> pkg://omnios/runtime/python-26
> pkg://ms.omniti.com/omniti/runtime/python-26
> 
> Please provide one of the package FMRIs listed above to the install command.
> root@mojvps:/# pkg uninstall pkg://ms.omniti.com/omniti/runtime/python-26
> Packages to remove:  1
>Create boot environment: No
> Create backup boot environment: No
> 
> PHASE  ITEMS
> Removing old actions   4111/4111
> Updating package state database Done 
> Updating package cache   1/1 
> Updating image stateDone 
> Creating fast lookup database   Done 
> root@mojvps:/# pkg publisher
> PUBLISHER   TYPE STATUS P LOCATION
> omnios  origin   online F 
> https://pkg.omniti.com/omnios/r151022/
> root@mojvps:/# /usr/bin/pkg update -v --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/incorporation/jeos/illumos-gate@11,5.11-0.151022:20170510T210757Z
>   
> pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151022:20170510T212740Z
>   
> pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151022:20170511T001737Z
>   pkg://omnios/entire@11,5.11-0.151022:20170511T002513Z
> Dependency analysis is unable to determine exact cause.
> Try specifying expected results to obtain more detailed error messages.
> 
> root@mojvps:/# pkg update -v 
> pkg://omnios/entire@11,5.11-0.151022:20170511T002513Z
> Creating Plan (Solver setup): |
> pkg update: No matching version of entire can be installed:
>   Reject:  pkg://omnios/entire@11,5.11-0.151022:20170511T002513Z
>   Reason:  This version is excluded by installed incorporation 
> pkg://ms.omniti.com/omniti/library/uuid@1.41.14,5.11-0.151014:20150508T153803Z
> 
> 
> Im not pretty sure why should I remove uuid and why it is complaining about 
> it
> 
> Regards,
> Chris
> 
> 
> 2017-08-13 14:15 GMT+02:00 Michael Rasmussen :
>> On Sun, 13 Aug 2017 13:56:46 +0200
>> Krzysztof Grzempa  wrote:
>> 
>> > root@mojvps:/root# pkg publisher
>> > PUBLISHER   TYPE STATUS P LOCATION
>> > omnios  origin   online F
>> > https://pkg.omniti.com/omnios/r151022/
>> > root@mojvps:/root# /usr/bin/pkg update -v --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.
>> >
>> Your problem is that you have installed packages from the ms.omniti.com
>> repro. To be able to upgrade you need to uninstall those packages
>> first. Especially the python 2.6 package is a problem since 141022 is
>> based on python 2.7. So uninstall python-26 before upgrade.
>> 
>> --
>> 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'd horsewhip you if I had a horse.
>> -- Groucho Marx
>> 
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>> 
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH

[Dan McDonald]

available for this image.
>> root@mojvps:/root# pkg install -nv entire
>> No updates necessary for this image.
>> 
>> 
>> Regards,
>> Chris
>> 
>> 2017-07-31 19:54 GMT+02:00 Andries Annema :
>>> 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@nas01:~# pkg install pkg:/package/pkg
>>>> Packages to update:   1
>>>>Create boot environment:  No
>>>> Create backup boot environment: Yes
>>>> 
>>>> DOWNLOADPKGS FILESXFER (MB)   
>>>> SPEED
>>>> Completed1/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 stateDone 
>>>> Creating fast lookup database   Done 
>>>> Reading search indexDone 
>>>> Updating search index1/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
>

Re: [OmniOS-discuss] OmniOS r151014: failed to switch from SunSSH to OpenSSH

[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@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@11,5.11-0.151022:20170511T002513Z
>   
> pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151022:20170510T210757Z
>   
> pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151022:20170510T212740Z
>   
> pkg://omnios/incorporation/jeos/omnios-userland@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@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@nas01:/root# pkg list | grep ssh
>> network/openssh   7.4.1-0.151014 
>> i--
>> network/openssh-server7.4.1-0.151014 
>> i--
>> root@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@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@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@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>> 
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Local zone regression in CE bloody

[Dan McDonald]

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?

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Local zone regression in CE bloody

[Dan McDonald]

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@midgar:~# pkg unset-publisher omnios
> Updating package cache   1/1
> root@midgar:~# pkg set-publisher -P --set-property
> signature-policy=require-signatures -g
> https://pkg.omniosce.org/bloody/core/ omnios
> root@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@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 | enquir...@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@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Using OmniOSce with other publishers?

[Dan McDonald]

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


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Using OmniOSce with other publishers?

[Dan McDonald]

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@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ANNOUNCEMENT - OmniOSce r151022i is out

[Dan McDonald]

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@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Broken upgrade list

[Dan McDonald]

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

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h

[Dan McDonald]

Thank you all for your efforts.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] BE CAREFUL with version-bump upgrades

[Dan McDonald]

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

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Questions about - End the uncertainty -

[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

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Questions about - End the uncertainty -

[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@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Dan McDonald]

> 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

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] [dan...@joyent.com: Missed FLAG DAY for OmniOS r151022 users of ONU and illumos-gate]

[Dan McDonald]

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 -
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] zfs receive -x parameter missing?

[Dan McDonald]

> 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

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Loosing NFS shares

[Dan McDonald]

> On Jun 22, 2017, at 3:13 AM, Oliver Weinmann 
>  wrote:
> 
> Hi,
>  
> Don’t think so:
>  
> svcs -vx rcapd 
>  
> shows nothing.

You're not looking for the right thing.

neuromancer(~)[0]% pgrep rcapd
340
neuromancer(~)[0]% svcs -a | grep cap
online May_12   svc:/system/rcap:default
neuromancer(~)[0]% svcs -xv rcap
svc:/system/rcap:default (resource capping daemon)
 State: online since Fri May 12 02:12:40 2017
   See: man -M /usr/share/man -s 1M rcapd
   See: man -M /usr/share/man -s 1M rcapstat
   See: man -M /usr/share/man -s 1M rcapadm
   See: /var/svc/log/system-rcap:default.log
Impact: None.
neuromancer(~)[0]% su troot
Password: 
OmniOS 5.11 omnios-r151022-f9693432c2   May 2017
(0)# svcadm disable rcap
(0)# 


Hope this helps,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Intel C612 chipset

[Dan McDonald]

> On Jun 19, 2017, at 4:51 AM, Lawrence Giam  wrote:
> 
> Hi All,
> 
> I am planning to get this SuperMicro server SSG-2028R-E1CR24L and I am 
> wondering if there is any problem associated with Intel C612 chipset and 
> Intel X540 Dual Port 10GBase-T?
> 
> Planning to use Seagate ST1200MM00 10KRPM 512E 2.5" SAS HDD.
> 
> Any comment?

Looks like a good pick.  It has the 3008 set to the IT firmware already (check 
the illumos mailing list for what the best revision of said FW should be), and 
the X540 is also been supported.

Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] HBA Broadcom SAS 9305-16i (SAS3224)

[Dan McDonald]

 On Wed, Jun 14, 2017 at 07:13:55PM +0200, Frank M. wrote:
> Hi,
> 
> anybody knows, if HBA Broadcom SAS 9305-16i (SAS3224) works properly?

The 16-port one, no.

Sorry,
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Fwd: Kayak failed to make the release images of 151022 by the local Repos

[Dan McDonald]

It's like you're missing packages.  Did you populate it with both
illumos-omnios AND omnios-build packages?

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ms.omniti.com needs "pkgrepo -s ... rebuild"

[Dan McDonald]

(1)# pkg update -rnv
pkg: 1/2 catalogs successfully updated:
 
1: http protocol error: Unknown error code: 404 reason: Not Found
URL: 
'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170515T21Z.C'
2: http protocol error: Unknown error code: 404 reason: Not Found
URL: 
'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170607T14Z.C' 
(happened 3 times)
3: http protocol error: Unknown error code: 404 reason: Not Found
URL: 
'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170607T15Z.C' 
(happened 4 times)
4: http protocol error: Unknown error code: 404 reason: Not Found
URL: 
'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170605T18Z.C' 
(happened 3 times)
5: http protocol error: Unknown error code: 404 reason: Not Found
URL: 
'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170605T20Z.C' 
(happened 3 times)
6: http protocol error: Unknown error code: 404 reason: Not Found
URL: 
'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170606T21Z.C' 
(happened 3 times)

(1)# 

I think an internal "pkgrepo -s  rebuild" will cure this.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] panic: bd_strategy after new loader installed

[Dan McDonald]

> On Jun 6, 2017, at 9:47 PM, Paul B. Henson  wrote:
> 
> echo ::sd_state | mdb -k | egrep '(^un|_blocksize)'

Shit, you're right:

(2)# echo ::sd_state | mdb -k | egrep '(^un|_blocksize)'
un 0: ff0d0c58d9c0
un_sys_blocksize = 0x200
un_tgt_blocksize = 0x200
un_phy_blocksize = 0x200
un_f_tgt_blocksize_is_valid = 0x1
un 1: ff0d0c58cd40
un_sys_blocksize = 0x200
un_tgt_blocksize = 0x200
un_phy_blocksize = 0x1000
un_f_tgt_blocksize_is_valid = 0x1
un 2: ff0d0c58d380
un_sys_blocksize = 0x200
un_tgt_blocksize = 0x200
un_phy_blocksize = 0x200
un_f_tgt_blocksize_is_valid = 0x1
un 3: ff0d0c58c700
un_sys_blocksize = 0x200
un_tgt_blocksize = 0x200
un_phy_blocksize = 0x1000
un_f_tgt_blocksize_is_valid = 0x1

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] panic: bd_strategy after new loader installed

[Dan McDonald]

> On Jun 4, 2017, at 11:00 PM, Paul B. Henson  wrote:
> 
>> 
>> And what does the "native" mean: is that "4kB physical AND 4kB logical 
>> block size" as opposed to "4kB physical with 512B logical block size"?
> 
> At this point I'm thinking the loader is only broken for disks that have
> a *logical* sector size of 4k, as opposed to those that have a physical
> sector size of 4k but still maintain a logical sector size of 512b.


Sorry for the VERY long latency.  Started Joyent last week, attended a funeral 
yesterday, and more.

I apologize if I'm missing something.  Here's my home system:

(0)# diskinfo
TYPEDISKVID  PID  SIZE  RMV SSD
UNKNOWN c5t0d0  INTELSSDSC2BB080G4  74.53 GiB   no  yes
UNKNOWN c5t1d0  INTELSSDSC2BB080G4  74.53 GiB   no  yes
UNKNOWN c5t2d0  HGST HDN726060ALE610  5589.03 GiB   no  no 
UNKNOWN c5t3d0  HGST HDN726060ALE610  5589.03 GiB   no  no 
(0)# zpool list -v
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAGCAP  DEDUP  HEALTH  
ALTROOT
rpool 51.5G  25.6G  25.9G -37%49%  1.00x  ONLINE  -
  mirror  51.5G  25.6G  25.9G -37%49%
c5t0d0s0  -  -  - -  -  -
c5t1d0s0  -  -  - -  -  -
tank  5.44T  2.08T  3.36T -20%38%  1.00x  ONLINE  -
  mirror  5.44T  2.08T  3.36T -20%38%
c5t2d0-  -  - -  -  -
c5t3d0-  -  - -  -  -
log   -  -  - -  -  -
  mirror  3.97G   768K  3.97G -52% 0%
c5t0d0s4  -  -  - -  -  -
c5t1d0s4  -  -  - -  -  -
(0)# uname -a
SunOS neuromancer 5.11 omnios-r151022-f9693432c2 i86pc i386 i86pc
(0)# 


The INTEL drives are 512b sectors.  The HGST drives (which are NOT boot disks) 
have 4kb sectors.  zdb shows this with ashift.

I thought this problem manifested with ANY 4k disk on your system, even if it 
wasn't the boot drive?!  Or am I missing something from the back discussions?  
And yes, this server boots with Loader (off a old-school Solaris-partitioned 
INTEL SSDs).

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] panic: bd_strategy after new loader installed

[Dan McDonald]

On Thu, Jun 01, 2017 at 01:01:49PM -0700, Paul B. Henson wrote:
> > From: Geoff Nordli
> > Sent: Tuesday, May 30, 2017 7:57 PM
> > 
> > Right, it will not boot after upgrading to the new loader; even if the
> > 4K disks are not part of the rpool.
> 
> Yikes 8-/, I'm glad I hadn't got around to updating; my data pool consists
> of 13 WD Red 3TB drives which are 4K native. I'm surprised this deficiency
> wasn't noticed during development or testing, aren't 4K native drives fairly
> common nowadays? I deployed my pool back in 2009.

WAIT A MINUTE.  I thought it wasn't 4k, but "4K" that actually had more bytes
on them (some sort of T.10 thing).

I'm on the road right now, but I'm pretty sure I have 4k data disks and I'm
on 022 + loader Just Fine (TM).

Here's the relevant mail:

   http://lists.omniti.com/pipermail/omnios-discuss/2017-May/008906.html

I can confirm/deny this when I get home.

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] NFS & SMB connection freezes 30-40 second sometimes.

[Dan McDonald]

r151022 is out now.  Please upgrade to that and see if the problem manifests.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Fix for no UUID in Kayak-installed BE?

[Dan McDonald]

Given the "uuidgen" binary has WAY too many libraries, and the uniqueness of 
the UUID doesn't need to be super-special for the installed BE, I put together 
this patch using the existing miniroot tools:


diff --git a/install_help.sh b/install_help.sh
index 7ad5ab1..7095536 100644
--- a/install_help.sh
+++ b/install_help.sh
@@ -115,6 +115,11 @@ BuildBE() {
   $GRAB $MEDIA | pv -B 128m -w 78 | $DECOMP | zfs receive -u $RPOOL/ROOT/omnios
   zfs set canmount=noauto $RPOOL/ROOT/omnios
   zfs set mountpoint=legacy $RPOOL/ROOT/omnios
+  # Generate UUID for BE using existing tools...
+  prtconf -v | md5sum | awk '{print $1}' > /tmp/bits
+  echo "`cut -b1-8 < /tmp/bits`-`cut -b9-12 < /tmp/bits`-`cut -b13-16 < 
/tmp/bits`-`cut -b17-20 < /tmp/bits`-`cut -b21-32 < /tmp/bits`" > /tmp/uuid
+  zfs set org.opensolaris.libbe:uuid=`cat /tmp/uuid` $RPOOL/ROOT/omnios
+  zfs set org.opensolaris.libbe:policy=static $RPOOL/ROOT/omnios
   log "Cleaning up boot environment"
   beadm mount omnios /mnt
   ALTROOT=/mnt


I initially tested by invoking the prtconf & echo commands, to make sure the 
resultant UUID looked correct.  I am spinning a bloody ISO as I type this to 
try and make sure it ACTUALLY works.

Thanks,
Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] panic: bd_strategy after new loader installed

[Dan McDonald]

> On May 18, 2017, at 3:55 PM, Geoff Nordli  wrote:
> 
> Hi.
> 
> I upgraded to the latest r151022 version.  The upgrade went fine, rebooted 
> the machine, then upgraded to the new loader.
> 
> When i rebooted after the loader upgrade, I got an error message:
> 
> panic: bd_strategy: 512 bytes I/O not multiple of block size.
> 
> press a key on the console to reboot
> 
> Rebooting...
> 
> panic free: guard1 fail @ 0x2e2e2e67 from ../../common/devopen.c:64
> 
> The boot disk is an 80GB intel ssd.
> 
> Any thoughts?

Looks like you may have one of those 512b or 4k sector problems.

I'm Bcc:ing the loader person, in case this is familiar to him.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Test

[Dan McDonald]

This is only a test.

Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] COMMUNITY EXERCISE: illumos 7590

[Dan McDonald]

> On May 16, 2017, at 5:22 PM, Dan McDonald  wrote:
> 
> The tests are collidy-enough where I'm running an illumos-omnios build before 
> I push them.  For now, let's assume it works and I push these upstream to the 
> illumos-omnios repo.

The illumos-omnios build worked for bloody, and now the master and upstream 
branches are updated.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] COMMUNITY EXERCISE: illumos 7590

[Dan McDonald]

Found my first error

> On May 16, 2017, at 5:22 PM, Dan McDonald  wrote:
> 
> YOUR HOMEWORK PART 0:  Figure this out.


Correction:  "Figure out whether or not illumos 7590 is worth a backport all by 
itself."


Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] COMMUNITY EXERCISE: illumos 7590

[Dan McDonald]

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

.  .  .

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

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

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

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

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

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

YOUR HOMEWORK PART 0:  Figure this out.

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

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

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

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


bloody(~)[0]% illumos-update 
HEY -- pay attention in case any of these FUBAR somehow.
~/ws/illumos-gate ~
Fetching origin
remote: Counting objects: 163, done.
remote: Compressing objects: 100% (66/66), done.
remote: Total 163 (delta 102), reused 77 (delta 77), pack-reused 13
Receiving objects: 100% (163/163), 173.54 KiB | 0 bytes/s, done.
Resolving deltas: 100% (102/102), completed with 76 local objects.
>From https://github.com/illumos/illumos-gate
   49bf4c2bcf..f012ee0c3d  master -> origin/master
Updating 49bf4c2bcf..f012ee0c3d
Fast-forward
 exception_lists/cstyle |   4 +
 usr/src/lib/libdscfg/common/cfg.c  | 290 +-
 usr/src/lib/libndmp/common/libndmp_prop.c  |   3 +-
 .../lib/print/libpapi-common/common/attribute.c| 171 +--
 usr/src/man/man3nsl/xdr_admin.3nsl |  21 +-
 usr/src/pkg/manifests/system-test-ostest.mf|   9 +-
 usr/src/test/os-tests/runfiles/default.run |   8 +
 usr/src/test/os-tests/tests/Makefile   |   4 +-
 usr/src/test/os-tests/tests/sockfs/Makefile|  54 
 usr/src/test/os-tests/tests/sockfs/conn.c  | 220 ++
 usr/src/test/os-tests/tests/sockfs/dgram.c | 182 
 usr/src/test/os-tests/tests/sockfs/drop_priv.c | 330 +
 usr/src/test/os-tests/tests/sockfs/sockpair.c  | 168 +++
 usr/src/test/os-tests/tests/stress/Makefile|  42 +++
 usr/src/test/os-tests/tests/stress/dladm-kstat.sh  |  67 +
 usr/src/uts/common/avs/ns/sdbc/sd_bio.c|  11 +-
 usr/src/uts/common/fs/autofs/auto_vfsops.c |   5 +-
 usr/src/uts/common/fs/autofs/auto_vnops.c  |   4 +-
 usr/src/uts/common/fs/dcfs/dc_vnops.c  |   6 +-
 usr/src/uts/common/fs/dev/sdev_subr.c  |   9 +-
 usr/src/uts/common/fs/dev/sdev_vfsops.c|   9 +-
 usr/src/uts/common/fs/devfs/devfs_vnops.c  |   7 +-
 usr/src/uts/common/fs/dnlc.c   |  17 +-
 usr/src/uts/common/fs/doorfs/door_vnops.c  |  23 +-
 usr/src/uts/common/fs/fd/fdops.c   |  22 +-
 usr/src/uts/common/fs/fifofs/fifovnops.c   |  40 ++-
 usr/src/uts/common/fs/gfs.c|   7 +-
 usr/src/uts/common/fs/hsfs/hsfs_vnops.c| 209 -
 usr/src/uts/common/fs/lofs/lofs_subr.c |  11 +-
 usr/src/uts/common/fs/namefs/namevfs.c |   4 +-
 usr/src/uts/common/fs/namefs/namevno.c |  36 +--
 usr/src/uts/common/fs/nfs/nfs4_client.c|  12 +-
 usr/src/uts/common/fs/nfs/nfs4_rnode.c |  13 +-
 usr/src/uts/common/fs/nfs/nfs4_shadow.c|   5 +-
 usr/src/uts/common/fs/nfs/nfs_subr.c   |  14 +-
 usr/src/uts/common/fs/pcfs/pc_node.c   |   5 +-
 usr/src/uts/common/fs/pcfs/pc_vnops.c  |   3 +-
 usr/src/uts/common/fs/proc/prvnops.c   |   3 +-
 usr/src/uts/common/fs/smbclnt/smbfs/smbfs_subr2.c  |  15 +-
 usr/src/uts/common/fs/sockfs/sockcommon_vnops.c|   9 +-
 usr/src/uts/common/fs/sockfs/socksubr.c|  16 +-
 usr/src/uts/common/fs/sockfs/socktpi.c | 234 +++
 usr/src/uts/common/fs/sockfs/socktpi.h |   9 +-
 usr/src/uts/common/fs/specfs/specvnops.

Re: [OmniOS-discuss] Legal next steps

[Dan McDonald]

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

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

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

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

Dan

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

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] First r151023 Bloody is now out

[Dan McDonald]

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

Visit the Installation page for media downloads and checksums:

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

And a current r151021 bloody user can just do:

pkg update (-r)

to get updated to the new r151023 bloody.

Happy bloody updating!
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dan McDonald]

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] To the OmniOS Community

[Dan McDonald]

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dan McDonald]

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

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

Worst-case scenario is to explicitly install it:

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bloody bump to r151023, and more

[Dan McDonald]

This is my last official week at OmniTI.

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

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

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

Thanks!
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Oddity following upgrade to r151022

[Dan McDonald]

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

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

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

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


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dan McDonald]

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dan McDonald]

> On May 12, 2017, at 5:15 PM, Ian Kaufman  wrote:
> 
> Hmmm, having trouble going from 14 to 22. I cannot migrate to OpenSSH - 
> 
> root@hiperq-data:/root# /usr/bin/pkg install --no-backup-be --reject 
> pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject 
> pkg:/service/network/ssh --reject pkg:/service/network/ssh-common 
> pkg:/network/openssh pkg:/network/openssh-server
> Creating Plan (Solver setup): \
> pkg install: No matching version of network/openssh can be installed:
>   Reject:  pkg://omnios/network/openssh@7.4.1,5.11-0.151022:20170511T001844Z
>   Reason:  All versions matching 'require' dependency 
> pkg:/library/security/openssl@1.0.2.11,5.11-0.151022 are rejected
> Reject:  
> pkg://omnios/library/security/openssl@1.0.2.11,5.11-0.151022:20170510T232316Z
> Reason:  This version is excluded by installed incorporation 
> pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151014:20161221T194806Z
> No matching version of network/openssh-server can be installed:
>   Reject:  
> pkg://omnios/network/openssh-server@7.4.1,5.11-0.151022:20170511T001853Z
>   Reason:  All versions matching 'require' dependency 
> pkg:/SUNWcs@0.5.11,5.11-0.151022 are rejected
> Reject:  pkg://omnios/SUNWcs@0.5.11,5.11-0.151022:20170510T212740Z
> Reason:  This version is excluded by installed incorporation 
> pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151014:20170301T162824Z
>  This version is excluded by installed incorporation 
> pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151014:20160804T060038Z

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

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

Sorry,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dan McDonald]

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

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dan McDonald]

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

Huh.

Some dumb questions:

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

2.) Any non-global zones?

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dan McDonald]

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

[Dan McDonald]

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

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

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Heads up for people who want to clone the 151022 repository

[Dan McDonald]

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

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] To the OmniOS Community

[Dan McDonald]

Dear OmniOS Community,

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

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

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

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

Dan McDonald -- OmniOS Engineering

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] OmniOS r151022 is now out!

[Dan McDonald]

As always, please start with the release notes:

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

And for this release, there are upgrade notes:

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

This is an LTS and Stable update.  Highlights include:

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

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

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

- Perl is now 5.24.1.

- USB 3.0 support.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks, and happy upgrading!
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LX: real ksh93 broken

[Dan McDonald]

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

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

One thing you can DO is this:

set max-lwps=2000

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

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

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

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

Thanks,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LX: real ksh93 broken

[Dan McDonald]

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

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

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

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

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

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

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

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

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

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


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

Dan



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LX: real ksh93 broken

[Dan McDonald]

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

Thanks,
Dan

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

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

Re: [OmniOS-discuss] Resilver zero progress

[Dan McDonald]

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

Dan

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

> On May 10, 2017, at 11:29 AM, Schweiss, Chip  wrote:
> 
> I have a pool that has had a resilver running for about an hour but the 
> progress status is a bit alarming.  I'm concerned for some reason it will not 
> resilver.   Resilvers are tuned to be faster in /etc/system.   This is on 
> OmniOS r151014, currently fully updated.   Any suggestions?
> 
> -Chip
> 
> from /etc/system:
> 
> set zfs:zfs_resilver_delay = 0
> set zfs:zfs_scrub_delay = 0
> set zfs:zfs_top_maxinflight = 64
> set zfs:zfs_resilver_min_time_ms = 5000
> 
> 
> # zpool status hcp03
>   pool: hcp03
>  state: DEGRADED
> status: One or more devices is currently being resilvered.  The pool will
> continue to function, possibly in a degraded state.
> action: Wait for the resilver to complete.
>   scan: resilver in progress since Wed May 10 09:22:15 2017
> 1 scanned out of 545T at 1/s, (scan is slow, no estimated time)
> 0 resilvered, 0.00% done
> config:
> 
> NAME STATE READ WRITE CKSUM
> hcp03DEGRADED 0 0 0
>   raidz2-0   DEGRADED 0 0 0
> c0t5000C500846F161Fd0ONLINE   0 0 0
> spare-1  UNAVAIL  0 0 0
>   5676922542927845170UNAVAIL  0 0 0  was 
> /dev/dsk/c0t5000C5008473DBF3d0s0
>   c0t5000C500846F1823d0  ONLINE   0 0 0
> c0t5000C500846F134Fd0ONLINE   0 0 0
> c0t5000C500846F139Fd0ONLINE   0 0 0
> c0t5000C5008473B89Fd0ONLINE   0 0 0
> c0t5000C500846F145Bd0ONLINE   0 0 0
> c0t5000C5008473B6BBd0ONLINE   0 0 0
> c0t5000C500846F131Fd0ONLINE   0 0 0
>   raidz2-1   ONLINE   0 0 0
> c0t5000C5008473BB63d0ONLINE   0 0 0
> c0t5000C5008473C9C7d0ONLINE   0 0 0
> c0t5000C500846F1A17d0ONLINE   0 0 0
> c0t5000C5008473A0A3d0ONLINE   0 0 0
> c0t5000C5008473D047d0ONLINE   0 0 0
> c0t5000C5008473BF63d0ONLINE   0 0 0
> c0t5000C5008473BC83d0ONLINE   0 0 0
> c0t5000C5008473E35Bd0ONLINE   0 0 0
>   raidz2-2   ONLINE   0 0 0
> c0t5000C5008473ABAFd0ONLINE   0 0 0
> c0t5000C5008473ADF3d0ONLINE   0 0 0
> c0t5000C5008473AE77d0ONLINE   0 0 0
> c0t5000C5008473A23Bd0ONLINE   0 0 0
> c0t5000C5008473C907d0ONLINE   0 0 0
> c0t5000C5008473CCABd0ONLINE   0 0 0
> c0t5000C5008473C77Fd0ONLINE   0 0 0
> c0t5000C5008473B6D3d0ONLINE   0 0 0
>   raidz2-3   ONLINE   0 0 0
> c0t5000C5008473E4FFd0ONLINE   0 0 0
> c0t5000C5008473ECFFd0ONLINE   0 0 0
> c0t5000C5008473F4C3d0ONLINE   0 0 0
> c0t5000C5008473F8CFd0ONLINE   0 0 0
> c0t5000C500846F1897d0ONLINE   0 0 0
> c0t5000C500846F14B7d0ONLINE   0 0 0
> c0t5000C500846F1353d0ONLINE   0 0 0
> c0t5000C5008473EEDFd0ONLINE   0 0 0
>   raidz2-4   ONLINE   0 0 0
> c0t5000C500846F144Bd0ONLINE   0 0 0
> c0t5000C5008473F10Fd0ONLINE   0 0 0
> c0t5000C500846F15CBd0ONLINE   0 0 0
> c0t5000C500846F1493d0ONLINE   0 0 0
> c0t5000C5008473E26Fd0ONLINE   0 0 0
> c0t5000C500846F1A0Bd0ONLINE   0 0 0
> c0t5000C5008473EE07d0ONLINE   0 0 0
> c0t5000C500846F1453d0ONLINE   0 0 0
>   raidz2-5   ONLINE   0 0 0
> c0t5000C500846F153Bd0ONLINE   0 0 0
> c0t5000C5008473F9EBd0ONLINE   0 0 0
> c0t5000C500846F14EFd0ONLINE   0 0 0
> c0t5000C5008473AB0Bd0ONLINE   0 0 0
> c0t5000C500846F140Bd0ONLINE   0 0 0
> c0t5000C5008473FC0Fd0ONLINE   0 0 0
> c0t5000C5008473DFA3d0ONLINE   0 0 0
> c0t5000C5008473F89Bd0ONLINE   0 0 0
>   raidz2-6

Re: [OmniOS-discuss] LX: real ksh93 broken

[Dan McDonald]

Wow, thank you for the further deep-diving.

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

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

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

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

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


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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS DOS'd my entire network

[Dan McDonald]

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



Interesting.

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS DOS'd my entire network

[Dan McDonald]

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

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

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

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

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

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


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

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

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

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

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LX: real ksh93 broken

[Dan McDonald]

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

ksh93 appears to be looping in something:

mdb: target stopped at:
0x42adf0:   movq   +0x350129(%rip),%rax <0x77af20>
> ::step
mdb: target stopped at:
0x42adf7:   testq  %rax,%rax
> ::step
mdb: target stopped at:
0x42adfa:   jne+0xc <0x42ae08>
> ::step
mdb: target stopped at:
0x42adfc:   jmp+0x28<0x42ae26>
> ::step
mdb: target stopped at:
0x42ae26:   addl   $0x1,%r14d
> ::step
mdb: target stopped at:
0x42ae2a:   cmpl   0x10(%rsi),%r14d
> ::step
mdb: target stopped at:
0x42ae2e:   jl -0x40<0x42adf0>
> ::step
mdb: target stopped at:
0x42adf0:   movq   +0x350129(%rip),%rax <0x77af20>
>   0x7f0470f0/D
0x7f0470f0: 2147483647  
> 0x7f0470f0/X
0x7f0470f0: 7fff
>   

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

NO idea how this happened.  :-/

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LX: real ksh93 broken

[Dan McDonald]

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

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

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

^D
^C# 
# 

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

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

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

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

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

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

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

Sorry,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LX: real ksh93 broken

[Dan McDonald]

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

Dan

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

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

[OmniOS-discuss] Bloody update for May 8th (r151022-RC0 feeder)

[Dan McDonald]

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

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

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

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

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

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

Thank you!
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Fwd: [smartos-discuss] Problem updating Debian 8.7 (jessie) zone

[Dan McDonald]

For anyone using Debian in an LX zone...

Dan

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

Re: [OmniOS-discuss] l2arc 16.0E accounting leak

[Dan McDonald]

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

Dan

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

> On May 5, 2017, at 11:06 AM, Richard Jahnel  wrote:
> 
> Does anyone know if we pulled or backported the 
> https://www.illumos.org/issues/7867  into r151020 yet?
>  
> We are suffering from this bug now. I’m pulling out my l2arc devices until a 
> fix is in place, which makes me sad.
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] git push/fsck problem on r151020

[Dan McDonald]

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

Dan

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

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

[OmniOS-discuss] Repo-only illumos-omnios update

[Dan McDonald]

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

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

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bloody update

[Dan McDonald]

This update is almost entirely illumos-omnios driven.

uname -v says omnios-master-f88fa452c2, and illumos-omnios from master, commit 
f88fa452c2, built this release.

Some bugfixes include:

- Install media were missing the "xhci" USB3 driver.

- Two older LX commits that I'd overlooked, involving epoll and inotify.

- Some very recent LX bugfixes from Joyent.

- Loader bugfixes


The new media pointers can be found here:

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

Happy updating!
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] I am have a problem copying the stable repo

[Dan McDonald]

> On Apr 26, 2017, at 12:44 PM, Richard Skelton  wrote:
> 
> Hi,
> I am have a problem copying the stable repo:-(
> 
> root@ml110:~# pkgrepo create /rpool/omnios/r151020
> root@ml110:~# pkgrecv -s http://pkg.omniti.com/omnios/r151020 -d
> /rpool/omnios/r151020 -m latest '*'
> pkgrecv: Framework error: code: E_SSL_CACERT (60) reason: SSL
> certificate problem: certificate is not yet valid
> URL: 'http://pkg.omniti.com/omnios/r151020/versions/0/'

Before you copy, make SURE you're updated to the latest ca-bundle package:

r151020(~)[0]% pkg list -v ca-bundle
FMRI IFO
pkg://omnios/web/ca-bundle@5.11-0.151020:20170414T020145Zi--
r151020(~)[0]% 


Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Requesting System Maintenance Mode at Installation

[Dan McDonald]

> On Apr 26, 2017, at 11:34 AM, Jens Bauernfeind 
>  wrote:
> 
> Do you used a real DVD or an ISO?
> For the future you could use the iso mount feature of HP ILOs so you save 
> time to burn the iso and save blank cd/dvd.
> I see no reason to use a remote console just to insert a physical disk when 
> needed ;-)

Will that work for pre-USB3 ISO images?

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Requesting System Maintenance Mode at Installation

[Dan McDonald]

> On Apr 26, 2017, at 10:31 AM, Özkan Göksu  wrote:
> 
> I installed omnios-r151020-4151d05.
> 
> I think you should add next release PKGIN, diskinfo, and maybe more disk 
> utility. 

diskinfo is baked-in to illumos now, and subsequently will be in r151022. The 
disk-selection of the new installer takes diskinfo(1M) output as its data, e.g.

> I'm tired every release installing these software besides almost everybody 
> needs...

This falls back to the original OmniOS KYSTY philosophy, which I still agree 
with, though I understand very much your concern & frustration.  After 022, I 
was hoping to address clearly the problem by proposing a LARGE secondary 
publisher that would provide the sort of extras you seek. There were questions 
about its construction and maintenance of course.  024 was going to have an 
022-like super-sized 9-ish-month cycle (to get us back on the spring/fall 
6-month cadence), which would've been partially used to solve such problems.

> I'm very sad about ending.

Me too, but that train has left the station (at least w.r.t. OmniTI).  It's on 
the community now.

> Thank you for your all effort.

It was my pleasure.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Requesting System Maintenance Mode at Installation

[Dan McDonald]

> On Apr 26, 2017, at 9:04 AM, Özkan Göksu  wrote:
> 
> Thank you so much. 
> 

Glad GEA was able to help.

Which OmniOS version were you installing?  We've radically changed the 
installer itself for the current bloody, and the soon-to-be-release r151022.  
These changes have nothing to do with USB3, but early revisions went into 
maintenance mode sometimes.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] IPFILTER Rate Limiting

[Dan McDonald]

Sorry, I didn't read deeply enough.  flowadm(1M) doesn't use establishment as a 
flow limiter.  I do wonder, though, if you couldn't use ipfilter to label 
inbound SYN packets with a distinct diffserv number which flowadm CAN use for 
limiting?

Dan

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

> On Apr 25, 2017, at 1:52 PM, Brad Stone  wrote:
> 
> I could be wrong, but I think flowadm can control only the priority and max 
> bandwidth for the traffic, not
> the connection rate.
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] IPFILTER Rate Limiting

[Dan McDonald]

Read up on flowadm(1M) - this is a better tool for rate limiting.

Dan

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

> On Apr 25, 2017, at 1:29 PM, Software Information 
>  wrote:
> 
> Hi All
> I have been trying to find some ipfilter documentation that will show me how 
> to rate limit to a particular port in OmniOS. I really want to rate limit 
> users logging on using ssh to seriously discourage the brute forcers. I am 
> more used to putting lines like this in pf.conf on a BSD.
> 
> 1. table  persist
> 
> 2. block in quick from 
> 
> 3. pass in on $interface proto tcp to $interface port 53 flags S/SA keep 
> state \
> (max-src-conn-rate 15/5, overload  flush)
> 
> Can anyone show me where some good docs are on how to accomplish this on Omni?
> 
> Regards
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] web site seems to attack server internet connection

[Dan McDonald]

> On Apr 24, 2017, at 10:09 AM, Dan McDonald  wrote:
> 
> Is e1000g0 manually configured, or configured with DHCP?

I'd also suggest running and capturing the output of:


route -n monitor

on the zone you have e1000g0 in.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] web site seems to attack server internet connection

[Dan McDonald]

> On Apr 24, 2017, at 4:34 AM, Michael Mounteney  wrote:
> 
> What seems to happen is that e1000g0 goes down entirely so that, as
> previously mentioned, not even "ping 89.16.167.134" works, but if you
> Esc on the web page so that it doesn't keep trying to send traffic,
> after about 45 seconds the interface recovers, by itself.  At other
> times it recovers but the default route is lost from the routing table
> and I have to add it back in manually.

Is e1000g0 manually configured, or configured with DHCP?

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss