Friday, March 9, 2012

I seem to be getting old: I find myself reminiscing about all sorts of stuff, and Quake is one of my favorite subjects. In one of these nostalgia attacks I decided to relive the fun and install the games on my Linux laptop. I still have all the relevant CD-ROMs, so all that's needed is a suitable game engine. Quake and Quake3 are packaged in Debian, but Quake2 is not packaged.

Friday, March 2, 2012

There's a hardware compatibility issue between my laptop's on-board nVidia nForce4 antiquated and buggy SATA interface and the modern Western Digital hard disk that I've installed in it.

The hard disk seems to disappear in mid-boot - this can happen anytime it is being re-detected: when BIOS transfers control to the boot loader (either GRUB2 or the Windows Boot Loader), and when the initial kernel image (loaded by the boot loader) re-initializes the SATA controller. If the system comes up, then any power management event may cause the disk to disappear. Sometimes, the disk just disappears for no obvious reason. The kernel's libata error handling routines may manage to reestablish connection to the disk, but sometimes it does not come up and I have to power cycle the laptop.

None of the solutions/workarounds I tried did the trick: apart for the stuff I already mentioned, I added rootdelay=10 to the kernel command line, hoping that the extra delay would give libata a better chance of re-detecting the disk; I even installed the watchdog daemon, to get my laptop to reboot when it freezes, but either it doesn't really work, or (most likely) I don't understand how to configure it.

The last ditch workaround I came up with, was to boot the laptop into GRUB2 from a USB disk-on-key, thus avoiding the internal hard disk altogether, and have GRUB2 perform the following steps:

check if boot related files on the internal hard disk are accessible

if any file is not accessible then reboot

if all files are accessible, then if this is the first success then reboot

if this is the second success then boot GRUB2 on the internal hard disk

This procedure captures the sequence of steps that seems to get my box to boot - it's Voodoo, I know, but it does work (most of the time).

The script (boot/grub/grub.cfg) below implements this procedure. It uses get_env and save_env to keep a persistent state (the variable need_reboot) between reboots. The first few lines make sure that the state is properly initialized, even if the environment variables were not saved yet (i.e. if this is the first ever boot from this device).

The fact that one can control the boot process this way is pretty neat, in my opinion. The only trouble is that even with this, my system still fails to boot - albeit less frequently than before.

I must admit defeat. The laptop is usable now, but, in my eyes, just barely. The whole experience made me itch for a new PC, but with my luck being what it is, I fear that it won't be a much easier ride. So, for now, I've resigned myself to my fate, until I gather up the courage (and cash) to tackle a new box.