GRUB2 core.img not fitting between MBR and sector 63

[chrismurphy]

There are a number of posts lately with users who have msdos (MBR) disklabels, and partition 1 starts at sector 63. This appears to be common with Windows XP installations. I just tried partitioning a VDI with Vista 32-bit and it starts partition 1 with sector 2048.

A starting sector of 63 frequently, but not always, causes GRUB2 to complain:

Single disk example:

[root@localhost /]# grub2-install --no-floppy --recheck /dev/sda
/sbin/grub2-setup: warn: Your embedding area is unusually small. core.img won't fit in it..
/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
/sbin/grub2-setup: error: will not proceed with blocklists.
[root@localhost /]#

Two disk example:

[root@donk ~]# grub2-install --no-floppy --recheck /dev/sda
/sbin/grub2-setup: warn: Your core.img is unusually large. It won't fit in the embedding area..
/sbin/grub2-setup: error: embedding is not possible, but this is required for cross-disk install.

It would be nice if there were a way to deal with these legacy situations more elegantly than asking users to partition with linux fdisk with a start of > sector 63 and reinstall Windows XP.

Or should this be suggested on grub-devel?

[sonoran]

There are several ways of dealing with grub2 in those circumstances:

1. create a bios boot partition of 2 MiB - this can be anywhere on disc < 2TB, but is recommended
to be near the start of the disc, and before a /boot partition.

2. install grub2 to /boot and chainload it from legacy grub

After playing around with Fedora 16's grub2 on the mbr of one of my discs, I reinstalled it to the
/boot directory and went back to Arch's legacy grub. For some reason this setup is not
recommended, but it works here.

In Arch's menu.lst I have:

title fedora 16
root (hd0,0)
chainloader +1

the same way one would boot windows.

I am planning to convert to syslinux one of these days.

[chrismurphy]

Option 1 is for GPT disks, not MBR disks. Since this is Windows XP, it's an MBR situation for sure. (And even most Vista and Windows 7 installations are still MBR based). The 'BIOS Boot' partition type is GPT specific. It doesn't exist on MBR disks.

Option 2 is something I thought of but it's painful for regular joe user just trying to figure out one GRUB let alone two. (Seriously I had major anger management issues with Grub Legacy, and then GRUB2 was a whole order of magnitude beyond that level of near insanity.)

So I'm trying to think of whether the current behavior is the only behavior possible, and if there's a better way Fedora should behave with a (hopefully nice) GUI installation for people who still have XP on their systems.

[DBelton]

About the only time you may run into grub2 not being able to fit in the space between the MBR and the first sector is if you have software or firmware RAID.

If there isn't room for grub2 in the 32k that is available between the MBR and the first partition, then your only options would be to align your first partition on a MB boundary (which would move the start sector to 2048), or convert to GUID partition table (GPT) (since you are using XP on that drive, GUID (GPT) is out of the question, since XP doesn't recognize them)

Or you can keep using legacy grub, and remove grub2 completely.

It's mentioned in the Fedora common bugs what causes this and what you can do about it:

Boot sometimes fails when installing to a pre-existing partition layout with complex boot configuration (e.g. software or firmware RAID-1)

link to this item - Bugzilla: #737508

Versions of Fedora prior to Fedora 16, and many other operating systems, will by default use the MS-DOS disk label format, and create the first partition on a hard disk at sector 63. This leaves a gap of 32KiB between the MBR and the first partition. This is the space into which the core of the system bootloader must be installed on an MS-DOS labelled disk.

The core part of Fedora 16's bootloader, grub2, may not fit into this 32KiB space, if the required configuration to boot the system is complex. One known problematic case comes when the /boot partition is on a software or firmware (not hardware) RAID-1 device. In this case, the core grub2 image must include RAID support, and the inclusion of this makes the core image larger than 32KiB in size.

In more 'straightforward' cases, grub2's core image is smaller than 32KiB in size, so this bug will often not be encountered. Also, if you install Fedora 16 in such a way that the target drive is re-formatted, Fedora will use a GPT disk label and create a 1MiB 'BIOS Boot' partition. With the GPT disk label format, the bootloader core must reside on such a 'BIOS Boot' partition, and the 1MB size provides comfortably enough room for any necessary grub2 core image. The bug only occurs when installing Fedora 16 to an existing partition layout (and hence also when upgrading an existing configuration) which requires a complex grub2 core image.

When you encounter the bug, Fedora's installer may warn you that bootloader installation failed, but the installation will complete. However, the installed system will fail to boot. If you examine the installer logs you may find the message grub2-setup: warn: your core.img is unusually large, it won't fit in the embedding area.

The safest workaround for the issue is to resize the first disk on the partition so that there is more empty space in front of it. A very small change will be sufficient - just having the partition start at 1MiB rather than 32KiB should suffice. Some partition types can be non-destructively resized from the beginning in this way, but in some cases it may be necessary to archive all the data on the partition, delete it, re-create it with a slightly later starting sector, and then restore the data. If you have to do this, you will likely wish to note the partition's UUID and partition label before destroying the partition, and ensure that they match when re-creating it. There are parameters you can pass to the various mkfs commands to force the UUID of the created partition: for instance, the parameter is -U for the mke2fs command.

An alternative workaround may be to manually install grub-legacy (rather than grub2) as the bootloader. However, the use of grub-legacy on Fedora 16 is not officially supported, and grub-legacy may well be removed entirely from future Fedora releases, so this is likely to be feasible only in the short term.

You may also compare Arch Linux's note on the same issue.

[chrismurphy]

Hi - thanks for the response and the clarification.

It's just that two Windows XP users, and I have no indication either of them are using RAID based on the boot info script results, definitely have start sectors of 63 for the first partition, and their /boot/grub2/core.img is bigger than 61 sectors. So it won't fit and --force isn't working in at least one case either.

It seems to me maybe an inquiry with the anaconda team might be warranted to retain or use Grub Legacy in any case where a start sector for the first partition is less than some value. Even if it were 100 it would be fine for GRUB2.

I'm surprised this problem doesn't come up more frequently.

[DBelton]

I have 2 machines here that are dual boot, Windows XP and Fedora 16, and the grub2 core.img stuff fits fine in the space between the MBR and the first partition (starting partition is at sector 63)

I wonder if you could put grub2 on your second drive (or move it to be the first drive) and format it GPT with a BIOS_BOOT partition, and to start Windows, map the drives so that Windows sees it's drive as the first one.

[chrismurphy]

What is the size of you /boot/grub2/core.img?

In the case where there are two hard drives, the original idea was to have GRUB2 in BIOT Boot, since it's a GPT disk. The problem that person is running into is getting Windows to boot. The grub.cfg has a drivemap -s command to flip around (hd0) for (hd1) virtually (I don't understand it) and apparently the BIOS isn't cooperating and it isn't working. Hence the logic of trying to install GRUB2 on the drive that contains Windows and then running into the core.img size problem.

Anyway, that's a different thread already in play. I'm just surprised there's a difference in core.img from computer to computer.

In the other case, it looks like --force did work. It still complained as if it didn't work but it did create the blocklist and does boot the computer.

[DBelton]

On the machine that is dual booting Windows XP, my core.img file is less than 30k

-rw-r--r--. 1 root root  29221 Oct  5 18:09 core.img

[chrismurphy]

That's the smallest one I've seen so far. Mine is 34K and the ones from people having this issue with XP are 31K+.

[DBelton]

well, I just ran into the very same issue on a machine that was previously working correctly

What happened:

Booted to Windows XP and updated the system. Something updated or I did something stupid that stepped on grub2 in the MBR and it wouldn't boot..

So.. Pulling out my trusty Fedora DVD (Same DVD I used to install from) I figured it would be an easy task to stick grub back and go on about my business..

Nope.. Grub2 wouldn't install into the MBR of the very same drive that the Fedora installer had put it into. I get to looking, and the grub2-install had increased the size of my core.img file from the size shown above to just a little over 31K.

-rw-r--r--. 1 root root  31703 Jan  5 01:24 core.img

Same machine, same drive setup, same everything. The Fedora installer worked and installed the bootloader, grub2-install didn't.

So, I didn't want to reinstall Windows XP and resize the partitions on that drive..

I set the BIOS boot order to boot from the second hard drive (my Fedora drive) instead of the first (Windows XP drive)

Windows XP is formatted MBR, Fedora is formatted GPT
I had no BIOS_Boot partition on the Fedora drive, but luckily I had started my partitions at sector 2048 instead of 34, so I had sectors 34-2047 free.

Booted up my Fedora install DVD, entered rescue mode...

Used gdisk to create a BIOS_Boot partition on /dev/sdb (sectors 34-2047)

Checked, rescue mode mounted all of my existing /, /boot/ /dev etc... under /mnt/sysimage so I was good to go as far as setting up a chroot

chroot /mnt/sysimage

just to be safe, I ran a grub2-mkconfig


grub2-mkconfig -o /boot/grub2/grub.cfg

then the grub2 install

grub2-install /dev/sdb

rebooted and all worked fine...

Here is the portion of my grub.cfg that boot into Windows XP

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Microsoft Windows XP Professional (on /dev/sda1)" --class windows --class os {
	savedefault
	insmod part_msdos
	insmod ntfs
	set root='(hd0,msdos1)'
	search --no-floppy --fs-uuid --set=root CADC8BADDC8B927D
	drivemap -s (hd0) ${root}
	chainloader +1
}
### END /etc/grub.d/30_os-prober ###

