Red Hat Bugzilla – Bug 169412
initrd images are frighteningly large
Last modified: 2008-02-23 01:30:55 EST
The FC4 initrd image inclues these four very large, statically linked
binaries (sizes from the current x86_64 distribution). They make up
the bulk of the space in the image; the kernel modules are actually a
fairly small fraction:
-rwxr-xr-x 1 andy andy 502872 Sep 27 15:47 ./bin/insmod
-rwxr-xr-x 1 andy andy 539352 Sep 27 15:47 ./bin/nash
-rwxr-xr-x 1 andy andy 662640 Sep 27 15:47 ./bin/udev
-rwxr-xr-x 1 andy andy 662672 Sep 27 15:47 ./bin/udevstart
The dynamically linked counterparts are not nearly so big:
-rwxr-xr-x 1 root root 9888 Jul 22 14:06 /sbin/insmod
-rwxr-xr-x 1 root root 59008 May 20 20:45 /sbin/udev
-rwxr-xr-x 1 root root 59008 May 20 20:45 /sbin/udevstart
I even built a dyamic nash just for completeness:
-rwxrwxr-x 1 andy andy 40928 Sep 27 13:11 ./mkinitrd-4.2.15/nash
And just for arguments sake, note that the total waste here is
actually more than the entire C library:
-rwxr-xr-x 1 root root 1544248 Aug 15 07:15 /lib64/libc-2.3.5.so
Now this is mostly an aesthetic argument, but this just seems
ridiculous to me given the really minimal work that needs to happen in
the initrd. The extra I/O involved at least has the potential to be a
performance problem. I tried timing the difference (with a stopwatch)
between the default initrd and a custom kernel without one (the time
between launch from grub and the start of the real init) and got about
1.2 seconds, but that could be inside the noise.
How hard would it be to write up a tiny libc for these to link
statically against rather than pulling in huge chunks of glibc?
Or just include a glibc/newlib image and runtime linker?
Or, as a fancy and (IMHO) elegant hack: have mkinitrd generate not a
script for nash, but an actual C program with no libc dependence that
can be built and installed as the "/init" binary in the image. The
commands accepted by nash and the (*really* minimal) udev
functionality implemented by the current initrd should be replaceable
more or less 1:1 with equivalent C code...
Some of this is clearly glibc's fault. See bug 169414
Jakub in bug 169414 says that static linkage to glibc is not supported, and
recommends dietlibc, uclibc or klibc.
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
Fedora Core 4 is no longer maintained.
Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.