On Wed, Mar 9, 2011 at 7:15 PM, Tom Gall tom.gall@linaro.org 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?
- 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:
- 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?
- 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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 creation.
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.
Cheers ---Dave