[Techtalk] Restoring boot set-up

Akkana Peck akkana at shallowsky.com
Sun Jan 20 19:20:52 UTC 2013

Chris Wilson writes:
> I agree that Grub2 is much more complex, but it is the future, and I
> recommend that you bite the bullet and get used to it.
> The biggest help for me in understanding Grub2 is that the
> configuration file is not AT ALL written by hand any more. In Grub1,

My problem with grub2 is that it really doesn't work well for the
sort of installation David uses (which I also use), precisely
because of this "don't touch the configuration file" issue.

The problem shows up when you have a shared /boot partition that all your
distros use, where the actual bootloader files (the menu and such) live.

With grub2, you're not supposed to edit anything in that shared /boot,
and the bootloader configuration -- the one you're allowed to edit --
lives on the /usr partition for one of your distros.

So let's say grub2 was installed by Ubuntu Quetzal, and the config
files live there. But while you're running from your Ubuntu Pangolin
installed on another partition, you do a dist-upgrade and you notice
there was a new kernel.

Whoops! You can't reboot into that kernel, because there's no way,
from Pangolin, to update the bootloader. Not by hand (because you're
not supposed to edit that file); not automatically from dist-upgrade
(because the files all live on the Quetzal partition). You're
supposed to shut down everything and reboot into your Quetzal
"master distro" so you can run update-grub.

You might think, "Wait, both versions of Ubuntu have grub2, so can't
I run update-grub from either one?"  But grub version changes make
that dicey: it's likely to fail with an error message. Oh, don't
forget to write down somewhere which of your distros is the master,
so you don't accidentally try to update grub from one of the others!

But wait, it's worse than that. Because at least under Ubuntu,
when you run update-grub after rebooting into your master distro,
that distro goes out and finds all the kernels on /boot and gives
you a menu containing a combinatoric explosion with an entry for
every root partition you have times ever kernel you have. And
if you want to know which of those 22 entries is the one you want,
you have to remember (a) which partition is Pangolin and (b)
which kernel version is the new one that was just installed before
you rebooted. I've seen grub menus with more than 30 entries, most
of which wouldn't boot at all since they mixed one distro's root
partition with the kernel from another distro.

It's possible to get back to a simple boot menu with nice labels --
but it requires turning off all the automatic update-grub
mechanisms. In which case, it's not really any easier than
editing the configuration file by hand, directly.

(There are a few other stupid things about grub2, too: see
http://shallowsky.com/blog/linux/grub2-lightning.html )

Unfortunately, it's not easy to go back to grub1, since it hasn't
been supported in years. The easiest way is to use one of your spare
partitions to install a distro that still offers it. (Don't bother
with Ubuntu's legacy grub package -- it says it's grub1 but it
actually installs grub2 files.) My husband says Arch's grub1 works
best, though the package isn't in their current package repository
so you have to get it from their "wayback machine".

I find that too much hassle, so I've given up on both grub1 and grub2
and switched to extlinux. It's still supported in all distros,
so you can install it from anywhere. The Debian/Ubuntu version of
extlinux has some automatic updating similar to what grub does,
but it's much easier to turn off. Its only down side is that it
apparently doesn't support UEFI; maybe it will eventually.

The only bad thing about extlinux is that there isn't much
documentation, so once I got it working I wrote up a howto:

And an article about how Debian's extlinux auto-update works, and
how to disable it:


More information about the Techtalk mailing list