| 2019-07-31 12:51:56 |
Paride Legovini |
bug |
|
|
added bug |
| 2019-09-24 16:11:08 |
Paride Legovini |
tags |
|
rls-ee-incoming |
|
| 2019-09-25 15:37:00 |
Dimitri John Ledkov |
bug task added |
|
grub-installer (Ubuntu) |
|
| 2019-09-25 15:41:34 |
Launchpad Janitor |
debian-installer (Ubuntu): status |
New |
Confirmed |
|
| 2019-09-25 15:41:34 |
Launchpad Janitor |
grub-installer (Ubuntu): status |
New |
Confirmed |
|
| 2019-09-25 15:49:04 |
Dimitri John Ledkov |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918590 |
|
| 2019-09-25 15:49:04 |
Dimitri John Ledkov |
bug task added |
|
debian-installer (Debian) |
|
| 2019-09-25 15:52:36 |
Dimitri John Ledkov |
grub-installer (Ubuntu): status |
Confirmed |
Fix Committed |
|
| 2019-09-25 16:33:35 |
Dimitri John Ledkov |
grub-installer (Ubuntu): importance |
Undecided |
Critical |
|
| 2019-09-25 17:05:17 |
Launchpad Janitor |
grub-installer (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2019-09-25 21:21:55 |
Brian Murray |
debian-installer (Ubuntu): status |
Confirmed |
Invalid |
|
| 2019-09-26 01:13:33 |
Bug Watch Updater |
debian-installer (Debian): status |
Unknown |
New |
|
| 2019-09-26 10:57:53 |
Dimitri John Ledkov |
grub-installer (Ubuntu): status |
Fix Released |
Triaged |
|
| 2019-09-26 10:57:57 |
Dimitri John Ledkov |
debian-installer (Ubuntu): status |
Invalid |
New |
|
| 2019-09-26 17:32:35 |
Brian Murray |
nominated for series |
|
Ubuntu Eoan |
|
| 2019-09-26 17:32:35 |
Brian Murray |
bug task added |
|
debian-installer (Ubuntu Eoan) |
|
| 2019-09-26 17:32:35 |
Brian Murray |
bug task added |
|
grub-installer (Ubuntu Eoan) |
|
| 2019-09-26 18:01:06 |
Ubuntu QA Website |
tags |
rls-ee-incoming |
iso-testing rls-ee-incoming |
|
| 2019-09-26 19:21:22 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2019-09-27 14:04:59 |
Andreas Hasenack |
attachment added |
|
grub-install-virtio-case.log https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/+attachment/5291785/+files/grub-install-virtio-case.log |
|
| 2019-09-27 14:05:19 |
Andreas Hasenack |
attachment added |
|
grub-install-novirtio-case.log https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/+attachment/5291786/+files/grub-install-novirtio-case.log |
|
| 2019-09-28 12:41:30 |
Francis Ginther |
tags |
iso-testing rls-ee-incoming |
id-5d8cf66b49519e737f6e6856 iso-testing rls-ee-incoming |
|
| 2019-10-01 21:19:56 |
Andreas Hasenack |
attachment added |
|
disk-by-id.png https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/+attachment/5293325/+files/disk-by-id.png |
|
| 2019-10-01 21:20:25 |
Andreas Hasenack |
attachment added |
|
which-dev-is-first.png https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/+attachment/5293326/+files/which-dev-is-first.png |
|
| 2019-10-02 14:31:57 |
Rafael David Tinoco |
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. |
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. |
|
| 2019-10-02 14:32:09 |
Rafael David Tinoco |
description |
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. |
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. |
|
| 2019-10-03 12:38:18 |
Rafael David Tinoco |
bug task deleted |
grub-installer (Ubuntu Eoan) |
|
|
| 2019-10-03 12:38:24 |
Rafael David Tinoco |
bug task deleted |
debian-installer (Ubuntu Eoan) |
|
|
| 2019-10-03 12:38:41 |
Rafael David Tinoco |
bug task added |
|
lvm2 (Ubuntu) |
|
| 2019-10-03 12:38:55 |
Rafael David Tinoco |
grub-installer (Ubuntu): status |
Triaged |
In Progress |
|
| 2019-10-03 12:38:59 |
Rafael David Tinoco |
lvm2 (Ubuntu): status |
New |
In Progress |
|
| 2019-10-03 12:39:01 |
Rafael David Tinoco |
debian-installer (Ubuntu): status |
New |
In Progress |
|
| 2019-10-03 12:39:04 |
Rafael David Tinoco |
lvm2 (Ubuntu): importance |
Undecided |
Critical |
|
| 2019-10-03 12:39:06 |
Rafael David Tinoco |
debian-installer (Ubuntu): importance |
Undecided |
Critical |
|
| 2019-10-03 12:39:08 |
Rafael David Tinoco |
debian-installer (Ubuntu): assignee |
|
Rafael David Tinoco (rafaeldtinoco) |
|
| 2019-10-03 12:39:10 |
Rafael David Tinoco |
grub-installer (Ubuntu): assignee |
|
Rafael David Tinoco (rafaeldtinoco) |
|
| 2019-10-03 12:39:11 |
Rafael David Tinoco |
lvm2 (Ubuntu): assignee |
|
Rafael David Tinoco (rafaeldtinoco) |
|
| 2019-10-03 12:39:29 |
Rafael David Tinoco |
bug task added |
|
grub2 (Ubuntu) |
|
| 2019-10-03 12:39:41 |
Rafael David Tinoco |
bug task deleted |
grub-installer (Ubuntu) |
|
|
| 2019-10-03 12:39:44 |
Rafael David Tinoco |
grub2 (Ubuntu): status |
New |
In Progress |
|
| 2019-10-03 12:39:46 |
Rafael David Tinoco |
grub2 (Ubuntu): importance |
Undecided |
Critical |
|
| 2019-10-03 12:39:48 |
Rafael David Tinoco |
grub2 (Ubuntu): assignee |
|
Rafael David Tinoco (rafaeldtinoco) |
|
| 2019-10-08 02:49:54 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/grub2/+git/grub2/+merge/373792 |
|
| 2019-10-08 02:59:34 |
Rafael David Tinoco |
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. |
[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. |
|
| 2019-10-08 03:02:32 |
Rafael David Tinoco |
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).
[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. |
[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. |
|
| 2019-10-08 03:21:16 |
Rafael David Tinoco |
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. |
[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. |
|
| 2019-10-08 10:43:12 |
Dimitri John Ledkov |
grub2 (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2019-10-08 10:56:55 |
Rafael David Tinoco |
debian-installer (Ubuntu): status |
In Progress |
Invalid |
|
| 2019-10-08 10:56:59 |
Rafael David Tinoco |
lvm2 (Ubuntu): status |
In Progress |
Invalid |
|
| 2019-10-08 10:57:01 |
Rafael David Tinoco |
debian-installer (Ubuntu): assignee |
Rafael David Tinoco (rafaeldtinoco) |
|
|
| 2019-10-08 10:57:03 |
Rafael David Tinoco |
lvm2 (Ubuntu): assignee |
Rafael David Tinoco (rafaeldtinoco) |
|
|
| 2019-10-08 10:57:19 |
Rafael David Tinoco |
debian-installer (Ubuntu): importance |
Critical |
Undecided |
|
| 2019-10-08 10:57:21 |
Rafael David Tinoco |
lvm2 (Ubuntu): importance |
Critical |
Undecided |
|
| 2019-10-09 07:51:35 |
Launchpad Janitor |
grub2 (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2020-06-17 22:57:43 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~mwhudson/grub-installer/+git/grub-installer/+merge/385962 |
|
| 2020-06-17 23:00:56 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~mwhudson/grub-installer/+git/grub-installer/+merge/385962 |
|
|
