Subject: Re: /etc/rc out of order
To: Christoph Badura <firstname.lastname@example.org>
From: None <email@example.com>
Date: 01/06/1999 22:15:19
> That gives us a different ordering problem, though, namely the case
> when a local FS should be mounted on a directory of a remote FS.
Ah - I missed the "critical file systems" in the cited mail.
So at least my "/usr/src" example is not worth much.
Well, I can still imagine cases where the "local before remote" rule
would break things - on diskless machines for instance where it doesn't
need "netstart" to have the network up and running, thus the
local/remote distinction is meaningless.
So the next iteration would be to tell whether the network
is already up - but it might be not "up enough" for a particular
NFS mount because some routes are still missing...
A clean and complete solution could be something involving some
per-module "provides/requires" variables in the startup process, but
this is not only a nightmare to implement, but also needs
an administrator or a database which actually knows that pppd
needs /usr and /usr needs some route etc. I'd say this is a work
worth a Nobel award at least.
I'd propose: leave the mount ordering alone as long as there
is no real solution. /etc/netstart needs to be divided into a
"get interfaces and routes up" and a "start pppd" part.
Look at FreeBSD - some shell functions to be called at different
stages in the startup process are not bad. This doesn't solve
the chicken-and-egg-like problems completely, but it might help
in the most common cases.