From 4bd2f59773bec11ad7be1ced5b49edbf44d711f2 Mon Sep 17 00:00:00 2001 From: Vladimir Serbinenko <phco...@gmail.com> Date: Tue, 10 Nov 2020 20:23:56 +0100 Subject: [PATCH 2/2] Document new limitations on MBR gap support
Signed-off-by: Vladimir Serbinenko <phco...@gmail.com> --- docs/grub.texi | 43 ++++++++++++++++++++++++++++++++----------- 1 file changed, 32 insertions(+), 11 deletions(-) diff --git a/docs/grub.texi b/docs/grub.texi index 37f7ce7da..d6ce0999f 100644 --- a/docs/grub.texi +++ b/docs/grub.texi @@ -829,25 +829,46 @@ four primary partitions and additional logical partitions. With this partition table format, there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (called by various names, such as the "boot track", "MBR gap", or "embedding area", and -which is usually at least 31 KiB), or the core image can be installed in a +which is usually at least 1000 KiB), or the core image can be installed in a file system and a list of the blocks that make it up can be stored in the first sector of that partition. -Each of these has different problems. There is no way to reserve space in +Modern tools usually leave MBR gap of at least 1023 KiB. This amount is +sufficient to cover most configurations. Hence this value is recommended +by the GRUB team. + +Historically many tools left only 31 KiB of space. This is not enough to +parse reliably difficult structures like btrfs, zfs, raid or lvm, or to +use difficult disk access methods like ahci. Hence GRUB will warn if attempted +to install into small MBR gap except in a small number of configurations +that were grandfathered. The grandfathered config must: + +* use biosdisk as disk access module for @file{/boot} +* not use any additional partition maps to access @file{/boot} +* @file{/boot} must be on one of following filesystems: + * AFFS, AFS, BFS, cpio, newc, odc, ext2/3/4, FAT, exFAT, + F2FS, HFS, uncompressed HFS+, ISO9660, JFS, Minix, Minix2, Minix3, NILFS2, + NTFS, REISERFS, ROMFS, SFS, tar, UDF, UFS1, UFS2, XFS + +MBR gap has few technical problems. There is no way to reserve space in the embedding area with complete safety, and some proprietary software is known to use it to make it difficult for users to work around licensing -restrictions; and systems are sometimes partitioned without leaving enough -space before the first partition. On the other hand, installing to a -filesystem means that GRUB is vulnerable to its blocks being moved around by -filesystem features such as tail packing, or even by aggressive fsck -implementations, so this approach is quite fragile; and this approach can -only be used if the @file{/boot} filesystem is on the same disk that the -BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive -numbers. +restrictions. GRUB works it around by detecting sectors by other software and +avoiding them and protecting its own sectors using Reed-Solomon encoding. + +GRUB team recommends having MBR gap of at least 1000 KiB + +Should it be not possible GRUB has support for a fallback solution which is +heavily recommended against. Installing to a filesystem means that GRUB is +vulnerable to its blocks being moved around by filesystem features such as +tail packing, or even by aggressive fsck implementations, so this approach +is quite fragile; and this approach can only be used if the @file{/boot} +filesystem is on the same disk that the BIOS boots from, so that GRUB does +not have to rely on guessing BIOS drive numbers. The GRUB development team generally recommends embedding GRUB before the first partition, unless you have special requirements. You must ensure that -the first partition starts at least 31 KiB (63 sectors) from the start of +the first partition starts at least 1000 KiB (2000 sectors) from the start of the disk; on modern disks, it is often a performance advantage to align partitions on larger boundaries anyway, so the first partition might start 1 MiB from the start of the disk. -- 2.20.1 -- Regards Vladimir 'phcoder' Serbinenko _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel