DoomBook

Having just purchased a OBDPro USB scantool I’ve been getting it kicking to start troubleshooting the new-old Saab that I’m working on. The two programs that come up on Freshmeat are obdgpslogger and obdgui as a single project and FreeDiag.

Freediag wouldn’t compile out of the box on my 64 bit Debian machine, so I moved on to the first package obdgpslogger/obdgui.

OBDgpslogger compiled up in a snap and appears to work well. It’s got a nice GUI component that’s about the equal of the quickie software that came with the device. For reference, here’s the list of libraries the two programs use.

OBDGui:
linux-vdso.so.1
libfltk_images.so.1.1
libfltk.so.1.1
libfltk_gl.so.1.1
libfltk_forms.so.1.1
libSM.so.6
libICE.so.6
libX11.so.6
libXext.so.6
libpthread.so.0
libdl.so.2
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
libpng12.so.0
libjpeg.so.62
libXft.so.2
libfontconfig.so.1
libXinerama.so.1
libGL.so.1
libxcb-xlib.so.0
libxcb.so.1
libXau.so.6
/lib64/ld-linux-x86-64.so.2 (0×00007f99dea9a000)
libz.so.1
libfreetype.so.6
libXrender.so.1
libexpat.so.1
libGLcore.so.1
libnvidia-tls.so.1
libXdmcp.so.6

OBDGPSLogger:
linux-vdso.so.1
libpthread.so.0
libdl.so.2
libgps.so.18
libc.so.6
/lib64/ld-linux-x86-64.so.2
libnsl.so.1
libstdc++.so.6
libm.so.6
libgcc_s.so.1

Oddball stuff I didn’t have installed already included gpsd devel packages, FLTK devel (for the gui), and “fluid” (fltk add-on?) (also for the gui).

It seems like it’s going to work well. The sensor hooks up fine on the included software package (through WINE) so long as I symlink /dev/ttyUSB0 to /dev/com1, set it to 9600bps, and make sure /dev/ttyUSB0 is permmisioned so that my user has access to it.

obdgdmlogger hooked in just fine short the GPS sensor (not installed yet) and gui output (just compiled).

So in short it all “just worked” for me. Which is nice. Occasionally the 64 bit nature of this machine makes installing things a pain.

An interesting thing happened on the way to backing up the VM server this weekend. And by interesting I mean mindbendingly horrible.

So I’m pulling down the array for a backup. Not that odd in and of itself. And then I start getting spurious IRQ requests (it’s spamming the crap out of the line) that crash out one of the HDDs on the array and render the machine frozen.

OKAY. That’s why we have a RAID-5 array in the first place.

When I bring the machine back up it chokes with some errors on the RAID initiation. Apparently it doesn’t think there are enough drives in the array anymore to bring up the primary /dev/md1 array that holds all our precious data. Excellent, I love spending a weekend de-mucking dead servers :/.

Naturally I don’t want to compound issues, so I pull a backup of each of the bloody 300+ GB drives to a recently verified good (off it’s third RMA.. hardware incompatibility rather than mechanical flaws) 640GB backup drive. This takes roughly a day.. but it’s worth it if the drives die in the middle of a recovery effort.

I’ve got everything pretty straight data-wise, no real fear of doing worse damage at this point. Cracking open mdadm to do a examine on the arrays reveals something a bit weird though. The drives, two of them anyway, show that they’re still okay…

Turns out that the system hit the third drive in the array first, saw that it reported a failure of the entire array, and went no further. The other two drives in the array report as working fine.. and do. I did a –assemble sans funky drive and the array came right up for me to pull a quick backup.

Now I’ll just re-add the “dead” drive to the array and have it re-build once the backup is finished.

So, if you’re staring at an array that won’t come up take a closer look at the mdadm output to make sure it isn’t just hanging on a single debilitated drive. Although I’ve never seen this happen before, restoring a single drive sure beats restoring off backup medium.