Back to article
Why Use GRUB2? Good Question! (part 3)
Translating Bizarre Error Messages, and Fixes
March 11, 2010
The last two grub2 articles (Part 1, Part 2)have covered how to clean up your grub2 boot menu and make it look prettier. But writing grub2 entries can be frustrating, too. Here are some possible solutions and workarounds.
While you're debugging your grub2 entries, you may make some (gasp!) mistakes. And the error messages aren't always as clear as they could be.
The one I saw most was "error: You need to load the kernel first". That one actually means "You got the name of the kernel wrong: you probably said /boot/vmlinuz when you meant just /vmlinuz". That's easy to fix, fortunately, if you know what the real kernel name is.
Note: If /boot is its own partition, then kernels need to be specified as just /vmlinuz, or by the full kernel name, such as /vmlinuz-2.6.26-2-686. But the standard update-grub scripts don't always get that right, and sometimes insert an extra /boot which will cause problems when you reboot.
Another popular error was "mount point /dev/pts does not exist". None of the experts I've asked could tell me exactly what's happening here -- /dev/pts has to do with virtual ttys, so that's not really the problem. But practically speaking, most often it means it couldn't find the right initrd file. So check your grub entry to see if an initrd is specified, and make sure the name is right.
There's one big problem left: machines with multiple Linux distributions installed on separate partitions.
Suppose you want to keep your Ubuntu 9.10 installation but also try Fedora 11. Or what if you have the latest releases of Ubuntu and Fedora, but you want to try the unstable scary alpha of the next release? On today's big disks, it's easy to find space for lots of 9-12G root partitions. But how do you boot them?
In the distant past, Linux used a boot loader called lilo. Lilo was a pain, because whenever you changed anything, like adding a new kernel, you had to reboot into the distro where you originally installed lilo to update your disk's boot partition. You couldn't run lilo from anywhere else because of version incompatibilities. If you forgot which distro was the one allowed to run lilo, you were in trouble.
In 2001, grub changed that -- you could make a small shared partition for /boot and update it from anywhere. Huge improvement!
Now, 9 years later, we have grub2 -- and we're back to the bad old days of lilo. Sure, there's a file called /boot/grub/grub.cfg that you can edit -- and it starts like this:
# # DO NOT EDIT THIS FILE # # It is automatically generated by /usr/sbin/grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### if [ -s /boot/grub/grubenv ]; then ...
Instead, you're supposed to edit files inside /etc/grub.d, plus another file, /etc/default/grub. That's all very well ... except that those directories aren't accessible to other distros. If you've set up grub on your Ubuntu 9.10 partition but you're currently running 10.04, or Fedora or Gentoo, what happens if you need to add a new grub2 entry? Apparently you're supposed to reboot back to Ubuntu 9.10, and lord help you if you forget and accidentally run update-grub from some other system. Ouch! Is this a case of "Those who don't remember the past are doomed to repeat it?"
So how do you work around the problem?
Method 1: Edit grub.cfg Anyway
If you don't mind editing /boot/grub/grub.cfg yourself, you just need to ensure that update-grub won't overwrite it when you update your system. Be sure to keep a backup copy, just in case.
/usr/sbin/update-grub is just a one-line shell script:
#!/bin/sh -e exec grub-mkconfig -o /boot/grub/grub.cfg "$@"
You can comment out the line and replace it with an echo:
#!/bin/sh -e # exec grub-mkconfig -o /boot/grub/grub.cfg "$@" echo "Not updating grub: edit /boot/grub/grub.cfg directly"
If you want to be sure the system won't overwrite that change, use chattr:
$ sudo chattr +i /usr/sbin/update-grub
Warning: this chattr trick means that if a system update ever tries to install a new update-grub, the update will fail. So any time you make hacks like this to your system, be prepared for that possibility.