Description of problem: I built up new DVD image from the latest development tree and installed os on my ia64 box by hard drive method. The installation failed. Version-Release number of selected component (if applicable): anaconda-11.2.0.9-1 How reproducible: Reproduce everytime when installing it. Steps to Reproduce: 1.Rebuilup dvd image from the latest development tree; 2.Copy the image to anb ext3 partition of the ia64 machine; 3.Install os on the machine by choosing Hard drive method; Actual results: A window is poped up to say: Failed to read directory /tmp/hdimage/root/work: No such file or directory. Device /dev/sdb2 doesn't appear to contain Fedora Core for ia64 CDROM images. Expected results: The installation could go on. Additional info:
I checked the log and found the mount failed. Just after I chose hard drive method, a window could show all partitions. I could choose a partition and input directory. It looks like partition mount failed.
How did you build the images? Does the stamp from the stage2 match that of the kernel/initrd used for booting?
I built with script buildos written by Prarit. The stamp does match with each other. I think it might be the same problem like #223750.
I put the image on an ext3 partition. anaconda doesn't insert ext3 module before trying to mount the partition.
I have the same problem on FFC7T1.
Yes you're correct - it's because the ext3 module is not getting loaded early enough. For now you can either use an ext2 or vfat partition instead. This should be fixed for test 2.
Actually, it is not possible through anaconda to create / format / install fedora on a ext2 partition. And I can't imagine doing so on a vfat file system. Is there a regression ?
You can make an ext2 or vfat partition to store the ISO images on, and then test 1 anaconda will be able to find them. You should be able to create any kind of filesystems you like in anaconda for installation since the ext3 module will be loaded by then. It's just a question of what the images are stored on in the very beginning.
*** Bug 228777 has been marked as a duplicate of this bug. ***