From geoffn at gnaa.net  Sat Mar  3 20:44:38 2018
From: geoffn at gnaa.net (Geoff Nordli)
Date: Sat, 3 Mar 2018 12:44:38 -0800
Subject: [OmniOS-discuss] how to: networking with zones in Omnios running as
	Virtualbox guest
Message-ID: <dbe16d30-5d67-d58d-3063-e9b94ea37ad4@gnaa.net>

Hi.

I use Linux as my desktop and run Virtualbox as the hypervisor.

I started playing with lxzones. ? First, I couldn't login to the Ubuntu 
native container.? I set the root password and then logged in via the 
console.? Then I couldn't get the zone to connect to the outside world.? 
I noticed there were some people having the same problem on ESX.

When I would do a network sniff on the virtualbox host OS, I could see 
the arp requests leaving the zone and the reply back.

1 0.000000000 02:08:20:db:c2:c4 ? ff:ff:ff:ff:ff:ff ARP 60 Who has 
192.168.0.1? Tell 192.168.0.51
2 0.000024439 02:08:20:db:c2:c4 ? ff:ff:ff:ff:ff:ff ARP 60 Who has 
192.168.0.1? Tell 192.168.0.51
3 0.000547144 1c:ab:c0:b1:cc:a2 ? 02:08:20:db:c2:c4 ARP 60 192.168.0.1 
is at 1c:ab:c0:b1:cc:a2

The problem was the arp request would never get back to the zone.

To fix the problem:

Set promiscuous mode set to "allow all" on the guest network adapter

On the omnios guest OS, create a bridge and add your guest OS nic to the 
bridge.

dladm create-bridge vboxbridge

Add the guest OS nic to the bridge.

dladm add-bridge -l e1000g0 vboxbridge


I pulled some of the information from this post: 
https://forums.virtualbox.org/viewtopic.php?t=52428

They created an etherstub, but I didn't have to get it to work.

Geoff

From omnios at citrus-it.net  Mon Mar  5 20:13:19 2018
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Mon, 5 Mar 2018 20:13:19 +0000 (UTC)
Subject: [OmniOS-discuss] [developer] [call for testing] KPTI images (fwd)
Message-ID: <nycvar.TFB.7.76.1803052002130.14205@erncre.pvgehf-vg.arg>


Joyent's illumos fix for the Meltdown vulnerability is nearing
completion and so we  have produced some test images and, along with
Openindiana and SmartOS, are asking people to install and test on as wide a
range of machines as possible.

We've provided this as a hotfix so it can easily be installed into a new
BE by anyone running OmniOS bloody. Have a look at
https://omniosce.org/article/kpti for instructions and some useful mdb
commands to check the installation afterwards.

Please see the original announcement message that was posted to other
lists. If you can, please test and provide feedback.

Thanks,

Andy

---------- Forwarded message ----------
Date: Mon, 5 Mar 2018 13:46:50 +0000
From: John Levon <john.levon at joyent.com>
Reply-To: illumos-developer <developer at lists.illumos.org>
To: oi-dev at openindiana.org, developer at lists.illumos.org,
    smartos-discuss at lists.smartos.org
Subject: [developer] [call for testing] KPTI images

Hi all, please see below for test images for the various
distributions. These images include the KPTI (and PCID) work done by
Joyent up to the current kpti-squash branch. They are non-DEBUG except
as noted.

As before, any and all testing is useful, especially with "weird"
things like LDT-using code, older machines, etc.

Thanks to Aur?lien Larcher and Andy Fiddaman for building the OI and
OmniOS images below.

thanks
john

OpenIndiana:

http://dlc-int.openindiana.org/users/aurelien/kpti/

OmniOSce (bloody):

# pkg update pkg
# pkg apply-hot-fix --be-name=kpti
https://downloads.omniosce.org/pkg/bloody/kpti.p5p
# init 6

or for DEBUG bits:

# pkg apply-hot-fix --be-name=kpti
https://downloads.omniosce.org/pkg/bloody/kpti-DEBUG.p5p

SmartOS:

https://us-east.manta.joyent.com/jlevon/public/bits/kpti/platform-20180305T101513Z.iso
https://us-east.manta.joyent.com/jlevon/public/bits/kpti/platform-20180305T101513Z.tgz

------------------------------------------
illumos: illumos-developer
Permalink: https://illumos.topicbox.com/groups/developer/discussions/T4c9a8fdfb8301f10-Mdd69563eb3591402853dce82
Delivery options: https://illumos.topicbox.com/groups
-- 
Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From an3s.annema at gmail.com  Thu Mar  8 16:05:36 2018
From: an3s.annema at gmail.com (Andries Annema)
Date: Thu, 8 Mar 2018 17:05:36 +0100
Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL
	inheritance)
In-Reply-To: <nycvar.TFB.7.76.1802181940060.14654@erncre.pvgehf-vg.arg>
References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org>
	<8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com>
	<nycvar.TFB.7.76.1802181940060.14654@erncre.pvgehf-vg.arg>
Message-ID: <68d28785-c73e-c10e-cc40-7cc0d839360d@gmail.com>

Hi Andy (and list),

Following the release of r151022ap, I updated my testing VM and poked 
around a bit trying to verify whether the 8984 issue is now indeed 
properly resolved. Well, on the one hand it is, but on the other... I'm 
getting a bit confused whether it is, or if there is something else 
going on still.

It looks like the ACL inheritance issue is indeed resolved when:
- creating files or making directories from CLI (touch, mkdir),
- copying files from CLI (cp),
- creating/copying files from Windows through CIFS/SMB-share (there was 
nothing wrong with that in the first place).

But the issue seems unresolved when:
- using rsync to copy stuff over from one dataset to another.

Check out the output below; I suppose the filenames speak for themselves.

SOURCE DATASET:

root at vm01omniosce ~ # /usr/bin/ls -lVd /tank/media/music
drwxrws---+? 4 root???? media????????? 7 Mar? 8 15:48 /tank/media/music
 ???????????????? owner@:rwxpdDaARWcCos:-d-----:allow
 ???????????????? owner@:rw-pdDaARWc--s:f------:allow
 ???????????????? group@:rwxp--a-R-c--s:-d-----:allow
 ???????????????? group@:rw-p--a-R-c--s:f------:allow
 ????????? group:mediaro:r-x---a-R-c--s:-d-----:allow
 ????????? group:mediaro:r-----a-R-c--s:f------:allow
 ????????????? everyone@:------a-R-c--s:fd-----:allow


TARGET DATASET:

root at vm01omniosce ~ # /usr/bin/ls -lVd /tank/media_uncategorized/
drwxrws---+? 4 root???? media????????? 7 Mar? 8 15:48 
/tank/media_uncategorized/
 ????????????? user:an3s:rwxpdDaARWcCos:-d-----:allow
 ????????????? user:an3s:rw-pdDaARWc--s:f------:allow
 ???????????? user:dlmgr:rwxp--aARWc--s:-d-----:allow
 ???????????? user:dlmgr:rw-p--aARWc--s:f------:allow
 ???????????????? owner@:rwxpdDaARWcCos:-d-----:allow
 ???????????????? owner@:rw-pdDaARWc--s:f------:allow
 ???????????????? group@:rwxp--aARWc--s:-d-----:allow
 ???????????????? group@:rw-p--aARWc--s:f------:allow
 ????????? group:mediaro:r-x---a-R-c--s:-d-----:allow
 ????????? group:mediaro:r-----a-R-c--s:f------:allow
 ????????????? everyone@:------a-R-c--s:fd-----:allow


ACL RESULT AFTER DIFFERENT ACTIONS:

root at vm01omniosce ~ # /usr/bin/ls -lV /tank/media_uncategorized/*.mp3
-rw-rw----+? 1 an3s???? media??? 11613081 Mar? 8 16:15 
/tank/media_uncategorized/file-copied-from-win7.mp3
 ????????????? user:an3s:rw-pdDaARWc--s:------I:allow
 ???????????? user:dlmgr:rw-p--aARWc--s:------I:allow
 ???????????????? owner@:rw-pdDaARWc--s:------I:allow
 ???????????????? group@:rw-p--aARWc--s:------I:allow
 ????????? group:mediaro:r-----a-R-c--s:------I:allow
 ????????????? everyone@:------a-R-c--s:------I:allow
-rw-rw----+? 1 root???? media??? 11613081 Mar? 8 16:15 
/tank/media_uncategorized/file-cp'd.mp3
 ????????????? user:an3s:rw-pdDaARWc--s:------I:allow
 ???????????? user:dlmgr:rw-p--aARWc--s:------I:allow
 ???????????????? owner@:rw-pdDaARWc--s:------I:allow
 ???????????????? group@:rw-p--aARWc--s:------I:allow
 ????????? group:mediaro:r-----a-R-c--s:------I:allow
 ????????????? everyone@:------a-R-c--s:------I:allow
-rw-rw----+? 1 root???? media????????? 0 Mar? 8 16:27 
/tank/media_uncategorized/file-created-from-cli.mp3
 ????????????? user:an3s:rw-pdDaARWc--s:------I:allow
 ???????????? user:dlmgr:rw-p--aARWc--s:------I:allow
 ???????????????? owner@:rw-pdDaARWc--s:------I:allow
 ???????????????? group@:rw-p--aARWc--s:------I:allow
 ????????? group:mediaro:r-----a-R-c--s:------I:allow
 ????????????? everyone@:------a-R-c--s:------I:allow
-rw-r-----+? 1 an3s???? media??? 11613081 Feb 23 21:02 
/tank/media_uncategorized/file-rsync'd-options-rltgoDu.mp3
 ????????????? user:an3s:rw-pdDaARWc--s:------I:allow
 ???????????? user:dlmgr:rw-p--aARWc--s:------I:allow
 ????????? group:mediaro:r-----a-R-c--s:------I:allow
 ???????????????? owner@:rw-p--aARWcCos:-------:allow
 ???????????????? group@:r-----a-R-c--s:-------:allow
 ????????????? everyone@:------a-R-c--s:-------:allow
-rw-rw----+? 1 an3s???? media??? 11613081 Feb 23 21:02 
/tank/media_uncategorized/file-rsync'd-options-rltgoDupAX.mp3
 ????????????? user:an3s:rw-pdDaARWc--s:------I:allow
 ???????????? user:dlmgr:rw-p--aARWc--s:------I:allow
 ????????? group:mediaro:r-----a-R-c--s:------I:allow
 ???????????????? owner@:rw-p--aARWcCos:-------:allow
 ???????????????? group@:rw-p--a-R-c--s:-------:allow
 ????????????? everyone@:------a-R-c--s:-------:allow


Only the rsync'd file does not inherit the ACE's properly. Does this 
make any sense?
I'm using the rsync release from https://pkg.omniosce.org/r151022/core/, 
rsync version 3.1.3-0.151022:20180129T134935Z.

Modifying the rsync options (see file names) doesn't actually really 
matter: the inheritance is broken.

Any thoughts are appreciated! Tnx.

Cheers,
Andries


On 2018-02-18 20:43, Andy Fiddaman wrote:
> On Sun, 18 Feb 2018, Andries Annema wrote:
>
> ; Playing around with r151022, I may have bumped into the same issue here.
> ; The ACE's that I set on the parent directory are nicely inherited, but
> ; on top of that, another ACE for owner@, group@ and everyone@ is added.
>
> Hi,
>
> This does sound like the same issue and we have a fix for this currently in
> testing for OmniOS r151022 which we plan to upstream when it's ready.
>
> If you want to test the hot-fix, a package archive containing an updated
> zfs pachage is available for download at:
>
> https://downloads.omniosce.org/pkg/8984_r151022.p5p
>
> to install please proceed as follows (assuming the downloaded archive
> is in /root):
>
> # pkg set-publisher -g /root/8984_r151022.p5p omnios
> # pkg update -v --be-name=...
> # init 6
> # pkg set-publisher -G /root/8984_r151022.p5p omnios
>
> Andy
>


From henson at acm.org  Thu Mar  8 21:47:56 2018
From: henson at acm.org (Paul B. Henson)
Date: Thu, 8 Mar 2018 13:47:56 -0800
Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks
	ACL	inheritance)
In-Reply-To: <68d28785-c73e-c10e-cc40-7cc0d839360d@gmail.com>
References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org>	<8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com>	<nycvar.TFB.7.76.1802181940060.14654@erncre.pvgehf-vg.arg>
	<68d28785-c73e-c10e-cc40-7cc0d839360d@gmail.com>
Message-ID: <2f8801d3b727$1e858230$5b908690$@acm.org>

> From: Andries Annema
> Sent: Thursday, March 8, 2018 8:06 AM
>
> But the issue seems unresolved when:
>
> - using rsync to copy stuff over from one dataset to another.

