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

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 <dan...@nowhere.kebe.com>
> 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

<SNIP!>

>  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 <omn...@citrus-it.co.uk>
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] 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 <gearbo...@outlook.com> 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 <dan...@kebe.com>
> 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 <gearbo...@outlook.com> 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 >
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 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 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=0xD3C9A00E
>> mir  datanom  net
>> http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
>> mir  miras  org
>> http://pgp.mit.edu:11371/pks/lookup?op=get=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]

re detailed error messages.
>> 
>> root@mojvps:/root# pkg update -nv entire
>> No updates 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 <an3s.ann...@gmail.com>:
>>> 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 <grzem...@gmail.com> 
>>>>> 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" <bauernfe...@ipk-gatersleben.de> 
>>>>> napisał(a):
>>>>>> Hi,
>

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
> 

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

[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 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] 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 <dan...@joyent.com> -

Date: Mon, 3 Jul 2017 09:33:20 -0400
From: Dan McDonald <dan...@joyent.com>
To: illumos-developer <develo...@lists.illumos.org>
Cc: Dan McDonald <dan...@joyent.com>, Dan McDonald <dan...@kebe.com>
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] 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] 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 <dan...@omniti.com> wrote:
> 
> The tests are collidy-enough where I'm running an illumos-omnios build before 
> I push them.  For now, let's assume it works and I push these upstream to the 
> illumos-omnios repo.

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

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@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 <dan...@omniti.com> wrote:
> 
> YOUR HOMEWORK PART 0:  Figure this out.


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


Dan

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

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

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

[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

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] 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 10:30 AM, Dan McDonald <dan...@omniti.com> wrote:
> 
> When I get home I'll provide more details, but you should try bloody or still 
> in beta r151022.
> 

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

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

[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] 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 <dan...@omniti.com> 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

[OmniOS-discuss] OmniOS bloody update -- countdown to r151022

[Dan McDonald]

Hello!

I've updated all of the omnios-build packages for bloody, in anticipation of 
getting r151022 ready for a release sometime in May.  There's still some 
debugging to do for r151022 (and some PRs to accept), and a couple of more 
illumos merges, but with this update we have several new things to report.

Speaking of debugging, a few of the debugging items involve the installer ISO, 
so there will not be an ISO update with this bump. 

uname -v shows omnios-master-c561ad5255   (Note the new, longer, hash, part of 
the git(1) upgrade).

omnios-build was built from commit 5806fb4.

New in this build:

- Parent-dependent IPS packages ---> This means for some system-critical 
package, "pkg update" even WITHOUT "-r" will update linked-image zones.

- ZFS fixes, including illumos 7885 (16.0e reported for expandsz)

- zone-centered modernization of shutdown(1M) (illumos 8034)

- LX improvements

- illumos 8085 -- Handle RPC group lists better.

- Bind to 9.10.4-P8

- NSS to 3.30.1, NSPR to 4.14

- GNU coreutils to 8.27

- Curl to 7.54

- dbus to 1.11.12

- git to 2.12.2

- GMP to 6.1.2

- gnu-grep to 3.0

- ISO-codes to 43.74

- less to 487

- libpcap to 1.8.1

- GNU m4 to 1.4.18

