[ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Erik van Konijnenburg]

OK, time to stop polishing and start publishing.

This is to announce yaird, Yet Another mkInitRD, a rewrite of mkinitrd
based on hotplug algorithms.

MOTIVATION
=====
Why a rewrite?  The versions of mkinitrd that I studied, Debian sid
and Fedora FC3, have some problems: they capture a lot of knowledge
about the boot process, but don't always understand when a new kernel
uses a different module name than the old kernel, may rely on modules
compiled into the kernel, and don't always catch errors at the earliest
opportunity.

Assumption: there are three issues that cause most of these problems.
 - Backward compatibility: sysfs provides a wealth of information
   about hardware, but if you have to support 2.4 kernels, you have
   to limit yourself in the use you can make of that information.
 - Originality: hotplug does a pretty good job of finding the appropriate
   modules for a device, basically because it closely follows the
   algorithms the kernel uses for matching hardware with modules.
   Deviating from those algorithms is unlikely to produce a more
   robust result.
 - Shell scripting: beyond a certain level of complexity, the shell
   syntax makes it difficult to focus on the data structures you're
   trying to process and makes it difficult to do rigorous error checking.

Yaird is intended to find out whether that assumption is correct: if so, 
a program to build initrd images will be more reliable if it's written
in perl, if it uses sysfs to determine what hardware needs to be supported,
and if it closely follows the methods hotplug uses find the modules
needed to support some hardware.

STATUS
===
There is working code: yaird booted the machine this note is written on.
Code is available online, there also is a paper that discusses the workings
of the application in detail.

	http://www.xs4all.nl/~ekonijn/yaird/

So far, the program works correctly on every machine it's been tested on,
but with only two test boxes that does not mean much.

Basic creature comforts are in place: "configure; make" but no RPM or
deb files, a README and help option but no manual page.

Features:
 - understands SATA and IDE.  USB sticks and SCSI should work, but are
   untested.
 - understands MDADM and LVM2, activates only necessary devices,
   understands stacks like LVM on top of stripe on top of mirror.
 - handles both initrd and initramfs.
 - understands USB keyboards.
 - understands hotplug blacklist.
 - knows that a module compiled into the kernel does not need insmod.
 - understands /etc/fstab, including niceties such as labels, uuids and
   octal escapes.
 - image generation understands symbolic links and shared libraries.
   (should support 32bit emulation on 64bit kernels; untested).
 - templating system to simplify tuning the initrd image to the distribution.
 - avoids hard-coded device numbers; does not require devfs.
 - testing mode gives detailed overview of the systems hardware
   and the modules needed to support that.

There are rough edges in practically every feature: this is suitable
for testing, but not for production use.

TODO
==
(1) Testing so far is 100% successful, but with just two boxes to play
with, that's not saying much.  If you can find space to test the code
on your system, your results are highly appreciated.  At this point,
hardware testing is most valuable: I already know that dm-crypt is
unsupported for now, but whether this stuff can boot a powerbook, sparc,
or just about anything else is an open question.

(2) Feedback.  This may be an interesting idea, but how does it relate
to other new stuff floating about?  In particular, what about the work
that's going on putting udev on initramfs: are these approaches complementary
or alternatives?  Different perspectives on where this stuff fits in would
help.

(3) Support more configurations.  dm-crypt is unsupported for now, and so
are multipath, swsusp, EVMS, NFS and loopback mounts.  Implementing this
stuff becomes interesting once there are some tests results that the
basic ideas work in practice.

Regards,
Erik




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Jeff Garzik]

Erik van Konijnenburg wrote:
> Features:
>  - handles both initrd and initramfs.


Comments:

* Having a mkinitrd that's not a shell script is a godsend.  I would 
endorse yaird on that fact alone :)

* I've long wanted a "mkinitfoo" that would create .cpio.gz for 
initramfs by default.  So, good job there, too.

* Eventually your script will need pull in, into the initramfs, klibc 
and programs linked against klibc.

	Jeff




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Roman Kagan]

On Thu, Feb 17, 2005 at 09:06:20PM +0100, Erik van Konijnenburg wrote:
> This is to announce yaird, Yet Another mkInitRD, a rewrite of mkinitrd
> based on hotplug algorithms.

What do you think will its target user base be?

I'm just trying to figure out why a user of such a utility (i.e. we're
not speaking of embedded world) wouldn't be able to afford an initramfs
image of up to, say, 8 MB.  Then, with gzip -9 giving a factor of 2.5+
compression on the cpio archive of the modules tree, you can perhaps fit
all the modules (well, sound can be thrown away) and the hotplug stuff
from the live system into initramfs.cpio.gz.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Erik van Konijnenburg]

On Fri, Feb 18, 2005 at 01:50:58AM +0300, Roman Kagan wrote:
> On Thu, Feb 17, 2005 at 09:06:20PM +0100, Erik van Konijnenburg wrote:
> > This is to announce yaird, Yet Another mkInitRD, a rewrite of mkinitrd
> > based on hotplug algorithms.
> 
> What do you think will its target user base be?
> 
> I'm just trying to figure out why a user of such a utility (i.e. we're
> not speaking of embedded world) wouldn't be able to afford an initramfs
> image of up to, say, 8 MB.  Then, with gzip -9 giving a factor of 2.5+
> compression on the cpio archive of the modules tree, you can perhaps fit
> all the modules (well, sound can be thrown away) and the hotplug stuff
> from the live system into initramfs.cpio.gz.

Good question, that may be relevant to the hotplug next generation
discussion.  Once you accept the idea of a 2.6-only initrd builder,
the choice is between:
- the classical method: pre-compute required modules and put only
  those on the image,
- or the radical approach: put it all on the image and let hotplug
  sort it out at boot time.

There is an extra cost in putting everything on the image, but that
may be worth it if it means less maintenance, less problem reports or
faster boots.  Here's an attempt to sort out the strong and weak points:

- The main argument in favor of the radical approach is that it can
be more resistant to hardware changes: if /dev/sda decides it wants
to be known as /dev/sdb after a reboot, hotplug can accommodate that.
Is this something that bites users, and are there many cases where
hotplug handles this without need for a recovery disk?  [that's not
a rethorical question; I'd appreciate an estimate from someone with
more overview than me.]

- The radical approach depends on a rewrite of hotplug without shell
scripts (it's very difficult for mkinitrd to determine reliably which
executables are needed by a shell script).  That seems to be in the
works, but the catch is that that needs to be done in such a way that
it can handle the mounting of a new root file system without leaving
dangling references to the old rootfs; I think at the moment that issue
is unresolved, but once it is, it will no longer be an objection to the
radical approach.

http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m\x110530801407386&w=2

- More serious may be the use of PROGRAM="..." in udev.rules; this again
sucks in executables and shell scripts that make it difficult to find
out what should go on the image.  It may be possible to write a
separate rules file for use on initrd that avoids the PROGRAM="...";
it would help to make the rule format richer, so that more cases can
be handled without resorting to PROGRAM="...".

- Finally there is the issue of boot times.  Does udevstart depend on
ide-probe and loading and unloading of IDE modules to detect legacy
devices?  If so, that can't help in the race for the fastest boot
time.

At the moment I see no clear winner; lets just build both approaches
and see which one works best.

As an aside, yaird can support the radical approach just as well as the
classical approach.  For radical images, it would add LVM, mdadm and
file system support; the hardware detection would be done by a coldplug
in the prologue of the /init script.  The only change required to the
software is adding wildcards to the file list in the templates: add a
complete /lib/modules tree to the image rather than individual files.
If you want to use yaird to add LVM and mdadm support to experiments
with radical images, let me know and I'll add the wildcard thingy.

Regards,
Erik




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Roman Kagan]

On Sat, Feb 19, 2005 at 03:00:53AM +0100, Erik van Konijnenburg wrote:
> - the classical method: pre-compute required modules and put only
>   those on the image,
> - or the radical approach: put it all on the image and let hotplug
>   sort it out at boot time.
> 
> - The radical approach depends on a rewrite of hotplug without shell
> scripts (it's very difficult for mkinitrd to determine reliably which
> executables are needed by a shell script).

But this will probably be needed in your classical approach too (I mean
tracking of the required executables, I don't immediately see why shell
scripts are worse in this respect).

BTW one more item to track the dependencies for (in case you don't have
enough :) is the firmware files.  You can identify which modules may
need firmware by checking their dependency on firmware_class, but I see
no way of knowing which firmware files they are going to request.  To
make it worse, firmware is the (only) kind of hotplug events which can
be neither delayed (due to limited timeout) nor postponed to be replayed
later on.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Harald Hoyer]

Erik van Konijnenburg wrote:
> - More serious may be the use of PROGRAM="..." in udev.rules; this again
> sucks in executables and shell scripts that make it difficult to find
> out what should go on the image.  It may be possible to write a
> separate rules file for use on initrd that avoids the PROGRAM="...";
> it would help to make the rule format richer, so that more cases can
> be handled without resorting to PROGRAM="...".
> 

Another problem arises, if you edit one config file for the udev/hotplug/init 
process, all kernels initrd have to be recreated, unless we have a hotplug 
replay mechanism after root is mounted. Though any modprobe.conf scripts which 
are not in initrd, will not be executed.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Patrick Mansfield]

On Tue, Feb 22, 2005 at 02:51:10PM +0300, Roman Kagan wrote:

> BTW one more item to track the dependencies for (in case you don't have
> enough :) is the firmware files.  You can identify which modules may
> need firmware by checking their dependency on firmware_class, but I see
> no way of knowing which firmware files they are going to request.  To
> make it worse, firmware is the (only) kind of hotplug events which can
> be neither delayed (due to limited timeout) nor postponed to be replayed
> later on.

Hi -

Maybe we need in module.h:

#define MODULE_FIRMWARE(_firmware) MODULE_INFO(firmware, _firmware)

And use it for any module that can generate a call to request_firmware().
(Too bad we can't hook right into request_firmware(), since some callers
pass variables as the name.)

Then the *rd generator queries the modules and copies any "firmware" file
from /lib/firmware into the initrd/ramfs.


Why is there no file system reader (like grub has)? So the initrd could just
copy files off of a file system as needed without mounting them.  There
are probably device naming / slippage problems with using a physical path
especially for scsi: usb mass storage, SAS/SATA, SPI, FC etc. But are
those bad enough to reject such an approach?

-- Patrick Mansfield


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Roman Kagan]

On Tue, Feb 22, 2005 at 11:26:09AM -0800, Patrick Mansfield wrote:
> On Tue, Feb 22, 2005 at 02:51:10PM +0300, Roman Kagan wrote:
> 
> > BTW one more item to track the dependencies for (in case you don't have
> > enough :) is the firmware files.
> 
> Maybe we need in module.h:
> 
> #define MODULE_FIRMWARE(_firmware) MODULE_INFO(firmware, _firmware)
> 
> And use it for any module that can generate a call to request_firmware().
> (Too bad we can't hook right into request_firmware(), since some callers
> pass variables as the name.)

That's the problem here as well: you'll have to manually keep
MODULE_FIRMWARE in sync with what you actually pass to
request_firmware().

> Why is there no file system reader (like grub has)? So the initrd could just
> copy files off of a file system as needed without mounting them.

Alternatively grub can perhaps be taught to use its filesystem reader
and generate initramfs on the fly from /bin, /etc, /lib, /sbin of the
actual root filesystem.  This may be slow, though...

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Erik van Konijnenburg]

On Tue, Feb 22, 2005 at 02:51:10PM +0300, Roman Kagan wrote:
> On Sat, Feb 19, 2005 at 03:00:53AM +0100, Erik van Konijnenburg wrote:
> > - the classical method: pre-compute required modules and put only
> >   those on the image,
> > - or the radical approach: put it all on the image and let hotplug
> >   sort it out at boot time.
> > 
> > - The radical approach depends on a rewrite of hotplug without shell
> > scripts (it's very difficult for mkinitrd to determine reliably which
> > executables are needed by a shell script).
> 
> But this will probably be needed in your classical approach too (I mean
> tracking of the required executables, I don't immediately see why shell
> scripts are worse in this respect).

At the moment, templating provides a limited solution.  The author of
a template can state that an action such as 'vgchange' needs
/sbin/vgchange; that's a reasonable effort when tuning a template to
a distribution, and yaird or mkinird can make it easier by handling
details such as shared libraries.

This approach breaks down when you have open-ended shell scripting,
and yaird or mkinitrd is expected to automatically find every
executable that needs to go on the image.

For example, a modprobe.conf install line that says:
	install snd-als4000 modprobe --ignore-install snd-als4000 &&
		/lib/alsa/modprobe-post-install snd-als4000

Interpreting that and determining what scripts are invoked
directly or indirectly is in general an undecidable problem.

This is one of the reasons why yaird doesn't support modprobe.conf
yet.  As an aside, it might be acceptable to simply reject install lines.
That seems to be the normal approach at the moment, and does not seem
to give rise to too many bug reports.

In the radical approach, currently you'd have to put every excutable
on the image that's used by hotplug or its agents.  That's doable,
but requires a *lot* of maintenance.  I expect this to become more
manageable one hotplug-ng is a reality.

Regards,
Erik

PS: thanks for your quick wildcard feedback; I'll dive into the patch
after going through the mail.  Notes on firmware in a next message



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Erik van Konijnenburg]

