Category: PC Tweakage

The default Grub2 video mode for Ubuntu 12.04 is 640×480, which looks rather overwhelming on a 24 inch monitor that can do 1920×1600. I’m also a fan of Old Skool scrolling text, because when something goes wrong it’s handy to get an actual hint in real time.

Thus, some Grub tweakage was in order:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

 ... snippage ...

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
#GRUB_GFXMODE=1600x1200
GRUB_GFXMODE=1280x1024

AFAICT, it’s impossible to:

• Page(*) the output of the Grub vbeinfo command. A blind stab at 1600×1200 turned out to be too small and painfully slow at scrolling in graphics mode.
• Boot a text-mode console in anything other than 80 characters x 24 rows, so un-commenting the GRUB_TERMINAL line isn’t helpful.

This being Grub2, you must do this special dance (anybody remember when one of Grub’s advantages over Lilo was that it didn’t require a special dance?) to make it work:

sudo nano /etc/default/grub
 ... make changes & save ...
sudo update-grub
sudo reboot ; exit

That’s from an SSH session across the room, of course…

Incidentally, shutting off the graphic drivel immediately revealed that those NFS mounts weren’t happening because statd wasn’t running. Knowing that immediately would have saved some diagnostic time, yes, it would.

(*) The Official Grub2 doc suggests set pager=1, but there’s no way to discover that using help set at the Grub2 command line. Now we both know and maybe we’ll remember it for the next time.

Back in the old days, the Unix startup sequence was rigidly fixed. For a variety of reasons, that’s no longer the case; Ubuntu (and, presumably, other distros) now use upstart, which turns the startup sequence into a lightly documented Pachinko machine. This parallel processing presumably works great for most of Ubuntu’s use cases and falls flat on its face for me: I’m apparently the only person who expects NFS mounts to be in place before signing in.

Well, maybe other folks expect that, but the entire startup mechanism is apparently broken as designed.

The only solution seems to be stalling the user sign-on screen by jamming the display manager until the NFS client hauls itself to its feet. This takes up to a minute, for reasons I do not understand, but it’s better to let it run to completion rather than signing on and expecting one’s files to be in the right places. Email clients, in particular, have difficulty coping with missing files.

The fix involves adding a line to /etc/init/lightdm.conf, as mentioned there (albeit with incorrect syntax):

start on ((filesystem
           and runlevel [!06]
           and started dbus
           and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                or stopped udev-fallback-graphics)
           and mounted MOUNTPOINT=/mnt/bulkdata)
          or runlevel PREVLEVEL=S)

I tried to check for another filesystem that should also be mounted, but, as I understand neither the syntax nor the semantics of the language, what you see is what finally worked. As it turns out, upstart's syntax error messages aren’t particularly helpful; a single line (helpfully relating, perhaps, that the parser expected a token on line 16) appears on VT 7, but if you don’t know to switch from VT 1, you’ll never get even that minimal assistance. No, such errors don’t appear in the /var/log/upstart/* logs.

For unknown reasons, waiting for the remote-filesystems event didn’t delay the startup at all. Evidently, mountall emits that event almost immediately, long before the NFS mounts happen. Perhaps the event occurs even when the mount fails, contrary to what the doc suggests?

Most of the debugging occurred through an ssh session across the room. Edit the file, try a new version, reboot, watch for the filesystems to come up, watch for the sign-in screen to appear. Or not, as the case may be.

Grumpy though I may seem, the great thing about Open Source / Free Software is that when it breaks, you have access to all the pieces and can actually fix the problem. That makes up for nearly everything, I’d say.

No, I didn’t update any of those bug reports or start another one. It’s obvious this isn’t getting any attention, so what’s the point? If you’re also having the problem, you’ll eventually wind up here…

FWIW, I knew the NFS mounts weren’t working because I always set the screen background to an image on the file server: no mount = no picture = fix-the-problem-now. This image seemed appropriate:

Back then, transistors were countable resources…

[Update: The previous picture link, now broken, was to http://www.nasaimages.org/luna/servlet/detail/nasaNAS~2~2~2995~104520. The revised link points to a description on archive.org, with versions of the picture available for download.]