- Mercurial to 4.1.3  (NOTE: There have been reports via OpenIndiana that this 
version of hg doesn't play entirely nice with illumos)

- nghttp2 to 1.21.1

- pkg-config to 0.29.2

- Various python-package updates.

- screen to 4.5.1

- GNU sed to 4.4

- tcsh to 6.20

- vim 8 is now at patchlevel 567

- zsh to 5.3.1

Happy upgrading!
Dan

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

Re: [OmniOS-discuss] tzselect for kayak installer

[Dan McDonald]

> On Apr 20, 2017, at 12:24 PM, Volker A. Brandt  wrote:
> 
> So the abomination will live on.   Sigh...


You can engage them via t...@iana.org, y'know.  :)

Dan

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

Re: [OmniOS-discuss] tzselect for kayak installer

[Dan McDonald]

> On Apr 20, 2017, at 11:52 AM, Jens Bauernfeind 
>  wrote:
> 
> Hello all,
> 
> I thought that adding a menu for the timezone selection might be an idea.
> As I wrote to Dan, it uses tzselect(1M) instead of entering the $TZ
> manually.
> 
> It's only a little modification of the rpool-install.sh file, as seeing in
> my pull request:
> https://github.com/omniti-labs/kayak/pull/15
> 
> I need your opinion if this change is worth or not.
> 
> - more "user-friendly"
> - a typo error is not possible, as tzselect builds the $TZ value for you

I haven't pulled it in yet, but I am going to.

Community --> if I'm being hasty, this is the time to go to PR #15 and correct 
me.  I think this is a generally good idea, however.  ESPECIALLY since, unlike 
the caiman TZ selector, it doesn't use any crappy hacks to the stock TZ 
database (e.g. libzoneinfo).

Dan

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

Re: [OmniOS-discuss] Bloody web/curl update.

[Dan McDonald]

ENOCAFFEINE -- it's not because of entire or OmniOS-userland.

I'll investigate this more when I get back from the Dr.

Dan

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

> On Apr 20, 2017, at 8:24 AM, Dan McDonald <dan...@omniti.com> wrote:
> 
> I have to push out entire and OmniOS-userland consolidation updates as well.
> 
> Sorry about that -  will do that later this morning.
> 
> Dan
> 
> Sent from my iPhone (typos, autocorrect, and all)
> 
>> On Apr 20, 2017, at 6:34 AM, Andy Fiddaman <omn...@citrus-it.net> wrote:
>> 
>> 
>> My OmniOS Bloody box says that there is a web/curl update available but
>> won't install it (says no updates available). Any ideas? I'm running the
>> debug kernel in case it's relevant.
>> 
>> Thanks!
>> 
>> omni# pkg refresh
>> omni# pkg list -u
>> NAME (PUBLISHER)  VERSION  IFO
>> web/curl  7.53.0-0.151021  i--
>> omni# pkg update
>> No updates available for this image.
>> zsh: exit 4 pkg update
>> omni# pkg update -nv
>> No updates available for this image.
>> zsh: exit 4 pkg update -nv
>> 
>> omni# pkg variant
>> VARIANTVALUE
>> arch   i386
>> debug.illumos  true
>> opensolaris.zone   global
>> 
>> -- 
>> Citrus IT Limited | +44 (0)870 199 8000 | 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

Re: [OmniOS-discuss] Issue with java and poll

[Dan McDonald]

No EPOLL in r151014:

commit a5eb7107f06a6e23e8e77e8d3a84c1ff90a73ac6
Author: Bryan Cantrill 
Date:   Sat Feb 14 16:55:35 2015 -0800

5640 want epoll support
Reviewed by: Jerry Jelinek 
Reviewed by: Robert Mustacchi 
Approved by: Garrett D'Amore 

.  .  .

bloody(~/ws/illumos-omnios)[141]% git branch -a --contains 
a5eb7107f06a6e23e8e77e8d3a84c1ff90a73ac6
* master
  upstream
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/r151016
  remotes/origin/r151018
  remotes/origin/r151020
  remotes/origin/r151022
  remotes/origin/upstream
bloody(~/ws/illumos-omnios)[0]% 


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]

I'd recommend snoop -o  on your NAT box/zone.

I tried your steps, and did not see this problem.  My NAT is more 
sophisticated, servicing both my home and a work-from-home segment for OmniTI, 
which was where I tried your reproduction.  NO idea what might've happened.

Are you yourself in Australia?  The problem could be country-local w.r.t. any 
possible mischief.

Dan

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

Re: [OmniOS-discuss] bloody installer system maintenance

[Dan McDonald]

> On Apr 16, 2017, at 7:37 PM, Jens Bauernfeind 
>  wrote:
> 
> Hello,
> 
> is this normal behaviour?
> r151021-20170405.iso
> Platform: VMware Workstation Player 12.5.5-5234757 on latest CentOS7
> OS: Solaris 11 64bit
> 4GB RAM
> 2 CPU
> 30GB vDisk

I have seen this occasionally.

> i entered the shell after that, but dont know where i have to look for
> log files, /var/adm seems to contain nothing useful.
> the service "console-login" is running, and no service is in maintenance
> state. 
> further Installation is straight forward.

By "further installation", do you mean that once you exitted the shell the 
installer came up?  Yeah, this happened to me in this situation as well.

There's a race between initial-login and login:console that sometimes makes SMF 
enter this state.  I've not yet figured out how to deterministically reproduce 
it, but when I do, I can kill it.

Dan

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

Re: [OmniOS-discuss] zdb doesn't find a pool

[Dan McDonald]

That woz was the result of zpool split is news to me (or I missed it, in which 
case I apologize).

I wonder if a toy test with files ala the zfs test suite can reproduce this?

- create 3-way mirror
- zdb
- split one disk
- zdb original and split-created pool

Adding illumos zfs list.

Dan

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

> On Apr 15, 2017, at 9:19 PM, Michael Mounteney  wrote:
> 
> Hello and apology to Dan to whom I've already mentioned this matter on
> IRC.
> 
> Summary:  zdb doesn't see a pool specified by name.
> 
> My (home) server has three pools so:
> 
> 
> # zpool status
>  pool: rpool
> state: ONLINE
>  scan: scrub repaired 0 in 0h2m with 0 errors on Sun Feb 19 14:01:41
> 2017 config:
> 
>NAMESTATE READ WRITE CKSUM
>rpool   ONLINE   0 0 0
>  c2t0d0s0  ONLINE   0 0 0
> 
> errors: No known data errors
> 
>  pool: vault
> state: ONLINE
>  scan: none requested
> config:
> 
>NAME  STATE READ WRITE CKSUM
>vault ONLINE   0 0 0
>  raidz2-0ONLINE   0 0 0
>c2t1d0s0  ONLINE   0 0 0
>c2t2d0s0  ONLINE   0 0 0
>c2t3d0s0  ONLINE   0 0 0
>c2t5d0s0  ONLINE   0 0 0
> 
> errors: No known data errors
> 
>  pool: woz
> state: ONLINE
>  scan: resilvered 359G in 8h21m with 0 errors on Fri Mar 17 03:16:51
>  2017 config:
> 
>NAMESTATE READ WRITE CKSUM
>woz ONLINE   0 0 0
>  c2t4d0s0  ONLINE   0 0 0
> 
> errors: No known data errors
> 
> 
> However, zdb won't see the pool 'woz':
> 
> 
> # zdb vault | head -4
> 
> Cached configuration:
>version: 5000
>name: 'vault'
> # zdb woz
> zdb: can't open 'woz': No such file or directory
> # zdb -l /dev/rdsk/c2t4d0s0 | head -6
> 
> LABEL 0
> 
>version: 5000
>name: 'woz'
>state: 0
> 
> 
> So zdb finds pool 'vault' alright but not 'woz'.  It will however see
> 'woz' if it's referred-to by disk.  The difference which I think might
> be crucial is that 'vault' was created via zpool create, whereas 'woz'
> was created via zpool split.  In the full output of zdb
> -l /dev/rdsk/c2t4d0s0 (omitted here for brevity), there are four labels
> numbered 0 to 3.  The output is much shorter as well;  it doesn't list
> the individual file objects as zdb vault does.
> 
> Is this worth a mention on https://www.illumos.org/issues ?
> 
> __
> Michael Mounteney
> ___
> 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] Setup problems with newest OmniOS 151021 on ESXi 6.5

[Dan McDonald]

> On Apr 14, 2017, at 6:20 AM, Guenther Alka  wrote:
> 
> I found a strange behaviour with the newest 151021 when I tried to setup on 
> ESXi 6.5
> 
> I created a new VM (Solaris 11-64)  with a DVD device connected to the OS 
> .iso.
> On first boot of the VM, the ESXi web console crashed completely with a 
> required reload.
> 
> After reload, the VM console shows a
> - configuring devices
> - ..requesting system maintenance, press ctrl-d to continue
> 
> After ctrl-d I was able to select a bootdisk and install OmniOS
> After setup, reboot work
> 
> A power off/on and the ESXi webconsole crashes again (mostly, not always)

Are you saying that older r151021s did not have this problem?

I know Fusion has a "black screen" problem with Loader, GRUB, et. al, but 
that's new, and only with the combination of the latest Fusion and latest MacOS 
X.

Dan

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

[OmniOS-discuss] ATTENTION ALL WHO WISH TO UPGRADE TO r151022

[Dan McDonald]

We've changed the code-signing regimen for OmniOS r151022.  To that end, if you 
want to be able to upgrade to r151022, you will need to update your "ca-bundle" 
package to include the new root CA certificates.

Normally we don't update obsoleted release, but in the spirit of allowing any 
014-and-later release to update to r151022, we've pushed out:

pkg://omnios/web/ca-bundle@5.11-0.151014:20170414T020006Z
pkg://omnios/web/ca-bundle@5.11-0.151016:20170414T020046Z
pkg://omnios/web/ca-bundle@5.11-0.151018:20170414T020116Z
pkg://omnios/web/ca-bundle@5.11-0.151020:20170414T020145Z

to their respective repo servers.  If you do NOT have the most recent ca-bundle 
package, you will not be able to update to r151022 when the time comes, because 
you will fail with a signature verification error.

Thanks to Dale Ghent for strengthening the new OmniOS CA cert(s).  We're now 
two level, and 4k RSA + SHA512.

Happy updating!
Dan

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

Re: [OmniOS-discuss] I need a bit of testing help...

[Dan McDonald]

It appears there's an additional requirement -- Active Directory.  :(. The 
/dev/random check happens in the join_domain() function of kclient.

Thanks and sorry,
Dan

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

> On Apr 12, 2017, at 11:43 AM, Dan McDonald <dan...@omniti.com> wrote:
> 
> Does anyone have:
> 
> * Working kerberos infrastructure
> 
> * A non-global zone in which they can test kclient(1M)?
> 
> If so, please contact me off-list.
> 
> Thanks,
> Dan
> 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] I need a bit of testing help...

[Dan McDonald]

Does anyone have:

* Working kerberos infrastructure

* A non-global zone in which they can test kclient(1M)?

If so, please contact me off-list.

Thanks,
Dan

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

Re: [OmniOS-discuss] ZPOOL bug after upgrade to r151020

[Dan McDonald]

