grub-install: error: embedding is not possible, but this is required for RAID and LVM install

1

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.

debian
grub2
debian-buster
asked on Super User Mar 4, 2021 by grifferz

2 Answers

1

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.
answered on Super User Mar 4, 2021 by user1686 • edited Mar 4, 2021 by user1686
0

Damn, I have the exact same problem with my RAID1 /boot partition with sda/sdb.

# fdisk -l /dev/sda
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk model: WDC WD2500AAJS-0
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: 0x0007d768

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *         63   1953125   1953063 953.7M fd Linux raid autodetect
/dev/sda3       4305420 488392064 484086645 230.9G fd Linux raid autodetect

It's not too long ago when I was able to recover from /boot out of disk space when upgrading from Stretch to Buster. And now this :(

Sorry I'm bit thick on the possible alternatives that user1686 offered as solution. Specially the moving boot partition sounded interesting. Could you please elaborate them more or the possible creating a new smaller boot array/partition that Mr. grifferz commented.

I do have some 1GB of unallocated space available from that earlier exercise with the boot partition. I wonder if I could utilize that someway perhaps?

Command (m for help): F
Unpartitioned space /dev/sda: 1.1 GiB, 1206319104 bytes, 2356092 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

    Start       End Sectors  Size
  1953792   4305419 2351628  1.1G
488392704 488397167    4464  2.2M

Somehow reinstalling the system does not feel appealing at all...

answered on Super User Mar 4, 2021 by jaMO

User contributions licensed under CC BY-SA 3.0