GRUB fails with certain memory configurations
Bug #638945 reported by
C
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| grub (Ubuntu) |
Triaged
|
High
|
Unassigned | ||
Bug Description
Binary package hint: grub
If the low-memory in the area 0x90000 to 0x9A000 is not available GRUB 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.
| Changed in grub (Ubuntu): | |
| status: | New → Triaged |
| importance: | Undecided → High |
Revision history for this message
| C (ubuntu-caranfil) wrote | #1 |
To post a comment you must log in.
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.