Package: ifupdown Version: 0.7~rc3 Severity: critical Justification: breaks the whole system
I have specified this bug as "critical/breaks the whole system", because its effect is that if an external PPP link does not come up for some reason, the system boot fails. It actually gets wedged so hard that you cannot even boot into recovery mode to fix it; the problem can only be resolved with a rescue disk. This is completely unacceptable. According to the ifupdown package changelog, as of version 0.7~alpha4, "ifup -a" will use the "updetach" option for PPP interfaces. This may be an attempt to address the problem described in #127786, #287173, and #347594, wherein it is implied that other boot scripts which depend on the PPP link should be able to rely on it being up by the time they are run. This fails for two reasons. First, the termination of "pppd updetach" does not by any means guarantee that the PPP link is up, only that the attempt was made. It might have timed out and then failed, so other boot processes must be prepared to deal with that contingency anyway. Second, PPP links can go up and down depending on conditions on external WAN links and telephone lines, which are not in any way controllable by the local system or its human administrators. For maximum resiliency, it therefore makes sense to specify the PPP options "persist maxfail 0" in /etc/network/interfaces, so that if the link does not come up on boot, or goes down later, the PPP daemon will keep retrying indefinitely until it does come up. Unfortunately, the combination of these options, a broken WAN link, and the "updetach" option now baked into the ifup binary result in an unbootable system, which cannot even be gotten into recovery mode. This is unacceptable. It is quite inappropriate for "updetach" to be hard-wired into a binary executable, where it can only be removed with a hex editor. However, the patch for #196877, where this change is made, provides another solution to the network dependency problem: "Allow passing PPP options" (presumably in /etc/network/interfaces). If anybody wishes to have the "updetach" behavior, let them specify it there, without forcing it on other installations where it is quite possibly fatal. Suggestion for further work on network dependencies at boot: perhaps this is better handled in a general way for any type of network interface, through hotplug or udev, or something like that? What happens if /etc/network/interfaces specifies "auto eth0/iface eth0 inet dhcp", and the DHCP server is not responding for some reason? Does this also result in a boot failure? Is this not exactly analogous to the PPP situation described above? There seems to be some discussion of these issues in #245642. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ifupdown depends on: ii dpkg 1.16.3 ii initscripts 2.88dsf-22.1 ii iproute 20120105-1 ii libc6 2.13-32 ii lsb-base 3.2-28 ifupdown recommends no packages. Versions of packages ifupdown suggests: pn isc-dhcp-client [dhcp-client] 4.2.2.dfsg.1-5 pn net-tools 1.60-23 pn ppp 2.4.5-5.1 pn rdnssd <none> -- no debconf information -- debsums errors found: debsums: changed file /sbin/ifdown (from ifupdown package) debsums: changed file /sbin/ifquery (from ifupdown package) debsums: changed file /sbin/ifup (from ifupdown package) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
