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 post installation). 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 "sda". 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): How reproducible: Always 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. Additional info: 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
Fixed
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.