GRUB2 fails with certain memory configurations

Bug #638947 reported by C on 2010-09-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)

Bug Description

Binary package hint: grub2

I guess same bug as

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) wrote :

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) wrote :

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.

Changed in grub2 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
importance: Medium → High
C (ubuntu-caranfil) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers