Hi list,
since SeaBIOS 1.14.0 (QEMU 5.1) VMs with LVM root disks spanning more than one PV fail to boot, if only the first is set as bootable. I believe this is due to the changes in SeaBIOS only initializing drives marked as 'bootable' by QEMU.
One fix is to mark all disks containing root data as bootable, but existing setups will still break on upgrade (where only the disk containing the bootloader is marked). This is not ideal.
Discovered by a user in our bugtracker: https://bugzilla.proxmox.com/show_bug.cgi?id=3011
and verified by installing Ubuntu 20.04 w/ LVM and GRUB on virtio-scsi, then expanding the LV to a second disk.
I found that just reverting SeaBIOS to 1.13.0 makes it work again, same guest install, even with QEMU 5.1.
Is this intended behaviour? A bug in GRUB? Any fix or workaround?
~ Stefan
Dear Stefan,
Am 21.09.20 um 15:10 schrieb Stefan Reiter:
since SeaBIOS 1.14.0 (QEMU 5.1) VMs with LVM root disks spanning more than one PV fail to boot, if only the first is set as bootable. I believe this is due to the changes in SeaBIOS only initializing drives marked as 'bootable' by QEMU.
One fix is to mark all disks containing root data as bootable, but existing setups will still break on upgrade (where only the disk containing the bootloader is marked). This is not ideal.
Discovered by a user in our bugtracker: https://bugzilla.proxmox.com/show_bug.cgi?id=3011
and verified by installing Ubuntu 20.04 w/ LVM and GRUB on virtio-scsi, then expanding the LV to a second disk.
I found that just reverting SeaBIOS to 1.13.0 makes it work again, same guest install, even with QEMU 5.1.
Is this intended behaviour? A bug in GRUB? Any fix or workaround?
As SeaBIOS 1.13.0 works and SeaBIOS 1.14.0 does not, please bisect the issue, and tell us the commit introducing the regression.
Kind regards,
Paul
On 21/09/2020 15:44, Paul Menzel wrote:
Dear Stefan,
Am 21.09.20 um 15:10 schrieb Stefan Reiter:
since SeaBIOS 1.14.0 (QEMU 5.1) VMs with LVM root disks spanning more than one PV fail to boot, if only the first is set as bootable. I believe this is due to the changes in SeaBIOS only initializing drives marked as 'bootable' by QEMU.
One fix is to mark all disks containing root data as bootable, but existing setups will still break on upgrade (where only the disk containing the bootloader is marked). This is not ideal.
Discovered by a user in our bugtracker: https://bugzilla.proxmox.com/show_bug.cgi?id=3011
and verified by installing Ubuntu 20.04 w/ LVM and GRUB on virtio-scsi, then expanding the LV to a second disk.
I found that just reverting SeaBIOS to 1.13.0 makes it work again, same guest install, even with QEMU 5.1.
Is this intended behaviour? A bug in GRUB? Any fix or workaround?
As SeaBIOS 1.13.0 works and SeaBIOS 1.14.0 does not, please bisect the issue, and tell us the commit introducing the regression.
Bisected for virtio-blk drives:
2f4d068645 "virtio: Do not init non-bootable devices"
...as expected. Also, untested, but I would strongly assume:
d6bdb85eb0 "virtio-scsi: skip initializing non-bootable devices"
is the equivalent for virtio-scsi devices, and
76551856b2 "nvme: skip initializing non-bootable devices"
for NVMe.
Kind regards,
Paul
On Mon, Sep 21, 2020 at 03:10:51PM +0200, Stefan Reiter wrote:
Hi list,
since SeaBIOS 1.14.0 (QEMU 5.1) VMs with LVM root disks spanning more than one PV fail to boot, if only the first is set as bootable. I believe this is due to the changes in SeaBIOS only initializing drives marked as 'bootable' by QEMU.
One fix is to mark all disks containing root data as bootable, but existing setups will still break on upgrade (where only the disk containing the bootloader is marked). This is not ideal.
Discovered by a user in our bugtracker: https://bugzilla.proxmox.com/show_bug.cgi?id=3011
and verified by installing Ubuntu 20.04 w/ LVM and GRUB on virtio-scsi, then expanding the LV to a second disk.
I found that just reverting SeaBIOS to 1.13.0 makes it work again, same guest install, even with QEMU 5.1.
Is this intended behaviour?
Yes, it is intentional. Save some memory and speed up boot by not initializing disks which are not needed.
Any fix or workaround?
- Assign a bootindex to all drives needed, as you already figured, or
- Start qemu with -boot strict=off, or
- Install guest with a /boot filesystem on a normal partition. Which is IMHO a good idea anyway for robustness reasons, you can use all lvm features without worrying whenever grub is able to cope or not.
take care, Gerd
-
Gerd Hoffmann -
Paul Menzel -
Stefan Reiter