** Summary changed:
- 24.04 TPM backed FDE regression following snapd 2.62 update
+ 24.04 TPM backed FDE regression following shim 15.8 update
** Description changed:
Azure testing has reported an issue following update of the nullboot
package from 0.5.0-0ubuntu3 to 0.5.1-0ubuntu1 which I
We reverted nullboot to 0.5.0-0ubuntu3 with shim 15.7 prior to the
release of Noble. We have identified and fixed the issue in encrypt-
cloud-image but we are still waiting on Microsoft to deploy the new
version of tool in their provisioning backend. Once this will be done we
will be able to
To help with the investigations: I was able to reproduce the issue by
simply installing dracut on a normal (non tpm-backed FDE) VM. Dracut
replaces initramfs-tools and build a systemd-base initramfs.
# start the lxd VM
$ lxc launch --vm ubuntu:24.04 noble-vm
# in the VM install dracut and reboot
Azure CVM images are impacted by the same issue. I see on #2064088 that
this is an tpm-backed FDE system. So I think it's the same problem here
if those desktop images use an systemd-based initramfs.
For now I suspect that the issue is due to systemd starting services and
setting up UNIX sockets
Probably more readable on pastebin:
https://pastebin.ubuntu.com/p/sv5W99tWKP/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1954678
Title:
Build for more platforms
To manage notifications about
Tested on Azure with an Arm64 instance:
ubuntu@bionic-arm:~$ sudo apt-get install walinuxagent
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
walinuxagent
1 upgraded, 0 newly installed, 0 to remove and 17 not
I started 156 instances for both:
* an impish image with systemd 248.3-1ubuntu8.5
* a focal image with systemd 245.4-4ubuntu3.16
In both images, I also removed the workaround in
/etc/systemd/system/dbus.service.d
(Environment=SYSTEMD_NSS_DYNAMIC_BYPASS=1) to make sure I was really
testing the
Can it be related to this reddit post:
https://www.reddit.com/r/Ubuntu/comments/tkvjwu/this_is_why_i_love_linux_how_a_kernel_upgrade/
?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1966066
Title:
This is now part of Azure's cloud images (focal to devel) and I can
confirm that it fixes the issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871538
Title:
dbus timeout-ed during an upgrade,
Hi there,
I used this[0] script to test the different series. The most relevant
parts of it are those parameters for qemu:
-smbios type=0,vendor='Hyper-V test',version=1.2.3 \
-smbios
Only arm64 is needed for now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1954678
Title:
Build for more platforms
To manage notifications about this bug go to:
Public bug reported:
[Impact]
* We previously restricted the build to amd64[0] because walinuxagent
had a dependency that was only available on amd64. This is not the case
any more, we should at least build walinuxagent for arm64.
[Test Plan]
* Make sure the package builds correctly and can
Public bug reported:
[Impact]
* The detection of Microsoft Hyper-V VMs is done by cpuid currently,
however there is no cpuid on ARM64. And since ARM64 is now a supported
architecture for Microsoft Hyper-V guests[0], then introduce a more
generic way to detect whether a guest is running as a
** Changed in: linux-azure (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1951924
Title:
linux-azure 4.15 fails to boot on Standard_M416s_v2 in Azure
To
Public bug reported:
To reproduce:
* start a bionic VM in azure:
az vm create --name bionic --resource-group test-bionic --image
"Canonical:UbuntuServer:18_04-lts-gen2:latest" --size Standard_M416s_v2
--admin-username ubuntu --ssh-key-value SSH_KEY_PATH
* "downgrade" the kernel to 4.15 and
** Tags added: rls-ii-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871538
Title:
dbus timeout-ed during an upgrade, taking services down including gdm
To manage notifications about this
I tried to reproduce the issue with the latest hirsute image pushed to
Azure and it appears that I cannot.
While I can still reproduce the issue with 20210511.1, I can't with
20210622.1.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
@rbalint @ddstreed any update on this issue?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1919177
Title:
Azure: issues with accelerated networking on Hirsute
To manage notifications about this
Ok I will cook an other custom image and try to reproduce.
Concerning this log line:
Jun 16 08:55:45 alan-hirsute-base-aiamcicscciaelhaktpo dbus-daemon[711]:
[system] Connection has not authenticated soon enough, closing it
(auth_timeout=3ms, elapsed: 45129ms)
Please note that during our
Also, systemd is actually reloaded by cloud-init. In cloud-init logs, I
can read:
2021-06-16 08:54:51,608 - subp.py[DEBUG]: Running command ['systemctl',
'daemon-reload'] with allowed return codes [0] (shell=False, capture=True)
2021-06-16 08:54:51,953 - cc_mounts.py[DEBUG]: Activate mounts:
@laney I built a custom image with system logs level set to debug and I
was able to reproduce the issue. You can find the logs attached.
** Attachment added: "syslog"
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1871538/+attachment/5505001/+files/syslog
--
You received this bug
I seems that we are seeing this issue on Azure with Ubuntu >=20.04. The
CPC team is running a series of tests before publishing images, those
tests spin up ~50 instances in Azure and usually one of them is having
this issue.
You can find the system logs of a failing instance here:
It's been there for almost 3 months, I think it can wait a few more
days. It's affecting Azure's users who use Hirsute instances with
accelerated networking enabled, I don't know how many users that is.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I built the following images using the version in -proposed and it
worked as expected.
Concerning the autopkgtest regression, I think it is unrelated with this
change. It seems to be related to openstack and nova setup.
Groovy
==
ubuntu@ubuntu:~$ lsb_release -c -r
Release:20.10
@rbalint, I just tested Impish and I cannot reproduce the issue. It
doesn't prove it's not there but it's a very good sign!
I can see that our automated testing failed because of this issue on the
2021-05-10 but not after. If I'm not wrong, systemd 248 was pushed on
the 14th, this would make a
@rbalint I was able to reproduce the issue with an image that was
running the following:
ii cloud-init20.4.1-79-g71564dce-0ubuntu1 all initialization
and customization tool for cloud instances
ii linux-image-azure 5.8.0.1017.19+21.04.14 amd64Linux kernel
image
Hi there,
Is there any update on this issue? I would like to understand who owns
the investigation/debugging process? Please tell us if you need any help
from the CPC team.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Indeed, this fixed the issue. I started a new bionic instance and ran
do-release-upgrade -p
The process went as expected.
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923111
Title:
I was actually able to reproduce today and I can confirm that the
instance creation didn't take more than a few seconds. This bug can be
closed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925526
Public bug reported:
On Azure instances running Xenial Pro FIPS images with accelerated
networking enabled, cloud-init fails to setup the user's ssh key and I
can see the following stack trace in the logs:
Traceback (most recent call last):
File
I was unable to reproduce this, and I think @oddbloke is right. Please
feel free to close this and I will post something new if I see the issue
happening again.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Also affects: cloud-images/xenial
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923865
Title:
Bootable buildd xenial images go to initramfs on boot
** Changed in: cloud-images
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923865
Title:
Bootable buildd xenial images go to initramfs on boot
To manage
Finally, I forgot bionic:
AWS bionic arm64:
ubuntu@ip-172-31-6-24:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.5 LTS
Release:18.04
Codename: bionic
ubuntu@ip-172-31-6-24:~$ uname -a
Linux ip-172-31-6-24 5.4.0-1045-aws
** Tags removed: verification-needed-focal verification-needed-groovy
verification-needed-xenial
** Tags added: verification-done-focal verification-done-groovy
verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Hi,
I built livecd-rootfs packages with this change and built cloud images
from them. I focused my testing on cloud supporting UEFI. All VMs are
amd64 except for AWS.
KVM (Groovy):
ubuntu@ubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.10
Hi,
I am not using Pro offers here.
@oddbloke, that's very interesting, thanks for the explanation. You
might be right here, I'm not sure I actually have to wait 3m30 to create
the instance. I will try to reproduce the issue while carefully
monitoring the delay to be sure.
--
You received this
Public bug reported:
Sometimes, cloud-init-local takes a few min to start on Azure instances.
Eg:
$ systemd-analyze blame
3min 33.770s cloud-init-local.service
5.441s snapd.seeded.service
5.146s cloud-init.service
After quickly checking cloud-init logs, I see the following time
I attach here the full diff of packages between the two serials.
** Attachment added: "Package diff between 20210219 and 20210220 20.04 Azure
images"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1919177/+attachment/5491010/+files/package-diff.txt
--
You received this bug
I isolated the issue between those two serial: 20210219 (doesn't have
the issue) and 20210220 (reproduces the issue).
The main difference I can see between those two serial is systemd
version:
20210219 -> 247.1-4ubuntu1
20210220 -> 247.3-1ubuntu2
Cloud-init version is the same
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1919177
Title:
Azure: issues with accelerated networking on Hirsute
To
Hi,
Checking the cmdline, the root filesystem is not set:
/boot/vmlinuz-4.4.0-21-generic root= ro quiet splash $vt_handoff
If I change it to "root=PARTUUID=fb561bdb-b68a-44ae-a884-a5fd70f80cf7"
it's booting.
I see also two other errors during boot:
[0.075065] core perfctr but no
** Description changed:
[General]
On Azure, when provisioning a Hirsute VM with Accelerated Networking
- enabled, sometimes the SSH key is not setup properly and the user cannot
- log into the VM.
+ enabled, sometimes part of the cloud-init configuration is not applied.
+
+ Especially, in
The issue probably* started between these two serials: 20210215 and
20210304.
*I say "probably" because while I'm sure I can reproduce the issue with
20210304, the fact I didn't manage to reproduce it with 20210215 (in ~15
tries) doesn't **absolutely prove** that the issue wasn't there.
--
You
Hi,
Ok thanks. I am now trying to find at which time the issue was first
introduced. So far I tested an image from 20201222 and confirm that I
cannot reproduce the issue with this image.
Then by modifying the image (always before first boot) I was able to find that:
- upgrading cloud-init from
I don't have any particular knowledge of how systemd waits for the
network to be ready but reading systemd-networkd-wait-online.service(8)
and networkctl(1) I wonder if cloud-init shouldn't wait for networkd-
wait-online to report that the link is "routable" instead of
"degradated" (default
Hi there,
For whether or not the issue affects Groovy. I've been creating Groovy
VMs on a loop to confirm if I could reproduce it there and (after ~50
tries) I still haven't seen it happen. I think we can safely assume that
this issue does not affect Groovy.
Also I was able to reproduce the
Hi Wayne,
Thank you for reporting the issue.
I am able to reproduce it using this URN
'Canonical:UbuntuServer:18.04-LTS:latest'. By checking APT logs, the
issue seems related to python2. Indeed, if I remove python2.7 (apt purge
python2.7) before doing 'do-release-upgrade', the upgrade goes fine.
Hi,
Thanks for looking into that. Indeed, while trying to reproduce the
issue this morning, I found it more challenging than I originally
thought. I want to add a few points here on how I reproduced the issue:
1. Usually, I do not use the Azure CLI directly. I use a custom CLI of my own
that
** Description changed:
+ [Impact]
+
+ * For the affected images`, the ESP is currently mounted with default
+ (0755) permissions. This means anyone can read the ESP partition. This
+ can cause security issues as sensitive data might be put in this
+ partition[0]
+
+ [Test Plan]
+
+ * Build
I will revert to the original description and move the SRU template to
LP1881006.
** Description changed:
- [Impact]
-
- * In cloud images, the ESP is currently mounted with default (0755)
- permissions. This means anyone can read the ESP partition. This can
- cause security issues as
@rcj thanks for your reply. Since we only want to SRU the umask change,
I propose move the discussion under this bug[0] as it is only related to
this particular change.
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006
--
You received this bug notification because you are a member of
** Description changed:
[Impact]
- * In cloud images, the ESP is currently mounted with default (0755)
-permissions. This means anyone can read the ESP partition. This can
-cause security issues as sensitive data might be put in this
-partition[1]
+ * In cloud images, the ESP
** Description changed:
+ [Impact]
+
+ * In cloud images, the ESP is currently mounted with default (0755)
+permissions. This means anyone can read the ESP partition. This can
+cause security issues as sensitive data might be put in this
+partition[1]
+
+ * The root filesystem
Awesome, thanks
On Wed, Mar 10, 2021 at 4:15 PM Dan Streetman <1913...@bugs.launchpad.net>
wrote:
> > @rbalint or @ddstreet, do you plan to also backport this to Xenial?
>
> sure
>
> ** Tags removed: verification-needed verification-needed-bionic
> verification-needed-focal
Thanks for this.
@rbalint or @ddstreet, do you plan to also backport this to Xenial?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1913763
Title:
hyperv: unable to distinguish PTP devices
To
A fix has been merged upstream:
https://github.com/systemd/systemd/pull/18811/files
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1913763
Title:
hyperv: unable to distinguish PTP devices
To manage
A similar rule has already been added upstream for KVM PTP device, see:
https://github.com/systemd/systemd/pull/5495
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1913763
Title:
hyperv: unable to
Public bug reported:
Hyperv provides a PTP device. On system with multiple PTP devices,
services like Chrony don't have a way to know which one is which.
We would like to have a udev rule to create a symlink to the hyperv
clock. This way, services could be configured to always use this clock
no
59 matches
Mail list logo