[Bug 1873924] [NEW] Menu entries generated for other linux installations on lvm volumes point to /dev/dm-X as root filesystem which can result in boot failures

[Jan Rathmann]

Public bug reported:

Hello,

this is some bug in the generation of grub.cfg that I have seen on all
Ubuntu releases during the last years (can't recall when this first
happened - sorry!) - now I finally manage to report it :-)

On the grub.cfg generated on my system only the menu entry of my main
Ubuntu installation contains a direct reference to the actual name of
the volume group/logical volume in the "linux line", e.g.:

...
linux	/@/boot/vmlinuz-5.4.0-24-generic root=/dev/mapper/internal--ssd-roothome ro ...
...

This is fine.

But on entries that are generated for linux installations on other
logical volumes (which are booted by grub of my main installation) the
"linux line" contains only a reference to "/dev/dm-X", e.g.:

...
linux /boot/vmlinuz root=/dev/dm-4
...

The problem is that there seems to be no constant assignment of volume group/logical volume names to "/dev/dm-X" names between reboots, maybe because I have two drives (one SSD with volume group "internal-ssd"; one HDD with volume group "internal-hdd") on my system.
The result is that the menu entries generated this way sometimes fails to boot because "root=/dev/dm-X" points to the wrong logical volume. I can workaround this only by either editing /boot/grub.cfg or editing the menu entries during boot to make them point to the actual name of the logical volume ("root=/dev/mapper/internal--hdd-test1" instead of "root=/dev/dm-0").

So the fix for this issue would be that the entries for other linux
installations in grub.cfg would be generated that way that they
reference the actual v-group/lv-name of the respective root filesystem
instead of volatile /dev/dm-X.

I have attached my grub.cfg below.

Kind regards,
Jan

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: grub2 (not installed)
ProcVersionSignature: Ubuntu 5.4.0-24.28-generic 5.4.30
Uname: Linux 5.4.0-24-generic x86_64
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Mon Apr 20 19:01:14 2020
InstallationDate: Installed on 2020-04-08 (12 days ago)
InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200408)
SourcePackage: grub2
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: grub2 (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug focal

** Attachment added: "grub.cfg"
   https://bugs.launchpad.net/bugs/1873924/+attachment/5357214/+files/grub.cfg

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

Title:
  Menu entries generated for other linux installations on lvm volumes
  point to /dev/dm-X as root filesystem which can result in boot
  failures

Status in grub2 package in Ubuntu:
  New

Bug description:
  Hello,

  this is some bug in the generation of grub.cfg that I have seen on all
  Ubuntu releases during the last years (can't recall when this first
  happened - sorry!) - now I finally manage to report it :-)

  On the grub.cfg generated on my system only the menu entry of my main
  Ubuntu installation contains a direct reference to the actual name of
  the volume group/logical volume in the "linux line", e.g.:

  ...
  linux	/@/boot/vmlinuz-5.4.0-24-generic root=/dev/mapper/internal--ssd-roothome ro ...
  ...

  This is fine.

  But on entries that are generated for linux installations on other
  logical volumes (which are booted by grub of my main installation) the
  "linux line" contains only a reference to "/dev/dm-X", e.g.:

  ...
  linux /boot/vmlinuz root=/dev/dm-4
  ...

  The problem is that there seems to be no constant assignment of volume group/logical volume names to "/dev/dm-X" names between reboots, maybe because I have two drives (one SSD with volume group "internal-ssd"; one HDD with volume group "internal-hdd") on my system.
  The result is that the menu entries generated this way sometimes fails to boot because "root=/dev/dm-X" points to the wrong logical volume. I can workaround this only by either editing /boot/grub.cfg or editing the menu entries during boot to make them point to the actual name of the logical volume ("root=/dev/mapper/internal--hdd-test1" instead of "root=/dev/dm-0").

  So the fix for this issue would be that the entries for other linux
  installations in grub.cfg would be generated that way that they
  reference the actual v-group/lv-name of the respective root filesystem
  instead of volatile /dev/dm-X.

  I have attached my grub.cfg below.

  Kind regards,
  Jan

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: grub2 (not installed)
  ProcVersionSignature: Ubuntu 5.4.0-24.28-generic 5.4.30
  Uname: Linux 5.4.0-24-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Mon Apr 20 19:01:14 2020
  InstallationDate: Installed on 2020-04-08 (12 days ago)
  InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200408)
  SourcePackage: grub2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1873924/+subscriptions