[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: One more anomaly after 5.99.17 upgrade
On Sat, 12 Sep 2009, Paul Goyette wrote:
> [running /etc/rc.d/mountcritremote]
> /etc/rc.d/mountcritremote reported failure status 1
/etc/defaults.rc.conf sets critical_filesystems_local=/var and
critical_filesystems_remote=/usr. Perhaps you didn't override those,
and you don't have a /usr file system? mountcritremote redirects the
output of the "mount" command to /dev/null, so you won't see the actual
error message when it tries to mount the nonexistent /usr file system.
I think we need a way of distinguishing between
"critical_filesystems_remote=/usr because that's the default" and
"critical_filesystems_remote=/usr because the admin said so", with
no error in the first case even if /usr doesn't exist. I have two
A) Set critical_filesystems_remote="DEFAULT" and
critical_filesystems_remote="DEFAULT" in /etc/defaults/rc.conf,
and teach mount_critical_filesystems in rc.subr that "DEFAULT"
means "try /var or /usr as appropriate, but it's not an error
if it does not exist.
B) Set critical_filesystems_remote="NOERROR:/var" and
critical_filesystems_remote="NOERROR:/usr" in /etc/defaults/rc.conf,
and teach mount_critical_filesystems in rc.subr that "NOERROR:foo"
means "try foo, but it's not an error if it does not exist".
> [running /etc/rc.d/savecore]
> Checking for core dump...
> savecore - - - no core dump
> /etc/rc.d/savecore reported failure status 1
Either rc.d/savecore or savecore(8) itself should be changed to make
"no core dump" not an error.
--apb (Alan Barrett)
Main Index |
Thread Index |