klibc only initramfs

[Goswin von Brederlow]

Michael Tokarev <mjt at tls.msk.ru> writes:

> Goswin von Brederlow wrote:
>> Hi,
>> 
>> I googled a bit and found this old mail about a klibc only initramfs:
>> 
>> http://lists.debian.org/debian-kernel/2006/07/msg00400.html
>> 
>> I would really like to do this and it has been close to 4 years since
>> that mail. But it doesn't look like there has been much progress or not
>> in the right direction. Looking at my initramfs I see:
>> 
>> % ls lib
>> cryptsetup/                            libm.so.6
>> klibc-zUXi_KjK5ZQAIyc8jlwme9T6a4U.so*  libncurses.so.5
>> ld-linux.so.2*                         libpopt.so.0
>> libc.so.6*                             libreadline.so.5
>> libcfont.so.0                          libselinux.so.1
>> libconsole.so.0                        libuuid.so.1
>> libctutils.so.0                        libvolume_id.so.0
>> libdevmapper.so.1.02.1                 modules/
>> libdl.so.2                             udev/
>
> Apparently the initramfs contains _two_ different libc implementations.
> ...
>
> []
>> Could we build stripped down versions of those tools (and libs as
>> required) build against klibc? I certainly see no need for ncurses in my
>> initramfs. Building a klibc based initramfs that then includes libc6
>> (and even busybox) as well seems rather stupid. One without klibc would
>> be smaller then.
>
> May I ask this question the other way around:
>
> Why maintain two sets of tools and libraries while one set is more
> than enough already?  Why we need/want klibc to start with, while
> regular glibc and regular tools do the work just fine?
>
> I use glibc-based initramfs (with busybox) since first days when
> initramfs were introduced in kernel.  I booted even the less capable
> machines (i486 with 16Mb memory) with it without any issues.  I don't
> see any reason to maintain another set of tools just for initramfs.
>
> In previous life there was an argument about whole thing fitting a
> single floppy drive.  But nowadays a) floppies are gone, and b)
> kernel itself does not fit in a floppy anymore.
>
> Also, I heard people saying that klibc-based initramfs is somehow
> faster than glibc-based.  Maybe this is partially true, because the
> bigger the initramfs is, the more time it requires to load by a
> relatively dumb and slow boot loader (esp. for slow network-based
> boots).  But even here, in most cases the difference is small and
> does not justify the amount of work needed to support the second
> set of tools/libraries.
>
> Just an opinion....
>
> /mjt

The reason would be size. I don't see anything else there.

For network based boots, specifically high performance cluster, the size
can make a real difference. When you turn the cluster on it is not just
one system downloading an extra meg but 100+ nodes. That largely
increases the network collisions, errors and dropped packages. Something
that can even make systems fail to boot.

MfG
        Goswin