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

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.

@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?

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.

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.

@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.

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.

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

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.

Possible duplicate of Bug #1059827

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.