View Full Version : GRUB2 core.img not fitting between MBR and sector 63
chrismurphy
3rd January 2012, 10:00 AM
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
3rd January 2012, 10:31 PM
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.:confused:
I am planning to convert to syslinux one of these days.
chrismurphy
3rd January 2012, 10:35 PM
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
4th January 2012, 05:04 AM
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
4th January 2012, 05:27 AM
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
4th January 2012, 03:48 PM
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
4th January 2012, 06:21 PM
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
5th January 2012, 06:33 AM
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
5th January 2012, 07:20 AM
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
5th January 2012, 02:40 PM
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
5th January 2012, 07:30 PM
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
5th January 2012, 08:13 PM
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
5th January 2012, 09:09 PM
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
5th January 2012, 09:46 PM
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
8th January 2012, 04:41 AM
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?
chrismurphy
8th January 2012, 04:53 AM
I'll guess that info is in the anaconda kickstart file, somewhere near the very end.
publius21
8th January 2012, 05:00 AM
I spoke too soon. "grub2-install --force" *worked*, even though it warned it "could not embed". I thought that was a failure, but lo and behold, up comes the grub2 screen when I just tried booting from sdb.
I have no idea what --force does when core.img is too big, but it did something. Grub2 works as before.
chrismurphy
8th January 2012, 05:01 AM
It's using blocklists - basically it's finding additional free space in between partitions and after the last partition and stuffing core.img into those areas. I think.
the.ridikulus.rat
10th January 2012, 07:43 PM
https://wiki.archlinux.org/index.php/GRUB2#Install_to_Partition_or_Partitionless_Disk
GeekGirl1
25th January 2012, 02:44 AM
Thank you for the clear explanations in this thread. I upgraded from FC15 to FC16 using How to use PreUpgrade - FedoraProject (http://fedoraproject.org/wiki/How_to_use_PreUpgrade).
My PC has 2 hard drives: the primary hard drive is Windows 7 (NTFS); the secondary hard drive has several Ext4 partitions for Fedora, one for NTFS storage.
After the upgrade, Grub 1.99 was installed and I was able to boot successfully from the primary hard drive. I recently had to restore a Windows 7 image and reset the MBR to the Windows 7 bootloader. Both hard drives are SATA.
Upon restoring Windows 7, I then tried to restore the bootloader with grub2. This did not work (/dev/sda is the primary drive):
# grub2-install --force /dev/sda
I then tried to install grub2 on my secondary drive's boot partition. It displayed the error messages followed by a successful installation message. My PC now boots on the secondary drive.
# grub2-install --force /dev/sdb
I modified my BIOS settings to boot on the secondary drive. My core.img filesize is:
65246 32 -rw-r--r--. 1 root root 31645 Jan 24 14:49 core.img
DBelton
25th January 2012, 03:04 AM
Once again, looks like another situation where anaconda was able to install the core.img file into the space between the MBR and first partition, but grub2-install wasn't able to due to the core.img file being a larger size.
Question is...
What does anaconda do to the core.img file to make it small enough to fit in the space? Is it just creating it with fewer modules?
Whatever it is doing, then grub2-install should be doing it the same way.
chrismurphy
25th January 2012, 03:09 AM
We need an anaconda.log posted. It should have the grub2 commands used in it.
DBelton
25th January 2012, 03:17 AM
the anaconda-ks.cfg file from the last install I did on one machine here has not much info in it:
# Kickstart file automatically generated by anaconda.
#version=DEVEL
install
cdrom
lang en_US.UTF-8
keyboard us
network --onboot yes --device em1 --noipv6 --nameserver 192.168.1.254 --hostname tower11.home
timezone --utc America/Chicago
rootpw --iscrypted $6$C.AuX7CMQWuX8a6K$e0DsnRoHJ2wQQdeiKzwXWNYbEcz7fb muDOJXhubUpX0WA4pYgCzPo6aCcFw23vI8MZBVVm/8LcSI1/litmpxL1
selinux --enforcing
authconfig --enableshadow --passalgo=sha512
firewall --service=ssh
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
#clearpart --none
#part None --fstype=ext4 --label="Drive_I" --onpart=sdl1 --noformat
#part None --fstype=ext4 --label="Drive_D" --onpart=sdk1 --noformat
#part None --fstype=ext4 --label="Drive_H" --onpart=sdf1 --noformat
#part None --fstype=ext4 --label="Drive_G" --onpart=sde1 --noformat
#part None --fstype=ext4 --label="Drive_E" --onpart=sdd1 --noformat
#part None --fstype=ext4 --label="Drive_F" --onpart=sdc1 --noformat
#part /home --fstype=ext4 --onpart=sdb4
#part / --fstype=ext4 --onpart=sdb3
#part swap --onpart=sdb2
#part /boot --fstype=ext4 --onpart=sdb1
#part None --fstype=ntfs --onpart=sda1 --noformat
bootloader --location=mbr --timeout=5 --driveorder=sda,sdb,sdc,sdd,sde,sdf,sdk,sdl --append="rhgb quiet"
%packages
**** all the different packages installed removed ****
I would have to go through another install to grab the logs that really show what is needed, and I'm really not in a good position to do an install at the moment.
chrismurphy
25th January 2012, 03:18 AM
I think there's an actual log that has what it actually tried and any console messages that resulted.
DBelton
25th January 2012, 03:31 AM
Found some more of the anaconda logs from my last install..
Here is what I found pertaining to bootloader installations.. not much :(
23:14:30,170 DEBUG storage: new bootloader stage1 device: sda
23:14:30,171 DEBUG storage: new drive order: ['sda', 'sdb', 'sdc', 'sdd', 'sde', 'sdf', 'sdk', 'sdl']
23:14:30,171 DEBUG storage: new default image: <pyanaconda.bootloader.LinuxBootLoaderImage object at 0xb656ce6c>
23:14:33,783 DEBUG storage: DeviceTree.getDeviceByName: name: sr0 ;
23:14:33,791 DEBUG storage: OpticalDevice.mediaPresent: sr0 ; status: True ;
23:14:33,799 DEBUG storage: DeviceTree.getDeviceByName returned existing 3629MB cdrom sr0 (51) with existing iso9660 filesystem
23:28:03,994 INFO storage: not writing out mpath configuration
23:28:04,125 INFO storage: not writing out mpath configuration
00:40:10,848 INFO storage: bootloader stage1 target device is sda
00:40:10,869 INFO storage: bootloader stage2 target device is sdb1
00:40:07,342 INFO program: Running... /usr/sbin/lokkit --selinux=enforcing
00:40:08,765 INFO program: Running... /usr/sbin/authconfig --update --nostart --enableshadow --passalgo=sha512 --enablefingerprint
00:40:10,491 INFO program: Running... /usr/sbin/lokkit --quiet --nostart -f --service=ssh
00:40:11,178 INFO program: Running... grub2-set-default Fedora Linux, with Linux 3.1.0-5.fc16.i686.PAE
00:40:11,516 INFO program: Running... grub2-install --no-floppy (hd0)
00:40:25,019 INFO program: Installation finished. No error reported.
00:40:25,021 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg
00:40:27,325 ERR program: Generating grub.cfg ...
00:40:28,116 ERR program: Found linux image: /boot/vmlinuz-3.1.0-5.fc16.i686.PAE
00:40:28,168 ERR program: Found initrd image: /boot/initramfs-3.1.0-5.fc16.i686.PAE.img
00:40:32,809 ERR program: No volume groups found
00:40:37,050 ERR program: Found Microsoft Windows XP Professional on /dev/sda1
00:40:39,037 ERR program: done
00:40:39,577 INFO program: Running... grub2-install --no-floppy (hd0)
00:40:44,855 INFO program: Installation finished. No error reported.
BUT... it appears that anaconda just runs grub2-install, so what is the difference?
Edit:
About the only thing I can think of is that an update to grub2 causes it to create a larger core.img file than the version that is included on the install media.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.