Smokes your problems, coughs fresh air.

The road through Ubuntu

My mom bought a new laptop because of a broken screen on the old Linux machine that she had inherited from me (which wasn’t wasn’t a laptop, so I’m sure that the Golden Arrow of Consumption can explain why she didn’t just replace the screen, although the new boyfriend who is kind of Windows-but-not-Linux-literate qualifies as a more probable reason for getting a laptop that is needlessly dragged down by Vista).

I was a little surprised by her move. The first computer my mother learned turning on was this computer back when I was still using it. Of course it was running Linux at the time. Before I gave it to her, I replaced Gentoo Linux with Ubuntu Linux, and, honestly, she never had any problems with it that were not hardware-related. (Ok, there was that one time when there was some junk stuck in the print spool without a user-friendly path to getting rid of it, but you could argue that this was really due to a junk printer. (On the subject of print spools: my friend Wiebe complained to me a while ago that when the queue in their WorkCentre Pro 232 gets stuck, Xerox engineers have to come in to replace the whole damn control board; apparently, just plugging in a terminal with shell access isn’t possible.)) She was comfortable with and used to Linux. But, alas, she’s in love with someone who is less than comfortable with Linux and there’s always that male ego thing.

But, then, who cares? It was good news for my sister. With her having gone through a rally of shitty old machines in just a couple years and this still being an ok-enough machine, I asked her if she’d like a “new” machine running Linux when she called me about one of those typical Windows problems that had just taken out her previous wreck of a machine. Yeah, sure, she’s was more than willing to finally get rid of Windows.

I was glad that my sister didn’t feel the need to inflict the pain of Windows on this poor old machine. This meant I only had to upgrade and reconfigure i a bit. Upgrading Ubuntu to version 8.04 went pretty seamless, because it was a relatively fresh installation where all dependencies where actually marked as “auto”. After moving away some old – uhm – aesthetic imagery, ill-suited for big-sister-eyes, I brought the machine to her place, plugged in her peripherals, connected it to her screen, and tried to boot.

It booted, but GDM wouldn’t start. I had just swapped a Matrox G400 with a noisy GeForce 4 which I had previously assumed to be broken. This assumption actually goes all the way back to before I realized that the screen was broken. When the screen started complaining of “Not Recommended Mode”, one of my first diagnosis was that the GeForce card was borked. This diagnosis was arrived to after first blaming the screen, plugging it in elsewhere, seeing that working, plugging it back in, seeing that working too, then seeing that stop working again, resetting the screen in increasingly complex sequences, seeing it work again, seeing it stop working again, swapping the DVI connection with a VGA connection, and then, finally, swapping the GeForce racehorse with the old Matrox workhorse. Of course the problems returned, but not before another fun round of swapping parts and peripherals because the machine had started crashing. The crashing led me to replacing the power supply, only to find out later that the CPU’s cooling block had someone loosened dangerously. So, with all that in mind, I had now put back to GeForce plaything before I took the whole concoction to my sister. Now, GDM wouldn’t start. (The GeForce graphics worked fine before I moved the machine to her.)

Admittedly, I hadn’t exactly tried booting with the GeForce. (I’m not the rebooting type.) After swapping the card, not being able to use the binary nvidia and an hour or so of messing around, I found that the nvidia kernel module was actually missing. (I hadn’t noticed this because a “find /lib/modules|grep -i nvidia” did show an nvidia entry; had I looked better, I would’ve seen that it was a directory and not a .ko file.) So I performed a reinstall of the appropriate linux-restricted-modules package and—voila!—the files where there (in /lib/modules/2.6.24-21-generic/volatile/).

So I’m at my sister’s and I’m surprised that X won’t start. I try to find the module in /lib/modules/; it’s gone. Then, after reinstalling the package and an extraneous reboot to see it gone again, it dawns on me: what did volatile mean again? (I should really not be telling you this, because it’s fucking embarrassing. 😉 ) Yes, the volatile directory is a tmpfs mount point. When I realized that this was probably due to initramfs, I realized that I know jack about initramfs, except that it makes Grub’s configuration incomprehensible to me.

I tried updating the initrd.img by issuing update-initramfs -u. When this didn’t work, I added the module name explicitly to /etc/initramfs-tools/modules. When that didn’t work, I changed the MODULES option in /etc/initramfs-tools/initramfs.conf to MODULES=dep and pulled update-initramfs through grep to find out if the module was added appropriately: update-initramfs -u -v|grep nvidia. It was outputted and it was the right initrd.img too but still, after booting, the module was missing from the volatile directory.

So, fuck this! I was getting inpatient: cd /lib/modules/2.6.24-21-generic/volatile; mv nvidia.ko ../kernel/drivers/video; depmod -a; reboot and GDM started nicely.

Now I just have to find out why the bloody eth0 interface isn’t ifup’ed at boot. The configuration seems fine to me (although I’m confused by all this new-fangled GUI stuff and by where everything is stored. :-?) For now, I just dropped a script on her desktop called Darn, the network doesn’t work:

#!/bin/bash
gksu ifup eth0

Pure sophistication, isn’t it? I’ve yet to encounter an operating system where solving such problems has any resemblance to anything I’d call user-friendly… For all the polish they add these days, if you can’t go below the hood and bang away at the shell, you’re basically screwed. That’s why I hate Windows so much, because I know nobody who can get under its hood.

1 Comment

  1. halfgaar

    Actually, Xerox solved the problem by reformatting and reinstalling the Linux operating system that these things use. I’d call that going after a fly with a bazooka, because all that would have been necessary is just removing the queue files and possibly restarting the print spooler.

    And, about the print jobs that get stuck in Linux, that’s not due to a shitty printer, but due to shitty printer driver/architecture. For some printers, CUPS uses foomatic perl scripts to handle the jobs. This is what causes those problems. When the job has been passed to the script, there is no way of stopping it, except killing it; as root, because the script runs as root.

© 2024 BigSmoke

Theme by Anders NorenUp ↑