Checking servers for firmware/driver updates etc

Stephen Dowdy sdowdy at
Fri Feb 26 13:00:57 CST 2010

Patrick_Fischer at wrote, On 02/26/2010 03:28 AM:
> We provide 2 Tools.
> Old: IT Assistant (requires a Windows 32 Bit OS)
> New: DMC (requires a w23 Host or VM)
> Both tools are able to compare server revisions with the actual Updates.
> So you can run the comparison report to see which machines need to be
> updated. A snmp configuration on each machine is a must have.
> Maybe some of the Linux guys are able to run such reports with Nagios or
> anything else, maybe with reading out the FW and driver strings
> (omreport) and compare it with the latest versions from the Update DVD
> dell provide ca. 1 time per quarter.

I manage 100s of Debian, RHEL, and SLES boxes here.

I enclose a script that's hit/miss to do *some* inventory.
Here's sample output:

[root at server1 MegaRAID]# /opt/sbin/ral-superinv
Hostname:        [server1]
Manufacturer:    [Dell Inc.]
Model:           [PowerEdge 2950]
Serial Number:   [XXXXXXX]
BIOS Version:    [2.4.3] *(!=2.6.1)
BMC Version:     [2.28] *(!=2.37)
PERC5i Version:  [1.03, 1.03]
PERC5E Version:  [1.03, 1.03, 1.03, 1.03, 1.03, 1.03, 1.03]
SASBP Version:   [1.05]
MD1000 Version:  [A.04, A.04, A.04, A.04, A.04]

It's seriously flawed, predominantly because it requires constant
manual updating to report out-of-rev BIOS, etc.  Why do i do this
and not run OMSA?

Because OMSA doesn't run on Debian, grrr.
It might provide you with some strategies to do inventory gathering
on your own.

Now, please note at the bottom of the script, there's a URL at Dell
that's titled "Enterprise BIOS and Firmware Matrix".  Wow, that's
awesome, something that would really help endusers, EXCEPT, it hasn't
been updated in years!! (more grrr).

So, it would be super-mega-awesome if Dell provided said Matrix
in a queryable format.  I.e. i'd like to be able to probe, say:

to get a history listing of all pe2950 BIOS updates including their
criticality status.  yeah, i'll keep dreaming...
But even a static (but maintained) table like the one proposed
at the "Enterprise BIOS and Firmware Matrix" page would be really
awesome (if i could easily programmatically parse it and rely
on its data being accurate and timely)

So, it looks like DMC might do this, but again, it locks me into
a *Windows* solution.  sigh.  SUU uses Java to do the Catalog
processing/inventory, why can't we have a platform-agnostic
tool that'll manage this (at least the inventory part).

Now, as far as updates go...

I've had limited success on Debian doing updates with various
DUP components.

BIOS: I've posted a thread in the past here on using libsmbios
on payloads extracted from DUP kits, and the '-writehdrfile'
option for Windows-only BIOS payloads (mostly for laptops, and
desktops not supported via DUP updates) with the dell_rbu
(Remote BIOS Update) kernel module & libsmbios.  That's all
pretty solid.

BMC: can't do that in Debian.  there's a "bmcflash" kit on
the site, but it doesn't seem to work, and is
unmaintained.  Also the old list threads seem to discuss a
history of "bricking" servers and i think the connection with
that project getting scrapped.

SASDUPIE:  This kit can update SAS disks on Debian, but it
has a bug.  I wanted to dump all the payload images into the
payload directory, and running it in DEBUG mode shows it doing
"addfile" on each payload image, but when it comes to flashing
the disks, it ONLY attempts the first payload image in the
list.  So, with this version of 'sadupie', i'd have to modify
the caller script to scan "N" payload subdirectories, or build
my own catalog and specify the payload directory for the disk image
after doing all my own up-front processing.
(note that LD_LIBRARY_PATH has to be setup to point to all the
required "Lib" bits that are provided with the DUP kits)

The SUU doesn't even always work right.  And the diagnostics are
very poor.  Yes, i've learned:

iconv -f utf16 -t ascii /var/log/dell/suu/invcolError.log
less /var/log/dell/suu/{update,support}.log*

and having to 'FOO.BIN --extract' to find the PIEConfig
inventory execution bits and run them with '-debug' to
hopefully figure out what's going wrong.

AND having to always do:

rpm -e $(rpm -qa | egrep '(srvadmin|instsvc)') || rpm -e --noscripts $(rpm -qa | egrep '(srvadmin|instsvc)')

because leaving old instsvc or srvadmin kits on the system often
silently breaks suu.  Even to the point of it saying "Update Successful"
anyway, and me scratching my head why the BIOS is still out of date
on a server when i thought i'd updated it.  (this is on RHEL, since
SUU doesn't support Debian)

So, my first desire is to get a SIMPLE maintained, supported interface that
is platform agnostic for VALIDATING my server's status.  That one seems
like it should be pretty simple.  (the current SUU is not that answer.  It is
monolithic (huge) and not incrementally-updatable

My second is for an maintenance update system that is platform agnostic.

Perhaps these things exist, but it's also difficult trying to figure
out which system is the one to use (note the ITA vs DMC, SBUU vs SUU vs ..)
Even things like the Dell Capacity Planner/Calculator hav gone from
a Windows only executable to a Java app to a flash app to ???  and often
the new servers aren't included.   And, STILL: points to "ESSA" for the Blades, and you click that
link and get "can't find the server at"  (it's been
that way for MONTHS)

--stephen "Cranky Old Man Ramblin'" dowdy
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ral-superinv

More information about the Linux-PowerEdge mailing list