> On Apr 7, 2017, at 8:26 PM, John Barfield  wrote:
> 
> Greetings,
> 
> I just want to report that after a clean istall of r151020 I found a bug 
> whereby importing an older zpool from r151012 and running zpool upgrade 
> causes an SSD cache device size to be reported incorrectly. (only 1 out of 4 
> devices in this instance)
> 
> The cache device size is 93gb and arcstat reported it to be 680gb.
> 
> I confirmed by monitoring zpool iostat -v and saw the same size being 
> reported.
> 
> We've had a lot of weird io lockups (which is how I found the issue, we didnt 
> notice it until a month after) that brings all of our NFS mounts to a 
> screeching halt and this was the only thing I could find to be out of the 
> ordinary on the system.
> 
> CPU average @1% , 20% of ram free, no crazy processes waiting on IO. It was 
> completely invisible. At least from my testing using several dtrace scripts 
> from the net.
> 
> I can only assume that the incorrect size reporting caused the zpool to fill 
> the cache drive up beyond its physical capacity during periods of heavy load.
> 
> I removed all cache devices and then added them back to the zpool. Then all 
> disks reported correctly again. Format/diskinfo always reported correctly so 
> it was specific to zfs.
> 
> We're monitoring the NAS closely to see if the issues occur again. 

The only thing I could find that might address the symptoms you see is this:

https://illumos.org/issues/7504

Which didn't make it upstream in time to hit r151020.

You should forward this on to the illumos ZFS developers' list:  
z...@lists.illumos.org.

Dan

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

Re: [OmniOS-discuss] How some services boot

[Dan McDonald]

> On Apr 6, 2017, at 2:16 PM, Software Information  
> wrote:
> 
> Hi All
> Just trying to understand how some services work under OmniOS. Please help me 
> to understand this. I have build omnios-r151020-4151d05 and I am running a 
> Git Server in a zone. I used packages to install Git with a pkg install. When 
> I run svcs, I don't see the git service at all but I can use a client to 
> connect to it and the port is open. I am trying to get better at service 
> management. Where can I find the script that is starting this service.

Our git package only contains the client (i.e. the git(1) command).

You're on your own for configuring a git server.

Sorry,
Dan

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

Re: [OmniOS-discuss] network configuration script

[Dan McDonald]

> On Apr 5, 2017, at 1:52 PM, Michael Rasmussen  wrote:
> 
> I prefer using stdout for a broader usage scenario leaving
> decision where to output to the invoker.
> 
> What do you think?

I think that's what I had in mind.  :)

Thanks!
Dan

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

Re: [OmniOS-discuss] network configuration script

[Dan McDonald]

> On Apr 3, 2017, at 4:56 PM, Michael Rasmussen  wrote:
> 
> Btw. What do you exactly mean by 'modified to scribble commands
> into /mnt/.initialboot' ?

Sorry for not getting back to this sooner.

You have an interactive setup.  It then invokes certain commands like "ipadm 
create-addr ".

Instead of invoking those commands, what if it wrote those commands to a file 
(i.e. scribbled those commands :) ) or even stdout?  The file I was imagining 
was "/mnt/.initialboot", because after a fresh ISO/USB installation, any 
commands in the file are invoked once when the new system boots the first time.

One could put the bring-up-networking commands on the newly installed machine 
using your tool and the commands it outputs.

Dan

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

[OmniOS-discuss] Community help opportunity: packages with parent dependencies

[Dan McDonald]

Now that linked-image zones don't necessarily update from global without the 
"-r" flag, we DO need to tag certain packages as "MUST ALWAYS UPGRADE" because 
they have dependencies on the kernel or other global-zone goodies.

Rich Lowe brought this to my attention a long while back, and now it's time to 
kick things off with his suggested list:

http://kebe.com/~danmcd/webrevs/io-parent-deps/

Basically, any lipkg-zone package that MUST be updated when its global-zone 
version is should be tagged per the ones already in this webrev.

I'll be going through packages myself in both illumos, and in omnios-build (if 
there are changes there, they will be updated in a repo called 
"ob-parent-deps").  If anyone wants to help, this is why I started this mail 
thread.  :)

This is the last piece of development work for this bloody cycle, and once it's 
done, all I have to do is finish documentation (there will be a lot with this 
release), find a freeze point for updates from upstream, and make sure 
omnios-build packages are caught up with their respective upstreams.

Thank you!
Dan

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

[OmniOS-discuss] OmniOS User Survey

[Dan McDonald]

OmniTI would like to hear from OmniOS users.  We have a survey that we'd 
appreciate you taking.

There's no extra automatic emails that will result from taking this survey.

Here's the link:

https://www.surveymonkey.com/r/omnios

Please take the survey before May 5th.

Thanks,
Dan

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

[OmniOS-discuss] Bloody update

[Dan McDonald]

A new bloody update is out.  All media has been updated, as has the upstream 
repo server.

REMINDER:  OmniOS repo servers can & should be accessed via https URLs from now 
on.  Just as an extra level of protection.  This will also be true for r151022 
when it ships.

"uname -v" shows omnios-master-0137ede

