All autopkgtests for the newly accepted makedumpfile (1:1.6.5-1ubuntu1~18.04.4) for bionic have finished running. The following regressions have been reported in tests triggered by the package:
makedumpfile/1:1.6.5-1ubuntu1~18.04.4 (ppc64el, s390x) 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/bionic/update_excuses.html#makedumpfile [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1856323 Title: kdump-tools is unable to resolve DNS when systemd-resolved is used Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Disco: Won't Fix Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Released Bug description: [Impact] * Currently kdump is unable to handle domain name resolution due to the lack of "resolved" service in the kdump environment; this happens given the nature of reduced service load required in the kdump scenario. * Kdump currently relies on a systemd service approach - there are 2 services, one being a configuration/load entity (kdump-tools.service) whereas the other is the crash dump service itself (kdump-tools- dump.service). Due to the complexity and risk in booting a machine after a kernel crash to collect kernel dump, it's expected kdump- tools-dump to load the minimal possible amount of services. In order to achieve that, kdump-tools-dump relies only in the sysinit and network-online targets. * The systemd DNS tool ("resolved") is not ready in the moment kdump- tools-dump service is up to collect the kernel dump; also, "resolved" depends on dbus.socket to work, so to have a fully functional DNS resolution we are hereby adding both services as dependencies for kdump-tools-dump, so the network dump functionality works with hostnames (not requiring anymore that users set IP raw addresses). * The attached SVG files (kdump.svg and regular_boot.svg) contains "systemd-analyze plot" outputs from a kdump-tools-dump and regular boot perspective. To collect the kdump data we manage to change the kdump-tools-dump service to load SSHd and also that required disabling the OneShot property of such service. With that data, one can check the services started/completed in each environment - it's possible to notice the absence of systemd-resolved when in kdump environment. * Notice this modification is being worked concurrently with other kdump-tools' changes in LP #1828596. [Test Case] 1) Deploy a Bionic VM e.g. with uvt-kvm; 2) Set-up console output in the guest; 3) Install the kdump-tools package; 4) Configure a network dump (SSH or NFS) using hostnames for the target machine; 5) Perform the test dump (with 'echo c> /proc/sysrq-trigger') and watch the failure in name resolution, [Regression Potential] * The modifications hereby proposed are minimal and scope-constrained to kdump-tools package; it'll only affect the services loaded before kdump-tools-dump collecting service. A regression would then potentially fails kdump completion if one of the new services added to the kdump environment load (resolved and dbus.socket) fails to load and stalls/prevents the kdump service complete load. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1856323/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
