autogenerated entries for other Ubuntu systems use wrong root filesystem, unbootable

Bug #1912677 reported by Akkana Peck
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

On my disk I have two partitions that are root filesystems for two releases, Focal and Groovy:

Groovy 20.10 is on /dev/nvme0n1p3 3ac2446d-ae7c-4975-b736-44b1084266de
Focal 20.04 is on /dev/nvme0n1p4 4ff7a630-0e7e-4427-aa9e-513bcae849c3

If I run update-grub2 from Groovy, it detects the Focal partition and generates this entry for it:

menuentry 'Ubuntu 20.04.1 LTS (20.04) (on /dev/nvme0n1p4)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-4ff7a630-0e7e-4427-aa9e-513bcae849c3' {
 insmod part_gpt
 insmod ext2
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root 4ff7a630-0e7e-4427-aa9e-513bcae849c3
 else
   search --no-floppy --fs-uuid --set=root 4ff7a630-0e7e-4427-aa9e-513bcae849c3
 fi
 linux /boot/vmlinuz-5.4.0-52-generic root=UUID=3ac2446d-ae7c-4975-b736-44b1084266de ro text
 initrd /boot/initrd.img-5.4.0-52-generic
}

Note how the menu correctly says it's on p4, and gives the right UUID there and in the search --fs-uuid lines, but then in the actual linux kernel line, it uses root=UUID=3ac2446d-ae7c-4975-b736-44b1084266de, the wrong partition.

If I try to boot from that menuentry, the boot fails. At one point I'm fairly sure saw a message about not being able to find its initrd flash by, but I wasn't able to capture that message. Eventually it gets to a single-user prompt, and at that point if I scroll back, here are the warnings (yellow) and errors (red) captured in the scrollback:

UNSUPP Starting of Executable File Format File System Automount Point not supported
FAILED Failed to mount /boot/efi
DEPEND Dependency failed for Local File Systems

If I give the root password and then type mount, it has /dev/nvme0n1p3 (the Groovy root) mounted on /, not p4 (the Focal root it should be using).

So if I want to be able to use that Focal partition, I can't use the entry generated by os-prober; I have to make my own entry and add it to somewhere like 40_custom (in reality, of course I want it earlier, before the nonworking os-prober entries, so I named it 25-local):

menuentry 'Ubuntu 20.04 Focal LTS on nvme0n1p4' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-4ff7a630-0e7e-4427-aa9e-513bcae849c3' {
 recordfail
 load_video
 gfxmode $linux_gfx_mode
 insmod gzio
 if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
 insmod part_gpt
 insmod ext2
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root 4ff7a630-0e7e-4427-aa9e-513bcae849c3
 else
   search --no-floppy --fs-uuid --set=root 4ff7a630-0e7e-4427-aa9e-513bcae849c3
 fi
 linux /boot/vmlinuz-5.4.0-52-generic root=UUID=4ff7a630-0e7e-4427-aa9e-513bcae849c3 ro text
 initrd /boot/initrd.img-5.4.0-52-generic
}

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: grub-common 2.04-1ubuntu35.1
ProcVersionSignature: Ubuntu 5.8.0-38.43-generic 5.8.18
Uname: Linux 5.8.0-38-generic x86_64
ApportVersion: 2.20.11-0ubuntu50.3
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Jan 21 10:26:38 2021
InstallationDate: Installed on 2020-04-29 (267 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: grub2
UpgradeStatus: Upgraded to groovy on 2020-10-23 (90 days ago)
mtime.conffile..etc.grub.d.10_linux: 2021-01-21T10:19:44.446687

Revision history for this message
Akkana Peck (akkzilla) wrote :
Revision history for this message
Julian Andres Klode (juliank) wrote :

Running two *Ubuntu installs on the same system is not really supported, as there can only be one grub installed.

Same for os-prober really, it doesn't really work correctly for anything other than Windows.

So I understand that there's an issue, and we can fix this, but the expectation is that os-prober will go away at some point, and you should not run two ubuntus on one system.

Though I guess you can override the grub distributor is environment variable to hack around things, making the second Ubuntu install as like ubuntu2 to the ESP, and then select that from the UEFI boot device menu.

Changed in grub2 (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Akkana Peck (akkzilla) wrote :

Wow, really? But if multiple Linux partitions (common since the days of LILO) are discouraged now, why is os-prober searching for Linux distros on unmounted partitions and adding them to grub.cfg? If it's just for Windows and anything else isn't supported, maybe it should only add Windows installs.

I don't mind adding grub stanzas by hand for distros on other partitions. But automatically added grub entries that are wrong and won't boot just clutter the boot menu, making it hard to tell which are the working entries.

Revision history for this message
Julian Andres Klode (juliank) wrote :

Things are complicated, and they work fine if you don't use secureboot UEFI.

Multiple ubuntu systems work fine in BIOS mode, but on UEFI grub-install only installs one "ubuntu" boot loader entry and hence if you run multiple ubuntus, you essentially flip back and forth between their grubs on /boot/efi which is suboptimal. I'm not sure if grub devs ever thought about users having two installs of one system. But it's hard to solve the problem of people changing disks and not indefinitely growing the number of boot loader entries with each new disk.

Anyhow, yes, I guess it needs fixing, needs some digging into what's going on.

Windows is a lot simpler, as that code just chainloads window's bootloader, and doesn't have to deal with setting up the other kernel entries :)

Changed in grub2 (Ubuntu):
importance: Low → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers