[Bug 2062373] Re: 24.04 TPM backed FDE regression following shim 15.8 update
** 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 am informed - included the vendoring of snapd 2.62. + included the vendoring of shim 15.8. This has caused a regression and TPM backed FDE instances no longer boot as expected. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2062373 Title: 24.04 TPM backed FDE regression following shim 15.8 update To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nullboot/+bug/2062373/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2062373] Re: 24.04 TPM backed FDE regression following snapd 2.62 update
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 release a new version of nullboot with shim 15.8. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2062373 Title: 24.04 TPM backed FDE regression following snapd 2.62 update To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nullboot/+bug/2062373/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE
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 $ sudo apt update && sudo apt install -y dracut && sudo reboot # check the logs after reboot $ sudo journalctl -b0 | grep DENIED -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2064096 Title: Services fail to start in noble deployed with TPM+FDE To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2064096/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2064096] Re: rsyslog service timeout on noble numbat
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 (eg /run/systemd/journal/dev-log, /run/systemd/notify and others) before doing the pivot_root and reexec. Then, when apparmor tries to resolve the path of the peer socket it fails here[1] I believe. [1] https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/noble/tree/fs/d_path.c#n125 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2064096 Title: rsyslog service timeout on noble numbat To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2064096/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1954678] Re: Build for more platforms
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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1954678/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1954678] Re: Build for more platforms
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 upgraded. Need to get 186 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://ports.ubuntu.com/ubuntu-ports bionic-proposed/main arm64 walinuxagent arm64 2.2.45-0ubuntu1~18.04.2 [186 kB] Fetched 186 kB in 0s (3,529 kB/s) (Reading database ... 59468 files and directories currently installed.) Preparing to unpack .../walinuxagent_2.2.45-0ubuntu1~18.04.2_arm64.deb ... Unpacking walinuxagent (2.2.45-0ubuntu1~18.04.2) over (2.2.45-0ubuntu1~18.04.1ppa2) ... Setting up walinuxagent (2.2.45-0ubuntu1~18.04.2) ... update-initramfs: deferring update (trigger activated) Processing triggers for ureadahead (0.100.0-21) ... Processing triggers for initramfs-tools (0.130ubuntu3.13) ... update-initramfs: Generating /boot/initrd.img-5.4.0-1078-azure Unsupported platform on EFI system, doing nothing. ubuntu@bionic-arm:~$ dpkg -l walinuxagent Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii walinuxagent 2.2.45-0ubuntu1~18.04.2 arm64Windows Azure Linux Agent ubuntu@bionic-arm:~$ sudo systemctl status walinuxagent.service ● walinuxagent.service - Azure Linux Agent Loaded: loaded (/lib/systemd/system/walinuxagent.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2022-05-03 14:47:56 UTC; 51s ago Main PID: 27978 (python3) Tasks: 4 (limit: 4915) CGroup: /system.slice/walinuxagent.service ├─27978 /usr/bin/python3 -u /usr/sbin/waagent -daemon └─28149 python3 -u /usr/sbin/waagent -run-exthandlers May 03 14:47:57 bionic-arm python3[27978]: pkts bytes target prot opt in out source destination May 03 14:47:57 bionic-arm python3[27978]: Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) May 03 14:47:57 bionic-arm python3[27978]: pkts bytes target prot opt in out source destination May 03 14:47:57 bionic-arm python3[27978]:00 ACCEPT tcp -- * * 0.0.0.0/0168.63.129.16owner UID match 0 May 03 14:47:57 bionic-arm python3[27978]:00 DROP tcp -- * * 0.0.0.0/0168.63.129.16ctstate INVALID,NEW May 03 14:47:57 bionic-arm python3[27978]: 2022/05/03 14:47:57.497717 INFO ExtHandler Created slice for walinuxagent extensions system-walinuxagent.extensions.slice May 03 14:47:57 bionic-arm python3[27978]: 2022/05/03 14:47:57.507169 INFO ExtHandler Wire server endpoint:168.63.129.16 May 03 14:47:57 bionic-arm python3[27978]: 2022/05/03 14:47:57.518215 INFO ExtHandler Wire server endpoint:168.63.129.16 May 03 14:47:57 bionic-arm python3[27978]: 2022/05/03 14:47:57.574883 INFO ExtHandler Wire server endpoint:168.63.129.16 May 03 14:47:57 bionic-arm python3[27978]: 2022/05/03 14:47:57.580448 INFO ExtHandler ProcessGoalState completed [incarnation 1; 62 ms] ** Tags added: verification-done-bionic -- 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: https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1954678/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
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 fix. None of the instances shown any provisioning issue (cloud-init was always done withing 5min). This was the main symptom we were observing previously with 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/1871538 Title: dbus timeout-ed during an upgrade, taking services down including gdm To manage notifications about this bug go to: https://bugs.launchpad.net/dbus/+bug/1871538/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1966066] Re: audio from external sound card is distorted
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: audio from external sound card is distorted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.13/+bug/1966066/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
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, taking services down including gdm To manage notifications about this bug go to: https://bugs.launchpad.net/dbus/+bug/1871538/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1952599] Re: virt: Support detection for ARM64 Hyper-V guests (fixed upstream)
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
type=1,manufacturer=t1manufacturer,product=t1product,version=t1version,serial=t1serial,uuid=----,sku=t1sku,family=t1family
\
You can read more about them here[1]. In short, it configures the DMI
table as follows:
ubuntu@impish:~$ cat /sys/class/dmi/id/product_name
t1product
ubuntu@impish:~$ cat /sys/class/dmi/id/sys_vendor
t1manufacturer
ubuntu@impish:~$ cat /sys/class/dmi/id/bios_vendor
Hyper-V test
ubuntu@impish:~$ cat /sys/class/dmi/id/product_version
t1version
Thus, the old systemd should not detect any virt ("none") and the new
one should detect "microsoft"[2].
Test results:
Bionic
==
ubuntu@bionic:~$ dpkg -l systemd ; systemd-detect-virt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Architecture Description
+++-==---=
ii systemd237-3ubuntu10.52
arm64system and service manager
none
ubuntu@bionic:~$ sudo apt-get install -y systemd
...
ubuntu@bionic:~$ dpkg -l systemd ; systemd-detect-virt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Architecture Description
+++-==---=
ii systemd237-3ubuntu10.53
arm64system and service manager
microsoft
Focal
=
ubuntu@focal:~$ dpkg -l systemd ; systemd-detect-virt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==-=--=
ii systemd245.4-4ubuntu3.13 arm64system and service manager
none
ubuntu@focal:~$ sudo apt-get install -y systemd
...
ubuntu@focal:~$ dpkg -l systemd ; systemd-detect-virt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==-=--=
ii systemd245.4-4ubuntu3.14 arm64system and service manager
microsoft
Impish
==
ubuntu@impish:~$ dpkg -l systemd ; systemd-detect-virt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name VersionArchitecture Description
+++-==-==--=
ii systemd248.3-1ubuntu8 arm64system and service manager
none
ubuntu@impish:~$ sudo apt-get install -y systemd
...
ubuntu@impish:~$ dpkg -l systemd ; systemd-detect-virt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---=
ii systemd248.3-1ubuntu8.1 arm64system and service manager
microsoft
[0] https://pastebin.canonical.com/p/WCqqyCK7Qj/
[1] https://gist.github.com/smoser/290f74c256c89cb3f3bd434a27b9f64c
[2] https://github.com/systemd/systemd/blob/main/src/basic/virt.c#L144-L193
** Tags removed: verification-needed-bionic verification-needed-focal
verification-needed-impish
** Tags added: verification-done-bionic verification-done-focal
verification-done-impish
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1952599
Title:
virt: Support detection for ARM64 Hyper-V
[Bug 1954678] Re: Build for more platforms
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: https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1954678/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1954678] [NEW] Build for more platforms
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 be installed on arm64 [Where problems could occur] * We could discover bugs that only affects arm64 (or non-amd64) platform that are not visible at the moment. However, it is still better than not building it at all. [0] https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1326018 ** Affects: walinuxagent (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/1954678 Title: Build for more platforms To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1954678/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1952599] [NEW] virt: Support detection for ARM64 Hyper-V guests (fixed upstream)
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 Hyper-V guest: check if /sys/class/dmi/id/product_version starts with "Hyper-V". * This bug has already been fixed upstream[1][2] [Test Plan] * While changes have been made in the kernel for ARM64 on Hyper-V, there is no way to start an ARM64 VM on Hyper-V at the moment. Thus we just want to make sure no regression is introduced. * start an Hyper-V amd64 VM and make sure "systemd-detect-virt" still return MSFT (should still rely on cpuid here) [Where problems could occur] * The main risk is for the system to detect Hyper-V virt erroneously. An issue was reported upstream after the first commit was merged[3]. For this reason, systemd is now looking for "Hyper-V" (in /sys/class/dmi/id/product_version) and not "Microsoft" (in /sys/class/dmi/id/bios_vendor) * This change might also break virt detection on hyper-v AMD64. That's why we need testing. However, AMD64 virt detection should still rely on cpuid instead of DMI as cpuid takes priority over DMI. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7aff79e297ee1aa0126924921fd87a4ae59d2467 [1] https://github.com/systemd/systemd/pull/20998/files [2] https://github.com/systemd/systemd/pull/21475/files [3] https://github.com/systemd/systemd/issues/21468 ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Hirsute) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Impish) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Jammy) 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/1952599 Title: virt: Support detection for ARM64 Hyper-V guests (fixed upstream) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1952599/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1951924] Re: linux-azure 4.15 fails to boot on Standard_M416s_v2 in Azure
** 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1951924/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1951924] [NEW] linux-azure 4.15 fails to boot on Standard_M416s_v2 in Azure
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 delete the 5.4 kernel * reboot (the machine should fail to boot) The serial console logs can be found on the azure portal (boot diagnostic needs to be enabled for the VM first). Logs: https://pastebin.ubuntu.com/p/mhKMdMJCtX/ ** Affects: linux-azure (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/1951924 Title: linux-azure 4.15 fails to boot on Standard_M416s_v2 in Azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1951924/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
** 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 bug go to: https://bugs.launchpad.net/dbus/+bug/1871538/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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 Ubuntu. https://bugs.launchpad.net/bugs/1919177 Title: Azure: issues with accelerated networking on Hirsute To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
@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 bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
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 first investigation with @slyon, we added this
9
in /etc/dbus-1/system-local.conf and this particular error disappeared.
However the original issue ("Unexpected error response from
GetNameOwner()" and slow critical-chain) was still there.
--
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 bug go to:
https://bugs.launchpad.net/systemd/+bug/1871538/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
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: PASS:systemctl daemon-reload 2021-06-16 08:54:51,953 - handlers.py[DEBUG]: finish: init-network/config-mounts: SUCCESS: config-mounts ran successfully -- 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 bug go to: https://bugs.launchpad.net/systemd/+bug/1871538/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
@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 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 bug go to: https://bugs.launchpad.net/systemd/+bug/1871538/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
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: https://pastebin.ubuntu.com/p/WC4M7JdTGk/ in which you can read the following: Jun 3 06:57:12 alan-focal-base-uuisspbroykxijgbixkk systemd[1]: accounts-daemon.service: Unexpected error response from GetNameOwner(): Connection terminated Jun 3 06:57:12 alan-focal-base-uuisspbroykxijgbixkk systemd[1]: systemd-logind.service: Unexpected error response from GetNameOwner(): Connection terminated Jun 3 06:57:12 alan-focal-base-uuisspbroykxijgbixkk systemd[1]: polkit.service: Unexpected error response from GetNameOwner(): Connection terminated I built a custom hirsute image with dbus-broker installed and I was unable to reproduce the issue with it. -- 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 bug go to: https://bugs.launchpad.net/systemd/+bug/1871538/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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 subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1919177 Title: Azure: issues with accelerated networking on Hirsute To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1915571] Re: Cannot start bash session for buildd vm images in LXD vm
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 Codename: groovy ubuntu@ubuntu:~$ cat /etc/default/grub.d/50-builddimg-settings.cfg GRUB_DEFAULT=0 GRUB_HIDDEN_TIMEOUT=0.1 GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=0.1 GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0" GRUB_RECORDFAIL_TIMEOUT=0 GRUB_TERMINAL=console ubuntu@ubuntu:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.8.0-54-generic root=PARTUUID=797f2571-c983-48c6-9f6f-7b363913 ro console=ttyS0 Focal = ubuntu@ubuntu:~$ lsb_release -r -c Release:20.04 Codename: focal ubuntu@ubuntu:~$ cat /etc/default/grub.d/50-builddimg-settings.cfg GRUB_DEFAULT=0 GRUB_HIDDEN_TIMEOUT=0.1 GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=0.1 GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0" GRUB_RECORDFAIL_TIMEOUT=0 GRUB_TERMINAL=console ubuntu@ubuntu:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.4.0-74-generic root=PARTUUID=182116e9-0eda-43a0-beff-1e5acca75889 ro console=ttyS0 Bionic == ubuntu@ubuntu:~$ lsb_release -c -r Release:18.04 Codename: bionic ubuntu@ubuntu:~$ cat /etc/default/grub.d/50-builddimg-settings.cfg GRUB_DEFAULT=0 GRUB_HIDDEN_TIMEOUT=0.1 GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=0.1 GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0" GRUB_RECORDFAIL_TIMEOUT=0 GRUB_TERMINAL=console ubuntu@ubuntu:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=PARTUUID=8fbea74d-4805-4438-9bd6-f7725963faa2 ro console=ttyS0 ** Tags removed: verification-needed verification-needed-bionic verification-needed-focal verification-needed-groovy ** Tags added: verification-done verification-done-bionic verification-done-focal verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915571 Title: Cannot start bash session for buildd vm images in LXD vm To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1915571/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
@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 nice correlation. -- 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 bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
@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 for Azure systems. ii systemd 247.3-3ubuntu3 amd64system and service manager For reference, I took 20210219 and only upgraded systemd. I will also try to reproduce with Impish to confirm whether or not systemd 248 solves 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/1919177 Title: Azure: issues with accelerated networking on Hirsute To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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. https://bugs.launchpad.net/bugs/1919177 Title: Azure: issues with accelerated networking on Hirsute To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923111] Re: Azure Ubuntu 18.04.5 LTS hit a bug when running 'do-release-upgrade'
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: Azure Ubuntu 18.04.5 LTS hit a bug when running 'do-release-upgrade' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1923111/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1925526] Re: Hirsute/Azure: cloud-init-local sometimes very slow to initialize
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 Title: Hirsute/Azure: cloud-init-local sometimes very slow to initialize To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1925526/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1927124] [NEW] Azure/Xenial Pro FIPS: RuntimeError: duplicate mac found!
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 "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 652, in status_wrapper ret = functor(name, args) File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 361, in main_init init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL)) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 735, in apply_network_config self.distro.networking.wait_for_physdevs(netcfg) File "/usr/lib/python3/dist-packages/cloudinit/distros/networking.py", line 147, in wait_for_physdevs present_macs = self.get_interfaces_by_mac().keys() File "/usr/lib/python3/dist-packages/cloudinit/distros/networking.py", line 76, in get_interfaces_by_mac blacklist_drivers=self.blacklist_drivers) File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 830, in get_interfaces_by_mac blacklist_drivers=blacklist_drivers) File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 901, in get_interfaces_by_mac_on_linux (name, ret[mac], mac)) RuntimeError: duplicate mac found! both 'eth0' and 'enP1p0s2' have mac '00:0d:3a:7f:a8:e5' The following SAS URL can be used to start a VM with this image in order to reproduce the problem: https://gjolly.blob.core.windows.net/daily-vhd/xenial/20210430/Ubuntu_DAILY_BUILD-xenial-16_04-LTS-amd64-server-20210430-en-us-30GB.vhd?sp=r=2021-05-04T14:27:27Z=2022-05-04T22:27:27Z=https=2020-02-10=b=UYNr7aoThE28sZqkgAWCRSHuaBRqz4rAfJHWzbUqXKw%3D ** Affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Attachment added: "cloud-init.tar.gz" https://bugs.launchpad.net/bugs/1927124/+attachment/5494733/+files/cloud-init.tar.gz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927124 Title: Azure/Xenial Pro FIPS: RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1927124/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1925526] Re: Hirsute/Azure: cloud-init-local sometimes very slow to initialize
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. https://bugs.launchpad.net/bugs/1925526 Title: Hirsute/Azure: cloud-init-local sometimes very slow to initialize To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1925526/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923865] Re: Bootable buildd xenial images go to initramfs on boot
** 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 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1923865/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923865] Re: 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 notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1923865/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1881006] Re: Incorrect ESP mount options
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 #47~18.04.1-Ubuntu SMP Tue Apr 13 16:00:48 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux ubuntu@ip-172-31-6-24:~$ cat /etc/fstab LABEL=cloudimg-rootfs /ext4 defaults,discard0 1 LABEL=UEFI /boot/efi vfatumask=0077 0 1 ubuntu@ip-172-31-6-24:~$ mount -l | grep /boot/efi /dev/nvme0n1p15 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) [UEFI] ubuntu@ip-172-31-6-24:~$ ls -l /boot/ | grep efi drwx-- 3 root root 512 Jan 1 1970 efi ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1881006 Title: Incorrect ESP mount options To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1881006/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1881006] Re: Incorrect ESP mount options
** 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 Ubuntu. https://bugs.launchpad.net/bugs/1881006 Title: Incorrect ESP mount options To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1881006/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1881006] Re: Incorrect ESP mount options
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 Release:20.10 Codename: groovy ubuntu@ubuntu:~$ cat /etc/fstab LABEL=cloudimg-rootfs /ext4 defaults0 1 LABEL=UEFI /boot/efi vfatumask=0077 0 1 ubuntu@ubuntu:~$ mount -l | grep efi /dev/vda15 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) [UEFI] ubuntu@ubuntu:~$ ls -l /boot/ | grep efi drwx-- 3 root root 512 Jan 1 1970 efi AWS ARM[0] (Focal) $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.2 LTS Release:20.04 Codename: focal $ uname -a Linux ip-172-31-43-214 5.4.0-1045-aws #47-Ubuntu SMP Tue Apr 13 07:04:23 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux $ cat /etc/fstab LABEL=cloudimg-rootfs /ext4 defaults,discard0 1 LABEL=UEFI /boot/efi vfatumask=0077 0 1 $ ls -l /boot/ | grep efi drwx-- 3 root root 512 Jan 1 1970 efi Azure (Groovy) ubuntu@sru-test:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.10 Release:20.10 Codename: groovy ubuntu@sru-test:~$ cat /etc/fstab # CLOUD_IMG: This file was created/modified by the Cloud Image build process UUID=c8c63d06-c675-48ab-b62a-e5643d892aa8 /ext4 defaults,discard0 1 UUID=9468-D694 /boot/efi vfatumask=0077 0 1 /dev/disk/cloud/azure_resource-part1/mntauto defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig 0 2 ubuntu@sru-test:~$ ls -l /boot/ | grep efi drwx-- 3 root root 512 Jan 1 1970 efi ubuntu@sru-test:~$ mount -l | grep efi /dev/sdb15 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) [UEFI] Azure (Xenial): ubuntu@sru-test:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 16.04.7 LTS Release:16.04 Codename: xenial ubuntu@sru-test:~$ cat /etc/fstab # CLOUD_IMG: This file was created/modified by the Cloud Image build process UUID=d098c424-d293-4328-ad4a-82f0816e5c44 /ext4 defaults,discard0 1 UUID=70DB-F381 /boot/efi vfatumask=0077 0 1 /dev/disk/cloud/azure_resource-part1/mntauto defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig 0 2 ubuntu@sru-test:~$ ls -l /boot/ | grep efi drwx-- 4 root root 512 Jan 1 1970 efi ubuntu@sru-test:~$ mount -l | grep efi /dev/sda15 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) [UEFI] [0] On AWS only ARM machines support UEFI boot (https://aws.amazon.com/premiumsupport/knowledge-center/ec2-linux-boots-with-uefi-or-legacy-bios/) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1881006 Title: Incorrect ESP mount options To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1881006/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1925526] Re: Hirsute/Azure: cloud-init-local sometimes very slow to initialize
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 bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1925526 Title: Hirsute/Azure: cloud-init-local sometimes very slow to initialize To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1925526/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1925526] [NEW] Hirsute/Azure: cloud-init-local sometimes very slow to initialize
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 gap: 2021-04-22 15:00:55,211 - netlink.py[DEBUG]: Wait for media disconnect and reconnect to happen 2021-04-22 15:04:20,783 - netlink.py[DEBUG]: netlink socket ready for read This only seems to be affecting Hirsute, cloud-init 21.1-19-gbad84ad4-0ubuntu1~20.10.1. ** Affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Attachment added: "cloud-init logs" https://bugs.launchpad.net/bugs/1925526/+attachment/5491043/+files/cloud-init.tar.gz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1925526 Title: Hirsute/Azure: cloud-init-local sometimes very slow to initialize To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1925526/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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 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 bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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 (20.4.1-79-g71564dce-0ubuntu1). I will try to get a better package diff between those two images to understand if anything else significant changed. -- 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 bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
** 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 manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923865] Re: Bootable buildd xenial images go to initramfs on boot
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 constraints; unknown hardware! fsck: error 2 (No such file or directory) while executing fsck.ext4 for /dev/vda1 fsck exited with status code 8 The fsk issue is also present in the bionic images I tried but not the perfctr one. I just think something went/was wrong when grub was updated during build. -- 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 notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1923865/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
** 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 those cases, the SSH key is not setup properly and the
+ user cannot log into the VM.
[how to reproduce]
Start a VM with AN enabled:
```
az vm create --name "$VM_NAME --resource-group "$GROUP" --location "UK South"
--image
'Canonical:0001-com-ubuntu-server-hirsute-daily:21_04-daily-gen2:latest' --size
Standard_F8s_v2 --admin-username ubuntu --ssh-key-value "$SSH_KEY"
--accelerated-networking
```
After a moment, try to SSH: if you succeed, delete and recreate a new
VM.
[troubleshooting]
- To be able to connect into the VM to debug, run:
+ To be able to connect into the VM, run:
- ```
+
az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id
RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"
```
In "/run/cloud-init/instance-data.json", I can see:
```
- "publicKeys": [
- {
-"keyData": "",
-"path": "/home/ubuntu/.ssh/authorized_keys"
- }
- ],
+ "publicKeys": [
+ {
+ "keyData": "",
+ "path": "/home/ubuntu/.ssh/authorized_keys"
+ }
+ ],
```
as expected.
+
+ [workaround]
+
+ As mentioned, Azure allows the user to run command into the VM without
+ SSH connection. To do so, one can use the Azure CLI:
+
+
+ az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id
RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"
+
+ This example uses "ssh-import-id" but it's also possible to just echo a
+ given public key into /home/ubuntu/.ssh/authorized_keys
+
+ NOTE: this will only solves the SSH issue, I do not know if this bug
+ affects other things. If so the user would have to apply those things
+ manually.
** Description changed:
[General]
On Azure, when provisioning a Hirsute VM with Accelerated Networking
enabled, sometimes part of the cloud-init configuration is not applied.
- Especially, in those cases, the SSH key is not setup properly and the
- user cannot log into the VM.
+ Especially, in those cases, the public SSH key is not setup properly.
[how to reproduce]
Start a VM with AN enabled:
```
az vm create --name "$VM_NAME --resource-group "$GROUP" --location "UK South"
--image
'Canonical:0001-com-ubuntu-server-hirsute-daily:21_04-daily-gen2:latest' --size
Standard_F8s_v2 --admin-username ubuntu --ssh-key-value "$SSH_KEY"
--accelerated-networking
```
After a moment, try to SSH: if you succeed, delete and recreate a new
VM.
[troubleshooting]
To be able to connect into the VM, run:
-
az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id
RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"
```
In "/run/cloud-init/instance-data.json", I can see:
```
"publicKeys": [
{
"keyData": "",
"path": "/home/ubuntu/.ssh/authorized_keys"
}
],
```
as expected.
[workaround]
As mentioned, Azure allows the user to run command into the VM without
SSH connection. To do so, one can use the Azure CLI:
-
- az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id
RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"
+ az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id
+ RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"
This example uses "ssh-import-id" but it's also possible to just echo a
given public key into /home/ubuntu/.ssh/authorized_keys
NOTE: this will only solves the SSH issue, I do not know if this bug
affects other things. If so the user would have to apply those things
manually.
--
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 bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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 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 bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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 20.4-0ubuntu1 to 21.1-19-gbad84ad4-0ubuntu2 I still cannot reproduce the issue - upgrading systemd from 246.6-5ubuntu1 to 247.3-1ubuntu4 I couldn't reproduce the issue - upgrading BOTH cloud-init and systemd at the same time I was able to reproduce the issue I am now trying to test newer images to understand what is the first image that introduces 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/1919177 Title: Azure: issues with accelerated networking on Hirsute To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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 minimum). "/usr/lib/systemd/systemd-networkd-wait-online -o routable" -- 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 bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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 issue with gen1 hyper-v (before I was only using gen2). To continue the system log investigation, I can add the following: GOOD Apr 19 08:53:43 hirsute-man-2 systemd[1]: Finished Wait for Network to be Configured. Apr 19 08:53:43 hirsute-man-2 systemd-networkd[660]: eth0: Gained carrier Apr 19 08:53:43 hirsute-man-2 systemd-networkd[660]: eth0: DHCPv4 address 10.0.0.4/24 via 10.0.0.1 Apr 19 08:53:44 hirsute-man-2 cloud-init[667]: Cloud-init v. 21.1-19-gbad84ad4-0ubuntu2 running 'init' at Mon, 19 Apr 2021 08:53:44 +. Up 84.81 seconds. Apr 19 08:53:48 hirsute-man-2 systemd-networkd[660]: enP6454s1: Link UP Apr 19 08:53:48 hirsute-man-2 systemd-networkd[660]: enP6454s1: Gained carrier BAD Apr 19 08:33:48 groovy-acc-UWP5F systemd[1]: Finished Wait for Network to be Configured. Apr 19 08:33:48 groovy-acc-UWP5F systemd-networkd[616]: eth0: Gained carrier Apr 19 08:33:48 groovy-acc-UWP5F cloud-init[626]: Cloud-init v. 21.1-19-gbad84ad4-0ubuntu2 running 'init' at Mon, 19 Apr 2021 08:33:48 +. Up 7.34 seconds. Apr 19 08:33:48 groovy-acc-UWP5F systemd-networkd[616]: enP30932s1np0: Gained carrier Apr 19 08:33:51 groovy-acc-UWP5F systemd-networkd[616]: eth0: DHCPv4 address 10.0.0.4/24 via 10.0.0.1 On GOOD, DHCP is configured before Cloud-init runs, on BAD it's done after. This is "obvious" considering the error raised by cloud-init but I just wanted to underline it. -- 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 bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923111] Re: Azure Ubuntu 18.04.5 LTS hit a bug when running 'do-release-upgrade'
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. -- 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: Azure Ubuntu 18.04.5 LTS hit a bug when running 'do-release-upgrade' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1923111/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
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 uses the Azure SDK. This custom CLI always creates the NIC (with AN)
before creating the VM. The VM is created with the existing NIC. I don't know
how Azure CLI manages "--accelerated-networking" flag under the hood, maybe
it's doing something different that makes it harder to reproduce the issue.
2. (for costs reasons) I always create a new resource group when I create a
new VM. Once again, I don't know if it has any impact on the reproducibility.
3. This morning I managed to reproduce the issue using only the Azure CLI and
after a few (unsuccessful) tries:
➜ ~ az group create --resource-group hirsute-acc-manual-1 --location 'UK South'
{
"id":
"/subscriptions/5059ce5a-a72d-4085-acb7-33b421daa1ee/resourceGroups/hirsute-acc-manual-1",
"location": "uksouth",
"managedBy": null,
"name": "hirsute-acc-manual-1",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null,
"type": "Microsoft.Resources/resourceGroups"
}
➜ ~ az vm create --name hirsute-acc-manual --resource-group
hirsute-acc-manual-1 --location "UK South" --image
'Canonical:0001-com-ubuntu-server-hirsute-daily:21_04-daily-gen2:latest' --size
Standard_F8s_v2 --admin-username ubuntu --ssh-key-value "$(cat
~/.ssh/canonical.pub)" --accelerated-networking
{- Finished ..
"fqdns": "",
"id":
"/subscriptions/5059ce5a-a72d-4085-acb7-33b421daa1ee/resourceGroups/hirsute-acc-manual-1/providers/Microsoft.Compute/virtualMachines/hirsute-acc-manual",
"location": "uksouth",
"macAddress": "00-22-48-40-82-32",
"powerState": "VM running",
"privateIpAddress": "10.0.0.4",
"publicIpAddress": "51.104.198.218",
"resourceGroup": "hirsute-acc-manual-1",
"zones": ""
}
➜ ~ ssh -i ~/.ssh/canonical ubuntu@51.104.198.218
The authenticity of host '51.104.198.218 (51.104.198.218)' can't be established.
ECDSA key fingerprint is SHA256:wIQAUjmIeFvdBeqT5a2RHJEpDtjCnrJ+FggR8pzW7OM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '51.104.198.218' (ECDSA) to the list of known hosts.
ubuntu@51.104.198.218: Permission denied (publickey).
4. I will post the full syslog file here but I also want to point that
I THINK this issue only appears with mlx5 devices/drivers. When I was
checking the VM created with no issue, mlx4 modules were loaded. On the
previous VM, I can see:
ubuntu@hirsute-acc-manual:~$ lsmod | grep mlx
mlx5_ib 331776 0
ib_uverbs 139264 1 mlx5_ib
ib_core 348160 2 ib_uverbs,mlx5_ib
mlx5_core1081344 1 mlx5_ib
tls90112 1 mlx5_core
mlxfw 36864 1 mlx5_core
Once again, I don't know if that really matters.
** Attachment added: "syslog"
https://bugs.launchpad.net/cloud-init/+bug/1919177/+attachment/5487677/+files/syslog
--
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 bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1881006] Re: Incorrect ESP mount options
** 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 an uefi image from the ubuntu-cpc project in livecd-rootfs + + * Launch in KVM + + * Check `/etc/fstab` content + + * Check that mount options are reflected in 'mount' command output + + * Ensure a non-root user can not access /boot/efi + + [Where problems could occur] + + * Some users can have automation in place change the mount options. + This change might break their automation. However, because this change + is only related to the ESP partition, I don't think a lot of users would + want to change the default settings. + + * All use cases requiring non-root user to read from this file system + will be broken. However, given the content of this filesystem, this + scenario is unlikely and the security benefits should justify this risk. + + [original description] + Previously we decided that ESP should be mounted with umask=0077 See https://git.launchpad.net/ubuntu/+source/partman- efi/commit/fstab.d/efi?id=b141ba7648e66ae80eb58d26d40dd717cfee1904 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770033 https://bugs.launchpad.net/ubuntu/+source/partman-efi/+bug/1390183 This is also documented in https://wiki.ubuntu.com/FSTAB However, in GCE instance /boot/efi is not mounted with umask=0077 fstab is: LABEL=cloudimg-rootfs /ext4 defaults0 0 LABEL=UEFI /boot/efi vfatdefaults0 0 And in mount options are: (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) fstab should be fixed to specify "umask=0077" instead of "defaults" for the ESP partition also zsys setup in ubiquity does weird explicit umask=0022,fmask=0022,dmask=0022 which are the defaults anyway, not sure where that got those options from. systemd, gpt-auto-generator correctly defaults to umask=0077 for ESP mount I think subiquity is affected, as it does not set "options: 'umask=0077'" on the /boot/efi mount in the storage specification. + + [0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11 ** Description changed: [Impact] - * For the affected images`, the ESP is currently mounted with default + * 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 an uefi image from the ubuntu-cpc project in livecd-rootfs + * Build an uefi image from the ubuntu-cpc project in livecd-rootfs - * Launch in KVM + * Launch in KVM - * Check `/etc/fstab` content + * Check `/etc/fstab` content - * Check that mount options are reflected in 'mount' command output + * Check that mount options are reflected in 'mount' command output - * Ensure a non-root user can not access /boot/efi + * Ensure a non-root user can not access /boot/efi [Where problems could occur] - * Some users can have automation in place change the mount options. + * Some users can have automation in place change the mount options. This change might break their automation. However, because this change is only related to the ESP partition, I don't think a lot of users would want to change the default settings. - * All use cases requiring non-root user to read from this file system + * All use cases requiring non-root user to read from this file system will be broken. However, given the content of this filesystem, this scenario is unlikely and the security benefits should justify this risk. [original description] Previously we decided that ESP should be mounted with umask=0077 See https://git.launchpad.net/ubuntu/+source/partman- efi/commit/fstab.d/efi?id=b141ba7648e66ae80eb58d26d40dd717cfee1904 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770033 https://bugs.launchpad.net/ubuntu/+source/partman-efi/+bug/1390183 This is also documented in https://wiki.ubuntu.com/FSTAB However, in GCE instance /boot/efi is not mounted with umask=0077 fstab is: LABEL=cloudimg-rootfs /ext4 defaults0 0 LABEL=UEFI /boot/efi vfatdefaults0 0 And in mount options are: (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) fstab should be fixed to specify "umask=0077" instead of "defaults" for the ESP partition also zsys setup in ubiquity does weird explicit umask=0022,fmask=0022,dmask=0022 which are the defaults anyway, not sure where that got those options from. systemd, gpt-auto-generator correctly defaults to
[Bug 1902103] Re: Ensure default fstab options are sane and consistent across all images
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 sensitive data might be put in this - partition[0] - - * The root filesystem partition uses defaults mount options. In case - of filesystem error, it is safer to use `remount-ro`. Also for cloud - usage (where storage can be expensive) it makes sense to mount the - root filesystem with `discard`. This will also align cloud images - fstab with what we have elsewhere. - - [Test Plan] - - * Build an uefi image from the ubuntu-cpc project in livecd-rootfs - - * Launch in KVM - - * Check `/etc/fstab` content - - * Check that mount options are reflected in 'mount' command output - - * Ensure a non-root user can not access /boot/efi - - * Check 'lsblk -D' output to see that there is a non-zero discard block - size for the root device (this check may be imperfect, the goal is to - check that discard from fstab is enabled if available from the - underlying block device) - - [Where problems could occur] - - * Some users can have automation in place change those defaults. This - change might break their automation. - - * `error=remount-ro` might create issues for certain user. Especially if - the filesystem superblock default was set to `error=continue`. For - those users, any error that was previously ignored will make the - filesystem read-only. - - * `discard` parameter might have an impact on i/o throughput and reduce - read/write speed. Also some particular disk might have issues with - TRIM commands[1]. - - [original description] The default fstab entries for ubuntu cloud images are: LABEL=cloudimg-rootfs / ext4 defaults 0 0 LABEL=UEFI /boot/efi vfat defaults 0 0 These entries do not align with the defaults that we use elsewhere. We should decide on the defaults for fstab, and apply those consistently across all Ubuntu images. -- - quoted from ~xnox: I expect [these entries] to be: + quoted from ~xnox: the expect [these entries] to be: LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1 LABEL=UEFI /boot/efi vfat umask=0077 0 1 - - [0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11 - [1] https://wiki.debian.org/SSDOptimization#WARNING -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902103 Title: Ensure default fstab options are sane and consistent across all images To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1902103/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902103] Re: Ensure default fstab options are sane and consistent across all images
@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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902103 Title: Ensure default fstab options are sane and consistent across all images To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1902103/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902103] Re: Ensure default fstab options are sane and consistent across all images
** 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 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] - * The root filesystem partition uses defaults mount options. In case -of filesystem error, it is safer to use `remount-ro`. Also for cloud -usage (where storage can be expensive) it makes sense to mount the -root filesystem with `discard`. This will also align cloud images -fstab with what we have elsewhere. + * The root filesystem partition uses defaults mount options. In case + of filesystem error, it is safer to use `remount-ro`. Also for cloud + usage (where storage can be expensive) it makes sense to mount the + root filesystem with `discard`. This will also align cloud images + fstab with what we have elsewhere. [Test Plan] - * Start a GCE or a KVM instance + * Start a GCE or a KVM instance - * Check `/etc/fstab` content + * Check `/etc/fstab` content [Where problems could occur] - * Some users can have automation in place change those defaults. This -change might break their automation. + * Some users can have automation in place change those defaults. This + change might break their automation. - * `error=remount-ro` might create issues for certain user. Especially if -the filesystem superblock default was set to `error=continue`. For -those users, any error that was previously ignored will make the -filesystem read-only. + * `error=remount-ro` might create issues for certain user. Especially if + the filesystem superblock default was set to `error=continue`. For + those users, any error that was previously ignored will make the + filesystem read-only. - * `discard` parameter might have an impact on i/o throughput and reduce -read/write speed. Also some particular disk might have issues with -TRIM commands[2]. - - [0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11 - [1] http://cloud-images.ubuntu.com/daily/server/focal/current/ - [2] https://wiki.debian.org/SSDOptimization#WARNING + * `discard` parameter might have an impact on i/o throughput and reduce + read/write speed. Also some particular disk might have issues with + TRIM commands[1]. [original description] The default fstab entries for ubuntu cloud images are: LABEL=cloudimg-rootfs / ext4 defaults 0 0 LABEL=UEFI /boot/efi vfat defaults 0 0 These entries do not align with the defaults that we use elsewhere. We should decide on the defaults for fstab, and apply those consistently across all Ubuntu images. -- quoted from ~xnox: I expect [these entries] to be: LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1 LABEL=UEFI /boot/efi vfat umask=0077 0 1 + + + [0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11 + [1] https://wiki.debian.org/SSDOptimization#WARNING -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902103 Title: Ensure default fstab options are sane and consistent across all images To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1902103/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902103] Re: Ensure default fstab options are sane and consistent across all images
** 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 partition uses defaults mount options. In case +of filesystem error, it is safer to use `remount-ro`. Also for cloud +usage (where storage can be expensive) it makes sense to mount the +root filesystem with `discard`. This will also align cloud images +fstab with what we have elsewhere. + + [Test Plan] + + * Start a GCE or a KVM instance + + * Check `/etc/fstab` content + + [Where problems could occur] + + * Some users can have automation in place change those defaults. This +change might break their automation. + + * `error=remount-ro` might create issues for certain user. Especially if +the filesystem superblock default was set to `error=continue`. For +those users, any error that was previously ignored will make the +filesystem read-only. + + * `discard` parameter might have an impact on i/o throughput and reduce +read/write speed. Also some particular disk might have issues with +TRIM commands[2]. + + [0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11 + [1] http://cloud-images.ubuntu.com/daily/server/focal/current/ + [2] https://wiki.debian.org/SSDOptimization#WARNING + + [original description] + The default fstab entries for ubuntu cloud images are: LABEL=cloudimg-rootfs / ext4 defaults 0 0 LABEL=UEFI /boot/efi vfat defaults 0 0 These entries do not align with the defaults that we use elsewhere. We should decide on the defaults for fstab, and apply those consistently across all Ubuntu images. -- quoted from ~xnox: I expect [these entries] to be: LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1 LABEL=UEFI /boot/efi vfat umask=0077 0 1 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902103 Title: Ensure default fstab options are sane and consistent across all images To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1902103/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1913763] Re: hyperv: unable to distinguish PTP devices
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 verification-needed-groovy
> ** Tags added: verification-done verification-done-bionic
> verification-done-focal verification-done-groovy
>
> --
> You received this bug notification because you are a member of Canonical
> Cloudware, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1913763
>
> Title:
> hyperv: unable to distinguish PTP devices
>
> Status in systemd package in Ubuntu:
> Fix Released
> Status in systemd source package in Bionic:
> Fix Committed
> Status in systemd source package in Focal:
> Fix Committed
> Status in systemd source package in Groovy:
> Fix Committed
>
> Bug description:
> [impact]
>
> the /dev/ptp0 device for a hyperv instance may not be the correct,
> hyperv-provided, ptp device.
>
> [test case]
>
> on some hyperv instance types, particularly those that might contain
> passthrough network card(s) that also provide ptp, the first ptp
> device may not be the correct one to use for ptp, e.g. there may be
> multiple ones:
>
> $ ls /dev/ptp*
> /dev/ptp0 /dev/ptp1
> $ cat /sys/class/ptp/ptp0/clock_name
> hyperv
> $ cat /sys/class/ptp/ptp1/clock_name
> mlx5_p2p
>
> the order can change across boots, so a consistent way of addressing
> the hyperv-provided one is needed
>
> [regression potential]
>
> any regression would involve failure to properly create the ptp
> symlink, or other failure while udev is processing newly detected ptp
> device(s)
>
> [scope]
>
> this is needed in all releases
>
> this was fixed upstream with the commit
> 32e868f058da8b90add00b2958c516241c532b70 which is not yet included in
> any release
>
> [original description]
>
> 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 matter if it is ptp0, ptp1, etc..
>
> For example:
>
> ```
> SUBSYSTEM=="ptp", ATTR{clock_name}=="hyperv", SYMLINK += "ptp_hyperv"
> ```
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913763/+subscriptions
>
--
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 notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913763/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913763] Re: hyperv: unable to distinguish PTP devices
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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913763/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913763] Re: hyperv: unable to distinguish PTP devices
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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913763/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913763] Re: hyperv: unable to distinguish PTP devices
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 distinguish PTP devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913763/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913763] [NEW] hyperv: unable to distinguish PTP devices
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 matter if it is ptp0, ptp1, etc..
For example:
```
SUBSYSTEM=="ptp", ATTR{clock_name}=="hyperv", SYMLINK += "ptp_hyperv"
```
** 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/1913763
Title:
hyperv: unable to distinguish PTP devices
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913763/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
