[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces
Si-Wei, What environment and methodology are you testing with? I do not see the same results you are reporting. I am using the instructions you previously provided, and with an 18.04.5 Ubuntu image, I see the expected network interface naming (ens3, ens3nsby), and do not see /run/systemd/network or /run/udev/rules.d as you describe. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1820929 Title: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces Status in netplan: Triaged Status in initramfs-tools package in Ubuntu: New Status in netplan.io package in Ubuntu: Triaged Status in systemd package in Ubuntu: Incomplete Status in initramfs-tools source package in Bionic: Fix Released Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New Bug description: [Impact] * At present, virtual machines utilizing net_failover network interface configurations are incorrectly configured due to the reliance on the MAC address to identify specific network interfaces. When net_failover is utilized, multiple interfaces will bear the same MAC address (the net_failover master itself, as well as the interfaces subordinate to it), rendering the MAC address ineffective for unique identification of the interface. This results in incorrect naming of network interfaces from the "set-name" directive in the netplan configuration. * The solution here is to use the interface name instead of the MAC address when the interface is a net_failover master device. Logic is added on initramfs-tools to check the device type and virtio flags to apply this change only to net_failover master devices. [Test Case] * The change can be tested by configuring a virtual machine with a virtio_net network device with the "failover=on" option to the "-device" option to qemu, e.g., -device virtio-net- pci,netdev=hostnet0,id=net0,bus=pci.0,addr=0x3,mac=00:00:17:00:18:04,failover=on * This will set the virtio device "standby" feature bit (bit 62, counting from 0). This requires a version of qemu with support for this feature. * When so configured, the netplan configuration generated by initramfs will not contain a "macaddress:" match directive for the network interface in question. [Regression Potential] * Erroneous identification of a network interface as a net_failover master device could lead to omission of a macaddress directive, causing interfaces to be incorrectly named. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1820929/+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
[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces
Si-Wei, In the test environment I'm using, the only change needed was to initramfs-tools. I suspect the udevd change you're thinking of was an alternate implementation that we did not proceed with due to the regression it introduced (that network interface names would change). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1820929 Title: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces Status in netplan: Triaged Status in initramfs-tools package in Ubuntu: New Status in netplan.io package in Ubuntu: Triaged Status in systemd package in Ubuntu: Incomplete Status in initramfs-tools source package in Bionic: Fix Released Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New Bug description: [Impact] * At present, virtual machines utilizing net_failover network interface configurations are incorrectly configured due to the reliance on the MAC address to identify specific network interfaces. When net_failover is utilized, multiple interfaces will bear the same MAC address (the net_failover master itself, as well as the interfaces subordinate to it), rendering the MAC address ineffective for unique identification of the interface. This results in incorrect naming of network interfaces from the "set-name" directive in the netplan configuration. * The solution here is to use the interface name instead of the MAC address when the interface is a net_failover master device. Logic is added on initramfs-tools to check the device type and virtio flags to apply this change only to net_failover master devices. [Test Case] * The change can be tested by configuring a virtual machine with a virtio_net network device with the "failover=on" option to the "-device" option to qemu, e.g., -device virtio-net- pci,netdev=hostnet0,id=net0,bus=pci.0,addr=0x3,mac=00:00:17:00:18:04,failover=on * This will set the virtio device "standby" feature bit (bit 62, counting from 0). This requires a version of qemu with support for this feature. * When so configured, the netplan configuration generated by initramfs will not contain a "macaddress:" match directive for the network interface in question. [Regression Potential] * Erroneous identification of a network interface as a net_failover master device could lead to omission of a macaddress directive, causing interfaces to be incorrectly named. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1820929/+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
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Regarding #2 from comment #19: As the defined range for the ipv6.mtu is from IPV6_MIN_MTU to the device's MTU, and the existing API returns an error if the ipv6.mtu is out of range, I think it's reasonable for a configuration with the ipv6.mtu > device MTU to fail. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Bug description: = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+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
[Touch-packages] [Bug 1652348] Re: initrd dhcp fails / ignores valid response
Patch proposal to modify ipconfig to use one packet socket per interface ** Patch added: "klibc-fix-1.patch" https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+attachment/4806861/+files/klibc-fix-1.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1652348 Title: initrd dhcp fails / ignores valid response Status in klibc package in Ubuntu: In Progress Status in klibc source package in Xenial: Triaged Bug description: Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect. Over serial console it outputs: IP-Config: no response after 2 secs - giving up IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP IP-Config: no response after 3 secs - giving up with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea: (initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe :13:00.0 ens2f0: changing MTU from 1500 to 9000 d "ens2f0" IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP IP-Config: ens2f0 guessed broadcast address 10.0.1.255 IP-Config: ens2f0 complete (dhcp from 169.254.169.254): addres[ 728.980448] ixgbe :13:00.0 ens2f0: detected SFP+: 3 s: 10.0.1.56broadcast: 10.0.1.255 netmask: 255.255.255.0 gateway: 10.0.1.1 [ 729.148410] ixgbe :13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX dns0 : 169.254.169.254 dns1 : 0.0.0.0 rootserver: 169.254.169.254 rootpath: filename : /ipxe.efi tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig. I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue. Putting "ip=dhcp" back on with this kernel no longer fixes the problem. I've compared the two initrds and effectively the only thing that has changed between the two is the kernel components. Ubuntu kernel bisect offending commit: # first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts Ubuntu kernel bisect offending commit submission: https://lkml.org/lkml/2016/10/5/308 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+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
[Touch-packages] [Bug 1652348] Re: initrd dhcp fails / ignores valid response
** Changed in: klibc (Ubuntu) Status: Confirmed => In Progress ** Tags removed: kernel-bug-exists-upstream kernel-bug-exists- upstream-4.10-rc1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1652348 Title: initrd dhcp fails / ignores valid response Status in klibc package in Ubuntu: In Progress Status in klibc source package in Xenial: Triaged Bug description: Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect. Over serial console it outputs: IP-Config: no response after 2 secs - giving up IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP IP-Config: no response after 3 secs - giving up with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea: (initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe :13:00.0 ens2f0: changing MTU from 1500 to 9000 d "ens2f0" IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP IP-Config: ens2f0 guessed broadcast address 10.0.1.255 IP-Config: ens2f0 complete (dhcp from 169.254.169.254): addres[ 728.980448] ixgbe :13:00.0 ens2f0: detected SFP+: 3 s: 10.0.1.56broadcast: 10.0.1.255 netmask: 255.255.255.0 gateway: 10.0.1.1 [ 729.148410] ixgbe :13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX dns0 : 169.254.169.254 dns1 : 0.0.0.0 rootserver: 169.254.169.254 rootpath: filename : /ipxe.efi tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig. I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue. Putting "ip=dhcp" back on with this kernel no longer fixes the problem. I've compared the two initrds and effectively the only thing that has changed between the two is the kernel components. Ubuntu kernel bisect offending commit: # first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts Ubuntu kernel bisect offending commit submission: https://lkml.org/lkml/2016/10/5/308 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+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
[Touch-packages] [Bug 1652348] Re: initrd dhcp fails / ignores valid response
I have instrumented ipconfig, and determined that the ultimate source of the problem is that, for the case of multiple interfaces, ipconfig has a dependency on the kernel's probe order of the network interfaces. For whatever reason, the -31 kernel probes the network devices in one order (e.g., ens3 then ens4), and the -57 kernel in the other order (ens4 first then ens3). The probe order of network devices (and PCI devices in general) is explicitly not defined, and so this is not a bug in the kernel itself; ipconfig is failing due to its dependency on a specific enumeration order. The issue in ipconfig is that it is using a single packet socket to attempt to multiplex packet traffic on multiple interfaces. Presuming that ens3 will answer DHCP and ens4 will not, for the case that works, the order ends up being something like: send DHCP request on ens3 send DHCP request on ens4 [ system gets DHCP response via ens3 ] try to receive DHCP reply sent by peer for ens3; this matches, and all is happy For the case that it fails, the sequence is roughly: send DHCP request on ens4 send DHCP request on ens3 [ system gets DHCP response via ens3 ] try to receive DHCP reply sent by peer for ens4; the reply is actually for ens3, so ipconfig throws it away (as the XID, et al, don't match what is expected for the ens4 DHCP request). This repeats until ipconfig gives up. As I said above, the issue is that ipconfig is trying to multiplex traffic for two interfaces on one packet socket. This is fine for sending, but for receiving on an unbound packet socket, there is no way to receive a packet sent to a specific interface. Packets are delivered to recvfrom/recvmsg in the order received. I note that ipconfig sets sll.sll_ifindex on the msghdr provided to recvfrom and recvmsg system calls; perhaps the author believed that this limits received packets to only packets received on that ifindex. This is not the case, and the sll_ifindex passed to recvfrom/recvmsg is ignored. I'm looking into whether or not there is an simple fix for this that will let ipconfig function without major rework to utilize one packet socket per interface. ** Tags removed: kernel-key ** Package changed: linux (Ubuntu) => klibc (Ubuntu) ** Changed in: klibc (Ubuntu) Status: Triaged => Confirmed ** Changed in: klibc (Ubuntu) Assignee: (unassigned) => Jay Vosburgh (jvosburgh) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1652348 Title: initrd dhcp fails / ignores valid response Status in klibc package in Ubuntu: Confirmed Status in klibc source package in Xenial: Triaged Bug description: Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect. Over serial console it outputs: IP-Config: no response after 2 secs - giving up IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP IP-Config: no response after 3 secs - giving up with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea: (initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe :13:00.0 ens2f0: changing MTU from 1500 to 9000 d "ens2f0" IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP IP-Config: ens2f0 guessed broadcast address 10.0.1.255 IP-Config: ens2f0 complete (dhcp from 169.254.169.254): addres[ 728.980448] ixgbe :13:00.0 ens2f0: detected SFP+: 3 s: 10.0.1.56broadcast: 10.0.1.255 netmask: 255.255.255.0 gateway: 10.0.1.1 [ 729.148410] ixgbe :13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX dns0 : 169.254.169.254 dns1 : 0.0.0.0 rootserver: 169.254.169.254 rootpath: filename : /ipxe.efi tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig. I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue. Putting "ip=dhcp" back on with this kernel no longer fixes the problem. I've compared the two initrds and effectively the only th
[Touch-packages] [Bug 1327412] Re: Delay during PXE Boot, IP-Config gives up
The patch added to nominally fix this issue is incorrect; it is setting the wrong bit in the BOOTP flags field for broadcast: + bootp.flags = htons(0x800); The correct value should be 0x8000. This is causing issues with switches that reject the packet as having bits set in a "must be zero" flag area. RFC 1542 defines the flags field as 16 bits, and the broadcast bit is the most significant bit: 2.2 Definition of the 'flags' Field The standard BOOTP message format defined in [1] includes a two-octet field located between the 'secs' field and the 'ciaddr' field. This field is merely designated as "unused" and its contents left unspecified, although Section 7.1 of [1] does offer the following suggestion: "Before setting up the packet for the first time, it is a good idea to clear the entire packet buffer to all zeros; this will place all fields in their default state." This memo hereby designates this two-octet field as the 'flags' field. This memo hereby defines the most significant bit of the 'flags' field as the BROADCAST (B) flag. The semantics of this flag are discussed in Sections 3.1.1 and 4.1.2 of this memo. The remaining bits of the 'flags' field are reserved for future use. They MUST be set to zero by clients and ignored by servers [...] and relay agents. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1327412 Title: Delay during PXE Boot, IP-Config gives up Status in klibc package in Ubuntu: Fix Released Status in klibc source package in Trusty: Fix Released Status in klibc source package in Wily: Won't Fix Status in klibc source package in Xenial: Fix Released Status in klibc package in Debian: New Bug description: [Impact] PXE booting users with live images or other minimal setups using klibc-utils. [Test case] Attempt to PXE boot using Ubuntu live images; see below for details. [Regression potential] This forces the yiaddr (client requested/current IP) to be set to 0 when sending DHCP messages; currently the messages are DHCPREQUEST and DHCPDISCOVER, which should typically only happen when there is no IP set on the device and it is otherwise unable to receive unicast (on account of not being configured). Should there be a need to send other messages which would require setting the yiaddr value to the current configured IP address, a naive change would break. The yiaddr variable would need to be adjusted to pull value from a new location, or initialized directly by the callers to dhcp_send() where the business logic would reside. --- Attempting to PXE boot both the 12.04.3 and 14.04 Live images. PXE boot works normally (PXE Menu, select desired image, image begins loading), then the boot process hangs while IP-Config attempts to get an IP address: IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP IP-Config: no response after 2 secs - giving up IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP IP-Config: no response after 3 secs - giving up These lines appear very quickly (5 seconds has NOT elapsed), after about a minute, we get this: IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP IP-Config: no response after 4 secs - giving up Some time later, this: IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP IP-Config: no response after 6 secs - giving up Until finally, this: IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP IP-Config: no response after 9 secs - giving up IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP IP-Config: eth0 guessed broadcast address 172.25.11.31 IP-Config: eth0 complete (dhcp from 172.25.10.20): (snip) While watching the DHCP server logs, Ubuntu is either not sending a DHCP Discover at times, or is not replying back with a DHCPRequest during these sessions, presumably ignoring an response from the DHCP server. From the initial booting of the system via PXE, to when Ubuntu finally shows the desktop, almost 12 minutes will have elapsed. I am seeing this same behavior on both 12.04.3 and 14.04. After finding a number of similar erros via Google and no real resolution, I have opened this bug. The system experiencing this issue has multiple ethernet interfaces (actual HW, not a VM), some Google found solutions suggest hard coding DEVICE=eth0 in /etc/initra
[Touch-packages] [Bug 1539826] [NEW] initramfs-tools hook-functions error causes failure
Public bug reported: The /usr/share/initramfs-tools/hook-functions contains what appears to be a variable name update (from root to dev_node) error. It appears that one instance of root was not updated correctly; this causes mkinitramfs to fail with the error: mkinitramfs: for device /dev/vda1 missing vda1 /sys/block/ entry mkinitramfs: workaround is MODULES=most mkinitramfs: Error please report the bug A trivial patch that appears to resolve this is attached. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: initramfs-tools 0.120ubuntu7 [modified: usr/share/initramfs-tools/hook-functions] ProcVersionSignature: Ubuntu 4.3.0-7.18-generic 4.3.3 Uname: Linux 4.3.0-7-generic x86_64 ApportVersion: 2.19.4-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Fri Jan 29 17:44:20 2016 InstallationDate: Installed on 2016-01-29 (0 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160129) PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial ** Patch added: "hook-functions variable name fix" https://bugs.launchpad.net/bugs/1539826/+attachment/4559496/+files/hook-functions.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1539826 Title: initramfs-tools hook-functions error causes failure Status in initramfs-tools package in Ubuntu: New Bug description: The /usr/share/initramfs-tools/hook-functions contains what appears to be a variable name update (from root to dev_node) error. It appears that one instance of root was not updated correctly; this causes mkinitramfs to fail with the error: mkinitramfs: for device /dev/vda1 missing vda1 /sys/block/ entry mkinitramfs: workaround is MODULES=most mkinitramfs: Error please report the bug A trivial patch that appears to resolve this is attached. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: initramfs-tools 0.120ubuntu7 [modified: usr/share/initramfs-tools/hook-functions] ProcVersionSignature: Ubuntu 4.3.0-7.18-generic 4.3.3 Uname: Linux 4.3.0-7-generic x86_64 ApportVersion: 2.19.4-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Fri Jan 29 17:44:20 2016 InstallationDate: Installed on 2016-01-29 (0 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160129) PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1539826/+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
[Touch-packages] [Bug 1442828] Re: ifup-wait-all-auto does not wait for interfaces to be fully up
ifupdown 0.7.48.1ubuntu9 resolves the original problem for me on a fresh vivid install with the daily build for today. Thanks. -- 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/1442828 Title: ifup-wait-all-auto does not wait for interfaces to be fully up Status in ifupdown package in Ubuntu: Fix Released Status in ifupdown source package in Vivid: Fix Released Bug description: The change to ifup@.service done as part of LP 1425376 appears to break the ordering of units marked as "After=network-online.target". In my specific case, a new service script with "After=network-online.target" is erroneously run concurrently with dhclient. As the new script depends on networking configuration being complete, it fails as the IP addresses and routes from DHCP are not configured. This functioned correctly on vivid daily images from a few days ago, and appears to break starting with the vivid daily from approximately 0409. Infinity suggested this change as a likely suspect: diff -Nru systemd-219/debian/extra/units/ifup@.service systemd-219/debian/extra/units/ifup@.service --- systemd-219/debian/extra/units/ifup@.service 2015-04-02 08:08:56.0 + +++ systemd-219/debian/extra/units/ifup@.service 2015-04-07 14:38:38.0 + @@ -6,10 +6,8 @@ DefaultDependencies=no [Service] -Type=oneshot -ExecStart=/sbin/ifup --allow=hotplug %I -ExecStartPost=/sbin/ifup --allow=auto %I # only fail if ifupdown knows about the iface AND it's not up -ExecStartPost=/bin/sh -c 'if ifquery %I >/dev/null; then ifquery --state %I >/dev/null; fi' +ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifup --allow=auto %I; \ +if ifquery %I >/dev/null; then ifquery --state %I >/dev/null; fi' ExecStop=/sbin/ifdown %I RemainAfterExit=true and, indeed, reverting this (copying ifup@.service from a few-days old vivid image to a current image) resolves the problem. The affected version is ubuntu-vivid-daily-amd64-server-20150409.2 (installed via AWS). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1442828/+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
[Touch-packages] [Bug 1442828] [NEW] change for LP 1425376 breaks systemd After=network-online.target
Public bug reported: The change to ifup@.service done as part of LP 1425376 appears to break the ordering of units marked as "After=network-online.target". In my specific case, a new service script with "After=network-online.target" is erroneously run concurrently with dhclient. As the new script depends on networking configuration being complete, it fails as the IP addresses and routes from DHCP are not configured. This functioned correctly on vivid daily images from a few days ago, and appears to break starting with the vivid daily from approximately 0409. Infinity suggested this change as a likely suspect: diff -Nru systemd-219/debian/extra/units/ifup@.service systemd-219/debian/extra/units/ifup@.service --- systemd-219/debian/extra/units/ifup@.service2015-04-02 08:08:56.0 + +++ systemd-219/debian/extra/units/ifup@.service2015-04-07 14:38:38.0 + @@ -6,10 +6,8 @@ DefaultDependencies=no [Service] -Type=oneshot -ExecStart=/sbin/ifup --allow=hotplug %I -ExecStartPost=/sbin/ifup --allow=auto %I # only fail if ifupdown knows about the iface AND it's not up -ExecStartPost=/bin/sh -c 'if ifquery %I >/dev/null; then ifquery --state %I >/dev/null; fi' +ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifup --allow=auto %I; \ +if ifquery %I >/dev/null; then ifquery --state %I >/dev/null; fi' ExecStop=/sbin/ifdown %I RemainAfterExit=true and, indeed, reverting this (copying ifup@.service from a few-days old vivid image to a current image) resolves the problem. The affected version is ubuntu-vivid-daily-amd64-server-20150409.2 (installed via AWS). ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Package changed: linux (Ubuntu) => systemd (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1442828 Title: change for LP 1425376 breaks systemd After=network-online.target Status in systemd package in Ubuntu: New Bug description: The change to ifup@.service done as part of LP 1425376 appears to break the ordering of units marked as "After=network-online.target". In my specific case, a new service script with "After=network-online.target" is erroneously run concurrently with dhclient. As the new script depends on networking configuration being complete, it fails as the IP addresses and routes from DHCP are not configured. This functioned correctly on vivid daily images from a few days ago, and appears to break starting with the vivid daily from approximately 0409. Infinity suggested this change as a likely suspect: diff -Nru systemd-219/debian/extra/units/ifup@.service systemd-219/debian/extra/units/ifup@.service --- systemd-219/debian/extra/units/ifup@.service 2015-04-02 08:08:56.0 + +++ systemd-219/debian/extra/units/ifup@.service 2015-04-07 14:38:38.0 + @@ -6,10 +6,8 @@ DefaultDependencies=no [Service] -Type=oneshot -ExecStart=/sbin/ifup --allow=hotplug %I -ExecStartPost=/sbin/ifup --allow=auto %I # only fail if ifupdown knows about the iface AND it's not up -ExecStartPost=/bin/sh -c 'if ifquery %I >/dev/null; then ifquery --state %I >/dev/null; fi' +ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifup --allow=auto %I; \ +if ifquery %I >/dev/null; then ifquery --state %I >/dev/null; fi' ExecStop=/sbin/ifdown %I RemainAfterExit=true and, indeed, reverting this (copying ifup@.service from a few-days old vivid image to a current image) resolves the problem. The affected version is ubuntu-vivid-daily-amd64-server-20150409.2 (installed via AWS). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1442828/+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
