Red Hat Bugzilla – Bug 187858
An i386 LiveCD created on an x86_64 builder is not bootable
Last modified: 2007-11-30 17:11:29 EST
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
Steps to Reproduce:
1. On an x86_64 machine, build kadischi from cvs
3. Create a LiveCD with this build pointing at a 32bit repository.
4. Boot with the created disk.
The generated livecd panics the kernel with the above error.
Working 32bit livecd.
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.
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?
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