initramfs is too big

[SurJector]

A lot of space is wasted in initramfs because busybox is not correctly used.

1) busybox-initramfs is compiled statically but it's useless because libc.so is on the initramfs (that means 1217840 bytes against 270112 if compiled dynamically -- give or take a few, arch: amd64)
2) some tools that are present in the initramfs could be symlinks to busybox
3) all symbolic links are destroyed by cpio --dereference in mkinitramfs

To solve 2) and 3) I propose the attached changes to mkinitramfs (and ntfs-3g hook).

In addition to solve 1) I propose the following 1 line change to busybox-initramfs
(i.e. to busybox_1.10.2-2ubuntu4.diff).
--- busybox_1.10.2-2ubuntu4.diff.orig 2009-02-06 19:02:32.000000000 +0100
+++ busybox_1.10.2-2ubuntu4.diff 2009-02-06 16:14:14.000000000 +0100
@@ -4179,7 +4179,7 @@
 +#
 +# Build Options
 +#
-CONFIG_STATIC=y
++# CONFIG_STATIC is not set
 +# CONFIG_NOMMU is not set
 +# CONFIG_BUILD_LIBBUSYBOX is not set
 +# CONFIG_FEATURE_INDIVIDUAL is not set

4) Wishlist: busybox has a lot applets that are currently unused. In particular
cpio dd dmesg eject gzip halt insmod kbd_mode losetup pivot_root pkill rmmod swapon
could replace the ones on the initramfs (those one use 176656 bytes on jaunty-alpha4,
their replacement with busybox increases its size of 28768 bytes (amd64)).
5) If 4) is treated, only
fstype
ipconfig
kinit unused
minips useless (ps in busybox)
nfsmount (mount in busybox ?)
nuke = find $1 -xdev -type f | xargs rm; find $1 -xdev -depth -type d | xargs rmdir
resume
run-init
  remain from klibc. Maybe it is possible to dispose of klibc completely.
  As far as remember run-init is essentially nuke;chroot /dir;exec /sbin/init "$@"
  ipconfig can be emulated,
  fstype probably (recompiled ?).
  I don't know about resume.

     SurJector

[Colin Watson (cjwatson)]

I fixed the busybox part of this independently before looking at this bug. I also have an independently-created patch that addresses most of the same issues in initramfs-tools. Note that the symlink vs. cpio issue really doesn't matter all that much, IMO; identical files will get compressed very efficiently anyway. I seem to remember there was a good reason to use cpio --dereference - I think it allowed initramfs *generation* to take much less space - so I'd rather not change that.

busybox (1:1.13.3-1ubuntu2) karmic; urgency=low

  * [initramfs] Link dynamically rather than statically. We always have
    glibc in the initramfs these days.

 -- Colin Watson <email address hidden> Tue, 23 Jun 2009 10:02:27 +0100

[Colin Watson (cjwatson)]

Actually, the symlink vs. cpio issue does seem to cause a certain amount of bloat. This is unfortunate but I'd prefer not to fix that just now, since I know that it causes issues for building on disk-limited systems. If this is important to you, it's probably best to file a separate bug; as of the patch I'm about to upload the footprint of this problem is 500KB or so, much less than it used to be. We're going to be gradually making the initramfs smaller for boot performance reasons over the course of this cycle, which may make it less of an issue in future.

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.92bubuntu32

---------------
initramfs-tools (0.92bubuntu32) karmic; urgency=low

  * Copy in KMS drivers (currently just i915 and the AGP drivers) if we can,
    so that we can load them before starting usplash. NOTE that this whole
    edifice is not intended to be used by default on most systems for
    Karmic, and that the general intent is to make the initramfs smaller
    rather than larger; however, we're still going to need usplash in the
    initramfs for some use cases (e.g. dm-crypt), so we might as well get
    this working now.
  * Fix formatting error in initramfs-tools(8).
  * 'set -e' in initramfs-tools.postrm.
  * Fix handling of resume_offset: if it's set then we need to check in a
    different location for the swap signature.
  * Remove kinit and gzip from the initramfs. The first record I can find of
    this Ubuntu change is in a merge from Debian, and I can't see any
    justification for it since neither binary is actually used by any
    initramfs scripts.
  * Remove klibc utilities if busybox is in use (patch based on Debian
    #338405; LP: #327106). Leave a symlink for /bin/sleep since some scripts
    expect that to exist.

 -- Colin Watson <email address hidden> Tue, 23 Jun 2009 14:19:02 +0100

[SurJector (loic-grenie)]

2009/6/23 Colin Watson <email address hidden>:
> Actually, the symlink vs. cpio issue does seem to cause a certain amount
> of bloat. This is unfortunate but I'd prefer not to fix that just now,
> since I know that it causes issues for building on disk-limited systems.

     Fine. That's your call.

     What can be done to save space (on disk limited systems) and
  time (at loading/decompression), is to build the symbolic links at
  the beginning of the init script. The

echo "Loading, please wait"

  would be substituted by

busybox echo "Loading, please wait"

  and then adding a line

[ -x "/bin/buildlinks.sh" ] && /bin/buildlinks.sh

  where the /bin/buildlinks.sh would be a successions of

busybox ln -s busybox /bin/gzip
busybox ln -s busybox /bin/ln
busybox ln -s busybox /bin/sleep
...
busybox ln -s ../bin/ntfs-3g /sbin/mount.ntfs-3g
busybox ln -s ../bin/ntfs-3g /sbin/mount.ntfs

  (at least the busybox applets could be determined at mkiniramfs
  time).

> If this is important to you, it's probably best to file a separate bug;
> as of the patch I'm about to upload the footprint of this problem is
> 500KB or so, much less than it used to be. We're going to be gradually
> making the initramfs smaller for boot performance reasons over the
> course of this cycle, which may make it less of an issue in future.

    Fine. I'll wait and see Karmic !

    Please include a lot of applets in busybox, because it is VERY frustrating
  not to be able to fix a problem because vi/ifconfig/whatever has not
  been included in initramfs' busybox. It is possible to have 141 applets
  (most of them potentially useful in case of problems) in 396k of
  x86-32 busybox. Please do include a lot.

     Thanks,

          Loïc