Red Hat Bugzilla – Bug 412111
Install from Live Image fails with ext2 live images
Last modified: 2008-02-07 16:54:47 EST
Description of problem: I have created a new Fedora spin 'EeeDora' specifically for the EeePC. The Live Image boots fine (very fine). Live install works in manual mode, but with a kickstart file (I'd like to make this completely automatic) Anaconda goes through the installation (writing packages=100%), but gives an exception in the last stages. This leaves the machine in an unusable state (if booting without the Live image) Version-Release number of selected component (if applicable): Fedora 8 + all updates How reproducible: Every time - Steps to Reproduce: 1. Run anaconda with live install, and kickstart file 2. See disks partitioned, and packages written 3. In finalizing step, Anaconda throws exception Actual results: Bootable install Expected results: Grub does not load Additional info: Exception report from anaconda attached
Created attachment 278371 [details] Anaconda Exception thrown
Of course I meant : Expected results: Bootable install Actual results: Grub does not load Sorry.
Actually, based on something that someone just filed... can you try manually loading the ext2 module and see if that helps?
I think we've got to the bottom of this on the mailing list. The issue is that livecd-creator (and mayflower) has the assumption that the rootfs img should be ext3 (and called ext3fs.img). liveinst block copies the filesystem 8Mb at a time without checking whether the partition fstypes are the same. This can be fixed 2 ways : (a) allow livecd-creator/mayflower to use ext2 images (which is the route I took); and (b) fix liveinst to copy partitions file-by-file if the partition fstypes don't match.
Fixed things up in git so that the creation works correctly as well as the installation.
Thanks for the fix - I just realized that I didn't explain the reason this was important : The EeePC has a Flash main drive, which has limited write-cycles : and a journaling fs (eg: ext3) would tend to wear the drive out quicker than something like ext2. Thanks again Martin :-)