Hmm, I'm inclined to agree. Still, this draws my attention to the module
loading behaviour of modprobe and its method of automatically loading
modules as required:
alias net-pf-10 ipv6
... shouldn't this happen if/when the kernel attempts to register any
address of this family, or route for that matter?
I don't use the aliases file much at all, I simply don't trust it,
meaning I'm unfamiliar with how it works internally or how that would
impact ifup/ifdown. Being old school, I hand-type the modules I use
into /etc/modules, but even this would alleviate the problem.
In short, ===I don't see how module loading is any responsibility of
ifup/ifdown to begin with===. Even PPP connections load the ppp module
as required simply by executing pppd in any modern Linux environment.
That said, I don't particularly care which method is employed, as long
as I can stop hand-patching each and every ifupdown installation on my
network.
On the other hand, ===modprobe -Q should NEVER set a failure status===
as I understand it:
-Q --silent
As -q with the addition that all warnings and errors are also
silenced.
This doesn't state that it must return a True value, but I think for the
case of rapid or inconsequential execution, this fact seems implied to
me. What we have here is two problems compounding to produce a strange
(and inconvenient) result, but in my opinion they should both be fixed.
--
In respect to the default route designation, I don't see how this is
required in a modern environment. Router advertisements should
distribute next-hop routes automatically. In an environment where this
isn't the case, either route designations should work with appropriate
metrics.
The reason I changed the ::/0 to 2000::/3 in the patch was because ...
well, metrics. fe80::/8 is within the realm of ::/0 if the route metric
of ::/0 is set incorrectly. The route command doesn't provide any
method of manually setting a metric, so we take its word for it that it
is correct. Not ALL implementations do this properly, which results in
broken anycast routing, hence breaking router adverts and so on.
I haven't seen this happen since one instance of Debian years ago, so
===it's probably a null issue at this point and that modification can be
removed===. Still, I can't see any situation where it would break
anything, except perhaps an otherwise operational (but broken by design)
IPv6 network.
--
modprobe -Q is not 'silent enough' / ifup is too picky about return status.
https://bugs.launchpad.net/bugs/107432
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
