** Description changed:
- kdump-tools runs early in boot, currently before systemd-resolved is
- loaded. This LP is to track efforts on fixing this. Current idea is to
- load systemd-resolved from kdumpt-tools-dump service. Description will
- be updated accordingly, when SRU is ready for submission.
+ [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.
** Attachment added: "regular_boot.svg"
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1856323/+attachment/5314421/+files/regular_boot.svg
--
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:
In Progress
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:
In Progress
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
