Description of problem: I have an x86_64 builder and am trying to build an i386 LiveCD. Once built, the liveCD errors out in the boot proccess with: > > VFS: Mounted root (ext2 filesystem). > > EXT2-fs: unable to read superblock > > isofs_fill_super: bread failed, dev=md1, iso_blknum=16, block=32 > > Kernel panic - not syncing: VFS: Unable to mount root fs on > > unknown-block(9,1) Version-Release number of selected component (if applicable): CVS as of April 3, 2006 How reproducible: Every time. Steps to Reproduce: 1. On an x86_64 machine, build kadischi from cvs 2. Install. 3. Create a LiveCD with this build pointing at a 32bit repository. 4. Boot with the created disk. Actual results: The generated livecd panics the kernel with the above error. Expected results: Working 32bit livecd. Additional info: This happens in both vmwareplayer and when burned to a cd. We've done some work on what 64bit applications are being moved into the livecd. From within kadischi: scanswap and find-live-cd. The error persists even when these are changed. From outside kadischi, we've so far identified busybox.anaconda. Need to test what happens when changing that. Future: Thinking ahead to when we build and package kadischi in Extras, I think we need to create separate tarballs for kadischi's driver files and kadischi's installable files. So scanswap, find-live-cd, and linuxrc will go into a separate tarball from livecd_generator, lib, and post_install_scripts. This will allow packagers to create a kadischi package that matches the builder's architecture (or, currently, noarch) and a kadischi-data.i386 package that must match the generated livecd. Within kadischi we can either require that the the builder has a copy of the kadischi-data and anaconda-runtime for the target arch in a kadischi-known area or that these packages must be in the repository of software to be installed onto the livecd. Opinions on which of these are cleaner?
We've moved to using an initramfs which eliminates the need to mount an Ext2 filesystem for the initrd. Would you please retest with Kadischi from CVS and confirm this issue does not exist, or still exists with the new code? Thanks.
Ping ?
I haven't had a chance to look at the new kadischi but the initramfs might fix the VFS problem. We've finished the server portion of our usage of livecd's here at my work and I'm discussing with my boss if he can let me start working on a Fedora/kadischi version of the client-side, liveCD again. I should find out next week if I can devote any work time to testing this. Have the scanswap, find-live-cd, and linuxrc problems been addressed as well? (ie: compiled programs need to be pulled in according to the repository that is being built, not the host system.) It seems that the best way to deal with this is to create an rpm with those files in it and then require that rpm be in the repository that kadischi uses to create the liveCD. Then kadischi can pull the files from that rpm. If both of those have been addressed you might as well close this bug and I can open a new one if testing reveals that there are still issues.
I guess from now on we should market pungi