Comment 43 for bug 420933

Am Freitag, den 30.10.2009, 10:35 +0000 schrieb mikeXYZ:
> A user shouldn't have to change the boot order to get the new-and-
> improved GRUB to work reasonably well.
>
> Many users have Windows on a first-in-BIOS HDD "sda" and boot from that
> HDD by installing GRUB to its MBR, in preference to maintaining their
> Windows on a non-first HDD (requiring devicemap and being subject to
> various maintenance issues, especially as Windows receives updates). I
> do agree with posters above now that this is a show stopper. Not only
> is the delay between POST and boot menu unacceptably long (70 s in my
> case, with just two standard SATA disks), but there also may be a 2-6
> second delay after selecting a menuentry from the menu. As GRUB
> improves along certain useful dimensions (e.g., loopback, GPT support,
> os-prober, etc.), many other new features will never be used by most
> users of GRUB; so let's not ask them to live with a regression of basic
> performance & features. (BTW, I'm a GRUB lover, too, and an active how-
> to writer these past several years, aka Qqmike@kubuntuforums).
>

I can't image any reason why for Windows itself it makes a difference if
BIOS really booted from the same harddisk or if it's emulated via
drivemap command.
30_os-prober adds drivemap anyway always with Windows < Vista
And I don't get all why you said `especially as Windows receives
updates'
Windows update shouldn't at all affect this.

Well anyway, the only 2 fixes/workarounds for this you currently have is
to either install it to the MBR of the disk containing /boot/grub or
hack grub-install so it doestn't use the UUID= hack but instead
hardcodes the real grub device for /boot/grub.
But if then the BIOS disk order changes then you have to change
grub-install again.
And the changes get lost on the next package upgrade.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer