From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-13smp-MO i686; Nav)
Description of problem:
If your system has a scsi boot device, eventually there will be an initrd image
which will cause the scsi devices to be numbered (from a), upon boot (this is
The problem (during installation) is that if you have a usb storage device that
happens to be plugged in, then the usb probe (which happens _before_ the scsi
probe) will see the usb device, and number that device as "sda". Later on, once
you get into disk druid, your scsi devices will be numberes with the usb_storage
device as sda, and your 1st scsi device as "sdb" - this does not reflect a post
install configuration, as
post-install, the initrd will generally force the scsi devices to number from
It seems that there could be significant problems getting a system
booted/running after the installation, due to the mis-numbering. (e2labels will
forgive alot of problems, but there is always tle lilo.conf/grub.conf file,
which will be wrong).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. plug a usb-storage device into the usb port. (e.g. a san-disk reader)
2. boot the red hat installer
3. go to dusk druid. observe that the disk layout begins from sdb
Expected Results: the scsi disks should have been labeled first, and the
usb-storage should have been labeled after the scsi devices.
I think that by moving the usb probe to after the scsi probe, this will
circumvent the situation.
Thought we fixed this already - jeremy?
This should be happening already unless it broke merging to head... I'll have
to check a bit later
Bleah, broken by dropping rmmod support from the loader modutils. notting's
working on it
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.