Over the weekend I have managed to have about three separate problems with my computer.

In particular, I've been having trouble with bits of it having unexpected persistent state.

On Thursday, I decided that if I was going to be at home going uuurgh for two days, a good way to spend that time would be to finally get round to MP3ing my CD collection; so instead of sitting in the lounge with a book, I sat in the study with a book and changed CDs every twenty minutes. Simple, undemanding, but useful; just what I needed. Unfortunately I then ran out of disk space, but that was OK because I'd anticipated it and had a 250Gb disk on order. (It only cost 200 quid, so I thought I might as well! And 250Gb allows me to store my whole CD collection losslessly compressed, which means if I decide I want to re-encode the MP3s at a different bit rate I can do so without running the physical CDs through the machine a second time.)

So. Take side off computer; connect up 250Gb disk as slave to existing 30Gb one; machine no longer boots. (LILO tells me ‘L 01 01 01 01 01 01’ to an accompaniment of worrying grinding noises from the old 30Gb disk.) Since the last time I tried to install two IDE disks on the same controller, they had a fight and blew up part of the motherboard (but this was in 1995ish and IDE wasn't so stable then), my instinctive reaction was to panic wildly and remove the new disk to make sure the damage wasn't permanent. But even with the new disk removed and the machine in precisely its original configuration, ‘L 01 01 01 01 01’ grind grind grind. YIKES.

After some headless-chicken impressions and a badly timed phone call from Mum (she was really worried at how ill I sounded, but in fact most of that was blind panic :-), I eventually found someone on IRC who guessed what had happened: the addition of the 250Gb disk had caused the BIOS to completely rethink the basis on which it invented CHS geometries for disks. And this rethink was (a) irreversible; (b) undetectable in the BIOS config; and (c) applied to all disks and not just the one that was over its limit. Hence, all the CHS values in my LILO config were obsolete. So booting off a Debian rescue floppy and reinstalling LILO with LBA32 enabled sorted it out. Phew. But also *GRRR*, to whoever thought it would be funny to have a piece of persistent state in the BIOS which you couldn't configure how you wanted and also couldn't even detect by looking through the config screens! That's just stupid.

So. That lot sorted, I continued to rip CDs over the rest of the weekend; and on Sunday morning I found one I couldn't rip. It didn't look to have been deliberately copy-protected; the first nine tracks ripped fine but the last one ran into read errors part-way through. (Though it still plays fine in an ordinary CD player, so *shrug*.) What was odd about this was that the CD-ROM drive's efforts to read this CD caused something somewhere to get very confused, and thereafter whenever my computer instructed the drive to eject, it started playing instead. Consistently. How can that happen? Again, something has some persistent state which I'm sure it simply ought not to have. (Though fortunately this one was corrected by a power cycle.)

Finally, I upgraded my kernel from 2.4.20 to 2.4.22 because someone told me there were lots of IDE fixes in 2.4.21 and I thought it couldn't hurt; and this caused my encrypted swap device (OK, so I'm paranoid) to stop functioning. It transpired, eventually, that the ad-hoc patch I applied to 2.4.22 to enable the encrypted loop device actually functions in exactly the same way as the one I had in 2.4.20, so that wasn't the problem; but the standard losetup program first validates your choice of cipher by looking in /proc/crypto, and that had changed format between 2.4.20 and 2.4.22! And worse still, I couldn't find a version of losetup which knew how to talk to the new format at all. I eventually had to hack one up myself. That's just ridiculous.