initramfs howto?

initramfs howto?

[Chris Meadors]

I've been a monolithic kernel guy forever.  But with all the new toys
going into 2.6 I figured I'd try to catch up with the times.

I've got udev + hotplug halfway functioning, and wanted to try moving
even my fs and IDE/SCSI modules out of the kernel.  It seems the way to
do that is with an initramfs.

So I figure I'll start simple, I got klibc and built it.  Copied the the
lib and executables into a new tree, lib in lib and bins in bin.
Symlinked linuxrc to /bin/sh.  I also added a dev directory with ram0,
ram1, and initrd (later in my experimentation).  Then I cpio'd up the
tree, gzip'd it, and put it where I told grub to find it:
 "initrd (hd0,0)/boot/test/initramfs.cpio.gz"

When I boot the kernel associated with that initrd line, it says that it
found a compressed image at block 0.  But then panics saying it can't
mount the root filesystem.

I've tried various root= options.
>From /dev/ram0, /dev/ram1, /dev/initrd, and initramfs.  All fail.
Although /dev/ram0, spit out its own name instead of an unknown block
device 0,0.

So, what am I missing?  I've Googled for about an hour now.  Everyone is
just talking about the neat new features of initramfs, but no one says,
"do this".  The in-tree documentation isn't much better, although it is
what got me this far.  The early-userspace document talks about
short-circuting the kernel build to get a custom initramfs appended to
the kernel image.  But that seems a bit rough, shouldn't the bootloader
be able to do the appending?

Any help will be welcomed.

-- 
Chris

Re: initramfs howto?

