For this LP SRU submission, the following candidate packages were tested in amd64 arch in a qemu guest for each release: * Bionic, candidate version 1.6.5-1ubuntu1~18.04.4; * Disco, candidate version 1.6.5-1ubuntu1.4; * Eoan, candidate version 1.6.6-2ubuntu2;
The test consisted in trying a SSH dump to a hostname, with the kdump- tools present in -updates pocket, and see it fails (not being able to resolve the hostname). Then, install the candidate version in each release and observe the kdump complete successfully, being able to resolve hostnames. Cheers, Guilherme -- 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: In Progress Status in makedumpfile source package in Disco: In Progress Status in makedumpfile source package in Eoan: In Progress 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
