Red Hat Bugzilla – Bug 223749
Installing os by hard drive method failed
Last modified: 2007-11-30 17:11:53 EST
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):
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;
A window is poped up to say:
Failed to read directory /tmp/hdimage/root/work: No such file or
Device /dev/sdb2 doesn't appear to contain Fedora Core for ia64 CDROM images.
The installation could go on.
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
*** Bug 228777 has been marked as a duplicate of this bug. ***