kexec-tools/kdumpctl

1279 lines
29 KiB
Plaintext
Raw Normal View History

#!/bin/bash
2011-07-06 19:25:34 +00:00
KEXEC=/sbin/kexec
KDUMP_KERNELVER=""
KDUMP_COMMANDLINE=""
KEXEC_ARGS=""
KDUMP_CONFIG_FILE="/etc/kdump.conf"
MKDUMPRD="/sbin/mkdumprd -f"
DRACUT_MODULES_FILE="/usr/lib/dracut/modules.txt"
SAVE_PATH=/var/crash
SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa"
INITRD_CHECKSUM_LOCATION="/boot/.fadump_initrd_checksum"
DUMP_TARGET=""
DEFAULT_INITRD=""
DEFAULT_INITRD_BAK=""
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
TARGET_INITRD=""
FADUMP_REGISTER_SYS_NODE="/sys/kernel/fadump_registered"
#kdump shall be the default dump mode
DEFAULT_DUMP_MODE="kdump"
image_time=0
2011-07-06 19:25:34 +00:00
[[ $dracutbasedir ]] || dracutbasedir=/usr/lib/dracut
. $dracutbasedir/dracut-functions.sh
. /lib/kdump/kdump-lib.sh
2011-07-06 19:25:34 +00:00
standard_kexec_args="-p"
# Some default values in case /etc/sysconfig/kdump doesn't include
KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug"
2011-07-06 19:25:34 +00:00
if [ -f /etc/sysconfig/kdump ]; then
. /etc/sysconfig/kdump
fi
single_instance_lock()
{
local rc timeout=5
exec 9>/var/lock/kdump
if [ $? -ne 0 ]; then
echo "Create file lock failed"
exit 1
fi
flock -n 9
rc=$?
while [ $rc -ne 0 ]; do
echo "Another app is currently holding the kdump lock; waiting for it to exit..."
flock -w $timeout 9
rc=$?
done
}
determine_dump_mode()
{
# Check if firmware-assisted dump is enabled
# if yes, set the dump mode as fadump
if is_fadump_capable; then
echo "Dump mode is fadump"
DEFAULT_DUMP_MODE="fadump"
fi
}
# remove_cmdline_param <kernel cmdline> <param1> [<param2>] ... [<paramN>]
# Remove a list of kernel parameters from a given kernel cmdline and print the result.
# For each "arg" in the removing params list, "arg" and "arg=xxx" will be removed if exists.
remove_cmdline_param()
{
local cmdline=$1
shift
for arg in $@; do
cmdline=`echo $cmdline | \
sed -e "s/\b$arg=[^ ]*//g" \
-e "s/^$arg\b//g" \
-e "s/[[:space:]]$arg\b//g" \
-e "s/\s\+/ /g"`
done
echo $cmdline
}
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
#
kdumpctl: use "apicid" other than "initial apicid" 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>
2017-05-09 11:52:09 +00:00
# This function returns the "apicid" of the boot
# cpu (cpu 0) if present.
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
#
kdumpctl: use "apicid" other than "initial apicid" 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>
2017-05-09 11:52:09 +00:00
get_bootcpu_apicid()
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
{
awk ' \
BEGIN { CPU = "-1"; } \
$1=="processor" && $2==":" { CPU = $NF; } \
kdumpctl: use "apicid" other than "initial apicid" 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>
2017-05-09 11:52:09 +00:00
CPU=="0" && /^apicid/ { print $NF; } \
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
' \
/proc/cpuinfo
}
#
# This function appends argument "$2=$3" to string ($1) if not already present.
#
append_cmdline()
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
{
local cmdline=$1
local newstr=${cmdline/$2/""}
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
# unchanged str implies argument wasn't there
if [ "$cmdline" == "$newstr" ]; then
cmdline="${cmdline} ${2}=${3}"
fi
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
echo $cmdline
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
}
# This function performs a series of edits on the command line.
# Store the final result in global $KDUMP_COMMANDLINE.
prepare_cmdline()
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
{
local cmdline id
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
if [ -z "$KDUMP_COMMANDLINE" ]; then
cmdline=$(cat /proc/cmdline)
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
else
cmdline=${KDUMP_COMMANDLINE}
fi
# These params should always be removed
cmdline=$(remove_cmdline_param "$cmdline" crashkernel panic_on_warn)
# These params can be removed configurably
cmdline=$(remove_cmdline_param "$cmdline" ${KDUMP_COMMANDLINE_REMOVE})
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
# Always remove "root=X", as we now explicitly generate all kinds
# of dump target mount information including root fs.
#
# We do this before KDUMP_COMMANDLINE_APPEND, if one really cares
# about it(e.g. for debug purpose), then can pass "root=X" using
# KDUMP_COMMANDLINE_APPEND.
cmdline=$(remove_cmdline_param "$cmdline" root)
# With the help of "--hostonly-cmdline", we can avoid some interitage.
cmdline=$(remove_cmdline_param "$cmdline" rd.lvm.lv rd.luks.uuid rd.dm.uuid rd.md.uuid fcoe)
kdumpctl: Remove 'netroot' and 'iscsi initiator' entries from kdump cmdline In a iSCSI multipath environment (which uses iSCSI software initiator and target environment) when the vmcore file is saved on the target, kdump always fails to establish a iSCSI session and also fails to collect dump due to duplicate entries for 'netroot' and 'iscsi initiator' in the kdump bootargs: # echo c > /proc/sysrq-trigger [83471.842707] SysRq : Trigger a crash [83471.843233] BUG: unable to handle kernel NULL pointer dereference at (null) [83471.844155] IP: [<ffffffffac82ed16>] sysrq_handle_crash+0x16/0x20 [83471.844931] PGD 800000023f710067 PUD 229fd6067 PMD 0 [83471.845655] Oops: 0002 [#1] SMP <snip..> [83471.861889] Call Trace: [83471.862162] [<ffffffffac82f53d>] __handle_sysrq+0x10d/0x170 [83471.862771] [<ffffffffac82f9af>] write_sysrq_trigger+0x2f/0x40 [83471.863405] [<ffffffffac690630>] proc_reg_write+0x40/0x80 [83471.863984] [<ffffffffac61acd0>] vfs_write+0xc0/0x1f0 [83471.864536] [<ffffffffac61baff>] SyS_write+0x7f/0xf0 [83471.865075] [<ffffffffacb1f7d5>] system_call_fastpath+0x1c/0x21 [83471.865714] Code: eb 9b 45 01 f4 45 39 65 34 75 e5 4c 89 ef e8 e2 f7 ff ff eb db 0f 1f 44 00 00 55 48 89 e5 c7 05 41 47 81 00 01 00 00 00 0f ae f8 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 be [83471.868888] RIP [<ffffffffac82ed16>] sysrq_handle_crash+0x16/0x20 [83471.869700] RSP <ffff9e7fe77b7e58> [83471.870074] CR2: 0000000000000000 <snip..> Starting Login iSCSI Target iqn.2014-08.com.example:t1... [ OK ] Stopped Login iSCSI Target iqn.2014-08.com.example:t1. Starting Login iSCSI Target iqn.2014-08.com.example:t1... [ 6.607051] scsi host2: iSCSI Initiator over TCP/IP [FAILED] Failed to start Login iSCSI Target iqn.2014-08.com.example:t1. See 'systemctl status "iscsistart_\\x40...com.example:t1.service"' for details. [ 126.572911] dracut-initqueue[243]: Warning: dracut-initqueue timeout - starting timeout scripts Stopping Open-iSCSI... [ OK ] Stopped Open-iSCSI. Starting Open-iSCSI... [ OK ] Started Open-iSCSI. Starting Login iSCSI Target iqn.2014-08.com.example:t1... [ OK ] Stopped Login iSCSI Target iqn.2014-08.com.example:t1. Starting Login iSCSI Target iqn.2014-08.com.example:t1... [ 131.095897] scsi host3: iSCSI Initiator over TCP/IP [FAILED] Failed to start Login iSCSI Target iqn.2014-08.com.example:t1. See 'systemctl status "iscsistart_\\x40...com.example:t1.service"' for details. [ 251.085029] dracut-initqueue[243]: Warning: dracut-initqueue timeout - starting timeout scripts [ 251.594554] dracut-initqueue[243]: Warning: dracut-initqueue timeout - starting timeout scripts <snip..> This patch fixes the same by removing the 'netroot', 'rd.iscsi.initiator' and 'iscsi_initiator' entries from the kdump boot cmdline. One reason why this is safe is our kdump target setup does not depend on 1st kernel inherited cmdline params now since the work we dropped root dependency. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Acked-by: Dave Young <dyoung@redhat.com>
2018-05-21 05:01:46 +00:00
# Remove netroot, rd.iscsi.initiator and iscsi_initiator since
# we get duplicate entries for the same in case iscsi code adds
# it as well.
cmdline=$(remove_cmdline_param "$cmdline" netroot rd.iscsi.initiator iscsi_initiator)
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
id=$(get_bootcpu_apicid)
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
if [ ! -z ${id} ] ; then
cmdline=$(append_cmdline "${cmdline}" disable_cpu_apicid ${id})
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
fi
KDUMP_COMMANDLINE=$cmdline
kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel == Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-21 01:09:30 +00:00
}
save_core()
2011-07-06 19:25:34 +00:00
{
coredir="/var/crash/`date +"%Y-%m-%d-%H:%M"`"
mkdir -p $coredir
cp --sparse=always /proc/vmcore $coredir/vmcore-incomplete
if [ $? == 0 ]; then
mv $coredir/vmcore-incomplete $coredir/vmcore
echo "saved a vmcore to $coredir"
2011-07-06 19:25:34 +00:00
else
echo "failed to save a vmcore to $coredir" >&2
2011-07-06 19:25:34 +00:00
fi
# pass the dmesg to Abrt tool if exists, in order
# to collect the kernel oops message.
# https://fedorahosted.org/abrt/
if [ -x /usr/bin/dumpoops ]; then
makedumpfile --dump-dmesg $coredir/vmcore $coredir/dmesg >/dev/null 2>&1
dumpoops -d $coredir/dmesg >/dev/null 2>&1
if [ $? == 0 ]; then
echo "kernel oops has been collected by abrt tool"
2011-07-06 19:25:34 +00:00
fi
fi
}
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
rebuild_fadump_initrd()
{
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
local target_initrd_tmp
# this file tells the initrd is fadump enabled
touch /tmp/fadump.initramfs
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
target_initrd_tmp="$TARGET_INITRD.tmp"
$MKDUMPRD $target_initrd_tmp --rebuild $TARGET_INITRD --kver $kdump_kver \
-i /tmp/fadump.initramfs /etc/fadump.initramfs
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
if [ $? != 0 ]; then
echo "mkdumprd: failed to rebuild initrd with fadump support" >&2
rm -f /tmp/fadump.initramfs
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
return 1
fi
rm -f /tmp/fadump.initramfs
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
# updating fadump initrd
mv $target_initrd_tmp $TARGET_INITRD
sync
return 0
}
rebuild_kdump_initrd()
{
$MKDUMPRD $TARGET_INITRD $kdump_kver
if [ $? != 0 ]; then
echo "mkdumprd: failed to make kdump initrd" >&2
return 1
fi
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
return 0
}
rebuild_initrd()
{
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
rebuild_fadump_initrd
else
rebuild_kdump_initrd
fi
return $?
}
#$1: the files to be checked with IFS=' '
check_exist()
{
for file in $1; do
if [ ! -f "$file" ]; then
echo -n "Error: $file not found."; echo
return 1
fi
done
}
#$1: the files to be checked with IFS=' '
check_executable()
{
for file in $1; do
if [ ! -x "$file" ]; then
echo -n "Error: $file is not executable."; echo
return 1
fi
done
}
backup_default_initrd()
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
{
if [ ! -f "$DEFAULT_INITRD" ]; then
return
fi
if [ ! -e $DEFAULT_INITRD_BAK ]; then
echo "Backing up $DEFAULT_INITRD before rebuild."
# save checksum to verify before restoring
sha1sum $DEFAULT_INITRD > $INITRD_CHECKSUM_LOCATION
cp $DEFAULT_INITRD $DEFAULT_INITRD_BAK
if [ $? -ne 0 ]; then
echo "WARNING: failed to backup $DEFAULT_INITRD."
rm -f $DEFAULT_INITRD_BAK
fi
fi
}
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
restore_default_initrd()
{
# If a backup initrd exists, we must be switching back from
# fadump to kdump. Restore the original default initrd.
if [ -f $DEFAULT_INITRD_BAK ] && [ -f $INITRD_CHECKSUM_LOCATION ]; then
# verify checksum before restoring
backup_checksum=`sha1sum $DEFAULT_INITRD_BAK | awk '{ print $1 }'`
default_checksum=`cat $INITRD_CHECKSUM_LOCATION | awk '{ print $1 }'`
if [ "$default_checksum" != "$backup_checksum" ]; then
echo "WARNING: checksum mismatch! Can't restore original initrd.."
else
rm -f $INITRD_CHECKSUM_LOCATION
mv $DEFAULT_INITRD_BAK $DEFAULT_INITRD
if [[ $? -eq 0 ]]; then
echo -n "Restoring original initrd as fadump mode "
echo "is disabled."
sync
fi
fi
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
fi
}
check_config()
{
local nr
2016-08-26 03:23:35 +00:00
nr=$(awk 'BEGIN{cnt=0} /^raw|^ssh[[:blank:]]|^nfs|^ext[234]|^xfs|^btrfs|^minix|^dracut_args .*\-\-mount/{cnt++} END{print cnt}' $KDUMP_CONFIG_FILE)
[ $nr -gt 1 ] && {
echo "More than one dump targets specified."
return 1
}
2016-08-26 03:23:35 +00:00
nr=$(grep "^dracut_args .*\-\-mount" $KDUMP_CONFIG_FILE | grep -o "\-\-mount" | wc -l)
[ $nr -gt 1 ] && {
echo "Multiple mount targets specified in one \"dracut_args\"."
return 1
}
# Check if we have any leading spaces (or tabs) before the
# variable name in the kdump conf file
if grep -E -q '^[[:blank:]]+[a-z]' $KDUMP_CONFIG_FILE; then
echo "No whitespaces are allowed before a kdump option name in $KDUMP_CONFIG_FILE"
return 1
fi
while read config_opt config_val; do
case "$config_opt" in
\#* | "")
;;
raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes)
# remove inline comments after the end of a directive.
config_val=$(strip_comments $config_val)
[ -z "$config_val" ] && {
echo "Invalid kdump config value for option $config_opt."
return 1;
}
;;
net|options|link_delay|disk_timeout|debug_mem_level|blacklist)
echo "Deprecated kdump config option: $config_opt. Refer to kdump.conf manpage for alternatives."
return 1
;;
*)
echo "Invalid kdump config option $config_opt"
return 1;
;;
esac
done < $KDUMP_CONFIG_FILE
check_default_config || return 1
check_fence_kdump_config || return 1
return 0
}
# get_pcs_cluster_modified_files <image timestamp>
# return list of modified file for fence_kdump modified in Pacemaker cluster
get_pcs_cluster_modified_files()
{
local time_stamp
local modified_files
is_generic_fence_kdump && return 1
is_pcs_fence_kdump || return 1
time_stamp=`pcs cluster cib | xmllint --xpath 'string(/cib/@cib-last-written)' - | \
xargs -0 date +%s --date`
if [ -n $time_stamp -a $time_stamp -gt $image_time ]; then
modified_files="cluster-cib"
fi
if [ -f $FENCE_KDUMP_CONFIG_FILE ]; then
time_stamp=`stat -c "%Y" $FENCE_KDUMP_CONFIG_FILE`
if [ "$time_stamp" -gt "$image_time" ]; then
modified_files="$modified_files $FENCE_KDUMP_CONFIG_FILE"
fi
fi
echo $modified_files
}
check_boot_dir()
{
#If user specify a boot dir for kdump kernel, let's use it. Otherwise
#check whether it's a atomic host. If yes parse the subdirectory under
#/boot; If not just find it under /boot.
[ -n "$KDUMP_BOOTDIR" ] && return
if ! is_atomic || [ "$(uname -m)" = "s390x" ]; then
KDUMP_BOOTDIR="/boot"
else
eval $(cat /proc/cmdline| grep "BOOT_IMAGE" | cut -d' ' -f1)
KDUMP_BOOTDIR="/boot"$(dirname $BOOT_IMAGE)
fi
}
setup_initrd()
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
{
DEFAULT_INITRD="${KDUMP_BOOTDIR}/initramfs-`uname -r`.img"
DEFAULT_INITRD_BAK="${KDUMP_BOOTDIR}/.initramfs-`uname -r`.img.default"
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
TARGET_INITRD="$DEFAULT_INITRD"
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
if [ ! -s "$TARGET_INITRD" ]; then
echo "Error: No initrd found to rebuild!"
return 1
fi
else
TARGET_INITRD="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}kdump.img"
fi
}
check_files_modified()
{
local modified_files=""
#also rebuild when Pacemaker cluster conf is changed and fence kdump is enabled.
modified_files=$(get_pcs_cluster_modified_files)
EXTRA_BINS=`grep ^kdump_post $KDUMP_CONFIG_FILE | cut -d\ -f2`
CHECK_FILES=`grep ^kdump_pre $KDUMP_CONFIG_FILE | cut -d\ -f2`
CORE_COLLECTOR=`grep ^core_collector $KDUMP_CONFIG_FILE | cut -d\ -f2`
CORE_COLLECTOR=`type -P $CORE_COLLECTOR`
EXTRA_BINS="$EXTRA_BINS $CHECK_FILES"
CHECK_FILES=`grep ^extra_bins $KDUMP_CONFIG_FILE | cut -d\ -f2-`
EXTRA_BINS="$EXTRA_BINS $CHECK_FILES"
files="$KDUMP_CONFIG_FILE $kdump_kernel $EXTRA_BINS $CORE_COLLECTOR"
[[ -e /etc/fstab ]] && files="$files /etc/fstab"
check_exist "$files" && check_executable "$EXTRA_BINS"
[ $? -ne 0 ] && return 2
for file in $files; do
time_stamp=`stat -c "%Y" $file`
if [ "$time_stamp" -gt "$image_time" ]; then
modified_files="$modified_files $file"
fi
done
if [ -n "$modified_files" ]; then
echo "Detected change(s) in the following file(s):"
echo -n " "; echo "$modified_files" | sed 's/\s/\n /g'
return 1
fi
return 0
}
kdumpctl: force rebuild in case of file system is modified kdumpctl passes --device argument if dump target is a raw device. It passes --mount argument if dump target is either mounted as nfs or as a bulk device. When dump target device is a root device then it does not pass any of the above two arguments. After kdumpctl restart, if there is any change in file system which needs different dracut arguments, then initramfs must be rebuild. Modification in filesystem for a raw target does not affect dracut arguments. So, we do not consider to check any modification if raw target was specified in kdump.conf. We might need to change dracut arguments if there is some changes in nfs and ssh target related files. However, we do not consider them in this patch. We mainly consider changes in bulk target specified in kdump.conf. We also consider changes in bulk and nfs file system, if there was no dump target specified in kdump.conf but dump path is mounting such file systems. So the initramfs must be rebuild if, either dump target's persistent path or it's mount point or its file system type changes. If there is no dump target specified then, both dump path and root path must mount same device, otherwise rebuild should be triggered. Some of the examples when we can need a rebuild: -- "dump target" is specified as one of ext[234], xfs or btrfs. But after kdump initramfs building its UUID is changed by reformatting. -- "dump target" is specified as file system type fs1 (say ext3). But after kdump initramfs building, user change it to fs2 (say ext4), probably by a mkfs.ext4 executing on the target device. -- "dump target" is not specified, but "dump path" mounts a device which is different than device for root path and either UUID or file system type is modified after kdump initramfs build. -- "dump target" is not specified, but "dump path" mounts a nfs device and nfs host path changes after kdump initramfs build. Some testing: Initial conditions: -- No dump target specified -- dump path (/var/crash) and root(/) are on same device -- kdumpctl was already executed once after last modification in /etc/kdump.conf # kdumpctl restart No rebuild # mkfs.ext2 /dev/md0;mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/md0; # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/mapper/fedora-swap # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.btrfs /dev/mapper/fedora-swap -f # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount /dev/mapper/fedora-swap /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.minix /dev/md0 # mount /dev/md0 /var/crash/; kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash;mount 192.168.1.12:/nfsroot /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" Added "raw /dev/md0" in /etc/kdump.conf # kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # mkfs.ext4 /dev/md0 ;kdumpctl restart No rebuild Added "ext4 /dev/md0" in /etc/kdump.conf # mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # umount /mnt;mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" Most of the credits for this patch goes to Xunlei Pang <xpang@redhat.com> for suggesting several improvements. Signed-off-by: Pratyush Anand <panand@redhat.com> Acked-by: Xunlei Pang <xlpang@redhat.com> Acked-by: Baoquan He <xlpang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com>
2016-05-09 08:17:55 +00:00
check_dump_fs_modified()
{
local _old_dev _old_mntpoint _old_fstype
local _new_dev _new_mntpoint _new_fstype
local _target _path _dracut_args
2016-08-26 03:23:35 +00:00
# No need to check in case of mount target specified via "dracut_args".
if is_mount_in_dracut_args; then
return 0
fi
kdumpctl: force rebuild in case of file system is modified kdumpctl passes --device argument if dump target is a raw device. It passes --mount argument if dump target is either mounted as nfs or as a bulk device. When dump target device is a root device then it does not pass any of the above two arguments. After kdumpctl restart, if there is any change in file system which needs different dracut arguments, then initramfs must be rebuild. Modification in filesystem for a raw target does not affect dracut arguments. So, we do not consider to check any modification if raw target was specified in kdump.conf. We might need to change dracut arguments if there is some changes in nfs and ssh target related files. However, we do not consider them in this patch. We mainly consider changes in bulk target specified in kdump.conf. We also consider changes in bulk and nfs file system, if there was no dump target specified in kdump.conf but dump path is mounting such file systems. So the initramfs must be rebuild if, either dump target's persistent path or it's mount point or its file system type changes. If there is no dump target specified then, both dump path and root path must mount same device, otherwise rebuild should be triggered. Some of the examples when we can need a rebuild: -- "dump target" is specified as one of ext[234], xfs or btrfs. But after kdump initramfs building its UUID is changed by reformatting. -- "dump target" is specified as file system type fs1 (say ext3). But after kdump initramfs building, user change it to fs2 (say ext4), probably by a mkfs.ext4 executing on the target device. -- "dump target" is not specified, but "dump path" mounts a device which is different than device for root path and either UUID or file system type is modified after kdump initramfs build. -- "dump target" is not specified, but "dump path" mounts a nfs device and nfs host path changes after kdump initramfs build. Some testing: Initial conditions: -- No dump target specified -- dump path (/var/crash) and root(/) are on same device -- kdumpctl was already executed once after last modification in /etc/kdump.conf # kdumpctl restart No rebuild # mkfs.ext2 /dev/md0;mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/md0; # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/mapper/fedora-swap # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.btrfs /dev/mapper/fedora-swap -f # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount /dev/mapper/fedora-swap /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.minix /dev/md0 # mount /dev/md0 /var/crash/; kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash;mount 192.168.1.12:/nfsroot /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" Added "raw /dev/md0" in /etc/kdump.conf # kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # mkfs.ext4 /dev/md0 ;kdumpctl restart No rebuild Added "ext4 /dev/md0" in /etc/kdump.conf # mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # umount /mnt;mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" Most of the credits for this patch goes to Xunlei Pang <xpang@redhat.com> for suggesting several improvements. Signed-off-by: Pratyush Anand <panand@redhat.com> Acked-by: Xunlei Pang <xlpang@redhat.com> Acked-by: Baoquan He <xlpang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com>
2016-05-09 08:17:55 +00:00
# No need to check in case of raw target.
# Currently we do not check also if ssh/nfs target is specified
if is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target; then
return 0
fi
_target=$(get_user_configured_dump_disk)
if [[ -n "$_target" ]]; then
_target=$(to_dev_name $_target)
_new_fstype=$(blkid $_target | awk -F"TYPE=" '{print $2}' | cut -d '"' -f 2)
else
_path=$(get_save_path)
_target=$(get_target_from_path $_path)
_target=$(to_dev_name $_target)
_new_fstype=$(get_fs_type_from_target $_target)
kdumpctl: force rebuild in case of file system is modified kdumpctl passes --device argument if dump target is a raw device. It passes --mount argument if dump target is either mounted as nfs or as a bulk device. When dump target device is a root device then it does not pass any of the above two arguments. After kdumpctl restart, if there is any change in file system which needs different dracut arguments, then initramfs must be rebuild. Modification in filesystem for a raw target does not affect dracut arguments. So, we do not consider to check any modification if raw target was specified in kdump.conf. We might need to change dracut arguments if there is some changes in nfs and ssh target related files. However, we do not consider them in this patch. We mainly consider changes in bulk target specified in kdump.conf. We also consider changes in bulk and nfs file system, if there was no dump target specified in kdump.conf but dump path is mounting such file systems. So the initramfs must be rebuild if, either dump target's persistent path or it's mount point or its file system type changes. If there is no dump target specified then, both dump path and root path must mount same device, otherwise rebuild should be triggered. Some of the examples when we can need a rebuild: -- "dump target" is specified as one of ext[234], xfs or btrfs. But after kdump initramfs building its UUID is changed by reformatting. -- "dump target" is specified as file system type fs1 (say ext3). But after kdump initramfs building, user change it to fs2 (say ext4), probably by a mkfs.ext4 executing on the target device. -- "dump target" is not specified, but "dump path" mounts a device which is different than device for root path and either UUID or file system type is modified after kdump initramfs build. -- "dump target" is not specified, but "dump path" mounts a nfs device and nfs host path changes after kdump initramfs build. Some testing: Initial conditions: -- No dump target specified -- dump path (/var/crash) and root(/) are on same device -- kdumpctl was already executed once after last modification in /etc/kdump.conf # kdumpctl restart No rebuild # mkfs.ext2 /dev/md0;mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/md0; # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/mapper/fedora-swap # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.btrfs /dev/mapper/fedora-swap -f # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount /dev/mapper/fedora-swap /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.minix /dev/md0 # mount /dev/md0 /var/crash/; kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash;mount 192.168.1.12:/nfsroot /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" Added "raw /dev/md0" in /etc/kdump.conf # kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # mkfs.ext4 /dev/md0 ;kdumpctl restart No rebuild Added "ext4 /dev/md0" in /etc/kdump.conf # mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # umount /mnt;mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" Most of the credits for this patch goes to Xunlei Pang <xpang@redhat.com> for suggesting several improvements. Signed-off-by: Pratyush Anand <panand@redhat.com> Acked-by: Xunlei Pang <xlpang@redhat.com> Acked-by: Baoquan He <xlpang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com>
2016-05-09 08:17:55 +00:00
if [[ -z "$_target" || -z "$_new_fstype" ]];then
echo "Dump path $_path does not exist"
return 2
fi
fi
if [[ $(expr substr $_new_fstype 1 3) = "nfs" ]];then
_new_dev=$_target
else
_new_dev=$(get_persistent_dev $_target)
if [ -z "$_new_dev" ]; then
echo "Get persistent device name failed"
return 2
fi
kdumpctl: force rebuild in case of file system is modified kdumpctl passes --device argument if dump target is a raw device. It passes --mount argument if dump target is either mounted as nfs or as a bulk device. When dump target device is a root device then it does not pass any of the above two arguments. After kdumpctl restart, if there is any change in file system which needs different dracut arguments, then initramfs must be rebuild. Modification in filesystem for a raw target does not affect dracut arguments. So, we do not consider to check any modification if raw target was specified in kdump.conf. We might need to change dracut arguments if there is some changes in nfs and ssh target related files. However, we do not consider them in this patch. We mainly consider changes in bulk target specified in kdump.conf. We also consider changes in bulk and nfs file system, if there was no dump target specified in kdump.conf but dump path is mounting such file systems. So the initramfs must be rebuild if, either dump target's persistent path or it's mount point or its file system type changes. If there is no dump target specified then, both dump path and root path must mount same device, otherwise rebuild should be triggered. Some of the examples when we can need a rebuild: -- "dump target" is specified as one of ext[234], xfs or btrfs. But after kdump initramfs building its UUID is changed by reformatting. -- "dump target" is specified as file system type fs1 (say ext3). But after kdump initramfs building, user change it to fs2 (say ext4), probably by a mkfs.ext4 executing on the target device. -- "dump target" is not specified, but "dump path" mounts a device which is different than device for root path and either UUID or file system type is modified after kdump initramfs build. -- "dump target" is not specified, but "dump path" mounts a nfs device and nfs host path changes after kdump initramfs build. Some testing: Initial conditions: -- No dump target specified -- dump path (/var/crash) and root(/) are on same device -- kdumpctl was already executed once after last modification in /etc/kdump.conf # kdumpctl restart No rebuild # mkfs.ext2 /dev/md0;mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/md0; # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/mapper/fedora-swap # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.btrfs /dev/mapper/fedora-swap -f # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount /dev/mapper/fedora-swap /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.minix /dev/md0 # mount /dev/md0 /var/crash/; kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash;mount 192.168.1.12:/nfsroot /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" Added "raw /dev/md0" in /etc/kdump.conf # kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # mkfs.ext4 /dev/md0 ;kdumpctl restart No rebuild Added "ext4 /dev/md0" in /etc/kdump.conf # mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # umount /mnt;mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" Most of the credits for this patch goes to Xunlei Pang <xpang@redhat.com> for suggesting several improvements. Signed-off-by: Pratyush Anand <panand@redhat.com> Acked-by: Xunlei Pang <xlpang@redhat.com> Acked-by: Baoquan He <xlpang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com>
2016-05-09 08:17:55 +00:00
fi
if ! findmnt $_target >/dev/null; then
echo "Dump target $_target is probably not mounted."
return 2
fi
if [[ "$_target" = "$(get_root_fs_device)" ]]; then
_new_mntpoint="/sysroot"
else
_new_mntpoint="/kdumproot/$(get_mntpoint_from_target $_target)"
fi
kdumpctl: force rebuild in case of file system is modified kdumpctl passes --device argument if dump target is a raw device. It passes --mount argument if dump target is either mounted as nfs or as a bulk device. When dump target device is a root device then it does not pass any of the above two arguments. After kdumpctl restart, if there is any change in file system which needs different dracut arguments, then initramfs must be rebuild. Modification in filesystem for a raw target does not affect dracut arguments. So, we do not consider to check any modification if raw target was specified in kdump.conf. We might need to change dracut arguments if there is some changes in nfs and ssh target related files. However, we do not consider them in this patch. We mainly consider changes in bulk target specified in kdump.conf. We also consider changes in bulk and nfs file system, if there was no dump target specified in kdump.conf but dump path is mounting such file systems. So the initramfs must be rebuild if, either dump target's persistent path or it's mount point or its file system type changes. If there is no dump target specified then, both dump path and root path must mount same device, otherwise rebuild should be triggered. Some of the examples when we can need a rebuild: -- "dump target" is specified as one of ext[234], xfs or btrfs. But after kdump initramfs building its UUID is changed by reformatting. -- "dump target" is specified as file system type fs1 (say ext3). But after kdump initramfs building, user change it to fs2 (say ext4), probably by a mkfs.ext4 executing on the target device. -- "dump target" is not specified, but "dump path" mounts a device which is different than device for root path and either UUID or file system type is modified after kdump initramfs build. -- "dump target" is not specified, but "dump path" mounts a nfs device and nfs host path changes after kdump initramfs build. Some testing: Initial conditions: -- No dump target specified -- dump path (/var/crash) and root(/) are on same device -- kdumpctl was already executed once after last modification in /etc/kdump.conf # kdumpctl restart No rebuild # mkfs.ext2 /dev/md0;mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/md0; # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/mapper/fedora-swap # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.btrfs /dev/mapper/fedora-swap -f # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount /dev/mapper/fedora-swap /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.minix /dev/md0 # mount /dev/md0 /var/crash/; kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash;mount 192.168.1.12:/nfsroot /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" Added "raw /dev/md0" in /etc/kdump.conf # kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # mkfs.ext4 /dev/md0 ;kdumpctl restart No rebuild Added "ext4 /dev/md0" in /etc/kdump.conf # mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # umount /mnt;mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" Most of the credits for this patch goes to Xunlei Pang <xpang@redhat.com> for suggesting several improvements. Signed-off-by: Pratyush Anand <panand@redhat.com> Acked-by: Xunlei Pang <xlpang@redhat.com> Acked-by: Baoquan He <xlpang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com>
2016-05-09 08:17:55 +00:00
_dracut_args=$(lsinitrd $TARGET_INITRD -f usr/lib/dracut/build-parameter.txt)
kdumpctl: force rebuild in case of file system is modified kdumpctl passes --device argument if dump target is a raw device. It passes --mount argument if dump target is either mounted as nfs or as a bulk device. When dump target device is a root device then it does not pass any of the above two arguments. After kdumpctl restart, if there is any change in file system which needs different dracut arguments, then initramfs must be rebuild. Modification in filesystem for a raw target does not affect dracut arguments. So, we do not consider to check any modification if raw target was specified in kdump.conf. We might need to change dracut arguments if there is some changes in nfs and ssh target related files. However, we do not consider them in this patch. We mainly consider changes in bulk target specified in kdump.conf. We also consider changes in bulk and nfs file system, if there was no dump target specified in kdump.conf but dump path is mounting such file systems. So the initramfs must be rebuild if, either dump target's persistent path or it's mount point or its file system type changes. If there is no dump target specified then, both dump path and root path must mount same device, otherwise rebuild should be triggered. Some of the examples when we can need a rebuild: -- "dump target" is specified as one of ext[234], xfs or btrfs. But after kdump initramfs building its UUID is changed by reformatting. -- "dump target" is specified as file system type fs1 (say ext3). But after kdump initramfs building, user change it to fs2 (say ext4), probably by a mkfs.ext4 executing on the target device. -- "dump target" is not specified, but "dump path" mounts a device which is different than device for root path and either UUID or file system type is modified after kdump initramfs build. -- "dump target" is not specified, but "dump path" mounts a nfs device and nfs host path changes after kdump initramfs build. Some testing: Initial conditions: -- No dump target specified -- dump path (/var/crash) and root(/) are on same device -- kdumpctl was already executed once after last modification in /etc/kdump.conf # kdumpctl restart No rebuild # mkfs.ext2 /dev/md0;mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/md0; # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/mapper/fedora-swap # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.btrfs /dev/mapper/fedora-swap -f # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount /dev/mapper/fedora-swap /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.minix /dev/md0 # mount /dev/md0 /var/crash/; kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash;mount 192.168.1.12:/nfsroot /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" Added "raw /dev/md0" in /etc/kdump.conf # kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # mkfs.ext4 /dev/md0 ;kdumpctl restart No rebuild Added "ext4 /dev/md0" in /etc/kdump.conf # mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # umount /mnt;mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" Most of the credits for this patch goes to Xunlei Pang <xpang@redhat.com> for suggesting several improvements. Signed-off-by: Pratyush Anand <panand@redhat.com> Acked-by: Xunlei Pang <xlpang@redhat.com> Acked-by: Baoquan He <xlpang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com>
2016-05-09 08:17:55 +00:00
if [[ -z "$_dracut_args" ]];then
echo "Warning: No dracut arguments found in initrd"
return 0
fi
# if --mount argument present then match old and new target, mount
# point and file system. If any of them mismatches then rebuild
echo $_dracut_args | grep "\-\-mount" &> /dev/null
if [[ $? -eq 0 ]];then
set -- $(echo $_dracut_args | awk -F "--mount '" '{print $2}' | cut -d' ' -f1,2,3)
_old_dev=$1
_old_mntpoint=$2
_old_fstype=$3
[[ $_new_dev = $_old_dev && $_new_mntpoint = $_old_mntpoint && $_new_fstype = $_old_fstype ]] && return 0
# otherwise rebuild if target device is not a root device
else
[[ "$_target" = "$(get_root_fs_device)" ]] && return 0
fi
echo "Detected change in File System"
return 1
}
check_wdt_modified()
{
local -A _drivers
local _alldrivers _active _wdtdrv _wdtppath _dir
local wd_old wd_new
is_wdt_mod_omitted
[[ $? -eq 0 ]] && return 0
[[ -d /sys/class/watchdog/ ]] || return 0
# Copied logic from dracut 04watchdog/module-setup.sh::installkernel()
for _dir in /sys/class/watchdog/*; do
[[ -d "$_dir" ]] || continue
[[ -f "$_dir/state" ]] || continue
_active=$(< "$_dir/state")
[[ "$_active" = "active" ]] || continue
# device/modalias will return driver of this device
_wdtdrv=$(< "$_dir/device/modalias")
# There can be more than one module represented by same
# modalias. Currently load all of them.
# TODO: Need to find a way to avoid any unwanted module
# represented by modalias
_wdtdrv=$(modprobe --set-version "$kdump_kver" -R $_wdtdrv 2>/dev/null)
if [[ $_wdtdrv ]]; then
for i in $_wdtdrv; do
_drivers[$i]=1
done
fi
# however in some cases, we also need to check that if there is
# a specific driver for the parent bus/device. In such cases
# we also need to enable driver for parent bus/device.
_wdtppath=$(readlink -f "$_dir/device")
while [[ -d "$_wdtppath" ]] && [[ "$_wdtppath" != "/sys" ]]; do
_wdtppath=$(readlink -f "$_wdtppath/..")
[[ -f "$_wdtppath/modalias" ]] || continue
_wdtdrv=$(< "$_wdtppath/modalias")
_wdtdrv=$(modprobe --set-version "$kdump_kver" -R $_wdtdrv 2>/dev/null)
if [[ $_wdtdrv ]]; then
for i in $_wdtdrv; do
_drivers[$i]=1
done
fi
done
done
# ensure that watchdog module is loaded as early as possible
_alldrivers="${!_drivers[*]}"
[[ $_alldrivers ]] && wd_new="rd.driver.pre=${_alldrivers// /,}"
wd_old=$(lsinitrd $TARGET_INITRD -f etc/cmdline.d/00-watchdog.conf)
[[ "$wd_old" = "$wd_new" ]] && return 0
return 1
}
# returns 0 if system is not modified
# returns 1 if system is modified
# returns 2 if system modification is invalid
check_system_modified()
{
local ret
[[ -f $TARGET_INITRD ]] || return 1
check_files_modified
ret=$?
if [ $ret -ne 0 ]; then
return $ret
fi
kdumpctl: force rebuild in case of file system is modified kdumpctl passes --device argument if dump target is a raw device. It passes --mount argument if dump target is either mounted as nfs or as a bulk device. When dump target device is a root device then it does not pass any of the above two arguments. After kdumpctl restart, if there is any change in file system which needs different dracut arguments, then initramfs must be rebuild. Modification in filesystem for a raw target does not affect dracut arguments. So, we do not consider to check any modification if raw target was specified in kdump.conf. We might need to change dracut arguments if there is some changes in nfs and ssh target related files. However, we do not consider them in this patch. We mainly consider changes in bulk target specified in kdump.conf. We also consider changes in bulk and nfs file system, if there was no dump target specified in kdump.conf but dump path is mounting such file systems. So the initramfs must be rebuild if, either dump target's persistent path or it's mount point or its file system type changes. If there is no dump target specified then, both dump path and root path must mount same device, otherwise rebuild should be triggered. Some of the examples when we can need a rebuild: -- "dump target" is specified as one of ext[234], xfs or btrfs. But after kdump initramfs building its UUID is changed by reformatting. -- "dump target" is specified as file system type fs1 (say ext3). But after kdump initramfs building, user change it to fs2 (say ext4), probably by a mkfs.ext4 executing on the target device. -- "dump target" is not specified, but "dump path" mounts a device which is different than device for root path and either UUID or file system type is modified after kdump initramfs build. -- "dump target" is not specified, but "dump path" mounts a nfs device and nfs host path changes after kdump initramfs build. Some testing: Initial conditions: -- No dump target specified -- dump path (/var/crash) and root(/) are on same device -- kdumpctl was already executed once after last modification in /etc/kdump.conf # kdumpctl restart No rebuild # mkfs.ext2 /dev/md0;mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/md0; # mount /dev/md0 /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.ext4 /dev/mapper/fedora-swap # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.btrfs /dev/mapper/fedora-swap -f # mount /dev/mapper/fedora-swap /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount /dev/mapper/fedora-swap /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash;mkfs.minix /dev/md0 # mount /dev/md0 /var/crash/; kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" # kdumpctl restart No rebuild # umount /var/crash;mount 192.168.1.12:/nfsroot /var/crash/ # kdumpctl restart Rebuilt because "Detected change in File System" # umount /var/crash/;kdumpctl restart Rebuilt because "Detected change in File System" Added "raw /dev/md0" in /etc/kdump.conf # kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # mkfs.ext4 /dev/md0 ;kdumpctl restart No rebuild Added "ext4 /dev/md0" in /etc/kdump.conf # mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" # umount /mnt;mkfs.ext4 /dev/md0;mount /dev/md0 /mnt # mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart Rebuilt because "Detected change in /etc/kdump.conf" Most of the credits for this patch goes to Xunlei Pang <xpang@redhat.com> for suggesting several improvements. Signed-off-by: Pratyush Anand <panand@redhat.com> Acked-by: Xunlei Pang <xlpang@redhat.com> Acked-by: Baoquan He <xlpang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com>
2016-05-09 08:17:55 +00:00
check_dump_fs_modified
ret=$?
if [ $ret -ne 0 ]; then
return $ret
fi
check_wdt_modified
if [ $? -ne 0 ]; then
echo "Detected change in watchdog state"
return 1
fi
return 0
}
check_rebuild()
2011-07-06 19:25:34 +00:00
{
local extra_modules
local capture_capable_initrd="1"
local _force_rebuild force_rebuild="0"
local _force_no_rebuild force_no_rebuild="0"
local ret system_modified="0"
check_boot_dir
2011-07-06 19:25:34 +00:00
if [ -z "$KDUMP_KERNELVER" ]; then
2011-07-25 10:04:32 +00:00
kdump_kver=`uname -r`
2011-07-06 19:25:34 +00:00
else
kdump_kver=$KDUMP_KERNELVER
fi
kdump_kernel="${KDUMP_BOOTDIR}/${KDUMP_IMG}-${kdump_kver}${KDUMP_IMG_EXT}"
setup_initrd
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
if [ $? -ne 0 ]; then
return 1
fi
2011-07-06 19:25:34 +00:00
_force_no_rebuild=`grep ^force_no_rebuild $KDUMP_CONFIG_FILE 2>/dev/null`
if [ $? -eq 0 ]; then
force_no_rebuild=`echo $_force_no_rebuild | cut -d' ' -f2`
if [ "$force_no_rebuild" != "0" ] && [ "$force_no_rebuild" != "1" ];then
echo "Error: force_no_rebuild value is invalid"
return 1
fi
fi
_force_rebuild=`grep ^force_rebuild $KDUMP_CONFIG_FILE 2>/dev/null`
if [ $? -eq 0 ]; then
force_rebuild=`echo $_force_rebuild | cut -d' ' -f2`
if [ "$force_rebuild" != "0" ] && [ "$force_rebuild" != "1" ];then
echo "Error: force_rebuild value is invalid"
return 1
fi
fi
if [[ "$force_no_rebuild" == "1" && "$force_rebuild" == "1" ]]; then
echo "Error: force_rebuild and force_no_rebuild are enabled simultaneously in kdump.conf"
return 1
fi
# Will not rebuild kdump initrd
if [ "$force_no_rebuild" == "1" ]; then
return 0
fi
#will rebuild every time if extra_modules are specified
extra_modules=`grep ^extra_modules $KDUMP_CONFIG_FILE`
[ -n "$extra_modules" ] && force_rebuild="1"
2011-07-06 19:25:34 +00:00
#check to see if dependent files has been modified
#since last build of the image file
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
if [ -f $TARGET_INITRD ]; then
image_time=`stat -c "%Y" $TARGET_INITRD 2>/dev/null`
#in case of fadump mode, check whether the default/target
#initrd is already built with dump capture capability
if [ "$DEFAULT_DUMP_MODE" == "fadump" ]; then
capture_capable_initrd=$(lsinitrd -f $DRACUT_MODULES_FILE $TARGET_INITRD | grep ^kdumpbase$ | wc -l)
fi
2011-07-06 19:25:34 +00:00
fi
check_system_modified
ret=$?
if [ $ret -eq 2 ]; then
return 1
elif [ $ret -eq 1 ];then
system_modified="1"
fi
handle_mode_switch
if [ $image_time -eq 0 ]; then
echo -n "No kdump initial ramdisk found."; echo
elif [ "$capture_capable_initrd" == "0" ]; then
echo -n "Rebuild $TARGET_INITRD with dump capture support"; echo
elif [ "$force_rebuild" != "0" ]; then
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
echo -n "Force rebuild $TARGET_INITRD"; echo
elif [ "$system_modified" != "0" ]; then
:
else
return 0
2011-07-06 19:25:34 +00:00
fi
if [[ ! -w "$KDUMP_BOOTDIR" ]];then
echo "$KDUMP_BOOTDIR does not have write permission. Can not rebuild $TARGET_INITRD"
return 1
fi
kdump: Rebuild default initrd for firmware assisted dump The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd. The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken. Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-24 18:39:07 +00:00
echo "Rebuilding $TARGET_INITRD"
rebuild_initrd
return $?
2011-07-06 19:25:34 +00:00
}
# This function check iomem and determines if we have more than
# 4GB of ram available. Returns 1 if we do, 0 if we dont
need_64bit_headers()
2011-07-06 19:25:34 +00:00
{
return `tail -n 1 /proc/iomem | awk '{ split ($1, r, "-"); \
print (strtonum("0x" r[2]) > strtonum("0xffffffff")); }'`
2011-07-06 19:25:34 +00:00
}
# Load the kdump kernel specified in /etc/sysconfig/kdump
2011-07-06 19:25:34 +00:00
# If none is specified, try to load a kdump kernel with the same version
# as the currently running kernel.
load_kdump()
2011-07-06 19:25:34 +00:00
{
ARCH=`uname -m`
2011-07-06 19:25:34 +00:00
if [ "$ARCH" == "i686" -o "$ARCH" == "i386" ]
then
need_64bit_headers
if [ $? == 1 ]
then
FOUND_ELF_ARGS=`echo $KEXEC_ARGS | grep elf32-core-headers`
if [ -n "$FOUND_ELF_ARGS" ]
then
echo -n "Warning: elf32-core-headers overrides correct elf64 setting"
echo
else
KEXEC_ARGS="$KEXEC_ARGS --elf64-core-headers"
fi
else
FOUND_ELF_ARGS=`echo $KEXEC_ARGS | grep elf64-core-headers`
if [ -z "$FOUND_ELF_ARGS" ]
then
KEXEC_ARGS="$KEXEC_ARGS --elf32-core-headers"
fi
fi
fi
prepare_cmdline
2011-07-06 19:25:34 +00:00
# For secureboot enabled machines, use new kexec file based syscall.
# Old syscall will always fail as it does not have capability to
# to kernel signature verification.
if is_secure_boot_enforced; then
echo "Secure Boot is enabled. Using kexec file based syscall."
KEXEC_ARGS="$KEXEC_ARGS -s"
fi
2011-07-06 19:25:34 +00:00
$KEXEC $KEXEC_ARGS $standard_kexec_args \
--command-line="$KDUMP_COMMANDLINE" \
--initrd=$TARGET_INITRD $kdump_kernel
2011-07-06 19:25:34 +00:00
if [ $? == 0 ]; then
echo "kexec: loaded kdump kernel"
2011-07-06 19:25:34 +00:00
return 0
else
echo "kexec: failed to load kdump kernel" >&2
2011-07-06 19:25:34 +00:00
return 1
fi
}
check_ssh_config()
{
while read config_opt config_val; do
case "$config_opt" in
sshkey)
# remove inline comments after the end of a directive.
config_val=$(strip_comments $config_val)
if [ -f "$config_val" ]; then
# canonicalize the path
SSH_KEY_LOCATION=$(/usr/bin/readlink -m $config_val)
else
echo "WARNING: '$config_val' doesn't exist, using default value '$SSH_KEY_LOCATION'"
fi
;;
path)
config_val=$(strip_comments $config_val)
SAVE_PATH=$config_val
;;
ssh)
config_val=$(strip_comments $config_val)
DUMP_TARGET=$config_val
;;
*)
;;
esac
done < $KDUMP_CONFIG_FILE
#make sure they've configured kdump.conf for ssh dumps
local SSH_TARGET=`echo -n $DUMP_TARGET | sed -n '/.*@/p'`
if [ -z "$SSH_TARGET" ]; then
return 1
fi
return 0
}
check_ssh_target()
{
local _ret
ssh -q -i $SSH_KEY_LOCATION -o BatchMode=yes $DUMP_TARGET mkdir -p $SAVE_PATH
_ret=$?
if [ $_ret -ne 0 ]; then
echo "Could not create $DUMP_TARGET:$SAVE_PATH, you probably need to run \"kdumpctl propagate\"" >&2
return 1
fi
return 0
}
propagate_ssh_key()
2011-07-06 19:25:34 +00:00
{
check_ssh_config
if [ $? -ne 0 ]; then
echo "No ssh config specified in $KDUMP_CONFIG_FILE. Can't propagate" >&2
exit 1
fi
local KEYFILE=$SSH_KEY_LOCATION
2011-07-06 19:25:34 +00:00
local errmsg="Failed to propagate ssh key"
#Check to see if we already created key, if not, create it.
if [ -f $KEYFILE ]; then
echo "Using existing keys..."
else
echo -n "Generating new ssh keys... "
/usr/bin/ssh-keygen -t rsa -f $KEYFILE -N "" 2>&1 > /dev/null
2011-07-06 19:25:34 +00:00
echo "done."
fi
#now find the target ssh user and server to contact.
SSH_USER=`echo $DUMP_TARGET | cut -d\ -f2 | cut -d@ -f1`
SSH_SERVER=`echo $DUMP_TARGET | sed -e's/\(.*@\)\(.*$\)/\2/'`
2011-07-06 19:25:34 +00:00
#now send the found key to the found server
ssh-copy-id -i $KEYFILE $SSH_USER@$SSH_SERVER
2011-07-06 19:25:34 +00:00
RET=$?
if [ $RET == 0 ]; then
echo $KEYFILE has been added to ~$SSH_USER/.ssh/authorized_keys on $SSH_SERVER
return 0
else
echo $errmsg, $KEYFILE failed in transfer to $SSH_SERVER >&2
2011-07-06 19:25:34 +00:00
exit 1
fi
}
show_reserved_mem()
{
local mem=3D$(cat /sys/kernel/kexec_crash_size)
local mem_mb=3D$(expr $mem / 1024 / 1024)
echo "Reserved "$mem_mb"MB memory for crash kernel"
}
handle_mode_switch()
{
if [ "$DEFAULT_DUMP_MODE" == "fadump" ]; then
# backup initrd for reference before replacing it
# with fadump aware initrd
backup_default_initrd
else
# check if a backup of default initrd exists. If yes,
# it signifies a switch from fadump mode. So, restore
# the backed up default initrd.
restore_default_initrd
fi
}
check_current_fadump_status()
{
# Check if firmware-assisted dump has been registered.
rc=`cat $FADUMP_REGISTER_SYS_NODE`
[ $rc -eq 1 ] && return 0
return 1
}
check_current_kdump_status()
2011-07-06 19:25:34 +00:00
{
if [ ! -f /sys/kernel/kexec_crash_loaded ];then
echo "Perhaps CONFIG_CRASH_DUMP is not enabled in kernel"
return 1
fi
2011-07-06 19:25:34 +00:00
rc=`cat /sys/kernel/kexec_crash_loaded`
if [ $rc == 1 ]; then
return 0
else
return 1
fi
}
check_current_status()
{
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
check_current_fadump_status
else
check_current_kdump_status
fi
return $?
}
save_raw()
{
local kdump_dir
local raw_target
raw_target=$(awk '$1 ~ /^raw$/ { print $2; }' $KDUMP_CONFIG_FILE)
[ -z "$raw_target" ] && return 0
[ -b "$raw_target" ] || {
echo "raw partition $raw_target not found"
return 1
}
kdump_dir=`grep ^path $KDUMP_CONFIG_FILE | cut -d' ' -f2-`
if [ -z "${kdump_dir}" ]; then
coredir="/var/crash/`date +"%Y-%m-%d-%H:%M"`"
else
coredir="${kdump_dir}/`date +"%Y-%m-%d-%H:%M"`"
fi
mkdir -p "$coredir"
[ -d "$coredir" ] || {
echo "failed to create $coredir"
return 1
}
if makedumpfile -R $coredir/vmcore <$raw_target >/dev/null 2>&1; then
# dump found
echo "Dump saved to $coredir/vmcore"
# wipe makedumpfile header
dd if=/dev/zero of=$raw_target bs=1b count=1 2>/dev/null
else
rm -rf "$coredir"
fi
return 0
}
is_dump_target_configured()
{
local _target
_target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw|^ssh|^nfs" /etc/kdump.conf)
[ -n "$_target" ]
}
local_fs_dump_target()
{
local _target
_target=$(egrep "^ext[234]|^xfs|^btrfs|^minix" /etc/kdump.conf)
if [ $? -eq 0 ]; then
echo $_target|awk '{print $2}'
fi
}
path_to_be_relabeled()
{
local _path _target _mnt="/" _rmnt
if is_dump_target_configured; then
_target=$(local_fs_dump_target)
if [[ -n "$_target" ]]; then
_mnt=$(findmnt -k -f -n -r -o TARGET $_target)
if [ -z "$_mnt" ]; then
return
fi
else
return
fi
fi
if is_mount_in_dracut_args; then
return;
fi
_path=$(get_save_path)
# if $_path is masked by other mount, we will not relabel it.
_rmnt=$(df $_mnt/$_path 2>/dev/null | tail -1 | awk '{ print $NF }')
if [ "$_rmnt" == "$_mnt" ]; then
echo $_mnt/$_path
fi
}
selinux_relabel()
{
local _path _i _attr
_path=$(path_to_be_relabeled)
if [ -z "$_path" ] || ! [ -d "$_path" ] ; then
return
fi
for _i in $(find $_path); do
_attr=$(getfattr -m "security.selinux" $_i 2>/dev/null)
if [ -z "$_attr" ]; then
restorecon $_i;
fi
done
}
# Check if secure boot is being enforced.
#
# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and
# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four
# bytes are the attributes associated with the variable and can safely be
# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot
# is 1 and SetupMode is 0, then secure boot is being enforced.
#
# Assume efivars is mounted at /sys/firmware/efi/efivars.
is_secure_boot_enforced()
{
local secure_boot_file setup_mode_file
local secure_boot_byte setup_mode_byte
secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null)
setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null)
if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then
secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5)
setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5)
if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; then
return 0
fi
fi
return 1
}
check_crash_mem_reserved()
{
local mem_reserved
mem_reserved=$(cat /sys/kernel/kexec_crash_size)
if [ $mem_reserved -eq 0 ]; then
echo "No memory reserved for crash kernel"
return 1
fi
return 0
}
check_kdump_feasibility()
{
if [ ! -e /sys/kernel/kexec_crash_loaded ]; then
echo "Kdump is not supported on this kernel"
return 1
fi
check_crash_mem_reserved
return $?
}
check_fence_kdump_config()
{
local hostname=`hostname`
local ipaddrs=`hostname -I`
local nodes=$(get_option_value "fence_kdump_nodes")
for node in $nodes; do
if [ "$node" = "$hostname" ]; then
echo "Option fence_kdump_nodes cannot contain $hostname"
return 1
fi
# node can be ipaddr
echo $ipaddrs | grep $node > /dev/null
if [ $? -eq 0 ]; then
echo "Option fence_kdump_nodes cannot contain $node"
return 1
fi
done
return 0
}
check_dump_feasibility()
{
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
return 0
fi
check_kdump_feasibility
return $?
}
start_fadump()
{
echo 1 > $FADUMP_REGISTER_SYS_NODE
if ! check_current_fadump_status; then
echo "fadump: failed to register"
return 1
fi
echo "fadump: registered successfully"
return 0
}
start_dump()
{
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
start_fadump
else
load_kdump
fi
return $?
}
check_default_config()
{
local default_option
default_option=$(awk '$1 ~ /^default$/ {print $2;}' $KDUMP_CONFIG_FILE)
if [ -z "$default_option" ]; then
return 0
else
case "$default_option" in
reboot|halt|poweroff|shell|dump_to_rootfs)
return 0
;;
*)
echo $"Usage kdump.conf: default {reboot|halt|poweroff|shell|dump_to_rootfs}"
return 1
esac
fi
}
start()
2011-07-06 19:25:34 +00:00
{
check_dump_feasibility
if [ $? -ne 0 ]; then
echo "Starting kdump: [FAILED]"
return 1
fi
check_config
if [ $? -ne 0 ]; then
echo "Starting kdump: [FAILED]"
return 1
fi
if sestatus 2>/dev/null | grep -q "SELinux status.*enabled"; then
selinux_relabel
fi
save_raw
if [ $? -ne 0 ]; then
echo "Starting kdump: [FAILED]"
return 1
fi
check_current_status
if [ $? == 0 ]; then
echo "Kdump already running: [WARNING]"
return 0
2011-07-06 19:25:34 +00:00
fi
if check_ssh_config; then
if ! check_ssh_target; then
echo "Starting kdump: [FAILED]"
return 1
fi
fi
check_rebuild
2011-07-06 19:25:34 +00:00
if [ $? != 0 ]; then
echo "Starting kdump: [FAILED]"
2011-07-06 19:25:34 +00:00
return 1
fi
start_dump
2011-07-06 19:25:34 +00:00
if [ $? != 0 ]; then
echo "Starting kdump: [FAILED]"
2011-07-06 19:25:34 +00:00
return 1
fi
echo "Starting kdump: [OK]"
2011-07-06 19:25:34 +00:00
}
stop_fadump()
{
echo 0 > $FADUMP_REGISTER_SYS_NODE
if check_current_fadump_status; then
echo "fadump: failed to unregister"
return 1
fi
echo "fadump: unregistered successfully"
return 0
}
stop_kdump()
2011-07-06 19:25:34 +00:00
{
if is_secure_boot_enforced; then
$KEXEC -s -p -u
else
$KEXEC -p -u
fi
if [ $? != 0 ]; then
echo "kexec: failed to unload kdump kernel"
return 1
fi
echo "kexec: unloaded kdump kernel"
return 0
}
stop()
{
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
stop_fadump
else
stop_kdump
fi
if [ $? != 0 ]; then
echo "Stopping kdump: [FAILED]"
2011-07-06 19:25:34 +00:00
return 1
fi
echo "Stopping kdump: [OK]"
return 0
2011-07-06 19:25:34 +00:00
}
if [ ! -f "$KDUMP_CONFIG_FILE" ]; then
echo "Error: No kdump config file found!" >&2
exit 1
fi
2013-11-25 16:23:11 +00:00
main ()
{
# Determine if the dump mode is kdump or fadump
determine_dump_mode
2013-11-25 16:23:11 +00:00
case "$1" in
start)
if [ -s /proc/vmcore ]; then
save_core
reboot
else
start
fi
;;
stop)
stop
;;
status)
2011-07-06 19:25:34 +00:00
EXIT_CODE=0
check_current_status
2013-11-25 16:23:11 +00:00
case "$?" in
0)
echo "Kdump is operational"
EXIT_CODE=0
;;
1)
echo "Kdump is not operational"
EXIT_CODE=3
;;
esac
exit $EXIT_CODE
2011-07-06 19:25:34 +00:00
;;
2013-11-25 16:23:11 +00:00
restart)
stop
start
;;
condrestart)
2011-07-06 19:25:34 +00:00
;;
2013-11-25 16:23:11 +00:00
propagate)
propagate_ssh_key
2011-07-06 19:25:34 +00:00
;;
showmem)
show_reserved_mem
;;
2013-11-25 16:23:11 +00:00
*)
echo $"Usage: $0 {start|stop|status|restart|propagate|showmem}"
2013-11-25 16:23:11 +00:00
exit 1
2011-07-06 19:25:34 +00:00
esac
2013-11-25 16:23:11 +00:00
}
# Other kdumpctl instances will block in queue, until this one exits
single_instance_lock
# To avoid fd 9 leaking, we invoke a subshell, close fd 9 and call main.
# So that fd isn't leaking when main is invoking a subshell.
(exec 9<&-; main $1)
2011-07-06 19:25:34 +00:00
exit $?