install-etc-files iso_image_mi iso-image_md_pre iso-image_md_post snap_kern
- add the following targets to the RELEASEDIR=="" check:
iso_image_mi iso-image_md_pre iso-image_md_post snap_kern
- improve comments around make .flow control statements (including adding
some helper # { ... # } comments around large .if statements for (ab)use
with vi showmatch mode)
- clean up whitespace
at the end, and as wscons (actually ttyE0) is required to login on the console,
it is probably better that an out of space MAKEDEV fail on some other device.
and links exist:
${ntpd_chrootdir}/dev/clockctl
/var/db/ntp.drift -> ${ntpd_chrootdir}/var/db/ntp.drift
and then start ntpd with the appropriate options to run chroot(2)ed
under $ntpd_chrootdir as user ntpd group ntpd.
to take advantage of this, set ntpd_chrootdir in /etc/rc.conf.
[this is based on similar work i did for rc.d/named]
when building the kernel sets and placing gzip'd kernels in binary/kernels.
For example, if KERNEL_SUFFIXES were set to "ecoff srec", then the kernel
set would include:
netbsd
netbsd.ecoff (only if it exists in the kernel compile directory)
netbsd.srec (only if it exists in the kernel compile directory)
This is useful for packaging kernel sets for platforms which have
extra special requirements for loading the kernel.
more consistent. To quote the comment in etc/Makefile
that describes how it's done:
# This target builds the kernels specified by each port. A port may
# specify the following kernels:
#
# KERNEL_SETS The list of kernels that will be
# packaged into sets, named
# kern-${kernel}.tgz. These kernels
# are also placed in the binary/kernels
# area of the release package as
# netbsd-${kernel}.gz.
#
# EXTRA_KERNELS Additional kernels to place in the
# binary/kernels area of the release
# package as netbsd-${kernel}.gz, but
# which are not placed into sets. This
# allows a port to provide e.g. a netbootable
# installation kernel containing a ramdisk.
#
# BUILD_KERNELS Additional kernels to build which are
# not placed into sets nor into the
# binary/kernels area of the release
# package. These are typically kernels
# that are built for inclusion only in
# installation disk/CD-ROM/tape images.
#
the latter being called by the "distribution" target. This allows the
various /etc/... files to be installed manually in a convenient way, if
desired.
NOTE: It is INTENTIONAL that this target is not named "install".
or distribution.
Also, clean up the check and include <sys/endian.h> instead -- some platforms'
<machine/endian_machdep.h> pull in the definitions of _BIG_ENDIAN and
_LITTLE_ENDIAN, invalidating the test; this makes the check values uniformly
"4321" and "1234" respectively.
Shouldn't be needed, but install has no other good way to deal with
this.
Pointed out by Rob Windsor in PR 14394 -- I committed his patch plus
one for something he didn't hit yet.
the etc Makefile override that by putting USETOOLS into $.MAKEOVERRIDES
This way the default for kernel compiles is still to use the installed
toolchain instead of depending on $TOOLDIR. $TOOLDIR can be used by
simply adding USETOOLS=yes to the command line as usual.
Adjust each ports template to set the default no setting and also pull in
bsd.own.mk if they weren't already to ensure they'll build correctly
with the new toolchain setup.
csh: Permission denied
csh: Trying to start from "/var/log"
message.
This was caused by the
su -m uucp -c "uustat -a"
line being executed in a directory not readable by uucp. The login
shell implied by -m is of course root's shell, /bin/csh, which doesn't
like not being able to read the dir it is in, and thus the errors. By
temporarily cd'ing to /tmp the problem is fixed.
What is really needed, of course, is a way to tell su what shell you
want to use explicitly, especially for use in scripts where the
vagaries of which shell the login executing the script uses should not
be depended on. No such method exists. One should be added.
Indeed, it might also be nice to have a way of telling su to directly
execute a command with -c rather than using a shell to interpret the
command.
I cannot find any standards documents that specify su at the moment,
though. SuSv2 is silent on su(8).