[Bug 1838525] Re: LVM setup fails to install grub on virtio storage
Rafael David Tinoco
rafaeldtinoco at kernelpath.com
Tue Oct 8 03:00:34 UTC 2019
Merge request was done here:
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/grub2/+git/grub2/+merge/373792
And the following PPA is available:
https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1838525
** Description changed:
+ [Impact]
+
+ * Any Eoan installation that depends on latest installer will face this
+ issue when final user chooses LVM full disk partitioning type.
+
+ * Grub won't be able to install due to bad bootdevice variable in the
+ installer. It will try to install grub to "/dev/mapper" and will fail.
+ The default boot option will also be "/dev/mapper".
+
+ [Test Case]
+
+ * Download netboot files from current installer (vmlinuz and initrd
+ files).
+
+ * Create a KVM guest running from these files, with a NIC connected to
+ the internet.
+
+ * Initiate a network installation inside the KVM guest, choosing the
+ Entire Disk - LVM partitioning option.
+
+ * Wait installation to finish and to start the grub-install phase. It
+ will ask where to install grub, having, as default, "/dev/mapper". By
+ default, it might simply try to grub-install /dev/mapper, which will
+ also fail.
+
+ * That happens because /dev/disk/by-id/ has an unexpected (by the
+ installer) symlink added by lvm2 package that grub-installer (used by
+ debian-installer) does not expect (when using grub-mkdevice command).
+
+ [Regression Potential]
+
+ There are 3 alternatives to fix this and I have chosen the one I believe
+ has the smaller potential for any type of regression. Comment #30
+ describes what caused the regression and these 3 alternatives:
+
+ (1) To revert this change for current release, since this rule was added
+ to "make navigation a bit easier using PV UUIDs", as the commit says. We
+ would worry about installer changes in the next release.
+
+ (2) Another possibility would be to change the logic inside "grub-
+ mkdevicemap.c: make_device_map()->grub_util_iterate_devices()" to ignore
+ all symlinks from /dev/disk/by-id/ containing lvm-pv-uuid-*. We would
+ not have to worry about this in the next release if using debian-
+ installer.
+
+ (3) Another option would be to change grub-installer package/logic.
+ Unfortunately, a few days before the full freeze, I don't think messing
+ with the installer would be a good option to avoid regressions
+ (potential regression item would grow in significance).
+
+ => I'm choosing (2) because ubuntu foundations already faced a similar
+ situation, when grub-mkdevicemap.c file was removed from grub2 code and
+ they re-added it by using a quilt patch, assuming it was the easiest and
+ better to maintain. I'm doing something similar, patching the patch that
+ creates grub-mkdevicemap.c file again to ignore /dev/disk/by-id/lvm-pv-
+ uuid-* files (like it already does for other symlinks, actually).
+
+ [Other Info]
+
Comment #26 has the TL;DR version of the problem.
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/comments/26
[Original Description]
The Eoan debian-installer ISO fails to install GRUB on LVM installs with
virtio storage, as it runs grub-install with /dev/mapper as a target (a
directory), even if instructed to target a device.
The following steps to reproduce have been prepared running the 20190730
build, but this has been broken since about June 18, 2019. Steps to
reproduce:
$ md5sum eoan-server-amd64.iso
f591e30485e5f0b5117f6c116e538c42 eoan-server-amd64.iso
$ qemu-img create -f raw disk1.img 8G
Formatting 'disk1.img', fmt=raw size=8589934592
$ kvm -m 1024 -boot d -cdrom eoan-server-amd64.iso -drive file=disk1.img,if=virtio
Proceed with all the defaults. In the "Partition disk" step select
"Guided - use entire disk and set up LVM". Go ahead accepting the
defaults. At the "Install the GRUB boot loader" step select "/dev/vda"
as the target device. The installer will actually run `grub-install
--force /dev/mapper` and fail after a while. The wrong command is
visible both in the d-i screen and by running `ps` on a different
console.
Full installer syslog: http://paste.ubuntu.com/p/qtZy86dTp6/
It's interesting how this doesn't happen when not using virtio. If from
the commands above the "if=virtio" option is dropped then everything
works as expected. In this case the target block device is called
/dev/sda instead of /dev/vda.
** Description changed:
[Impact]
- * Any Eoan installation that depends on latest installer will face this
+ * Any Eoan installation that depends on latest installer will face this
issue when final user chooses LVM full disk partitioning type.
- * Grub won't be able to install due to bad bootdevice variable in the
+ * Grub won't be able to install due to bad bootdevice variable in the
installer. It will try to install grub to "/dev/mapper" and will fail.
The default boot option will also be "/dev/mapper".
[Test Case]
- * Download netboot files from current installer (vmlinuz and initrd
+ * Download netboot files from current installer (vmlinuz and initrd
files).
- * Create a KVM guest running from these files, with a NIC connected to
+ * Create a KVM guest running from these files, with a NIC connected to
the internet.
- * Initiate a network installation inside the KVM guest, choosing the
+ * Initiate a network installation inside the KVM guest, choosing the
Entire Disk - LVM partitioning option.
- * Wait installation to finish and to start the grub-install phase. It
+ * Wait installation to finish and to start the grub-install phase. It
will ask where to install grub, having, as default, "/dev/mapper". By
default, it might simply try to grub-install /dev/mapper, which will
also fail.
- * That happens because /dev/disk/by-id/ has an unexpected (by the
+ * That happens because /dev/disk/by-id/ has an unexpected (by the
installer) symlink added by lvm2 package that grub-installer (used by
debian-installer) does not expect (when using grub-mkdevice command).
+
+ [Simplified Test Case]
+
+ * To add a PV + VG + LVM in a KVM guest to an empty virtio disk, for
+ example, and to check if the command:
+
+ grub-mkdevice --no-floppy -m -
+
+ lists /dev/vdX1 in front of /dev/vdX. This will be a sign that:
+
+ /dev/disk/by-id/*lvm* file exists and will be enough to confuse
+ installer.
[Regression Potential]
There are 3 alternatives to fix this and I have chosen the one I believe
has the smaller potential for any type of regression. Comment #30
describes what caused the regression and these 3 alternatives:
(1) To revert this change for current release, since this rule was added
to "make navigation a bit easier using PV UUIDs", as the commit says. We
would worry about installer changes in the next release.
(2) Another possibility would be to change the logic inside "grub-
mkdevicemap.c: make_device_map()->grub_util_iterate_devices()" to ignore
all symlinks from /dev/disk/by-id/ containing lvm-pv-uuid-*. We would
not have to worry about this in the next release if using debian-
installer.
(3) Another option would be to change grub-installer package/logic.
Unfortunately, a few days before the full freeze, I don't think messing
with the installer would be a good option to avoid regressions
(potential regression item would grow in significance).
=> I'm choosing (2) because ubuntu foundations already faced a similar
situation, when grub-mkdevicemap.c file was removed from grub2 code and
they re-added it by using a quilt patch, assuming it was the easiest and
better to maintain. I'm doing something similar, patching the patch that
creates grub-mkdevicemap.c file again to ignore /dev/disk/by-id/lvm-pv-
uuid-* files (like it already does for other symlinks, actually).
[Other Info]
-
+
Comment #26 has the TL;DR version of the problem.
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/comments/26
[Original Description]
The Eoan debian-installer ISO fails to install GRUB on LVM installs with
virtio storage, as it runs grub-install with /dev/mapper as a target (a
directory), even if instructed to target a device.
The following steps to reproduce have been prepared running the 20190730
build, but this has been broken since about June 18, 2019. Steps to
reproduce:
$ md5sum eoan-server-amd64.iso
f591e30485e5f0b5117f6c116e538c42 eoan-server-amd64.iso
$ qemu-img create -f raw disk1.img 8G
Formatting 'disk1.img', fmt=raw size=8589934592
$ kvm -m 1024 -boot d -cdrom eoan-server-amd64.iso -drive file=disk1.img,if=virtio
Proceed with all the defaults. In the "Partition disk" step select
"Guided - use entire disk and set up LVM". Go ahead accepting the
defaults. At the "Install the GRUB boot loader" step select "/dev/vda"
as the target device. The installer will actually run `grub-install
--force /dev/mapper` and fail after a while. The wrong command is
visible both in the d-i screen and by running `ps` on a different
console.
Full installer syslog: http://paste.ubuntu.com/p/qtZy86dTp6/
It's interesting how this doesn't happen when not using virtio. If from
the commands above the "if=virtio" option is dropped then everything
works as expected. In this case the target block device is called
/dev/sda instead of /dev/vda.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1838525
Title:
LVM setup fails to install grub on virtio storage
Status in debian-installer package in Ubuntu:
In Progress
Status in grub2 package in Ubuntu:
In Progress
Status in lvm2 package in Ubuntu:
In Progress
Status in debian-installer package in Debian:
New
Bug description:
[Impact]
* Any Eoan installation that depends on latest installer will face
this issue when final user chooses LVM full disk partitioning type.
* Grub won't be able to install due to bad bootdevice variable in the
installer. It will try to install grub to "/dev/mapper" and will fail.
The default boot option will also be "/dev/mapper".
[Test Case]
* Download netboot files from current installer (vmlinuz and initrd
files).
* Create a KVM guest running from these files, with a NIC connected
to the internet.
* Initiate a network installation inside the KVM guest, choosing the
Entire Disk - LVM partitioning option.
* Wait installation to finish and to start the grub-install phase. It
will ask where to install grub, having, as default, "/dev/mapper". By
default, it might simply try to grub-install /dev/mapper, which will
also fail.
* That happens because /dev/disk/by-id/ has an unexpected (by the
installer) symlink added by lvm2 package that grub-installer (used by
debian-installer) does not expect (when using grub-mkdevice command).
[Simplified Test Case]
* To add a PV + VG + LVM in a KVM guest to an empty virtio disk, for
example, and to check if the command:
grub-mkdevice --no-floppy -m -
lists /dev/vdX1 in front of /dev/vdX. This will be a sign that:
/dev/disk/by-id/*lvm* file exists and will be enough to confuse
installer.
[Regression Potential]
There are 3 alternatives to fix this and I have chosen the one I
believe has the smaller potential for any type of regression. Comment
#30 describes what caused the regression and these 3 alternatives:
(1) To revert this change for current release, since this rule was
added to "make navigation a bit easier using PV UUIDs", as the commit
says. We would worry about installer changes in the next release.
(2) Another possibility would be to change the logic inside "grub-
mkdevicemap.c: make_device_map()->grub_util_iterate_devices()" to
ignore all symlinks from /dev/disk/by-id/ containing lvm-pv-uuid-*. We
would not have to worry about this in the next release if using
debian-installer.
(3) Another option would be to change grub-installer package/logic.
Unfortunately, a few days before the full freeze, I don't think
messing with the installer would be a good option to avoid regressions
(potential regression item would grow in significance).
=> I'm choosing (2) because ubuntu foundations already faced a similar
situation, when grub-mkdevicemap.c file was removed from grub2 code
and they re-added it by using a quilt patch, assuming it was the
easiest and better to maintain. I'm doing something similar, patching
the patch that creates grub-mkdevicemap.c file again to ignore
/dev/disk/by-id/lvm-pv-uuid-* files (like it already does for other
symlinks, actually).
[Other Info]
Comment #26 has the TL;DR version of the problem.
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/comments/26
[Original Description]
The Eoan debian-installer ISO fails to install GRUB on LVM installs
with virtio storage, as it runs grub-install with /dev/mapper as a
target (a directory), even if instructed to target a device.
The following steps to reproduce have been prepared running the
20190730 build, but this has been broken since about June 18, 2019.
Steps to reproduce:
$ md5sum eoan-server-amd64.iso
f591e30485e5f0b5117f6c116e538c42 eoan-server-amd64.iso
$ qemu-img create -f raw disk1.img 8G
Formatting 'disk1.img', fmt=raw size=8589934592
$ kvm -m 1024 -boot d -cdrom eoan-server-amd64.iso -drive file=disk1.img,if=virtio
Proceed with all the defaults. In the "Partition disk" step select
"Guided - use entire disk and set up LVM". Go ahead accepting the
defaults. At the "Install the GRUB boot loader" step select "/dev/vda"
as the target device. The installer will actually run `grub-install
--force /dev/mapper` and fail after a while. The wrong command is
visible both in the d-i screen and by running `ps` on a different
console.
Full installer syslog: http://paste.ubuntu.com/p/qtZy86dTp6/
It's interesting how this doesn't happen when not using virtio. If
from the commands above the "if=virtio" option is dropped then
everything works as expected. In this case the target block device is
called /dev/sda instead of /dev/vda.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/+subscriptions
More information about the foundations-bugs
mailing list