[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 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
** 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 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] [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 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 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 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
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
** 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
** 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
# 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
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] [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 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 1888726] Re: systemd-udevd regression: some renamed network interfaces stuck in "pending" state
@Dan Just ran into this issue in curtin's vmtest for network_vlan on groovy. I can confirm that if the netplan config includes the driver match on the physical interfaces, then the vlans come up just fine. I was thinking that netplan could inject the driver of the underlying device into the match section. That would help in these situations, however, I know of a few scenarios where this would need to be disabled (On Azure, for example, their Advanced Networking which auto-bonds an SRIOV interface and a HyperV nic together as eth0). Also, this scenario does *NOT* fail for me on Focal, so I'm wondering what changed between either netplan or systemd? Focal: netplan.io 0.99-0ubuntu3~20.04.2 systemd 245.4-4ubuntu3.2 Groovy netplan.io 0.99-0ubuntu6 systemd 246-2ubuntu1 -- 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/1888726 Title: systemd-udevd regression: some renamed network interfaces stuck in "pending" state Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Bug description: Summary: In Ubuntu Server 20.04 LTS and newer, using netplan.io and systemd- networkd, in certain network configurations, renamed network interfaces get stuck in "pending" state and are not configured properly. On boot, system is stuck on "Wait for Network to be Configured" for 2 minutes. How to reproduce: 1. Configure a machine (for example, a virtual machine) with two Ethernet network cards. Make note of MAC addresses of these network cards. 2. Set up netplan with a single configuration file, contents are in the attached "00-static.yaml" file. Replace the MAC addresses to match your setup. IP address configuration is omitted and is not necessary to reproduce the bug. 3. Reboot the system. Expected outcome: 1. System boots in a reasonable time 2. First network interface (wan) is brought up, is not renamed, and is marked as configured by networkd 3. Second network interface (lan) is brought up, renamed, configured for MTU=9000, and is marked as configured by networkd 4. VLAN interface (vlan20) is brought up, renamed, configured for MTU=9000, and is marked as configured by networkd Actual outcome: 1. System boot is delayed by 2 minutes 2. First network interface (wan) is configured as expected 3. Second network interface (lan) is configured as expected 4. VLAN interface (vlan20) seems to be configured as expected, but is stuck in "pending" state according to networkctl list Test environment: Hardware: Virtual machine with the following configuration * 4 amd64 CPU cores (also tested with a single core) * 1 GB RAM * 8 GB disk * 2 network cards (vmxnet3 in VMware, virtio in Parallels) Working as expected: * [1] Ubuntu Server 19.10, kernel 5.3.0-62, netplan.io 0.99-0ubuntu3~19.10.2, systemd+udev 242-7ubuntu3.11 Broken: * [2] Ubuntu Server 19.10, kernel 5.3.0-62, netplan.io 0.99-0ubuntu3~19.10.2, systemd 242-7ubuntu3.11, udev 245.4-4ubuntu3.1 * [3] Ubuntu Server 20.04 LTS, kernel 5.4.0-42, netplan.io 0.99-0ubuntu3~20.04.2, systemd+udev 245.4-4ubuntu3.1 * [4] Ubuntu Server 20.04 LTS, kernel 5.4.0-42, netplan.io 0.99-0ubuntu3~20.04.2, systemd+udev vanilla upstream git e9769453 * [5] Ubuntu Server 20.04 LTS, kernel 5.4.0-42, netplan.io 0.99-0ubuntu3~20.04.2, systemd+udev vanilla upstream git v242 * [6] Ubuntu Server 20.10 daily-live, kernel 5.4.0-26, netplan.io 0.99-0ubuntu5, systemd+udev 245.6-3ubuntu3 [2] As noted above, issue was reproduced in 19.10 by upgrading ONLY udev and libudev1 to ones shipped in focal-updates. [4] It was also reproduced in vanilla upstream systemd, git master commit e9769453. Just installed on top of existing systemd using "sudo ninja -C build install". [5] Interestingly enough, issue also seems to exist in vanilla v242. Either that, or the installation didn't replace the packaged systemd properly. This may hint at some distribution-specific patch that got removed before 20.04. This issue was reproduced in VMware ESXi 6.7U3, VMware Fusion 11.5.5 and Parallels Desktop 15.1.4. This leads me to believe that network card drivers or virtualisation engines do not play part in the issue. Extra observations: To make the example configuration (00-static.yaml) not get stuck in "pending" state, any one of the following options helps: * Remove "set-name" parameter for "lan" interface * Remove "mtu" parameter for "lan" interface * Remove "wan" interface entirely I got some data/logs for each of these scenarios for eoan [1] and focal [3], as well as the original broken config, and put them together in the attached "parallels.tar.gz". Note about Apport: Attached apport report was generated for test environment [2] above. At
[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0
@Rafael It's in both places: https://github.com/koverstreet/bcache-tools/pull/1 I can update the PR there as well; though I don't think upstream cares as Kent's working on bcachefs instead of bcache AFAICT. > I see that you are trying to come up with something nor relying in the kernel fix (to throw the variables again after pivot root, etc..) I think after the systemd discussion upstream: https://github.com/systemd/systemd/pull/16317 The kernel uevent for CACHED_UUID isn't the right way to go long term; all of the information we want is present in the superblock of the devices as they are probed; If we have a 69-bcache.rules with a helper that uses bcache-super-show; we could drop the Ubuntu sauce patch we have; it's just noise (and now it's somewhat unreliable, this bug shows 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in bcache-tools source package in Bionic: Triaged Status in systemd source package in Bionic: Triaged Status in bcache-tools source package in Focal: Confirmed Status in systemd source package in Focal: Triaged Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
@Rafael For bcache-tools changes, bcache-export-cached-uuid needs the full path to bcache-super-show, as PATH is not exported when running from udev. -- 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in bcache-tools source package in Bionic: Triaged Status in systemd source package in Bionic: Triaged Status in bcache-tools source package in Focal: Confirmed Status in systemd source package in Focal: Triaged Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
@ddstreet I'm not sure where upstream is going just yet. For Ubuntu; I think 1) Adjusting the bcache-tools patch to use the full path to bcache- super-show should change; 2) If we fix (1) then I think we can drop the systemd patch from a bug fixing perspective; on the openSUSE image I did testing on; the skip of the dev/disk/by-uuid symlink for backing devices does not *break* the /dev/bcache/by-uuid ; it was missing due to the updated 69-bcache.rules not working. 3) IMO, blkid should not report FS_UUID for bcache backing/cache devices since it's not a Filesystem; we could patch that in blkid directly instead; alternatively since older blkid's may or maynot emit FS_UUID for bcache backing/caching devices the patch to systemd we're caring will avoid creating a useless dev/disk/by-uuid symlink to those devices. -- 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Triaged Status in linux package in Ubuntu: Incomplete Status in linux-signed package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Released Status in bcache-tools source package in Bionic: New Status in linux source package in Bionic: New Status in linux-signed source package in Bionic: New Status in systemd source package in Bionic: New Status in bcache-tools source package in Focal: Confirmed Status in linux source package in Focal: Invalid Status in linux-signed source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in bcache-tools source package in Groovy: Triaged Status in linux source package in Groovy: Incomplete Status in linux-signed source package in Groovy: Confirmed Status in systemd source package in Groovy: Fix Released Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
On Tue, Jun 30, 2020 at 6:35 AM Balint Reczey <1861...@bugs.launchpad.net> wrote: > @raharper I've forwarded the systemd fix for you with minimal tidying of > the commit message https://github.com/systemd/systemd/pull/16317 Thanks! > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1861941 > > Title: > bcache by-uuid links disappear after mounting bcache0 > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Triaged Status in linux package in Ubuntu: Incomplete Status in linux-signed package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Released Status in bcache-tools source package in Bionic: New Status in linux source package in Bionic: New Status in linux-signed source package in Bionic: New Status in systemd source package in Bionic: New Status in bcache-tools source package in Focal: Confirmed Status in linux source package in Focal: Invalid Status in linux-signed source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in bcache-tools source package in Groovy: Triaged Status in linux source package in Groovy: Incomplete Status in linux-signed source package in Groovy: Confirmed Status in systemd source package in Groovy: Fix Released Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
systemd debdiff with a fix to skip creating /dev/disk/by-uuid for bcache backing, caching devices. ** Patch added: "lp1861941-skip-bcache-links.debdiff" https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+attachment/5375730/+files/lp1861941-skip-bcache-links.debdiff -- 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Incomplete Status in linux-signed package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in bcache-tools source package in Focal: New Status in linux source package in Focal: Invalid Status in linux-signed source package in Focal: New Status in systemd source package in Focal: Invalid Status in bcache-tools source package in Groovy: Fix Released Status in linux source package in Groovy: Incomplete Status in linux-signed source package in Groovy: New Status in systemd source package in Groovy: Invalid Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
Updated test to be a bit more resilient. ** Attachment added: "test-bcache-byuuid-links-fixed.sh" https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941/+attachment/5375723/+files/test-bcache-byuuid-links-fixed.sh -- 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Incomplete Status in linux-signed package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in bcache-tools source package in Focal: New Status in linux source package in Focal: Invalid Status in linux-signed source package in Focal: New Status in systemd source package in Focal: Invalid Status in bcache-tools source package in Groovy: Fix Released Status in linux source package in Groovy: Incomplete Status in linux-signed source package in Groovy: New Status in systemd source package in Groovy: Invalid Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
Tarball of a source package with a fix for this issue: bcache-tools_1.0.8.orig.tar.gz bcache-tools_1.0.8-4ubuntu1_amd64.build bcache-tools_1.0.8-4ubuntu1_amd64.buildinfo bcache-tools_1.0.8-4ubuntu1_amd64.changes bcache-tools_1.0.8-4ubuntu1_amd64.deb bcache-tools_1.0.8-4ubuntu1.debian.tar.xz bcache-tools_1.0.8-4ubuntu1.dsc bcache-tools_1.0.8-4ubuntu1_source.build bcache-tools_1.0.8-4ubuntu1_source.buildinfo bcache-tools_1.0.8-4ubuntu1_source.changes bcache-tools-dbgsym_1.0.8-4ubuntu1_amd64.ddeb bcache-tools-debdiff-1.0.8-4_to_1.0.8-4ubuntu1 ** Attachment added: "bcache-tools-fix-lp1861941.tar.gz" https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941/+attachment/5375721/+files/bcache-tools-fix-lp1861941.tar.gz -- 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Incomplete Status in linux-signed package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in bcache-tools source package in Focal: New Status in linux source package in Focal: Invalid Status in linux-signed source package in Focal: New Status in systemd source package in Focal: Invalid Status in bcache-tools source package in Groovy: Fix Released Status in linux source package in Groovy: Incomplete Status in linux-signed source package in Groovy: New Status in systemd source package in Groovy: Invalid Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
debdiff of the changes ** Attachment added: "bcache-tools-debdiff-1.0.8-4_to_1.0.8-4ubuntu1" https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941/+attachment/5375722/+files/bcache-tools-debdiff-1.0.8-4_to_1.0.8-4ubuntu1 -- 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Incomplete Status in linux-signed package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in bcache-tools source package in Focal: New Status in linux source package in Focal: Invalid Status in linux-signed source package in Focal: New Status in systemd source package in Focal: Invalid Status in bcache-tools source package in Groovy: Fix Released Status in linux source package in Groovy: Incomplete Status in linux-signed source package in Groovy: New Status in systemd source package in Groovy: Invalid Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
OK.
I've reviewed the kernel code, and there are no unexpected changes w.r.t
the CACHED_UUID change event. So I don't think we will need any kernel
changes which is good.
With the small change to the 60-persistent-storage.rules to not attempt
to create a /dev/disk/by-uuid symlink for the backing device; instead we
want to only create a /dev/bcache/by-uuid symlink to the bcacheN device
(that is associated with the backing device).
# by-label/by-uuid links (filesystem metadata), skip bcache backing,caching
devices, handled in 69-bcache.rules
ENV{ID_FS_TYPE}=="bcache", GOTO="skip_fs_uuid_enc"
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*",
SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_LABEL_ENC}=="?*",
SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}"
LABEL="skip_fs_uuid_enc"
And then with my previously proposed changed to 69-bcache.rules in place
https://github.com/g2p/bcache-tools/pull/29/files
The test-case works just fine.
--
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/1861941
Title:
bcache by-uuid links disappear after mounting bcache0
Status in bcache-tools package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
Incomplete
Status in linux-signed package in Ubuntu:
New
Status in systemd package in Ubuntu:
Invalid
Status in bcache-tools source package in Focal:
New
Status in linux source package in Focal:
Invalid
Status in linux-signed source package in Focal:
New
Status in systemd source package in Focal:
Invalid
Status in bcache-tools source package in Groovy:
Fix Released
Status in linux source package in Groovy:
Incomplete
Status in linux-signed source package in Groovy:
New
Status in systemd source package in Groovy:
Invalid
Bug description:
1.
root@ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
2.
root@ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
root@ubuntu:~# apt-cache policy linux-image-virtual
linux-image-virtual:
Installed: 5.4.0.12.15
Candidate: 5.4.0.12.15
Version table:
*** 5.4.0.12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic
linux-image-5.4.0-12-generic:
Installed: 5.4.0-12.15
Candidate: 5.4.0-12.15
Version table:
*** 5.4.0-12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/
+ ls -al /dev/bcache/by-uuid/
total 0
drwxr-xr-x 2 root root 60 Feb 4 23:31 .
drwxr-xr-x 3 root root 60 Feb 4 23:31 ..
lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a
-> ../../bcache0
4.
root@ubuntu:~# ls -al /dev/bcache/by-uuid
ls: cannot access '/dev/bcache/by-uuid': No such file or directory
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-12-generic 5.4.0-12.15
ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
Uname: Linux 5.4.0-12-generic x86_64
ApportVersion: 2.20.11-0ubuntu16
Architecture: amd64
Date: Tue Feb 4 23:31:52 2020
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: linux-signed-5.4
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
@Balint I do not thing the fix you're released is correct, can you upload a new version without the scripts? Also, we should fix make-bcache -B to ensure that cset.uuid is not initialized; that may be why the kernel thinks it should emit the CACHED_UUID if the suerpblock of the device has a cset.uuid value (versus None). -- 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: New Status in linux-signed package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in bcache-tools source package in Focal: New Status in linux source package in Focal: Invalid Status in linux-signed source package in Focal: New Status in systemd source package in Focal: Invalid Status in bcache-tools source package in Groovy: Fix Released Status in linux source package in Groovy: New Status in linux-signed source package in Groovy: New Status in systemd source package in Groovy: Invalid Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
Digging deeper and walking through this in a focal vm, I'm seeing some
strange things.
Starting with a clean disk, and just creating the backing device like
so:
make-bcache -B /dev/vdb
We see /dev/bcache0 get created with vdb as the backing device. Now,
after this, I see:
/dev/bcache/by-uuid/ -> ../../bcache0
This is unexpected. It should *only* appear once the bcache0 device is
actively cached; that is the bcache driver should not emit CACHED_UUID,
until the UUID is actually cached, which only happens once we've
registered a cache device with the bcache0 device. We need to look at
the kernel source to see if the SAUCE patch isn't quite right, or some
other part of bcache code has changed.
Next issue, blkid now detects the bcache dev.uuid, and this shows up
like so:
# udevadm test-builtin blkid /sys/class/block/vdb
...
vdb: Probe /dev/vdb with raid and offset=0
ID_FS_UUID=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
ID_FS_UUID_ENC=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
ID_FS_TYPE=bcache
ID_FS_USAGE=other
Note, it shows up as an FS_UUID, but it is *NOT* an fs_uuid; there is no
filesystem on this device at all at this time; it does have a bcache
superblock, note the FS_UUID matches the dev.uuid of the backing device.
# bcache-super-show /dev/vdb
sb.magicok
sb.first_sector 8 [match]
sb.csum 29D6774A332A280B [match]
sb.version 1 [backing device]
dev.label (empty)
dev.uuidd7d7e025-b8d2-43cb-a5df-c240ba1418dc
dev.sectors_per_block 1
dev.sectors_per_bucket 1024
dev.data.first_sector 16
dev.data.cache_mode 0 [writethrough]
dev.data.cache_state0 [detached]
cset.uuid 37b37bc1-e185-4825-8900-579df102b7d6
It's also curious that cset.uuid has a UUID, as there are no csets
created; IMO this is also a bug and it should be 0, null, or empty.
Now, here's where the udev fights over the links. The backing device,
vdb, triggers this rule in 60-persistent-storage.rules:
# by-label/by-uuid links (filesystem metadata)
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*",
SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
This creates confusion due to the CACHED_UUID also being emitted from
the kernel, like so:
root@ubuntu:/run/udev/links# ls -al
/dev/disk/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc
lrwxrwxrwx 1 root root 9 May 21 16:39
/dev/disk/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc -> ../../vdb
root@ubuntu:/run/udev/links# ls -al
/dev/bcache/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc
lrwxrwxrwx 1 root root 13 May 21 16:39
/dev/bcache/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc -> ../../bcache0
There we have two devices both claiming the backing devices dev.uuid
value, with two different block names.
So, in summary, there are two problems to fix:
1) blkid on bcache devices should not report FS_UUID values when
FS_TYPE=bcache; there is no filesystem on it; this will need to be
discussed upstream
2) our kernel (need to check mainline vs. ours) emits CACHED_UUID when
the bcache0 is created, but no cache is attached: see this udev event:
KERNEL[2217.605118] change /devices/virtual/block/bcache0 (block)
ACTION=change
DEVPATH=/devices/virtual/block/bcache0
SUBSYSTEM=block
DRIVER=bcache
CACHED_UUID=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
CACHED_LABEL=
DEVNAME=/dev/bcache0
DEVTYPE=disk
SEQNUM=5890
MAJOR=251
MINOR=0
** Changed in: linux (Ubuntu Groovy)
Status: Invalid => New
** Changed in: linux-signed (Ubuntu Groovy)
Status: Invalid => 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/1861941
Title:
bcache by-uuid links disappear after mounting bcache0
Status in bcache-tools package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
New
Status in linux-signed package in Ubuntu:
New
Status in systemd package in Ubuntu:
Invalid
Status in bcache-tools source package in Focal:
New
Status in linux source package in Focal:
Invalid
Status in linux-signed source package in Focal:
New
Status in systemd source package in Focal:
Invalid
Status in bcache-tools source package in Groovy:
Fix Released
Status in linux source package in Groovy:
New
Status in linux-signed source package in Groovy:
New
Status in systemd source package in Groovy:
Invalid
Bug description:
1.
root@ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
2.
root@ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
root@ubuntu:~# apt-cache policy linux-image-virtual
linux-image-virtual:
Installed: 5.4.0.12.15
Candidate: 5.4.0.12.15
Version table:
*** 5.4.0.12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root@ubuntu:~# apt-cache policy linux-image-5.
[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0
That doesn't explain why they show up sometimes, but not all of the time. There are 3 devices in play here. * The backing device, let's say /dev/vda; this is where we want to store the data. * The caching device, let's say /dev/vdb; this holds the cache. * The bcache device; this only appears when a backing device is detected; via bcache-probe which reads the header on the disk and indicates it's a bcache device. Now, there are a few sequences that we see: 1) make-bcache -b /dev/vda -c /deb/vdb will create a bcache0 with the cache and backing dev at the same time and emit the CACHED_UUID change event which runs *after* 60-persistent-storage, and adds the bcache/by-uuid links 2) After a reboot (or if you tear down a bcache0 by stopping them in sysfs) we have several scenarios where the 2 real block devices are found: 2a) order: backing, bcacheN, caching In this scenario, vda will run through 60-persistent-storage.rules and blkid will discover ID_FS_TYPE=bcache, and generates only by-path, by-id links for the device, 69-bcache.rules will run bcache-register /dev/vda which informs the kernel that a backing device has been found. If the cache device has not yet been handled by udev (we don't know if a cache device exists, bcache can work without one) then the kernel will create a bcacheN device, but without the cache device being present, it will *NOT* emit a CHANGE event with CACHED_UUID value. Now when the cache device (vdb) is going through, 60-persistent-storage.rules, blkid will discover the same settings, TYPE=bcache, generate by-path, by-id symlinks. Then 69-bcache.rules runs, triggers a bcache-register on vdb registering the cache device in the kernel and because the superblock on the backing device specifies the cache device UUID it used the kernel can bind the cache device into the correct bcacheN device. A mainline kernel (no sauce patch) does not emit a CHANGE event with CACHED_UUID value. Our sauce patch changes the kernel to emit the CHANGE event with CACHED_UUID whenever we bind a cache device to an existing bcacheN precisely so the bcache/by-* links get generated. 2b) order: cache, backing, bcacheN Here, when vdb is plugged in, the cache device is registered in the kernel, but without a backing device, no bcacheN device is created yet. Then the backing is probed, as in 2a; the bcache-register command will register it with the kernel, and create a bcache0, and since the cache device is present, mainline kernels (and ours) will emit the CHANGE event with CACHED_UUID With this in-mind; it appears to me that in the focal case we're seeing the bcache driver CHANGE event with CACHED_UUID and then additional change events from the block layer around the bcache0 device (but not emitted from the bcache driver code) So I'd like to understand why ... I expect those events to occur but not before the driver change event. And maybe that's the race here The happy path: 1. udev processing CHANGE on backing device, it's bcache so we register it 2. kernel bcache driver creates a bcache0 block device (udev ADD event) 3. udev processing CHANGE on bcache0 device 4. udev processing CHANGE on cache device, it's bcache so we register it 5. kernel bcache driver emits CHANGE event with CACHED_UUID 6. udev processing CHANGE on bcache0 device with CACHED_UUID The bad path 1. udev processing CHANGE on cache device, it's bcache so we register it 2. udev processing CHANGE on backing device, it's bcache so we register it 3. kernel bcache driver creates a bcache0 block device (udev ADD event) 4. kernel bcache driver emits CHANGE event with CACHED_UUID 5. udev processing CHANGE on bcache0 device with CACHED_UUID 6. udev processing CHANGE on bcache0 device without CACHED_UUID if the bcache change event occurs before the block layer change events, then the database does get clobbered ... but we've an incomplete trace; we should see pairs of events, one from KERNEL, and then one from UDEV. We should definitely get a complete capture for this bug. w.r.t the fix; I've a few concerns: 1) bcache-keep-symlinks relies on /dev/bcache/by-* links to exist, if they are removed, then the keep won't work. 2) The removal of the /dev/bcache/by-uuid/ happens during processing of 60-persistent-storage.rules, which will remove the link before bcache-keep-symlinks can run (it's in 69-bcache.rules) 3) since we cannot rely on the existing links, instead we should read and parse the bcache superblock devices, much like the one I put together (and you reminded me I wrote) https://github.com/g2p/bcache-tools/pull/29/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/1861941 Title: bcache by-uuid links disappear after mounting
[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0
I guess I don't understand why we see this in focal. The two events in
Colin's trace always happen on any Ubuntu kernel. We should see if we
can get another udev trace on bionic that captures both CHANGE events,
one will be from the bcache driver itself, and one is from the block
layer. THe order and content of the change event matter.
Another thing I don't understand is why does udev drop the a symlink created by
another rule? This seems like the core issue.
Looking at systemd/udev source code; udev will do a
FOREACH_DEVICE_DEVLINK and check if the name is in the database file for
the device. Its not clear to me yet how or when the database file get's
written.
The other question I have is: if we reversed the order of the focal
CHANGE events, wouldn't we see just the opposite happen (the
driver=bcache change event would not have all of the devlinks from a
blkid probe) and all of the /dev/disk/by-{id, uuid, ...} get removed
when running
I think the patch you're proposing should work; but I don't think we've
root caused why the link gets removed in the first place. Once we
understand the root cause, I think we can better understand what a fix
should look like.
Lastly, I think we might also test this out on mainline kernel; I wonder if our
SAUCE patch for emitting the CACHED_UUID needs an update (or could be dropped).
--
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/1861941
Title:
bcache by-uuid links disappear after mounting bcache0
Status in bcache-tools package in Ubuntu:
In Progress
Status in linux package in Ubuntu:
Invalid
Status in linux-signed package in Ubuntu:
Invalid
Status in systemd package in Ubuntu:
Invalid
Status in bcache-tools source package in Focal:
New
Status in linux source package in Focal:
Invalid
Status in linux-signed source package in Focal:
New
Status in systemd source package in Focal:
Invalid
Status in bcache-tools source package in Groovy:
In Progress
Status in linux source package in Groovy:
Invalid
Status in linux-signed source package in Groovy:
Invalid
Status in systemd source package in Groovy:
Invalid
Bug description:
1.
root@ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
2.
root@ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
root@ubuntu:~# apt-cache policy linux-image-virtual
linux-image-virtual:
Installed: 5.4.0.12.15
Candidate: 5.4.0.12.15
Version table:
*** 5.4.0.12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic
linux-image-5.4.0-12-generic:
Installed: 5.4.0-12.15
Candidate: 5.4.0-12.15
Version table:
*** 5.4.0-12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/
+ ls -al /dev/bcache/by-uuid/
total 0
drwxr-xr-x 2 root root 60 Feb 4 23:31 .
drwxr-xr-x 3 root root 60 Feb 4 23:31 ..
lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a
-> ../../bcache0
4.
root@ubuntu:~# ls -al /dev/bcache/by-uuid
ls: cannot access '/dev/bcache/by-uuid': No such file or directory
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-12-generic 5.4.0-12.15
ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
Uname: Linux 5.4.0-12-generic x86_64
ApportVersion: 2.20.11-0ubuntu16
Architecture: amd64
Date: Tue Feb 4 23:31:52 2020
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: linux-signed-5.4
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1878752] Re: vgcreate fails on /dev/disk/by-dname block devices
I would very much agree with xnox (it's a duplicate) (and Dan, nothing
for curtin to do);
curtin generated dname rules rely upon pointing to a /dev/bcache/by-
uuid/* symlink which is currently broken per
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941
which at this time points some issue in udev itself (the kernel emits
all of the correct uevents we expect).
And as James' workaround shows; it's *not* always happening; a rescan
can "restore" the links; but that's not 100% reliable.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1878752
Title:
vgcreate fails on /dev/disk/by-dname block devices
Status in OpenStack ceph-osd charm:
New
Status in curtin package in Ubuntu:
Invalid
Status in lvm2 package in Ubuntu:
New
Bug description:
Ubuntu Focal, OpenStack Charmers Next Charms.
juju run-action --wait ceph-osd/0 add-disk osd-devices=/dev/disk/by-
dname/bcache2
unit-ceph-osd-0:
UnitId: ceph-osd/0
id: "5"
message: exit status 1
results:
ReturnCode: 1
Stderr: |
partx: /dev/disk/by-dname/bcache2: failed to read partition table
Failed to find physical volume "/dev/bcache1".
Failed to find physical volume "/dev/bcache1".
Device /dev/disk/by-dname/bcache2 not found.
Traceback (most recent call last):
File "/var/lib/juju/agents/unit-ceph-osd-0/charm/actions/add-disk",
line 79, in
request = add_device(request=request,
File "/var/lib/juju/agents/unit-ceph-osd-0/charm/actions/add-disk",
line 34, in add_device
charms_ceph.utils.osdize(device_path, hookenv.config('osd-format'),
File "lib/charms_ceph/utils.py", line 1497, in osdize
osdize_dev(dev, osd_format, osd_journal,
File "lib/charms_ceph/utils.py", line 1570, in osdize_dev
cmd = _ceph_volume(dev,
File "lib/charms_ceph/utils.py", line 1705, in _ceph_volume
cmd.append(_allocate_logical_volume(dev=dev,
File "lib/charms_ceph/utils.py", line 1965, in
_allocate_logical_volume
lvm.create_lvm_volume_group(vg_name, pv_dev)
File "hooks/charmhelpers/contrib/storage/linux/lvm.py", line 104, in
create_lvm_volume_group
check_call(['vgcreate', volume_group, block_device])
File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['vgcreate',
'ceph-911bc34b-4634-4ebd-a055-876b978d0b0a', '/dev/disk/by-dname/bcache2']'
returned non-zero exit status 5.
Stdout: |2
Physical volume "/dev/disk/by-dname/bcache2" successfully created.
status: failed
timing:
completed: 2020-05-15 06:04:41 + UTC
enqueued: 2020-05-15 06:04:30 + UTC
started: 2020-05-15 06:04:39 + UTC
The same action on the /dev/bcacheX device succeeds - looks like some
sort of behaviour break in Ubuntu.
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-ceph-osd/+bug/1878752/+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 1874501] Re: vgscan --mknodes creates block device multipath nodes in /dev/mapper
Probert PR to drop --mknodes:
https://github.com/canonical/probert/pull/88
Curtin MP to drop --mknodes
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/383141
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1874501
Title:
vgscan --mknodes creates block device multipath nodes in /dev/mapper
Status in Ubuntu on IBM z Systems:
New
Status in lvm2 package in Ubuntu:
Confirmed
Bug description:
Description:Ubuntu 20.04 LTS
Release:20.04
# apt-cache policy multipath-tools
multipath-tools:
Installed: 0.8.3-1ubuntu2
Candidate: 0.8.3-1ubuntu2
Version table:
*** 0.8.3-1ubuntu2 500
500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages
100 /var/lib/dpkg/status
/dev/mapper/mpatha is symlink which points to ../../dm-X device
/dev/mapper/mpath is block device
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: multipath-tools 0.8.3-1ubuntu2
ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
Uname: Linux 5.4.0-26-generic s390x
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27
Architecture: s390x
CasperMD5CheckResult: pass
CasperVersion: 1.445
Date: Thu Apr 23 17:32:12 2020
LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release s390x
(20200423.1)
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: multipath-tools
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.multipath.conf:
defaults {
user_friendly_names yes
skip_kpartx no
verbosity 4
}
mtime.conffile..etc.multipath.conf: 2020-04-23T15:47:28.659850
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874501/+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 1874501] Re: vgscan --mknodes creates block device multipath nodes in /dev/mapper
I don't think this is the right fix. We need to test that it doesn't
prevent vgscan from finding and creating /dev/vg/lv device files outside
of of multipath.
The real fix involves:
1) omitting the call to vgmknodes if there are no volume groups present
2) if vgnodes are present, device_mapper/libdm-common.c should determine if
DM_DISABLE_LIBRARY_FALLBACK should be set in the same way that dmsetup.c does.
I'd much prefer upstream to produce a proper fix.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1874501
Title:
vgscan --mknodes creates block device multipath nodes in /dev/mapper
Status in Ubuntu on IBM z Systems:
New
Status in lvm2 package in Ubuntu:
Confirmed
Bug description:
Description:Ubuntu 20.04 LTS
Release:20.04
# apt-cache policy multipath-tools
multipath-tools:
Installed: 0.8.3-1ubuntu2
Candidate: 0.8.3-1ubuntu2
Version table:
*** 0.8.3-1ubuntu2 500
500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages
100 /var/lib/dpkg/status
/dev/mapper/mpatha is symlink which points to ../../dm-X device
/dev/mapper/mpath is block device
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: multipath-tools 0.8.3-1ubuntu2
ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
Uname: Linux 5.4.0-26-generic s390x
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27
Architecture: s390x
CasperMD5CheckResult: pass
CasperVersion: 1.445
Date: Thu Apr 23 17:32:12 2020
LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release s390x
(20200423.1)
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: multipath-tools
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.multipath.conf:
defaults {
user_friendly_names yes
skip_kpartx no
verbosity 4
}
mtime.conffile..etc.multipath.conf: 2020-04-23T15:47:28.659850
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874501/+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 1874501] Re: vgscan --mknodes creates block device multipath nodes in /dev/mapper
This patch configures the dm_task to use the
DM_UDEV_DISABLE_LIBRARY_FALLBACK udev flag to prevent calls to
dm_mknodes() from using the library fallback code.
Another possible fix would be to obtain a different return code from
vgscan.c where it does not detect any VGs and then calls the mknode
path due to the argument passed to the cli
maxret = process_each_vg(cmd, argc, argv, NULL, NULL, 0, 0, NULL,
&_vgscan_single);
/* at this point, this could return some indication if vgs were found
such that we could skip the vgmknodes() if no vgs were found */
if (arg_is_set(cmd, mknodes_ARG)) {
ret = vgmknodes(cmd, argc, argv);
if (ret > maxret)
maxret = ret;
}
** Patch added: "disable-library-fallback-in-vgscan-mknodes.patch"
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1874501/+attachment/5362656/+files/disable-library-fallback-in-vgscan-mknodes.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1874501
Title:
vgscan --mknodes creates block device multipath nodes in /dev/mapper
Status in Ubuntu on IBM z Systems:
New
Status in lvm2 package in Ubuntu:
Confirmed
Bug description:
Description:Ubuntu 20.04 LTS
Release:20.04
# apt-cache policy multipath-tools
multipath-tools:
Installed: 0.8.3-1ubuntu2
Candidate: 0.8.3-1ubuntu2
Version table:
*** 0.8.3-1ubuntu2 500
500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages
100 /var/lib/dpkg/status
/dev/mapper/mpatha is symlink which points to ../../dm-X device
/dev/mapper/mpath is block device
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: multipath-tools 0.8.3-1ubuntu2
ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
Uname: Linux 5.4.0-26-generic s390x
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27
Architecture: s390x
CasperMD5CheckResult: pass
CasperVersion: 1.445
Date: Thu Apr 23 17:32:12 2020
LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release s390x
(20200423.1)
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: multipath-tools
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.multipath.conf:
defaults {
user_friendly_names yes
skip_kpartx no
verbosity 4
}
mtime.conffile..etc.multipath.conf: 2020-04-23T15:47:28.659850
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874501/+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 1874501] Re: vgscan --mknodes creates block device multipath nodes in /dev/mapper
Note, the whitespace damage in the patch is not needed, just my text client cleaning up trailing whitespace. With this patch applied, vgscan --mknodes no longer creates block devices in /dev/mapper root@ubuntu:/dev/mapper# ls -al total 0 drwxr-xr-x 2 root root 120 Apr 28 16:31 . drwxr-xr-x 17 root root3800 Apr 28 15:25 .. crw--- 1 root root 10, 236 Apr 28 15:22 control lrwxrwxrwx 1 root root 7 Apr 28 16:31 mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Apr 28 16:31 mpatha-part1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Apr 28 16:31 mpatha-part2 -> ../dm-2 root@ubuntu:/dev/mapper# root@ubuntu:/dev/mapper# root@ubuntu:/dev/mapper# ls -al total 0 drwxr-xr-x 2 root root 120 Apr 28 16:31 . drwxr-xr-x 17 root root3800 Apr 28 15:25 .. crw--- 1 root root 10, 236 Apr 28 15:22 control lrwxrwxrwx 1 root root 7 Apr 28 16:31 mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Apr 28 16:31 mpatha-part1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Apr 28 16:31 mpatha-part2 -> ../dm-2 root@ubuntu:/dev/mapper# rm -rf mpatha* root@ubuntu:/dev/mapper# vgscan --mknodes root@ubuntu:/dev/mapper# ls -al total 0 drwxr-xr-x 2 root root 60 Apr 28 16:40 . drwxr-xr-x 17 root root3800 Apr 28 15:25 .. crw--- 1 root root 10, 236 Apr 28 15:22 control The relevant output: 16:40:35.179504 vgscan[55466] toollib.c:2288 No volume groups found. 16:40:35.179806 vgscan[55466] device_mapper/libdm-common.c:2205 WARK: setting a cookie 16:40:35.180137 vgscan[55466] device_mapper/libdm-common.c:2565 Udev cookie 0xd4d8d17 (semid 32786) created 16:40:35.180451 vgscan[55466] device_mapper/libdm-common.c:2585 Udev cookie 0xd4d8d17 (semid 32786) incremented to 1 16:40:35.180762 vgscan[55466] device_mapper/libdm-common.c:2457 Udev cookie 0xd4d8d17 (semid 32786) incremented to 2 16:40:35.181082 vgscan[55466] device_mapper/libdm-common.c:2690 Udev cookie 0xd4d8d17 (semid 32786) assigned to MKNODES task(15) with flags DISABLE_LIBRARY_FALLBACK (0x20) 16:40:35.181398 vgscan[55466] device_mapper/libdm-common.c:2709 WARK: got my cookie, return 1 16:40:35.181714 vgscan[55466] device_mapper/libdm-common.c:2214 WARK: running dmt with DM-DEV_DISABLE_LIBRARY_FALLBACK flag 16:40:35.182048 vgscan[55466] device_mapper/ioctl/libdm-iface.c:1853 dm names [ opencount flush ] [16384] (*1) 16:40:35.182379 vgscan[55466] device_mapper/ioctl/libdm-iface.c:1853 dm mknodes mpatha [ noopencount flush ] [16384] (*1) 16:40:35.182687 vgscan[55466] device_mapper/libdm-common.c:1484 mpatha: Stacking NODE_ADD (253,0) 0:6 0660 [trust_udev] 16:40:35.183004 vgscan[55466] device_mapper/ioctl/libdm-iface.c:1853 dm mknodes mpatha-part2 [ noopencount flush ] [16384] (*1) 16:40:35.183341 vgscan[55466] device_mapper/libdm-common.c:1484 mpatha-part2: Stacking NODE_ADD (253,2) 0:6 0660 [trust_udev] 16:40:35.183648 vgscan[55466] device_mapper/ioctl/libdm-iface.c:1853 dm mknodes mpatha-part1 [ noopencount flush ] [16384] (*1) 16:40:35.183968 vgscan[55466] device_mapper/libdm-common.c:1484 mpatha-part1: Stacking NODE_ADD (253,1) 0:6 0660 [trust_udev] 16:40:35.184275 vgscan[55466] device_mapper/libdm-common.c:2218 WARK: running out path 16:40:35.184563 vgscan[55466] activate/fs.c:492 Syncing device names 16:40:35.184862 vgscan[55466] device_mapper/libdm-common.c:1484 mpatha: Skipping NODE_ADD (253,0) 0:6 0660 [trust_udev] 16:40:35.185163 vgscan[55466] device_mapper/libdm-common.c:1484 mpatha-part2: Skipping NODE_ADD (253,2) 0:6 0660 [trust_udev] 16:40:35.185478 vgscan[55466] device_mapper/libdm-common.c:1484 mpatha-part1: Skipping NODE_ADD (253,1) 0:6 0660 [trust_udev] 16:40:35.185806 vgscan[55466] device_mapper/libdm-config.c:986 report/output_format not found in config: defaulting to basic 16:40:35.186112 vgscan[55466] device_mapper/libdm-config.c:1085 log/report_command_log not found in config: defaulting to 0 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1874501 Title: vgscan --mknodes creates block device multipath nodes in /dev/mapper Status in Ubuntu on IBM z Systems: New Status in lvm2 package in Ubuntu: Confirmed Bug description: Description:Ubuntu 20.04 LTS Release:20.04 # apt-cache policy multipath-tools multipath-tools: Installed: 0.8.3-1ubuntu2 Candidate: 0.8.3-1ubuntu2 Version table: *** 0.8.3-1ubuntu2 500 500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages 100 /var/lib/dpkg/status /dev/mapper/mpatha is symlink which points to ../../dm-X device /dev/mapper/mpath is block device ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: multipath-tools 0.8.3-1ubuntu2 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic s390x NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27
[Touch-packages] [Bug 1867029] Re: Package ifupdown breaks network configuration by cloud-init
** Also affects: ifupdown (Ubuntu) Importance: Undecided Status: New ** Tags added: uec-images -- 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/1867029 Title: Package ifupdown breaks network configuration by cloud-init Status in cloud-init: Confirmed Status in ifupdown package in Ubuntu: New Bug description: It appears the `ifupdown` package breaks networking configuration that cloud-init would normally handle (?) on both providers. The result, if you image an instance with the `ifupdown` package installed, is that the image is not bootable by Azure/AWS. I'm not familiar with how Azure/AWS/etc use cloud-init for network start up however. I'm filing here for now, in case `cloud-init` needs to be more defensive against `ifupdown`. To reproduce with Packer (I confirmed this method): * Add necessary Azure subscription env vars from `ifupdown-bug.json` * `packer build ifupdown-bug.json` * Try to boot an instance with resulting image * Instance will never boot -- more specifically, networking never comes up. See `boot.log` for an example boot To reproduce manually (only a guess, I did not confirm): * Boot 18.04 ubuntu instance * Install ifupdown * Image the instance * Try to boot instance using new image * Instance won't boot I hit this with Packer, creating new images for booting instances in scaling groups -- `ifupdown` is brought in by `salt`. If this is reproducible via manual installation, there could be some backup images/snapshots that are unable to boot though. This appears to be because cloud-init network start up operations are broken by whatever `ifupdown` sysv/systemd scripts perform on boot. With `ifupdown` installed on Azure, `eth0` does not get an IP address, the instance never fully boots according to Azure, and it will enter an error state. On AWS, the instance boots, but network operations like SSH fail. The `boot.log` is from Azure. Eventually `cloud-init` gives an exception (see `exception.log`), but this seems like a secondary issue related to networking being down. I did try to upgrade cloud-init using nightly PPAs (version 20.1 I believe), but no luck. This is on Ubuntu 18.04 instances from Azure marketplace and AWS Canonical AMI, cloud-init version `19.4-33-gbb4131a2-0ubuntu1~18.04.1`. Related: https://github.com/Azure/WALinuxAgent/issues/1612 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1867029/+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 Tue, Feb 25, 2020 at 2:35 PM Scott Moser wrote: > this seemed to "just work" for me. > http://paste.ubuntu.com/p/93dWDPZfZT/ Ah, I didn't check that there was an existing ubuntu/devel branch. Sorry. I've pushed a MR here: https://code.launchpad.net/~raharper/cloud-utils/+git/cloud-utils/+merge/379851 > > -- > 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: Fix Committed Status in cloud-initramfs-tools package in Ubuntu: Confirmed Status in cloud-utils package in Ubuntu: Confirmed 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
** Patch added: "debdiff showing the changes to upload to fix the bug." https://bugs.launchpad.net/cloud-init/+bug/1834875/+attachment/5330894/+files/cloud-utils_0.31-6_to_0.31-7.debdiff -- 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: Fix Committed Status in cloud-initramfs-tools package in Ubuntu: Confirmed Status in cloud-utils package in Ubuntu: Confirmed 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
** Attachment added: "tarball of source package to upload" https://bugs.launchpad.net/cloud-init/+bug/1834875/+attachment/5330895/+files/cloud-utils_0.31-7-gd99b2d76-source.tar.xz -- 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: Fix Committed Status in cloud-initramfs-tools package in Ubuntu: Confirmed Status in cloud-utils package in Ubuntu: Confirmed 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
@Scott, cloud-utils isn't quite new-upstream-snapshot out of the box; the debian dir does not contain the changelog; however, I think I've got this sorted out. I've a MP I can put up; but it only will show the add of the changelog file. I'll attach a debdiff and a source package. -- 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: Fix Committed Status in cloud-initramfs-tools package in Ubuntu: Confirmed Status in cloud-utils package in Ubuntu: Confirmed 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
Here's the upstream changes to growpart I'm suggesting: https://code.launchpad.net/~raharper/cloud-utils/+git/cloud- utils/+merge/379177 I've also proposed on modifications to cloud-init's cc_growpart as a further method to aid debugging if this hit as well as some mitigation around the race. https://github.com/canonical/cloud-init/pull/213 -- 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 1862846] Re: Crash and failure installing focal
** Changed in: curtin (Ubuntu Focal) Status: Triaged => In Progress ** Changed in: curtin (Ubuntu Focal) Assignee: (unassigned) => Ryan Harper (raharper) -- 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/1862846 Title: Crash and failure installing focal Status in subiquity: New Status in curtin package in Ubuntu: In Progress Status in util-linux package in Ubuntu: New Status in curtin source package in Eoan: Invalid Status in util-linux source package in Eoan: New Status in curtin source package in Focal: In Progress Status in util-linux source package in Focal: New Status in util-linux package in Debian: New Bug description: During an install of the daily live image for 20.04 Ubuntu Server, the installer first crashed and restarted itself, then failed to install the system. Attached are the logs left on the install USB key. To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1862846/+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 1862846] Re: Crash and failure installing focal
** Merge proposal linked: https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/379024 -- 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/1862846 Title: Crash and failure installing focal Status in subiquity: New Status in curtin package in Ubuntu: Triaged Status in util-linux package in Ubuntu: New Status in curtin source package in Eoan: Invalid Status in util-linux source package in Eoan: New Status in curtin source package in Focal: Triaged Status in util-linux source package in Focal: New Status in util-linux package in Debian: Unknown Bug description: During an install of the daily live image for 20.04 Ubuntu Server, the installer first crashed and restarted itself, then failed to install the system. Attached are the logs left on the install USB key. To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1862846/+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 1862846] Re: Crash and failure installing focal
@Alberto > I thought the installer would work similarly to what the desktop installer > does with btrfs, where it creates subvolumes for / and /home in the root > partition (as @ and @home). > > On my desktop, when I upgrade I just move @ out of the way (by renaming it) > and the installer creates a new one. > This is kinda nice as you can easily keep/revert to the old rootfs by > just changing which subvol is mounted at boot. Subiquity/curtin does not have support for btrfs subvolumes. -- 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/1862846 Title: Crash and failure installing focal Status in subiquity: New Status in curtin package in Ubuntu: Triaged Status in util-linux package in Ubuntu: New Status in curtin source package in Eoan: Invalid Status in util-linux source package in Eoan: New Status in curtin source package in Focal: Triaged Status in util-linux source package in Focal: New Bug description: During an install of the daily live image for 20.04 Ubuntu Server, the installer first crashed and restarted itself, then failed to install the system. Attached are the logs left on the install USB key. To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1862846/+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 1862846] Re: Crash and failure installing focal
@Lee Thanks for tracking down the util-linux bug. Since this is broken in 2.34 (eoan/focal); I'm thinking we should use sysfs to find the parent via device name walking; Given a kname (nvme0n1p1) of the target partition # look up sysfs path from kname % realpath /sys/class/block/nvme0n1p1 /sys/devices/pci:00/:00:02.0/:05:00.0/nvme/nvme0/nvme0n1/nvme0n1p1 # check if it's a partition % ls -al /sys/devices/pci:00/:00:02.0/:05:00.0/nvme/nvme0/nvme0n1/nvme0n1p1/partition -r--r--r-- 1 root root 4096 Feb 12 08:08 /sys/devices/pci:00/:00:02.0/:05:00.0/nvme/nvme0/nvme0n1/nvme0n1p1/partition # extract parent device path % dirname /sys/devices/pci:00/:00:02.0/:05:00.0/nvme/nvme0/nvme0n1/nvme0n1p1 /sys/devices/pci:00/:00:02.0/:05:00.0/nvme/nvme0/nvme0n1 # extract parent device major/minor % cat /sys/devices/pci:00/:00:02.0/:05:00.0/nvme/nvme0/nvme0n1/dev 259:0 # udev symlinks/dev/block/$MAJOR:$MINOR % ls -al /dev/block/259:0 lrwxrwxrwx 1 root root 10 Jan 18 00:16 /dev/block/259:0 -> ../nvme0n1 % realpath /dev/block/259:0 /dev/nvme0n1 -- 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/1862846 Title: Crash and failure installing focal Status in subiquity: New Status in curtin package in Ubuntu: Triaged Status in util-linux package in Ubuntu: New Status in curtin source package in Eoan: Invalid Status in util-linux source package in Eoan: New Status in curtin source package in Focal: Triaged Status in util-linux source package in Focal: New Bug description: During an install of the daily live image for 20.04 Ubuntu Server, the installer first crashed and restarted itself, then failed to install the system. Attached are the logs left on the install USB key. To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1862846/+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 1862846] Re: Crash and failure installing focal
** Also affects: util-linux (Ubuntu) Importance: Undecided Status: New ** Tags added: rls-ff-incoming ** Also affects: util-linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: curtin (Ubuntu Focal) Importance: High Status: Triaged ** Also affects: util-linux (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: curtin (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: curtin (Ubuntu Eoan) Status: New => Invalid -- 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/1862846 Title: Crash and failure installing focal Status in subiquity: New Status in curtin package in Ubuntu: Triaged Status in util-linux package in Ubuntu: New Status in curtin source package in Eoan: Invalid Status in util-linux source package in Eoan: New Status in curtin source package in Focal: Triaged Status in util-linux source package in Focal: New Bug description: During an install of the daily live image for 20.04 Ubuntu Server, the installer first crashed and restarted itself, then failed to install the system. Attached are the logs left on the install USB key. To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1862846/+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
Yes, this is my read on the issue as well. The trigger is related to the inotify watch that systemd-udevd puts on the disk. Something that might help that we could try per xnox's comment around use of flock. if growpart were to flock /dev/sda (we need to sort out what flags are needed to prevent udev probe and rule execution) prior to running sgdisk, and not release this flock until after partx runs (to inform the kernel of the update) and a udevadm settle (and possibly a trigger of a CHANGE event). This should prevent early reads of the modified but not update-to-date partition data in the kernel. Lastly, another area of exploration is: why isn't a change event emitted when partx runs to update the kernel with new partition data? If there is one, and the rules then generate the correct symlink; another approach for growpart is for it to block until the size of the new partition is correct. growpart calculates what the new size should be; so it could poll for this value thus blocking cloud-init's size check from running until growpart is confident that the kernel has updated the correct value (and the subsequent rules have completed execution)! -- 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 1671951] Re: networkd should allow configuring IPV6 MTU
Verified Eoan systemd 242-7ubuntu3.7 correctly sets IPv6 MTU Verified Bionic systemd 237-3ubuntu10.39 correctly sets IPv6 MTU ** Attachment added: "curtin vmtest logs for ipv6 mtu verification" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+attachment/5326389/+files/bug-1671951-curtin-vmtest-verification-v2.tar.gz -- 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: Unknown 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 Committed 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: Won't Fix Status in cloud-init source package in Eoan: New Status in netplan.io source package in Eoan: Fix Released Status in systemd source package in Eoan: Fix Committed Status in cloud-init source package in Focal: Confirmed Status in netplan.io source package in Focal: Fix Released Status in systemd source package in Focal: Fix Released 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 larg
[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to
Verified VLANs on Eoan using systemd 242-7ubuntu3.7 from -proposed correctly set the MTU to 1500 when specified in the netplan config. ** Attachment added: "curtin vmtest logs for vlan mtu verification" https://bugs.launchpad.net/curtin/+bug/1846232/+attachment/5326388/+files/bug-1846232-curtin-vmtest-verification-v2.tar.gz -- 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: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: Fix Committed Bug description: [impact] vlan interface has wrong mtu, which may cause lost packets due to incorrect mtu [test case] configure a system using the netplan cfg similar to comment 2. alternately, networkd config can be used, similar to: ubuntu@lp1846232-e:/run/systemd/network$ grep . * 10-netplan-ens3.2667.netdev:[NetDev] 10-netplan-ens3.2667.netdev:Name=ens3.2667 10-netplan-ens3.2667.netdev:MTUBytes=1500 10-netplan-ens3.2667.netdev:Kind=vlan 10-netplan-ens3.2667.netdev:[VLAN] 10-netplan-ens3.2667.netdev:Id=2667 10-netplan-ens3.2667.network:[Match] 10-netplan-ens3.2667.network:Name=ens3.2667 10-netplan-ens3.2667.network:[Network] 10-netplan-ens3.2667.network:LinkLocalAddressing=ipv6 10-netplan-ens3.2667.network:Address=1.2.3.4/32 10-netplan-ens3.2667.network:ConfigureWithoutCarrier=yes 10-netplan-ens3.link:[Match] 10-netplan-ens3.link:OriginalName=ens3 10-netplan-ens3.link:[Link] 10-netplan-ens3.link:WakeOnLan=off 10-netplan-ens3.link:MTUBytes=1500 10-netplan-ens3.network:[Match] 10-netplan-ens3.network:Name=ens3 10-netplan-ens3.network:[Network] 10-netplan-ens3.network:LinkLocalAddressing=ipv6 10-netplan-ens3.network:VLAN=ens3.2667 The reboot and check the mtus: ubuntu@lp1846232-e:~$ ip l show ens3 2: ens3: mtu 1504 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:12:99:1b brd ff:ff:ff:ff:ff:ff ubuntu@lp1846232-e:~$ ip l show ens3.2667 3: ens3.2667@ens3: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:12:99:1b brd ff:ff:ff:ff:ff:ff The base interface should have a mtu of only 1500. [regression potential] As this corrects/adjusts the mtu of the interface, regressions would likely involve interface(s) being assigned incorrect mtu values, which then would lead to dropped packets and/or lowered network performance. [scope] this is needed only for Eoan. disco and earlier don't have the patch that introduces this problem, commit 4b151b71320bbee1549afcbad5554a40d90d63b4 focal already has the patches that fix this, commit f6fcc1c2a41eae749467de58453174296b635a69 (and the commit before it) see comment 4 for more details [other info] original 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: f
[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
Cloud-init service starts and will run growpart, etc Feb 06 00:37:26 ubuntu systemd[1]: Starting Initial cloud-init job (pre-networking)... Feb 06 00:37:37 test-xrdpdnvfctsofyygmzan systemd[1]: Starting Initial cloud-init job (metadata service crawler)... Something has modified sdb1 (growpart/sgdisk) so we see a change event, and removal of symlink Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[265]: sdb1: Device (SEQNUM=3353, ACTION=change) is queued Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: sdb1: Updating old name, '/dev/disk/by-partuuid/5e01dd62-6f50-4cd7-8f62-30bb372b58ea' no longer belonging to '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/--8899--/host0/target0:0:0/0:0:0:0/block/sdb/sdb1' Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: read: off=2244476928 len=26214 Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: sdb1: No reference left, removing '/dev/disk/by-partuuid/5e01dd62-6f50-4cd7-8f62-30bb372b58ea' cc_growpart attempts to check if the block device has been resized and fails Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan cloud-init[570]: 2020-02-06 00:37:42,658 - util.py[WARNING]: Running module growpart () failed cloud-init now runs resizefs on sdb1 Feb 06 00:37:43 test-xrdpdnvfctsofyygmzan kernel: EXT4-fs (sdb1): resizing filesystem from 548091 to 7836155 blocks Feb 06 00:37:44 test-xrdpdnvfctsofyygmzan kernel: EXT4-fs (sdb1): resized filesystem to 7836155 Almost a minute later, something triggers a rescan and we see the link return (looks like walinuxagent poking) Feb 06 00:38:14 test-xrdpdnvfctsofyygmzan systemd-udevd[1482]: sdb1: /usr/lib/udev/rules.d/60-persistent-storage.rules:106 LINK 'disk/by-partuuid/5e01dd62-6f50-4cd7-8f62-30bb372b58ea' Feb 06 00:38:14 test-xrdpdnvfctsofyygmzan systemd-udevd[1482]: sdb1: Creating symlink '/dev/disk/by-partuuid/5e01dd62-6f50-4cd7-8f62-30bb372b58ea' to '../../sdb1' -- 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 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to
Eoan vmtests for vlan MTU checks now pass:
(neipa) vlan-mtu % egrep "242-7ubuntu3.3"
output/EoanTestNetworkVlan/logs/install-serial.log
[ 131.271209] cloud-init[765]: Get:12 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 libnss-systemd amd64 242-7ubuntu3.3 [126 kB]
[ 131.281683] cloud-init[765]: Get:13 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 udev amd64 242-7ubuntu3.3 [1202 kB]
[ 131.534129] cloud-init[765]: Get:14 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 libudev1 amd64 242-7ubuntu3.3 [76.9 kB]
[ 131.538365] cloud-init[765]: Get:15 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 systemd-sysv amd64 242-7ubuntu3.3 [9360 B]
[ 131.567844] cloud-init[765]: Get:17 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 libpam-systemd amd64 242-7ubuntu3.3 [130 kB]
[ 131.605061] cloud-init[765]: Get:19 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 systemd amd64 242-7ubuntu3.3 [3440 kB]
[ 132.048959] cloud-init[765]: Get:20 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 libsystemd0 amd64 242-7ubuntu3.3 [262 kB]
[ 137.411834] cloud-init[765]: Preparing to unpack
.../libnss-systemd_242-7ubuntu3.3_amd64.deb ...
[ 137.415407] cloud-init[765]: Unpacking libnss-systemd:amd64 (242-7ubuntu3.3)
over (242-7ubuntu3.2) ...
[ 137.453015] cloud-init[765]: Preparing to unpack
.../udev_242-7ubuntu3.3_amd64.deb ...
[ 137.493093] cloud-init[765]: Unpacking udev (242-7ubuntu3.3) over
(242-7ubuntu3.2) ...
[ 137.718653] cloud-init[765]: Preparing to unpack
.../libudev1_242-7ubuntu3.3_amd64.deb ...
[ 137.722315] cloud-init[765]: Unpacking libudev1:amd64 (242-7ubuntu3.3) over
(242-7ubuntu3.2) ...
[ 137.760023] cloud-init[765]: Setting up libudev1:amd64 (242-7ubuntu3.3) ...
[ 137.824616] cloud-init[765]: Preparing to unpack
.../systemd-sysv_242-7ubuntu3.3_amd64.deb ...
[ 137.827789] cloud-init[765]: Unpacking systemd-sysv (242-7ubuntu3.3) over
(242-7ubuntu3.2) ...
[ 138.148717] cloud-init[765]: Preparing to unpack
.../libpam-systemd_242-7ubuntu3.3_amd64.deb ...
[ 138.153753] cloud-init[765]: Unpacking libpam-systemd:amd64 (242-7ubuntu3.3)
over (242-7ubuntu3.2) ...
[ 138.232109] cloud-init[765]: Preparing to unpack
.../systemd_242-7ubuntu3.3_amd64.deb ...
[ 138.334042] cloud-init[765]: Unpacking systemd (242-7ubuntu3.3) over
(242-7ubuntu3.2) ...
[ 138.888353] cloud-init[765]: Preparing to unpack
.../libsystemd0_242-7ubuntu3.3_amd64.deb ...
[ 138.891850] cloud-init[765]: Unpacking libsystemd0:amd64 (242-7ubuntu3.3)
over (242-7ubuntu3.2) ...
[ 138.952214] cloud-init[765]: Setting up libsystemd0:amd64 (242-7ubuntu3.3)
...
[ 143.816265] cloud-init[765]: Setting up udev (242-7ubuntu3.3) ...
[ 146.749187] cloud-init[765]: Setting up systemd (242-7ubuntu3.3) ...
[ 148.329699] cloud-init[765]: Setting up systemd-sysv (242-7ubuntu3.3) ...
[ 148.333114] cloud-init[765]: Setting up libnss-systemd:amd64
(242-7ubuntu3.3) ...
[ 148.336356] cloud-init[765]: Setting up libpam-systemd:amd64
(242-7ubuntu3.3) ...
[ 189.293271] cloud-init[765]: systemd is already the newest version
(242-7ubuntu3.3).
(neipa) vlan-mtu % cat
output/EoanTestNetworkVlan/collect/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 reboot. 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:
addresses:
- 10.245.168.16/21
gateway4: 10.245.168.1
match:
macaddress: d4:be:d9:a8:49:13
mtu: 1500
nameservers:
addresses:
- 10.245.168.2
set-name: interface0
interface1:
addresses:
- 10.245.188.2/24
match:
macaddress: d4:be:d9:a8:49:15
mtu: 1500
nameservers:
addresses:
- 10.245.168.2
search:
- dellstack
set-name: interface1
interface2:
match:
macaddress: d4:be:d9:a8:49:17
mtu: 1500
set-name: interface2
interface3:
match:
macaddress: d4:be:d9:a8:49:19
mtu: 1500
set-name: interface3
vlans:
interface1.2667:
addresses:
- 10.245.184.2/24
id: 2667
link: interface1
mtu: 1500
nameservers:
addresses:
- 10.245.168.2
search:
- dellstack
interface1.2668:
addresses:
- 10.245.185.1/24
id: 2668
link: interface1
mtu: 1500
nameservers:
addresses:
[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to
** Attachment added: "curtin vmtest logs for vlan mtu issue" https://bugs.launchpad.net/curtin/+bug/1846232/+attachment/5325684/+files/bug-1846232-curtin-vmtest-verification.tar.gz -- 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: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: Fix Committed Bug description: [impact] vlan interface has wrong mtu, which may cause lost packets due to incorrect mtu [test case] configure a system using the netplan cfg similar to comment 2. alternately, networkd config can be used, similar to: ubuntu@lp1846232-e:/run/systemd/network$ grep . * 10-netplan-ens3.2667.netdev:[NetDev] 10-netplan-ens3.2667.netdev:Name=ens3.2667 10-netplan-ens3.2667.netdev:MTUBytes=1500 10-netplan-ens3.2667.netdev:Kind=vlan 10-netplan-ens3.2667.netdev:[VLAN] 10-netplan-ens3.2667.netdev:Id=2667 10-netplan-ens3.2667.network:[Match] 10-netplan-ens3.2667.network:Name=ens3.2667 10-netplan-ens3.2667.network:[Network] 10-netplan-ens3.2667.network:LinkLocalAddressing=ipv6 10-netplan-ens3.2667.network:Address=1.2.3.4/32 10-netplan-ens3.2667.network:ConfigureWithoutCarrier=yes 10-netplan-ens3.link:[Match] 10-netplan-ens3.link:OriginalName=ens3 10-netplan-ens3.link:[Link] 10-netplan-ens3.link:WakeOnLan=off 10-netplan-ens3.link:MTUBytes=1500 10-netplan-ens3.network:[Match] 10-netplan-ens3.network:Name=ens3 10-netplan-ens3.network:[Network] 10-netplan-ens3.network:LinkLocalAddressing=ipv6 10-netplan-ens3.network:VLAN=ens3.2667 The reboot and check the mtus: ubuntu@lp1846232-e:~$ ip l show ens3 2: ens3: mtu 1504 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:12:99:1b brd ff:ff:ff:ff:ff:ff ubuntu@lp1846232-e:~$ ip l show ens3.2667 3: ens3.2667@ens3: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:12:99:1b brd ff:ff:ff:ff:ff:ff The base interface should have a mtu of only 1500. [regression potential] As this corrects/adjusts the mtu of the interface, regressions would likely involve interface(s) being assigned incorrect mtu values, which then would lead to dropped packets and/or lowered network performance. [scope] this is needed only for Eoan. disco and earlier don't have the patch that introduces this problem, commit 4b151b71320bbee1549afcbad5554a40d90d63b4 focal already has the patches that fix this, commit f6fcc1c2a41eae749467de58453174296b635a69 (and the commit before it) see comment 4 for more details [other info] original 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' multica
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Curtin vmtest verification for bionic using systemd from -proposed has
run successfully.
(neipa) ipv6_mtu % egrep "237-3ubuntu10.34"
output/BionicTestNetworkMtu/logs/install-serial.log
[ 126.923480] cloud-init[1176]: Get:10 http://archive.ubuntu.com/ubuntu
bionic-proposed/main amd64 libsystemd0 amd64 237-3ubuntu10.34 [206 kB]
[ 126.999639] cloud-init[1176]: Get:11 http://archive.ubuntu.com/ubuntu
bionic-proposed/main amd64 libnss-systemd amd64 237-3ubuntu10.34 [104 kB]
[ 127.012854] cloud-init[1176]: Get:12 http://archive.ubuntu.com/ubuntu
bionic-proposed/main amd64 libpam-systemd amd64 237-3ubuntu10.34 [107 kB]
[ 127.018126] cloud-init[1176]: Get:13 http://archive.ubuntu.com/ubuntu
bionic-proposed/main amd64 systemd amd64 237-3ubuntu10.34 [2910 kB]
[ 127.112992] cloud-init[1176]: Get:14 http://archive.ubuntu.com/ubuntu
bionic-proposed/main amd64 udev amd64 237-3ubuntu10.34 [1101 kB]
[ 127.230646] cloud-init[1176]: Get:15 http://archive.ubuntu.com/ubuntu
bionic-proposed/main amd64 libudev1 amd64 237-3ubuntu10.34 [55.4 kB]
[ 127.237607] cloud-init[1176]: Get:16 http://archive.ubuntu.com/ubuntu
bionic-proposed/main amd64 systemd-sysv amd64 237-3ubuntu10.34 [13.2 kB]
[ 130.615970] cloud-init[1176]: Preparing to unpack
.../libsystemd0_237-3ubuntu10.34_amd64.deb ...
[ 130.619809] cloud-init[1176]: Unpacking libsystemd0:amd64 (237-3ubuntu10.34)
over (237-3ubuntu10.33) ...
[ 130.671345] cloud-init[1176]: Setting up libsystemd0:amd64
(237-3ubuntu10.34) ...
[ 130.734901] cloud-init[1176]: Preparing to unpack
.../libnss-systemd_237-3ubuntu10.34_amd64.deb ...
[ 130.738718] cloud-init[1176]: Unpacking libnss-systemd:amd64
(237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 130.775590] cloud-init[1176]: Preparing to unpack
.../libpam-systemd_237-3ubuntu10.34_amd64.deb ...
[ 130.780829] cloud-init[1176]: Unpacking libpam-systemd:amd64
(237-3ubuntu10.34) over (237-3ubuntu10.33) ...
[ 130.817036] cloud-init[1176]: Preparing to unpack
.../systemd_237-3ubuntu10.34_amd64.deb ...
[ 130.938621] cloud-init[1176]: Unpacking systemd (237-3ubuntu10.34) over
(237-3ubuntu10.33) ...
[ 131.534337] cloud-init[1176]: Preparing to unpack
.../udev_237-3ubuntu10.34_amd64.deb ...
[ 131.631496] cloud-init[1176]: Unpacking udev (237-3ubuntu10.34) over
(237-3ubuntu10.33) ...
[ 131.877032] cloud-init[1176]: Preparing to unpack
.../libudev1_237-3ubuntu10.34_amd64.deb ...
[ 131.880841] cloud-init[1176]: Unpacking libudev1:amd64 (237-3ubuntu10.34)
over (237-3ubuntu10.33) ...
[ 131.921311] cloud-init[1176]: Setting up libudev1:amd64 (237-3ubuntu10.34)
...
[ 131.923955] cloud-init[1176]: Setting up systemd (237-3ubuntu10.34) ...
[ 132.376367] cloud-init[1176]: Preparing to unpack
.../systemd-sysv_237-3ubuntu10.34_amd64.deb ...
[ 132.379899] cloud-init[1176]: Unpacking systemd-sysv (237-3ubuntu10.34) over
(237-3ubuntu10.33) ...
[ 135.341098] cloud-init[1176]: Setting up libnss-systemd:amd64
(237-3ubuntu10.34) ...
[ 135.355290] cloud-init[1176]: Setting up systemd-sysv (237-3ubuntu10.34) ...
[ 135.897825] cloud-init[1176]: Setting up udev (237-3ubuntu10.34) ...
[ 136.901473] cloud-init[1176]: Setting up libpam-systemd:amd64
(237-3ubuntu10.34) ...
[ 141.343998] cloud-init[1176]: Processing triggers for systemd
(237-3ubuntu10.34) ...
[ 181.788269] cloud-init[1176]: systemd is already the newest version
(237-3ubuntu10.34).
(neipa) ipv6_mtu % cat
output/BionicTestNetworkMtu/collect/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 reboot. 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:
addresses:
- 192.168.1.2/24
- 2001:4800:78ff:1b:be76:4eff:fe06:1000/64
ipv6-mtu: 1501
match:
macaddress: '52:54:00:12:34:00'
mtu: 1601
set-name: interface0
interface1:
addresses:
- 192.168.2.2/24
- 2001:4800:78ff:1b:be76:4eff:fe06:2000/64
ipv6-mtu: 1501
match:
macaddress: '52:54:00:12:34:02'
mtu: 1501
set-name: interface1
interface2:
dhcp4: true
match:
macaddress: '52:54:00:12:34:04'
set-name: interface2
interface4:
addresses:
- 2001:4800:78ff:1b:be76:4eff:fe06:5000/64
- 192.168.5.2/24
ipv6-mtu: 8900
match:
macaddress: '52:54:00:12:34:08'
mtu: 9000
set-name: interface4
interface5:
addresses:
- 2001:4800:78ff:1b:be76:4eff:fe06:6000/64
- 192.168.6.2/24
ipv6-mtu: 1480
match:
mac
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Curtin vmtest verification for eoan using systemd from -proposed has run
successfully.
(neipa) ipv6_mtu % egrep "242-7ubuntu3.3"
output/EoanTestNetworkMtu/logs/install-serial.log
[ 136.520219] cloud-init[765]: Get:12 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 libnss-systemd amd64 242-7ubuntu3.3 [126 kB]
[ 136.527400] cloud-init[765]: Get:13 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 udev amd64 242-7ubuntu3.3 [1202 kB]
[ 136.693312] cloud-init[765]: Get:14 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 libudev1 amd64 242-7ubuntu3.3 [76.9 kB]
[ 136.701002] cloud-init[765]: Get:15 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 systemd-sysv amd64 242-7ubuntu3.3 [9360 B]
[ 136.722467] cloud-init[765]: Get:17 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 libpam-systemd amd64 242-7ubuntu3.3 [130 kB]
[ 136.743657] cloud-init[765]: Get:19 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 systemd amd64 242-7ubuntu3.3 [3440 kB]
[ 137.138458] cloud-init[765]: Get:20 http://archive.ubuntu.com/ubuntu
eoan-proposed/main amd64 libsystemd0 amd64 242-7ubuntu3.3 [262 kB]
[ 142.884502] cloud-init[765]: Preparing to unpack
.../libnss-systemd_242-7ubuntu3.3_amd64.deb ...
[ 142.887869] cloud-init[765]: Unpacking libnss-systemd:amd64 (242-7ubuntu3.3)
over (242-7ubuntu3.2) ...
[ 142.924747] cloud-init[765]: Preparing to unpack
.../udev_242-7ubuntu3.3_amd64.deb ...
[ 142.962745] cloud-init[765]: Unpacking udev (242-7ubuntu3.3) over
(242-7ubuntu3.2) ...
[ 143.165029] cloud-init[765]: Preparing to unpack
.../libudev1_242-7ubuntu3.3_amd64.deb ...
[ 143.168604] cloud-init[765]: Unpacking libudev1:amd64 (242-7ubuntu3.3) over
(242-7ubuntu3.2) ...
[ 143.206268] cloud-init[765]: Setting up libudev1:amd64 (242-7ubuntu3.3) ...
[ 143.272647] cloud-init[765]: Preparing to unpack
.../systemd-sysv_242-7ubuntu3.3_amd64.deb ...
[ 143.275554] cloud-init[765]: Unpacking systemd-sysv (242-7ubuntu3.3) over
(242-7ubuntu3.2) ...
[ 143.594537] cloud-init[765]: Preparing to unpack
.../libpam-systemd_242-7ubuntu3.3_amd64.deb ...
[ 143.599803] cloud-init[765]: Unpacking libpam-systemd:amd64 (242-7ubuntu3.3)
over (242-7ubuntu3.2) ...
[ 143.680250] cloud-init[765]: Preparing to unpack
.../systemd_242-7ubuntu3.3_amd64.deb ...
[ 143.785319] cloud-init[765]: Unpacking systemd (242-7ubuntu3.3) over
(242-7ubuntu3.2) ...
[ 144.362457] cloud-init[765]: Preparing to unpack
.../libsystemd0_242-7ubuntu3.3_amd64.deb ...
[ 144.366022] cloud-init[765]: Unpacking libsystemd0:amd64 (242-7ubuntu3.3)
over (242-7ubuntu3.2) ...
[ 144.423950] cloud-init[765]: Setting up libsystemd0:amd64 (242-7ubuntu3.3)
...
[ 149.340746] cloud-init[765]: Setting up udev (242-7ubuntu3.3) ...
[ 152.700118] cloud-init[765]: Setting up systemd (242-7ubuntu3.3) ...
[ 154.478301] cloud-init[765]: Setting up systemd-sysv (242-7ubuntu3.3) ...
[ 154.481899] cloud-init[765]: Setting up libnss-systemd:amd64
(242-7ubuntu3.3) ...
[ 154.485400] cloud-init[765]: Setting up libpam-systemd:amd64
(242-7ubuntu3.3) ...
[ 198.012728] cloud-init[765]: systemd is already the newest version
(242-7ubuntu3.3).
(neipa) ipv6_mtu % cat
output/EoanTestNetworkMtu/collect/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 reboot. 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:
addresses:
- 192.168.1.2/24
- 2001:4800:78ff:1b:be76:4eff:fe06:1000/64
ipv6-mtu: 1501
match:
macaddress: '52:54:00:12:34:00'
mtu: 1601
set-name: interface0
interface1:
addresses:
- 192.168.2.2/24
- 2001:4800:78ff:1b:be76:4eff:fe06:2000/64
ipv6-mtu: 1501
match:
macaddress: '52:54:00:12:34:02'
mtu: 1501
set-name: interface1
interface2:
dhcp4: true
match:
macaddress: '52:54:00:12:34:04'
set-name: interface2
interface4:
addresses:
- 2001:4800:78ff:1b:be76:4eff:fe06:5000/64
- 192.168.5.2/24
ipv6-mtu: 8900
match:
macaddress: '52:54:00:12:34:08'
mtu: 9000
set-name: interface4
interface5:
addresses:
- 2001:4800:78ff:1b:be76:4eff:fe06:6000/64
- 192.168.6.2/24
ipv6-mtu: 1480
match:
macaddress: 52:54:00:12:34:0c
mtu: 1480
set-name: interface5
(neipa) ipv6_mtu % grep . output/EoanTestNetworkMtu/collect/interface0_*
output/EoanTestNetworkMtu/collect/interface0_dev_mtu:1601
ou
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
** Attachment added: "curtin vmtest logs for ipv6 mtu verification" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+attachment/5325665/+files/bug-1671951-curtin-vmtest-verification.tar.gz -- 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: Unknown 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 Committed 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: Won't Fix Status in cloud-init source package in Eoan: New Status in netplan.io source package in Eoan: Fix Released Status in systemd source package in Eoan: Fix Committed Status in cloud-init source package in Focal: Confirmed Status in netplan.io source package in Focal: Fix Released Status in systemd source package in Focal: Fix Released 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/systemd/+bug/1671951/+subscriptions
[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 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 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
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
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 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
[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
[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
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 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 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 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
@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
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
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
[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
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
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 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 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
@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 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 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
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
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
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
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 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
[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
[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 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 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 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 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 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 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
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
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 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
[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
This may now be a cloud-init bug if the support is there since this is
a network-config v1 -> cloud-init renders netplan.
On Fri, Sep 28, 2018 at 9:12 AM Scott Moser wrote:
>
> Hm...
>
> Our tests show that this is not fixed in cosmic or bionic.
>
> https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel-amd64/533/console
> shows curtin's vmtest failing. Partial output shows:
>
> ==
> ERROR: test_ipv6_mtu_smaller_than_ipv4_v6_iface_first
> (vmtests.test_network_mtu.CosmicTestNetworkMtu)
> --
> Traceback (most recent call last):
> File
> "/var/lib/jenkins/slaves/torkoal/workspace/curtin-vmtest-devel-amd64/curtin-533/tests/vmtests/__init__.py",
> line 468, in wrapper
> raise RuntimeError(msg)
> RuntimeError:
> skip_by_date(CosmicTestNetworkMtu.test_ipv6_mtu_smaller_than_ipv4_v6_iface_first)
> LP: #1671951 fixby=2018-09-26 removeby=2018-10-17: (PAST_FIXBY) Failed: 1480
> != 1500
> >> begin captured stdout << -
> iface=interface4 subnets=[{'address':
> '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 'type': 'static',
> 'mtu': 1480}, {'address': '192.168.5.2/24', 'type': 'static', 'mtu': 1501}]
> subnet:{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64,
> 'type': 'static', 'mtu': 1480}
> mtu_data:{'device': 1500, 'ipv6': 1500}
> subnet_mtu=1480 ipv6_mtu=1500
>
> - >> end captured stdout << --
>
>
> ** Attachment added: "console log of curtin vmtest amd64 533"
>
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+attachment/5194078/+files/curtin-vmtest-devel-amd64-533-console.log
>
> --
> 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/systemd/+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:
New
Status in netplan.io package in Ubuntu:
New
Status in systemd package in Ubuntu:
Fix Released
Status in cloud-init source package in Bionic:
New
Status in netplan.io source package in Bionic:
New
Status in systemd source package in Bionic:
New
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/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
Actually there needs to be changes to netplan to emit the correct IPV6BytesMtu setting to networkd; and then cloud-init can emit the correct netplan yaml for that. This feature is on the netplan roadmap here: https://trello.com/c/nIjLIRSG/6-support-ipv6-mtu-bytes-configuration ** Also affects: netplan.io (Ubuntu) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu) 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/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: New Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New 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/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 1789758] [NEW] bluetooth headphones a2dp profile does not function after suspend
Public bug reported: 1) lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 2) $ apt-cache policy bluez bluez: Installed: 5.48-0ubuntu3.1 Candidate: 5.48-0ubuntu3.1 Version table: *** 5.48-0ubuntu3.1 500 500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 5.48-0ubuntu3 500 500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages 3) bluetooth headphones stay working in a2dp mode even after suspend 4) bluetooth headphones connect but no sound will come out of a2dp mode, only in HSP profile ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: bluez 5.48-0ubuntu3.1 ProcVersionSignature: Ubuntu 4.15.0-30.32-generic 4.15.18 Uname: Linux 4.15.0-30-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Aug 29 18:07:26 2018 InstallationDate: Installed on 2018-05-26 (95 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180525) InterestingModules: rfcomm bnep btusb bluetooth ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-30-generic root=UUID=9e84ffd4-d629-4dcd-a6c4-6648d1a34665 ro quiet splash vt.handoff=1 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/16/2015 dmi.bios.vendor: Intel Corp. dmi.bios.version: RKPPT10H.86A.0041.2015.0316.1442 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: D53427RKE dmi.board.vendor: Intel Corporation dmi.board.version: G87971-406 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrRKPPT10H.86A.0041.2015.0316.1442:bd03/16/2015:svn:pn:pvr:rvnIntelCorporation:rnD53427RKE:rvrG87971-406:cvn:ct3:cvr: dmi.product.family: To be filled by O.E.M. hciconfig: hci0: Type: Primary Bus: USB BD Address: 48:51:B7:07:93:F5 ACL MTU: 1021:5 SCO MTU: 96:5 DOWN RX bytes:5617087 acl:790 sco:22622 events:634625 errors:0 TX bytes:540631745 acl:632348 sco:22584 commands:537 errors:0 ** Affects: bluez (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1789758 Title: bluetooth headphones a2dp profile does not function after suspend Status in bluez package in Ubuntu: New Bug description: 1) lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 2) $ apt-cache policy bluez bluez: Installed: 5.48-0ubuntu3.1 Candidate: 5.48-0ubuntu3.1 Version table: *** 5.48-0ubuntu3.1 500 500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 5.48-0ubuntu3 500 500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages 3) bluetooth headphones stay working in a2dp mode even after suspend 4) bluetooth headphones connect but no sound will come out of a2dp mode, only in HSP profile ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: bluez 5.48-0ubuntu3.1 ProcVersionSignature: Ubuntu 4.15.0-30.32-generic 4.15.18 Uname: Linux 4.15.0-30-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Aug 29 18:07:26 2018 InstallationDate: Installed on 2018-05-26 (95 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180525) InterestingModules: rfcomm bnep btusb bluetooth ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-30-generic root=UUID=9e84ffd4-d629-4dcd-a6c4-6648d1a34665 ro quiet splash vt.handoff=1 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/16/2015 dmi.bios.vendor: Intel Corp. dmi.bios.version: RKPPT10H.86A.0041.2015.0316.1442 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: D53427RKE dmi.board.vendor: Intel Corporation dmi.board.version: G87971-406 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrRKPPT10H.86A.0041.2015.0316.1442:bd03/16/2015:svn:pn:pvr:rvnIntelCorporation:rnD53427RKE:rvrG87971-406:cvn:ct3:cvr: dmi.product.family: To be filled by O.E.M. hciconfig: hci0:Type: Primary Bus: USB BD Address: 48:51:B7:07:93:F5 ACL MTU: 1021:5 SCO MTU: 96:5 DOWN RX bytes:5617087 acl:790 sco:22622 events:634625 errors:0 TX bytes:540631745 acl:632348 sco:22584 commands:537 errors:0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1789758/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad
Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
On Wed, Aug 29, 2018 at 8:41 AM Dimitri John Ledkov wrote: > > Do we need this in bionic? Yes > > -- > 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/systemd/+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 systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: New 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 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
