Is boot.iso in todays x86_64 rawhide usable?

[Will Woods]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20080124/3814a1bf/attachment.sig>