omnios-build was build from commit a69bc58.

New in this update:

* Perl to 5.24.1!!!  Update your .env files if you have your own on bloody for 
building illumos-gate!  The sample ones we include in /opt/onbld/env have been 
appropriately updated.

* Removal of legacy yyy packages (e.g. BRCMbnxe, SUNWdtrt, except for 
SUNWcs, of course).

* EOF of lms and heci.

* Man page cleanups.

* Zone cleanups for "shutdown", thanks to Bob Friesenhahn for his finding this 
bug.

* More /proc/sys files for LX zones (Joyent OS-6025).

* Kayak build in omnios-build now less sudo-y, and cleaner.

* pciutils to 3.5.4

* pcre to 8.40

* xz to 5.2.3

* nghttp2 to 1.21.0

Happy updating!
Dan

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

[OmniOS-discuss] Got a larval fix for you, Bob!

[Dan McDonald]

I would like you to go into your zones, and patch THEIR version of 
/usr/sbin/shutdown thusly:

--- /usr/sbin/shutdown  Fri Apr 22 16:36:43 2016
+++ /zones/lipkg0/root/usr/sbin/shutdownMon Apr  3 17:54:24 2017
@@ -228,7 +228,9 @@
 
 if [ "$pid1" ] || [ "$pid2" ]
 then
-   /usr/bin/kill $pid1 $pid2 > /dev/null 2>&1
+# XXX KEBE SAYS TRY SOMETHING DIFFERENT...
+   /usr/bin/pwait $pid1 $pid2
+#  /usr/bin/kill $pid1 $pid2 > /dev/null 2>&1
 fi
 
 /sbin/init ${initstate}


I believe the shutdown script is forking procs that don't finish until AFTER 
zoneadmd starts to shut things down.  This causes the problems you see.

The global version of shutdown should not be modified for now (esp. if this 
doesn't work for you, you can use it to recover).

Thanks,
Dan

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

Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue

[Dan McDonald]

> On Apr 3, 2017, at 4:11 PM, Frank Boeye  wrote:
> 
> Do I need to specify an old repository or publisher first again then?

Yes.  Sorry for not being clear about that.  You need to go back to the 006 
publisher and get it all-the-way updated.

Dan

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

Re: [OmniOS-discuss] Continuing hung-zone problems

[Dan McDonald]

> On Apr 3, 2017, at 3:38 PM, Bob Friesenhahn  
> wrote:
> 
> It does not seem that you obtained the same initial error message ("failed to 
> open console master: Device busy") that I always do.

When it fails, I *DO* see this.

Apr  3 15:22:16 bloody zoneadmd[3639]: [ID 702911 daemon.error] [zone 'lipkg0'] 
failed to open console master: Device busy
Apr  3 15:22:16 bloody zoneadmd[3639]: [ID 702911 daemon.error] [zone 'lipkg0'] 
WARNING: could not open master side of zone console for lipkg0 to release slave 
handle: Device busy
Apr  3 15:22:16 bloody zoneadmd[3639]: [ID 702911 daemon.error] [zone 'lipkg0'] 
WARNING: console /devices//pseudo/zconsnex@1/zcons@2 found, but it could not be 
removed.: I/O error


And you may be right about it being a race of some sort.  But between what 
entities I cannot tell as of yet.  As of this second, I cannot get this error 
to manifest.

Dan

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

Re: [OmniOS-discuss] Continuing hung-zone problems

[Dan McDonald]

> On Apr 3, 2017, at 3:18 PM, Dan McDonald <dan...@omniti.com> wrote:
> 
> AND THINGS GET WEIRDER.
> 
> After the failure I documented earlier, I went off to do something else.  
> When I came back, the zsched process was gone, and the zone appeared to be 
> properly shut down.
> 
> So I booted the zone, and uttered "zoneadm -z lipkg0 shutdown".  THIS TIME IT 
> WORKED!

But trying it again failed.

Okay, I see what happened.

1st shutdown failed.  I tried a 2nd shutdown, which also failed, BUT managed to 
unwedge zsched, likely by calling zone_destroy() and having the right thing 
happen.

Sorry for rubberducking on the public mailing list.  :)

Dan

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

Re: [OmniOS-discuss] Continuing hung-zone problems

[Dan McDonald]

> On Apr 3, 2017, at 2:59 PM, Dan McDonald <dan...@omniti.com> wrote:
> 
> Okay.  I will be diving into this now to see WTF happened.  I'm sorry for not 
> paying closer attention to this sooner.

AND THINGS GET WEIRDER.

After the failure I documented earlier, I went off to do something else.  When 
I came back, the zsched process was gone, and the zone appeared to be properly 
shut down.

So I booted the zone, and uttered "zoneadm -z lipkg0 shutdown".  THIS TIME IT 
WORKED!

I noticed *this* in my /var/adm/messages:

Apr  3 15:15:46 bloody genunix: [ID 408114 kern.info] 
/pseudo/zconsnex@1/zcons@2 (zcons2) online

This makes me wonder if something happens wrong the first time a zcons is 
created.  I'll try this again on another box I can reboot fully if need be.

Dan

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

Re: [OmniOS-discuss] Continuing hung-zone problems

[Dan McDonald]

> On Apr 3, 2017, at 2:11 PM, Bob Friesenhahn  
> wrote:
> 
> The problem is definintely with zone 'shutdown'.  I have never seen it happen 
> with 'reboot' or 'halt'.

Which does go through the inittab things.

I've found something.  I can reproduce this on bloody easily:

bloody(~)[0]% sudo zoneadm -z lipkg0 shutdown

zone 'lipkg0': unable to shutdown zone
bloody(~)[1]% zoneadm list -cv
  ID NAME STATUS PATH   BRANDIP
   0 global   running/  ipkg shared
   1 lx1  running/zones/lx1 lx   excl  
   2 lx0  running/zones/lx0 lx   excl  
   3 lx2  running/zones/lx2 lx   excl  
   4 lipkg0   shutting_down /zones/lipkg0  lipkg
excl  
bloody(~)[0]% pgrep -z lipkg0
764
bloody(~)[0]% 

Process 764 is a zsched process.  It's here:

> 0xff007d61fc40::findstack -v
stack pointer for thread ff007d61fc40: ff007d61f950
[ ff007d61f950 _resume_from_idle+0x112() ]
  ff007d61f980 swtch+0x141()
  ff007d61f9c0 cv_wait+0x70(ff1955618148, fbcf8610)
  ff007d61fa50 zone_status_wait_cpr+0xb5(ff1955618000, 8, 
  fbb82a3d)
  ff007d61fb30 zsched+0x5f0(ff007dfbacf0)
  ff007d61fb40 thread_start+8()

Which is in this function:

3007  /*
3008   * Private CPR-safe version of zone_status_wait().
3009   */
3010  static void
3011  zone_status_wait_cpr(zone_t *zone, zone_status_t status, char *str)
3012  {
3013callb_cpr_t cprinfo;
3014  
3015ASSERT(status > ZONE_MIN_STATE && status <= ZONE_MAX_STATE);
3016  
3017CALLB_CPR_INIT(, _status_lock, callb_generic_cpr,
3018str);
3019mutex_enter(_status_lock);
3020while (zone->zone_status < status) {
3021CALLB_CPR_SAFE_BEGIN();
3022cv_wait(>zone_cv, _status_lock);
3023CALLB_CPR_SAFE_END(, _status_lock);
3024}
3025/*
3026 * zone_status_lock is implicitly released by the following.
3027 */
3028CALLB_CPR_EXIT();
3029  }


Okay.  I will be diving into this now to see WTF happened.  I'm sorry for not 
paying closer attention to this sooner.

Dan

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

Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue

[Dan McDonald]

I see the problem...


> On Apr 3, 2017, at 1:47 PM, Frank Boeye  wrote:
> 
> pkg contents -m runtime/perl/manual
> 
> set name=pkg.fmri 
> value=pkg://omnios/runtime/perl/manual@5.16.1,5.11-0.151006:20130507T191120Z
> set name=pkg.summary value="Perl 5.16.1 Programming Language Docs"
> set name=pkg.descr value="Perl 5.16.1 Programming Language Docs"
> set name=publisher value=s...@omniti.com
> file 80eb1eb144aa8dc55993e8e368ca8189e7911bb4 
> chash=cce029c54848ec6178ebd419fd738dd15b671f60 group=bin mode=0755 owner=root 
> path=usr/perl5/5.16.1/bin/pod2html pkg.csize=927 pkg.size=2064
> file 6360c1a609c5a72aa3380f5d2a9f1a576fb2e640 
> chash=be1ecb4772c547a9f7739a28303230c8aac6200b group=bin mode=0755 owner=root 
> path=usr/perl5/5.16.1/bin/pod2latex pkg.csize=3804 pkg.size=10378
> file 5d088db441e21d8faa653427ce905e7125da852e 
> chash=0ff7255b30bd6a2e216c4b20aa6de36780863cf4 group=bin mode=0755 owner=root 
> path=usr/perl5/5.16.1/bin/pod2man pkg.csize=4791 pkg.size=11615
> file a7dd55d275470b2fca194799c30cd04cb0d53d14 
> chash=9d97ff341806398db56fd3b3ba5025c48cefcb08 group=bin mode=0755 owner=root 
> path=usr/perl5/5.16.1/bin/pod2text pkg.csize=3778 pkg.size=9158
> 
> Bunch more files
> 
> file 704d896209dafbb4bd55a3e054273b9ee3c2968c 
> chash=e7cc73a54f163ad5aacf8265641bb0e9610c80d0 group=bin mode=0644 owner=root 
> path=usr/perl5/5.16.1/man/man3/utf8.3 pkg.csize=4590 pkg.size=12203
> file 658bdc92fe9df6d61b2d645be5c4e8b5f1faa68a 
> chash=17d77b6c181ba716d8d78b862aa049d5e624e7c1 group=bin mode=0644 owner=root 
> path=usr/perl5/5.16.1/man/man3/vars.3 pkg.csize=2370 pkg.size=5193
> file 7946cf41e4289d078292daaa3a5b97e29dbd8a20 
> chash=0b7d398714a70ce146727254ea2542d041b5650d group=bin mode=0644 owner=root 
> path=usr/perl5/5.16.1/man/man3/version.3 pkg.csize=5668 pkg.size=15576
> file 77cb31e7b3765e1ec0886fd8a11b5af97dda9a56 
> chash=38552cdd0c7e8f4ce5d1f18a40312dcfda92337c group=bin mode=0644 owner=root 
> path=usr/perl5/5.16.1/man/man3/version::Internals.3 pkg.csize=11021 
> pkg.size=31868
> file 24f98111b69a8b09970c6d50765c8e0c02c93368 
> chash=f69e790ebd4c26817756a41cc45c4671145f3445 group=bin mode=0644 owner=root 
> path=usr/perl5/5.16.1/man/man3/vmsish.3 pkg.csize=3298 pkg.size=7992
> file b5351f32a043da6782154f3fb3b8906db003895e 
> chash=57e11931fe6ce73af627a4652d3cbb714e7a5434 group=bin mode=0644 owner=root 
> path=usr/perl5/5.16.1/man/man3/warnings.3 pkg.csize=2759 pkg.size=8740
> file 9b9ec1c4b3b6918b873126b2a1ce76164b199bfa 
> chash=7155a3420e0f13f2609a5a740581627c94a77af8 group=bin mode=0644 owner=root 
> path=usr/perl5/5.16.1/man/man3/warnings::register.3 pkg.csize=1855 
> pkg.size=4138
> license 8db6c3c8a577b36129555ff15dabf691b4a73c55 
> chash=8f1b2dd37aec20d7b4aaf4ae32bc7b8501678f79 license=Artistic 
> pkg.csize=2416 pkg.size=6321
> depend fmri=runtime/perl@5.16.1,5.11-0.151006 type=incorporate
> depend fmri=runtime/perl@5.16.1,5.11-0.151006 type=require

Wow!  I don't know how runtime/perl/manual ended up with an INCORPORATE 
dependency, but that's what happened.

I have one other suggestion:

- Please just do a vanilla "pkg update" of your 006 first.  It may create a new 
BE, BUT it will update all of the packages.  The revision on your 
runtime/perl/manual is VERY VERY OLD, and has this INCORPORATE dependency which 
is fixed by later revisions within 006.

I should've said this earlier: You can't update to a whole new revision until 
your OLD revision is at its latest possible update.

Please try that and report back.

Thank you,
Dan

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

Re: [OmniOS-discuss] Continuing hung-zone problems

[Dan McDonald]

> On Apr 3, 2017, at 1:40 PM, Bob Friesenhahn  
> wrote:
> 
> The common theme is always the first message "failed to open console master: 
> Device busy".  The failure to unmount filesystems is new to me.

That could be something from the LX code, but I'm not seeing it in my 020 zones 
(and I've several of them).

> All of my zones (some of which do not use NFS and have almost every network 
> service disabled) on my two OmniOS systems are equally plagued with this 
> issue.  I know that I am not alone since others have reported that this is 
> happening to them.

I've probably missed out on those mails, but who else has seen this issue 
(precisely zones taking forever to shutdown)?  I know about the message, but I 
don't see zones being jammed up on shutdown.

I wonder if it's "init 6" specifically?  I use reboot(1M) command, so it does 
not go through the inittab(4) sequence.  Now I'm more fascinated to know what 
process(es) are hanging, because I suspect they arrive via "init 6".

Dan

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

Re: [OmniOS-discuss] network configuration script

[Dan McDonald]

> On Apr 3, 2017, at 12:01 PM, Michael Rasmussen  wrote:
> 
> I will make a new version later today which supports command line. Do
> you need the file attached here or can you live with that you have to
> fetch it from git?

Git is fine assuming the URL you mentioned earlier is the correct repo.  
Otherwise, I'll need a URL from which I can "git clone".

Dan

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

Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue

[Dan McDonald]

Dumb question:  Do you have any non-OmniOS publishers like ms.omniti.com on 
this installation?  If so, let's see if one of those is incorporate-blocking 
you.

If not, you could try, thought this will produce more output:

pkg update -v --be-name=omnios-r151014 entire@11,5.11-0.151014

The output you have indicates perl & vim, being blocked by:

pkg://omnios/runtime/perl/manual@5.16.1,5.11-0.151006:20130507T191120Z

Actually, also please include the output of:

pkg contents -m runtime/perl/manual

Thanks,
Dan

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

Re: [OmniOS-discuss] Continuing hung-zone problems

[Dan McDonald]

> On Apr 2, 2017, at 7:07 PM, Bob Friesenhahn  
> wrote:
> 
> Previously I reported a problem (in the 040 timeframe) in that zones are 
> hanging when being shut down.  Problems continue on that system. Today I am 
> seeing the same issue with a different OmniOS system (version is 
> omnios-r151020-4151d05).
> 
> In this case it was after doing 'init 6' to reboot the system and the problem 
> added about 180 seconds to the shutdown time.  In three reboots, the problem 
> happened twice.

If you have a shell available, you should inspect the available processes to 
see what all is stuck in where.

pgrep -z 

is helpful, as well as:

pstack 
pwdx 

pwdx(1) shows the PWD for a process.  If the process is stuck with 
PWD== that  can't be umounted until the process exits or 
changes PWD.  If that pstack(1) command shows NOTHING, it means it's stuck 
doing something in the kernel.  In that case, "mdb -k" may show you the 
processes from the kernel's pov:

::ps -t

and then you can find the stuck process, and check out its threads in "mdb -k" 
by:

::findstack -v

> This is logged:
> 
> Apr  2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] 
> failed to open console master: Device busy
> Apr  2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] 
> WARNING: could not open master side of zone console for swdev to release 
> slave handle: Device busy
> Apr  2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] 
> WARNING: console /devices//pseudo/zconsnex@1/zcons@0 found, but it could not 
> be removed.: I/O error
> Apr  2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] 
> unable to unmount '/zones/swdev/root/proc'
> Apr  2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] 
> unable to unmount file systems in zone
> Apr  2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] 
> unable to destroy zone
> Apr  2 17:51:53 velma svc.startd[10]: [ID 122153 daemon.warning] 
> svc:/system/zones:default: Method or service exit timed out.  Killing 
> contract 169.
> Apr  2 17:51:53 velma svc.startd[10]: [ID 636263 daemon.warning] 
> svc:/system/zones:default: Method "/lib/svc/method/svc-zones stop" failed due 
> to signal KILL.

