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 Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
