karmic alpha: grub2 core.img with mdraid & lvm too big to embed

[Roland Dreier]

Binary package hint: grub2

I tried to install a system with today's Karmic amd64 alternate CD, and with / on LVM on RAID. This setup used to work with older Karmic alphas (and presumably older grub2), but with the latest grub2, the core.img ends up being > 33000 bytes, which is just a bit more than the 31744 (= 62*512) bytes of space available for embedding. So grub-install fails and the system is unbootable.

The core.img that is built seems pretty minimal -- the raid, mdraid and lvm added in, which are all necessary AFAIK.

Not sure what the right way to handle this is -- LVM on RAID seems pretty mainstream, and the code just needs to be shrunk < %10 for core.img to fit, so fixing this would be great if possible. On the other hand, being so close to the limit seems pretty fragile....

ProblemType: Bug
Architecture: amd64
Date: Wed Sep 2 13:35:50 2009
DistroRelease: Ubuntu 9.10
Package: grub-pc 1.96+20090826-3ubuntu3
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-9.29-generic
SourcePackage: grub2
Uname: Linux 2.6.31-9-generic x86_64

[Colin Watson (cjwatson)]

Ouch. Thanks for the report; I'll take this up upstream (though probably
tomorrow, not today) and see what can be done.

 status triaged
 importance high

[Felix Zielcke (fzielcke)]

Am Mittwoch, den 02.09.2009, 20:53 +0000 schrieb Roland Dreier:
> Public bug reported:
>
> Binary package hint: grub2
>
> I tried to install a system with today's Karmic amd64 alternate CD, and
> with / on LVM on RAID. This setup used to work with older Karmic alphas
> (and presumably older grub2), but with the latest grub2, the core.img
> ends up being > 33000 bytes, which is just a bit more than the 31744 (=
> 62*512) bytes of space available for embedding. So grub-install fails
> and the system is unbootable.
>
> The core.img that is built seems pretty minimal -- the raid, mdraid and
> lvm added in, which are all necessary AFAIK.
>
> Not sure what the right way to handle this is -- LVM on RAID seems
> pretty mainstream, and the code just needs to be shrunk < %10 for
> core.img to fit, so fixing this would be great if possible. On the
> other hand, being so close to the limit seems pretty fragile....
>

Which RAID? RAID 5 or RAID 6?
And wich filesystem?
Reiser3 is the biggest filesystem in GRUB 2.
That was always a problem with a too big core.img
ext3/ext4 should work.

[Colin Watson (cjwatson)]

I clarified with Felix on IRC that even ext2 fails, and he spotted that it's mostly due to our use of gcc-4.4 by default. gcc-4.3 seems to generate smaller code, so I'll force that for the time being.

[Colin Watson (cjwatson)]

I've also just sent a patch to grub-devel that fixes the size issue with gcc-4.4.

[Roland Dreier (roland.dreier)]

Great, thanks for the quick fix. And for the record, I was using ext4, ie grub's ext2.mod -- I had pretty much the most plain-vanilla set of modules possible except for lvm and raid. With the current grub-pc on my laptop (amd64, 1.97~beta1-1ubuntu1), I see for the set of modules I would need:

$ grub-mkimage --output foo part_msdos biosdisk ext2 lvm raid mdraid ; ls -l foo
-rw-r--r-- 1 roland roland 33335 2009-09-03 07:15 foo

so hopefully the new grub will fix that.

[Roland Dreier (roland.dreier)]

Oh, by the way: it seems that the grub modules are built with -O2 -- using -Os could possibly shave a few percent off, which would give a little bit bigger margin of safety in the future.

[Felix Zielcke (fzielcke)]

Am Donnerstag, den 03.09.2009, 14:17 +0000 schrieb Roland Dreier:
> Oh, by the way: it seems that the grub modules are built with -O2 --
> using -Os could possibly shave a few percent off, which would give a
> little bit bigger margin of safety in the future.
>

You probable looked wrong.
For the utilities fs/ext2.c is compiled with -O2 but also with
-DGRUB_UTIL=1
For the module itself it's compiled with -Os
For example taken from the amd64 buildd log:

gcc -Ifs -I/build/buildd/grub2-1.97~beta1/fs -I. -I./include
-I/build/buildd/grub2-1.97~beta1/include -Wall -W -Wall -W -Wshadow
-Wpointer-arith -Wmissing-prototypes -Wundef
-Wstrict-prototypes -g -Os -falign-jumps=1 -falign-loops=1
-falign-functions=1 -m32 -fno-stack-protector -fno-builtin -m32 -MD -c
-o ext2_mod-fs_ext2.o /build/buildd/grub2-1.97~beta1/fs/ext2.c

--
Felix Zielcke
Proud Debian Maintainer

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 1.97~beta1-1ubuntu2

---------------
grub2 (1.97~beta1-1ubuntu2) karmic; urgency=low

  * debian/patches/953_no_eh_frame.diff: Build with -fno-dwarf2-cfi-asm to
    stop gcc-4.4 generating .eh_frame sections that cause core.img to be too
    big to embed in some common cases (LP: #423412).
  * debian/patches/954_normal_quiet.diff: Don't display introductory message
    about line editing unless we're actually offering a shell prompt.
  * debian/patches/955_really_quiet.diff: Remove some verbose messages
    printed before reading the configuration file. In some ways this is
    awkward because it makes debugging harder, but it's a requirement for a
    smooth-looking boot process; we may be able to do better in future (LP:
    #386922).
  * debian/patches/956_linux_quiet.diff: If the environment variable "quiet"
    is set to something other than 1, suppress progress messages as the
    kernel and initrd load. Set this for non-recovery kernel menu entries
    (LP: #386922).
  * debian/patches/957_savedefault.diff: Add GRUB_DEFAULT=saved, as well as
    grub-set-default and grub-reboot utilities. Provides functionality
    essentially equivalent to GRUB Legacy's savedefault (LP: #216178).
  * debian/rules, debian/grub-pc.install.in: Install grub-reboot and
    grub-set-default only in grub-common.
  * Add tag information to old Ubuntu patches.

 -- Colin Watson <email address hidden> Fri, 04 Sep 2009 15:02:36 +0100