Early kdump inherits the settings of normal kdump, so any changes that
caused normal kdump rebuilding also require rebuilding the system initramfs
to make sure that the changes take effect for early kdump.
Therefore, when the early kdump is enabled, provide a prompt message after
the rebuilding of kdump initramfs is completed.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Previous we rebuild the initramfs when kenrel load module list changed,
but this is not very stable as some async services may load/unload
kernel modules, and cause unnecessary initramfs rebuild.
Instead, it's better to just check if the module required to dump to
the dump target is loaded or not, and rebuild if not loaded. This
avoids most false-positives, and ensure local target change is always
covered.
Currently only local fs dump target is covered, because this check
requires the dump target to be mounted when building the initramfs,
this guarantee that the module is in the loaded kernel module list,
else we may still get some false positive.
dracut-install could be leveraged to combine the modalias list with
kernel loaded module list as a more stable module list in the initramfs,
but upstream dracut change need to be done first.
Passed test on a KVM VM, changing the storage between SATA/USB/VirtIO
will trigger initramfs rebuild and didn't notice any false-positive.
Also passed test on my laptop with no false-positive.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This reverts commit 6b479b6572.
Check initramfs rebuild by looking at if there is any change of load
kernel modules list is not very stable after all. Previously we are
counting on udev to settle before kdump is started to ensure all modules
is ready, but actually any service may cause a kernel module load, even
after udev is settled.
The previous commit is trying to workaround an issue that VM created
with disk snapshot may fail in the kdump initramfs. The better fix is to
not include the kdump initramfs in the disk snapshot at all, as the
kdump initramfs is not generated for a generic use. And With new added
"kdumpctl reload" command, admins could rebuild the image easily, and
should rebuild the initramfs on hardware change manually.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Use "kdumpctl rebuild" to rebuild the image directly. This could help
admins to rebuild kdump image directly.
Also merge fadump related initramfs backup/restore into setup_initrd,
and do permission only when actually trying to rebuild the image.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
With kernel commit 0823c68b054b ("powerpc/fadump: re-register firmware-
assisted dump if already registered") support is enabled to re-register
when FADump is alredy registered. Leverage that option in kdump scripts.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Kairui Song <kasong@redhat.com>
The idea behind adding support for dracut '--rebuild' option was to
ensure the initrd built for fadump takes into consideration all the
build parameters passed to original initrd. Pass original initrd
instead of current default initrd for rebuild as current initrd
might already have build parameters from original initrd along
with parameters from previous fadump intird build making the
build parameters look like this after a few iterations:
-H --persistent-policy 'by-uuid' -f --quiet --hostonly --hostonly-
cmdline --hostonly-i18n --hostonly-mode 'strict' -o 'plymouth dash
resume ifcfg' --mount '/dev/mapper/rhel_zzfp219--lp3-home /kdumproot
//home xfs defaults' -f --kver '4.18.0-60.el8.ppc64le' --quiet
--hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode 'strict'
-o 'plymouth dash resume ifcfg' --mount '/dev/mapper/rhel_zzfp219--lp3-home
/kdumproot//home xfs defaults' -f --kver '4.18.0-60.el8.ppc64le' --quiet
--hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode 'strict'
-o 'plymouth dash resume ifcfg' --mount '/dev/mapper/rhel_zzfp219--lp3-home
/kdumproot//home xfs defaults' -f --kver '4.18.0-60.el8.ppc64le' --include
'/tmp/fadump.initramfs' '/etc/fadump.initramfs' --include
'/tmp/fadump.initramfs' '/etc/fadump.initramfs' --include
'/tmp/fadump.initramfs' '/etc/fadump.initramfs'
--
Since it is not desirable to build initrd with stale and/or duplicate
build parameters, use original initrd (backed up) to rebuild fadump
initrd, instead of current default initrd.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
If a crash occurs repeatedly after enabling kdump, the system goes
into a crash loop and the dump target may get filled up by vmcores.
This is likely especially with early kdump.
This patch introduces 'final_action' option to kdump.conf, in order
for users to be able to power off the system even after capturing
a vmcore successfully.
Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Lianbo Jiang <lijiang@redhat.com>
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Kairui Song <kasong@redhat.com>
In preparation for adding 'final_action' option, since it's confusing
to have the 'final_action' and 'default' options at the same time,
this patch introduces 'failure_action' as an alias of the 'default'
option to /etc/kdump.conf, and makes 'default' obsolete to be removed
in the future.
Also, the "default action" term is renamed to "failure action".
Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Lianbo Jiang <lijiang@redhat.com>
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Kairui Song <kasong@redhat.com>
In commit b34ce3a reload support was added to kdumpctl but the usage
info is not updated. Now add reload to usage output to let user aware
of the new command.
Signed-off-by: Kairui Song <kasong@redhat.com>
Add reload support to kdumpctl, reload will simply unload current
loaded kexec crash kernel and initramfs, and load it again.
Changes in /etc/sysconfig/kdump will take effect with kdumpctl
reload, but reloading will not check the content of
/etc/kdump.conf and won't rebuild anything. reload is fast, the only
time-consuming part of kdumpctl reload is loading kernel and initramfs
with kexec which is always necessary.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Currently the kdumpctl script doesn't check if the raw device is
formatted which might destroy existing data at the time of dump
capture.
This patch addresses this issue, by ensuring kdumpctl prints
a warning in case it finds the raw device to be formatted.
Signed-off-by: Kenneth D'souza <kdsouza@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
Currently the kdumpctl script doesn't check if the path option is
set more than once due to which a vmcore is not captured.
This patch addresses this issue by ensuring that only one path
is specified in /etc/kdump.conf file.
Signed-off-by: Kenneth D'souza <kdsouza@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
Currently, we only rebuilt kdump initramfs on config file change,
fs change, or watchdog related change. This will not cover the case
that hardware changed but fs layout and other configurations still
stays the same, and kdump may fail.
To cover such case, we can detect and compare loaded kernel modules,
if a hardware change requires the image to be rebuilt, loaded kernel
modules must have changed.
Starting from commit 7047294 dracut will record loaded kernel modules
when the image is built if hostonly mode is enabled. With this patch,
kdumpctl will compare the recorded value with currently loaded kernel
modules, and rebuild the image on change.
"kdumpctl start" will be a bit slower, as we have to call lsinitrd one
more time to get the loaded kernel modules list. I measure the time
consumption and we have an overall 0.2s increased loading time.
Time consumption of command "kdumpctl restart":
Before:
real 0m0.587s
user 0m0.481s
sys 0m0.102s
After:
real 0m0.731s
user 0m0.591s
sys 0m0.133s
Time comsumption of command "kdumpctl restart" with image rebuild:
Before (force rebuild):
real 0m10.972s
user 0m8.966s
sys 0m1.318s
After (inserted ~100 new modules):
real 0m11.220s
user 0m9.387s
sys 0m1.337s
Signed-off-by: Kairui Song <kasong@redhat.com>
we move some common functions from kdumpctl to kdump-lib.sh, the
functions could be used in other modules, such as early kdump.
It has no bad effect.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Reviewed-by: Kazuhito Hagio <khagio@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
port from rhel, original patch is contributed by Minfei Huang:
Using /sys to determines crashkernel actual size is confusing since
there is no unit of measure.
Add a new command "kdumpctl showmem" to show the reserved memory kindly.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
When core_collector is changed, the kdump initramfs needs to
be rebuilt before it is loaded.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
When using "dracut_args --mount" to specify dump target, e.g. nfs like:
path /
core_collector makedumpfile -d 31
dracut_args --mount "host:/path /var/crash nfs defaults"
kdump service should neither guarantees the correctness, nor relabels it.
For current code, since dracut_args dump targets are likely not mounted
so kdump service mistakenly relabel the rootfs, which is meanless and
takes very long time.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
This reverts commit 2040103bd7.
Reason is it's based on the environment of 1st kernel where all
present devices could be active and initialized during bootup.
Then all pci devices will request irqs. While kdump only brings
up those devices which are necessary for vmcore dumping. So this
commit is not meaningful and helpless to very large extent. And
it will print out 'Warning' when calculated result is larger than
1 cpu, actually it's a false positive report most of the time.
So revert the commit, and can check the git history for later
reference.
[dyoung]: on some machine this warning message shows up but
later we found the irq numbers with and without nr_cpus=1 is
quite different so this need more investigation since
the formula is not accurate.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: BZ1484945
https://bugzilla.redhat.com/show_bug.cgi?id=1484945
Currently the kdumpctl script doesn't handle
whitespaces (including TABs) which might be there before
an option name in the kdump.conf
This patch addresses this issue, by ensuring that the
kdumpctl errors out in case it finds any stray space(s)
or tab(s) before a option name.
Reported-by: Kenneth D'souza <kdsouza@redhat.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
As default initrd is used for booting fadump capture kernel, it must be
rebuilt with dump capture capability when dump mode is fadump. Check if
default initrd is already fadump capable and rebuild, if necessary.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Now with the help of "--hostonly-cmdline", dracut will generate
the needed cmdlines for the dump target, so we can avoid the
corresponding duplicate or unnecessary inheritage.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Currently, we kept "root=X" for the dump_to_rootfs case, this
patch consolidates to use "--mount" for all the kdump mounts.
One advantage of this way is that dracut can correctly mark root
(in case of dump_to_rootfs is specified) as the host device when
"--no-hostonly-default-device" is added in the following patch.
Changed the code style in passing, as shellcheck tool reported:
Use $(..) instead of deprecated `..`
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Make is_fadump_capable() a library function, as we will need
it in mkdumprd.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This reverts commit cb38b32dfc.
We are going to add "--hostonly-cmdline" dracut argument in
the following patch.
With the help of "--hostonly-cmdline", dracut will generate
"rd.lvm.lv=X" for us, no need to implement here again.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This reverts commit 54a5bcc4ee.
We are going to add "--no-hostonly-default-device" dracut argument
in the following patch.
With the help of "--no-hostonly-default-device", dracut only
adds the dump target as host devices, which naturally guarantees
only required dracut modules being selected.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
We met a problem on AMD machines, when using "nr_cpus=4" for
kdump, and crash happens on cpus other than cpu0, kdump kernel
will fail to boot and eventually reset.
After some debugging, we found that it stuck at the kernel path
do_boot_cpu()-> ... ->wakeup_secondary_cpu_via_init():
apic_icr_write(APIC_INT_LEVELTRIG|APIC_INT_ASSERT|APIC_DM_INIT,
phys_apicid);
that is, it stuck at sending INIT from AP to BP and reset, which
is actually what "disable_cpu_apicid=X" tries to solve. Printing
the value of @phys_apicid showed that it was the value of "apicid"
other that of "initial apicid" showed by /proc/cpuinfo.
As described in x86 specification:
"In MP systems, the local APIC ID is also used as a processor ID by the
BIOS and the operating system. Some processors permit software to modify
the APIC ID. However, the ability of software to modify the APIC ID is
processor model specific. Because of this, operating system software
should avoid writing to the local APIC ID register. The value returned by
bits 31-24 of the EBX register (when the CPUID instruction is executed with a
source operand value of 1 in the EAX register) is always the Initial APIC ID
(determined by the platform initialization). This is true even if software
has changed the value in the Local APIC ID register."
From kernel commit 151e0c7de("x86, apic, kexec: Add disable_cpu_apicid
kernel parameter"), we can see in generic_processor_info(), it uses
a)read_apic_id() and b)@apicid to compare with @disabled_cpu_apicid.
a)@apicid which is actually @phys_apicid above-mentioned is from the
following calltrace(on the problematic AMD machine):
generic_processor_info+0x37/0x300
acpi_register_lapic+0x30/0x90
acpi_parse_lapic+0x40/0x50
acpi_table_parse_entries_array+0x171/0x1de
acpi_boot_init+0xed/0x50f
The value of @apicid(from acpi MADT) is equal to the value of "apicid"
showed by /proc/cpuinfo as proved by our debug printk.
b)read_apic_id() gets the value from LAPIC ID register which is "apicid"
as well.
While the value of "initial apicid" is from cpuid instruction.
One example of "apicid" and "initial apicid" of cpu0 from /proc/cpuinfo
on AMD machine:
apicid : 32
initial apicid : 0
Therefore, we should assign /proc/cpuifo "apicid" to "disable_cpu_apicid=X".
We've never met such issue before, because we usually tested "nr_cpus=1",
and mostly on Intel machines, and "apicid" and "initial apicid" have the
same value in most cases on Intel machines.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz1451717
https://bugzilla.redhat.com/1451717
When there is no crypt related kdump target, we can safely
omit "crypt" dracut module, this can avoid the pop asking
disk password during kdump boot in some cases.
This patch introduces omit_dracut_modules() before calling
dracut, we can omit more modules to reduce initrd size in
the future.
We don't want to omit any module for fadump, thus we move
is_fadump_capable() into kdump-lib.sh as a helper to use.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz1451717
https://bugzilla.redhat.com/1451717
When there is any "rd.lvm.lv=X", "lvm" dracut module will
try to recognize all the lvm volumes which is unnecessary
and probably cause trouble for us.
See https://bugzilla.redhat.com/show_bug.cgi?id=1451717#c2
Remove all the rd.lvm.lv=X inherited from the kernel cmdline,
and generate the corresponding cmdline as needed for kdump.
Because prepare_cmdline() is only used by kdump, we don't need
to add any fadump judgement(also remove the existing judgement
in passing).
Currently, we don't handle "rd.lvm.vg=X", we can add it in
when there is some bug reported in the future.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz1451717
https://bugzilla.redhat.com/1451717
We need to know all the kdump targets including the dump
target and root in case of "dump_to_rootfs".
This is useful for us to do some extra work related to the
type of different targets.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz1451717
https://bugzilla.redhat.com/1451717
This patch improves get_block_dump_target as follows:
-Consider block device in the special "--dracut-args --mount ..."
in get_user_configured_dump_disk().
-Consider save path instead of root fs in get_block_dump_target(),
and move it into kdump-lib.sh because we will have another user
in the following patch.
-For nfs/ssh dumping, there is no need to check the root device.
-Move get_save_path into kdump-lib.sh.
After this patch, get_block_dump_target() can always return the
correct block dump target specified.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Description of problem
(https://bugzilla.redhat.com/show_bug.cgi?id=1465735):
Run `kdumpctl status` as normal user, get below error messages:
Another app is currently holding the kdump lock; waiting for it to exit...
flock: 9: Bad file descriptor
Another app is currently holding the kdump lock; waiting for it to exit...
flock: 9: Bad file descriptor
...
The bug is caused by behavior difference between bash
and sh (bash in posix).
In the function single_instance_lock in kdumpctl script,
there is
exec 9>/var/lock/kdump
which will fail in user mode. However, this fail will cause
script exiting under bash but not exiting under sh, causing
infinite loop because the flock will always fail.
According to the 16th item in
ftp://ftp.gnu.org/old-gnu/Manuals/bash-2.02/html_node/bashref_66.html
If a POSIX.2 special builtin returns an error status, a non-
interactive shell exits.
And according to
https://www.gnu.org/software/bash/manual/html_node/Special-Builtins.html
exec is one of the POSIX.2 special builtin's.
This patch fixes the bug by checking exec return value.
Fixes: 9fb2996d05 ("kdumpctl: change the shebang header to use /bin/bash")
Signed-off-by: Ziyue Yang <ziyang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
kdump should not send fence_kdump notifications to local host, because
the role of the falied node (i.e local host) is to send fence_kdump
notifications to other nodes to tell them I'm kdumping, tell to itself is
nonsense. And we have excluded hostname of local host but when one use ip
address we also need exclude it.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
We met one issue that when changing softlink of "/usr/bin/sh"
to point to "ksh" instead of the default "bash", kdumpctl will
not work and go wrong.
kdumpctl is expected to run under bash like dracut, we should
change its shebang header from "#!/bin/sh" to "#!/bin/bash".
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
The "time kdumpctl start" command shows that strip_comments()
consumes lots of cpu time. By only calling it when necessary,
it saves us nearly half second.
Tested on my Fedora kvm machine.
Before this patch:
$ time kdumpctl start
kexec: loaded kdump kernel
Starting kdump: [OK]
real 0m1.849s
user 0m1.497s
sys 0m0.462s
After this patch:
$ time kdumpctl start
kexec: loaded kdump kernel
Starting kdump: [OK]
real 0m1.344s
user 0m1.195s
sys 0m0.195s
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz1449801
"cat $KDUMP_CONFIG_FILE|grep -v "^#"|while read ..." use pipes
to invoke subshells, as a result we met "the dreaded inaccessible
variables within a subshell problem" as described in the book
"Advanced Bash-Scripting Guide".
It cause regressions, so revert it.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
I found using "cat $KDUMP_CONFIG_FILE|grep -v "^#"|while read ..."
instead of "while read ... do ...; done < $KDUMP_CONFIG_FILE" will
make the script run faster, it saves us nearly half second.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
We use faster "lsinitrd XXX -f usr/lib/dracut/build-parameter.txt"
instead of "lsinitrd XXX | grep "^Arguments:" | head -1", this can
save us around one second.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Use the logic of dracut 04watchdog/module-setup.sh to check,
then we only need to compare the content of 00-watchdog.conf,
so we can save one operation of lsinitrd.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
handle_mode_switch() can ensure the correct logic, so remove
the needless is_mode_switched(). This helps to save one slow
lsinitrd operation for each boot.
Improved backup_default_initrd() to judge DEFAULT_INITRD.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Some cloud people complained that VM boot speed is slower than
Ubuntu and other distributions, after some debugging, we found
that one of the causes is kdump service starts too slow(7seconds
according to the test result on the test VM), actually there is
no "crashkernel=X" specified. Although kdump service is parallel,
it affects the speed more or less especially on VMs with few cpus,
which is unacceptable. It is even worse when kdump initramfs is
built out in case of no reserved memory at first boot.
Commit afa4a35d3 ("kdumpctrl: kdump feasibility should fail if no
crash memory") can actually solve this issue.
This patch is a supplement of above-mentioned commit, we bail out
start() even earlier in case of no reserved memory.
Also made some cosmatic changes for check_crash_mem_reserved().
1) Before this patch
$ time kdumpctl start
No memory reserved for crash kernel.
Starting kdump: [FAILED]
real 0m0.282s
user 0m0.184s
sys 0m0.146s
2) After this patch
$ time kdumpctl start
No memory reserved for crash kernel
Starting kdump: [FAILED]
real 0m0.010s
user 0m0.008s
sys 0m0.001s
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This patch introduces the 'force_no_rebuild' option
inside the 'kdump.conf' and its handling inside the 'kdumpctl'
script.
There might be several use cases, where a system admin
decides that he doesn't need to rebuild the kdump initrd
and wants to use an existing version of the same. In such cases,
he can set the 'force_no_rebuild' option inside 'kdump.conf'
to 1, to force the 'kdumpctl' script not to rebuild the kdump
initrd.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This reverts commit 892bea7aa
We already eliminated the root filesystem by removing "root=X"
in case of non-root dumping, and for livecd it must be non-root
dumping according to "live-image-kdump-howto.txt".
So it's time to revert this commit.
Also update "live-image-kdump-howto.txt", make sure users do not
configure "default dump_to_rootfs".
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
Since the current dracut of Fedora already supports not always
mounting root device, we can remove "root=X" from the command
line directly, and always get the dump target specified in
"/etc/kdump.conf" and mount it. If the dump target is located
at root filesystem, we will add the root mount info explicitly
from kdump side instead of from dracut side.
For example, in case of nfs/ssh/usb/raw/etc(non-root) dumping,
kdump will not mount the unnecessary root fs after this change.
This patch removes "root=X" via the "KDUMP_COMMANDLINE_REMOVE"
(if "default dump_to_rootfs" is specified, don't remove "root=X"),
and mounts non-root target under "/kdumproot", the root target
still under "/sysroot"(to be align with systemd sysroot.mount).
After removing "root=X", we now add root fs mount information
explicitly from the kdump side.
Changed check_dump_fs_modified() a little to avoid rebuild when
dump target is root, since we add root fs mount explicitly now.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
For the following scripts:
cmdline="root=/dev/mapper/fedora-root rd.lvm.lv=fedora/root rw"
remove_cmdline_param $cmdline "root"
cmdline="root=nfs4:192.168.122.9:/ ip=ens3:dhcp rw"
remove_cmdline_param $cmdline "root"
The current implementation will get the wrong results:
"rd.lvm.lv=fedora/ rw"
":/ ip=ens3:dhcp rw"
After this patch we can get the correct results:
"rd.lvm.lv=fedora/root rw"
"ip=ens3:dhcp rw"
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
When kexec_crash_loaded does not exist, means kdump was not enabled in
kernel we get
$ kdumpctl status
cat: /sys/kernel/kexec_crash_loaded: No such file or directory
/usr/bin/kdumpctl: line 879: [: ==: unary operator expected
Kdump is not operational
After this patch:
$ kdumpctl status
Perhaps CONFIG_CRASH_DUMP is not enabled in kernel
Kdump is not operational
Signed-off-by: Pratyush Anand <panand@redhat.com>
Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Check the number of cpus for x86_64 kdump kernel to boot with.
We met an issue on x86_64: kdump runs out of vectors with the
default "nr_cpus=1", when requesting tons of irqs.
This patch detects such situation and warns users about the risk.
The total number of vectors percpu is 256 defined by x86 architecture.
The available vectors can be allocated to io devices percpu starts
from FIRST_EXTERNAL_VECTOR(see kernel code), and some high-numbered
ones are consumed by some system interrupts. As a result, the vectors
for io device are within [FIRST_EXTERNAL_VECTOR, FIRST_SYSTEM_VECTOR),
with one known exception, 0x80 within the range is reserved specially
as the syscall vector.
FIRST_EXTERNAL_VECTOR is invariably 32, while FIRST_SYSTEM_VECTOR can
vary between different kernel versions. E.g. FIRST_SYSTEM_VECTOR gets
0xef(with CONFIG_X86_LOCAL_APIC on)for linux-4.10, that is 17 vectors
reserved, considering it may increase in the future and the special
vectors, we use a flexible variance and assume there are 32 reserved
from FIRST_EXTERNAL_VECTOR. Then the max vectors for device interrupts
percpu is: (256-32)-32=192, we acquire the number N of device interrupts
from /proc/irq/, then the number of minimal cpus required is calculated:
(N + 192 - 1) / 192
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Since KDUMP_COMMANDLINE is a global variable, prepare_cmdline can
modify it directly instead of echoing back the result. This change
enables it to output messages.
Changed some coding styles.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
We maintained several kdump specific functions which are duplicate with the
similar versions in dracut, Dracut upstream splitted dracut init stuff from
dracut-functions.sh so that we can source it now.
Notes about kdump_get_presistent_dev:
Dracut now has a persistent_policy feature, for kdump when we dump to
raw disks we do not care the filesystem uuid and labels so we prefer to
search disk id instead. For raw disk set the persistent_policy before calling
get_persistent_dev ensure kdump logic still work.
Tested filesystem and raw dump in kvm guests.
[Xunlei: drop other functions other than get_persistent_dev.]
Signed-off-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
