Date:	Fri, 19 Dec 2008 14:55:26 +0100
From:	Hannes Reinecke <hare@...e.de>
To:	Seewer Philippe <philippe.seewer@....ch>
Cc:	Bernhard Walle <bwalle@...e.de>,
	Christoph Hellwig <hch@...radead.org>,
	initramfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	Kay Sievers <kay.sievers@...y.org>,
	Dave Jones <davej@...hat.com>, cjwatson@...ntu.com,
	Bernhard Walle <bwalle@...ell.com>
Subject: Re: Dracut -- Cross distribution initramfs infrastructure

Hi all,

Bernhard Walle wrote:
> * Seewer Philippe [2008-12-19 08:41]:
>> Hannes Reinecke wrote:
>> [snip]
>>> If anyone is interested I can give a short overview of it.
>> Please do so, would be appreciated.
> 
> A good start is the manual page in section 5:
> http://git.opensuse.org/?p=projects/mkinitrd.git;a=blob_plain;f=man/mkinitrd.5.txt;hb=7583c3cc047edc3e8f1a06e8b7925bd27ac0228c
> 
> (The git.kernel.org and the opensuse.org repos are basically the same,
> we just switched to opensuse.org after the internal maintainership has
> been transferred from Hannes to myself because it was easier to add
> new users there. The opensuse.org git repo site didn't exist when the
> kernel.org mkinitrd repo was created.)
> 
> Anyway:
> 
> The basic idea is to have most stuff not in the main 'mkinitrd' script
> but in modules. Each module has (normally) a setup script part that is
> executed when the initrd is created, and a boot part that is executed
> when the initrd is running. For example, NFS root is in the 'nfs-util'
> package, not in 'mkinitrd'. Same for iSCSI. Or the kdump part is
> not in the main mkinitrd but in our 'kdump' package [1]. So the main
> initrd  package is quite small but still very flexible.
> 
> It's also flexible enough to use Busybox as module that resides in the
> 'busybox' package and can then be enabled with -F busybox (feature)
> when building the initrd.
> 
> Only documentation is at the current time a bit weak, one has to fiddle
> some stuff from the sources when writing new modules. But that's easy
> to fix. :-)
> 
> Hannes may explain more ...
> 
Yes, quite so. The design principles are as follows:

The goal of the initrd is to activate and mount the root fs.
And the root fs _only_. Every other system should be configured
once the main system is running.

So mkinitrd has two parts:
a) Detect the configuration of the rootfs and create the
   initramfs
b) Configure the rootfs on boot.

Therefore there are two distinct script types:

setup-XXX.sh - run during initrd creation time to detect
  and record the configuration

boot-XXX.sh - run during boot to configure the subsystem

The setup scripts have these tasks:
- Detect the rootfs
- Unwind the storage stack and record the configuration
  on each level
- Copy the required contents into the initramfs
- Pack initramfs for use

The boot scripts have these tasks:
- Initial configuration (create required device nodes, start udev)
- Configure the storage stack
- fsck and mount the root fs

So basically the boot scripts have to be called in reverse
order to the setup scripts.
To ensure the order is preserved during each run I've
introduced some 'stages', which are run consecutively.
These stages are documented in mkinitrd.5

The neat thing here is that we've split off each
configuration into small scripts, which will be called
if present. This allows for a pretty modular setup
and avoid the massive requirement setting of an
monolithic script.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@...e.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists