To the submitter: A better short-term workaround if you prefer not to
edit conffiles that are hopefully going to be fixed soon, is to do
# mkdir /var/run/network
# ln -sf /var/run/network/ /etc/network/run
Otherwise the underlying bug might show up next time you boot, anyway.
The culprit seems to be the following snippet (lines 92ff, reformated
for email) in the postinst of -4.12:
if RUN_CANONICALDIR="$(readlink -f /etc/network/run)" &&
[ "$RUN_CANONICALDIR" ] ; then
if ! mkdir "$RUN_CANONICALDIR" ; then
report_err "Failure creating directory ${RUN_CANONICALDIR}. Aborting."
exit 1
fi
else
report_err \
"The canonical path of /etc/network/run could not be determined. Aborting."
exit 1
fi
The problem is that "readlink -f /etc/network/run" returns nothing and
exits with failure when /etc/network/run is a dangling symlink, so the
mkdir that is the point of this code never gets a chance to run.
This behavior is exhibited by the readlink in coreutils 5.2.1-2
(sid+sarge), but not for the readlink in debianutils 1.6.2woody1
(woody).
Code that depends on readlink -f being able to stop at a dangling
symlink also appears in /etc/init.d/{ifupdown,ifupdown-clean}
and will abort the boot initialization on systems where
/etc/network/run refers to a ramdisk. (Which I suppose is the default,
as I do not remember having done anything to redirect /etc/network/run
myself).
Refusing to work with dangling links is the documented behavior in GNU
readlink, so coreutils probably cannot be faulted for this. A
quick-and-dirty workaround that should work in the most common cases
would be to say
$(readlink -f /etc/network/run || readlink /etc/network/run)
instead of just
$(readlink -f /etc/network/run)
in all three affected files.
--
Henning Makholm "I ... I have to return some videos."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
