+ExecStop=/bin/sh -c 'for f in "$@"; do [ -e "$f" ] || continue; echo "$f existed."; exit 1; done; exit 0' -- /run/initramfs/open-iscsi.interface /run/network/network-root-fs ExecStop=/sbin/ifdown -a --read-environment
This will leave networking.service in "failed" state on stop -- *if* you do this hack, then please just put it into the existing ExecStop= line, and simplify this: ExecStop=/bin/sh -c '[ -e /run/initramfs/open-iscsi.interface /run/network/network-root-fs ] || ifdown -a --read-environment' However, this is still a nasty hack. Why would ifdown shut down the interface in the first place? If you use iSCSI, then /e/n/i should *not* have a "dhcp" stanza (and an "auto enXXX) for that interface, but a "manual" one, so that the declaration and behavior don't fight with each other. I. e.: - If ifdown downs a "manual" interface, then let's fix that properly. - If /e/n/i still has a "dhcp" declaration, then drop that (I thought that got fixed ages ago already). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1629972 Title: networking stop incorrectly disconnects from (network) root filesystem Status in MAAS: Triaged Status in ifupdown package in Ubuntu: Confirmed Status in ifupdown source package in Xenial: Confirmed Bug description: With the switch to systemd, all support for iscsi root (and other) filesystems disappeared, since shutdown yanks the rug out from under us. Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i creates..), the DEV check should be expanded to include iscsi devices, and networking.service ExecStop should honor those checks. Related bugs: * bug 1229458: grub2 needed changes * bug 1621615: network not configured when ipv6 netbooted into cloud-init * bug 1621507: ipv6 network boot does not work [Impact] With the changes from the above, the iscsi root (at least in the ipv6 case) gets disconneceted prior to clean shutdown (ifdown downs the interface), resulting in a failure to enlist, commission, or deploy cleanly under MAAS. (and a failure to cleanly unmount the root filesystem when it is over iscsi.) [Test Case] Given a MAAS 2.0 installation, and the packages in the other bugs, attempt to enlist, commission, or deploy a host with xenial. [Regression potential] This restores the pre-xenial behavior of not shutting down the interface if there are network drives at the time that neworking is stopped (making it a no-op.) The additional change is to detect "/dev/disk/by-path/*-iscsi-*" as a network disk, replacing the check for the existence of /etc/iscsi/iscsi.initramfs, which was only created by debian-installer (and maas until recently). To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1629972/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
