core.img too large for embedding with msdos partition style (possibly only when boot is on LVM or other complex partition type?)

[Jamin W. Collins]

After upgrading to 12.10 I found that I could no longer boot my system. Instead I ended at a grub rescue prompt. Attempting to fix this by booting from a USB stick built from the 12.04 alternative installer revealed that grub could no longer embed the necessary core.img file. This same configuration worked flawlessly under 12.04, but no longer works under 12.10. This would appear to be a regression.

In order to get the system booting again, I had to move to a gpt partition table to allow for the larger core.img size.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: grub-pc 2.00-7ubuntu10
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu3
Architecture: amd64
Date: Sat Oct 13 08:41:42 2012
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: grub2
UpgradeStatus: Upgraded to quantal on 2012-10-12 (0 days ago)

[Julian Taylor (jtaylor)]

my core.img is also larger than 32k and my not very old machine (partitioned about 1-2 years ago with gparted) also only had 64 start sectors until I had to fix it for quantal. So it may be a common issue.
as it can leave inexperienced users with an unbootable machine I'm marking it critical.

[Max Bowsher (maxb)]

@jcollins, jtaylor:

I am also affected by this bug and it seems to be because my disks are all LVM, with no separate non-LVM /boot. Do your systems also match this description?

[Max Bowsher (maxb)]

I have opened an ubuntu-release-notes bugtask to track adding a caution to the Quantal release notes regarding this issue. I would imagine it would affect every user using direct LVM booting with a "traditional" 62 sector embedding area between the MBR and the first partition.

[Max Bowsher (maxb)]

For the record, my workaround for this issue has been to borrow another disc, incorporate it into my existing VG, and temporarily migrate all data out of one existing PV at a time to allow recreating it with more space before the partition.

Modern fdisk versions no longer default to starting the first partition at sector 63, but choose sector 2048 instead, allowing for almost 1MiB of grub image.

[Jamin W. Collins (jcollins)]

@maxb:

Yes, your configuration matches mine (disks are all LVM, with no separate non-LVM /boot). Also, your work around is much the same approach I took, though I did also migrate to a GPT partition table in the process.

[Phillip Susi (psusi)]

It seems that from the perspective of grub2, this is a WONTFIX. Your average desktop user won't be affected since they don't use LVM. A release note should probably be added for server admins to watch out for this on upgrade.

[Max Bowsher (maxb)]

LVM is useful on the desktop as well as the server! Can we get this release-noted for Ubuntu Desktop too?

[Jamin W. Collins (jcollins)]

As maxb@ states LVM is useful on the desktop/laptop just as much as on the server. In fact I won't install a system without it. Full disk encryption also uses it. I'd hazard to say that's going to become more and more prevalent.

Why make assumptions about how the user is or isn't going to use the installation? Why not simply document the issues for all cases.

[YannUbuntu (yannubuntu)]

Possible duplicate of Bug #1059827

[[e-mail] (ruedii)]

Would creating a build optimized for size help here? I don't think the memory alignment build options really will give much advantage for boot time on Grub, it's only a few kilobytes of code, and most of it is only run under certain situations.

If we absolutely had to, we could create a version called "mini" for these affected systems, which has far fewer features.