Subject: Re: /rescue, crunchgen'ed?
To: Martin Husemann <firstname.lastname@example.org>
From: Richard Rauch <email@example.com>
Date: 08/31/2002 18:49:36
(Sorry for the numerous typos in the original. On reading it, I'm
appalled at myself. (^& Oh well...)
> > The former seems about like the dependancy on crunchgen, and elimites the
> > complexity of having two sets of binaries.
> While exploding the / partition size. Otherwise: fine. Maybe we should add
If space on / is a problem for so many, why do /home and /var reside on /
by default? I have trouble believing that a cramped / is a serious issue.
I'm sure you can find a few machines for which this acttuall matters.
Crunchgen may be preferable for them. They may even want their / to have
crunchgen binaries (from the numbers someone listed, I think that that
saves even more space than shared, yes?). People in such "extreme"
environments will presumably want or need to do some extra work to get
things working anyway; a default setup that they can override (and which
doesn't actively impede them installing a working system) seems like the
appropriate response, to me.
> yet another make knob to generate uncrunched /rescue binaries for those that
> like it and have the space available? (No idea if this is easily implementable
> without making a big mess out of the /sbin and /bin makefiles)
Or, generate uncrunched /rescue and add a knob to *not* generate /rescue.
If people want, they can use the dynamic-linked root (or the old
static-linked root) as their sole setup. Then the Makefile knob would be
"generate /rescue or not", which should be fairly simple.
I'm not sure how much it complicates things to make a crunchgen'ed /rescue
based on present-day /, but if the cost of such things is being weighed
carefully, surely it would be easier to make a /rescue that looks more
like present-day / than to use crunchgen for it. Yes? And less "mess" in
> > Perhaps, as well (if this isn't already part of the plan), /rescue (if
> > provided) should be a distinct parttion
> That you mount by which 'mount'/'mount_ffs' binary if your dynamic binaries
> do not work?
Err...I don't remember if I had fully engaged my brain on that. (^&
A couple of post-hoc responses would be:
a) Make mount static, or provide a static copy somewhere. This still
depends upon a lynchpin file in your regular / though.
b) Make the /rescue partition bootable (i.e., include a kernel, etc.).
This will add a few more megs, but would provide a fairly robust
rescue environment. Presumably there is no need to boot multiuser
(Yes, this could be done without any real support from the NetBSD
project... But having a ``rescue'' environment optionally created
at install-time (or easily unpacked into a filesystem from a .tar.gz)
seems rather simpler, and would make the rescue environment more
uniform, as an OS feature.)
I think that I had the latter in mind when I posted the original comment,
but I can't be completely sure. (^&
``I probably don't know what I'm talking about.'' --firstname.lastname@example.org