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

[Steve McIntyre]

On Mon, May 01, 2023 at 02:16:46PM +0200, Pascal Hambourg wrote:
>On Sun, 30 Apr 2023 17:37:13 -0700 Vagrant Cascadian <vagrant at debian.org>
>
>> > I ran d-i in rescue mode to get into the system, simply ran
>> > dpkg-reconfigure grub-pc (which will run grub-install *and*
>> > update-grub), and the system now boots again. It looks like what we're
>> > seeing might be a limit in what's built in to the core image by
>> > default. grub-pc is deliberately designed to build minimal images
>> > here, to minimise the chance of the image being too large to embed.
>
>I wonder how much this policy is still relevant for PC platforms. Originally
>the core image was designed to fit in the "post-MBR gap" whose typical size
>was 62 sectors (31 KiB) because the first partition used to start at sector
>63. But nowadays a 1-MiB post-MBR gap has been the standard for many years. I
>do not remember when this was introduced in fdisk and other Linux partition
>editors, but Windows 7 installer had it. Besides, I observe that the size of
>the core.img built for LVM+ext4 on my bullseye system is 34 KiB so it would
>not even fit in a 31-KiB post-MBR gap.

Even the 1MB post-MBR gap can be a struggle AIUI. BIOS booting is
fragile as hell, and there have been lots of discussions over the
years on the upstream list about the problems of embedding...

>The minimal core image policy is even less relevant for EFI images, as the
>EFI partition size is usually several MB so a few more kB won't hurt. I
>cannot tell for other platforms.

Nod, exactly. To be honest, EFI typically makes things *so* much more
sane here for exactly these reasons. Then again you get to see more
issues with broken firmware. :-/

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray