On Tue, 5 Jun 2007, Don Jackson wrote:
> cd /home/openbsd/4.1/src/etc/../sys/arch/amd64/conf && config GENERIC
> config: cannot create ../compile/GENERIC: Permission denied
> *** Error code 2
>
> Stop in /home/openbsd/4.1/src/etc (line 11 of etc.amd64/Makefile.inc).
>
> (FYI, /usr/src -> /home/openbsd/4.1/src )
>
> Looks like make release is trying to build a new kernel in my /usr/src tree.
Hmmm. Readonly /home partition?
> 1) Is there a way to get make release to NOT build a new kernel inside
> my source tree?
The "obvious" kludge is to move .../conf and .../compile to somewhere
writable, replacing the directories with symbolic links.
An "inobvious" kludge is to mount something(s) writable on ..../conf
and .../compile. (cleverly having copied the relevant files there).
Unionfs used to be a cute way to do this, but that is no longer
supported. A memory file system might do the trick. (man mfs).
A dangerous kludge, or as it might be more properly called, a
"kulhavy", would be to find which Makefile(s) call for building the
kernels and remove the offending lines. There are gotchas connected
with this when it comes time to populate "RELEASE_DIR", especially
if all your kernels are not "just so" before "make release". The
way you make them "just so", of course, is to recompile them, so
why not let make release do it?
> 2) Actually, I have already built a GENERIC kernel anyway, it would be very
> nice
> if "make release" would be able to figure that out, and just use
> the already built
> GENERIC kernel. I understand it will still need to build bsd.mp,
> bsd.rd, etc.,
> but hopefully it would build those outside the source tree also.
I have a bug report that I will never file titled "Make doesn't".
"make" in the context of ports, releases, kernels and so on is not
the make we once loved, a program for compiling programs whose
source is updated. In these other contexts, it is instead a bizarre
and nearly opaque "write only" scripting language used to build
programs and systems, almost a wrapper for "autoconf", "libtool"
and concepually similar stuffs. So don't expect it to accept a
kernel that is built from up-to-date sources and config file as
being up-to-date, that is not make's true function in "make release".
(Or "make build", for that matter.) (Oh, if you mosey down the
tree away from /usr/src and don't use targets like "build" or
"release", make almost "makes" most of the time. But too often
it's a driver for "rm" and other tools already mentioned and
implicitly cursed, and this overshadows its original purpose. The
whole idea of make ~was~ to avoid rm'ing all intermediates ("make
clean") all the time, but this is now a common first target -- there
are, ahem, human-factor reasons for this (doltish lusers poking
at source with sticks), but there may be stuff now that cannot
be built properly without a "make clean" preliminary step, for thus do
tails wag dogs.)
The "obvious" kludge above will solve your "build this outside the src
tree" problem in the readonly-dodging sense.
I am feeling uneasy, though. "make release" may wish to do some other
"minor" and "incidental" (but abending) writes in /usr/src in the release
process. You are well-positioned to discover them ;-)
An unrelated gotcha with "make release" is that svnd0 must be free
before you start, and must stay free until it's used towards the
~end~ of the "make release". So if you use svnd0 routinely for
something, don't. Update: in 4.1, there is now a variable VND which
defaults to svnd0. So if you use svnd0, you can have "release"
build its ramdisks on a different svnd device by saying so in
/etc/mk.conf or on the command line. (This is a nice improvement!).
Dave
--
Resistance is futile. You've already been assimilated.
