Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| cloud-images |
Undecided
|
Unassigned | ||
| systemd |
New
|
Unknown
|
||
| cloud-init (Ubuntu) |
Undecided
|
Unassigned | ||
| Focal |
Undecided
|
Unassigned | ||
| Groovy |
Undecided
|
Unassigned | ||
| systemd (Ubuntu) |
Undecided
|
Unassigned | ||
| Focal |
Medium
|
Dan Streetman | ||
| Groovy |
Medium
|
Dan Streetman |
Bug Description
[impact]
on boot of a specific azure instance, the ID_NET_DRIVER parameter of the instance's eth0 interface is not set. That leads to a failure of systemd-networkd to take control of the interface after a restart of systemd-networkd, which results in DNS failures (at first) and eventually complete loss of networking (once the DHCP lease expires).
[test case]
this occurs on first boot of an instance using the specific image; it is not reproducable using the latest ubuntu image nor any reboot of the affected image, and it has not been reproducable (for me) when using debug-enabled images based on the affected image.
So, while the problem is reproducable using the specific image in question, it's not possible to verify the fix since any change to the image removes reproducability.
however, while the problem itself can't be reproduced and then verified, if the assumption is correct (that the 'add' uevent is being missed on boot), that is possible to test and verify:
$ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
E: ID_NET_
$ sudo rm /run/udev/data/n2
(note, change 'n2' to whichever network interface index is correct)
$ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
$ sudo udevadm trigger -c change /sys/class/net/eth0
$ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
(note the 'change' uevent did not populate ID_NET_DRIVER property)
$ sudo udevadm trigger -c add /sys/class/net/eth0
$ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
E: ID_NET_
(note the 'add' uevent did populate ID_NET_DRIVER)
the test verification should result in ID_NET_DRIVER being populated for a 'change' uevent.
[regression potential]
any regression would likely involve problems with systemd-udevd processing 'change' events from network devices, and/or incorrect udevd device properties.
[scope]
this is needed only for focal and groovy.
this is fixed by upstream commit e0e789c1e97 which is first included in v247, so this is fixed already in hirsute.
while this commit is not included in bionic, due to the difficult nature of reproducing (and verifying) this, and the fact it has only been seen once on a focal image, I don't think it's appropriate to SRU to bionic at this point; possibly it may be appropriate if this is ever reproduced with a bionic image.
[other info]
note that this bug's subject and description, as well as the upstream systemd bug subject and description, talk about the problem being DNS resolution. However that is strictly a side-effect of the real problem and is not the actual issue.
[original description]
The systemd upgrade 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to have broken DNS resolution across much of our Azure fleet earlier today. We ended up mitigating this by forcing reboots on the associated instances, no combination of networkctl reload, reconfigure, systemctl daemon-reexec, systemctl daemon-reload, netplan generate, netplan apply would get resolvectl to have a DNS server again. The main symptom appears to have been systemd-networkd believing it wasn't managing the eth0 interfaces:
ubuntu@machine-1:~$ sudo networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable unmanaged
Which eventually made them lose their DNS resolvers:
ubuntu@machine-1:~$ sudo resolvectl dns
Global:
Link 2 (eth0):
After rebooting, we see this behaving properly:
ubuntu@machine-1:~$ sudo networkctl list
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
2 links listed.
ubuntu@machine-1:~$ sudo resolvectl dns
Global:
Link 2 (eth0): 168.63.129.16
This appears to be specifically linked to the upgrade, i.e. we were able to provoke the issue by upgrading the systemd package, so I suspect it's part of the packaging in the upgrade process.
---
ProblemType: Bug
ApportVersion: 2.20.11-
Architecture: amd64
CasperMD5CheckR
DistroRelease: Ubuntu 20.04
Lspci-vt:
-[0000:00]-+-00.0 Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled)
+-07.0 Intel Corporation 82371AB/EB/MB PIIX4 ISA
+-07.1 Intel Corporation 82371AB/EB/MB PIIX4 IDE
+-07.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI
\-08.0 Microsoft Corporation Hyper-V virtual VGA
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
MachineType: Microsoft Corporation Virtual Machine
Package: systemd 245.4-4ubuntu3.3
PackageArchitec
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=
ProcVersionSign
Tags: focal uec-images
Uname: Linux 5.4.0-1031-azure x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: N/A
_MarkForUpload: True
dmi.bios.date: 12/07/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 090008
dmi.board.name: Virtual Machine
dmi.board.vendor: Microsoft Corporation
dmi.board.version: 7.0
dmi.chassis.
dmi.chassis.type: 3
dmi.chassis.vendor: Microsoft Corporation
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: Virtual Machine
dmi.product.uuid: 4412ad79-
dmi.product.
dmi.sys.vendor: Microsoft Corporation
David Lawson (deej) wrote : CurrentDmesg.txt | #1 |
tags: | added: apport-collected focal uec-images |
description: | updated |
David Lawson (deej) wrote : Dependencies.txt | #2 |
apport information
David Lawson (deej) wrote : Lspci.txt | #3 |
apport information
David Lawson (deej) wrote : ProcCpuinfo.txt | #4 |
apport information
apport information
David Lawson (deej) wrote : ProcInterrupts.txt | #6 |
apport information
David Lawson (deej) wrote : ProcModules.txt | #7 |
apport information
David Lawson (deej) wrote : SystemdDelta.txt | #8 |
apport information
David Lawson (deej) wrote : UdevDb.txt | #9 |
apport information
Launchpad Janitor (janitor) wrote : | #11 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in systemd (Ubuntu): | |
status: | New → Confirmed |
Haw Loeung (hloeung) wrote : | #12 |
Spun up a new unit in Azure and also ran into this:
Haw Loeung (hloeung) wrote : | #13 |
Attached /var/log/syslog.
Benjamin Allot (ballot) wrote : | #14 |
Here is a pastebin of the situation and how I tried to resolve this : https:/
Unfortunately, the interface stays "unmanaged".
When I check the netplan source (https:/
Dan Streetman (ddstreet) wrote : | #15 |
This isn't a problem with 3.2 to 3.3 upgrade, this is a problem where on first boot of the azure instance any restart of networkd fails to associate the .network file with the interface, e.g.:
root@lp1902960-3:~# networkctl status eth0
● 2: eth0
Link File: n/a
Network File: /run/systemd/
HW Address: 00:0d:3a:4e:ec:8c (Microsoft Corp.)
Queue Length (Tx/Rx): 64/64
Auto negotiation: no
Search Domains: wh32vgcjtxsend1
root@lp1902960-3:~# systemctl restart systemd-networkd
root@lp1902960-3:~# networkctl status eth0
● 2: eth0
Link File: n/a
Network File: n/a
HW Address: 00:0d:3a:4e:ec:8c (Microsoft Corp.)
Queue Length (Tx/Rx): 64/64
Auto negotiation: no
This is because udev doesn't know about the eth0 'Driver', because the systemd-
Simply re-running systemd-
Dan Streetman (ddstreet) wrote : | #16 |
This problem is somehow created only on the first boot, most likely by some magic being performed by cloud-init. If the created instance is rebooted, there is no problem and systemd-networkd can be restarted with no problems.
Marking this as invalid for system as this isn't a systemd issue, this is a cloud problem, probably with cloud-init, or maybe with the cloud image.
Changed in systemd (Ubuntu): | |
status: | Confirmed → Invalid |
Dan Streetman (ddstreet) wrote : | #17 |
> systemd-
note: as systemd-networkd did correctly associate the .network file at first, my guess would be during boot the .network file was different than it is when boot is finished, which is why a restart causes networkd to remove the match. Only a guess, however - i haven't looked any deeper at what magic is being done by cloud-init.
Launchpad Janitor (janitor) wrote : | #18 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in cloud-init (Ubuntu): | |
status: | New → Confirmed |
Dan Watkins (oddbloke) wrote : | #19 |
Hey folks,
Thanks for the report! If someone could run `cloud-init collect-logs` on an affected instance, and upload the produced tarball to this bug, we can dig into it further. The contents of /etc/netplan would also be very handy.
(Once attached, please move this back to New.)
Cheers,
Dan
Changed in cloud-init (Ubuntu): | |
status: | Confirmed → Incomplete |
David Lawson (deej) wrote : | #20 |
Sure, not a problem. Here's the contents of /etc/netplan/*
ubuntu@machine-2:~$ cat /etc/netplan/*
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
network:
ethernets:
eth0:
dhcp4: true
dhcp6: false
match:
version: 2
Changed in cloud-init (Ubuntu): | |
status: | Incomplete → New |
Dan Watkins (oddbloke) wrote : | #21 |
OK, I've managed to reproduce this (in a non-Juju launched VM). The ordering of these journal lines look suspicious to me:
Nov 09 17:41:51.091033 ubuntu systemd[1]: Starting udev Coldplug all Devices...
Nov 09 17:41:51.236309 ubuntu systemd[1]: Finished Load Kernel Modules.
Nov 09 17:41:51.363482 ubuntu systemd[1]: Finished udev Coldplug all Devices.
Because, you guessed it, hv_netvsc is shipped as a kernel module:
$ lsmod | grep hv_netvsc
hv_netvsc 81920 0
So my assumption is that udev coldplugging of the network device is happening before the driver is loaded, and so (unsurprisingly :) it doesn't find the driver.
I suspect that adding an `After=
Given the above (and the fact that cloud-init doesn't run for another ~5s after these lines), I _think_ this is a systemd/kernel interface issue, not a cloud-init issue.
Changed in cloud-init (Ubuntu): | |
status: | New → Incomplete |
Changed in systemd (Ubuntu): | |
status: | Invalid → New |
Dan Streetman (ddstreet) wrote : | #22 |
> coldplugging of the network device is happening before the driver is loaded,
> and so (unsurprisingly :) it doesn't find the driver.
so, 'coldplugging' (meaning systemd-
additionally, hotplugging the driver later would generate its own uevents, thus notifying udevd about it. That's the whole point of systemd-
additionally it doesn't explain how systemd-networkd *did* match the .network file, even though it doesn't know anything about the interface Driver.
> I suspect that adding an `After=
> systemd-
that shouldn't be needed since systemd-
I certainly may be wrong about cloud-init, however; that was just my guess on what code might be doing non-standard first-boot magic.
I'm fairly certain it isn't anything in systemd misbehaving, however.
Benjamin Allot (ballot) wrote : | #23 |
Thanks for the explanation.
I confirm that the workaround using "sytemctl restart systemd-
@Dan Watkins : did you do some specific thing to reproduce the issue on your local VM ? It would be interesting to see the whole logs happening there.
We could possibly hijack the image to add a
| udevadm control --log-priority=
and see what happens.
Dan Watkins (oddbloke) wrote : | #24 |
Thanks for the explanation, Dan! I was off down a wrong path, I appreciate the correction.
I've just downloaded the Azure image from cloud-images.u.c and it includes this in `/etc/netplan/
# This netplan yaml is delivered in Azure cloud images to support
# attaching and detaching nics after the instance first boot.
# Cloud-init otherwise handles initial boot network configuration in
# /etc/netplan/
network:
version: 2
ethernets:
ephemeral:
dhcp4: true
match:
dhcp4: true
match:
This file is not present in a booted system, because cloud-init removes it during boot:
2020-11-09 18:12:09,306 - handlers.py[DEBUG]: start: azure-ds/
2020-11-09 18:12:09,307 - DataSourceAzure
2020-11-09 18:12:09,307 - util.py[DEBUG]: Attempting to remove /etc/netplan/
2020-11-09 18:12:09,307 - handlers.py[DEBUG]: finish: azure-ds/
It does this before the regular cloud-init network configuration is written, or `netplan generate` is called:
2020-11-09 18:12:09,465 - util.py[DEBUG]: Writing to /etc/netplan/
2020-11-09 18:12:09,466 - subp.py[DEBUG]: Running command ['netplan', 'generate'] with allowed return codes [0] (shell=False, capture=True)
cloud-init also runs a couple of udevadm commands right after `netplan generate`:
2020-11-09 18:12:09,813 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/
2020-11-09 18:12:09,828 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/
This all happens before systemd-networkd starts:
Nov 09 18:12:09.956027 focal-1604945439 systemd[1]: Starting Network Service...
So: I'm not really sure what's going on here. I've tried restoring `90-hotplug-
One thing worth noting, that could lead to unexpected state: cloud-init performs a DHCP on this interface (in order to be able to fetch the network configuration it is going to apply). It does this in a sandbox (i.e. it doesn't use system configuration for it), but potentially that could mean that there's (kernel?) state for that interface which {udev,network}d interpret in a way that leads to this issue?
Changed in cloud-init (Ubuntu): | |
status: | Incomplete → New |
Changed in systemd (Ubuntu): | |
status: | New → Incomplete |
Dan Watkins (oddbloke) wrote : | #25 |
(Added cloud-images for visibility.)
Dan Watkins (oddbloke) wrote : | #26 |
I've just tested, and this doesn't seem to reproduce when launching from a captured image (with 90-hotplug-
I think we're going to need an image published with some debugging built into it (which, hopefully, will continue to reproduce the issue). If https:/
I'm not sure if there's any more networking/
Launchpad Janitor (janitor) wrote : | #27 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in cloud-init (Ubuntu): | |
status: | New → Confirmed |
Dan Streetman (ddstreet) wrote : | #28 |
Unfortunately (or maybe fortunately?) I'm no longer able to reproduce this when deploying Ubuntu 20.04 instances in azure.
@deej are you able to reproduce this with newly deployed 20.04 instances?
Dan Streetman (ddstreet) wrote : | #29 |
As I mentioned in the upstream systemd bug, it's still not clear what exactly is causing this, and the inability to reproduce it after the image first boot, or with another image with debug added, or with the latest image, means it will be impossible to verify any fix to this problem.
However, my best guess is udevd is somehow missing the 'add' uevent for the network device, as I described in the upstream bug. While I don't know why it would miss the event, the upstream commit e0e789c1e97e2cd
So, based on those assumptions/guesses and on the relative safety of the upstream commit, I plan to SRU that commit for this bug.
Dan Streetman (ddstreet) wrote : | #30 |
based on comment 29, and the assumption that the referenced upstream commit does actually 'fix' (or at least work around) this, marking as Fix Released for h and later.
description: | updated |
Changed in systemd (Ubuntu): | |
status: | Incomplete → Opinion |
status: | Opinion → New |
status: | New → Fix Released |
Changed in systemd (Ubuntu Focal): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in systemd (Ubuntu Groovy): | |
importance: | Undecided → Medium |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in systemd (Ubuntu Focal): | |
status: | New → In Progress |
importance: | Undecided → Medium |
Changed in systemd (Ubuntu Groovy): | |
status: | New → In Progress |
David Lawson (deej) wrote : | #31 |
I don't actually know that we've deployed any new instances into Azure in the recent past so I'm not sure we can confirm but that all sounds reasonable.
Changed in systemd: | |
status: | Unknown → New |
Dan Watkins (oddbloke) wrote : | #32 |
It sounds to me like there's no cloud-init aspect here, so I'm going to move our tasks to Incomplete (so they'll expire out eventually). Please do set them back if I've missed something!
Changed in cloud-init (Ubuntu): | |
status: | Confirmed → Incomplete |
Changed in cloud-init (Ubuntu Focal): | |
status: | New → Incomplete |
Changed in cloud-init (Ubuntu Groovy): | |
status: | New → Incomplete |
Hello David, or anyone else affected,
Accepted systemd into focal-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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 systemd (Ubuntu Focal): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed verification-needed-focal |
description: | updated |
Chris Halse Rogers (raof) wrote : | #34 |
Hello David, or anyone else affected,
Accepted systemd into groovy-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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 systemd (Ubuntu Groovy): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed-groovy |
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (systemd/245.4-4ubuntu3.4) | #35 |
All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.4) for focal have finished running.
The following regressions have been reported in tests triggered by the package:
linux-hwe-
netplan.
apt/2.0.2ubuntu0.2 (armhf)
munin/2.
gvfs/1.
prometheus-
lxc/1:4.
indicator-
pyudev/
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (systemd/246.6-1ubuntu1.1) | #36 |
All autopkgtests for the newly accepted systemd (246.6-1ubuntu1.1) for groovy have finished running.
The following regressions have been reported in tests triggered by the package:
gvfs/1.
prometheus/
netplan.
flatpak/1.8.2-1 (arm64)
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
Benjamin Allot (ballot) wrote : | #37 |
I confirm I got it working at first boot on azure with systemd-
```
ubuntu@machine-3:~$ sudo networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
2 links listed.
ubuntu@machine-3:~$ sudo apt update
Hit:1 http://
Hit:2 http://
Get:3 http://
Get:4 http://
Get:5 http://
Get:6 http://
Fetched 591 kB in 3s (225 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
ubuntu@machine-3:~$ dpkg -l systemd
Desired=
| Status=
|/ Err?=(none)
||/ Name Version Architecture Description
+++-===
ii systemd 245.4-4ubuntu3.4 amd64 system and service manager
```
Dan Streetman (ddstreet) wrote : | #38 |
groovy:
root@lp1902960-g:~# dpkg -l systemd|grep systemd
ii systemd 246.6-1ubuntu1 amd64 system and service manager
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_
root@lp1902960-g:~# rm /run/udev/data/n2
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-g:~# udevadm trigger -c change /sys/class/net/ens3
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-g:~# udevadm trigger -c add /sys/class/net/ens3
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_
root@lp1902960-g:~# dpkg -l systemd|grep systemd
ii systemd 246.6-1ubuntu1.1 amd64 system and service manager
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_
root@lp1902960-g:~# rm /run/udev/data/n2
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-g:~# udevadm trigger -c change /sys/class/net/ens3
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_
Dan Streetman (ddstreet) wrote : | #39 |
focal:
root@lp1902960-f:~# dpkg -l systemd|grep systemd
ii systemd 245.4-4ubuntu3.3 amd64 system and service manager
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_
root@lp1902960-f:~# rm /run/udev/data/n2
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-f:~# udevadm trigger -c change /sys/class/net/ens3
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-f:~# udevadm trigger -c add /sys/class/net/ens3
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_
root@lp1902960-f:~# dpkg -l systemd|grep systemd
ii systemd 245.4-4ubuntu3.4 amd64 system and service manager
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_
root@lp1902960-f:~# rm /run/udev/data/n2
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-f:~# udevadm trigger -c change /sys/class/net/ens3
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_
tags: |
added: verification-done verification-done-focal verification-done-groovy removed: verification-needed verification-needed-focal verification-needed-groovy |
Launchpad Janitor (janitor) wrote : | #40 |
This bug was fixed in the package systemd - 246.6-1ubuntu1.1
---------------
systemd (246.6-1ubuntu1.1) groovy; urgency=medium
[ Dan Streetman ]
* d/t/boot-smoke: update test to avoid false negatives
(LP: #1892358)
https:/
* d/t/boot-
(LP: #1892358)
https:/
* d/t/systemd-fsckd: rewrite test to try to fix false negatives
(LP: #1892358)
https:/
* d/p/lp1905044-
test: use cap_last_cap() instead of capability_
(LP: #1905044)
https:/
* d/p/lp1907306/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
Send correct number of dhcpv4 renew and rebind requests
(LP: #1907306)
https:/
* d/p/lp1902960-
Run net_setup_link on 'change' uevents (LP: #1902960)
https:/
* d/t/root-unittests:
Remove any corrupt journal files (LP: #1881947)
https:/
[ Balint Reczey ]
* d/t/systemd-fsckd: Plymouth-start stays active in 20.10 and later
(LP: #1908067)
https:/
-- Dan Streetman <email address hidden> Wed, 06 Jan 2021 15:40:39 -0500
Changed in systemd (Ubuntu Groovy): | |
status: | Fix Committed → Fix Released |
The verification of the Stable Release Update for systemd 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.
Launchpad Janitor (janitor) wrote : | #42 |
This bug was fixed in the package systemd - 245.4-4ubuntu3.4
---------------
systemd (245.4-4ubuntu3.4) focal; urgency=medium
* d/p/lp1905245/
d/p/
d/p/
- print number of unknown capabilities instead of failing
(LP: #1905245)
https:/
* d/p/lp1890448-
Add EliteBook to use micmute hotkey (LP: #1890448)
https:/
* d/extra/
suppress output of cmp command in dhclient hook (LP: #1878955)
https:/
* d/p/lp1905044-
test: use cap_last_cap() instead of capability_
(LP: #1905044)
https:/
* d/p/lp1903300/
d/p/
d/p/
set vxlan multicast group when specified (LP: #1903300)
https:/
* d/p/lp1907306/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
d/p/
Send correct number of dhcpv4 renew and rebind requests
(LP: #1907306)
https:/
* d/p/lp1902960-
Run net_setup_link on 'change' uevents (LP: #1902960)
https:/
* d/t/root-unittests:
Remove any corrupt journal files (LP: #1881947)
https:/
-- Dan Streetman <email address hidden> Wed, 06 Jan 2021 15:47:39 -0500
Changed in systemd (Ubuntu Focal): | |
status: | Fix Committed → Fix Released |
apport information