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: 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: 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 Reply-To: illumos-developer 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: References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org> <8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com> 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> <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> <68d28785-c73e-c10e-cc40-7cc0d839360d@gmail.com> <2f8801d3b727$1e858230$5b908690$@acm.org> Message-ID: 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: <7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi> <9012C25D-BD6D-4619-9748-C0C66753EC86@omniti.com> Message-ID: 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 wrote: > > > On Jan 16, 2017, at 5:01 PM, Mini Trader > 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: 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: References: <7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi> <9012C25D-BD6D-4619-9748-C0C66753EC86@omniti.com> Message-ID: 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 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 wrote: > >> >> > On Jan 16, 2017, at 5:01 PM, Mini Trader >> 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: 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: 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: References: <7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi> <9012C25D-BD6D-4619-9748-C0C66753EC86@omniti.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 Date: Thu Jun 8 21:57:45 2017 +0000 8376 cached v_path should be kept fresh Reviewed by: Jerry Jelinek Reviewed by: Robert Mustacchi Approved by: Gordon Ross hadfl at bloody-build:/build/illumos-omnios$ git log master --grep "cached v_path" commit e2fc3408efa6cdfc5e33c73c3567efc8c7592707 Author: Patrick Mooney Date: Thu Jun 8 21:57:45 2017 +0000 8376 cached v_path should be kept fresh Reviewed by: Jerry Jelinek Reviewed by: Robert Mustacchi Approved by: Gordon Ross 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 > 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 > wrote: > > > > On Jan 16, 2017, at 5:01 PM, Mini Trader > 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 > > > > > > _______________________________________________ > 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: References: Message-ID: 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 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: 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: 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: 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: References: Message-ID: 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: References: Message-ID: 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: References: Message-ID: On Tue, Mar 13, 2018 at 5:50 PM, Andy Fiddaman 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: 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: 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 wrote: > On Fri, Feb 16, 2018 at 10:47 AM, Robert Mustacchi 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: 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: 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 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 > wrote: > >> On Fri, Feb 16, 2018 at 10:47 AM, Robert Mustacchi 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: 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: fmadm allows you to load/unload modules. -- richard > On Mar 16, 2018, at 8:24 AM, Schweiss, Chip 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 > 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 > wrote: > On Fri, Feb 16, 2018 at 10:47 AM, Robert Mustacchi > 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 > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From an3s.annema at gmail.com 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: References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org> <8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com> <68d28785-c73e-c10e-cc40-7cc0d839360d@gmail.com> <2f8801d3b727$1e858230$5b908690$@acm.org> 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 type -f -exec /usr/bin/chmod && find type -d -exec /usr/bin/chmod && chmod " 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: 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> <68d28785-c73e-c10e-cc40-7cc0d839360d@gmail.com> <2f8801d3b727$1e858230$5b908690$@acm.org> <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 type -f -exec /usr/bin/chmod && find > type -d -exec /usr/bin/chmod && chmod > " > > 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: 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 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 > 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 >> wrote: >> >>> On Fri, Feb 16, 2018 at 10:47 AM, Robert Mustacchi >>> 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: 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: On Mon, Mar 19, 2018 at 9:19 AM, Andy Fiddaman 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: 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: On Mon, 19 Mar 2018, Schweiss, Chip wrote: ; On Mon, Mar 19, 2018 at 9:19 AM, Andy Fiddaman 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: On Mon, Mar 19, 2018 at 9:33 AM, Andy Fiddaman wrote: > > On Mon, 19 Mar 2018, Schweiss, Chip wrote: > > ; On Mon, Mar 19, 2018 at 9:19 AM, Andy Fiddaman > 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: 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: 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: References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: 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 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 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: