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
On Wed, 21 Oct 2009 17:24:52 -0400 Gene Czarcinski wrote:
Can someone explain how anaconda figures out boot/disk order and is there some guarantee that the algorithm will not change between Fedora releases?
I can't answer any of your other questions, but because I have watched it over many releases, I can guarantee that the disk order is randomly changed in just about every release :-(.
On 10/21/2009 05:50 PM, Tom Horsley wrote:
On Wed, 21 Oct 2009 17:24:52 -0400 Gene Czarcinski wrote:
Can someone explain how anaconda figures out boot/disk order and is there some guarantee that the algorithm will not change between Fedora releases?
I can't answer any of your other questions, but because I have watched it over many releases, I can guarantee that the disk order is randomly changed in just about every release :-(.
So far with all of the incarnations of F12, and fresh installs of F10, F11, Centos and Omega, anaconda has ordered the disks on my test system per the bios ordering even tho they are not in order by letter. I.e, 4 SATA disks (A..D) and 2 IDE (F, G). In the bios I have them ordered F, G, A to D and this is the ordering anaconda has maintained. Anaconda initally wanted to put /boot on sdf and I let it since it was the first bios disk. Each test install of a different distro or version of Fedora gets its own boot sector and I just tell the boot loader dialogue to install in the first sector of the /boot partition.
On Wednesday 21 October 2009 17:50:36 Tom Horsley wrote:
On Wed, 21 Oct 2009 17:24:52 -0400
Gene Czarcinski wrote:
Can someone explain how anaconda figures out boot/disk order and is there some guarantee that the algorithm will not change between Fedora releases?
I can't answer any of your other questions, but because I have watched it over many releases, I can guarantee that the disk order is randomly changed in just about every release :-(.
Yes, I noticed.
I really do not understand the problem with anaconda.
I did a "quick" test: bootup the distribution DVD in rescue mode for Fedora 8, Fedora 9, Fedora 11, and Fedora 12-Beta. After bootup do: cat /proc/scsi/scsi
On Fedora 8 and Fedora 9, the DVD drive was the first listed (scsi0) whereas on Fedora 11 and Fedora 12-Beta the DVD drive was the last listed (scsi4).
For the three disk drives, they were in the same order as shown by the BIOS -- 1.5TB disk first followed by the 1.0 TB disks. The important thing is that the order was identical in all cases.
So, if /proc/scsi/scsi can be created correctly, why can't anaconda do it?
On 10/22/2009 02:45 PM, Gene Czarcinski wrote:
<snip>.
So, if /proc/scsi/scsi can be created correctly, why can't anaconda do it?
Looks like anaconda is using the BIOS boot disk order, not the bus order. At least it does that on my ASUS P5K-E mobo and P5E mobo and some older ASUS mobos that I used to have.
Clyde E. Kunkel wrote:
On 10/22/2009 02:45 PM, Gene Czarcinski wrote:
<snip>.
So, if /proc/scsi/scsi can be created correctly, why can't anaconda do it?
Looks like anaconda is using the BIOS boot disk order, not the bus order. At least it does that on my ASUS P5K-E mobo and P5E mobo and some older ASUS mobos that I used to have.
The "BIOS boot order" is not as easy to find as you'd like: http://www.gnu.org/software/grub/manual/html_node/Device-map.html#Device-map "The reason why the grub shell gives you the device map file is that it cannot guess the map between BIOS drives and OS devices correctly in some environments. For example, if you exchange the boot sequence between IDE and SCSI in your BIOS, it gets the order wrong."
A long-existing problem with SCSI disks is figuring the order, reliably. SCSI controllers can support seven or fifteen devices, and one can add/remove devices (on some at least) at any time, including while the system is up and running. I don't recall whether the host OS could tell which connector any particular disk was attached to, but I suspect not.
I could never understand how calling all disks "scsi" would help.
I can imagine that polling a SCSI adaptor, checking what is attached to each connector might be time-consuming (especially if it relies on a timeout to detect "nothing here, move along") and might miss something that is slow to respond - perhaps getting different results between cold-stand and warm-start, while relying on interrupts as devices become ready could result in random ordering, even on the same hardware and potentially between reboots.
No doubt the use of GUIDs solves the problem of recognising individual disks, unfriendly to humans though they be.
I have wondered whether /dev/sda might be an internal disk one boot, a USB disk another even when both are present both times. I think I could build a kernel so they do change, by reordering the loading of relevant drivers.