> Can someone possibly explain exactly what's wrong with GRUB2? The main problem of GRUB2/GRUB4DOS is that it is entering the Linux kernel by the partially documented 32 bits entry point: http://www.mirrorservice.org/sites/alpha.gnu.org/gnu/grub/grub-1.98.tar.gz/grub- 1.98/loader/i386/linux.c?extract=true
That means you are no more executing the real mode part of the linux kernel, you are using some real mode memory structures set-up by GRUB2. Those structures have been more or less identical to those of Linux at some point in the past. That means that some kernel options which were working with GRUB1 (like EDID and EBIOS disk identifications) are no more working, and no more evolutions can be done in the real mode part of the Linux kernel (like increasing some structures, moving their base address...). Those evolutions would only be working with kernel booted with GRUB1, LILO or Gujin, but not with GRUB2. Disclaimer: I am not unrelated with the GPL bootloader Gujin at sourceforge. When entering the Linux kernel by the 32 bits entry point on ia32/amd64 has been discussed on lkml, it was seriously criticised. For instance, because the boot disk can no more be determined safely (the BIOS on most machine can tell the PCI address of a drive, but it is unsafe to call the BIOS after so many modifications in protected mode done by GRUB2), you get distributions switching to all UUID mode - which is a major pain when one of your hard disk fails and you copy it byte per byte onto a spare disk, leading to UUID conflicts. Also, some amd64 PC seems to want a BIOS call when they will run a 64 bits kernel (linux kernel real-mode code), I am not sure that one is done by GRUB2. And a third problem is that you need the 32 bits libraries to compile GRUB2, even on a clean 64 bits machine. Just my $0.02, Etienne.
