"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!"
This expiration never happened, and no additional comments indicate that
cloud-init has a problem, so I'm goi
The Groovy Gorilla has reached end of life, so this bug will not be
fixed for that release
** Changed in: cloud-init (Ubuntu Groovy)
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to syste
This bug was fixed in the package systemd - 245.4-4ubuntu3.4
---
systemd (245.4-4ubuntu3.4) focal; urgency=medium
* d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch,
d/p/lp1905245/0002-basic-capability-util-let-cap_last_cap-return-unsign.patch,
d/p
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://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/com
focal:
root@lp1902960-f:~# dpkg -l systemd|grep systemd
ii systemd245.4-4ubuntu3.3 amd64system and service manager
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net
root@lp1902960-f:~# rm /run/udev/data/n2
root@lp1902960-f:~# ud
groovy:
root@lp1902960-g:~# dpkg -l systemd|grep systemd
ii systemd246.6-1ubuntu1 amd64system and service manager
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net
root@lp1902960-g:~# rm /run/udev/data/n2
root@lp1902960-g:~# udev
I confirm I got it working at first boot on azure with
systemd-245.4-4ubuntu3.4
```
ubuntu@machine-3:~$ sudo networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 etherroutableconfigured
2 links listed.
ubuntu@machine-3:~$ sudo apt update
Hi
Hello David, or anyone else affected,
Accepted systemd into groovy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/246.6-1ubuntu1.1 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://
Hello David, or anyone else affected,
Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.4 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://w
** Description changed:
[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 failur
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 F
** Changed in: systemd
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1902960
Title:
Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appear
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.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https:
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 changed:
+ [impact]
+
+ on boot of a specific azure instance, the ID_NET_DRIVER parameter of the
+ instance's et
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
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?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, whi
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cloud-init (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpa
I've just tested, and this doesn't seem to reproduce when launching from
a captured image (with 90-hotplug-azure.yaml restored and `cloud-init
clean` executed). So I think I've exhausted the ways in which I can
attempt to gain more insight into what's happening during the part of
boot where this r
(Added cloud-images for visibility.)
** Also affects: cloud-images
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1902960
Title:
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/90-hotplug-azure.yaml`:
# This netplan yaml is delivered in Azure cloud images to support
# attaching and de
Thanks for the explanation.
I confirm that the workaround using "sytemctl restart systemd-udev-
trigger && systemctl restart systemd-networkd" does the trick.
@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 happ
> 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-udev-trigger service) just runs
through all devices in the system and asks them to (re)issue 'add'
uevents. if a device doesn't
** Changed in: cloud-init (Ubuntu)
Status: New => Incomplete
** Changed in: systemd (Ubuntu)
Status: Invalid => New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/b
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
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
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
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cloud-init (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpa
> systemd-udev-trigger service didn't correctly run at the proper time
to generate uevents for existing devices
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
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
i
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
Here is a pastebin of the situation and how I tried to resolve this :
https://pastebin.ubuntu.com/p/c6cfKqvBmN/
Unfortunately, the interface stays "unmanaged".
When I check the netplan source
(https://github.com/CanonicalLtd/netplan/blob/master/netplan/cli/commands/apply.py#L128),
it just stops s
Attached /var/log/syslog.
** Attachment added: "syslog"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1902960/+attachment/5431334/+files/syslog
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
h
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
--
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.n
Spun up a new unit in Azure and also ran into this:
| https://paste.ubuntu.com/p/zd6z8dZ5Zr/
--
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/1902960
Title:
Upgrade from 24
apport information
** Tags added: apport-collected focal uec-images
** Description changed:
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 as
35 matches
Mail list logo
