Bug 169412 - initrd images are frighteningly large
initrd images are frighteningly large
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-27 19:13 EDT by Andy Ross
Modified: 2008-02-23 01:30 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-23 01:30:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andy Ross 2005-09-27 19:13:25 EDT
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...
Comment 1 Andy Ross 2005-09-27 20:06:14 EDT
Some of this is clearly glibc's fault.  See bug 169414
Comment 2 Andy Ross 2005-09-28 12:44:42 EDT
Jakub in bug 169414 says that static linkage to glibc is not supported, and
recommends dietlibc, uclibc or klibc.
Comment 3 Christian Iseli 2007-01-22 06:52:45 EST
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 ?

Thanks.
Comment 4 petrosyan 2008-02-23 01:30:55 EST
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.

Note You need to log in before you can comment on or make changes to this bug.