From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.2) Gecko/20040803 Description of problem: (NB - This was "FC3Test2 I2O install problem (anaconda)" on fedora-test-list, but I accidentally posted with an in-reply-to header, meaning it got incorrectly threaded on the list archive.) Device inodes for detected existing partitions are not being created correctly in all cases - specifically those cases where the device inode occupies a subdirectory under /proc, does not have a "c?d?p?" naming convention, and is not iseries. During the install of FC3 Test 2 onto an I2O controller with existing partitions present on it, instead of: /dev/i2o/hda 80, 0 /dev/i2o/hda1 80, 1 ... /dev/i2o/hda9 80, 9 Anaconda is generating: /dev/i2o/hda 80, 0 /dev/i2o/hdap1 80, 0 ... /dev/i2o/hdap9 80, 0 causing the install to fail with no drives found. Creating the devices manually allows the install to proceed as normal: mknod /dev/i2o/hda1 b 80 1 mknod /dev/i2o/hda2 b 80 2 ... mknod /dev/i2o/hda9 b 80 9 isys/devnodes.c, devMakeInode() cannot determine minor device number since devName[7] is always 'p' - Assuming fsset.py formatDevice() is correct, the bug appears to be in loader2/getparts.c, isPartitionName() where it falsely assumes that any device subdirectory other than iseries follows "c?d?p?" naming convention. Version-Release number of selected component (if applicable): anaconda-10.0.2-4 How reproducible: Always Steps to Reproduce: 1. Partition a drive on an I2O controller 2. Attempt to install Fedora Core 3 Test 2 3. Actual Results: Installer exits with no disk drive found. Expected Results: I2O partitions correctly detected. Additional info:
Created attachment 104199 [details] Suggested fix Instead of excluding devices that don't have the form c?d?p?, just include those that do.
Created attachment 104200 [details] Exclude recognising i2o controller as "c?d?p?" format less likely to break exisiting anaconda behaviour? NB - neither of these patches have been tested, I don't currently have a build system capable of generating the latest anaconda, so take as "simple one line suggestions, untested" - I'm not even sure if this *is* the problem! Once I have a build system up and running, I can test and verify further if required.
Created attachment 104201 [details] Exclude recognising i2o controller as "c?d?p?" format either/or - this one is less likely to break exisiting anaconda behaviour. NB - neither of these patches have been tested, I don't currently have a build system capable of generating the latest anaconda, so take as "simple one line suggestions, untested" - I'm not even sure if this *is* the problem! Once I have a build system up and running, I can test and verify further if required.
Created attachment 104231 [details] Revised fix Apologies - it looks like the bug is actually in iutil.py - makeDriveDeviceNodes() is erroneously explicitly adding a 'p' seperator to i2o hard drive device nodes - rather than take a shotgun-in-the-dark approach, I'll just offer one more suggested patch to this, will confirm after I have a platform capable of rebuilding FC3t2 and/or CVS anaconda.
A combination of the patches in comment #3 and comment #4 look right to me. Applied in CVS. (I don't have hardware to test, unfortunately -- you should be able to use an updates.img where you just copy the updated python files to a floppy and boot with 'linux updates' to test the patch in comment #4. #3 is definitely right)
Yup, the suggestion in comment #2 was incorrect - directory seperator should follow, not proceed device directories in the substring match. That aside - using an update floppy I can confirm that the python update fixes the problem, so that's alright then. =)
Original reporter confirmed the fix. closing as resolution rawhide