route6d is in /usr/sbin, doesn't start on boot

[Greg Troxel]

I have been finding that route6d does not start on boot (with
route6d=YES in rc.conf).

After much consternation, I found that the problem is that route6d is in
/usr/sbin, but only expresses a dependency on mountcritlocal, and thus
/usr is not necessarily mounted yet, (with default values).

With the following patch, route6d starts on boot:

--- /usr/netbsd-etc/etc/rc.d/route6d 2007-07-09 14:33:22.000000000 -0400
+++ route6d 2011-08-11 11:05:06.000000000 -0400
@@ -4,7 +4,7 @@
#

# PROVIDE: route6d
-# REQUIRE: network mountcritlocal
+# REQUIRE: network mountcritlocal mountcritremote
# BEFORE: NETWORKING

$_rc_subr_loaded . /etc/rc.subr


So,

should I commit this (I think so, because it fixes the immediate
issue)

Why is route6d in /usr/sbin while routed is in /sbin? It seems that
needing routing to mount /usr is sufficiently fraught with perils that
it doesn't make sense. So I'd say they both belong in /usr/sbin, but
I don't think it's worth the churn. So I am in favor of letting this
be.


Or, is this whole critical_filesystems_{local,remote} bit no longer
sensible? Here, I am agnostic, and wouldn't mind this being cleaned
up, but I don't see the route6d problem as a reason to get into that.



Given all that, unless I hear objections, I'm going to apply the above
diff.

[Greg Troxel]

Post by Greg Troxel
I have been finding that route6d does not start on boot (with
route6d=YES in rc.conf).
After much consternation, I found that the problem is that route6d is in
/usr/sbin, but only expresses a dependency on mountcritlocal, and thus
/usr is not necessarily mounted yet, (with default values).

It turns out that mountcritremote depends on NETWORKING which depends on
route6d. Unfortunately there really is a cycle in our requirements.

So, options are:

1) move route6d (and rtsol, rtsold) to /sbin

2) drop the notion of nfs mounting /usr from our rc.d plan

3) in mountcritremote, depend on, instead of NETWORKING
network wpa_supplicate dhclient staticroute

4) move /usr to critical_filesystems_local and leave the problem to
people who use nfs /usr to figure out what makes sense in their world.


The 3rd option essentially splits NETWORKING into NETWORKING_BASIC and
NETWORKING_ROUTING. It seems crazy to nfs mount /usr across a router,
so this seems ok to me.

But, if putting route6d in /sbin is the right answer, that's fine.
(And if someone who has better install-set-rearranging-fu than me wants
to, that would be even better.)

[Alan Barrett]

Post by Greg Troxel
It turns out that mountcritremote depends on NETWORKING which
depends on route6d. Unfortunately there really is a cycle in
our requirements.

[...]

Post by Greg Troxel
The 3rd option essentially splits NETWORKING into
NETWORKING_BASIC and NETWORKING_ROUTING. It seems crazy to nfs
mount /usr across a router, so this seems ok to me.

Yes, this makes sense. I'd probably keep the name "NETWORKING"
for the second stage, and include static routes in the new
"NETWORKING_BASIC" stage, so people who really want network mounts
across a router can get there using static routes.

Post by Greg Troxel
But, if putting route6d in /sbin is the right answer, that's
fine. (And if someone who has better install-set-rearranging-fu
than me wants to, that would be even better.)

routed is in /sbin, so it probably makes sense to put route6d
there too.

--apb (Alan Barrett)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de