Date: Sat, 10 Mar 2001 04:19:51 -0500 From: James FitzGibbon <james@targetnet.com> To: current@freebsd.org Subject: sysinstall option for softupdates Message-ID: <20010310041951.G62392@targetnet.com>
next in thread | raw e-mail | index | archive | help
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 here. 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 -- #!/bin/sh # cd /sys/compile/MYKERNEL if [ -x kernel ] then /usr/bin/make install /bin/rm /etc/rc.local /sbin/reboot fi --- 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 ? -- j. James FitzGibbon james@targetnet.com Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010310041951.G62392>