[Touch-packages] [Bug 1381623] Re: CRITICAL: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed
NOT fixed !!! This message, among several others, repeats rapidly, hard drive continually seeks, system unusable. Reboot, runs ok for a while (couple hours or so), then it starts again. Sometimes I have to use the reset button to stop it, sometimes I can get to restart. Just a very short set of sample4s below : Aug 31 21:24:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:25:03 roger-desktop rtkit-daemon[1573]: Supervising 5 threads of 2 processes of 1 users. Aug 31 21:25:05 roger-desktop rtkit-daemon[1573]: message repeated 3 times: [ Supervising 5 threads of 2 processes of 1 users.] Aug 31 21:25:26 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:25:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:25:26 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:25:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:25:26 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:25:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:25:50 roger-desktop PackageKit: daemon quit Aug 31 21:25:50 roger-desktop systemd[1]: packagekit.service: Succeeded. Aug 31 21:25:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:25:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:25:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:25:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:25:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:25:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:26:26 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:26:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:26:26 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:26:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:26:26 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:26:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:26:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:26:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:26:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:26:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:26:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:26:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:27:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:27:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:27:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:27:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:27:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:27:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:28:26 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:28:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:28:26 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:28:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:28:26 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:28:26 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:28:56 roger-desktop gnome-panel[2348]: gtk_icon_info_get_filename: assertion 'icon_info != NULL' failed Aug 31 21:28:56 roger-desktop gnome-panel[2348]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Aug 31 21:28:56
[Touch-packages] [Bug 1948882] Re: PulseEffects does not properly initialize on startup
Can someone explain in a noob friendly way how to install the 4.8.7-1 version from the kinetic testing repo? I am experiencing this bug on Linux Mint 21 XFCE (Jammy) and PulseEffects 4.8.4-1 and don't know enough to be able to figure it out on my own... can you post the terminal commands to install this new bugfix version please? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to d-conf in Ubuntu. https://bugs.launchpad.net/bugs/1948882 Title: PulseEffects does not properly initialize on startup Status in d-conf package in Ubuntu: Confirmed Status in pulseeffects package in Ubuntu: Confirmed Bug description: In KUbuntu 21.10, PulseEffects no longer initializes its effects chain on startup. I usually use only Equalizer, so when I log into KDE, this equalizer does not get activated. To ativate it I need (i) start PulseEffects GUI, (ii) untic and tic again the "Equalizer" box. This is rarher annoying sequence that I have to repeat each time I login. Previousy, in ubuntu 21.04, all this was unnecessary. PluseEffets just worked immediately after logging in, without any additional actions. I would expect the same behaviour in 21.10. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: pulseeffects 4.8.4-1 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Wed Oct 27 02:56:47 2021 InstallationDate: Installed on 2017-04-03 (1667 days ago) InstallationMedia: Kubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) ProcEnviron: LANGUAGE=ru PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash SourcePackage: pulseeffects UpgradeStatus: Upgraded to impish on 2021-09-24 (32 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/d-conf/+bug/1948882/+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 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
Embarrassingly it seems that this week I'm getting more proper behavior. I will keep trying to replicate here as time permits, but the system applied some updates automatically and I also installed a few things since the first incident (sane, wireshark, etc). Rolling everything back isn't much of an option for me right now. -- 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/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Invalid Status in systemd package in Ubuntu: Incomplete Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+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 1988364] Re: Sony WH-1000XM4 missing the A2DP profile and defaults to low quality
** Also affects: bluez (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: bluez (Ubuntu Jammy) Status: New => Triaged ** Changed in: bluez (Ubuntu Jammy) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1988364 Title: Sony WH-1000XM4 missing the A2DP profile and defaults to low quality Status in Bluez Utilities: Unknown Status in bluez package in Ubuntu: Fix Released Status in bluez source package in Jammy: Triaged Bug description: Sony WH-1000XM4 missing the A2DP profile and defaults to low quality https://github.com/bluez/bluez/issues/313 To manage notifications about this bug go to: https://bugs.launchpad.net/bluez/+bug/1988364/+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 1982739] Re: BlueZ 5.65 release
Rafael, I have opened bug 1988364 to track that issue and future backporting of the fix to jammy. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1982739 Title: BlueZ 5.65 release Status in bluez package in Ubuntu: Fix Released Bug description: Release BlueZ 5.65 to kinetic: https://mirrors.edge.kernel.org/pub/linux/bluetooth/bluez-5.65.tar.xz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1982739/+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 1988364] Re: Sony WH-1000XM4 missing the A2DP profile and defaults to low quality
The fix is: https://github.com/bluez/bluez/commit/62e591578e3f948e187aacf44ede4286fad37ad7 ** Tags added: rls-jj-incoming ** Changed in: bluez (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1988364 Title: Sony WH-1000XM4 missing the A2DP profile and defaults to low quality Status in Bluez Utilities: Unknown Status in bluez package in Ubuntu: Fix Released Bug description: Sony WH-1000XM4 missing the A2DP profile and defaults to low quality https://github.com/bluez/bluez/issues/313 To manage notifications about this bug go to: https://bugs.launchpad.net/bluez/+bug/1988364/+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 1988364] [NEW] Sony WH-1000XM4 missing the A2DP profile and defaults to low quality
Public bug reported: Sony WH-1000XM4 missing the A2DP profile and defaults to low quality https://github.com/bluez/bluez/issues/313 ** Affects: bluez Importance: Unknown Status: Unknown ** Affects: bluez (Ubuntu) Importance: High Status: Fix Released ** Tags: fixed-in-5.65 fixed-upstream rls-jj-incoming ** Bug watch added: github.com/bluez/bluez/issues #313 https://github.com/bluez/bluez/issues/313 ** Also affects: bluez via https://github.com/bluez/bluez/issues/313 Importance: Unknown Status: Unknown ** Changed in: bluez (Ubuntu) Status: New => Fix Released ** Tags added: fixed-in-5.65 fixed-upstream -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1988364 Title: Sony WH-1000XM4 missing the A2DP profile and defaults to low quality Status in Bluez Utilities: Unknown Status in bluez package in Ubuntu: Fix Released Bug description: Sony WH-1000XM4 missing the A2DP profile and defaults to low quality https://github.com/bluez/bluez/issues/313 To manage notifications about this bug go to: https://bugs.launchpad.net/bluez/+bug/1988364/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
We got bite by this but we added a cron to our 18.04 instances: * * * * * host google.com || dhclient works-for-us :-) HTH, Norberto -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1986984] Re: [FFe] tzdata 2022c update
I've retried the mtail test.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1986984
Title:
[FFe] tzdata 2022c update
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Confirmed
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Jammy:
Fix Committed
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022a.
[Test Case for releases <= 20.04 LTS]
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. Subsequently, these should be checked for using the following:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
[Original report]
tzdata 2022b and 2022c were just released that includes some timezone changes
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a
change to the start of their daylight savings and pushed it from Sept 4th to
the 11th, so we really need our servers updated before the 4th.
Thanks
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
The failure mode still exists if "udevadm trigger" has been issued before the package upgrade to systemd 237-3ubuntu10.55. That is, if unattended-upgrades or the user had installed open-vm-tools, and has not rebooted yet, they will lose network connection on upgrade to 237-3ubuntu10.55. We need to implement a way to add ID_NET_DRIVER back to the device before the systemd upgrade takes place, otherwise an outage will occur. Release admins - DO NOT RELEASE systemd 237-3ubuntu10.55 yet. Tagging block-proposed. $ ping google.com PING google.com (142.251.45.110) 56(84) bytes of data. 64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=1 ttl=56 time=1.51 ms 64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=2 ttl=56 time=1.35 ms 64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=3 ttl=56 time=1.17 ms ^C --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.172/1.349/1.516/0.140 ms azureuser@mruffell-test:~$ sudo apt-cache policy systemd | grep Installed Installed: 237-3ubuntu10.53 azureuser@mruffell-test:~$ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc azureuser@mruffell-test:~$ sudo udevadm trigger azureuser@mruffell-test:~$ ping google.com PING google.com (142.251.45.110) 56(84) bytes of data. 64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=1 ttl=56 time=2.15 ms 64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=2 ttl=56 time=1.21 ms ^C --- google.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 1.212/1.682/2.152/0.470 ms azureuser@mruffell-test:~$ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER azureuser@mruffell-test:~$ sudo apt install libnss-systemd libpam-systemd libsystemd0 libudev1 systemd systemd-sysv udev Reading package lists... Done Building dependency tree Reading state information... Done The following package was automatically installed and is no longer required: linux-headers-4.15.0-191 Use 'sudo apt autoremove' to remove it. Suggested packages: systemd-container The following packages will be upgraded: libnss-systemd libpam-systemd libsystemd0 libudev1 systemd systemd-sysv udev 7 upgraded, 0 newly installed, 0 to remove and 8 not upgraded. Need to get 4497 kB of archives. After this operation, 8192 B of additional disk space will be used. Get:1 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main amd64 libsystemd0 amd64 237-3ubuntu10.55 [205 kB] Get:2 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main amd64 libnss-systemd amd64 237-3ubuntu10.55 [105 kB] Get:3 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main amd64 libpam-systemd amd64 237-3ubuntu10.55 [107 kB] Get:4 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main amd64 systemd amd64 237-3ubuntu10.55 [2915 kB] Get:5 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main amd64 udev amd64 237-3ubuntu10.55 [1099 kB] Get:6 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main amd64 libudev1 amd64 237-3ubuntu10.55 [54.2 kB] Get:7 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main amd64 systemd-sysv amd64 237-3ubuntu10.55 [12.0 kB] Fetched 4497 kB in 3s (1461 kB/s) (Reading database ... 77176 files and directories currently installed.) Preparing to unpack .../libsystemd0_237-3ubuntu10.55_amd64.deb ... Unpacking libsystemd0:amd64 (237-3ubuntu10.55) over (237-3ubuntu10.53) ... Setting up libsystemd0:amd64 (237-3ubuntu10.55) ... (Reading database ... 77176 files and directories currently installed.) Preparing to unpack .../libnss-systemd_237-3ubuntu10.55_amd64.deb ... Unpacking libnss-systemd:amd64 (237-3ubuntu10.55) over (237-3ubuntu10.53) ... Preparing to unpack .../libpam-systemd_237-3ubuntu10.55_amd64.deb ... Unpacking libpam-systemd:amd64 (237-3ubuntu10.55) over (237-3ubuntu10.53) ... Preparing to unpack .../systemd_237-3ubuntu10.55_amd64.deb ... Unpacking systemd (237-3ubuntu10.55) over (237-3ubuntu10.53) ... Preparing to unpack .../udev_237-3ubuntu10.55_amd64.deb ... Unpacking udev (237-3ubuntu10.55) over (237-3ubuntu10.53) ... Preparing to unpack .../libudev1_237-3ubuntu10.55_amd64.deb ... Unpacking libudev1:amd64 (237-3ubuntu10.55) over (237-3ubuntu10.53) ... Setting up libudev1:amd64 (237-3ubuntu10.55) ... Setting up systemd (237-3ubuntu10.55) ... (Reading database ... 77176 files and directories currently installed.) Preparing to unpack .../systemd-sysv_237-3ubuntu10.55_amd64.deb ... Unpacking systemd-sysv (237-3ubuntu10.55) over (237-3ubuntu10.53) ... Setting up libnss-systemd:amd64 (237-3ubuntu10.55) ... Setting up systemd-sysv (237-3ubuntu10.55) ... Setting up udev (237-3ubuntu10.55) ... update-initramfs: deferring update (trigger activated) Setting up libpam-systemd:amd64 (237-3ubuntu10.55) ...
[Touch-packages] [Bug 1988144] Re: klist not showing tgt after reboot
Thanks for taking the time to report a bug and make Ubuntu better. I tried reproducing the problem here but it seems there's something I'm missing. I have a Samba AD DC setup (running Focal, but that shouldn't matter) and I setup a Bionic client. I then obtained a ticket using "kinit", verified that the ticket is listed using "klist", and then reboot the VM. When it came back online, the ticket was gone. The same behaviour happens if I setup a Focal client, BTW. I may be wrong, but looking at the ticket you got on the Bionic machine it seems to me that there's some extra configuration in your /etc/krb5.conf that may be causing this behaviour. Would it be possible for you to come up with a step-by-step reproducer for this problem, please? Thanks in advance. ** Changed in: krb5 (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to krb5 in Ubuntu. https://bugs.launchpad.net/bugs/1988144 Title: klist not showing tgt after reboot Status in krb5 package in Ubuntu: Incomplete Bug description: Hello, iam not sure if this is a bug, but iam noticed a different behaviour of kinit/klist between Ubuntu 18.04 and 22.04 I already talked to sam hartman who is maintainer of krb5 packages at debian and he told that basically there is no difference between different version of kinit/klist and one should dig in Ubuntu environment. Let me decribe the notice: We use kinit/klist/krb5 keytab as base for sssd and ssh access controlled by AD. In Ubuntu 18.04 LTS i could do: "kinit myprincipal" and created a valid tgt. This tgt was stable and survived a reboot which can be viewed by "klist". I log in as unprivileged user, doing "sudo -i" and see: myhost: # klist Ticket cache: FILE:/tmp/krb5cc_27465975_uqBiyq File /tmp/krb5cc_27465975_uqBiyq is existent and owned by my unprivileged username and group domainusers. Ubuntu 18.04 LTS is using 1.16-2ubuntu0.2 of krb5-user. i have to say, that first login as unprivileged user is done by using ssh-keypair, so no sssd is involved. But by using "sudo -i" sssd is used and worked like expected. Now we switched to Ubuntu 22.04 LTS, Version of krb5-user is 1.19.2-2 Doing kinit myprincipal on 22.04 leads to: myhost: # klist Ticket cache: FILE:/tmp/krb5cc_0 File /tmp/krb5cc_0 is owned by root:root After reboot i can still login successful as unprivileged user make "sudo -i" and klist says: myhost: # klist klist: No credentials cache found (filename: /tmp/krb5cc_0 File /tmp/krb5cc_0 is gone (deleted from unknown), but i see a file /tmp/krb5cc_27465975_nGySkP which is owned by my unprivileged username and group is domainusers. is this expected? It seems that newer klist always wants to use the default name /tmp/krb5cc_0. It creates tgt with this name and tries to read this filename. but after reboot file is recreated with different name and default klist command fails. First login as unprivilged user was done with ssh-keypair without sssd, but "sudo -i" uses sssd agin. Whole thing only works like in 18.04 if you dont use ssh-keypairs and do all logins by hand with manually login, so sssd is forced to use in every step. What do you think? Is this a bug or wrong use? Behaviour of 18.04 was absolutely satisfying. Thanks, Hans To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1988144/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
** Changed in: systemd (Ubuntu Bionic) Status: Fix Released => Fix Committed -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
I've blindly retried both of these failures. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1974115 Title: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16 Status in Ubuntu on IBM z Systems: Fix Committed Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: Fix Committed Status in binutils source package in Kinetic: Fix Released Bug description: SRU Justification: == [Impact] * As of today the architectural (level) name 'arch14' is used as CPU name for the new IBM z16 system. * The real name 'z16' couldn't be used until officially announced. * That happened meanwhile, hence we can now add and use the real name. [Test Plan] * Check if the same (proper) opcodes are detected on an IBM z16 system with and without the patch. Since only the identification and name of a z16 system was modified. * Or the simplest test is probably to check (after having 'binutils' installed on an Ubuntu 22.04 s390x system) if not only: 'as -m64 -march=arch14 --target-help' but also: 'as -m64 -march=z16 --target-help' succeeds and leads to the same output. (As it does for '-march=arch13' and '-march=arch15'.) [Where problems could occur] * Issues could happen if the conditional statement that look for architectural / CPU name are paired wrongly, since: * 'z16' belongs to 'arch14', 'z15' to 'arch13', etc. * If these pairs are not handled correctly, or the identification is erroneous a wrong system might be identified and wrong instructions used etc. [Other] * This is a hardware enablement SRU to enhance the IBM z16 support. __ After the announcement support for the official machine name z16 has been added to binutils. Please consider picking up the following patch from 2.37 branch: commit e24d2a2d11008aa363366c1087219f3e3405782a (origin/binutils-2_37-branch, 2.37) IBM zSystems: Add support for z16 as CPU name. So far z16 was identified as arch14. After the machine has been announced we can now add the real name. (cherry picked from commit 69341966def7f6551bc4452684136831d6a6941c) (cherry picked from commit fb4d148004f28494e9fb5d2400a13308d07a7988) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1974115/+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 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
** Changed in: systemd (Ubuntu) Status: Invalid => 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/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Invalid Status in systemd package in Ubuntu: Incomplete Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+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 1955135] Re: multiple issues with /etc/X11/Xsession.d/ - "has_option: command not found"
*** This bug is a duplicate of bug 1922414 *** https://bugs.launchpad.net/bugs/1922414 Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: xorg (Ubuntu) Status: New => Confirmed -- 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/1955135 Title: multiple issues with /etc/X11/Xsession.d/ - "has_option: command not found" Status in dbus package in Ubuntu: Confirmed Status in xorg package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Boot 20211217 Ubuntu MATE daily ISO 2. Open ~/.xsession-errors Expected results: * no errors and warnings Actual results: * there are two errors about xorg: /etc/X11/Xsession.d/30x11-common_xresources: line 16: has_option: command not found /etc/X11/Xsession.d/90x11-common_ssh-agent: line 9: has_option: command not found ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: x11-common 1:7.7+23ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14 Uname: Linux 5.13.0-19-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu74 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CasperVersion: 1.465 CompositorRunning: None CurrentDesktop: MATE Date: Fri Dec 17 14:22:15 2021 Dependencies: lsb-base 11.1.0ubuntu3 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: NVIDIA Corporation GF108M [GeForce GT 425M] [10de:0df0] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Sony Corporation GF108M [GeForce GT 425M] [104d:907a] LiveMediaBuild: Ubuntu-MATE 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211217) MachineType: Sony Corporation VPCF13Z1R PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/username.seed maybe-ubiquity quiet splash --- SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/20/2010 dmi.bios.release: 1.90 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: R0190Y9 dmi.board.asset.tag: N/A dmi.board.name: VAIO dmi.board.vendor: Sony Corporation dmi.board.version: N/A dmi.chassis.asset.tag: N/A dmi.chassis.type: 10 dmi.chassis.vendor: Sony Corporation dmi.chassis.version: N/A dmi.ec.firmware.release: 1.90 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrR0190Y9:bd10/20/2010:br1.90:efr1.90:svnSonyCorporation:pnVPCF13Z1R:pvrC606GZYK:skuN/A:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A: dmi.product.family: VAIO dmi.product.name: VPCF13Z1R dmi.product.sku: N/A dmi.product.version: C606GZYK dmi.sys.vendor: Sony Corporation version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1955135/+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 1955135] Re: multiple issues with /etc/X11/Xsession.d/ - "has_option: command not found"
*** This bug is a duplicate of bug 1922414 *** https://bugs.launchpad.net/bugs/1922414 Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: dbus (Ubuntu) Status: New => Confirmed -- 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/1955135 Title: multiple issues with /etc/X11/Xsession.d/ - "has_option: command not found" Status in dbus package in Ubuntu: Confirmed Status in xorg package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Boot 20211217 Ubuntu MATE daily ISO 2. Open ~/.xsession-errors Expected results: * no errors and warnings Actual results: * there are two errors about xorg: /etc/X11/Xsession.d/30x11-common_xresources: line 16: has_option: command not found /etc/X11/Xsession.d/90x11-common_ssh-agent: line 9: has_option: command not found ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: x11-common 1:7.7+23ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14 Uname: Linux 5.13.0-19-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu74 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CasperVersion: 1.465 CompositorRunning: None CurrentDesktop: MATE Date: Fri Dec 17 14:22:15 2021 Dependencies: lsb-base 11.1.0ubuntu3 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: NVIDIA Corporation GF108M [GeForce GT 425M] [10de:0df0] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Sony Corporation GF108M [GeForce GT 425M] [104d:907a] LiveMediaBuild: Ubuntu-MATE 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211217) MachineType: Sony Corporation VPCF13Z1R PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/username.seed maybe-ubiquity quiet splash --- SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/20/2010 dmi.bios.release: 1.90 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: R0190Y9 dmi.board.asset.tag: N/A dmi.board.name: VAIO dmi.board.vendor: Sony Corporation dmi.board.version: N/A dmi.chassis.asset.tag: N/A dmi.chassis.type: 10 dmi.chassis.vendor: Sony Corporation dmi.chassis.version: N/A dmi.ec.firmware.release: 1.90 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrR0190Y9:bd10/20/2010:br1.90:efr1.90:svnSonyCorporation:pnVPCF13Z1R:pvrC606GZYK:skuN/A:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A: dmi.product.family: VAIO dmi.product.name: VPCF13Z1R dmi.product.sku: N/A dmi.product.version: C606GZYK dmi.sys.vendor: Sony Corporation version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1955135/+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 1971932] Re: error in rsync protocol data stream
There are a few upstream issues that seem to be related to this one, but https://github.com/WayneD/rsync/issues/86 seems like the most likely candidate. Not using "-z" was determined to be a possible workaround here. If any of you (who can actually reproduce the issue) can check if "-zz" also works, then we can establish the relation between both bugs. Thanks. ** Bug watch added: github.com/WayneD/rsync/issues #86 https://github.com/WayneD/rsync/issues/86 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1971932 Title: error in rsync protocol data stream Status in rsync package in Ubuntu: Confirmed Bug description: When synchronizing to other systems, rsync exits with "error in rsync protocol data stream (code 12)". The problem occurs since ubuntu 22.04 LTS with two different destination systems not running ubuntu but plain debian. The error did not occur under 20.04 LTS. Synchronisation runs fine for most other files, but always stops at the same (relative large) file. The file itself has also been changed on a test basis to make sure the file is not the problem itself. Log snippet: ... chunk[46131] len=46120 offset=2127561720 sum1=2f48caf4 chunk[46132] len=46120 offset=2127607840 sum1=5dfcb4ee chunk[46133] len=46120 offset=2127653960 sum1=d1037d81 chunk[46134] len=8870 offset=2127700080 sum1=6deedc97 send_files mapped /path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX of size 2135722584 calling match_sums /path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX built hash table hash search b=46120 len=2135722584 sum=1e1722dc k=46120 hash search s->blength=46120 len=2135722584 count=46135 potential match at 0 i=0 sum=1e1722dc match at 0 last_match=0 j=0 len=46120 n=0 potential match at 46120 i=1 sum=c482d6b6 match at 46120 last_match=46120 j=1 len=46120 n=0 potential match at 92240 i=2 sum=b21c7e11 match at 92240 last_match=92240 j=2 len=46120 n=0 potential match at 138360 i=3 sum=d066473a match at 138360 last_match=138360 j=3 len=46120 n=0 potential match at 184480 i=4 sum=a32a2984 match at 184480 last_match=184480 j=4 len=46120 n=0 potential match at 230600 i=5 sum=39cc049f match at 230600 last_match=230600 j=5 len=46120 n=0 potential match at 276720 i=6 sum=ad3de98a match at 276720 last_match=276720 j=6 len=46120 n=0 potential match at 322840 i=7 sum=83e16fa9 match at 322840 last_match=322840 j=7 len=46120 n=0 deflate on token returned 0 (8512 bytes left) rsync error: error in rsync protocol data stream (code 12) at token.c(476) [sender=3.2.3] [sender] _exit_cleanup(code=12, file=token.c, line=476): entered [sender] _exit_cleanup(code=12, file=token.c, line=476): about to call exit(12) Sender system: (rsync 3.2.3-8ubuntu3) - rsync version 3.2.3 protocol version 31 Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others. Web site: https://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, hardlink-specials, symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv, symtimes, prealloc, stop-at, no crtimes Optimizations: SIMD, no asm, openssl-crypto Checksum list: xxh128 xxh3 xxh64 (xxhash) md5 md4 none Compress list: zstd lz4 zlibx zlib none rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. Recipient systems: (rsync 3.1.3-6) -- rsync version 3.1.3 protocol version 31 Copyright (C) 1996-2018 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes, prealloc rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1971932/+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 1986984] Autopkgtest regression report (tzdata/2022c-0ubuntu0.20.04.0)
All autopkgtests for the newly accepted tzdata (2022c-0ubuntu0.20.04.0) for
focal have finished running.
The following regressions have been reported in tests triggered by the package:
mtail/3.0.0~rc24.1-1ubuntu1 (armhf)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#tzdata
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1986984
Title:
[FFe] tzdata 2022c update
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Confirmed
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Jammy:
Fix Committed
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022a.
[Test Case for releases <= 20.04 LTS]
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. Subsequently, these should be checked for using the following:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
[Original report]
tzdata 2022b and 2022c were just released that includes some timezone changes
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a
change to the start of their daylight savings and pushed it from Sept 4th to
the 11th, so we really need our servers updated before the 4th.
Thanks
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1988010] Re: systemd ignoring DHCP DNS servers and DNS servers set in Network Manager GUI
Josh - Before applying your workaround, you can see which DNS servers systemd-resolved is using by running: $ resolvectl status What does that show you for DNS servers? Your servers, or something else entirely? -- 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/1988010 Title: systemd ignoring DHCP DNS servers and DNS servers set in Network Manager GUI Status in systemd package in Ubuntu: New Bug description: Hi there! I'm running ubuntu 22.04.1 LTS installed via the ISO image ubuntu-22.04.1-desktop-amd64.iso. This issue affects both the Live CD and installed operating system. I have configured my modem's DHCP server to push my adguard home DNS server (cloud-hosted) as the DNS for the network. I have an access point that is setup to do the same. With the Live CD and installed operating system, there is a local DNS server installed that runs on 127.0.0.1:53. Somehow this bypasses the DNS servers I've configured for the network and suddenly websites that have been blocked for being malicious or harmful are now accessible. There is no option in the installer or GUI to disable this. Changing the network DNS settings via the GUI of either the live cd or installation do not change the behavior and do not result in the specified DNS server(s) being used. The 127.0.0.1:53 server still overrides anything set in the GUI. The only way I have found to override this behavior is to edit /etc/systemd/resolved.conf: 1) uncomment DNSStubListener=yes 2) change yes to no 3) save file 4) run the following commands in terminal: sudo systemctl daemon-reload sudo systemctl restart systemd-networkd sudo systemctl restart systemd-resolved After doing so, the DNS servers that have been provided by DHCP are properly used. This is considered a security vulnerability due to there being no way for a normal user to change this setting without editing system configuration files and no warning given to the user that the settings they are applying in the GUI have not been applied due to this default configuration. This is considered a hack if this is the intentional configuration as it overrides network configuration options set by the DHCP server. I've resolved it for myself for now by making a custom iso image that removes this configuration by default and instead installs the /etc/systemd/resolved.conf file attached to this bug report. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd 249.11-0ubuntu3.4 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 Uname: Linux 5.15.0-46-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Aug 28 21:18:35 2022 InstallationDate: Installed on 2022-08-29 (0 days ago) InstallationMedia: Ubuntu 22.04.1 2022.08.28 LTS "Custom Jammy Jellyfish" (20220828) MachineType: Micro-Star International Co., Ltd. GS75 Stealth 9SG ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.15.0-46-generic root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/26/2019 dmi.bios.release: 1.12 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: E17G1IMS.10C dmi.board.asset.tag: Default string dmi.board.name: MS-17G1 dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: REV:1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrE17G1IMS.10C:bd03/26/2019:br1.12:svnMicro-StarInternationalCo.,Ltd.:pnGS75Stealth9SG:pvrREV1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMS-17G1:rvrREV1.0:cvnMicro-StarInternationalCo.,Ltd.:ct10:cvrN/A:sku17G1.1: dmi.product.family: GS dmi.product.name: GS75 Stealth 9SG dmi.product.sku: 17G1.1 dmi.product.version: REV:1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. mtime.conffile..etc.systemd.resolved.conf: 2022-08-28T19:29:41 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988010/+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 1983618] Update Released
The verification of the Stable Release Update for openldap has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1983618 Title: New upstream microrelease 2.5.13 Status in openldap package in Ubuntu: Invalid Status in openldap source package in Jammy: Fix Released Bug description: [ Impact ] * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.13. This update includes bugfixes only following the SRU policy exception defined at https://wiki.ubuntu.com/OpenLDAPUpdates. [ Major Changes ] * See the list of bugs fixed in this release here: https://lists.openldap.org/hyperkitty/list/openldap- annou...@openldap.org/thread/3PLJDVP7QWTRFHC2GPQTGBLEQFCBUZZ2/ [ Test Plan ] * Upstream gitlab pipeline results: https://git.openldap.org/openldap/openldap/-/pipelines/4504 * Upstream "call for testing": https://lists.openldap.org/hyperkitty/list/openldap- techni...@openldap.org/thread/RXOSXVLKTIDM4XJUA5EZZ42677JXRHYN/ * As described in the MRE wiki page for OpenLDAP, the test plan is to build the package in bileto and make sure that (1) all build-time tests pass and (2) all autopkgtest runs (from reverse dependencies) also pass. * Build log (amd64) confirming that the build-time testsuite has been performed and completed successfully: https://launchpad.net/~ci-train- ppa-service/+archive/ubuntu/4887/+build/24250107 * Bileto ticket: https://bileto.ubuntu.com/#/ticket/4895 [ Where problems could occur ] * Upstream tests are always executed during build-time. There are many reverse dependencies whose dep8 tests depend on OpenLDAP so the coverage is good. Nevertheless, there is always a risk for something to break since we are dealing with a microrelease upgrade. Whenever a test failure is detected, we will be on top of it and make sure it doesn't affect existing users. [ Other Info ] * This is a reoccurring MRE. See below for links to previous OpenLDAP MREs. * CVEs fixed by this release: - None. Current versions in supported releases that got updates: openldap | 2.5.12+dfsg-0ubuntu0.22.04.1 | jammy-updates | source Special cases: - None. Previous MREs for OpenLDAP: - https://pad.lv/1977627 As usual we test and prep from the PPA and then push through SRU/Security as applicable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1983618/+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 1983618] Re: New upstream microrelease 2.5.13
This bug was fixed in the package openldap - 2.5.13+dfsg-0ubuntu0.22.04.1 --- openldap (2.5.13+dfsg-0ubuntu0.22.04.1) jammy; urgency=medium * New upstream version (LP: #1983618). - Several fixes, including memory leaks that affected libldap. - Added slapo-emptyds contrib module (ITS#8882). -- Sergio Durigan Junior Fri, 05 Aug 2022 10:51:52 -0400 ** Changed in: openldap (Ubuntu Jammy) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1983618 Title: New upstream microrelease 2.5.13 Status in openldap package in Ubuntu: Invalid Status in openldap source package in Jammy: Fix Released Bug description: [ Impact ] * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.13. This update includes bugfixes only following the SRU policy exception defined at https://wiki.ubuntu.com/OpenLDAPUpdates. [ Major Changes ] * See the list of bugs fixed in this release here: https://lists.openldap.org/hyperkitty/list/openldap- annou...@openldap.org/thread/3PLJDVP7QWTRFHC2GPQTGBLEQFCBUZZ2/ [ Test Plan ] * Upstream gitlab pipeline results: https://git.openldap.org/openldap/openldap/-/pipelines/4504 * Upstream "call for testing": https://lists.openldap.org/hyperkitty/list/openldap- techni...@openldap.org/thread/RXOSXVLKTIDM4XJUA5EZZ42677JXRHYN/ * As described in the MRE wiki page for OpenLDAP, the test plan is to build the package in bileto and make sure that (1) all build-time tests pass and (2) all autopkgtest runs (from reverse dependencies) also pass. * Build log (amd64) confirming that the build-time testsuite has been performed and completed successfully: https://launchpad.net/~ci-train- ppa-service/+archive/ubuntu/4887/+build/24250107 * Bileto ticket: https://bileto.ubuntu.com/#/ticket/4895 [ Where problems could occur ] * Upstream tests are always executed during build-time. There are many reverse dependencies whose dep8 tests depend on OpenLDAP so the coverage is good. Nevertheless, there is always a risk for something to break since we are dealing with a microrelease upgrade. Whenever a test failure is detected, we will be on top of it and make sure it doesn't affect existing users. [ Other Info ] * This is a reoccurring MRE. See below for links to previous OpenLDAP MREs. * CVEs fixed by this release: - None. Current versions in supported releases that got updates: openldap | 2.5.12+dfsg-0ubuntu0.22.04.1 | jammy-updates | source Special cases: - None. Previous MREs for OpenLDAP: - https://pad.lv/1977627 As usual we test and prep from the PPA and then push through SRU/Security as applicable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1983618/+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 1986984] Re: [FFe] tzdata 2022c update
I verified the upload on Jammy, Focal and Bionic via fresh LXC
containers, using the attached script.
For the ESM releases, it has been handled by sbeattie from the Security
Team. As I understand, the packages are already available in the ESM
security PPA (I don't have access to it).
** Attachment added: "validate.sh"
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+attachment/5612734/+files/validate.sh
** Tags removed: verification-needed verification-needed-bionic
verification-needed-focal verification-needed-jammy
** Tags added: verification-done verification-done-bionic
verification-done-focal verification-done-jammy
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1986984
Title:
[FFe] tzdata 2022c update
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Confirmed
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Jammy:
Fix Committed
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022a.
[Test Case for releases <= 20.04 LTS]
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. Subsequently, these should be checked for using the following:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
[Original report]
tzdata 2022b and 2022c were just released that includes some timezone changes
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a
change to the start of their daylight savings and pushed it from Sept 4th to
the 11th, so we really need our servers updated before the 4th.
Thanks
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
I just created a new worker nodepool this morning, en redschedulded all pods to the new workers. Solved it for us. -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1988300] Re: systemd-resolved is not installable in Docker images
** Changed in: systemd (Ubuntu) Status: In Progress => Fix Committed -- 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/1988300 Title: systemd-resolved is not installable in Docker images Status in Ubuntu Docker Images: Invalid Status in dpkg package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Committed Bug description: Since 30 August (going by my daily CI builds, I do see the changelog entry for resolved is a few days older), I get this: Selecting previously unselected package systemd-resolved. Preparing to unpack .../321-systemd-resolved_251.4-1ubuntu1_amd64.deb ... Unpacking systemd-resolved (251.4-1ubuntu1) ... dpkg: error processing archive /tmp/apt-dpkg-install-NS2Yvi/321-systemd-resolved_251.4-1ubuntu1_amd64.deb (--unpack): unable to make backup link of './etc/resolv.conf' before installing new version: Invalid cross-device link The reason this fails is that Docker mounts resolv.conf, readonly, from the host system, so dpkg is not allowed to move/replace it. (To be clear, I do not need systemd-resolved in my container. "apt install devscripts" pulled it in, and debtree does not tell me why. "apt install --no-install-recommends devscripts" does not pull it in, and I'll likely adjust my builds [for PowerDNS] to do that because it's a good idea anyway). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-docker-images/+bug/1988300/+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 1969856] Re: bash --version does not correspond to package name
bash upstream encodes the patchlevel into the version number, while patches and security fixes in Ubuntu are applied on top of the upstream version. That's expected behavior. ** Changed in: bash (Ubuntu) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1969856 Title: bash --version does not correspond to package name Status in bash package in Ubuntu: Won't Fix Bug description: While investigating a potentially compromised system, I ran `bash --version` and got the following: `GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)` Disquieting, given that I had just installed a package named `bash_4.4.18-2ubuntu1.3_amd64.deb`. I downloaded the `.deb` archive and, upon extracting it, checked its hash (SHA256) against the instance on my path. They were the same (`15d4469eb3da716fefcc0c395a5b1d1657ad0555ec3ae623e727bb0dfcee19cf`)--indicating, presumably, that I was running whatever version was in the `.deb` I'd just downloaded. Why is the version reported by the binary different from the version used to denote the package? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1969856/+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 1987356] Re: [BPO] elfutils/0.187-1 from Kinetic
** Also affects: elfutils (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: elfutils (Ubuntu Jammy) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to elfutils in Ubuntu. https://bugs.launchpad.net/bugs/1987356 Title: [BPO] elfutils/0.187-1 from Kinetic Status in elfutils package in Ubuntu: Fix Released Status in elfutils source package in Jammy: Fix Released Bug description: [Impact] * elfutils ships many ELF/DWARF related tools that are interesting for users and developers of low level code. * More specifically, elfutils ships the debuginfod library and server. Ubuntu is going to have a debuginfod server soon (see https://blog.sergiodj.net/2022/08/14/debuginfod-is-coming-to- ubuntu.html), and there have been many important changes that impact debuginfod's performance on 0.187. [Scope] * I will backport elfutils/0.187 from Kinetic. * I will backport elfutils/0.187 to Jammy. [Other Info] * None so far. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/1987356/+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 1987356] Re: [BPO] elfutils/0.187-1 from Kinetic
** Changed in: elfutils (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to elfutils in Ubuntu. https://bugs.launchpad.net/bugs/1987356 Title: [BPO] elfutils/0.187-1 from Kinetic Status in elfutils package in Ubuntu: Fix Released Status in elfutils source package in Jammy: Fix Released Bug description: [Impact] * elfutils ships many ELF/DWARF related tools that are interesting for users and developers of low level code. * More specifically, elfutils ships the debuginfod library and server. Ubuntu is going to have a debuginfod server soon (see https://blog.sergiodj.net/2022/08/14/debuginfod-is-coming-to- ubuntu.html), and there have been many important changes that impact debuginfod's performance on 0.187. [Scope] * I will backport elfutils/0.187 from Kinetic. * I will backport elfutils/0.187 to Jammy. [Other Info] * None so far. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/1987356/+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 1912256] Re: Missing channel binding prevents authentication to ActiveDirectory
** Changed in: cyrus-sasl2 (Ubuntu Jammy) Assignee: Andreas Hasenack (ahasenack) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1912256 Title: Missing channel binding prevents authentication to ActiveDirectory Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in openldap package in Ubuntu: Fix Released Status in cyrus-sasl2 source package in Jammy: Triaged Status in openldap source package in Jammy: Fix Released Bug description: > Are you uncertain if your issue is really a bug? Effect is an authentication error. Root case is a "missing feature" (see below) and requires updating dependencies, downporting. > If you are certain this is a bug please include the source package the bug is in. It's in the interaction between three libraries: openldap, cyrus-sasl, krb5 > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu Broken in 18.04 and also in 20.10 (I guess it's also broken in anything inbetween) > 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1 ldap-utils: 2.4.53+dfsg-1ubuntu1.2 libgssapi-krb5-2: 1.17-10ubuntu0.1 > 3) What you expected to happen # kinit $ export LDAPSASL_CBINDING=tls-endpoint $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps:// SASL/GSSAPI authentication started SASL username: SASL SSF: 0 u: > 4) What happened instead SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C090597, comment: AcceptSecurityContext error, data 80090346, v4563 --- Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends activating this as a required feature. See https://access.redhat.com/articles/4661861 Authentication to any AD DC which has mandatory channel binding fails. Channel binding requires at least an update to cyrus-sasl, which is not in any release as far as I can see: https://github.com/cyrusimap/cyrus- sasl/commit/975edbb69070eba6b035f08776de771a129cfb57 It also needs this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6 Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5). RH also mentions it needs up-to-date krb5 libraries, but I can't tell what minimum version this needs. I can build all libraries from source, current master (except for krb5 where I've used 1.18.3) and can confirm that channel binding works when using those libraries. I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I would guess by extension also SSSD and realmd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1912256/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
I confirm that Mark Gerrits' approach worked also for my AKS instance. Tahnk you very much. -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1986984] Re: [FFe] tzdata 2022c update
https://wiki.ubuntu.com/StableReleaseUpdates#tzdata says "Uploads should
also be made to any releases supported via ESM". I see a bug task but
nothing in the queue. What are your plans on this, please?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1986984
Title:
[FFe] tzdata 2022c update
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Confirmed
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Jammy:
Fix Committed
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022a.
[Test Case for releases <= 20.04 LTS]
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. Subsequently, these should be checked for using the following:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
[Original report]
tzdata 2022b and 2022c were just released that includes some timezone changes
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a
change to the start of their daylight savings and pushed it from Sept 4th to
the 11th, so we really need our servers updated before the 4th.
Thanks
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1986984] Re: [FFe] tzdata 2022c update
Hello Jason, or anyone else affected,
Accepted tzdata into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/tzdata/2022c-0ubuntu0.22.04.0 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: tzdata (Ubuntu Jammy)
Status: Confirmed => Fix Committed
** Tags added: verification-needed verification-needed-jammy
** Changed in: tzdata (Ubuntu Focal)
Status: Confirmed => Fix Committed
** Tags added: verification-needed-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1986984
Title:
[FFe] tzdata 2022c update
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Confirmed
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Jammy:
Fix Committed
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022a.
[Test Case for releases <= 20.04 LTS]
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. Subsequently, these should be checked for using the following:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
[Original report]
tzdata 2022b and 2022c were just released that includes some timezone changes
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a
change to the start of their daylight savings and pushed it from Sept 4th to
the 11th, so we really need our servers updated before the 4th.
Thanks
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1986984] Please test proposed package
Hello Jason, or anyone else affected,
Accepted tzdata into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/tzdata/2022c-0ubuntu0.18.04.0 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1986984
Title:
[FFe] tzdata 2022c update
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Confirmed
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Jammy:
Fix Committed
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022a.
[Test Case for releases <= 20.04 LTS]
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. Subsequently, these should be checked for using the following:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
[Original report]
tzdata 2022b and 2022c were just released that includes some timezone changes
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a
change to the start of their daylight savings and pushed it from Sept 4th to
the 11th, so we really need our servers updated before the 4th.
Thanks
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1986984] Please test proposed package
Hello Jason, or anyone else affected,
Accepted tzdata into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/tzdata/2022c-0ubuntu0.20.04.0 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: tzdata (Ubuntu Bionic)
Status: Confirmed => Fix Committed
** Tags added: verification-needed-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1986984
Title:
[FFe] tzdata 2022c update
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Confirmed
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Jammy:
Fix Committed
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022a.
[Test Case for releases <= 20.04 LTS]
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. Subsequently, these should be checked for using the following:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
[Original report]
tzdata 2022b and 2022c were just released that includes some timezone changes
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a
change to the start of their daylight savings and pushed it from Sept 4th to
the 11th, so we really need our servers updated before the 4th.
Thanks
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1988300] Re: systemd-resolved is not installable in Docker images
** Merge proposal linked: https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/429166 -- 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/1988300 Title: systemd-resolved is not installable in Docker images Status in Ubuntu Docker Images: Invalid Status in dpkg package in Ubuntu: Invalid Status in systemd package in Ubuntu: In Progress Bug description: Since 30 August (going by my daily CI builds, I do see the changelog entry for resolved is a few days older), I get this: Selecting previously unselected package systemd-resolved. Preparing to unpack .../321-systemd-resolved_251.4-1ubuntu1_amd64.deb ... Unpacking systemd-resolved (251.4-1ubuntu1) ... dpkg: error processing archive /tmp/apt-dpkg-install-NS2Yvi/321-systemd-resolved_251.4-1ubuntu1_amd64.deb (--unpack): unable to make backup link of './etc/resolv.conf' before installing new version: Invalid cross-device link The reason this fails is that Docker mounts resolv.conf, readonly, from the host system, so dpkg is not allowed to move/replace it. (To be clear, I do not need systemd-resolved in my container. "apt install devscripts" pulled it in, and debtree does not tell me why. "apt install --no-install-recommends devscripts" does not pull it in, and I'll likely adjust my builds [for PowerDNS] to do that because it's a good idea anyway). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-docker-images/+bug/1988300/+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 1988300] Re: systemd-resolved is not installable in Docker images
The bug is in the systemd packaging, and we have cherry-picked a fix [1] from Debian that will be included in the next kinetic upload. [1] https://salsa.debian.org/systemd- team/systemd/-/commit/5d8a69933df0e9ce9e02ff07baed916ddc5af35e ** Changed in: dpkg (Ubuntu) Status: New => Invalid ** Changed in: ubuntu-docker-images Status: New => Invalid ** Changed in: systemd (Ubuntu) Status: New => Fix Committed ** Changed in: systemd (Ubuntu) Status: Fix Committed => In Progress ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Nick Rosbrook (enr0n) -- 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/1988300 Title: systemd-resolved is not installable in Docker images Status in Ubuntu Docker Images: Invalid Status in dpkg package in Ubuntu: Invalid Status in systemd package in Ubuntu: In Progress Bug description: Since 30 August (going by my daily CI builds, I do see the changelog entry for resolved is a few days older), I get this: Selecting previously unselected package systemd-resolved. Preparing to unpack .../321-systemd-resolved_251.4-1ubuntu1_amd64.deb ... Unpacking systemd-resolved (251.4-1ubuntu1) ... dpkg: error processing archive /tmp/apt-dpkg-install-NS2Yvi/321-systemd-resolved_251.4-1ubuntu1_amd64.deb (--unpack): unable to make backup link of './etc/resolv.conf' before installing new version: Invalid cross-device link The reason this fails is that Docker mounts resolv.conf, readonly, from the host system, so dpkg is not allowed to move/replace it. (To be clear, I do not need systemd-resolved in my container. "apt install devscripts" pulled it in, and debtree does not tell me why. "apt install --no-install-recommends devscripts" does not pull it in, and I'll likely adjust my builds [for PowerDNS] to do that because it's a good idea anyway). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-docker-images/+bug/1988300/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
** Changed in: systemd (Ubuntu Bionic) Status: In Progress => Fix Released -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1982739] Re: BlueZ 5.65 release
Will this also be released for jammy soon? I'm running into this issue which should be fixed with 5.65: https://github.com/bluez/bluez/issues/313 ** Bug watch added: github.com/bluez/bluez/issues #313 https://github.com/bluez/bluez/issues/313 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1982739 Title: BlueZ 5.65 release Status in bluez package in Ubuntu: Fix Released Bug description: Release BlueZ 5.65 to kinetic: https://mirrors.edge.kernel.org/pub/linux/bluetooth/bluez-5.65.tar.xz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1982739/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
Can confirm we get rid off this issue on our Azure AKS setup; by updating our NodePool's OS Image to AKSUbuntu-1804gen2containerd-2022.08.10 (using k8s version 1.22.11) -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1988300] Re: systemd-resolved in kinetic image tries to replace resolv.conf
Thanks for filing this bug, Peter. The issue here is not related to /etc/resolv.conf being read-only (it is actually a RW file) [1]. The issue lies in the fact that it is always mounted in a running container by docker itself [2]. During a package installation process, dpkg performs backups of existing files through hard links. Hard links cannot be performed across mounts, hence, dpkg fails to install systemd-resolved when it tried to backup /etc/resolv.conf $ apt-file search /etc/resolv.conf ... systemd-resolved: /etc/resolv.conf Now, while I am unsure where this bug belongs, this should be a good place to start a discussion. For further context, this is the bug where systemd-resolved split and /etc/resolv.conf ownership were discussed [3]. [1] https://github.com/moby/moby/pull/5129/files [2] https://docs.docker.com/storage/#good-use-cases-for-bind-mounts [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939904 ** Bug watch added: Debian Bug tracker #939904 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939904 ** Also affects: dpkg (Ubuntu) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Summary changed: - systemd-resolved in kinetic image tries to replace resolv.conf + systemd-resolved is not installable in Docker images -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1988300 Title: systemd-resolved is not installable in Docker images Status in Ubuntu Docker Images: New Status in dpkg package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: Since 30 August (going by my daily CI builds, I do see the changelog entry for resolved is a few days older), I get this: Selecting previously unselected package systemd-resolved. Preparing to unpack .../321-systemd-resolved_251.4-1ubuntu1_amd64.deb ... Unpacking systemd-resolved (251.4-1ubuntu1) ... dpkg: error processing archive /tmp/apt-dpkg-install-NS2Yvi/321-systemd-resolved_251.4-1ubuntu1_amd64.deb (--unpack): unable to make backup link of './etc/resolv.conf' before installing new version: Invalid cross-device link The reason this fails is that Docker mounts resolv.conf, readonly, from the host system, so dpkg is not allowed to move/replace it. (To be clear, I do not need systemd-resolved in my container. "apt install devscripts" pulled it in, and debtree does not tell me why. "apt install --no-install-recommends devscripts" does not pull it in, and I'll likely adjust my builds [for PowerDNS] to do that because it's a good idea anyway). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-docker-images/+bug/1988300/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
@mruffell, spinning up a clean Azure 18.04 Bionic VM and following your steps + reproducer, I can confirm DNS and network connectivity work fine: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.04.6 LTS Release:18.04 Codename: bionic $ sudo apt-cache policy systemd | grep Installed Installed: 237-3ubuntu10.55 $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com PING google.com (216.58.214.14) 56(84) bytes of data. 64 bytes from lhr26s05-in-f14.1e100.net (216.58.214.14): icmp_seq=1 ttl=112 time=2.46 ms 64 bytes from lhr26s05-in-f14.1e100.net (216.58.214.14): icmp_seq=2 ttl=112 time=2.87 ms 64 bytes from lhr26s05-in-f14.1e100.net (216.58.214.14): icmp_seq=3 ttl=112 time=2.30 ms -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
I confirm that Sebastiens approach worked also for my AKS instance. Thank you and to everyone involved, I owe you a pint :) https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/comments/19 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1961108] Re: network options greyed out in paprefs
Bug still exists in Kubuntu 22.04.1 and Pulseaudio 15.99
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1961108
Title:
network options greyed out in paprefs
Status in pulseaudio package in Ubuntu:
New
Bug description:
I installed Kubuntu 21.10 which comes with pulseaudio
1:15.0+dfsg1-1ubuntu2.2. When I start paprefs all network options are
greyed out. The problem seems to be, that the directory with the
modules is called /usr/lib/pulse-15.0+dfsg1, but paprefs expects the
modules in /usr/lib/pulse-15.0
$ strace paprefs 2>&1 |grep /lib/pulse
access("/usr/lib/pulse-15.0/modules/module-esound-protocol-tcp.so", F_OK) =
-1 ENOENT (No such file or directory)
access("/usr/lib/pulse-15.0/modules/module-native-protocol-tcp.so", F_OK) =
-1 ENOENT (No such file or directory)
access("/usr/lib/pulse-15.0/modules/module-zeroconf-publish.so", F_OK) = -1
ENOENT (No such file or directory)
access("/usr/lib/pulse-15.0/modules/module-zeroconf-discover.so", F_OK) = -1
ENOENT (No such file or directory)
access("/usr/lib/pulse-15.0/modules/module-raop-discover.so", F_OK) = -1
ENOENT (No such file or directory)
access("/usr/lib/pulse-15.0/modules/module-rtp-recv.so", F_OK) = -1 ENOENT
(No such file or directory)
access("/usr/lib/pulse-15.0/modules/module-rtp-send.so", F_OK) = -1 ENOENT
(No such file or directory)
access("/usr/lib/pulse-15.0/modules/module-rygel-media-server.so", F_OK) = -1
ENOENT (No such file or directory)
Creating a symlink /usr/lib/pulse-15.0 solves the problem
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1961108/+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 1981807] Re: qt5-network openssl3 armhf does not support tls1.3
Oops, forgot about that. Done.
Also, ABI is not affected. We have symbols to track ABI, and there are
no symbols changes for libqt5network5.
** Description changed:
+ [Impact]
+
+ Qt 5 Network library does not use TLS 1.3 on armhf, and falls back to
+ less secure protocols.
+
+ [Test Plan]
+
+ 1. Create test.cpp with the following contents:
+
+ #include
+ #include
+ #include
+ #include
+
+ int main(int argc, char **argv) {
+ QCoreApplication app(argc, argv);
+ QSslSocket s;
+ QSslConfiguration cfg = s.sslConfiguration();
+ cfg.setProtocol(QSsl::TlsV1_3OrLater);
+ s.setSslConfiguration(cfg);
+ s.connectToHostEncrypted("www.ubuntu.com", 443);
+ s.waitForConnected();
+ qDebug() << s.sessionProtocol();
+ return 0;
+ }
+
+ 2. Create test.pro with the following contents:
+
+ CONFIG += debug warn_all
+ QT = core network
+ SOURCES = test.cpp
+
+ 3. Install qtbase5-dev package.
+
+ 4. Compile using `qmake && make`.
+
+ 5. Run the generated ./test executable. It should print 15, not -1.
+
+ [Where problems could occur]
+
+ It is unlikely to cause issues on 64-bit platforms because long and
+ uint64_t are both 64 bits long. On armhf potential problems may be
+ related to availability of other protocols.
+
+ [Original Description]
+
lsb_release
Description:Ubuntu 22.04 LTS
Release:22.04
libqt5network5/jammy,now 5.15.3+dfsg-2 armhf
libssl3/jammy-updates,jammy-security,now 3.0.2-0ubuntu1.6 armhf
the qt5 armhf version shipped with ubuntu jammy has a regression in
tls1.3 support (simply missing in runtime).
openssl supports tls1.3, so the underlying library works.
x86_64 is obviously not affected
the short sample applications writes -1 on armhf, 15 on x86_64 (unknown
protocol vs tls1.3)
QSslSocket* s = new QSslSocket();
QSslConfiguration cfg = s->sslConfiguration();
cfg.setProtocol(QSsl::TlsV1_3OrLater);
s->setSslConfiguration(cfg);
s->connectToHostEncrypted("tls13-enabled.server",443);
s->waitForConnected();
printf("%d\n",s->sessionProtocol());
marking it as security since the most secure tls protocol is not used on
some platforms
** Changed in: qtbase-opensource-src (Ubuntu Jammy)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtbase-opensource-src in
Ubuntu.
https://bugs.launchpad.net/bugs/1981807
Title:
qt5-network openssl3 armhf does not support tls1.3
Status in qtbase-opensource-src package in Ubuntu:
Fix Released
Status in qtbase-opensource-src source package in Jammy:
Confirmed
Bug description:
[Impact]
Qt 5 Network library does not use TLS 1.3 on armhf, and falls back to
less secure protocols.
[Test Plan]
1. Create test.cpp with the following contents:
#include
#include
#include
#include
int main(int argc, char **argv) {
QCoreApplication app(argc, argv);
QSslSocket s;
QSslConfiguration cfg = s.sslConfiguration();
cfg.setProtocol(QSsl::TlsV1_3OrLater);
s.setSslConfiguration(cfg);
s.connectToHostEncrypted("www.ubuntu.com", 443);
s.waitForConnected();
qDebug() << s.sessionProtocol();
return 0;
}
2. Create test.pro with the following contents:
CONFIG += debug warn_all
QT = core network
SOURCES = test.cpp
3. Install qtbase5-dev package.
4. Compile using `qmake && make`.
5. Run the generated ./test executable. It should print 15, not -1.
[Where problems could occur]
It is unlikely to cause issues on 64-bit platforms because long and
uint64_t are both 64 bits long. On armhf potential problems may be
related to availability of other protocols.
[Original Description]
lsb_release
Description:Ubuntu 22.04 LTS
Release:22.04
libqt5network5/jammy,now 5.15.3+dfsg-2 armhf
libssl3/jammy-updates,jammy-security,now 3.0.2-0ubuntu1.6 armhf
the qt5 armhf version shipped with ubuntu jammy has a regression in
tls1.3 support (simply missing in runtime).
openssl supports tls1.3, so the underlying library works.
x86_64 is obviously not affected
the short sample applications writes -1 on armhf, 15 on x86_64 (unknown
protocol vs tls1.3)
QSslSocket* s = new QSslSocket();
QSslConfiguration cfg = s->sslConfiguration();
cfg.setProtocol(QSsl::TlsV1_3OrLater);
s->setSslConfiguration(cfg);
s->connectToHostEncrypted("tls13-enabled.server",443);
s->waitForConnected();
printf("%d\n",s->sessionProtocol());
marking it as security since the most secure tls protocol is not used
on some platforms
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1981807/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to :
[Touch-packages] [Bug 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
Hi Matthew, on our production Ubuntu VM in Azure we have problem to ping google.com The version of prod Ubuntu is: DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.5 LTS" NAME="Ubuntu" VERSION="18.04.5 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.5 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic I have installed new test Ubuntu VM now: DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.6 LTS" NAME="Ubuntu" VERSION="18.04.6 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.6 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic ping google.com was working fine. Then I have applied your steps above and ping google.com is still working fine. Milan -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from
[Touch-packages] [Bug 1988290] [NEW] NO_PROXY doesn't work for IPv6 literals
Public bug reported: [Partial copypaste from the linked upstream bug.] Setting NO_PROXY=localhost,127.0.0.1,::1 enables connections to http://localhost and http://127.0.0.1 and does not work for http://[::1] at all. Apparently the problem is caused by an assumption [1] that a hostname cannot contain a colon. [1] https://github.com/curl/curl/blob/7e35eb77292fe6464889ddc8329c6a64136f969d/lib/url.c#L2577 ** Affects: curl Importance: Unknown Status: Unknown ** Affects: curl (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: curl (Ubuntu Bionic) Importance: Undecided Status: Triaged ** Also affects: curl (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: curl (Ubuntu Bionic) Status: New => Triaged ** Changed in: curl (Ubuntu) Status: New => Fix Released ** Bug watch added: github.com/curl/curl/issues #2353 https://github.com/curl/curl/issues/2353 ** Also affects: curl via https://github.com/curl/curl/issues/2353 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1988290 Title: NO_PROXY doesn't work for IPv6 literals Status in Curl: Unknown Status in curl package in Ubuntu: Fix Released Status in curl source package in Bionic: Triaged Bug description: [Partial copypaste from the linked upstream bug.] Setting NO_PROXY=localhost,127.0.0.1,::1 enables connections to http://localhost and http://127.0.0.1 and does not work for http://[::1] at all. Apparently the problem is caused by an assumption [1] that a hostname cannot contain a colon. [1] https://github.com/curl/curl/blob/7e35eb77292fe6464889ddc8329c6a64136f969d/lib/url.c#L2577 To manage notifications about this bug go to: https://bugs.launchpad.net/curl/+bug/1988290/+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 1988290] Re: NO_PROXY doesn't work for IPv6 literals
Fixed upstream and in >= Focal by: https://github.com/curl/curl/commit/b7f90470be9b75f57167abbcd63aadb2e3b33958 ** Description changed: + [Partial copypaste from the linked upstream bug.] + Setting - NO_PROXY=localhost,127.0.0.1,::1 + NO_PROXY=localhost,127.0.0.1,::1 enables connections to http://localhost and http://127.0.0.1 and does not work for http://[::1] at all. Apparently the problem is caused by an assumption [1] that a hostname cannot contain a colon. [1] https://github.com/curl/curl/blob/7e35eb77292fe6464889ddc8329c6a64136f969d/lib/url.c#L2577 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1988290 Title: NO_PROXY doesn't work for IPv6 literals Status in Curl: Unknown Status in curl package in Ubuntu: Fix Released Status in curl source package in Bionic: Triaged Bug description: [Partial copypaste from the linked upstream bug.] Setting NO_PROXY=localhost,127.0.0.1,::1 enables connections to http://localhost and http://127.0.0.1 and does not work for http://[::1] at all. Apparently the problem is caused by an assumption [1] that a hostname cannot contain a colon. [1] https://github.com/curl/curl/blob/7e35eb77292fe6464889ddc8329c6a64136f969d/lib/url.c#L2577 To manage notifications about this bug go to: https://bugs.launchpad.net/curl/+bug/1988290/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1965439] Re: [SRU] kdesu fails to authenticate with sudo from Jammy
On 31/08/2022 10:38, mtu wrote: > Note that with kdesu fixed, the hotfix to kubuntu-settings by Erich > Eickmeyer can possibly be reverted, removing the ugly xterm workaround > when launching Driver Manager from Kubuntu Settings. Yes, if this update gets accepted into the main archive for jammy, that will be the next thing to do. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1965439 Title: [SRU] kdesu fails to authenticate with sudo from Jammy Status in kdesu package in Ubuntu: Fix Released Status in kubuntu-settings package in Ubuntu: Fix Released Status in sudo package in Ubuntu: Confirmed Status in ubuntustudio-default-settings package in Ubuntu: Fix Released Status in kdesu source package in Jammy: Fix Committed Status in kubuntu-settings source package in Jammy: In Progress Status in sudo source package in Jammy: Won't Fix Status in ubuntustudio-default-settings source package in Jammy: In Progress Status in kdesu source package in Kinetic: Fix Released Status in kubuntu-settings source package in Kinetic: Fix Released Status in sudo source package in Kinetic: Won't Fix Status in ubuntustudio-default-settings source package in Kinetic: Fix Released Status in kdesu package in Debian: Fix Released Bug description: kdesu fails to authenticate with sudo from Jammy. See upstream bug: KDE bug: https://bugs.kde.org/show_bug.cgi?id=452532 Examples: Launch Kubuntu driver manager from system setting, launching ksystemlog from the main menu, or trying to run krusader root mode option via its 'Tools > Start Krusader Root Mode' menu entry. Assuming that the current user is a member of the sudo group. On entering the correct password authentication is refused, stating that possibly an incorrect password has been entered. It appears that kdesu fails to cope with the sudo config change in this commit: https://salsa.debian.org/sudo- team/sudo/-/commit/59db341d46aa4c26b54c1270e69f2562e7f3d751 kdesu was fixed in Debian with: https://tracker.debian.org/news/1330116/accepted-kdesu-5940-2-source- into-unstable/ and fixed in kinetic with: https://launchpad.net/ubuntu/+source/kdesu/5.94.0-0ubuntu2 The issue can be worked around by adding /etc/sudoers.d/kdesu-sudoers with the contents Defaults!/usr/lib/*/libexec/kf5/kdesu_stub !use_pty [Impact] * Users are unable to authenticate to and launch applications via kdesu. * This should be backported to restore functionality that users expect. [Test Plan] * Launch Kubuntu driver manager from system setting, launching ksystemlog from the main menu, or trying to run krusader root mode option via its 'Tools > Start Krusader Root Mode' menu entry. Assuming that the current user is a member of the sudo group. * Confirm that the application authentcate and launch as successfully as in previous releases. [Where problems could occur] * While this update only returns sudo to its default behaviour (used in previous releases and virtually all other distributions) for kdesu, care should be taken to test some other applications that seek root permissions to confirm that no unexpected consequences occur. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdesu/+bug/1965439/+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 1986984] Re: [FFe] tzdata 2022c update
Apologies for the metadata bug traffic, I hadn't realized there were
duplicates, and actually use different bug numbers in the SRU and devel
uploads. Marking this manually as released on Kinetic, as the SRU
uploads use this bug number.
** Changed in: tzdata (Ubuntu Kinetic)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1986984
Title:
[FFe] tzdata 2022c update
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Confirmed
Status in tzdata source package in Bionic:
Confirmed
Status in tzdata source package in Focal:
Confirmed
Status in tzdata source package in Jammy:
Confirmed
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022a.
[Test Case for releases <= 20.04 LTS]
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. Subsequently, these should be checked for using the following:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
[Original report]
tzdata 2022b and 2022c were just released that includes some timezone changes
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a
change to the start of their daylight savings and pushed it from Sept 4th to
the 11th, so we really need our servers updated before the 4th.
Thanks
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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 1987642] Re: Chile is delaying the DST by one week for 2022
*** This bug is a duplicate of bug 1986984 ***
https://bugs.launchpad.net/bugs/1986984
** This bug has been marked a duplicate of bug 2022
iso-codes is not available for breezy
** This bug is no longer a duplicate of bug 2022
iso-codes is not available for breezy
** Description changed:
- Chile is delaying the start of Daylight Saving Time (DST) by one week
- this year [1],[2].
+ New timezone data, with the following timezones impacted:
+ - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
+ - Iran no longer observes DST (Asia/Tehran)
+
+ Verification is done with 'zdump'. The first timezone that gets changed
+ in the updated package is dumped with 'zdump -v
+ $region/$timezone_that_changed' (this needs to be greped for in
+ /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
+ compared to the same output after the updated package got installed. If
+ those are different the verification is considered done.
+
+ [Test Case for all releases]
+ 1) zdump -v America/Santiago | grep 'Sep.*2022'
+ -> should indicate Sep 11, not Sep 4
+ 2) zdump -v Asia/Tehran | tail
+ -> last dates should be in 2022, not in 2499
+
+ [Test Case for releases >= 20.04 LTS]
+
+ For releases with ICU timezone data verification is done using the following
with dates before and after the change:
+ 1) sudo apt-get install python3-icu
+ 2) Run the following python script:
+
+ from datetime import datetime
+ from icu import ICUtzinfo, TimeZone
+ tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
+ always_before = datetime(2022, 9, 1)
+ now_before = datetime(2022, 9, 8)
+ always_after = datetime(2022, 9, 12)
+ assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
+ assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
+
+ The assertions would crash on 2022a.
+
+ [Test Case for releases <= 20.04 LTS]
+
+ Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and
earlier releases. Subsequently, these should be checked for using the following:
+ diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
+
+ Nothing should be returned by the above command.
+
+ [Original report]
+ Chile is delaying the start of Daylight Saving Time (DST) by one week this
year [1],[2].
DST timezone in Chile will start on midnight of September 11th; and will
end on April 1st, 2023.
Debian's 2022c-1 and 2022b-1 versions of tzdata contain the fix for
this.
Upstream commit :
https://github.com/eggert/tz/commit/711b46f8fc4e8a3d5caf7d4820562d6cdfe9d769
We need to fix this in all or releases back to Xenial.
-
[1]
https://www.interior.gob.cl/noticias/2022/08/09/comunicado-el-proximo-sabado-10-de-septiembre-los-relojes-se-deben-adelantar-una-hora/
[2]
https://www.timeanddate.com/news/time/chile-dst-delay-2022.html#:~:text=Chile%20is%20delaying%20the%20start,financial%20district%20in%20Chile%27s%20capital.
** This bug has been marked a duplicate of bug 1986984
[FFe] tzdata 2022c update
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1987642
Title:
Chile is delaying the DST by one week for 2022
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Confirmed
Status in tzdata source package in Bionic:
Confirmed
Status in tzdata source package in Focal:
Confirmed
Status in tzdata source package in Jammy:
Confirmed
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
[Touch-packages] [Bug 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
Hello everyone, I know there are quite a few people watching this bug, so I will provide a status update. The test package has been looking good throughout our internal testing, and we have proceeded to build the next systemd update, version 237-3ubuntu10.55, and it is currently in the bionic-security -proposed ppa. If you would like to help test, that would be greatly appreciated. Please use a fresh VM on Azure, and please don't put the package into production just yet. Instructions to install (On a Bionic system): 1) sudo add-apt-repository ppa:ubuntu-security-proposed/ppa 2) sudo apt update 3) sudo apt install libnss-systemd libpam-systemd libsystemd0 libudev1 systemd systemd-sysv udev 4) sudo apt-cache policy systemd | grep Installed Installed: 237-3ubuntu10.55 5) sudo rm /etc/apt/sources.list.d/ubuntu-security-proposed-ubuntu-ppa-bionic.list 6) sudo apt update >From there you can run the reproducer: $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com PING google.com (172.253.122.138) 56(84) bytes of data. 64 bytes from bh-in-f138.1e100.net (172.253.122.138): icmp_seq=1 ttl=103 time=1.67 ms if you do test, comment here on how it went. Again, please don't put the package into production until it has had a little more testing, and we will get this released to the world as quickly and safely as we can. Thanks, Matthew -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action()
[Touch-packages] [Bug 1965439] Re: [SRU] kdesu fails to authenticate with sudo from Jammy
Note that with kdesu fixed, the hotfix to kubuntu-settings by Erich Eickmeyer can possibly be reverted, removing the ugly xterm workaround when launching Driver Manager from Kubuntu Settings. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1965439 Title: [SRU] kdesu fails to authenticate with sudo from Jammy Status in kdesu package in Ubuntu: Fix Released Status in kubuntu-settings package in Ubuntu: Fix Released Status in sudo package in Ubuntu: Confirmed Status in ubuntustudio-default-settings package in Ubuntu: Fix Released Status in kdesu source package in Jammy: Fix Committed Status in kubuntu-settings source package in Jammy: In Progress Status in sudo source package in Jammy: Won't Fix Status in ubuntustudio-default-settings source package in Jammy: In Progress Status in kdesu source package in Kinetic: Fix Released Status in kubuntu-settings source package in Kinetic: Fix Released Status in sudo source package in Kinetic: Won't Fix Status in ubuntustudio-default-settings source package in Kinetic: Fix Released Status in kdesu package in Debian: Fix Released Bug description: kdesu fails to authenticate with sudo from Jammy. See upstream bug: KDE bug: https://bugs.kde.org/show_bug.cgi?id=452532 Examples: Launch Kubuntu driver manager from system setting, launching ksystemlog from the main menu, or trying to run krusader root mode option via its 'Tools > Start Krusader Root Mode' menu entry. Assuming that the current user is a member of the sudo group. On entering the correct password authentication is refused, stating that possibly an incorrect password has been entered. It appears that kdesu fails to cope with the sudo config change in this commit: https://salsa.debian.org/sudo- team/sudo/-/commit/59db341d46aa4c26b54c1270e69f2562e7f3d751 kdesu was fixed in Debian with: https://tracker.debian.org/news/1330116/accepted-kdesu-5940-2-source- into-unstable/ and fixed in kinetic with: https://launchpad.net/ubuntu/+source/kdesu/5.94.0-0ubuntu2 The issue can be worked around by adding /etc/sudoers.d/kdesu-sudoers with the contents Defaults!/usr/lib/*/libexec/kf5/kdesu_stub !use_pty [Impact] * Users are unable to authenticate to and launch applications via kdesu. * This should be backported to restore functionality that users expect. [Test Plan] * Launch Kubuntu driver manager from system setting, launching ksystemlog from the main menu, or trying to run krusader root mode option via its 'Tools > Start Krusader Root Mode' menu entry. Assuming that the current user is a member of the sudo group. * Confirm that the application authentcate and launch as successfully as in previous releases. [Where problems could occur] * While this update only returns sudo to its default behaviour (used in previous releases and virtually all other distributions) for kdesu, care should be taken to test some other applications that seek root permissions to confirm that no unexpected consequences occur. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdesu/+bug/1965439/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
Sebastien Tardif (sebastientardifverituity) the fix you mentioned works for me, 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 591823] Re: "File descriptor \d+ (\S+) leaked on lvs invocation."
Shouldn't the bug be assigned to grub(/usr/sbin/grub-probe) instead of lvm2 as the comment here explains ? https://unix.stackexchange.com/questions/433313/strange-problem-lvs- invocation-with-grub-on-debian-stretch#comment1232731_433407 The fact that lvm did extra work towards security and detected something shouldn't mean that we should now blame them and supress the warning instead fixing real issue -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/591823 Title: "File descriptor \d+ (\S+) leaked on lvs invocation." Status in aptitude: Fix Released Status in lvm2: Fix Released Status in lvm2 package in Ubuntu: Opinion Bug description: If you see messages like these: File descriptor 40 (/var/lib/dpkg/status) leaked on lvs invocation. Parent PID 1854: /bin/sh File descriptor 41 (/var/lib/dpkg/status) leaked on lvs invocation. Parent PID 1854: /bin/sh File descriptor 42 (/var/lib/dpkg/status) leaked on lvs invocation. Parent PID 1854: /bin/sh File descriptor 43 (/var/lib/dpkg/status) leaked on lvs invocation. Parent PID 1854: /bin/sh You can set LVM_SUPPRESS_FD_WARNINGS to suppress these warnings. Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581339 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432986 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138 This is a slightly controversial bug and it's not yet fixed either way (aka fix not to leak file descriptors or stop warning by default) To manage notifications about this bug go to: https://bugs.launchpad.net/aptitude/+bug/591823/+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 1965439] Re: [SRU] kdesu fails to authenticate with sudo from Jammy
On Jammy, I have installed the following packages from jammy-proposed: - libkf5su-data (5.92.0-0ubuntu1.1) - libkf5su5:amd64 (5.92.0-0ubuntu1.1) - libkf5su-bin (5.92.0-0ubuntu1.1) I have performed the following tests, in accordance with the bug description: - launching KSystemLog from the K Menu - launching Software Sources from Settings in Discover - launching Software Sources from Settings in Muon All tests were successful, so I can confirm that the bug is fixed in Jammy. ** Tags removed: verification-needed-jammy ** Tags added: verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1965439 Title: [SRU] kdesu fails to authenticate with sudo from Jammy Status in kdesu package in Ubuntu: Fix Released Status in kubuntu-settings package in Ubuntu: Fix Released Status in sudo package in Ubuntu: Confirmed Status in ubuntustudio-default-settings package in Ubuntu: Fix Released Status in kdesu source package in Jammy: Fix Committed Status in kubuntu-settings source package in Jammy: In Progress Status in sudo source package in Jammy: Won't Fix Status in ubuntustudio-default-settings source package in Jammy: In Progress Status in kdesu source package in Kinetic: Fix Released Status in kubuntu-settings source package in Kinetic: Fix Released Status in sudo source package in Kinetic: Won't Fix Status in ubuntustudio-default-settings source package in Kinetic: Fix Released Status in kdesu package in Debian: Fix Released Bug description: kdesu fails to authenticate with sudo from Jammy. See upstream bug: KDE bug: https://bugs.kde.org/show_bug.cgi?id=452532 Examples: Launch Kubuntu driver manager from system setting, launching ksystemlog from the main menu, or trying to run krusader root mode option via its 'Tools > Start Krusader Root Mode' menu entry. Assuming that the current user is a member of the sudo group. On entering the correct password authentication is refused, stating that possibly an incorrect password has been entered. It appears that kdesu fails to cope with the sudo config change in this commit: https://salsa.debian.org/sudo- team/sudo/-/commit/59db341d46aa4c26b54c1270e69f2562e7f3d751 kdesu was fixed in Debian with: https://tracker.debian.org/news/1330116/accepted-kdesu-5940-2-source- into-unstable/ and fixed in kinetic with: https://launchpad.net/ubuntu/+source/kdesu/5.94.0-0ubuntu2 The issue can be worked around by adding /etc/sudoers.d/kdesu-sudoers with the contents Defaults!/usr/lib/*/libexec/kf5/kdesu_stub !use_pty [Impact] * Users are unable to authenticate to and launch applications via kdesu. * This should be backported to restore functionality that users expect. [Test Plan] * Launch Kubuntu driver manager from system setting, launching ksystemlog from the main menu, or trying to run krusader root mode option via its 'Tools > Start Krusader Root Mode' menu entry. Assuming that the current user is a member of the sudo group. * Confirm that the application authentcate and launch as successfully as in previous releases. [Where problems could occur] * While this update only returns sudo to its default behaviour (used in previous releases and virtually all other distributions) for kdesu, care should be taken to test some other applications that seek root permissions to confirm that no unexpected consequences occur. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdesu/+bug/1965439/+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 1959211] Re: Please merge dbus 1.14.0-2 from Debian unstable.
This bug was fixed in the package dbus - 1.14.0-2ubuntu2
---
dbus (1.14.0-2ubuntu2) kinetic; urgency=medium
* d/control: Add M-A: foreign to the new dbus-{session,system}-bus-common
packages to permit the resolver to use them to satisfy i386 dependencies
-- Dave Jones Tue, 30 Aug 2022 15:15:24
+0100
** Changed in: dbus (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 dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1959211
Title:
Please merge dbus 1.14.0-2 from Debian unstable.
Status in dbus package in Ubuntu:
Fix Released
Bug description:
Please merge dbus 1.14.0-2 from Debian unstable.
Updated changelog and diff against Debian unstable to be attached
below.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1959211/+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 1981807] Re: qt5-network openssl3 armhf does not support tls1.3
The patch looks reasonable (assuming that it doesn't change ABI, which
seems to be the case). Could you be able to update the bug with the
necessary SRU information (the
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template can help
here)?
Particularly, the [Test Plan] and [Where problems might occur] parts are
important. You've got most of a test-plan there already (but we should
have some tests of existing packages to check we don't have a regression
and make sure ABI hasn't been broken). I can help there, but you
probably have better insight into this code and where it might go wrong
than me :). If you'd like help, give me a ping (RAOF in #ubuntu-
release:libera.chat).
** Changed in: qtbase-opensource-src (Ubuntu Jammy)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtbase-opensource-src in
Ubuntu.
https://bugs.launchpad.net/bugs/1981807
Title:
qt5-network openssl3 armhf does not support tls1.3
Status in qtbase-opensource-src package in Ubuntu:
Fix Released
Status in qtbase-opensource-src source package in Jammy:
Incomplete
Bug description:
lsb_release
Description:Ubuntu 22.04 LTS
Release:22.04
libqt5network5/jammy,now 5.15.3+dfsg-2 armhf
libssl3/jammy-updates,jammy-security,now 3.0.2-0ubuntu1.6 armhf
the qt5 armhf version shipped with ubuntu jammy has a regression in
tls1.3 support (simply missing in runtime).
openssl supports tls1.3, so the underlying library works.
x86_64 is obviously not affected
the short sample applications writes -1 on armhf, 15 on x86_64 (unknown
protocol vs tls1.3)
QSslSocket* s = new QSslSocket();
QSslConfiguration cfg = s->sslConfiguration();
cfg.setProtocol(QSsl::TlsV1_3OrLater);
s->setSslConfiguration(cfg);
s->connectToHostEncrypted("tls13-enabled.server",443);
s->waitForConnected();
printf("%d\n",s->sessionProtocol());
marking it as security since the most secure tls protocol is not used
on some platforms
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1981807/+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 1988078] Re: Please backport systemd-hwdb patches to support src:systemd-hwe tests
** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- 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/1988078 Title: Please backport systemd-hwdb patches to support src:systemd-hwe tests Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: New Bug description: [Impact] We plan to SRU src:systemd-hwe to Jammy[1] to provide an easier way to SRU HWE hwdb rules to Ubuntu. The src:systemd-hwe package contains a test script[2] to ensure that no redundant hwdb rules are added to the package, i.e. rules that are already present in src:systemd. This test requires patches to implement --root flag support for the `systemd- hwdb query` command[3]. These patches are already present in kinetic. Without these patches in Jammy, src:systemd-hwe would have to disable these tests, which are important to maintaining HWE hwdb rules in Ubuntu. [1] https://bugs.launchpad.net/ubuntu/+source/systemd-hwe/+bug/1983996 [2] https://git.launchpad.net/~canonical-foundations/+git/systemd-hwe/tree/tests/hwdb-redundancy?h=main [3] https://github.com/systemd/systemd/pull/23518 [Test plan] * Create a new directory for testing hwdb rule queries: $ mkdir -p fakeroot/etc/udev/hdwb.d * Add a new .hwdb file to override an existing rule. For example, I chose to override the last entry from /lib/udev/hdwb.d/60-keyboard.hwdb: $ tail -2 /lib/udev/hwdb.d/60-keyboard.hwdb > fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb $ sed -i 's/chromebook/reserved/g' fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb $ cat fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:* XKB_FIXED_MODEL=reserved * Create the hwdb.bin within fakeroot: $ systemd-hwdb update --root fakeroot $ ls fakeroot/etc/udev/hwdb.bin fakeroot/etc/udev/hwdb.bin * Finally, attempt to query this new hwdb.bin using systemd-hwdb query. On an unpatched system, we will see results from the system's hwdb.bin: $ systemd-hwdb query --root fakeroot evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:* | grep XKB_FIXED_MODEL XKB_FIXED_MODEL=chromebook ...and on a patched system we should see the overridden rule: $ systemd-hwdb query --root fakeroot evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:* | grep XKB_FIXED_MODEL XKB_FIXED_MODEL=reserved [Where problems could occur] The patches add support for the --root flag when calling systemd-hwdb query, thus changing the behavior of this command (previously, query would always load the system's hwdb.bin). It is unlikely that existing scripts try to use the --root flag with `systemd-hwdb query`, but if they did, this is where we would see problems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988078/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
@mruffel thank you for the debdiff! With my limited systemd codebase knowledge, this change feels fine. But I agree with the regression potential section of the SRU description - we should make sure that the update is well tested before going out as potentially it can change behavior. -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
@sebastientardifverituity the Microsoft support fix you mentioned worked for me. -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure
Is there an workaround for Azure Container Apps at this point? -- 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/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer resolve DNS queries, breaking networking. For affected users, the following workarounds are available. Use whatever is most convenient. - Reboot your instances - or - - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root The trigger was found to be open-vm-tools issuing "udevadm trigger". Azure has a specific netplan setup that uses the `driver` match to set up networking. If a udevadm trigger is executed, the KV pair that contains this info is lost. Next time netplan is executed, the server loses it's DNS information. This is the same as bug 1902960 experienced on Focal two years ago. The root cause was found to be a bug in systemd, where if we receive a "Remove" action from a change uevent, we need to run net_setup_link(), we need to skip device rename and keep the old name. [Testcase] Start an instance up on Azure, any type. Simply issue udevadm trigger and reload systemd-networkd: $ ping google.com PING google.com (172.253.62.102) 56(84) bytes of data. 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms $ sudo udevadm trigger && sudo systemctl restart systemd-networkd $ ping google.com ping: google.com: Temporary failure in name resolution To fix a broken instance, you can run: $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- networkd and then install the test packages below: Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test If you install them, the issue should no longer occur. [Where problems could occur] If a regression were to occur, it would affect systemd-udevd processing 'change' events from network devices, which could lead to network outages. Since this would happen when systemd-networkd is restarted on postinstall, a regression would cause widespread outages due to this SRU being targeted to the security pocket, where unattended-upgrades will automatically install from. Side effects could include incorrect udevd device properties. It is very important that this SRU is well tested before release. [Other info] This was fixed in Systemd 247 with the following commit: commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 Author: Yu Watanabe Date: Mon, 14 Sep 2020 15:21:04 +0900 Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 two years ago. Focal required a heavy backport, which was performed by Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below pastebin: https://paste.ubuntu.com/p/K5k7bGt3Wx/ The changes between the Focal backport and the Bionic backport are: - We use udev_device_get_action() instead of device_get_action() - device_action_from_string() is used to get to enum DeviceAction - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" - log_device_* has been changed to log_*. See attached debdiff for Bionic backport. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1988119] Re: Update to systemd 237-3ubuntu10.54 broke dns
Attached is a debdiff for systemd on Bionic which fixes this bug. ** Description changed: - Two servers today that updated systemd to "systemd 237-3ubuntu10.54" - https://ubuntu.com/security/notices/USN-5583-1 + [Impact] - could not resolve dns anymore. - no dns servers, normally set through dhcp. + A widespread outage was caused on Azure instances earlier today, when + systemd 237-3ubuntu10.54 was published to the bionic-security pocket. + Instances could no longer resolve DNS queries, breaking networking. - Ubuntu 18.04 + For affected users, the following workarounds are available. Use whatever is most convenient. + - Reboot your instances + - or - + - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" as root - Temp fix. - 1. Edit /etc/systemd/resolved.conf - 1. Add/Uncomment # FallbackDNS=168.63.129.16 - 1. Restart systemd-resolved sudo systemctl restart systemd-resolved.service - 1. Confirm dns working with systemd-resolve google.com + The trigger was found to be open-vm-tools issuing "udevadm trigger". + Azure has a specific netplan setup that uses the `driver` match to set + up networking. If a udevadm trigger is executed, the KV pair that + contains this info is lost. Next time netplan is executed, the server + loses it's DNS information. + + This is the same as bug 1902960 experienced on Focal two years ago. + + The root cause was found to be a bug in systemd, where if we receive a + "Remove" action from a change uevent, we need to run net_setup_link(), + we need to skip device rename and keep the old name. + + [Testcase] + + Start an instance up on Azure, any type. Simply issue udevadm trigger + and reload systemd-networkd: + + $ ping google.com + PING google.com (172.253.62.102) 56(84) bytes of data. + 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 time=1.85 ms + $ sudo udevadm trigger && sudo systemctl restart systemd-networkd + $ ping google.com + ping: google.com: Temporary failure in name resolution + + To fix a broken instance, you can run: + + $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd- + networkd + + and then install the test packages below: + + Test packages are available in the following ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test + + If you install them, the issue should no longer occur. + + [Where problems could occur] + + If a regression were to occur, it would affect systemd-udevd processing + 'change' events from network devices, which could lead to network + outages. Since this would happen when systemd-networkd is restarted on + postinstall, a regression would cause widespread outages due to this SRU + being targeted to the security pocket, where unattended-upgrades will + automatically install from. + + Side effects could include incorrect udevd device properties. + + It is very important that this SRU is well tested before release. + + [Other info] + + This was fixed in Systemd 247 with the following commit: + + commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 + Author: Yu Watanabe + Date: Mon, 14 Sep 2020 15:21:04 +0900 + Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= properties on non-'add' uevent + Link: https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151 + + This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960 + two years ago. Focal required a heavy backport, which was performed by + Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re- + assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below + pastebin: + + https://paste.ubuntu.com/p/K5k7bGt3Wx/ + + The changes between the Focal backport and the Bionic backport are: + + - We use udev_device_get_action() instead of device_get_action() + - device_action_from_string() is used to get to enum DeviceAction + - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto no_rename" + - log_device_* has been changed to log_*. + + See attached debdiff for Bionic backport. ** Summary changed: - Update to systemd 237-3ubuntu10.54 broke dns + systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure ** Patch added: "Debdiff for systemd on Bionic" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+attachment/5612617/+files/lp1988119_bionic.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1988119 Title: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [Impact] A widespread outage was caused on Azure instances earlier today, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket. Instances could no longer