I don't think rsync understands ZFS ACLs? So it is most likely trying to duplicate the mode bits while copying, using chmod...

If both sides are zfs, send/receive might be a better option?


From omnios at citrus-it.net  Fri Mar  9 08:59:42 2018
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Fri, 9 Mar 2018 08:59:42 +0000 (UTC)
Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL
 inheritance)
In-Reply-To: <2f8801d3b727$1e858230$5b908690$@acm.org>
References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org>
	<8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com>
	<nycvar.TFB.7.76.1802181940060.14654@erncre.pvgehf-vg.arg>
	<68d28785-c73e-c10e-cc40-7cc0d839360d@gmail.com>
	<2f8801d3b727$1e858230$5b908690$@acm.org>
Message-ID: <nycvar.TFB.7.76.1803090855100.8876@erncre.pvgehf-vg.arg>


On Thu, 8 Mar 2018, Paul B. Henson wrote:

; > From: Andries Annema
; > Sent: Thursday, March 8, 2018 8:06 AM
; >
; > But the issue seems unresolved when:
; >
; > - using rsync to copy stuff over from one dataset to another.
;
; I don't think rsync understands ZFS ACLs? So it is most likely trying to duplicate the mode bits while copying, using chmod...

rsync explicity does do that, it tries to make the permissions on the target
file match the source, including ACLs where it can (I'm also not sure if it
supports NFSv4 ACLs).

>From the man page:

	To give new files the destination-default permissions,
	make sure that the --perms option is off and use
	--chmod=ugo=rwX (which ensures that all non-masked bits get
	enabled).

So, give this a go:

	 rsync -a --no-p --no-g --chmod=ugo=rwX src/ dst/

The extra options need to come after -a.

Regards,

Andy

-- 
Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From miniflowtrader at gmail.com  Fri Mar  9 18:01:34 2018
From: miniflowtrader at gmail.com (Mini Trader)
Date: Fri, 9 Mar 2018 13:01:34 -0500
Subject: [OmniOS-discuss] LX chdir bug with steps to reproduce
In-Reply-To: <9012C25D-BD6D-4619-9748-C0C66753EC86@omniti.com>
References: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
	<7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi>
	<CACFEqhsx4znecKwb6qRi-L8VRddr3mtZun5dmjayAWebPuyEQw@mail.gmail.com>
	<9012C25D-BD6D-4619-9748-C0C66753EC86@omniti.com>
Message-ID: <CACFEqhtVi9g3DvFNzmYXuNj9JgLLAmpgY05skiUfRuMghycS=Q@mail.gmail.com>

Would this bug have been fixed in the latest stable version of OmniOS CE?

On Mon, Jan 16, 2017 at 5:36 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On Jan 16, 2017, at 5:01 PM, Mini Trader <miniflowtrader at gmail.com>
> wrote:
> >
> > We definitely need:
> >
> > https://smartos.org/bugview/OS-5167 (and probably whatever was done
> before it).
>
> Joyent mentioned that very bug to me earlier this afternoon.  During the
> bringup of LX zones, I didn't cherrypick it from illumos-joyent, and now I
> remember why... it unravels a larger ball of yarn.
>
> To that end, I'm attempting that unravelling now.  I doubt it'll be
> backported into r151020, though.  LX is still considered "beta" in 020, and
> stability of the overall system is why I'm loathe to bring in non-LX fixes
> for LX problems (as these all are) into a Stable release.
>
> I'm going to cut a bloody release this week.  It has lots of new things in
> it, and if I'm lucky, it may include these Joyent fixes as well.  If you
> want to help, get a box up to bloody once I cut the release this week.
>
> Thanks, and sorry I can't be of IMMEDIATE assistance,
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180309/7c999f89/attachment-0001.html>

From miniflowtrader at gmail.com  Fri Mar  9 18:34:05 2018
From: miniflowtrader at gmail.com (Mini Trader)
Date: Fri, 9 Mar 2018 13:34:05 -0500
Subject: [OmniOS-discuss] LX chdir bug with steps to reproduce
In-Reply-To: <CACFEqhtVi9g3DvFNzmYXuNj9JgLLAmpgY05skiUfRuMghycS=Q@mail.gmail.com>
References: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
	<7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi>
	<CACFEqhsx4znecKwb6qRi-L8VRddr3mtZun5dmjayAWebPuyEQw@mail.gmail.com>
	<9012C25D-BD6D-4619-9748-C0C66753EC86@omniti.com>
	<CACFEqhtVi9g3DvFNzmYXuNj9JgLLAmpgY05skiUfRuMghycS=Q@mail.gmail.com>
Message-ID: <CACFEqhvGPiAuexQ3D=qZBNHdO+wixv=jwpijZqjp3BmrRq=ZbQ@mail.gmail.com>

This simple python code will break on an LX zone (LTS)

import os
import time

os.chdir('/main/documents/test')
for i in xrange(2000):
    print i
    os.chdir('a')
    print os.getcwd()
    os.chdir('..')


On Fri, Mar 9, 2018 at 1:01 PM, Mini Trader <miniflowtrader at gmail.com>
wrote:

> Would this bug have been fixed in the latest stable version of OmniOS CE?
>
> On Mon, Jan 16, 2017 at 5:36 PM, Dan McDonald <danmcd at omniti.com> wrote:
>
>>
>> > On Jan 16, 2017, at 5:01 PM, Mini Trader <miniflowtrader at gmail.com>
>> wrote:
>> >
>> > We definitely need:
>> >
>> > https://smartos.org/bugview/OS-5167 (and probably whatever was done
>> before it).
>>
>> Joyent mentioned that very bug to me earlier this afternoon.  During the
>> bringup of LX zones, I didn't cherrypick it from illumos-joyent, and now I
>> remember why... it unravels a larger ball of yarn.
>>
>> To that end, I'm attempting that unravelling now.  I doubt it'll be
>> backported into r151020, though.  LX is still considered "beta" in 020, and
>> stability of the overall system is why I'm loathe to bring in non-LX fixes
>> for LX problems (as these all are) into a Stable release.
>>
>> I'm going to cut a bloody release this week.  It has lots of new things
>> in it, and if I'm lucky, it may include these Joyent fixes as well.  If you
>> want to help, get a box up to bloody once I cut the release this week.
>>
>> Thanks, and sorry I can't be of IMMEDIATE assistance,
>> Dan
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180309/23f2ed4a/attachment.html>

From mtalbott at lji.org  Fri Mar  9 18:56:11 2018
From: mtalbott at lji.org (Michael Talbott)
Date: Fri, 9 Mar 2018 10:56:11 -0800
Subject: [OmniOS-discuss] Fibrechannel Tape Library
Message-ID: <D51DFECB-1014-4C50-8AA8-2F46CA0BC8A2@lji.org>

Anyone have any tips to get a fibrechannel based tape library properly recognized in omnios as /dev/changer or similar?

All the zoning is fine and I can see the tape drives and they show in /dev/rmt/, but the library changer is showing up as an unknown type:

# cfgadm -al
Ap_Id                          Type         Receptacle   Occupant     Condition
c12::500084f10010e0e3          unknown      connected    unconfigured unknown
c12::500084f20010e0e3          unknown      connected    unconfigured unknown
c12::500507631248cc65          tape         connected    configured   unknown
c12::500507631248d745          tape         connected    configured   unknown
c12::500507631248d7a2          tape         connected    configured   unknown
c12::50050763124a6979          tape         connected    configured   unknown

I've tried:
add_drv -i '"scsiclass,08" "scsiclass,08.QUALSTAR,*"' sgen
update_drv -fv sgen
reboot

But, no luck. Any suggestions?

Thanks,

Michael

From hasslerd at gmx.li  Fri Mar  9 20:37:59 2018
From: hasslerd at gmx.li (Dominik Hassler)
Date: Fri, 9 Mar 2018 21:37:59 +0100
Subject: [OmniOS-discuss] LX chdir bug with steps to reproduce
In-Reply-To: <CACFEqhvGPiAuexQ3D=qZBNHdO+wixv=jwpijZqjp3BmrRq=ZbQ@mail.gmail.com>
References: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
	<7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi>
	<CACFEqhsx4znecKwb6qRi-L8VRddr3mtZun5dmjayAWebPuyEQw@mail.gmail.com>
	<9012C25D-BD6D-4619-9748-C0C66753EC86@omniti.com>
	<CACFEqhtVi9g3DvFNzmYXuNj9JgLLAmpgY05skiUfRuMghycS=Q@mail.gmail.com>
	<CACFEqhvGPiAuexQ3D=qZBNHdO+wixv=jwpijZqjp3BmrRq=ZbQ@mail.gmail.com>
Message-ID: <63b5a256-226b-5cdd-cbec-6db42f502988@gmx.li>

The fix for the issue you reference (OS-5167) has been integrated in r24
and bloody:

hadfl at bloody-build:/build/illumos-omnios$ git log r151022 --grep "cached
v_path"
hadfl at bloody-build:/build/illumos-omnios$ git log r151024 --grep "cached
v_path"
commit e2fc3408efa6cdfc5e33c73c3567efc8c7592707
Author: Patrick Mooney <pmooney at pfmooney.com>
Date:   Thu Jun 8 21:57:45 2017 +0000

    8376 cached v_path should be kept fresh
    Reviewed by: Jerry Jelinek <jerry.jelinek at joyent.com>
    Reviewed by: Robert Mustacchi <rm at joyent.com>
    Approved by: Gordon Ross <gwr at nexenta.com>
hadfl at bloody-build:/build/illumos-omnios$ git log master --grep "cached
v_path"
commit e2fc3408efa6cdfc5e33c73c3567efc8c7592707
Author: Patrick Mooney <pmooney at pfmooney.com>
Date:   Thu Jun 8 21:57:45 2017 +0000

    8376 cached v_path should be kept fresh
    Reviewed by: Jerry Jelinek <jerry.jelinek at joyent.com>
    Reviewed by: Robert Mustacchi <rm at joyent.com>
    Approved by: Gordon Ross <gwr at nexenta.com>


running your python code on bloody does not seem to be broken.


On 03/09/2018 07:34 PM, Mini Trader wrote:
> This simple python code will break on an LX zone (LTS)
> 
> import os
> import time
> 
> os.chdir('/main/documents/test')
> for i in xrange(2000):
> ? ? print i
> ? ? os.chdir('a')
> ? ? print os.getcwd()
> ? ? os.chdir('..')
> 
> 
> On Fri, Mar 9, 2018 at 1:01 PM, Mini Trader <miniflowtrader at gmail.com
> <mailto:miniflowtrader at gmail.com>> wrote:
> 
>     Would this bug have been fixed in the latest stable version of
>     OmniOS CE?
> 
>     On Mon, Jan 16, 2017 at 5:36 PM, Dan McDonald <danmcd at omniti.com
>     <mailto:danmcd at omniti.com>> wrote:
> 
> 
>         > On Jan 16, 2017, at 5:01 PM, Mini Trader <miniflowtrader at gmail.com <mailto:miniflowtrader at gmail.com>> wrote:
>         >
>         > We definitely need:
>         >
>         > https://smartos.org/bugview/OS-5167
>         <https://smartos.org/bugview/OS-5167> (and probably whatever was
>         done before it).
> 
>         Joyent mentioned that very bug to me earlier this afternoon.?
>         During the bringup of LX zones, I didn't cherrypick it from
>         illumos-joyent, and now I remember why... it unravels a larger
>         ball of yarn.
> 
>         To that end, I'm attempting that unravelling now.? I doubt it'll
>         be backported into r151020, though.? LX is still considered
>         "beta" in 020, and stability of the overall system is why I'm
>         loathe to bring in non-LX fixes for LX problems (as these all
>         are) into a Stable release.
> 
>         I'm going to cut a bloody release this week.? It has lots of new
>         things in it, and if I'm lucky, it may include these Joyent
>         fixes as well.? If you want to help, get a box up to bloody once
>         I cut the release this week.
> 
>         Thanks, and sorry I can't be of IMMEDIATE assistance,
>         Dan
> 
> 
> 
> 
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 

From mtalbott at lji.org  Sat Mar 10 01:06:54 2018
From: mtalbott at lji.org (Michael Talbott)
Date: Fri, 9 Mar 2018 17:06:54 -0800
Subject: [OmniOS-discuss] Fibrechannel Tape Library
In-Reply-To: <D51DFECB-1014-4C50-8AA8-2F46CA0BC8A2@lji.org>
References: <D51DFECB-1014-4C50-8AA8-2F46CA0BC8A2@lji.org>
Message-ID: <CAGP7N4MnR4M=Quffk1-+PcbjCbq74dAoHZ-pQgPxcHkJ03vvBA@mail.gmail.com>

Managed to fix my own problem. I forgot to set the library itself in
logical mode instead of physical mode. The os now magically sees the
changer and populates /dev/scsi/changer/ appropriately.

