From fca70aadfda857f12136b09677ff7ee493c63e3d Mon Sep 17 00:00:00 2001 From: Dave Young Date: Wed, 10 Oct 2012 15:09:15 +0800 Subject: [PATCH] improve persistent name handling For devices with filesystem, udev /dev/disk/by-uuid/* links are usually reliable. But one exception is multipath devices, child and top layer device may have same uuid. As dm devices maintain /dev/mapper/* as persistent names, so converting to /dev/mapper/* firstly then try by-uuid/* and by-id/* Also because user know better what's the persistent name we just document well to suggest user use persistent name in kdump.conf. it's suggested to to use lvm or multipath canonical names or uuid/label. Updated kdump.conf examples and related chunks in kexec-kdump-howto.txt use lvm /dev/vg/ in examples Signed-off-by: Dave Young Acked-by: Vivek Goyal --- kdump.conf | 9 +++++++-- kdump.conf.5 | 6 ++++-- kexec-kdump-howto.txt | 25 +++++++++++++++---------- mkdumprd | 2 +- 4 files changed, 27 insertions(+), 15 deletions(-) diff --git a/kdump.conf b/kdump.conf index 8fd3f33..753af6b 100644 --- a/kdump.conf +++ b/kdump.conf @@ -12,6 +12,8 @@ # # Basics commands supported are: # raw - Will dd /proc/vmcore into . +# Use persistent device names for partition devices, +# such as /dev/vg/. # # nfs - Will mount fs and copy /proc/vmcore to # /var/crash/%HOST-%DATE/, supports DNS. @@ -33,6 +35,9 @@ # - Will mount -t /mnt and copy # /proc/vmcore to /mnt/var/crash/%DATE/. # NOTE: can be a device node, label or uuid. +# It's recommended to use persistent device names +# such as /dev/vg/. +# Otherwise it's suggested to use label or uuid. # # path - Append path to the filesystem device which you are # dumping to. Ignored for raw device dumps. @@ -109,8 +114,8 @@ # necessary. Specify 1 to force rebuilding kdump # initrd every time when kdump service starts. -#raw /dev/sda5 -#ext4 /dev/sda3 +#raw /dev/vg/lv_kdump +#ext4 /dev/vg/lv_kdump #ext4 LABEL=/boot #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 #nfs my.server.com:/export/tmp diff --git a/kdump.conf.5 b/kdump.conf.5 index 609cec5..edee8b6 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -28,7 +28,8 @@ understand how this configuration file affects the behavior of kdump. .B raw .RS -Will dd /proc/vmcore into . +Will dd /proc/vmcore into . Use persistent device names for +partition devices, such as /dev/vg/. .RE .B nfs @@ -61,7 +62,8 @@ the default value is /root/.ssh/kdump_id_rsa. .RS Will mount -t /mnt and copy /proc/vmcore to /mnt/var/crash/%DATE/. NOTE: can be a device node, label -or uuid. +or uuid. It's recommended to use persistent device names such as +/dev/vg/. Otherwise it's suggested to use label or uuid. .RE .B path diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index 7015a0b..cb8a725 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -333,22 +333,24 @@ 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 -/dev/sda5 is left unformatted, kdump.conf can be configured with 'raw -/dev/sda5', and the vmcore file will be copied via dd directly onto partition -/dev/sda5. Restart the kdump service via '/sbin/systemctl restart kdump.service' -to commit this change to your kdump initrd. +/dev/vg/lv_kdump is left unformatted, kdump.conf can be configured with +'raw /dev/vg/lv_kdump', and the vmcore file will be copied via dd directly +onto partition /dev/vg/lv_kdump. Restart the kdump service via +'/sbin/systemctl restart kdump.service' to commit this change to your kdump +initrd. Dump target should be persistent device name, such as lvm or device +mapper canonical name. 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 of memory in the system. Assuming it should be at least as large as the -amount of memory in the system. Assuming /dev/sda3 has been formatted ext4, -specify 'ext4 /dev/sda3' in kdump.conf, and a vmcore file will be copied -onto the file system after it has been mounted. Dumping to a dedicated -partition has the advantage that you can dump multiple vmcores to the -file system, space permitting, without overwriting previous ones, as would -be the case in a raw partition setup. Restart the kdump service via +amount of memory in the system. Assuming /dev/vg/lv_kdump has been +formatted ext4, specify 'ext4 /dev/vg/lv_kdump' in kdump.conf, and a +vmcore file will be copied onto the file system after it has been mounted. +Dumping to a dedicated partition has the advantage that you can dump multiple +vmcores to the file system, space permitting, without overwriting previous ones, +as would be the case in a raw partition setup. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd. Note that for local file systems ext4 and ext2 are supported as dumpable targets. Kdump will not prevent you from specifying @@ -359,6 +361,9 @@ crash recovery, the dump will fail if the system has more than 2GB of memory (since vfat and msdos filesystems do not support more than 2GB files). 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 Dumping over NFS requires an NFS server configured to export a file system diff --git a/mkdumprd b/mkdumprd index 610b3dd..6baff38 100644 --- a/mkdumprd +++ b/mkdumprd @@ -24,7 +24,7 @@ get_persistent_dev() { exit 1 } - for i in /dev/disk/by-id/*; do + for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do _tmp=$(udevadm info --query=name --name="$i" 2>/dev/null) if [ "$_tmp" = "$_dev" ]; then echo $i