2017-05-09 09:30:30 +00:00
|
|
|
#!/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"
|
2012-06-06 08:24:23 +00:00
|
|
|
MKDUMPRD="/sbin/mkdumprd -f"
|
2017-08-31 06:27:00 +00:00
|
|
|
DRACUT_MODULES_FILE="/usr/lib/dracut/modules.txt"
|
2012-02-22 03:16:09 +00:00
|
|
|
SAVE_PATH=/var/crash
|
|
|
|
SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa"
|
2016-11-03 18:46:31 +00:00
|
|
|
INITRD_CHECKSUM_LOCATION="/boot/.fadump_initrd_checksum"
|
2012-02-22 03:16:09 +00:00
|
|
|
DUMP_TARGET=""
|
2016-11-03 18:46:31 +00:00
|
|
|
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=""
|
2014-07-24 18:38:36 +00:00
|
|
|
FADUMP_REGISTER_SYS_NODE="/sys/kernel/fadump_registered"
|
|
|
|
#kdump shall be the default dump mode
|
|
|
|
DEFAULT_DUMP_MODE="kdump"
|
2016-05-09 08:17:53 +00:00
|
|
|
image_time=0
|
2011-07-06 19:25:34 +00:00
|
|
|
|
2016-11-17 04:51:12 +00:00
|
|
|
[[ $dracutbasedir ]] || dracutbasedir=/usr/lib/dracut
|
|
|
|
. $dracutbasedir/dracut-functions.sh
|
2013-09-26 11:46:48 +00:00
|
|
|
. /lib/kdump/kdump-lib.sh
|
|
|
|
|
2011-07-06 19:25:34 +00:00
|
|
|
standard_kexec_args="-p"
|
|
|
|
|
2015-11-18 08:00:22 +00:00
|
|
|
# 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
|
|
|
|
|
2013-08-30 09:21:56 +00:00
|
|
|
single_instance_lock()
|
|
|
|
{
|
2014-07-16 12:09:48 +00:00
|
|
|
local rc timeout=5
|
|
|
|
|
2013-08-30 09:21:56 +00:00
|
|
|
exec 9>/var/lock/kdump
|
2017-07-12 02:59:55 +00:00
|
|
|
if [ $? -ne 0 ]; then
|
|
|
|
echo "Create file lock failed"
|
|
|
|
exit 1
|
|
|
|
fi
|
2014-07-16 12:09:48 +00:00
|
|
|
|
|
|
|
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
|
2013-08-30 09:21:56 +00:00
|
|
|
}
|
|
|
|
|
2014-07-24 18:38:36 +00:00
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2013-08-02 06:22:21 +00:00
|
|
|
# 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.
|
2014-07-15 06:41:54 +00:00
|
|
|
remove_cmdline_param()
|
2013-08-02 06:22:21 +00:00
|
|
|
{
|
|
|
|
local cmdline=$1
|
|
|
|
shift
|
|
|
|
|
|
|
|
for arg in $@; do
|
|
|
|
cmdline=`echo $cmdline | \
|
2017-04-05 11:34:11 +00:00
|
|
|
sed -e "s/\b$arg=[^ ]*//g" \
|
|
|
|
-e "s/^$arg\b//g" \
|
|
|
|
-e "s/[[:space:]]$arg\b//g" \
|
2013-08-02 06:22:21 +00:00
|
|
|
-e "s/\s\+/ /g"`
|
|
|
|
done
|
|
|
|
echo $cmdline
|
|
|
|
}
|
|
|
|
|
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.
|
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()
|
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; } \
|
2014-02-21 01:09:30 +00:00
|
|
|
' \
|
|
|
|
/proc/cpuinfo
|
|
|
|
}
|
|
|
|
|
|
|
|
#
|
|
|
|
# This function appends argument "$2=$3" to string ($1) if not already present.
|
|
|
|
#
|
2014-07-15 06:41:54 +00:00
|
|
|
append_cmdline()
|
2014-02-21 01:09:30 +00:00
|
|
|
{
|
2014-07-15 06:41:54 +00:00
|
|
|
local cmdline=$1
|
|
|
|
local newstr=${cmdline/$2/""}
|
2014-02-21 01:09:30 +00:00
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
# unchanged str implies argument wasn't there
|
|
|
|
if [ "$cmdline" == "$newstr" ]; then
|
|
|
|
cmdline="${cmdline} ${2}=${3}"
|
|
|
|
fi
|
2014-02-21 01:09:30 +00:00
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
echo $cmdline
|
2014-02-21 01:09:30 +00:00
|
|
|
}
|
|
|
|
|
kdumpctl: sanity check of nr_cpus for x86_64 in case running out of vectors
Check the number of cpus for x86_64 kdump kernel to boot with.
We met an issue on x86_64: kdump runs out of vectors with the
default "nr_cpus=1", when requesting tons of irqs.
This patch detects such situation and warns users about the risk.
The total number of vectors percpu is 256 defined by x86 architecture.
The available vectors can be allocated to io devices percpu starts
from FIRST_EXTERNAL_VECTOR(see kernel code), and some high-numbered
ones are consumed by some system interrupts. As a result, the vectors
for io device are within [FIRST_EXTERNAL_VECTOR, FIRST_SYSTEM_VECTOR),
with one known exception, 0x80 within the range is reserved specially
as the syscall vector.
FIRST_EXTERNAL_VECTOR is invariably 32, while FIRST_SYSTEM_VECTOR can
vary between different kernel versions. E.g. FIRST_SYSTEM_VECTOR gets
0xef(with CONFIG_X86_LOCAL_APIC on)for linux-4.10, that is 17 vectors
reserved, considering it may increase in the future and the special
vectors, we use a flexible variance and assume there are 32 reserved
from FIRST_EXTERNAL_VECTOR. Then the max vectors for device interrupts
percpu is: (256-32)-32=192, we acquire the number N of device interrupts
from /proc/irq/, then the number of minimal cpus required is calculated:
(N + 192 - 1) / 192
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-01-23 06:36:40 +00:00
|
|
|
# Check the number of cpus for kdump kernel to boot with.
|
|
|
|
# We met an issue on x86_64: kdump runs out of vectors with
|
|
|
|
# "nr_cpus=1" when requesting tons of irqs, so here we check
|
|
|
|
# "nr_cpus=1" and warn users if kdump probably can't work.
|
|
|
|
check_kdump_cpus()
|
|
|
|
{
|
|
|
|
local nr_origin nr_min nr_max
|
|
|
|
local arch=$(uname -m) cmdline=$KDUMP_COMMANDLINE_APPEND
|
|
|
|
|
|
|
|
if [ $arch != "x86_64" ]; then
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
|
|
|
# We only care about the default "nr_cpus=1".
|
|
|
|
echo $cmdline | grep -E -q "nr_cpus=1[[:space:]]*|nr_cpus=1$"
|
|
|
|
if [ $? -ne 0 ]; then
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
|
|
|
nr_origin=1
|
|
|
|
|
|
|
|
# Online cpus in first kernel.
|
|
|
|
nr_max=$(grep -c '^processor' /proc/cpuinfo)
|
|
|
|
|
|
|
|
# To calculate the estimated minimal cpus required.
|
|
|
|
nr_min=$(ls -ld /proc/irq/*/ | wc -l)
|
|
|
|
|
|
|
|
# Vectors for io device start from FIRST_EXTERNAL_VECTOR(32),
|
|
|
|
# some high-numbered ones starting from FIRST_EXTERNAL_VECTOR
|
|
|
|
# are reserved for system internal uses.
|
|
|
|
#
|
|
|
|
# We use a flexible variance and assume there are 32 reserved
|
|
|
|
# from FIRST_EXTERNAL_VECTOR. Then the total vectors for device
|
|
|
|
# interrupts percpu is: (256-32)-32=192.
|
|
|
|
#
|
|
|
|
# For "nr_cpus=1", irq and vector have the 1:1 mapping.
|
|
|
|
nr_min=$(($nr_min + 192 - 1))
|
|
|
|
nr_min=$(($nr_min / 192))
|
|
|
|
if [ $nr_min -gt 1 ]; then
|
|
|
|
# The system seems to have tons of interrupts. We need
|
|
|
|
# some further calculation of the number of cpus(>1).
|
|
|
|
# For "nr_cpus>1", irq and vector have the 1:M mapping,
|
|
|
|
# multiple-cpu affinity can consume multiple vectors.
|
|
|
|
# Luckily for x2apic which is commonly deployed on large
|
|
|
|
# modern machines, default case of boot, device bringup
|
|
|
|
# etc will use a single cpu to minimize vector pressure.
|
|
|
|
#
|
|
|
|
# For further safety, we add one more cpu and round it
|
|
|
|
# up to an even number.
|
|
|
|
nr_min=$(($nr_min + 1))
|
|
|
|
nr_min=$(($nr_min + $nr_min % 2))
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ $nr_min -gt $nr_max ]; then
|
|
|
|
nr_min=$nr_max
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ $nr_origin -ge $nr_min ]; then
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
|
|
|
echo -n "Warning: nr_cpus=1 may not be enough for kdump boot,"
|
|
|
|
echo " try nr_cpus=$nr_min or larger instead"
|
|
|
|
}
|
|
|
|
|
2017-01-12 04:47:20 +00:00
|
|
|
# This function performs a series of edits on the command line.
|
|
|
|
# Store the final result in global $KDUMP_COMMANDLINE.
|
2014-07-15 06:41:54 +00:00
|
|
|
prepare_cmdline()
|
2014-02-21 01:09:30 +00:00
|
|
|
{
|
2017-01-12 04:47:20 +00:00
|
|
|
local cmdline id
|
|
|
|
|
2014-02-21 01:09:30 +00:00
|
|
|
if [ -z "$KDUMP_COMMANDLINE" ]; then
|
2017-08-30 08:45:46 +00:00
|
|
|
cmdline=$(cat /proc/cmdline)
|
2014-02-21 01:09:30 +00:00
|
|
|
else
|
|
|
|
cmdline=${KDUMP_COMMANDLINE}
|
|
|
|
fi
|
2017-01-12 04:47:20 +00:00
|
|
|
|
2015-11-18 08:00:22 +00:00
|
|
|
# These params should always be removed
|
2017-08-30 08:45:46 +00:00
|
|
|
cmdline=$(remove_cmdline_param "$cmdline" crashkernel panic_on_warn)
|
2015-11-18 08:00:22 +00:00
|
|
|
# These params can be removed configurably
|
2017-08-30 08:45:46 +00:00
|
|
|
cmdline=$(remove_cmdline_param "$cmdline" ${KDUMP_COMMANDLINE_REMOVE})
|
2014-02-21 01:09:30 +00:00
|
|
|
|
kdumpctl: remove "root=X" for kdump boot
Since the current dracut of Fedora already supports not always
mounting root device, we can remove "root=X" from the command
line directly, and always get the dump target specified in
"/etc/kdump.conf" and mount it. If the dump target is located
at root filesystem, we will add the root mount info explicitly
from kdump side instead of from dracut side.
For example, in case of nfs/ssh/usb/raw/etc(non-root) dumping,
kdump will not mount the unnecessary root fs after this change.
This patch removes "root=X" via the "KDUMP_COMMANDLINE_REMOVE"
(if "default dump_to_rootfs" is specified, don't remove "root=X"),
and mounts non-root target under "/kdumproot", the root target
still under "/sysroot"(to be align with systemd sysroot.mount).
After removing "root=X", we now add root fs mount information
explicitly from the kdump side.
Changed check_dump_fs_modified() a little to avoid rebuild when
dump target is root, since we add root fs mount explicitly now.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
2017-04-05 11:34:12 +00:00
|
|
|
# Always remove "root=X", as we now explicitly generate all kinds
|
2017-08-30 08:45:46 +00:00
|
|
|
# of dump target mount information including root fs.
|
kdumpctl: remove "root=X" for kdump boot
Since the current dracut of Fedora already supports not always
mounting root device, we can remove "root=X" from the command
line directly, and always get the dump target specified in
"/etc/kdump.conf" and mount it. If the dump target is located
at root filesystem, we will add the root mount info explicitly
from kdump side instead of from dracut side.
For example, in case of nfs/ssh/usb/raw/etc(non-root) dumping,
kdump will not mount the unnecessary root fs after this change.
This patch removes "root=X" via the "KDUMP_COMMANDLINE_REMOVE"
(if "default dump_to_rootfs" is specified, don't remove "root=X"),
and mounts non-root target under "/kdumproot", the root target
still under "/sysroot"(to be align with systemd sysroot.mount).
After removing "root=X", we now add root fs mount information
explicitly from the kdump side.
Changed check_dump_fs_modified() a little to avoid rebuild when
dump target is root, since we add root fs mount explicitly now.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
2017-04-05 11:34:12 +00:00
|
|
|
#
|
|
|
|
# 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.
|
2017-08-30 08:45:46 +00:00
|
|
|
cmdline=$(remove_cmdline_param "$cmdline" root)
|
kdumpctl: remove "root=X" for kdump boot
Since the current dracut of Fedora already supports not always
mounting root device, we can remove "root=X" from the command
line directly, and always get the dump target specified in
"/etc/kdump.conf" and mount it. If the dump target is located
at root filesystem, we will add the root mount info explicitly
from kdump side instead of from dracut side.
For example, in case of nfs/ssh/usb/raw/etc(non-root) dumping,
kdump will not mount the unnecessary root fs after this change.
This patch removes "root=X" via the "KDUMP_COMMANDLINE_REMOVE"
(if "default dump_to_rootfs" is specified, don't remove "root=X"),
and mounts non-root target under "/kdumproot", the root target
still under "/sysroot"(to be align with systemd sysroot.mount).
After removing "root=X", we now add root fs mount information
explicitly from the kdump side.
Changed check_dump_fs_modified() a little to avoid rebuild when
dump target is root, since we add root fs mount explicitly now.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
2017-04-05 11:34:12 +00:00
|
|
|
|
2017-08-30 08:45:48 +00:00
|
|
|
# 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)
|
|
|
|
|
2014-02-21 01:09:30 +00:00
|
|
|
cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
|
|
|
|
|
2017-08-30 08:45:46 +00:00
|
|
|
id=$(get_bootcpu_apicid)
|
2014-02-21 01:09:30 +00:00
|
|
|
if [ ! -z ${id} ] ; then
|
2017-08-30 08:45:46 +00:00
|
|
|
cmdline=$(append_cmdline "${cmdline}" disable_cpu_apicid ${id})
|
2014-02-21 01:09:30 +00:00
|
|
|
fi
|
|
|
|
|
2017-01-12 04:47:20 +00:00
|
|
|
KDUMP_COMMANDLINE=$cmdline
|
kdumpctl: sanity check of nr_cpus for x86_64 in case running out of vectors
Check the number of cpus for x86_64 kdump kernel to boot with.
We met an issue on x86_64: kdump runs out of vectors with the
default "nr_cpus=1", when requesting tons of irqs.
This patch detects such situation and warns users about the risk.
The total number of vectors percpu is 256 defined by x86 architecture.
The available vectors can be allocated to io devices percpu starts
from FIRST_EXTERNAL_VECTOR(see kernel code), and some high-numbered
ones are consumed by some system interrupts. As a result, the vectors
for io device are within [FIRST_EXTERNAL_VECTOR, FIRST_SYSTEM_VECTOR),
with one known exception, 0x80 within the range is reserved specially
as the syscall vector.
FIRST_EXTERNAL_VECTOR is invariably 32, while FIRST_SYSTEM_VECTOR can
vary between different kernel versions. E.g. FIRST_SYSTEM_VECTOR gets
0xef(with CONFIG_X86_LOCAL_APIC on)for linux-4.10, that is 17 vectors
reserved, considering it may increase in the future and the special
vectors, we use a flexible variance and assume there are 32 reserved
from FIRST_EXTERNAL_VECTOR. Then the max vectors for device interrupts
percpu is: (256-32)-32=192, we acquire the number N of device interrupts
from /proc/irq/, then the number of minimal cpus required is calculated:
(N + 192 - 1) / 192
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-01-23 06:36:40 +00:00
|
|
|
|
|
|
|
check_kdump_cpus
|
2014-02-21 01:09:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-07-15 06:41:54 +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
|
2013-02-18 09:05:41 +00:00
|
|
|
echo "saved a vmcore to $coredir"
|
2011-07-06 19:25:34 +00:00
|
|
|
else
|
2013-02-18 09:05:41 +00:00
|
|
|
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
|
2013-02-18 09:05:41 +00:00
|
|
|
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()
|
2012-06-14 01:57:27 +00:00
|
|
|
{
|
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
|
|
|
|
|
2014-07-24 18:39:22 +00:00
|
|
|
# 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"
|
2014-07-24 18:39:22 +00:00
|
|
|
$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
|
2014-08-04 10:46:36 +00:00
|
|
|
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
|
2014-08-04 10:46:36 +00:00
|
|
|
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
|
2012-06-14 01:57:27 +00:00
|
|
|
if [ $? != 0 ]; then
|
2013-02-18 09:05:41 +00:00
|
|
|
echo "mkdumprd: failed to make kdump initrd" >&2
|
2012-06-14 01:57:27 +00:00
|
|
|
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 $?
|
2012-06-14 01:57:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#$1: the files to be checked with IFS=' '
|
2014-07-15 06:41:54 +00:00
|
|
|
check_exist()
|
2012-06-14 01:57:27 +00:00
|
|
|
{
|
|
|
|
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=' '
|
2014-07-15 06:41:54 +00:00
|
|
|
check_executable()
|
2012-06-14 01:57:27 +00:00
|
|
|
{
|
|
|
|
for file in $1; do
|
|
|
|
if [ ! -x "$file" ]; then
|
|
|
|
echo -n "Error: $file is not executable."; echo
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
2016-11-03 18:46:31 +00:00
|
|
|
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
|
|
|
{
|
2017-05-04 06:56:54 +00:00
|
|
|
if [ ! -f "$DEFAULT_INITRD" ]; then
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2016-11-03 18:46:31 +00:00
|
|
|
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
|
|
|
|
2016-11-03 18:46:31 +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
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_config()
|
2013-03-11 09:31:25 +00:00
|
|
|
{
|
|
|
|
local nr
|
|
|
|
|
Support special mount information via "dracut_args"
There are some complaints about nfs kdump that users must mount
nfs beforehand, which may cause some overhead to nfs server.
For example, there're thounsands of diskless clients deployed with
nfs dumping, each time the client is boot up, it will trigger
kdump rebuilding so will mount nfs, thus resulting in thousands
of nfs request concurrently imposed on the same nfs server.
We introduce a new way of specifying mount information via the
already-existent "dracut_args" directive(so avoid adding extra
directives in /etc/kdump.conf), we will skip all the filesystem
mounting and checking stuff for it. So it can be used in the
above-mentioned nfs scenario to avoid severe nfs server overhead.
Specifically, if there is any "--mount" information specified via
"dracut_args" in /etc/kdump.conf, always use it as the final mount
without any validation(mounting or checking like mount options,
fs size, etc), so users are expected to ensure its correctness.
NOTE:
-Only one mount target is allowed using "dracut_args" globally.
-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
<mountpoint> must be specified as an absolute path.
-Users should do a test first and ensure it works because kdump does
not prepare the mount or check all the validity.
Reviewed-by: Pratyush Anand <panand@redhat.com>
Suggested-by: Dave Young <dyoung@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
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)
|
2013-03-11 09:31:25 +00:00
|
|
|
[ $nr -gt 1 ] && {
|
|
|
|
echo "More than one dump targets specified."
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
Support special mount information via "dracut_args"
There are some complaints about nfs kdump that users must mount
nfs beforehand, which may cause some overhead to nfs server.
For example, there're thounsands of diskless clients deployed with
nfs dumping, each time the client is boot up, it will trigger
kdump rebuilding so will mount nfs, thus resulting in thousands
of nfs request concurrently imposed on the same nfs server.
We introduce a new way of specifying mount information via the
already-existent "dracut_args" directive(so avoid adding extra
directives in /etc/kdump.conf), we will skip all the filesystem
mounting and checking stuff for it. So it can be used in the
above-mentioned nfs scenario to avoid severe nfs server overhead.
Specifically, if there is any "--mount" information specified via
"dracut_args" in /etc/kdump.conf, always use it as the final mount
without any validation(mounting or checking like mount options,
fs size, etc), so users are expected to ensure its correctness.
NOTE:
-Only one mount target is allowed using "dracut_args" globally.
-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
<mountpoint> must be specified as an absolute path.
-Users should do a test first and ensure it works because kdump does
not prepare the mount or check all the validity.
Reviewed-by: Pratyush Anand <panand@redhat.com>
Suggested-by: Dave Young <dyoung@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
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
|
|
|
|
}
|
|
|
|
|
2017-05-11 05:44:28 +00:00
|
|
|
while read config_opt config_val; do
|
2013-03-11 09:31:25 +00:00
|
|
|
case "$config_opt" in
|
2017-05-11 05:44:28 +00:00
|
|
|
\#* | "")
|
2013-03-11 09:31:25 +00:00
|
|
|
;;
|
2017-04-12 05:44:18 +00:00
|
|
|
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)
|
2017-05-11 05:44:29 +00:00
|
|
|
# remove inline comments after the end of a directive.
|
|
|
|
config_val=$(strip_comments $config_val)
|
2013-03-11 09:31:25 +00:00
|
|
|
[ -z "$config_val" ] && {
|
|
|
|
echo "Invalid kdump config value for option $config_opt."
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
;;
|
2013-03-22 03:55:24 +00:00
|
|
|
net|options|link_delay|disk_timeout|debug_mem_level|blacklist)
|
2013-03-11 09:31:25 +00:00
|
|
|
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
|
2017-05-11 05:44:28 +00:00
|
|
|
done < $KDUMP_CONFIG_FILE
|
2014-07-15 06:41:54 +00:00
|
|
|
|
2015-06-11 08:22:11 +00:00
|
|
|
check_default_config || return 1
|
|
|
|
|
2014-04-02 08:33:47 +00:00
|
|
|
check_fence_kdump_config || return 1
|
|
|
|
|
2013-03-11 09:31:25 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2014-04-02 08:33:47 +00:00
|
|
|
# get_pcs_cluster_modified_files <image timestamp>
|
|
|
|
# return list of modified file for fence_kdump modified in Pacemaker cluster
|
|
|
|
get_pcs_cluster_modified_files()
|
2013-12-17 07:00:33 +00:00
|
|
|
{
|
2014-04-02 08:33:47 +00:00
|
|
|
local time_stamp
|
|
|
|
local modified_files
|
2013-12-17 07:00:33 +00:00
|
|
|
|
2014-04-02 08:33:47 +00:00
|
|
|
is_generic_fence_kdump && return 1
|
2014-04-02 08:33:43 +00:00
|
|
|
is_pcs_fence_kdump || return 1
|
2013-12-17 07:00:33 +00:00
|
|
|
|
2014-04-02 08:33:47 +00:00
|
|
|
time_stamp=`pcs cluster cib | xmllint --xpath 'string(/cib/@cib-last-written)' - | \
|
|
|
|
xargs -0 date +%s --date`
|
2013-12-17 07:00:33 +00:00
|
|
|
|
2014-04-02 08:33:47 +00:00
|
|
|
if [ -n $time_stamp -a $time_stamp -gt $image_time ]; then
|
|
|
|
modified_files="cluster-cib"
|
2013-12-17 07:00:33 +00:00
|
|
|
fi
|
|
|
|
|
2014-04-02 08:33:47 +00:00
|
|
|
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
|
2013-12-17 07:00:33 +00:00
|
|
|
}
|
|
|
|
|
2015-01-28 08:22:47 +00:00
|
|
|
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
|
|
|
|
|
2015-04-17 08:26:25 +00:00
|
|
|
if ! is_atomic || [ "$(uname -m)" = "s390x" ]; then
|
2015-01-28 08:22:47 +00:00
|
|
|
KDUMP_BOOTDIR="/boot"
|
|
|
|
else
|
|
|
|
eval $(cat /proc/cmdline| grep "BOOT_IMAGE" | cut -d' ' -f1)
|
|
|
|
KDUMP_BOOTDIR="/boot"$(dirname $BOOT_IMAGE)
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2016-11-03 18:46:31 +00:00
|
|
|
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
|
|
|
{
|
2016-11-03 18:46:31 +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
|
2016-11-03 18:46:31 +00:00
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2016-05-09 08:17:53 +00:00
|
|
|
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`
|
|
|
|
EXTRA_BINS="$EXTRA_BINS $CHECK_FILES"
|
|
|
|
CHECK_FILES=`grep ^extra_bins $KDUMP_CONFIG_FILE | cut -d\ -f2-`
|
|
|
|
EXTRA_BINS="$EXTRA_BINS $CHECK_FILES"
|
2016-09-14 14:42:17 +00:00
|
|
|
files="$KDUMP_CONFIG_FILE $kdump_kernel $EXTRA_BINS"
|
|
|
|
[[ -e /etc/fstab ]] && files="$files /etc/fstab"
|
2016-05-09 08:17:53 +00:00
|
|
|
|
|
|
|
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
|
|
|
|
|
Support special mount information via "dracut_args"
There are some complaints about nfs kdump that users must mount
nfs beforehand, which may cause some overhead to nfs server.
For example, there're thounsands of diskless clients deployed with
nfs dumping, each time the client is boot up, it will trigger
kdump rebuilding so will mount nfs, thus resulting in thousands
of nfs request concurrently imposed on the same nfs server.
We introduce a new way of specifying mount information via the
already-existent "dracut_args" directive(so avoid adding extra
directives in /etc/kdump.conf), we will skip all the filesystem
mounting and checking stuff for it. So it can be used in the
above-mentioned nfs scenario to avoid severe nfs server overhead.
Specifically, if there is any "--mount" information specified via
"dracut_args" in /etc/kdump.conf, always use it as the final mount
without any validation(mounting or checking like mount options,
fs size, etc), so users are expected to ensure its correctness.
NOTE:
-Only one mount target is allowed using "dracut_args" globally.
-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
<mountpoint> must be specified as an absolute path.
-Users should do a test first and ensure it works because kdump does
not prepare the mount or check all the validity.
Reviewed-by: Pratyush Anand <panand@redhat.com>
Suggested-by: Dave Young <dyoung@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
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)
|
2016-09-12 07:10:04 +00:00
|
|
|
_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
|
2016-11-17 04:51:12 +00:00
|
|
|
_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
|
|
|
|
|
kdumpctl: remove "root=X" for kdump boot
Since the current dracut of Fedora already supports not always
mounting root device, we can remove "root=X" from the command
line directly, and always get the dump target specified in
"/etc/kdump.conf" and mount it. If the dump target is located
at root filesystem, we will add the root mount info explicitly
from kdump side instead of from dracut side.
For example, in case of nfs/ssh/usb/raw/etc(non-root) dumping,
kdump will not mount the unnecessary root fs after this change.
This patch removes "root=X" via the "KDUMP_COMMANDLINE_REMOVE"
(if "default dump_to_rootfs" is specified, don't remove "root=X"),
and mounts non-root target under "/kdumproot", the root target
still under "/sysroot"(to be align with systemd sysroot.mount).
After removing "root=X", we now add root fs mount information
explicitly from the kdump side.
Changed check_dump_fs_modified() a little to avoid rebuild when
dump target is root, since we add root fs mount explicitly now.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
2017-04-05 11:34:12 +00:00
|
|
|
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
|
|
|
|
2017-05-04 06:56:56 +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
|
|
|
|
}
|
|
|
|
|
2016-07-20 18:12:21 +00:00
|
|
|
check_wdt_modified()
|
|
|
|
{
|
2017-05-04 06:56:55 +00:00
|
|
|
local -A _drivers
|
|
|
|
local _alldrivers _active _wdtdrv _wdtppath _dir
|
|
|
|
local wd_old wd_new
|
|
|
|
|
2016-07-20 18:12:21 +00:00
|
|
|
is_wdt_mod_omitted
|
|
|
|
[[ $? -eq 0 ]] && return 0
|
|
|
|
[[ -d /sys/class/watchdog/ ]] || return 0
|
|
|
|
|
2017-05-04 06:56:55 +00:00
|
|
|
# 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
|
2016-07-20 18:12:21 +00:00
|
|
|
fi
|
2017-05-04 06:56:55 +00:00
|
|
|
# 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
|
2016-07-20 18:12:21 +00:00
|
|
|
done
|
|
|
|
|
2017-05-04 06:56:55 +00:00
|
|
|
# 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)
|
2016-07-20 18:12:21 +00:00
|
|
|
|
2017-05-04 06:56:55 +00:00
|
|
|
[[ "$wd_old" = "$wd_new" ]] && return 0
|
|
|
|
|
|
|
|
return 1
|
2016-07-20 18:12:21 +00:00
|
|
|
}
|
|
|
|
|
2016-05-09 08:17:52 +00:00
|
|
|
# returns 0 if system is not modified
|
|
|
|
# returns 1 if system is modified
|
|
|
|
# returns 2 if system modification is invalid
|
|
|
|
check_system_modified()
|
|
|
|
{
|
2016-05-09 08:17:53 +00:00
|
|
|
local ret
|
|
|
|
|
2016-05-09 08:17:52 +00:00
|
|
|
[[ -f $TARGET_INITRD ]] || return 1
|
|
|
|
|
2016-05-09 08:17:53 +00:00
|
|
|
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
|
|
|
|
|
2016-07-20 18:12:21 +00:00
|
|
|
check_wdt_modified
|
|
|
|
if [ $? -ne 0 ]; then
|
|
|
|
echo "Detected change in watchdog state"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2016-05-09 08:17:52 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_rebuild()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2016-05-09 08:17:53 +00:00
|
|
|
local extra_modules
|
2017-08-31 06:27:00 +00:00
|
|
|
local capture_capable_initrd="1"
|
2012-08-06 14:01:29 +00:00
|
|
|
local _force_rebuild force_rebuild="0"
|
2017-04-12 05:44:18 +00:00
|
|
|
local _force_no_rebuild force_no_rebuild="0"
|
2016-05-09 08:17:52 +00:00
|
|
|
local ret system_modified="0"
|
2012-06-14 01:57:27 +00:00
|
|
|
|
2015-01-28 08:22:47 +00:00
|
|
|
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}"
|
2016-11-03 18:46:31 +00:00
|
|
|
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
|
|
|
|
2017-04-12 05:44:18 +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
|
|
|
|
|
2012-08-06 14:01:29 +00:00
|
|
|
_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
|
|
|
|
|
2017-04-12 05:44:18 +00:00
|
|
|
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
|
|
|
|
|
2012-06-14 01:57:27 +00:00
|
|
|
#will rebuild every time if extra_modules are specified
|
|
|
|
extra_modules=`grep ^extra_modules $KDUMP_CONFIG_FILE`
|
2012-08-06 14:01:29 +00:00
|
|
|
[ -n "$extra_modules" ] && force_rebuild="1"
|
2011-07-06 19:25:34 +00:00
|
|
|
|
2012-06-14 01:57:27 +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`
|
2017-08-31 06:27:00 +00:00
|
|
|
|
|
|
|
#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
|
|
|
|
|
2016-05-09 08:17:52 +00:00
|
|
|
check_system_modified
|
|
|
|
ret=$?
|
|
|
|
if [ $ret -eq 2 ]; then
|
|
|
|
return 1
|
|
|
|
elif [ $ret -eq 1 ];then
|
|
|
|
system_modified="1"
|
|
|
|
fi
|
|
|
|
|
2017-05-04 06:56:54 +00:00
|
|
|
handle_mode_switch
|
|
|
|
|
|
|
|
if [ $image_time -eq 0 ]; then
|
2012-06-14 01:57:27 +00:00
|
|
|
echo -n "No kdump initial ramdisk found."; echo
|
2017-08-31 06:27:00 +00:00
|
|
|
elif [ "$capture_capable_initrd" == "0" ]; then
|
|
|
|
echo -n "Rebuild $TARGET_INITRD with dump capture support"; echo
|
2012-08-06 14:01:29 +00:00
|
|
|
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
|
2016-05-09 08:17:52 +00:00
|
|
|
elif [ "$system_modified" != "0" ]; then
|
|
|
|
:
|
2012-06-14 01:57:27 +00:00
|
|
|
else
|
|
|
|
return 0
|
2011-07-06 19:25:34 +00:00
|
|
|
fi
|
|
|
|
|
2016-04-11 12:01:27 +00:00
|
|
|
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"
|
2012-06-14 01:57:27 +00:00
|
|
|
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
|
2014-07-15 06:41:54 +00:00
|
|
|
need_64bit_headers()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2014-07-15 06:41:54 +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
|
|
|
}
|
|
|
|
|
2016-11-15 09:07:59 +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.
|
2014-07-15 06:41:54 +00:00
|
|
|
load_kdump()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2012-11-12 08:51:03 +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
|
|
|
|
|
2017-01-12 04:47:20 +00:00
|
|
|
prepare_cmdline
|
2011-07-06 19:25:34 +00:00
|
|
|
|
2014-09-08 15:35:22 +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" \
|
2014-09-08 15:35:20 +00:00
|
|
|
--initrd=$TARGET_INITRD $kdump_kernel
|
2011-07-06 19:25:34 +00:00
|
|
|
if [ $? == 0 ]; then
|
2013-02-18 09:05:41 +00:00
|
|
|
echo "kexec: loaded kdump kernel"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 0
|
|
|
|
else
|
2013-02-18 09:05:41 +00:00
|
|
|
echo "kexec: failed to load kdump kernel" >&2
|
2011-07-06 19:25:34 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_ssh_config()
|
2012-02-22 03:16:09 +00:00
|
|
|
{
|
2017-05-11 05:44:28 +00:00
|
|
|
while read config_opt config_val; do
|
2012-02-22 03:16:09 +00:00
|
|
|
case "$config_opt" in
|
|
|
|
sshkey)
|
2017-05-11 05:44:29 +00:00
|
|
|
# remove inline comments after the end of a directive.
|
|
|
|
config_val=$(strip_comments $config_val)
|
2012-02-22 03:16:09 +00:00
|
|
|
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)
|
2017-05-11 05:44:29 +00:00
|
|
|
config_val=$(strip_comments $config_val)
|
2012-02-22 03:16:09 +00:00
|
|
|
SAVE_PATH=$config_val
|
|
|
|
;;
|
2012-07-23 07:31:28 +00:00
|
|
|
ssh)
|
2017-05-11 05:44:29 +00:00
|
|
|
config_val=$(strip_comments $config_val)
|
2012-02-22 03:16:09 +00:00
|
|
|
DUMP_TARGET=$config_val
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
;;
|
|
|
|
esac
|
2017-05-11 05:44:28 +00:00
|
|
|
done < $KDUMP_CONFIG_FILE
|
2012-02-22 03:16:09 +00:00
|
|
|
|
|
|
|
#make sure they've configured kdump.conf for ssh dumps
|
2012-03-28 08:23:38 +00:00
|
|
|
local SSH_TARGET=`echo -n $DUMP_TARGET | sed -n '/.*@/p'`
|
2012-02-22 03:16:09 +00:00
|
|
|
if [ -z "$SSH_TARGET" ]; then
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_ssh_target()
|
2012-02-22 03:16:09 +00:00
|
|
|
{
|
2013-02-18 09:05:43 +00:00
|
|
|
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
|
2012-02-22 03:16:09 +00:00
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
propagate_ssh_key()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2012-02-22 03:16:09 +00:00
|
|
|
check_ssh_config
|
|
|
|
if [ $? -ne 0 ]; then
|
2013-02-18 09:05:41 +00:00
|
|
|
echo "No ssh config specified in $KDUMP_CONFIG_FILE. Can't propagate" >&2
|
2012-02-22 03:16:09 +00:00
|
|
|
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... "
|
2012-02-22 03:16:09 +00:00
|
|
|
/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.
|
2012-02-22 03:16:09 +00:00
|
|
|
SSH_USER=`echo $DUMP_TARGET | cut -d\ -f2 | cut -d@ -f1`
|
|
|
|
SSH_SERVER=`echo $DUMP_TARGET | sed -e's/\(.*@\)\(.*$\)/\2/'`
|
2014-07-15 06:41:54 +00:00
|
|
|
|
2011-07-06 19:25:34 +00:00
|
|
|
#now send the found key to the found server
|
2012-02-22 03:16:09 +00:00
|
|
|
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
|
2013-02-18 09:05:41 +00:00
|
|
|
echo $errmsg, $KEYFILE failed in transfer to $SSH_SERVER >&2
|
2011-07-06 19:25:34 +00:00
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2016-11-03 18:46:31 +00:00
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2014-07-24 18:38:36 +00:00
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_current_kdump_status()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2017-04-07 04:17:33 +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
|
|
|
|
}
|
|
|
|
|
2014-07-24 18:38:36 +00:00
|
|
|
check_current_status()
|
|
|
|
{
|
|
|
|
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
|
|
|
|
check_current_fadump_status
|
|
|
|
else
|
|
|
|
check_current_kdump_status
|
|
|
|
fi
|
|
|
|
|
|
|
|
return $?
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
save_raw()
|
2012-04-28 10:01:18 +00:00
|
|
|
{
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
is_dump_target_configured()
|
|
|
|
{
|
|
|
|
local _target
|
2013-06-08 06:22:31 +00:00
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
_target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw|^ssh|^nfs" /etc/kdump.conf)
|
2013-06-08 06:22:31 +00:00
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
[ -n "$_target" ]
|
2013-06-08 06:22:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
path_to_be_relabeled()
|
|
|
|
{
|
2013-06-08 06:22:31 +00:00
|
|
|
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
|
|
|
|
|
|
|
|
_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
|
|
|
|
}
|
|
|
|
|
2014-02-12 02:31:41 +00:00
|
|
|
# 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.
|
2014-07-15 06:41:54 +00:00
|
|
|
is_secure_boot_enforced()
|
2014-02-12 02:31:41 +00:00
|
|
|
{
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2016-05-12 04:56:39 +00:00
|
|
|
check_crash_mem_reserved()
|
|
|
|
{
|
2017-04-29 01:15:00 +00:00
|
|
|
local mem_reserved
|
|
|
|
|
|
|
|
mem_reserved=$(cat /sys/kernel/kexec_crash_size)
|
|
|
|
if [ $mem_reserved -eq 0 ]; then
|
|
|
|
echo "No memory reserved for crash kernel"
|
2016-05-12 04:56:39 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_kdump_feasibility()
|
2014-02-12 02:31:41 +00:00
|
|
|
{
|
2014-02-13 03:23:58 +00:00
|
|
|
if [ ! -e /sys/kernel/kexec_crash_loaded ]; then
|
|
|
|
echo "Kdump is not supported on this kernel"
|
|
|
|
return 1
|
|
|
|
fi
|
2016-05-12 04:56:39 +00:00
|
|
|
check_crash_mem_reserved
|
|
|
|
return $?
|
2014-02-12 02:31:41 +00:00
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_fence_kdump_config()
|
2014-04-02 08:33:47 +00:00
|
|
|
{
|
|
|
|
local hostname=`hostname`
|
2017-05-17 03:16:22 +00:00
|
|
|
local ipaddrs=`hostname -I`
|
2014-04-02 08:33:47 +00:00
|
|
|
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
|
2017-05-17 03:16:22 +00:00
|
|
|
# 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
|
2014-04-02 08:33:47 +00:00
|
|
|
done
|
|
|
|
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2014-07-24 18:38:36 +00:00
|
|
|
check_dump_feasibility()
|
|
|
|
{
|
|
|
|
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
|
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
check_kdump_feasibility
|
|
|
|
return $?
|
|
|
|
}
|
|
|
|
|
2014-07-24 18:38:53 +00:00
|
|
|
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 $?
|
|
|
|
}
|
|
|
|
|
2015-06-11 08:22:11 +00:00
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
start()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2017-04-29 01:15:00 +00:00
|
|
|
check_dump_feasibility
|
2013-03-11 09:31:25 +00:00
|
|
|
if [ $? -ne 0 ]; then
|
|
|
|
echo "Starting kdump: [FAILED]"
|
2012-04-28 07:17:13 +00:00
|
|
|
return 1
|
2013-03-11 09:31:25 +00:00
|
|
|
fi
|
2012-04-28 07:17:13 +00:00
|
|
|
|
2017-04-29 01:15:00 +00:00
|
|
|
check_config
|
2012-04-28 10:01:18 +00:00
|
|
|
if [ $? -ne 0 ]; then
|
2013-02-18 09:05:42 +00:00
|
|
|
echo "Starting kdump: [FAILED]"
|
2012-04-28 10:01:18 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2017-04-29 01:15:00 +00:00
|
|
|
if sestatus 2>/dev/null | grep -q "SELinux status.*enabled"; then
|
|
|
|
selinux_relabel
|
|
|
|
fi
|
|
|
|
|
|
|
|
save_raw
|
2014-02-12 02:31:41 +00:00
|
|
|
if [ $? -ne 0 ]; then
|
|
|
|
echo "Starting kdump: [FAILED]"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2014-07-24 18:38:36 +00:00
|
|
|
check_current_status
|
2014-02-13 03:23:58 +00:00
|
|
|
if [ $? == 0 ]; then
|
|
|
|
echo "Kdump already running: [WARNING]"
|
|
|
|
return 0
|
2011-07-06 19:25:34 +00:00
|
|
|
fi
|
2012-02-22 03:16:09 +00:00
|
|
|
|
2013-02-18 09:05:43 +00:00
|
|
|
if check_ssh_config; then
|
|
|
|
if ! check_ssh_target; then
|
|
|
|
echo "Starting kdump: [FAILED]"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
2013-03-05 08:07:37 +00:00
|
|
|
check_rebuild
|
2011-07-06 19:25:34 +00:00
|
|
|
if [ $? != 0 ]; then
|
2013-02-18 09:05:42 +00:00
|
|
|
echo "Starting kdump: [FAILED]"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 1
|
|
|
|
fi
|
2014-07-24 18:38:53 +00:00
|
|
|
|
|
|
|
start_dump
|
2011-07-06 19:25:34 +00:00
|
|
|
if [ $? != 0 ]; then
|
2013-02-18 09:05:42 +00:00
|
|
|
echo "Starting kdump: [FAILED]"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2013-02-18 09:05:42 +00:00
|
|
|
echo "Starting kdump: [OK]"
|
2011-07-06 19:25:34 +00:00
|
|
|
}
|
|
|
|
|
2014-07-24 18:39:00 +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
|
|
|
{
|
2014-09-08 15:35:21 +00:00
|
|
|
if is_secure_boot_enforced; then
|
|
|
|
$KEXEC -s -p -u
|
|
|
|
else
|
|
|
|
$KEXEC -p -u
|
|
|
|
fi
|
|
|
|
|
2014-07-24 18:39:00 +00:00
|
|
|
if [ $? != 0 ]; then
|
2014-07-15 06:41:54 +00:00
|
|
|
echo "kexec: failed to unload kdump kernel"
|
2014-07-24 18:39:00 +00:00
|
|
|
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
|
2013-02-18 09:05:42 +00:00
|
|
|
echo "Stopping kdump: [FAILED]"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 1
|
|
|
|
fi
|
2014-07-24 18:39:00 +00:00
|
|
|
|
|
|
|
echo "Stopping kdump: [OK]"
|
|
|
|
return 0
|
2011-07-06 19:25:34 +00:00
|
|
|
}
|
|
|
|
|
2012-04-28 10:01:18 +00:00
|
|
|
if [ ! -f "$KDUMP_CONFIG_FILE" ]; then
|
2013-02-18 09:05:42 +00:00
|
|
|
echo "Error: No kdump config file found!" >&2
|
2012-04-28 10:01:18 +00:00
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
2013-11-25 16:23:11 +00:00
|
|
|
main ()
|
|
|
|
{
|
2014-07-24 18:38:36 +00:00
|
|
|
# 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
|
2014-07-24 18:38:36 +00:00
|
|
|
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
|
|
|
;;
|
2013-11-25 16:23:11 +00:00
|
|
|
*)
|
|
|
|
echo $"Usage: $0 {start|stop|status|restart|propagate}"
|
|
|
|
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 $?
|