[Lucid] Upgrade of grub-pc: "Your embedding area is unusually small. core.img won't fit in it."

[Mario Vukelic]

Binary package hint: grub2

Yesterday I installed Lucid on a MacBook Pro 5,4 (https://help.ubuntu.com/community/MacBookPro5-4/Lucid), using the snapshot disc image. I removed Mac OS X and converted the disk to MBR like described here: https://help.ubuntu.com/community/MactelSupportTeam/AppleIntelInstallation#Single-Boot:%20Ubuntu%20Only
The installation went totally fine.

Today I did an aptitude full-upgrade, which pulled in a new grub-common and grub-pc. grub-pc generated this error:

Setting up grub-common (1.98~20100115-1ubuntu3) ...
Setting up grub-pc (1.98~20100115-1ubuntu3) ...
/usr/sbin/grub-setup: warn: Your embedding area is unusually small. core.img won't fit in it.
/usr/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and its use is discouraged.
Installation finished. No error reported.
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-12-generic
Found initrd image: /boot/initrd.img-2.6.32-12-generic
Found memtest86+ image: /boot/memtest86+.bin
done

I am now afraid to reboot.

ProblemType: Bug
Architecture: amd64
Date: Mon Feb 1 22:28:48 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100131)
NonfreeKernelModules: wl nvidia
Package: grub-pc 1.98~20100115-1ubuntu3
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-12.16-generic
SourcePackage: grub2
Uname: Linux 2.6.32-12-generic x86_64

[Mario Vukelic (kreuzsakra)]

Here comes my partition setup from parted. Note that it says that the partition table is GPT, although I used gparted to remove all partitions and to create a new partition table of type msdos prior to installation (as described in the link from my previous post). Some googling showed that several people have this issue and it seems to be caused by the fact that the GPT is actually at the end of the drive not the start. I have no idea whether this GPT issue has an impact on the grub warning.

GNU Parted 1.8.8.git-dirty
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print
Model: ATA ST9320423ASG (scsi)
Disk /dev/sda: 625142448s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 34s 1987s 1954s bios_grub
 2 1988s 603027378s 603025391s ext4
 3 603027379s 625142414s 22115036s linux-swap(v1)

[Colin Watson (cjwatson)]

These wiki instructions are really odd. I don't buy their recommendation to convert back to MBR; we'd actually prefer people stay with GPT if that's how their disk comes, and I expect that staying with GPT would fix this problem.

grub-setup is just telling it how it is; the message is not a grub2 bug in and of itself. You should be able to reboot successfully (though keep a live CD handy!), but the unreliability of blocklists means that you may have to rerun grub-install more frequently than you otherwise would - for example, after major filesystem rearrangements. http://grub.enbug.org/BIOS_Boot_Partition has some further details here.

[Colin Watson (cjwatson)]

I have edited the wiki page to note my explicit disagreement with its recommendation.

[Mario Vukelic (kreuzsakra)]

Thanks, Colin, for the quick response and for adding to the wiki. Do you happen to have any idea whether the disk is now GPT, MBR, or some unholy mix of both? It's not only parted that flags it as GPT, fdisk does the same (and recommends parted because it cannot deal with GPT).

If for some reason the disk stayed with GPT despite my amateurish intervention, what would this mean for your statement that "I expect that staying with GPT would fix this problem"?

Thanks again.

[Ricky Campbell (cyberdork33)]

Colin,

I was one of the contributing authors of that wiki

There are some issues that are specific to the Mac Hybrid system that converting to the MBR format allows, such as being able to boot from partitions beyond #4. I'd say that was the major reason for doing so. I think a lot of the issues that were really cumbersome with GPT are not that big of a deal anymore, and the use of grub2 may solve them all anyway. Either way, it is old, and probably outdated info. It is, of course, and open wiki and you contribution is helpful.

[Ricky Campbell (cyberdork33)]

If parted says its GPT, then it likely is.

[Mario Vukelic (kreuzsakra)]

Thanks Ricky. But if the disk actually still *is* GPT, then there may be an issue with grub on the MacBook (Pro) after all, no?

[Mario Vukelic (kreuzsakra)]

For the sake of completeness:

Today's upgrade to grub-common and grub-pc 1.98~20100128-1ubuntu3 first triggered a debconf dialog for grub-pc, which asked for the device to install grub2 on, where I chose /dev/sda. Then the same warning about "embedding area too small" appeared as previously posted.

[Ricky Campbell (cyberdork33)]

You could just try installing it to your Ubuntu root partition. This is what we would normally do when dual-booting with OSX anyway. It appears that is /dev/sda2.

You also have a VERY small sda1 partition. Is that what it is supposed to look like?

[Mario Vukelic (kreuzsakra)]

If I don't misunderstand, then according to the installation instructions for dual-boot at https://help.ubuntu.com/community/MactelSupportTeam/AppleIntelInstallation#Dual-Boot:%20Mac%20OSX%20and%20Ubuntu it would not be installed to the Ubuntu root partition (which would be /dev/sda4 in this case) but into the BIOS Boot Partition, /dev/sda3 (with the bios_grub flag). Like also described in Colin's link from above, http://grub.enbug.org/BIOS_Boot_Partition

As to the size of sda1 (grub's BIOS Boot Partition), this was created with that size by ubiquity during installation. Before installation I removed all partitions and recreated the partition table with gparted (as in the single-boot install instructions linked above, which according to parted may have failed to actually convert the disk). If sda1 is now too small, this is the installer's doing.

[YannUbuntu (yannubuntu)]

Hi Mario,
can you reproduce this bug with Ubuntu 12.04 ?

[Mario Vukelic (kreuzsakra)]

Thanks for asking. Indeed I cannot.

Now that you ask I realize that I don't think I have seen that in a long time - I think I did a fresh install on the same MacBook Pro 5,4 (same HDD as well) with Oneiric around Beta time, later upgraded to Precise. That was an Ubuntu-only install, and I don't think I saw the issue.

In any case just a few weeks ago I did a fresh install with 12.04.1. I used the Desktop CD, amd64, BIOS version and followed the Ubuntu Mactel wiki instructions to create a parallel install of OS X (also completely new reinstall) and Ubuntu, using rEFIt. This was on a new HDD (Seagate Momentum XT, 750 GB hybrid with 8 GB NAND SSD built in. This time I'm sure I didn't see the problem.

[YannUbuntu (yannubuntu)]

ok thanks!

[Phillip Susi (psusi)]

YannU, please don't de-dup this bug without at least explaining why you feel it is not a dup.

[YannUbuntu (yannubuntu)]

I feel this is not a dup because here core.img should go to the BIOS-Boot partition, while Bug #1059827 is about cases where it goes to the embed area.

[Phillip Susi (psusi)]

Good point, I missed the bios_grub partition.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Marcus Tomlinson (marcustomlinson)]

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.