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@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@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@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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1838525 Title: LVM setup fails to install grub on virtio storage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
