Enable kdump mechanism from kdump-tool instead of kexec-tools

Registered by Louis Bouchard on 2012-10-10

The kdump mechanism from the kdump-tool package is more flexible than its kexec-tool equivalent. It allows for multiple dumps to be collected, is the mechanism used in upstream Debian and has a configuration file that let the sysadmin controls some parameters.

It is currently functional on Ubuntu but the documented way of gathering a kernel dump is to use the 0_kdump initscript delivered by kexec-tools which package the kernel dump file as an Apport bundle. While this solution is sufficient on Desktops, it becomes restrictive on server/cloud installs.

Rationale: Current kexec-tool kernel dump capture mechanism is too limitative in a server/cloud environment

Goal: Decide on the feasibility of using kdump-tool as default for server/cloud installs

Blueprint information

Status:
Not started
Approver:
Dave Walker
Priority:
Medium
Drafter:
Ubuntu Server
Direction:
Approved
Assignee:
Louis Bouchard
Definition:
Approved
Series goal:
Accepted for raring
Implementation:
Unknown
Milestone target:
milestone icon ubuntu-13.04-feature-freeze

Related branches

Sprints

Whiteboard

User Stories:

Risks:

Test Plans:

Release Note:

----------

The kdump mechanism from the kdump-tool package is more flexible than its kexec-tool equivalent. It allows for multiple dumps to be collected, is the mechanism used in upstream Debian and has a configuration file that let the sysadmin controls some parameters.

It is currently functional on Ubuntu but the documented way of gathering a kernel dump is to use the 0_kdump initscript delivered by kexec-tools which package the kernel dump file as an Apport bundle. While this solution is sufficient on Desktops, it becomes restrictive on server/cloud installs.

Rationale: Current kexec-tool kernel dump capture mechanism is too limitative in a server/cloud environment. Because you only capture last crash; people want to change mkdumpfile options, have to hack scripts vs. conf files.

We might need to consider different use cases for desktop/server if using kdump-tool. But this might not be bad since we can have a similar setup as kexec-tool.

linux-crashdump
    - needs to be changed to install kdump-tool
    - does it need to install 'crash'? we might not do analysis on same machine

Goal: Decide on the feasibility of using kdump-tool as default for server/cloud installs

Issues :
what is the current story around kdump with UEFI ?
    - currently disabled if using secure boot
    - but will be re-enabled when we can use signed kexec kernels
Is the "server only" requirement valid or should we use kdump accross the board ?
Is usage of apport hooks for kernel dumps useful and/or valid ?

Need to be considerate of
    - whoopise integration (how is this turned on for servers?)
    - private data reporting (private daisy instance?)

Can server/cloud users upload large amounts of crash data?; need to consider sensitive environments, etc.

Discussion points:
Right now start with x86, long term ensure it works on ARM.
consider how we can reproduce apport behavor with kdump-tools during discussion.
need to determine use cases for desktop/server for kdump-tool configurations

Notes:
MIR is not required for kdump-tools as its source package (makedumpfile) is already in main
A simple kexec fails on ARM (Calxeda/Highbank) as of linux 3.8.0-17.27

(?)

Work Items

Work items:
[louis] - kdump-tools needs to be MIR / file a bug: DONE
[smb] - discuss linuxcrashdump changes on ubuntu-devel / ubuntu-kernel: DONE
[smb] - linuxcrashdump changed to install kdump-tool (after discussion): DONE
[arges] - write better documentation for kdump-tool: DONE
[dannf] - validate/invalidate with kdump-tools / mkdumpfile on ARM: DONE
[louis] - Integrate netdump support: POSTPONED
[med] - netdump charm to aggregate dumps in a cloud: POSTPONED

Dependency tree

* Blueprints in grey have been implemented.