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/<devname> in examples

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>

kdump.conf

@@ -12,6 +12,8 @@
 #
 # Basics commands supported are:
 # raw <partition>	- Will dd /proc/vmcore into <partition>.
+#			  Use persistent device names for partition devices,
+#			  such as /dev/vg/<devname>.
 #
 # nfs <nfs mount>	- Will mount fs and copy /proc/vmcore to
 #			  <mnt>/var/crash/%HOST-%DATE/, supports DNS.
@@ -33,6 +35,9 @@
 # <fs type> <partition> - Will mount -t <fs type> <partition> /mnt and copy
 #		 	  /proc/vmcore to /mnt/var/crash/%DATE/.
 #			  NOTE: <partition> can be a device node, label or uuid.
+#			  It's recommended to use persistent device names
+#			  such as /dev/vg/<devname>.
+#			  Otherwise it's suggested to use label or uuid.
 #
 # path <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
+#raw /dev/vg/lv_kdump
-#ext4 /dev/sda3
+#ext4 /dev/vg/lv_kdump
 #ext4 LABEL=/boot
 #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
 #nfs my.server.com:/export/tmp

kdump.conf.5

@@ -28,7 +28,8 @@ understand how this configuration file affects the behavior of kdump.
 
 .B raw <partition>
 .RS
-Will dd /proc/vmcore into <partition>.
+Will dd /proc/vmcore into <partition>.  Use persistent device names for
+partition devices, such as /dev/vg/<devname>.
 .RE
 
 .B nfs <nfs mount>
@@ -61,7 +62,8 @@ the default value is /root/.ssh/kdump_id_rsa.
 .RS
 Will mount -t <fs type> <partition> /mnt and copy /proc/vmcore to
 /mnt/var/crash/%DATE/.  NOTE: <partition> can be a device node, label
-or uuid.
+or uuid.  It's recommended to use persistent device names such as
+/dev/vg/<devname>. Otherwise it's suggested to use label or uuid.
 .RE
 
 .B path <path>

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/vg/lv_kdump is left unformatted, kdump.conf can be configured with
-/dev/sda5', and the vmcore file will be copied via dd directly onto partition
+'raw /dev/vg/lv_kdump', and the vmcore file will be copied via dd directly
-/dev/sda5. Restart the kdump service via '/sbin/systemctl restart kdump.service'
+onto partition /dev/vg/lv_kdump. Restart the kdump service via
-to commit this change to your kdump initrd.
+'/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,
+amount of memory in the system. Assuming /dev/vg/lv_kdump has been
-specify 'ext4 /dev/sda3' in kdump.conf, and a vmcore file will be copied
+formatted ext4, specify 'ext4 /dev/vg/lv_kdump' in kdump.conf, and a
-onto the file system after it has been mounted. Dumping to a dedicated
+vmcore file will be copied onto the file system after it has been mounted.
-partition has the advantage that you can dump multiple vmcores to the
+Dumping to a dedicated partition has the advantage that you can dump multiple
-file system, space permitting, without overwriting previous ones, as would
+vmcores to the file system, space permitting, without overwriting previous ones,
-be the case in a raw partition setup. Restart the kdump service via
+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/<devname>.
+
 NFS mount
 
 Dumping over NFS requires an NFS server configured to export a file system

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