Blueprint changed by Chris J Arges: Whiteboard changed: User Stories: Risks: Test Plans: Release Note: + ---------- - [louis_bouchard] - kdump-tools needs to be MIR / file a bug: TODO - [smb] - discuss linuxcrashdump changes on ubuntu-devel / ubuntu-kernel: TODO - [smb] - linuxcrashdump changed to install kdump-tool (after discussion): BLOCKED - [christopherarges] - write better documentation for kdump-tool: TODO - [dannf] - validate/invalidate with kdump-tools / mkdumpfile on ARM: TODO - [louis_bouchard] - Integrate netdump support: POSTPONED - [med] - netdump charm to aggregate dumps in a cloud: TODO + 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
-- Enable kdump mechanism from kdump-tool instead of kexec-tools https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-kdump-tool -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
