[Bug 1800566] Re: Make reset_devices parameter default for kdump and decouple kdump systemd service from the KDUMP_CMDLINE_APPEND

[Ubuntu Foundations Team Bug Bot]

The attachment "lp1800566_eoan.debdiff" seems to be a debdiff.  The
ubuntu-sponsors team has been subscribed to the bug report so that they
can review and hopefully sponsor the debdiff.  If the attachment isn't a
patch, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe
the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issue please contact him.]

** Tags added: patch

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1800566

Title:
  Make reset_devices parameter default for kdump and decouple kdump
  systemd service from the KDUMP_CMDLINE_APPEND

Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Trusty:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Confirmed
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Cosmic:
  Confirmed
Status in makedumpfile source package in Disco:
  Confirmed
Status in makedumpfile source package in Eoan:
  In Progress

Bug description:
  [Impact]

  * Kdump does not configure by default the crash kernel to perform a
  device reset by default, by passing the "reset_devices" parameter.
  Also, the systemd service "kdump-tools-dump" is tightly-coupled with
  KDUMP_CMDLINE_APPEND and it shouldn't, to prevent user confusion.

  * Kernel has the "reset_devices" parameter that drivers can opt-in,
  and perform special activity in case this parameter is parsed from
  command-line. For example, in kdump kernels it hints the drivers that
  they are booting from a non-healthy condition and needs to issue some
  form of reset to the adapter, like clearing DMA mapping in their
  firmware for example. Users currently (kernel v5.2) are: aacraid,
  hpsa, ipr, megaraid_sas, mpt3sas, smartpqi, xenbus.

  This should be enabled by default in the kdump config file to be added
  in the kdump kernel command-line for all versions.

  * The systemd service"kdump-tools-dump" is responsible for triggering the execution of the makedumpfile tool ultimately. Kdump from Xenial+ releases rely on systemd as their init system, so this service is the way to trigger the kdump mechanism. Currently it is configured as any other parameter in KDUMP_CMDLINE_APPEND, meaning if user decides to change the line they need to remember adding the systemd service back. It's not really a parameter that should be easily manipulated in kdump line, since there's no use for it except to instruct systemd to load kdump; the only 
  reasonable case for removing it is to debug kdump itself.

  
  [Test Case]

  1) Deploy a Disco VM e.g. with uvt-kvm
  2) Install the kdump-tools package
  3) Run `kdump-config test`and check for the 'reset_devices' parameter:

  $ kdump-config test
  ...
  kexec command to be used:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" /var/lib/kdump/vmlinuz

  Also, by changing the KDUMP_CMDLINE_APPEND we can see "systemd.unit
  =kdump-tools.service" to be removed.

  
  [Regression Potential]

  The regression potential is low, since it doesn't need any changes in
  makedumpfile code and we're only adding a parameter on the crash
  kernel command-line. The risks are related with bad behavior with the
  kernel when using "reset_devices", like if the driver has bugs in this
  path. It's considered safer to have the option (and this way prevent
  problems for booting a unhealthy kernel with potential stuck DMAs in
  the devices) than not having it.

  Regarding the other change, about the systemd service, it'll only
  affect users the are debugging kdump itself and it has no known
  regression potential.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800566/+subscriptions