[Bug 1838525] Re: LVM setup fails to install grub on virtio storage

Tue Oct 8 03:24:52 UTC 2019

Verifying the fix from the PPA:

(k)rafaeldtinoco at keoan:~$ ls /dev/disk/by-id
ls: cannot access '/dev/disk/by-id': No such file or directory

(k)rafaeldtinoco at keoan:~$ sudo grub-mkdevicemap --no-floppy -m -
(hd0)   /dev/vda
(hd1)   /dev/vdb

This is the expected behavior (by installer).

(k)rafaeldtinoco at keoan:~$ sudo pvcreate /dev/vdb 
  Physical volume "/dev/vdb" successfully created.

(k)rafaeldtinoco at keoan:~$ sudo vgcreate vgubuntu /dev/vdb
  Volume group "vgubuntu" successfully created

(k)rafaeldtinoco at keoan:~$ sudo lvcreate -l100%VG -n lvubuntu vgubuntu
  Logical volume "lvubuntu" created.

(k)rafaeldtinoco at keoan:~$ sudo grub-mkdevicemap --no-floppy -m -
(hd0)   /dev/disk/by-id/lvm-pv-uuid-tdcf0A-qcPJ-1A1H-Oh2G-I1vE-GQPx-tjjeva
(hd1)   /dev/vda

After installing the fix:

(k)rafaeldtinoco at keoan:~$ ls -1 /dev/disk/by-id
dm-name-vgubuntu-lvubuntu
dm-uuid-LVM-btjm85kImnUtxMqC6ObQmM64kO1Bop7Gv7v1qbZIaKsBfOB0uyFfC3cG37LaB3KN
lvm-pv-uuid-tdcf0A-qcPJ-1A1H-Oh2G-I1vE-GQPx-tjjeva

(k)rafaeldtinoco at keoan:~$ sudo grub-mkdevicemap --no-floppy -m -
(hd0)   /dev/vda
(hd1)   /dev/vdb

Back to same behavior!

** 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).

  [Simplified Test Case]

-  * To add a PV + VG + LVM in a KVM guest to an empty virtio disk, for
+  * 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 -
+ grub-mkdevicemap --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-mkdevicemap --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