[Bryan O'Sullivan]

On Thu, 2004-04-08 at 12:17, Chris Meadors wrote:

> Then I cpio'd up the
> tree, gzip'd it, and put it where I told grub to find it:
>  "initrd (hd0,0)/boot/test/initramfs.cpio.gz"

Did you use a newc-format cpio archive?  Sounds like yes, but I want to
be sure.

> When I boot the kernel associated with that initrd line, it says that it
> found a compressed image at block 0.  But then panics saying it can't
> mount the root filesystem.

You need a patch to force the kernel not to bother trying to mount a
root filesystem.  This has been floating around for a while somewhere. 
If you don't use this patch, the kernel won't fall through to initramfs
and panics instead, as you are seeing.

Ooh, I see that Olaf Hering has a recent variant of this patch which is
in -aa kernels.  Andrew, can you consider dropping this into -mc or -mm,
please?  It won't break normal operation, but will relieve the pain of
the not-yet-battle-scarred.  It's less fugly than the earlier dev=0:0
patch.  Maybe.

http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.6/2.6.5-rc3-aa1/initramfs-search-for-init

	<b

Re: initramfs howto?

[Miles Bader]

"Bryan O'Sullivan" <bos@serpentine.com> writes:
> Ooh, I see that Olaf Hering has a recent variant of this patch which is
> in -aa kernels.  Andrew, can you consider dropping this into -mc or -mm,
> please?  It won't break normal operation, but will relieve the pain of
> the not-yet-battle-scarred.  It's less fugly than the earlier dev=0:0
> patch.  Maybe.
> 
> http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.6/2.6.5-rc3-aa1/initramfs-search-for-init

If you use that, can you just keep using the initial initramfs as your
root fs forever?  That'd be swell for embedded systems...

If so, it'd be nice if it checked for some other name than /init
(e.g. /sbin/init) -- there's too much crap in / already.

Thanks,

-Miles
-- 
I'd rather be consing.

Re: initramfs howto?

[Bryan O'Sullivan]

On Thu, 2004-04-08 at 23:48, Miles Bader wrote:

> If you use that, can you just keep using the initial initramfs as your
> root fs forever?  That'd be swell for embedded systems...

You could do so, yep.

> If so, it'd be nice if it checked for some other name than /init
> (e.g. /sbin/init) -- there's too much crap in / already.

I'm agnostic.  It's a two-line patch.  I don't care if it's called
/spam/fandango/wubble, so long as the brave souls who are trying out
initramfs don't keep stumbling over the same problem again and again :-)

	<b

Re: initramfs howto?

[Miles Bader]

On Fri, Apr 09, 2004 at 10:21:39AM -0700, Bryan O'Sullivan wrote:
> > If so, it'd be nice if it checked for some other name than /init
> > (e.g. /sbin/init) -- there's too much crap in / already.
> 
> I'm agnostic.  It's a two-line patch.  I don't care if it's called
> /spam/fandango/wubble, so long as the brave souls who are trying out
> initramfs don't keep stumbling over the same problem again and again :-)

Indeed; I just wanna raise the point before people start actually using /init
in large numbers...

I wonder if you could move the bulk of stuff (the console open, the calls to
run_init_proces) that happens after prepare_namespace into a separate
function and attempt to call it both before and after prepare_namespace; the
problem seems to be the unlock_kernel &c., which I gather must be done after
prepare_namespace?

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: initramfs howto?

[Chris Lingard]

On Friday 09 April 2004 6:21 pm, Bryan O'Sullivan wrote:
> On Thu, 2004-04-08 at 23:48, Miles Bader wrote:

> I'm agnostic.  It's a two-line patch.  I don't care if it's called
> /spam/fandango/wubble, so long as the brave souls who are trying out
> initramfs don't keep stumbling over the same problem again and again :-)

May I suggest

diff -Naur linux-2.6.5.old/init/main.c linux-2.6.5/init/main.c
--- linux-2.6.5.old/init/main.c 2004-04-05 18:19:04.000000000 +0100
+++ linux-2.6.5/init/main.c     2004-04-18 15:37:56.000000000 +0100
@@ -604,7 +604,12 @@
        smp_init();
        do_basic_setup();

-       prepare_namespace();
+       /*
+       * check if there is an early userspace init, if yes
+       * let it do all the work
+       */
+       if ( ! sys_access("/linuxrc", 0) == 0)
+               prepare_namespace();

        /*
         * Ok, we have completed the initial bootup, and

linuxrc already exists for initrd systems, and is coded in anyway.

I have tested this with both with both linuxrc -> bin/ash
and with a script that brings up a full system.  (I have made
a boot CD that installs Linux-2.6.5 with udev)

Chris Lingard

Re: initramfs howto?

[H. Peter Anvin]

Followup to:  <200404192048.29666.chris@ukpost.com>
By author:    Chris Lingard <chris@ukpost.com>
In newsgroup: linux.dev.kernel
> 
> linuxrc already exists for initrd systems, and is coded in anyway.
> 

NO NO NO NO NO NO NO NO NO NO NO ...

Calling it /linuxrc instead of /sbin/init was a bad idea to begin with
.. let's not make it worse by making it magic...

	-hpa

initramfs howto?

[Sledz, Steffen]

We want to use a little initramfs for our machine (hipox
with linux-2.6.24) to load some modules. I've found some
samples (e.g. initramfs-image.bb). But the usage is totally
unclear to me.

Is there a little howto/tutorial how to create an initramfs
with oe?

Steffen

Re: initramfs howto?

[Tom Rini]

On Fri, Apr 17, 2009 at 06:18:19PM +0200, Sledz, Steffen wrote:

> We want to use a little initramfs for our machine (hipox
> with linux-2.6.24) to load some modules. I've found some
> samples (e.g. initramfs-image.bb). But the usage is totally
> unclear to me.

I don't think that out of the box, "load some modules" can work.  The
current initramfs stuff, if I read it right, makes use of a premade
cpio.  It should however, be possible to fix this up, with the hardest
part being fixing up of the dev nodes.  What follows is a hack I've done
to a specific kernel's do_compile:

# We need to make an initramfs.  First step, extract the
# initramfs
# contents, minus modules.
mkdir -p rootfs/dev
fakeroot tar -C rootfs -xf ${DEPLOY_DIR_IMAGE}/myinitramfs.tar

# Second, build first kernel and modules.
oe_runmake ${KERNEL_IMAGETYPE} modules CC="${KERNEL_CC}" LD="${KERNEL_LD}"

# Third, install modules
oe_runmake DEPMOD=`which ${TARGET_PREFIX}depmod-2.6` \
  INSTALL_MOD_PATH="rootfs" modules_install

# Fourth, make the cpio list AND add in /dev/null and
# /dev/console
sh ./scripts/gen_initramfs_list.sh rootfs > rootfs.list
echo "nod /dev/console 0600 0 0 c 5 1" >> rootfs.list
echo "nod /dev/null 0666 0 0 c 1 3" >> rootfs.list

# Fifth, build a kernel with the full initramfs.
sed -i -e 's|\(CONFIG_INITRAMFS_SOURCE\)=""|\1="rootfs.list"|g' .config
echo "CONFIG_INITRAMFS_ROOT_UID=`id -u`" >> .config
echo "CONFIG_INITRAMFS_ROOT_GID=`id -g`" >> .config
oe_runmake ${KERNEL_IMAGETYPE} CC="${KERNEL_CC}" LD="${KERNEL_LD}"

And I also put in:
# For our initramfs.  It must exist and if we clean this, we should
# clean that.
do_compile[depends] += "myinitramfs-image:do_rootfs"
do_clean[depends] += "myinitramfs-image:do_clean"

This should somehow be generalized a bit and put into kernel.bbclass,
quite probably.

-- 
Tom Rini

Re: initramfs howto?

[Sledz, Steffen]

> I don't think that out of the box, "load some modules" can work.  The
> current initramfs stuff, if I read it right, makes use of a premade
> cpio.  It should however, be possible to fix this up, with the hardest
> part being fixing up of the dev nodes.  What follows is a 
> hack I've done to a specific kernel's do_compile:

Would be really nice if you can send me the complete bb as an example (or is it in the git repo?). Some things are not fully clear to me.

> This should somehow be generalized a bit and put into kernel.bbclass,
> quite probably.

That would be a great thing! :)

Steffen

Re: initramfs howto?

[Andrea Adami]

You can look at the initramfs-kexecboot image for a really slim initramfs.

Regards

Andrea

Re: initramfs howto?

[Tom Rini]

On Mon, Apr 20, 2009 at 05:21:46PM +0200, Sledz, Steffen wrote:
> > I don't think that out of the box, "load some modules" can work.  The
> > current initramfs stuff, if I read it right, makes use of a premade
> > cpio.  It should however, be possible to fix this up, with the hardest
> > part being fixing up of the dev nodes.  What follows is a 
> > hack I've done to a specific kernel's do_compile:
> 
> Would be really nice if you can send me the complete bb as an example (or is it in the git repo?). Some things are not fully clear to me.

This is actually something I did in an older snapshot for a customer.
The only part of the normal do_compile I left was the part to unset
flags and make the first header.

-- 
Tom Rini

Re: initramfs howto?

[Sledz, Steffen]

I'll try to sort my thoughts a little bit. Our final target is this constellation:

* Kernel-A with Rootfs-A on an UBIFS (without initramfs) shall be able to start Kernel-B using kexec.

* Kernel-B with Rootfs-B on initramfs shall be able to start Kernel-A using kexec.

Both kernels do have associated modules.

As i understand OE i have to build two images (for Rootfs-A and Rootfs-B). But ...

(a) How do i tell those images which kernels (and as a consequence which modules) are associated with it?

(b) How do i build Kernel-B with it's initramfs?

The mentioned initramfs-kexecboot-image looks to me like a target to build an initramfs. But this does not contain any modules. So it does not involve one of the main questions.

The sample recipe code from Tom looks like a solution for (b) which expects another recipy myinitramfs-image for building myinitramfs.tar. But the answer to (a) is still unclear to me.

Steffen

PS: The kexec stuff is no problem.

Re: initramfs howto?

[Roman I Khimov]

On Wednesday 22 April 2009 11:45:38 Sledz, Steffen wrote:
> Both kernels do have associated modules.
>
> As i understand OE i have to build two images (for Rootfs-A and Rootfs-B).
> But ...
>
> (a) How do i tell those images which kernels (and as a consequence which
> modules) are associated with it?
>
> (b) How do i build Kernel-B with it's initramfs?

As I understand it's not possible to build multiple kernels currently in OE, 
as the packages will be named as "kernel-*" and if versions are the same 
you'll get something completely unusable. Even if not, you'll need to be very 
careful to get it working right.

We're doing multikernel builds here, but in sort of primary-secondary fashion, 
I've split kernel.bbclass into kernel.bbclass and kernel_base.bbclass so that 
kernel.bbclass works exactly as it worked before split, but if you use 
kernel_base the packages won't be renamed, so if you have "linux-smth" recipe 
you'll get "linux-smth-*" packages. Although I should note that our secondary 
kernel doesn't have any modules and we're installing both of them on one 
image.

I can try to make a patch for current OE if interested, unfortunately we 
diverged a little from time overlay was made, so patches from overlay don't 
apply easily. 

Re: initramfs howto?

[Andrea Adami]

>The mentioned initramfs-kexecboot-image looks to me like a target to build an initramfs. But this does
>not contain any modules. So it does not involve one of the main questions.

Including /conf/machine/include/kexecboot.inc in the machine.conf we
obtain the result of having one extra kernel built in the same image.

EXTRA_IMAGEDEPENDS += "linux-kexecboot"

You can create your own recipe linux-kexecboot like and populate the
cpio.gz as you like. The a.m. image must be as small as possible, thus
kblic, no shell and no modules, just a custom binary as /init.

BTW it is even possible to concatenate the modules (at the end) of the
cpio, after creating it.

Regards

Andrea

Re: initramfs howto?

[Tom Rini]

On Wed, Apr 22, 2009 at 12:49:07PM +0400, Roman I Khimov wrote:
> On Wednesday 22 April 2009 11:45:38 Sledz, Steffen wrote:
> > Both kernels do have associated modules.
> >
> > As i understand OE i have to build two images (for Rootfs-A and Rootfs-B).
> > But ...
> >
> > (a) How do i tell those images which kernels (and as a consequence which
> > modules) are associated with it?
> >
> > (b) How do i build Kernel-B with it's initramfs?
> 
> As I understand it's not possible to build multiple kernels currently in OE, 
> as the packages will be named as "kernel-*" and if versions are the same 
> you'll get something completely unusable. Even if not, you'll need to be very 
> careful to get it working right.

The workaround here (and this was OK for our needs) was that the 2nd
kernel doesn't make any packages, just deploys the final kernel.
Indeed what I posted should be good for (b), with the caveat that you
need to either not use kernel.bbclass or hack out a second
kernel.bbclass that doesn't make any packages.  If you need this kernel
to be put automagically inside the rootfs you'll need to do something
like this in rootfs-a.bb:
ROOTFS_POSTPROCESS_COMMAND += "cp ${DEPLOY_IMG_DIR}/kernelB
${IMAGE_ROOTFS}/boot/"

-- 
Tom Rini