Package: ifupdown Version: 0.7.53.1 Severity: normal Dear Maintainer,
I am reporting from a different computer because the affected computer is still deadlocked, but the system information below is largely the same because both (64-bit Intel) computers have been updated today to the latest version of jessie after not updating for roughly a month in each case. I was going to add this additional report to <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218>, but that one has been closed so apparently I have to start a new bug report for this on-going issue. This fairly modest recent update made the other computer unbootable. The last message in the boot sequence is "A start job is running for LSB: Raise network interfaces. (HHh MMmin SSsec / no limit) where HH is now up to 3 (hours). Ctrl-C doesn't break the deadlock and if I type ctrl-alt-del, then the boot sequence is gone through again until this same deadlock is reached. >From skimming through the comments in bug 754218 I had the impression that jessie had been fixed in this regard in the sense that when deadlocks like this occurred, it would eventually timeout. That appears not to be the case from both HH being so high above and also the "no limit" in the message. So can we have an immediate Jessie fix for that unlimited timeout at least? A slowly booting machine is far preferable to one that won't boot at all. :-) Also, could someone here give clear directions about how to get out of the current deadlock so I can use that other computer or is a rescue distro like RIP necessary to get that computer working again? Note again, ctrl-C has no effect and ctrl-alt-del just reboots into the same deadlock again. >From previous experience with this deadlock on my current computer, I suspect this deadlock was caused because of the following stanza in /etc/network/interfaces on the currently deadlocked system (with the pre-up commands commented out on my current computer to avoid the deadlock). auto eth0 iface eth0 inet dhcp pre-up [ -f /etc/init.d/ferm ] pre-up /etc/init.d/ferm start >| /tmp/ferm.out 2>&1 The point of those two pre-up commands (which I have used on Debian for a very long time) was to work around a slight ferm issue where the configured firewall is put into place by ferm after networking is up, and I prefer to do that before (on at least non-NFS systems like this one where /etc/init.d/ferm is available regardless of networking) to avoid that small gap in firewall coverage. Up to today's modest update the above pre-up commands were not causing any trouble on that system (which has a USB stick drive rather than a normal HD) so I did not comment them out. Could you advise me how to get the above ferm workaround to work on non-NFS systems like this one (and also my present one) without generating a deadlock? In sum I need (1) a quick fix so the timeout is not indefinite, (2) a cookbook how to get out of this deadlock without resorting to a rescue distro, and (3) advice on how to use pre-up like above without running into deadlock trouble. Thanks in advance for your help with these issues. Alan -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-59 ii iproute 1:3.16.0-2 ii iproute2 3.16.0-2 ii libc6 2.19-18+deb8u1 ii lsb-base 4.1+Debian13+nmu1 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.3.1-6 Versions of packages ifupdown suggests: ii net-tools 1.60-26+b1 ii ppp 2.4.6-3.1 pn rdnssd <none> -- no debconf information
