Windows 2000 hangs on start when grub is used

My friend has similar problem: two hard drives, hda with XP, hdb with Ubuntu Feisty. XP started only once form grub, then no more. I'll have his machine here tomorrow, so I'll tell you what I figured out.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

I just enabled hardy-proposed updates in Synaptic package manager and installed suggested updates. Since then I can't boot into my Vista system anymore I suspect there's a problem in the Grub version that got installed (0.97-29ubuntu21) because I never had any boot problems before. The menu.lst seems seems OK to me.

I did a couple of trials. I was wondering what 'savedefault' was doing in my Vista entry in menu.lst, it shouldn't be there so I removed it. And to my surprise that seemed to solve the problem! So I rebooted once more and added it again from the Grub gui at boot and got the error: "Selected cylinder exceeds maximum supported by BIOS." Rebooted without 'savedefault' and it works. All very strange to me. What does 'savedefault' have to do with this behaviour? Way beyond my understanding.

This is the entry after upgrade (that doesn't work):
# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/sda3
title Windows Vista/Longhorn (loader)
root (hd0,2)
makeactive
savedefault
chainloader +1

This is the one that works:
title Windows Vista/Longhorn (loader)
root (hd0,2)
makeactive
chainloader +1

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. this Problem even occurs in Ubuntu 8.10 & kubunt 8.10 as well.

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

(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: 00000...

Can anyone test if this problem still appears in Ubuntu 9.10 (Karmic)? Can you confirm if it exists when using Grub2?

The bug still occoured when I wanted to use savedefault (with setting default to "saved" in menu.lst) on karmic and x86_64 and grub1.

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