Description of problem: The graphical disk partitioner lists None as the type for most partitions, where the actual types are ext3, ntfs, and gpt_data. Version-Release number of selected component (if applicable): anaconda-11.5.0.36-1.i586 pyparted-2.0.9-1.fc11.i586 How reproducible: always Steps to Reproduce: 1. Compose DVD from rawhide of Tues.Mar.24 using pungi. 2. Boot DVD in install mode, choose "Create custom layout" for storage configuration. 3. Actual results: List of partitions says Type is None instead of ext3, etc. Extended partion on two drives with DOS label is identified correctly. Expected results: ext3, ntfs, ext4, and gpt data partitions that are present should be identified properly. Additional info: Disk labels are DOS (6 partitions), GPT (9 partitions), DOS (15 partitions.)
Some of the problem reproduces today with i386 boot.iso containing anaconda-11.5.0.37-1. Boot in install mode, choose "Create custom layout". Several partitions appear with Type as "None". Most of them are listed on VT1 as "udevadm settle - timeout of 2 seconds reached, the event queue contains:". Will attach anaconda.log, program.log, storage.log, syslog.
Created attachment 336680 [details] anaconda.log
Created attachment 336681 [details] program.log
Created attachment 336682 [details] storage.log
Created attachment 336683 [details] syslog
Created attachment 336688 [details] updates with longer udev settle timeout Try this updates.img and see if it helps. Let us know what happens.
There was still one filesystem listed on VT1, and its Type was None. However, the timeout was still 2, so I'm not sure that the updates.img actually changed anything. Since this is my first time using anaconda updates, I'll be very specific about what I did. Download the attachment in Comment #5. Copy it with name "updates.img" onto a USB2.0 flash memory device (VFAT), where the file appears along with several others in the root directory: ----- $ ls ## total 718MB on 1GB flash storage 090325 f10utest-root LiveOS syslinux 090325b f10utest-tmp m2a-vm_h.bin updates.img $ ls -l updates.img -rwxr-xr-x. 1 jreiser jreiser 140290 2009-03-25 12:00 updates.img $ md5sum updates.img 75461d5ba8bb9815465431f7b7c194bc updates.img ----- Boot today's i386 boot.iso, type <Tab> with cursor on first line (Install), append " updates vga=ask" to kernel command line, type <Enter> to boot. Select vga mode 0x324 (1280x1024x32). Anaconda asks to choose between /dev/sr0 (CD/DVD) and /dev/sdd (USB 2.0 flash memory device.) I choose /dev/sdd. Anaconda asks to verify partition /dev/sdd4. That's the correct one; I say OK. Anaconda spends half a minute accessing the USB storage (LED activity light), then proceeds. [This turns out to be copying all files on the flash memory into RAM.] Eventually /dev/sdc5 still has Type None, and is still listed as late in the udevadm settle; but the timeout still is 2 seconds.
Retrying with only the single file updates.img on the USB2.0 flash device: all partitions have correct Type. However, the timeout is still 2 in "cd /tmp; grep settle *". So where would any change have appeared? What did the updates.img supposedly set the timeout?
First: http://fedoraproject.org/wiki/Anaconda/Updates To verify that the updates are in effect, go to tty2 and list /tmp/updates/storage/ -- if there are several files there, the timeout should no longer be 2 seconds. If there is no /tmp/updates/storage directory the updates were specified incorrectly.
The updates.img I gave you is a compressed cpio archive, which may not work when copied onto a device via dd.
Retrying after: gzip -d < updates-492049.img | (cd USBdevice-root-directory; cpio --extract --make-directories) now gives a 'storage' directory that appears as a subdirectory in /tmp of running anaconda installer. All partitions have correct Type, and "cd /tmp; grep settle *" shows timeout was 10. So that looks like everything worked.
Closing on the basis of comment #11. Thanks for the testing.
*** Bug 493270 has been marked as a duplicate of this bug. ***