4

On a Debian 10 (buster) system I've just tried to install the recent grub-pc update and for the first time I received this error:

Installing for i386-pc platform.
grub-install: warning: your core.img is unusually large.  It won't fit in the embedding area.
grub-install: error: embedding is not possible, but this is required for RAID and LVM install.

This was repeated for each of the disks that form my /boot/ partition.

This installation is very old; it was installed in 2006 and the disks have been transplanted into new hardware several times and the OS kept up to date since then.

As a consequence, the setup for /boot is rather antiquated but should still work. There are four HDDs identically partitioned:

$ sudo fdisk -u -l /dev/sda
Disk /dev/sda: 298.1 GiB, 320069031424 bytes, 625134827 sectors
Disk model: ST3320620AS     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot   Start       End   Sectors  Size Id Type
/dev/sda1  *         63    514079    514017  251M fd Linux raid autodetect
/dev/sda2        514080   6393869   5879790  2.8G fd Linux raid autodetect
/dev/sda3       6393870 625121279 618727410  295G fd Linux raid autodetect

So this is an old style MBR with first partition starting 63 sectors in. The first partition of each disk is put into a 4-way RAID-1 that is md0 and that is my /boot:

$ sudo mdadm --detail /dev/md0                                                      
/dev/md0:              
           Version : 0.90            
     Creation Time : Sun Jun  4 08:18:05 2006                                       
        Raid Level : raid1                                                          
        Array Size : 256896 (250.88 MiB 263.06 MB)
     Used Dev Size : 256896 (250.88 MiB 263.06 MB)
      Raid Devices : 4
     Total Devices : 4                                                              
   Preferred Minor : 0                                                              
       Persistence : Superblock is persistent

   Update Time : Thu Mar  4 06:52:36 2021                                       
         State : clean
Active Devices : 4



Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0


Consistency Policy : resync


          UUID : 78cf4169:e31908f4:e667021c:582159fb
        Events : 0.2479

Number   Major   Minor   RaidDevice State
   0       8       49        0      active sync   /dev/sdd1
   1       8        1        1      active sync   /dev/sda1
   2       8       17        2      active sync   /dev/sdb1
   3       8       33        3      active sync   /dev/sdc1

This md array has metadata version 0.90 intentionally so that it can be booted by grub, as it dates from a time when grub had no md support; the 0.90 metadata version puts the metadata at the end of the partition so grub should just be able to read each partition as if it weren't software RAID.

grub was installed to the base disk device, i.e. to each of /dev/sd{a,b,c,d}. Subsequent upgrades of the grub-pc package seem to know to run grub-install /dev/sda and then the same for sd{b,c,d}.

It is only today that this error has appeared.

Is this system now unbootable? It looks like an error condition so I assume that the new version of grub has not actually been installed.

I am confused why it says that it needs to do something for RAID/LVM, when no such support is required to boot this system.

Has grub grown in size for some reason and now does not fit in the first 63 sectors of each disk? I know the convention is now to start partitions at 1MB but as I say, this is a very old install that has always worked.

What is the easiest way to get this grub update installed? If I need to delete those first partitions and start them at 1MB I can easily enough do that, though I'd like to have some assurance that is actually the issue before I go to that length.

The verbose output of grub-install -v /dev/sda is enormous and then ends the same way. I could not spot anything useful in it but I will include it if anyone thinks it necessary.

grifferz
  • 808

1 Answers1

4

Has grub grown in size for some reason and now does not fit in the first 63 sectors of each disk? I know the convention is now to start partitions at 1MB but as I say, this is a very old install that has always worked.

Specifically, the latest grub2 package on Debian Buster and Bullseye includes a massive changelog of patches, a lot of which involve adding missing checks (e.g. buffer overflows, NULL dereferences) which were absent in the previous build.

Some of them affect the configuration parser, the grub.cfg script executor, and the partition table scanner, all of which which are included in the core image that gets installed in the post-MBR gap. This increases the code size slightly.

But with such a small margin, you could even be affected by a different compiler outputting different code for the same source or by the distribution changing compiler flags to add runtime safety checks.

If you keep updating the system, that in itself implies the software keeps changing and the philosophy "it can't stop working because it has always worked" goes straight out of the window.

This md array has metadata version 0.90 intentionally so that it can be booted by grub, as it dates from a time when grub had no md support; the 0.90 metadata version puts the metadata at the end of the partition so grub should just be able to read each partition as if it weren't software RAID.

But GRUB 2 does have md support now, which means if it detects that /boot is on an mdraid array then it will include an mdraid driver in its core image – even if the array happens to be 0.90 RAID1. This increases the core image size.

(mdraid support doesn't just mean being able to skip over the metadata – it means being able to read from raid0/5/6 arrays, recognizing spare disks, and so on.)

On current Debian Buster, a completely barebones core.img with just the GRUB 2 kernel (no modules nor configuration) is 39 sectors1. With the default set of 'biosdisk', 'part_msdos', 'search_fs_uuid', and 'ext2' modules it's 54 sectors – and if you add the 'mdraid09' module on top, that's already 64 sectors and your disk only has 62 sectors to spare (the MBR bootsector at position 0 is not included).

1 Measured using grub-mkimage -O i386-pc -p /boot [modules] | wc -c.

Package Kernel + 5 modules Size on disk
Stretch 2.02~beta3-5+deb9u2 31 186 bytes 61 (~60.9) sectors
Buster 2.02+dfsg1-20+deb10u2 32 061 bytes 63 (~62.6) sectors
Buster 2.02+dfsg1-20+deb10u4 32 729 bytes 64 (~63.9) sectors
Bullseye 2.04-15 31 902 bytes 63 (~62.3) sectors
Bullseye 2.04-16 33 072 bytes 65 (~64.6) sectors
Arch Linux 2:2.04-10 32 131 bytes 63 (~62.75) sectors

grub-install also needs to add a short 2-line config pointing the GRUB kernel towards your real /boot location, but let's say this fits in the remaining 1⁄4th of a sector.

On BIOS systems, grub-install also uses some extra space for Reed-Solomon error correcting codes, to allow booting in case one of those sectors is damaged – I can't find information on how much space this uses, but it's at least a few sectors.

So you have a few options:

  • Move your /boot partition to another offset, such as sector 1024 or 2048.
  • Try to install with --no-rs-codes and hope the result will be just small enough to fit.
  • Build a custom GRUB core image which doesn't include mdraid09 (possibly grub-install --skip-fs-probe --modules=..., but more likely using grub-mkimage), pretending that it's still 2006 and GRUB doesn't have md support yet.
grawity
  • 501,077