IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
commit f00c36641a enabled
crash_kexec_post_notifiers by default regardless of whether pstore
is enabled or not.
The original intention to enabled this option by default is that
it only affects kernel post-panic behavior, so should have no harm.
But this is not true if the user wants a reliable kdump.
crash_kexec_post_notifiers is known to cause problem with kdump,
and it's documented in kernel. It's not easy to fix the problem
because of how kdump works. Kdump expects the crashed kernel to
jump to an pre-loaded crash kernel, so doing any extra job before
the jump will increase the risk.
It depends on the user to choose between having a reliable kdump or
some other post-panic debug mechanic.
So it's better to keep this config untouched by default, or it may put
kdump at higher risk of failing silently. User should enable it by
uncommenting the config line manually if pstore is always needed.
Also add a inline comment inform user about the potential issue.
Thanks to Dave Young for finding out this issue.
Fixes#16661
Signed-off-by: Kairui Song <kasong@redhat.com>
The systemd pstore service archives the contents of /sys/fs/pstore
upon boot so that there is room for a subsequent dump. The issue is
that while the service is present, the kernel still needs to be
configured to write data into the pstore. The kernel has two
parameters, crash_kexec_post_notifiers and printk.always_kmsg_dump,
that control writes into pstore.
The crash_kexec_post_notifiers parameter enables the kernel to write
dmesg (including stack trace) into pstore upon a panic, and
printk.always_kmsg_dump parameter enables the kernel to write dmesg
upon a shutdown (shutdown, reboot, halt).
As it stands today, these parameters are not managed/manipulated by
the systemd pstore service, and are solely reliant upon the user [to
have the foresight] to set them on the kernel command line at boot, or
post boot via sysfs. Furthermore, the user would need to set these
parameters in a persistent fashion so that that they are enabled on
subsequent reboots.
This patch introduces the setting of these two kernel parameters via
the systemd tmpfiles technique.