David Krings wrote: > Mikkel L. Ellertson wrote: >> I suspect that the problem you are running into is that the >> device.map file does not match the setup after you hook the Windows >> drive back up, so that when you install another kernel, or update >> grub, grub is trying to use the wrong drive. > > The extra drives aren't Windows specific. Although they have partitions > on them, they are just plain NTFS partitions in an extended partition. > > Well, is there any way to tell grub at the grub> prompt to look for some > bootable ext2 file system? Dare I write it, but even Windows can do that > since the stone ages (and no, it isn't always first partition on the > first drive, at least not for NT/2K/XP). > > I mean, GRUB ought to be a bit smarter...not that I'm saying I can make > a better or any boot loader. > > David > Sure - tell it that /boot/grub is on hd1,# where # is the correct partition on the second drive. The drive number has to match the BIOS mapping, because BIOS calls are used. The thing is, if the BIOS drive mapping is changed after grub is installed, you have to tell grub about it. The later Windows boot loaders have the same problem - install XP to the second drive on second drive on a system, and move it to a new system, or install it on the first drive, and then change that drive to the slave, and add a master. The problem is you only have so much space for the first stage boot loader, and both the first stage and second stage boot loaders use the BIOS to load things. Now, if your Linux drive is set as the boot device, and you chainload to boot Windows, then I don't understand why you are running into problems. On the other hand, if you are using booting from the RAID array with Windows on it, you have to tell grub about the changed BIOS mapping. It is best to do this before installing grub to the MBR of the RAID array. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
