[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2.6.13, experimental and 2.6.14-rc ...



Le mercredi 05 octobre 2005 à 20:19 +0200, Jonas Smedegaard a écrit :
> Silence as response to both questions (from all but you and I) I dare
> interpret as "we have already decided on initramfs-tools and are either
> too lazy or too busy to even shed light on the issues we have with
> yaird".

I have an obvious bias towards initramfs-tools as the primary author,
but I'd hate for you to think it was apathy. =)

initramfs-tools is designed as a collection of hooks that are easy to
add to.  Just drop the various pieces you want in the right place and
it's no problem.  In Ubuntu it has already been extended to do
cryptroot, boot off a nested flash, usplash, etc, all without core code
changes.

It is klibc based, which means that some arch's may need a bit more love
to make them work.  Alternatively, it would be trivial to make it
optionally glibc based.  Ubuntu only has i386, amd64, sparc64, powerpc,
powerpc64, ia64, and hppa.  Of those, klibc is miscompiled on hppa and
will be fixed RSN.

> > I think what would be of most interest is a technical description of
> > both solutions, as well as a list of arches where it is known to
> > work, should work, almost works, fails utterly.
> 
> It is not only arches, but also combinations of features:
> 
> With initrd-tools, running 2.4-x when installing a 2.6-x kernel causes
> the tool to switch from "dep" to "most" because (I believe) it cannot
> probe kernel module dependencies. Same situation will currently cause
> yaird to fail completely,as it requires sysfs and udev support in the
> running kernel.

initramfs-tools will install from any kernel, but requires 2.6.12 to
boot.  The version verification is done on the target kernel.  For this
it must be in "most" mode.  In "dep" mode, it needs to walk sysfs to
figure out what's there.

> The features - mount types and kernel command line options - supported
> or planned by yaird is listed upstream here:
> http://www.xs4all.nl/~ekonijn/yaird/yaird.html

I have no equivalent to this for initramfs-tools because it doesn't
really make sense.  The hook structure of initramfs is such that most of
these features should not be provided by initramfs-tools, but should be
provided by other packages that ask for themselves to be included in the
initramfs.

The two big features that I want and don't have:

1) Make busybox optional.

2) Make dep mode smaller.

#1 right now isn't the case because we use sed and awk in a few of the
scripts.  (raid detection for auto-assembling arrays without config
files).  mdadm can do this all built-in, but I wasn't getting consistant
results from it.

#2 is just a matter of expanding the hook script interface so that the
initramfs.conf file is make available to them more easily.  Then in
"dep" mode, they can do some detection to figure out if installing
themselves is the right thing to do or not.

In terms of tested environments, it's easier for me to list of places
where initramfs-tools is failing to work well -- I don't usually get
success reports, I get bug reports. ;)  At this time, I have 21 bugzilla
reports, 3 of which are enhancement requests.  About 5 of the
non-enhancements are solvable quickly when we're not in various freezes.
Others (like making yaboot not loading trailing garbage on xfs
partitions) and a bit harder. =)

> Generally, yaird has a minimalistic approach, wanting to include only
> what is known to be needed - whereas it seems initrd-tools and
> initramfs-tools both include all except what is known not to be needed.

initrd-tools and initramfs-tools both have a dep mode.  The one in
initramfs-tools is tighter than the one in initrd-tools, but still has
places for obvious improvements.

> > The fact that yaird doesn't use klibc seems to be a nice feature on
> > those arches where klibc is still broken.
> 
> Another point is size: Do all of those arches with a working klibc
> support the large initramfs'es generated currently by initramfs-tools?

The output from initramfs-tools is generally comparable to that of
initrd-tools.

> And do I remember correctly that some tools in the initramfs using klibc
> and others (like mdadm and lvm) using glibc can cause trouble?

No trouble.  It's just sad to have to libcs in there.  Newer versions of
these tools supporting klibc are starting to come out, which is nice.

> > I believe the best solution is to leave the choice to the user, with
> > a sane default depending on the arch/subarch used.
> 
> I agree. Similar to the choice of LILO or GRUB (or other bootloaders
> when relevant).

Sure, it's much more Debian's style to do this.

One advantage I will pitch to the initramfs-tools concept is something
that yaird could also easily adopt.

I include a tool "update-initramfs" that is designed to manage
creation / regeneration of the initramfs' for programs.  Ubuntu's
post-breezy kernels will no longer call mkinitramfs directly, but will
call the tool to create it.

The tool then stores a sha1 has to make sure that the initramfs hasn't
been altered.  If it has not, then maintainers that want to alter the
initramfs can just call "update-initramfs -u" and have it regenerated.
If it has been altered by the user, it will say so, and refuse to touch
it.

This is key to the strategy of pushing as many of the add-on bits out to
other packages as possible.

For those that haven't looked at the initramfs-tools code, please
consider doing so.  It's written in shell. =)  If you have questions,
lemme know.  I'm subscribed to this list, but don't check the folder
often, so cc:'ing me is usually good if you need a fast response.

Tks,
Jeff Bailey

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=


Reply to: