Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Vagrant Cascadian]

On 2023-05-01, Pascal Hambourg wrote:
> On Sun, 30 Apr 2023 17:37:13 -0700 Vagrant Cascadian 
> <vagrant at debian.org> wrote:
>> On 2023-05-01, Steve McIntyre wrote:
>> "ls" from the grub prompt did not show the other disk...
>> ...until I made the second disk bootable from libvirt!
>> Then grub now sees both disks, and boots fine!
>> So this is possibly a quirk of the way libvirt exposes boot disks.
>
> Apparently. GRUB can only see disks exposed by the BIOS/UEFI/other 
> platform firmware. There are other known situations where a given 
> firmware may not expose some disks, including but not limited to:
> - disks connected to a SATA controller card without a BIOS expansion ROM
> - unsupported media types: USB other than the boot disk, NVMe, SD/MMC...
>
> The UEFI firmware on an old Intel board only had EFI drivers for the 
> SATA controller in IDE mode and lacked EFI drivers for AHCI and USB. It 
> has been reported that more recent boards had support for NVMe only in 
> EFI mode, not in legacy mode.
...
>> Re-running grub-install /dev/vda from debian-installer rescue mode did
>> *not* fix the issue for me
>
> Because there were two issues preventing GRUB from seeing the new PV:
> - the disk was not exposed by libvirt BIOS
> - the disk had an unsupported GPT partition scheme
>
> grub-install fixed only the second issue. Making the disk "bootable" in 
> libvirt was required to fix the first issue.
>
>> (though, now I am curious if dpkg-reconfigure
>> grub-pc would do anything more?)
>
> As Steve wrote, dpkg-reconfigure also runs update-grub to rebuild 
> grub.cfg. AFAIK here the only difference with the old grub.cfg is 
> additional "insmod part_gpt" commands to load GPT support, but the 
> module must already be embedded in the core image so this addition is 
> not required.

Well, in my original bug report, grub.cfg did contain both:

  insmod part_gpt
  insmod part_msdos

Although, maybe it is possible that was generated after running
update-grub...

Even though a perfectly reasonable stance is just to use a split /boot
partition, I may keep experimenting with this to get greater confidence
we really understand what went wrong. :)

live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-grub-devel/attachments/20230501/a8c030a1/attachment.sig>