[Touch-packages] [Bug 2080069] [NEW] lxc-dev does not provide liblxc.a any more
Public bug reported: 1) # lsb_release -rd No LSB modules are available. Description:Ubuntu 24.04 LTS Release:24.04 2) # apt-cache policy lxc-dev lxc-dev: Installed: 1:5.0.3-2ubuntu7 Candidate: 1:5.0.3-2ubuntu7 Version table: *** 1:5.0.3-2ubuntu7 500 500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages 100 /var/lib/dpkg/status 3) # # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.a /usr/lib/x86_64-linux-gnu/liblxc.so 4) # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.so ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: lxc-dev 1:5.0.3-2ubuntu7 ProcVersionSignature: Ubuntu 6.5.0-41.41~22.04.2-generic 6.5.13 Uname: Linux 6.5.0-41-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.1 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: lxd CloudName: lxd CloudPlatform: lxd CloudSerial: 20240822 CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock) Date: Mon Sep 9 20:12:44 2024 ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) TERM=xterm-256color RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: lxc (Ubuntu) Importance: High Status: Confirmed ** Affects: lxc (Ubuntu Noble) Importance: High Status: Confirmed ** Tags: amd64 apport-bug cloud-image noble patch ** Also affects: lxc (Ubuntu Noble) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/2080069 Title: lxc-dev does not provide liblxc.a any more Status in lxc package in Ubuntu: Confirmed Status in lxc source package in Noble: Confirmed Bug description: 1) # lsb_release -rd No LSB modules are available. Description: Ubuntu 24.04 LTS Release: 24.04 2) # apt-cache policy lxc-dev lxc-dev: Installed: 1:5.0.3-2ubuntu7 Candidate: 1:5.0.3-2ubuntu7 Version table: *** 1:5.0.3-2ubuntu7 500 500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages 100 /var/lib/dpkg/status 3) # # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.a /usr/lib/x86_64-linux-gnu/liblxc.so 4) # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.so ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: lxc-dev 1:5.0.3-2ubuntu7 ProcVersionSignature: Ubuntu 6.5.0-41.41~22.04.2-generic 6.5.13 Uname: Linux 6.5.0-41-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.1 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: lxd CloudName: lxd CloudPlatform: lxd CloudSerial: 20240822 CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock) Date: Mon Sep 9 20:12:44 2024 ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) TERM=xterm-256color RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+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 2080069] Re: lxc-dev does not provide liblxc.a any more
I'm not sure exactly how the liblxc.a static lib was dropped, but the attached debdiff resolves this by not removing all .a files (an extra find|rm is around a comment about removing all .la files) and then adding the file to lxc-dev.install This produces a lxc-dev deb which includes the static lib. ** Patch added: "debdiff with fix applied" https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+attachment/5814914/+files/lxc-fix-lxc-dev-missing-liblxc-dot-a.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/2080069 Title: lxc-dev does not provide liblxc.a any more Status in lxc package in Ubuntu: Confirmed Status in lxc source package in Noble: Confirmed Bug description: 1) # lsb_release -rd No LSB modules are available. Description: Ubuntu 24.04 LTS Release: 24.04 2) # apt-cache policy lxc-dev lxc-dev: Installed: 1:5.0.3-2ubuntu7 Candidate: 1:5.0.3-2ubuntu7 Version table: *** 1:5.0.3-2ubuntu7 500 500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages 100 /var/lib/dpkg/status 3) # # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.a /usr/lib/x86_64-linux-gnu/liblxc.so 4) # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.so ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: lxc-dev 1:5.0.3-2ubuntu7 ProcVersionSignature: Ubuntu 6.5.0-41.41~22.04.2-generic 6.5.13 Uname: Linux 6.5.0-41-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.1 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: lxd CloudName: lxd CloudPlatform: lxd CloudSerial: 20240822 CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock) Date: Mon Sep 9 20:12:44 2024 ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) TERM=xterm-256color RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+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 2080069] Re: lxc-dev does not provide liblxc.a any more
dpkg --contents on lxc-dev_5.0.3-2ubuntu7_amd64.deb ** Attachment added: "output from dpkg --contents on lxc-dev_5.0.3-2ubuntu7_amd64.deb" https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+attachment/5814926/+files/lxc-dev_5.0.3-2ubuntu7_amd64.deb.contents -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/2080069 Title: lxc-dev does not provide liblxc.a any more Status in lxc package in Ubuntu: Confirmed Status in lxc source package in Noble: Confirmed Bug description: 1) # lsb_release -rd No LSB modules are available. Description: Ubuntu 24.04 LTS Release: 24.04 2) # apt-cache policy lxc-dev lxc-dev: Installed: 1:5.0.3-2ubuntu7 Candidate: 1:5.0.3-2ubuntu7 Version table: *** 1:5.0.3-2ubuntu7 500 500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages 100 /var/lib/dpkg/status 3) # # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.a /usr/lib/x86_64-linux-gnu/liblxc.so 4) # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.so ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: lxc-dev 1:5.0.3-2ubuntu7 ProcVersionSignature: Ubuntu 6.5.0-41.41~22.04.2-generic 6.5.13 Uname: Linux 6.5.0-41-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.1 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: lxd CloudName: lxd CloudPlatform: lxd CloudSerial: 20240822 CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock) Date: Mon Sep 9 20:12:44 2024 ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) TERM=xterm-256color RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+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 2080069] Re: lxc-dev does not provide liblxc.a any more
** Patch added: "Diff of dpkg --contents file column only between 7 and 8" https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+attachment/5814925/+files/file-list.diff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/2080069 Title: lxc-dev does not provide liblxc.a any more Status in lxc package in Ubuntu: Confirmed Status in lxc source package in Noble: Confirmed Bug description: 1) # lsb_release -rd No LSB modules are available. Description: Ubuntu 24.04 LTS Release: 24.04 2) # apt-cache policy lxc-dev lxc-dev: Installed: 1:5.0.3-2ubuntu7 Candidate: 1:5.0.3-2ubuntu7 Version table: *** 1:5.0.3-2ubuntu7 500 500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages 100 /var/lib/dpkg/status 3) # # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.a /usr/lib/x86_64-linux-gnu/liblxc.so 4) # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.so ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: lxc-dev 1:5.0.3-2ubuntu7 ProcVersionSignature: Ubuntu 6.5.0-41.41~22.04.2-generic 6.5.13 Uname: Linux 6.5.0-41-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.1 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: lxd CloudName: lxd CloudPlatform: lxd CloudSerial: 20240822 CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock) Date: Mon Sep 9 20:12:44 2024 ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) TERM=xterm-256color RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+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 2080069] Re: lxc-dev does not provide liblxc.a any more
dpkg --contents lxc-dev_5.0.3-2ubuntu8_amd64.deb output ** Attachment added: "dpkg --contents lxc-dev_5.0.3-2ubuntu8_amd64.deb output" https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+attachment/5814927/+files/lxc-dev_5.0.3-2ubuntu8_amd64.deb.contents -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/2080069 Title: lxc-dev does not provide liblxc.a any more Status in lxc package in Ubuntu: Confirmed Status in lxc source package in Noble: Confirmed Bug description: 1) # lsb_release -rd No LSB modules are available. Description: Ubuntu 24.04 LTS Release: 24.04 2) # apt-cache policy lxc-dev lxc-dev: Installed: 1:5.0.3-2ubuntu7 Candidate: 1:5.0.3-2ubuntu7 Version table: *** 1:5.0.3-2ubuntu7 500 500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages 100 /var/lib/dpkg/status 3) # # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.a /usr/lib/x86_64-linux-gnu/liblxc.so 4) # dpkg -L lxc-dev | grep liblxc /usr/lib/x86_64-linux-gnu/liblxc.so ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: lxc-dev 1:5.0.3-2ubuntu7 ProcVersionSignature: Ubuntu 6.5.0-41.41~22.04.2-generic 6.5.13 Uname: Linux 6.5.0-41-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.1 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: lxd CloudName: lxd CloudPlatform: lxd CloudSerial: 20240822 CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock) Date: Mon Sep 9 20:12:44 2024 ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) TERM=xterm-256color RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+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 2080069] Re: lxc-dev does not provide liblxc.a any more
I generated the smaller diff with:
$ diff -u <(awk '{print $6}' lxc-dev_5.0.3-2ubuntu7_amd64.deb.contents )
<(awk '{print $6}' lxc-dev_5.0.3-2ubuntu8_amd64.deb.contents) > file-
list.diff
so one can just see which files were added/removed vs the date/timestamp
change on files that are in both archives.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/2080069
Title:
lxc-dev does not provide liblxc.a any more
Status in lxc package in Ubuntu:
Confirmed
Status in lxc source package in Noble:
Confirmed
Bug description:
1) # lsb_release -rd
No LSB modules are available.
Description: Ubuntu 24.04 LTS
Release: 24.04
2) # apt-cache policy lxc-dev
lxc-dev:
Installed: 1:5.0.3-2ubuntu7
Candidate: 1:5.0.3-2ubuntu7
Version table:
*** 1:5.0.3-2ubuntu7 500
500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages
100 /var/lib/dpkg/status
3) # # dpkg -L lxc-dev | grep liblxc
/usr/lib/x86_64-linux-gnu/liblxc.a
/usr/lib/x86_64-linux-gnu/liblxc.so
4) # dpkg -L lxc-dev | grep liblxc
/usr/lib/x86_64-linux-gnu/liblxc.so
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: lxc-dev 1:5.0.3-2ubuntu7
ProcVersionSignature: Ubuntu 6.5.0-41.41~22.04.2-generic 6.5.13
Uname: Linux 6.5.0-41-generic x86_64
ApportVersion: 2.28.1-0ubuntu3.1
Architecture: amd64
CasperMD5CheckResult: unknown
CloudArchitecture: x86_64
CloudBuildName: server
CloudID: lxd
CloudName: lxd
CloudPlatform: lxd
CloudSerial: 20240822
CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock)
Date: Mon Sep 9 20:12:44 2024
ProcEnviron:
LANG=C.UTF-8
PATH=(custom, no user)
TERM=xterm-256color
RebootRequiredPkgs: Error: path contained symlinks.
SourcePackage: lxc
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+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 2000170] [NEW] bond interface down: device or resource busy
Public bug reported: 1) # lsb_release -rd Description:Ubuntu 20.04.5 LTS Release:20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://azure.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://azure.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://azure.archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) create a bond with one interface, active backup mode, apply config, bond should be UP and configured with ip network: ethernets: eth1: dhcp4: false dhcp6: false match: driver: hv_netvsc macaddress: 00:0d:3a:32:68:27 set-name: eth1 bonds: bond1: interfaces: [eth1] macaddress: 00:0d:3a:32:68:27 parameters: mode: active-backup addresses: [10.1.2.132/25] version: 2 netplan generate networkctl reload networkctl reconfigure bond1 ip link show bond1 4) bond1 interface has IP configured but admin state is down. ip link show bond1 6: bond1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:0d:3a:32:68:27 brd ff:ff:ff:ff:ff:ff -- journal entries -- Dec 20 16:59:53 0-11686-3 systemd-networkd[723]: eth1: Link UP Dec 20 16:59:53 0-11686-3 systemd-networkd[723]: eth1: Gained carrier Dec 20 16:59:53 0-11686-3 systemd-networkd[723]: bond1: Could not bring up interface: Device or resource busy Dec 20 16:59:58 0-11686-3 systemd-networkd[723]: bond1: Re-configuring with /run/systemd/network/10-netplan-bond1.network Dec 20 16:59:58 0-11686-3 systemd-networkd[723]: bond1: IPv6 successfully enabled Dec 20 16:59:58 0-11686-3 systemd-networkd[723]: bond1: Could not bring up interface: Device or resource busy -- systemd-networkd in debug mode --- Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Re-configuring with /run/systemd/network/10-netplan-bond1.network Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Removing address 10.1.2.132 Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Setting '/proc/sys/net/ipv6/conf/bond1/disable_ipv6' to '0' Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: IPv6 successfully enabled Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Setting '/proc/sys/net/ipv6/conf/bond1/proxy_ndp' to '0' Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Setting '/proc/sys/net/ipv6/conf/bond1/use_tempaddr' to '0' Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Setting '/proc/sys/net/ipv6/conf/bond1/accept_ra' to '0' Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Setting address genmode for link Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Forgetting address: 10.1.2.132/25 (valid forever) Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_36 interface=org.freedesktop.D> Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Forgetting route: dst: 10.1.2.132/32, src: n/a, gw: n/a, prefsrc: 10.1.2.132, scope: host, table: local, proto: > Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Setting address genmode done. Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: State changed: pending -> configuring Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_36 interface=org.freedesktop.D> Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Bringing link up Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Setting addresses Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Could not bring up interface: Device or resource busy Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Remembering updated address: 10.1.2.132/25 (valid forever) Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_36 interface=org.freedesktop.D> Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Remembering route: dst: 10.1.2.132/32, src: n/a, gw: n/a, prefsrc: 10.1.2.132, scope: host, table: local, proto:> Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Addresses set Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: State changed: configuring -> configured Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_36 interface=org.freedesktop. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.19 ProcVersionSignature: Ubuntu 5.15.0-1029.36~20.04.1-azure 5.15.64 Uname: Linux 5.15.0-1029-azure x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5Ch
[Touch-packages] [Bug 2000325] [NEW] ipv6 duplicate address prevents interface configuration
Public bug reported: 1) # lsb_release -rd Description:Ubuntu 20.04.5 LTS Release:20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) Interface should be configured with all addresses and routes 4) Interface is missing ipv4 and ipv6 static addresses and associated routes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.19 ProcVersionSignature: Ubuntu 5.4.0-135.152-generic 5.4.212 Uname: Linux 5.4.0-135-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Dec 22 16:13:11 2022 Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=vt220 PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-135-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: http://192.168.14.1:/register.html dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-focal:cvnQEMU:ct1:cvrhttp//192.168.14.1/register.html: dmi.product.family: cisco dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-focal dmi.sys.vendor: QEMU ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal uec-images -- 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/2000325 Title: ipv6 duplicate address prevents interface configuration Status in systemd package in Ubuntu: New Bug description: 1) # lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) Interface should be configured with all addresses and routes 4) Interface is missing ipv4 and ipv6 static addresses and associated routes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.19 ProcVersionSignature: Ubuntu 5.4.0-135.152-generic 5.4.212 Uname: Linux 5.4.0-135-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Dec 22 16:13:11 2022 Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=vt220 PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-135-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: http://192.168.14.1:/register.html dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-focal:cvnQEMU:ct1:cvrhttp//192.168.14.1/register.html: dmi.product.family: cisco dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-focal dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+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 2000325] Re: ipv6 duplicate address prevents interface configuration
To reproduce what happens on physical systems I create two VMs with nics in the same bridge on the host. Booting the first VM up and allowing the network config to apply, and then when booting the second VM up layer, as it applies the IPv6 address to the interface in the bridge, the kernel detects a duplicate IPv6 address and networkd fails to configure the interface. This happens on Focal systemd-networkd, but works fine on Jammy; that is the network configuration is applied (including the duplicate V6) but critically the v4 address and routes are as well. -- 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/2000325 Title: ipv6 duplicate address prevents interface configuration Status in systemd package in Ubuntu: New Bug description: 1) # lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) Interface should be configured with all addresses and routes 4) Interface is missing ipv4 and ipv6 static addresses and associated routes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.19 ProcVersionSignature: Ubuntu 5.4.0-135.152-generic 5.4.212 Uname: Linux 5.4.0-135-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Dec 22 16:13:11 2022 Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=vt220 PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-135-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: http://192.168.14.1:/register.html dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-focal:cvnQEMU:ct1:cvrhttp//192.168.14.1/register.html: dmi.product.family: cisco dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-focal dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+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 2000325] Re: ipv6 duplicate address prevents interface configuration
# Create a bridge and add two ports
$ sudo ip link add name atx-fabric0 type bridge
$ sudo ip link set up dev atx-fabric0
$ sudo ip tuntap add atx-fabric0i1p1 user $USER group $USER
$ sudo ip tuntap add atx-fabric0i2p1 user $USER group $USER
# create two focal VM images from focal daily server
$ qemu-img create -f qcow2 -b focal-server-cloudimg-amd64.img focal-net1.img
100G
$ qemu-img create -f qcow2 -b focal-server-cloudimg-amd64.img focal-net2.img
100G
# create cloud-init seed
$ cat >user-data < meta-data
$ cloud-localds seed.img user-data meta-data
# Launch VM1 (need sudo for bridge access)
BOOT=focal-net1.img
SEED=seed.img
sudo qemu-system-x86_64 -smp 2 -m 2048 --enable-kvm \
-global pc35.no_floppy=1 \
-name "${1}" \
-drive id=disk0,if=none,format=qcow2,file=${BOOT} \
-device virtio-blk-pci,drive=disk0,bootindex=0 \
-drive id=cdrom0,if=none,media=cdrom,file=$SEED \
-device virtio-blk-pci,drive=cdrom0,bootindex=1 \
-netdev user,id=net0,hostfwd=tcp::2-:22 \
-device e1000,bootindex=2,netdev=net0,mac=52:54:00:a2:34:c0 \
-netdev tap,id=net1,ifname=atx-fabric0i1p1 \
-device virtio-net,bootindex=4,netdev=net1,mac=b8:38:61:bc:60:f5 \
-nographic \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0 \
-serial mon:stdio
# Login and replace netplan config
cat > 50-cloud-init-vm1.yaml << EOF
network:
version: 2
ethernets:
ens5:
match:
macaddress: "52:54:00:a2:34:c0"
accept-ra: false
dhcp4: true
dhcp6: false
mtu: 1500
eth2-1:
optional: true
match:
macaddress: b8:38:61:bc:60:f5
set-name: eth2-1
accept-ra: false
dhcp4: false
dhcp6: false
mtu: 1500
addresses:
- 6.1.6.1/24
- 2006:1:6::1/116
routes:
- from: 6.1.6.1
scope: link
to: 6.1.6.254
- from: 2006:1:6::1
scope: link
to: 2006:1:6::254
- to: default
via: 2006:1:6::254
metric: 32
- to: default
via: 6.1.6.254
metric: 32
eth2-2:
match:
macaddress: b8:38:61:bc:60:f6
set-name: eth2-2
accept-ra: false
dhcp4: false
dhcp6: false
mtu: 1500
EOF
scp -P 2 50-cloud-init-vm1.yaml ubuntu@localhost:
ssh -P 2 'sudo cp /home/ubuntu/50-cloud-init-vm1.yaml
/etc/netplan/50-cloud-init.yaml'
ssh -P 2 'sudo netplan apply'
# Launch VM2 (need sudo for bridge access)
BOOT=focal-net2.img
SEED=seed.img
sudo qemu-system-x86_64 -smp 2 -m 1024 --enable-kvm \
-global pc35.no_floppy=1 \
-name "${1}" \
-drive id=disk0,if=none,format=qcow2,file=${BOOT} \
-device virtio-blk-pci,drive=disk0,bootindex=0 \
-drive id=cdrom0,if=none,media=cdrom,file=$SEED \
-device virtio-blk-pci,drive=cdrom0,bootindex=1 \
-netdev user,id=net0,hostfwd=tcp::3-:22 \
-device e1000,bootindex=2,netdev=net0,mac=52:54:00:ef:88:a2 \
-netdev tap,id=net1,ifname=atx-fabric0i2p1 \
-device virtio-net,bootindex=4,netdev=net1,mac=b8:38:61:bc:60:f6 \
-nographic \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0 \
-serial mon:stdio
# Login and replace netplan config
cat > 50-cloud-init-vm2.yaml << EOF
network:
version: 2
ethernets:
ens5:
match:
macaddress: "52:54:00:ef:88:a2"
accept-ra: false
dhcp4: true
dhcp6: false
mtu: 1500
eth2-1:
match:
macaddress: b8:38:61:bc:60:f5
set-name: eth2-1
accept-ra: false
dhcp4: false
dhcp6: false
mtu: 1500
eth2-2:
optional: true
match:
macaddress: b8:38:61:bc:60:f6
set-name: eth2-2
accept-ra: false
dhcp4: false
dhcp6: false
mtu: 1500
addresses:
- 6.1.6.1/24
- 2006:1:6::1/116
routes:
- from: 6.1.6.1
scope: link
to: 6.1.6.254
- from: 2006:1:6::1
scope: link
to: 2006:1:6::254
- to: default
via: 2006:1:6::254
metric: 32
- to: default
via: 6.1.6.254
metric: 32
EOF
scp -P 2 50-cloud-init-vm1.yaml ubuntu@localhost:
ssh -P 2 'sudo cp /home/ubuntu/50-cloud-init-vm1.yaml
/etc/netplan/50-cloud-init.yaml'
ssh -P 2 'sudo netplan apply'
--
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/2000325
Title:
ipv6 duplicate address prevents interface configuration
Status in systemd package in Ubuntu:
New
Bug description:
1) # lsb_release -rd
Description: Ubuntu 20.04.5 LTS
Release: 20.04
2) # apt-cache policy systemd
systemd:
Installed: 245.4-4ubuntu3.19
Candidate: 245.4-4ubuntu3.19
Version table:
*** 245.4-4ubuntu3.19 500
500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
100 /var/lib/dpkg/status
245.4-4ubuntu3.15 500
500 http://security.u
[Touch-packages] [Bug 2000325] Re: ipv6 duplicate address prevents interface configuration
** Attachment added: "netplan config for vm1" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+attachment/5637220/+files/50-v4-v6-fail-vm1.yaml -- 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/2000325 Title: ipv6 duplicate address prevents interface configuration Status in systemd package in Ubuntu: New Bug description: 1) # lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) Interface should be configured with all addresses and routes 4) Interface is missing ipv4 and ipv6 static addresses and associated routes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.19 ProcVersionSignature: Ubuntu 5.4.0-135.152-generic 5.4.212 Uname: Linux 5.4.0-135-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Dec 22 16:13:11 2022 Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=vt220 PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-135-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: http://192.168.14.1:/register.html dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-focal:cvnQEMU:ct1:cvrhttp//192.168.14.1/register.html: dmi.product.family: cisco dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-focal dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+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 2000325] Re: ipv6 duplicate address prevents interface configuration
** Attachment added: "netplan config for vm2" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+attachment/5637221/+files/50-v4-v6-fail-vm2.yaml -- 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/2000325 Title: ipv6 duplicate address prevents interface configuration Status in systemd package in Ubuntu: New Bug description: 1) # lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) Interface should be configured with all addresses and routes 4) Interface is missing ipv4 and ipv6 static addresses and associated routes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.19 ProcVersionSignature: Ubuntu 5.4.0-135.152-generic 5.4.212 Uname: Linux 5.4.0-135-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Dec 22 16:13:11 2022 Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=vt220 PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-135-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: http://192.168.14.1:/register.html dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-focal:cvnQEMU:ct1:cvrhttp//192.168.14.1/register.html: dmi.product.family: cisco dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-focal dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+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 2000325] Re: ipv6 duplicate address prevents interface configuration
There are two scenarios: Applying to VM the first time, on subsequent boots. On first boot without the updated netplan config, when you first add it root@ubuntu:/home/ubuntu# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth2-2: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:38:61:bc:60:f6 brd ff:ff:ff:ff:ff:ff 3: ens5: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:ef:88:a2 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic ens5 valid_lft 86177sec preferred_lft 86177sec inet6 fe80::5054:ff:feef:88a2/64 scope link valid_lft forever preferred_lft forever After a reboot initially the addresses are assigned. root@ubuntu:/home/ubuntu# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth2-2: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:38:61:bc:60:f6 brd ff:ff:ff:ff:ff:ff inet 6.1.6.1/24 brd 6.1.6.255 scope global eth2-2 valid_lft forever preferred_lft forever inet6 2006:1:6::1/116 scope global dadfailed tentative valid_lft forever preferred_lft forever inet6 fe80::ba38:61ff:febc:60f6/64 scope link valid_lft forever preferred_lft forever 3: ens5: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:ef:88:a2 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic ens5 valid_lft 85262sec preferred_lft 85262sec inet6 fe80::5054:ff:feef:88a2/64 scope link valid_lft forever preferred_lft forever However, if the addresses are cleared from the interface, networkd cannot reapply the config and leaves the interface unconfigured root@ubuntu:/home/ubuntu# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth2-2: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:38:61:bc:60:f6 brd ff:ff:ff:ff:ff:ff 3: ens5: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:ef:88:a2 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic ens5 valid_lft 86177sec preferred_lft 86177sec inet6 fe80::5054:ff:feef:88a2/64 scope link valid_lft forever preferred_lft forever -- 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/2000325 Title: ipv6 duplicate address prevents interface configuration Status in systemd package in Ubuntu: New Bug description: 1) # lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) Interface should be configured with all addresses and routes 4) Interface is missing ipv4 and ipv6 static addresses and associated routes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.19 ProcVersionSignature: Ubuntu 5.4.0-135.152-generic 5.4.212 Uname: Linux 5.4.0-135-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Dec 22 16:13:11 2022 Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=vt220 PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-135-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: http://192.168.14.1:/register.html dm
[Touch-packages] [Bug 2000325] Re: ipv6 duplicate address prevents interface configuration
root@ubuntu:/home/ubuntu# networkctl status eth2-2 --no-pager ● 2: eth2-2 Link File: /run/systemd/network/10-netplan-eth2-2.link Network File: /run/systemd/network/10-netplan-eth2-2.network Type: ether State: carrier (failed) Path: pci-:00:06.0 Driver: virtio_net Vendor: Red Hat, Inc. Model: Virtio network device HW Address: b8:38:61:bc:60:f6 (Cisco Systems, Inc) MTU: 1500 (min: 68, max: 65535) Queue Length (Tx/Rx): 1/1 Auto negotiation: no Speed: n/a Activation Policy: up Required For Online: yes Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: Configuring route: dst: 6.1.6.254/32, src: n/a, gw: n/a, prefsrc: 6.1.6.1, scope: link, table: main, proto: static, type: unicast Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: Configuring route: dst: n/a, src: n/a, gw: 6.1.6.254, prefsrc: n/a, scope: global, table: main, proto: static, type: unicast Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: Configuring route: dst: n/a, src: n/a, gw: 2006:1:6::254, prefsrc: n/a, scope: global, table: main, proto: static, type: unicast Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: Setting routes Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: State changed: pending -> configuring Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: Forgetting route: dst: 2006:1:6::/116, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: main, proto: kernel, type: unicast Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: Setting address genmode done. Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: Could not set route: Invalid source address. Invalid argument Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: Failed Dec 22 16:53:58 ubuntu systemd-networkd[552]: eth2-2: State changed: configuring -> failed ** Attachment added: "journal with systemd-networkd debug on calling netplan apply after ip addr flush eth2-2" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+attachment/5637222/+files/journal-since-flush-netplan-apply.log -- 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/2000325 Title: ipv6 duplicate address prevents interface configuration Status in systemd package in Ubuntu: New Bug description: 1) # lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) Interface should be configured with all addresses and routes 4) Interface is missing ipv4 and ipv6 static addresses and associated routes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.19 ProcVersionSignature: Ubuntu 5.4.0-135.152-generic 5.4.212 Uname: Linux 5.4.0-135-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Dec 22 16:13:11 2022 Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=vt220 PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-135-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: http://192.168.14.1:/register.html dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-focal:cvnQEMU:ct1:cvrhttp//192.168.14.1/register.html: dmi.product.family: cisco dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.versio
[Touch-packages] [Bug 2000325] Re: ipv6 duplicate address prevents interface configuration
** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New -- 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/2000325 Title: ipv6 duplicate address prevents interface configuration Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Bug description: 1) # lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) Interface should be configured with all addresses and routes 4) Interface is missing ipv4 and ipv6 static addresses and associated routes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.19 ProcVersionSignature: Ubuntu 5.4.0-135.152-generic 5.4.212 Uname: Linux 5.4.0-135-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Dec 22 16:13:11 2022 Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=vt220 PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-135-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: http://192.168.14.1:/register.html dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-focal:cvnQEMU:ct1:cvrhttp//192.168.14.1/register.html: dmi.product.family: cisco dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-focal dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+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 2000170] Re: bond interface down: device or resource busy
** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New -- 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/2000170 Title: bond interface down: device or resource busy Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Bug description: 1) # lsb_release -rd Description:Ubuntu 20.04.5 LTS Release:20.04 2) # apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.19 Candidate: 245.4-4ubuntu3.19 Version table: *** 245.4-4ubuntu3.19 500 500 http://azure.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.15 500 500 http://azure.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://azure.archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) create a bond with one interface, active backup mode, apply config, bond should be UP and configured with ip network: ethernets: eth1: dhcp4: false dhcp6: false match: driver: hv_netvsc macaddress: 00:0d:3a:32:68:27 set-name: eth1 bonds: bond1: interfaces: [eth1] macaddress: 00:0d:3a:32:68:27 parameters: mode: active-backup addresses: [10.1.2.132/25] version: 2 netplan generate networkctl reload networkctl reconfigure bond1 ip link show bond1 4) bond1 interface has IP configured but admin state is down. ip link show bond1 6: bond1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:0d:3a:32:68:27 brd ff:ff:ff:ff:ff:ff -- journal entries -- Dec 20 16:59:53 0-11686-3 systemd-networkd[723]: eth1: Link UP Dec 20 16:59:53 0-11686-3 systemd-networkd[723]: eth1: Gained carrier Dec 20 16:59:53 0-11686-3 systemd-networkd[723]: bond1: Could not bring up interface: Device or resource busy Dec 20 16:59:58 0-11686-3 systemd-networkd[723]: bond1: Re-configuring with /run/systemd/network/10-netplan-bond1.network Dec 20 16:59:58 0-11686-3 systemd-networkd[723]: bond1: IPv6 successfully enabled Dec 20 16:59:58 0-11686-3 systemd-networkd[723]: bond1: Could not bring up interface: Device or resource busy -- systemd-networkd in debug mode --- Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Re-configuring with /run/systemd/network/10-netplan-bond1.network Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Removing address 10.1.2.132 Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Setting '/proc/sys/net/ipv6/conf/bond1/disable_ipv6' to '0' Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: IPv6 successfully enabled Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Setting '/proc/sys/net/ipv6/conf/bond1/proxy_ndp' to '0' Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Setting '/proc/sys/net/ipv6/conf/bond1/use_tempaddr' to '0' Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Setting '/proc/sys/net/ipv6/conf/bond1/accept_ra' to '0' Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Setting address genmode for link Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Forgetting address: 10.1.2.132/25 (valid forever) Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_36 interface=org.freedesktop.D> Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Forgetting route: dst: 10.1.2.132/32, src: n/a, gw: n/a, prefsrc: 10.1.2.132, scope: host, table: local, proto: > Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Setting address genmode done. Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: State changed: pending -> configuring Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_36 interface=org.freedesktop.D> Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Bringing link up Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Setting addresses Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Could not bring up interface: Device or resource busy Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Remembering updated address: 10.1.2.132/25 (valid forever) Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_36 interface=org.freedesktop.D> Dec 20 17:05:52 0-11686-3 systemd-networkd[2685]: bond1: Remembering route: dst: 10.1.2.132/32, src: n/a, gw: n/a, prefsrc: 10.1.2.132, scope: host, table: local, proto:> Dec 20 17:05:52 0-11686-3 systemd-networkd[
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
It seems there are some limitations to what systemd will do with IPv6BytesMTU. 1) if LinkLocalAddressing is not disabled, it will clobber any IPv6BytesMTU value set. [Network] LinkLocalAddressing=ipv6 Address=10.10.10.10/24 IPv6MTUBytes=1470 This results in: /proc/sys/net/ipv6/conf//mtu having a value of 1500 if I disable LinkLocalAddressing like so: [Network] LinkLocalAddressing=no Address=10.10.10.10/24 IPv6MTUBytes=1470 Then I get 1470. This seems like a bug; do we need an upstream issue to track this? 2) systemd-networkd will not raise the device MTU limit automatically. The default device MTU is 1500. If you set IPv6BytesMTU to 1520, then systemd-networkd emits this message: Nov 26 19:13:59 rharper-b2 systemd-networkd[593]: eth2: Cannot set IPv6 MTU for interface: Invalid argument which is the same message you get if you: echo "1520" > /proc/sys/net/ipv6/conf//mtu: # echo 1520 > /proc/sys/net/ipv6/conf/eth2/mtu bash: echo: write error: Invalid argument If this is considered "acceptable" behavior for systemd, then it will leave netplan with a decision when it is presented with a config which sets an ipv6-mtu bytes value that is bigger than the default device value (1500), or bigger than an specified device mtu. Will it report an error with the config? Should we file an upstream issue to see if networkd is willing to raise the device limit (or possibly emit a more helpful message to indicate that networkd cannot set an IPv6 MTU greater than the underlying device MTU? -- 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 :
Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
On Mon, Nov 26, 2018 at 11:11 PM Jay Vosburgh <1671...@bugs.launchpad.net> wrote: > > 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. I think that's reasonable too. We'll need to file a separate bug with MAAS to ensure that it knows it should set device MTU >= to the ipv6 MTU configured. This will ensure the configuration that gets generated will include both a raised device MTU and an IPV6 MTU. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1671951 > > Title: > networkd should allow configuring IPV6 MTU > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions -- 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
Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
On Tue, Dec 4, 2018 at 6:31 AM Dimitri John Ledkov wrote: > Using systemd 237-3ubuntu10.10 > > Using: > [Match] > Name=ens3 > [Network] > DHCP=ipv4 > IPv6MTUBytes=1600 > [Link] > MTUBytes=1800 > [DHCP] > UseMTU=no > RouteMetric=100 > Do you put this in the same .network file or .link file? -- 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
Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
On Tue, Dec 4, 2018 at 9:31 AM Ryan Harper wrote: > > > On Tue, Dec 4, 2018 at 6:31 AM Dimitri John Ledkov > wrote: > >> Using systemd 237-3ubuntu10.10 >> >> Using: >> [Match] >> Name=ens3 >> [Network] >> DHCP=ipv4 >> IPv6MTUBytes=1600 >> [Link] >> MTUBytes=1800 >> [DHCP] >> UseMTU=no >> RouteMetric=100 >> > > Do you put this in the same .network file or .link file? > FWIW, I'm not able to make this work inside a LXD container. Could you provide more details on how you validated and in what environment? -- 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 1831787] Re: Bogus routes after DHCP lease change
Looks like this issue, I think: https://github.com/systemd/systemd/issues/12490 ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- 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/1831787 Title: Bogus routes after DHCP lease change Status in netplan: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: Netplan config: network: version: 2 renderer: networkd ethernets: eno4: dhcp4: no eno1np0: dhcp4: no addresses: - 172.16.0.2/24 bridges: br0: dhcp4: yes interfaces: - eno4 On initial boot, machine got 10.0.15.109 IP address: May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: Configured May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: DHCPv4 address 10.0.15.109/23 via 10.0.15.253 At one point, DHCP server reserver this IP address and client eventually picked up new IP address: May 03 15:01:12 ceph2 systemd-networkd[1137]: br0: DHCPv4 address 10.0.15.128/23 via 10.0.15.253 This resulted in IP addresses: # ip -o a 1: loinet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 1: loinet6 ::1/128 scope host \ valid_lft forever preferred_lft forever 2: eno1np0inet 172.16.0.2/24 brd 172.16.0.255 scope global eno1np0\ valid_lft forever preferred_lft forever 2: eno1np0inet6 fe80::b226:28ff:fe53:56be/64 scope link \ valid_lft forever preferred_lft forever 6: br0inet 10.0.15.128/23 brd 10.0.15.255 scope global dynamic br0\ valid_lft 503sec preferred_lft 503sec 6: br0inet6 fe80::b8d7:5eff:fe6b:62a/64 scope link \ valid_lft forever preferred_lft forever So far, everything is fine. But, the routes on the machine are bogus: # ip r default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.109 metric 100 default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.128 metric 100 10.0.14.0/23 dev br0 proto kernel scope link src 10.0.15.128 10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.109 metric 100 10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.128 metric 100 172.16.0.0/24 dev eno1np0 proto kernel scope link src 172.16.0.2 routes with src 10.0.15.109 should have been removed when lease was renewed. I'm not sure if this is a bug in netplan or systemd. This is 18.04, systemd 37-3ubuntu10.21, netplan 0.40.1~18.04.4. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1831787/+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 1831787] Re: Bogus routes after DHCP lease change
** Changed in: netplan Status: Incomplete => Invalid ** Changed in: systemd (Ubuntu) Importance: Undecided => High ** Changed in: systemd (Ubuntu) Status: Incomplete => Triaged -- 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/1831787 Title: Bogus routes after DHCP lease change Status in netplan: Invalid Status in systemd package in Ubuntu: Triaged Bug description: Netplan config: network: version: 2 renderer: networkd ethernets: eno4: dhcp4: no eno1np0: dhcp4: no addresses: - 172.16.0.2/24 bridges: br0: dhcp4: yes interfaces: - eno4 On initial boot, machine got 10.0.15.109 IP address: May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: Configured May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: DHCPv4 address 10.0.15.109/23 via 10.0.15.253 At one point, DHCP server reserver this IP address and client eventually picked up new IP address: May 03 15:01:12 ceph2 systemd-networkd[1137]: br0: DHCPv4 address 10.0.15.128/23 via 10.0.15.253 This resulted in IP addresses: # ip -o a 1: loinet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 1: loinet6 ::1/128 scope host \ valid_lft forever preferred_lft forever 2: eno1np0inet 172.16.0.2/24 brd 172.16.0.255 scope global eno1np0\ valid_lft forever preferred_lft forever 2: eno1np0inet6 fe80::b226:28ff:fe53:56be/64 scope link \ valid_lft forever preferred_lft forever 6: br0inet 10.0.15.128/23 brd 10.0.15.255 scope global dynamic br0\ valid_lft 503sec preferred_lft 503sec 6: br0inet6 fe80::b8d7:5eff:fe6b:62a/64 scope link \ valid_lft forever preferred_lft forever So far, everything is fine. But, the routes on the machine are bogus: # ip r default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.109 metric 100 default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.128 metric 100 10.0.14.0/23 dev br0 proto kernel scope link src 10.0.15.128 10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.109 metric 100 10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.128 metric 100 172.16.0.0/24 dev eno1np0 proto kernel scope link src 172.16.0.2 routes with src 10.0.15.109 should have been removed when lease was renewed. I'm not sure if this is a bug in netplan or systemd. This is 18.04, systemd 37-3ubuntu10.21, netplan 0.40.1~18.04.4. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1831787/+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 1846232] Re: vmtests: test_ip_output failing in vlan tests on eoan
@Dan/Chad I suggest we skip-by this bug number on the eoan vlan test case; -- 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/1846232 Title: vmtests: test_ip_output failing in vlan tests on eoan Status in curtin: Invalid Status in systemd package in Ubuntu: New Bug description: From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel- amd64/916/console: == FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan) -- Traceback (most recent call last): File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 311, in test_ip_output routes) File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 337, in check_interface int(ipcfg[key])) AssertionError: 1500 != 1504 >> begin captured stdout << - parsed ip_a dict: interface0: broadcast: 10.245.175.255 group: default inet4: - address: 10.245.168.16 prefixlen: '21' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4913 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4913 prefixlen: '64' scope: link valid_lft: forever interface: interface0 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:13 mtu: '1500' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1: broadcast: 10.245.188.255 group: default inet4: - address: 10.245.188.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4915 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1504' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1.2667: broadcast: 10.245.184.255 group: default inet4: - address: 10.245.184.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2667 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2668: broadcast: 10.245.185.255 group: default inet4: - address: 10.245.185.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2668 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2669: broadcast: 10.245.186.255 group: default inet4: - address: 10.245.186.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2669 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2670: broadcast: 10.245.187.255 group: default inet4: - address: 10.245.187.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2670 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: fa
[Touch-packages] [Bug 1846232] Re: vmtests: test_ip_output failing in vlan tests on eoan
This can be reproduced in an LXD Eoan container: lxc launch ubuntu-daily:eoan e1 lxc exec e1 cat > /etc/netplan/50-cloud-init.yaml << EOF network: version: 2 ethernets: eth0: dhcp4: false mtu: 1500 vlans: eth0.2667: id: 2667 addresses: [10.22.33.2/24] link: eth0 mtu: 1500 EOF reboot lxc exec e1 bash cloud-init status --wait ip link show eth0 And this is not an issue in Disco systemd. -- 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/1846232 Title: vmtests: test_ip_output failing in vlan tests on eoan Status in curtin: Invalid Status in systemd package in Ubuntu: New Bug description: From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel- amd64/916/console: == FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan) -- Traceback (most recent call last): File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 311, in test_ip_output routes) File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 337, in check_interface int(ipcfg[key])) AssertionError: 1500 != 1504 >> begin captured stdout << - parsed ip_a dict: interface0: broadcast: 10.245.175.255 group: default inet4: - address: 10.245.168.16 prefixlen: '21' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4913 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4913 prefixlen: '64' scope: link valid_lft: forever interface: interface0 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:13 mtu: '1500' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1: broadcast: 10.245.188.255 group: default inet4: - address: 10.245.188.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4915 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1504' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1.2667: broadcast: 10.245.184.255 group: default inet4: - address: 10.245.184.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2667 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2668: broadcast: 10.245.185.255 group: default inet4: - address: 10.245.185.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2668 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2669: broadcast: 10.245.186.255 group: default inet4: - address: 10.245.186.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2669 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2670: broadcast: 10.245.187.255 group: default inet4: - address: 10.245.187.2 prefixlen: '24' scope: gl
[Touch-packages] [Bug 1846232] Re: vmtests: test_ip_output failing in vlan tests on eoan
This looks to be related to networkd: https://github.com/systemd/systemd/pull/12574/commits Which is automatically added 4 bytes to base interface MTU, even though we're explicitly setting mtu to 1500 on base interface and vlan. ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: curtin Status: New => Invalid -- 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/1846232 Title: vmtests: test_ip_output failing in vlan tests on eoan Status in curtin: Invalid Status in systemd package in Ubuntu: New Bug description: From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel- amd64/916/console: == FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan) -- Traceback (most recent call last): File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 311, in test_ip_output routes) File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 337, in check_interface int(ipcfg[key])) AssertionError: 1500 != 1504 >> begin captured stdout << - parsed ip_a dict: interface0: broadcast: 10.245.175.255 group: default inet4: - address: 10.245.168.16 prefixlen: '21' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4913 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4913 prefixlen: '64' scope: link valid_lft: forever interface: interface0 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:13 mtu: '1500' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1: broadcast: 10.245.188.255 group: default inet4: - address: 10.245.188.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4915 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1504' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1.2667: broadcast: 10.245.184.255 group: default inet4: - address: 10.245.184.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2667 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2668: broadcast: 10.245.185.255 group: default inet4: - address: 10.245.185.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2668 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2669: broadcast: 10.245.186.255 group: default inet4: - address: 10.245.186.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2669 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2670: broadcast: 10.245.187.255 group: default inet4: - address: 10.245.187.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64'
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
I cannot verify this is working on bionic with ipv6 static addresses.
root@ubuntu:~# lsb_release -rd
Description:Ubuntu 18.04.3 LTS
Release:18.04
root@ubuntu:~# cat /etc/cloud/build.info
build_name: server
serial: 20191021
root@ubuntu:~# uname -a
Linux ubuntu 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:~# apt-cache policy netplan.io
netplan.io:
Installed: 0.98-0ubuntu1~18.04.1
Candidate: 0.98-0ubuntu1~18.04.1
Version table:
*** 0.98-0ubuntu1~18.04.1 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
0.40.1~18.04.4 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
Packages
0.36.1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
root@ubuntu:~# apt-cache policy systemd
systemd:
Installed: 237-3ubuntu10.31
Candidate: 237-3ubuntu10.31
Version table:
*** 237-3ubuntu10.31 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
237-3ubuntu10.29 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
Packages
237-3ubuntu10 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
root@ubuntu:~# cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
interface0:
dhcp4: true
match:
macaddress: '52:54:00:12:34:00'
set-name: interface0
interface1:
dhcp4: false
dhcp6: false
addresses:
- 192.168.1.2/24
- 2001:4800:78ff:1b:be76:4eff:fe06:1000/64
match:
macaddress: '52:54:00:12:34:02'
mtu:
ipv6-mtu: 5634
set-name: interface1
accept-ra: false
dhcp6-overrides:
use-mtu: false
link-local: [ ]
root@ubuntu:~# ip link show interface1
3: interface1: mtu qdisc fq_codel state
UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:12:34:02 brd ff:ff:ff:ff:ff:ff
# sysctl net.ipv6.conf.interface1.mtu
net.ipv6.conf.interface1.mtu =
root@ubuntu:~# cat /run/systemd/network/10-netplan-interface1.link
[Match]
MACAddress=52:54:00:12:34:02
[Link]
Name=interface1
WakeOnLan=off
MTUBytes=
root@ubuntu:~# cat /run/systemd/network/10-netplan-interface1.network
[Match]
MACAddress=52:54:00:12:34:02
Name=interface1
[Network]
LinkLocalAddressing=no
Address=192.168.1.2/24
Address=2001:4800:78ff:1b:be76:4eff:fe06:1000/64
IPv6AcceptRA=no
IPv6MTUBytes=5634
# journalctl -o short-precise -b 0 | egrep -i "(MTU|interface1)"
Oct 23 21:28:47.968910 ubuntu kernel: virtio_net virtio3 interface1: renamed
from ens6
Oct 23 21:28:50.636014 ubuntu systemd-networkd[670]: Ignoring
/run/systemd/network/10-netplan-interface1.network, because it's not a regular
file with suffix .netdev.
Oct 23 21:28:50.636090 ubuntu systemd-networkd[670]: Ignoring
/run/systemd/network/10-netplan-interface1.link, because it's not a regular
file with suffix .netdev.
Oct 23 21:28:50.636706 ubuntu systemd-networkd[670]: Ignoring
/run/systemd/network/10-netplan-interface1.link, because it's not a regular
file with suffix .network.
Oct 23 21:28:50.640507 ubuntu systemd-networkd[670]: interface7: Saved original
MTU: 1500
Oct 23 21:28:50.642454 ubuntu systemd-networkd[670]: interface6: Saved original
MTU: 1500
Oct 23 21:28:50.643050 ubuntu systemd-networkd[670]: interface5: Saved original
MTU: 1500
Oct 23 21:28:50.643629 ubuntu systemd-networkd[670]: interface4: Saved original
MTU: 1500
Oct 23 21:28:50.644214 ubuntu systemd-networkd[670]: interface3: Saved original
MTU: 1500
Oct 23 21:28:50.644939 ubuntu systemd-networkd[670]: interface2: Saved original
MTU: 1500
Oct 23 21:28:50.645025 ubuntu systemd-networkd[670]: interface1: New device has
no master, continuing without
Oct 23 21:28:50.645107 ubuntu systemd-networkd[670]: interface1: Flags change:
+MULTICAST +BROADCAST
Oct 23 21:28:50.645175 ubuntu systemd-networkd[670]: interface1: Link 3 added
Oct 23 21:28:50.645456 ubuntu systemd-networkd[670]: interface1: udev
initialized link
Oct 23 21:28:50.647448 ubuntu systemd-networkd[670]: interface1: Saved original
MTU:
Oct 23 21:28:50.648100 ubuntu systemd-networkd[670]: interface0: Saved original
MTU: 1500
Oct 23 21:28:50.648670 ubuntu systemd-networkd[670]: lo: Saved original MTU: 0
Oct 23 21:28:50.655303 ubuntu systemd-networkd[670]: interface1: Interface name
change detected, interface1 has been renamed to ens6.
Oct 23 21:28:50.655431 ubuntu systemd-netwo
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
The original netplan yaml I was testing was simpler, but also failed so I tried to see if additional settings would make a difference, but it did not. network: version: 2 ethernets: interface0: dhcp4: true match: macaddress: '52:54:00:12:34:00' set-name: interface0 interface1: addresses: - 192.168.1.2/24 - 2001:4800:78ff:1b:be76:4eff:fe06:1000/64 match: macaddress: '52:54:00:12:34:02' mtu: ipv6-mtu: 5634 set-name: interface1 -- 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: Fix Released 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: Fix Released Status in systemd source package in Bionic: Fix Released Status in cloud-init source package in Disco: New Status in netplan.io source package in Disco: Fix Released Status in systemd source package in Disco: New Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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/
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
In the Eoan version of systemd, I can see in the logs these messages: Oct 24 18:52:32.753746 ubuntu systemd-networkd[1167]: Setting '/proc/sys/net/ipv6/conf/interface1/proxy_ndp' to '0' Oct 24 18:52:32.753848 ubuntu systemd-networkd[1167]: Setting '/proc/sys/net/ipv6/conf/interface1/use_tempaddr' to '0' Oct 24 18:52:32.753884 ubuntu systemd-networkd[1167]: Setting '/proc/sys/net/ipv6/conf/interface1/accept_ra' to '0' Oct 24 18:52:32.753962 ubuntu systemd-networkd[1167]: Setting '/proc/sys/net/ipv6/conf/interface1/mtu' to '5634' These are not emitted in bionic or disco versions of systemd. -- 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: Fix Released 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: Fix Released Status in systemd source package in Bionic: Fix Released Status in cloud-init source package in Disco: New Status in netplan.io source package in Disco: Fix Released Status in systemd source package in Disco: New Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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-ini
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
I did some more testing today. I upgraded systemd and netplan.io to disco level, rebooted and tested the MTU settings; disco packages fail as well. I then upgraded to eoan systemd/netplan.io rebooted and the MTU settings are correct. -- 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: Fix Released 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: Fix Released Status in systemd source package in Bionic: Fix Released Status in cloud-init source package in Disco: New Status in netplan.io source package in Disco: Fix Released Status in systemd source package in Disco: New Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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
Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
On Fri, Oct 25, 2019 at 1:31 PM Dan Streetman wrote: > I looked at this for a few minutes, and it seems strange that it works > at all (at boot) since networkd sets the ipv6 mtu before bringing the > link up, but the kernel resets the ipv6 mtu to the device mtu on link > up. I must be missing something. > I'm glad you saw that. I'm seeing this as well on my curtin vmtest (automated deployment and data collection during first boot). I have to restart networkd for it to work on the first boot. Subsequent boots it seems to work fine without a restart of networkd. > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1671951 > > Title: > networkd should allow configuring IPV6 MTU > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions > -- 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: Fix Released 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: Fix Released Status in systemd source package in Bionic: Triaged Status in cloud-init source package in Disco: New Status in netplan.io source package in Disco: Fix Released Status in systemd source package in Disco: Triaged Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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.
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
@Balint, after further testing, here's where things are: - On LXD Containers - On Bionic 1) First boot: neither interface mtu, nor ipv6 mtu is applied. 2) Restarting systemd-networkd: neither interface nor ipv6-mtu is applied 3) netplan apply: interface mtu is set correctly, ipv6 mtu is not. On Disco 1) First boot: neither interface mtu, nor ipv6 mtu is applied. 2) Restarting systemd-networkd: neither interface nor ipv6-mtu is applied 3) netplan apply: both interface and ipv6 MTU are set correctly. On Eoan 1) First boot: neither interface mtu, nor ipv6 mtu is applied 2) Restarting systemd-networkd: neither interface nor ipv6-mtu is applied 3) netplan apply: both interface and ipv6 MTU are set correctly. -- On VMs -- On Bionic 1) First boot: interface MTU is set, ipv6 MTU is not applied. 2) Restarting systemd-networkd: both interface and ipv6 MTU are set correctly 3) netplan apply not needed 4) After reboot, same as (1) On Disco 1) First boot: interface MTU is set, ipv6 MTU is not applied. 2) Restarting systemd-networkd: both interface and ipv6 MTU are set correctly 3) netplan apply not needed 4) After reboot, same as (1) On Eoan 1) First boot: interface MTU is set, ipv6 MTU is not applied. 2) Restarting systemd-networkd: both interface and ipv6 MTU are set correctly 3) netplan apply not needed 4) After reboot, same as (1) -- 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: Fix Released 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: Fix Released Status in systemd source package in Bionic: Triaged Status in cloud-init source package in Disco: New Status in netplan.io source package in Disco: Fix Released Status in systemd source package in Disco: Triaged Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
@Dan, Ill try the ppa and report back. cloud-init is not doing anything special here, we render the config and call netplan generate. If we take cloud-init out of the picture, and just have a file in /etc/netplan it will still fail due to the udev issue you specify. Shouldn't netplan itself handle container-based rendering if [Link] sections when running inside a container? -- 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: Fix Released 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: Fix Released Status in systemd source package in Bionic: Triaged Status in cloud-init source package in Disco: New Status in netplan.io source package in Disco: Fix Released Status in systemd source package in Disco: Triaged Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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.launc
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Testing with @ddstreet's systemd ppa, I can confirm that bionic, disco and eoan correctly set MTU on first boot, no systemd-restart needed. -- 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: Fix Released 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: Fix Released Status in systemd source package in Bionic: Triaged Status in cloud-init source package in Disco: New Status in netplan.io source package in Disco: Fix Released Status in systemd source package in Disco: Triaged Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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 1851438] Re: cloud-init disk_setup fails to partition disk for Ubuntu18
On trusty; this complains but works. ubuntu@ubuntu:~$ dpkg --list | grep util-linux ii util-linux 2.20.1-5.1ubuntu20.9 amd64Miscellaneous system utilities ubuntu@ubuntu:~$ cat /proc/partitions major minor #blocks name 2530 10485760 vda 2531 10484736 vda1 253 16 10485760 vdb 253 32366 vdc 1101048575 sr0 ubuntu@ubuntu:~$ sudo bash sudo: unable to resolve host ubuntu root@ubuntu:~# echo "0," | sfdisk --Linux --unit=S --force /dev/vdb Checking that no-one is using this disk right now ... OK Disk /dev/vdb: 20805 cylinders, 16 heads, 63 sectors/track sfdisk: ERROR: sector 0 does not have an msdos signature /dev/vdb: unrecognized partition table type Old situation: No partitions found Warning: bad partition start (earliest 1) New situation: Units = sectors of 512 bytes, counting from 0 Device BootStart End #sectors Id System /dev/vdb1 1 20971519 20971519 83 Linux /dev/vdb2 0 - 0 0 Empty /dev/vdb3 0 - 0 0 Empty /dev/vdb4 0 - 0 0 Empty Warning: no primary partition is marked bootable (active) This does not matter for LILO, but the DOS MBR will not boot this disk. Successfully wrote the new partition table Re-reading the partition table ... If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1 (See fdisk(8).) root@ubuntu:~# cat /proc/partitions major minor #blocks name 2530 10485760 vda 2531 10484736 vda1 253 16 10485760 vdb 253 17 10485759 vdb1 253 32366 vdc 1101048575 sr0 ** Also affects: util-linux (Ubuntu) Importance: Undecided Status: New ** Also affects: util-linux (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: util-linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: util-linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: util-linux (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1851438 Title: cloud-init disk_setup fails to partition disk for Ubuntu18 Status in cloud-init: Triaged Status in util-linux package in Ubuntu: New Status in util-linux source package in Xenial: New Status in util-linux source package in Bionic: New Status in util-linux source package in Eoan: New Status in util-linux source package in Focal: New Bug description: Pasting disk_setup for cloud-config: disk_setup: /dev/xvde: layout: True overwrite: False type: mbr fs_setup: -device: /dev/xvde filesystem: ext4 label: data overwrite: false partition: auto I want to attach and mount a /data disk on the VM using cloud-init so I just want to single partition 100% of the disk. Error while running the sfdisk command for partitioning the disk (please see attached file). OS: Ubuntu18 How I repro-ed it outside cloud-init environment: 1. Open XenCenter, add a new disk, say /dev/xvdc 2. Run `/sbin/sfdisk --Linux --unit=S --force /dev/xvdc` and specify start sector as 0. Because from the cloud-init logs and source code, I figured that it was picking start sector as 0. Save it and see the error. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1851438/+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 1834875] Re: cloud-init growpart race with udev
A couple of comments on the suggested path: > Imho the sequency of commands should be: > * take flock on the device, to neutralise udev +1 on this approach. Do you know if the flock will block systemd's inotify write watch on the block device which triggers udevd? This is the typical race we see with partition creation and rules executing. > * modify device with sfdisk > * reread partitions tables (i would say with blockdev --rereadpt, rather than > partx/partprobe) I'm not sure we can use blockdev --rereadpt as we are operating upon the root disk we're booted on and my understanding is that the ioctl that partx uses is the only way to update the kernel partition table while the disk is in use, otherwise we'd see the normal warning message like when you fdisk your booted device and it says the disk is busy and cannot read the partition table. > * release the flock +1 > * udevadm trigger --action=add --wait device (or trigger && settle) I don't relish the idea of *re-adding* actions on the disk again since the partx update should have already emitted the uevents associated with the new partitions. However, we could do this as a way to force reloading of everything. I'd like to withhold judgement on whether we need this after testing with use of flock on the device. > And like have a canary "only use locked codepath on this region" such that we can assert through testing that this no longer happens with new code, but does with old code. The change to cloud-utils growpart could add a flag (--use-flock) so cloud-init could emit different log messages on which path it takes (including a warning if we cannot use flock (ie, you may race). -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1834875] Re: cloud-init growpart race with udev
> it will prevent udevd from running the rules against it. Thus effectively the event will be fired and done, but nothing actually executed for it. Interesting, I suspect this is the race we see. The events emitted but no actions taken (ie we didn't get our by-partuuid symlink created. > I somehow wonder if we even need partx call, if we properly flock the device and trigger udev after everything is done. Growpart is modifying the partition table of the root device which is already mounted. We will not be able to flock the root device since it's open and mounted. This is precisely why we need to use the partx call as it updates the kernel partition table mapping without requiring an exclusive lock on the device. > So does growpart create partition? move it? delete/recreate one? i.e does ADD happen? or like REMOVE & ADD? or maybe it's like just MOVE or CHANGE? Do we have logs of the emitted events already? growpart on gpt, uses sgdisk which, deletes and then recreates the existing partition but with a larger size. The logs are above, see comment #22 -> #24 and #38. > Don't like flags, as then we'll have to supported forever =) maybe env variable? or like simply change in focal and compare focal vs eoan? This may not matter if we can't flock. I suspect we'll need to use the ugly re-trigger events for the disk. growpart could take the disk it's pointed at, examine the existing udevadm symlinks associated with this (via udevadm info --export), perform it's operation, and then post- operation, trigger the add event on the disk, settle, and confirm that udevadm info --export contains the same set of links (partuuid ,etc). -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1834875] Re: cloud-init growpart race with udev
@ddstreet Yes, settle does not help. Re-triggering udevadm trigger --action=add /sys/class/block/sda Would re-run all of them after the partition change has occurred, which is what I'm currently suggesting as a heavy-handed workaround. I would like to understand *why* the udevd/kernel pair exhibits this racy behavior whereas other kernels/udevd from Bionic do not. -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+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
Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
On Thu, Nov 7, 2019 at 1:30 PM Dan Streetman wrote: > > Yes, settle does not help. > > Well, I didn't suggest just to settle ;-) > Sorry; long bug thread. > > I'm currently suggesting as a heavy-handed workaround. > > I don't really see why you think this is heavy-handed, but I must be > missing something. > It's replaying the disk events which results in running rules multiple times. The ADD|CHANGE event was already emitted once (when growpart modifies the partition) and the rules were run (likely at the wrong time). Issuing a second trigger will repeat this. IMO, that's a non-zero amount of time that slows the boot down, so I'd like to avoid that. -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+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
Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
On Thu, Nov 7, 2019 at 11:30 AM Dimitri John Ledkov wrote: > > So that means we have this sequence of events: > > a.) growpart change partition table > > b.) growpart call partx > > c.) udev created and events being processed > > That is not true. whilst sfdisk is deleting, creating, finishing > partition table (a) and partx is called (b), udev events are already > fired and running in parallel and may complete against deleted, > partially new, completely new partition table, with or without partx > completed. > > No amount of settling for events will fix the fact that events were run > against racy state of the partition table _during_ sfdisk and partx > calls. > udevadm control --stop-exec-queue sgdisk partx udevadm control --start-exec-queue -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+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
Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
On Thu, Nov 7, 2019 at 2:41 PM Dan Streetman wrote: > > Issuing a second > > trigger will repeat this. > > IMO, that's a non-zero amount of time that slows the boot down, so I'd > like > > to avoid that. > > systemd-udev-trigger.serivce retriggers *everything* at boot (except in > an unprivileged container where it can't), so I'm not sure how much > added time we're talking about just for a single block device. We can't know how many devices are in the system. It maybe nearly zero, it could be minutes. The cold plug is required (initramfs may or maynot have ran scripts/udevd etc but kernel events already were emitted during initial boot and userspace isn't ready yet) and runs before cloud-init runs. > yeah, you need the kernel to send a uevent to udevd after the partition > table is ready for udevd to read, or udevd won't get the right partition > table info; whether you do some locking to try to block udevd from > reading it or just retrigger an event after it's ready. > Generally yes; and what we still don;t know is why it's racing here but not everywhere all the time. Note that *growpart* runs on every single cloud instance boot. There's a _LOT_ of those; something changed in udev/kernel which is racing and it'd be good to track that bit down. > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1834875 > > Title: > cloud-init growpart race with udev > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions > -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1768468] Re: error in ca_certs module
Hi, I don't believe this is a cloud-init bug. Cloud-init wrote the two certificate files requested. 2018-05-02 08:55:00,913 - stages.py[DEBUG]: Running module ca-certs () with frequency once-per-instance 2018-05-02 08:55:00,914 - handlers.py[DEBUG]: start: init-network/config-ca-certs: running config-ca-certs with frequency once-per-instance 2018-05-02 08:55:00,914 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/44574988-144d-485a-9386-2ec4f4f545c4/sem/config_ca_certs - wb: [644] 24 bytes 2018-05-02 08:55:00,914 - helpers.py[DEBUG]: Running config-ca-certs using lock () 2018-05-02 08:55:00,914 - cc_ca_certs.py[DEBUG]: Adding 2 certificates 2018-05-02 08:55:00,916 - util.py[DEBUG]: Writing to /usr/share/ca-certificates/cloud-init-ca-certs.crt - wb: [644] 4545 bytes 2018-05-02 08:55:00,917 - util.py[DEBUG]: Reading from /etc/ca-certificates.conf (quiet=False) 2018-05-02 08:55:00,917 - util.py[DEBUG]: Read 5898 bytes from /etc/ca-certificates.conf 2018-05-02 08:55:00,917 - util.py[DEBUG]: Writing to /etc/ca-certificates.conf - wb: [644] 5922 bytes 2018-05-02 08:55:00,918 - cc_ca_certs.py[DEBUG]: Updating certificates 2018-05-02 08:55:00,918 - util.py[DEBUG]: Running command ['update-ca-certificates'] with allowed return codes [0] (shell=False, capture=False) 2018-05-02 08:55:01,845 - handlers.py[DEBUG]: finish: init-network/config-ca-certs: SUCCESS: config-ca-certs ran successfully The error you show mentions a 'cloud-init-ca-certs.pem' It may be related the ca-certificates package? I'm adding the package as a task. ** Also affects: ca-certificates (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1768468 Title: error in ca_certs module Status in cloud-init: Invalid Status in ca-certificates package in Ubuntu: New Bug description: Hello, I'm using cloud-init in order to customize Nutanix AHV images. I'm using the ca_certs module to upload our private ca chain (root and intermediate) but in the log I found a log that states that - Cloud-init v. 18.2 running 'init-local' at Wed, 02 May 2018 08:54:58 +. Up 6.25 seconds. Updating certificates in /etc/ssl/certs... rehash: skipping cloud-init-ca-certs.pem,it does not contain exactly one certificate or CRL 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. - And the certificates are not trusted. Ubuntu version is 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1768468/+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 1768468] Re: error in ca_certs module
I'm marking the cloud-init task invalid; I don't believe cloud-init did anything wrong; but please set the task back to New if you have new information showing that cloud-init didn't do something quite right. ** Changed in: cloud-init Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1768468 Title: error in ca_certs module Status in cloud-init: Invalid Status in ca-certificates package in Ubuntu: New Bug description: Hello, I'm using cloud-init in order to customize Nutanix AHV images. I'm using the ca_certs module to upload our private ca chain (root and intermediate) but in the log I found a log that states that - Cloud-init v. 18.2 running 'init-local' at Wed, 02 May 2018 08:54:58 +. Up 6.25 seconds. Updating certificates in /etc/ssl/certs... rehash: skipping cloud-init-ca-certs.pem,it does not contain exactly one certificate or CRL 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. - And the certificates are not trusted. Ubuntu version is 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1768468/+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 1838653] [NEW] lvs blocks a long time when /run is not mounted
Public bug reported: Installing into a chroot without /run mounted, grub's os-prober calls into lvs for details and it waits a very long time. I believe this is fixed upstream: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=3ebce8dbd2d9afc031e0737f8feed796ec7a8df9 1. Eoan 2. lvm2 2.03.02-2ubuntu5 3. lvs doesn't hang 4. lvs waits up to 10 seconds for each device to be in udev [ 181.186946] cloud-init[860]: Generating grub configuration file ... [ 181.482159] cloud-init[860]: File descriptor 3 (pipe:[156394]) leaked on lvs invocation. Parent PID 336: [ 191.524704] cloud-init[860]: WARNING: Device /dev/nvme0n1 not initialized in udev database even after waiting 1000 microseconds. [ 201.551563] cloud-init[860]: WARNING: Device /dev/loop0 not initialized in udev database even after waiting 1000 microseconds. [ 211.576785] cloud-init[860]: WARNING: Device /dev/md0 not initialized in udev database even after waiting 1000 microseconds. [ 221.604393] cloud-init[860]: WARNING: Device /dev/bcache0 not initialized in udev database even after waiting 1000 microseconds. [ 231.635862] cloud-init[860]: WARNING: Device /dev/bcache2 not initialized in udev database even after waiting 1000 microseconds. [ 241.662524] cloud-init[860]: WARNING: Device /dev/bcache4 not initialized in udev database even after waiting 1000 microseconds. [ 251.691894] cloud-init[860]: WARNING: Device /dev/vda not initialized in udev database even after waiting 1000 microseconds. [ 261.722293] cloud-init[860]: WARNING: Device /dev/nvme1n1 not initialized in udev database even after waiting 1000 microseconds. [ 271.755710] cloud-init[860]: WARNING: Device /dev/vda1 not initialized in udev database even after waiting 1000 microseconds. [ 281.790372] cloud-init[860]: WARNING: Device /dev/nvme0n1p1 not initialized in udev database even after waiting 1000 microseconds. [ 291.826365] cloud-init[860]: WARNING: Device /dev/nvme1n1p1 not initialized in udev database even after waiting 1000 microseconds. [ 301.861237] cloud-init[860]: WARNING: Device /dev/nvme0n1p2 not initialized in udev database even after waiting 1000 microseconds. [ 311.892953] cloud-init[860]: WARNING: Device /dev/nvme1n1p2 not initialized in udev database even after waiting 1000 microseconds. [ 321.924557] cloud-init[860]: WARNING: Device /dev/vdb not initialized in udev database even after waiting 1000 microseconds. [ 331.957529] cloud-init[860]: WARNING: Device /dev/vdc not initialized in udev database even after waiting 1000 microseconds. [ 341.990234] cloud-init[860]: WARNING: Device /dev/vdd not initialized in udev database even after waiting 1000 microseconds. [ 352.022321] cloud-init[860]: WARNING: Device /dev/vde not initialized in udev database even after waiting 1000 microseconds. [ 362.056566] cloud-init[860]: WARNING: Device /dev/vdf not initialized in udev database even after waiting 1000 microseconds. [ 372.091625] cloud-init[860]: WARNING: Device /dev/vdf1 not initialized in udev database even after waiting 1000 microseconds. [ 382.125340] cloud-init[860]: WARNING: Device /dev/vdf2 not initialized in udev database even after waiting 1000 microseconds. [ 392.159381] cloud-init[860]: WARNING: Device /dev/vdf3 not initialized in udev database even after waiting 1000 microseconds. [ 402.190582] cloud-init[860]: WARNING: Device /dev/vdg not initialized in udev database even after waiting 1000 microseconds. [ 412.219362] cloud-init[860]: WARNING: Device /dev/vdh not initialized in udev database even after waiting 1000 microseconds. [ 422.250694] cloud-init[860]: WARNING: Device /dev/vdh1 not initialized in udev database even after waiting 1000 microseconds. [ 432.281953] cloud-init[860]: WARNING: Device /dev/bcache1 not initialized in udev database even after waiting 1000 microseconds. [ 442.310473] cloud-init[860]: WARNING: Device /dev/bcache3 not initialized in udev database even after waiting 1000 microseconds. [ 452.336603] cloud-init[860]: WARNING: Device /dev/bcache5 not initialized in udev database even after waiting 1000 microseconds. [ 462.362582] cloud-init[860]: WARNING: Device /dev/vdi not initialized in udev database even after waiting 1000 microseconds. [ 472.395526] cloud-init[860]: WARNING: Device /dev/nvme0n1 not initialized in udev database even after waiting 1000 microseconds. [ 482.422127] cloud-init[860]: WARNING: Device /dev/loop0 not initialized in udev database even after waiting 1000 microseconds. [ 492.454553] cloud-init[860]: WARNING: Device /dev/md0 not initialized in udev database even after waiting 1000 microseconds. [ 502.484730] cloud-init[860]: WARNING: Device /dev/bcache0 not initialized in udev database even after waiting 1000 microseconds. [ 512.514417] cloud-init[860]:
[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
The sequence is: exec growpart exec sgdisk --info # read-only exec sgdisk --pretend # read-only exec sgdisk --backup # read-only copy # modification of disk starts exec sgdisk --move-second-header \ --delete=PART \ --new=PART \ --typecode --partition-guid --change-name # now that sgdisk has *closed* the filehandle on the disk, systemd-udevd will # get an inotify signal and trigger udevd to run udev scripts on the disk. # this includes the *removal* of symlinks due to the --delete portion of sgdisk call # and following the removal, the -new will trigger the add run on the rules which would # recreate the symlinks. # update kernel partition sizes; this is an ioctl so it does not trigger an udev events exec partx --update # the kernel has the new partition sizes, and udev scripts/events are all queued (and possibly in flight) exit growpart cloud-init invokes get_size() operation which: # this is where the race occurs if the symlink created by udev is *not* present os.open(/dev/disk/by-id/fancy-symlink-with-partuuid-points-to-sdb1) Dan had put a udevadm settle in this spot like so def get_size(filename) util.subp(['udevadm', 'settle']) os.open() So, you're suggesting that somehow _not all_ of the uevents triggered by the sgdisk command in growpart *wouldn't* have been queued before we call udevadm settle? If some other events are happening how is cloud-init to know such that it can take action to "handle this race" more robustly? Lastly if there is a *race* in the symlink creation/remove/delay in uevent propigation; why is that a userspace let alone a cloud-init issue. This isn't universally reproducible, rather it's pretty narrow circumstances between certain kernels and udevs all the while the growpart/cloud-init code remains the same. ** Changed in: cloud-init Status: New => Incomplete -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in systemd package in Ubuntu: New Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+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
Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
On Fri, Aug 23, 2019 at 10:00 AM Dan Streetman wrote: > > Dan had put a udevadm settle in this spot like so > > > > def get_size(filename) > >util.subp(['udevadm', 'settle']) > >os.open() > > if you know you've just changed (e.g.) /dev/sda, possibly its kernel- > generated udev events just haven't reached udev yet, so the immediate > call to 'udev settle' has nothing to wait for; maybe you should tell > udev to explicitly request a new full set of events and settle on that? > > udevadm trigger --settle /dev/sda > Possible; though in the case that we don't race, we get to repeat all of the rules. If we can sort out what changes in the kernel/udev expose this race then maybe we can see if there's something that cloud-init/growpart/etc can do. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1834875 > > Title: > cloud-init growpart race with udev > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions > -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in systemd package in Ubuntu: New Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+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
Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
On Fri, Aug 23, 2019 at 10:21 AM Dan Watkins wrote: > Looking at the comment timestamps, Dan probably didn't see my comment, > but to reiterate: all the events we expect to be processed _are_ > processed, the issue is that when they are processed they don't always > end up with the correct partition information. > One bit of info we don't have is a timestamp for when the BLKPG ioctl from partx --update is run. That would confirm the order of things. > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1834875 > > Title: > cloud-init growpart race with udev > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions > -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in systemd package in Ubuntu: New Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+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
Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
On Mon, Aug 26, 2019 at 4:05 AM Tobias Koch <1834...@bugs.launchpad.net> wrote: > > (Odds are that whatever causes it to be recreated later in boot would be > > blocked by cloud-init waiting.) > > But that's not happening. The instance does boot normally, the only > service degraded is cloud-init and there is no significant delay either. > > So conversely, if I put a loop into cloud-init and just waited on the > symlink to appear and if that worked with minimal delay, would that > refute the above? > That's still a workaround for something we don't exactly know why is racing nor why this isn't more widespread. The code in cloud-init and growpart, sgdisk and partx are stable (the code has not changed significantly much in some time). We don't have root cause for the race at this time. When cloud-init invokes growpart the symlink exists, and when growpart returns sometimes it does not. If anything growpart should address the race itself; and at this point, it would have to pickup a workaround as well. Let's at least make sure we understand the actual race before we look further into workarounds. >From what I can see in what growpart is doing, the sgdisk command will clear the partition tables (this involves removing the partition and then re-adding it, which triggers udev. Further, Dan's show that partx --update can also trigger a remove and an add. Looking at the partx update code; *sometimes* it will remove and add, however, if the partition to be updated *exists* then it will instead issue an update IOCTL which only updates the size value in sysfs. https://github.com/karelzak/util- linux/blob/53ae7d60cfeacd4e87bfe6fcc015b58b78ef4555/disk- utils/partx.c#L451 Which makes me think that in the successful path, we're seeing partx --update take the partx_resize_partition path, which submits the resize IOCTL https://github.com/karelzak/util- linux/blob/917f53cf13c36d32c175f80f2074576595830573/include/partx.h#L54 which in linux kernel does: https://elixir.bootlin.com/linux/latest/source/block/ioctl.c#L100 and just updates the size value in sysfs: https://elixir.bootlin.com/linux/latest/source/block/ioctl.c#L146 which AFAICT does not emit any new uevents; Lastly, in either path (partx updates vs partx removes/adds); invoking a udevadm settle after the binary has exited is the reasonable way to ensure that *if* any uevents were created, that they are processed. growpart could add udevadm settle code; so could cloud-init. We actually did that in our first test package and that did not result in ensuring the symlink was present. All of this suggests to me that *something* isn't processing the sequence of uevents in such a way that the once they've all been processed we have the symlink. We must be missing some other bit of information in the failing path where the symlink is eventually recreated (possibly due to some other write or close on the disk on the disk which re-triggers rules). > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1834875 > > Title: > cloud-init growpart race with udev > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions > -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in systemd package in Ubuntu: New Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
I launched a bionic image on serverstack, updated the netplan.io to proposed, modified the network config to set ipv6-mtu to 6000 and rebooted. root@b-test-ipv6-mtu:~# apt-cache policy netplan.io netplan.io: Installed: 0.98-0ubuntu1~18.04.1 Candidate: 0.98-0ubuntu1~18.04.1 Version table: *** 0.98-0ubuntu1~18.04.1 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages 100 /var/lib/dpkg/status 0.97-0ubuntu1~18.04.1 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 0.40.1~18.04.4 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 0.36.1 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main amd64 Packages root@b-test-ipv6-mtu:~# cat /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: fa:16:3e:4d:3c:6a set-name: ens3 ipv6-mtu: 6000 root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.link [Match] MACAddress=fa:16:3e:4d:3c:6a [Link] Name=ens3 WakeOnLan=off root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.network [Match] MACAddress=fa:16:3e:4d:3c:6a Name=ens3 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 IPv6MTUBytes=6000 [DHCP] RouteMetric=100 UseMTU=true ~# cat /sys/class/net/ens3/mtu 8958 ~# sysctl net.ipv6.conf.ens3.mtu net.ipv6.conf.ens3.mtu = 8958 -- 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: Fix Released 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: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
I tested with your single-file approach and that also fails. Note that bionic now has systemd 237, so maybe something is missing (or regressed) ? $ apt-cache policy systemd systemd: Installed: 237-3ubuntu10.26 Candidate: 237-3ubuntu10.26 Version table: *** 237-3ubuntu10.26 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10.25 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 237-3ubuntu10.19 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 237-3ubuntu10 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main amd64 Packages -- 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: Fix Released 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: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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/16719
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
err, on Eoan, I used ipv6-mtu 6000. -- 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: Fix Released 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: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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 1671951] Re: networkd should allow configuring IPV6 MTU
See comment #20; ipv6 mtu is 1280 -> DEVICE_MTU. I'm testing something in the middle now. On Eoan with: network: version: 2 ethernets: ens3: addresses: [10.5.0.16/16] gateway4: 10.5.0.1 dhcp4: false match: macaddress: fa:16:3e:c9:1e:fb mtu: 8958 ipv6-mtu: 8960 set-name: ens3 nameservers: addresses: [10.5.0.2] search: [project.serverstack] It works. Now on bionic-proposed, it does not. Aug 28 16:59:56.659125 b-test-ipv6-mtu systemd-networkd[1149]: /run/systemd/network/10-netplan-ens3.network:11: Unknown lvalue 'IPv6MTUBytes' in section 'Network' So, looks like bionic systemd is missing something. -- 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: Fix Released 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: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [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] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [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 netplan.io = = 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/+so
[Touch-packages] [Bug 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'
This is still around. Scott wrote up a script to handle cleaning this up. https://gist.github.com/smoser/2c78cf54a1e22b6f05270bd3fead8a5c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1779156 Title: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy' Status in linux package in Ubuntu: Triaged Status in lxc package in Ubuntu: Confirmed Status in linux source package in Cosmic: Triaged Status in lxc source package in Cosmic: Confirmed Bug description: I'm not sure exactly what got me into this state, but I have several lxc containers that cannot be deleted. $ lxc info api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls environment: addresses: [] architectures: - x86_64 - i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificate_fingerprint: 3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb driver: lxc driver_version: 3.0.1 kernel: Linux kernel_architecture: x86_64 kernel_version: 4.15.0-23-generic server: lxd server_pid: 15123 server_version: "3.2" storage: zfs storage_version: 0.7.5-1ubuntu15 server_clustered: false server_name: milhouse $ lxc delete --force b1 Error: Failed to destroy ZFS filesystem: cannot destroy 'default/containers/b1': dataset is busy Talking in #lxc-dev, stgraber and sforeshee provided diagnosis: | short version is that something unshared a mount namespace causing | them to get a copy of the mount table at the time that dataset was | mounted, which then prevents zfs from being able to destroy it) The work around provided was | you can unstick this particular issue by doing: | grep default/containers/b1 /proc/*/mountinfo | then for any of the hits, do: | nsenter -t PID -m -- umount /var/snap/lxd/common/lxd/storage-pools/default/containers/b1 | then try the delete again ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.15.0-23-generic 4.15.0-23.25 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: smoser31412 F pulseaudio /dev/snd/controlC2: smoser31412 F pulseaudio /dev/snd/controlC0: smoser31412 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Thu Jun 28 10:42:45 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (1071 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) MachineType: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.174 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2015 dmi.bios.vendor: Intel Corporation dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355 dmi.board.asset.tag: � dmi.board.name: NUC5i5RYB dmi.board.vendor: Intel Corporation dmi.board.version: H40999-503 dmi.chassis.asset.tag: � dmi.chassis.type: 3 dmi.chassis.vendor: � dmi.chassis.version: � dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr: dmi.product.family: � dmi.product.name: � dmi.product.version: � dmi.sys.vendor: � To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779156/+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 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'
https://github.com/lxc/lxd/issues/4656 ** Bug watch added: LXD bug tracker #4656 https://github.com/lxc/lxd/issues/4656 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1779156 Title: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy' Status in linux package in Ubuntu: Triaged Status in lxc package in Ubuntu: Confirmed Status in linux source package in Cosmic: Triaged Status in lxc source package in Cosmic: Confirmed Bug description: I'm not sure exactly what got me into this state, but I have several lxc containers that cannot be deleted. $ lxc info api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls environment: addresses: [] architectures: - x86_64 - i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificate_fingerprint: 3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb driver: lxc driver_version: 3.0.1 kernel: Linux kernel_architecture: x86_64 kernel_version: 4.15.0-23-generic server: lxd server_pid: 15123 server_version: "3.2" storage: zfs storage_version: 0.7.5-1ubuntu15 server_clustered: false server_name: milhouse $ lxc delete --force b1 Error: Failed to destroy ZFS filesystem: cannot destroy 'default/containers/b1': dataset is busy Talking in #lxc-dev, stgraber and sforeshee provided diagnosis: | short version is that something unshared a mount namespace causing | them to get a copy of the mount table at the time that dataset was | mounted, which then prevents zfs from being able to destroy it) The work around provided was | you can unstick this particular issue by doing: | grep default/containers/b1 /proc/*/mountinfo | then for any of the hits, do: | nsenter -t PID -m -- umount /var/snap/lxd/common/lxd/storage-pools/default/containers/b1 | then try the delete again ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.15.0-23-generic 4.15.0-23.25 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: smoser31412 F pulseaudio /dev/snd/controlC2: smoser31412 F pulseaudio /dev/snd/controlC0: smoser31412 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Thu Jun 28 10:42:45 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (1071 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) MachineType: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.174 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2015 dmi.bios.vendor: Intel Corporation dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355 dmi.board.asset.tag: � dmi.board.name: NUC5i5RYB dmi.board.vendor: Intel Corporation dmi.board.version: H40999-503 dmi.chassis.asset.tag: � dmi.chassis.type: 3 dmi.chassis.vendor: � dmi.chassis.version: � dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr: dmi.product.family: � dmi.product.name: � dmi.product.version: � dmi.sys.vendor: � To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779156/+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 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to
** Summary changed: - vmtests: test_ip_output failing in vlan tests on eoan + networkd pads interface MTU by 4 bytes for vlan even when told not to -- 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/1846232 Title: networkd pads interface MTU by 4 bytes for vlan even when told not to Status in curtin: Invalid Status in systemd package in Ubuntu: New Bug description: From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel- amd64/916/console: == FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan) -- Traceback (most recent call last): File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 311, in test_ip_output routes) File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 337, in check_interface int(ipcfg[key])) AssertionError: 1500 != 1504 >> begin captured stdout << - parsed ip_a dict: interface0: broadcast: 10.245.175.255 group: default inet4: - address: 10.245.168.16 prefixlen: '21' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4913 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4913 prefixlen: '64' scope: link valid_lft: forever interface: interface0 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:13 mtu: '1500' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1: broadcast: 10.245.188.255 group: default inet4: - address: 10.245.188.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4915 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1504' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1.2667: broadcast: 10.245.184.255 group: default inet4: - address: 10.245.184.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2667 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2668: broadcast: 10.245.185.255 group: default inet4: - address: 10.245.185.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2668 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2669: broadcast: 10.245.186.255 group: default inet4: - address: 10.245.186.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2669 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2670: broadcast: 10.245.187.255 group: default inet4: - address: 10.245.187.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2670 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false
[Touch-packages] [Bug 1859858] [NEW] udev has truncated ID_SERIAL value for scsi disk
Public bug reported: 1. root@ubuntu:/home/ubuntu# cat /etc/cloud/build.info build_name: server serial: 20200106 root@ubuntu:/home/ubuntu# lsb_release -rd Description:Ubuntu Focal Fossa (development branch) Release:20.04 2. root@ubuntu:/home/ubuntu# apt-cache policy systemd systemd: Installed: 244-3ubuntu1 Candidate: 244-3ubuntu1 Version table: *** 244-3ubuntu1 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. ID_SERIAL value should be 322dc58dc023c7008 4. ID_SERIAL value is 3 -- Launching a qemu VM with the same extra scsi disk like so: -drive file=extra_disk_1.img,id=drv4,if=none,format=raw,index=4,cache=unsafe \ -device scsi-hd,drive=drv4,serial=0x22dc58dc023c7008,wwn=0x22dc58dc023c7008 On Focal udevadm info output: root@ubuntu:/home/ubuntu# udevadm info --query=property /dev/sdc DEVPATH=/devices/pci:00/:00:03.0/virtio0/host2/target2:0:2/2:0:2:0/block/sdc DEVNAME=/dev/sdc DEVTYPE=disk MAJOR=8 MINOR=32 SUBSYSTEM=block USEC_INITIALIZED=1497555 SCSI_TPGS=0 SCSI_TYPE=disk SCSI_VENDOR=QEMU SCSI_VENDOR_ENC=QEMU\x20\x20\x20\x20 SCSI_MODEL=QEMU_HARDDISK SCSI_MODEL_ENC=QEMU\x20HARDDISK\x20\x20\x20 SCSI_REVISION=2.5+ ID_SCSI=1 ID_SCSI_INQUIRY=1 ID_VENDOR=QEMU ID_VENDOR_ENC=QEMU\x20\x20\x20\x20 ID_MODEL=QEMU_HARDDISK ID_MODEL_ENC=QEMU\x20HARDDISK\x20\x20\x20 ID_REVISION=2.5+ ID_TYPE=disk SCSI_IDENT_SERIAL=0x22dc58dc023c7008 SCSI_IDENT_LUN_VENDOR=0x22dc58dc023c7008 SCSI_IDENT_LUN_NAA_EXT=22dc58dc023c7008 ID_WWN=0x22dc58dc023c7008 ID_WWN_WITH_EXTENSION=0x22dc58dc023c7008 ID_BUS=scsi ID_SERIAL=3 ID_SERIAL_SHORT=22dc58dc023c7008 MPATH_SBIN_PATH=/sbin DM_MULTIPATH_DEVICE_PATH=0 ID_PATH=pci-:00:03.0-scsi-0:0:2:0 ID_PATH_TAG=pci-_00_03_0-scsi-0_0_2_0 ID_FS_UUID=b20cf5c1-15ae-48a7-a5d9-dfcfd37df494 ID_FS_UUID_ENC=b20cf5c1-15ae-48a7-a5d9-dfcfd37df494 ID_FS_UUID_SUB=e06d861c-c6e2-497c-b14f-265ae37060e2 ID_FS_UUID_SUB_ENC=e06d861c-c6e2-497c-b14f-265ae37060e2 ID_FS_TYPE=btrfs ID_FS_USAGE=filesystem ID_BTRFS_READY=1 DEVLINKS=/dev/disk/by-id/scsi-3 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_0x22dc58dc023c7008 /dev/disk/by-path/pci-:00:03.0-scsi-0:0:2:0 /dev/disk/by-id/wwn-0x22dc58dc023c7008 /dev/disk/by-id/scsi-SQEMU_QEMU_HARDDISK_0x22dc58dc023c7008 /dev/disk/by-uuid/b20cf5c1-15ae-48a7-a5d9-dfcfd37df494 /dev/disk/by-id/scsi-322dc58dc023c7008 TAGS=:systemd: On Bionic: root@ubuntu:~# cat /etc/cloud/build.info build_name: server serial: 20200112 root@ubuntu:~# lsb_release -rd Description:Ubuntu 18.04.3 LTS Release:18.04 root@ubuntu:~# apt-cache policy systemd systemd: Installed: 237-3ubuntu10.33 Candidate: 237-3ubuntu10.33 Version table: *** 237-3ubuntu10.33 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10.29 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 237-3ubuntu10 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages root@ubuntu:~# udevadm info --query=property /dev/sdc DEVLINKS=/dev/disk/by-uuid/13a8a15f-4f6b-4904-b307-339b825c445b /dev/disk/by-path/pci-:00:03.0-scsi-0:0:2:0 /dev/disk/by-id/wwn-0x22dc58dc023c7008 /dev/disk/by-id/scsi-322dc58dc023c7008 DEVNAME=/dev/sdc DEVPATH=/devices/pci:00/:00:03.0/virtio0/host2/target2:0:2/2:0:2:0/block/sdc DEVTYPE=disk ID_BTRFS_READY=1 ID_BUS=scsi ID_FS_TYPE=btrfs ID_FS_USAGE=filesystem ID_FS_UUID=13a8a15f-4f6b-4904-b307-339b825c445b ID_FS_UUID_ENC=13a8a15f-4f6b-4904-b307-339b825c445b ID_FS_UUID_SUB=81178585-f7c0-429a-b02d-aeb2f245342c ID_FS_UUID_SUB_ENC=81178585-f7c0-429a-b02d-aeb2f245342c ID_MODEL=QEMU_HARDDISK ID_MODEL_ENC=QEMU\x20HARDDISK\x20\x20\x20 ID_PATH=pci-:00:03.0-scsi-0:0:2:0 ID_PATH_TAG=pci-_00_03_0-scsi-0_0_2_0 ID_REVISION=2.5+ ID_SCSI=1 ID_SCSI_SERIAL=0x22dc58dc023c7008 ID_SERIAL=322dc58dc023c7008 ID_SERIAL_SHORT=22dc58dc023c7008 ID_TYPE=disk ID_VENDOR=QEMU ID_VENDOR_ENC=QEMU\x20\x20\x20\x20 ID_WWN=0x22dc58dc023c7008 ID_WWN_WITH_EXTENSION=0x22dc58dc023c7008 MAJOR=8 MINOR=32 SUBSYSTEM=block TAGS=:systemd: USEC_INITIALIZED=2069797 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 244-3ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-24.26-lowlatency 5.3.10 Uname: Linux 5.3.0-24-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu15 Architecture: amd64 Date: Wed Jan 15 18:17:35 2020 Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: root=squash:http://10.245.168.20:41815/root/squashfs ds=nocloud-net;seedfrom=http://10.245.168.20:41815/ console=ttyS0 overlayroot=tmpfs ro --- systemd.mask=snapd.seeded.service systemd.mask=snapd.service ip=:BOOTIF:dhcp BOOTIF=01-52-54-00-12-34-0
[Touch-packages] [Bug 1859858] Re: udev has truncated ID_SERIAL value for scsi disk
** Tags added: rls-ff-incoming -- 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/1859858 Title: udev has truncated ID_SERIAL value for scsi disk Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Bug description: 1. root@ubuntu:/home/ubuntu# cat /etc/cloud/build.info build_name: server serial: 20200106 root@ubuntu:/home/ubuntu# lsb_release -rd Description:Ubuntu Focal Fossa (development branch) Release:20.04 2. root@ubuntu:/home/ubuntu# apt-cache policy systemd systemd: Installed: 244-3ubuntu1 Candidate: 244-3ubuntu1 Version table: *** 244-3ubuntu1 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. ID_SERIAL value should be 322dc58dc023c7008 4. ID_SERIAL value is 3 -- Launching a qemu VM with the same extra scsi disk like so: -drive file=extra_disk_1.img,id=drv4,if=none,format=raw,index=4,cache=unsafe \ -device scsi-hd,drive=drv4,serial=0x22dc58dc023c7008,wwn=0x22dc58dc023c7008 On Focal udevadm info output: root@ubuntu:/home/ubuntu# udevadm info --query=property /dev/sdc DEVPATH=/devices/pci:00/:00:03.0/virtio0/host2/target2:0:2/2:0:2:0/block/sdc DEVNAME=/dev/sdc DEVTYPE=disk MAJOR=8 MINOR=32 SUBSYSTEM=block USEC_INITIALIZED=1497555 SCSI_TPGS=0 SCSI_TYPE=disk SCSI_VENDOR=QEMU SCSI_VENDOR_ENC=QEMU\x20\x20\x20\x20 SCSI_MODEL=QEMU_HARDDISK SCSI_MODEL_ENC=QEMU\x20HARDDISK\x20\x20\x20 SCSI_REVISION=2.5+ ID_SCSI=1 ID_SCSI_INQUIRY=1 ID_VENDOR=QEMU ID_VENDOR_ENC=QEMU\x20\x20\x20\x20 ID_MODEL=QEMU_HARDDISK ID_MODEL_ENC=QEMU\x20HARDDISK\x20\x20\x20 ID_REVISION=2.5+ ID_TYPE=disk SCSI_IDENT_SERIAL=0x22dc58dc023c7008 SCSI_IDENT_LUN_VENDOR=0x22dc58dc023c7008 SCSI_IDENT_LUN_NAA_EXT=22dc58dc023c7008 ID_WWN=0x22dc58dc023c7008 ID_WWN_WITH_EXTENSION=0x22dc58dc023c7008 ID_BUS=scsi ID_SERIAL=3 ID_SERIAL_SHORT=22dc58dc023c7008 MPATH_SBIN_PATH=/sbin DM_MULTIPATH_DEVICE_PATH=0 ID_PATH=pci-:00:03.0-scsi-0:0:2:0 ID_PATH_TAG=pci-_00_03_0-scsi-0_0_2_0 ID_FS_UUID=b20cf5c1-15ae-48a7-a5d9-dfcfd37df494 ID_FS_UUID_ENC=b20cf5c1-15ae-48a7-a5d9-dfcfd37df494 ID_FS_UUID_SUB=e06d861c-c6e2-497c-b14f-265ae37060e2 ID_FS_UUID_SUB_ENC=e06d861c-c6e2-497c-b14f-265ae37060e2 ID_FS_TYPE=btrfs ID_FS_USAGE=filesystem ID_BTRFS_READY=1 DEVLINKS=/dev/disk/by-id/scsi-3 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_0x22dc58dc023c7008 /dev/disk/by-path/pci-:00:03.0-scsi-0:0:2:0 /dev/disk/by-id/wwn-0x22dc58dc023c7008 /dev/disk/by-id/scsi-SQEMU_QEMU_HARDDISK_0x22dc58dc023c7008 /dev/disk/by-uuid/b20cf5c1-15ae-48a7-a5d9-dfcfd37df494 /dev/disk/by-id/scsi-322dc58dc023c7008 TAGS=:systemd: On Bionic: root@ubuntu:~# cat /etc/cloud/build.info build_name: server serial: 20200112 root@ubuntu:~# lsb_release -rd Description:Ubuntu 18.04.3 LTS Release:18.04 root@ubuntu:~# apt-cache policy systemd systemd: Installed: 237-3ubuntu10.33 Candidate: 237-3ubuntu10.33 Version table: *** 237-3ubuntu10.33 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10.29 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 237-3ubuntu10 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages root@ubuntu:~# udevadm info --query=property /dev/sdc DEVLINKS=/dev/disk/by-uuid/13a8a15f-4f6b-4904-b307-339b825c445b /dev/disk/by-path/pci-:00:03.0-scsi-0:0:2:0 /dev/disk/by-id/wwn-0x22dc58dc023c7008 /dev/disk/by-id/scsi-322dc58dc023c7008 DEVNAME=/dev/sdc DEVPATH=/devices/pci:00/:00:03.0/virtio0/host2/target2:0:2/2:0:2:0/block/sdc DEVTYPE=disk ID_BTRFS_READY=1 ID_BUS=scsi ID_FS_TYPE=btrfs ID_FS_USAGE=filesystem ID_FS_UUID=13a8a15f-4f6b-4904-b307-339b825c445b ID_FS_UUID_ENC=13a8a15f-4f6b-4904-b307-339b825c445b ID_FS_UUID_SUB=81178585-f7c0-429a-b02d-aeb2f245342c ID_FS_UUID_SUB_ENC=81178585-f7c0-429a-b02d-aeb2f245342c ID_MODEL=QEMU_HARDDISK ID_MODEL_ENC=QEMU\x20HARDDISK\x20\x20\x20 ID_PATH=pci-:00:03.0-scsi-0:0:2:0 ID_PATH_TAG=pci-_00_03_0-scsi-0_0_2_0 ID_REVISION=2.5+ ID_SCSI=1 ID_SCSI_SERIAL=0x22dc58dc023c7008 ID_SERIAL=322dc58dc023c7008 ID_SERIAL_SHORT=22dc58dc023c7008 ID_TYPE=disk ID_VENDOR=QEMU ID_VENDOR_ENC=QEMU\x20\x20\x20\x20 ID_WWN=0x22dc58dc023c7008 ID_WWN_WITH_EXTENSION=0x22dc58dc023c7008 MAJOR=8 MINOR=32 SUBSYSTEM=block TAGS=:systemd: USEC_INITIALIZED=2069797 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 244-3ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-24.26-lowlatency 5.3.10 Uname: Linux 5.3.0-24-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVers
[Touch-packages] [Bug 1765173] Re: networkd waits 10 seconds for ipv6 network discovery by default
I disagree that SLAAC is something that we should by default block reaching network-online.target. In general we cannot know in advance whether or not another system in the same subnet is providing Router Advertisements to other instances. If one instance in my VPC is running radvd, ec2 has no knowledge of this meaning that if cloud-init sets accept-ra: false; that disables accepting RAs and that breaks this use-case; this is similar for LXD as well. Additionally, accept-ra:false doesn't mean networkd doesn't handle RA, it also disables accept-ra in the kernel as well; I believe that *IF* you are running an instance where you expect to use SLAAC and know that you won't use other means of network configuration then that instance should set some sort of flag to indicate that you want network-online.target to wait for a SLAAC response. No matter how forward looking we want to be; it doesn't make sense to punish the majority of boots today with a 10 second timeout. -- 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/1765173 Title: networkd waits 10 seconds for ipv6 network discovery by default Status in cloud-init package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: Confirmed Bug description: 1. $ lsb_release -rd Description: Ubuntu Bionic Beaver (development branch) Release: 18.04 2. $ apt-cache policy systemd systemd: Installed: 237-3ubuntu8 Candidate: 237-3ubuntu8 Version table: *** 237-3ubuntu8 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status 3. systemd-networkd-wait-online doesn't block for 10 seconds waiting on an IPV6 Router Advertisement 4. systemd-networkd sends at least two RA solicitation packets waiting for a response before setting the link to configured. This blocks the boot for every Ubuntu system where it does not have a IPV6 router responding to solicitations. THis includes bionic containers, cloud instances, vms and physical machines. -- We can see that we're spending 13 seconds waiting for networkd to say the network is up. % systemd-analyze blame 13.326s systemd-networkd-wait-online.service 999ms cloud-init-local.service 954ms cloud-init.service 887ms cloud-config.service 749ms dev-vda1.device 666ms cloud-final.service 248ms keyboard-setup.service 175ms systemd-udev-trigger.service 171ms lxd-containers.service 165ms snapd.service 154ms apparmor.service 147ms ssh.service 144ms systemd-timesyncd.service 133ms grub-common.service 130ms systemd-journald.service 130ms accounts-daemon.service 99ms systemd-modules-load.service 98ms systemd-resolved.service 94ms apport.service 92ms rsyslog.service 88ms systemd-logind.service 80ms lvm2-monitor.service 75ms iscsid.service 64ms ebtables.service 62ms user@1000.service 54ms dev-mqueue.mount 53ms ufw.service 52ms systemd-remount-fs.service 52ms kmod-static-nodes.service 34ms systemd-journal-flush.service 34ms polkit.service 32ms systemd-tmpfiles-setup-dev.service 27ms systemd-udevd.service 26ms systemd-networkd.service 26ms systemd-sysctl.service 25ms systemd-tmpfiles-setup.service 21ms dev-hugepages.mount 17ms sys-kernel-debug.mount 16ms console-setup.service 15ms plymouth-read-write.service 15ms snapd.socket 15ms plymouth-quit.service 14ms systemd-update-utmp.service 10ms systemd-user-sessions.service 9ms boot-efi.mount 8ms sys-fs-fuse-connections.mount 8ms systemd-update-utmp-runlevel.service 8ms lxd.socket 7ms blk-availability.service 5ms systemd-random-seed.service 3ms setvtrgb.service 3ms plymouth-quit-wait.service 3ms sys-kernel-config.mount Here we can see that we start networking at 18:30:51.69, and then IPv6 NDISC runs for 10 seconds and then the link is configured at 18:31:05. *AND* we see NDISC stays around and continues to see if it gets a RA packet. $ journalctl -o short-precise -u systemd-networkd.service | egrep "(Starting Network|Discovering IPv6 routers|NDISC|Configured)" Apr 18 18:30:51.691532 rharper-b1 systemd[1]: Starting Network Service... Apr 18 18:30:53.031041 rharper-b1 sys
[Touch-packages] [Bug 1765173] Re: networkd waits 10 seconds for ipv6 network discovery by default
I don't think not blocking for RAs during boot as a decision that prefers ipv4 over ipv6. networkd is just doing something else by default that the kernel doesn't do today, or historically; *and* there is no toggle for the blocking; only do you want RAs or not *and* if you say you don't want RAs it disables them in the kernel too. That's just not very flexible and breaks at least one known use-case w.r.t radvd use. W.r.t the the online-target; what you describe sounds complete. I think it's worth mentioning that this state can be reached by combining different interfaces; one may have a default route, a second has DNS, and a third has an address. -- 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/1765173 Title: networkd waits 10 seconds for ipv6 network discovery by default Status in cloud-init package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: Confirmed Bug description: 1. $ lsb_release -rd Description: Ubuntu Bionic Beaver (development branch) Release: 18.04 2. $ apt-cache policy systemd systemd: Installed: 237-3ubuntu8 Candidate: 237-3ubuntu8 Version table: *** 237-3ubuntu8 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status 3. systemd-networkd-wait-online doesn't block for 10 seconds waiting on an IPV6 Router Advertisement 4. systemd-networkd sends at least two RA solicitation packets waiting for a response before setting the link to configured. This blocks the boot for every Ubuntu system where it does not have a IPV6 router responding to solicitations. THis includes bionic containers, cloud instances, vms and physical machines. -- We can see that we're spending 13 seconds waiting for networkd to say the network is up. % systemd-analyze blame 13.326s systemd-networkd-wait-online.service 999ms cloud-init-local.service 954ms cloud-init.service 887ms cloud-config.service 749ms dev-vda1.device 666ms cloud-final.service 248ms keyboard-setup.service 175ms systemd-udev-trigger.service 171ms lxd-containers.service 165ms snapd.service 154ms apparmor.service 147ms ssh.service 144ms systemd-timesyncd.service 133ms grub-common.service 130ms systemd-journald.service 130ms accounts-daemon.service 99ms systemd-modules-load.service 98ms systemd-resolved.service 94ms apport.service 92ms rsyslog.service 88ms systemd-logind.service 80ms lvm2-monitor.service 75ms iscsid.service 64ms ebtables.service 62ms user@1000.service 54ms dev-mqueue.mount 53ms ufw.service 52ms systemd-remount-fs.service 52ms kmod-static-nodes.service 34ms systemd-journal-flush.service 34ms polkit.service 32ms systemd-tmpfiles-setup-dev.service 27ms systemd-udevd.service 26ms systemd-networkd.service 26ms systemd-sysctl.service 25ms systemd-tmpfiles-setup.service 21ms dev-hugepages.mount 17ms sys-kernel-debug.mount 16ms console-setup.service 15ms plymouth-read-write.service 15ms snapd.socket 15ms plymouth-quit.service 14ms systemd-update-utmp.service 10ms systemd-user-sessions.service 9ms boot-efi.mount 8ms sys-fs-fuse-connections.mount 8ms systemd-update-utmp-runlevel.service 8ms lxd.socket 7ms blk-availability.service 5ms systemd-random-seed.service 3ms setvtrgb.service 3ms plymouth-quit-wait.service 3ms sys-kernel-config.mount Here we can see that we start networking at 18:30:51.69, and then IPv6 NDISC runs for 10 seconds and then the link is configured at 18:31:05. *AND* we see NDISC stays around and continues to see if it gets a RA packet. $ journalctl -o short-precise -u systemd-networkd.service | egrep "(Starting Network|Discovering IPv6 routers|NDISC|Configured)" Apr 18 18:30:51.691532 rharper-b1 systemd[1]: Starting Network Service... Apr 18 18:30:53.031041 rharper-b1 systemd-networkd[603]: ens3: Discovering IPv6 routers Apr 18 18:30:53.031306 rharper-b1 systemd-networkd[603]: NDISC: Started IPv6 Router Solicitation client Apr 18 18:30:53.031612 rharper-b1 systemd-networkd[603]: NDISC: Sent Router Solicitation, next solicitation in 4s Apr 18 18:30:57.092282 rharper-b1 systemd-networkd
[Touch-packages] [Bug 1765173] Re: networkd waits 10 seconds for ipv6 network discovery by default
I've given this a test in LXD on my system which triggers the RA stall; after upgrading it does not wait for an RA before marking the interface configured and also confirmed that it does not regress the case where there are existing RA's on the network; those are still received. Note that we see eth0: Configured before the Discovering IPv6 routers, and Received Router Advertisement. Apr 20 20:55:21.062761 b1 systemd[1]: Started Network Service. Apr 20 20:55:21.904103 b1 systemd-networkd[163]: eth0: Configured Apr 20 20:55:21.904190 b1 systemd-networkd[163]: eth0: Discovering IPv6 routers Apr 20 20:55:21.904252 b1 systemd-networkd[163]: NDISC: Started IPv6 Router Solicitation client Apr 20 20:55:21.904632 b1 systemd-networkd[163]: NDISC: Sent Router Solicitation, next solicitation in 3s Apr 20 20:55:21.906538 b1 systemd-networkd[163]: NDISC: Received Router Advertisement: flags none preference medium lifetime 30 sec root@b1:~# networkctl status ●State: routable Address: 10.8.107.88 on eth0 2001:db8:100:f101:216:3eff:fe5f:d776 on eth0 fe80::216:3eff:fe5f:d776 on eth0 Gateway: 10.8.107.1 on eth0 fe80::216:3eff:fe31:e211 (Xensource, Inc.) on eth0 DNS: 10.8.107.1 Search Domains: lxd -- 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/1765173 Title: networkd waits 10 seconds for ipv6 network discovery by default Status in cloud-init package in Ubuntu: Fix Released Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Committed Bug description: [Impact] * On ipv6 less hosts, boot stalls for 10s * This is due to implicit RA being on, and wait-online awaiting for RA to timeout * Expectation is, that since explicit request for RA was not done, it should not block network-online.target, whilst all other aspects of network-online.target should be honored. [Test Case] * lxc network set lxdbr0 ipv6.address none * lxc launch ubuntu-daily:bionic lp1765173 * sleep 20 && lxc exec lp1765173 systemd-analyze blame | head Bad result is: 12.157s systemd-networkd-wait-online.service Good result is: 739ms systemd-networkd-wait-online.service [Regression Potential] * If explicit IPv6 dhcp/ra was enabled in .network file, the boot will be blocked awaiting RA response * Only kernel implicit RA configuration will now become "async" * This is inline with behaviour of xenial systems [Other Info] * Original bug report 1. $ lsb_release -rd Description: Ubuntu Bionic Beaver (development branch) Release: 18.04 2. $ apt-cache policy systemd systemd: Installed: 237-3ubuntu8 Candidate: 237-3ubuntu8 Version table: *** 237-3ubuntu8 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status 3. systemd-networkd-wait-online doesn't block for 10 seconds waiting on an IPV6 Router Advertisement 4. systemd-networkd sends at least two RA solicitation packets waiting for a response before setting the link to configured. This blocks the boot for every Ubuntu system where it does not have a IPV6 router responding to solicitations. THis includes bionic containers, cloud instances, vms and physical machines. -- We can see that we're spending 13 seconds waiting for networkd to say the network is up. % systemd-analyze blame 13.326s systemd-networkd-wait-online.service 999ms cloud-init-local.service 954ms cloud-init.service 887ms cloud-config.service 749ms dev-vda1.device 666ms cloud-final.service 248ms keyboard-setup.service 175ms systemd-udev-trigger.service 171ms lxd-containers.service 165ms snapd.service 154ms apparmor.service 147ms ssh.service 144ms systemd-timesyncd.service 133ms grub-common.service 130ms systemd-journald.service 130ms accounts-daemon.service 99ms systemd-modules-load.service 98ms systemd-resolved.service 94ms apport.service 92ms rsyslog.service 88ms systemd-logind.service 80ms lvm2-monitor.service 75ms iscsid.service 64ms ebtables.service 62ms user@1000.service 54ms dev-mqueue.mount 53ms ufw.service 52ms systemd-remount-fs.service 52ms kmod-static-nodes.service 34ms systemd-journal-flush.service 34ms polkit.service 32ms systemd-tmpfiles-setup-dev.service 27ms systemd-udevd.service 26ms systemd-networkd.service 26ms systemd-
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Are you providing network config to cloud-init? Otherwise, cloud-init
is going to generate a fallback network config like your original, dhcp
on one of the interfaces.
If you want to persist network changes, you need to add them to a
separate netplan yaml config, or provide an updated network-config to
cloud-init; otherwise it's going to regenerate the same configuration
which will clobber a local 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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm
still trying to hunt down.
This breaks some forms of migration in certain cloud environments.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
On Wed, May 9, 2018 at 9:13 AM, Daniel Axtens
wrote:
> Ryan: I removed /etc/netplan/50-cloud-init.yaml and rebooted repeatedly and
> I've never seen it regenerated.
Ah, right, it doesn't regenerate unless you change instance-ids.
>
> I also don't see anything in /run/netplan or /run/systemd/network that has
> been autogenerated.
>
> I haven't touched anything else generated by cloud-init. When would
> cloud-init regenerate a network config file?
Nothing, you're right. You can make a local change and reboot but typically
for cloud instances you'd want to have it set during the first boot.
So your scenario is:
1) deploy instance
2) log in and modify /etc/netplan/50-cloud-init.yaml to add a set-name:
3) reboot?
And the result is that you don't see a name change?
Yes, I think this is the udev scenario where it won't change a device
name whose 'name_assign_type' is either 3 or 4;
The driver unplug code in netplan is designed to workaround this
design issue with udev itself.
Can you confirm the driver for the interface you're renaming? ethtool
-i
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm
still trying to hunt down.
This breaks some forms of migrat
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Investigating, it appears that the interfaces are getting renamed by
udev in the initramfs, which pushes their name_assign_type value to 4,
and udev refuses to rename an interface if the name_assign_type value is
4.
So, I can make this scenario work if I do:
4. sudo update-initramfs -u
5. reboot
After rebooting, the interface is correct.
I'll add a systemd task here in case we want to poke at allowing renames
even if assign-type is 4.
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm
still trying to hunt down.
This breaks some forms of migration in certain cloud environments.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
On Fri, May 11, 2018 at 3:25 AM, Daniel Axtens
wrote:
> Ryan, I can't get that to work on my systems. What is it that update-
> initramfs is supposed to change? I don't see any files in my initramfs
> that are generated or read by netplan. Neither do I see netplan itself
> in the initramfs!
The .link files end up getting pulled into the initramfs, where
systemd-udev will run and apply the
names there. When systemd-udev does a rename, the kernel marks an
interface 'name_assign_type' to a value of 4
and systemd-udev will refuse to further rename a device, despite
having a rule (.link file) to do so.
Netplan works around this in 'apply' by unplugging the driver, which
resets the state of the 'name_assign_type' value
in the kernel.
>
> Mathieu, I thought netplan was supposed to be initramfs friendly by
> virtue of being in C. Is it supposed to be in the initramfs?
The generator is, the cli is not.
>
> For both of you, how are you getting through initrd without your device
> being given a generic udev name (like ens3 or enp1s0)? On both my
> physical and virtual machines, my various network cards all get renamed
> in initrd, well before netplan is run.
We're not; udev runs in the initramfs and triggers renames there.
>
> [PS. I know the scenario as described sounds far-fetched - the original
> way this came up was a cloud setup where you can change the type of a
> network interface but keep the same MAC. The different type leads to a
> different udev name, which is what revealed that set-name: wasn't taking
> effect.]
Cloud scenarios are slightly different when cloud-init is involved;
Cloud-init itself will handle device renames if
they are needed. Typically cloud-init just re-uses the name the
interface got from udev when it renders it's netplan config during
boot.
For non-cloud scenarios (or if you attempt to use set-name in a cloud
instances without launching a new instance) we're seeing this
situation where we are creating new .link files but they need to be
present in the initramfs otherwise when udevd runs, it will set the
name
to the predictable name and then ignore any of the .link files on the rootfs.
This really needs fixing in udev; I don't think there's a good reason
to have udev refuse to rename an interface.
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
I'm just verifying that on my end; note that the 99-default.link is
going to be sufficient to trigger a rename from eth0 to ens3; which
then prevents any rename once we mount root.
Here's the trigger:
% /usr/share/initramfs-tools/hooks/udev
# copy .link files containing interface naming definitions
mkdir -p $DESTDIR/lib/systemd/network/
find /lib/systemd/network -name '*.link' -execdir cp -pt
$DESTDIR/lib/systemd/network/ '{}' +
if [ -d /etc/systemd/network ]; then
find /etc/systemd/network -name '*.link' -execdir cp -pt
$DESTDIR/lib/systemd/network/ '{}' +
fi
If you create a .link file in /etc/systemd/network/ lower than 99-*
then those link rules will apply first.
On Fri, May 11, 2018 at 9:24 AM, Daniel Axtens
wrote:
> Ok, so the bit I'm stuck on is how the link files and the netplan
> generator are getting pulled into the initramfs then.
>
> ubuntu@btest:~$ sudo update-initramfs -u
> update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic
>
> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \\.link
> lib/systemd/network/99-default.link
> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep netplan
> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep generate
> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep
> system-generators
>
> As you can see there's no generator and no link files in my initramfs -
> by what mechanism is it supposed to work? What package/script/tool is
> supposed to pull the link files in?
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
root@rharper-b1:~# vi /etc/netplan/50-cloud-init.yaml
# changed the set-name: to eth_lan
root@rharper-b1:~# netplan generate
root@rharper-b1:~# cp /run/systemd/network/10-netplan-ens3.link
/etc/systemd/network/
# just the default link file in the initramfs
root@rharper-b1:~# lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \.link
lib/systemd/network/99-default.link
lib/modules/4.15.0-20-generic/kernel/net/core/devlink.ko
lib/udev/rules.d/80-net-setup-link.rules
bin/readlink
root@rharper-b1:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic
# now we see the local .link file from /etc copied in.
root@rharper-b1:~# lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \.link
lib/modules/4.15.0-20-generic/kernel/net/core/devlink.ko
lib/systemd/network/99-default.link
lib/systemd/network/10-netplan-ens3.link
lib/udev/rules.d/80-net-setup-link.rules
bin/readlink
On Fri, May 11, 2018 at 9:35 AM, Ryan Harper wrote:
> I'm just verifying that on my end; note that the 99-default.link is
> going to be sufficient to trigger a rename from eth0 to ens3; which
> then prevents any rename once we mount root.
>
> Here's the trigger:
>
> % /usr/share/initramfs-tools/hooks/udev
> # copy .link files containing interface naming definitions
> mkdir -p $DESTDIR/lib/systemd/network/
> find /lib/systemd/network -name '*.link' -execdir cp -pt
> $DESTDIR/lib/systemd/network/ '{}' +
> if [ -d /etc/systemd/network ]; then
> find /etc/systemd/network -name '*.link' -execdir cp -pt
> $DESTDIR/lib/systemd/network/ '{}' +
> fi
>
> If you create a .link file in /etc/systemd/network/ lower than 99-*
> then those link rules will apply first.
>
>
> On Fri, May 11, 2018 at 9:24 AM, Daniel Axtens
> wrote:
>> Ok, so the bit I'm stuck on is how the link files and the netplan
>> generator are getting pulled into the initramfs then.
>>
>> ubuntu@btest:~$ sudo update-initramfs -u
>> update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic
>>
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \\.link
>> lib/systemd/network/99-default.link
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep netplan
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep
>> generate
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep
>> system-generators
>>
>> As you can see there's no generator and no link files in my initramfs -
>> by what mechanism is it supposed to work? What package/script/tool is
>> supposed to pull the link files in?
>>
>> --
>> You received this bug notification because you are subscribed to
>> netplan.
>> Matching subscriptions: netplan
>> https://bugs.launchpad.net/bugs/1770082
>>
>> Title:
>> systemd-networkd not renaming devices on boot
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
On Fri, May 11, 2018 at 10:18 AM, Daniel Axtens
wrote:
> Right. Yes, I can replicate that, thanks heaps!
Great!
>
> So to summarise, you can make the rename take effect on boot if you:
> 1) copy the files from /run/systemd/network -> /etc/systemd/network
> 2) then update-initramfs -u
>
> This seems pretty far outside of the way that netplan is supposed to work -
> indeed using /etc/systemd/ is basically bypassing netplan. So we still have
> the issue that just changing 'set-name' in /etc/netplan/*.yaml doesn't work
> as expected. What should we change so that set-name works as expected?
>
> I see a few options:
>
> 0) Document that set-name is fragile and stop relying on it. This is
> actually really easy to do and I have a netplan patch drafted already. The
> reason that we have no network connectivity when set-name fails is that the
> network file netplan creates maches on *both* the new name and the mac
> address. We can just drop the new name from the [Match] section of the
> relevant .network file and match only on the provided mac address (or
> whatever else was used in the netplan match stanza). This means that
> regardless of the interface name it's brought up and networking works.
IIUC, we want to stop include the Name= value in the .network config since the
name is flaky; we may want to hold off on that as I think we want the naming to
be solid. You've outlined at least one way below. We should make
set-name reliable
and we can do that, even within netplan itself.
>
> 1) Make the initramfs hook for udev copy the files from /run (as well as
> from /lib and /etc) into the initial ramdisk. This is probably my
> preference; we can run netplan generate beforehand to make sure we get a
> clean copy, and then document that update-initramfs is required to get
> stuff to stick.
Yes, I think that's also reasonable, it's a new location where .link
files may be present.
>
> 2) Allow udev to re-rename interfaces. I don't know if this would be
> acceptable to systemd upstream?
>
> 3) Something else?
Netplan can do what cloud-init does and check that if the current name
of an interface doesn't match
the set-name value, to ip link set name on it.
>
> Regards,
> Daniel
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Can you provide the journalctl -b output for the boot that does this
rename? Is the reproduce the same, can you provide your steps and
I'll replicate.
Xenial does not enable netplan by default so we have a different path
there at least.
On Mon, May 14, 2018 at 9:58 PM, Daniel Axtens
wrote:
> This is not a full solution. In Xenial this renaming works even if
> initramfs has *not* been updated and there is no 70-persistent-net.rules
> file in the initial ramdisk. I'm still figuring out why this is, but it
> means that even if my patch were applied, there would be a regression in
> bionic vs xenial.
>
> Here's a snippet from dmesg showing the same device being renamed twice,
> this is a xenial guest. It shows the device going from the kernel name
> (eth0) to the udev slot based name (ens16), to the name specified in the
> udev rules file that is *not* present in initrd.
>
> ubuntu@xt2:~$ dmesg|grep renamed
> [2.428015] virtio_net virtio3 ens16: renamed from eth0
> [5.317990] virtio_net virtio3 ens3: renamed from ens16
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm
still trying to hunt down.
This breaks some forms of migration in certain cloud environ
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Note, that uvt-kvm is going to use cloud-init; how are you making
sure that cloud-init isn't doing the rename itself?
Xenial by default doesn't use netplan; it still uses eni; the network
configuration generation in cloud-init using eni
does create a 70-persistent-net.rules file that handles renames on
subsequent reboots; in a netplan world (bionic)
the .link file is meant to be the equivalent of a .rules file.
I've not attempted to determine if systemd-udev in bionic would
respect renames from .rules file; it certainly seems
odd to have .rules files allow renames independent of name_assign_type
value where .link files do.
On Tue, May 15, 2018 at 12:29 PM, Daniel Axtens
wrote:
> Hi Ryan,
>
> [Journal Output]
> Attached.
>
> [Reproducer]
> uvt-kvm create xenial-test release=xenial arch=amd64
> virsh edit xenial-test # change network interface pci slot: s/0x03/0x10/
> virsh destroy xenial-test
> virsh start xenial-test
> uvt-kvm ssh xenial-test
> dmesg|grep rename
> [2.790623] virtio_net virtio3 ens16: renamed from eth0
> [6.048520] virtio_net virtio3 ens3: renamed from ens16
>
> [Analysis]
> I've been working on this a lot, and I think I have the cause of the
> difference.
>
> In udev-events.c, udev_execute_rules will _forcibly_ rename a device
> with via a netlink message if there is a matching rule that sets a name.
> Under Xenial, there *is* a matching rule, in 70-persistent-net.rules, so
> this forces a rename. This rename will occur even if the device already
> has a name, and therefore even if the rules file isn't in the initramfs.
>
> Under Bionic, this rules file doesn't exist, there is a .link file
> instead. Unfortunately, a name in a .link file will only take effect if
> the device hasn't been renamed - because of the renaming in initrd, this
> means that a link file that is not present in the initrd will never be
> able to cause a rename.
>
> [Solutions]
> There are a couple of ways we could fix this that come to mind:
>
> - make netplan generate a file in /run/udev/rules.d for each device
> - make systemd rename devices from a link file even if they've been renamed
>
> My preference is the first, but I'm open to anything we can get
> upstream.
>
> Thanks again.
>
> Regards,
> Daniel
>
> ** Attachment added: "journalctl -b output on Xenial VM with multiple renames"
>
> https://bugs.launchpad.net/netplan/+bug/1770082/+attachment/5139894/+files/journalctl-b.txt
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
New
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UN
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
We really only want to be allowed to rename interfaces that have requested it.
This means other interfaces which do not have a set-name directive
will have the kernel name.
On Thu, May 24, 2018 at 6:56 AM, Mike Jonkmans
<1770...@bugs.launchpad.net> wrote:
> Things seem to work when i change the NamePolicy in the initrd file
> /lib/systemd/network/99-default.link to
> `NamePolicy=kernel`
>
> Leaving out the other NamePolicy-options, prevents renaming in the initrd
> fase.
> Which allows later renames from .link files/netplan.
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
Confirmed
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm
still trying to hunt down.
This breaks some forms of migration in certain cloud environments.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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 1770082] Re: systemd-networkd not renaming devices on boot
That's not the final conclusion; the issue is still being discussed
upstream; in particular as to why only the interface name cannot be
modified at runtime by .link files.
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Incomplete
Status in systemd package in Ubuntu:
Confirmed
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm
still trying to hunt down.
This breaks some forms of migration in certain cloud environments.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
On Fri, May 25, 2018 at 8:48 AM, Mathieu Trudel-Lapierre
wrote:
> My recommended course of action for cosmic:
>
> - drop udevadm (net_setup_link) call from cloud-init
This will still be needed in the case that we have a network config with names.
Cloud-init runs after udev coldplug, so any .link files would have to already be
present. We're generating a network config post coldplug, but pre networking.
Now, if after we netplan generate, if links could be applied or if
networkd kicks udev
to rename interfaces, that's fine. But it doesn't do that today.
> - drop set-name "renaming" from cloud-init / maas
I've already replied, but this is required for instances where udev
doesn't run but
network config has been provided.
> - drop replug code in netplan; replace with proper .link code,
possibly call to net_setup_link.
+1
> - maybe write udev rule for renaming in netplan (think belt and
suspenders)
? Instead of the .link files?
> - make sure .link files are written correctly by netplan for renaming
> - patch systemd to not second-guess renaming from .link files
+1
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Confirmed
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priorit
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
On Fri, May 25, 2018 at 9:09 AM, Mathieu Trudel-Lapierre
wrote:
> I'm not completely sure where the code lives in cloud-init; it looks a
> bit like what's in:
>
> cloudinit/net/netplan.py
>
> But the code does read as though it should not be running 'udevadm test-
> builtin net_setup_link'. However, deploying a system with MAAS shows a
> /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg file, which contains
> data referring to the network interfaces:
>
> network:
> config:
> - id: ens6
> mac_address: 52:54:00:31:27:2c
> mtu: 1500
> name: ens6
> subnets:
> - address: 10.3.99.13/24
> gateway: 10.3.99.1
> type: static
> type: physical
> version: 1
>
> With that file in place, any netplan config renaming the interface to
> something other than ens6 will see the interface being renamed *again*
> back to ens6, when that file is removed, this behavior does not appear.
Cloud-init only renders network config once per-instance. If a user
wanted to modify this to something else (and we fix udev to handle
.link file name changes) then there won't be any additional renames.
Even without the change, cloud-init isn't going to call udevadm test-builtin
more than once per-instance.
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Confirmed
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever p
Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
"This is why I added
cloud-init to affected packages -- cloud-init should not be second-
guessing the network layer and attempting to do renames / to run"
There is no second guessing. In the case where we have no network
config, there is no renaming; we accept whatever name is given.
If the config passed to cloud-init includes a name for an interface, then
cloud-init applies that name; this is the MAAS scenario;
Given the unreliable nature of udev w.r.t naming (see this very bug)
The *only* way for cloud-init to ensure that a directive to name an interface
matches the config (also note cloud-init accepts network config in
various formats
not just netplan) is to handle naming if requested directly, precisely
due to this bug.
If we fix systemd-udevd to allow renames of interfaces reliably that helps
most cases where udevd runs. For the remaining cases where udev doesn't run,
containers for example, cloud-init will still need to use iproute2 to
set an interface
name if requested.
On Fri, May 25, 2018 at 8:55 AM, Mathieu Trudel-Lapierre
wrote:
> netplan changes are available in git:
>
> Daniel's patch to write udev rules (SRU material):
> https://github.com/CanonicalLtd/netplan/commit/b0c51bfa8ba8b898a9feaed9cd7d8790d147d35d
>
> Daniel's patch + dropping replug code + rework 'netplan apply' (code for
> cosmic); in progress for upload to cosmic:
> https://github.com/CanonicalLtd/netplan/tree/live-rename
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions
--
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/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Confirmed
Bug description:
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
[Touch-packages] [Bug 1732002] Re: cloud images in lxc get ipv6 address
It would be nice for both nplan and networkd to accept a tri-state: accept-ra: [off|on|kernel] I think that would make it clear rather than an unset value to indicate that it's controlled by the kernel. -- 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/1732002 Title: cloud images in lxc get ipv6 address Status in nplan package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: I noticed that lxd (lxc list) reports that an lxc container has an ipv6 address in artful or bionic. It does not list this in xenial or zesty. I suspect this change occurred in the switch over to netplan/networkd. This may at first seem harmless or even desired, but note that the user configuration did not request ipv6 config, so its presence is a bug. $ for rel in xenial zesty artful bionic; do lxc launch ubuntu-daily:$rel $rel-demo; done Creating xenial-demo Starting xenial-demo .. Creating bionic-demo Starting bionic-demo $ sleep 10 $ lxc list $ lxc list +-+-+--+++---+ |NAME | STATE | IPV4 | IPV6 |TYPE| SNAPSHOTS | +-+-+--+++---+ | artful-demo | RUNNING | 10.75.205.208 (eth0) | fd42:eee5:7c43:3d62:3a42:611c:3f6f:1184 (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | bionic-demo | RUNNING | 10.75.205.187 (eth0) | fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | xenial-demo | RUNNING | 10.75.205.143 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ | zesty-demo | RUNNING | 10.75.205.123 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ ## Here is the config that was provided by lxd $ lxc exec bionic-demo cat /var/lib/cloud/seed/nocloud-net/network-config version: 1 config: - type: physical name: eth0 subnets: - type: dhcp control: auto ## Here is the config that cloud-init rendered. $ lxc exec bionic-demo -- grep -v '^#' /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: eth0: dhcp4: true $ lxc exec bionic-demo cat /run/systemd/network/10-netplan-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 [DHCP] UseMTU=true RouteMetric=100 $ lxc exec bionic-demo -- systemctl status --no-pager --full systemd-networkd ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2017-11-13 18:37:34 UTC; 8min ago Docs: man:systemd-networkd.service(8) Main PID: 118 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 4915) Memory: 2.0M CPU: 19ms CGroup: /system.slice/systemd-networkd.service └─118 /lib/systemd/systemd-networkd Nov 13 18:37:34 bionic-demo systemd[1]: Starting Network Service... Nov 13 18:37:34 bionic-demo systemd-networkd[118]: eth0: Gained IPv6LL Nov 13 18:37:34 bionic-demo systemd-networkd[118]: Enumeration completed Nov 13 18:37:34 bionic-demo systemd[1]: Started Network Service. Nov 13 18:37:37 bionic-demo systemd-networkd[118]: eth0: DHCPv6 address fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d/128 timeout preferred 3600 valid 3600 Nov 13 18:37:37 bionic-demo systemd-networkd[118]: eth0: DHCPv4 address 10.75.205.187/24 via 10.75.205.1 Nov 13 18:37:37 bionic-demo systemd-networkd[118]: Not connected to system bus, ignoring transient hostname. Nov 13 18:37:39 bionic-demo systemd-networkd[118]: eth0: Configured Nov 13 18:38:09 bionic-demo systemd-networkd[118]: Could not set hostname: Method call timed out ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: nplan 0.30 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu4 Architecture: amd64 Date: Mon Nov 13 18:27:53 2017 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SourcePackage: nplan UpgradeStatus: No upgrade log present (probably fresh
[Touch-packages] [Bug 1732002] Re: cloud images in lxc get ipv6 address
After some discussion, it appears that networkd is kinda of making a boolean (on|off) for IPV6 RA, when it's really a tri-state (on|off|kernel). Upstream networkd indicates there is a tri-state; like so: Enable or disable IPv6 Router Advertisement (RA) reception support for the interface. Takes a boolean parameter. If true, RAs are accepted; if false, RAs are ignored, independently of the local forwarding state. When not set, the kernel default is used, and RAs are accepted only when local forwarding is disabled for that interface. When RAs are accepted, they may trigger the start of the DHCPv6 client if the relevant flags are set in the RA data, or if no routers are found on the link. While in netplan, we've only a boolean, which could be fine, except netplan defaults to AcceptRA=True which means we have no way of allowing the kernel configuration to work. Netplan needs to know if the yaml includes an accept-ra key, and if so, uses the value set (off or on); but if the yaml does not specify an accept-ra key, it should *NOT* render a default value. This allows hosts to defer the the kernel settings. This key was introduced as away to resolve a bug where "unconfigured" interfaces got an IPV6 address due to kernel setting and an IPV6 router present. https://bugs.launchpad.net/maas/+bug/1655440 -- 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/1732002 Title: cloud images in lxc get ipv6 address Status in nplan package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: I noticed that lxd (lxc list) reports that an lxc container has an ipv6 address in artful or bionic. It does not list this in xenial or zesty. I suspect this change occurred in the switch over to netplan/networkd. This may at first seem harmless or even desired, but note that the user configuration did not request ipv6 config, so its presence is a bug. $ for rel in xenial zesty artful bionic; do lxc launch ubuntu-daily:$rel $rel-demo; done Creating xenial-demo Starting xenial-demo .. Creating bionic-demo Starting bionic-demo $ sleep 10 $ lxc list $ lxc list +-+-+--+++---+ |NAME | STATE | IPV4 | IPV6 |TYPE| SNAPSHOTS | +-+-+--+++---+ | artful-demo | RUNNING | 10.75.205.208 (eth0) | fd42:eee5:7c43:3d62:3a42:611c:3f6f:1184 (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | bionic-demo | RUNNING | 10.75.205.187 (eth0) | fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | xenial-demo | RUNNING | 10.75.205.143 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ | zesty-demo | RUNNING | 10.75.205.123 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ ## Here is the config that was provided by lxd $ lxc exec bionic-demo cat /var/lib/cloud/seed/nocloud-net/network-config version: 1 config: - type: physical name: eth0 subnets: - type: dhcp control: auto ## Here is the config that cloud-init rendered. $ lxc exec bionic-demo -- grep -v '^#' /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: eth0: dhcp4: true $ lxc exec bionic-demo cat /run/systemd/network/10-netplan-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 [DHCP] UseMTU=true RouteMetric=100 $ lxc exec bionic-demo -- systemctl status --no-pager --full systemd-networkd ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2017-11-13 18:37:34 UTC; 8min ago Docs: man:systemd-networkd.service(8) Main PID: 118 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 4915) Memory: 2.0M CPU: 19ms CGroup: /system.slice/systemd-networkd.service └─118 /lib/systemd/systemd-networkd Nov 13 18:37:34 bionic-demo systemd[1]: Starting Network Service... Nov 13 18:37:34 bionic-demo systemd-networkd[118]: eth0:
[Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives
** Also affects: tar (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1757565 Title: btrfs and tar sparse truncate archives Status in linux package in Ubuntu: Confirmed Status in tar package in Ubuntu: New Bug description: root@ubuntu:~# lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 4.13.0.37.40 Candidate: 4.13.0.37.40 Version table: *** 4.13.0.37.40 500 500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 100 /var/lib/dpkg/status 4.13.0.16.17 500 500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages 3. Taring files into an archive are not truncated 4. Files included in tar are filled with NULLs To reproduce, run an Artful system with one spare disk: - mkfs.btrfs -f /dev/sda - mount /dev/sda /mnt - grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 Then run this script which copies a 4MB binary to a btrfs filesystem, tars the directory up containing the binary; then untars to stdout and md5sum compares, showing it's different. % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - And now without the sparse flag: # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an actual fix. Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 kernel appears to be fixed as well though I'm not sure what the difference is. References: https://patchwork.kernel.org/patch/10151037/ https://www.spinics.net/lists/linux-btrfs/msg56768.html https://www.spinics.net/lists/linux-btrfs/msg57111.html ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-virtual 4.13.0.37.40 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 21 22:55 seq crw-rw 1 root audio 116, 33 Mar 21 22:55 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Date: Wed Mar 21 23:08:05 2018 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-37-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-4.13.0-37-generic N/A linux-backports-modules-4.13.0-37-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-xenial dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1757565/+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 1757565] Re: btrfs and tar sparse truncate archives
v4.14-rc1: BAD ubuntu@ubuntu:~$ uname -r 4.14.0-041400rc1-generic ubuntu@ubuntu:~$ sudo bash root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - v4.14 Final: BAD root@ubuntu:~# uname -r 4.14.0-041400-generic root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - v4.15-rc1: BAD root@ubuntu:~# uname -r 4.15.0-041500rc1-generic root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - Bionic v4.15.0-12-generic: GOOD root@ubuntu:~# uname -r 4.15.0-12-generic root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1757565 Title: btrfs and tar sparse truncate archives Status in linux package in Ubuntu: Triaged Status in tar package in Ubuntu: New Status in linux source package in Artful: Triaged Status in tar source package in Artful: New Bug description: root@ubuntu:~# lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 4.13.0.37.40 Candidate: 4.13.0.37.40 Version table: *** 4.13.0.37.40 500 500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 100 /var/lib/dpkg/status 4.13.0.16.17 500 500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages 3. Taring files into an archive are not truncated 4. Files included in tar are filled with NULLs To reproduce, run an Artful system with one spare disk: - mkfs.btrfs -f /dev/sda - mount /dev/sda /mnt - grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 Then run this script which copies a 4MB binary to a btrfs filesystem, tars the directory up containing the binary; then untars to stdout and md5sum compares, showing it's different. % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - And now without the sparse flag: # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an actual fix. Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 kernel appears to be fixed as well though I'm not sure what the difference is. References: https://patchwork.kernel.org/patch/10151037/ https://www.spinics.net/lists/linux-btrfs/msg56768.html https://www.spinics.net/lists/linux-btrfs/msg57111.html ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-virtual 4.13.0.37.40 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 21 22:55 seq crw-rw 1 root audio 116, 33 Mar 21 22:55 timer AplayDevices: Error:
[Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives
v4.15.7: GOOD root@ubuntu:~# uname -r 4.15.7-041507-generic root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1757565 Title: btrfs and tar sparse truncate archives Status in linux package in Ubuntu: Triaged Status in tar package in Ubuntu: New Status in linux source package in Artful: Triaged Status in tar source package in Artful: New Bug description: root@ubuntu:~# lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 4.13.0.37.40 Candidate: 4.13.0.37.40 Version table: *** 4.13.0.37.40 500 500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 100 /var/lib/dpkg/status 4.13.0.16.17 500 500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages 3. Taring files into an archive are not truncated 4. Files included in tar are filled with NULLs To reproduce, run an Artful system with one spare disk: - mkfs.btrfs -f /dev/sda - mount /dev/sda /mnt - grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 Then run this script which copies a 4MB binary to a btrfs filesystem, tars the directory up containing the binary; then untars to stdout and md5sum compares, showing it's different. % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - And now without the sparse flag: # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an actual fix. Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 kernel appears to be fixed as well though I'm not sure what the difference is. References: https://patchwork.kernel.org/patch/10151037/ https://www.spinics.net/lists/linux-btrfs/msg56768.html https://www.spinics.net/lists/linux-btrfs/msg57111.html ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-virtual 4.13.0.37.40 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 21 22:55 seq crw-rw 1 root audio 116, 33 Mar 21 22:55 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Date: Wed Mar 21 23:08:05 2018 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-37-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-4.13.0-37-generic N/A linux-backports-modules-4.13.0-37-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-xenial dmi.
Re: [Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives
On Thu, Mar 22, 2018 at 2:56 PM, Joseph Salisbury wrote: > @Scott, will that upstream commit make it so the kernel fix we are > looking for is not required? This is a curtin workaround; we're not using the sparse flag when invoking tar; However, the bug/issue remains between tar and btrfs. Outside of curtin's use of it it, any users of btrfs with any "sparse" file detection are vulnerable. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1757565 > > Title: > btrfs and tar sparse truncate archives > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1757565/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1757565 Title: btrfs and tar sparse truncate archives Status in linux package in Ubuntu: Triaged Status in tar package in Ubuntu: New Status in linux source package in Artful: Triaged Status in tar source package in Artful: New Bug description: root@ubuntu:~# lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 4.13.0.37.40 Candidate: 4.13.0.37.40 Version table: *** 4.13.0.37.40 500 500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 100 /var/lib/dpkg/status 4.13.0.16.17 500 500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages 3. Taring files into an archive are not truncated 4. Files included in tar are filled with NULLs To reproduce, run an Artful system with one spare disk: - mkfs.btrfs -f /dev/sda - mount /dev/sda /mnt - grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 Then run this script which copies a 4MB binary to a btrfs filesystem, tars the directory up containing the binary; then untars to stdout and md5sum compares, showing it's different. % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - And now without the sparse flag: # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an actual fix. Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 kernel appears to be fixed as well though I'm not sure what the difference is. References: https://patchwork.kernel.org/patch/10151037/ https://www.spinics.net/lists/linux-btrfs/msg56768.html https://www.spinics.net/lists/linux-btrfs/msg57111.html ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-virtual 4.13.0.37.40 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 21 22:55 seq crw-rw 1 root audio 116, 33 Mar 21 22:55 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Date: Wed Mar 21 23:08:05 2018 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-37-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-4.13.0-37-generic N/A linux-backports-modules-4.13.0-37-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:b
[Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives
v4.15 Final: GOOD root@ubuntu:~# uname -r 4.15.0-041500-generic root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1757565 Title: btrfs and tar sparse truncate archives Status in linux package in Ubuntu: Triaged Status in tar package in Ubuntu: New Status in linux source package in Artful: Triaged Status in tar source package in Artful: New Bug description: root@ubuntu:~# lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 4.13.0.37.40 Candidate: 4.13.0.37.40 Version table: *** 4.13.0.37.40 500 500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 100 /var/lib/dpkg/status 4.13.0.16.17 500 500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages 3. Taring files into an archive are not truncated 4. Files included in tar are filled with NULLs To reproduce, run an Artful system with one spare disk: - mkfs.btrfs -f /dev/sda - mount /dev/sda /mnt - grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 Then run this script which copies a 4MB binary to a btrfs filesystem, tars the directory up containing the binary; then untars to stdout and md5sum compares, showing it's different. % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - And now without the sparse flag: # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an actual fix. Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 kernel appears to be fixed as well though I'm not sure what the difference is. References: https://patchwork.kernel.org/patch/10151037/ https://www.spinics.net/lists/linux-btrfs/msg56768.html https://www.spinics.net/lists/linux-btrfs/msg57111.html ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-virtual 4.13.0.37.40 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 21 22:55 seq crw-rw 1 root audio 116, 33 Mar 21 22:55 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Date: Wed Mar 21 23:08:05 2018 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-37-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-4.13.0-37-generic N/A linux-backports-modules-4.13.0-37-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-xenial
[Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives
v4.15-rc6: GOOD root@ubuntu:~# uname -r 4.15.0-041500rc6-generic root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - v4.15-rc4: GOOD root@ubuntu:~# uname -r 4.15.0-041500rc4-generic root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - v4.15-rc3: GOOD root@ubuntu:~# uname -r 4.15.0-041500rc3-generic root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - v4.14-rc2: GOOD root@ubuntu:~# uname -r 4.15.0-041500rc2-generic root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - So, somewhere between rc1 and rc2. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1757565 Title: btrfs and tar sparse truncate archives Status in linux package in Ubuntu: Triaged Status in tar package in Ubuntu: New Status in linux source package in Artful: Triaged Status in tar source package in Artful: New Bug description: root@ubuntu:~# lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 4.13.0.37.40 Candidate: 4.13.0.37.40 Version table: *** 4.13.0.37.40 500 500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 100 /var/lib/dpkg/status 4.13.0.16.17 500 500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages 3. Taring files into an archive are not truncated 4. Files included in tar are filled with NULLs To reproduce, run an Artful system with one spare disk: - mkfs.btrfs -f /dev/sda - mount /dev/sda /mnt - grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 Then run this script which copies a 4MB binary to a btrfs filesystem, tars the directory up containing the binary; then untars to stdout and md5sum compares, showing it's different. % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - And now without the sparse flag: # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an actual fix. Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 kernel appears to be fixed as well though I'm not sure what the difference is. References: https://patchwork.kernel.org/patch/10151037/ https://www.spinics.net/lists/linux-btrfs/msg56768.html https://www.spinics.net/lists/linux-btrfs/msg57111.html ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-virtual 4.13.0.37.40 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 21 22:55 seq crw-rw 1 root audio 116, 33 Mar 21 22:55 timer AplayDevices: Error: [E
[Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives
This looks promising and landed in -rc2: Btrfs: fix reported number of inode blocks after buffered append writes https://www.spinics.net/lists/linux-btrfs/msg71274.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1757565 Title: btrfs and tar sparse truncate archives Status in linux package in Ubuntu: Triaged Status in tar package in Ubuntu: New Status in linux source package in Artful: Triaged Status in tar source package in Artful: New Bug description: root@ubuntu:~# lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 4.13.0.37.40 Candidate: 4.13.0.37.40 Version table: *** 4.13.0.37.40 500 500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 100 /var/lib/dpkg/status 4.13.0.16.17 500 500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages 3. Taring files into an archive are not truncated 4. Files included in tar are filled with NULLs To reproduce, run an Artful system with one spare disk: - mkfs.btrfs -f /dev/sda - mount /dev/sda /mnt - grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 Then run this script which copies a 4MB binary to a btrfs filesystem, tars the directory up containing the binary; then untars to stdout and md5sum compares, showing it's different. % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - And now without the sparse flag: # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an actual fix. Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 kernel appears to be fixed as well though I'm not sure what the difference is. References: https://patchwork.kernel.org/patch/10151037/ https://www.spinics.net/lists/linux-btrfs/msg56768.html https://www.spinics.net/lists/linux-btrfs/msg57111.html ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-virtual 4.13.0.37.40 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 21 22:55 seq crw-rw 1 root audio 116, 33 Mar 21 22:55 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Date: Wed Mar 21 23:08:05 2018 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-37-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-4.13.0-37-generic N/A linux-backports-modules-4.13.0-37-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-xenial dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1757565/+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/
[Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives
Yeah, rc2 was fine. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1757565 Title: btrfs and tar sparse truncate archives Status in linux package in Ubuntu: Triaged Status in tar package in Ubuntu: New Status in linux source package in Artful: Triaged Status in tar source package in Artful: New Bug description: root@ubuntu:~# lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 4.13.0.37.40 Candidate: 4.13.0.37.40 Version table: *** 4.13.0.37.40 500 500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 100 /var/lib/dpkg/status 4.13.0.16.17 500 500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages 3. Taring files into an archive are not truncated 4. Files included in tar are filled with NULLs To reproduce, run an Artful system with one spare disk: - mkfs.btrfs -f /dev/sda - mount /dev/sda /mnt - grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 Then run this script which copies a 4MB binary to a btrfs filesystem, tars the directory up containing the binary; then untars to stdout and md5sum compares, showing it's different. % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - And now without the sparse flag: # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an actual fix. Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 kernel appears to be fixed as well though I'm not sure what the difference is. References: https://patchwork.kernel.org/patch/10151037/ https://www.spinics.net/lists/linux-btrfs/msg56768.html https://www.spinics.net/lists/linux-btrfs/msg57111.html ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-virtual 4.13.0.37.40 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 21 22:55 seq crw-rw 1 root audio 116, 33 Mar 21 22:55 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Date: Wed Mar 21 23:08:05 2018 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-37-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-4.13.0-37-generic N/A linux-backports-modules-4.13.0-37-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-xenial dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1757565/+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 1757565] Re: btrfs and tar sparse truncate archives
Test kernel: GOOD root@ubuntu:~# cat /proc/version_signature Ubuntu 4.13.0-37.42~lp1757565-generic 4.13.13 root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1757565 Title: btrfs and tar sparse truncate archives Status in linux package in Ubuntu: Triaged Status in tar package in Ubuntu: New Status in linux source package in Artful: Triaged Status in tar source package in Artful: New Bug description: root@ubuntu:~# lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 4.13.0.37.40 Candidate: 4.13.0.37.40 Version table: *** 4.13.0.37.40 500 500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 100 /var/lib/dpkg/status 4.13.0.16.17 500 500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages 3. Taring files into an archive are not truncated 4. Files included in tar are filled with NULLs To reproduce, run an Artful system with one spare disk: - mkfs.btrfs -f /dev/sda - mount /dev/sda /mnt - grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 Then run this script which copies a 4MB binary to a btrfs filesystem, tars the directory up containing the binary; then untars to stdout and md5sum compares, showing it's different. % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - And now without the sparse flag: # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 e4121d2f3126b8c364bfa1aaa82371a3 - This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an actual fix. Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 kernel appears to be fixed as well though I'm not sure what the difference is. References: https://patchwork.kernel.org/patch/10151037/ https://www.spinics.net/lists/linux-btrfs/msg56768.html https://www.spinics.net/lists/linux-btrfs/msg57111.html ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-virtual 4.13.0.37.40 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 21 22:55 seq crw-rw 1 root audio 116, 33 Mar 21 22:55 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Date: Wed Mar 21 23:08:05 2018 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-37-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-4.13.0-37-generic N/A linux-backports-modules-4.13.0-37-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial: dmi.product.name: Standard PC (i440FX + PIIX, 1996)
[Touch-packages] [Bug 1761294] Re: Network configuration doesn't survive reboots after bionic dist-upgrade
As per cloud-init networking disabled. Please reopen task if you find cloud-init is in the picture here. ** Changed in: cloud-init (Ubuntu) Status: New => Invalid -- 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/1761294 Title: Network configuration doesn't survive reboots after bionic dist- upgrade Status in cloud-init package in Ubuntu: Invalid Status in ifupdown package in Ubuntu: New Status in netplan.io package in Ubuntu: Invalid Bug description: I deployed Xenial in this machine with MAAS. After deployment i had re-configured interfaces manually (on /etc/network/interfaces), and removed /etc/network/interfaces.d. At some point, I upgraded the machine from Xenial to Bionic, and everything was working just fine with /e/n/i. About 2/3 weeks ago, I dist-upgraded bionic for the latest packages, and after reboot, networking didn't come up. To recover the machine, what i did is: 1. From the console, brought up the interfaces manually (eno1) 2. added an IP address manually (ip addr add) 3. Configured netplan and applied the config: network: version: 2 renderer: networkd ethernets: eno1: dhcp4: no dhcp6: no addresses: [192.168.1.13/24] gateway4: 192.168.1.1 nameservers: addresses: [8.8.8.8, 8.8.4.4] usb0: dhcp4: no bridges: br0: interfaces: [usb0] dhcp4: no addresses: [10.90.90.1/24] parameters: stp: false forward-delay: 0 max-age: 0 5. Interfaces dont get configured correctly: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 17: eno1: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether ec:a8:6b:fd:ac:70 brd ff:ff:ff:ff:ff:ff inet 192.168.1.13/24 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::eea8:6bff:fefd:ac70/64 scope link valid_lft forever preferred_lft forever 19: usb0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:0e:c6:88:b7:9f brd ff:ff:ff:ff:ff:ff inet6 fe80::20e:c6ff:fe88:b79f/64 scope link valid_lft forever preferred_lft forever 22: wlp2s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether c4:d9:87:5b:42:62 brd ff:ff:ff:ff:ff:ff 6. on reboot, the machine goes back to have no networking again, at all. Note that I also have /e/n/i configured. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1761294/+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 1732002] Re: cloud images in lxc get ipv6 address
The kernel value is equivalent to not writing it out, yes; I thought it'd be better to be explicit in the config. W.r.t disabling by default; no plans to do so at this point but as it is now, all Artful and Bionic images will block for 10 seconds, unless an RA comes in sooner. So ideally we stop writing the Accept-RA unless we have a value provided in the yaml. -- 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/1732002 Title: cloud images in lxc get ipv6 address Status in nplan package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: I noticed that lxd (lxc list) reports that an lxc container has an ipv6 address in artful or bionic. It does not list this in xenial or zesty. I suspect this change occurred in the switch over to netplan/networkd. This may at first seem harmless or even desired, but note that the user configuration did not request ipv6 config, so its presence is a bug. $ for rel in xenial zesty artful bionic; do lxc launch ubuntu-daily:$rel $rel-demo; done Creating xenial-demo Starting xenial-demo .. Creating bionic-demo Starting bionic-demo $ sleep 10 $ lxc list $ lxc list +-+-+--+++---+ |NAME | STATE | IPV4 | IPV6 |TYPE| SNAPSHOTS | +-+-+--+++---+ | artful-demo | RUNNING | 10.75.205.208 (eth0) | fd42:eee5:7c43:3d62:3a42:611c:3f6f:1184 (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | bionic-demo | RUNNING | 10.75.205.187 (eth0) | fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | xenial-demo | RUNNING | 10.75.205.143 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ | zesty-demo | RUNNING | 10.75.205.123 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ ## Here is the config that was provided by lxd $ lxc exec bionic-demo cat /var/lib/cloud/seed/nocloud-net/network-config version: 1 config: - type: physical name: eth0 subnets: - type: dhcp control: auto ## Here is the config that cloud-init rendered. $ lxc exec bionic-demo -- grep -v '^#' /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: eth0: dhcp4: true $ lxc exec bionic-demo cat /run/systemd/network/10-netplan-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 [DHCP] UseMTU=true RouteMetric=100 $ lxc exec bionic-demo -- systemctl status --no-pager --full systemd-networkd ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2017-11-13 18:37:34 UTC; 8min ago Docs: man:systemd-networkd.service(8) Main PID: 118 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 4915) Memory: 2.0M CPU: 19ms CGroup: /system.slice/systemd-networkd.service └─118 /lib/systemd/systemd-networkd Nov 13 18:37:34 bionic-demo systemd[1]: Starting Network Service... Nov 13 18:37:34 bionic-demo systemd-networkd[118]: eth0: Gained IPv6LL Nov 13 18:37:34 bionic-demo systemd-networkd[118]: Enumeration completed Nov 13 18:37:34 bionic-demo systemd[1]: Started Network Service. Nov 13 18:37:37 bionic-demo systemd-networkd[118]: eth0: DHCPv6 address fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d/128 timeout preferred 3600 valid 3600 Nov 13 18:37:37 bionic-demo systemd-networkd[118]: eth0: DHCPv4 address 10.75.205.187/24 via 10.75.205.1 Nov 13 18:37:37 bionic-demo systemd-networkd[118]: Not connected to system bus, ignoring transient hostname. Nov 13 18:37:39 bionic-demo systemd-networkd[118]: eth0: Configured Nov 13 18:38:09 bionic-demo systemd-networkd[118]: Could not set hostname: Method call timed out ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: nplan 0.30 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu4 Architecture: amd64 Date: Mon Nov 13 18:27:53 20
Re: [Touch-packages] [Bug 1732002] Re: cloud images in lxc get ipv6 address
Guys, I'm no longer suggesting that we disable RA here. After our discussion I updated this bug to indicate that we really want some way to *leave* RA alone. At this point that means netplan needs to *NOT* emit AcceptRA values into the .network configuration files by default (as it does now), but only if the input yaml included an accept-ra value set. On Mon, Apr 9, 2018 at 5:22 PM, Stéphane Graber wrote: > I'd like to +1 what cyphermox said, the expected behavior on Ubuntu is > that if you do receive a RA, you let the kernel configure it. > > That's how Ubuntu has been ever since IPv6 support was enabled and I > personally have about 200 systems that very much rely on this (no > specific IPv6 configuration, just RA based config). > > If you turn off IPv6 on your host, this may or may not affect your > containers, depending on how you've turned it off (globally at kernel > level, through the default policy or through the all policy). > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1732002 > > Title: > cloud images in lxc get ipv6 address > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1732002/+subscriptions -- 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/1732002 Title: cloud images in lxc get ipv6 address Status in nplan package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: I noticed that lxd (lxc list) reports that an lxc container has an ipv6 address in artful or bionic. It does not list this in xenial or zesty. I suspect this change occurred in the switch over to netplan/networkd. This may at first seem harmless or even desired, but note that the user configuration did not request ipv6 config, so its presence is a bug. $ for rel in xenial zesty artful bionic; do lxc launch ubuntu-daily:$rel $rel-demo; done Creating xenial-demo Starting xenial-demo .. Creating bionic-demo Starting bionic-demo $ sleep 10 $ lxc list $ lxc list +-+-+--+++---+ |NAME | STATE | IPV4 | IPV6 |TYPE| SNAPSHOTS | +-+-+--+++---+ | artful-demo | RUNNING | 10.75.205.208 (eth0) | fd42:eee5:7c43:3d62:3a42:611c:3f6f:1184 (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | bionic-demo | RUNNING | 10.75.205.187 (eth0) | fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | xenial-demo | RUNNING | 10.75.205.143 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ | zesty-demo | RUNNING | 10.75.205.123 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ ## Here is the config that was provided by lxd $ lxc exec bionic-demo cat /var/lib/cloud/seed/nocloud-net/network-config version: 1 config: - type: physical name: eth0 subnets: - type: dhcp control: auto ## Here is the config that cloud-init rendered. $ lxc exec bionic-demo -- grep -v '^#' /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: eth0: dhcp4: true $ lxc exec bionic-demo cat /run/systemd/network/10-netplan-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 [DHCP] UseMTU=true RouteMetric=100 $ lxc exec bionic-demo -- systemctl status --no-pager --full systemd-networkd ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2017-11-13 18:37:34 UTC; 8min ago Docs: man:systemd-networkd.service(8) Main PID: 118 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 4915) Memory: 2.0M CPU: 19ms CGroup: /system.slice/systemd-networkd.service └─118 /lib/systemd/systemd-networkd Nov 13 18:37:34 bionic-demo systemd[1]: Starting Network Service... Nov 13 18:37:34 bionic-demo systemd-networkd[118]: eth0: Gained IPv6LL Nov 13 18:37:34 bionic-demo systemd-n
[Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives
Verified artful-proposed. root@ubuntu:~# cat /etc/cloud/build.info build_name: server serial: 20180404 root@ubuntu:~# uname -a Linux ubuntu 4.13.0-38-generic #43-Ubuntu SMP Wed Mar 14 15:20:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux root@ubuntu:~# mount /dev/sda /mnt root@ubuntu:~# grep sda /proc/mounts /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz .; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum e4121d2f3126b8c364bfa1aaa82371a3 /usr/bin/python3.6 0ce8c4139740198926273853defcb12a - root@ubuntu:~# dpkg --list | grep virtual ii linux-headers-virtual 4.13.0.38.41 amd64Virtual Linux kernel headers ii linux-image-virtual4.13.0.38.41 amd64Virtual Linux kernel image ii linux-virtual 4.13.0.38.41 amd64Minimal Generic Linux kernel and headers ii open-vm-tools 2:10.1.10-3ubuntu0.1 amd64Open VMware Tools for virtual machines hosted on VMware (CLI) root@ubuntu:~# apt update && apt install linux-image-virtual Hit:1 http://archive.ubuntu.com/ubuntu artful InRelease Hit:2 http://security.ubuntu.com/ubuntu artful-security InRelease Hit:3 http://archive.ubuntu.com/ubuntu artful-updates InRelease Hit:4 http://archive.ubuntu.com/ubuntu artful-backports InRelease Get:5 http://archive.ubuntu.com/ubuntu artful-proposed InRelease [235 kB] Get:6 http://archive.ubuntu.com/ubuntu artful-proposed/main amd64 Packages [62.3 kB] Get:7 http://archive.ubuntu.com/ubuntu artful-proposed/main Translation-en [26.1 kB] Fetched 323 kB in 1s (206 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 29 packages can be upgraded. Run 'apt list --upgradable' to see them. Reading package lists... Done Building dependency tree Reading state information... Done The following package was automatically installed and is no longer required: grub-pc-bin Use 'apt autoremove' to remove it. The following additional packages will be installed: linux-headers-4.13.0-39 linux-headers-4.13.0-39-generic linux-headers-generic linux-headers-virtual linux-image-4.13.0-39-generic linux-virtual Suggested packages: fdutils linux-doc-4.13.0 | linux-source-4.13.0 linux-tools The following NEW packages will be installed: linux-headers-4.13.0-39 linux-headers-4.13.0-39-generic linux-image-4.13.0-39-generic The following packages will be upgraded: linux-headers-generic linux-headers-virtual linux-image-virtual linux-virtual 4 upgraded, 3 newly installed, 0 to remove and 25 not upgraded. Need to get 32.5 MB of archives. After this operation, 156 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://archive.ubuntu.com/ubuntu artful-proposed/main amd64 linux-headers-4.13.0-39 all 4.13.0-39.44 [10.9 MB] Get:2 http://archive.ubuntu.com/ubuntu artful-proposed/main amd64 linux-headers-4.13.0-39-generic amd64 4.13.0-39.44 [704 kB] Get:3 http://archive.ubuntu.com/ubuntu artful-proposed/main amd64 linux-image-4.13.0-39-generic amd64 4.13.0-39.44 [20.9 MB] Get:4 http://archive.ubuntu.com/ubuntu artful-proposed/main amd64 linux-virtual amd64 4.13.0.39.42 [1780 B] Get:5 http://archive.ubuntu.com/ubuntu artful-proposed/main amd64 linux-image-virtual amd64 4.13.0.39.42 [2308 B] Get:6 http://archive.ubuntu.com/ubuntu artful-proposed/main amd64 linux-headers-virtual amd64 4.13.0.39.42 [1766 B] Get:7 http://archive.ubuntu.com/ubuntu artful-proposed/main amd64 linux-headers-generic amd64 4.13.0.39.42 [2294 B] Fetched 32.5 MB in 5s (5459 kB/s) Selecting previously unselected package linux-headers-4.13.0-39. (Reading database ... 57609 files and directories currently installed.) Preparing to unpack .../0-linux-headers-4.13.0-39_4.13.0-39.44_all.deb ... Unpacking linux-headers-4.13.0-39 (4.13.0-39.44) ... Selecting previously unselected package linux-headers-4.13.0-39-generic. Preparing to unpack .../1-linux-headers-4.13.0-39-generic_4.13.0-39.44_amd64.deb ... Unpacking linux-headers-4.13.0-39-generic (4.13.0-39.44) ... Selecting previously unselected package linux-image-4.13.0-39-generic. Preparing to unpack .../2-linux-image-4.13.0-39-generic_4.13.0-39.44_amd64.deb ... Done. Unpacking linux-image-4.13.0-39-generic (4.13.0-39.44) ... Preparing to unpack .../3-linux-virtual_4.13.0.39.42_amd64.deb ... Unpacking linux-virtual (4.13.0.39.42) over (4.13.0.38.41) ... Preparing to unpack .../4-linux-image-virtual_4.13.0.39.42_amd64.deb ... Unpacking linux-image-virtual (4.13.0.39.42) over (4.13.0.38.41) ... Preparing to unpack .../5-linux-headers-virtual_4.13.0.39.42_amd64.deb ... Unpacking linux-headers-virtual (4.13.0.39.42)
[Touch-packages] [Bug 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial), please disable LLMNR
I'm seeing this on Artful as well, in Azure cloud. ** Also affects: glibc (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Artful) Importance: Undecided Status: New -- 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/1739672 Title: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial), please disable LLMNR Status in glibc package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in glibc source package in Artful: New Status in linux source package in Artful: New Status in systemd source package in Artful: New Status in glibc source package in Bionic: Invalid Status in linux source package in Bionic: Invalid Status in systemd source package in Bionic: Fix Released Bug description: When testing MAAS on Bionic, we noticed sluggish performance that we could not immediately explain. After comparing the results from a run of the test suite on Xenial to a run on Bionic, we determined that the slowdowns had to do with DNS lookups. In particular, if MAAS attempts to resolve a hostname using getaddrinfo() and the call fails, on Xenial the negative result is returned in a fraction of a second. On Bionic, the negative result is returned in ~1.6 seconds, according to some measures. ### To run the test ### git clone https://github.com/mpontillo/test-getaddrinfo cd test-getaddrinfo make ### Results on Xenial ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Success getaddrinfo() return value: -2 (Name or service not known) real 0m0.015s user 0m0.000s sys 0m0.000s ### Results on Bionic ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Resource temporarily unavailable getaddrinfo() return value: -3 (Temporary failure in name resolution) real 0m1.609s user 0m0.004s sys 0m0.000s To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial), please disable LLMNR
ubuntu@foufoune:~$ lsb_release -rd Description:Ubuntu 17.10 Release:17.10 ubuntu@foufoune:~$ apt-cache policy systemd systemd: Installed: 234-2ubuntu12.3 Candidate: 234-2ubuntu12.3 Version table: *** 234-2ubuntu12.3 500 500 http://azure.archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages 100 /var/lib/dpkg/status 234-2ubuntu12.1 500 500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages 234-2ubuntu12 500 500 http://azure.archive.ubuntu.com/ubuntu artful/main amd64 Packages ubuntu@foufoune:~$ time ping __cloud_init_expected_not_found ping: __cloud_init_expected_not_found: Temporary failure in name resolution real0m15.016s user0m0.000s sys 0m0.003s After applying the workaround from comment #11, I see fast lookups again. ubuntu@foufoune:~$ cat /etc/systemd/resolved.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. # # See resolved.conf(5) for details [Resolve] #DNS= #FallbackDNS= #Domains= #LLMNR=yes #MulticastDNS=yes #DNSSEC=no #Cache=yes #DNSStubListener=udp LLMNR=no ubuntu@foufoune:~$ time ping __cloud_init_expected_not_found ping: __cloud_init_expected_not_found: Name or service not known real0m0.006s user0m0.000s sys 0m0.001s -- 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/1739672 Title: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial), please disable LLMNR Status in glibc package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in glibc source package in Artful: New Status in linux source package in Artful: New Status in systemd source package in Artful: New Status in glibc source package in Bionic: Invalid Status in linux source package in Bionic: Invalid Status in systemd source package in Bionic: Fix Released Bug description: When testing MAAS on Bionic, we noticed sluggish performance that we could not immediately explain. After comparing the results from a run of the test suite on Xenial to a run on Bionic, we determined that the slowdowns had to do with DNS lookups. In particular, if MAAS attempts to resolve a hostname using getaddrinfo() and the call fails, on Xenial the negative result is returned in a fraction of a second. On Bionic, the negative result is returned in ~1.6 seconds, according to some measures. ### To run the test ### git clone https://github.com/mpontillo/test-getaddrinfo cd test-getaddrinfo make ### Results on Xenial ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Success getaddrinfo() return value: -2 (Name or service not known) real 0m0.015s user 0m0.000s sys 0m0.000s ### Results on Bionic ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Resource temporarily unavailable getaddrinfo() return value: -3 (Temporary failure in name resolution) real 0m1.609s user 0m0.004s sys 0m0.000s To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1732002] Re: cloud images in lxc get ipv6 address
The MP has been moved to a github PR: https://github.com/CanonicalLtd/netplan/pull/19 -- 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/1732002 Title: cloud images in lxc get ipv6 address Status in nplan package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: I noticed that lxd (lxc list) reports that an lxc container has an ipv6 address in artful or bionic. It does not list this in xenial or zesty. I suspect this change occurred in the switch over to netplan/networkd. This may at first seem harmless or even desired, but note that the user configuration did not request ipv6 config, so its presence is a bug. $ for rel in xenial zesty artful bionic; do lxc launch ubuntu-daily:$rel $rel-demo; done Creating xenial-demo Starting xenial-demo .. Creating bionic-demo Starting bionic-demo $ sleep 10 $ lxc list $ lxc list +-+-+--+++---+ |NAME | STATE | IPV4 | IPV6 |TYPE| SNAPSHOTS | +-+-+--+++---+ | artful-demo | RUNNING | 10.75.205.208 (eth0) | fd42:eee5:7c43:3d62:3a42:611c:3f6f:1184 (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | bionic-demo | RUNNING | 10.75.205.187 (eth0) | fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | xenial-demo | RUNNING | 10.75.205.143 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ | zesty-demo | RUNNING | 10.75.205.123 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ ## Here is the config that was provided by lxd $ lxc exec bionic-demo cat /var/lib/cloud/seed/nocloud-net/network-config version: 1 config: - type: physical name: eth0 subnets: - type: dhcp control: auto ## Here is the config that cloud-init rendered. $ lxc exec bionic-demo -- grep -v '^#' /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: eth0: dhcp4: true $ lxc exec bionic-demo cat /run/systemd/network/10-netplan-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 [DHCP] UseMTU=true RouteMetric=100 $ lxc exec bionic-demo -- systemctl status --no-pager --full systemd-networkd ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2017-11-13 18:37:34 UTC; 8min ago Docs: man:systemd-networkd.service(8) Main PID: 118 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 4915) Memory: 2.0M CPU: 19ms CGroup: /system.slice/systemd-networkd.service └─118 /lib/systemd/systemd-networkd Nov 13 18:37:34 bionic-demo systemd[1]: Starting Network Service... Nov 13 18:37:34 bionic-demo systemd-networkd[118]: eth0: Gained IPv6LL Nov 13 18:37:34 bionic-demo systemd-networkd[118]: Enumeration completed Nov 13 18:37:34 bionic-demo systemd[1]: Started Network Service. Nov 13 18:37:37 bionic-demo systemd-networkd[118]: eth0: DHCPv6 address fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d/128 timeout preferred 3600 valid 3600 Nov 13 18:37:37 bionic-demo systemd-networkd[118]: eth0: DHCPv4 address 10.75.205.187/24 via 10.75.205.1 Nov 13 18:37:37 bionic-demo systemd-networkd[118]: Not connected to system bus, ignoring transient hostname. Nov 13 18:37:39 bionic-demo systemd-networkd[118]: eth0: Configured Nov 13 18:38:09 bionic-demo systemd-networkd[118]: Could not set hostname: Method call timed out ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: nplan 0.30 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu4 Architecture: amd64 Date: Mon Nov 13 18:27:53 2017 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SourcePackage: nplan UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1732002/
[Touch-packages] [Bug 1765173] [NEW] networkd waits 10 seconds for ipv6 network discovery by default
Public bug reported: 1. $ lsb_release -rd Description:Ubuntu Bionic Beaver (development branch) Release:18.04 2. $ apt-cache policy systemd systemd: Installed: 237-3ubuntu8 Candidate: 237-3ubuntu8 Version table: *** 237-3ubuntu8 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status 3. systemd-networkd-wait-online doesn't block for 10 seconds waiting on an IPV6 Router Advertisement 4. systemd-networkd sends at least two RA solicitation packets waiting for a response before setting the link to configured. This blocks the boot for every Ubuntu system where it does not have a IPV6 router responding to solicitations. THis includes bionic containers, cloud instances, vms and physical machines. -- We can see that we're spending 13 seconds waiting for networkd to say the network is up. % systemd-analyze blame 13.326s systemd-networkd-wait-online.service 999ms cloud-init-local.service 954ms cloud-init.service 887ms cloud-config.service 749ms dev-vda1.device 666ms cloud-final.service 248ms keyboard-setup.service 175ms systemd-udev-trigger.service 171ms lxd-containers.service 165ms snapd.service 154ms apparmor.service 147ms ssh.service 144ms systemd-timesyncd.service 133ms grub-common.service 130ms systemd-journald.service 130ms accounts-daemon.service 99ms systemd-modules-load.service 98ms systemd-resolved.service 94ms apport.service 92ms rsyslog.service 88ms systemd-logind.service 80ms lvm2-monitor.service 75ms iscsid.service 64ms ebtables.service 62ms user@1000.service 54ms dev-mqueue.mount 53ms ufw.service 52ms systemd-remount-fs.service 52ms kmod-static-nodes.service 34ms systemd-journal-flush.service 34ms polkit.service 32ms systemd-tmpfiles-setup-dev.service 27ms systemd-udevd.service 26ms systemd-networkd.service 26ms systemd-sysctl.service 25ms systemd-tmpfiles-setup.service 21ms dev-hugepages.mount 17ms sys-kernel-debug.mount 16ms console-setup.service 15ms plymouth-read-write.service 15ms snapd.socket 15ms plymouth-quit.service 14ms systemd-update-utmp.service 10ms systemd-user-sessions.service 9ms boot-efi.mount 8ms sys-fs-fuse-connections.mount 8ms systemd-update-utmp-runlevel.service 8ms lxd.socket 7ms blk-availability.service 5ms systemd-random-seed.service 3ms setvtrgb.service 3ms plymouth-quit-wait.service 3ms sys-kernel-config.mount Here we can see that we start networking at 18:30:51.69, and then IPv6 NDISC runs for 10 seconds and then the link is configured at 18:31:05. *AND* we see NDISC stays around and continues to see if it gets a RA packet. $ journalctl -o short-precise -u systemd-networkd.service | egrep "(Starting Network|Discovering IPv6 routers|NDISC|Configured)" Apr 18 18:30:51.691532 rharper-b1 systemd[1]: Starting Network Service... Apr 18 18:30:53.031041 rharper-b1 systemd-networkd[603]: ens3: Discovering IPv6 routers Apr 18 18:30:53.031306 rharper-b1 systemd-networkd[603]: NDISC: Started IPv6 Router Solicitation client Apr 18 18:30:53.031612 rharper-b1 systemd-networkd[603]: NDISC: Sent Router Solicitation, next solicitation in 4s Apr 18 18:30:57.092282 rharper-b1 systemd-networkd[603]: NDISC: Sent Router Solicitation, next solicitation in 8s Apr 18 18:31:05.040895 rharper-b1 systemd-networkd[603]: NDISC: No RA received before link confirmation timeout Apr 18 18:31:05.040932 rharper-b1 systemd-networkd[603]: NDISC: Invoking callback for 't'. Apr 18 18:31:05.041099 rharper-b1 systemd-networkd[603]: ens3: Configured Apr 18 18:31:05.484261 rharper-b1 systemd-networkd[603]: NDISC: Sent Router Solicitation, next solicitation in 16s Apr 18 18:31:21.550612 rharper-b1 systemd-networkd[603]: NDISC: Sent Router Solicitation, next solicitation in 33s Apr 18 18:31:54.706283 rharper-b1 systemd-networkd[603]: NDISC: Sent Router Solicitation, next solicitation in 1min 5s Apr 18 18:33:00.232685 rharper-b1 systemd-networkd[603]: NDISC: Sent Router Solicitation, next solicitation in 2min 15s Apr 18 18:35:15.436376 rharper-b1 systemd-networkd[603]: NDISC: Sent Router Solicitation, next solicitation in 4min 32s Apr 18 18:39:48.111413 rharper-b1 systemd-networkd[603]: NDISC: Sent Router Solicitation, next solicitation in 9min 16s networkd runs ndisc if your host is configured with ipv6 forwarding disabled and accept_ra enabled. % sysctl net.ipv6.conf.all.forwarding net.ipv6.conf.all.f
[Touch-packages] [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces
In your netplan example config, keyword 'optional' means that systemd- networkd won't wait until this interface is up before declaring to systemd that the network is online. THis means dnsmasq is starting before the vlan0 interface is created. If you remove the optional value that should ensure it is up and configured before the dnsmasq service starts. ** Also affects: netplan.io (Ubuntu) Importance: Undecided Status: New ** Changed in: netplan.io (Ubuntu) Status: New => Incomplete ** Changed in: dnsmasq (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1777094 Title: dnsmasq started too early, not getting all interfaces Status in dnsmasq package in Ubuntu: Incomplete Status in netplan.io package in Ubuntu: Incomplete Bug description: Hi, I'm still struggling with 18.04 and the move from ifupdown to netplan. I am running a local virtual linux bridge as a network for several virtual machines and containers, which is to be serviced with dhcp and dns by dnsmasq. Conforming to latest designs from Ubuntu the bridge is now started by netplan and configured in /etc/netplan/60-vlan0.yaml straightforward. Since there is no ifupdown-scripts anymore, I've configured the default dnsmasq daemon in /etc/dnsmasq.d/vlan0 to offer dhcp for that bridge. This works only when started manually. When booting ubuntu the normal way, the bridge is correctly generated, and dnsmasq is running, but it does *not* offer DNS for the bridge and does not occupy its port 53. But just a manual systemctl restart dnsmasq.service make it run as expected, then everything is fine. So my guess is that my configuration is correct, but dnsmasq simply started to early, i.e. before the bridge is created, and thus does not see the bridge when starting up. There's something wrong in the dependencies of the startup configuration. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: dnsmasq 2.79-1 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: LXDE Date: Fri Jun 15 10:59:43 2018 InstallationDate: Installed on 2018-04-30 (45 days ago) InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1777094/+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
Re: [Touch-packages] [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces
https://netplan.io/faq#example-for-an-ifupdown-legacy-hook-for-post- uppost-down-states You can use a networkd-dispatcherd to hook on vlan0 becoming routeable and then start/restart the dnsmasq service; On Fri, Jun 15, 2018 at 12:36 PM, Hadmut Danisch wrote: > So it is not possible to have an interface as optional (for other > reasons beyond that example) and still have a dnsmasq running for it? > > In former versions of ubuntu I had my bridges (some containing usb > ethernet interfaces to bridge virtual with physical machines) configured > in /etc/network/if-up.d, and started separate dnsmasq instances for > every single one of these bridges. > > Now there is no regular way to start a daemon like dnsmasq through ifup- > scripts, since netplan does not support them. Some people try to > workaround that problem with udev clauses, starting systemd services, > but then it's overcomplicated and error prone. > > So what is the offical way to have services like dnsmasq run for > optional interfaces under 18.04? > > > "Don't use optional" is a workaround, not a solution to the problem. If there > is no ifup-script anymore, then how are services to be started, once the > interface is up (late or just sometimes)? > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1777094 > > Title: > dnsmasq started too early, not getting all interfaces > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1777094/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1777094 Title: dnsmasq started too early, not getting all interfaces Status in dnsmasq package in Ubuntu: Incomplete Status in netplan.io package in Ubuntu: Incomplete Bug description: Hi, I'm still struggling with 18.04 and the move from ifupdown to netplan. I am running a local virtual linux bridge as a network for several virtual machines and containers, which is to be serviced with dhcp and dns by dnsmasq. Conforming to latest designs from Ubuntu the bridge is now started by netplan and configured in /etc/netplan/60-vlan0.yaml straightforward. Since there is no ifupdown-scripts anymore, I've configured the default dnsmasq daemon in /etc/dnsmasq.d/vlan0 to offer dhcp for that bridge. This works only when started manually. When booting ubuntu the normal way, the bridge is correctly generated, and dnsmasq is running, but it does *not* offer DNS for the bridge and does not occupy its port 53. But just a manual systemctl restart dnsmasq.service make it run as expected, then everything is fine. So my guess is that my configuration is correct, but dnsmasq simply started to early, i.e. before the bridge is created, and thus does not see the bridge when starting up. There's something wrong in the dependencies of the startup configuration. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: dnsmasq 2.79-1 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: LXDE Date: Fri Jun 15 10:59:43 2018 InstallationDate: Installed on 2018-04-30 (45 days ago) InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1777094/+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
Re: [Touch-packages] [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces
I see, interesting. The dnsmasq.service does not wait for network-online.target; This appears to be a duplicate of: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1531184 In addition to the netplan config to ensure it waits for your bridge to come up, you need to delay dnsmasq.service until after the network is online. You can do that with something like this: % mkdir -p /etc/systemd/system/dnsmasq.service.d % echo -e "[Unit]\nAfter=network-online.target\nWants=network-online.target" | sudo tee /etc/systemd/system/dnsmasq.service.d/network-online.conf % reboot After rebooting, you should see that networkd runs, brings up the interfaces, then network-online.target is reached, and lastly dnsmasq is then started. % journalctl -b -o short-monotonic | egrep "(Reboot|networkd|Network is Online|Starting dnsmasq)" [1835835.825873] b1 systemd-networkd[173]: vlan0: IPv6 successfully enabled [1835835.827054] b1 systemd-networkd[173]: vlan0: netdev ready [1835835.837274] b1 systemd-networkd[173]: Enumeration completed [1835835.864747] b1 systemd-networkd[173]: eth1: Lost carrier [1835835.871748] b1 systemd-networkd[173]: eth0: DHCPv4 address 10.8.107.77/24 via 10.8.107.1 [1835835.879184] b1 systemd-networkd[173]: eth1: IPv6 successfully disabled [1835835.908530] b1 systemd-networkd[173]: eth1: Gained carrier [1835835.908903] b1 systemd-networkd[173]: eth1: Configured [1835835.909878] b1 systemd-networkd[173]: vlan0: Gained carrier [1835835.913807] b1 systemd-networkd-wait-online[175]: managing: eth1 [1835836.288648] b1 systemd-networkd[173]: eth0: Gained IPv6LL [1835836.289022] b1 systemd-networkd[173]: eth0: Configured [1835836.290405] b1 systemd-networkd-wait-online[175]: managing: eth1 [1835836.290834] b1 systemd-networkd-wait-online[175]: managing: eth0 [1835836.291077] b1 systemd-networkd-wait-online[175]: ignoring: lo [1835837.760738] b1 systemd-networkd[173]: vlan0: Gained IPv6LL [1835837.761713] b1 systemd-networkd[173]: vlan0: Configured [1835837.762522] b1 systemd-networkd-wait-online[175]: managing: eth1 [1835837.763413] b1 systemd-networkd-wait-online[175]: managing: eth0 [1835837.763705] b1 systemd-networkd-wait-online[175]: ignoring: lo [1835837.764057] b1 systemd-networkd-wait-online[175]: managing: vlan0 [1835838.445945] b1 systemd[1]: Reached target Network is Online. [1835838.496394] b1 dbus-daemon[195]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.0' (uid=100 pid=173 comm="/lib/systemd/systemd-networkd " label="unconfined") [1835838.516683] b1 systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... On Tue, Jun 19, 2018 at 3:51 AM Hadmut Danisch wrote: > > setting optional: false does not solve the problem, a systemctl > restart dnsmasq is still required. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1777094 > > Title: > dnsmasq started too early, not getting all interfaces > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1777094/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1777094 Title: dnsmasq started too early, not getting all interfaces Status in dnsmasq package in Ubuntu: Incomplete Status in netplan.io package in Ubuntu: Incomplete Bug description: Hi, I'm still struggling with 18.04 and the move from ifupdown to netplan. I am running a local virtual linux bridge as a network for several virtual machines and containers, which is to be serviced with dhcp and dns by dnsmasq. Conforming to latest designs from Ubuntu the bridge is now started by netplan and configured in /etc/netplan/60-vlan0.yaml straightforward. Since there is no ifupdown-scripts anymore, I've configured the default dnsmasq daemon in /etc/dnsmasq.d/vlan0 to offer dhcp for that bridge. This works only when started manually. When booting ubuntu the normal way, the bridge is correctly generated, and dnsmasq is running, but it does *not* offer DNS for the bridge and does not occupy its port 53. But just a manual systemctl restart dnsmasq.service make it run as expected, then everything is fine. So my guess is that my configuration is correct, but dnsmasq simply started to early, i.e. before the bridge is created, and thus does not see the bridge when starting up. There's something wrong in the dependencies of the startup configuration. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: dnsmasq 2.79-1 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: LXDE Date: Fri Jun 15 1
Re: [Touch-packages] [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces
On Tue, Jun 19, 2018 at 9:41 AM Hadmut Danisch wrote:
>
> dnsmasq _after_ networking?
>
> Isn't it part of networking and should be running and ready for other
> services depending on networking?
Yes, but it's complicated; see below.
>
>
> (my guess is that Ubuntu has never defined the targets very precisely. it
> should distinguish between low level /interface level configuration and
> networking services.)
>
This is rather precisely defined; not by Ubuntu but by the init
system. In systemd there are many targets that indicate various state
of the system during boot[1][2]
For networking, the ones that matter are:
network-pre.target (before systemd has attempted to bring the network up)
network.target (systemd has started to bring network up; for
Artful/Bionic, this means systemd-networkd.service has started)
network-online.target ("required" networking interfaces are up,
configured, routable)
Dnsmasq itself is a networking service, so arguably, it is fine to run
at After=network.target; but network.target does not guarantee that
all of networking has been configured. Dnsmasq has two choices. 1)
it can run later, at network-online.target which means systemd is
done with creating and configuring interfaces. 2) start at
After=network.target but listen to dbus or netlink layer to react to
when a
configured interface is present and ready for it to use.
Since dnsmasq does not watch dbus or netlink for new interfaces and
when they're configured, then the only solution is to run after such
a time that the configured interfaces are ready for use by dnsmasq.
1. https://www.freedesktop.org/software/systemd/man/systemd.special.html
2. https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1777094
>
> Title:
> dnsmasq started too early, not getting all interfaces
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1777094/+subscriptions
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1777094
Title:
dnsmasq started too early, not getting all interfaces
Status in dnsmasq package in Ubuntu:
Incomplete
Status in netplan.io package in Ubuntu:
Incomplete
Bug description:
Hi,
I'm still struggling with 18.04 and the move from ifupdown to netplan.
I am running a local virtual linux bridge as a network for several
virtual machines and containers, which is to be serviced with dhcp and
dns by dnsmasq.
Conforming to latest designs from Ubuntu the bridge is now started by
netplan and configured in /etc/netplan/60-vlan0.yaml straightforward.
Since there is no ifupdown-scripts anymore, I've configured the
default dnsmasq daemon in /etc/dnsmasq.d/vlan0 to offer dhcp for that
bridge.
This works only when started manually.
When booting ubuntu the normal way, the bridge is correctly generated,
and dnsmasq is running, but it does *not* offer DNS for the bridge and
does not occupy its port 53. But just a manual systemctl restart
dnsmasq.service make it run as expected, then everything is fine.
So my guess is that my configuration is correct, but dnsmasq simply
started to early, i.e. before the bridge is created, and thus does not
see the bridge when starting up.
There's something wrong in the dependencies of the startup
configuration.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: LXDE
Date: Fri Jun 15 10:59:43 2018
InstallationDate: Installed on 2018-04-30 (45 days ago)
InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64
(20180426)
PackageArchitecture: all
SourcePackage: dnsmasq
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1777094/+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
I've just seen that upstream systemd v239 claims to support IPV6MtuBytes https://lwn.net/Articles/758128/ * networkd's .network files now support a new IPv6MTUBytes= option for setting the MTU used by IPv6 explicitly as well as a new MTUBytes= option in the [Route] section to configure the MTU to use for specific routes. It also gained support for configuration of the DHCP "UserClass" option through the new UserClass= setting. It gained three new options in the new [CAN] section for configuring CAN networks. The MULTICAST and ALLMULTI interface flags may now be controlled explicitly with the new Multicast= and AllMulticast= settings. -- 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 systemd package in Ubuntu: Confirmed Bug description: 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/systemd/+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 1734167] Re: DNS doesn't work in no-cloud as launched by ubuntu
I suspect because in bionic/artful we're missing resolvconf package, that the
systemd-resolved service ends up starting later in boot. The
systemd-resolved-update-resolveconf.{service,path} require /sbin/resolvconf to
run; this service had a path-based trigger that would get hooked whenever DHCP
clients would call resolvconf to kick off a DNS update once config was
available.
I suspect that systemd-networkd itself isn't poking DNS service properly after
acquiring information.
The dependency loop comes from systemd-resolved using default
dependencies which run after when cloud-init.service would run.
This then needs systemd-resolved to specify DefaultDependencies=No and
something like network-online.target to require systemd-resolved.
I modified cloud-init.service to include an After=systemd-
resolved.service but some other service may require dns, so I feel this
is a property of network-online.target.
--
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/1734167
Title:
DNS doesn't work in no-cloud as launched by ubuntu
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Confirmed
Status in cloud-init source package in Zesty:
Fix Released
Status in systemd source package in Zesty:
Fix Released
Status in cloud-init source package in Artful:
Confirmed
Status in systemd source package in Artful:
Confirmed
Status in cloud-init source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Confirmed
Bug description:
I use no-cloud to test the kernel in CI (I am maintainer of the bcache
subsystem), and have been running it successfully under 16.04 cloud
images from qemu, using a qemu command that includes:
-smbios "type=1,serial=ds=nocloud-
net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud-
metadata/linuxtst/"
As documented here:
http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
Under the new 17.10 cloud images, this doesn't work: the network comes
up, but name resolution doesn't work-- /etc/resolv.conf is a symlink
to a nonexistent file at this point of the boot and systemd-resolved
is not running. When I manually hack /etc/resolv.conf in the cloud
image to point to 4.2.2.1 it works fine.
I don't know if nameservice not working is by design, but it seems
like it should work. The documentation states:
"With ds=nocloud-net, the seedfrom value must start with http://,
https:// or ftp://";
And https is not going to work for a raw IP address.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1734167/+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 1734167] Re: DNS doesn't work in no-cloud as launched by ubuntu
We will still need something that helps ensure systemd-resolved runs we reach network-online.target; and I suspect (though I've not validated yet) that we really want systemd-resolved to be running prior to systemd-networkd such that systemd-networkd can relay DNS configuration info retrieved from DHCP results, ala how resolvconf was hooked on networking config touching files in /run. -- 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/1734167 Title: DNS doesn't work in no-cloud as launched by ubuntu Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in cloud-init source package in Zesty: Fix Released Status in systemd source package in Zesty: Fix Released Status in cloud-init source package in Artful: Confirmed Status in systemd source package in Artful: Confirmed Status in cloud-init source package in Bionic: Confirmed Status in systemd source package in Bionic: Confirmed Bug description: I use no-cloud to test the kernel in CI (I am maintainer of the bcache subsystem), and have been running it successfully under 16.04 cloud images from qemu, using a qemu command that includes: -smbios "type=1,serial=ds=nocloud- net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud- metadata/linuxtst/" As documented here: http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html Under the new 17.10 cloud images, this doesn't work: the network comes up, but name resolution doesn't work-- /etc/resolv.conf is a symlink to a nonexistent file at this point of the boot and systemd-resolved is not running. When I manually hack /etc/resolv.conf in the cloud image to point to 4.2.2.1 it works fine. I don't know if nameservice not working is by design, but it seems like it should work. The documentation states: "With ds=nocloud-net, the seedfrom value must start with http://, https:// or ftp://"; And https is not going to work for a raw IP address. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1734167/+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 1668347] Re: Unable to set bridge_portpriority with networkd
This bug was filed to address *port* priority, not the bridge priority. As mentioned, systemd (networkd) lacks a per-port priority setting; it should mirror path-cost which takes an interface and value, then the interfaces have a [Bridge] section which has the value. -- 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/1668347 Title: Unable to set bridge_portpriority with networkd Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Released Status in systemd source package in Zesty: Fix Released Bug description: [Impact] * Netplan uses systemd-netword provider to configure all sorts of networking settings * However, unlike ifupdown, released versions of systemd do not support setting bridgeport priority, aka `brctl setportprio ` * This prevents full migration from ifupdown to netplan/systemd-networkd for projects like MAAS that do need to configure equal cost; yet differential priority bridge ports. * This is proposal to cherrypick this functionality which essentially accepts one more key in the .network units; and send those values via netlink. [Test Case] * networkd-test.py is executed as part of autopkgtests that configures a bridge, and sets various valid bridge port priorities and verifies from sysfs that those were correctly set by systemd. * Alternativey create a bridge .link unit, and specify .network unit for a bridge port and use Priority=4 setting in the [Bridge] section in the said unit to modify bridge port priority. [Regression Potential] * This is an upstream cherrypick of functionality that will be included in 234 release. However, since MAAS and netplan target stable releases, I would like to cherrypick this functionality all the way back to xenial. This almost a feature, rather than a bugfix, but it is so small and accompanied by regression testsuite that it is almost a tiny bugfix. [Other Info] * Original request to support this feature. 1. root@ubuntu:/run/systemd/network# lsb_release -rd Description:Ubuntu Zesty Zapus (development branch) Release:17.04 2. root@ubuntu:/run/systemd/network# apt-cache policy systemd systemd: Installed: 232-18ubuntu1 Candidate: 232-18ubuntu1 Version table: *** 232-18ubuntu1 500 500 http://archive.ubuntu.com/ubuntu zesty/main amd64 Packages 100 /var/lib/dpkg/status 3. Using a networkd config like this: # cat 10-netplan-eth1.network [Match] MACAddress=52:54:00:12:34:02 Name=eth1 [Network] Bridge=br0 LinkLocalAddressing=no IPv6AcceptRA=no [Bridge] Cost=50 Priority=28 % cat /sys/class/net/br0/brif/eth1/priority 28 4. % cat /sys/class/net/br0/brif/eth1/priority 32 When using ifupdown and /etc/network/interfaces to configure a bridge users are able to specify a bridge port priority: auto br0 iface br0 inet static address 192.168.1.1 bridge_ports eth1 eth2 bridge_portprio eth1 28 bridge_portprio eth2 14 Which results in the bridge hook scripts running: brctl setportprio br0 eth1 28 which is visible via: /sys/class/net/br0/brif/eth2/priority Note, networkd does not mention PortPriority under netdev Bridge section, however, PathCost is mentioned. It appears networkd is missing an implementation. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: systemd 232-18ubuntu1 ProcVersionSignature: Ubuntu 4.10.0-8.10-generic 4.10.0-rc8 Uname: Linux 4.10.0-8-generic x86_64 ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 Date: Mon Feb 27 17:11:32 2017 Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-8-generic root=UUID=900c1e3f-f682-4455-949c-ebdbf60ac6f5 ro console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.10.1-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-zesty dmi.modalias: dmi:bvnSeaBIOS:bvr1.10.1-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-zesty:cvnQEMU:ct1:cvrpc-i440fx-zesty: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-zesty dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1668347/+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
