[Linux-PowerEdge] Latest firmware live DVD posted

Elias Abacioglu elias.rabi at gmail.com
Fri Mar 28 04:42:25 CDT 2014

I Like Sven's thinking.

I also tried PXE booting the LiveDVD without success.. Like Sven says, it's
not really optimal to download a 4GB image over PXE. It was a while ago I
tried this so I really can't remember what I tried, maybe HTTP or NFS..

His idea about completely unattended updates is the way to go. If you strip
the GUI and a lot of stuff you can easily get the size down. And you gotta
boot the image over NFS or HTTP (via PXE).
Basically you want to setup a PXE boot option for Dell Firmware Upgrades.
Boot into that and have it automatically upgrade firmware and report via
remote syslog. When finished it reboots and goes back to normal operations.
Completely unattended..

And about that what Luca saying about the community and community projects.
I could reverse what he is saying and point out that it's bad that this
kind of support and tools aren't official Dell.
A bit out of topic but as an example a short time ago I was recommended by
Dell ProSupport (escalated third line or something) to try out Red Hat
instead of Ubuntu when having a server with hardware failures that we
haven't been able to pinpoint.
It's a shame that "Offical Dell" puts so little effort in non-Windows (and
non-Red Hat).

2014-03-27 15:04 GMT+01:00 Sven Ulland <sveniu at opera.com>:

> 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
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20140328/b571ead8/attachment-0001.html 

More information about the Linux-PowerEdge mailing list