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

Rafael David Tinoco rafaeldtinoco at kernelpath.com
Wed Oct 2 14:31:18 UTC 2019


Excluding installer issue on ordering, which would be harder to fix AS code base is highly dependent on assumptions, etc... checking only LVM for previous releases:

----
(k)inaddy at kdisco:~$ sudo ls -lah -1 /dev/disk/by-id
total 0
drwxr-xr-x 2 root root 100 Oct  2 13:57 .
drwxr-xr-x 7 root root 140 Oct  2 13:56 ..
lrwxrwxrwx 1 root root  10 Oct  2 13:57 dm-name-vgtest-lvtest -> ../../dm-0
lrwxrwxrwx 1 root root  10 Oct  2 13:57 dm-uuid-LVM-Lgv4fdmiLAyXaqNZLyUZgUwg7mdSoNVAkj1l3zQ8S7WH2AILanFSbeCId5OsFrXV -> ../../dm-0
lrwxrwxrwx 1 root root  10 Oct  2 13:57 lvm-pv-uuid-GroJzt-f64i-aElM-q0t2-iCxZ-dhj2-2Smyih -> ../../vdb1

(k)inaddy at kbionic:~$ ls -lah /dev/disk/by-id
total 0
drwxr-xr-x 2 root root 100 Oct  2 14:15 .
drwxr-xr-x 7 root root 140 Oct  2 14:15 ..
lrwxrwxrwx 1 root root  10 Oct  2 14:15 dm-name-vgtest-lvtest -> ../../dm-0
lrwxrwxrwx 1 root root  10 Oct  2 14:15 dm-uuid-LVM-Lgv4fdmiLAyXaqNZLyUZgUwg7mdSoNVAkj1l3zQ8S7WH2AILanFSbeCId5OsFrXV -> ../../dm-0
lrwxrwxrwx 1 root root  10 Oct  2 14:15 lvm-pv-uuid-GroJzt-f64i-aElM-q0t2-iCxZ-dhj2-2Smyih -> ../../vdb1

Same issue happened even in Bionic and Xenial:

(k)inaddy at kxenial:~$ sudo ls -lah1 /dev/disk/by-id
total 0
drwxr-xr-x 2 root root 100 Oct  2 14:24 .
drwxr-xr-x 6 root root 120 Oct  2 14:24 ..
lrwxrwxrwx 1 root root  10 Oct  2 14:24 dm-name-vgtest-lvtest -> ../../dm-0
lrwxrwxrwx 1 root root  10 Oct  2 14:24 dm-uuid-LVM-Lgv4fdmiLAyXaqNZLyUZgUwg7mdSoNVAkj1l3zQ8S7WH2AILanFSbeCId5OsFrXV -> ../../dm-0
lrwxrwxrwx 1 root root  10 Oct  2 14:24 lvm-pv-uuid-GroJzt-f64i-aElM-q0t2-iCxZ-dhj2-2Smyih -> ../../vdb1
----

So, in theory, this bug has always been present.. but I got reports
saying "it worked" before, so Im trying to check what could have changed
grub-mkdevicemap behavior. I tested bionic and was able to reproduce the
issue. Testing xenial installer now and then disco, if needed...

** Description changed:

+ Comment #26 has the TL;DR version of the problem.
+ 
+ [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:

  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 grub-installer 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:
  New
Status in grub-installer package in Ubuntu:
  Triaged
Status in debian-installer source package in Eoan:
  New
Status in grub-installer source package in Eoan:
  Triaged
Status in debian-installer package in Debian:
  New

Bug description:
  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