tags 810656 + pending thanks On Sun, Jan 10, 2016 at 05:50:05PM -0800, Alan W. Irwin wrote:
> 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. You can reopen bugs that were closed, but it's OK to open a new one. > 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. [...] > 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. :-) That's indeed a problem. The upcoming version of ifupdown will have a timeout of 5 minutes. > 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. That I actually don't know, I suspect you have to ask some systemd gurus about how to do that. > >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? If it's ferm itself that is stuck, then you can apply a timeout to that one, like this: auto eth0 iface eth0 inet dhcp pre-up timeout 1m service ferm start The timeout command should always be installed on a Debian system, in /usr/bin. I hope this helps. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@debian.org>
signature.asc
Description: Digital signature
