For me, more often than not, the backgrounded syslogd daemon is not
yet ready to process log messages before other things (such as named)
want to log a heap of them. It seems that it's the O_SYNC writes of
the stuff coming in from /dev/klog that's the slowdown.
Anyway, instead of using the libc daemon, roll a modified version. This
one has a timeout. The child will wait for either the timeout to expire
or the child process to signal it to let it know that it's "ready" and
the /dev/log socket is set up and active, so it's safe to continue the
boot. It adds a small fraction of a second pause to the boot time, but on
the other hand the overall boot time is *quicker* since the disk is not
being thrashed while the log messages are getting written out synchronously
one by one while other daemons are loading in parallel.
The timeout is in case the child segfaults or something before becoming
fully operational.
SLIP/PPP devices, putting them before the others in the network device
selection menu.
2. Change "Other" to "URL" so as not to conflict with the keyboard accellerator
for the "OK" button in FTP site selection menu.
3. Detect the NULL last symbol in the name list and initialize the other
members correctly.
First, change sysinstall and the Makefile rules to not build the kernel
nlist directly into sysinstall now. Instead, spit it out as an ascii
file in /stand and parse it from sysinstall later. This solves the chicken-n-
egg problem of building sysinstall into the fsimage before BOOTMFS is built
and can have its symbols extracted. Now we generate the symbol file in
release.8.
Second, add Poul-Henning's USERCONFIG_BOOT changes. These have two
effects:
1. Userconfig is always entered, rather than only after a -c
(don't scream yet, it's not as bad as it sounds).
2. Userconfig reads a message string which can optionally be
written just past the boot blocks. This string "preloads"
the userconfig input buffer and is parsed as user input.
If the first command is not "USERCONFIG", userconfig will
treat this as an implied "quit" (which is why you don't need
to scream - you never even know you went through userconfig
and back out again if you don't specifically ask for it),
otherwise it will read and execute the following commands
until a "quit" is seen or the end is reached, in which case
the normal userconfig command prompt will then be presented.
How to create your own startup sequences, using any boot.flp image
from the next snap forward (not yet, but soon):
% dd of=/dev/rfd0 seek=1 bs=512 count=1 conv=sync <<WAKKA_WAKKA_DOO
USERCONFIG
irq ed0 10
iomem ed0 0xcc000
disable ed1
quit
WAKKA_WAKKA_DOO
Third, add an intro screen to UserConfig so that users aren't just thrown
into this strange screen if userconfig is auto-launched. The default
boot.flp startup sequence is now, in fact, this:
USERCONFIG
intro
visual
(Since visual never returns, we don't need a following "quit").
Submitted-By: phk & jkh
kernel" mechanism. This is just the foundation - more work follows
and will be committed over the next few hours.
Submitted-by: "Eric L. Hernes" <erich@lodgenet.com> & jkh
possibility of security holes allowing root penetration.
Inspired by: Mark Handley <M.Handley@cs.ucl.ac.uk> and
Theo de Raadt <deraadt@theos.com> independently
Submitted by: Theo de Raadt <deraadt@theos.com>
have it check to see that it doesn't contain any '/' characters. This
prevents possible silliness like ypcat "../../../kernel". We already
test the domain name for this in yp_validdomain(), and ypserv itself
tests the map name in yp_open_db(), but it doesn't hurt to be paranoid
and test for it in the generic access routine too. rpc.ypxfrd does not
test the map name for slashes, but it does call yp_access() with the
map name, so this removes a potential vulnerability from there.
Also make the tests for IPPORT_RESERVED a little more selective: make
sure it trips when map == master.passwd.*, prog == YPPROC and proc ==
YPPROC_XFR, and prog == YPXFRD_FREEBSD_PROG and proc == YPXFRD_GETMAP.
Also use IPPORT_RESERVED instead of hard-coded value.
by sysctl and never can be in their documented form (kern.name_max would
have to become fs.filesystemname.name_max, etc.).
Added missing references to user.stream_max and user.tzname_max. These
seem to misnamed. <sys/sysconf.h> says that they correspond to POSIX2
names, but the sysconf names don't have POSIX2 or "posix2" like all the
other POSIX2 names.
and use /dev/console.
I really think the proper test is to determine which device has been configured
to be the console (remember the RB_SERIAL flag?) and use it instead of always
trying to open /dev/ttyv0 first.
and the user inserts a floppy), read the config file to pre-define variables
for a custom installation.
[Note: I fixed one bug in LOAD_CONFIG_FILE code, but it's still not perfect.]
