Bug 458138 - anaconda switches the sda and sdb names
Summary: anaconda switches the sda and sdb names
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: i386
OS: Linux
medium
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-08-06 16:40 UTC by cornel panceac
Modified: 2010-06-18 02:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-18 02:54:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description cornel panceac 2008-08-06 16:40:07 UTC
Description of problem:
as reported here
https://bugzilla.redhat.com/show_bug.cgi?id=431638
drive names are not consistent to the bios order, and they are not even consistent between reboots.

in bios, the first is the PATA hard disk and the second is the SATA harddisk.
same thing i've seen in x86 and x86_64.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.boot one livecd
2.start the installer
3.
  
Actual results:
the drive order is sometimes changed and different from the bios order as well as the installed fedora order.

Expected results:
drive order is always the same with the bios order.



Additional info:

Comment 1 Christopher D. Stover 2008-10-22 16:25:19 UTC
As mentioned in other bug reports, this isn't really a bug.  There's no way for the drive order to be consistently detected.

Comment 2 cornel panceac 2008-10-22 17:38:29 UTC
tha's not exactly computer science, imho.
where is the limit coming from? kernel or bios? 
i don't understand why the drive order can not be consistently detected.
thnx

Comment 3 Christopher D. Stover 2008-10-22 17:53:48 UTC
Hi Cornel, I won't claim to be a computer scientist, but according to Chris Lumens from your bug 431638: "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."

I don't know how the HAL works either so I can't give you much better of an answer.  However, what are you trying to do that this is causing you problems?

Comment 4 cornel panceac 2008-10-22 18:11:48 UTC
[quote]
However, what are you trying to do that this is causing you problems?
[/quote]
i am trying to install fedora, sometimes (alfa,beta,rc,release,etc).

you can find the details in the old reports.

the problem i see here (except the lack of available time to fix the bug) is that fedora+"standard" pc-compatible-hardware is a system wich behaves randomly: starting always from the same state, we can not predict the next state. maybe the bios/mobo manufacturers are not perfect but i believe that the main unpredictable system is the linux kernel (or maybe anaconda?). however, it's just a belief, only i've not found a better explanation for the inconsistency _before_ install versus the consistency after install of fedora .....

meanwhile it seems that the same bug affects some other distros, like ubuntu:

https://bugs.launchpad.net/ubuntu/+source/grub/+bug/8497

they pretend to have fixed it.

thanks.

Comment 5 cornel panceac 2010-06-03 17:14:17 UTC
just a thing i've noticed: i've added another disk drive to my system (the second sata) and, sometimes, the installed fedora (13, now, and 12 previously) uses (R)another disk order. hence, my partitions (/dev/sdX) are no longer mounted and, this is interesting, it seems that i no longer have the hibernate option when selecting shutdown from the menu. same thing happened when there was only one pata and one sata disk drive in the computer. i wonder why these two things go together ...

Comment 6 Chuck Ebbert 2010-06-18 02:54:24 UTC
(In reply to comment #5)
> just a thing i've noticed: i've added another disk drive to my system (the
> second sata) and, sometimes, the installed fedora (13, now, and 12 previously)
> uses (R)another disk order. hence, my partitions (/dev/sdX) are no longer
> mounted

That's why we use mount-by-UUID:

UUID=93b5994b-1fa1-4474-a875-d7316b2b04dd /boot   ext3    defaults        1 2

You can also try to load the edd driver which will tell you what devices correspond to which PCI slots, if your BIOS supports EDD properly.


Note You need to log in before you can comment on or make changes to this bug.