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.
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:
--no-rs-codes
and hope the result will be just small enough to fit.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.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...
User contributions licensed under CC BY-SA 3.0