GRUB2 fails with certain memory configurations

[C]

Binary package hint: grub2

I guess same bug as https://bugs.launchpad.net/ubuntu/+source/grub/+bug/638945

If the low-memory in the area 0x90000 to 0x9A000 is not available GRUB2 fails.

That area is increasingly being used by certain BIOS extensions (like FakeRAID BIOS).

On systems with such configuration the only quick workaround is to use EXTLINUX - which does not have the same problem and seems to be able to check if memory is reserved before using it - but which requires a little more experience and work from the user.

[dazza5000 (darran-kelinske)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

[Colin Watson (cjwatson)]

Seems fairly plausible to me; in fact I wondered if this was going to be an issue while reading some related code just the other day. I imagine it can only be recreated on certain machines, and when it happens it's fatal.

[C (ubuntu-caranfil)]

The bug is perfectly reproducible on a system with such a BIOS (for instance ASROCK 939A785GMH).

With RAID disabled the RAM is free up to about 0x9f800 (displaymem in GRUB and lsmmap in GRUB2), with RAID enabled a reserved area appears at 0x92400 (len 0x0dc00).

The bug was mentioned long ago somewhere on the internet also in relation to memtest, but I believe any kernel with bzImage format (which an old file was documenting that it gets loaded in that area) will trigger the problem.

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

[Launchpad Janitor (janitor)]

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]