On Mon, May 01, 2023 at 02:16:46PM +0200, Pascal Hambourg wrote: >On Sun, 30 Apr 2023 17:37:13 -0700 Vagrant Cascadian <vagr...@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. st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray