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