Re: One more anomaly after 5.99.17 upgrade

[Alan Barrett <apb%cequrux.com@localhost>]

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
simple ideas:

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)