update-grub sets wrong root argument

I agree, grub2 is a complete mess here and this problem looks closely related to what I reported in bug 510824. I talked to the devs in #grub about it, but unfortunately they don't seem to care about shipping a quality product.

/etc/grub.d/30_os-prober uses os-prober to determine the parameters to pass to linux. os-prober in turn looks at what is passed to the kernel in that system's /boot/grub/grub.cfg. Since that system is a copy of the main one, its grub.cfg has the main system's UUID for the root= parameter.

That is my guess of what is happening at least. If I'm correct then booting/chrooting into the backup system and running update-grub ( or manually fixing the root= in the backup's grub.cfg ), then booting into the main system and running update-grub there should give you a working entry for the backup system.

Jordan, thank you for that explanation. I would say, that is way to complicated for an ordinary user (I consider myself proficient with them and would have to reread a couple of times to understand what it is you want the user to do). This needs to be "dumbed down" so that it just works and an ordinary user won't even run into the problem described here.

proficient with them = proficient with computers

Maybe this is related to bug 551790?

Appears to be related to Bugs 392836, 462961, and 551790.

I had a similar problem after copying all files from the root partition /dev/sda1 to another partition /dev/sdb1 and trying to tell grub to boot from there now.

I digged into problem a little bit...
When i run `update-grub` it runs each of the files in `/etc/grub.d/`, my linux copy (Ubuntu in this case) gets detected by `30_os-prober`. This will run `/usr/bin/os-prober`. This works fine. In the `for OS in ${OSPROBED} ` loop it goes into the linux) branch, but somehow sets the $LPARAMS variable wrong. This is due to the sometimes-wrong output of `/usr/bin/linux-boot-prober`. In that script, there is a loop `for test in /usr/lib/linux-boot-probes/mounted/*`, which runs the file `40grub2` from there in my case. (I know that from the debug output flooding syslog.) This script calls its `parse_grub_menu` function with some parameters, and parses "$mpoint/boot/grub/grub.cfg", where $mpoint is the mount point of /dev/sdb1. However, the grub.cfg in there contains the old UUID of /dev/sda1, because it is just a binary copy and does not come from a fresh install.

My plan A was to fix this, take the correct UUID from the device (here: /dev/sdb1), corresponding to the mapping from /dev/disk/by-uuid/ and post a patch. But the inner works of grub seem to complicated for me. I lost motivation to do that.

Now that I know what the problem is, I took plan B, and chrooted into /dev/sdb1, ran update-grub in there, and reboot. You only need to do that once, afterwards the files are okay.
(...btw, for similar setups: you might want to have two different /etc/fstab on each of the partitions.)
This is somewhat a workaround. But here it goes:

mount /dev/sdb1 /mnt/disk
mount -o bind /dev /mnt/disk/dev
mount -o bind /sys /mnt/disk/sys
mount -t proc /proc /mnt/disk/proc
cp /proc/mounts /mnt/disk/etc/mtab

chroot /mnt/disk /bin/bash
grub-install /dev/sdb
update-grub
exit

(Plan C would have been to update the grub.cfg with the correct UUID manually.)

This is fixed by applying this:
https://gist.github.com/pepa65/85d5fcd1e12bc6028501c746258ac8cf

Peter, have you tried to get this into upstream or at least into Debian?

The problem with this solution is, it is discarding most of the information of os-prober, and instead is just enumerating the kernels & initrds that are listed in /lib/modules. Now I haven't checked with many distributions, but I know Ubuntu, Debian, OpenSUSE and RedHat is using this same location. But you could build boot entries for any kernel you can find anywhere. It's just that you couldn't build initrds for those other kernels because update-initramfs will not run (I don't know about dracut).

I have reported a related problem in these forums, but got a Won't Fix. I'm now maintaining my own patches for my own needs, and anybody is welcome to them.

HOLY COW!!!! This bug was reported in 2010 AND STILL HAS NOT BEEN FIXED ! Totally unacceptable.

To make sure we have a common understanding. I have linux on partition sda9 and "other" version of linux on partitions sda8, sdb8, and sdb9. The menu entries for ALL the "other" linuxes all specify the sda8 partition is the root partition, which is wrong for the sdb8 and sdb9 partitions. The bug applies if one is specifying the root using UUID or device name.

I have inserted the following line into 30_os-prober as a Bug-Work-Around. The BWA only works because I am specifing root with a device name and not a UUID. A different BWA would be required for those using UUID. Fixing this should not be a major undertaking. I cannot fathom why in some much time it has not been addressed.

LPARAMS=`echo $LPARAMS | sed "s:root=/dev/[A-Za-z0-9]* :root=$LROOT :"`

I think either linux-boot-prober or update-grub need a fix. As far as I remember, the point was that $mpoint/boot/grub/grub.cfg is not a reliable source of information. However, if you can do `mount $DEVICE $mpoint`, you can trust that $DEVICE correct, because the environment in which update-grub is called is mostly likely the new/current/correct one. At the very least, one could check if the "root" from linux-boot-prober is mountable and if not, fall back to what Peter's patch does.