Michael Tokarev <m...@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bpfk6ugv....@frosties.localdomain
