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>
This commit is contained in:
Dave Young
parent
3c2d53ebfd
commit
fca70aadfd
|
|
@ -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
|
||||
#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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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/<devname>.
|
||||
|
||||
NFS mount
|
||||
|
||||
Dumping over NFS requires an NFS server configured to export a file system
|
||||
|
|
|
|||
Loading…
Reference in New Issue