Problems installing with multiple drives

[Sam Varshavchik]

Emmett Culley writes:

> I suppose I should put in a bug report, and I will, but I'd like to know if I am the only on experiencing this issue.

Not with the last couple of Fedora releases, but before then, on one of my 
machines Anaconda would consistently get the drive order wrong. Before 
anaconda rebooted, I always had to drop back to a shell, chroot to 
/mnt/sysimage, fix the Anaconda-generated /boot/grub/device.map to show the 
correct boot drive order, and reinstall grub. The Anaconda kernel would not 
assign the same driver letters that the regular kernel would. In the early 
part of the Anaconda installer's kernel boot, it manually probes drivers for 
identified hardware, and, in some previous Fedora releases, it was 
apparently doing it in a different order than the ultimately installed 
kernel would load the modules from linuxrc. Hilarity ensued.

The problem is that device.map needs to list the drives in the same order 
that the BIOS enumerates them at POST, and it's not always possible to 
figure out what it is, long after the kernel finished booting. It's often 
highly dependent on the individual motherboard's details, and sometimes 
there are even BIOS options that let you specify the disk boot order.

What you need to do is, first, identify the order in which your hard drives 
are enumerated by your BIOS and power on. You should be able to do that by 
carefully examining its messages.

Then, before you act upon Anaconda's prompt to reboot, switch to the ALT-F2 
shell, figure out how your drives are mounted, chroot to /mnt/sysimage, fix 
the Anaconda-generated device.map to map each drive to its BIOS order, 
make sure that grub.conf refers to the root volumes by their UUID or 
label, and then rerun /sbin/grub-install.

When you reboot back into the regular kernel, if the drive order is 
different, you'll need to update device.map again, otherwise the next time a 
kernel update gets installed, you may end up breaking grub again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20100904/346f295b/attachment.bin