The first class using Debian Etch started in May 2007. Graduation date is June 17; machines need to be customized by the end of Week Five, June 10. Robert made a box of cloned drives. Issues and (hopefully) resolutions:

Sean was having problems getting the xserver to start. He did all the right things (ran dpkg-reconfigure xserver-xorg and specified the Intel i810, set the ranges correctly for a standard monitor, etc.) but it still wouldn't work. Here's how I figured it out … read this screen carefully. Note which specific video chip it points out may cause a problem.

The solution was as simple as specifying an amount of memory for the video card to use. I tried 64000kB, saved the config file … and now the xserver works. So it would seem that when the xserver was xfree86, it didn't have a problem with the i810 and no memory specified, but now that it is xorg, it does. Also explains why I didn't run into the issue. My test machine at home has an older nVidia card.

Debian gets its initial system time from BIOS when it boots up. So, if the battery is bad, and the machine has been unplugged since the last time the date and time were set in BIOS, then Debian gets a system date of whatever the BIOS default is - the one I ran into was January 1, 1990. So when the machine began to boot, a filesystem check was forced because the filesystem date was a future date (last time the machine shut down it was 2007. Now it thinks it's 1990.), and the fsck failed with an error. I rebooted, fixed the BIOS, it had to run another fsck because it had been 6000+ days since the last time, or so it thought, and also because I wanted to make sure nothing was wrong with the drive. Point is, that would be a complete show-stopper for most of our graduates. Is there anything we can do about it? Do we start a policy of swapping out every machine's BIOS battery as a part of our build process? Just wanted to get this out there for folks to think about.

This is peculiar, but repeatable, behavior. The first time I boot up with the GUI working, GRUB has no timeout. Once I select the Debian image, and boot up, then when I re-boot, the timeout is now working. Don't know why this is. Robert didn't know either. For now, since we have to boot up each machine at least once or twice while configuring it, it is not a big deal. Just check to make sure GRUB's timeout is enabled after a reboot.

One of the machines I brought home has some serious issues. This one, I had to boot up in single-user mode in order to get to a login screen to reconfigure the xserver. Once that was fixed, I could boot off either (although had to hit 'enter' to make the choice, as no GRUB timeout was working) but ran into other issues. It seems to get stuck on starting crond, so using the virtual terminals 2-6 isn't possible, and 1 is stuck so you can't log in there, so your only option is 7, via the GUI. Opening a terminal there, it looks quite peculiar. Note that although the terminal window is named correctly, the menu is not displaying, although the unknown characters are underscored correctly! (second from the right would be 'tabs' and that one is hot-keyed off the 'd' and not the 't')

Another hard disk has similar issues with gnome components. Got errors when trying to open a terminal in the GUI, for example. For now, I just labeled it as needs to be re-imaged.

GRUB