A little less than a year ago, I wrote a script for my SigO (as a Christmas gift) that loads a random background image when she starts X with IceWM. In the process of migrating to a new laptop, though, she found that vanilla Debian wasn’t working as well as she would like. The specific problem was that wireless wouldn’t work unless she used a newer kernel and the ATI driver wouldn’t work unless she used an older kernel — which meant she would have to choose between wireless networking and playing World of Warcraft. Neither option was appealing. There were some other problems, too — involving Wine not working under certain circumstances — but I don’t recall the specifics. Maybe I’m misremembering the situation, but it was all something like that.
As a result, the new laptop ended up with Ubuntu running on it. Of course, being the discerning person with excellent taste that she is, she finds GNOME highly annoying. As such, she futzed around until she got IceWM working and decided she would just live with a crapload of unnecessary and undesirable GNOME garbage living on the hard drive since uninstalling any of it would result in a bunch of other stuff she actually wants and isn’t necessarily GNOME-specific being hosed up (aren’t Ubuntu dependencies grand?). Unfortunately, because the random background script I wrote was called from .xinitrc, and neither of us knew off the tops of our heads how to do something similar with gdm, we either needed to learn how (if possible) to get gdm to do what .xinitrc used to do when using
startx to start X, or we had to get gdm to stop working.
I haven’t dealt with this kind of thing on any Linux systems in a while, so it took me a few minutes of farting around to remember about the rcN.d directories in
/etc. Once I got to that point, though, I entered
runlevel at the shell to find out that her laptop automatically boots to runlevel 2. Armed with this information, I checked out the contents of
/etc/rc2.d and found
S30gdm (S for “start”). Great! I just renamed that to
K30gdm (K for “kill”), and figured that should solve the problem. Now she could boot to a text console instead of straight into a display manager, and use startx with .xinitrc to get her random backgrounds. She, like me, seems to like having the option of just running the system at the console when no GUI is needed, anyway.
While I was at this, she asked me to turn off the splash screen, and looked up the
/boot/grub/menu.lst syntax to disable the splash screen and get console output during bootup so I wouldn’t have to strain my brain trying to remember that sort of thing about how the bootloader works.
Everything was great after that point, except one thing: now, the system would hang on reboot. Shutdown would work fine when going to runlevel 0, but reboot when going to runlevel 6 would cause it to hang at the point where it tells the user that it’s going to restart the system.
We both did some hunting through Google’s archive of the Internet, but we didn’t find anything worthwhile. She did more of that than me, because I was spending the time searching through the
/etc/init.d scripts and so on. Eventually, I recalling enough about how Debian-based Linux systems work to crawl through the filesystem looking for problems that led to a solution. It turns out that the
/etc/init.d/reboot script restarted the system by executing
reboot -d -f -i. This is where it gets really interesting.
It turns out that
reboot -d -f -i would work fine on FreeBSD, with the
-d option (according to the manpage) doing the following:
The system is requested to create a crash dump. This option is supported only when rebooting, and it has no effect unless a dump device has previously been specified with dumpon(8).
. . . but the version of the halt script that Ubuntu’s
/etc/init.d/reboot uses doesn’t have a
-d option listed in its manpage at all. I decided to try removing the
-d option from the reboot command in
/etc/init.d/reboot and see what changed. It fixed the problem; now the system restarts just fine. I don’t know how it was executing a reboot when gdm was still running that was so different from how it did things after I disabled gdm at runlevel 2, but at least we got it working without having to have gdm acting as gatekeeper to system functionality any longer.
Trouble In Paradise
Okay — what the fuck?
Why does deactivating gdm cause the graphics driver to stop working properly so that 3D rendering doesn’t work any longer?
Christ on a stick, I hate the way Ubuntu just assumes that everybody wants to do everything exactly one way, and no other way of doing this is “okay”. Yes, we must all want GNOME, and gdm, and a fucking splash screen at start up, and seventy metric tons of other useless shit cluttering up our computers and getting in our fucking way. We all want it so badly that turning any of that off has to break fucking everything.
Goddammit, Ubuntu, you can pucker up and kiss my bunghole. Shit.