Re: 2.6.13, experimental and 2.6.14-rc ...
On Wed, Oct 05, 2005 at 08:19:14PM +0200, Jonas Smedegaard wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> > > If not, why?
> >
> > I guess generic miscomprehension, or whatever. The fact that ubuntu
> > uses initramfs-tools for example, and so on.
>
> I would guess similarly. My interest was (and still is) actual concrete
> reasons from those (if any) not interested.
>
> 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".
Please interpret it as too busy to reply right now, as many in the kernel team
are over-worked with RL stuff these days :)
> > 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.
We don't care about 2.4 kernels, and we don't care about initrd-tools, the
choice is between intiramfs-tools and yaird, i favor a solution where this
choice can be left to the user.
> 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
>
>
> 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.
>
>
> > 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?
>
> And do I remember correctly that some tools in the initramfs using klibc
> and others (like mdadm and lvm) using glibc can cause trouble?
>
>
> > 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).
Except done right, and not the mess that the bootloader selection is right now
:)
Friendly,
Sven LUther
Reply to: