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

[Rafael David Tinoco]

After Andreas and I compared side by side the 2 "set -x" outputs, we
discovered what is happening.

https://pastebin.ubuntu.com/p/WyvnChrqBQ/

And "/dev/vda1" is being caught instead of "/dev/vda", as it happens to
"/dev/sda" (instead of getting "/dev/sda1"). This logic comes a bit
above that execution output:

https://pastebin.ubuntu.com/p/ZRNHfnmJ4P/

And this is why andreas talks about "grub-mkdevicemap" here, and he is
triggered by the "head -n1"  usage:

17:10 <rafaeldtinoco> instead of /dev/vda
17:10 <andreas> cyphermox: I wonder about this head -n1
17:10 <andreas> default_bootdev_os="$($chroot $ROOT grub-mkdevicemap --no-floppy -m - | head -n1 | cut -f2)"
17:10 <andreas> if it's making an assumption
17:10 <cyphermox> well, usually hd0 is really what you want
17:10 <cyphermox> and it works for sda
17:10 <cyphermox> I mean, what is so different about virtio?
17:10 <andreas> yeah, I don't have the raw output in the sda case

We then tested both, virtio and non-virtio installations and saw that,
for the SCSI case:

bash-5.0# grub-mkdevicemap --no-floppy -m -
(hd0)	/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0
(hd1)	/dev/disk/by-id/lvm-pv-uuid-oKqHJy-nRnC-nLm3-AuxT-FmpR-CCox-ltoWeB

the disk is listed first (as hd0) in grub-mkdevicemap, while in the
VIRTIO case, it is listed as SECOND (explaining why /dev/mapper was
generated in subsequent wrong logic bellow).

https://pastebin.ubuntu.com/p/hCNPH8GjgS/

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