On Fri, Mar 9, 2018 at 10:56 AM, Michael Talbott <mtalbott at lji.org> wrote:

> Anyone have any tips to get a fibrechannel based tape library properly
> recognized in omnios as /dev/changer or similar?
>
> All the zoning is fine and I can see the tape drives and they show in
> /dev/rmt/, but the library changer is showing up as an unknown type:
>
> # cfgadm -al
> Ap_Id                          Type         Receptacle   Occupant
>  Condition
> c12::500084f10010e0e3          unknown      connected    unconfigured
> unknown
> c12::500084f20010e0e3          unknown      connected    unconfigured
> unknown
> c12::500507631248cc65          tape         connected    configured
>  unknown
> c12::500507631248d745          tape         connected    configured
>  unknown
> c12::500507631248d7a2          tape         connected    configured
>  unknown
> c12::50050763124a6979          tape         connected    configured
>  unknown
>
> I've tried:
> add_drv -i '"scsiclass,08" "scsiclass,08.QUALSTAR,*"' sgen
> update_drv -fv sgen
> reboot
>
> But, no luck. Any suggestions?
>
> Thanks,
>
> Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180309/7b926bf1/attachment.html>

From chip at innovates.com  Tue Mar 13 19:25:28 2018
From: chip at innovates.com (Schweiss, Chip)
Date: Tue, 13 Mar 2018 14:25:28 -0500
Subject: [OmniOS-discuss] 8806 back port
Message-ID: <CALeZrrQHcxWZb3KLUBrCxK0=v4Uhbiqk_96L5Y1hCr0-A6XrSA@mail.gmail.com>

The 8806 backport will no longer apply to r151022ap.

# pkg apply-hot-fix --be-name=omniosce-r151022ap-8806 8806-backport_r22.p5p
No updates available for this image.
pkg set-publisher: Could not refresh the catalog for omnios

file protocol error: code: E_FAILED_INIT (2) reason: Package archive
/root/8806-backport_r22.p5p does not contain the requested package file(s):
publisher/omnios/catalog/catalog.attrs.
Repository URL: 'file:///root/8806-backport_r22.p5p'. (happened 4 times)
----

Some things are not clear about hot-fixes.

Do they need to be reapplied after each update?

Are they only compatible with the release they are built against?

Cheers!
-Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180313/5417067b/attachment.html>

From omnios at citrus-it.net  Tue Mar 13 20:22:28 2018
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Tue, 13 Mar 2018 20:22:28 +0000 (UTC)
Subject: [OmniOS-discuss] 8806 back port
In-Reply-To: <CALeZrrQHcxWZb3KLUBrCxK0=v4Uhbiqk_96L5Y1hCr0-A6XrSA@mail.gmail.com>
References: <CALeZrrQHcxWZb3KLUBrCxK0=v4Uhbiqk_96L5Y1hCr0-A6XrSA@mail.gmail.com>
Message-ID: <nycvar.TFB.7.76.1803132009500.27881@erncre.pvgehf-vg.arg>


On Tue, 13 Mar 2018, Schweiss, Chip wrote:

; The 8806 backport will no longer apply to r151022ap.
; No updates available for this image.

I think this is the relevant message - we need to look at why you got the
additional errors but ignore them for now.

; Some things are not clear about hot-fixes.
;
; Do they need to be reapplied after each update?

No. A hotfix usually updates a specific package; 'system/kernel' in the
case of 8806.

If a weekly update includes a new version of that package, then it will also
include the rolled-up hotfix. If a weekly update does not include that
package then you keep the hot-fixed version in place.

; Are they only compatible with the release they are built against?

No, but they won't apply if you have the same or a newer version of the
affected package installed already.

HTH.

Andy

-- 
Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From omnios at citrus-it.net  Tue Mar 13 22:50:04 2018
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Tue, 13 Mar 2018 22:50:04 +0000 (UTC)
Subject: [OmniOS-discuss] 8806 back port
In-Reply-To: <CALeZrrQHcxWZb3KLUBrCxK0=v4Uhbiqk_96L5Y1hCr0-A6XrSA@mail.gmail.com>
References: <CALeZrrQHcxWZb3KLUBrCxK0=v4Uhbiqk_96L5Y1hCr0-A6XrSA@mail.gmail.com>
Message-ID: <nycvar.TFB.7.76.1803132248490.21035@erncre.pvgehf-vg.arg>


On Tue, 13 Mar 2018, Schweiss, Chip wrote:

; pkg set-publisher: Could not refresh the catalog for omnios
;
; file protocol error: code: E_FAILED_INIT (2) reason: Package archive
; /root/8806-backport_r22.p5p does not contain the requested package file(s):
; publisher/omnios/catalog/catalog.attrs.
; Repository URL: 'file:///root/8806-backport_r22.p5p'. (happened 4 times)

Hi Chip,

This error message actually looks like you still have the publisher set
from the last time you applied the fix by hand. Can you check the output
of 'pkg publisher'?

Andy

-- 
Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From chip at innovates.com  Thu Mar 15 15:20:21 2018
From: chip at innovates.com (Schweiss, Chip)
Date: Thu, 15 Mar 2018 10:20:21 -0500
Subject: [OmniOS-discuss] 8806 back port
In-Reply-To: <nycvar.TFB.7.76.1803132248490.21035@erncre.pvgehf-vg.arg>
References: <CALeZrrQHcxWZb3KLUBrCxK0=v4Uhbiqk_96L5Y1hCr0-A6XrSA@mail.gmail.com>
	<nycvar.TFB.7.76.1803132248490.21035@erncre.pvgehf-vg.arg>
Message-ID: <CALeZrrSROLTjOAceY2fHJ2XBHQSbpfhgn+7XoQrMdbV-R8DS_g@mail.gmail.com>

On Tue, Mar 13, 2018 at 5:50 PM, Andy Fiddaman <omnios at citrus-it.net> wrote:

>
> This error message actually looks like you still have the publisher set
> from the last time you applied the fix by hand. Can you check the output
> of 'pkg publisher'?
>
>
That was it.   It was still there because I rolled back to the BE before it
was previously installed.

Thanks!

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

From chip at innovates.com  Fri Mar 16 14:18:17 2018
From: chip at innovates.com (Schweiss, Chip)
Date: Fri, 16 Mar 2018 09:18:17 -0500
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
Message-ID: <CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>

While this problem was originally ruled out as an artifact of running as a
virtual machine, I've now installed the same HBA and JBOD to a physical
server.   The problem is exactly the same.

This is on OmniOS CE r151024r

-Chip

