Bug 431638 - anaconda switches the sda and sdb names
anaconda switches the sda and sdb names
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-05 23:41 EST by cornel panceac
Modified: 2008-08-06 12:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-06 09:44:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
grub was supposed to be on sda6 (54.75 KB, image/png)
2008-02-08 11:28 EST, cornel panceac
no flags Details
choosing the drive to boot from (55.00 KB, image/png)
2008-02-08 11:30 EST, cornel panceac
no flags Details

  None (edit)
Description cornel panceac 2008-02-05 23:41:08 EST
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
Comment 1 Jeremy Katz 2008-02-06 11:53:15 EST
Drive names are (largely) at this point pretty meaningless.  What exactly is the
problem that you're seeing as a result?
Comment 2 cornel panceac 2008-02-06 12:04:18 EST
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
Comment 3 Jeremy Katz 2008-02-08 09:09:06 EST
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).
Comment 4 cornel panceac 2008-02-08 10:33:20 EST
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.
Comment 5 cornel panceac 2008-02-08 11:28:30 EST
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.
Comment 6 cornel panceac 2008-02-08 11:30:03 EST
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).
Comment 7 cornel panceac 2008-03-25 15:36:09 EDT
stays true for f9beta livecd. as usual, after install, fedora sees them the
other way.
Comment 8 cornel panceac 2008-03-28 15:10:23 EDT
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
Comment 9 cornel panceac 2008-03-28 15:15:34 EDT
_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.
Comment 10 cornel panceac 2008-04-18 13:05:19 EDT
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.
Comment 11 Bug Zapper 2008-05-14 01:01:04 EDT
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
Comment 12 Joe Bayes 2008-05-14 20:11:26 EDT
Could this be related to bug 246295 from back in the Fedora 7 days?

Comment 13 Chris Lumens 2008-05-15 13:09:50 EDT
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.
Comment 14 cornel panceac 2008-06-08 07:57:38 EDT
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
Comment 15 cornel panceac 2008-08-06 00:47:00 EDT
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!
Comment 16 Chris Lumens 2008-08-06 09:44:22 EDT
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.
Comment 17 cornel panceac 2008-08-06 12:22:51 EDT
thnx chris, i hope this time i got the message.

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