All autopkgtests for the newly accepted systemd (248.3-1ubuntu8.1) for impish have finished running. The following regressions have been reported in tests triggered by the package:
dpdk/20.11.3-0ubuntu1 (armhf) casper/1.465 (amd64) diaspora-installer/0.7.15.0+debian1 (s390x, armhf) libvirt-dbus/1.4.0-2ubuntu1 (amd64) exim4/4.94.2-7ubuntu2 (armhf) dovecot/1:2.3.13+dfsg1-1ubuntu3 (armhf) udisks2/2.9.4-1 (arm64) systemd/248.3-1ubuntu8.1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/impish/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1952599 Title: virt: Support detection for ARM64 Hyper-V guests (fixed upstream) 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 Hirsute: New Status in systemd source package in Impish: Fix Committed Status in systemd source package in Jammy: Fix Released Bug description: [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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1952599/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
