Computer stuck at “Verifying DMI Pool Data”

I built my desktop back in 2009 and it has served me well. However, I decided that a dual-core machine with 4 GB of RAM just really wasn’t cutting it in 2015. Flush with Christmas cash, I upgraded to an eight-core CPU and 16 GB of RAM. This also meant bringing a new motherboard along for a ride. Like my old motherboard, this new one was a Gigabyte product (GA-78LMT-S2P, specifically), so I figured life would be pretty simple.

After work, I yanked the old parts out and inserted the new. I booted the new machine and made sure the BIOS settings were just how I wanted them. I let it boot and…

Crap. It got stuck at “Verifying DMI Pool Data”. For a long time. I did some searching and most of the answers I found suggested that the answer was one of a bad SATA cable, a bad SATA port, or a bad disk. None of these seemed to be the case, as the RAID utility found all four drives. But wait, I have five. Two smaller drives in a RAID 1 for my OS and local files, and a 3×1 TB (software) RAID 5 for data.

Therein lies the solution: by setting SATA ports 4/5 to RAID instead of IDE mode, the computer booted right up. I leave this here as a marker for anyone else who happens to come across this problem (or myself if I repeat it in another six years). As an aside, this is the first time I’ve played with hardware in a few years. I kind of missed it a little, tiny bit.

Sometimes, Windows wins

It should be clear by now that I am an advocate of free software.  I’m not reflexively against closed software though, sometimes it’s the right tool for the job.  Use of Windows is not a reason for mockery.  In fact, I’ve found one situation where I like the way Windows works better.

As part of our efforts to use Condor for power saving, I thought it would be a great idea if we could calculate the power savings based on the actual power usage of the machines.  The plan was to have Cycle Server aggregate the time in hibernate state for each model and then multiply that by the power draw for the model.  Since Condor doesn’t note the hardware model, I needed to write a STARTD_CRON module to determine this.  The only limitations I had were that I couldn’t depend on root/administrator privileges or on particular software packages being installed. (The execute nodes are in departments across campus and mostly not under my control.)

Despite the lack of useful tools like grep, sed, and awk (there are equivalents for some of the taken-for-granted GNU tools, but they frankly aren’t very good), the plugin for Windows was very easy.  The systeminfo command gives all kinds of useful, parseable information about the system’s hardware and OS.  The only difficult part was chopping the blank spaces off the end of the output. I wanted to do this in Perl, but that’s not guaranteed to be installed on Windows machines, and I had some difficulty getting a standalone-compiled version working consistently.

On Linux, parsing the output is easy.  The hard part was getting the information at all.  dmidecode seems to be ubiquitous, but it requires root privileges to get any information.  I tried lshw, lshal, and the entire /proc tree.  /proc didn’t have the information I need, and the two commands were not necessarily a part of the “base” install.  The solution seemed to be to require the addition of a package (or bundling a binary for lshw in our Condor distribution).

Eventually, we decided that it was more effort than it was worth to come up with a reliable module.  While both platforms had problems, Linux was definitely the more difficult.  It’s a somewhat rare condition, but there are times when Windows wins.