[Linux-PowerEdge] Latest firmware live DVD posted

Sven Ulland sveniu at opera.com
Thu Mar 27 09:04:51 CDT 2014


On 03/26/2014 06:45 PM, Stephen Dowdy wrote:
> - use of bashisms in every script with magic '#!/bin/sh'.
> - way to update the BIOS on
>   - 12th generation poweredge servers

+1. This, particularly the use of the HAPI and obscure IPMI calls that
goes with many of the updates, has made me give up on doing anything
reasonable with Dell's updates on Debian (or non-RH systems, really).

The choice is then between the lifecycle controller and the firmware
DVD. With some additional features, the firmware DVD could easily be
the better option of the two. Some suggestions at the end of the mail.

> - Dell's inability to offer a SIMPLE programmatic method to:
>   - obtain latest firmware versions for systems
>   - obtain lists of firmware versions along with their release
>     notes/changelogs

I tried parsing ftp://ftp.dell.com/catalog.xml.gz, with some degree of
success. The main issues are:

* Updates that apply to PCI IDs are easy to map to servers. Applying
   the updates is of course tricky, as mentioned.

* Updates that apply to "component IDs" (like iDRAC, disk drives, etc)
   are not: They rely on the undocumented HAPI/IPMI stuff to somehow
   map non-PCI components to unique IDs. I gave up trying to get to the
   bottom of this.

* The various catalog versions are often not synced: catalog.xml vs
   Catalog.cab vs catalog/catalog.xml vs catalog/Catalog.cab. Also,
   these are not up to date compared to the manual web interface
   downloads, so a critical patch would need to be fetched manually
   anyway.

> I see little reason that Dell can't easily support a Linux
> distro-agnostic DUP environment. (or at least one that did not do
> things like check /etc/redhat-release and dump ambigous error
> messages like "Unable to determine System Generation")

The DUPs appear to be overly complex and over-engineered wrappers
around some very poorly implemented binary tools provided by the
hardware vendors, like LSI and Broadcom. The command line interfaces
vary widely, have nearly undocumented command line switches, seem to
be crudely ported from DOS, are sloppy with exit codes, but are
possible -- but painful -- to automate. This applies to only a small
subset of the firmware updates, though. The others need the HAPI/IPMI
integration, so the LC/DVD are needed is my case.


About the firmware DVD, here are some suggestions:

* Make it bootable over NFS. I tried the KIWI instructions for NFS
   mounting [1], but there was no attempt of trying to mount: The boot
   halted with an NFS mount error. tcpdump was used to verify that no
   network packets arrived at the server. Using NFS instead of
   N servers * 4GB downloads would help avoid DoS-ing your own tftp
   server when N > 4.

   [1]: KIWI via NFS:
 
<URL:http://doc.opensuse.org/projects/kiwi/doc/#sec.pxe.root-tree-over-nfs>

* The image is 3.8GB, but the content is 2.6GB. Over a gigabyte can be
   saved, lowering both the download time, at least for the full image-
   in-RAM approach.

* The var/lib/yum/history/ content is ~400MB. Can it be removed?

* The DVD boots into a TWM environment. When testing, via the iDRAC
   Java KVM on Linux (OpenJDK/IcedTea 1.4-3), the mouse pointer acted
   completely aberrantly, making it impossible to click anything; all
   clicks ended up in the top left corner. Some keyboard navigation was
   possible (accept the invalid web cert, click some tabs), but all in
   all the interface was useless. TWM's notorious lack of keyboard
   shortcuts made it worse.

   At this point I gave up. The erratic mouse is probably due to my
   choice of Java. I maintain that this would be a non-issue if there
   was a CLI option.

* Why is a GUI needed at all? What about unattended updates? What
   about unattended updates with custom hooks for each update, so that
   you could for example wrap each update in a script; the script would
   report each update's status (update name, hardware component,
   current version, target version, update success/failure) via syslog
   or something like a webhook (http://.../update?name=x&status=y&..).

   This would give you the benefit of automated updates that would
   scale to any number of nodes (instead of the current scalability
   which is .. a single system), and not leaving you blindsided as to
   whether or not the updates were actually applied.

sven



More information about the Linux-PowerEdge mailing list