You did say you were using that zone as an NFS client.  Perhaps one of the 
processes wasn't really done accessing a remote filesystem?  I noticed the 
unmountable filesystem is procfs for that zone.  I can't tell you why that's 
interesting off the top of my head, that IS interesting to know, however.

Dan

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

Re: [OmniOS-discuss] network configuration script

[Dan McDonald]

I'll need to take a look at this in depth.

Our preferred license is CDDL.  Take a look at the prototypes directory for 
sample headers for each:


https://github.com/omniti-labs/illumos-omnios/tree/master/usr/src/prototypes/

One thing about this, and I need to try it of course, is whether or not this 
could be modified to scribble commands into /mnt/.initialboot as a bonus 
feature of the new Kayak interactive install?  Say under a "post-install 
extras" sub-menu or something.

Pardon the latency.  Today is off for a number of reasons, and I won't be fully 
recombobulated until Tuesday.

Thanks,
Dan

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

Re: [OmniOS-discuss] Bug 6569 r151020

[Dan McDonald]

> On Apr 1, 2017, at 12:07 PM, John Barfield  wrote:
> 
> Thanks for that! 

Add "-a" to that git branch:

git branch -a --contains 

That way you don't have to check out every branch in your local repo.

Dan

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

Re: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?

[Dan McDonald]

