RAID management from hell

This, ladies and gentlemen, is the state of the art when it comes to RAID management in 2013. It’s the monumentally awful LSI MegaRAID BIOS configuration interface on a fairly recent Dell C8000 series system:

My First RAIDâ„¢ by Hasbro

My First RAIDâ„¢ by Hasbro

I’m seriously offended. Who the hell lets this sort of garbage through QA for a high end product? It features such brilliant highlights as:

  • A faux windowing UI, with a god damn mouse cursor as primary input.
  • Yes, your eyes do not deceive you: A fucking WordArt logo.
  • A beautiful color scheme inspired by Windows 3.1.
  • A mouse cursor with Parkinson’s, simply useless over remote KVM.
  • Rage-inducing tab-tab-tab-enter keyboard navigation.
  • Highlighted shortcut keys with no obvious way of activating them (no Alt+key).
  • “WebBIOS is an HTML-based utility that is embedded in the firmware”. So they’ve implemented a browser in the BIOS firmware. Top job, I say, and an exquisite choice of technology. If only the Internet was more like LSI’s vision of the web.
  • A bad idea in 2003; a terrible idea in 2013; a horrible idea since always.

Luckily there’s an alternative to this madness in the slightly less dreadful MegaCLI command line tool. It’s a proprietary binary that at least doesn’t limit your options, but it is clearly not a work of art.

LSI: Get your shit together. Release full specs and source for MegaCLI and its character device interface under a permissive license to let distros include it or better yet, write a better one. You obviously do hardware better than software.

Dell: Demand better from LSI and raise the bar for software quality, both for third parties and yourself.

Advertisements

Fuckin’ UUIDs, how do they work?

Pretty much any computer these days has an smbios full of lovely data. The system UUID is particularly useful for identifying and keeping track of your servers. You happily assume it’s set in stone from now until the end of time, but then someone comes along and fucks up the byte order.

Here are some brilliant wtfs from a HP server:

# dmidecode -s system-uuid
43315434-3341-3255-5832-333731303946

$ curl -ks "https://ilo4/xmldata?item=All"
34543143-4133-5532-5832-333731303946

So the first three fields are in reverse byte order. Which one is the right one? Neither. Or both? Hngh!

HP’s UUID is a simple ascii encoding of the six-digit product number plus the ten-digit serial number:

$ python -c "import binascii as b
print b.hexlify('C1T43A2UX237109F');"
43315434334132555832333731303946

So dmidecode gets it right? Yeeaano. Not according to section 7.2.1 in version 2.6 of the smbios spec. In short, assumptions and poor specs have resulted in yet another mess. Dmidecode 2.10 adds the little endian parsing for smbios versions >= 2.6.

Here’s Dell doing the same thing:

# dmidecode -s system-uuid
44454c4c-4d00-105a-8058-cac04ca8474a

Note the broken UUID format in the second field in the iDRAC’s SMASH CLP:

-> show admin1/system1
OtherIdentifyingInfo={
  4c4c4544-04d-5a10-8058-cac04ca8474a,

..and enumerating the WSMan CIM_ComputerSystem class gives the same result:

<wsinst:OtherIdentifyingInfo>
  4c4c4544-04d-5a10-8058-cac04ca8474a
</wsinst:OtherIdentifyingInfo>

Dell have later added the WSMan DCIM_SystemView:smbiosGUID value that presents the uuid in network byte order (same as dmidecode <= 2.9).

Oh, and Dell’s C6100 servers come with the same UUID and serial numbers for all nodes in the enclosure. Thanks a lot, Dell.

More details on this UUID wtfery here.