Are there any issues/plans to let users enable softupdates from inside of
sysinstall ?  Softupdates are already enabled in the GENERIC kernel, but to
turn them on you have to run tunefs with the filesystem unmounted.  Too
often I find myself doing an onsite install then doing all my customization
remotely only to realize that I've forgotten to enable softupdates.

My machines all run in securelevel 3, so the only fix I've come up with is
to horribly twist the purpose of the rc.diskless scripts, as they are the
only 'hooks' I've found in /etc/rc that can be executed before the r/w
mounts take place.  It works, but damn is it ugly.

If this is a good idea[tm], this could go either in the label editor
(probably more trouble than it's worth, as there is no code in sysinstall to
manipulate superblocks.)  There is also the issue of cramping in the label
editor screen.

What might make more sense is to have this on the Configuration menu, and
provide a dialog-driven interface to executing tunefs.  There might be
issues surrounding the dismount/remount sequence that would be required

A more extensible option would be to add a facility to /etc/rc to execute
user scripts from a directory on the root partition upon boot.  This
technique could then be applied to other purposes, such as this hack I use
for installing a new kernel on a remote box running at securelevel 3:

-- START --

cd /sys/compile/MYKERNEL
if [ -x kernel ]
        /usr/bin/make install
        /bin/rm /etc/rc.local
--- END ---

I install this script as /etc/rc.local.kerninst and hardlink it to
/etc/rc.local in lieu of running 'make installkernel' or 'make install' (if
I'm using the old kernel build method.)  This isn't all that clean because
it requires two reboots for a kernel install, and the reboot happens after
everything has been brought up (but just before kern.securelevel gets
bumped.)  Again, it works but it's ugly.  Having a facility for running
these 'early' config scripts, optimally with a way of deleting them or
flagging them as having been run already would be of great help.

Thoughts ?


James FitzGibbon                                           [EMAIL PROTECTED] Inc.                              Voice/Fax +1 416 306-0466/0452

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to