Thanks, EvilSupahFly. I can now add this:

Rm'ing every grub related file on the other systems, reinstalling grub,
and running update-grub was REALLY BAD IDEA. Now when I try to boot
/dev/sda6 (the system that is an fsarchiver-made clone of my main,
/dev/sda5-based 14.04 system, where grub is supposed to live) all I get
is BusyBox with a prompt something like "[initramfs]". So now my sda5
system is broken. But I can restore the fsa backup again easily enough.

It is possible, AFAIK from my own ignorance, that a modified approach
like that MIGHT work, if you knew exactly WHICH grub related files to
rm, and if anyone thinks that's the case, I'd appreciate their expanding
on the topic, as it sounds to me as if, that if something like that
would work at all it might be either something I'd only have to do once,
or failing that, something that might be simple enough to write a script
to do, and run that script every time I run dist-upgrade or restore an
fsarchiver backup to a partition it wasn't on originally.

When you say manual editing works for you, I assume you mean editing
grub.cfg on the system that should be the one where grub was last
installed via a regular installation procedure (as opposed to restoring
a clone with fsarchiver or Clonezilla). As for update-grub rewriting it
incorrectly, I could just mark it read-only or take the x perm off
update-grub, or alias update-grub to something innocuous. As for
grub.cfg getting outdated and booting old kernels (or crashing if
they've been removed), I seem to remember there is some way to make an
entry that in effect says "boot from the latest one there, whatever it
is". If I had a grub.cfg like that, could I just disable os-prober and
update-grub, and not have to edit until I changed my partition setup?

Would having a seperate boot partition get me around all this and let
grub work automatically?

If I have to manually edit grub.cfg every time a kernel is updated, or
every time I install an OS or restore an fsa or clonezilla backup, would
I be better off switching to a boot loader that was written with the
INTENT that a boot configuration file would have to be manually
maintained?

I've also tried the LILO approach since I posted. It does boot my main
/dev/sda5 14.04 fine, but it didn't pick up on any of the other systems
automatically. So I purged it with apt-get and reinstalled grub ("grub
'2'") hoping I could get find the magic spell to make grub-2 work
automatically, but so far I haven't. So, if I DO have to hand edit every
time constantly, maybe I should revert that.

At any rate, anyone reading this looking for work arounds will now know
at least one thing that does NOT work. Anyone with thoughts on how to
set up a low maintenance boot loader, either with grub-2 or something
else, that can cope with new OSs coming and going through normal
installation and clone restoration, please share your ideas.

Meanwhile, I think I'm going to read up on boot partitions. Thanks for
reading.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/554307

Title:
  linux-boot-prober yields wrong uuid for kernel root parameter

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/554307/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to