Makedumpfile SRU Exception

This document describes the policy for introducing new upstream releases of makedumpfile into a stable supported distro, including LTS.

MAKEDUMPFILE

makedumpfile makes a relatively small memory dump file by compressing dumpdata or by excluding unnecessary pages for analysis, or both. It is used by default by kdump-tools, Ubuntu's facility for recovering crash dump artifacts after a kernel crash, as otherwise dump files would be too large for users to reasonably store and transfer.

This tool is critical for Canonical to support Ubuntu Advantage customers, partners, and the community. It is dependent on kernel interfaces that can change between kernel versions, so it often breaks with the release of newer kernels (e.g. HWE kernels). Since upstream attempts to preserve backwards compatibility, it is safer to keep it updated to the latest necessary version for all the supported releases rather than to SRU individual patches.

In addition to bug fixes, new versions of makedumpfile can be SRU-ed in to older releases provided the steps in the “Process” section are followed.

Features

• Excludes unnecessary pages from dump
• Compress dump data with zlib, lzo, zstd, or snappy
• Multi-threaded processing

Resources

• Project page

• Wiki

• Kexec mailing list archives

Process

This is the mandatory process that the proposed packages have to pass.

For every stable release, the proposed packages should be tested as follows:

Manually test that the candidate makedumpfile can be used successfully as part of the crash dump process.

1. Configure Linux Crash Dump on a given system.

2. Trigger a crash and make sure the dump and dmesg files are created correctly.

     # echo 1 > /proc/sys/kernel/sysrq
     # echo c > /proc/sysrq-trigger

3. After the reboot, verify that the directory """/var/crash/<timestamp>""" exists, with the contents:

     dmesg.<timestamp>
     dump.<timestamp>

For LTS releases, also test the corresponding HWE kernels.

Test the main cloud kernels (linux-azure, linux-gcp, linux-aws).

Ensure backwards compatibility is maintained.

Thoroughly test at least x86_64. Preferably, test other architectures as well.

Requesting the SRU

The SRU should be requested as usual (StableReleaseUpdates), with an additional note about having completed the steps documented in the “Process” section.

Past SRUs

Links to past SRUs using this process are below: