On Thu, 2008-01-24 at 12:15 -0500, Will Woods wrote: > On Thu, 2008-01-24 at 11:41 -0500, Clyde E. Kunkel wrote: > > Clyde E. Kunkel wrote: > > > Fails for me with : > > > > > > Failed to execute /init > > > Kernel panic - not syncing: no init found. Try passing init= option to > > > kernel. > > > > > > > Well, makes no difference since install is underway using the rescue iso. > > > > Is a bz needed, tho, for todays x86_64 boot.iso? > > Happens on i386 too. We're looking into it. I'm a little baffled. I checked the initrd and the reason /init won't load is.. there are no libraries on the initrd. (Yes, we're using dynamically-loaded binaries in initrd now). So I hacked up pungi to enable --debug on buildinstall (the script that builds the images) and I get the following output: DSO_DEPS for /usr/lib/anaconda-runtime/loader/init are Gosh. Yep, seems like there should be some libraries listed there. Like libc, maybe. Checking the code for buildinstall, I find get_dso_deps in buildinstall.functions. It uses a chroot and some ld.so hackery to figure out what libraries a binary wants to load. But there's no ld-linux.so.* in /lib on the initrd, so this fails, so we get no deps. Okay, that makes sense. So it seems like mk-images would need something like: cp -Lfp $IMGPATH/LIBDIR/ld*.so $MBD_DIR/$LIBDIR/ before any call to instbin (which calls get_dso_deps, which requires ld.so to work right). What *doesn't* make sense is: how did this ever work before? Neither mk-images nor buildinstall* has been modified in the past week. So yeah. I obviously don't understand the problem well enough to solve it. But I hope this information is useful to someone smarter than me. -w
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
