Comment 16 for bug 554307

I agree with you that os-prober cannot automatically tell, which kernel files belong to which installation, if several linux installs share the same /boot.

(1) Still, its behaviour could be easily improved: If os-prober detects two linux installs with a shared /boot, it could simply ask the user, which install should boot which kernel. Instead it silently fails with no warning and the user ends up with a grub.cfg that fails booting one of the installs.

(2) The resulting grub.cfg is definitely inconsistent, even if os-prober cannot decide which kernel belongs to which install. To illustrate this, kindly have a look at my original bug report (which I have later marked a duplicate of this): Bug #554307
In the description of Bug #554307 you see the grub.cfg the user gets when running update-grub on two installs sharing /boot. Yes, os-prober cannot determine which install should boot which kernel. But this is not the problem I report there. The resulting grub.cfg looks like this:

[...]
menuentry '<name of first linux OS> (on /dev/sda2)' [...] {
        [...]
        set root='(hd0,msdos1)' # <- this is the boot partition, /dev/sda1
        search --no-floppy --fs-uuid --set=root <UUID of /dev/sda1>
        linux /vmlinuz-x.x.x root=UUID=<UUID of /dev/sda2> [...]
        initrd [....]
}
menuentry '<name of second linux OS> (on /dev/sda3)' [...] {
        [...]
        set root='(hd0,msdos1)' # <- this is the boot partition, /dev/sda1
        search --no-floppy --fs-uuid --set=root <UUID-of-/dev/sda1>
        linux /vmlinuz-y.y.y root=UUID=<UUID of /dev/sda2 (!!!)> [...]
        initrd [....]
}
[...]

Look at the *second* menuentry: Its *name* correctly refers to the *second* install (on /dev/sda3). Still its *linux call* refers to the *first* install an /dev/sda2. This is clearly inconsistent and a bug.

My original report in #554307 was about this bug. If you feel that this differs from the issues reported here, I will be unlisting this bug as a duplicate and reopen it.