long standing aggravation

[Gene Czarcinski]

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