Savedefault on Windows entry causes Error 28: Selected item cannot fit into memory

[Håvard Gulldahl]

Binary package hint: grub

Sometime between Hardy beta and Hardy, grub stopped booting my Windows Vista partition.

Now, when I try to boot the Vista entry from grub, it fails with the following message:

"
 Error 28: Selected item cannot fit into memory

Press any key to continue...
"

My menu.lst was auto-generated by the Hardy beta installer, and I haven't touched it since. I occasionally boot the Vista partition, which worked fine up until a few days ago. Alas, I'm not really able to tell which grub version that caused this. I'll try to re-install some older versions and report back the results.

I'm attaching my menu.lst. Please let me know if something else is needed.

System info:

Release: 8.04
grub: 0.97-29ubuntu21

(Edit: 2008-09-22: add [solved] to title)

[Håvard Gulldahl (havard)]

Of course, this may or may not be related to Bug #109672, but since that's been left alone for a year, and this appears to be a regression, I created a new bug report for this issue.

https://bugs.launchpad.net/ubuntu/+source/grub/+bug/109672

[Piotr M (yabolus)]

I have (had) exactly the same issue (with XP). Then I noticed that removing the 'savedefault' line fixes it. What does that line do?

[Piotr M (yabolus)]

Ok, I know what it does. It does nothing, since 'default' is set to "0" and not "saved".

[Håvard Gulldahl (havard)]

I can confirm that diabling the "savedefault" line in the Vista stanza *solves this problem*. Thanks, Piotr!

How do I proceed in pinpointing the bug?

Here's to removing that line from the autogenerated menu.lst (since, as Piotr correctly notes, it doesn't do anything anyway, as long as the value of 'default' is not 'saved').

[ramuk (kumar-yesitsme)]

Explanation to the above problem found on debian

Problem is not with Grub, it is with Memtest86 Read below. May be someone make a Patch available ASAP. because am not a Programmer

===========================================================================
===========================================================================

(Bug reported copied from http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;bug=319837)

Message #21 received at <email address hidden> (full text, mbox):

From: Paolo Ornati <email address hidden>
To: <email address hidden>
Subject: Not really a BUG...
Date: Mon, 1 Jan 2007 13:55:05 +0100

This is not really a BUG of GRUB... it's just that BIOS tables are
getting bigger!

Memtest86(+) uses the "standard" linux kernel image format, so it it can
be loaded easily by boot loaders such as Lilo and Grub...

The format is:
 512 byte of boot sector
 512 * X bytes of setup (where X is usually 4)
 Y bytes of kernel image

A zImage kernel will be loaded at address 0x10000 (64k) while a bzImage
will be loaded at 0x10000 (1MB).

Memtest uses the old format.

The boot loader also loads a copy of boot sector and setup sectors at
0x90000 (and then execute the setup code):

        | |
0A0000 +------------------------+
        | Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
09A000 +------------------------+
        | Stack/heap/cmdline | For use by the kernel real-mode code.
098000 +------------------------+
        | Kernel setup | The kernel real-mode code.
090200 +------------------------+
        | Kernel boot sector | The kernel legacy boot sector.
090000 +------------------------+
        | Protected-mode kernel | The bulk of the kernel image.
010000 +------------------------+
        | Boot loader | <- Boot sector entry point 0000:7C00
001000 +------------------------+
        | Reserved for MBR/BIOS |
000800 +------------------------+
        | Typically used by MBR |
000600 +------------------------+
        | BIOS use only |
000000 +------------------------+

For the details read this:
 http://lxr.linux.no/source/Documentation/i386/boot.txt

So, basically, this layout assumes that memory up to address 0x9A000 can be used.

The problem is that the newer BIOSes are reserving more and more space
in the top addresses below 640k (low memory), so this layout got
broken... and GRUB cannot do anything about it.

I hit this problem a few days ago switching from an "old" Athlon64
based system to a Core2Duo base one.

If you have an x86_64 system you shold have something like this in the
"dmesg" (it's not printed on x86 if I rember correctly, you can look at
"/proc/iomem" anyway):

[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
[ 0.000000] BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000003e599000 (usable)
[ 0.000000] BIOS-e820: 000000003e599000 - 000000003e5a6000 (reserved)
[ 0.000000] BIOS-e...

[ramuk (kumar-yesitsme)]

this Problem even occurs in Ubuntu 8.10 & kubunt 8.10 as well.

posted the same message in the Below link too
https://bugs.launchpad.net/ubuntu/+source/grub/+bug/109672

[Piotr M (yabolus)]

ramuk: I don't think that's the right answer. I switched from kubuntu to gentoo some time ago and I'm using grub's savedefault option and it works. Also, it doesn't seem to be in any way connected to memtest86.

[Cyber Killer (cyber-killer)]

Confirmed in Kubuntu 9.04. Commenting out savedefault fixes the problem.

[Alexandre Gauthier (underwares)]

How is it solved? It still happens with 10.04 and grub 0.97.

I upgraded from 9.10 to 10.04 hence why I'm not in magical grub2 land yet. And honestly I'm not too eager to make the jump.

This worked at first, and one day, eventually stopped working. Curiously enough 'savedefault' only fails when chainloading windows. 7. It works fine for other entries.

[Thomas Hotz (thotz-deactivatedaccount)]

Marking bug as confirmed because it happens to several people.

[DonJuan (johnalexocay)]

How to remove the "savedefault" line? anyone please :)

[dino99 (9d9)]

This is no more a supported version; and grub legacy upstream is also stopped, only receiving possible random fixes locally. Its time to use grub2 instead