Previously after setting kdump config, people will just regard the configs
to be "workable". However sometimes the "workable" kdump config is
just an
illusion and will not have a vmcore generated when system crashes. The patchset
implements kdumpctl test/test-check, which will actually perform a crash & dump
based on the current kdump config, to work as a way to verify if the current
kdump config can really generate vmcores.
kdumpctl test: It will output the current kdump config list to users, including
crash kernel size, effective contents of kdump.conf etc. Then it will generate
a timestamp, which works as a id to mark the current testing. For kdump, the
id will be appended to 2nd kernel's commandline. For fadump, the id will be
append to 1st kernel's dmesg through /dev/kmsg.
kdumpctl test-check: After system reboot back, test-check will automatically
mount the dump target, then check if the id exists within files of dump path.
For kdump, the id should be in kexec-dmesg.log, similar in vmcore-dmesg.txt for
fadump. If test-check is successful, a md5sum of the current kdump config will
be generated. If re-run test-check, it will only check if md5sum, or kdump
config, is changed. This can speed up re-running test-check, since it will
not remount dump target nor file string grep.
Tao Liu (5):
Extract some common functions from mkdumprd to kdump-lib.sh
Small modifications for kdumpctl test/test-check preparation
kdumpctl test support
kdumpctl test-check support
Add md5sum to kdumpctl test-check
dracut-kdump.sh | 1 -
kdump-lib-initramfs.sh | 6 ++
kdump-lib.sh | 138 ++++++++++++++++++++++++
kdumpctl | 232 ++++++++++++++++++++++++++++++++++++++++-
mkdumprd | 127 ++--------------------
5 files changed, 386 insertions(+), 118 deletions(-)
--
2.40.1