Cool Ubuntu Themes with Bisigi

I’ve always found gnome desktops to be something of a hassle to find good themes for. Usually it takes a solid amount of time rooting around in one of the repositories, checking compatibility, etc. etc.

One of the places I’ve found that has a reliable theme pack that’ll install and give you a clean looking desktop to work with is the Bisigi Project. Just pop their repositories in your system, install, and go.

Gnome 3 support is coming with the release of Ubuntu 12.04. For now you can hack it in for previous versions of gnome or get it working with LXDE.

Using PPA Repositories with Debian add-apt-repository Script

Looking for a way to replicate PPA repositories into your Debian squeeze or wheezy install? Anantshri has you covered with a quick shell script. Note that it may break your installation horribly and kill puppies wantonly.

For installing Bisigi Themes for the gnome desktop? Worked for me.

OBD-II Support on Linux

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 (0x00007f99dea9a000)
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.

RAID-5 Array Not Responding Due to One Dropped Drive

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.