[Group.of.nepali.translators] [Bug 1806777] Re: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain
This bug was fixed in the package open-iscsi - 2.0.874-5ubuntu2.6 --- open-iscsi (2.0.874-5ubuntu2.6) bionic; urgency=medium * debian/iscsi-disk.rules: Fix bug with LVM on top of iscsi devices. (LP: #1807978) open-iscsi (2.0.874-5ubuntu2.5) bionic; urgency=medium [Scott Moser] * debian/extra/initramfs.local-top: handle iSCSI iBFT DHCP to correctly run ipconfig to gather all DHCP config info, including DNS search domain, which iBFT can't provide. (LP: #1806777) -- Scott Moser Tue, 11 Dec 2018 19:14:17 -0500 ** Changed in: open-iscsi (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: open-iscsi (Ubuntu Cosmic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1806777 Title: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain Status in cloud-init: Invalid Status in cloud-init package in Ubuntu: Invalid Status in open-iscsi package in Ubuntu: Fix Released Status in cloud-init source package in Trusty: Invalid Status in open-iscsi source package in Trusty: Invalid Status in cloud-init source package in Xenial: Invalid Status in open-iscsi source package in Xenial: Fix Released Status in cloud-init source package in Bionic: Invalid Status in open-iscsi source package in Bionic: Fix Released Status in cloud-init source package in Cosmic: Invalid Status in open-iscsi source package in Cosmic: Fix Released Status in cloud-init source package in Disco: Invalid Status in open-iscsi source package in Disco: Fix Released Status in open-iscsi package in Debian: New Bug description: [impact] in bug 1752391, cloud-init was updated to check if the initramfs has specific iscsi root device config (e.g. static initramfs config, or ibft), and if so then set up the interface in e/n/i but do not mark it as 'auto'. This prevents ifupdown from actually running dhclient for the interface; the reason for the change in that bug was to prevent a hang at shutdown, as taking down the interface removes access to the iscsi root disk (thus hanging the system). However, iBFT has no mechanism in its spec to provide the DNS search domain, so while the interface ip address/netmask and gateway is correctly set up when the system finishes booting, it does not contain any search domain in /etc/resolv.conf. There is no way to get this information except from an actual dhcp query/response. In the initramfs, if open-iscsi does not detect ibft (or have static config built-in) then it will not create a /run/net-IFACE.conf file; if it does find ibft (or have static config) it will create a /run /net-IFACE.conf file with the config data that it has (e.g. with ibft, all the interface configuration that ibft is able and configured to provide). After this (setting up the interface and mounting the root dev), ipconfig runs and checks for the existence of /run/net- IFACE.conf file. If it does NOT exist, then ipconfig creates it containing the result of the dhcp lease response that ipconfig received - which includes the dns search domain. However, if there is already a /run/net-IFACE.conf file, ipconfig does NOT update it. So, the file created by open-iscsi remains, without any dns search domain. Once the system boots, resolvconf checks for existance of the /etc /net-IFACE.conf file, and if found it transfers some of the data into /etc/resolv.conf (e.g. the dns search domain). Since it does not contain any dns search domain, the /etc/resolv.conf file does not contain it either. If the system is configured to start dhclient for the interface, then dhclient receives and sets up the system resolv.conf to use the dns search domain correctly. For trusty: cloud-init is very different and sets up the running system ifupdown to start dhclient for the root device interface. The dns search domain is therefore configured by dhclient in the runtime system. For xenial: cloud-init sets up the iscsi root device's interface with a e/n/i configuration for dhcp, but leaves its 'auto' line commented out, e.g.: # control-manual ens3f0 iface ens3f0 inet dhcp dns-nameservers 169.254.169.254 gateway 10.0.0.1 this results in no dns search domain for the system. (note: as mentioned above, it does this due to bug 1752391). For bionic and later: cloud-init sets up netplan instead of ifupdown; netplan has no such 'auto' mechanism. The initramfs-tools scripts create a /run/netplan/$DEVICE.yaml file which (when ibft uses dhcp) contains the 'critical' parameter, causing netplan to create a systemd-networkd .network file with the "CriticalConnection" parameter set to true, which prevents systemd-networkd from ever taking the
[Group.of.nepali.translators] [Bug 1806777] Re: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain
This bug was fixed in the package open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu3.7 --- open-iscsi (2.0.873+git0.3b4b4500-14ubuntu3.7) xenial; urgency=medium [Scott Moser] * debian/extra/initramfs.local-top: handle iSCSI iBFT DHCP to correctly run ipconfig to gather all DHCP config info, including DNS search domain, which iBFT can't provide. (LP: #1806777) -- Dan Streetman Wed, 05 Dec 2018 14:33:36 -0500 ** Changed in: open-iscsi (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1806777 Title: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain Status in cloud-init: Invalid Status in cloud-init package in Ubuntu: Invalid Status in open-iscsi package in Ubuntu: Fix Released Status in cloud-init source package in Trusty: Invalid Status in open-iscsi source package in Trusty: Invalid Status in cloud-init source package in Xenial: Invalid Status in open-iscsi source package in Xenial: Fix Released Status in cloud-init source package in Bionic: Invalid Status in open-iscsi source package in Bionic: Fix Released Status in cloud-init source package in Cosmic: Invalid Status in open-iscsi source package in Cosmic: Fix Released Status in cloud-init source package in Disco: Invalid Status in open-iscsi source package in Disco: Fix Released Status in open-iscsi package in Debian: New Bug description: [impact] in bug 1752391, cloud-init was updated to check if the initramfs has specific iscsi root device config (e.g. static initramfs config, or ibft), and if so then set up the interface in e/n/i but do not mark it as 'auto'. This prevents ifupdown from actually running dhclient for the interface; the reason for the change in that bug was to prevent a hang at shutdown, as taking down the interface removes access to the iscsi root disk (thus hanging the system). However, iBFT has no mechanism in its spec to provide the DNS search domain, so while the interface ip address/netmask and gateway is correctly set up when the system finishes booting, it does not contain any search domain in /etc/resolv.conf. There is no way to get this information except from an actual dhcp query/response. In the initramfs, if open-iscsi does not detect ibft (or have static config built-in) then it will not create a /run/net-IFACE.conf file; if it does find ibft (or have static config) it will create a /run /net-IFACE.conf file with the config data that it has (e.g. with ibft, all the interface configuration that ibft is able and configured to provide). After this (setting up the interface and mounting the root dev), ipconfig runs and checks for the existence of /run/net- IFACE.conf file. If it does NOT exist, then ipconfig creates it containing the result of the dhcp lease response that ipconfig received - which includes the dns search domain. However, if there is already a /run/net-IFACE.conf file, ipconfig does NOT update it. So, the file created by open-iscsi remains, without any dns search domain. Once the system boots, resolvconf checks for existance of the /etc /net-IFACE.conf file, and if found it transfers some of the data into /etc/resolv.conf (e.g. the dns search domain). Since it does not contain any dns search domain, the /etc/resolv.conf file does not contain it either. If the system is configured to start dhclient for the interface, then dhclient receives and sets up the system resolv.conf to use the dns search domain correctly. For trusty: cloud-init is very different and sets up the running system ifupdown to start dhclient for the root device interface. The dns search domain is therefore configured by dhclient in the runtime system. For xenial: cloud-init sets up the iscsi root device's interface with a e/n/i configuration for dhcp, but leaves its 'auto' line commented out, e.g.: # control-manual ens3f0 iface ens3f0 inet dhcp dns-nameservers 169.254.169.254 gateway 10.0.0.1 this results in no dns search domain for the system. (note: as mentioned above, it does this due to bug 1752391). For bionic and later: cloud-init sets up netplan instead of ifupdown; netplan has no such 'auto' mechanism. The initramfs-tools scripts create a /run/netplan/$DEVICE.yaml file which (when ibft uses dhcp) contains the 'critical' parameter, causing netplan to create a systemd-networkd .network file with the "CriticalConnection" parameter set to true, which prevents systemd-networkd from ever taking the interface down, which avoids the hang on shutdown (or any other time dhcp fails/stops for the interface). However, it is still possible to remove netplan and install ifupdown in bionic (and later
[Group.of.nepali.translators] [Bug 1806777] Re: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain
This bug was fixed in the package open-iscsi - 2.0.874-5ubuntu12 --- open-iscsi (2.0.874-5ubuntu12) disco; urgency=medium [Scott Moser] * debian/extra/initramfs.local-top: handle iSCSI iBFT DHCP to correctly run ipconfig to gather all DHCP config info, including DNS search domain, which iBFT can't provide. (LP: #1806777) -- Dan Streetman Wed, 05 Dec 2018 11:28:12 -0500 ** Changed in: open-iscsi (Ubuntu Disco) Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1806777 Title: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain Status in cloud-init: Invalid Status in cloud-init package in Ubuntu: Invalid Status in open-iscsi package in Ubuntu: Fix Released Status in cloud-init source package in Trusty: Invalid Status in open-iscsi source package in Trusty: Invalid Status in cloud-init source package in Xenial: Invalid Status in open-iscsi source package in Xenial: In Progress Status in cloud-init source package in Bionic: Invalid Status in open-iscsi source package in Bionic: In Progress Status in cloud-init source package in Cosmic: Invalid Status in open-iscsi source package in Cosmic: In Progress Status in cloud-init source package in Disco: Invalid Status in open-iscsi source package in Disco: Fix Released Status in open-iscsi package in Debian: New Bug description: [impact] in bug 1752391, cloud-init was updated to check if the initramfs has specific iscsi root device config (e.g. static initramfs config, or ibft), and if so then set up the interface in e/n/i but do not mark it as 'auto'. This prevents ifupdown from actually running dhclient for the interface; the reason for the change in that bug was to prevent a hang at shutdown, as taking down the interface removes access to the iscsi root disk (thus hanging the system). However, iBFT has no mechanism in its spec to provide the DNS search domain, so while the interface ip address/netmask and gateway is correctly set up when the system finishes booting, it does not contain any search domain in /etc/resolv.conf. There is no way to get this information except from an actual dhcp query/response. In the initramfs, if open-iscsi does not detect ibft (or have static config built-in) then it will not create a /run/net-IFACE.conf file; if it does find ibft (or have static config) it will create a /run /net-IFACE.conf file with the config data that it has (e.g. with ibft, all the interface configuration that ibft is able and configured to provide). After this (setting up the interface and mounting the root dev), ipconfig runs and checks for the existence of /run/net- IFACE.conf file. If it does NOT exist, then ipconfig creates it containing the result of the dhcp lease response that ipconfig received - which includes the dns search domain. However, if there is already a /run/net-IFACE.conf file, ipconfig does NOT update it. So, the file created by open-iscsi remains, without any dns search domain. Once the system boots, resolvconf checks for existance of the /etc /net-IFACE.conf file, and if found it transfers some of the data into /etc/resolv.conf (e.g. the dns search domain). Since it does not contain any dns search domain, the /etc/resolv.conf file does not contain it either. If the system is configured to start dhclient for the interface, then dhclient receives and sets up the system resolv.conf to use the dns search domain correctly. For trusty: cloud-init is very different and sets up the running system ifupdown to start dhclient for the root device interface. The dns search domain is therefore configured by dhclient in the runtime system. For xenial: cloud-init sets up the iscsi root device's interface with a e/n/i configuration for dhcp, but leaves its 'auto' line commented out, e.g.: # control-manual ens3f0 iface ens3f0 inet dhcp dns-nameservers 169.254.169.254 gateway 10.0.0.1 this results in no dns search domain for the system. (note: as mentioned above, it does this due to bug 1752391). For bionic and later: cloud-init sets up netplan instead of ifupdown; netplan has no such 'auto' mechanism. The initramfs-tools scripts create a /run/netplan/$DEVICE.yaml file which (when ibft uses dhcp) contains the 'critical' parameter, causing netplan to create a systemd-networkd .network file with the "CriticalConnection" parameter set to true, which prevents systemd-networkd from ever taking the interface down, which avoids the hang on shutdown (or any other time dhcp fails/stops for the interface). However, it is still possible to remove netplan and install ifupdown in bionic (and later), and when that is done this bug exi
[Group.of.nepali.translators] [Bug 1806777] Re: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain
** Bug watch added: Debian Bug tracker #915669 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915669 ** Also affects: cloud-init (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915669 Importance: Unknown Status: Unknown ** Also affects: open-iscsi (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915669 Importance: Unknown Status: Unknown ** No longer affects: cloud-init (Debian) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1806777 Title: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain Status in cloud-init: Invalid Status in cloud-init package in Ubuntu: Invalid Status in open-iscsi package in Ubuntu: In Progress Status in cloud-init source package in Trusty: Invalid Status in open-iscsi source package in Trusty: Invalid Status in cloud-init source package in Xenial: Invalid Status in open-iscsi source package in Xenial: In Progress Status in cloud-init source package in Bionic: Invalid Status in open-iscsi source package in Bionic: In Progress Status in cloud-init source package in Cosmic: Invalid Status in open-iscsi source package in Cosmic: In Progress Status in cloud-init source package in Disco: Invalid Status in open-iscsi source package in Disco: In Progress Status in open-iscsi package in Debian: Unknown Bug description: [impact] in bug 1752391, cloud-init was updated to check if the initramfs has specific iscsi root device config (e.g. static initramfs config, or ibft), and if so then set up the interface in e/n/i but do not mark it as 'auto'. This prevents ifupdown from actually running dhclient for the interface; the reason for the change in that bug was to prevent a hang at shutdown, as taking down the interface removes access to the iscsi root disk (thus hanging the system). However, iBFT has no mechanism in its spec to provide the DNS search domain, so while the interface ip address/netmask and gateway is correctly set up when the system finishes booting, it does not contain any search domain in /etc/resolv.conf. There is no way to get this information except from an actual dhcp query/response. In the initramfs, if open-iscsi does not detect ibft (or have static config built-in) then it will not create a /run/net-IFACE.conf file; if it does find ibft (or have static config) it will create a /run /net-IFACE.conf file with the config data that it has (e.g. with ibft, all the interface configuration that ibft is able and configured to provide). After this (setting up the interface and mounting the root dev), ipconfig runs and checks for the existence of /run/net- IFACE.conf file. If it does NOT exist, then ipconfig creates it containing the result of the dhcp lease response that ipconfig received - which includes the dns search domain. However, if there is already a /run/net-IFACE.conf file, ipconfig does NOT update it. So, the file created by open-iscsi remains, without any dns search domain. Once the system boots, resolvconf checks for existance of the /etc /net-IFACE.conf file, and if found it transfers some of the data into /etc/resolv.conf (e.g. the dns search domain). Since it does not contain any dns search domain, the /etc/resolv.conf file does not contain it either. If the system is configured to start dhclient for the interface, then dhclient receives and sets up the system resolv.conf to use the dns search domain correctly. For trusty: cloud-init is very different and sets up the running system ifupdown to start dhclient for the root device interface. The dns search domain is therefore configured by dhclient in the runtime system. For xenial: cloud-init sets up the iscsi root device's interface with a e/n/i configuration for dhcp, but leaves its 'auto' line commented out, e.g.: # control-manual ens3f0 iface ens3f0 inet dhcp dns-nameservers 169.254.169.254 gateway 10.0.0.1 this results in no dns search domain for the system. (note: as mentioned above, it does this due to bug 1752391). For bionic and later: cloud-init sets up netplan instead of ifupdown; netplan has no such 'auto' mechanism. The initramfs-tools scripts create a /run/netplan/$DEVICE.yaml file which (when ibft uses dhcp) contains the 'critical' parameter, causing netplan to create a systemd-networkd .network file with the "CriticalConnection" parameter set to true, which prevents systemd-networkd from ever taking the interface down, which avoids the hang on shutdown (or any other time dhcp fails/stops for the interface). However, it is still possible to remove netplan and install ifupdown in bionic (and later), and when that is done this bug exists, so it should be fixed in those rele
[Group.of.nepali.translators] [Bug 1806777] Re: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain
** Changed in: open-iscsi (Ubuntu Trusty) Status: New => Invalid ** Description changed: [impact] in bug 1752391, cloud-init was updated to check if the initramfs has specific iscsi root device config (e.g. static initramfs config, or ibft), and if so then set up the interface in e/n/i but do not mark it as 'auto'. This prevents ifupdown from actually running dhclient for the interface; the reason for the change in that bug was to prevent a hang at shutdown, as taking down the interface removes access to the iscsi root disk (thus hanging the system). However, iBFT has no mechanism in its spec to provide the DNS search domain, so while the interface ip address/netmask and gateway is correctly set up when the system finishes booting, it does not contain any search domain in /etc/resolv.conf. There is no way to get this information except from an actual dhcp query/response. In the initramfs, if open-iscsi does not detect ibft (or have static config built-in) then it will not create a /run/net-IFACE.conf file; if it does find ibft (or have static config) it will create a /run/net- IFACE.conf file with the config data that it has (e.g. with ibft, all the interface configuration that ibft is able and configured to provide). After this (setting up the interface and mounting the root dev), ipconfig runs and checks for the existence of /run/net-IFACE.conf file. If it does NOT exist, then ipconfig creates it containing the result of the dhcp lease response that ipconfig received - which includes the dns search domain. However, if there is already a /run /net-IFACE.conf file, ipconfig does NOT update it. So, the file created by open-iscsi remains, without any dns search domain. Once the system boots, resolvconf checks for existance of the /etc/net- IFACE.conf file, and if found it transfers some of the data into /etc/resolv.conf (e.g. the dns search domain). Since it does not contain any dns search domain, the /etc/resolv.conf file does not contain it either. If the system is configured to start dhclient for the interface, then dhclient receives and sets up the system resolv.conf to use the dns search domain correctly. For trusty: cloud-init is very different and sets up the running system ifupdown to start dhclient for the root device interface. The dns search domain is therefore configured by dhclient in the runtime system. For xenial: cloud-init sets up the iscsi root device's interface with a e/n/i configuration for dhcp, but leaves its 'auto' line commented out, e.g.: # control-manual ens3f0 iface ens3f0 inet dhcp dns-nameservers 169.254.169.254 gateway 10.0.0.1 - this results in no dns search domain for the system. + this results in no dns search domain for the system. (note: as + mentioned above, it does this due to bug 1752391). For bionic and later: cloud-init sets up netplan instead of ifupdown; netplan has no such 'auto' mechanism. The initramfs-tools scripts create a /run/netplan/$DEVICE.yaml file which (when ibft uses dhcp) contains the 'critical' parameter, causing netplan to create a systemd- networkd .network file with the "CriticalConnection" parameter set to true, which prevents systemd-networkd from ever taking the interface down, which avoids the hang on shutdown (or any other time dhcp fails/stops for the interface). However, it is still possible to remove netplan and install ifupdown in bionic (and later), and when that is done this bug exists, so it should be fixed in those releases also. [test case] start a xenial system that uses ibft and check /etc/resolv.conf; there will be no dns search domain. for bionic or later, start a system that uses ibft, then install ifupdown and resolvconf and remove netplan.io. When the system is rebooted, the /etc/resolv.conf will not have any dns search domain. [regression potential] as this slightly changes when/how open-iscsi creates a /run/net-$DEVICE.conf file, this has the potential to boot a system with wrong or even no network configuration, when the system configures an iscsi device at boot, e.g. with iBFT. However, the patch does perform a 'fallback' which should prevent such failure when iBFT does work but ipconfig does not. [other info] this appears to have been introduced by bug 1752391. This bug may possibly also exist if the "ip=" parameter is used, which also triggers the cloud-init code that sets the runtime interface to 'manual' instead of 'auto', though I have not specifically tested that. - Trusty may need to be updated to handle bug 1752391's problem, which - would then mean trusty would also need this fix. + Trusty's open-iscsi does *not* create a /run/net-$DEVICE.conf file, so + the initramfs there will always run ipconfig to gather dhcp data and + save that; so this bug should not affect trusty. Bionic and late
[Group.of.nepali.translators] [Bug 1806777] Re: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain
** Description changed: [impact] in bug 1752391, cloud-init was updated to check if the initramfs has specific iscsi root device config (e.g. static initramfs config, or ibft), and if so then set up the interface in e/n/i but do not mark it as 'auto'. This prevents ifupdown from actually running dhclient for the interface; the reason for the change in that bug was to prevent a hang at shutdown, as taking down the interface removes access to the iscsi root disk (thus hanging the system). However, iBFT has no mechanism in its spec to provide the DNS search domain, so while the interface ip address/netmask and gateway is correctly set up when the system finishes booting, it does not contain any search domain in /etc/resolv.conf. There is no way to get this information except from an actual dhcp query/response. In the initramfs, if open-iscsi does not detect ibft (or have static config built-in) then it will not create a /run/net-IFACE.conf file; if it does find ibft (or have static config) it will create a /run/net- IFACE.conf file with the config data that it has (e.g. with ibft, all the interface configuration that ibft is able and configured to provide). After this (setting up the interface and mounting the root dev), ipconfig runs and checks for the existence of /run/net-IFACE.conf file. If it does NOT exist, then ipconfig creates it containing the result of the dhcp lease response that ipconfig received - which includes the dns search domain. However, if there is already a /run /net-IFACE.conf file, ipconfig does NOT update it. So, the file created by open-iscsi remains, without any dns search domain. Once the system boots, resolvconf checks for existance of the /etc/net- IFACE.conf file, and if found it transfers some of the data into /etc/resolv.conf (e.g. the dns search domain). Since it does not contain any dns search domain, the /etc/resolv.conf file does not contain it either. If the system is configured to start dhclient for the interface, then dhclient receives and sets up the system resolv.conf to use the dns search domain correctly. For trusty: cloud-init is very different and sets up the running system ifupdown to start dhclient for the root device interface. The dns search domain is therefore configured by dhclient in the runtime system. For xenial: cloud-init sets up the iscsi root device's interface with a e/n/i configuration for dhcp, but leaves its 'auto' line commented out, e.g.: # control-manual ens3f0 iface ens3f0 inet dhcp - dns-nameservers 169.254.169.254 - gateway 10.0.0.1 + dns-nameservers 169.254.169.254 + gateway 10.0.0.1 this results in no dns search domain for the system. For bionic and later: cloud-init sets up netplan instead of ifupdown; - netplan has no such 'auto' mechanism, but it creates systemd-networkd - .network file with the "CriticalConnection" parameter set to true, which - prevents systemd-networkd from ever taking the interface down, which - avoids the hang on shutdown (or any other time dhcp fails/stops for the - interface). + netplan has no such 'auto' mechanism. The initramfs-tools scripts + create a /run/netplan/$DEVICE.yaml file which (when ibft uses dhcp) + contains the 'critical' parameter, causing netplan to create a systemd- + networkd .network file with the "CriticalConnection" parameter set to + true, which prevents systemd-networkd from ever taking the interface + down, which avoids the hang on shutdown (or any other time dhcp + fails/stops for the interface). However, it is still possible to remove + netplan and install ifupdown in bionic (and later), and when that is + done this bug exists, so it should be fixed in those releases also. [test case] start a xenial system that uses ibft and check /etc/resolv.conf; there will be no dns search domain. + for bionic or later, start a system that uses ibft, then install + ifupdown and resolvconf and remove netplan.io. When the system is + rebooted, the /etc/resolv.conf will not have any dns search domain. + [regression potential] - depending on the specific fix, this has the potential to cause the - interface to be taken down which would then hang the system (due to root - device being iscsi). + as this slightly changes when/how open-iscsi creates a + /run/net-$DEVICE.conf file, this has the potential to boot a system with + wrong or even no network configuration, when the system configures an + iscsi device at boot, e.g. with iBFT. However, the patch does perform a + 'fallback' which should prevent such failure when iBFT does work but + ipconfig does not. [other info] this appears to have been introduced by bug 1752391. This bug may possibly also exist if the "ip=" parameter is used, which also triggers the cloud-init code that sets the runtime interface to 'manual' instead of 'auto', though I have not specifically tested that
[Group.of.nepali.translators] [Bug 1806777] Re: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain
** Changed in: cloud-init (Ubuntu Xenial) Status: In Progress => Invalid ** Changed in: cloud-init (Ubuntu Xenial) Assignee: Dan Streetman (ddstreet) => (unassigned) ** Also affects: open-iscsi (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: open-iscsi (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Disco) Importance: Undecided Status: Invalid ** Changed in: open-iscsi (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: open-iscsi (Ubuntu Bionic) Status: New => In Progress ** Changed in: open-iscsi (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: open-iscsi (Ubuntu Cosmic) Importance: Undecided => Medium ** Changed in: open-iscsi (Ubuntu Cosmic) Status: New => In Progress ** Changed in: open-iscsi (Ubuntu Cosmic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: open-iscsi (Ubuntu Disco) Importance: Undecided => Medium ** Changed in: open-iscsi (Ubuntu Disco) Status: New => In Progress ** Changed in: open-iscsi (Ubuntu Disco) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: open-iscsi (Ubuntu Xenial) Importance: Undecided => Medium -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1806777 Title: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain Status in cloud-init: Invalid Status in cloud-init package in Ubuntu: Invalid Status in open-iscsi package in Ubuntu: In Progress Status in cloud-init source package in Trusty: Invalid Status in open-iscsi source package in Trusty: New Status in cloud-init source package in Xenial: Invalid Status in open-iscsi source package in Xenial: In Progress Status in cloud-init source package in Bionic: Invalid Status in open-iscsi source package in Bionic: In Progress Status in cloud-init source package in Cosmic: New Status in open-iscsi source package in Cosmic: In Progress Status in cloud-init source package in Disco: Invalid Status in open-iscsi source package in Disco: In Progress Bug description: [impact] in bug 1752391, cloud-init was updated to check if the initramfs has specific iscsi root device config (e.g. static initramfs config, or ibft), and if so then set up the interface in e/n/i but do not mark it as 'auto'. This prevents ifupdown from actually running dhclient for the interface; the reason for the change in that bug was to prevent a hang at shutdown, as taking down the interface removes access to the iscsi root disk (thus hanging the system). However, iBFT has no mechanism in its spec to provide the DNS search domain, so while the interface ip address/netmask and gateway is correctly set up when the system finishes booting, it does not contain any search domain in /etc/resolv.conf. There is no way to get this information except from an actual dhcp query/response. In the initramfs, if open-iscsi does not detect ibft (or have static config built-in) then it will not create a /run/net-IFACE.conf file; if it does find ibft (or have static config) it will create a /run /net-IFACE.conf file with the config data that it has (e.g. with ibft, all the interface configuration that ibft is able and configured to provide). After this (setting up the interface and mounting the root dev), ipconfig runs and checks for the existence of /run/net- IFACE.conf file. If it does NOT exist, then ipconfig creates it containing the result of the dhcp lease response that ipconfig received - which includes the dns search domain. However, if there is already a /run/net-IFACE.conf file, ipconfig does NOT update it. So, the file created by open-iscsi remains, without any dns search domain. Once the system boots, resolvconf checks for existance of the /etc /net-IFACE.conf file, and if found it transfers some of the data into /etc/resolv.conf (e.g. the dns search domain). Since it does not contain any dns search domain, the /etc/resolv.conf file does not contain it either. If the system is configured to start dhclient for the interface, then dhclient receives and sets up the system resolv.conf to use the dns search domain correctly. For trusty: cloud-init is very different and sets up the running system ifupdown to start dhclient for the root device interface. The dns search domain is therefore configured by dhclient in the runtime system. For xenial: cloud-init sets up the iscsi root device's interface with a e/n/i configuration for dhcp, but leaves its 'auto' line commented out, e.g.: # control-manual ens3f0 iface ens3f0 inet dhcp dns-
[Group.of.nepali.translators] [Bug 1806777] Re: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain
Discussed with @smoser and we think this can be fixed in open-iscsi's initramfs local-top script; I am patching and testing now. ** Also affects: open-iscsi (Ubuntu) Importance: Undecided Status: New ** Changed in: open-iscsi (Ubuntu Xenial) Status: New => In Progress ** Changed in: open-iscsi (Ubuntu Xenial) Assignee: (unassigned) => Dan Streetman (ddstreet) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1806777 Title: cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain Status in cloud-init: Invalid Status in cloud-init package in Ubuntu: Invalid Status in open-iscsi package in Ubuntu: New Status in cloud-init source package in Trusty: Invalid Status in open-iscsi source package in Trusty: New Status in cloud-init source package in Xenial: In Progress Status in open-iscsi source package in Xenial: In Progress Status in cloud-init source package in Bionic: Invalid Status in open-iscsi source package in Bionic: New Bug description: [impact] in bug 1752391, cloud-init was updated to check if the initramfs has specific iscsi root device config (e.g. static initramfs config, or ibft), and if so then set up the interface in e/n/i but do not mark it as 'auto'. This prevents ifupdown from actually running dhclient for the interface; the reason for the change in that bug was to prevent a hang at shutdown, as taking down the interface removes access to the iscsi root disk (thus hanging the system). However, iBFT has no mechanism in its spec to provide the DNS search domain, so while the interface ip address/netmask and gateway is correctly set up when the system finishes booting, it does not contain any search domain in /etc/resolv.conf. There is no way to get this information except from an actual dhcp query/response. In the initramfs, if open-iscsi does not detect ibft (or have static config built-in) then it will not create a /run/net-IFACE.conf file; if it does find ibft (or have static config) it will create a /run /net-IFACE.conf file with the config data that it has (e.g. with ibft, all the interface configuration that ibft is able and configured to provide). After this (setting up the interface and mounting the root dev), ipconfig runs and checks for the existence of /run/net- IFACE.conf file. If it does NOT exist, then ipconfig creates it containing the result of the dhcp lease response that ipconfig received - which includes the dns search domain. However, if there is already a /run/net-IFACE.conf file, ipconfig does NOT update it. So, the file created by open-iscsi remains, without any dns search domain. Once the system boots, resolvconf checks for existance of the /etc /net-IFACE.conf file, and if found it transfers some of the data into /etc/resolv.conf (e.g. the dns search domain). Since it does not contain any dns search domain, the /etc/resolv.conf file does not contain it either. If the system is configured to start dhclient for the interface, then dhclient receives and sets up the system resolv.conf to use the dns search domain correctly. For trusty: cloud-init is very different and sets up the running system ifupdown to start dhclient for the root device interface. The dns search domain is therefore configured by dhclient in the runtime system. For xenial: cloud-init sets up the iscsi root device's interface with a e/n/i configuration for dhcp, but leaves its 'auto' line commented out, e.g.: # control-manual ens3f0 iface ens3f0 inet dhcp dns-nameservers 169.254.169.254 gateway 10.0.0.1 this results in no dns search domain for the system. For bionic and later: cloud-init sets up netplan instead of ifupdown; netplan has no such 'auto' mechanism, but it creates systemd-networkd .network file with the "CriticalConnection" parameter set to true, which prevents systemd-networkd from ever taking the interface down, which avoids the hang on shutdown (or any other time dhcp fails/stops for the interface). [test case] start a xenial system that uses ibft and check /etc/resolv.conf; there will be no dns search domain. [regression potential] depending on the specific fix, this has the potential to cause the interface to be taken down which would then hang the system (due to root device being iscsi). [other info] this appears to have been introduced by bug 1752391. This bug may possibly also exist if the "ip=" parameter is used, which also triggers the cloud-init code that sets the runtime interface to 'manual' instead of 'auto', though I have not specifically tested that. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1806777/+subscriptions _
