These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
v6->v7: Introduce is_fs_type_nfs to check if fstype is nfs or nfs4 per Vivek's idea.
Signed-off-by: Baoquan He bhe@redhat.com --- kdump-lib.sh | 28 ++++++++++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 831d063..e20197e 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_FILE="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send"
@@ -21,6 +22,13 @@ is_raw_dump_target() grep -q "^raw" /etc/kdump.conf }
+is_fs_type_nfs() +{ + local _fstype=$1 + [ $_fstype = "nfs" ] || [ $_fstype = "nfs4" ] && return 0 + return 1 +} + strip_comments() { echo $@ | sed -e 's/(.*)#.*/\1/' @@ -82,6 +90,26 @@ 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) +} + # get_option_value <option_name> # retrieves value of option defined in kdump.conf get_option_value() { diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 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 e20197e..c629af8 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -116,3 +116,29 @@ get_option_value() { echo $(strip_comments `grep ^$1 /etc/kdump.conf | tail -1 | cut -d\ -f2-`) }
+#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 + + [ -n $_target ] && _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 3849866..adf9167 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() { @@ -538,7 +507,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)
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.
v4->v5: Per Vivek's comment, add a helper function is_fs_dump_target. Then is_user_configured_dump_target is rewrite with these helper functions.
v5->v7: No v6 for this patch. Just use newly introduced function is_fs_type_nfs in handle_default_dump_target.
Signed-off-by: Baoquan He bhe@redhat.com --- kdump-lib.sh | 24 ++++++++++-------------- mkdumprd | 31 ++++++++++++++++++------------- 2 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index c629af8..a20c6e8 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -29,6 +29,16 @@ is_fs_type_nfs() return 1 }
+is_fs_dump_target() +{ + egrep -q "^ext[234]|^xfs|^btrfs|^minix" /etc/kdump.conf +} + +is_user_configured_dump_target() +{ + return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target) +} + strip_comments() { echo $@ | sed -e 's/(.*)#.*/\1/' @@ -67,20 +77,6 @@ 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 adf9167..0376320 100644 --- a/mkdumprd +++ b/mkdumprd @@ -325,24 +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
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 $(is_fs_type_nfs $_fstype); then + add_dracut_module "nfs" fi + + add_mount "$_target" + check_size fs $_target fi }
@@ -469,8 +474,6 @@ check_crypt() return 1 }
-check_block_dump_target - if ! check_resettable; then exit 1 fi @@ -548,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 04/11/14 at 08:27pm, 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.
v4->v5: Per Vivek's comment, add a helper function is_fs_dump_target. Then is_user_configured_dump_target is rewrite with these helper functions.
v5->v7: No v6 for this patch. Just use newly introduced function is_fs_type_nfs in handle_default_dump_target.
Signed-off-by: Baoquan He bhe@redhat.com
kdump-lib.sh | 24 ++++++++++-------------- mkdumprd | 31 ++++++++++++++++++------------- 2 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index c629af8..a20c6e8 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -29,6 +29,16 @@ is_fs_type_nfs() return 1 }
+is_fs_dump_target() +{
- egrep -q "^ext[234]|^xfs|^btrfs|^minix" /etc/kdump.conf
+}
+is_user_configured_dump_target() +{
- return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target)
Here $() is not correct for use.
You should do this:
is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target
or
return is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target
+}
strip_comments() { echo $@ | sed -e 's/(.*)#.*/\1/' @@ -67,20 +77,6 @@ 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 adf9167..0376320 100644 --- a/mkdumprd +++ b/mkdumprd @@ -325,24 +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
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" != "/" ]; thenperror "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 $(is_fs_type_nfs $_fstype); then
Again, should be:
if is_fs_type_nfs $_fstype; then [..] fi
Thanks WANG Chao
On Sun, Apr 13, 2014 at 12:48:47PM +0800, WANG Chao wrote:
[..]
+is_fs_dump_target() +{
- egrep -q "^ext[234]|^xfs|^btrfs|^minix" /etc/kdump.conf
+}
+is_user_configured_dump_target() +{
- return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target)
Here $() is not correct for use.
You should do this:
is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target
or
return is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target
Why it is not correct to call above in a subshell. I am curious to know what's wrong with that (apart from performance penalty).
Thanks Vivek
On 04/14/14 at 03:53pm, Vivek Goyal wrote:
On Sun, Apr 13, 2014 at 12:48:47PM +0800, WANG Chao wrote:
[..]
+is_fs_dump_target() +{
- egrep -q "^ext[234]|^xfs|^btrfs|^minix" /etc/kdump.conf
+}
+is_user_configured_dump_target() +{
- return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target)
Here $() is not correct for use.
You should do this:
is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target
or
return is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target
Why it is not correct to call above in a subshell. I am curious to know what's wrong with that (apart from performance penalty).
It would go wrong when the subshell returns a string.
Actually in this case, nothing would go wrong. Because subshell doesn't return anything back.
I'm just not too keen about such coding style.
Thanks WANG Chao
On Wed, Apr 16, 2014 at 03:12:35PM +0800, WANG Chao wrote:
On 04/14/14 at 03:53pm, Vivek Goyal wrote:
On Sun, Apr 13, 2014 at 12:48:47PM +0800, WANG Chao wrote:
[..]
+is_fs_dump_target() +{
- egrep -q "^ext[234]|^xfs|^btrfs|^minix" /etc/kdump.conf
+}
+is_user_configured_dump_target() +{
- return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target)
Here $() is not correct for use.
You should do this:
is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target
or
return is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target
Why it is not correct to call above in a subshell. I am curious to know what's wrong with that (apart from performance penalty).
It would go wrong when the subshell returns a string.
One can not return a string from function. I tried it and I got following message.
return: abc: numeric argument required
And if above functions return string, then non-shell call will also fails, isn't it. So this is not specific to calling a function in a sub-shell.
Actually in this case, nothing would go wrong. Because subshell doesn't return anything back.
I'm just not too keen about such coding style.
I am fine with that. Not calling them in sub-shell will make it faster too.
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.
v5->v7: No v6 for this patch. Just use newly introduced function is_fs_type_nfs in default_dump_target_install_conf().
Signed-off-by: Baoquan He bhe@redhat.com --- dracut-module-setup.sh | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 7a6ea17..2a16900 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -261,6 +261,38 @@ 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 $(is_fs_type_nfs $_fstype); then + kdump_install_net "$_target" + _fstype="nfs" + 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 +317,8 @@ kdump_install_conf() { esac done < /etc/kdump.conf
+ default_dump_target_install_conf + kdump_configure_fence_kdump "/tmp/$$-kdump.conf" 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 08bbe2a..54b581d 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 69628bd..f1c2a2c 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
On 04/11/14 at 08:26pm, Baoquan He wrote:
These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
v6->v7: Introduce is_fs_type_nfs to check if fstype is nfs or nfs4 per Vivek's idea.
Signed-off-by: Baoquan He bhe@redhat.com
Hi, Baoquan
I know it's late and it's v7 already. But I still feel like to bring up two minor nits.
kdump-lib.sh | 28 ++++++++++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 831d063..e20197e 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_FILE="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send"
@@ -21,6 +22,13 @@ is_raw_dump_target() grep -q "^raw" /etc/kdump.conf }
+is_fs_type_nfs() +{
- local _fstype=$1
- [ $_fstype = "nfs" ] || [ $_fstype = "nfs4" ] && return 0
- return 1
+}
strip_comments() { echo $@ | sed -e 's/(.*)#.*/\1/' @@ -82,6 +90,26 @@ get_root_fs_device() return }
+get_mntpoint_from_path() +{
- echo $(df $1 | tail -1 | awk '{print $NF}')
+}
How about using findmnt to unfiy these funtions below.
findmnt -k -f -n -r -o TARGET --target $1
+get_target_from_path() +{
- echo $(df $1 | tail -1 | awk '{print $1}')
+}
findmnt -k -f -n -r -o SOURCE --target $1
Thanks WANG Chao
+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)
+}
# get_option_value <option_name> # retrieves value of option defined in kdump.conf get_option_value() { diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 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 -- 1.8.5.3
On Fri, Apr 11, 2014 at 08:26:59PM +0800, Baoquan He wrote:
These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
v6->v7: Introduce is_fs_type_nfs to check if fstype is nfs or nfs4 per Vivek's idea.
Signed-off-by: Baoquan He bhe@redhat.com
Bao,
Can you please take care of issues raised by Chao and post another version of this patch series.
This is an important change and I want to get it in fedora ASAP.
Thanks Vivek
kdump-lib.sh | 28 ++++++++++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 831d063..e20197e 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_FILE="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send"
@@ -21,6 +22,13 @@ is_raw_dump_target() grep -q "^raw" /etc/kdump.conf }
+is_fs_type_nfs() +{
- local _fstype=$1
- [ $_fstype = "nfs" ] || [ $_fstype = "nfs4" ] && return 0
- return 1
+}
strip_comments() { echo $@ | sed -e 's/(.*)#.*/\1/' @@ -82,6 +90,26 @@ 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)
+}
# get_option_value <option_name> # retrieves value of option defined in kdump.conf get_option_value() { diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 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 -- 1.8.5.3
On 04/16/14 at 10:34am, Vivek Goyal wrote:
On Fri, Apr 11, 2014 at 08:26:59PM +0800, Baoquan He wrote:
These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
v6->v7: Introduce is_fs_type_nfs to check if fstype is nfs or nfs4 per Vivek's idea.
Signed-off-by: Baoquan He bhe@redhat.com
Bao,
Can you please take care of issues raised by Chao and post another version of this patch series.
This is an important change and I want to get it in fedora ASAP.
Sorry for this. It's v7 yet, just want to wait for you and Dave to review when convenient. I know you are busy recently.
Will talk to Chao face to face tomorrow, then he can merge it into fedora with newly change. I assume you have acked this patchset except of Chao's concern, right?
Thanks Baoquan
On Wed, Apr 16, 2014 at 11:12:02PM +0800, Baoquan He wrote:
On 04/16/14 at 10:34am, Vivek Goyal wrote:
On Fri, Apr 11, 2014 at 08:26:59PM +0800, Baoquan He wrote:
These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
v6->v7: Introduce is_fs_type_nfs to check if fstype is nfs or nfs4 per Vivek's idea.
Signed-off-by: Baoquan He bhe@redhat.com
Bao,
Can you please take care of issues raised by Chao and post another version of this patch series.
This is an important change and I want to get it in fedora ASAP.
Sorry for this. It's v7 yet, just want to wait for you and Dave to review when convenient. I know you are busy recently.
Will talk to Chao face to face tomorrow, then he can merge it into fedora with newly change. I assume you have acked this patchset except of Chao's concern, right?
Yep, I am fine with patches. Just take Cho's concerns into account.
Thanks Vivek
Hi Martin,
This patchset has been merged into kdump of Fedora, could you please update the related s-c-kdump accordingly when conveninet?
Since this change is very important, and the earlier Fedora user use and test it, the safer when we backport it to rhel7 (maybe rhel7.1).
Anyting I can help please let me know.
Thanks Baoquan
On 04/11/14 at 08:26pm, Baoquan He wrote:
These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
v6->v7: Introduce is_fs_type_nfs to check if fstype is nfs or nfs4 per Vivek's idea.
Signed-off-by: Baoquan He bhe@redhat.com
kdump-lib.sh | 28 ++++++++++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 831d063..e20197e 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_FILE="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send"
@@ -21,6 +22,13 @@ is_raw_dump_target() grep -q "^raw" /etc/kdump.conf }
+is_fs_type_nfs() +{
- local _fstype=$1
- [ $_fstype = "nfs" ] || [ $_fstype = "nfs4" ] && return 0
- return 1
+}
strip_comments() { echo $@ | sed -e 's/(.*)#.*/\1/' @@ -82,6 +90,26 @@ 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)
+}
# get_option_value <option_name> # retrieves value of option defined in kdump.conf get_option_value() { diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 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 -- 1.8.5.3
Hi, I have released system-config-kdump-2.0.15-1 for rawhide and F20 (currently in updates-testing). The new release allows you to select a path even if no FS is explicitly chosen.
Any testing is appreciated.
Cheers, Martin
On Tue, Apr 22, 2014 at 09:59:11 +0800, Baoquan He wrote:
Hi Martin,
This patchset has been merged into kdump of Fedora, could you please update the related s-c-kdump accordingly when conveninet?
Since this change is very important, and the earlier Fedora user use and test it, the safer when we backport it to rhel7 (maybe rhel7.1).
Anyting I can help please let me know.
Thanks Baoquan
On 04/11/14 at 08:26pm, Baoquan He wrote:
These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
v6->v7: Introduce is_fs_type_nfs to check if fstype is nfs or nfs4 per Vivek's idea.
Signed-off-by: Baoquan He bhe@redhat.com
kdump-lib.sh | 28 ++++++++++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 831d063..e20197e 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_FILE="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send"
@@ -21,6 +22,13 @@ is_raw_dump_target() grep -q "^raw" /etc/kdump.conf }
+is_fs_type_nfs() +{
- local _fstype=$1
- [ $_fstype = "nfs" ] || [ $_fstype = "nfs4" ] && return 0
- return 1
+}
strip_comments() { echo $@ | sed -e 's/(.*)#.*/\1/' @@ -82,6 +90,26 @@ 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)
+}
# get_option_value <option_name> # retrieves value of option defined in kdump.conf get_option_value() { diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 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 -- 1.8.5.3
Thanks Martin. Glad to hear that now system-config-kdump will also allowing only specifying the path.
Thanks Vivek
On Mon, May 12, 2014 at 06:05:59PM +0200, Martin Milata wrote:
Hi, I have released system-config-kdump-2.0.15-1 for rawhide and F20 (currently in updates-testing). The new release allows you to select a path even if no FS is explicitly chosen.
Any testing is appreciated.
Cheers, Martin
On Tue, Apr 22, 2014 at 09:59:11 +0800, Baoquan He wrote:
Hi Martin,
This patchset has been merged into kdump of Fedora, could you please update the related s-c-kdump accordingly when conveninet?
Since this change is very important, and the earlier Fedora user use and test it, the safer when we backport it to rhel7 (maybe rhel7.1).
Anyting I can help please let me know.
Thanks Baoquan
On 04/11/14 at 08:26pm, Baoquan He wrote:
These utility function will be shared by several files, they are all operation related to mount stuff.
Meantime define DEFAULT_PATH="/var/crash".
v5-> v6: Since in rhel7 nfs4 becomes default nfs version, and its fstype is nfs4. So change the implementation of get_fs_type_from_target(), whatever fstype returned from findmount, just echo nfs as fstype for all nfs version.
v6->v7: Introduce is_fs_type_nfs to check if fstype is nfs or nfs4 per Vivek's idea.
Signed-off-by: Baoquan He bhe@redhat.com
kdump-lib.sh | 28 ++++++++++++++++++++++++++++ mkdumprd | 2 +- 2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index 831d063..e20197e 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_FILE="/etc/sysconfig/fence_kdump" FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send"
@@ -21,6 +22,13 @@ is_raw_dump_target() grep -q "^raw" /etc/kdump.conf }
+is_fs_type_nfs() +{
- local _fstype=$1
- [ $_fstype = "nfs" ] || [ $_fstype = "nfs4" ] && return 0
- return 1
+}
strip_comments() { echo $@ | sed -e 's/(.*)#.*/\1/' @@ -82,6 +90,26 @@ 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)
+}
# get_option_value <option_name> # retrieves value of option defined in kdump.conf get_option_value() { diff --git a/mkdumprd b/mkdumprd index 84f1e18..3849866 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 -- 1.8.5.3
On 05/12/14 at 06:05pm, Martin Milata wrote:
Hi, I have released system-config-kdump-2.0.15-1 for rawhide and F20 (currently in updates-testing). The new release allows you to select a path even if no FS is explicitly chosen.
Any testing is appreciated.
Hi Martin,
Thanks for this update.
I tested s-c-k-2.0.15-1 on f20, when no target specified, "path" can be edited now. The diagram is like below with your update:
------------------------------------------------------------------ Path: /var/crash Local file system: Partition: Root file system core will be in /var/crash/%DATE on rootfs -----------------------------------------------------------------
There are some comments:
1) the text for Partition should be "Unspecified" in this case, since it can present that user didn't specify a target, "Root file system" is a little confusing, misguide user to think that core is dumped into rootfs device.
2) The string "core will be in /var/crash/%DATE on rootfs" may be not accurate for this case. If disk is mounted on /var or /var/crash, the core will be not in rootfs, just in a absolute path which begins from "/". So 2 different ideas are raised, one is to explain this "Path", namely "/var/crash" is a absolute path, the other is to tell user the mount info.
E.g: The text of 1st would be like: core will be in /var/crash/%DATE which is an absolute path
The text of 2nd would be like below (assume /dev/sdc mounted on /var) core will be in /crash/%DATE on ext4 /dev/sdc or (if no disk mounted on /var or /var/crash) core will be in /var/crash/%DATE on rootfs
I personally prefer the 1st, the 2nd could be more detailed. Let's review and discuss it.
Thanks Baoquan
On 05/13/14 at 01:51pm, Baoquan He wrote:
On 05/12/14 at 06:05pm, Martin Milata wrote:
Hi, I have released system-config-kdump-2.0.15-1 for rawhide and F20 (currently in updates-testing). The new release allows you to select a path even if no FS is explicitly chosen.
Any testing is appreciated.
Hi Martin,
Thanks for this update.
I tested s-c-k-2.0.15-1 on f20, when no target specified, "path" can be edited now. The diagram is like below with your update:
Path: /var/crashLocal file system: Partition: Root file system core will be in /var/crash/%DATE on rootfs
There are some comments:
- the text for Partition should be "Unspecified" in this case, since it
can present that user didn't specify a target, "Root file system" is a little confusing, misguide user to think that core is dumped into rootfs device.
- The string "core will be in /var/crash/%DATE on rootfs" may be not
accurate for this case. If disk is mounted on /var or /var/crash, the core will be not in rootfs, just in a absolute path which begins from "/". So 2 different ideas are raised, one is to explain this "Path", namely "/var/crash" is a absolute path, the other is to tell user the mount info.
E.g: The text of 1st would be like: core will be in /var/crash/%DATE which is an absolute path
The text of 2nd would be like below (assume /dev/sdc mounted on /var) core will be in /crash/%DATE on ext4 /dev/sdc
I vote for this one. It's more consistent with the existing output. And I think it's more comprehensive and intuitive for a kdump newbie.
or (if no disk mounted on /var or /var/crash) core will be in /var/crash/%DATE on rootfs
I personally prefer the 1st, the 2nd could be more detailed. Let's review and discuss it.
Thanks Baoquan
On Tue, May 13, 2014 at 13:51:16 +0800, Baoquan He wrote:
On 05/12/14 at 06:05pm, Martin Milata wrote:
Hi, I have released system-config-kdump-2.0.15-1 for rawhide and F20 (currently in updates-testing). The new release allows you to select a path even if no FS is explicitly chosen.
Any testing is appreciated.
Hi Martin,
Thanks for this update.
I tested s-c-k-2.0.15-1 on f20, when no target specified, "path" can be edited now. The diagram is like below with your update:
Path: /var/crashLocal file system: Partition: Root file system core will be in /var/crash/%DATE on rootfs
There are some comments:
- the text for Partition should be "Unspecified" in this case, since it
can present that user didn't specify a target, "Root file system" is a little confusing, misguide user to think that core is dumped into rootfs device.
Good point! I'll change it.
- The string "core will be in /var/crash/%DATE on rootfs" may be not
accurate for this case. If disk is mounted on /var or /var/crash, the core will be not in rootfs, just in a absolute path which begins from "/". So 2 different ideas are raised, one is to explain this "Path", namely "/var/crash" is a absolute path, the other is to tell user the mount info.
E.g: The text of 1st would be like: core will be in /var/crash/%DATE which is an absolute path
The text of 2nd would be like below (assume /dev/sdc mounted on /var) core will be in /crash/%DATE on ext4 /dev/sdc or (if no disk mounted on /var or /var/crash) core will be in /var/crash/%DATE on rootfs
I personally prefer the 1st, the 2nd could be more detailed. Let's review and discuss it.
The second option sounds better to me as well. I'll look into it and provide a new build.
These new texts won't be true for old kexec-tools versions that do not have the auto-mounting feature. I propose to solve this by requiring a new enough version of kexec-tools for system-config-kdump. What is the N-V-R of the first version with this feature?
Thank you for testing and suggestions, Martin
On Tue, May 13, 2014 at 12:36:04PM +0200, Martin Milata wrote:
On Tue, May 13, 2014 at 13:51:16 +0800, Baoquan He wrote:
On 05/12/14 at 06:05pm, Martin Milata wrote:
Hi, I have released system-config-kdump-2.0.15-1 for rawhide and F20 (currently in updates-testing). The new release allows you to select a path even if no FS is explicitly chosen.
Any testing is appreciated.
Hi Martin,
Thanks for this update.
I tested s-c-k-2.0.15-1 on f20, when no target specified, "path" can be edited now. The diagram is like below with your update:
Path: /var/crashLocal file system: Partition: Root file system core will be in /var/crash/%DATE on rootfs
There are some comments:
- the text for Partition should be "Unspecified" in this case, since it
can present that user didn't specify a target, "Root file system" is a little confusing, misguide user to think that core is dumped into rootfs device.
Good point! I'll change it.
- The string "core will be in /var/crash/%DATE on rootfs" may be not
accurate for this case. If disk is mounted on /var or /var/crash, the core will be not in rootfs, just in a absolute path which begins from "/". So 2 different ideas are raised, one is to explain this "Path", namely "/var/crash" is a absolute path, the other is to tell user the mount info.
E.g: The text of 1st would be like: core will be in /var/crash/%DATE which is an absolute path
The text of 2nd would be like below (assume /dev/sdc mounted on /var) core will be in /crash/%DATE on ext4 /dev/sdc or (if no disk mounted on /var or /var/crash) core will be in /var/crash/%DATE on rootfs
I personally prefer the 1st, the 2nd could be more detailed. Let's review and discuss it.
The second option sounds better to me as well. I'll look into it and provide a new build.
These new texts won't be true for old kexec-tools versions that do not have the auto-mounting feature. I propose to solve this by requiring a new enough version of kexec-tools for system-config-kdump. What is the N-V-R of the first version with this feature?
I am not a big fan of this idea. Why not leave it as follows.
------------------------------------------------------------------ Path: /var/crash Local file system: Partition: core will be in /var/crash/%DATE/ -----------------------------------------------------------------
Reason being.
- First of all now system-config-kdump will have to implement the logic to map which disk /var/crash is mounted on and then do the relative path calculation on that disk.
- More importantly, this is not kdump API. If kdump changes behavior down the line, system-config-kdump will be out of sync again.
So to me let us not try to be too intelligent. Once we say core will be saved in /var/crash/%DATE, I think it is clear. Who cares what's the disk and what's the filesystem. Admin has plenty of ways to figure out what's the disk backing /var/crash/.
Thanks Vivek
On Tue, May 13, 2014 at 09:02:31 -0400, Vivek Goyal wrote:
On Tue, May 13, 2014 at 12:36:04PM +0200, Martin Milata wrote:
On Tue, May 13, 2014 at 13:51:16 +0800, Baoquan He wrote:
On 05/12/14 at 06:05pm, Martin Milata wrote:
Hi, I have released system-config-kdump-2.0.15-1 for rawhide and F20 (currently in updates-testing). The new release allows you to select a path even if no FS is explicitly chosen.
Any testing is appreciated.
Hi Martin,
Thanks for this update.
I tested s-c-k-2.0.15-1 on f20, when no target specified, "path" can be edited now. The diagram is like below with your update:
Path: /var/crashLocal file system: Partition: Root file system core will be in /var/crash/%DATE on rootfs
There are some comments:
- the text for Partition should be "Unspecified" in this case, since it
can present that user didn't specify a target, "Root file system" is a little confusing, misguide user to think that core is dumped into rootfs device.
Good point! I'll change it.
- The string "core will be in /var/crash/%DATE on rootfs" may be not
accurate for this case. If disk is mounted on /var or /var/crash, the core will be not in rootfs, just in a absolute path which begins from "/". So 2 different ideas are raised, one is to explain this "Path", namely "/var/crash" is a absolute path, the other is to tell user the mount info.
E.g: The text of 1st would be like: core will be in /var/crash/%DATE which is an absolute path
The text of 2nd would be like below (assume /dev/sdc mounted on /var) core will be in /crash/%DATE on ext4 /dev/sdc or (if no disk mounted on /var or /var/crash) core will be in /var/crash/%DATE on rootfs
I personally prefer the 1st, the 2nd could be more detailed. Let's review and discuss it.
The second option sounds better to me as well. I'll look into it and provide a new build.
These new texts won't be true for old kexec-tools versions that do not have the auto-mounting feature. I propose to solve this by requiring a new enough version of kexec-tools for system-config-kdump. What is the N-V-R of the first version with this feature?
I am not a big fan of this idea. Why not leave it as follows.
Path: /var/crashLocal file system: Partition: core will be in /var/crash/%DATE/
Reason being.
First of all now system-config-kdump will have to implement the logic to map which disk /var/crash is mounted on and then do the relative path calculation on that disk.
More importantly, this is not kdump API. If kdump changes behavior down the line, system-config-kdump will be out of sync again.
So to me let us not try to be too intelligent. Once we say core will be saved in /var/crash/%DATE, I think it is clear. Who cares what's the disk and what's the filesystem. Admin has plenty of ways to figure out what's the disk backing /var/crash/.
Oops, I didn't catch this email yesterday and went ahead implementing it. Scratch builds if you want to try it:
F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848717 rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848763
To be honest, I have no idea what's more suitable for a typical s-c-kdump user. I agree with Vivek's point about trying to be smarter than the user. Perhaps we should use what he proposes but with a Partition: combobox item that concisely explains what's going on?
Martin
On Wed, May 14, 2014 at 03:16:39PM +0200, Martin Milata wrote:
[..]
I am not a big fan of this idea. Why not leave it as follows.
Path: /var/crashLocal file system: Partition: core will be in /var/crash/%DATE/
Reason being.
First of all now system-config-kdump will have to implement the logic to map which disk /var/crash is mounted on and then do the relative path calculation on that disk.
More importantly, this is not kdump API. If kdump changes behavior down the line, system-config-kdump will be out of sync again.
So to me let us not try to be too intelligent. Once we say core will be saved in /var/crash/%DATE, I think it is clear. Who cares what's the disk and what's the filesystem. Admin has plenty of ways to figure out what's the disk backing /var/crash/.
Oops, I didn't catch this email yesterday and went ahead implementing it. Scratch builds if you want to try it:
F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848717 rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848763
Hi Martin,
If you have already done the changes, I guess there is no need to revert it.
So after your changes, how do all three fields look like for the case where /var/crash is mounted on some other disk, say /dev/foo.
Thanks Vivek
On Wed, May 14, 2014 at 11:50:39 -0400, Vivek Goyal wrote:
On Wed, May 14, 2014 at 03:16:39PM +0200, Martin Milata wrote:
[..]
I am not a big fan of this idea. Why not leave it as follows.
Path: /var/crashLocal file system: Partition: core will be in /var/crash/%DATE/
Reason being.
First of all now system-config-kdump will have to implement the logic to map which disk /var/crash is mounted on and then do the relative path calculation on that disk.
More importantly, this is not kdump API. If kdump changes behavior down the line, system-config-kdump will be out of sync again.
So to me let us not try to be too intelligent. Once we say core will be saved in /var/crash/%DATE, I think it is clear. Who cares what's the disk and what's the filesystem. Admin has plenty of ways to figure out what's the disk backing /var/crash/.
Oops, I didn't catch this email yesterday and went ahead implementing it. Scratch builds if you want to try it:
F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848717 rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848763
Hi Martin,
If you have already done the changes, I guess there is no need to revert it.
So after your changes, how do all three fields look like for the case where /var/crash is mounted on some other disk, say /dev/foo.
If /dev/foo (ext4) is mounted on /var/crash then it looks like this:
------------------------------------------------------------------ Path: /var/crash Local file system: Partition: Unspecified core will be in /%DATE on ext4 /dev/foo ------------------------------------------------------------------
Martin
On Thu, May 15, 2014 at 11:30:22AM +0200, Martin Milata wrote: [..]
Oops, I didn't catch this email yesterday and went ahead implementing it. Scratch builds if you want to try it:
F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848717 rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848763
Hi Martin,
If you have already done the changes, I guess there is no need to revert it.
So after your changes, how do all three fields look like for the case where /var/crash is mounted on some other disk, say /dev/foo.
If /dev/foo (ext4) is mounted on /var/crash then it looks like this:
Path: /var/crashLocal file system: Partition: Unspecified core will be in /%DATE on ext4 /dev/foo
Ok, this looks reasonable.
Thanks Vivek
On Fri, May 16, 2014 at 08:10:02 -0400, Vivek Goyal wrote:
On Thu, May 15, 2014 at 11:30:22AM +0200, Martin Milata wrote: [..]
Oops, I didn't catch this email yesterday and went ahead implementing it. Scratch builds if you want to try it:
F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848717 rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848763
Hi Martin,
If you have already done the changes, I guess there is no need to revert it.
So after your changes, how do all three fields look like for the case where /var/crash is mounted on some other disk, say /dev/foo.
If /dev/foo (ext4) is mounted on /var/crash then it looks like this:
Path: /var/crashLocal file system: Partition: Unspecified core will be in /%DATE on ext4 /dev/foo
Ok, this looks reasonable.
Now built as system-config-kdump-2.0.15-2.fc21 for rawhide. I'm ready to drop the partition detection logic if it proves to be confusing or buggy.
Martin
On 05/16/14 at 02:50pm, Martin Milata wrote:
On Fri, May 16, 2014 at 08:10:02 -0400, Vivek Goyal wrote:
On Thu, May 15, 2014 at 11:30:22AM +0200, Martin Milata wrote: [..]
Oops, I didn't catch this email yesterday and went ahead implementing it. Scratch builds if you want to try it:
F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848717 rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848763
Hi Martin,
If you have already done the changes, I guess there is no need to revert it.
So after your changes, how do all three fields look like for the case where /var/crash is mounted on some other disk, say /dev/foo.
If /dev/foo (ext4) is mounted on /var/crash then it looks like this:
Path: /var/crashLocal file system: Partition: Unspecified core will be in /%DATE on ext4 /dev/foo
Ok, this looks reasonable.
Now built as system-config-kdump-2.0.15-2.fc21 for rawhide. I'm ready to drop the partition detection logic if it proves to be confusing or buggy.
Hi Martin,
I tested your update, it's like what we have discussed as below:
------------------------------------------------------------------ Path: /var/crash Local file system: Partition: Unspecified core will be in /%DATE on ext4 /dev/foo ------------------------------------------------------------------
About the change related to "Path", we all have agreed on this. Thanks for your effort.
After several times of operations, erorr happened and below message was printed, paste it here for your reference.
[bhe@localhost ~]$ system-config-kdump /usr/share/system-config-kdump/system-config-kdump.py:343: GtkWarning: IA__gtk_radio_button_set_group: assertion '!g_slist_find (group, radio_button)' failed "/usr/share/system-config-kdump/system-config-kdump.glade")
Thanks Baoquan
On Mon, May 19, 2014 at 12:31:10 +0800, Baoquan He wrote:
On 05/16/14 at 02:50pm, Martin Milata wrote:
On Fri, May 16, 2014 at 08:10:02 -0400, Vivek Goyal wrote:
On Thu, May 15, 2014 at 11:30:22AM +0200, Martin Milata wrote: [..]
Oops, I didn't catch this email yesterday and went ahead implementing it. Scratch builds if you want to try it:
F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848717 rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848763
Hi Martin,
If you have already done the changes, I guess there is no need to revert it.
So after your changes, how do all three fields look like for the case where /var/crash is mounted on some other disk, say /dev/foo.
If /dev/foo (ext4) is mounted on /var/crash then it looks like this:
Path: /var/crashLocal file system: Partition: Unspecified core will be in /%DATE on ext4 /dev/foo
Ok, this looks reasonable.
Now built as system-config-kdump-2.0.15-2.fc21 for rawhide. I'm ready to drop the partition detection logic if it proves to be confusing or buggy.
Hi Martin,
I tested your update, it's like what we have discussed as below:
Path: /var/crash Local file system: Partition: Unspecified core will be in /%DATE on ext4 /dev/foo
About the change related to "Path", we all have agreed on this. Thanks for your effort.
After several times of operations, erorr happened and below message was printed, paste it here for your reference.
[bhe@localhost ~]$ system-config-kdump /usr/share/system-config-kdump/system-config-kdump.py:343: GtkWarning: IA__gtk_radio_button_set_group: assertion '!g_slist_find (group, radio_button)' failed "/usr/share/system-config-kdump/system-config-kdump.glade")
Did system-config-kdump crash as a result of this warning? GTK tends to print messages like that with no apparent effect. If it crashes system-config-kdump, do you know how to reproduce it?
Thanks, Martin
On 05/19/14 at 12:22pm, Martin Milata wrote:
On Mon, May 19, 2014 at 12:31:10 +0800, Baoquan He wrote:
On 05/16/14 at 02:50pm, Martin Milata wrote:
On Fri, May 16, 2014 at 08:10:02 -0400, Vivek Goyal wrote:
On Thu, May 15, 2014 at 11:30:22AM +0200, Martin Milata wrote: [..]
> Oops, I didn't catch this email yesterday and went ahead implementing > it. Scratch builds if you want to try it: > > F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848717 > rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=6848763
Hi Martin,
If you have already done the changes, I guess there is no need to revert it.
So after your changes, how do all three fields look like for the case where /var/crash is mounted on some other disk, say /dev/foo.
If /dev/foo (ext4) is mounted on /var/crash then it looks like this:
Path: /var/crashLocal file system: Partition: Unspecified core will be in /%DATE on ext4 /dev/foo
Ok, this looks reasonable.
Now built as system-config-kdump-2.0.15-2.fc21 for rawhide. I'm ready to drop the partition detection logic if it proves to be confusing or buggy.
Hi Martin,
I tested your update, it's like what we have discussed as below:
Path: /var/crash Local file system: Partition: Unspecified core will be in /%DATE on ext4 /dev/foo
About the change related to "Path", we all have agreed on this. Thanks for your effort.
After several times of operations, erorr happened and below message was printed, paste it here for your reference.
[bhe@localhost ~]$ system-config-kdump /usr/share/system-config-kdump/system-config-kdump.py:343: GtkWarning: IA__gtk_radio_button_set_group: assertion '!g_slist_find (group, radio_button)' failed "/usr/share/system-config-kdump/system-config-kdump.glade")
Did system-config-kdump crash as a result of this warning? GTK tends to print messages like that with no apparent effect. If it crashes system-config-kdump, do you know how to reproduce it?
I remember I just open s-c-k in term, then close it to change the mount information, then open again. After several times, it just crashed.
Thanks, Martin
-
Baoquan He -
Martin Milata -
Vivek Goyal -
WANG Chao