Making linaro-nano smaller or Give Up Disk Space for Lent

Dave Martin dave.martin at
Fri Mar 11 11:20:35 UTC 2011

On Wed, Mar 9, 2011 at 7:15 PM, Tom Gall <tom.gall at> wrote:
> Hi All,
> In the developer platforms team we're working on getting the
> linaro-nano image so that it is considerably smaller. To date I've
> been using the approach I outlined last fall in a previous post to
> this list.
> Some highlights to nano:
>   * The linaro-image boots just as our linaro-headless image did
> (upstart and friends)
>   * it can be updated, or additional pkgs installed via apt-get
>   * networking works
>   * busybox is in use tho not necessarily universally
>   * ureadahead, python, have been removed
>   * docs have been removed
>   * linux-firmware has been removed (binary kernel firmware blobs)
>   * locales is remove
> Installed image is 125 Megs. (Down from 290 Meg) We're on the cusp of
> being able to fit into 128 megs of flash.
> This brings me to the subject of the kernel. hwpacks besides
> installing linux-firmware (32 Megs) but also approx 50 Megs in
> modules. Yet on my beagleboard lsmod notes
> Module                  Size  Used by
> asix                   12805  0
> usbnet                 17027  1 asix
> omap2_mcspi             8441  0
> omap_wdt                4093  0
> hid_apple               4999  0
> twl4030_usb             4950  0
> twl4030_pwrbutton       1298  0
> gpio_keys               6072  0
> leds_gpio               2198  0
> usbhid                 39072  0
> hid                    74787  2 hid_apple,usbhid
> Clearly we don't need all of these modules and I don't think it's an
> unreasonable change our policy to "build what's needed + some
> reasonable subset of function that our average user might neeed".
> I don't know why we're installed the firmware deb, does any of the
> hardware we're supporting even use that?
> From the directories where modules are located there is the following size info:
> 812     ./crypto
> 7568    ./net
> 2456    ./sound
> 60      ./arch
> 28372   ./drivers
> 172     ./lib
> 272     ./ubuntu
> 8316    ./fs
> 48032   .
> Going deeper it's pretty easy to spot low hanging fruit:
> From fs - Do we need afs, jfs, code, minix, hpfs, xfs, hfs, hfsplus,
> gfs2, reiserfs...  I'm thinking no.
> From drivers - net and media make about about 1/3rd of the 28 meg in
> use, I'm sure there's a number of drivers in here that can just be
> turned off.
> From sound - ac97, are there arm boards that use that?
> From net - x25, decnet, appletalk ?
> So that said, what is the best way to proceed?
> 1) Is there agreement that for all the kernels we supply that we
> should change the policy for kernel configs to not default to
> everything on?
> (Maybe we should be using the upstream config with minimal modifications?)
> Pro: everyone benefits from the diet
> Con: Our kernel would be build slightly different than ubuntu's
> others:
> 2) Linaro-media-create shouldn't install linux-firmware_1.47_all.deb ?
> Do we have any any hardware that needs it?  If so could there be a
> --nano option to not install it?
> 3) linaro-media-create should have some kind of option (--nano) to
> clear out apt caches (saves ~40 meg of space)
> Specifically from the installed image after the hwpack deps are
> installed get rid of the following:
> rm -f ./var/lib/apt/lists/*Packages
> rm -f ./var/lib/apt/lists/*Sources
> rm -f ./var/lib/apt/lists/*Release
> rm -f ./var/lib/apt/lists/*Release.gpg
> rm -f ./var/cache/apt/pkgcache.bin
> rm -f ./var/cache/apt/srcpkgcache.bin
> Pro: if you never run apt* you won't mind the cold caches
> Con: if you're running out of nand and you're going to apt-get upgrade
> your system, you're probably going to run out of space (Probably a
> problem to solve in a future cycle)
> It's important through this exercise for people to speak up about what
> can and can NOT be safely turned off.
> Thanks for your time, attention, suggestions and feedback.
> Regards,
> Tom
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at

Although it's not directly related to nano (which is useful in itself
as a miminal usable system) it could make sense to be able to generate
images with no built-in packager support - i.e., the packer must
effectively be run offline to generate the filesystem.  There's also
the possibility of keeping the packager information outside the main
tarball, so the filesystem can be modified/updated offline after

Such images don't need dpkg or apt built in; and hence don't need
/var/lib/dpkg or /var/{lib,cache}/apt, and may not need perl,
libstdc++ etc.  Altogether, that will be a very significant saving
compared with something like the nano image.

As I understand it, debootstrap or germinate basically do the right
thing.  All we would need would be to document the use of the existing
tools, and provide suitable ultra-minimal seeds (at the level of
busybox+libc only) and/or an ultra-minimal --variant for debootstrap.

If that's seen to be interesting, we should probably discuss it with
the emdebian folks-- there's a risk of reinventing what they do; plus
they certainly have tools which are useful for this.


More information about the linaro-dev mailing list