Rene, for me the updates in question still seem like they need manual intervention , in the same way they have since 2016. I haven't tried Ananya's work around but for the hundred plus machines I had to update I can confirm the --extract, rename the .so, and run works.
Ananya, 68NGY is the exact same issue as V38WK the so file the update wants isn't named in a manner it can be found when running the bin. why the build of the bins can't just get fixed is perplexing - but I can't find anything on dell's site to acknowledge the issue anywhere or provide any official workarounds. so it's all tribal knowledge at this point. thank you for replying. On Mon, Jun 5, 2017 at 6:24 AM, Rene Shuster <[email protected]> wrote: > Are the FW DUPs I listed on April 7th fixed yet? Is there an ETA when the > fixes will implemented? RepoManager is kind of useless if it creates an ISO > with non-working FW updates. > > On Thu, May 25, 2017 at 10:20 AM, Rene Shuster <[email protected]> > wrote: > >> Hi, >> the two solutions do not apply when we use RepoManager to create an FW >> Update ISO. It seems to me that the DUPs need to be fixed. >> >> Quote: "Fix is included in newer DUP framework and newer version of >> firmware update ( DUP) on each impacted Firmware DUP is expected to have >> fix." >> How do we know that the DUPs have been updated or that a newer DUP >> Framework was used? >> >> On Mon, Apr 24, 2017 at 5:59 AM, <[email protected]> wrote: >> >>> Hi Mark/Rene, >>> >>> >>> There is a known issue on linux systems for update packages created with >>> very old framework. >>> >>> All the update packages (except 68NGY) are built with >>> old framework(7.2.0 or 7.3.1), hence they might have the issue. The >>> details of the issue is given below: >>> >>> >>> *Description* >>> Firmware related to PowerEdge Storage may fail to update with error >>> “Collecting inventory. Inventory collection failed “ In following >>> conditions >>> >>> >>> >>> - Device being updated is PERC / Hard Drive Or Backplane. >>> - Operating system is Linux. >>> - Server generation is 11G. >>> - OMSA 8.2 is installed. >>> >>> >>> This article is applicable only when all above conditions are met. Do >>> not replace hardware Engineering is aware of the issue. >>> >>> >>> >>> *Solution* >>> >>> - Uninstall OMSA 8.2 >>> - Run the DUP to update the firmware >>> >>> *Or * >>> >>> >>> - Stop OMSA services >>> - Rename the libstorelibir.so.5 from >>> /opt/dell/srvadmin/lib64 to libstorelibir.so.5.bkp >>> - Run the DUP >>> - Rename libstorelibir.so.5.bkp to libstorelibir.so.5 from >>> /opt/dell/srvadmin/lib64 directory >>> - Start OMSA services >>> >>> >>> Fix is included in newer DUP framework and newer version of firmware >>> update ( DUP) on each impacted Firmware DUP is expected to have fix. >>> >>> >>> Can you please share more details about the failure of the update >>> package 68NGY? >>> >>> Thanks, >>> Ananya >>> >>> >>> >>> >>> ------------------------------ >>> *From:* linux-poweredge-bounces-Lists on behalf of Rene Shuster < >>> [email protected]> >>> *Sent:* Saturday, April 22, 2017 2:26 AM >>> *To:* mark >>> *Cc:* linux-poweredge-Lists >>> *Subject:* Re: [Linux-PowerEdge] SAS Drive Firmware annoyances. >>> >>> Do we know yet if this is us(er error) or DELL causing the issue? Anyone >>> else experiencing this? >>> >>> On Fri, Apr 7, 2017 at 2:31 PM, Rene Shuster <[email protected]> >>> wrote: >>> >>>> I'm building the bootable FW update ISO with Repomanager (in Windows >>>> :( ) and have seen the inventory collection fail for other firmware as >>>> well. Inventory collection worked back in 2016, but at one point they >>>> failed for certain firmware. Here's an overview of what fails: >>>> Backplane 12G SEP (for 8 drives or less) v1.00 681JN 2013-01-02 >>>> PERC 6/i Integrated v6.3.3-0002 F96NR 2012-11-02 >>>> 2.5" 6G/3G SAS HDD (15K) - Seagate (Hornet) >>>> ST973452SS (73 GB) >>>> ST9146852SS (146 GB) HT66 4VM2N 2013-10-10 >>>> 2.5" 6G SAS HDD (10K) - Seagte Savvio 10K.5 >>>> ST9300605SS (300 GB) >>>> ST9600205SS (600 GB) >>>> ST9900805SS (900 GB) CS09 6PM3Y 2013-10-09 >>>> 2.5" SAS HDD (15K) - Toshiba >>>> MK1401GRRB (146 GB) >>>> MK3001GRRB (300 GB) DB08 G9CVG 2013-10-09 >>>> 2.5" 6G/3G SAS HDD (10K) - Seagate (Firefly) >>>> ST9146803SS (146 GB) >>>> ST9300603SS (300 GB) FS66 XJ1HM 2013-10-09 >>>> 3.5" 6G SAS HDD (15k) - Seagate Cheetah (Eagle) >>>> ST3300657SS (300 GB) >>>> ST3450857SS (450 GB) >>>> ST3600057SS (600 GB) ES68 A07 V38WK 2013-10-09 >>>> 3.5" SAS HDD (15k) - Seagate 15k.6 >>>> XX518, FM501, YP778 >>>> ST3300656SS (300 GB) >>>> ST3450856SS (450 GB) >>>> ST3146356SS *(146 GB) HS11 288PJ 2013-10-10 >>>> 3.5" SAS HDD (15k) - Seagate 15k.5 >>>> TN397, HT953, GY581 >>>> ST3300655SS (300 GB) >>>> ST3146855SS (146 GB) >>>> ST373455SS (73 GB) S52C NYHRG 2013-10-09 >>>> 3.5 SAS HDD (15k) - Hitachi >>>> H704F >>>> HUS154530VLS300 (300 GB) B598 R243266/ >>>> H5KGX 2013-10-09 >>>> 3.5 SAS HDD (15k) - Hitachi >>>> XX517 >>>> HUS154545VLS300 (450 GB) D598 7TW7W 2013-10-10 >>>> I'm running the ISO (and see the inventory collection fail) on T630, >>>> R730, R720, T610, R710, T710 and R610 servers. >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Apr 7, 2017 at 1:29 PM, mark <[email protected]> wrote: >>>> >>>>> dsu fails on several SAS drive firmware updates saying it can't >>>>> collect inventory. >>>>> >>>>> the fix, after a little debugging... >>>>> >>>>> download the SAS drive firmware bin manually (one way or another), run >>>>> ./SAS-<whatever> --extract=/tmp/mypath >>>>> >>>>> cd /tmp/mypath >>>>> mv libstorelibir.so libstorelibir.so.5 >>>>> ./spssetup.sh >>>>> done. >>>>> >>>>> >>>>> could anyone comment if they are seeing this and if so what drives ? >>>>> >>>>> so far my list is >>>>> SAS-Drive_Firmware_V38WK_LN_ES68 >>>>> SAS-Drive_Firmware_68NGY_LN_LS0B >>>>> >>>>> there is another segate drive that also fails without some manual work >>>>> on an admin's part , but I can't seem to find it in my notes right now. >>>>> >>>>> anyone else seeing this ? I've seen a few RPM updates to these >>>>> packages but there is no change log on them from the packaging point of >>>>> view and my issue wasn't fixed with it so I have no idea what the change >>>>> in >>>>> the packaging was that bumped the version number of the rpm packaging as >>>>> the firmware rev was the same. >>>>> >>>>> -Mark >>>>> >>>>> _______________________________________________ >>>>> Linux-PowerEdge mailing list >>>>> [email protected] >>>>> https://lists.us.dell.com/mailman/listinfo/linux-poweredge >>>>> >>>>> >>>> >>>> >>>> -- >>>> Tech III * AppControl * Endpoint Protection * Server Maintenance >>>> Buncombe County Schools Technology Department Network Group >>>> ComicSans Awareness Campaign <http://comicsanscriminal.com> >>>> >>> >>> >>> >>> -- >>> Tech III * AppControl * Endpoint Protection * Server Maintenance >>> Buncombe County Schools Technology Department Network Group >>> ComicSans Awareness Campaign <http://comicsanscriminal.com> >>> >> >> >> >> -- >> Tech III * AppControl * Endpoint Protection * Server Maintenance >> Buncombe County Schools Technology Department Network Group >> ComicSans Awareness Campaign <http://comicsanscriminal.com> >> > > > > -- > Tech III * AppControl * Endpoint Protection * Server Maintenance > Buncombe County Schools Technology Department Network Group > ComicSans Awareness Campaign <http://comicsanscriminal.com> >
_______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge
