Is boot.iso in todays x86_64 rawhide usable?

[John Poelstra]

Will Woods said the following on 01/24/2008 03:42 PM Pacific Time:
> 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
> 

What is the bugzilla number?

John