80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?

[Sam Leffler]

M. Warner Losh wrote:
> In message: <372128.56919.qm at web51502.mail.re2.yahoo.com>
>             fbsd2 <fbsd2 at yahoo.com> writes:
> : Greetings list,
> : 
> :    Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box.  I've seen
> : 
> : http://www.freebsd.org/releases/7.0R/relnotes.html   and
> : http://marc.info/?l=freebsd-stable&m=121278826119286&w=2
> : 
> : which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /.  Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space?  TIA
>
> Doesn't look like anybody has answered this question...
>
> 80MB is plenty, even for 7.x.  However, you'll have to use nanobsd or
> tinybsd to get that small.  You'll likely been unable to do a 'make
> installworld' to get this size.  You'll have to create an image and
> push it over to this machine somehow.
>
> In the 3.x time frame, I had FreeBSD booting with the standard scripts
> in 13MB without compression.  4.x, 5.x and 6.x bloated these binaries
> to about 18MB (a few more were added).  I haven't built a system based
> on 7.x with this system due to a change in employment, but expect that
> it wouldn't be much larger than 20MB for these same files.  Some
> careful honing could reduce that a little, but maybe not a lot.
> Typical embedded systems that I shipped were on the order of 24MB
> without X11 and 32-60MB for those with an X11 server.
>
> What's this box used for?
>
>   
I've been looking at nanobsd for a couple of applications and working to 
reduce the footprint of the images without hacking special rules.  With 
the existing set of WITHOUT knobs in the build system you get a 48M 
image.  With my additional knobs I have this down to 24M.  There are 
still numerous bits of junk that must be removed with special rules 
unless I go the complete route and add WITHOUT knobs for just about 
everything.  I'd much prefer an opt-in configuration scheme but wasn't 
keen on what I see in existing packaging systems.  Like you I have my 
own packaging system (works on HEAD and RELENG_[4567] though stuff <7 is 
probably rotted) but hope to move away from it.  In the long run I doubt 
nanobsd will work for a true embedded application (with my private tools 
my current RELENG_7 firewall is 10M and includes bind+dhcpd).

The other area that I hope to improve on in nanobsd is build time.  At 
the moment you're required to build a bunch of stuff just to throw it 
away.  This is unacceptable with our current build times being so long.

My main motivation for improving nanobsd is to offer it as a way to 
package embedded cross-builds.  I've got examples to cross-build images 
for the AVILA board (it's trivial and I'm sure can be done by other 
systems like tinybsd so long as they use the buildworld infrastructure).

To get past the current 24M barrier I'll need to attack individual 
applications.  For example bind is currently huge and ancillary tools 
like dig are almost as big!  I haven't looked at why but for my current 
firewall I crunchgen bind and related tools into an image together w/ 
various other bits.

If we're ever to consider building images for flash parts (not compact 
flash) then we'll need to do a lot of work to pare down the bloat--or 
replace current apps w/ special purpose replacements a la busybox (not 
something I find appealing).

    Sam