# /usr/lib/fm/fmd/fmd -o fg=true -o client.debug=true
fmd: [ loading modules ... ABORT: attempted zero-length allocation:
Operation not supported
Abort (core dumped)

> $C
080462a8 libc.so.1`_lwp_kill+0x15(1, 6, 80462f8, fef42000, fef42000,
8046330)
080462c8 libc.so.1`raise+0x2b(6, 0, 80462e0, feec1b59, 0, 0)
08046318 libc.so.1`abort+0x10e(fead51f0, 0, fede2a40, 30, 524f4241,
61203a54)
08046748 libses.so.1`ses_panic(fdde6758, 8046774, 80467e8, fdb6b67a,
83eb0a8, fdb6c398)
08046768 libses.so.1`ses_realloc(fdde6758, 0, 83f01b8, fdde6130, fddf7000,
fdb6658f)
08046788 libses.so.1`ses_alloc+0x27(0, feb80000, 6, 10, ee0, 8111627)
080467b8 libses.so.1`ses_zalloc+0x1e(0, 0, 73, fdb6659d, 83f0190, 8)
08046838 ses2.so`elem_parse_aes_misc+0x91(81114f4, 83eb0a8, 8, fdb65d85)
08046888 ses2.so`elem_parse_aes+0xfc(82f1ac8, 83f0288, 80468f8, fdb80eae)
080468a8 ses2.so`ses2_fill_element_node+0x37(82f1ac8, 83f0288, 832e930, 4)
080468d8 ses2.so`ses2_node_parse+0x53(82f1ac8, 83f0288, e, fddf7000)
080468f8 libses.so.1`ses_fill_node+0x22(83f0288, 83f0348, fdde38ae,
fdde394c)
08046918 libses.so.1`ses_fill_tree+0x21(83f0288, 82f1c88, 83e4cc8, fdde394c)
08046938 libses.so.1`ses_fill_tree+0x33(82f1d88, 82f1b88, 8046968, fdde394c)
08046958 libses.so.1`ses_fill_tree+0x33(82f1c88, 82ef758, 8046998, fdde394c)
08046978 libses.so.1`ses_fill_tree+0x33(82f1b88, 0, 18, fddf7000)
08046998 libses.so.1`ses_fill_snap+0x22(82f08a0, 80, 0, fdde56eb)
080469e8 libses.so.1`ses_snap_new+0x325(82f1b48, 0, 8046a18, fdde3006)
08046a18 libses.so.1`ses_open_scsi+0xc4(1, 82ef688, 8046aa0, fed71c1b,
81053f8, fede4042)
08046a68 libses.so.1`ses_open+0x98(1, 8046aa0, 0, feecedd3, 43, fde1fc58)
08046eb8 ses.so`ses_process_dir+0x133(fde20159, 83cc348, 0, fed77e40)
08046ee8 ses.so`ses_enum+0xc1(81053f8, 82f21a0, 8386608, 0, 400, 0)
08046f38 libtopo.so.1`topo_mod_enumerate+0xc4(81053f8, 82f21a0, 82fb1c8,
8386608, 0, 400)
08046f88 libtopo.so.1`enum_run+0xe9(8105a18, 83d6f78, a, fed7b1dd)
08046fd8 libtopo.so.1`topo_xml_range_process+0x13e(8105a18, 82eb5b0,
83d6f78, 8047008)
08047028 libtopo.so.1`tf_rdata_new+0x135(8105a18, 82dfde0, 82eb5b0, 82f21a0)
08047088 libtopo.so.1`topo_xml_walk+0x246(8105a18, 82dfde0, 82ebd30,
82f21a0, 8105a18, 83cbac0)
080470e8 libtopo.so.1`topo_xml_walk+0x1b2(8105a18, 82dfde0, 82de080,
82f21a0)
08047128 libtopo.so.1`dependent_create+0x127(8105a18, 82dfde0, 83d3aa0,
82de080, 82f21a0, fed7b1f9)
08047168 libtopo.so.1`dependents_create+0x64(8105a18, 82dfde0, 83d3aa0,
82de300, 82f21a0, 81eb0d8)
08047218 libtopo.so.1`pad_process+0x51e(8105a18, 83ce100, 82de300, 82f21a0,
83ce128, 81d8638)
08047278 libtopo.so.1`topo_xml_range_process+0x31f(8105a18, 82de300,
83ce100, 80472a8)
080472c8 libtopo.so.1`tf_rdata_new+0x135(8105a18, 82dfde0, 82de300, 81eb198)
08047328 libtopo.so.1`topo_xml_walk+0x246(8105a18, 82dfde0, 82d1ca0,
81eb198, 8103f40, fed8c000)
08047358 libtopo.so.1`topo_xml_enum+0x67(8105a18, 82dfde0, 81eb198,
feac2000)
08047488 libtopo.so.1`topo_file_load+0x139(8105a18, 81eb198, fe20c127,
fe20bda2, 0, 82d2000)
080474b8 libtopo.so.1`topo_mod_enummap+0x26(8105a18, 81eb198, fe20c127,
fe20bda2, 8105a18, fe20b11c)
08047508 x86pi.so`x86pi_enum_start+0xc5(8105a18, 8047530, 8047538,
fe205580, 8105a18, 8105a18)
08047558 x86pi.so`x86pi_enum+0x55(8105a18, 81eb198, 81d8a90, 0, 0, 0)
080475a8 libtopo.so.1`topo_mod_enumerate+0xc4(8105a18, 81eb198, 80ebf38,
81d8a90, 0, 0)
080475f8 libtopo.so.1`enum_run+0xe9(8105b68, 81f1070, a, fed7b1dd)
08047648 libtopo.so.1`topo_xml_range_process+0x13e(8105b68, 81f94c8,
81f1070, 8047678)
08047698 libtopo.so.1`tf_rdata_new+0x135(8105b68, 81f4240, 81f94c8, 81eb198)
080476f8 libtopo.so.1`topo_xml_walk+0x246(8105b68, 81f4240, 81f9608,
81eb198, 8103f40, fed8c000)
08047728 libtopo.so.1`topo_xml_enum+0x67(8105b68, 81f4240, 81eb198, 81d8ad0)
08047858 libtopo.so.1`topo_file_load+0x139(8105b68, 81eb198, 80f3f38,
81d8aa0, 0, 2c)
08047898 libtopo.so.1`topo_tree_enum+0x89(8103f40, 81f51c8, 80478c8,
fe70e6f8, 81f7f78, 8103f40)
080478b8 libtopo.so.1`topo_tree_enum_all+0x20(8103f40, 81f7f78, 80478f8,
fed71087)
080478f8 libtopo.so.1`topo_snap_create+0x13d(8103f40, 804794c, 0, fed7118d,
807c010, 4d5)
08047928 libtopo.so.1`topo_snap_hold+0x56(8103f40, 0, 804794c, 80e7f08, 0,
8047ac8)
08047968 fmd_topo_update+0x9f(80e7f08, 8085dfa, 8047a68, 80601f7, 0, 0)
08047978 fmd_topo_init+0xb(0, 0, 0, 0, 2, 80992f8)
08047a68 fmd_run+0x118(809a8c0, ffffffff, 0, 2)
08047ae8 main+0x344(8047adc, fef4f348, 8047b18, 805fdd3, 5, 8047b24)
08047b18 _start+0x83(5, 8047c38, 8047c4c, 8047c4f, 8047c57, 8047c5a)


On Fri, Feb 16, 2018 at 10:57 AM, Schweiss, Chip <chip at innovates.com> wrote:

> On Fri, Feb 16, 2018 at 10:47 AM, Robert Mustacchi <rm at joyent.com> wrote:
>
>> We're getting a zero length allocation here. It appears that the number
>> of phys that we're detecting in one of the elements is probably zero. Is
>> it possible to upload the core so we can confirm the data and fix the
>> ses module to handle this, potentially odd, case?
>>
>>
> Sure, where would you like me to upload the core?
>
> I've put it here if you'd like to grab it:  ftp://ftp.nrg.wustl.edu/
> pub/zfs/fmd.core
>
> -Chip
>
>
>
>> Thanks,
>> Robert
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180316/3bbd2a94/attachment.html>

From chip at innovates.com  Fri Mar 16 15:24:41 2018
From: chip at innovates.com (Schweiss, Chip)
Date: Fri, 16 Mar 2018 10:24:41 -0500
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
Message-ID: <CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>

I need to get this JBOD working with OmniOS.  Is there a way to get FMD to
ignore this SES device until this issue is fixed?

It is a RAID, Inc. 4U 96-Bay
http://www.raidinc.com/products/object-storage/ability-4u-96-bay

-Chip

On Fri, Mar 16, 2018 at 9:18 AM, Schweiss, Chip <chip at innovates.com> wrote:

> While this problem was originally ruled out as an artifact of running as a
> virtual machine, I've now installed the same HBA and JBOD to a physical
> server.   The problem is exactly the same.
>
> This is on OmniOS CE r151024r
>
> -Chip
>
> # /usr/lib/fm/fmd/fmd -o fg=true -o client.debug=true
> fmd: [ loading modules ... ABORT: attempted zero-length allocation:
> Operation not supported
> Abort (core dumped)
>
> > $C
> 080462a8 libc.so.1`_lwp_kill+0x15(1, 6, 80462f8, fef42000, fef42000,
> 8046330)
> 080462c8 libc.so.1`raise+0x2b(6, 0, 80462e0, feec1b59, 0, 0)
> 08046318 libc.so.1`abort+0x10e(fead51f0, 0, fede2a40, 30, 524f4241,
> 61203a54)
> 08046748 libses.so.1`ses_panic(fdde6758, 8046774, 80467e8, fdb6b67a,
> 83eb0a8, fdb6c398)
> 08046768 libses.so.1`ses_realloc(fdde6758, 0, 83f01b8, fdde6130,
> fddf7000, fdb6658f)
> 08046788 libses.so.1`ses_alloc+0x27(0, feb80000, 6, 10, ee0, 8111627)
> 080467b8 libses.so.1`ses_zalloc+0x1e(0, 0, 73, fdb6659d, 83f0190, 8)
> 08046838 ses2.so`elem_parse_aes_misc+0x91(81114f4, 83eb0a8, 8, fdb65d85)
> 08046888 ses2.so`elem_parse_aes+0xfc(82f1ac8, 83f0288, 80468f8, fdb80eae)
> 080468a8 ses2.so`ses2_fill_element_node+0x37(82f1ac8, 83f0288, 832e930, 4)
> 080468d8 ses2.so`ses2_node_parse+0x53(82f1ac8, 83f0288, e, fddf7000)
> 080468f8 libses.so.1`ses_fill_node+0x22(83f0288, 83f0348, fdde38ae,
> fdde394c)
> 08046918 libses.so.1`ses_fill_tree+0x21(83f0288, 82f1c88, 83e4cc8,
> fdde394c)
> 08046938 libses.so.1`ses_fill_tree+0x33(82f1d88, 82f1b88, 8046968,
> fdde394c)
> 08046958 libses.so.1`ses_fill_tree+0x33(82f1c88, 82ef758, 8046998,
> fdde394c)
> 08046978 libses.so.1`ses_fill_tree+0x33(82f1b88, 0, 18, fddf7000)
> 08046998 libses.so.1`ses_fill_snap+0x22(82f08a0, 80, 0, fdde56eb)
> 080469e8 libses.so.1`ses_snap_new+0x325(82f1b48, 0, 8046a18, fdde3006)
> 08046a18 libses.so.1`ses_open_scsi+0xc4(1, 82ef688, 8046aa0, fed71c1b,
> 81053f8, fede4042)
> 08046a68 libses.so.1`ses_open+0x98(1, 8046aa0, 0, feecedd3, 43, fde1fc58)
> 08046eb8 ses.so`ses_process_dir+0x133(fde20159, 83cc348, 0, fed77e40)
> 08046ee8 ses.so`ses_enum+0xc1(81053f8, 82f21a0, 8386608, 0, 400, 0)
> 08046f38 libtopo.so.1`topo_mod_enumerate+0xc4(81053f8, 82f21a0, 82fb1c8,
> 8386608, 0, 400)
> 08046f88 libtopo.so.1`enum_run+0xe9(8105a18, 83d6f78, a, fed7b1dd)
> 08046fd8 libtopo.so.1`topo_xml_range_process+0x13e(8105a18, 82eb5b0,
> 83d6f78, 8047008)
> 08047028 libtopo.so.1`tf_rdata_new+0x135(8105a18, 82dfde0, 82eb5b0,
> 82f21a0)
> 08047088 libtopo.so.1`topo_xml_walk+0x246(8105a18, 82dfde0, 82ebd30,
> 82f21a0, 8105a18, 83cbac0)
> 080470e8 libtopo.so.1`topo_xml_walk+0x1b2(8105a18, 82dfde0, 82de080,
> 82f21a0)
> 08047128 libtopo.so.1`dependent_create+0x127(8105a18, 82dfde0, 83d3aa0,
> 82de080, 82f21a0, fed7b1f9)
> 08047168 libtopo.so.1`dependents_create+0x64(8105a18, 82dfde0, 83d3aa0,
> 82de300, 82f21a0, 81eb0d8)
> 08047218 libtopo.so.1`pad_process+0x51e(8105a18, 83ce100, 82de300,
> 82f21a0, 83ce128, 81d8638)
> 08047278 libtopo.so.1`topo_xml_range_process+0x31f(8105a18, 82de300,
> 83ce100, 80472a8)
> 080472c8 libtopo.so.1`tf_rdata_new+0x135(8105a18, 82dfde0, 82de300,
> 81eb198)
> 08047328 libtopo.so.1`topo_xml_walk+0x246(8105a18, 82dfde0, 82d1ca0,
> 81eb198, 8103f40, fed8c000)
> 08047358 libtopo.so.1`topo_xml_enum+0x67(8105a18, 82dfde0, 81eb198,
> feac2000)
> 08047488 libtopo.so.1`topo_file_load+0x139(8105a18, 81eb198, fe20c127,
> fe20bda2, 0, 82d2000)
> 080474b8 libtopo.so.1`topo_mod_enummap+0x26(8105a18, 81eb198, fe20c127,
> fe20bda2, 8105a18, fe20b11c)
> 08047508 x86pi.so`x86pi_enum_start+0xc5(8105a18, 8047530, 8047538,
> fe205580, 8105a18, 8105a18)
> 08047558 x86pi.so`x86pi_enum+0x55(8105a18, 81eb198, 81d8a90, 0, 0, 0)
> 080475a8 libtopo.so.1`topo_mod_enumerate+0xc4(8105a18, 81eb198, 80ebf38,
> 81d8a90, 0, 0)
> 080475f8 libtopo.so.1`enum_run+0xe9(8105b68, 81f1070, a, fed7b1dd)
> 08047648 libtopo.so.1`topo_xml_range_process+0x13e(8105b68, 81f94c8,
> 81f1070, 8047678)
> 08047698 libtopo.so.1`tf_rdata_new+0x135(8105b68, 81f4240, 81f94c8,
> 81eb198)
> 080476f8 libtopo.so.1`topo_xml_walk+0x246(8105b68, 81f4240, 81f9608,
> 81eb198, 8103f40, fed8c000)
> 08047728 libtopo.so.1`topo_xml_enum+0x67(8105b68, 81f4240, 81eb198,
> 81d8ad0)
> 08047858 libtopo.so.1`topo_file_load+0x139(8105b68, 81eb198, 80f3f38,
> 81d8aa0, 0, 2c)
> 08047898 libtopo.so.1`topo_tree_enum+0x89(8103f40, 81f51c8, 80478c8,
> fe70e6f8, 81f7f78, 8103f40)
> 080478b8 libtopo.so.1`topo_tree_enum_all+0x20(8103f40, 81f7f78, 80478f8,
> fed71087)
> 080478f8 libtopo.so.1`topo_snap_create+0x13d(8103f40, 804794c, 0,
> fed7118d, 807c010, 4d5)
> 08047928 libtopo.so.1`topo_snap_hold+0x56(8103f40, 0, 804794c, 80e7f08,
> 0, 8047ac8)
> 08047968 fmd_topo_update+0x9f(80e7f08, 8085dfa, 8047a68, 80601f7, 0, 0)
> 08047978 fmd_topo_init+0xb(0, 0, 0, 0, 2, 80992f8)
> 08047a68 fmd_run+0x118(809a8c0, ffffffff, 0, 2)
> 08047ae8 main+0x344(8047adc, fef4f348, 8047b18, 805fdd3, 5, 8047b24)
> 08047b18 _start+0x83(5, 8047c38, 8047c4c, 8047c4f, 8047c57, 8047c5a)
>
>
> On Fri, Feb 16, 2018 at 10:57 AM, Schweiss, Chip <chip at innovates.com>
> wrote:
>
>> On Fri, Feb 16, 2018 at 10:47 AM, Robert Mustacchi <rm at joyent.com> wrote:
>>
>>> We're getting a zero length allocation here. It appears that the number
>>> of phys that we're detecting in one of the elements is probably zero. Is
>>> it possible to upload the core so we can confirm the data and fix the
>>> ses module to handle this, potentially odd, case?
>>>
>>>
>> Sure, where would you like me to upload the core?
>>
>> I've put it here if you'd like to grab it:  ftp://ftp.nrg.wustl.edu/p
>> ub/zfs/fmd.core
>>
>> -Chip
>>
>>
>>
>>> Thanks,
>>> Robert
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180316/6b7084a5/attachment-0001.html>

From richard.elling at richardelling.com  Fri Mar 16 20:42:41 2018
From: richard.elling at richardelling.com (Richard Elling)
Date: Fri, 16 Mar 2018 13:42:41 -0700
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
	<CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
Message-ID: <C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>

fmadm allows you to load/unload modules.
 -- richard

> On Mar 16, 2018, at 8:24 AM, Schweiss, Chip <chip at innovates.com> wrote:
> 
> I need to get this JBOD working with OmniOS.  Is there a way to get FMD to ignore this SES device until this issue is fixed?   
> 
> It is a RAID, Inc. 4U 96-Bay  http://www.raidinc.com/products/object-storage/ability-4u-96-bay <http://www.raidinc.com/products/object-storage/ability-4u-96-bay> 
> 
> -Chip
> 
> On Fri, Mar 16, 2018 at 9:18 AM, Schweiss, Chip <chip at innovates.com <mailto:chip at innovates.com>> wrote:
> While this problem was originally ruled out as an artifact of running as a virtual machine, I've now installed the same HBA and JBOD to a physical server.   The problem is exactly the same.   
> 
> This is on OmniOS CE r151024r
> 
> -Chip
> 
> # /usr/lib/fm/fmd/fmd -o fg=true -o client.debug=true
> fmd: [ loading modules ... ABORT: attempted zero-length allocation: Operation not supported
> Abort (core dumped)
> 
> > $C
> 080462a8 libc.so.1`_lwp_kill+0x15(1, 6, 80462f8, fef42000, fef42000, 8046330)
> 080462c8 libc.so.1`raise+0x2b(6, 0, 80462e0, feec1b59, 0, 0)
> 08046318 libc.so.1`abort+0x10e(fead51f0, 0, fede2a40, 30, 524f4241, 61203a54)
> 08046748 libses.so.1`ses_panic(fdde6758, 8046774, 80467e8, fdb6b67a, 83eb0a8, fdb6c398)
> 08046768 libses.so.1`ses_realloc(fdde6758, 0, 83f01b8, fdde6130, fddf7000, fdb6658f)
> 08046788 libses.so.1`ses_alloc+0x27(0, feb80000, 6, 10, ee0, 8111627)
> 080467b8 libses.so.1`ses_zalloc+0x1e(0, 0, 73, fdb6659d, 83f0190, 8)
> 08046838 ses2.so`elem_parse_aes_misc+0x91(81114f4, 83eb0a8, 8, fdb65d85)
> 08046888 ses2.so`elem_parse_aes+0xfc(82f1ac8, 83f0288, 80468f8, fdb80eae)
> 080468a8 ses2.so`ses2_fill_element_node+0x37(82f1ac8, 83f0288, 832e930, 4)
> 080468d8 ses2.so`ses2_node_parse+0x53(82f1ac8, 83f0288, e, fddf7000)
> 080468f8 libses.so.1`ses_fill_node+0x22(83f0288, 83f0348, fdde38ae, fdde394c)
> 08046918 libses.so.1`ses_fill_tree+0x21(83f0288, 82f1c88, 83e4cc8, fdde394c)
> 08046938 libses.so.1`ses_fill_tree+0x33(82f1d88, 82f1b88, 8046968, fdde394c)
> 08046958 libses.so.1`ses_fill_tree+0x33(82f1c88, 82ef758, 8046998, fdde394c)
> 08046978 libses.so.1`ses_fill_tree+0x33(82f1b88, 0, 18, fddf7000)
> 08046998 libses.so.1`ses_fill_snap+0x22(82f08a0, 80, 0, fdde56eb)
> 080469e8 libses.so.1`ses_snap_new+0x325(82f1b48, 0, 8046a18, fdde3006)
> 08046a18 libses.so.1`ses_open_scsi+0xc4(1, 82ef688, 8046aa0, fed71c1b, 81053f8, fede4042)
> 08046a68 libses.so.1`ses_open+0x98(1, 8046aa0, 0, feecedd3, 43, fde1fc58)
> 08046eb8 ses.so`ses_process_dir+0x133(fde20159, 83cc348, 0, fed77e40)
> 08046ee8 ses.so`ses_enum+0xc1(81053f8, 82f21a0, 8386608, 0, 400, 0)
> 08046f38 libtopo.so.1`topo_mod_enumerate+0xc4(81053f8, 82f21a0, 82fb1c8, 8386608, 0, 400)
> 08046f88 libtopo.so.1`enum_run+0xe9(8105a18, 83d6f78, a, fed7b1dd)
> 08046fd8 libtopo.so.1`topo_xml_range_process+0x13e(8105a18, 82eb5b0, 83d6f78, 8047008)
> 08047028 libtopo.so.1`tf_rdata_new+0x135(8105a18, 82dfde0, 82eb5b0, 82f21a0)
> 08047088 libtopo.so.1`topo_xml_walk+0x246(8105a18, 82dfde0, 82ebd30, 82f21a0, 8105a18, 83cbac0)
> 080470e8 libtopo.so.1`topo_xml_walk+0x1b2(8105a18, 82dfde0, 82de080, 82f21a0)
> 08047128 libtopo.so.1`dependent_create+0x127(8105a18, 82dfde0, 83d3aa0, 82de080, 82f21a0, fed7b1f9)
> 08047168 libtopo.so.1`dependents_create+0x64(8105a18, 82dfde0, 83d3aa0, 82de300, 82f21a0, 81eb0d8)
> 08047218 libtopo.so.1`pad_process+0x51e(8105a18, 83ce100, 82de300, 82f21a0, 83ce128, 81d8638)
> 08047278 libtopo.so.1`topo_xml_range_process+0x31f(8105a18, 82de300, 83ce100, 80472a8)
> 080472c8 libtopo.so.1`tf_rdata_new+0x135(8105a18, 82dfde0, 82de300, 81eb198)
> 08047328 libtopo.so.1`topo_xml_walk+0x246(8105a18, 82dfde0, 82d1ca0, 81eb198, 8103f40, fed8c000)
> 08047358 libtopo.so.1`topo_xml_enum+0x67(8105a18, 82dfde0, 81eb198, feac2000)
> 08047488 libtopo.so.1`topo_file_load+0x139(8105a18, 81eb198, fe20c127, fe20bda2, 0, 82d2000)
> 080474b8 libtopo.so.1`topo_mod_enummap+0x26(8105a18, 81eb198, fe20c127, fe20bda2, 8105a18, fe20b11c)
> 08047508 x86pi.so`x86pi_enum_start+0xc5(8105a18, 8047530, 8047538, fe205580, 8105a18, 8105a18)
> 08047558 x86pi.so`x86pi_enum+0x55(8105a18, 81eb198, 81d8a90, 0, 0, 0)
> 080475a8 libtopo.so.1`topo_mod_enumerate+0xc4(8105a18, 81eb198, 80ebf38, 81d8a90, 0, 0)
> 080475f8 libtopo.so.1`enum_run+0xe9(8105b68, 81f1070, a, fed7b1dd)
> 08047648 libtopo.so.1`topo_xml_range_process+0x13e(8105b68, 81f94c8, 81f1070, 8047678)
> 08047698 libtopo.so.1`tf_rdata_new+0x135(8105b68, 81f4240, 81f94c8, 81eb198)
> 080476f8 libtopo.so.1`topo_xml_walk+0x246(8105b68, 81f4240, 81f9608, 81eb198, 8103f40, fed8c000)
> 08047728 libtopo.so.1`topo_xml_enum+0x67(8105b68, 81f4240, 81eb198, 81d8ad0)
> 08047858 libtopo.so.1`topo_file_load+0x139(8105b68, 81eb198, 80f3f38, 81d8aa0, 0, 2c)
> 08047898 libtopo.so.1`topo_tree_enum+0x89(8103f40, 81f51c8, 80478c8, fe70e6f8, 81f7f78, 8103f40)
> 080478b8 libtopo.so.1`topo_tree_enum_all+0x20(8103f40, 81f7f78, 80478f8, fed71087)
> 080478f8 libtopo.so.1`topo_snap_create+0x13d(8103f40, 804794c, 0, fed7118d, 807c010, 4d5)
> 08047928 libtopo.so.1`topo_snap_hold+0x56(8103f40, 0, 804794c, 80e7f08, 0, 8047ac8)
> 08047968 fmd_topo_update+0x9f(80e7f08, 8085dfa, 8047a68, 80601f7, 0, 0)
> 08047978 fmd_topo_init+0xb(0, 0, 0, 0, 2, 80992f8)
> 08047a68 fmd_run+0x118(809a8c0, ffffffff, 0, 2)
> 08047ae8 main+0x344(8047adc, fef4f348, 8047b18, 805fdd3, 5, 8047b24)
> 08047b18 _start+0x83(5, 8047c38, 8047c4c, 8047c4f, 8047c57, 8047c5a)
> 
> 
> On Fri, Feb 16, 2018 at 10:57 AM, Schweiss, Chip <chip at innovates.com <mailto:chip at innovates.com>> wrote:
> On Fri, Feb 16, 2018 at 10:47 AM, Robert Mustacchi <rm at joyent.com <mailto:rm at joyent.com>> wrote:
> We're getting a zero length allocation here. It appears that the number
> of phys that we're detecting in one of the elements is probably zero. Is
> it possible to upload the core so we can confirm the data and fix the
> ses module to handle this, potentially odd, case?
> 
> 
> Sure, where would you like me to upload the core?
> 
> I've put it here if you'd like to grab it:  ftp://ftp.nrg.wustl.edu/pub/zfs/fmd.core <ftp://ftp.nrg.wustl.edu/pub/zfs/fmd.core>
> 
> -Chip
> 
>  
> Thanks,
> Robert
> 
> 
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180316/3a4b542b/attachment.html>

From an3s.annema at gmail.com  Sun Mar 18 13:58:34 2018
From: an3s.annema at gmail.com (Andries Annema)
Date: Sun, 18 Mar 2018 14:58:34 +0100
Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL
	inheritance)
In-Reply-To: <nycvar.TFB.7.76.1803090855100.8876@erncre.pvgehf-vg.arg>
References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org>
	<8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com>
	<nycvar.TFB.7.76.1802181940060.14654@erncre.pvgehf-vg.arg>
	<68d28785-c73e-c10e-cc40-7cc0d839360d@gmail.com>
	<2f8801d3b727$1e858230$5b908690$@acm.org>
	<nycvar.TFB.7.76.1803090855100.8876@erncre.pvgehf-vg.arg>
Message-ID: <94fd5aac-2cda-246f-7d34-c30c13b9b2f1@gmail.com>

Thanks Andy, for pointing that out. So it seems to be a "feature" of how 
rsync handles permissions.
I've been fiddling around with those rsync options, but I couldn't get 
it right. That's not a biggy though, I'll take an other approach: use 
rsync to copy the data over and afterwards correct the ACLs on the 
target by running commands like:

"find <location> type -f -exec /usr/bin/chmod <file-ACLs> && find 
<location> type -d -exec /usr/bin/chmod <dir-ACLs> && chmod 
<file-and-dir-ACLs>"

That will get me where I want to be.

@Paul: both sides are indeed ZFS, but send/receive in this case is not 
an option, as I'm trying to split a large dataset (with a number of 
toplevel subdirectories) into multiple smaller datasets (one per 
toplevel subdir). But the above strategy will get me there, it just 
requires one extra step.

Cheers,
Andries


On 2018-03-09 9:59, Andy Fiddaman wrote:
> On Thu, 8 Mar 2018, Paul B. Henson wrote:
>
> ; > From: Andries Annema
> ; > Sent: Thursday, March 8, 2018 8:06 AM
> ; >
> ; > But the issue seems unresolved when:
> ; >
> ; > - using rsync to copy stuff over from one dataset to another.
> ;
> ; I don't think rsync understands ZFS ACLs? So it is most likely trying to duplicate the mode bits while copying, using chmod...
>
> rsync explicity does do that, it tries to make the permissions on the target
> file match the source, including ACLs where it can (I'm also not sure if it
> supports NFSv4 ACLs).
>
>  From the man page:
>
> 	To give new files the destination-default permissions,
> 	make sure that the --perms option is off and use
> 	--chmod=ugo=rwX (which ensures that all non-masked bits get
> 	enabled).
>
> So, give this a go:
>
> 	 rsync -a --no-p --no-g --chmod=ugo=rwX src/ dst/
>
> The extra options need to come after -a.
>
> Regards,
>
> Andy
>

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

From david.ledger at ivdcs.co.uk  Sun Mar 18 14:46:06 2018
From: david.ledger at ivdcs.co.uk (David Ledger)
Date: Sun, 18 Mar 2018 14:46:06 +0000
Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL
	inheritance)
