diff --git a/SOURCES/dracut-kdump-error-handler.service b/SOURCES/dracut-kdump-error-handler.service index 32b74ab..a23b75e 100644 --- a/SOURCES/dracut-kdump-error-handler.service +++ b/SOURCES/dracut-kdump-error-handler.service @@ -21,7 +21,6 @@ Environment=DRACUT_SYSTEMD=1 Environment=NEWROOT=/sysroot WorkingDirectory=/ ExecStart=/bin/kdump-error-handler.sh -ExecStopPost=-/usr/bin/systemctl --fail --no-block default Type=oneshot StandardInput=tty-force StandardOutput=inherit diff --git a/SOURCES/dracut-kdump.sh b/SOURCES/dracut-kdump.sh index cb22254..8752178 100755 --- a/SOURCES/dracut-kdump.sh +++ b/SOURCES/dracut-kdump.sh @@ -177,6 +177,7 @@ read_kdump_conf() [ -n "$config_val" ] && add_dump_code "dump_fs $config_val" ;; ext[234]|xfs|btrfs|minix|nfs) + config_val=$(get_mntpoint_from_target "$config_val") add_dump_code "dump_fs $config_val" ;; raw) diff --git a/SOURCES/dracut-module-setup.sh b/SOURCES/dracut-module-setup.sh index e7a2e63..7e1ac0b 100755 --- a/SOURCES/dracut-module-setup.sh +++ b/SOURCES/dracut-module-setup.sh @@ -279,13 +279,14 @@ kdump_setup_vlan() { # $1: netdev name kdump_setup_znet() { local _options="" + local _netdev=$1 - source_ifcfg_file $1 + source_ifcfg_file $_netdev for i in $OPTIONS; do _options=${_options},$i done - echo rd.znet=${NETTYPE},${SUBCHANNELS}${_options} > ${initdir}/etc/cmdline.d/30znet.conf + echo rd.znet=${NETTYPE},${SUBCHANNELS}${_options} rd.znet_ifname=$_netdev:${SUBCHANNELS} > ${initdir}/etc/cmdline.d/30znet.conf } # Setup dracut to bringup a given network interface @@ -333,6 +334,11 @@ kdump_setup_netdev() { fi kdump_setup_dns "$_netdev" + + if [ ! -f ${initdir}/etc/cmdline.d/50neednet.conf ]; then + # network-manager module needs this parameter + echo "rd.neednet" >> ${initdir}/etc/cmdline.d/50neednet.conf + fi } get_ip_route_field() @@ -389,24 +395,9 @@ default_dump_target_install_conf() is_user_configured_dump_target && return - _save_path=$(get_option_value "path") - [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH - - # strip the duplicated "/" - _save_path=$(echo $_save_path | tr -s /) - - _mntpoint=$(get_mntpoint_from_path $_save_path) + _save_path=$(get_bind_mount_source $(get_save_path)) _target=$(get_target_from_path $_save_path) - - if is_atomic && is_bind_mount $_mntpoint; then - _save_path=${_save_path##"$_mntpoint"} - # the real dump path in the 2nd kernel, if the mount point is bind mounted. - _save_path=$(get_bind_mount_directory $_mntpoint)/$_save_path - _mntpoint=$(get_mntpoint_from_target $_target) - - # the absolute path in the 1st kernel - _save_path=$_mntpoint/$_save_path - fi + _mntpoint=$(get_mntpoint_from_target $_target) _fstype=$(get_fs_type_from_target $_target) if is_fs_type_nfs $_fstype; then @@ -418,8 +409,6 @@ default_dump_target_install_conf() echo "$_fstype $_target" >> ${initdir}/tmp/$$-kdump.conf - # strip the duplicated "/" - _save_path=$(echo $_save_path | tr -s /) # don't touch the path under root mount if [ "$_mntpoint" != "/" ]; then _save_path=${_save_path##"$_mntpoint"} @@ -430,30 +419,6 @@ default_dump_target_install_conf() echo "path $_save_path" >> ${initdir}/tmp/$$-kdump.conf } -adjust_bind_mount_path() -{ - local _target=$1 - local _save_path=$(get_option_value "path") - [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH - - # strip the duplicated "/" - _save_path=$(echo $_save_path | tr -s /) - - local _absolute_save_path=$(get_mntpoint_from_target $_target)/$_save_path - _absolute_save_path=$(echo "$_absolute_save_path" | tr -s /) - local _mntpoint=$(get_mntpoint_from_path $_absolute_save_path) - - if is_bind_mount $_mntpoint; then - _save_path=${_absolute_save_path##"$_mntpoint"} - # the real dump path in the 2nd kernel, if the mount point is bind mounted. - _save_path=$(get_bind_mount_directory $_mntpoint)/$_save_path - - #erase the old path line, then insert the parsed path - sed -i "/^path/d" ${initdir}/tmp/$$-kdump.conf - echo "path $_save_path" >> ${initdir}/tmp/$$-kdump.conf - fi -} - #install kdump.conf and what user specifies in kdump.conf kdump_install_conf() { local _opt _val _pdev @@ -470,9 +435,6 @@ kdump_install_conf() { ext[234]|xfs|btrfs|minix) _pdev=$(kdump_get_persistent_dev $_val) sed -i -e "s#^$_opt[[:space:]]\+$_val#$_opt $_pdev#" ${initdir}/tmp/$$-kdump.conf - if is_atomic; then - adjust_bind_mount_path "$_val" - fi ;; ssh|nfs) kdump_install_net "$_val" @@ -659,7 +621,8 @@ get_alias() { ips=$(hostname -I) for ip in $ips do - entries=$(grep $ip /etc/hosts | awk '{ $1=$2=""; print $0 }') + # in /etc/hosts, alias can come at the 2nd column + entries=$(grep $ip /etc/hosts | awk '{ $1=""; print $0 }') if [ $? -eq 0 ]; then alias_set="$alias_set $entries" fi diff --git a/SOURCES/early-kdump-howto.txt b/SOURCES/early-kdump-howto.txt index b8cab6a..68b23c7 100644 --- a/SOURCES/early-kdump-howto.txt +++ b/SOURCES/early-kdump-howto.txt @@ -3,12 +3,17 @@ Early Kdump HOWTO Introduction ------------ -Kdump service starts too late, so early crashes will have no chance to get -kdump kernel booting, this will cause crash information to be lost. It is -necessary to add a dracut module in order to load crash kernel and initramfs -as early as possible. You can provide "rd.earlykdump" in grub commandline -to enable, then the early kdump will load those files like the normal kdump, -which is disabled by default. +Early kdump is a mechanism to make kdump operational earlier than normal kdump +service. The kdump service starts early enough for general crash cases, but +there are some cases where it has no chance to make kdump operational in boot +sequence, such as detecting devices and starting early services. If you hit +such a case, early kdump may allow you to get more information of it. + +Early kdump is implemented as a dracut module. It adds a kernel (vmlinuz) and +initramfs for kdump to your system's initramfs in order to load them as early +as possible. After that, if you provide "rd.earlykdump" in kernel command line, +then in the initramfs, early kdump will load those files like the normal kdump +service. This is disabled by default. For the normal kdump service, it can check whether the early kdump has loaded the crash kernel and initramfs. It has no conflict with the early kdump. @@ -20,7 +25,9 @@ We assume if you're reading this document, you should already have kexec-tools installed. You can rebuild the initramfs with earlykdump support with below steps: + 1. start kdump service to make sure kdump initramfs is created. + # systemctl start kdump NOTE: If a crash occurs during boot process, early kdump captures a vmcore @@ -34,20 +41,13 @@ You can rebuild the initramfs with earlykdump support with below steps: For the failure_action, you can choose anything other than "reboot". 2. rebuild system initramfs with earlykdump support. - # dracut --add earlykdump -3. add rd.earlykdump in grub kernel command line. + # dracut --force --add earlykdump -Note: -[1]. Early kdump initramfs size will be large because it includes vmlinuz and -kdump initramfs. And for step 2 if you are sure to overwrite system initramfs -you can backup the original initramfs and use "--force" option. + NOTE: Recommend to backup the original system initramfs before performing + this step to put it back if something happens during boot-up. -[2]. Early kdump inherits the settings of normal kdump, so any changes that -caused normal kdump rebuilding also require rebuilding the system initramfs -to make sure that the changes take effect for early kdump. Therefore, after -the rebuilding of kdump initramfs is completed, provide a prompt message to -tell the fact. +3. add rd.earlykdump in grub kernel command line. After making said changes, reboot your system to take effect. Of course, if you want to disable early kdump, you can simply remove "rd.earlykdump" from kernel @@ -56,19 +56,40 @@ boot parameters in grub, and reboot system like above. Once the boot is completed, you can check the status of the early kdump support on the command prompt: - # journalctl -x|grep early-kdump + # journalctl -b | grep early-kdump + +Then, you will see some useful logs, for example: + +- if early kdump is successful. -Then, you will see some useful logs, for exapmle: +Mar 09 09:57:56 localhost dracut-cmdline[190]: early-kdump is enabled. +Mar 09 09:57:56 localhost dracut-cmdline[190]: kexec: loaded early-kdump kernel -1. if early kdump is successful. -Mar 09 09:57:56 localhost.localdomain dracut-cmdline[190]: early-kdump is enabled. -Mar 09 09:57:56 localhost.localdomain dracut-cmdline[190]: kexec: loaded early- -kdump kernel +- if early kdump is disabled. -2. if early kdump is disabled. -Mar 09 10:02:47 localhost.localdomain dracut-cmdline[189]: early-kdump is disabled. +Mar 09 10:02:47 localhost dracut-cmdline[189]: early-kdump is disabled. + +Notes +----- + +- The size of early kdump initramfs will be large because it includes vmlinuz + and kdump initramfs. + +- Early kdump inherits the settings of normal kdump, so any changes that + caused normal kdump rebuilding also require rebuilding the system initramfs + to make sure that the changes take effect for early kdump. Therefore, after + the rebuilding of kdump initramfs is completed, provide a prompt message to + tell the fact. + +- If you install an updated kernel and reboot the system with it, the early + kdump will be disabled by default. To enable it with the new kernel, you + need to take the above steps again. Limitation ---------- -At present, early kdump doesn't support fadump. +- At present, early kdump doesn't support fadump. + +- Early kdump loads a crash kernel and initramfs at the beginning of the + process in system's initramfs, so a crash at earlier than that (e.g. in + kernel initialization) cannot be captured even with the early kdump. diff --git a/SOURCES/fadump-howto.txt b/SOURCES/fadump-howto.txt new file mode 100644 index 0000000..c891e37 --- /dev/null +++ b/SOURCES/fadump-howto.txt @@ -0,0 +1,338 @@ +Firmware assisted dump (fadump) HOWTO + +Introduction + +Firmware assisted dump is a new feature in the 3.4 mainline kernel supported +only on powerpc architecture. The goal of firmware-assisted dump is to enable +the dump of a crashed system, and to do so from a fully-reset system, and to +minimize the total elapsed time until the system is back in production use. A +complete documentation on implementation can be found at +Documentation/powerpc/firmware-assisted-dump.txt in upstream linux kernel tree +from 3.4 version and above. + +Please note that the firmware-assisted dump feature is only available on Power6 +and above systems with recent firmware versions. + +Overview + +Fadump + +Fadump is a robust kernel crash dumping mechanism to get reliable kernel crash +dump with assistance from firmware. This approach does not use kexec, instead +firmware assists in booting the kdump kernel while preserving memory contents. +Unlike kdump, the system is fully reset, and loaded with a fresh copy of the +kernel. In particular, PCI and I/O devices are reinitialized and are in a +clean, consistent state. This second kernel, often called a capture kernel, +boots with very little memory and captures the dump image. + +The first kernel registers the sections of memory with the Power firmware for +dump preservation during OS initialization. These registered sections of memory +are reserved by the first kernel during early boot. When a system crashes, the +Power firmware fully resets the system, preserves all the system memory +contents, save the low memory (boot memory of size larger of 5% of system +RAM or 256MB) of RAM to the previous registered region. It will also save +system registers, and hardware PTE's. + +Fadump is supported only on ppc64 platform. The standard kernel and capture +kernel are one and the same on ppc64. + +If you're reading this document, you should already have kexec-tools +installed. If not, you install it via the following command: + + # yum install kexec-tools + +Fadump Operational Flow: + +Like kdump, fadump also exports the ELF formatted kernel crash dump through +/proc/vmcore. Hence existing kdump infrastructure can be used to capture fadump +vmcore. The idea is to keep the functionality transparent to end user. From +user perspective there is no change in the way kdump init script works. + +However, unlike kdump, fadump does not pre-load kdump kernel and initrd into +reserved memory, instead it always uses default OS initrd during second boot +after crash. Hence, for fadump, we rebuild the new kdump initrd and replace it +with default initrd. Before replacing existing default initrd we take a backup +of original default initrd for user's reference. The dracut package has been +enhanced to rebuild the default initrd with vmcore capture steps. The initrd +image is rebuilt as per the configuration in /etc/kdump.conf file. + +The control flow of fadump works as follows: +01. System panics. +02. At the crash, kernel informs power firmware that kernel has crashed. +03. Firmware takes the control and reboots the entire system preserving + only the memory (resets all other devices). +04. The reboot follows the normal booting process (non-kexec). +05. The boot loader loads the default kernel and initrd from /boot +06. The default initrd loads and runs /init +07. dracut-kdump.sh script present in fadump aware default initrd checks if + '/proc/device-tree/rtas/ibm,kernel-dump' file exists before executing + steps to capture vmcore. + (This check will help to bypass the vmcore capture steps during normal boot + process.) +09. Captures dump according to /etc/kdump.conf +10. Is dump capture successful (yes goto 12, no goto 11) +11. Perform the failure action specified in /etc/kdump.conf + (The default failure action is reboot, if unspecified) +12. Perform the final action specified in /etc/kdump.conf + (The default final action is reboot, if unspecified) + + +How to configure fadump: + +Again, we assume if you're reading this document, you should already have +kexec-tools installed. If not, you install it via the following command: + + # yum install kexec-tools + +Make the kernel to be configured with FADump as the default boot entry, if +it isn't already: + + # grubby --set-default=/boot/vmlinuz- + +Boot into the kernel to be configured for FADump. To be able to do much of +anything interesting in the way of debug analysis, you'll also need to install +the kernel-debuginfo package, of the same arch as your running kernel, and the +crash utility: + + # yum --enablerepo=\*debuginfo install kernel-debuginfo.$(uname -m) crash + +Next up, we need to modify some boot parameters to enable firmware assisted +dump. With the help of grubby, it's very easy to append "fadump=on" to the end +of your kernel boot parameters. To reserve the appropriate amount of memory +for boot memory preservation, pass 'crashkernel=X' kernel cmdline parameter. +For the recommended value of X, see 'FADump Memory Requirements' section. + + # grubby --args="fadump=on crashkernel=6G" --update-kernel=/boot/vmlinuz-`uname -r` + +The term 'boot memory' means size of the low memory chunk that is required for +a kernel to boot successfully when booted with restricted memory. By default, +the boot memory size will be the larger of 5% of system RAM or 256MB. +Alternatively, user can also specify boot memory size through boot parameter +'fadump_reserve_mem=' which will override the default calculated size. Use this +option if default boot memory size is not sufficient for second kernel to boot +successfully. + +After making said changes, reboot your system, so that the specified memory is +reserved and left untouched by the normal system. Take note that the output of +'free -m' will show X MB less memory than without this parameter, which is +expected. If you see OOM (Out Of Memory) error messages while loading capture +kernel, then you should bump up the memory reservation size. + +Now that you've got that reserved memory region set up, you want to turn on +the kdump init script: + + # systemctl enable kdump.service + +Then, start up kdump as well: + + # systemctl start kdump.service + +This should turn on the firmware assisted functionality in kernel by +echo'ing 1 to /sys/kernel/fadump_registered, leaving the system ready +to capture a vmcore upon crashing. For journaling filesystems like XFS an +additional step is required to ensure bootloader does not pick the +older initrd (without vmcore capture scripts): + + * If /boot is a separate partition, run the below commands as the root user, + or as a user with CAP_SYS_ADMIN rights: + + # fsfreeze -f + # fsfreeze -u + + * If /boot is not a separate partition, reboot the system. + +After reboot check if the kdump service is up and running with: + + # systemctl status kdump.service + +To test out whether FADump is configured properly, you can force-crash your +system by echo'ing a 'c' into /proc/sysrq-trigger: + + # echo c > /proc/sysrq-trigger + +You should see some panic output, followed by the system reset and booting into +fresh copy of kernel. When default initrd loads and runs /init, vmcore should +be copied out to disk (by default, in /var/crash//vmcore), +then the system rebooted back into your normal kernel. + +Once back to your normal kernel, you can use the previously installed crash +kernel in conjunction with the previously installed kernel-debuginfo to +perform postmortem analysis: + + # crash /usr/lib/debug/lib/modules/2.6.17-1.2621.el5/vmlinux + /var/crash/2006-08-23-15:34/vmcore + + crash> bt + +and so on... + +Saving vmcore-dmesg.txt +----------------------- +Kernel log bufferes are one of the most important information available +in vmcore. Now before saving vmcore, kernel log bufferes are extracted +from /proc/vmcore and saved into a file vmcore-dmesg.txt. After +vmcore-dmesg.txt, vmcore is saved. Destination disk and directory for +vmcore-dmesg.txt is same as vmcore. Note that kernel log buffers will +not be available if dump target is raw device. + +FADump Memory Requirements: + + System Memory Recommended memory +--------------------- ---------------------- + 4 GB - 16 GB : 768 MB + 16 GB - 64 GB : 1024 MB + 64 GB - 128 GB : 2 GB + 128 GB - 1 TB : 4 GB + 1 TB - 2 TB : 6 GB + 2 TB - 4 TB : 12 GB + 4 TB - 8 TB : 20 GB + 8 TB - 16 TB : 36 GB + 16 TB - 32 TB : 64 GB + 32 TB - 64 TB : 128 GB + 64 TB & above : 180 GB + +Things to remember: + +1) The memory required to boot capture Kernel is a moving target that depends + on many factors like hardware attached to the system, kernel and modules in + use, packages installed and services enabled, there is no one-size-fits-all. + But the above recommendations are based on system memory. So, the above + recommendations for FADump come with a few assumptions, based on available + system memory, about the resources the system could have. So, please take + the recommendations with a pinch of salt and remember to try capturing dump + a few times to confirm that the system is configured successfully with dump + capturing support. + +2) Though the memory requirements for FADump seem high, this memory is not + completely set aside but made available for userspace applications to use, + through the CMA allocator. + +3) As the same initrd is used for booting production kernel as well as capture + kernel and with dump being captured in a restricted memory environment, few + optimizations (like not inclding network dracut module, disabling multipath + and such) are applied while building the initrd. In case, the production + environment needs these optimizations to be avoided, dracut_args option in + /etc/kdump.conf file could be leveraged. For example, if a user wishes for + network module to be included in the initrd, adding the below entry in + /etc/kdump.conf file and restarting kdump service would take care of it. + + dracut_args --add "network" + +4) If FADump is configured to capture vmcore to a remote dump target using SSH + or NFS protocol, the network interface is renamed to kdump- + if is generic, for example, *eth#, or net#. This problem + occurs because the vmcore capture scripts in the initial RAM disk (initrd) + add the kdump- prefix to the network interface name to secure persistent + naming. As the same initrd is used for production kernel boot, the interface + name is changed for the production kernel too. + +Dump Triggering methods: + +This section talks about the various ways, other than a Kernel Panic, in which +fadump can be triggered. The following methods assume that fadump is configured +on your system, with the scripts enabled as described in the section above. + +1) AltSysRq C + +FAdump can be triggered with the combination of the 'Alt','SysRq' and 'C' +keyboard keys. Please refer to the following link for more details: + +https://fedoraproject.org/wiki/QA/Sysrq + +In addition, on PowerPC boxes, fadump can also be triggered via Hardware +Management Console(HMC) using 'Ctrl', 'O' and 'C' keyboard keys. + +2) Kernel OOPs + +If we want to generate a dump everytime the Kernel OOPses, we can achieve this +by setting the 'Panic On OOPs' option as follows: + + # echo 1 > /proc/sys/kernel/panic_on_oops + +3) PowerPC specific methods: + +On IBM PowerPC machines, issuing a soft reset invokes the XMON debugger(if +XMON is configured). To configure XMON one needs to compile the kernel with +the CONFIG_XMON and CONFIG_XMON_DEFAULT options, or by compiling with +CONFIG_XMON and booting the kernel with xmon=on option. + +Following are the ways to remotely issue a soft reset on PowerPC boxes, which +would drop you to XMON. Pressing a 'X' (capital alphabet X) followed by an +'Enter' here will trigger the dump. + +3.1) HMC + +Hardware Management Console(HMC) available on Power4 and Power5 machines allow +partitions to be reset remotely. This is specially useful in hang situations +where the system is not accepting any keyboard inputs. + +Once you have HMC configured, the following steps will enable you to trigger +fadump via a soft reset: + +On Power4 + Using GUI + + * In the right pane, right click on the partition you wish to dump. + * Select "Operating System->Reset". + * Select "Soft Reset". + * Select "Yes". + + Using HMC Commandline + + # reset_partition -m -p -t soft + +On Power5 + Using GUI + + * In the right pane, right click on the partition you wish to dump. + * Select "Restart Partition". + * Select "Dump". + * Select "OK". + + Using HMC Commandline + + # chsysstate -m -n -o dumprestart -r lpar + +3.2) Blade Management Console for Blade Center + +To initiate a dump operation, go to Power/Restart option under "Blade Tasks" in +the Blade Management Console. Select the corresponding blade for which you want +to initate the dump and then click "Restart blade with NMI". This issues a +system reset and invokes xmon debugger. + + +Advanced Setups & Failure action: + +Kdump and fadump exhibit similar behavior in terms of setup & failure action. +For fadump advanced setup related information see section "Advanced Setups" in +"kexec-kdump-howto.txt" document. Refer to "Failure action" section in "kexec- +kdump-howto.txt" document for fadump failure action related information. + +Compression and filtering + +Refer "Compression and filtering" section in "kexec-kdump-howto.txt" document. +Compression and filtering are same for kdump & fadump. + + +Notes on rootfs mount: +Dracut is designed to mount rootfs by default. If rootfs mounting fails it +will refuse to go on. So fadump leaves rootfs mounting to dracut currently. +We make the assumtion that proper root= cmdline is being passed to dracut +initramfs for the time being. If you need modify "KDUMP_COMMANDLINE=" in +/etc/sysconfig/kdump, you will need to make sure that appropriate root= +options are copied from /proc/cmdline. In general it is best to append +command line options using "KDUMP_COMMANDLINE_APPEND=" instead of replacing +the original command line completely. + +How to disable FADump: + +Remove "fadump=on" from kernel cmdline parameters: + + # grubby --update-kernel=/boot/vmlinuz-`uname -r` --remove-args="fadump=on" + +If KDump is to be used as the dump capturing mechanism, update the crashkernel +parameter (Else, remove "crashkernel=" parameter too, using grubby): + + # grubby --update-kernel=/boot/vmlinuz-$kver --args="crashkernl=auto" + +Reboot the system for the settings to take effect. diff --git a/SOURCES/kdump-lib-initramfs.sh b/SOURCES/kdump-lib-initramfs.sh index a1ee9cd..2a7b613 100755 --- a/SOURCES/kdump-lib-initramfs.sh +++ b/SOURCES/kdump-lib-initramfs.sh @@ -94,20 +94,16 @@ get_kdump_confs() fi } -# dump_fs +# dump_fs dump_fs() { - local _do_umount="" - local _dev=$(findmnt -k -f -n -r -o SOURCE $1) - local _mp=$(findmnt -k -f -n -r -o TARGET $1) - local _op=$(findmnt -k -f -n -r -o OPTIONS $1) + local _mp=$1 + local _dev=$(get_mount_info SOURCE target $_mp -f) + local _op=$(get_mount_info OPTIONS target $_mp -f) - if [ -z "$_mp" ]; then - _dev=$(findmnt -s -f -n -r -o SOURCE $1) - _mp=$(findmnt -s -f -n -r -o TARGET $1) - _op=$(findmnt -s -f -n -r -o OPTIONS $1) - - if [ -n "$_dev" ] && [ -n "$_mp" ]; then + # If dump path have a corresponding device entry but not mounted, mount it. + if [ -n "$_dev" ] || [ "$_dev" == "rootfs" ]; then + if ! is_mounted "$_mp"; then echo "kdump: dump target $_dev is not mounted, trying to mount..." mkdir -p $_mp mount -o $_op $_dev $_mp @@ -116,12 +112,10 @@ dump_fs() echo "kdump: mounting failed (mount point: $_mp, option: $_op)" return 1 fi - _do_umount=1 - else - echo "kdump: error: Dump target $_dev is not usable" fi else - echo "kdump: dump target is $_dev" + echo "kdump: failed to dump to \"$_mp\", it's not a mount point!" + return 1 fi # Remove -F in makedumpfile case. We don't want a flat format dump here. @@ -142,10 +136,6 @@ dump_fs() echo "kdump: saving vmcore complete" - if [ $_do_umount ]; then - umount $_mp || echo "kdump: warn: failed to umount target" - fi - # improper kernel cmdline can cause the failure of echo, we can ignore this kind of failure return 0 } diff --git a/SOURCES/kdump-lib.sh b/SOURCES/kdump-lib.sh index ef0151f..83d7779 100755 --- a/SOURCES/kdump-lib.sh +++ b/SOURCES/kdump-lib.sh @@ -121,21 +121,16 @@ get_user_configured_dump_disk() get_root_fs_device() { - local _target - _target=$(findmnt -k -f -n -o SOURCE /) - [ -n "$_target" ] && echo $_target - - return + findmnt -k -f -n -o SOURCE / } get_save_path() { - local _save_path=$(grep "^path" /etc/kdump.conf|awk '{print $2}') - if [ -z "$_save_path" ]; then - _save_path=$DEFAULT_PATH - fi + local _save_path=$(awk '$1 == "path" {print $2}' /etc/kdump.conf) + [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH - echo $_save_path + # strip the duplicated "/" + echo $_save_path | tr -s / } get_block_dump_target() @@ -197,44 +192,39 @@ get_kdump_targets() echo "$kdump_targets" } - +# Return the bind mount source path, return the path itself if it's not bind mounted +# Eg. if /path/to/src is bind mounted to /mnt/bind, then: +# /mnt/bind -> /path/to/src, /mnt/bind/dump -> /path/to/src/dump +# # findmnt uses the option "-v, --nofsroot" to exclusive the [/dir] # in the SOURCE column for bind-mounts, then if $_mntpoint equals to # $_mntpoint_nofsroot, the mountpoint is not bind mounted directory. -is_bind_mount() -{ - local _mntpoint=$(findmnt $1 | tail -n 1 | awk '{print $2}') - local _mntpoint_nofsroot=$(findmnt -v $1 | tail -n 1 | awk '{print $2}') - - if [[ $_mntpoint = $_mntpoint_nofsroot ]]; then - return 1 - else - return 0 - fi -} - +# # Below is just an example for mount info # /dev/mapper/atomicos-root[/ostree/deploy/rhel-atomic-host/var], if the # directory is bind mounted. The former part represents the device path, rest # part is the bind mounted directory which quotes by bracket "[]". -get_bind_mount_directory() +get_bind_mount_source() { - local _mntpoint=$(findmnt $1 | tail -n 1 | awk '{print $2}') - local _mntpoint_nofsroot=$(findmnt -v $1 | tail -n 1 | awk '{print $2}') + local _path=$1 + # In case it's a sub path in a mount point, get the mount point first + local _mnt_top=$(df $_path | tail -1 | awk '{print $NF}') + local _mntpoint=$(findmnt $_mnt_top | tail -n 1 | awk '{print $2}') + local _mntpoint_nofsroot=$(findmnt -v $_mnt_top | tail -n 1 | awk '{print $2}') - _mntpoint=${_mntpoint#*$_mntpoint_nofsroot} + if [[ "$_mntpoint" = $_mntpoint_nofsroot ]]; then + echo $_path && return + fi + _mntpoint=${_mntpoint#*$_mntpoint_nofsroot} _mntpoint=${_mntpoint#[} _mntpoint=${_mntpoint%]} + _path=${_path#$_mnt_top} - echo $_mntpoint -} - -get_mntpoint_from_path() -{ - echo $(df $1 | tail -1 | awk '{print $NF}') + echo $_mntpoint$_path } +# Return the current underlaying device of a path, ignore bind mounts get_target_from_path() { local _target @@ -244,73 +234,65 @@ get_target_from_path() echo $_target } -get_fs_type_from_target() +is_mounted() { - echo $(findmnt -k -f -n -r -o FSTYPE $1) + findmnt -k -n $1 &>/dev/null } -# input: device path -# output: the general mount point -# find the general mount point, not the bind mounted point in atomic -# As general system, Use the previous code -# -# ERROR and EXIT: -# the device can be umounted the general mount point, if one of the mount point is bind mounted -# For example: -# mount /dev/sda /mnt/ -# mount -o bind /mnt/var /var -# umount /mnt -get_mntpoint_from_target() +get_mount_info() { - if is_atomic; then - for _mnt in $(findmnt -k -n -r -o TARGET $1) - do - if ! is_bind_mount $_mnt; then - echo $_mnt - return - fi - done + local _info_type=$1 _src_type=$2 _src=$3; shift 3 + local _info=$(findmnt -k -n -r -o $_info_type --$_src_type $_src $@) - echo "Mount $1 firstly, without the bind mode" >&2 - exit 1 - else - echo $(findmnt -k -f -n -r -o TARGET $1) - fi -} + [ -z "$_info" ] && [ -e "/etc/fstab" ] && _info=$(findmnt -s -n -r -o $_info_type --$_src_type $_src $@) -# get_option_value -# retrieves value of option defined in kdump.conf -get_option_value() { - echo $(strip_comments `grep "^$1[[:space:]]\+" /etc/kdump.conf | tail -1 | cut -d\ -f2-`) + echo $_info } -#This function compose a absolute path with the mount -#point and the relative $SAVE_PATH. -#target is passed in as argument, could be UUID, LABEL, -#block device or even nfs server export of the form of -#"my.server.com:/tmp/export"? -#And possibly this could be used for both default case -#as well as when dump taret is specified. When dump -#target is not specified, then $target would be null. -make_absolute_save_path() +get_fs_type_from_target() { - local _target=$1 - local _mnt - - [ -n $_target ] && _mnt=$(get_mntpoint_from_target $1) - _mnt="${_mnt}/$SAVE_PATH" + get_mount_info FSTYPE source $1 -f +} - # strip the duplicated "/" - echo "$_mnt" | tr -s / +get_mntopt_from_target() +{ + get_mount_info OPTIONS source $1 -f +} +# Find the general mount point of a dump target, not the bind mount point +get_mntpoint_from_target() +{ + # Expcilitly specify --source to findmnt could ensure non-bind mount is returned + get_mount_info TARGET source $1 -f } -check_save_path_fs() +# Get the path where the target will be mounted in kdump kernel +# $1: kdump target device +get_kdump_mntpoint_from_target() { - local _path=$1 + local _mntpoint=$(get_mntpoint_from_target $1) - if [ ! -d $_path ]; then - perror_exit "Dump path $_path does not exist." + # mount under /sysroot if dump to root disk or mount under + # mount under /kdumproot if dump target is not mounted in first kernel + # mount under /kdumproot/$_mntpoint in other cases in 2nd kernel. + # systemd will be in charge to umount it. + if [ -z "$_mntpoint" ];then + _mntpoint="/kdumproot" + else + if [ "$_mntpoint" = "/" ];then + _mntpoint="/sysroot" + else + _mntpoint="/kdumproot/$_mntpoint" + fi fi + + # strip duplicated "/" + echo $_mntpoint | tr -s "/" +} + +# get_option_value +# retrieves value of option defined in kdump.conf +get_option_value() { + strip_comments `grep "^$1[[:space:]]\+" /etc/kdump.conf | tail -1 | cut -d\ -f2-` } is_atomic() diff --git a/SOURCES/kdump.sysconfig b/SOURCES/kdump.sysconfig index df518d6..7c5641a 100644 --- a/SOURCES/kdump.sysconfig +++ b/SOURCES/kdump.sysconfig @@ -17,7 +17,7 @@ KDUMP_COMMANDLINE="" # This variable lets us remove arguments from the current kdump commandline # as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline # NOTE: some arguments such as crashkernel will always be removed -KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet" +KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len" # This variable lets us append arguments to the current kdump commandline # after processed by KDUMP_COMMANDLINE_REMOVE diff --git a/SOURCES/kdump.sysconfig.aarch64 b/SOURCES/kdump.sysconfig.aarch64 index d5d7624..6f55c03 100644 --- a/SOURCES/kdump.sysconfig.aarch64 +++ b/SOURCES/kdump.sysconfig.aarch64 @@ -17,7 +17,7 @@ KDUMP_COMMANDLINE="" # This variable lets us remove arguments from the current kdump commandline # as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline # NOTE: some arguments such as crashkernel will always be removed -KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet" +KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb" # This variable lets us append arguments to the current kdump commandline # after processed by KDUMP_COMMANDLINE_REMOVE diff --git a/SOURCES/kdump.sysconfig.i386 b/SOURCES/kdump.sysconfig.i386 index 976aea6..84f0df1 100644 --- a/SOURCES/kdump.sysconfig.i386 +++ b/SOURCES/kdump.sysconfig.i386 @@ -17,7 +17,7 @@ KDUMP_COMMANDLINE="" # This variable lets us remove arguments from the current kdump commandline # as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline # NOTE: some arguments such as crashkernel will always be removed -KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet" +KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb" # This variable lets us append arguments to the current kdump commandline # after processed by KDUMP_COMMANDLINE_REMOVE diff --git a/SOURCES/kdump.sysconfig.ppc64 b/SOURCES/kdump.sysconfig.ppc64 index 6ddfc3d..7ce41e3 100644 --- a/SOURCES/kdump.sysconfig.ppc64 +++ b/SOURCES/kdump.sysconfig.ppc64 @@ -17,7 +17,7 @@ KDUMP_COMMANDLINE="" # This variable lets us remove arguments from the current kdump commandline # as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline # NOTE: some arguments such as crashkernel will always be removed -KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet" +KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb" # This variable lets us append arguments to the current kdump commandline # after processed by KDUMP_COMMANDLINE_REMOVE diff --git a/SOURCES/kdump.sysconfig.ppc64le b/SOURCES/kdump.sysconfig.ppc64le index 6ddfc3d..7ce41e3 100644 --- a/SOURCES/kdump.sysconfig.ppc64le +++ b/SOURCES/kdump.sysconfig.ppc64le @@ -17,7 +17,7 @@ KDUMP_COMMANDLINE="" # This variable lets us remove arguments from the current kdump commandline # as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline # NOTE: some arguments such as crashkernel will always be removed -KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet" +KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb" # This variable lets us append arguments to the current kdump commandline # after processed by KDUMP_COMMANDLINE_REMOVE diff --git a/SOURCES/kdump.sysconfig.s390x b/SOURCES/kdump.sysconfig.s390x index 68705f9..de0ac49 100644 --- a/SOURCES/kdump.sysconfig.s390x +++ b/SOURCES/kdump.sysconfig.s390x @@ -17,7 +17,7 @@ KDUMP_COMMANDLINE="" # This variable lets us remove arguments from the current kdump commandline # as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline # NOTE: some arguments such as crashkernel will always be removed -KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet" +KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb" # This variable lets us append arguments to the current kdump commandline # after processed by KDUMP_COMMANDLINE_REMOVE diff --git a/SOURCES/kdump.sysconfig.x86_64 b/SOURCES/kdump.sysconfig.x86_64 index e4aafc9..96ac7be 100644 --- a/SOURCES/kdump.sysconfig.x86_64 +++ b/SOURCES/kdump.sysconfig.x86_64 @@ -17,7 +17,7 @@ KDUMP_COMMANDLINE="" # This variable lets us remove arguments from the current kdump commandline # as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline # NOTE: some arguments such as crashkernel will always be removed -KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet" +KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb" # This variable lets us append arguments to the current kdump commandline # after processed by KDUMP_COMMANDLINE_REMOVE diff --git a/SOURCES/kdumpctl b/SOURCES/kdumpctl index 89030dd..a542b54 100755 --- a/SOURCES/kdumpctl +++ b/SOURCES/kdumpctl @@ -471,17 +471,7 @@ check_dump_fs_modified() fi fi - if ! findmnt $_target >/dev/null; then - echo "Dump target $_target is probably not mounted." - return 2 - fi - - if [[ "$_target" = "$(get_root_fs_device)" ]]; then - _new_mntpoint="/sysroot" - else - _new_mntpoint="/kdumproot/$(get_mntpoint_from_target $_target)" - fi - + _new_mntpoint="$(get_kdump_mntpoint_from_target $_target)" _dracut_args=$(lsinitrd $TARGET_INITRD -f usr/lib/dracut/build-parameter.txt) if [[ -z "$_dracut_args" ]];then echo "Warning: No dracut arguments found in initrd" @@ -887,15 +877,6 @@ save_raw() return 0 } -is_dump_target_configured() -{ - local _target - - _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw|^ssh|^nfs" /etc/kdump.conf) - - [ -n "$_target" ] -} - local_fs_dump_target() { local _target @@ -910,11 +891,15 @@ path_to_be_relabeled() { local _path _target _mnt="/" _rmnt - if is_dump_target_configured; then + if is_user_configured_dump_target; then + if is_mount_in_dracut_args; then + return; + fi + _target=$(local_fs_dump_target) if [[ -n "$_target" ]]; then - _mnt=$(findmnt -k -f -n -r -o TARGET $_target) - if [ -z "$_mnt" ]; then + _mnt=$(get_mntpoint_from_target $_target) + if ! is_mounted "$_mnt"; then return fi else @@ -922,9 +907,6 @@ path_to_be_relabeled() fi fi - if is_mount_in_dracut_args; then - return; - fi _path=$(get_save_path) # if $_path is masked by other mount, we will not relabel it. _rmnt=$(df $_mnt/$_path 2>/dev/null | tail -1 | awk '{ print $NF }') diff --git a/SOURCES/kexec-kdump-howto.txt b/SOURCES/kexec-kdump-howto.txt index 0da938e..4b15dd0 100644 --- a/SOURCES/kexec-kdump-howto.txt +++ b/SOURCES/kexec-kdump-howto.txt @@ -1,15 +1,22 @@ +================= Kexec/Kdump HOWTO +================= + Introduction +============ Kexec and kdump are new features in the 2.6 mainstream kernel. These features are included in Red Hat Enterprise Linux 5. The purpose of these features is to ensure faster boot up and creation of reliable kernel vmcores for diagnostic purposes. + Overview +======== Kexec +----- Kexec is a fastboot mechanism which allows booting a Linux kernel from the context of already running kernel without going through BIOS. BIOS can be very @@ -17,6 +24,7 @@ time consuming especially on the big servers with lots of peripherals. This can save a lot of time for developers who end up booting a machine numerous times. Kdump +----- Kdump is a new kernel crash dumping mechanism and is very reliable because the crash dump is captured from the context of a freshly booted kernel and @@ -52,7 +60,8 @@ Now reboot your system, taking note that it should bypass the BIOS: # reboot -How to configure kdump: +How to configure kdump +====================== Again, we assume if you're reading this document, you should already have kexec-tools installed. If not, you install it via the following command: @@ -136,7 +145,9 @@ perform postmortem analysis: and so on... -Notes: + +Notes on kdump +============== When kdump starts, the kdump kernel is loaded together with the kdump initramfs. To save memory usage and disk space, the kdump initramfs is @@ -152,8 +163,10 @@ recommended to rebuild the initramfs manually with following command: # kdumpctl rebuild + Saving vmcore-dmesg.txt ----------------------- +======================= + Kernel log bufferes are one of the most important information available in vmcore. Now before saving vmcore, kernel log bufferes are extracted from /proc/vmcore and saved into a file vmcore-dmesg.txt. After @@ -161,7 +174,9 @@ vmcore-dmesg.txt, vmcore is saved. Destination disk and directory for vmcore-dmesg.txt is same as vmcore. Note that kernel log buffers will not be available if dump target is raw device. -Dump Triggering methods: + +Dump Triggering methods +======================= This section talks about the various ways, other than a Kernel Panic, in which Kdump can be triggered. The following methods assume that Kdump is configured @@ -268,7 +283,8 @@ to initate the dump and then click "Restart blade with NMI". This issues a system reset and invokes xmon debugger. -Advanced Setups: +Dump targets +============ In addition to being able to capture a vmcore to your system's local file system, kdump can be configured to capture a vmcore to a number of other @@ -276,7 +292,8 @@ locations, including a raw disk partition, a dedicated file system, an NFS mounted file system, or a remote system via ssh/scp. Additional options exist for specifying the relative path under which the dump is captured, what to do if the capture fails, and for compressing and filtering the dump -(so as to produce smaller, more manageable, vmcore files). +(so as to produce smaller, more manageable, vmcore files, see "Advanced Setups" +for more detail on these options). In theory, dumping to a location other than the local file system should be safer than kdump's default setup, as its possible the default setup will try @@ -289,32 +306,133 @@ as allowing for the centralization of vmcore files, should you have several systems from which you'd like to obtain vmcore files. Of course, note that these configurations could present problems if your network is unreliable. -Advanced setups are configured via modifications to /etc/kdump.conf, -which out of the box, is fairly well documented itself. Any alterations to -/etc/kdump.conf should be followed by a restart of the kdump service, so -the changes can be incorporated in the kdump initrd. Restarting the kdump -service is as simple as '/sbin/systemctl restart kdump.service'. - - -Note that kdump.conf is used as a configuration mechanism for capturing dump -files from the initramfs (in the interests of safety), the root file system is -mounted, and the init process is started, only as a last resort if the -initramfs fails to capture the vmcore. As such, configuration made in -/etc/kdump.conf is only applicable to capture recorded in the initramfs. If -for any reason the init process is started on the root file system, only a -simple copying of the vmcore from /proc/vmcore to /var/crash/$DATE/vmcore will -be preformed. - -For both local filesystem and nfs dump the dump target must be mounted before -building kdump initramfs. That means one needs to put an entry for the dump -file system in /etc/fstab so that after reboot when kdump service starts, -it can find the dump target and build initramfs instead of failing. +Kdump target and advanced setups are configured via modifications to +/etc/kdump.conf, which out of the box, is fairly well documented itself. +Any alterations to /etc/kdump.conf should be followed by a restart of the +kdump service, so the changes can be incorporated in the kdump initrd. +Restarting the kdump service is as simple as '/sbin/systemctl restart kdump.service'. + +There are two ways to config the dump target, config dump target only +using "path", and config dump target explicitly. Interpretation of "path" +also differs in two config styles. + +Config dump target only using "path" +------------------------------------ + +You can change the dump target by setting "path" to a mount point where +dump target is mounted. When there is no explicitly configured dump target, +"path" in kdump.conf represents the current file system path in which vmcore +will be saved. Kdump will automatically detect the underlying device of +"path" and use that as the dump target. + +In fact, upon dump, kdump creates a directory $hostip-$date with-in "path" +and saves vmcore there. So practically dump is saved in $path/$hostip-$date/. + +Kdump will only check current mount status for mount entry corresponding to +"path". So please ensure the dump target is mounted on "path" before kdump +service starts. + +NOTES: + +- It's strongly recommanded to put an mount entry for "path" in /etc/fstab + and have it auto mounted on boot. This make sure the dump target is + reachable from the machine and kdump's configuration is stable. + +EXAMPLES: + +- path /var/crash/ + + This is the default configuration. Assuming there is no disk mounted + on /var/ or on /var/crash, dump will be saved on disk backing rootfs + in directory /var/crash. + +- path /var/crash/ (A separate disk mounted on /var/crash) + + Say a disk /dev/sdb is mounted on /var. In this case dump target will + become /dev/sdb and path will become "/" and dump will be saved + on "sdb:/var/crash/" directory. + +- path /var/crash/ (NFS mounted on /var) + + Say foo.com:/export/tmp is mounted on /var. In this case dump target is + nfs server and path will be adjusted to "/crash" and dump will be saved to + foo.com:/export/tmp/crash/ directory. + +Config dump target explicitely +------------------------------ + +You can set the dump target explicitly in kdump.conf, and "path" will be +the relative path in the specified dump target. For example, if dump +target is "ext4 /dev/sda", then dump will be saved in "path" directory +on /dev/sda. + +Same is the case for nfs dump. If user specified "nfs foo.com:/export/tmp/" +as dump target, then dump will effectively be saved in +"foo.com:/export/tmp/var/crash/" directory. + +If the dump target is "raw", then "path" is ignored. + +If it's a filesystem target, kdump will need to know the right mount option. +Kdump will check current mount status, and then /etc/fstab for mount options +corresponding to the specified dump target and use it. If there are +special mount option required for the dump target, it could be set by put +an entry in fstab. + +If there are no related mount entry, mount option is set to "defaults". + +NOTES: + +- It's recommended to put an entry for the dump target in /etc/fstab + and have it auto mounted on boot. This make sure the dump target is + reachable from the machine and kdump won't fail. + +- Kdump ignores some mount options, including "noauto", "ro". This + make it possible to keep the dump target unmounted or read-only + when not used. + +EXAMPLES: + +- ext4 /dev/sda (mounted) + path /var/crash/ + + In this case dump target is set to /dev/sdb, path is the absolute path + "/var/crash" in /dev/sda, vmcore path will saved on + "sda:/var/crash" directory. + +- nfs foo.com:/export/tmp (mounted) + path /var/crash/ + + In this case dump target is nfs server, path is the absolute path + "/var/crash", vmcore path will saved on "foo.com:/export/tmp/crash/" directory. + +- nfs foo.com:/export/tmp (not mounted) + path /var/crash/ + + Same with above case, kdump will use "defaults" as the mount option + for the dump target. + +- nfs foo.com:/export/tmp (not mounted, entry with option "noauto,nolock" exists in /etc/fstab) + path /var/crash/ + + In this case dump target is nfs server, vmcore path will saved on + "foo.com:/export/tmp/crash/" directory, and kdump will inherit "nolock" option. + +Dump target and mkdumprd +------------------------ + +MKdumprd is the tool used to create kdump initramfs, and it may change +the mount status of the dump target in some condition. + Usually the dump target should be used only for kdump. If you worry about someone uses the filesystem for something else other than dumping vmcore -you can mount it as read-only. Mkdumprd will still remount it as read-write -for creating dump directory and will move it back to read-only afterwards. +you can mount it as read-only or make it a noauto mount. Mkdumprd will +mount/remount it as read-write for creating dump directory and will +move it back to it's original state afterwards. -Raw partition +Supported dump target types and requirements +-------------------------------------------- + +1) Raw partition Raw partition dumping requires that a disk partition in the system, at least as large as the amount of memory in the system, be left unformatted. Assuming @@ -325,7 +443,7 @@ onto partition /dev/vg/lv_kdump. Restart the kdump service via initrd. Dump target should be persistent device name, such as lvm or device mapper canonical name. -Dedicated file system +2) Dedicated file system Similar to raw partition dumping, you can format a partition with the file system of your choice, Again, it should be at least as large as the amount @@ -349,7 +467,7 @@ Be careful of your filesystem selection when using this target. It is recommended to use persistent device names or UUID/LABEL for file system dumps. One example of persistent device is /dev/vg/. -NFS mount +3) NFS mount Dumping over NFS requires an NFS server configured to export a file system with full read/write access for the root user. All operations done within @@ -367,7 +485,7 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd. -Special mount via "dracut_args" +4) Special mount via "dracut_args" You can utilize "dracut_args" to pass "--mount" to kdump, see dracut manpage about the format of "--mount" for details. If there is any "--mount" specified @@ -385,7 +503,7 @@ dracut_args --mount "192.168.1.1:/share /mnt/test nfs4 defaults" NOTE: - must be specified as an absolute path. -Remote system via ssh/scp +5) Remote system via ssh/scp Dumping over ssh/scp requires setting up passwordless ssh keys for every machine you wish to have dump via this method. First up, configure kdump.conf @@ -403,49 +521,12 @@ you've connected to it, and then input the target system user's password to send over the necessary ssh key file. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd. -Path -==== -"path" represents the file system path in which vmcore will be saved. In -fact kdump creates a directory $hostip-$date with-in "path" and saves -vmcore there. So practically dump is saved in $path/$hostip-$date/. To -simplify discussion further, if we say dump will be saved in $path, it -is implied that kdump will create another directory inside path and -save vmcore there. - -If a dump target is specified in kdump.conf, then "path" is relative to the -specified dump target. For example, if dump target is "ext4 /dev/sda", then -dump will be saved in "$path" directory on /dev/sda. - -Same is the case for nfs dump. If user specified "nfs foo.com:/export/tmp/" -as dump target, then dump will effectively be saved in -"foo.com:/export/tmp/var/crash/" directory. - -Interpretation of path changes a bit if user has not specified a dump -target explicitly in kdump.conf. In this case, "path" represents the -absolute path from root. And dump target and adjusted path are arrived -at automatically depending on what's mounted in the current system. - -Following are few examples. - -path /var/crash/ ----------------- -Assuming there is no disk mounted on /var/ or on /var/crash, dump will -be saved on disk backing rootfs in directory /var/crash. - -path /var/crash/ (A separate disk mounted on /var) --------------------------------------------------- -Say a disk /dev/sdb is mouted on /var. In this case dump target will -become /dev/sdb and path will become "/crash" and dump will be saved -on "sdb:/crash/" directory. - -path /var/crash/ (NFS mounted on /var) -------------------------------------- -Say foo.com:/export/tmp is mounted on /var. In this case dump target is -nfs server and path will be adjusted to "/crash" and dump will be saved to -foo.com:/export/tmp/crash/ directory. +Advanced Setups +=============== Kdump boot directory -==================== +-------------------- + Usually kdump kernel is the same as 1st kernel. So kdump will try to find kdump kernel under /boot according to /proc/cmdline. E.g we execute below command and get an output: @@ -456,6 +537,7 @@ However a variable KDUMP_BOOTDIR in /etc/sysconfig/kdump is provided to user if kdump kernel is put in a different directory. Kdump Post-Capture Executable +----------------------------- It is possible to specify a custom script or binary you wish to run following an attempt to capture a vmcore. The executable is passed an exit code from @@ -463,6 +545,7 @@ the capture process, which can be used to trigger different actions from within your post-capture executable. Kdump Pre-Capture Executable +---------------------------- It is possible to specify a custom script or binary you wish to run before capturing a vmcore. Exit status of this binary is interpreted: @@ -470,6 +553,7 @@ capturing a vmcore. Exit status of this binary is interpreted: non 0 - reboot the system Extra Binaries +-------------- If you have specific binaries or scripts you want to have made available within your kdump initrd, you can specify them by their full path, and they @@ -478,6 +562,7 @@ This may be particularly useful for those running post-capture scripts that rely on other binaries. Extra Modules +------------- By default, only the bare minimum of kernel modules will be included in your kdump initrd. Should you wish to capture your vmcore files to a non-boot-path @@ -486,7 +571,8 @@ need to manually specify additional kernel modules to load into your kdump initrd. Failure action -============== +-------------- + Failure action specifies what to do when dump to configured dump target fails. By default, failure action is "reboot" and that is system reboots if attempt to save dump to dump target fails. @@ -494,21 +580,24 @@ if attempt to save dump to dump target fails. There are other failure actions available though. - dump_to_rootfs - This option tries to mount root and save dump on root filesystem - in a path specified by "path". This option will generally make - sense when dump target is not root filesystem. For example, if - dump is being saved over network using "ssh" then one can specify - failure action to "dump_to_rootfs" to try saving dump to root - filesystem if dump over network fails. + This option tries to mount root and save dump on root filesystem + in a path specified by "path". This option will generally make + sense when dump target is not root filesystem. For example, if + dump is being saved over network using "ssh" then one can specify + failure action to "dump_to_rootfs" to try saving dump to root + filesystem if dump over network fails. - shell - Drop into a shell session inside initramfs. + Drop into a shell session inside initramfs. + - halt - Halt system after failure + Halt system after failure + - poweroff - Poweroff system after failure. + Poweroff system after failure. Compression and filtering +------------------------- The 'core_collector' parameter in kdump.conf allows you to specify a custom dump capture method. The most common alternate method is makedumpfile, which @@ -526,22 +615,21 @@ Core collector command format depends on dump target type. Typically for filesystem (local/remote), core_collector should accept two arguments. First one is source file and second one is target file. For ex. -ex1. ---- -core_collector "cp --sparse=always" +- ex1. + + core_collector "cp --sparse=always" -Above will effectively be translated to: + Above will effectively be translated to: -cp --sparse=always /proc/vmcore /vmcore + cp --sparse=always /proc/vmcore /vmcore -ex2. ---- -core_collector "makedumpfile -l --message-level 1 -d 31" +- ex2. -Above will effectively be translated to: + core_collector "makedumpfile -l --message-level 1 -d 31" -makedumpfile -l --message-level 1 -d 31 /proc/vmcore /vmcore + Above will effectively be translated to: + makedumpfile -l --message-level 1 -d 31 /proc/vmcore /vmcore For dump targets like raw and ssh, in general, core collector should expect one argument (source file) and should output the processed core on standard @@ -549,55 +637,56 @@ output (There is one exception of "scp", discussed later). This standard output will be saved to destination using appropriate commands. raw dumps core_collector examples: ---------- -ex3. ---- -core_collector "cat" -Above will effectively be translated to. +- ex3. + + core_collector "cat" -cat /proc/vmcore | dd of= + Above will effectively be translated to. -ex4. ---- -core_collector "makedumpfile -F -l --message-level 1 -d 31" + cat /proc/vmcore | dd of= -Above will effectively be translated to. +- ex4. -makedumpfile -F -l --message-level 1 -d 31 | dd of= + core_collector "makedumpfile -F -l --message-level 1 -d 31" + + Above will effectively be translated to. + + makedumpfile -F -l --message-level 1 -d 31 | dd of= ssh dumps core_collector examples: ---------- -ex5. ---- -core_collector "cat" -Above will effectively be translated to. +- ex5. + + core_collector "cat" -cat /proc/vmcore | ssh "dd of=path/vmcore" + Above will effectively be translated to. -ex6. ---- -core_collector "makedumpfile -F -l --message-level 1 -d 31" + cat /proc/vmcore | ssh "dd of=path/vmcore" -Above will effectively be translated to. +- ex6. -makedumpfile -F -l --message-level 1 -d 31 | ssh "dd of=path/vmcore" + core_collector "makedumpfile -F -l --message-level 1 -d 31" + + Above will effectively be translated to. + + makedumpfile -F -l --message-level 1 -d 31 | ssh "dd of=path/vmcore" There is one exception to standard output rule for ssh dumps. And that is scp. As scp can handle ssh destinations for file transfers, one can specify "scp" as core collector for ssh targets (no output on stdout). -ex7. ----- -core_collector "scp" +- ex7. + + core_collector "scp" -Above will effectively be translated to. + Above will effectively be translated to. -scp /proc/vmcore :path/vmcore + scp /proc/vmcore :path/vmcore About default core collector ---------------------------- + Default core_collector for ssh/raw dump is: "makedumpfile -F -l --message-level 1 -d 31". Default core_collector for other targets is: @@ -615,7 +704,9 @@ dump data from stdard input to a normal dumpfile (readable with analysis tools). For example: "makedumpfile -R vmcore < vmcore.flat" -Caveats: + +Caveats +======= Console frame-buffers and X are not properly supported. If you typically run with something along the lines of "vga=791" in your kernel config line or @@ -624,7 +715,11 @@ kexec. Note that the kdump kernel should still be able to create a dump, and when the system reboots, video should be restored to normal. +Notes +===== + Notes on resetting video: +------------------------- Video is a notoriously difficult issue with kexec. Video cards contain ROM code that controls their initial configuration and setup. This code is nominally @@ -646,7 +741,9 @@ Secondly, it may be worth trying to add vga15fb.ko to the extra_modules list in /etc/kdump.conf. This will attempt to use the video card in framebuffer mode, which can blank the screen prior to the start of a dump capture. -Notes on rootfs mount: +Notes on rootfs mount +--------------------- + Dracut is designed to mount rootfs by default. If rootfs mounting fails it will refuse to go on. So kdump leaves rootfs mounting to dracut currently. We make the assumtion that proper root= cmdline is being passed to dracut @@ -656,7 +753,8 @@ options are copied from /proc/cmdline. In general it is best to append command line options using "KDUMP_COMMANDLINE_APPEND=" instead of replacing the original command line completely. -Notes on watchdog module handling: +Notes on watchdog module handling +--------------------------------- If a watchdog is active in first kernel then, we must have it's module loaded in crash kernel, so that either watchdog is deactivated or started @@ -670,7 +768,8 @@ not been written in watchdog-core framework then this option will not have any effect and module will not be added. Please note that only systemd watchdog daemon is supported as watchdog kick application. -Notes for disk images: +Notes for disk images +--------------------- Kdump initramfs is a critical component for capturing the crash dump. But it's strictly generated for the machine it will run on, and have @@ -684,7 +783,8 @@ a machine with a disk image which have kdump initramfs embedded, you should rebuild the initramfs using "kdumpctl rebuild" command manually, or else kdump may not work as expeceted. -Notes on encrypted dump target: +Notes on encrypted dump target +------------------------------ Currently, kdump is not working well with encrypted dump target. First, user have to give the password manually in capture kernel, @@ -698,7 +798,8 @@ crash kernel according, or update your encryption setup. It's recommanded to use a non-encrypted target (eg. remote target) instead. -Notes on device dump: +Notes on device dump +-------------------- Device dump allows drivers to append dump data to vmcore, so you can collect driver specified debug info. The drivers could append the @@ -715,8 +816,10 @@ the dump target setup will be included. To ensure the device dump data will be included in the vmcore, you need to force include related device drivers by using "extra_modules" option in /etc/kdump.conf + Parallel Dumping Operation ========================== + Kexec allows kdump using multiple cpus. So parallel feature can accelerate dumping substantially, especially in executing compression and filter. For example: @@ -746,8 +849,10 @@ may lead to panic due to Out Of Memory. hang, system reset or power-off at boot, depending on your system and runtime situation at the time of crash. + Debugging Tips --------------- +============== + - One can drop into a shell before/after saving vmcore with the help of using kdump_pre/kdump_post hooks. Use following in one of the pre/post scripts to drop into a shell. @@ -772,5 +877,3 @@ Debugging Tips minicom -C /tmp/console-logs Now minicom should be logging serial console in file console-logs. - - diff --git a/SOURCES/mkdumprd b/SOURCES/mkdumprd index 274f914..f8edde1 100644 --- a/SOURCES/mkdumprd +++ b/SOURCES/mkdumprd @@ -13,10 +13,25 @@ export IN_KDUMP=1 conf_file="/etc/kdump.conf" SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" -SAVE_PATH=$(awk '/^path/ {print $2}' $conf_file) -[ -z "$SAVE_PATH" ] && SAVE_PATH=$DEFAULT_PATH -# strip the duplicated "/" -SAVE_PATH=$(echo $SAVE_PATH | tr -s /) +SAVE_PATH=$(get_save_path) +OVERRIDE_RESETTABLE=0 + +extra_modules="" +dracut_args="--quiet --hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode strict -o \"plymouth dash resume ifcfg earlykdump\"" + +readonly MKDUMPRD_TMPDIR="$(mktemp -d -t mkdumprd.XXXXXX)" +[ -d "$MKDUMPRD_TMPDIR" ] || perror_exit "dracut: mktemp -p -d -t dracut.XXXXXX failed." +readonly MKDUMPRD_TMPMNT="$MKDUMPRD_TMPDIR/target" + +trap ' + ret=$?; + is_mounted $MKDUMPRD_TMPMNT && umount -f $MKDUMPRD_TMPMNT; + [[ -d $MKDUMPRD_TMPDIR ]] && rm --one-file-system -rf -- "$MKDUMPRD_TMPDIR"; + exit $ret; + ' EXIT + +# clean up after ourselves no matter how we die. +trap 'exit 1;' SIGINT is_wdt_addition_needed() { local active @@ -32,111 +47,60 @@ is_wdt_addition_needed() { return 1 } -WDTCFG="" -is_wdt_addition_needed -[[ $? -eq 0 ]] && WDTCFG="-a watchdog" - -extra_modules="" -dracut_args=("--quiet" "--hostonly" "--hostonly-cmdline" "--hostonly-i18n" "--hostonly-mode" "strict" "-o" "plymouth dash resume ifcfg earlykdump" $WDTCFG) -OVERRIDE_RESETTABLE=0 - add_dracut_arg() { - local arg qarg is_quoted=0 - while [ $# -gt 0 ]; - do - arg="${1//\'/\"}" - #Handle quoted substring properly for passing it to dracut_args array. - if [ $is_quoted -eq 0 ]; then - if [[ "$arg" == "\"" ]] || [[ $arg != ${arg#\"} ]]; then - is_quoted=1 - arg=${arg#\"} - fi - fi - if [ $is_quoted -eq 1 ]; then - qarg="$qarg $arg" - if [[ "$arg" == "\"" ]] || [[ $arg != ${arg%\"} ]]; then - is_quoted=0 - arg=${qarg%\"} - qarg="" - else - shift - continue - fi - fi - dracut_args+=("$arg") - shift - done + dracut_args="$dracut_args $@" } add_dracut_module() { - add_dracut_arg "--add" "$1" + add_dracut_arg "--add" "\"$1\"" } add_dracut_mount() { - add_dracut_arg "--mount" "$1" + add_dracut_arg "--mount" "\"$1\"" } add_dracut_sshkey() { - add_dracut_arg "--sshkey" "$1" + add_dracut_arg "--sshkey" "\"$1\"" } # caller should ensure $1 is valid and mounted in 1st kernel to_mount() { - local _dev=$1 _source _target _fstype _options _mntopts _pdev + local _target=$1 _fstype=$2 _options=$3 _new_mntpoint _mntopts _pdev - _source=$(findmnt -k -f -n -r -o SOURCE $_dev) - _target=$(get_mntpoint_from_target $_dev) - # mount under /sysroot if dump to root disk or mount under - #/kdumproot/$_target in other cases in 2nd kernel. systemd - #will be in charge to umount it. + _new_mntpoint=$(get_kdump_mntpoint_from_target $_target) + _fstype="${_fstype:-$(get_fs_type_from_target $_target)}" + _options="${_options:-$(get_mntopt_from_target $_target)}" + _options="${_options:-defaults}" - if [ "$_target" = "/" ];then - _target="/sysroot" - else - _target="/kdumproot/$_target" + if [[ "$_fstype" == "nfs"* ]]; then + _options=$(echo $_options | sed 's/,addr=[^,]*//') + _options=$(echo $_options | sed 's/,proto=[^,]*//') + _options=$(echo $_options | sed 's/,clientaddr=[^,]*//') fi - _fstype=$(findmnt -k -f -n -r -o FSTYPE $_dev) - [[ -e /etc/fstab ]] && _options=$(findmnt --fstab -f -n -r -o OPTIONS $_dev) - if [ -z "$_options" ]; then - _options=$(findmnt -k -f -n -r -o OPTIONS $_dev) - if [[ $_fstype == "nfs"* ]]; then - _options=$(echo $_options | sed 's/,addr=[^,]*//') - _options=$(echo $_options | sed 's/,proto=[^,]*//') - _options=$(echo $_options | sed 's/,clientaddr=[^,]*//') - fi - fi #mount fs target as rw in 2nd kernel _options=$(echo $_options | sed 's/\(^\|,\)ro\($\|,\)/\1rw\2/g') - # filter out 'noauto' here, it will be force appended later, avoid duplication + # with 'noauto' in fstab nfs and non-root disk mount will fail in 2nd + # kernel, filter it out here. _options=$(echo $_options | sed 's/\(^\|,\)noauto\($\|,\)/\1/g') - # only mount the dump target when needed. - _options="$_options,noauto" - - _mntopts="$_target $_fstype $_options" - #for non-nfs _dev converting to use udev persistent name - if [ -b "$_source" ]; then - _pdev="$(get_persistent_dev $_source)" + # use both nofail and x-systemd.before to ensure systemd will try best to + # mount it before kdump starts, this is an attempt to improve robustness + _options="$_options,nofail,x-systemd.before=initrd-fs.target" + + _mntopts="$_new_mntpoint $_fstype $_options" + # for non-nfs _target converting to use udev persistent name + if [ -b "$_target" ]; then + _pdev="$(get_persistent_dev $_target)" if [ -z "$_pdev" ]; then return 1 fi - else - _pdev=$_dev + _pdev=$_target fi echo "$_pdev $_mntopts" } -is_readonly_mount() { - local _mnt - _mnt=$(findmnt -k -f -n -r -o OPTIONS $1) - - #fs/proc_namespace.c: show_mountinfo(): - #seq_puts(m, mnt->mnt_flags & MNT_READONLY ? " ro" : " rw"); - [[ "$_mnt" =~ ^ro ]] -} - #Function: get_ssh_size #$1=dump target #called from while loop and shouldn't read from stdin, so we're using "ssh -n" @@ -155,7 +119,7 @@ get_ssh_size() { #mkdir if save path does not exist on ssh dump target #$1=ssh dump target -#caller should ensure write permission on $DUMP_TARGET:$SAVE_PATH +#caller should ensure write permission on $1:$SAVE_PATH #called from while loop and shouldn't read from stdin, so we're using "ssh -n" mkdir_save_path_ssh() { @@ -164,14 +128,14 @@ mkdir_save_path_ssh() ssh -qn $_opt $1 mkdir -p $SAVE_PATH 2>&1 > /dev/null _ret=$? if [ $_ret -ne 0 ]; then - perror_exit "mkdir failed on $DUMP_TARGET:$SAVE_PATH" + perror_exit "mkdir failed on $1:$SAVE_PATH" fi - #check whether user has write permission on $SAVE_PATH/$DUMP_TARGET + #check whether user has write permission on $1:$SAVE_PATH _dir=$(ssh -qn $_opt $1 mktemp -dqp $SAVE_PATH 2>/dev/null) _ret=$? if [ $_ret -ne 0 ]; then - perror_exit "Could not create temporary directory on $DUMP_TARGET:$SAVE_PATH. Make sure user has write permission on destination" + perror_exit "Could not create temporary directory on $1:$SAVE_PATH. Make sure user has write permission on destination" fi ssh -qn $_opt $1 rmdir $_dir @@ -222,6 +186,67 @@ check_size() { fi } +check_save_path_fs() +{ + local _path=$1 + + if [ ! -d $_path ]; then + perror_exit "Dump path $_path does not exist." + fi +} + +check_user_configured_target() +{ + local _target=$1 _cfg_fs_type=$2 _mounted + local _mnt=$(get_mntpoint_from_target $_target) + local _opt=$(get_mntopt_from_target $_target) + local _fstype=$(get_fs_type_from_target $_target) + + if [ -n "$_fstype" ]; then + # In case of nfs4, nfs should be used instead, nfs* options is deprecated in kdump.conf + [[ $_fstype = "nfs"* ]] && _fstype=nfs + + if [ -n "$_cfg_fs_type" ] && [ "$_fstype" != "$_cfg_fs_type" ]; then + perror_exit "\"$_target\" have a wrong type config \"$_cfg_fs_type\", expected \"$_fstype\"" + fi + else + _fstype="$_cfg_fs_type" + _fstype="$_cfg_fs_type" + fi + + # For noauto mount, mount it inplace with default value. + # Else use the temporary target directory + if [ -n "$_mnt" ]; then + if ! is_mounted "$_mnt"; then + if [[ $_opt = *",noauto"* ]]; then + mount $_mnt + [ $? -ne 0 ] && perror_exit "Failed to mount $_target on $_mnt for kdump preflight check." + _mounted=$_mnt + else + perror_exit "$_target is configured in fstab but not mounted, please check its usability." + fi + fi + else + _mnt=$MKDUMPRD_TMPMNT + mkdir -p $_mnt + mount $_target $_mnt -t $_fstype -o defaults + [ $? -ne 0 ] && perror_exit "Failed to mount $_target for kdump preflight check." + _mounted=$_mnt + fi + + # For user configured target, use $SAVE_PATH as the dump path within the target + if [ ! -d "$_mnt/$SAVE_PATH" ]; then + perror_exit "Dump path \"$SAVE_PATH\" does not exist in dump target \"$_target\"" + fi + + check_size fs "$_target" + + # Unmount it early, if function is interrupted and didn't reach here, the shell trap will clear it up anyway + if [ -n "$_mounted" ]; then + umount -f -- $_mounted + fi +} + # $1: core_collector config value verify_core_collector() { local _cmd="${1%% *}" @@ -249,7 +274,7 @@ verify_core_collector() { } add_mount() { - local _mnt=$(to_mount "$1") + local _mnt=$(to_mount $@) if [ $? -ne 0 ]; then exit 1 @@ -268,20 +293,11 @@ handle_default_dump_target() check_save_path_fs $SAVE_PATH - _mntpoint=$(get_mntpoint_from_path $SAVE_PATH) - _target=$(get_target_from_path $SAVE_PATH) - - if is_atomic && is_bind_mount $_mntpoint; then - SAVE_PATH=${SAVE_PATH##"$_mntpoint"} - # the real dump path in the 2nd kernel, if the mount point is bind mounted. - SAVE_PATH=$(get_bind_mount_directory $_mntpoint)/$SAVE_PATH - _mntpoint=$(get_mntpoint_from_target $_target) - - # the absolute path in the 1st kernel - SAVE_PATH=$_mntpoint/$SAVE_PATH - fi + _save_path=$(get_bind_mount_source $SAVE_PATH) + _target=$(get_target_from_path $_save_path) + _mntpoint=$(get_mntpoint_from_target $_target) - SAVE_PATH=${SAVE_PATH##"$_mntpoint"} + SAVE_PATH=${_save_path##"$_mntpoint"} add_mount "$_target" check_size fs $_target } @@ -399,6 +415,10 @@ if [ "$(uname -m)" = "s390x" ]; then add_dracut_module "znet" fi +if is_wdt_addition_needed; then + add_dracut_arg "-a" "watchdog" +fi + while read config_opt config_val; do # remove inline comments after the end of a directive. @@ -407,24 +427,11 @@ do extra_modules="$extra_modules $config_val" ;; ext[234]|xfs|btrfs|minix|nfs) - if ! findmnt $config_val >/dev/null; then - perror_exit "Dump target $config_val is probably not mounted." - fi - - _absolute_save_path=$(make_absolute_save_path $config_val) - _mntpoint=$(get_mntpoint_from_path $_absolute_save_path) - if is_atomic && is_bind_mount $_mntpoint; then - SAVE_PATH=${_absolute_save_path##"$_mntpoint"} - # the real dump path in the 2nd kernel, if the mount point is bind mounted. - SAVE_PATH=$(get_bind_mount_directory $_mntpoint)/$SAVE_PATH - fi - - add_mount "$config_val" - check_save_path_fs $_absolute_save_path - check_size fs $config_val + check_user_configured_target "$config_val" "$config_opt" + add_mount "$config_val" "$config_opt" ;; raw) - #checking raw disk writable + # checking raw disk writable dd if=$config_val count=1 of=/dev/null > /dev/null 2>&1 || { perror_exit "Bad raw disk $config_val" } @@ -472,7 +479,8 @@ if ! is_fadump_capable; then add_dracut_arg "--no-hostonly-default-device" fi -dracut "${dracut_args[@]}" "$@" +echo "$dracut_args $@" | xargs dracut + _rc=$? sync exit $_rc diff --git a/SPECS/kexec-tools.spec b/SPECS/kexec-tools.spec index 98beec7..1d69e85 100644 --- a/SPECS/kexec-tools.spec +++ b/SPECS/kexec-tools.spec @@ -1,6 +1,6 @@ Name: kexec-tools Version: 2.0.20 -Release: 18%{?dist} +Release: 24%{?dist} License: GPLv2 Group: Applications/System Summary: The kexec/kdump userspace component @@ -33,6 +33,7 @@ Source27: early-kdump-howto.txt Source28: supported-kdump-targets.txt Source29: kdump-udev-throttler Source30: kdump.sysconfig.aarch64 +Source31: fadump-howto.txt ####################################### # These are sources for mkdumpramfs @@ -169,9 +170,10 @@ cp %{SOURCE21} . cp %{SOURCE26} . cp %{SOURCE27} . cp %{SOURCE28} . +cp %{SOURCE31} . make -%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 %{arm} +%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 make -C eppic/libeppic make -C makedumpfile-1.6.7 LINKTYPE=dynamic USELZO=on USESNAPPY=on make -C makedumpfile-1.6.7 LDFLAGS="$LDFLAGS -I../eppic/libeppic -L../eppic/libeppic" eppic_makedumpfile.so @@ -224,7 +226,7 @@ install -m 644 %{SOURCE15} $RPM_BUILD_ROOT%{_mandir}/man5/kdump.conf.5 install -m 644 %{SOURCE16} $RPM_BUILD_ROOT%{_unitdir}/kdump.service install -m 755 -D %{SOURCE22} $RPM_BUILD_ROOT%{_prefix}/lib/systemd/system-generators/kdump-dep-generator.sh -%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 %{arm} +%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 install -m 755 makedumpfile-1.6.7/makedumpfile $RPM_BUILD_ROOT/usr/sbin/makedumpfile install -m 644 makedumpfile-1.6.7/makedumpfile.8.gz $RPM_BUILD_ROOT/%{_mandir}/man8/makedumpfile.8.gz install -m 644 makedumpfile-1.6.7/makedumpfile.conf.5.gz $RPM_BUILD_ROOT/%{_mandir}/man5/makedumpfile.conf.5.gz @@ -337,7 +339,7 @@ done %{_bindir}/* %{_datadir}/kdump %{_prefix}/lib/kdump -%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 %{arm} +%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 %{_sysconfdir}/makedumpfile.conf.sample %endif %config(noreplace,missingok) %{_sysconfdir}/sysconfig/kdump @@ -361,15 +363,61 @@ done %doc TODO %doc kexec-kdump-howto.txt %doc early-kdump-howto.txt +%doc fadump-howto.txt %doc supported-kdump-targets.txt %doc kdump-in-cluster-environment.txt %doc live-image-kdump-howto.txt -%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 %{arm} +%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 %{_libdir}/eppic_makedumpfile.so /usr/share/makedumpfile/ %endif %changelog +* Thu Jun 4 2020 Pingfan Liu - 2.0.20-24 +- fadump: update fadump-howto.txt with some more troubleshooting help + +* Wed Jun 3 2020 Pingfan Liu - 2.0.20-23 +- fadump-howto.txt: source it in spec file + +* Mon Jun 1 2020 Pingfan Liu - 2.0.20-22 +- mkdumprd: Use DUMP_TARGET which printing error message during ssh + +* Mon Jun 1 2020 Pingfan Liu - 2.0.20-21 +- Don't inherit swiotlb parameter form 1st kernel by default +- Add a new option 'rd.znet_ifname' in order to use it in udev rules +- kdump.sysconfig: Remove the option 'log_buf_len' from kdump command line +- kdump-error-handler.service: Remove ExecStopPost +- module-setup.sh: Add "rd.neednet" parameter if network is needed + +* Thu May 28 2020 Pingfan Liu - 2.0.20-20 +- Update docs for the new noauto dump target support +- kexec-kdump-howto.txt: Add some format to the document +- mkdumprd: generate usable kdump initramfs even target is not mounted +- Use get_mount_info to replace findmnt calls +- kdump-lib.sh: add fstab failback helper for getting mount info +- Allow calling mkdumprd from kdumpctl even if targat not mounted +- Add a is_mounted helper +- Introduce get_kdump_mntpoint_from_target and fix duplicated / +- Doc: Improves the early-kdump-howto.txt document in several points +- Doc: Add --force option to step 2 in early-kdump-howto.txt +- Doc: Fix typo in early-kdump-howto.txt +- Remove adjust_bind_mount_path call +- No longer treat atomic/silverblue specially +- mkdumprd: Simplify handling of user specified target +- mkdumprd: Use get_save_path instead of parsing config +- Remove is_dump_target_configured +- Always use get_save_path to get the 'path' option +- kdump-lib: Don't abuse echo, and clean up +- mkdumprd: Fix dracut args parsing +- mkdumprd: simplify dracut args parsing + +* Thu May 21 2020 Pingfan Liu - 2.0.20-19 +- dracut-module-setup.sh: improve get_alias() +- fadump: update fadump-howto.txt with some troubleshooting help +- Append both nofail and x-systemd.before to kdump mount target +- Partially Revert "Don't mount the dump target unless needed" +- Don't unmount the dump target just after saving vmcore + * Mon May 11 2020 Pingfan Liu - 2.0.20-18 - makedumpfile: Avoid false-positive failure in mem_seciton validation