lkml.org 
[lkml]   [2004]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.6.10-rc1 initramfs busted [u]
From
Date
On Sat, 2004-10-23 at 21:36 +0100, Russell King wrote:
> On Sat, Oct 23, 2004 at 02:42:08PM +0200, Martin Schlemmer [c] wrote:
> > On Sat, 2004-10-23 at 13:31 +0100, Russell King wrote:
> > > A build using O= does this:
> > >
> > > HOSTCC usr/gen_init_cpio
> > > GEN_INITRAMFS_LIST usr/initramfs_list
> > > Using shipped usr/initramfs_list
> > > CPIO usr/initramfs_data.cpio
> > > ERROR: unable to open 'usr/initramfs_list': No such file or directory
> > >
> > > Usage:
> > > ./usr/gen_init_cpio <cpio_list>
> > >
> > > <cpio_list> is a file containing newline separated entries that
> > > describe the files to be included in the initramfs archive:
> > >
> > > The source tree contains this in usr:
> > >
> > > -rw-r--r-- 1 rmk rmk 1657 Oct 23 11:41 Makefile
> > > -rw-r--r-- 1 rmk rmk 8335 Oct 23 11:41 gen_init_cpio.c
> > > -rw-r--r-- 1 rmk rmk 1024 Aug 1 2003 initramfs_data.S
> > > -rw-r--r-- 1 rmk rmk 146 Oct 23 11:41 initramfs_list
> > >
> > > and the build tree usr contains:
> > >
> > > -rwxr-xr-x 1 rmk rmk 10834 Oct 23 13:29 gen_init_cpio
> > > -rw-r--r-- 1 rmk rmk 0 Oct 23 13:29 initramfs_data.cpio
> > >
> > > Running with V=1 shows:
> > >
> > > make -f /home/rmk/build/linux-v2.6-local/scripts/Makefile.build obj=usr
> > > echo Using shipped usr/initramfs_list
> > > Using shipped usr/initramfs_list
> > > ./usr/gen_init_cpio usr/initramfs_list > usr/initramfs_data.cpio
> > > ERROR: unable to open 'usr/initramfs_list': No such file or directory
> > >
> > > so it's referencing the wrong directory.
> > >
> >
> > Yep. Please see the
> >
> > [PATCH 2.6.9-bk7] Select cpio_list or source directory for initramfs image updates
> >
> > thread for latest patch to fix this and other issues. There are some
> > other patches floating around that is slightly smaller, but I would
> > appreciate testing and feedback.
>
> There's this obvious error in the patch (missing 'i'):
>
> +$(obj)/$(initramfs_list): FORCE
> + $(if $(nitramfs_list_state_uptodate),, \
>

Ah, thanks!. Should not matter though, as we do nothing with
uptodate currently.

> though I am wondering why this looks rather complicated.
>

I guess I can drop the uptodate $(if, as we only really need to check
outofdate and missing, but I was not sure if anybody wanted to print or
do something on uptodate ...

Or is it not the nested $(if's you are referring to?


thanks,

--
Martin Schlemmer

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.038 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site