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
55 matches
Mail list logo