and my first Fedora linux entry:

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora Linux, with Linux 3.1.6-1.fc16.i686.PAE' --class fedora --class gnu-linux --class gnu --class os {
	savedefault
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod ext2
	set root='(hd1,gpt1)'
	search --no-floppy --fs-uuid --set=root 0cf6bfa2-74b2-4c80-8dfb-9b3b1a8bbbd5
	echo	'Loading Linux 3.1.6-1.fc16.i686.PAE ...'
	linux	/vmlinuz-3.1.6-1.fc16.i686.PAE root=UUID=10dc50c0-f981-49c9-8be0-7da4c58bd49c ro rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us SYSFONT=latarcyrheb-sun16 rd.luks=0 LANG=en_US.UTF-8 
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.6-1.fc16.i686.PAE.img
}

But something has definitely changed form the Fedora 16 release and now with grub2. Like I said, the F16 installer put grub2 into the boot sector and had room for the core.img file. Now grub2-install creates a larger core.img file and it won't fit between the MBR and sector 63

partition on /dev/sdb (Fedora drive)

Disk /dev/sdb: 586072368 sectors, 279.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 052DAAD8-581A-4742-8C76-91217DDA81E1
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 586072334
Partitions will be aligned on 8-sector boundaries
Total free space is 271 sectors (135.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2099199   1024.0 MiB  EF00  ext4
   2         2099200        10356735   3.9 GiB     8200  
   3        10356736       115214335   50.0 GiB    0700  
   4       115214336       586072063   224.5 GiB   0700  
   5              34            2047   1007.0 KiB  EF02  BIOS boot partition

partitions on /dev/sda (Windows XP drive)

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x123d123c

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63   488392064   244196001    7  HPFS/NTFS/exFAT

[chrismurphy]

You have 5104 sectors at the end unallocated. You could use gparted to resize and move at the same time. Set the start offset to 2048, and shrink by 1MB.

Or see if --force will work, if you're willing to use blocklists.

grub2-install --no-floppy --recheck --force /dev/sda

But it's curious that core.img is bigger this time around.

[DBelton]

I could have moved the Windows XP partition as you noted, however, I have always run into issues when I start playing around with Windows partitions, so I opted for the safer route with less work involved.

I tried using --force, and it wouldn't install that way, either

I haven't figured out what the difference is, but it is looking like anaconda does something different as far as putting the bootloader in the MBR than grub2-instal does. Possibly grub2-install is putting in a module that anaconda is leaving out??

[chrismurphy]

I'll point out that for at least one other person who tried --force, it does warn that it can't embed but it says that the installation did occur. Do you have the full output from using --force?

It's possible anaconda isn't using grub2-install, and is instead directly calling grub2-mkimage and choosing to pack in only specific modules into the core.img, whereas grub2-install might cause additional modules to be packed in.

But it seems to me the only thing needed in core.img for a disk is kernel.img, biosdisk.mod, and ext2.mod so that it can then fine /boot/grub2 and dynamically load all other modules. *shrug*

Clearly it's using some kind of compression to create core.img because kernel.img by itself is 44k.

[DBelton]

I don't have the output anymore where I tried installing it using --force.

You may have something there about anaconda might not be calling grub2-install. That would be about the only thing that explains the differences, unless an update since I installed increased the size of the modules it is loading. I haven't gone in and messed with anything to where it would be loading more or different modules than from when I did the install.

However, this behavior is not good, as that pretty much rules out being able to go back and re-install the bootloader if you have a Windows XP system installed unless you get lucky like I did and are able to move the bootloader to another drive.

[publius21]

I just ran into the same problem here. During the install of Fedora 16, Grub2 got installed to the MBR just fine, but after a install of Windows, which overwrote the MBR code, I can't get grub2 reinstalled, as core.img is too big. Luckily, I've got Grub4Dos which can be called from NTLDR.

The details are rather complicated, but I've got 4 hard drives, and the first partition is at 63 sectors on all of 'em. I use the first drive sda for normal booting, and had sdb for Grub on the MBR, and just switched around which drive boot in the BIOS as needed. Well, I decided to install Vista just to play around (I've got Win7), and for that install, I didn't have enough space on the small FAT boot partition on sda. Neither XP nor Win7 ever complained -- they just found a partition big enough to hold the temporary setup files and went from there. But for some reason, Vista's install wanted to use the boot drive.

The boot partition on sdb was big enough, so I ran the install after booting from the second drive, and thus overwrote Grub2 there. And now I can't reinstall it. Oh well.

Does anyone know the incantations to make a custom core.img the way Anaconda apparently does?