These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
Signed-off-by: Baoquan He bhe@redhat.com Acked-by: Vivek Goyal vgoyal@redhat.com --- kdump-lib.sh | 21 +++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 384f7b4..fdcde83 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -3,6 +3,7 @@ # Kdump common variables and functions #
+DEFAULT_PATH="/var/crash/" FENCE_KDUMP_CONFIG="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send" FENCE_KDUMP_NODES="/etc/fence_kdump_nodes" @@ -61,3 +62,23 @@ get_root_fs_device() return }
+get_mntpoint_from_path() +{ + echo $(df $1 | tail -1 | awk '{print $NF}') +} + +get_target_from_path() +{ + echo $(df $1 | tail -1 | awk '{print $1}') +} + +get_fs_type_from_target() +{ + echo $(findmnt -k -f -n -r -o FSTYPE $1) +} + +get_mntpoint_from_target() +{ + echo $(findmnt -k -f -n -r -o TARGET $1) +} + diff --git a/mkdumprd b/mkdumprd index bb1e01e..0295009 100644 --- a/mkdumprd +++ b/mkdumprd @@ -12,7 +12,7 @@ export IN_KDUMP=1 conf_file="/etc/kdump.conf" SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2) -[ -z "$SAVE_PATH" ] && SAVE_PATH="/var/crash" +[ -z "$SAVE_PATH" ] && SAVE_PATH=$DEFAULT_PATH extra_modules="" dracut_args=("--hostonly" "-o" "plymouth dash resume") OVERRIDE_RESETTABLE=0
kdump need create the dir specified in "path" formerly if it does not exist. Now change the behavior to be that ueser takes charge of the "path", make sure "path" has been created, especially when separate disk is mounted on this "path".
Also introduce 2 helper functions to help check the existence of path.
Signed-off-by: Baoquan He bhe@redhat.com --- kdump-lib.sh | 26 ++++++++++++++++++++++++++ mkdumprd | 33 +-------------------------------- 2 files changed, 27 insertions(+), 32 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index fdcde83..6c90ed5 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -82,3 +82,29 @@ get_mntpoint_from_target() echo $(findmnt -k -f -n -r -o TARGET $1) }
+#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() +{ + local _target=$1 + local _mnt + + _mnt=$(get_mntpoint_from_target $1) + echo "${_mnt}/$SAVE_PATH" +} + +check_save_path_fs() +{ + local _path=$1 + + if [ ! -d $_path ]; then + perror_exit "Dump path $_path does not exist." + fi +} + diff --git a/mkdumprd b/mkdumprd index 0295009..c8333a3 100644 --- a/mkdumprd +++ b/mkdumprd @@ -173,37 +173,6 @@ mkdir_save_path_ssh() return 0 }
- -#mkdir if save path does not exist on dump target filesystem -#$1=dump target -#caller should ensure $1 is mounted -mkdir_save_path_fs() { - local _mnt=$(to_mount_point $1) - local _remount="no" - local _ret - - [ ! -d ${_mnt}/$SAVE_PATH ] && { - if is_readonly_mount $1; then - echo "Mounting $1 as read-write for creating dump directory.." - mount -o remount,rw $1 || { - perror_exit "Mounting $1 as read-write failed." - } - _remount="yes" - fi - mkdir -p ${_mnt}/$SAVE_PATH - _ret=$? - [ "$_remount" = "yes" ] && { - echo "Remounting $1 as read-only." - mount -o remount,ro $1 || { - perror_exit "Remounting $1 as read-only failed." - } - } - [ $_ret -ne 0 ] && { - perror_exit "Creating ${_mnt}/$SAVE_PATH failed." - } - } -} - #Function: get_fs_size #$1=dump target get_fs_size() { @@ -539,7 +508,7 @@ do add_dracut_module "nfs" fi add_mount "$config_val" - mkdir_save_path_fs $config_val + check_save_path_fs $(make_absolute_save_path $config_val) check_size fs $config_val ;; raw)
On Fri, Mar 21, 2014 at 05:55:19PM +0800, Baoquan He wrote:
kdump need create the dir specified in "path" formerly if it does not exist. Now change the behavior to be that ueser takes charge of the "path", make sure "path" has been created, especially when separate disk is mounted on this "path".
Also introduce 2 helper functions to help check the existence of path.
Signed-off-by: Baoquan He bhe@redhat.com
kdump-lib.sh | 26 ++++++++++++++++++++++++++ mkdumprd | 33 +-------------------------------- 2 files changed, 27 insertions(+), 32 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index fdcde83..6c90ed5 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -82,3 +82,29 @@ get_mntpoint_from_target() echo $(findmnt -k -f -n -r -o TARGET $1) }
+#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() +{
- local _target=$1
- local _mnt
- _mnt=$(get_mntpoint_from_target $1)
- echo "${_mnt}/$SAVE_PATH"
+}
Hmm..., Initially I was thinking that default dump target path will make use of make_absolute_save_path(). But in patch3 it is not being used. That means we don't have to expect that somebody will call above with _target=NULL. We can remove that from comments above.
In fact if somebody calls it with _target=NULL, then we will pass it to get_mntoint_from_target(). That will return /proc for null target argument and you will take that and return /proc/var/crash as absolute path.
So remove above comments that _target can be null. Also it would be good to return null if _target=null before caling get_mntpoint_from_target().
Thanks Vivek
+check_save_path_fs() +{
- local _path=$1
- if [ ! -d $_path ]; then
perror_exit "Dump path $_path does not exist."
- fi
+}
diff --git a/mkdumprd b/mkdumprd index 0295009..c8333a3 100644 --- a/mkdumprd +++ b/mkdumprd @@ -173,37 +173,6 @@ mkdir_save_path_ssh() return 0 }
-#mkdir if save path does not exist on dump target filesystem -#$1=dump target -#caller should ensure $1 is mounted -mkdir_save_path_fs() {
- local _mnt=$(to_mount_point $1)
- local _remount="no"
- local _ret
- [ ! -d ${_mnt}/$SAVE_PATH ] && {
if is_readonly_mount $1; then
echo "Mounting $1 as read-write for creating dump directory.."
mount -o remount,rw $1 || {
perror_exit "Mounting $1 as read-write failed."
}
_remount="yes"
fi
mkdir -p ${_mnt}/$SAVE_PATH
_ret=$?
[ "$_remount" = "yes" ] && {
echo "Remounting $1 as read-only."
mount -o remount,ro $1 || {
perror_exit "Remounting $1 as read-only failed."
}
}
[ $_ret -ne 0 ] && {
perror_exit "Creating ${_mnt}/$SAVE_PATH failed."
}
- }
-}
#Function: get_fs_size #$1=dump target get_fs_size() { @@ -539,7 +508,7 @@ do add_dracut_module "nfs" fi add_mount "$config_val"
mkdir_save_path_fs $config_val
raw)check_save_path_fs $(make_absolute_save_path $config_val) check_size fs $config_val ;;
-- 1.8.5.3
On 03/27/14 at 02:23pm, Vivek Goyal wrote:
On Fri, Mar 21, 2014 at 05:55:19PM +0800, Baoquan He wrote:
+#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() +{
- local _target=$1
- local _mnt
- _mnt=$(get_mntpoint_from_target $1)
- echo "${_mnt}/$SAVE_PATH"
+}
Hmm..., Initially I was thinking that default dump target path will make use of make_absolute_save_path(). But in patch3 it is not being used. That means we don't have to expect that somebody will call above with _target=NULL. We can remove that from comments above.
In fact if somebody calls it with _target=NULL, then we will pass it to get_mntoint_from_target(). That will return /proc for null target argument and you will take that and return /proc/var/crash as absolute path.
So remove above comments that _target can be null. Also it would be good to return null if _target=null before caling get_mntpoint_from_target().
I didn't find the returned value will be /proc if null target is passed to get_mntpoint_from_target(). Thanks for pointing this out.
However, though patch3 doesn't use this function, from the implementation of function point of view, can we just keep the implementation to prepare the possibility that one day someone will need make a path with a null target?
Then I want to change it like below, it can be used by pair of target and save_path, also can be used with only save_path. The code matches the name of function. How do you think about it?
make_absolute_save_path() { local _target=$1 local _mnt
[ -n $_target ] && _mnt=$(get_mntpoint_from_target $1) echo "${_mnt}/$SAVE_PATH" }
Thanks Vivek
+check_save_path_fs() +{
- local _path=$1
- if [ ! -d $_path ]; then
perror_exit "Dump path $_path does not exist."
- fi
+}
On Fri, Mar 28, 2014 at 11:08:26AM +0800, Baoquan He wrote:
[..]
I didn't find the returned value will be /proc if null target is passed to get_mntpoint_from_target(). Thanks for pointing this out.
However, though patch3 doesn't use this function, from the implementation of function point of view, can we just keep the implementation to prepare the possibility that one day someone will need make a path with a null target?
Then I want to change it like below, it can be used by pair of target and save_path, also can be used with only save_path. The code matches the name of function. How do you think about it?
make_absolute_save_path() { local _target=$1 local _mnt
[ -n $_target ] && _mnt=$(get_mntpoint_from_target $1) echo "${_mnt}/$SAVE_PATH"
}
ok, I am fine with this too.
Vivek
When user does not specify dump target explicitly, it's better to dump to the "path" specified. That means after dump user enter into 1st kernel, can find vmcore in the "path". If that path is in root fs, vmcore is stored in root fs. If separate disk is mounted on any tier of "path", we just dump vmcore into the left path on the left separate disk.
E.g in kdump.conf path /mnt/nfs
in mount info, /dev/vdb on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
Then vmcore will be saved in /nfs of /dev/vdb.
In this patch, pass mount info to dracut in this case if separate disk is mounted on any tier of "path".
Meanwhile introduce a function in kdump-lib.sh to check if any target is specified.
Signed-off-by: Baoquan He bhe@redhat.com Acked-by: Vivek Goyal vgoyal@redhat.com --- kdump-lib.sh | 14 ++++++++++++++ mkdumprd | 34 +++++++++++++++++++--------------- 2 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 6c90ed5..d2562d1 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -53,6 +53,20 @@ get_user_configured_dump_disk() return }
+is_user_configured_dump_target() +{ + local _target + + if is_ssh_dump_target || is_nfs_dump_target; then + return 0 + fi + + _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw" /etc/kdump.conf 2>/dev/null |awk '{print $2}') + [ -n "$_target" ] && return 0 + + return 1 +} + get_root_fs_device() { local _target diff --git a/mkdumprd b/mkdumprd index c8333a3..6916de4 100644 --- a/mkdumprd +++ b/mkdumprd @@ -325,25 +325,29 @@ get_block_dump_target() [ -b "$_target" ] && echo $(to_dev_name $_target) }
-# If no dump disk is specified make sure /var/crash is not mounted on a -# separate disk. -check_block_dump_target() +#handle the case user does not specify the dump target explicitly +handle_default_dump_target() { local _target local _mntpoint + local _fstype
- _target=$(get_user_configured_dump_disk) - [ -n "$_target" ] && return + is_user_configured_dump_target && return
- _target=$(get_root_fs_device) - if [ -b "$_target" ]; then - mkdir -p $SAVE_PATH - _mntpoint=`df $SAVE_PATH | tail -1 | awk '{print $NF}'` - if [ "$_mntpoint" != "/" ]; then - perror "No dump target specified. Default dump target is rootfs block device." - perror "But dump path $SAVE_PATH is not backed by rootfs block device. " - perror_exit "Either explicitly specify a dump target or specify a dump path backed by rootfs block device" + check_save_path_fs $SAVE_PATH + + _mntpoint=$(get_mntpoint_from_path $SAVE_PATH) + _target=$(get_target_from_path $SAVE_PATH) + if [ "$_mntpoint" != "/" ]; then + SAVE_PATH=${SAVE_PATH##"$_mntpoint"} + _fstype=$(get_fs_type_from_target $_target) + + if [ "$_fstype" = "nfs" ]; then + add_dracut_module "nfs" fi + + add_mount "$_target" + check_size fs $_target fi }
@@ -470,8 +474,6 @@ check_crypt() return 1 }
-check_block_dump_target - if ! check_resettable; then exit 1 fi @@ -549,6 +551,8 @@ do esac done < $conf_file
+handle_default_dump_target + if [ -n "$extra_modules" ] then add_dracut_arg "--add-drivers" "$extra_modules"
On Fri, Mar 21, 2014 at 05:55:20PM +0800, Baoquan He wrote:
When user does not specify dump target explicitly, it's better to dump to the "path" specified. That means after dump user enter into 1st kernel, can find vmcore in the "path". If that path is in root fs, vmcore is stored in root fs. If separate disk is mounted on any tier of "path", we just dump vmcore into the left path on the left separate disk.
E.g in kdump.conf path /mnt/nfs
in mount info, /dev/vdb on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
Then vmcore will be saved in /nfs of /dev/vdb.
In this patch, pass mount info to dracut in this case if separate disk is mounted on any tier of "path".
Meanwhile introduce a function in kdump-lib.sh to check if any target is specified.
Can you rebase this patch on top of current tree and repost. We can now also introduce two new functions is_fs_dump_target() and is_raw_dump_target().
Thanks Vivek
Signed-off-by: Baoquan He bhe@redhat.com Acked-by: Vivek Goyal vgoyal@redhat.com
kdump-lib.sh | 14 ++++++++++++++ mkdumprd | 34 +++++++++++++++++++--------------- 2 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 6c90ed5..d2562d1 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -53,6 +53,20 @@ get_user_configured_dump_disk() return }
+is_user_configured_dump_target() +{
- local _target
- if is_ssh_dump_target || is_nfs_dump_target; then
return 0
- fi
- _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw" /etc/kdump.conf 2>/dev/null |awk '{print $2}')
- [ -n "$_target" ] && return 0
- return 1
+}
get_root_fs_device() { local _target diff --git a/mkdumprd b/mkdumprd index c8333a3..6916de4 100644 --- a/mkdumprd +++ b/mkdumprd @@ -325,25 +325,29 @@ get_block_dump_target() [ -b "$_target" ] && echo $(to_dev_name $_target) }
-# If no dump disk is specified make sure /var/crash is not mounted on a -# separate disk. -check_block_dump_target() +#handle the case user does not specify the dump target explicitly +handle_default_dump_target() { local _target local _mntpoint
- local _fstype
- _target=$(get_user_configured_dump_disk)
- [ -n "$_target" ] && return
- is_user_configured_dump_target && return
- _target=$(get_root_fs_device)
- if [ -b "$_target" ]; then
mkdir -p $SAVE_PATH
_mntpoint=`df $SAVE_PATH | tail -1 | awk '{print $NF}'`
if [ "$_mntpoint" != "/" ]; then
perror "No dump target specified. Default dump target is rootfs block device."
perror "But dump path $SAVE_PATH is not backed by rootfs block device. "
perror_exit "Either explicitly specify a dump target or specify a dump path backed by rootfs block device"
- check_save_path_fs $SAVE_PATH
- _mntpoint=$(get_mntpoint_from_path $SAVE_PATH)
- _target=$(get_target_from_path $SAVE_PATH)
- if [ "$_mntpoint" != "/" ]; then
SAVE_PATH=${SAVE_PATH##"$_mntpoint"}
_fstype=$(get_fs_type_from_target $_target)
if [ "$_fstype" = "nfs" ]; then
add_dracut_module "nfs" fi
add_mount "$_target"
ficheck_size fs $_target
}
@@ -470,8 +474,6 @@ check_crypt() return 1 }
-check_block_dump_target
if ! check_resettable; then exit 1 fi @@ -549,6 +551,8 @@ do esac done < $conf_file
+handle_default_dump_target
if [ -n "$extra_modules" ] then add_dracut_arg "--add-drivers" "$extra_modules" -- 1.8.5.3
On 03/27/14 at 02:29pm, Vivek Goyal wrote:
On Fri, Mar 21, 2014 at 05:55:20PM +0800, Baoquan He wrote:
When user does not specify dump target explicitly, it's better to dump to the "path" specified. That means after dump user enter into 1st kernel, can find vmcore in the "path". If that path is in root fs, vmcore is stored in root fs. If separate disk is mounted on any tier of "path", we just dump vmcore into the left path on the left separate disk.
E.g in kdump.conf path /mnt/nfs
in mount info, /dev/vdb on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
Then vmcore will be saved in /nfs of /dev/vdb.
In this patch, pass mount info to dracut in this case if separate disk is mounted on any tier of "path".
Meanwhile introduce a function in kdump-lib.sh to check if any target is specified.
Can you rebase this patch on top of current tree and repost. We can now also introduce two new functions is_fs_dump_target() and is_raw_dump_target().
Yes, will do.
Thanks Vivek
Signed-off-by: Baoquan He bhe@redhat.com Acked-by: Vivek Goyal vgoyal@redhat.com
Hi,
As Vivek previously suggested, I looked into the s-c-kdump setup. If the path which is mounted on by separate fs can be supported to be set as dump target, s-c-kdump is OK with it. The only thing is the save_path, it can not be changed when no disk is specified.
Now in s-c-kdump, there are 3 sections in "target setting" tab. For "Local Filesystem", user can select any separate disk which exist in current system, meanwhile specify a save_path. If "Partition" is "None", then "Path" would be "/var/crash" by default. Other 2 choices are "Raw device" and "Network".
For now, if both path with separate fs and explicitly specified dump target are supported, s-c-kdump may need be changed a little. E.g when "Partition" is "None", user can specify any "Path" which they have created. They decicde if a suitable fs is mounted on that "Path" so that a separate fs is used to store the dump vmcore or rootfs is used to store the dump.
Thanks Baoquan
On 03/21/14 at 05:55pm, Baoquan He wrote:
When user does not specify dump target explicitly, it's better to dump to the "path" specified. That means after dump user enter into 1st kernel, can find vmcore in the "path". If that path is in root fs, vmcore is stored in root fs. If separate disk is mounted on any tier of "path", we just dump vmcore into the left path on the left separate disk.
E.g in kdump.conf path /mnt/nfs
in mount info, /dev/vdb on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
Then vmcore will be saved in /nfs of /dev/vdb.
In this patch, pass mount info to dracut in this case if separate disk is mounted on any tier of "path".
Meanwhile introduce a function in kdump-lib.sh to check if any target is specified.
Signed-off-by: Baoquan He bhe@redhat.com Acked-by: Vivek Goyal vgoyal@redhat.com
kdump-lib.sh | 14 ++++++++++++++ mkdumprd | 34 +++++++++++++++++++--------------- 2 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 6c90ed5..d2562d1 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -53,6 +53,20 @@ get_user_configured_dump_disk() return }
+is_user_configured_dump_target() +{
- local _target
- if is_ssh_dump_target || is_nfs_dump_target; then
return 0
- fi
- _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw" /etc/kdump.conf 2>/dev/null |awk '{print $2}')
- [ -n "$_target" ] && return 0
- return 1
+}
get_root_fs_device() { local _target diff --git a/mkdumprd b/mkdumprd index c8333a3..6916de4 100644 --- a/mkdumprd +++ b/mkdumprd @@ -325,25 +325,29 @@ get_block_dump_target() [ -b "$_target" ] && echo $(to_dev_name $_target) }
-# If no dump disk is specified make sure /var/crash is not mounted on a -# separate disk. -check_block_dump_target() +#handle the case user does not specify the dump target explicitly +handle_default_dump_target() { local _target local _mntpoint
- local _fstype
- _target=$(get_user_configured_dump_disk)
- [ -n "$_target" ] && return
- is_user_configured_dump_target && return
- _target=$(get_root_fs_device)
- if [ -b "$_target" ]; then
mkdir -p $SAVE_PATH
_mntpoint=`df $SAVE_PATH | tail -1 | awk '{print $NF}'`
if [ "$_mntpoint" != "/" ]; then
perror "No dump target specified. Default dump target is rootfs block device."
perror "But dump path $SAVE_PATH is not backed by rootfs block device. "
perror_exit "Either explicitly specify a dump target or specify a dump path backed by rootfs block device"
- check_save_path_fs $SAVE_PATH
- _mntpoint=$(get_mntpoint_from_path $SAVE_PATH)
- _target=$(get_target_from_path $SAVE_PATH)
- if [ "$_mntpoint" != "/" ]; then
SAVE_PATH=${SAVE_PATH##"$_mntpoint"}
_fstype=$(get_fs_type_from_target $_target)
if [ "$_fstype" = "nfs" ]; then
add_dracut_module "nfs" fi
add_mount "$_target"
ficheck_size fs $_target
}
@@ -470,8 +474,6 @@ check_crypt() return 1 }
-check_block_dump_target
if ! check_resettable; then exit 1 fi @@ -549,6 +551,8 @@ do esac done < $conf_file
+handle_default_dump_target
if [ -n "$extra_modules" ] then add_dracut_arg "--add-drivers" "$extra_modules" -- 1.8.5.3
Hi,
do I understand it correctly that kdump will be able to automatically mount the filesystem(s) needed to access "path" if no partition is specified?
With regards to s-c-kdump, would it be sufficient to enable setting the "Path" textbox even when no partition is chosen in the "Partition" drop down menu? Does the path need some addition validation?
Is this change targeted at RHEL6/RHEL7/Fedora?
Thank you, Martin
On Fri, Mar 28, 2014 at 16:39:11 +0800, Baoquan He wrote:
Hi,
As Vivek previously suggested, I looked into the s-c-kdump setup. If the path which is mounted on by separate fs can be supported to be set as dump target, s-c-kdump is OK with it. The only thing is the save_path, it can not be changed when no disk is specified.
Now in s-c-kdump, there are 3 sections in "target setting" tab. For "Local Filesystem", user can select any separate disk which exist in current system, meanwhile specify a save_path. If "Partition" is "None", then "Path" would be "/var/crash" by default. Other 2 choices are "Raw device" and "Network".
For now, if both path with separate fs and explicitly specified dump target are supported, s-c-kdump may need be changed a little. E.g when "Partition" is "None", user can specify any "Path" which they have created. They decicde if a suitable fs is mounted on that "Path" so that a separate fs is used to store the dump vmcore or rootfs is used to store the dump.
Thanks Baoquan
On 03/21/14 at 05:55pm, Baoquan He wrote:
When user does not specify dump target explicitly, it's better to dump to the "path" specified. That means after dump user enter into 1st kernel, can find vmcore in the "path". If that path is in root fs, vmcore is stored in root fs. If separate disk is mounted on any tier of "path", we just dump vmcore into the left path on the left separate disk.
E.g in kdump.conf path /mnt/nfs
in mount info, /dev/vdb on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
Then vmcore will be saved in /nfs of /dev/vdb.
In this patch, pass mount info to dracut in this case if separate disk is mounted on any tier of "path".
Meanwhile introduce a function in kdump-lib.sh to check if any target is specified.
Signed-off-by: Baoquan He bhe@redhat.com Acked-by: Vivek Goyal vgoyal@redhat.com
kdump-lib.sh | 14 ++++++++++++++ mkdumprd | 34 +++++++++++++++++++--------------- 2 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 6c90ed5..d2562d1 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -53,6 +53,20 @@ get_user_configured_dump_disk() return }
+is_user_configured_dump_target() +{
- local _target
- if is_ssh_dump_target || is_nfs_dump_target; then
return 0
- fi
- _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw" /etc/kdump.conf 2>/dev/null |awk '{print $2}')
- [ -n "$_target" ] && return 0
- return 1
+}
get_root_fs_device() { local _target diff --git a/mkdumprd b/mkdumprd index c8333a3..6916de4 100644 --- a/mkdumprd +++ b/mkdumprd @@ -325,25 +325,29 @@ get_block_dump_target() [ -b "$_target" ] && echo $(to_dev_name $_target) }
-# If no dump disk is specified make sure /var/crash is not mounted on a -# separate disk. -check_block_dump_target() +#handle the case user does not specify the dump target explicitly +handle_default_dump_target() { local _target local _mntpoint
- local _fstype
- _target=$(get_user_configured_dump_disk)
- [ -n "$_target" ] && return
- is_user_configured_dump_target && return
- _target=$(get_root_fs_device)
- if [ -b "$_target" ]; then
mkdir -p $SAVE_PATH
_mntpoint=`df $SAVE_PATH | tail -1 | awk '{print $NF}'`
if [ "$_mntpoint" != "/" ]; then
perror "No dump target specified. Default dump target is rootfs block device."
perror "But dump path $SAVE_PATH is not backed by rootfs block device. "
perror_exit "Either explicitly specify a dump target or specify a dump path backed by rootfs block device"
- check_save_path_fs $SAVE_PATH
- _mntpoint=$(get_mntpoint_from_path $SAVE_PATH)
- _target=$(get_target_from_path $SAVE_PATH)
- if [ "$_mntpoint" != "/" ]; then
SAVE_PATH=${SAVE_PATH##"$_mntpoint"}
_fstype=$(get_fs_type_from_target $_target)
if [ "$_fstype" = "nfs" ]; then
add_dracut_module "nfs" fi
add_mount "$_target"
ficheck_size fs $_target
}
@@ -470,8 +474,6 @@ check_crypt() return 1 }
-check_block_dump_target
if ! check_resettable; then exit 1 fi @@ -549,6 +551,8 @@ do esac done < $conf_file
+handle_default_dump_target
if [ -n "$extra_modules" ] then add_dracut_arg "--add-drivers" "$extra_modules" -- 1.8.5.3
On Fri, Mar 28, 2014 at 02:01:15PM +0100, Martin Milata wrote:
Hi,
do I understand it correctly that kdump will be able to automatically mount the filesystem(s) needed to access "path" if no partition is specified?
Martin,
We will still expect target to be mounted in first kernel. Just that one should be able to only specify path and it is not mandatory to specify disk too.
For example, say you have mounted a disk /dev/sdb on /mnt/foo. And say you wanted dump to be saved in foo1 directory on disk sdb.
So far one will have to say following in /etc/kdump.conf to achive above.
ext4 /dev/sdb path /foo1
Now one should be able to achieve same goal by specifying.
path /mnt/foo/foo1
Kdump script will recognize that a disk is mounted on /mnt/foo and internally it will come up with target=/dev/sdb and path=/foo1.
So something which had to be done explicitly by user and now also be done by kdump script. User just has to pass full path of where dump needs to be saved.
With regards to s-c-kdump, would it be sufficient to enable setting the "Path" textbox even when no partition is chosen in the "Partition" drop down menu?
I think so. After this change, one should be able to change path even if target is not specified. Some kind of error checking would be good though to make sure path specified by user does exist.
Does the path need some addition validation?
We just need to make sure path exists.
Is this change targeted at RHEL6/RHEL7/Fedora?
This is fedora specific list so let us limit discussion to fedora only. We want to make this change in fedora because people have separate disk mounted in on /var and they expect dump to show up there automatically.
I think it will also make the configuraiton easier.
Thanks Vivek
On Fri, Mar 28, 2014 at 12:51:37 -0400, Vivek Goyal wrote:
On Fri, Mar 28, 2014 at 02:01:15PM +0100, Martin Milata wrote:
Hi,
do I understand it correctly that kdump will be able to automatically mount the filesystem(s) needed to access "path" if no partition is specified?
Martin,
We will still expect target to be mounted in first kernel. Just that one should be able to only specify path and it is not mandatory to specify disk too.
For example, say you have mounted a disk /dev/sdb on /mnt/foo. And say you wanted dump to be saved in foo1 directory on disk sdb.
So far one will have to say following in /etc/kdump.conf to achive above.
ext4 /dev/sdb path /foo1
Now one should be able to achieve same goal by specifying.
path /mnt/foo/foo1
Kdump script will recognize that a disk is mounted on /mnt/foo and internally it will come up with target=/dev/sdb and path=/foo1.
So something which had to be done explicitly by user and now also be done by kdump script. User just has to pass full path of where dump needs to be saved.
With regards to s-c-kdump, would it be sufficient to enable setting the "Path" textbox even when no partition is chosen in the "Partition" drop down menu?
I think so. After this change, one should be able to change path even if target is not specified. Some kind of error checking would be good though to make sure path specified by user does exist.
Nice, thanks for the explanation. I'm wondering whether s-c-kdump needs to know if the current kexec-tools support this feature. If we simply allow the path to be supplied regardless of kexec-tools version, the worst that can happen is that kdump.conf is generated which causes (an old version of) kdump to save the dump on root fs in the specified directory. Is that acceptable?
Does the path need some addition validation?
We just need to make sure path exists.
Is this change targeted at RHEL6/RHEL7/Fedora?
This is fedora specific list so let us limit discussion to fedora only. We want to make this change in fedora because people have separate disk mounted in on /var and they expect dump to show up there automatically.
I think it will also make the configuraiton easier.
Ah, sorry, should have looked at the name of the list.
Martin
On Mon, Mar 31, 2014 at 06:04:40PM +0200, Martin Milata wrote:
[..]
With regards to s-c-kdump, would it be sufficient to enable setting the "Path" textbox even when no partition is chosen in the "Partition" drop down menu?
I think so. After this change, one should be able to change path even if target is not specified. Some kind of error checking would be good though to make sure path specified by user does exist.
Nice, thanks for the explanation. I'm wondering whether s-c-kdump needs to know if the current kexec-tools support this feature. If we simply allow the path to be supplied regardless of kexec-tools version, the worst that can happen is that kdump.conf is generated which causes (an old version of) kdump to save the dump on root fs in the specified directory. Is that acceptable?
This sounds reasonable.
Thanks Vivek
If default target is a separate disk, the related information need be stored in /etc/kdump.conf of kdump initramfs. This includes the disk info which will help to deduce the dump_code and path which the vmcore will be written into.
Signed-off-by: Baoquan He bhe@redhat.com Acked-by: Vivek Goyal vgoyal@redhat.com --- dracut-module-setup.sh | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index bdadf7c..4c95e3d 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -261,6 +261,37 @@ kdump_install_net() { fi }
+default_dump_target_install_conf() +{ + local _target _fstype + local _s _t + local _mntpoint + local _path _save_path + + is_user_configured_dump_target && return + + _save_path=$(grep ^path "/etc/kdump.conf"| cut -d' ' -f2) + [ -z "$_save_path" ] && _save_path=$DEFAULT_PATH + + _mntpoint=$(get_mntpoint_from_path $_save_path) + _target=$(get_target_from_path $_save_path) + if [ "$_mntpoint" != "/" ]; then + _fstype=$(get_fs_type_from_target $_target) + + if [ "$_fstype" = "nfs" ];then + kdump_install_net "$_target" + else + _target=$(kdump_to_udev_name $_target) + fi + + echo "$_fstype $_target" >> /tmp/$$-kdump.conf + + _path=${_save_path##"$_mntpoint"} + sed -i -e "s#$_save_path#$_path#" /tmp/$$-kdump.conf + fi + +} + #install kdump.conf and what user specifies in kdump.conf kdump_install_conf() { sed -ne '/^#/!p' /etc/kdump.conf > /tmp/$$-kdump.conf @@ -285,6 +316,8 @@ kdump_install_conf() { esac done < /etc/kdump.conf
+ default_dump_target_install_conf + kdump_check_fence_kdump inst "/tmp/$$-kdump.conf" "/etc/kdump.conf" rm -f /tmp/$$-kdump.conf
In case no target is specified explicitly in /etc/kdump.conf, the behavior of path is changed, a check need be taken to see if any separate file system is mounted on any tier of 'path', and also to take the relevant action. Now the path section need be renewed accordingly.
Signed-off-by: Baoquan He bhe@redhat.com --- kexec-kdump-howto.txt | 50 +++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index 7ffeab9..5582e40 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -364,18 +364,46 @@ 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.
-By default, local file system vmcore files are written to /var/crash/%DATE -on the local system, ssh/scp dumps to /var/crash/%HOST-%DATE on the target -system, dedicated file system partition dumps to ./var/crash/%DATE, and -NFS dumps to ./var/crash/%HOST-%DATE, the latter two both relative to -their respective mount points within the kdump initrd (usually /mnt). The -'/var/crash' portion of the path can be overridden using kdump.conf's 'path' -variable, should you wish to write the vmcore out to a different location. For -example, 'path /data/coredumps' would lead to vmcore files being written to -/data/coredumps/%DATE if you were dumping to your local file system. Note -that the path option is ingnored if your kdump configuration results in the -core being saved from the initscripts in the root filesystem.
Kdump Post-Capture Executable
In case no target is specified explicitly in /etc/kdump.conf, the behavior of path is changed, a check need be taken to see if any separate file system is mounted on any tier of 'path', and also to take the relevant action. Now the path section need be renewed for kdump.conf and its man page accordingly.
Signed-off-by: Baoquan He bhe@redhat.com --- kdump.conf | 15 ++++++++++++--- kdump.conf.5 | 10 +++++++++- 2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/kdump.conf b/kdump.conf index a106462..d6f1123 100644 --- a/kdump.conf +++ b/kdump.conf @@ -35,9 +35,18 @@ # 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. -# If unset, will default to /var/crash. +# path <path> - "path" represents the file system path in which +# vmcore will be saved. If a dump target is specified +# in kdump.conf, then "path" is relative to the +# specified dump target. 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. +# Ignored for raw device dumps. If unset, will +# default to /var/crash. # # core_collector <command> <options> # - This allows you to specify the command to copy diff --git a/kdump.conf.5 b/kdump.conf.5 index 7eaf9dd..c338342 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -62,7 +62,15 @@ or uuid. It's recommended to use persistent device names such as
.B path <path> .RS -Append path to the filesystem device which you are dumping to. +"path" represents the file system path in which vmcore will be saved. +If a dump target is specified in kdump.conf, then "path" is relative to the +specified dump target. +.PP +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. +.PP Ignored for raw device dumps. If unset, will default to /var/crash. .RE