Description of problem: Booting rescue mode takes three minutes of cpu time to construct the list of partitions to rescue, and another three minutes to mount the selected partition as /mnt/sysimage. The box has 3 SATA disks with (6 + 9 + 15) partitions; two "basic" (DOS) partition tables, one GPT (GUID Partition Table), no LVM at all (Linux Volume Manager version 1 or 2). Version-Release number of selected component (if applicable): anaconda-11.5.0.19 How reproducible: always Steps to Reproduce: 1. boot rescue mode of boot.iso netinst CD-ROM 2. Select default language, keyboard, etc. 3. Actual results: Gettting to the dialog box to select the system to rescue (the root partition, which requires identifying all the eligible partitions) takes three minutes. Mounting that partition as /mnt/sysimage takes an additional three minutes. The hardware activity light for the disk controller is ON almost all the time during those six minutes, and the rescue CD-ROM is not spinning at all. Expected results: The budget should be no more than 1 second per partition (that's 100 seeks [one hundred]). Additional info: Timing was by "ps ax" on alternate screen (Ctrl-Alt-F2) and verified by external wristwatch.
Yeah, it's pretty slow for me today too. We definitely intend to look into the speed problems with the new pyparted, but we first wanted to make sure it was correct.
We've made some improvements both in avoiding unnecessary type conversions and in caching results, so the next build of anaconda and pyparted should show a decent amount of improvement. Please test the next build (which should be within the next couple of days) and let me know if it's acceptable for you, or if it's still unreasonably slow. If it's still slow, we're going to have to dive in more deeply to get it straightened out.
Today's boot.iso rescue mode (Thursday, 2009-03-05) is broken even worse. It says, "You don't have any Linux partitions." Nevertheless, running fdisk and parted from the shell can find all (6+9+15) of the partitions. Only one is NTFS with Vista. All others are ext3 or swap, with at least 8 Fedora root partitions, all the way from FC6 through F11alpha. This happens on both i386 and x86_64. Anaconda announces itself as version 11.5.0.24.
We've merged all the rest of the storage code into rawhide, which is probably what you are seeing. It's worth filing a new bug against anaconda for that as it's likely got nothing to do with pyparted.
Please test the Fedora 11 Beta release when it becomes available to see if this problem is still happening for you.
Rescue mode of Fedora-11-Beta-i386-DVD.iso detects the 30 partitions in about 12 seconds. anaconda-11.5.0.38.