80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?
sam at freebsd.org
Sat Aug 2 18:39:25 UTC 2008
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_ 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).
More information about the freebsd-stable