Description of problem: f9 alpha x86_64 live cd : on a system where bios/grub/installed_fedora sees pata hard disk as sda and sata hard disk as sdb , anaconda sees sata as sda and pata as sdb Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1.boot f9 alpha x86_64 live cd 2.start installation script 3. Actual results: anaconda sees sata as sda and pata as sdb Expected results: anaconda sees pata as sda and sata as sdb Additional info: same error was present during the devel of f8
Drive names are (largely) at this point pretty meaningless. What exactly is the problem that you're seeing as a result?
two problems i see with this confusion: - an user has to identify by other methods wich is the partition he wants to format and - the grub expects to boot from the wrong drive: https://bugzilla.redhat.com/show_bug.cgi?id=431644
The problem is that there's no reliable way to actually determine what is going to be "correct" for any case. So you're always going to have to use other methods to figure out the partition you want to format (this is why we ensure that we have other information about the drives available than just their names including things like size, vendor string, etc).
excuse me but don't you think would be correct for anaconda to use the same drive names as the installed system? right now this is not the case. i strongly believe whatever the decision will be it has to be the same for the bios (grub), for anaconda and for the installed system. right now, anaconda and the resulted grub disagrees with the bios and the installed system.
Created attachment 294374 [details] grub was supposed to be on sda6 as you can see, grub was supposed to be on sda6. however, since the computer boots from what anaconda sees as sdb, i believe this is another bug.
Created attachment 294375 [details] choosing the drive to boot from indeed, there's a way to choose the drive to boot from as long as you don't select create custom layout (wich i did).
stays true for f9beta livecd. as usual, after install, fedora sees them the other way.
it's true for both x86_64 livecd and (new!) for i686 kde livecd. as a side effect: https://bugzilla.redhat.com/show_bug.cgi?id=438888
_maybe_ it's because first hard disk it's a slave pata and not master but i still believe it should be the same before and after install.
installing from f9 preview live x86_64, everything is ok, regarding drives order, the same as bios order, during livecd/anaconda install, and at first boot. meanwhile, someone on fedora-test list reports that the drives order are chosen randomly, but this info is not confirmed.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Could this be related to bug 246295 from back in the Fedora 7 days?
Jeremy's comment is still correct. The drive names are really not guaranteed to be the same across reboots or anything given that the kernel might detect them in a different order. We're moving in the direction of providing more descriptive information for the drives as well as using things like UUIDs for naming filesystems instead of relying on the device names.
using boot.iso (x86_64) from 6th of june 2k8, the bug is still there. i've started install two times, first, the drive order was ok, second was reversed. i do not understand how can the same cd detect the drives order differently, and in the same time, installedsystem is consistent between reboots. can someone point me to some docs about this ? thnx
until another method of identifying drives will be used, in f10 alpha i686 live cd the error is still there. i've booted threee times in a row, and all three times, the drives order was reversed to the bios order. also, in the screen where we can decide where we'll install grub, the "bios order" is user defined!
There's still nothing we can do here, nor is this really a bug. We get the drives in the order we get them from the underlying kernel and hardware detection layers, and that order is not guaranteed to be consistent across reboots.
thnx chris, i hope this time i got the message.