> On Mar 30, 2017, at 5:11 PM, Brian Hechinger  wrote:
> 
> I'd like to see a way that network configuration can be disabled from within 
> the zone so that it's set by the host admin and not the zone admin (assuming 
> they are different people).

I thought more people would be in agreement with you, but that appears not to 
be the case.

Rewriting lxinit & friends to allow this sort of admin model is going to be 
harder than I thought, and since r151022 is already late relative to prior 
releases (it's a cadence-breaker thanks to Loader, Python2.7, and 
Kayak-for-ISO), I don't know if getting ipadm(1M) for LX zones would work.  
You're the strongest endorser of doing it so far.

Dan

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

Re: [OmniOS-discuss] Ang: LX Zones question: Do you miss ipadm(1M)?

[Dan McDonald]

> On Mar 30, 2017, at 5:02 PM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> 
> wrote:
> 
> On Thu, 30 Mar 2017, Dan McDonald wrote:
> 
>> 
>>> On Mar 30, 2017, at 4:26 PM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> 
>>> wrote:
>>> 
>>> The only way it could possibly work is if /etc/resolv.conf gets updated in 
>>> the zone.  This is because native user-space apps/libraries take care of 
>>> the DNS lookups rather than kernel code.
>> 
>> Check out /usr/lib/brand/lx/lx_boot_zone_*.  Those scripts scribble 
>> resolv.conf at zone boot time.
> 
> Linux DHCP can overwrite files at any time, possibly weeks after boot.

Interesting.

Given "lxinit" does DHCP too, you probably shouldn't be using any Linux DHCP 
client in an LX zone.

Dan

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