I have had a long standing aggravation dealing with anaconda's boot disk order and how grub is set. When I get things "right", the install and reboot work fine. Often as not, I don't get it right. But, with a lot of experience with this problem, the fix is "easy" ... after the install, boot up in rescue mode and change /boot/grub/grub.conf so that (hdN,i) is set correctly [e.g., change (hd2,7) to be (hd0,7)] ... then, after chroot'ing to the system run grub- install /dev/xxxx [such as grub-install /dev/sda8]. The "cost" is that I get an selinux relabel during the first bootup. This problem has been BZ'ed a number of times such as -- https://bugzilla.redhat.com/show_bug.cgi?id=431638 https://bugzilla.redhat.com/show_bug.cgi?id=431644 https://bugzilla.redhat.com/show_bug.cgi?id=435878 These reports are generally closed with "live with it, there is not much we can do" ... just set the boot selection and bios order options to the "correct" values. Putting in yet another BZ report does not seem to be very promising. Therefore, I thought that maybe some discussion on this list (or maybe this should be on the devel list) might prove more beneficial. Most of my recent experience has been on my test system where I have installed Fedora 10, Fedora 11, and Fedora 12-rawhide a number of times. My hardware: - ASUS M4A78 PRO mobo - AMD 940 Phenom processor with 8GB ram. - one 1.5TB disk (call this scsi0) - two 1.0TB disks (call them scsi1 and scsi2) - one DVD drive (call this scsi4). - plus two NICs and the usual set of other stuff. BTW, try buying small disks these days .. cost and performance where the deciding factors ... not storage capacity. This system is not just dual-boot but is multi-boot ... a single small Fedora installation on scsi0 with grub installed in scsi0's MBR ... this small system is used for "emergencies", as a boot selector, and to pre-partition my disks with LVM. Besides the "small Fedora", scsi0 has four /boot partitions with the rest of the disk as physical LVM. This physical LVM has a single volume group with root1, root2, root3, and root4 logical volumes allocated plus a /home logical volume. This gives me the ability to have up to four separate installations I can select to run [I always fresh install, never upgrade]. All installs are "custom layouts" for disks and edit rather than allocate partitions of logical volumes. The other two disks (scsi1 and scsi2) are a single LVM volume group that I use for data storage such as my collection of iso images and my storage for qemu- kvm disk images. I could possibly fit everything onto a single drive but experience with performance says that root and /home need to be separate from data such as qemu-kvm image files. When I boot up the BIOS lists the disks as scsi0, scsi1, and scsi2 (not by those names but in that order ... or at least the 1.5TB is always first and that is the MBR that is booted. After booting the F12-Beta DVD in either rescue mode or installation mode, if I go to VT-2 and do "cat /proc/scsi/scsi", this list is always in the "proper" order of scsi0, scsi1, and scsi2. But anaconda shows the order as scsi1, scsi2, and scsi0 (third place). Note: the physical order that the disk cables are plug into the mobo's SATA interfaces is scsi0, scsi1, and scsi2. On at least one occasion installing Fedora (10, 11, or 12 ... I forget which), the boot partition after installation was "sdc" and it worked! Naturally, since /etc/fstab has disks referenced by UUID or LVM name, stuff can shuffle around with no problems. But grub is something else. While anaconda seems to be pretty much consistent, what is it using to determine boot order since the list in ./proc/scsi/scsi is the correct order? If I guess right during the install, everything works. If I guess wrong then I have to go back and fix things which, like I said, I have lots of experience doing. Guessing right is not always as easy as I described above. One system I had (which I no longer have) had a 120GB PATA disk and a 120GB SATA disk ... the PATA disk was booted by the BIOS. And then there is the situation where you have two identical disks. I am not really python literate so figuring out what anaconda is doing is not simple for me. Can someone explain how anaconda figures out boot/disk order and is there some guarantee that the algorithm will not change between Fedora releases? Question: should I cross post to the devel list or is the test list sufficient? Gene -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list