[Touch-packages] [Bug 1829665] Re: Network Manager and upower not starting, libhogweed error
[Expired for nettle (Ubuntu) because there has been no activity for 60 days.] ** Changed in: nettle (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nettle in Ubuntu. https://bugs.launchpad.net/bugs/1829665 Title: Network Manager and upower not starting, libhogweed error Status in nettle package in Ubuntu: Expired Bug description: After updating Lubuntu 18.10 to 19.04, NetworkManager and upower no longer start. After a bit of digging it shows the source to be libhogweed4 v3.4.1-1. The error is: relocation error: /usr/lib/x86_64-linux-gnu/libgnutls.so.30: symbol nettle_rsa_sec_decrypt version HOGWEED_4 not defined in file libhogweed.so.4 with link time reference To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nettle/+bug/1829665/+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 1938195] Re: Configuration for eGPU removed on update
Judging by the top of the config file it sounds like the Nvidia driver writing and overwriting it. There was an update to nvidia-graphics- drivers-460 on 21 July. In theory this is what /usr/share/X11/xorg.conf.d/ is for, to add custom configs that other packages won't touch. But I don't know if spreading the nvidia config across multiple files with potentially duplicate sections would work. ** Package changed: xorg (Ubuntu) => nvidia-graphics-drivers-460 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1938195 Title: Configuration for eGPU removed on update Status in nvidia-graphics-drivers-460 package in Ubuntu: New Bug description: ThinkPad X1C9 running Kubuntu. I'm using an external nVidia GPU in an enclosure, attached via thunderbolt. I have applied updates over the last few weeks, and rebooted today. Got a black screen. Turns out an update back in mid June (22nd) removed the Option "AllowExternalGpus" "true" from my xorg.conf. Why is an update removing a vital configuration option enabling me to display my login screen? I had to re-edit the xorg.conf like an cave man from 20 years ago. ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: xorg 1:7.7+22ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia .proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file. .proc.driver.nvidia.capabilities.mig: Error: path was not a regular file. .proc.driver.nvidia.gpus..52.00.0: Error: path was not a regular file. .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 460.91.03 Fri Jul 2 06:04:10 UTC 2021 GCC version: ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: KDE Date: Tue Jul 27 16:42:11 2021 DistUpgraded: Fresh install DistroCodename: hirsute DistroVariant: ubuntu DkmsStatus: tp_smapi, 0.43, 5.11.0-22-generic, x86_64: installed tp_smapi, 0.43, 5.11.0-25-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Lenovo Iris Xe Graphics [17aa:22d5] NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GP107 [GeForce GTX 1050 Ti] [1043:85d1] InstallationDate: Installed on 2021-05-14 (73 days ago) InstallationMedia: Kubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) MachineType: LENOVO 20XWCTO1WW ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-25-generic root=UUID=f73d534c-9211-43d9-a8d5-fe9b6bb3 ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/26/2021 dmi.bios.release: 1.23 dmi.bios.vendor: LENOVO dmi.bios.version: N32ET47W (1.23 ) dmi.board.asset.tag: Not Available dmi.board.name: 20XWCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrN32ET47W(1.23):bd03/26/2021:br1.23:efr1.22:svnLENOVO:pn20XWCTO1WW:pvrThinkPadX1CarbonGen9:rvnLENOVO:rn20XWCTO1WW:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon Gen 9 dmi.product.name: 20XWCTO1WW dmi.product.sku: LENOVO_MT_20XW_BU_Think_FM_ThinkPad X1 Carbon Gen 9 dmi.product.version: ThinkPad X1 Carbon Gen 9 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.105-3~21.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.1-2 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-460/+bug/1938195/+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.lau
[Touch-packages] [Bug 1934995] Re: Broken on ppc64el (toolchain bug?)
** Also affects: mir (Ubuntu) Importance: Undecided Status: New ** Changed in: glibc (Ubuntu) Status: New => Invalid ** Changed in: umockdev (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mir in Ubuntu. https://bugs.launchpad.net/bugs/1934995 Title: Broken on ppc64el (toolchain bug?) Status in glibc package in Ubuntu: Invalid Status in mir package in Ubuntu: New Status in umockdev package in Ubuntu: Invalid Bug description: umockdev appears to be broken on ppc64el in impish. Running it on one of Mir's umockdev-using tests results in: (impish-ppc64el)root@juju-deb017-porterbox-1:/build/mir-Xn1VqE/umockdev# umockdev-run ../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests MIR_CLIENT_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/client-modules/ MIR_SERVER_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/server-modules/ LD_LIBRARY_PATH=../mir-2.4.1/build-ppc64el/bin/../lib exec=../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests.bin *** stack smashing detected ***: terminated umockdev-run: unable to propagate signal 6 to child 15833: No such process (You can also see this in the Mir 2.4.1-0ubuntu1 build log: https://launchpadlibrarian.net/546972958/buildlog_ubuntu-impish- ppc64el.mir_2.4.1-0ubuntu1_BUILDING.txt.gz ) Installing umockdev 0.15.4-1 and libumockdev0 0.15.4-1 from hirsute results in those tests passing. Strangely, rebuilding umockdev 0.15.4-1 in a hirsute sbuild environment results in packages that do *not* pass those tests, suggesting a toolchain change might be responsible. Unfortunately, I've tried rebuilding umockdev with gcc-9, gcc-11, and vala 0.48.12-1 in Impish and none of these appear to work. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: umockdev 0.16.1-1 ProcVersionSignature: Ubuntu 5.11.0-20.21+21.10.1-generic 5.11.21 Uname: Linux 5.11.0-20-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu67 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Jul 8 16:04:15 2021 InstallationDate: Installed on 2021-06-26 (11 days ago) InstallationMedia: Ubuntu 21.10.0 2021.05.28 amd64 "bcachefs" (20210622) SourcePackage: umockdev UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1934995/+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 1427600] Re: apport-unpack: ValueError: ['UserGroups'] has no binary content
** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1427600 Title: apport-unpack: ValueError: ['UserGroups'] has no binary content Status in apport package in Ubuntu: Fix Released Status in apport source package in Xenial: Triaged Status in apport source package in Focal: Fix Released Status in apport source package in Groovy: Fix Released Bug description: [Impact] apport-unpack crashes when trying to unpack a crash [Test Case] On a system running 20.04 LTS: 1) create an additional user who is only a member of their own group e.g. bdmurray@clean-focal-amd64:~$ id crashy uid=1001(crashy) gid=1001(crashy) groups=1001(crashy) 2) Launch a process as that user 3) kill -11 that process 4) Confirm there is a crash file in /var/crash for that process 5) Run apport-unpack on that .crash file With the version of apport from -proposed you will not get another crash file when unpacking the crash file. [Regression Potential] We are just setting UserGroups to 'N/A' as opposed to having it be completely empty so there isn't any chance for regression. When running apport-unpack to get at a core dump laney@raleigh> sudo apport-unpack _usr_lib_x86_64-linux-gnu_urfkill_urfkilld.0.crash ~/temp/zozoz [sudo] password for laney: Traceback (most recent call last): File "/usr/bin/apport-unpack", line 73, in pr.extract_keys(f, bin_keys, dir) File "/usr/lib/python3/dist-packages/problem_report.py", line 253, in extract_keys [item for item, element in b64_block.items() if element is False]) ValueError: ['UserGroups'] has no binary content laney@raleigh> apport-cli --version 2.16.2 It's not terrible, because most files are unpacked (those which sort before UserGroups, I guess). ProblemType: BugDistroRelease: Ubuntu 15.04 Package: apport 2.16.2-0ubuntu1 ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0 Uname: Linux 3.19.0-7-generic x86_64 ApportLog: ApportVersion: 2.16.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Tue Mar 3 10:09:26 2015 InstallationDate: Installed on 2012-10-07 (876 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20121007) PackageArchitecture: allSourcePackage: apport UpgradeStatus: Upgraded to vivid on 2013-05-07 (665 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1427600/+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 1427600] Re: apport-unpack: ValueError: ['UserGroups'] has no binary content
** Information type changed from Public to Public Security ** Information type changed from Public Security to Private Security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1427600 Title: apport-unpack: ValueError: ['UserGroups'] has no binary content Status in apport package in Ubuntu: Fix Released Status in apport source package in Xenial: Triaged Status in apport source package in Focal: Fix Released Status in apport source package in Groovy: Fix Released Bug description: [Impact] apport-unpack crashes when trying to unpack a crash [Test Case] On a system running 20.04 LTS: 1) create an additional user who is only a member of their own group e.g. bdmurray@clean-focal-amd64:~$ id crashy uid=1001(crashy) gid=1001(crashy) groups=1001(crashy) 2) Launch a process as that user 3) kill -11 that process 4) Confirm there is a crash file in /var/crash for that process 5) Run apport-unpack on that .crash file With the version of apport from -proposed you will not get another crash file when unpacking the crash file. [Regression Potential] We are just setting UserGroups to 'N/A' as opposed to having it be completely empty so there isn't any chance for regression. When running apport-unpack to get at a core dump laney@raleigh> sudo apport-unpack _usr_lib_x86_64-linux-gnu_urfkill_urfkilld.0.crash ~/temp/zozoz [sudo] password for laney: Traceback (most recent call last): File "/usr/bin/apport-unpack", line 73, in pr.extract_keys(f, bin_keys, dir) File "/usr/lib/python3/dist-packages/problem_report.py", line 253, in extract_keys [item for item, element in b64_block.items() if element is False]) ValueError: ['UserGroups'] has no binary content laney@raleigh> apport-cli --version 2.16.2 It's not terrible, because most files are unpacked (those which sort before UserGroups, I guess). ProblemType: BugDistroRelease: Ubuntu 15.04 Package: apport 2.16.2-0ubuntu1 ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0 Uname: Linux 3.19.0-7-generic x86_64 ApportLog: ApportVersion: 2.16.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Tue Mar 3 10:09:26 2015 InstallationDate: Installed on 2012-10-07 (876 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20121007) PackageArchitecture: allSourcePackage: apport UpgradeStatus: Upgraded to vivid on 2013-05-07 (665 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1427600/+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 1938229] [NEW] ubuntu-bug -w crashes
Public bug reported:
When running ubuntu-bug -w i get the dialog that tells me to select the
window to report a bug about, but after clicking this window, in the
terminal where I started ubuntu-bug -w, i only get:
(apport-gtk:26977): Gdk-CRITICAL **: 00:11:09.451:
gdk_wayland_window_set_dbus_properties_libgtk_only: assertion
'GDK_IS_WAYLAND_WINDOW (window)' failed
Traceback (most recent call last):
File "/usr/share/apport/apport-gtk", line 597, in
app.run_argv()
File "/usr/lib/python3/dist-packages/apport/ui.py", line 745, in run_argv
_('xprop failed to determine process ID of the window') + '\n\n' + err)
TypeError: can only concatenate str (not "bytes") to str
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: apport 2.20.11-0ubuntu65.1
ProcVersionSignature: Ubuntu 5.11.0-25.27-lowlatency 5.11.22
Uname: Linux 5.11.0-25-lowlatency x86_64
ApportLog:
ApportVersion: 2.20.11-0ubuntu65.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Wed Jul 28 00:12:06 2021
InstallationDate: Installed on 2020-04-12 (470 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
PackageArchitecture: all
SourcePackage: apport
UpgradeStatus: Upgraded to hirsute on 2021-07-27 (0 days ago)
** Affects: apport (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug hirsute wayland-session
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1938229
Title:
ubuntu-bug -w crashes
Status in apport package in Ubuntu:
New
Bug description:
When running ubuntu-bug -w i get the dialog that tells me to select
the window to report a bug about, but after clicking this window, in
the terminal where I started ubuntu-bug -w, i only get:
(apport-gtk:26977): Gdk-CRITICAL **: 00:11:09.451:
gdk_wayland_window_set_dbus_properties_libgtk_only: assertion
'GDK_IS_WAYLAND_WINDOW (window)' failed
Traceback (most recent call last):
File "/usr/share/apport/apport-gtk", line 597, in
app.run_argv()
File "/usr/lib/python3/dist-packages/apport/ui.py", line 745, in run_argv
_('xprop failed to determine process ID of the window') + '\n\n' + err)
TypeError: can only concatenate str (not "bytes") to str
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: apport 2.20.11-0ubuntu65.1
ProcVersionSignature: Ubuntu 5.11.0-25.27-lowlatency 5.11.22
Uname: Linux 5.11.0-25-lowlatency x86_64
ApportLog:
ApportVersion: 2.20.11-0ubuntu65.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Wed Jul 28 00:12:06 2021
InstallationDate: Installed on 2020-04-12 (470 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
PackageArchitecture: all
SourcePackage: apport
UpgradeStatus: Upgraded to hirsute on 2021-07-27 (0 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1938229/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
This bug was fixed in the package openssl - 1.1.1j-1ubuntu5 --- openssl (1.1.1j-1ubuntu5) impish; urgency=medium * Cherry-pick an upstream patch to fix s390x AES code (LP: #1931994) -- Simon Chopin Fri, 23 Jul 2021 14:32:42 +0200 ** Changed in: openssl (Ubuntu Impish) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: In Progress Status in openssl source package in Focal: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: Fix Released Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1930738] Re: network configuration failed on reboot
> There are more details regarding this issue and may be commit refs at > https://github.com/systemd/systemd/issues/17012 I'm aware of that as noted in my updates to the description, but that doesn't actually fix this inside unprivileged containers, which is the only place I can reproduce this. Please provide a full journal log from a boot on your VPS that reproduces this -- 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/1930738 Title: network configuration failed on reboot Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Bionic: Incomplete Status in systemd source package in Focal: Incomplete Bug description: [impact] number of statically defined addresses for an interface in systemd- networkd is limited [test case] Note: this only occurs in a container; this is not reproducable in a VM or bare metal. Configure netplan with the attached yaml file (10-test.yaml) enable debug for systemd-networkd reboot the system and check the journalctl output to see if any errors were reported for systemd-networkd, e.g.: $ journalctl -b -u systemd-networkd | grep 'could not set' Jul 23 13:16:52 lp1930738-b systemd-networkd[189]: eth0: could not set address: Connection timed out ... Note that systemd may be able to actually correctly set all addresses, but fails to communicate with netlink to determine the addresses are set, so just checking the output of 'ip a' is not enough, the systemd- networkd debug log should be checked [regression potential] possible failure to correctly apply all statically defined interfaces [scope] TBD, not fully fixed upstream this is needed in f and b this is fixed upstream with commits 628f08b66d43d1947b03419409d817d28eb47321 and PR 16982 which are included in v246 and later, so this is fixed in h and later [other info] I elided upstream commit d31f33e3c9f6ea3bdc873ee52f4398edbec74527 as that changes the udev-related behavior of networkd-manager inside a container, which is not appropriate for SRU for this bug, as I don't see any clear bug-related reason to change that behavior. Additionally this requires the typo fix from commit 4934ba2121d76229659939e19ab7d70a89446629 [original description] This issue was reported at https://github.com/systemd/systemd/issues/17012 **Used distribution** > Ubuntu 20.04.1 LTS **systemd version the issue has been seen with** > 245.4-4ubuntu3.2 **Issue details** I configured 255 IPv4 address (including primary IP) using netplan but when the server restart, it time out on configuring the interface. If I limit total IPv4 addresses to 181 or less, it works. But anything larger than 181 fails. Below are my configurations and error logs. **/etc/netplan/10-ens3.yaml** ``` network: version: 2 renderer: networkd ethernets: ens3: dhcp4: no addresses: - 140.XX.XX.XX/23 - 103.XXX.XX.1/24 - 103.XXX.XX.2/24 - CONTINUED IP ADDRESS UPTO BELOW ... - 103.XXX.XX.254/24 gateway4: 140.XX.XX.X nameservers: addresses: [1.1.1.1, 1.0.0.1] routes: - to: 169.254.0.0/16 via: 140.XX.XX.X metric: 100 ``` The above config works if I run `netplan apply` but when I reboot, it does not work. **networkctl** ``` IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 ens3 etherroutablefailed 2 links listed. ``` **/etc/systemd/system/systemd-networkd.service.d/override.conf** ``` [Service] Environment=SYSTEMD_LOG_LEVEL=debug ``` **systemctl status systemd-networkd.service** ``` ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; vendor preset: enabled) Drop-In: /etc/systemd/system/systemd-networkd.service.d └─override.conf Active: active (running) since Thu 2020-09-10 19:46:58 UTC; 1min 36s ago Docs: man:systemd-networkd.service(8) Main PID: 346 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 1074) Memory: 3.8M CGroup: /system.slice/systemd-networkd.service └─346 /lib/systemd/systemd-networkd Sep 10 19:47:03 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 7s Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: No RA received before link confirmation timeout Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Invoking callback for 'timeout' event. Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 15s Sep 10 19:47:23 test-server systemd-networkd[346]: Assertion 'm->sealed' failed at src/libsys
[Touch-packages] [Bug 1930738] Re: network configuration failed on reboot
I got this issue on a VPS from cloud provider. For me, this issue occurs every time I restart the VPS. To access the server after restart, I execute `netplan apply` command using web console/KVM. Furthermore, this issue does not occurs in Ubuntu 21.04 There are more details regarding this issue and may be commit refs at https://github.com/systemd/systemd/issues/17012 ** Bug watch added: github.com/systemd/systemd/issues #17012 https://github.com/systemd/systemd/issues/17012 -- 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/1930738 Title: network configuration failed on reboot Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Bionic: Incomplete Status in systemd source package in Focal: Incomplete Bug description: [impact] number of statically defined addresses for an interface in systemd- networkd is limited [test case] Note: this only occurs in a container; this is not reproducable in a VM or bare metal. Configure netplan with the attached yaml file (10-test.yaml) enable debug for systemd-networkd reboot the system and check the journalctl output to see if any errors were reported for systemd-networkd, e.g.: $ journalctl -b -u systemd-networkd | grep 'could not set' Jul 23 13:16:52 lp1930738-b systemd-networkd[189]: eth0: could not set address: Connection timed out ... Note that systemd may be able to actually correctly set all addresses, but fails to communicate with netlink to determine the addresses are set, so just checking the output of 'ip a' is not enough, the systemd- networkd debug log should be checked [regression potential] possible failure to correctly apply all statically defined interfaces [scope] TBD, not fully fixed upstream this is needed in f and b this is fixed upstream with commits 628f08b66d43d1947b03419409d817d28eb47321 and PR 16982 which are included in v246 and later, so this is fixed in h and later [other info] I elided upstream commit d31f33e3c9f6ea3bdc873ee52f4398edbec74527 as that changes the udev-related behavior of networkd-manager inside a container, which is not appropriate for SRU for this bug, as I don't see any clear bug-related reason to change that behavior. Additionally this requires the typo fix from commit 4934ba2121d76229659939e19ab7d70a89446629 [original description] This issue was reported at https://github.com/systemd/systemd/issues/17012 **Used distribution** > Ubuntu 20.04.1 LTS **systemd version the issue has been seen with** > 245.4-4ubuntu3.2 **Issue details** I configured 255 IPv4 address (including primary IP) using netplan but when the server restart, it time out on configuring the interface. If I limit total IPv4 addresses to 181 or less, it works. But anything larger than 181 fails. Below are my configurations and error logs. **/etc/netplan/10-ens3.yaml** ``` network: version: 2 renderer: networkd ethernets: ens3: dhcp4: no addresses: - 140.XX.XX.XX/23 - 103.XXX.XX.1/24 - 103.XXX.XX.2/24 - CONTINUED IP ADDRESS UPTO BELOW ... - 103.XXX.XX.254/24 gateway4: 140.XX.XX.X nameservers: addresses: [1.1.1.1, 1.0.0.1] routes: - to: 169.254.0.0/16 via: 140.XX.XX.X metric: 100 ``` The above config works if I run `netplan apply` but when I reboot, it does not work. **networkctl** ``` IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 ens3 etherroutablefailed 2 links listed. ``` **/etc/systemd/system/systemd-networkd.service.d/override.conf** ``` [Service] Environment=SYSTEMD_LOG_LEVEL=debug ``` **systemctl status systemd-networkd.service** ``` ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; vendor preset: enabled) Drop-In: /etc/systemd/system/systemd-networkd.service.d └─override.conf Active: active (running) since Thu 2020-09-10 19:46:58 UTC; 1min 36s ago Docs: man:systemd-networkd.service(8) Main PID: 346 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 1074) Memory: 3.8M CGroup: /system.slice/systemd-networkd.service └─346 /lib/systemd/systemd-networkd Sep 10 19:47:03 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 7s Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: No RA received before link confirmation timeout Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Invoking callback for 'timeout' event. Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitat
[Touch-packages] [Bug 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
I re-run the failed tests, and both of them passed on the second attempt, so it should migrate on impish soon. The SRUs are now uploaded, following Brian's advice with respect to hirsute. @Simon: Good if you can unsubscribe ubuntu-sponsors. ** Changed in: openssl (Ubuntu Hirsute) Status: New => In Progress ** Changed in: openssl (Ubuntu Hirsute) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Changed in: openssl (Ubuntu Focal) Status: New => In Progress ** Changed in: openssl (Ubuntu Focal) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Changed in: openssl (Ubuntu Bionic) Status: New => In Progress ** Changed in: openssl (Ubuntu Bionic) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: Fix Committed Status in openssl source package in Bionic: In Progress Status in openssl source package in Focal: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: Fix Committed Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1937238] Re: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting
Rasmus are you able to test with the systemd build from this ppa to see if it fixes the problem for you: https://launchpad.net/~ddstreet/+archive/ubuntu/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/1937238 Title: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Bug description: [impact] systemd-time-wait-sync service sometimes misses sync completed event and remains in 'activating' state [test case] this isn't consistently reproducable, see original description for test case [regression potential] possible problems with the systemd-time-wait-sync service completing too early or not completing on time [scope] this is needed only for f this is fixed upstream with commit f6f4f5fe5395a57f10dd446c7266c53f0673eaac which is in v246, so this is fixed in h and later already the service does not exist in b so this does not apply there [original description] When I start my server running Ubuntu 20.04 the systemd-time-wait- sync.service is stuck in "activating" state. I noticed this because none of the systemd timer units triggered, because all the timers depend on systemd-time-wait-sync.service. Running "systemctl restart systemd-time-wait-sync.service" manually works around the problem. Some logs and command outputs: raek@mizar:~$ lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 raek@mizar:~$ systemctl | grep systemd-time-wait-sync.service systemd-time-wait-sync.service loaded activating start start Wait Until Kernel Time Synchronized raek@mizar:~$ systemctl status systemd-time-wait-sync.service ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago Docs: man:systemd-time-wait-sync.service(8) Main PID: 514 (systemd-time-wa) Tasks: 1 (limit: 9415) Memory: 972.0K CGroup: /system.slice/systemd-time-wait-sync.service └─514 /lib/systemd/systemd-time-wait-sync Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC Warning: journal has been rotated since unit was started, output may be incomplete. raek@mizar:~$ journalctl -b -u systemd-time-wait-sync.service -- Logs begin at Wed 2020-07-08 16:34:13 CEST, end at Thu 2021-07-22 11:36:44 CEST. -- Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC raek@mizar:~$ dpkg -S /lib/systemd/system/systemd-time-wait-sync.service systemd: /lib/systemd/system/systemd-time-wait-sync.service raek@mizar:~$ apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.11 Candidate: 245.4-4ubuntu3.11 Version table: *** 245.4-4ubuntu3.11 500 500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.10 500 500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 245.4-4ubuntu3.8 400 400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages 245.4-4ubuntu3 500 500 http://se.archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1937238/+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 1937238] Re: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting
> so is there something else not working in focal? as noted in the [scope] sru template section this is fixed by upstream commit f6f4f5fe5395a57f10dd446c7266c53f0673eaac which isn't in focal -- 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/1937238 Title: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Bug description: [impact] systemd-time-wait-sync service sometimes misses sync completed event and remains in 'activating' state [test case] this isn't consistently reproducable, see original description for test case [regression potential] possible problems with the systemd-time-wait-sync service completing too early or not completing on time [scope] this is needed only for f this is fixed upstream with commit f6f4f5fe5395a57f10dd446c7266c53f0673eaac which is in v246, so this is fixed in h and later already the service does not exist in b so this does not apply there [original description] When I start my server running Ubuntu 20.04 the systemd-time-wait- sync.service is stuck in "activating" state. I noticed this because none of the systemd timer units triggered, because all the timers depend on systemd-time-wait-sync.service. Running "systemctl restart systemd-time-wait-sync.service" manually works around the problem. Some logs and command outputs: raek@mizar:~$ lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 raek@mizar:~$ systemctl | grep systemd-time-wait-sync.service systemd-time-wait-sync.service loaded activating start start Wait Until Kernel Time Synchronized raek@mizar:~$ systemctl status systemd-time-wait-sync.service ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago Docs: man:systemd-time-wait-sync.service(8) Main PID: 514 (systemd-time-wa) Tasks: 1 (limit: 9415) Memory: 972.0K CGroup: /system.slice/systemd-time-wait-sync.service └─514 /lib/systemd/systemd-time-wait-sync Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC Warning: journal has been rotated since unit was started, output may be incomplete. raek@mizar:~$ journalctl -b -u systemd-time-wait-sync.service -- Logs begin at Wed 2020-07-08 16:34:13 CEST, end at Thu 2021-07-22 11:36:44 CEST. -- Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC raek@mizar:~$ dpkg -S /lib/systemd/system/systemd-time-wait-sync.service systemd: /lib/systemd/system/systemd-time-wait-sync.service raek@mizar:~$ apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.11 Candidate: 245.4-4ubuntu3.11 Version table: *** 245.4-4ubuntu3.11 500 500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.10 500 500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 245.4-4ubuntu3.8 400 400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages 245.4-4ubuntu3 500 500 http://se.archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1937238/+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 1937922] Re: gtk4 not built for i386
This bug was fixed in the package ibus - 1.5.24-1ubuntu1 --- ibus (1.5.24-1ubuntu1) impish; urgency=medium * debian/rules, debian/control, debian/ibus-gtk4.install: - Enable GTK 4 and build the ibus-gtk4 binary (LP: #1937922) -- Gunnar Hjalmarsson Tue, 27 Jul 2021 08:56:35 +0200 ** Changed in: ibus (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1937922 Title: gtk4 not built for i386 Status in gtk4 package in Ubuntu: Fix Released Status in ibus package in Ubuntu: Fix Released Bug description: I'm trying to enable GTK 4 when building ibus: https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus2/+packages Up to now ibus has been built also on i386, but gtk4 has not been built on that arch, so the i386 build fails due to missing build dependencies. Is it time to stop building ibus on i386? Or can we build gtk4 on i386 (it was successfully built on Debian's i386)? At least some step needs to be taken. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk4/+bug/1937922/+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 1930738] Re: network configuration failed on reboot
** Attachment added: "10-test.yaml" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1930738/+attachment/5514117/+files/10-test.yaml ** Description changed: [impact] number of statically defined addresses for an interface in systemd- networkd is limited [test case] Note: this only occurs in a container; this is not reproducable in a VM or bare metal. - Configure netplan with the attached yaml file (TBD: attach) + Configure netplan with the attached yaml file (10-test.yaml) enable debug for systemd-networkd reboot the system and check the journalctl output to see if any errors were reported for systemd-networkd, e.g.: $ journalctl -b -u systemd-networkd | grep 'could not set' Jul 23 13:16:52 lp1930738-b systemd-networkd[189]: eth0: could not set address: Connection timed out ... Note that systemd may be able to actually correctly set all addresses, but fails to communicate with netlink to determine the addresses are set, so just checking the output of 'ip a' is not enough, the systemd- networkd debug log should be checked [regression potential] possible failure to correctly apply all statically defined interfaces [scope] this is needed in f and b this is fixed upstream with commits 628f08b66d43d1947b03419409d817d28eb47321 and PR 16982 which are included in v246 and later, so this is fixed in h and later [other info] I elided upstream commit d31f33e3c9f6ea3bdc873ee52f4398edbec74527 as that changes the udev-related behavior of networkd-manager inside a container, which is not appropriate for SRU for this bug, as I don't see any clear bug-related reason to change that behavior. Additionally this requires the typo fix from commit 4934ba2121d76229659939e19ab7d70a89446629 [original description] This issue was reported at https://github.com/systemd/systemd/issues/17012 **Used distribution** > Ubuntu 20.04.1 LTS **systemd version the issue has been seen with** > 245.4-4ubuntu3.2 **Issue details** I configured 255 IPv4 address (including primary IP) using netplan but when the server restart, it time out on configuring the interface. If I limit total IPv4 addresses to 181 or less, it works. But anything larger than 181 fails. Below are my configurations and error logs. **/etc/netplan/10-ens3.yaml** ``` network: version: 2 renderer: networkd ethernets: ens3: dhcp4: no addresses: - 140.XX.XX.XX/23 - 103.XXX.XX.1/24 - 103.XXX.XX.2/24 - CONTINUED IP ADDRESS UPTO BELOW ... - 103.XXX.XX.254/24 gateway4: 140.XX.XX.X nameservers: addresses: [1.1.1.1, 1.0.0.1] routes: - to: 169.254.0.0/16 via: 140.XX.XX.X metric: 100 ``` The above config works if I run `netplan apply` but when I reboot, it does not work. **networkctl** ``` IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 ens3 etherroutablefailed 2 links listed. ``` **/etc/systemd/system/systemd-networkd.service.d/override.conf** ``` [Service] Environment=SYSTEMD_LOG_LEVEL=debug ``` **systemctl status systemd-networkd.service** ``` ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; vendor preset: enabled) Drop-In: /etc/systemd/system/systemd-networkd.service.d └─override.conf Active: active (running) since Thu 2020-09-10 19:46:58 UTC; 1min 36s ago Docs: man:systemd-networkd.service(8) Main PID: 346 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 1074) Memory: 3.8M CGroup: /system.slice/systemd-networkd.service └─346 /lib/systemd/systemd-networkd Sep 10 19:47:03 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 7s Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: No RA received before link confirmation timeout Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Invoking callback for 'timeout' event. Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 15s Sep 10 19:47:23 test-server systemd-networkd[346]: Assertion 'm->sealed' failed at src/libsystemd/sd-netlink/netlink-message.c:582, function netlink_message_read_internal(). Ignoring. Sep 10 19:47:23 test-server systemd-networkd[346]: ens3: Could not set address: Connection timed out Sep 10 19:47:23 test-server systemd-networkd[346]: ens3: Failed Sep 10 19:47:23 test-server systemd-networkd[346]: ens3: State changed: configuring -> failed Sep 10 19:47:23 test-server systemd-networkd[346]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBu
[Touch-packages] [Bug 1930738] Re: network configuration failed on reboot
Deepika, Frank, is this happening for you inside an unprivileged container, or some other environment? I'm able to reproduce this in a container, but it appears still broken with upstream systemd, so I'm confused by Frank's comment 2. Also, it isn't intermittent at all for me, so maybe you're seeing some other problem. ** Changed in: systemd (Ubuntu) Status: Fix Released => Incomplete ** Changed in: systemd (Ubuntu Bionic) Status: New => Incomplete ** Changed in: systemd (Ubuntu Focal) Status: In Progress => 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/1930738 Title: network configuration failed on reboot Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Bionic: Incomplete Status in systemd source package in Focal: Incomplete Bug description: [impact] number of statically defined addresses for an interface in systemd- networkd is limited [test case] Note: this only occurs in a container; this is not reproducable in a VM or bare metal. Configure netplan with the attached yaml file (10-test.yaml) enable debug for systemd-networkd reboot the system and check the journalctl output to see if any errors were reported for systemd-networkd, e.g.: $ journalctl -b -u systemd-networkd | grep 'could not set' Jul 23 13:16:52 lp1930738-b systemd-networkd[189]: eth0: could not set address: Connection timed out ... Note that systemd may be able to actually correctly set all addresses, but fails to communicate with netlink to determine the addresses are set, so just checking the output of 'ip a' is not enough, the systemd- networkd debug log should be checked [regression potential] possible failure to correctly apply all statically defined interfaces [scope] TBD, not fully fixed upstream this is needed in f and b this is fixed upstream with commits 628f08b66d43d1947b03419409d817d28eb47321 and PR 16982 which are included in v246 and later, so this is fixed in h and later [other info] I elided upstream commit d31f33e3c9f6ea3bdc873ee52f4398edbec74527 as that changes the udev-related behavior of networkd-manager inside a container, which is not appropriate for SRU for this bug, as I don't see any clear bug-related reason to change that behavior. Additionally this requires the typo fix from commit 4934ba2121d76229659939e19ab7d70a89446629 [original description] This issue was reported at https://github.com/systemd/systemd/issues/17012 **Used distribution** > Ubuntu 20.04.1 LTS **systemd version the issue has been seen with** > 245.4-4ubuntu3.2 **Issue details** I configured 255 IPv4 address (including primary IP) using netplan but when the server restart, it time out on configuring the interface. If I limit total IPv4 addresses to 181 or less, it works. But anything larger than 181 fails. Below are my configurations and error logs. **/etc/netplan/10-ens3.yaml** ``` network: version: 2 renderer: networkd ethernets: ens3: dhcp4: no addresses: - 140.XX.XX.XX/23 - 103.XXX.XX.1/24 - 103.XXX.XX.2/24 - CONTINUED IP ADDRESS UPTO BELOW ... - 103.XXX.XX.254/24 gateway4: 140.XX.XX.X nameservers: addresses: [1.1.1.1, 1.0.0.1] routes: - to: 169.254.0.0/16 via: 140.XX.XX.X metric: 100 ``` The above config works if I run `netplan apply` but when I reboot, it does not work. **networkctl** ``` IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 ens3 etherroutablefailed 2 links listed. ``` **/etc/systemd/system/systemd-networkd.service.d/override.conf** ``` [Service] Environment=SYSTEMD_LOG_LEVEL=debug ``` **systemctl status systemd-networkd.service** ``` ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; vendor preset: enabled) Drop-In: /etc/systemd/system/systemd-networkd.service.d └─override.conf Active: active (running) since Thu 2020-09-10 19:46:58 UTC; 1min 36s ago Docs: man:systemd-networkd.service(8) Main PID: 346 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 1074) Memory: 3.8M CGroup: /system.slice/systemd-networkd.service └─346 /lib/systemd/systemd-networkd Sep 10 19:47:03 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 7s Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: No RA received before link confirmation timeout Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Invoking callback for 'timeout' event. Sep 10 19:47:11 test-server syste
[Touch-packages] [Bug 1930738] Re: network configuration failed on reboot
** Description changed: [impact] number of statically defined addresses for an interface in systemd- networkd is limited [test case] Note: this only occurs in a container; this is not reproducable in a VM or bare metal. Configure netplan with the attached yaml file (TBD: attach) enable debug for systemd-networkd reboot the system and check the journalctl output to see if any errors were reported for systemd-networkd, e.g.: $ journalctl -b -u systemd-networkd | grep 'could not set' Jul 23 13:16:52 lp1930738-b systemd-networkd[189]: eth0: could not set address: Connection timed out ... - Note that a restart of systemd-networkd may successfully complete - setting up all addresses, so the journal should be checked for errors - instead of only checking for configured addresses + Note that systemd may be able to actually correctly set all addresses, + but fails to communicate with netlink to determine the addresses are + set, so just checking the output of 'ip a' is not enough, the systemd- + networkd debug log should be checked [regression potential] possible failure to correctly apply all statically defined interfaces [scope] this is needed in f and b this is fixed upstream with commits 628f08b66d43d1947b03419409d817d28eb47321 and PR 16982 which are included in v246 and later, so this is fixed in h and later [other info] I elided upstream commit d31f33e3c9f6ea3bdc873ee52f4398edbec74527 as that changes the udev-related behavior of networkd-manager inside a container, which is not appropriate for SRU for this bug, as I don't see any clear bug-related reason to change that behavior. Additionally this requires the typo fix from commit 4934ba2121d76229659939e19ab7d70a89446629 [original description] This issue was reported at https://github.com/systemd/systemd/issues/17012 **Used distribution** > Ubuntu 20.04.1 LTS **systemd version the issue has been seen with** > 245.4-4ubuntu3.2 **Issue details** I configured 255 IPv4 address (including primary IP) using netplan but when the server restart, it time out on configuring the interface. If I limit total IPv4 addresses to 181 or less, it works. But anything larger than 181 fails. Below are my configurations and error logs. **/etc/netplan/10-ens3.yaml** ``` network: version: 2 renderer: networkd ethernets: ens3: dhcp4: no addresses: - 140.XX.XX.XX/23 - 103.XXX.XX.1/24 - 103.XXX.XX.2/24 - CONTINUED IP ADDRESS UPTO BELOW ... - 103.XXX.XX.254/24 gateway4: 140.XX.XX.X nameservers: addresses: [1.1.1.1, 1.0.0.1] routes: - to: 169.254.0.0/16 via: 140.XX.XX.X metric: 100 ``` The above config works if I run `netplan apply` but when I reboot, it does not work. **networkctl** ``` IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 ens3 etherroutablefailed 2 links listed. ``` **/etc/systemd/system/systemd-networkd.service.d/override.conf** ``` [Service] Environment=SYSTEMD_LOG_LEVEL=debug ``` **systemctl status systemd-networkd.service** ``` ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; vendor preset: enabled) Drop-In: /etc/systemd/system/systemd-networkd.service.d └─override.conf Active: active (running) since Thu 2020-09-10 19:46:58 UTC; 1min 36s ago Docs: man:systemd-networkd.service(8) Main PID: 346 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 1074) Memory: 3.8M CGroup: /system.slice/systemd-networkd.service └─346 /lib/systemd/systemd-networkd Sep 10 19:47:03 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 7s Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: No RA received before link confirmation timeout Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Invoking callback for 'timeout' event. Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 15s Sep 10 19:47:23 test-server systemd-networkd[346]: Assertion 'm->sealed' failed at src/libsystemd/sd-netlink/netlink-message.c:582, function netlink_message_read_internal(). Ignoring. Sep 10 19:47:23 test-server systemd-networkd[346]: ens3: Could not set address: Connection timed out Sep 10 19:47:23 test-server systemd-networkd[346]: ens3: Failed Sep 10 19:47:23 test-server systemd-networkd[346]: ens3: State changed: configuring -> failed Sep 10 19:47:23 test-server systemd-networkd[346]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties me
[Touch-packages] [Bug 1937238] Re: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting
But the things mentioned in systemd issue were supposedly resolved, and https://github.com/systemd/systemd/commit/d84af414180a4a8a7dd8772fc9d5302b5f9f28c9 is in focal already.. so is there something else not working in focal? -- 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/1937238 Title: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Bug description: [impact] systemd-time-wait-sync service sometimes misses sync completed event and remains in 'activating' state [test case] this isn't consistently reproducable, see original description for test case [regression potential] possible problems with the systemd-time-wait-sync service completing too early or not completing on time [scope] this is needed only for f this is fixed upstream with commit f6f4f5fe5395a57f10dd446c7266c53f0673eaac which is in v246, so this is fixed in h and later already the service does not exist in b so this does not apply there [original description] When I start my server running Ubuntu 20.04 the systemd-time-wait- sync.service is stuck in "activating" state. I noticed this because none of the systemd timer units triggered, because all the timers depend on systemd-time-wait-sync.service. Running "systemctl restart systemd-time-wait-sync.service" manually works around the problem. Some logs and command outputs: raek@mizar:~$ lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 raek@mizar:~$ systemctl | grep systemd-time-wait-sync.service systemd-time-wait-sync.service loaded activating start start Wait Until Kernel Time Synchronized raek@mizar:~$ systemctl status systemd-time-wait-sync.service ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago Docs: man:systemd-time-wait-sync.service(8) Main PID: 514 (systemd-time-wa) Tasks: 1 (limit: 9415) Memory: 972.0K CGroup: /system.slice/systemd-time-wait-sync.service └─514 /lib/systemd/systemd-time-wait-sync Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC Warning: journal has been rotated since unit was started, output may be incomplete. raek@mizar:~$ journalctl -b -u systemd-time-wait-sync.service -- Logs begin at Wed 2020-07-08 16:34:13 CEST, end at Thu 2021-07-22 11:36:44 CEST. -- Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC raek@mizar:~$ dpkg -S /lib/systemd/system/systemd-time-wait-sync.service systemd: /lib/systemd/system/systemd-time-wait-sync.service raek@mizar:~$ apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.11 Candidate: 245.4-4ubuntu3.11 Version table: *** 245.4-4ubuntu3.11 500 500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.10 500 500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 245.4-4ubuntu3.8 400 400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages 245.4-4ubuntu3 500 500 http://se.archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1937238/+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 1856428] Re: Disable TLS below 1.2 by default
** Bug watch added: Debian Bug tracker #991562 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991562 ** Also affects: nss via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991562 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nss in Ubuntu. https://bugs.launchpad.net/bugs/1856428 Title: Disable TLS below 1.2 by default Status in NSS: Unknown Status in gnutls28 package in Ubuntu: Fix Released Status in golang-1.13 package in Ubuntu: New Status in nss package in Ubuntu: Fix Released Status in openssl package in Ubuntu: Fix Released Bug description: Disable TLS 1.0, TLS1.1, DTLS1.0 As part of focal commitment, we shall disable obsolete protocols by default. Users can override this behaviour with a config file. To manage notifications about this bug go to: https://bugs.launchpad.net/nss/+bug/1856428/+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 1937238] Re: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting
** Description changed: + [impact] + + systemd-time-wait-sync service sometimes misses sync completed event and + remains in 'activating' state + + [test case] + + this isn't consistently reproducable, see original description for test + case + + [regression potential] + + possible problems with the systemd-time-wait-sync service completing too + early or not completing on time + + [scope] + + this is needed only for f + + this is fixed upstream with commit + f6f4f5fe5395a57f10dd446c7266c53f0673eaac which is in v246, so this is + fixed in h and later already + + the service does not exist in b so this does not apply there + + [original description] + When I start my server running Ubuntu 20.04 the systemd-time-wait- sync.service is stuck in "activating" state. I noticed this because none of the systemd timer units triggered, because all the timers depend on systemd-time-wait-sync.service. Running "systemctl restart systemd-time- wait-sync.service" manually works around the problem. Some logs and command outputs: raek@mizar:~$ lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 raek@mizar:~$ systemctl | grep systemd-time-wait-sync.service systemd-time-wait-sync.service loaded activating start start Wait Until Kernel Time Synchronized raek@mizar:~$ systemctl status systemd-time-wait-sync.service ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago Docs: man:systemd-time-wait-sync.service(8) Main PID: 514 (systemd-time-wa) Tasks: 1 (limit: 9415) Memory: 972.0K CGroup: /system.slice/systemd-time-wait-sync.service └─514 /lib/systemd/systemd-time-wait-sync Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC Warning: journal has been rotated since unit was started, output may be incomplete. raek@mizar:~$ journalctl -b -u systemd-time-wait-sync.service -- Logs begin at Wed 2020-07-08 16:34:13 CEST, end at Thu 2021-07-22 11:36:44 CEST. -- Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC raek@mizar:~$ dpkg -S /lib/systemd/system/systemd-time-wait-sync.service systemd: /lib/systemd/system/systemd-time-wait-sync.service raek@mizar:~$ apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.11 Candidate: 245.4-4ubuntu3.11 Version table: *** 245.4-4ubuntu3.11 500 500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.10 500 500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 245.4-4ubuntu3.8 400 400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages 245.4-4ubuntu3 500 500 http://se.archive.ubuntu.com/ubuntu focal/main amd64 Packages ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: Incomplete => Fix Released ** Changed in: systemd (Ubuntu Focal) Status: New => In Progress ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => Low ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Dan Streetman (ddstreet) -- 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/1937238 Title: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Bug description: [impact] systemd-time-wait-sync service sometimes misses sync completed event and remains in 'activating' state [test case] this isn't consistently reproducable, see original description for test case [regression potential] possible problems with the systemd-time-wait-sync service completing too early or not completing on time [scope] this is needed only for f this is fixed upstream with commit f6f4f5fe5395a57f10dd446c7266c53f0673eaac which is in v246, so this is fixed in h and later already the service does not exist in b so this does not apply there [original description] When I start my server running Ubuntu 20.04 the systemd-time-wait- sync.service is stuck in "activating" state. I noticed this because none of the systemd timer units triggered, because all the timers depend on systemd-time-wait-sync.service. Running "systemctl restart systemd-time-wait-sync.service" manually works around the
[Touch-packages] [Bug 1937238] Re: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting
> https://github.com/home-assistant/operating-system/issues/896 yes the upstream commit to fix this does look like what would cause this, thanks! -- 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/1937238 Title: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting Status in systemd package in Ubuntu: Incomplete Bug description: When I start my server running Ubuntu 20.04 the systemd-time-wait- sync.service is stuck in "activating" state. I noticed this because none of the systemd timer units triggered, because all the timers depend on systemd-time-wait-sync.service. Running "systemctl restart systemd-time-wait-sync.service" manually works around the problem. Some logs and command outputs: raek@mizar:~$ lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 raek@mizar:~$ systemctl | grep systemd-time-wait-sync.service systemd-time-wait-sync.service loaded activating start start Wait Until Kernel Time Synchronized raek@mizar:~$ systemctl status systemd-time-wait-sync.service ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago Docs: man:systemd-time-wait-sync.service(8) Main PID: 514 (systemd-time-wa) Tasks: 1 (limit: 9415) Memory: 972.0K CGroup: /system.slice/systemd-time-wait-sync.service └─514 /lib/systemd/systemd-time-wait-sync Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC Warning: journal has been rotated since unit was started, output may be incomplete. raek@mizar:~$ journalctl -b -u systemd-time-wait-sync.service -- Logs begin at Wed 2020-07-08 16:34:13 CEST, end at Thu 2021-07-22 11:36:44 CEST. -- Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC raek@mizar:~$ dpkg -S /lib/systemd/system/systemd-time-wait-sync.service systemd: /lib/systemd/system/systemd-time-wait-sync.service raek@mizar:~$ apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.11 Candidate: 245.4-4ubuntu3.11 Version table: *** 245.4-4ubuntu3.11 500 500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.10 500 500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 245.4-4ubuntu3.8 400 400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages 245.4-4ubuntu3 500 500 http://se.archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1937238/+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 1929657] udevadm_reload
--- Comment (attachment only) From mario.alberto.gali...@ibm.com 2021-07-27 11:37 EDT--- ** Attachment added: "udevadm_reload" https://bugs.launchpad.net/bugs/1929657/+attachment/5514091/+files/udevadm_reload.txt -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition enP50s3832 is not for us (backend 1) ** (generate
[Touch-packages] [Bug 1938195] [NEW] Configuration for eGPU removed on update
Public bug reported: ThinkPad X1C9 running Kubuntu. I'm using an external nVidia GPU in an enclosure, attached via thunderbolt. I have applied updates over the last few weeks, and rebooted today. Got a black screen. Turns out an update back in mid June (22nd) removed the Option "AllowExternalGpus" "true" from my xorg.conf. Why is an update removing a vital configuration option enabling me to display my login screen? I had to re-edit the xorg.conf like an cave man from 20 years ago. ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: xorg 1:7.7+22ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia .proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file. .proc.driver.nvidia.capabilities.mig: Error: path was not a regular file. .proc.driver.nvidia.gpus..52.00.0: Error: path was not a regular file. .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 460.91.03 Fri Jul 2 06:04:10 UTC 2021 GCC version: ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: KDE Date: Tue Jul 27 16:42:11 2021 DistUpgraded: Fresh install DistroCodename: hirsute DistroVariant: ubuntu DkmsStatus: tp_smapi, 0.43, 5.11.0-22-generic, x86_64: installed tp_smapi, 0.43, 5.11.0-25-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Lenovo Iris Xe Graphics [17aa:22d5] NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GP107 [GeForce GTX 1050 Ti] [1043:85d1] InstallationDate: Installed on 2021-05-14 (73 days ago) InstallationMedia: Kubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) MachineType: LENOVO 20XWCTO1WW ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-25-generic root=UUID=f73d534c-9211-43d9-a8d5-fe9b6bb3 ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/26/2021 dmi.bios.release: 1.23 dmi.bios.vendor: LENOVO dmi.bios.version: N32ET47W (1.23 ) dmi.board.asset.tag: Not Available dmi.board.name: 20XWCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrN32ET47W(1.23):bd03/26/2021:br1.23:efr1.22:svnLENOVO:pn20XWCTO1WW:pvrThinkPadX1CarbonGen9:rvnLENOVO:rn20XWCTO1WW:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon Gen 9 dmi.product.name: 20XWCTO1WW dmi.product.sku: LENOVO_MT_20XW_BU_Think_FM_ThinkPad X1 Carbon Gen 9 dmi.product.version: ThinkPad X1 Carbon Gen 9 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.105-3~21.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.1-2 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug hirsute ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1938195 Title: Configuration for eGPU removed on update Status in xorg package in Ubuntu: New Bug description: ThinkPad X1C9 running Kubuntu. I'm using an external nVidia GPU in an enclosure, attached via thunderbolt. I have applied updates over the last few weeks, and rebooted today. Got a black screen. Turns out an update back in mid June (22nd) removed the Option "AllowExternalGpus" "true" from my xorg.conf. Why is an update removing a vital configuration option enabling me to display my login screen? I had to re-edit the xorg.conf like an cave man from 20 years ago. ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: xorg 1:7.7+22ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia .proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file. .proc.dri
[Touch-packages] [Bug 1929657] Comment bridged from LTC Bugzilla
--- Comment From mario.alberto.gali...@ibm.com 2021-07-27 11:33 EDT---
Enable udev monitor:
udevadm --debug monitor --property >> udevadm_reload.txt
Steeps followed to retrieve logs:
- Checking actual status of the vLan:
root@ilabg13:~# date
Tue Jul 27 08:23:47 MST 2021
root@ilabg13:~# ip addr show dev enP53p0s0.171
10: enP53p0s0.171@enP53p0s0: mtu 9000 qdisc
noqueue state UP group default qlen 1000
link/ether 82:0c:9b:c9:78:f8 brd ff:ff:ff:ff:ff:ff
inet6 fe80::800c:9bff:fec9:78f8/64 scope link
valid_lft forever preferred_lft forever
- Reload udevadm
root@ilabg13:~# date
Tue Jul 27 08:24:22 MST 2021
root@ilabg13:~# udevadm control --reload; udevadm trigger; udevadm settle
- Try to assign ip via netplan
root@ilabg13:~# date
Tue Jul 27 08:26:01 MST 2021
root@ilabg13:~# netplan --debug apply
** (generate:3616109): DEBUG: 08:26:04.430: Processing input file
/etc/netplan/00-installer-config.yaml..
** (generate:3616109): DEBUG: 08:26:04.431: starting new processing pass
** (generate:3616109): DEBUG: 08:26:04.431: Processing input file
/etc/netplan/01-iscsi-config.yaml..
** (generate:3616109): DEBUG: 08:26:04.431: starting new processing pass
** (generate:3616109): DEBUG: 08:26:04.431: We have some netdefs, pass them
through a final round of validation
** (generate:3616109): DEBUG: 08:26:04.431: encdc0: setting default backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: encdb0: setting default backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: ence0f: setting default backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: encdb0.160: setting default backend
to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: enP50s3832: setting default backend
to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: enP53p0s0.171: setting default
backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: enP50s3832.170: setting default
backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: enP53p0s0: setting default backend
to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: encdc0.150: setting default backend
to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: Generating output files..
** (generate:3616109): DEBUG: 08:26:04.431: openvswitch: definition ence0f is
not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.431: NetworkManager: definition ence0f
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.431: openvswitch: definition encdb0 is
not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.431: NetworkManager: definition encdb0
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition encdc0 is
not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition encdc0
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition enP50s3832
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition
enP50s3832 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition enP53p0s0
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition
enP53p0s0 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition encdb0.160
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition
encdb0.160 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition encdc0.150
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition
encdc0.150 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition
enP53p0s0.171 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition
enP53p0s0.171 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition
enP50s3832.170 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition
enP50s3832.170 is not for us (backend 1)
(generate:3616109): GLib-DEBUG: 08:26:04.432: posix_spawn avoided (fd close
requested)
(generate:3616109): GLib-DEBUG: 08:26:04.432: posix_spawn avoided (fd close
requested)
DEBUG:netplan generated networkd configuration changed, restarting networkd
DEBUG:ence0f not found in {}
DEBUG:encdb0 not found in {'ence0f': {'addresses': ['9.11.116.213/24'],
'
[Touch-packages] [Bug 1937325] Re: Jack clients have segmentation fault when trying to connect to jackd
New information: Rebuilds of 1.9.17 and builds of 1.9.18 in impish result in the same issue, meaning there is likely a build-time dependency incompatibility. Upstream has been notified. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to jackd2 in Ubuntu. https://bugs.launchpad.net/bugs/1937325 Title: Jack clients have segmentation fault when trying to connect to jackd Status in jackd2 package in Ubuntu: Triaged Bug description: Steps to show this bug. Start jackd either as jackd or jackdbus (with jack_control). run jack_lsp from the command line to show jackd's port. Jack_lsp will segfault. Other jack clients will have similar problems. This is specific to jackd2 1.9.19, jackd 1.9.17 does not have this problem. jackd 1.1.19 on ubuntu 20.04 does work but jackd 1.9.19 on 21.10 does not. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: jackd2 1.9.19~dfsg~ubuntu-0ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-20.21+21.10.1-lowlatency 5.11.21 Uname: Linux 5.11.0-20-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu67 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Thu Jul 22 18:09:18 2021 InstallationDate: Installed on 2021-06-15 (37 days ago) InstallationMedia: Ubuntu-Studio 21.10 "Impish Indri" - Alpha amd64 (20210613) SourcePackage: jackd2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/1937325/+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 1937325] Re: Jack clients have segmentation fault when trying to connect to jackd
Changed to critical as this is a blocking bug for Ubuntu Studio 21.10's release. ** Changed in: jackd2 (Ubuntu) Importance: High => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to jackd2 in Ubuntu. https://bugs.launchpad.net/bugs/1937325 Title: Jack clients have segmentation fault when trying to connect to jackd Status in jackd2 package in Ubuntu: Triaged Bug description: Steps to show this bug. Start jackd either as jackd or jackdbus (with jack_control). run jack_lsp from the command line to show jackd's port. Jack_lsp will segfault. Other jack clients will have similar problems. This is specific to jackd2 1.9.19, jackd 1.9.17 does not have this problem. jackd 1.1.19 on ubuntu 20.04 does work but jackd 1.9.19 on 21.10 does not. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: jackd2 1.9.19~dfsg~ubuntu-0ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-20.21+21.10.1-lowlatency 5.11.21 Uname: Linux 5.11.0-20-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu67 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Thu Jul 22 18:09:18 2021 InstallationDate: Installed on 2021-06-15 (37 days ago) InstallationMedia: Ubuntu-Studio 21.10 "Impish Indri" - Alpha amd64 (20210613) SourcePackage: jackd2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/1937325/+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 1929657] Comment bridged from LTC Bugzilla
--- Comment From mario.alberto.gali...@ibm.com 2021-07-27 10:40 EDT--- Since the file /etc/systemd/network/10-enP53p0s0.link was removed it wasn't get generated again. Is there a way to get it generated again? -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition enP50s3832 is not for us (backend 1) ** (generate:59965):
[Touch-packages] [Bug 1800836] Re: systemd-networkd doesn't process IPv6 RA properly
** Changed in: systemd (Ubuntu) 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/1800836 Title: systemd-networkd doesn't process IPv6 RA properly Status in systemd package in Ubuntu: New Bug description: The gateways/firewalls in our DC are highly available and when there is a failover their IPv6 VIP (fe80::1) moves from the master to the backup one. We found that only our Bionic VMs behind those gateways had issues after a failover. Those Bionic VMs were all running systemd-networkd (from netplan) and before the failover they had: $ ip -6 route ... default via fe80::1 dev eth0 proto ra metric 1024 pref medium But after a failover: $ ip -6 route ... default proto ra metric 1024 nexthop via fe80::1 dev eth0 weight 1 nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1 And after another failover: $ ip -6 route ... default proto ra metric 1024 nexthop via fe80::1 dev eth0 weight 1 nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1 nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1 This is problematic as those then use fe80::210:18ff:fe77:b558%$IFACE as their default gateway even when this gateway is unavailable: $ ip -6 route get :: :: from :: via fe80::210:18ff:fe77:b558 dev eth0 proto ra src fe80::a800:ff:fe51:8c37 metric 1024 pref medium We concluded it was a systemd-networkd bug after checking that the following combinations were NOT affected: 1) Xenial+4.4 kernel 2) Xenial+4.15 kernel 3) Bionic+ifupdown Additional information: $ apt-cache policy systemd systemd: Installed: 237-3ubuntu10.3 Candidate: 237-3ubuntu10.3 Version table: *** 237-3ubuntu10.3 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages $ lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.3 ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18 Uname: Linux 4.15.0-38-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.4 Architecture: amd64 Date: Wed Oct 31 08:47:28 2018 Lspci: Error: [Errno 2] No such file or directory: 'lspci': 'lspci' Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb' MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic root=UUID=43b7ee2e-2ab1-4505-8e0b-d9fe0563a034 ro console=ttyS0 net.ifnames=0 vsyscall=none kaslr nmi_watchdog=0 possible_cpus=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-xenial dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1800836/+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 1905285] Re: socket-activated sshd breaks on concurrent connections
** Changed in: openssh (Ubuntu Focal)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1905285
Title:
socket-activated sshd breaks on concurrent connections
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Focal:
In Progress
Bug description:
[Impact]
Users of the systemd socket activated ssh service may experience a
race condition that may lead an ssh instance to fail.
The race condition happens when, for a running socket activated ssh
service,
an instance A is started, creating the RuntimeDirectory for the
service; then
an instance B is started, relying on the RuntimeDirectory created for
instance A; then
instance A halts, causing the RuntimeDirectory to be deleted.
If, at this point, instance B has not chrooted into RuntimeDirectory
yet, then instance B will fail.
The proposed patch fixes the issue by preserving the RuntimeDirectory
after an instance A of the socket activated ssh service halts.
[Test Plan]
1) Stop any running instances of ssh.
`systemctl stop ssh`
2) Start the socket activated ssh service.
`systemctl start ssh.socket`
3) Verify that no errors related to ssh were logged in /var/log/auth.log
`cat /var/log/auth.log | grep 'sshd.*fatal.*chroot.*No such file or
directory'`
4) perform several ssh connections to the running server in a short time
span. ssh-keyscan may help here.
`ssh-keyscan localhost`
5) Verify that errors related to ssh were logged in /var/log/auth.log
`cat /var/log/auth.log | grep 'sshd.*fatal.*chroot.*No such file or
directory'`
6) Apply the proposed fix (make sure the socket activated service is
restarted)
7) repead step (4), then verify that no new entries were appended to
the step (5) output
[Where problems could occur]
If the changes to the socket activated unit file are wrong, the socket
activated service may fail to start after the package upgrade. In this
case, we would need to instruct users to perform local changes to the
unit file with possible additional fixes while a new version of the
patch lands.
[Other Info]
This fix has been forwarded to Debian and accepted in
https://salsa.debian.org/ssh-team/openssh/-/merge_requests/12
[Original message]
This is mostly the same issue as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=934663.
With the default configuration of openssh-server and systemd, sshd
will complain and crash when multiple connections are made and
terminated in a quick succession, e.g. with `ssh-keyscan`. It results
in the following errors in /var/log/auth.log:
```
Nov 22 20:53:34 {host} sshd[14567]: Unable to negotiate with {client} port
41460: no matching host key type found. Their offer:
sk-ecdsa-sha2-nistp...@openssh.com [preauth]
Nov 22 20:53:34 {host} sshd[14570]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14569]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14568]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14566]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:47 {host} sshd[14584]: Connection closed by {client} port 59312
[preauth]
Nov 22 20:53:47 {host} sshd[14586]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:48 {host} sshd[14585]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
```
as well as e.g. missing responses in ssh-keyscan:
```
$ ssh-keyscan -vvv {host}
debug2: fd 3 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 2
debug2: fd 4 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 4
debug2: fd 5 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 8
debug2: fd 6 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 32
debug2: fd 7 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 64
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x0400
# {host}:22 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: sk-ecdsa-sha2-nistp...@openssh.com
debug2: ciphers ctos:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: ciphers stoc:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openss
Re: [Touch-packages] [Bug 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
The mosquitto test seems to be failing regardless of the version of openssl, I'll take a look at puma. On Tue, Jul 27, 2021 at 1:35 PM Gunnar Hjalmarsson < 1931...@bugs.launchpad.net> wrote: > @Simon: autopkgtest for mosquitto and puma fails on s390x. > > https://people.canonical.com/~ubuntu-archive/proposed- > migration/update_excuses.html#openssl > > Please investigate. > > -- > You received this bug notification because you are a member of Canonical > Foundations Team, which is a bug assignee. > https://bugs.launchpad.net/bugs/1931994 > > Title: > [Ubuntu 20.04] OpenSSL bugs im s390x AES code > > Status in Ubuntu on IBM z Systems: > In Progress > Status in openssl package in Ubuntu: > Fix Committed > Status in openssl source package in Bionic: > New > Status in openssl source package in Focal: > New > Status in openssl source package in Hirsute: > New > Status in openssl source package in Impish: > Fix Committed > > Bug description: > Problem description: > > When passing a NULL key to reset AES EVC state, the state wouldn't be > completely reset on s390x. > https://github.com/openssl/openssl/pull/14900 > > Solution available here: > > https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 > > Should be applied to all distros where openssl 1.1.1 is included for > consistency reason. > -> 21.10, 20.04, 18.04. > I think not needed for 16.04 anymore > > [Test plan] > > $ sudo apt install libssl-dev > $ gcc test.c -o evc-test -lcrypto -lssl # See > https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 > for the test.c program > $ ./evc-test && echo OK > > [Where problems could occur] > > This patch only touches s390x code paths, so there shouldn't be any > regression on other architectures. However, on s390x this could reveal > latent bugs by spreading a NULL key to new code paths. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+subscriptions > > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: Fix Committed Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: Fix Committed Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
@Simon: autopkgtest for mosquitto and puma fails on s390x. https://people.canonical.com/~ubuntu-archive/proposed- migration/update_excuses.html#openssl Please investigate. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: Fix Committed Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: Fix Committed Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1937922] Re: gtk4 not built for i386
gtk4 has now been built on i386 - thanks Steve! - and I have uploaded ibus with gtk4 support (needs to be approved in the NEW queue). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1937922 Title: gtk4 not built for i386 Status in gtk4 package in Ubuntu: Fix Released Status in ibus package in Ubuntu: In Progress Bug description: I'm trying to enable GTK 4 when building ibus: https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus2/+packages Up to now ibus has been built also on i386, but gtk4 has not been built on that arch, so the i386 build fails due to missing build dependencies. Is it time to stop building ibus on i386? Or can we build gtk4 on i386 (it was successfully built on Debian's i386)? At least some step needs to be taken. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk4/+bug/1937922/+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 1921484] Re: libedit no longer reads editrc
The bug is still there. Rendering the mysql client almost useless. You can not work efficient with the mysql client without proper keybindings. Either put mysql pack to readline or make libedit to read .editrc. It's a pity and it is annoying. DISTRIB_ID=Ubuntu DISTRIB_RELEASE=21.04 DISTRIB_CODENAME=hirsute DISTRIB_DESCRIPTION="Ubuntu 21.04" -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libedit in Ubuntu. https://bugs.launchpad.net/bugs/1921484 Title: libedit no longer reads editrc Status in libedit package in Ubuntu: Confirmed Bug description: strings /usr/lib/x86_64-linux-gnu/libedit.so.2.0.56 |grep editrc in Ubuntu 18.04 LTS returns /.editrc as expected but strings /usr/lib/x86_64-linux-gnu/libedit.so.2.0.63 |grep editrc in Ubuntu 20.04 LTS comes back empty. Verified with strace'ing the mysql client as well: editrc is no longer picked up, making mysql rather irritating to use. Peeking at the source code, the problematic commit is d253f567 which wraps the editrc code in an "#ifdef HAVE_ISSETUGID" which is BSD only. I am unable to find upstream in version control to help further. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libedit/+bug/1921484/+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 1938144] [NEW] monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange
Public bug reported: I'm using openssh 1:8.2p1-4ubuntu0.2 on Ubuntu 20.04.2 LTS (client and server) with the option "GSSAPIKeyExchange=yes", and this causes the connection to fail. The server has GSSAPI (Kerberos authentication) enabled, but is is only used for non-root users (root uses SSH keys). Client command: ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex root@server -v -p -o GSSAPIKeyExchange=yes Client log: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f 31 Mar 2020 debug1: Reading configuration data /home/user/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to compute-test [130.75.80.46] port . debug1: Connection established. debug1: identity file /home/rother/.ssh/id_rsa type 0 debug1: identity file /home/rother/.ssh/id_rsa-cert type -1 debug1: identity file /home/rother/.ssh/id_dsa type -1 debug1: identity file /home/rother/.ssh/id_dsa-cert type -1 debug1: identity file /home/rother/.ssh/id_ecdsa type -1 debug1: identity file /home/rother/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/rother/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/rother/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/rother/.ssh/id_ed25519 type -1 debug1: identity file /home/rother/.ssh/id_ed25519-cert type -1 debug1: identity file /home/rother/.ssh/id_ed25519_sk type -1 debug1: identity file /home/rother/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/rother/.ssh/id_xmss type -1 debug1: identity file /home/rother/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x0400 debug1: Authenticating to server: as 'root' debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q== debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g== debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: compression: none debug1: Doing group exchange debug1: Calling gss_init_sec_context debug1: Delegating credentials debug1: Received GSSAPI_COMPLETE debug1: Calling gss_init_sec_context debug1: Delegating credentials debug1: Rekey has happened - updating saved versions debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: Will attempt key: /home/rother/.ssh/id_rsa RSA SHA256:n/EY/cGjgd/r+7JpuqODxIotHHLsYptGXYx9GlKCWSM agent debug1: Will attempt key: /home/rother/.ssh/root_id_rsa RSA SHA256:yCLAID9FMILharHmDpCB8wW8eiA+iHa4oQKLODbbzKw agent debug1: Will attempt key: /home/user/.ssh/id_dsa debug1: Will attempt key: /home/user/.ssh/id_ecdsa debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk debug1: Will attempt key: /home/user/.ssh/id_ed25519 debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk debug1: Will attempt key: /home/user/.ssh/id_xmss debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Delegating credentials debug1: Delegating credentials debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex Connection closed by 1.2.3.4 port Server log: debug1: sshd version OpenSSH_8.2, OpenSSL 1.1.1f 31 Mar 2020 debug1: private host key #0: ssh-rsa SHA256:REDACTED debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:REDACTED debug1: private host key #2: ssh-ed25519 SHA256:REDACTED debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='' debug1: Set /proc/self/oom_score_adj from 0 to -1000 debug1: Bind to port on 0.0.0.0. Server listening on 0.0.0.0 port . debug1: Bind to port on ::. Server listening on :: port . debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: sshd version OpenSSH_8.2, OpenSSL 1.1.1f 31 Mar 2020 debug1: private host key #0: ssh-rsa SHA256:REDACTED debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:REDACTED debu
[Touch-packages] [Bug 1551623] Re: [SRU] package gconf2 3.2.6-3ubuntu6 failed to install/upgrade: dependency problems - leaving triggers unprocessed
Getting this in 21.04 When I close the dialog with "close" It pops right back again and the upgrade is stuck. ** Attachment added: "Screenshot_20210727_124636.png" https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/1551623/+attachment/5513993/+files/Screenshot_20210727_124636.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gconf in Ubuntu. https://bugs.launchpad.net/bugs/1551623 Title: [SRU] package gconf2 3.2.6-3ubuntu6 failed to install/upgrade: dependency problems - leaving triggers unprocessed Status in gconf package in Ubuntu: Triaged Bug description: [Impact] During system upgrades, triggers for gconf2 might activate too early, while some of its dependencies aren't configured yet. This happens several times in a loop and stops the upgrade in the end. The attached debdiffs fix this issue by changing interest to interest- noawait in debian/gconf2.triggers file. The triggers will now activate near the end of upgrade. In addition, the debdiff for Bionic also contains a fix for FTBFS (bug 1834211). [Test Case] Triggers for gconf2 are usually activated on changes in /usr/share/GConf/gsettings folder, so the main Ubuntu edition (with GNOME) is most suitable for reproducing the issue. To reproduce it, install that edition, apply all updates, then try upgrading to the next release. [Regression Potential] None, interest-noawait trigger is known to work well in other packages (comment 31). [Other Info] Even if Cosmic goes EOL next month, the fix for it might be worth it for release upgrades. [Original Description] When upgrading from 15.10 to 16.04Beta (2016-03-01), this error occured, alongside many others related to systemd and gnome. Notice that despite all warnings and errors, finally, the system remained functional. ProblemType: Package DistroRelease: Ubuntu 16.04 Package: gconf2 3.2.6-3ubuntu6 ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2 Uname: Linux 4.4.0-8-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 Date: Tue Mar 1 09:21:15 2016 ErrorMessage: dependency problems - leaving triggers unprocessed InstallationDate: Installed on 2015-10-04 (148 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20151002) RelatedPackageVersions: dpkg 1.18.4ubuntu1 apt 1.2.3 SourcePackage: gconf Title: package gconf2 3.2.6-3ubuntu6 failed to install/upgrade: dependency problems - leaving triggers unprocessed UpgradeStatus: Upgraded to xenial on 2016-03-01 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/1551623/+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 1931994] Comment bridged from LTC Bugzilla
--- Comment From boris.m...@de.ibm.com 2021-07-27 04:23 EDT--- Attachment "Standalone C program from the upstream test case" removed on the bugzilla side as requested by Canonical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: Fix Committed Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: Fix Committed Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1800836] Re: systemd-networkd doesn't process IPv6 RA properly
This bug is still present on Ubuntu 18.04.5 LTS with systemd 237-3ubuntu10.50. Please reopen. -- 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/1800836 Title: systemd-networkd doesn't process IPv6 RA properly Status in systemd package in Ubuntu: Invalid Bug description: The gateways/firewalls in our DC are highly available and when there is a failover their IPv6 VIP (fe80::1) moves from the master to the backup one. We found that only our Bionic VMs behind those gateways had issues after a failover. Those Bionic VMs were all running systemd-networkd (from netplan) and before the failover they had: $ ip -6 route ... default via fe80::1 dev eth0 proto ra metric 1024 pref medium But after a failover: $ ip -6 route ... default proto ra metric 1024 nexthop via fe80::1 dev eth0 weight 1 nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1 And after another failover: $ ip -6 route ... default proto ra metric 1024 nexthop via fe80::1 dev eth0 weight 1 nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1 nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1 This is problematic as those then use fe80::210:18ff:fe77:b558%$IFACE as their default gateway even when this gateway is unavailable: $ ip -6 route get :: :: from :: via fe80::210:18ff:fe77:b558 dev eth0 proto ra src fe80::a800:ff:fe51:8c37 metric 1024 pref medium We concluded it was a systemd-networkd bug after checking that the following combinations were NOT affected: 1) Xenial+4.4 kernel 2) Xenial+4.15 kernel 3) Bionic+ifupdown Additional information: $ apt-cache policy systemd systemd: Installed: 237-3ubuntu10.3 Candidate: 237-3ubuntu10.3 Version table: *** 237-3ubuntu10.3 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages $ lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.3 ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18 Uname: Linux 4.15.0-38-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.4 Architecture: amd64 Date: Wed Oct 31 08:47:28 2018 Lspci: Error: [Errno 2] No such file or directory: 'lspci': 'lspci' Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb' MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic root=UUID=43b7ee2e-2ab1-4505-8e0b-d9fe0563a034 ro console=ttyS0 net.ifnames=0 vsyscall=none kaslr nmi_watchdog=0 possible_cpus=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-xenial dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1800836/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
@schopin that is a (known) issue with the bugzilla-launchpad bridge that is in place here (bugproxy is the functional user id for this). I'll ask to get the "Standalone C program from the upstream test case" attachment removed on the bugzilla side, that should help ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: Fix Committed Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: Fix Committed Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1937922] Re: gtk4 not built for i386
** Also affects: gtk4 (Ubuntu) Importance: Undecided Status: New ** Changed in: gtk4 (Ubuntu) Status: New => Fix Released ** Changed in: ibus (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1937922 Title: gtk4 not built for i386 Status in gtk4 package in Ubuntu: Fix Released Status in ibus package in Ubuntu: In Progress Bug description: I'm trying to enable GTK 4 when building ibus: https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus2/+packages Up to now ibus has been built also on i386, but gtk4 has not been built on that arch, so the i386 build fails due to missing build dependencies. Is it time to stop building ibus on i386? Or can we build gtk4 on i386 (it was successfully built on Debian's i386)? At least some step needs to be taken. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk4/+bug/1937922/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
Oh, and thank you very much for the upload, much appreciated :-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: Fix Committed Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: Fix Committed Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
Regarding the bugproxy test case, it should be disregarded: I was the one who originally added it, but then found a much smaller and self- contained test case, and removed the attachment. For some reason, bugproxy didn't like that. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: Fix Committed Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: Fix Committed Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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