On Tue, Feb 22, 2005 at 06:48:29PM +0100, Harald Hoyer wrote:
> Erik van Konijnenburg wrote:
> > - More serious may be the use of PROGRAM="..." in udev.rules; this again
> > sucks in executables and shell scripts that make it difficult to find
> > out what should go on the image.  It may be possible to write a
> > separate rules file for use on initrd that avoids the PROGRAM="...";
> > it would help to make the rule format richer, so that more cases can
> > be handled without resorting to PROGRAM="...".
> > 
> 
> Another problem arises, if you edit one config file for the udev/hotplug/init 
> process, all kernels initrd have to be recreated, unless we have a hotplug 
> replay mechanism after root is mounted. Though any modprobe.conf scripts which 
> are not in initrd, will not be executed.

That, plus I want a back-out option ...

It seems the image depends on a combination of kernel, modprobe.conf
(for module options) and the hotplug config files; almost like we need
a makefile to do the mkinitrd invocation.  This is really too complicated
for me to think about now, but it's something to consider if we want
to offer the sysadm a robust environment.

Regards,
Erik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Erik van Konijnenburg]

On Tue, Feb 22, 2005 at 11:03:58PM +0300, Roman Kagan wrote:
> On Tue, Feb 22, 2005 at 11:26:09AM -0800, Patrick Mansfield wrote:
> > On Tue, Feb 22, 2005 at 02:51:10PM +0300, Roman Kagan wrote:
> > 
> > > BTW one more item to track the dependencies for (in case you don't have
> > > enough :) is the firmware files.
> > 
> > Maybe we need in module.h:
> > 
> > #define MODULE_FIRMWARE(_firmware) MODULE_INFO(firmware, _firmware)
> > 
> > And use it for any module that can generate a call to request_firmware().
> > (Too bad we can't hook right into request_firmware(), since some callers
> > pass variables as the name.)
> 
> That's the problem here as well: you'll have to manually keep
> MODULE_FIRMWARE in sync with what you actually pass to
> request_firmware().

I haven't really looked at firmware yet, so the following may be 
off the mark, but:

- one approach would be MODULE_FIRMWARE, perhaps in the form of an array,
where every firmware file that's potentially interesting to the module is
listed.  This way you can build the leanest initrd images possible;
it will also fail to make us wildy popular with out-of-tree driver authors.

- another approach is to let mkinitrd/yaird note a dependency on firmware
class, and if present put *all* of firmware on the image.  Yaird would need
to support wildcards for that (put a whole tree on the image, not individual
files), but that's needed anyway to allow experiments with hotplug on the
image.  If the firmware directory is small, this may be good enough.

- a hybrid, where the default is to put all firmware on the image,
but we design some optional MODULE_FIRMWARE magic to allow the module
author to make a statement that only certain files are needed.  
This could get tricky for situations where firmware is loaded by a common
support module, firmware loaded via ioctls or firmware specified via module
options.

Let's build the second solution first, then consider the third one once
there's data that shows it would provide significant benefits.

> > Why is there no file system reader (like grub has)? So the initrd could just
> > copy files off of a file system as needed without mounting them.
> 
> Alternatively grub can perhaps be taught to use its filesystem reader
> and generate initramfs on the fly from /bin, /etc, /lib, /sbin of the
> actual root filesystem.  This may be slow, though...

I'd like to get yaird to a point where you can but three USB sticks in a raid
set, put an encrypted file system on it and expect it to boot.  (A wonderful
platform to test mdadm error recovery ...)

Grub has a very limited file system reader that cannot support such
sillyness, and given the primitive facilities it has to use, that limitation
makes good sense.  Other bootloaders are even more limited.  The kernel
on the other hand needs flexibility to introduce new filesystems whenever
someone comes up with a plausible story on LKML.

Consider initrd/initramfs as an isolation layer that allows bootloader and
kernel to innovate independently.  If initramfs were to require
access to the root filesystem to get to user mode, that would place
limitations on what filesystems the kernel can support, and so defeat
the purpose of having an initramfs in the first pace.

Regards,
Erik




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Werner Almesberger]

Erik van Konijnenburg wrote:
> Yaird is intended to find out whether that assumption is correct: if so, 
> a program to build initrd images will be more reliable if it's written
> in perl, if it uses sysfs to determine what hardware needs to be supported,
> and if it closely follows the methods hotplug uses find the modules
> needed to support some hardware.

This is great, and was long overdue. Thanks for fixing my sins of
omission dating back from 1996 :-)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel