[Linux-PowerEdge] Latest firmware live DVD posted

Jonathan jonathan at schwarzelan.de
Fri Mar 28 06:52:23 CDT 2014


Seconded!
or +1 as it is used now...

On 03/28/2014 10:42 AM, Elias Abacioglu wrote:
> 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
> <mailto: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 <mailto:Linux-PowerEdge at dell.com>
>     https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
>
>
>
> _______________________________________________
> 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/3861cb1f/attachment.html 


More information about the Linux-PowerEdge mailing list