In-Reply-To: <94fd5aac-2cda-246f-7d34-c30c13b9b2f1@gmail.com>
References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org>
	<8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com>
	<nycvar.TFB.7.76.1802181940060.14654@erncre.pvgehf-vg.arg>
	<68d28785-c73e-c10e-cc40-7cc0d839360d@gmail.com>
	<2f8801d3b727$1e858230$5b908690$@acm.org>
	<nycvar.TFB.7.76.1803090855100.8876@erncre.pvgehf-vg.arg>
	<94fd5aac-2cda-246f-7d34-c30c13b9b2f1@gmail.com>
Message-ID: <87C4CCD9-9A03-4632-BE92-FCDBD484E0C5@ivdcs.co.uk>

On 18 Mar 2018, at 13:58, Andries Annema wrote:

> Thanks Andy, for pointing that out. So it seems to be a "feature" of 
> how rsync handles permissions.
> I've been fiddling around with those rsync options, but I couldn't get 
> it right. That's not a biggy though, I'll take an other approach: use 
> rsync to copy the data over and afterwards correct the ACLs on the 
> target by running commands like:
>
> "find <location> type -f -exec /usr/bin/chmod <file-ACLs> && find 
> <location> type -d -exec /usr/bin/chmod <dir-ACLs> && chmod 
> <file-and-dir-ACLs>"
>
> That will get me where I want to be.
>
> @Paul: both sides are indeed ZFS, but send/receive in this case is not 
> an option, as I'm trying to split a large dataset (with a number of 
> toplevel subdirectories) into multiple smaller datasets (one per 
> toplevel subdir). But the above strategy will get me there, it just 
> requires one extra step.
>
> Cheers,
> Andries

Had to do something similar recently. Did a snapshot + clone of 
original, on original; removed the stuff I didn?t want from the clone; 
then zsf sent to where I wanted it. Removed clone and repeated for the 
next top level. Etc.  Your data size may prevent you from doing that if 
it?s large.

David


> On 2018-03-09 9:59, Andy Fiddaman wrote:
>> On Thu, 8 Mar 2018, Paul B. Henson wrote:
>>
>> ; > From: Andries Annema
>> ; > Sent: Thursday, March 8, 2018 8:06 AM
>> ; >
>> ; > But the issue seems unresolved when:
>> ; >
>> ; > - using rsync to copy stuff over from one dataset to another.
>> ;
>> ; I don't think rsync understands ZFS ACLs? So it is most likely 
>> trying to duplicate the mode bits while copying, using chmod...
>>
>> rsync explicity does do that, it tries to make the permissions on the 
>> target
>> file match the source, including ACLs where it can (I'm also not sure 
>> if it
>> supports NFSv4 ACLs).
>>
>>  From the man page:
>>
>> 	To give new files the destination-default permissions,
>> 	make sure that the --perms option is off and use
>> 	--chmod=ugo=rwX (which ensures that all non-masked bits get
>> 	enabled).
>>
>> So, give this a go:
>>
>> 	 rsync -a --no-p --no-g --chmod=ugo=rwX src/ dst/
>>
>> The extra options need to come after -a.
>>
>> Regards,
>>
>> Andy
>>


> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss




David

From chip at innovates.com  Mon Mar 19 13:24:53 2018
From: chip at innovates.com (Schweiss, Chip)
Date: Mon, 19 Mar 2018 08:24:53 -0500
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
	<CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
	<C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>
Message-ID: <CALeZrrQ+3Nj3A2RibyO+HRfNF=oL5es7cU+bCrW+h3QepYr2hQ@mail.gmail.com>

Even unloading all the modules except 'fmd-self-diagnosis' which will not
unload, fmd still dies as soon as I plug in the JBOD.

# fmadm config
MODULE                   VERSION STATUS  DESCRIPTION
fmd-self-diagnosis       1.0     active  Fault Manager Self-Diagnosis

# fmadm unload fmd-self-diagnosis
fmadm: failed to unload fmd-self-diagnosis: module is in use and cannot be
unloaded

Looks like I'm dead in the water to make this work with Illumos until this
bug is fixed.

-Chip

On Fri, Mar 16, 2018 at 3:42 PM, Richard Elling <
richard.elling at richardelling.com> wrote:

> fmadm allows you to load/unload modules.
>  -- richard
>
> On Mar 16, 2018, at 8:24 AM, Schweiss, Chip <chip at innovates.com> wrote:
>
> I need to get this JBOD working with OmniOS.  Is there a way to get FMD to
> ignore this SES device until this issue is fixed?
>
> It is a RAID, Inc. 4U 96-Bay  http://www.raidinc.
> com/products/object-storage/ability-4u-96-bay
>
> -Chip
>
> On Fri, Mar 16, 2018 at 9:18 AM, Schweiss, Chip <chip at innovates.com>
> wrote:
>
>> While this problem was originally ruled out as an artifact of running as
>> a virtual machine, I've now installed the same HBA and JBOD to a physical
>> server.   The problem is exactly the same.
>>
>> This is on OmniOS CE r151024r
>>
>> -Chip
>>
>> # /usr/lib/fm/fmd/fmd -o fg=true -o client.debug=true
>> fmd: [ loading modules ... ABORT: attempted zero-length allocation:
>> Operation not supported
>> Abort (core dumped)
>>
>> > $C
>> 080462a8 libc.so.1`_lwp_kill+0x15(1, 6, 80462f8, fef42000, fef42000,
>> 8046330)
>> 080462c8 libc.so.1`raise+0x2b(6, 0, 80462e0, feec1b59, 0, 0)
>> 08046318 libc.so.1`abort+0x10e(fead51f0, 0, fede2a40, 30, 524f4241,
>> 61203a54)
>> 08046748 libses.so.1`ses_panic(fdde6758, 8046774, 80467e8, fdb6b67a,
>> 83eb0a8, fdb6c398)
>> 08046768 libses.so.1`ses_realloc(fdde6758, 0, 83f01b8, fdde6130,
>> fddf7000, fdb6658f)
>> 08046788 libses.so.1`ses_alloc+0x27(0, feb80000, 6, 10, ee0, 8111627)
>> 080467b8 libses.so.1`ses_zalloc+0x1e(0, 0, 73, fdb6659d, 83f0190, 8)
>> 08046838 ses2.so`elem_parse_aes_misc+0x91(81114f4, 83eb0a8, 8, fdb65d85)
>> 08046888 ses2.so`elem_parse_aes+0xfc(82f1ac8, 83f0288, 80468f8, fdb80eae)
>> 080468a8 ses2.so`ses2_fill_element_node+0x37(82f1ac8, 83f0288, 832e930,
>> 4)
>> 080468d8 ses2.so`ses2_node_parse+0x53(82f1ac8, 83f0288, e, fddf7000)
>> 080468f8 libses.so.1`ses_fill_node+0x22(83f0288, 83f0348, fdde38ae,
>> fdde394c)
>> 08046918 libses.so.1`ses_fill_tree+0x21(83f0288, 82f1c88, 83e4cc8,
>> fdde394c)
>> 08046938 libses.so.1`ses_fill_tree+0x33(82f1d88, 82f1b88, 8046968,
>> fdde394c)
>> 08046958 libses.so.1`ses_fill_tree+0x33(82f1c88, 82ef758, 8046998,
>> fdde394c)
>> 08046978 libses.so.1`ses_fill_tree+0x33(82f1b88, 0, 18, fddf7000)
>> 08046998 libses.so.1`ses_fill_snap+0x22(82f08a0, 80, 0, fdde56eb)
>> 080469e8 libses.so.1`ses_snap_new+0x325(82f1b48, 0, 8046a18, fdde3006)
>> 08046a18 libses.so.1`ses_open_scsi+0xc4(1, 82ef688, 8046aa0, fed71c1b,
>> 81053f8, fede4042)
>> 08046a68 libses.so.1`ses_open+0x98(1, 8046aa0, 0, feecedd3, 43, fde1fc58)
>> 08046eb8 ses.so`ses_process_dir+0x133(fde20159, 83cc348, 0, fed77e40)
>> 08046ee8 ses.so`ses_enum+0xc1(81053f8, 82f21a0, 8386608, 0, 400, 0)
>> 08046f38 libtopo.so.1`topo_mod_enumerate+0xc4(81053f8, 82f21a0, 82fb1c8,
>> 8386608, 0, 400)
>> 08046f88 libtopo.so.1`enum_run+0xe9(8105a18, 83d6f78, a, fed7b1dd)
>> 08046fd8 libtopo.so.1`topo_xml_range_process+0x13e(8105a18, 82eb5b0,
>> 83d6f78, 8047008)
>> 08047028 libtopo.so.1`tf_rdata_new+0x135(8105a18, 82dfde0, 82eb5b0,
>> 82f21a0)
>> 08047088 libtopo.so.1`topo_xml_walk+0x246(8105a18, 82dfde0, 82ebd30,
>> 82f21a0, 8105a18, 83cbac0)
>> 080470e8 libtopo.so.1`topo_xml_walk+0x1b2(8105a18, 82dfde0, 82de080,
>> 82f21a0)
>> 08047128 libtopo.so.1`dependent_create+0x127(8105a18, 82dfde0, 83d3aa0,
>> 82de080, 82f21a0, fed7b1f9)
>> 08047168 libtopo.so.1`dependents_create+0x64(8105a18, 82dfde0, 83d3aa0,
>> 82de300, 82f21a0, 81eb0d8)
>> 08047218 libtopo.so.1`pad_process+0x51e(8105a18, 83ce100, 82de300,
>> 82f21a0, 83ce128, 81d8638)
>> 08047278 libtopo.so.1`topo_xml_range_process+0x31f(8105a18, 82de300,
>> 83ce100, 80472a8)
>> 080472c8 libtopo.so.1`tf_rdata_new+0x135(8105a18, 82dfde0, 82de300,
>> 81eb198)
>> 08047328 libtopo.so.1`topo_xml_walk+0x246(8105a18, 82dfde0, 82d1ca0,
>> 81eb198, 8103f40, fed8c000)
>> 08047358 libtopo.so.1`topo_xml_enum+0x67(8105a18, 82dfde0, 81eb198,
>> feac2000)
>> 08047488 libtopo.so.1`topo_file_load+0x139(8105a18, 81eb198, fe20c127,
>> fe20bda2, 0, 82d2000)
>> 080474b8 libtopo.so.1`topo_mod_enummap+0x26(8105a18, 81eb198, fe20c127,
>> fe20bda2, 8105a18, fe20b11c)
>> 08047508 x86pi.so`x86pi_enum_start+0xc5(8105a18, 8047530, 8047538,
>> fe205580, 8105a18, 8105a18)
>> 08047558 x86pi.so`x86pi_enum+0x55(8105a18, 81eb198, 81d8a90, 0, 0, 0)
>> 080475a8 libtopo.so.1`topo_mod_enumerate+0xc4(8105a18, 81eb198, 80ebf38,
>> 81d8a90, 0, 0)
>> 080475f8 libtopo.so.1`enum_run+0xe9(8105b68, 81f1070, a, fed7b1dd)
>> 08047648 libtopo.so.1`topo_xml_range_process+0x13e(8105b68, 81f94c8,
>> 81f1070, 8047678)
>> 08047698 libtopo.so.1`tf_rdata_new+0x135(8105b68, 81f4240, 81f94c8,
>> 81eb198)
>> 080476f8 libtopo.so.1`topo_xml_walk+0x246(8105b68, 81f4240, 81f9608,
>> 81eb198, 8103f40, fed8c000)
>> 08047728 libtopo.so.1`topo_xml_enum+0x67(8105b68, 81f4240, 81eb198,
>> 81d8ad0)
>> 08047858 libtopo.so.1`topo_file_load+0x139(8105b68, 81eb198, 80f3f38,
>> 81d8aa0, 0, 2c)
>> 08047898 libtopo.so.1`topo_tree_enum+0x89(8103f40, 81f51c8, 80478c8,
>> fe70e6f8, 81f7f78, 8103f40)
>> 080478b8 libtopo.so.1`topo_tree_enum_all+0x20(8103f40, 81f7f78, 80478f8,
>> fed71087)
>> 080478f8 libtopo.so.1`topo_snap_create+0x13d(8103f40, 804794c, 0,
>> fed7118d, 807c010, 4d5)
>> 08047928 libtopo.so.1`topo_snap_hold+0x56(8103f40, 0, 804794c, 80e7f08,
>> 0, 8047ac8)
>> 08047968 fmd_topo_update+0x9f(80e7f08, 8085dfa, 8047a68, 80601f7, 0, 0)
>> 08047978 fmd_topo_init+0xb(0, 0, 0, 0, 2, 80992f8)
>> 08047a68 fmd_run+0x118(809a8c0, ffffffff, 0, 2)
>> 08047ae8 main+0x344(8047adc, fef4f348, 8047b18, 805fdd3, 5, 8047b24)
>> 08047b18 _start+0x83(5, 8047c38, 8047c4c, 8047c4f, 8047c57, 8047c5a)
>>
>>
>> On Fri, Feb 16, 2018 at 10:57 AM, Schweiss, Chip <chip at innovates.com>
>> wrote:
>>
>>> On Fri, Feb 16, 2018 at 10:47 AM, Robert Mustacchi <rm at joyent.com>
>>> wrote:
>>>
>>>> We're getting a zero length allocation here. It appears that the number
>>>> of phys that we're detecting in one of the elements is probably zero. Is
>>>> it possible to upload the core so we can confirm the data and fix the
>>>> ses module to handle this, potentially odd, case?
>>>>
>>>>
>>> Sure, where would you like me to upload the core?
>>>
>>> I've put it here if you'd like to grab it:  ftp://ftp.nrg.wustl.edu/p
>>> ub/zfs/fmd.core
>>>
>>> -Chip
>>>
>>>
>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>
>>>
>>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180319/1600674b/attachment.html>

From omnios at citrus-it.net  Mon Mar 19 14:19:43 2018
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Mon, 19 Mar 2018 14:19:43 +0000 (UTC)
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <CALeZrrQ+3Nj3A2RibyO+HRfNF=oL5es7cU+bCrW+h3QepYr2hQ@mail.gmail.com>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
	<CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
	<C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>
	<CALeZrrQ+3Nj3A2RibyO+HRfNF=oL5es7cU+bCrW+h3QepYr2hQ@mail.gmail.com>
Message-ID: <nycvar.TFB.7.76.1803191417290.22360@erncre.pvgehf-vg.arg>


On Mon, 19 Mar 2018, Schweiss, Chip wrote:

; Looks like I'm dead in the water to make this work with Illumos until this
; bug is fixed.

Chip,

I'll have a look at this for you and get a hot-fix built. I have the core
file that you made available so just need to go through and work out why
it thinks there are 0 phys somewhere.

Andy

-- 
Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From chip at innovates.com  Mon Mar 19 14:25:54 2018
From: chip at innovates.com (Schweiss, Chip)
Date: Mon, 19 Mar 2018 09:25:54 -0500
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <nycvar.TFB.7.76.1803191417290.22360@erncre.pvgehf-vg.arg>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
	<CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
	<C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>
	<CALeZrrQ+3Nj3A2RibyO+HRfNF=oL5es7cU+bCrW+h3QepYr2hQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191417290.22360@erncre.pvgehf-vg.arg>
Message-ID: <CALeZrrSuqxUWWY6twzEUcDB_8sjSHD1kqiENApzqzznaNjz0fQ@mail.gmail.com>

On Mon, Mar 19, 2018 at 9:19 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:

>
> I'll have a look at this for you and get a hot-fix built. I have the core
> file that you made available so just need to go through and work out why
> it thinks there are 0 phys somewhere.
>
>
Many thanks!

In discusscussion with JBOD vendor support, this JBOD has two SAS
expanders, which are linked together.  One is likely incorrectly reporting
0 and should be ignored.

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

From omnios at citrus-it.net  Mon Mar 19 14:33:46 2018
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Mon, 19 Mar 2018 14:33:46 +0000 (UTC)
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <CALeZrrSuqxUWWY6twzEUcDB_8sjSHD1kqiENApzqzznaNjz0fQ@mail.gmail.com>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
	<CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
	<C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>
	<CALeZrrQ+3Nj3A2RibyO+HRfNF=oL5es7cU+bCrW+h3QepYr2hQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191417290.22360@erncre.pvgehf-vg.arg>
	<CALeZrrSuqxUWWY6twzEUcDB_8sjSHD1kqiENApzqzznaNjz0fQ@mail.gmail.com>
Message-ID: <nycvar.TFB.7.76.1803191432490.26427@erncre.pvgehf-vg.arg>


On Mon, 19 Mar 2018, Schweiss, Chip wrote:

; On Mon, Mar 19, 2018 at 9:19 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:
;
; >
; > I'll have a look at this for you and get a hot-fix built. I have the core
; > file that you made available so just need to go through and work out why
; > it thinks there are 0 phys somewhere.
; >
; >
; Many thanks!
;
; In discusscussion with JBOD vendor support, this JBOD has two SAS
; expanders, which are linked together.  One is likely incorrectly reporting
; 0 and should be ignored.

The device is identifying as ESC_ELECTRONICS rather than a SAS_EXPANDER but
I'll do some more digging.

Andy

-- 
Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From chip at innovates.com  Mon Mar 19 14:38:53 2018
From: chip at innovates.com (Schweiss, Chip)
Date: Mon, 19 Mar 2018 09:38:53 -0500
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <nycvar.TFB.7.76.1803191432490.26427@erncre.pvgehf-vg.arg>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
	<CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
	<C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>
	<CALeZrrQ+3Nj3A2RibyO+HRfNF=oL5es7cU+bCrW+h3QepYr2hQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191417290.22360@erncre.pvgehf-vg.arg>
	<CALeZrrSuqxUWWY6twzEUcDB_8sjSHD1kqiENApzqzznaNjz0fQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191432490.26427@erncre.pvgehf-vg.arg>
Message-ID: <CALeZrrSXt-TWh=mZAuLT0eqjpJM2eWcoAupskWuvPCvoGxtteQ@mail.gmail.com>

On Mon, Mar 19, 2018 at 9:33 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:

>
> On Mon, 19 Mar 2018, Schweiss, Chip wrote:
>
> ; On Mon, Mar 19, 2018 at 9:19 AM, Andy Fiddaman <omnios at citrus-it.net>
> wrote:
> ;
> ; >
> ; > I'll have a look at this for you and get a hot-fix built. I have the
> core
> ; > file that you made available so just need to go through and work out
> why
> ; > it thinks there are 0 phys somewhere.
> ; >
> ; >
> ; Many thanks!
> ;
> ; In discusscussion with JBOD vendor support, this JBOD has two SAS
> ; expanders, which are linked together.  One is likely incorrectly
> reporting
> ; 0 and should be ignored.
>
> The device is identifying as ESC_ELECTRONICS rather than a SAS_EXPANDER but
> I'll do some more digging.
>
>
You might be on to something.  I was suspicious of Element 96 when
examining via sg_ses.  This JBOD has 96 slots and no display panel.  The
vendor suspected other issues.

sg_ses -p ed /dev/es/ses1
  RAIDINC   96BAY             1715
  Primary enclosure logical identifier (hex): 500093d230938000
Element Descriptor In diagnostic page:
  generation code: 0x1
  element descriptor list (grouped by type):
    Element type: Array device slot, subenclosure id: 0 [ti=0]
      Overall descriptor: Array Dev Slot
      Element 0 descriptor: SLOT 01 11
      Element 1 descriptor: SLOT 02 12
      Element 2 descriptor: SLOT 03 13
      Element 3 descriptor: SLOT 04 14
      Element 4 descriptor: SLOT 05 15
      Element 5 descriptor: SLOT 06 16
      Element 6 descriptor: SLOT 07 17
      Element 7 descriptor: SLOT 08 18
      Element 8 descriptor: SLOT 09 19
      Element 9 descriptor: SLOT 10 1A
      Element 10 descriptor: SLOT 11 1B
      Element 11 descriptor: SLOT 12 1C
      Element 12 descriptor: SLOT 13 1D
      Element 13 descriptor: SLOT 14 1E
      Element 14 descriptor: SLOT 15 21
      Element 15 descriptor: SLOT 16 22
      Element 16 descriptor: SLOT 17 23
      Element 17 descriptor: SLOT 18 24
      Element 18 descriptor: SLOT 19 25
      Element 19 descriptor: SLOT 20 26
      Element 20 descriptor: SLOT 21 27
      Element 21 descriptor: SLOT 22 28
      Element 22 descriptor: SLOT 23 29
      Element 23 descriptor: SLOT 24 2A
      Element 24 descriptor: SLOT 25 2B
      Element 25 descriptor: SLOT 26 2C
      Element 26 descriptor: SLOT 27 2D
      Element 27 descriptor: SLOT 28 2E
      Element 28 descriptor: SLOT 29 31
      Element 29 descriptor: SLOT 30 32
      Element 30 descriptor: SLOT 31 33
      Element 31 descriptor: SLOT 32 34
      Element 32 descriptor: SLOT 33 35
      Element 33 descriptor: SLOT 34 36
      Element 34 descriptor: SLOT 35 37
      Element 35 descriptor: SLOT 36 38
      Element 36 descriptor: SLOT 37 39
      Element 37 descriptor: SLOT 38 3A
      Element 38 descriptor: SLOT 39 3B
      Element 39 descriptor: SLOT 40 3C
      Element 40 descriptor: SLOT 41 3D
      Element 41 descriptor: SLOT 42 3E
      Element 42 descriptor: SLOT 43 41
      Element 43 descriptor: SLOT 44 42
      Element 44 descriptor: SLOT 45 43
      Element 45 descriptor: SLOT 46 44
      Element 46 descriptor: SLOT 47 45
      Element 47 descriptor: SLOT 48 46
      Element 48 descriptor: SLOT 49 47
      Element 49 descriptor: SLOT 50 49
      Element 50 descriptor: SLOT 51 4A
      Element 51 descriptor: SLOT 52 4B
      Element 52 descriptor: SLOT 53 4C
      Element 53 descriptor: SLOT 54 4D
      Element 54 descriptor: SLOT 55 4E
      Element 55 descriptor: SLOT 56 51
      Element 56 descriptor: SLOT 57 52
      Element 57 descriptor: SLOT 58 53
      Element 58 descriptor: SLOT 59 54
      Element 59 descriptor: SLOT 60 55
      Element 60 descriptor: SLOT 61 56
      Element 61 descriptor: SLOT 62 57
      Element 62 descriptor: SLOT 63 59
      Element 63 descriptor: SLOT 64 5A
      Element 64 descriptor: SLOT 65 5B
      Element 65 descriptor: SLOT 66 5C
      Element 66 descriptor: SLOT 67 5D
      Element 67 descriptor: SLOT 68 5E
      Element 68 descriptor: SLOT 69 61
      Element 69 descriptor: SLOT 70 62
      Element 70 descriptor: SLOT 71 63
      Element 71 descriptor: SLOT 72 64
      Element 72 descriptor: SLOT 73 65
      Element 73 descriptor: SLOT 74 66
      Element 74 descriptor: SLOT 75 67
      Element 75 descriptor: SLOT 76 68
      Element 76 descriptor: SLOT 77 69
      Element 77 descriptor: SLOT 78 6A
      Element 78 descriptor: SLOT 79 6B
      Element 79 descriptor: SLOT 80 6C
      Element 80 descriptor: SLOT 81 6D
      Element 81 descriptor: SLOT 82 6E
      Element 82 descriptor: SLOT 83 71
      Element 83 descriptor: SLOT 84 72
      Element 84 descriptor: SLOT 85 73
      Element 85 descriptor: SLOT 86 74
      Element 86 descriptor: SLOT 87 75
      Element 87 descriptor: SLOT 88 76
      Element 88 descriptor: SLOT 89 77
      Element 89 descriptor: SLOT 90 78
      Element 90 descriptor: SLOT 91 79
      Element 91 descriptor: SLOT 92 7A
      Element 92 descriptor: SLOT 93 7B
      Element 93 descriptor: SLOT 94 7C
      Element 94 descriptor: SLOT 95 7D
      Element 95 descriptor: SLOT 96 7E
      Element 96 descriptor: FRONT PNL
    Element type: Enclosure, subenclosure id: 0 [ti=1]
      Overall descriptor: 4960 Enclosure
      Element 0 descriptor: Enclosure       PCA-00612-01-A
000800080001
....additional rows deleted



> Andy
>
> --
> Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
> Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
> Registered in England and Wales | Company number 4899123
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180319/00c2f603/attachment-0001.html>

From omnios at citrus-it.net  Mon Mar 19 14:53:40 2018
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Mon, 19 Mar 2018 14:53:40 +0000 (UTC)
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <CALeZrrSXt-TWh=mZAuLT0eqjpJM2eWcoAupskWuvPCvoGxtteQ@mail.gmail.com>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
	<CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
	<C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>
	<CALeZrrQ+3Nj3A2RibyO+HRfNF=oL5es7cU+bCrW+h3QepYr2hQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191417290.22360@erncre.pvgehf-vg.arg>
	<CALeZrrSuqxUWWY6twzEUcDB_8sjSHD1kqiENApzqzznaNjz0fQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191432490.26427@erncre.pvgehf-vg.arg>
	<CALeZrrSXt-TWh=mZAuLT0eqjpJM2eWcoAupskWuvPCvoGxtteQ@mail.gmail.com>
Message-ID: <nycvar.TFB.7.76.1803191450490.23282@erncre.pvgehf-vg.arg>


On Mon, 19 Mar 2018, Schweiss, Chip wrote:

; You might be on to something.  I was suspicious of Element 96 when
; examining via sg_ses.  This JBOD has 96 slots and no display panel.  The
; vendor suspected other issues.

Well, it's this element:

    value='IO Module       PCA-00610-01-A  USE2600052CMK0162B'

which has no PHYs:

ses2_aes_descr_sas1_impl_t {
    uint8_t sadsi_n_phy_descriptors = 0
    unsigned char _reserved1 :6 = 0
    unsigned char sadsi_descriptor_type :2 = 0x1
    uint8_t [2] _reserved2 = [ 0, 0 ]
    ses2_aes_phy1_descr_impl_t [1] sadsi_phys = [
        ses2_aes_phy1_descr_impl_t {
            uint8_t sapdi_phy_identifier = 0x16
            uint8_t _reserved1 = 0x6e
            uint8_t sapdi_connector_element_index = 0
            uint8_t sapdi_other_element_index = 0x74
            uint64_t sapdi_sas_address = 0xd293005000004030
        },
    ]
}

I'm building the hot-fix now - takes about an hour.

Andy

-- 
Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From omnios at citrus-it.net  Mon Mar 19 15:33:26 2018
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Mon, 19 Mar 2018 15:33:26 +0000 (UTC)
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <CALeZrrSXt-TWh=mZAuLT0eqjpJM2eWcoAupskWuvPCvoGxtteQ@mail.gmail.com>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
	<CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
	<C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>
	<CALeZrrQ+3Nj3A2RibyO+HRfNF=oL5es7cU+bCrW+h3QepYr2hQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191417290.22360@erncre.pvgehf-vg.arg>
	<CALeZrrSuqxUWWY6twzEUcDB_8sjSHD1kqiENApzqzznaNjz0fQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191432490.26427@erncre.pvgehf-vg.arg>
	<CALeZrrSXt-TWh=mZAuLT0eqjpJM2eWcoAupskWuvPCvoGxtteQ@mail.gmail.com>
Message-ID: <nycvar.TFB.7.76.1803191530520.11804@erncre.pvgehf-vg.arg>


Chip,

Try this hot-fix:

# pkg apply-hot-fix --be-name=9317 \
    https://downloads.omniosce.org/pkg/r151024/9317-ses2.p5p

If it fixes your problem I'll work on upstreaming this fix to illumos-gate
and it will definitely be in the upcoming OmniOS r151026 as well as
being backported to r151022 & r151024.

Regards,

Andy

-- 
Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From chip at innovates.com  Mon Mar 19 16:41:58 2018
From: chip at innovates.com (Schweiss, Chip)
Date: Mon, 19 Mar 2018 11:41:58 -0500
Subject: [OmniOS-discuss] [zfs] FMD fails to run
In-Reply-To: <nycvar.TFB.7.76.1803191530520.11804@erncre.pvgehf-vg.arg>
References: <CALeZrrSDQpVDqjJy7RV=iUdLXDxszi-Z0iCiqzHM9wpEu2MzqA@mail.gmail.com>
	<9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net>
	<CALeZrrQ+VWwkn-4EPtK-h-LRd6+CX4hZtEExX2Q-+DWn3nmWmw@mail.gmail.com>
	<75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com>
	<CALeZrrSwQn3C8DwaPKaCO330Za5MLGcLn+fKN5R7dzznhgE=Mg@mail.gmail.com>
	<CALeZrrQsFWp4fnk4JszZ+Nd+ZazcEg8JOrBWT9UyKe8wLJ6j+w@mail.gmail.com>
	<CALeZrrSGLytWEWuriCRNAm3+kiAc-9LUBbNGmNOdT_oQBufzKw@mail.gmail.com>
	<C73AE31F-3A6E-4372-929C-7387DE97DE7B@richardelling.com>
	<CALeZrrQ+3Nj3A2RibyO+HRfNF=oL5es7cU+bCrW+h3QepYr2hQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191417290.22360@erncre.pvgehf-vg.arg>
	<CALeZrrSuqxUWWY6twzEUcDB_8sjSHD1kqiENApzqzznaNjz0fQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191432490.26427@erncre.pvgehf-vg.arg>
	<CALeZrrSXt-TWh=mZAuLT0eqjpJM2eWcoAupskWuvPCvoGxtteQ@mail.gmail.com>
	<nycvar.TFB.7.76.1803191530520.11804@erncre.pvgehf-vg.arg>
Message-ID: <CALeZrrT3cEyBLrjVWQD1LuxYTaVP-x4EMqowBOMUtJEEj5ziUA@mail.gmail.com>

The fault manager is starting now.  However, the disks still as show as
UNAVAIL when running zpool import.

# zpool import
   pool: hcp-arc01
     id: 11579406004081253836
  state: UNAVAIL
 status: One or more devices are missing from the system.
 action: The pool cannot be imported. Attach the missing
        devices and try again.
   see: http://illumos.org/msg/ZFS-8000-3C
 config:

        hcp-arc01                                            UNAVAIL
insufficient replicas
          raidz3-0                                           UNAVAIL
insufficient replicas
            c0t5000C50093E3BE87d0p0                          UNAVAIL
cannot open
            c0t5000C50086B52EABd0p0                          UNAVAIL
cannot open
            c0t5000C50093F046A7d0p0                          UNAVAIL
cannot open
            c0t5000C50093E3086Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E85C07d0p0                          UNAVAIL
cannot open
            c0t5000C50093E3BED3d0p0                          UNAVAIL
cannot open
            c0t5000C50093E39267d0p0                          UNAVAIL
cannot open
            c0t5000C50093E309DBd0p0                          UNAVAIL
cannot open
            c0t5000C50093E31407d0p0                          UNAVAIL
cannot open
            c0t5000C50093E3885Bd0p0                          UNAVAIL
cannot open
            c0t5000C50093E344D7d0p0                          UNAVAIL
cannot open
            c0t5000C50093E332AFd0p0                          UNAVAIL
cannot open
            c0t5000C50093F04A2Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093F04763d0p0                          UNAVAIL
cannot open
            c0t5000C50086B5DCE3d0p0                          UNAVAIL
cannot open
            c0t5000C50086B5CD37d0p0                          UNAVAIL
cannot open
            c0t5000C50086B5E263d0p0                          UNAVAIL
cannot open
            c0t5000C50086B5CD07d0p0                          UNAVAIL
cannot open
            c0t5000C50086B5DB3Bd0p0                          UNAVAIL
cannot open
            c0t5000C50086B5D95Fd0p0                          UNAVAIL
cannot open
            c0t5000C50086B566BBd0p0                          UNAVAIL
cannot open
            c0t5000C50086B5F38Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E37C97d0p0                          UNAVAIL
cannot open
            c0t5000C50093E3909Bd0p0                          UNAVAIL
cannot open
          raidz3-1                                           UNAVAIL
insufficient replicas
            c0t5000C50093E85C1Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E3A29Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E342BFd0p0                          UNAVAIL
cannot open
            c0t5000C50093E359DFd0p0                          UNAVAIL
cannot open
            c0t5000C50086B5281Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E331F7d0p0                          UNAVAIL
cannot open
            c0t5000C50093E35A93d0p0                          UNAVAIL
cannot open
            c0t5000C50093E38347d0p0                          UNAVAIL
cannot open
            c0t5000C50093E8532Bd0p0                          UNAVAIL
cannot open
            c0t5000C50093E3422Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093CFA493d0p0                          UNAVAIL
cannot open
            c0t5000C50093E29DB3d0p0                          UNAVAIL
cannot open
            c0t5000C50093E3B70Bd0p0                          UNAVAIL
cannot open
            c0t5000C50093E3946Fd0p0                          UNAVAIL
cannot open
            c0t5000C50086B5319Bd0p0                          UNAVAIL
cannot open
            c0t5000C50086B5608Bd0p0                          UNAVAIL
cannot open
            c0t5000C50086B5D9B7d0p0                          UNAVAIL
cannot open
            c0t5000C50086B5E1ABd0p0                          UNAVAIL
cannot open
            c0t5000C50093E85D93d0p0                          UNAVAIL
cannot open
            c0t5000C50093E85C73d0p0                          UNAVAIL
cannot open
            c0t5000C50086B5D7CBd0p0                          UNAVAIL
cannot open
            c0t5000C50093E33F23d0p0                          UNAVAIL
cannot open
            c0t5000C50093E36A8Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E30193d0p0                          UNAVAIL
cannot open
          raidz3-2                                           UNAVAIL
insufficient replicas
            c0t5000C50093E34E3Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E36DB7d0p0                          UNAVAIL
cannot open
            c0t5000C50093E2C467d0p0                          UNAVAIL
cannot open
            c0t5000C50093E3A213d0p0                          UNAVAIL
cannot open
            c0t5000C50093E387E3d0p0                          UNAVAIL
cannot open
            c0t5000C50093E36DDFd0p0                          UNAVAIL
cannot open
            c0t5000C50093E852BBd0p0                          UNAVAIL
cannot open
            c0t5000C50093E85E5Bd0p0                          UNAVAIL
cannot open
            c0t5000C50093E85CB7d0p0                          UNAVAIL
cannot open
            c0t5000C50093E85CA3d0p0                          UNAVAIL
cannot open
            c0t5000C50093E85B77d0p0                          UNAVAIL
cannot open
            c0t5000C50093E85D6Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E85F83d0p0                          UNAVAIL
cannot open
            c0t5000C50093E85753d0p0                          UNAVAIL
cannot open
            c0t5000C50093E92BBBd0p0                          UNAVAIL
cannot open
            c0t5000C50093F04C73d0p0                          UNAVAIL
cannot open
            c0t5000C50093F04BEFd0p0                          UNAVAIL
cannot open
            c0t5000C50093F04C4Bd0p0                          UNAVAIL
cannot open
            c0t5000C50093F04163d0p0                          UNAVAIL
cannot open
            c0t5000C50093E8581Fd0p0                          UNAVAIL
cannot open
            c0t5000C50086B54183d0p0                          UNAVAIL
cannot open
            c0t5000C50093F04C6Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093F0489Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E312A3d0p0                          UNAVAIL
cannot open
          raidz3-3                                           UNAVAIL
insufficient replicas
            c0t5000C50093E85E43d0p0                          UNAVAIL
cannot open
            c0t5000C50093E310A7d0p0                          UNAVAIL
cannot open
            c0t5000C50086B548DFd0p0                          UNAVAIL
cannot open
            c0t5000C50086B5EBFFd0p0                          UNAVAIL
cannot open
            c0t5000C50086B5B23Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E8579Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093E343DFd0p0                          UNAVAIL
cannot open
            c0t5000C50093E3A103d0p0                          UNAVAIL
cannot open
            c0t5000C50086B528ABd0p0                          UNAVAIL
cannot open
            c0t5000C50093E85727d0p0                          UNAVAIL
cannot open
            c0t5000C50093F2FE4Bd0p0                          UNAVAIL
cannot open
            c0t5000C50093F045E7d0p0                          UNAVAIL
cannot open
            c0t5000C50093D9298Bd0p0                          UNAVAIL
cannot open
            c0t5000C50093F3141Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093F04A53d0p0                          UNAVAIL
cannot open
            /dev/disk/by-id/dm-uuid-mpath-35000c50093f046b3  UNAVAIL
corrupted data
            c0t5000C50093F04853d0p0                          UNAVAIL
cannot open
            c0t5000C50093E85C0Bd0p0                          UNAVAIL
cannot open
            c0t5000C50093E3A9D3d0p0                          UNAVAIL
cannot open
            c0t5000C50093E31DEBd0p0                          UNAVAIL
cannot open
            c0t5000C50093F04A43d0p0                          UNAVAIL
cannot open
            c0t5000C50093F04C53d0p0                          UNAVAIL
cannot open
            c0t5000C50093F3009Fd0p0                          UNAVAIL
cannot open
            c0t5000C50093F04BDBd0p0                          UNAVAIL
cannot open


The "corrupted data" disk was kicked because of a predictive failure being
triggered:

# fmadm faulty
--------------- ------------------------------------  --------------
---------
TIME            EVENT-ID                              MSG-ID
 SEVERITY
--------------- ------------------------------------  --------------
---------
Mar 19 11:17:17 cd4beda0-c3c0-e335-b4a6-89887bc6966a  DISK-8000-0X   Major

Host        : hcp-raw-zfs01
Platform    : SYS-1018R-WC0R    Chassis_id  : S16229126215836
Product_sn  :

Fault class : fault.io.disk.predictive-failure
Affects     : dev:////scsi_vhci/disk at g5000c50093f046b3
                  faulted and taken out of service
FRU         : "SLOT 88 76"
(hc://:product-id=RAIDINC-96BAY:server-id=:chassis-id=500093d230938000:serial=ZA17RWNK0000R740EU4Z:part=SEAGATE-ST8000NM0075:revision=E004/ses-enclosure=0/bay=88/disk=0)
                  faulty

Description : SMART health-monitoring firmware reported that a disk
              failure is imminent.
              Refer to http://illumos.org/msg/DISK-8000-0X for more
              information.

Response    : None.

Impact      : It is likely that the continued operation of
              this disk will result in data loss.

Action      : Schedule a repair procedure to replace the affected disk.
              Use fmdump -v -u <EVENT_ID> to identify the disk.


This pool was created on Linux directly on the disk.   Could it be a
partitioning problem here?   Any suggestions how to fix this?

-Chip

On Mon, Mar 19, 2018 at 10:33 AM, Andy Fiddaman <omnios at citrus-it.net>
wrote:

>
> Chip,
>
> Try this hot-fix:
>
> # pkg apply-hot-fix --be-name=9317 \
>     https://downloads.omniosce.org/pkg/r151024/9317-ses2.p5p
>
> If it fixes your problem I'll work on upstreaming this fix to illumos-gate
> and it will definitely be in the upcoming OmniOS r151026 as well as
> being backported to r151022 & r151024.
>
> Regards,
>
> Andy
>
> --
> Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
> Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
> Registered in England and Wales | Company number 4899123
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180319/69a16a87/attachment-0001.html>

