There are some complaints about nfs kdump that users must mount nfs beforehand, which may cause some overhead to nfs server. For example, there're thounsands of diskless clients deployed with nfs dumping, each time the client is boot up, it will trigger kdump rebuilding so will mount nfs, thus resulting in thousands of nfs request concurrently imposed on the same nfs server.
We introduce a new way of specifying mount information via the already-existent "dracut_args" directive(so avoid adding extra directives in /etc/kdump.conf), we will skip all the filesystem mounting and checking stuff for it. So it can be used in the above-mentioned nfs scenario to avoid severe nfs server overhead.
Specifically, if there is any "--mount" information specified via "dracut_args" in /etc/kdump.conf, always use it as the final mount without any validation(mounting or checking like mount options, fs size, etc), so users are expected to ensure its correctness.
When doing nfs mount via "dracut_args", because nfs needn't to be mounted beforehand, some nfs-related ko modules must be explicitly specified as needed together in the "dracut_args"(or via directive "extra_modules" in /etc/kdump.conf). As an nfs example: dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
NOTE: -Only one mount target is allowed using "dracut_args" globally. -Dracut will create <mountpoint> if it doesn't exist in kdump kernel, <mountpoint> must be specified in an absolute path. -There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". -Users should do a test first and ensure it works because kdump does not prepare the mount and check all the validity.
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com --- dracut-kdump.sh | 6 +++++- dracut-module-setup.sh | 5 +++++ kdump-lib.sh | 41 ++++++++++++++++++++++++++++++++++++++++- kdumpctl | 13 ++++++++++++- mkdumprd | 3 +++ 5 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index 4aab205..8747dba 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -117,7 +117,7 @@ save_vmcore_dmesg_ssh() { get_host_ip() { local _host - if is_nfs_dump_target || is_ssh_dump_target + if is_nfs_dump_target || is_ssh_dump_target || does_dracut_args_contain_nfsmount then kdumpnic=$(getarg kdumpnic=) [ -z "$kdumpnic" ] && echo "kdump: failed to get kdumpnic!" && return 1 @@ -146,6 +146,10 @@ read_kdump_conf() # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) case "$config_opt" in + dracut_args) + config_val=$(get_dracut_args_target "$config_val") + [[ -n "$config_val" ]] && add_dump_code "dump_fs $config_val" + ;; ext[234]|xfs|btrfs|minix|nfs) add_dump_code "dump_fs $config_val" ;; diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 4cd7107..5f03558 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -433,6 +433,11 @@ kdump_install_conf() { ssh|nfs) kdump_install_net "$config_val" ;; + dracut_args) + if is_nfs_in_dracut_args "$config_val"; then + kdump_install_net "$(get_dracut_args_target "$config_val")" + fi + ;; kdump_pre|kdump_post|extra_bins) dracut_install $config_val ;; diff --git a/kdump-lib.sh b/kdump-lib.sh index fc2c036..a486db6 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -45,7 +45,8 @@ is_fs_dump_target()
is_user_configured_dump_target() { - return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target) + return $(does_dracut_args_contain_mount || is_ssh_dump_target || is_nfs_dump_target || \ + is_raw_dump_target || is_fs_dump_target) }
strip_comments() @@ -279,3 +280,41 @@ is_hostname() fi echo $1 | grep -q "[a-zA-Z]" } + +# If "dracut_args" contains "--mount" information, use it +# directly without any check(users are expected to ensure +# its correctness). +does_dracut_args_contain_mount() +{ + return $(grep ^dracut_args /etc/kdump.conf | grep -q "--mount") +} + +does_dracut_args_contain_nfsmount() +{ + local fstype + + fstype=$(grep "^dracut_args .*--mount" /etc/kdump.conf | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f3) + [[ $fstype = nfs* ]] && return 0 + + return 1 +} + +# $1: configuration value of "dracut_args". +is_nfs_in_dracut_args() +{ + [[ $(get_dracut_args_fstype "$1") = nfs* ]] && return 0 + + return 1 +} + +# $1: configuration value of "dracut_args". +get_dracut_args_fstype() +{ + echo $1 | grep "--mount" | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f3 +} + +# $1: configuration value of "dracut_args". +get_dracut_args_target() +{ + echo $1 | grep "--mount" | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f1 +} diff --git a/kdumpctl b/kdumpctl index fcc9ad0..fbed66d 100755 --- a/kdumpctl +++ b/kdumpctl @@ -236,12 +236,18 @@ check_config() { local nr
- nr=$(awk 'BEGIN{cnt=0} /^raw|^ssh[[:blank:]]|^nfs|^ext[234]|^xfs|^btrfs|^minix/{cnt++} END{print cnt}' $KDUMP_CONFIG_FILE) + nr=$(awk 'BEGIN{cnt=0} /^raw|^ssh[[:blank:]]|^nfs|^ext[234]|^xfs|^btrfs|^minix|^dracut_args .*--mount/{cnt++} END{print cnt}' $KDUMP_CONFIG_FILE) [ $nr -gt 1 ] && { echo "More than one dump targets specified." return 1 }
+ nr=$(grep "^dracut_args .*--mount" $KDUMP_CONFIG_FILE | grep -o "--mount" | wc -l) + [ $nr -gt 1 ] && { + echo "More than one mount targets specified in "dracut_args"." + return 1 + } + while read config_opt config_val; do # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) @@ -365,6 +371,11 @@ check_dump_fs_modified() local _new_dev _new_mntpoint _new_fstype local _target _path _dracut_args
+ # No need to check in case of mount target specified via "dracut_args". + if does_dracut_args_contain_mount; then + return 0 + fi + # No need to check in case of raw target. # Currently we do not check also if ssh/nfs target is specified if is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target; then diff --git a/mkdumprd b/mkdumprd index 78afb1a..7a0e733 100644 --- a/mkdumprd +++ b/mkdumprd @@ -544,6 +544,9 @@ do verify_core_collector "$config_val" ;; dracut_args) + if is_nfs_in_dracut_args "$config_val"; then + add_dracut_module "nfs" + fi add_dracut_arg $config_val ;; *)
Update "kexec-kdump-howto" to illustrate the usage of special mount information via "dracut_args".
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com --- kexec-kdump-howto.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index b4cdc22..f7c6811 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -345,6 +345,37 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
+Special mount via "dracut_args" + +Kdump uses dracut to generate initramfs for second kernel. This option +allows a user to pass arguments to dracut directly. + +Users can utilize "dracut_args" to pass "--mount" to kdump, please refer +to "man dracut" for the format of "--mount" argument. If there is any +"--mount" specified via "dracut_args", kdump always uses it as the final +mount target without any validation(mounting or checking like mount options, +fs size, save path, etc), so users are expected to ensure all the correctness. +It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs". + +This is useful when we want to deploy thoundsands of diskless clients using +nfs dumping and share the same nfs server. In this scenario, each time the +clients are booting up, the kdump initramfs rebuild will be triggered due to +the diskless environment, so all the clients will request nfs mount simultaneouly, +thereby imposing very much burdon on the shared nfs server. With the help of +special mount via "dracut_args", kdump can skip mounting and resolve the issue. +Because nfs needn't to be mounted beforehand, some nfs-related ko modules will +be explicitly specified as needed together in the "dracut_args"(or via directive +"extra_modules" in /etc/kdump.conf). As an nfs mount example: +dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4" + +NOTE: +-Only one mount target is allowed using "dracut_args" globally. +-Dracut will create <mountpoint> if it doesn't exist in kdump kernel, + <mountpoint> must be specified in an absolute path. +-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". +-Users should do a test first and ensure it works, because kdump does + not prepare the mount and check all the validity. + Remote system via ssh/scp
Dumping over ssh/scp requires setting up passwordless ssh keys for every
On 26/05/2016:09:08:04 PM, Xunlei Pang wrote:
There are some complaints about nfs kdump that users must mount nfs beforehand, which may cause some overhead to nfs server. For example, there're thounsands of diskless clients deployed with nfs dumping, each time the client is boot up, it will trigger kdump rebuilding so will mount nfs, thus resulting in thousands of nfs request concurrently imposed on the same nfs server.
We introduce a new way of specifying mount information via the already-existent "dracut_args" directive(so avoid adding extra directives in /etc/kdump.conf), we will skip all the filesystem mounting and checking stuff for it. So it can be used in the above-mentioned nfs scenario to avoid severe nfs server overhead.
Specifically, if there is any "--mount" information specified via "dracut_args" in /etc/kdump.conf, always use it as the final mount without any validation(mounting or checking like mount options, fs size, etc), so users are expected to ensure its correctness.
When doing nfs mount via "dracut_args", because nfs needn't to be mounted beforehand, some nfs-related ko modules must be explicitly specified as needed together in the "dracut_args"(or via directive "extra_modules" in /etc/kdump.conf). As an nfs example: dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
NOTE: -Only one mount target is allowed using "dracut_args" globally. -Dracut will create <mountpoint> if it doesn't exist in kdump kernel, <mountpoint> must be specified in an absolute path. -There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". -Users should do a test first and ensure it works because kdump does not prepare the mount and check all the validity.
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
Reviewed-by: Pratyush Anand panand@redhat.com
dracut-kdump.sh | 6 +++++- dracut-module-setup.sh | 5 +++++ kdump-lib.sh | 41 ++++++++++++++++++++++++++++++++++++++++- kdumpctl | 13 ++++++++++++- mkdumprd | 3 +++ 5 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index 4aab205..8747dba 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -117,7 +117,7 @@ save_vmcore_dmesg_ssh() { get_host_ip() { local _host
- if is_nfs_dump_target || is_ssh_dump_target
- if is_nfs_dump_target || is_ssh_dump_target || does_dracut_args_contain_nfsmount then kdumpnic=$(getarg kdumpnic=) [ -z "$kdumpnic" ] && echo "kdump: failed to get kdumpnic!" && return 1
@@ -146,6 +146,10 @@ read_kdump_conf() # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) case "$config_opt" in
dracut_args)config_val=$(get_dracut_args_target "$config_val")[[ -n "$config_val" ]] && add_dump_code "dump_fs $config_val";; ext[234]|xfs|btrfs|minix|nfs) add_dump_code "dump_fs $config_val" ;;diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 4cd7107..5f03558 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -433,6 +433,11 @@ kdump_install_conf() { ssh|nfs) kdump_install_net "$config_val" ;;
dracut_args)if is_nfs_in_dracut_args "$config_val"; thenkdump_install_net "$(get_dracut_args_target "$config_val")"fi;; kdump_pre|kdump_post|extra_bins) dracut_install $config_val ;;diff --git a/kdump-lib.sh b/kdump-lib.sh index fc2c036..a486db6 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -45,7 +45,8 @@ is_fs_dump_target()
is_user_configured_dump_target() {
- return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target)
- return $(does_dracut_args_contain_mount || is_ssh_dump_target || is_nfs_dump_target || \
is_raw_dump_target || is_fs_dump_target)}
strip_comments() @@ -279,3 +280,41 @@ is_hostname() fi echo $1 | grep -q "[a-zA-Z]" }
+# If "dracut_args" contains "--mount" information, use it +# directly without any check(users are expected to ensure +# its correctness). +does_dracut_args_contain_mount() +{
- return $(grep ^dracut_args /etc/kdump.conf | grep -q "--mount")
+}
+does_dracut_args_contain_nfsmount() +{
- local fstype
- fstype=$(grep "^dracut_args .*--mount" /etc/kdump.conf | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f3)
- [[ $fstype = nfs* ]] && return 0
- return 1
+}
+# $1: configuration value of "dracut_args". +is_nfs_in_dracut_args() +{
- [[ $(get_dracut_args_fstype "$1") = nfs* ]] && return 0
- return 1
+}
+# $1: configuration value of "dracut_args". +get_dracut_args_fstype() +{
- echo $1 | grep "--mount" | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f3
+}
+# $1: configuration value of "dracut_args". +get_dracut_args_target() +{
- echo $1 | grep "--mount" | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f1
+} diff --git a/kdumpctl b/kdumpctl index fcc9ad0..fbed66d 100755 --- a/kdumpctl +++ b/kdumpctl @@ -236,12 +236,18 @@ check_config() { local nr
- nr=$(awk 'BEGIN{cnt=0} /^raw|^ssh[[:blank:]]|^nfs|^ext[234]|^xfs|^btrfs|^minix/{cnt++} END{print cnt}' $KDUMP_CONFIG_FILE)
nr=$(awk 'BEGIN{cnt=0} /^raw|^ssh[[:blank:]]|^nfs|^ext[234]|^xfs|^btrfs|^minix|^dracut_args .*--mount/{cnt++} END{print cnt}' $KDUMP_CONFIG_FILE) [ $nr -gt 1 ] && { echo "More than one dump targets specified." return 1 }
nr=$(grep "^dracut_args .*--mount" $KDUMP_CONFIG_FILE | grep -o "--mount" | wc -l)
[ $nr -gt 1 ] && {
echo "More than one mount targets specified in \"dracut_args\"."return 1}
while read config_opt config_val; do # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val)
@@ -365,6 +371,11 @@ check_dump_fs_modified() local _new_dev _new_mntpoint _new_fstype local _target _path _dracut_args
- # No need to check in case of mount target specified via "dracut_args".
- if does_dracut_args_contain_mount; then
return 0- fi
- # No need to check in case of raw target. # Currently we do not check also if ssh/nfs target is specified if is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target; then
diff --git a/mkdumprd b/mkdumprd index 78afb1a..7a0e733 100644 --- a/mkdumprd +++ b/mkdumprd @@ -544,6 +544,9 @@ do verify_core_collector "$config_val" ;; dracut_args)
if is_nfs_in_dracut_args "$config_val"; thenadd_dracut_module "nfs"fi add_dracut_arg $config_val ;;-- 1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
On 26/05/2016:09:08:05 PM, Xunlei Pang wrote:
Update "kexec-kdump-howto" to illustrate the usage of special mount information via "dracut_args".
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
kexec-kdump-howto.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index b4cdc22..f7c6811 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -345,6 +345,37 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
+Special mount via "dracut_args"
+Kdump uses dracut to generate initramfs for second kernel. This option +allows a user to pass arguments to dracut directly.
+Users can utilize "dracut_args" to pass "--mount" to kdump, please refer +to "man dracut" for the format of "--mount" argument. If there is any +"--mount" specified via "dracut_args", kdump always uses it as the final +mount target without any validation(mounting or checking like mount options, +fs size, save path, etc), so users are expected to ensure all the correctness. +It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs".
+This is useful when we want to deploy thoundsands of diskless clients using +nfs dumping and share the same nfs server. In this scenario, each time the +clients are booting up, the kdump initramfs rebuild will be triggered due to +the diskless environment, so all the clients will request nfs mount simultaneouly, +thereby imposing very much burdon on the shared nfs server. With the help of
^^^^^^^^^ Probably "too much" would have been better wording..
+special mount via "dracut_args", kdump can skip mounting and resolve the issue. +Because nfs needn't to be mounted beforehand, some nfs-related ko modules will +be explicitly specified as needed together in the "dracut_args"(or via directive +"extra_modules" in /etc/kdump.conf). As an nfs mount example: +dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
+NOTE: +-Only one mount target is allowed using "dracut_args" globally. +-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
- <mountpoint> must be specified in an absolute path.
+-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". +-Users should do a test first and ensure it works, because kdump does
- not prepare the mount and check all the validity.
Remote system via ssh/scp
Dumping over ssh/scp requires setting up passwordless ssh keys for every
Other than that
Reviewed-by: Pratyush Anand panand@redhat.com
On 2016/05/27 at 11:19, Pratyush Anand wrote:
On 26/05/2016:09:08:05 PM, Xunlei Pang wrote:
Update "kexec-kdump-howto" to illustrate the usage of special mount information via "dracut_args".
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
kexec-kdump-howto.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index b4cdc22..f7c6811 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -345,6 +345,37 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
+Special mount via "dracut_args"
+Kdump uses dracut to generate initramfs for second kernel. This option +allows a user to pass arguments to dracut directly.
+Users can utilize "dracut_args" to pass "--mount" to kdump, please refer +to "man dracut" for the format of "--mount" argument. If there is any +"--mount" specified via "dracut_args", kdump always uses it as the final +mount target without any validation(mounting or checking like mount options, +fs size, save path, etc), so users are expected to ensure all the correctness. +It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs".
+This is useful when we want to deploy thoundsands of diskless clients using +nfs dumping and share the same nfs server. In this scenario, each time the +clients are booting up, the kdump initramfs rebuild will be triggered due to +the diskless environment, so all the clients will request nfs mount simultaneouly, +thereby imposing very much burdon on the shared nfs server. With the help of
^^^^^^^^^Probably "too much" would have been better wording..
Indeed, thanks!
Regards, Xunlei
+special mount via "dracut_args", kdump can skip mounting and resolve the issue. +Because nfs needn't to be mounted beforehand, some nfs-related ko modules will +be explicitly specified as needed together in the "dracut_args"(or via directive +"extra_modules" in /etc/kdump.conf). As an nfs mount example: +dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
+NOTE: +-Only one mount target is allowed using "dracut_args" globally. +-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
- <mountpoint> must be specified in an absolute path.
+-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". +-Users should do a test first and ensure it works, because kdump does
- not prepare the mount and check all the validity.
Remote system via ssh/scp
Dumping over ssh/scp requires setting up passwordless ssh keys for every
Other than that
Reviewed-by: Pratyush Anand panand@redhat.com
Hi, Xunlei
On 05/26/16 at 09:08pm, Xunlei Pang wrote:
Update "kexec-kdump-howto" to illustrate the usage of special mount information via "dracut_args".
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
kexec-kdump-howto.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index b4cdc22..f7c6811 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -345,6 +345,37 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
+Special mount via "dracut_args"
+Kdump uses dracut to generate initramfs for second kernel. This option +allows a user to pass arguments to dracut directly.
+Users can utilize "dracut_args" to pass "--mount" to kdump, please refer +to "man dracut" for the format of "--mount" argument. If there is any +"--mount" specified via "dracut_args", kdump always uses it as the final +mount target without any validation(mounting or checking like mount options, +fs size, save path, etc), so users are expected to ensure all the correctness. +It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs".
What is the behavior for ssh dump in /etc/kdump.conf being used?
+This is useful when we want to deploy thoundsands of diskless clients using +nfs dumping and share the same nfs server. In this scenario, each time the +clients are booting up, the kdump initramfs rebuild will be triggered due to +the diskless environment, so all the clients will request nfs mount simultaneouly, +thereby imposing very much burdon on the shared nfs server. With the help of +special mount via "dracut_args", kdump can skip mounting and resolve the issue. +Because nfs needn't to be mounted beforehand, some nfs-related ko modules will +be explicitly specified as needed together in the "dracut_args"(or via directive +"extra_modules" in /etc/kdump.conf). As an nfs mount example: +dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
For the stateless system use case, it is possible to avoid rebuilding during every boot. Ie. use a workable initrd with timestamp earlier then /etc/kdump.conf when admin create the rootfs etc. It is just a guess but there might be ways to do it. It seems not proper being used in the documentaion.
How about just say that one use case is for nfs dump some admin may not want nfs server being mounted first.
+NOTE: +-Only one mount target is allowed using "dracut_args" globally. +-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
- <mountpoint> must be specified in an absolute path.
+-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". +-Users should do a test first and ensure it works, because kdump does
- not prepare the mount and check all the validity.
Remote system via ssh/scp
Dumping over ssh/scp requires setting up passwordless ssh keys for every
1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
On 2016/05/27 at 14:00, Dave Young wrote:
Hi, Xunlei
On 05/26/16 at 09:08pm, Xunlei Pang wrote:
Update "kexec-kdump-howto" to illustrate the usage of special mount information via "dracut_args".
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
kexec-kdump-howto.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index b4cdc22..f7c6811 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -345,6 +345,37 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
+Special mount via "dracut_args"
+Kdump uses dracut to generate initramfs for second kernel. This option +allows a user to pass arguments to dracut directly.
+Users can utilize "dracut_args" to pass "--mount" to kdump, please refer +to "man dracut" for the format of "--mount" argument. If there is any +"--mount" specified via "dracut_args", kdump always uses it as the final +mount target without any validation(mounting or checking like mount options, +fs size, save path, etc), so users are expected to ensure all the correctness. +It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs".
What is the behavior for ssh dump in /etc/kdump.conf being used?
It will fail as well due to "More than one dump targets specified." Missed ssh, I will add "ssh" here. Thanks for the catching.
+This is useful when we want to deploy thoundsands of diskless clients using +nfs dumping and share the same nfs server. In this scenario, each time the +clients are booting up, the kdump initramfs rebuild will be triggered due to +the diskless environment, so all the clients will request nfs mount simultaneouly, +thereby imposing very much burdon on the shared nfs server. With the help of +special mount via "dracut_args", kdump can skip mounting and resolve the issue. +Because nfs needn't to be mounted beforehand, some nfs-related ko modules will +be explicitly specified as needed together in the "dracut_args"(or via directive +"extra_modules" in /etc/kdump.conf). As an nfs mount example: +dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
For the stateless system use case, it is possible to avoid rebuilding during every boot. Ie. use a workable initrd with timestamp earlier then /etc/kdump.conf when admin create the rootfs etc. It is just a guess but there might be ways to do it. It seems not proper being used in the documentaion.
How about just say that one use case is for nfs dump some admin may not want nfs server being mounted first.
Sure
Regards, Xunlei
+NOTE: +-Only one mount target is allowed using "dracut_args" globally. +-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
- <mountpoint> must be specified in an absolute path.
+-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". +-Users should do a test first and ensure it works, because kdump does
- not prepare the mount and check all the validity.
Remote system via ssh/scp
Dumping over ssh/scp requires setting up passwordless ssh keys for every
1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
On 2016/05/27 at 14:39, Xunlei Pang wrote:
On 2016/05/27 at 14:00, Dave Young wrote:
Hi, Xunlei
On 05/26/16 at 09:08pm, Xunlei Pang wrote:
Update "kexec-kdump-howto" to illustrate the usage of special mount information via "dracut_args".
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
kexec-kdump-howto.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index b4cdc22..f7c6811 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -345,6 +345,37 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
+Special mount via "dracut_args"
+Kdump uses dracut to generate initramfs for second kernel. This option +allows a user to pass arguments to dracut directly.
+Users can utilize "dracut_args" to pass "--mount" to kdump, please refer +to "man dracut" for the format of "--mount" argument. If there is any +"--mount" specified via "dracut_args", kdump always uses it as the final +mount target without any validation(mounting or checking like mount options, +fs size, save path, etc), so users are expected to ensure all the correctness. +It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs".
What is the behavior for ssh dump in /etc/kdump.conf being used?
It will fail as well due to "More than one dump targets specified." Missed ssh, I will add "ssh" here. Thanks for the catching.
+This is useful when we want to deploy thoundsands of diskless clients using +nfs dumping and share the same nfs server. In this scenario, each time the +clients are booting up, the kdump initramfs rebuild will be triggered due to +the diskless environment, so all the clients will request nfs mount simultaneouly, +thereby imposing very much burdon on the shared nfs server. With the help of +special mount via "dracut_args", kdump can skip mounting and resolve the issue. +Because nfs needn't to be mounted beforehand, some nfs-related ko modules will +be explicitly specified as needed together in the "dracut_args"(or via directive +"extra_modules" in /etc/kdump.conf). As an nfs mount example: +dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
For the stateless system use case, it is possible to avoid rebuilding during every boot. Ie. use a workable initrd with timestamp earlier then /etc/kdump.conf when admin create the rootfs etc. It is just a guess but there might be ways to do it. It seems not proper being used in the documentaion.
How about just say that one use case is for nfs dump some admin may not want nfs server being mounted first.
Sure
How about the modified description below:
Special mount via "dracut_args"
Kdump uses dracut to generate initramfs for second kernel. This option allows a user to pass arguments to dracut directly.
Users can utilize "dracut_args" to pass "--mount" to kdump, please refer to "man dracut" for the format of "--mount" argument. If there is any "--mount" specified via "dracut_args", kdump always uses it as the final mount target without any validation(mounting or checking like mount options, fs size, save path, etc), so users are expected to ensure all the correctness. It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs/ssh".
This is useful when administrators don't want the dump target being mounted first. Since the dump target needn't to be mounted beforehand, some fs-related ko modules will be explicitly specified as needed together in the "dracut_args" (or via directive "extra_modules" in /etc/kdump.conf). As an nfs mount example: dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
NOTE: -Only one mount target is allowed using "dracut_args" globally. -Dracut will create <mountpoint> if it doesn't exist in kdump kernel, <mountpoint> must be specified in an absolute path. -There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". -Users should do a test first and ensure it works, because kdump does not prepare the mount and check all the validity.
Regards, Xunlei
+NOTE: +-Only one mount target is allowed using "dracut_args" globally. +-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
- <mountpoint> must be specified in an absolute path.
+-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". +-Users should do a test first and ensure it works, because kdump does
- not prepare the mount and check all the validity.
Remote system via ssh/scp
Dumping over ssh/scp requires setting up passwordless ssh keys for every
1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
On 05/27/16 at 05:39pm, Xunlei Pang wrote:
On 2016/05/27 at 14:39, Xunlei Pang wrote:
On 2016/05/27 at 14:00, Dave Young wrote:
Hi, Xunlei
On 05/26/16 at 09:08pm, Xunlei Pang wrote:
Update "kexec-kdump-howto" to illustrate the usage of special mount information via "dracut_args".
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
kexec-kdump-howto.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index b4cdc22..f7c6811 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -345,6 +345,37 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
+Special mount via "dracut_args"
+Kdump uses dracut to generate initramfs for second kernel. This option +allows a user to pass arguments to dracut directly.
+Users can utilize "dracut_args" to pass "--mount" to kdump, please refer +to "man dracut" for the format of "--mount" argument. If there is any +"--mount" specified via "dracut_args", kdump always uses it as the final +mount target without any validation(mounting or checking like mount options, +fs size, save path, etc), so users are expected to ensure all the correctness. +It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs".
What is the behavior for ssh dump in /etc/kdump.conf being used?
It will fail as well due to "More than one dump targets specified." Missed ssh, I will add "ssh" here. Thanks for the catching.
+This is useful when we want to deploy thoundsands of diskless clients using +nfs dumping and share the same nfs server. In this scenario, each time the +clients are booting up, the kdump initramfs rebuild will be triggered due to +the diskless environment, so all the clients will request nfs mount simultaneouly, +thereby imposing very much burdon on the shared nfs server. With the help of +special mount via "dracut_args", kdump can skip mounting and resolve the issue. +Because nfs needn't to be mounted beforehand, some nfs-related ko modules will +be explicitly specified as needed together in the "dracut_args"(or via directive +"extra_modules" in /etc/kdump.conf). As an nfs mount example: +dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
For the stateless system use case, it is possible to avoid rebuilding during every boot. Ie. use a workable initrd with timestamp earlier then /etc/kdump.conf when admin create the rootfs etc. It is just a guess but there might be ways to do it. It seems not proper being used in the documentaion.
How about just say that one use case is for nfs dump some admin may not want nfs server being mounted first.
Sure
How about the modified description below:
Special mount via "dracut_args"
Kdump uses dracut to generate initramfs for second kernel. This option allows a user to pass arguments to dracut directly.
Above paragraph is not necessary because it has been documented in both kdump.conf comments and manpage.
Users can utilize "dracut_args" to pass "--mount" to kdump, please refer to "man dracut" for the format of "--mount" argument. If there is any "--mount" specified via "dracut_args", kdump always uses it as the final mount target without any validation(mounting or checking like mount options, fs size, save path, etc), so users are expected to ensure all the correctness. It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs/ssh".
This is useful when administrators don't want the dump target being mounted first. Since the dump target needn't to be mounted beforehand, some fs-related ko modules will be explicitly specified as needed together in the "dracut_args" (or via directive "extra_modules" in /etc/kdump.conf). As an nfs mount example: dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
NOTE: -Only one mount target is allowed using "dracut_args" globally. -Dracut will create <mountpoint> if it doesn't exist in kdump kernel, <mountpoint> must be specified in an absolute path. -There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". -Users should do a test first and ensure it works, because kdump does not prepare the mount and check all the validity.
Regards, Xunlei
+NOTE: +-Only one mount target is allowed using "dracut_args" globally. +-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
- <mountpoint> must be specified in an absolute path.
+-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". +-Users should do a test first and ensure it works, because kdump does
- not prepare the mount and check all the validity.
Remote system via ssh/scp
Dumping over ssh/scp requires setting up passwordless ssh keys for every
1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
But I have a concern, if the network can be setup correctly. Kdump still will find the right nic and set it up?
On 05/27/16 at 05:39pm, Xunlei Pang wrote:
On 2016/05/27 at 14:39, Xunlei Pang wrote:
On 2016/05/27 at 14:00, Dave Young wrote:
Hi, Xunlei
On 05/26/16 at 09:08pm, Xunlei Pang wrote:
Update "kexec-kdump-howto" to illustrate the usage of special mount information via "dracut_args".
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
kexec-kdump-howto.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index b4cdc22..f7c6811 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -345,6 +345,37 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
+Special mount via "dracut_args"
+Kdump uses dracut to generate initramfs for second kernel. This option +allows a user to pass arguments to dracut directly.
+Users can utilize "dracut_args" to pass "--mount" to kdump, please refer +to "man dracut" for the format of "--mount" argument. If there is any +"--mount" specified via "dracut_args", kdump always uses it as the final +mount target without any validation(mounting or checking like mount options, +fs size, save path, etc), so users are expected to ensure all the correctness. +It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs".
What is the behavior for ssh dump in /etc/kdump.conf being used?
It will fail as well due to "More than one dump targets specified." Missed ssh, I will add "ssh" here. Thanks for the catching.
+This is useful when we want to deploy thoundsands of diskless clients using +nfs dumping and share the same nfs server. In this scenario, each time the +clients are booting up, the kdump initramfs rebuild will be triggered due to +the diskless environment, so all the clients will request nfs mount simultaneouly, +thereby imposing very much burdon on the shared nfs server. With the help of +special mount via "dracut_args", kdump can skip mounting and resolve the issue. +Because nfs needn't to be mounted beforehand, some nfs-related ko modules will +be explicitly specified as needed together in the "dracut_args"(or via directive +"extra_modules" in /etc/kdump.conf). As an nfs mount example: +dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
For the stateless system use case, it is possible to avoid rebuilding during every boot. Ie. use a workable initrd with timestamp earlier then /etc/kdump.conf when admin create the rootfs etc. It is just a guess but there might be ways to do it. It seems not proper being used in the documentaion.
How about just say that one use case is for nfs dump some admin may not want nfs server being mounted first.
Sure
How about the modified description below:
Special mount via "dracut_args"
Kdump uses dracut to generate initramfs for second kernel. This option allows a user to pass arguments to dracut directly.
Above paragraph is not necessary because it has been documented in both kdump.conf comments and manpage.
Users can utilize "dracut_args" to pass "--mount" to kdump, please refer
s/Users/One, or s/Users/You But we need keep consistently use either one or you in the following paragraph.
to "man dracut" for the format of "--mount" argument. If there is any
Dropping needless politeness: s/please refer to "man dracut" for the format of "--mount" argument/see the dracut manpage about "--mount" for details.
I found a guideline of documentation, though it is for openstack, but some general rules also fit for other documentations: http://docs.openstack.org/contributor-guide/writing-style/general-writing-gu...
"--mount" specified via "dracut_args", kdump always uses it as the final mount target without any validation(mounting or checking like mount options, fs size, save path, etc), so users are expected to ensure all the correctness. It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs/ssh".
Kdump uses "--mount" provided in dracut_args without sanity checking so you must test it and ensure the correctness. You can not use other targets in /etc/kdump.conf if you use "--mount" in dracut_args.
This is useful when administrators don't want the dump target being mounted first. Since the dump target needn't to be mounted beforehand, some fs-related ko modules will be explicitly specified as needed together in the "dracut_args" (or via directive "extra_modules" in /etc/kdump.conf). As an nfs mount example: dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
This paragraph should be put before the usage paragraph so that it is more natrual. How about simplify it as below:
A use case of "--mount" in dracut_args is you do not want to mount dump target before kdump service startup, for example, to reduce the burden of nfs server. Such as below example: dracut_args --mount "192.168.1.1:/test /test nfs defaults"
NOTE: -Only one mount target is allowed using "dracut_args" globally.
Already mentioned above, either drop above clarification or drop this item here.
-Dracut will create <mountpoint> if it doesn't exist in kdump kernel, <mountpoint> must be specified in an absolute path.
We do not need explain the internal details, just mention about it must be an absolute path.
-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". -Users should do a test first and ensure it works, because kdump does not prepare the mount and check all the validity.
Also duplicated with previous sentences above.
Regards, Xunlei
+NOTE: +-Only one mount target is allowed using "dracut_args" globally. +-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
- <mountpoint> must be specified in an absolute path.
+-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". +-Users should do a test first and ensure it works, because kdump does
- not prepare the mount and check all the validity.
Remote system via ssh/scp
Dumping over ssh/scp requires setting up passwordless ssh keys for every
1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
On 2016/06/02 at 15:46, Dave Young wrote:
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
But I have a concern, if the network can be setup correctly. Kdump still will find the right nic and set it up?
The implementation patch added: + dracut_args) + if is_nfs_in_dracut_args "$config_val"; then + kdump_install_net "$(get_dracut_args_target "$config_val")" + fi + ;;
So the net device when specifying nfs can be installed correctly.
On 05/27/16 at 05:39pm, Xunlei Pang wrote:
On 2016/05/27 at 14:39, Xunlei Pang wrote:
On 2016/05/27 at 14:00, Dave Young wrote:
Hi, Xunlei
On 05/26/16 at 09:08pm, Xunlei Pang wrote:
Update "kexec-kdump-howto" to illustrate the usage of special mount information via "dracut_args".
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
kexec-kdump-howto.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index b4cdc22..f7c6811 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -345,6 +345,37 @@ mount the NFS mount and copy out the vmcore to your NFS server. Restart the kdump service via '/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
+Special mount via "dracut_args"
+Kdump uses dracut to generate initramfs for second kernel. This option +allows a user to pass arguments to dracut directly.
+Users can utilize "dracut_args" to pass "--mount" to kdump, please refer +to "man dracut" for the format of "--mount" argument. If there is any +"--mount" specified via "dracut_args", kdump always uses it as the final +mount target without any validation(mounting or checking like mount options, +fs size, save path, etc), so users are expected to ensure all the correctness. +It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs".
What is the behavior for ssh dump in /etc/kdump.conf being used?
It will fail as well due to "More than one dump targets specified." Missed ssh, I will add "ssh" here. Thanks for the catching.
+This is useful when we want to deploy thoundsands of diskless clients using +nfs dumping and share the same nfs server. In this scenario, each time the +clients are booting up, the kdump initramfs rebuild will be triggered due to +the diskless environment, so all the clients will request nfs mount simultaneouly, +thereby imposing very much burdon on the shared nfs server. With the help of +special mount via "dracut_args", kdump can skip mounting and resolve the issue. +Because nfs needn't to be mounted beforehand, some nfs-related ko modules will +be explicitly specified as needed together in the "dracut_args"(or via directive +"extra_modules" in /etc/kdump.conf). As an nfs mount example: +dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
For the stateless system use case, it is possible to avoid rebuilding during every boot. Ie. use a workable initrd with timestamp earlier then /etc/kdump.conf when admin create the rootfs etc. It is just a guess but there might be ways to do it. It seems not proper being used in the documentaion.
How about just say that one use case is for nfs dump some admin may not want nfs server being mounted first.
Sure
How about the modified description below:
Special mount via "dracut_args"
Kdump uses dracut to generate initramfs for second kernel. This option allows a user to pass arguments to dracut directly.
Above paragraph is not necessary because it has been documented in both kdump.conf comments and manpage.
Users can utilize "dracut_args" to pass "--mount" to kdump, please refer
s/Users/One, or s/Users/You But we need keep consistently use either one or you in the following paragraph.
to "man dracut" for the format of "--mount" argument. If there is any
Dropping needless politeness: s/please refer to "man dracut" for the format of "--mount" argument/see the dracut manpage about "--mount" for details.
I found a guideline of documentation, though it is for openstack, but some general rules also fit for other documentations: http://docs.openstack.org/contributor-guide/writing-style/general-writing-gu...
This is really cool, I will have a look and modify the doc according to you valuable comments.
Regards, Xunlei
"--mount" specified via "dracut_args", kdump always uses it as the final mount target without any validation(mounting or checking like mount options, fs size, save path, etc), so users are expected to ensure all the correctness. It conflicts with targets specified via "ext[234]/xfs/btrfs/nfs/ssh".
Kdump uses "--mount" provided in dracut_args without sanity checking so you must test it and ensure the correctness. You can not use other targets in /etc/kdump.conf if you use "--mount" in dracut_args.
This is useful when administrators don't want the dump target being mounted first. Since the dump target needn't to be mounted beforehand, some fs-related ko modules will be explicitly specified as needed together in the "dracut_args" (or via directive "extra_modules" in /etc/kdump.conf). As an nfs mount example: dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
This paragraph should be put before the usage paragraph so that it is more natrual. How about simplify it as below:
A use case of "--mount" in dracut_args is you do not want to mount dump target before kdump service startup, for example, to reduce the burden of nfs server. Such as below example: dracut_args --mount "192.168.1.1:/test /test nfs defaults"
NOTE: -Only one mount target is allowed using "dracut_args" globally.
Already mentioned above, either drop above clarification or drop this item here.
-Dracut will create <mountpoint> if it doesn't exist in kdump kernel, <mountpoint> must be specified in an absolute path.
We do not need explain the internal details, just mention about it must be an absolute path.
-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". -Users should do a test first and ensure it works, because kdump does not prepare the mount and check all the validity.
Also duplicated with previous sentences above.
Regards, Xunlei
+NOTE: +-Only one mount target is allowed using "dracut_args" globally. +-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
- <mountpoint> must be specified in an absolute path.
+-There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". +-Users should do a test first and ensure it works, because kdump does
- not prepare the mount and check all the validity.
Remote system via ssh/scp
Dumping over ssh/scp requires setting up passwordless ssh keys for every
1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote:
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
But I have a concern, if the network can be setup correctly. Kdump still will find the right nic and set it up?
The implementation patch added:
dracut_args)if is_nfs_in_dracut_args "$config_val"; thenkdump_install_net "$(get_dracut_args_target "$config_val")"fi;;So the net device when specifying nfs can be installed correctly.
Ok, cool then it should be ok.
BTW, for patch 1 I have not got time to think about it, maybe I will reply tomorrow.
Thanks Dave
Hi, Xunlei
On 05/26/16 at 09:08pm, Xunlei Pang wrote:
There are some complaints about nfs kdump that users must mount nfs beforehand, which may cause some overhead to nfs server. For example, there're thounsands of diskless clients deployed with nfs dumping, each time the client is boot up, it will trigger kdump rebuilding so will mount nfs, thus resulting in thousands of nfs request concurrently imposed on the same nfs server.
We introduce a new way of specifying mount information via the already-existent "dracut_args" directive(so avoid adding extra directives in /etc/kdump.conf), we will skip all the filesystem mounting and checking stuff for it. So it can be used in the above-mentioned nfs scenario to avoid severe nfs server overhead.
Specifically, if there is any "--mount" information specified via "dracut_args" in /etc/kdump.conf, always use it as the final mount without any validation(mounting or checking like mount options, fs size, etc), so users are expected to ensure its correctness.
When doing nfs mount via "dracut_args", because nfs needn't to be mounted beforehand, some nfs-related ko modules must be explicitly specified as needed together in the "dracut_args"(or via directive "extra_modules" in /etc/kdump.conf). As an nfs example: dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
NOTE: -Only one mount target is allowed using "dracut_args" globally. -Dracut will create <mountpoint> if it doesn't exist in kdump kernel, <mountpoint> must be specified in an absolute path. -There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". -Users should do a test first and ensure it works because kdump does not prepare the mount and check all the validity.
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
dracut-kdump.sh | 6 +++++- dracut-module-setup.sh | 5 +++++ kdump-lib.sh | 41 ++++++++++++++++++++++++++++++++++++++++- kdumpctl | 13 ++++++++++++- mkdumprd | 3 +++ 5 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index 4aab205..8747dba 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -117,7 +117,7 @@ save_vmcore_dmesg_ssh() { get_host_ip() { local _host
- if is_nfs_dump_target || is_ssh_dump_target
- if is_nfs_dump_target || is_ssh_dump_target || does_dracut_args_contain_nfsmount
I may miss previous discussion, but "does_dracut_args_contain_nfsmount" looks too long and does+contains uses 12 characters. How about drop it and move the logic to is_nfs_dump_target()
BTW, what is the difference between is_nfs_in_dracut_args and does_dracut_args_contain_nfsmount Can it be like below?
get_dracut_args() { echo dracut_args config value in kdump.conf if have any }
is_nfs_dump_targte() { ...
dargs=get_dracut_args() return is_nfs_in_dracut_args $dargs
... }
then kdumpnic=$(getarg kdumpnic=) [ -z "$kdumpnic" ] && echo "kdump: failed to get kdumpnic!" && return 1@@ -146,6 +146,10 @@ read_kdump_conf() # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) case "$config_opt" in
dracut_args)config_val=$(get_dracut_args_target "$config_val")[[ -n "$config_val" ]] && add_dump_code "dump_fs $config_val";; ext[234]|xfs|btrfs|minix|nfs) add_dump_code "dump_fs $config_val" ;;diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 4cd7107..5f03558 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -433,6 +433,11 @@ kdump_install_conf() { ssh|nfs) kdump_install_net "$config_val" ;;
dracut_args)if is_nfs_in_dracut_args "$config_val"; thenkdump_install_net "$(get_dracut_args_target "$config_val")"fi;; kdump_pre|kdump_post|extra_bins) dracut_install $config_val ;;diff --git a/kdump-lib.sh b/kdump-lib.sh index fc2c036..a486db6 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -45,7 +45,8 @@ is_fs_dump_target()
is_user_configured_dump_target() {
- return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target)
- return $(does_dracut_args_contain_mount || is_ssh_dump_target || is_nfs_dump_target || \
is_raw_dump_target || is_fs_dump_target)}
strip_comments() @@ -279,3 +280,41 @@ is_hostname() fi echo $1 | grep -q "[a-zA-Z]" }
+# If "dracut_args" contains "--mount" information, use it +# directly without any check(users are expected to ensure +# its correctness). +does_dracut_args_contain_mount()
How about using a simpler name is_dracut_args_target? is_darcut_args_target() { local ... dargs=get_dracut_args() target=get_dracut_args_target $dargs if [ -n $target ] then return true else return false }
+{
- return $(grep ^dracut_args /etc/kdump.conf | grep -q "--mount")
+}
+does_dracut_args_contain_nfsmount() +{
- local fstype
- fstype=$(grep "^dracut_args .*--mount" /etc/kdump.conf | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f3)
- [[ $fstype = nfs* ]] && return 0
- return 1
+}
+# $1: configuration value of "dracut_args". +is_nfs_in_dracut_args() +{
- [[ $(get_dracut_args_fstype "$1") = nfs* ]] && return 0
- return 1
+}
+# $1: configuration value of "dracut_args". +get_dracut_args_fstype() +{
- echo $1 | grep "--mount" | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f3
+}
+# $1: configuration value of "dracut_args". +get_dracut_args_target() +{
- echo $1 | grep "--mount" | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f1
+} diff --git a/kdumpctl b/kdumpctl index fcc9ad0..fbed66d 100755 --- a/kdumpctl +++ b/kdumpctl @@ -236,12 +236,18 @@ check_config() { local nr
- nr=$(awk 'BEGIN{cnt=0} /^raw|^ssh[[:blank:]]|^nfs|^ext[234]|^xfs|^btrfs|^minix/{cnt++} END{print cnt}' $KDUMP_CONFIG_FILE)
nr=$(awk 'BEGIN{cnt=0} /^raw|^ssh[[:blank:]]|^nfs|^ext[234]|^xfs|^btrfs|^minix|^dracut_args .*--mount/{cnt++} END{print cnt}' $KDUMP_CONFIG_FILE) [ $nr -gt 1 ] && { echo "More than one dump targets specified." return 1 }
nr=$(grep "^dracut_args .*--mount" $KDUMP_CONFIG_FILE | grep -o "--mount" | wc -l)
[ $nr -gt 1 ] && {
echo "More than one mount targets specified in \"dracut_args\"."return 1}
while read config_opt config_val; do # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val)
@@ -365,6 +371,11 @@ check_dump_fs_modified() local _new_dev _new_mntpoint _new_fstype local _target _path _dracut_args
- # No need to check in case of mount target specified via "dracut_args".
- if does_dracut_args_contain_mount; then
return 0- fi
- # No need to check in case of raw target. # Currently we do not check also if ssh/nfs target is specified if is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target; then
diff --git a/mkdumprd b/mkdumprd index 78afb1a..7a0e733 100644 --- a/mkdumprd +++ b/mkdumprd @@ -544,6 +544,9 @@ do verify_core_collector "$config_val" ;; dracut_args)
if is_nfs_in_dracut_args "$config_val"; thenadd_dracut_module "nfs"fi add_dracut_arg $config_val ;;-- 1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote:
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
Regards, Xunlei
But I have a concern, if the network can be setup correctly. Kdump still will find the right nic and set it up?
The implementation patch added:
dracut_args)if is_nfs_in_dracut_args "$config_val"; thenkdump_install_net "$(get_dracut_args_target "$config_val")"fi;;So the net device when specifying nfs can be installed correctly.
Ok, cool then it should be ok.
BTW, for patch 1 I have not got time to think about it, maybe I will reply tomorrow.
Thanks Dave
On 2016/06/06 at 09:01, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote:
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
I did some tests, seems dracut will parse "--mount" to add filesystem-related ko modules.
For nfs, 1) if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfs defaults", then "nfs.ko" will be added to initramfs only. 2) if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfsv4 defaults", then both "nfs.ko" and "nfsv4.ko" will be added.
Regards, Xunlei
Regards, Xunlei
But I have a concern, if the network can be setup correctly. Kdump still will find the right nic and set it up?
The implementation patch added:
dracut_args)if is_nfs_in_dracut_args "$config_val"; thenkdump_install_net "$(get_dracut_args_target "$config_val")"fi;;So the net device when specifying nfs can be installed correctly.
Ok, cool then it should be ok.
BTW, for patch 1 I have not got time to think about it, maybe I will reply tomorrow.
Thanks Dave
On 06/06/16 at 09:01am, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote:
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
Does --force-add works?
Thanks Dave
On 2016/06/03 at 10:06, Dave Young wrote:
Hi, Xunlei
On 05/26/16 at 09:08pm, Xunlei Pang wrote:
There are some complaints about nfs kdump that users must mount nfs beforehand, which may cause some overhead to nfs server. For example, there're thounsands of diskless clients deployed with nfs dumping, each time the client is boot up, it will trigger kdump rebuilding so will mount nfs, thus resulting in thousands of nfs request concurrently imposed on the same nfs server.
We introduce a new way of specifying mount information via the already-existent "dracut_args" directive(so avoid adding extra directives in /etc/kdump.conf), we will skip all the filesystem mounting and checking stuff for it. So it can be used in the above-mentioned nfs scenario to avoid severe nfs server overhead.
Specifically, if there is any "--mount" information specified via "dracut_args" in /etc/kdump.conf, always use it as the final mount without any validation(mounting or checking like mount options, fs size, etc), so users are expected to ensure its correctness.
When doing nfs mount via "dracut_args", because nfs needn't to be mounted beforehand, some nfs-related ko modules must be explicitly specified as needed together in the "dracut_args"(or via directive "extra_modules" in /etc/kdump.conf). As an nfs example: dracut_args --mount "192.168.1.1:/test /test nfs defaults" --add-driver "nfs nfsv4"
NOTE: -Only one mount target is allowed using "dracut_args" globally. -Dracut will create <mountpoint> if it doesn't exist in kdump kernel, <mountpoint> must be specified in an absolute path. -There must be double quotation marks behind "--mount", i.e. --mount "<mount info>". -Users should do a test first and ensure it works because kdump does not prepare the mount and check all the validity.
Suggested-by: Dave Young dyoung@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com
dracut-kdump.sh | 6 +++++- dracut-module-setup.sh | 5 +++++ kdump-lib.sh | 41 ++++++++++++++++++++++++++++++++++++++++- kdumpctl | 13 ++++++++++++- mkdumprd | 3 +++ 5 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index 4aab205..8747dba 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -117,7 +117,7 @@ save_vmcore_dmesg_ssh() { get_host_ip() { local _host
- if is_nfs_dump_target || is_ssh_dump_target
- if is_nfs_dump_target || is_ssh_dump_target || does_dracut_args_contain_nfsmount
I may miss previous discussion, but "does_dracut_args_contain_nfsmount" looks too long and does+contains uses 12 characters. How about drop it and move the logic to is_nfs_dump_target()
BTW, what is the difference between is_nfs_in_dracut_args and does_dracut_args_contain_nfsmount Can it be like below?
The difference is is_nfs_in_dracut_args has an argument, while the other doesn't have.
get_dracut_args() { echo dracut_args config value in kdump.conf if have any }
We still need to identify the proper dracut_args, as there might be multiple dracut_args (though only one of them is allowed to be with a target specified).
is_nfs_dump_targte() { ...
dargs=get_dracut_args() return is_nfs_in_dracut_args $dargs... }
then kdumpnic=$(getarg kdumpnic=) [ -z "$kdumpnic" ] && echo "kdump: failed to get kdumpnic!" && return 1@@ -146,6 +146,10 @@ read_kdump_conf() # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) case "$config_opt" in
dracut_args)config_val=$(get_dracut_args_target "$config_val")[[ -n "$config_val" ]] && add_dump_code "dump_fs $config_val";; ext[234]|xfs|btrfs|minix|nfs) add_dump_code "dump_fs $config_val" ;;diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 4cd7107..5f03558 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -433,6 +433,11 @@ kdump_install_conf() { ssh|nfs) kdump_install_net "$config_val" ;;
dracut_args)if is_nfs_in_dracut_args "$config_val"; thenkdump_install_net "$(get_dracut_args_target "$config_val")"fi;; kdump_pre|kdump_post|extra_bins) dracut_install $config_val ;;diff --git a/kdump-lib.sh b/kdump-lib.sh index fc2c036..a486db6 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -45,7 +45,8 @@ is_fs_dump_target()
is_user_configured_dump_target() {
- return $(is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target || is_fs_dump_target)
- return $(does_dracut_args_contain_mount || is_ssh_dump_target || is_nfs_dump_target || \
is_raw_dump_target || is_fs_dump_target)}
strip_comments() @@ -279,3 +280,41 @@ is_hostname() fi echo $1 | grep -q "[a-zA-Z]" }
+# If "dracut_args" contains "--mount" information, use it +# directly without any check(users are expected to ensure +# its correctness). +does_dracut_args_contain_mount()
How about using a simpler name is_dracut_args_target? is_darcut_args_target() { local ... dargs=get_dracut_args() target=get_dracut_args_target $dargs if [ -n $target ] then return true else return false }
I'm fine with the naming of "is_dracut_args_target", but for the approach, we still need the logic to be implemented in get_dracut_args() as I explained above.
Regards, Xunlei
+{
- return $(grep ^dracut_args /etc/kdump.conf | grep -q "--mount")
+}
+does_dracut_args_contain_nfsmount() +{
- local fstype
- fstype=$(grep "^dracut_args .*--mount" /etc/kdump.conf | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f3)
- [[ $fstype = nfs* ]] && return 0
- return 1
+}
+# $1: configuration value of "dracut_args". +is_nfs_in_dracut_args() +{
- [[ $(get_dracut_args_fstype "$1") = nfs* ]] && return 0
- return 1
+}
+# $1: configuration value of "dracut_args". +get_dracut_args_fstype() +{
- echo $1 | grep "--mount" | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f3
+}
+# $1: configuration value of "dracut_args". +get_dracut_args_target() +{
- echo $1 | grep "--mount" | sed "s/.*--mount "(.*)/\1/" | cut -d' ' -f1
+} diff --git a/kdumpctl b/kdumpctl index fcc9ad0..fbed66d 100755 --- a/kdumpctl +++ b/kdumpctl @@ -236,12 +236,18 @@ check_config() { local nr
- nr=$(awk 'BEGIN{cnt=0} /^raw|^ssh[[:blank:]]|^nfs|^ext[234]|^xfs|^btrfs|^minix/{cnt++} END{print cnt}' $KDUMP_CONFIG_FILE)
nr=$(awk 'BEGIN{cnt=0} /^raw|^ssh[[:blank:]]|^nfs|^ext[234]|^xfs|^btrfs|^minix|^dracut_args .*--mount/{cnt++} END{print cnt}' $KDUMP_CONFIG_FILE) [ $nr -gt 1 ] && { echo "More than one dump targets specified." return 1 }
nr=$(grep "^dracut_args .*--mount" $KDUMP_CONFIG_FILE | grep -o "--mount" | wc -l)
[ $nr -gt 1 ] && {
echo "More than one mount targets specified in \"dracut_args\"."return 1}
while read config_opt config_val; do # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val)
@@ -365,6 +371,11 @@ check_dump_fs_modified() local _new_dev _new_mntpoint _new_fstype local _target _path _dracut_args
- # No need to check in case of mount target specified via "dracut_args".
- if does_dracut_args_contain_mount; then
return 0- fi
- # No need to check in case of raw target. # Currently we do not check also if ssh/nfs target is specified if is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target; then
diff --git a/mkdumprd b/mkdumprd index 78afb1a..7a0e733 100644 --- a/mkdumprd +++ b/mkdumprd @@ -544,6 +544,9 @@ do verify_core_collector "$config_val" ;; dracut_args)
if is_nfs_in_dracut_args "$config_val"; thenadd_dracut_module "nfs"fi add_dracut_arg $config_val ;;-- 1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
On 2016/06/06 at 09:55, Dave Young wrote:
On 06/06/16 at 09:01am, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote:
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
Does --force-add works?
I doesn't work, the "nfs" dracut module is ok, it's the "instmods" in dracut's "nfs" that doesn't work. But with the other reply to specify the right "nfsv4" filesytem type, it should work for us.
Regards, Xunlei
Thanks Dave
Hi Xunlei,
On 06/06/16 at 10:43am, Xunlei Pang wrote:
On 2016/06/06 at 09:55, Dave Young wrote:
On 06/06/16 at 09:01am, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote:
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
Does --force-add works?
I doesn't work, the "nfs" dracut module is ok, it's the "instmods" in dracut's "nfs" that doesn't work. But with the other reply to specify the right "nfsv4" filesytem type, it should work for us.
If --force-add is meant to bypass hostonly then it should be extended to also work in instmods then we can use force-add for these --mount so that one do not need add extra kernel modules.
Thanks Dave
On 2016/06/06 at 11:12, Dave Young wrote:
Hi Xunlei,
On 06/06/16 at 10:43am, Xunlei Pang wrote:
On 2016/06/06 at 09:55, Dave Young wrote:
On 06/06/16 at 09:01am, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote: > Hi, Xunlei > > Seems I sent wrong draft, here is the right one: > > Add a question about below > --add-driver "nfs nfsv4" > > Why should we add them? if we addes dracut 95nfs module then it will install > all the nfs kernel modules and network module. Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
Does --force-add works?
I doesn't work, the "nfs" dracut module is ok, it's the "instmods" in dracut's "nfs" that doesn't work. But with the other reply to specify the right "nfsv4" filesytem type, it should work for us.
If --force-add is meant to bypass hostonly then it should be extended to also work in instmods then we can use force-add for these --mount so that one do not need add extra kernel modules.
"--force_add" affects check() in module_setup.sh.
For nfs, it is: # called by dracut check() { # If our prerequisites are not met, fail anyways. require_any_binary rpcbind portmap || return 1 require_binaries rpc.statd mount.nfs mount.nfs4 umount || return 1
[[ $hostonly ]] || [[ $mount_needs ]] && { for fs in "${host_fs_types[@]}"; do [[ "$fs" == "nfs" ]] && return 0 [[ "$fs" == "nfs3" ]] && return 0 [[ "$fs" == "nfs4" ]] && return 0 done return 255 } return 0 }
so only affects the dracut modules to be added.
For nfs instmods, dracut handles it in installkernel(), it is: # called by dracut installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
"The --force-add extension to instmods" will involve many dracut's fundamental changes.
Regards, Xunlei
Thanks Dave
On 2016/06/06 at 09:34, Xunlei Pang wrote:
On 2016/06/06 at 09:01, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote:
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
I did some tests, seems dracut will parse "--mount" to add filesystem-related ko modules.
For nfs,
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfs defaults", then "nfs.ko" will be added to initramfs only.
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfsv4 defaults", then both "nfs.ko" and "nfsv4.ko" will be added.
Further investigation shows that this can't work, the reason why nfsv4.ko is added is because in 90kernel-modules/module-setup.sh installkernel(), we have: for i in $(host_fs_all); do hostonly='' instmods $i done
So nfsv4.ko which is got from the fstype is added, but actually the mount will fail due to the invalid "nfsv4" specified in "--mount"(the right one should be "nfs4").
Regards, Xunlei
Regards, Xunlei
Regards, Xunlei
But I have a concern, if the network can be setup correctly. Kdump still will find the right nic and set it up?
The implementation patch added:
dracut_args)if is_nfs_in_dracut_args "$config_val"; thenkdump_install_net "$(get_dracut_args_target "$config_val")"fi;;So the net device when specifying nfs can be installed correctly.
Ok, cool then it should be ok.
BTW, for patch 1 I have not got time to think about it, maybe I will reply tomorrow.
Thanks Dave
Hi, On 06/06/16 at 05:00pm, Xunlei Pang wrote:
On 2016/06/06 at 11:12, Dave Young wrote:
Hi Xunlei,
On 06/06/16 at 10:43am, Xunlei Pang wrote:
On 2016/06/06 at 09:55, Dave Young wrote:
On 06/06/16 at 09:01am, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote: > On 2016/06/02 at 15:46, Dave Young wrote: >> Hi, Xunlei >> >> Seems I sent wrong draft, here is the right one: >> >> Add a question about below >> --add-driver "nfs nfsv4" >> >> Why should we add them? if we addes dracut 95nfs module then it will install >> all the nfs kernel modules and network module. > Yeah, dracut 95nfs module has > installkernel() { > instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files > } > > But actually during my test, I found that if nfs was not mounted, some of the modules > (for example nfsv4)will fail to be installed by instmods. Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
Does --force-add works?
I doesn't work, the "nfs" dracut module is ok, it's the "instmods" in dracut's "nfs" that doesn't work. But with the other reply to specify the right "nfsv4" filesytem type, it should work for us.
If --force-add is meant to bypass hostonly then it should be extended to also work in instmods then we can use force-add for these --mount so that one do not need add extra kernel modules.
"--force_add" affects check() in module_setup.sh.
For nfs, it is: # called by dracut check() { # If our prerequisites are not met, fail anyways. require_any_binary rpcbind portmap || return 1 require_binaries rpc.statd mount.nfs mount.nfs4 umount || return 1
[[ $hostonly ]] || [[ $mount_needs ]] && { for fs in "${host_fs_types[@]}"; do [[ "$fs" == "nfs" ]] && return 0 [[ "$fs" == "nfs3" ]] && return 0 [[ "$fs" == "nfs4" ]] && return 0 done return 255 } return 0}
so only affects the dracut modules to be added.
For nfs instmods, dracut handles it in installkernel(), it is: # called by dracut installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
"The --force-add extension to instmods" will involve many dracut's fundamental changes.
So there are two problems here.
1) --mount parsing and add nfs ko files in another reply 2) --force-add only affects module check
For 1), the original logic about nfs module seems wrong. One can setup nfs4 in config files, but just use mount -t nfs, it will actually use nfs4 kernel module. (Need verification..). If I am right then in case mount_needs for nfs all nfs kernel module should be added.
For 2), extend --force-add to installkernel() is also reasonable, just pass some variables to instmods function may work like some EVN varialbes so it only affects the callback from specific dracut module.
But if 1) works maybe we can leave 2) in todo list and discuss it later when we have to do it.
Thanks Dave
On 06/06/16 at 05:21pm, Xunlei Pang wrote:
On 2016/06/06 at 09:34, Xunlei Pang wrote:
On 2016/06/06 at 09:01, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote:
Hi, Xunlei
Seems I sent wrong draft, here is the right one:
Add a question about below --add-driver "nfs nfsv4"
Why should we add them? if we addes dracut 95nfs module then it will install all the nfs kernel modules and network module.
Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
I did some tests, seems dracut will parse "--mount" to add filesystem-related ko modules.
For nfs,
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfs defaults", then "nfs.ko" will be added to initramfs only.
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfsv4 defaults", then both "nfs.ko" and "nfsv4.ko" will be added.
Further investigation shows that this can't work, the reason why nfsv4.ko is added is because in 90kernel-modules/module-setup.sh installkernel(), we have: for i in $(host_fs_all); do hostonly='' instmods $i done
So nfsv4.ko which is got from the fstype is added, but actually the mount will fail due to the invalid "nfsv4" specified in "--mount"(the right one should be "nfs4").
Seems we are still not clear about the problem, shouldn't it been mapped from nfs4 -> nfsv4.ko automaticlly?
Also mount_needs should add kernel modules without considering hostonly or not, if --mount need instmods should install the ko unconditionally
Regards, Xunlei
Regards, Xunlei
Regards, Xunlei
But I have a concern, if the network can be setup correctly. Kdump still will find the right nic and set it up?
The implementation patch added:
dracut_args)if is_nfs_in_dracut_args "$config_val"; thenkdump_install_net "$(get_dracut_args_target "$config_val")"fi;;So the net device when specifying nfs can be installed correctly.
Ok, cool then it should be ok.
BTW, for patch 1 I have not got time to think about it, maybe I will reply tomorrow.
Thanks Dave
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
On 2016/06/08 at 10:16, Dave Young wrote:
Hi, On 06/06/16 at 05:00pm, Xunlei Pang wrote:
On 2016/06/06 at 11:12, Dave Young wrote:
Hi Xunlei,
On 06/06/16 at 10:43am, Xunlei Pang wrote:
On 2016/06/06 at 09:55, Dave Young wrote:
On 06/06/16 at 09:01am, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote: > On 06/02/16 at 04:21pm, Xunlei Pang wrote: >> On 2016/06/02 at 15:46, Dave Young wrote: >>> Hi, Xunlei >>> >>> Seems I sent wrong draft, here is the right one: >>> >>> Add a question about below >>> --add-driver "nfs nfsv4" >>> >>> Why should we add them? if we addes dracut 95nfs module then it will install >>> all the nfs kernel modules and network module. >> Yeah, dracut 95nfs module has >> installkernel() { >> instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files >> } >> >> But actually during my test, I found that if nfs was not mounted, some of the modules >> (for example nfsv4)will fail to be installed by instmods. > Hmm, it may related to we use hostonly, could you check the instmods function > to see if we can handle it without adding drivers in dracut args? You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
Does --force-add works?
I doesn't work, the "nfs" dracut module is ok, it's the "instmods" in dracut's "nfs" that doesn't work. But with the other reply to specify the right "nfsv4" filesytem type, it should work for us.
If --force-add is meant to bypass hostonly then it should be extended to also work in instmods then we can use force-add for these --mount so that one do not need add extra kernel modules.
"--force_add" affects check() in module_setup.sh.
For nfs, it is: # called by dracut check() { # If our prerequisites are not met, fail anyways. require_any_binary rpcbind portmap || return 1 require_binaries rpc.statd mount.nfs mount.nfs4 umount || return 1
[[ $hostonly ]] || [[ $mount_needs ]] && { for fs in "${host_fs_types[@]}"; do [[ "$fs" == "nfs" ]] && return 0 [[ "$fs" == "nfs3" ]] && return 0 [[ "$fs" == "nfs4" ]] && return 0 done return 255 } return 0}
so only affects the dracut modules to be added.
For nfs instmods, dracut handles it in installkernel(), it is: # called by dracut installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
"The --force-add extension to instmods" will involve many dracut's fundamental changes.
So there are two problems here.
- --mount parsing and add nfs ko files in another reply
- --force-add only affects module check
For 1), the original logic about nfs module seems wrong. One can setup nfs4 in config files, but just use mount -t nfs, it will actually use nfs4 kernel module. (Need verification..). If I am right then in case mount_needs for nfs all nfs kernel module should be added.
The original design needs nfs to be mounted beforehand, although users can use "mount -t nfs" for nfs4, but findmnt will get the right "nfs4" fstype, also the related modules(nfsv4.ko) were loaded after the mount, so there is no problem for instmods to install "nfsv4,ko".
The current implementation of dracut: function inst1mod() { <snip> # If we are building a host-specific initramfs and this # module is not already loaded, move on to the next one. [[ $hostonly ]] \ && ! module_is_host_only "$_mod" \ && return 0
module_is_host_only() { local _mod=$1 local _modenc a i _k _s _v _aliases _mod=${_mod##*/} _mod=${_mod%.ko} _modenc=${_mod//-/_}
[[ " $add_drivers " == *\ ${_mod}\ * ]] && return 0
# check if module is loaded [[ ${host_modules["$_modenc"]} ]] && return 0
Thus for $hostonly mode, it will fail to install any ko not loaded if not explicitly added via "--add-drivers".
I am not quite clear about "mount_needs" you mentioned, from the code it seems also to be only related to dracut's module check.
For 2), extend --force-add to installkernel() is also reasonable, just pass some variables to instmods function may work like some EVN varialbes so it only affects the callback from specific dracut module.
But if 1) works maybe we can leave 2) in todo list and discuss it later when we have to do it.
From my description above, I'm afraid 1) can't work, or do I miss something?
Regards, Xunlei
Thanks Dave
On 2016/06/08 at 10:30, Dave Young wrote:
On 06/06/16 at 05:21pm, Xunlei Pang wrote:
On 2016/06/06 at 09:34, Xunlei Pang wrote:
On 2016/06/06 at 09:01, Xunlei Pang wrote:
On 2016/06/02 at 16:48, Dave Young wrote:
On 06/02/16 at 04:21pm, Xunlei Pang wrote:
On 2016/06/02 at 15:46, Dave Young wrote: > Hi, Xunlei > > Seems I sent wrong draft, here is the right one: > > Add a question about below > --add-driver "nfs nfsv4" > > Why should we add them? if we addes dracut 95nfs module then it will install > all the nfs kernel modules and network module. Yeah, dracut 95nfs module has installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
But actually during my test, I found that if nfs was not mounted, some of the modules (for example nfsv4)will fail to be installed by instmods.
Hmm, it may related to we use hostonly, could you check the instmods function to see if we can handle it without adding drivers in dracut args?
You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common issue due to the target not mounted beforehand.
Currently, I can't think of a nice way to handle it without adding drivers explicitly.
I did some tests, seems dracut will parse "--mount" to add filesystem-related ko modules.
For nfs,
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfs defaults", then "nfs.ko" will be added to initramfs only.
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfsv4 defaults", then both "nfs.ko" and "nfsv4.ko" will be added.
Further investigation shows that this can't work, the reason why nfsv4.ko is added is because in 90kernel-modules/module-setup.sh installkernel(), we have: for i in $(host_fs_all); do hostonly='' instmods $i done
So nfsv4.ko which is got from the fstype is added, but actually the mount will fail due to the invalid "nfsv4" specified in "--mount"(the right one should be "nfs4").
Seems we are still not clear about the problem, shouldn't it been mapped from nfs4 -> nfsv4.ko automaticlly?
Unfortunately, the current implementation does no mapping about this. Maybe we could throw a patch on this to let "nfs4" mapping to "nfsv4" for instmods.
Regards, Xunlei
Also mount_needs should add kernel modules without considering hostonly or not, if --mount need instmods should install the ko unconditionally
Regards, Xunlei
Regards, Xunlei
Regards, Xunlei
> But I have a concern, if the network can be setup correctly. Kdump still will > find the right nic and set it up? The implementation patch added:
dracut_args)if is_nfs_in_dracut_args "$config_val"; thenkdump_install_net "$(get_dracut_args_target "$config_val")"fi;;So the net device when specifying nfs can be installed correctly.
Ok, cool then it should be ok.
BTW, for patch 1 I have not got time to think about it, maybe I will reply tomorrow.
Thanks Dave
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
On 06/12/16 at 10:05am, Xunlei Pang wrote:
On 2016/06/08 at 10:16, Dave Young wrote:
Hi, On 06/06/16 at 05:00pm, Xunlei Pang wrote:
On 2016/06/06 at 11:12, Dave Young wrote:
Hi Xunlei,
On 06/06/16 at 10:43am, Xunlei Pang wrote:
On 2016/06/06 at 09:55, Dave Young wrote:
On 06/06/16 at 09:01am, Xunlei Pang wrote: > On 2016/06/02 at 16:48, Dave Young wrote: >> On 06/02/16 at 04:21pm, Xunlei Pang wrote: >>> On 2016/06/02 at 15:46, Dave Young wrote: >>>> Hi, Xunlei >>>> >>>> Seems I sent wrong draft, here is the right one: >>>> >>>> Add a question about below >>>> --add-driver "nfs nfsv4" >>>> >>>> Why should we add them? if we addes dracut 95nfs module then it will install >>>> all the nfs kernel modules and network module. >>> Yeah, dracut 95nfs module has >>> installkernel() { >>> instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files >>> } >>> >>> But actually during my test, I found that if nfs was not mounted, some of the modules >>> (for example nfsv4)will fail to be installed by instmods. >> Hmm, it may related to we use hostonly, could you check the instmods function >> to see if we can handle it without adding drivers in dracut args? > You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common > issue due to the target not mounted beforehand. > > Currently, I can't think of a nice way to handle it without adding drivers explicitly. Does --force-add works?
I doesn't work, the "nfs" dracut module is ok, it's the "instmods" in dracut's "nfs" that doesn't work. But with the other reply to specify the right "nfsv4" filesytem type, it should work for us.
If --force-add is meant to bypass hostonly then it should be extended to also work in instmods then we can use force-add for these --mount so that one do not need add extra kernel modules.
"--force_add" affects check() in module_setup.sh.
For nfs, it is: # called by dracut check() { # If our prerequisites are not met, fail anyways. require_any_binary rpcbind portmap || return 1 require_binaries rpc.statd mount.nfs mount.nfs4 umount || return 1
[[ $hostonly ]] || [[ $mount_needs ]] && { for fs in "${host_fs_types[@]}"; do [[ "$fs" == "nfs" ]] && return 0 [[ "$fs" == "nfs3" ]] && return 0 [[ "$fs" == "nfs4" ]] && return 0 done return 255 } return 0}
so only affects the dracut modules to be added.
For nfs instmods, dracut handles it in installkernel(), it is: # called by dracut installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
"The --force-add extension to instmods" will involve many dracut's fundamental changes.
So there are two problems here.
- --mount parsing and add nfs ko files in another reply
- --force-add only affects module check
For 1), the original logic about nfs module seems wrong. One can setup nfs4 in config files, but just use mount -t nfs, it will actually use nfs4 kernel module. (Need verification..). If I am right then in case mount_needs for nfs all nfs kernel module should be added.
The original design needs nfs to be mounted beforehand, although users can use "mount -t nfs" for nfs4, but findmnt will get the right "nfs4" fstype, also the related modules(nfsv4.ko) were loaded after the mount, so there is no problem for instmods to install "nfsv4,ko".
The current implementation of dracut: function inst1mod() { <snip> # If we are building a host-specific initramfs and this # module is not already loaded, move on to the next one. [[ $hostonly ]] \ && ! module_is_host_only "$_mod" \ && return 0
module_is_host_only() { local _mod=$1 local _modenc a i _k _s _v _aliases _mod=${_mod##*/} _mod=${_mod%.ko} _modenc=${_mod//-/_}
[[ " $add_drivers " == *\ ${_mod}\ * ]] && return 0 # check if module is loaded [[ ${host_modules["$_modenc"]} ]] && return 0Thus for $hostonly mode, it will fail to install any ko not loaded if not explicitly added via "--add-drivers".
I am not quite clear about "mount_needs" you mentioned, from the code it seems also to be only related to dracut's module check.
mount_needs is introduced for adding dracut modules for --mount needed, but yes it only handles dracut modules in check() function, it may need to extend to inst kernel modules.
OTOH, since we have mount_needs why do we need to add 95nfs dracut modules in kdump code? Shouldn't it been added via mount_needs check?
Another issue is we may need use force_add because we are using hostonly mode along with mount_needs, we can not use mount_needs but without respecting hostonly for adding non-hostonly kernel modules..
So we should still force add 95nfs dracut modules in out code and extend force add to unset hostonly during handling kernel modules. It make sense because force-add already do that in module check functions it has already unset hostonly that means it has higer priority than hostonly.
For 2), extend --force-add to installkernel() is also reasonable, just pass some variables to instmods function may work like some EVN varialbes so it only affects the callback from specific dracut module.
But if 1) works maybe we can leave 2) in todo list and discuss it later when we have to do it.
From my description above, I'm afraid 1) can't work, or do I miss something?
Yes, agreed.
Thanks Dave
Regards, Xunlei
Thanks Dave
For nfs,
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfs defaults", then "nfs.ko" will be added to initramfs only.
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfsv4 defaults", then both "nfs.ko" and "nfsv4.ko" will be added.
Further investigation shows that this can't work, the reason why nfsv4.ko is added is because in 90kernel-modules/module-setup.sh installkernel(), we have: for i in $(host_fs_all); do hostonly='' instmods $i done
So nfsv4.ko which is got from the fstype is added, but actually the mount will fail due to the invalid "nfsv4" specified in "--mount"(the right one should be "nfs4").
Seems we are still not clear about the problem, shouldn't it been mapped from nfs4 -> nfsv4.ko automaticlly?
Unfortunately, the current implementation does no mapping about this. Maybe we could throw a patch on this to let "nfs4" mapping to "nfsv4" for instmods.
From nfs manpage nfs4 fstype is deprecated, -o vers=4 is prefered instead. In case without -o vers, 4 will be tried first, then 3, then 2.
So for nfs, maybe the right way is including all the kernel modules
Thanks Dave
On 2016/06/12 at 10:35, Dave Young wrote:
On 06/12/16 at 10:05am, Xunlei Pang wrote:
On 2016/06/08 at 10:16, Dave Young wrote:
Hi, On 06/06/16 at 05:00pm, Xunlei Pang wrote:
On 2016/06/06 at 11:12, Dave Young wrote:
Hi Xunlei,
On 06/06/16 at 10:43am, Xunlei Pang wrote:
On 2016/06/06 at 09:55, Dave Young wrote: > On 06/06/16 at 09:01am, Xunlei Pang wrote: >> On 2016/06/02 at 16:48, Dave Young wrote: >>> On 06/02/16 at 04:21pm, Xunlei Pang wrote: >>>> On 2016/06/02 at 15:46, Dave Young wrote: >>>>> Hi, Xunlei >>>>> >>>>> Seems I sent wrong draft, here is the right one: >>>>> >>>>> Add a question about below >>>>> --add-driver "nfs nfsv4" >>>>> >>>>> Why should we add them? if we addes dracut 95nfs module then it will install >>>>> all the nfs kernel modules and network module. >>>> Yeah, dracut 95nfs module has >>>> installkernel() { >>>> instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files >>>> } >>>> >>>> But actually during my test, I found that if nfs was not mounted, some of the modules >>>> (for example nfsv4)will fail to be installed by instmods. >>> Hmm, it may related to we use hostonly, could you check the instmods function >>> to see if we can handle it without adding drivers in dracut args? >> You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common >> issue due to the target not mounted beforehand. >> >> Currently, I can't think of a nice way to handle it without adding drivers explicitly. > Does --force-add works? I doesn't work, the "nfs" dracut module is ok, it's the "instmods" in dracut's "nfs" that doesn't work. But with the other reply to specify the right "nfsv4" filesytem type, it should work for us.
If --force-add is meant to bypass hostonly then it should be extended to also work in instmods then we can use force-add for these --mount so that one do not need add extra kernel modules.
"--force_add" affects check() in module_setup.sh.
For nfs, it is: # called by dracut check() { # If our prerequisites are not met, fail anyways. require_any_binary rpcbind portmap || return 1 require_binaries rpc.statd mount.nfs mount.nfs4 umount || return 1
[[ $hostonly ]] || [[ $mount_needs ]] && { for fs in "${host_fs_types[@]}"; do [[ "$fs" == "nfs" ]] && return 0 [[ "$fs" == "nfs3" ]] && return 0 [[ "$fs" == "nfs4" ]] && return 0 done return 255 } return 0}
so only affects the dracut modules to be added.
For nfs instmods, dracut handles it in installkernel(), it is: # called by dracut installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
"The --force-add extension to instmods" will involve many dracut's fundamental changes.
So there are two problems here.
- --mount parsing and add nfs ko files in another reply
- --force-add only affects module check
For 1), the original logic about nfs module seems wrong. One can setup nfs4 in config files, but just use mount -t nfs, it will actually use nfs4 kernel module. (Need verification..). If I am right then in case mount_needs for nfs all nfs kernel module should be added.
The original design needs nfs to be mounted beforehand, although users can use "mount -t nfs" for nfs4, but findmnt will get the right "nfs4" fstype, also the related modules(nfsv4.ko) were loaded after the mount, so there is no problem for instmods to install "nfsv4,ko".
The current implementation of dracut: function inst1mod() { <snip> # If we are building a host-specific initramfs and this # module is not already loaded, move on to the next one. [[ $hostonly ]] \ && ! module_is_host_only "$_mod" \ && return 0
module_is_host_only() { local _mod=$1 local _modenc a i _k _s _v _aliases _mod=${_mod##*/} _mod=${_mod%.ko} _modenc=${_mod//-/_}
[[ " $add_drivers " == *\ ${_mod}\ * ]] && return 0 # check if module is loaded [[ ${host_modules["$_modenc"]} ]] && return 0Thus for $hostonly mode, it will fail to install any ko not loaded if not explicitly added via "--add-drivers".
I am not quite clear about "mount_needs" you mentioned, from the code it seems also to be only related to dracut's module check.
mount_needs is introduced for adding dracut modules for --mount needed, but yes it only handles dracut modules in check() function, it may need to extend to inst kernel modules.
OTOH, since we have mount_needs why do we need to add 95nfs dracut modules in kdump code? Shouldn't it been added via mount_needs check?
Yes, agree, I think kdump needn't add "nfs" dracut module explicitly. The check_mount should be able to add it properly for us, as we have nfs "--mount" info, the host_fs_types[] will contain the "nfs*" fstype.
Another issue is we may need use force_add because we are using hostonly mode along with mount_needs, we can not use mount_needs but without respecting hostonly for adding non-hostonly kernel modules.. So we should still force add 95nfs dracut modules in out code and extend force add to unset hostonly during handling kernel modules. It make sense because force-add already do that in module check functions it has already unset hostonly that means it has higer priority than hostonly.
force_add is semantically better for the purpose of this patch, but OTOH this patch actually doesn't only deal with nfs, it's for a general purpose "--mount".
So I would rather rely on mount_needs to force "instmods".
Regards, Xunlei
For 2), extend --force-add to installkernel() is also reasonable, just pass some variables to instmods function may work like some EVN varialbes so it only affects the callback from specific dracut module.
But if 1) works maybe we can leave 2) in todo list and discuss it later when we have to do it.
From my description above, I'm afraid 1) can't work, or do I miss something?
Yes, agreed.
Thanks Dave
Regards, Xunlei
Thanks Dave
On 2016/06/12 at 11:00, Dave Young wrote:
For nfs,
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfs defaults", then "nfs.ko" will be added to initramfs only.
- if we specify "dracut_args --mount "10.66.129.115:/export/nfs /test nfsv4 defaults", then both "nfs.ko" and "nfsv4.ko" will be added.
Further investigation shows that this can't work, the reason why nfsv4.ko is added is because in 90kernel-modules/module-setup.sh installkernel(), we have: for i in $(host_fs_all); do hostonly='' instmods $i done
So nfsv4.ko which is got from the fstype is added, but actually the mount will fail due to the invalid "nfsv4" specified in "--mount"(the right one should be "nfs4").
Seems we are still not clear about the problem, shouldn't it been mapped from nfs4 -> nfsv4.ko automaticlly?
Unfortunately, the current implementation does no mapping about this. Maybe we could throw a patch on this to let "nfs4" mapping to "nfsv4" for instmods.
From nfs manpage nfs4 fstype is deprecated, -o vers=4 is prefered instead. In case without -o vers, 4 will be tried first, then 3, then 2.
For this patch, we use dracut's "--mount", which requires a <filesystem type> mandatorily, so this should not be an issue.
Regards, Xunlei
So for nfs, maybe the right way is including all the kernel modules
Thanks Dave
On 2016/06/12 at 12:01, Xunlei Pang wrote:
On 2016/06/12 at 10:35, Dave Young wrote:
On 06/12/16 at 10:05am, Xunlei Pang wrote:
On 2016/06/08 at 10:16, Dave Young wrote:
Hi, On 06/06/16 at 05:00pm, Xunlei Pang wrote:
On 2016/06/06 at 11:12, Dave Young wrote:
Hi Xunlei,
On 06/06/16 at 10:43am, Xunlei Pang wrote: > On 2016/06/06 at 09:55, Dave Young wrote: >> On 06/06/16 at 09:01am, Xunlei Pang wrote: >>> On 2016/06/02 at 16:48, Dave Young wrote: >>>> On 06/02/16 at 04:21pm, Xunlei Pang wrote: >>>>> On 2016/06/02 at 15:46, Dave Young wrote: >>>>>> Hi, Xunlei >>>>>> >>>>>> Seems I sent wrong draft, here is the right one: >>>>>> >>>>>> Add a question about below >>>>>> --add-driver "nfs nfsv4" >>>>>> >>>>>> Why should we add them? if we addes dracut 95nfs module then it will install >>>>>> all the nfs kernel modules and network module. >>>>> Yeah, dracut 95nfs module has >>>>> installkernel() { >>>>> instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files >>>>> } >>>>> >>>>> But actually during my test, I found that if nfs was not mounted, some of the modules >>>>> (for example nfsv4)will fail to be installed by instmods. >>>> Hmm, it may related to we use hostonly, could you check the instmods function >>>> to see if we can handle it without adding drivers in dracut args? >>> You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common >>> issue due to the target not mounted beforehand. >>> >>> Currently, I can't think of a nice way to handle it without adding drivers explicitly. >> Does --force-add works? > I doesn't work, the "nfs" dracut module is ok, it's the "instmods" in dracut's "nfs" that doesn't work. > But with the other reply to specify the right "nfsv4" filesytem type, it should work for us. If --force-add is meant to bypass hostonly then it should be extended to also work in instmods then we can use force-add for these --mount so that one do not need add extra kernel modules.
"--force_add" affects check() in module_setup.sh.
For nfs, it is: # called by dracut check() { # If our prerequisites are not met, fail anyways. require_any_binary rpcbind portmap || return 1 require_binaries rpc.statd mount.nfs mount.nfs4 umount || return 1
[[ $hostonly ]] || [[ $mount_needs ]] && { for fs in "${host_fs_types[@]}"; do [[ "$fs" == "nfs" ]] && return 0 [[ "$fs" == "nfs3" ]] && return 0 [[ "$fs" == "nfs4" ]] && return 0 done return 255 } return 0}
so only affects the dracut modules to be added.
For nfs instmods, dracut handles it in installkernel(), it is: # called by dracut installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
"The --force-add extension to instmods" will involve many dracut's fundamental changes.
So there are two problems here.
- --mount parsing and add nfs ko files in another reply
- --force-add only affects module check
For 1), the original logic about nfs module seems wrong. One can setup nfs4 in config files, but just use mount -t nfs, it will actually use nfs4 kernel module. (Need verification..). If I am right then in case mount_needs for nfs all nfs kernel module should be added.
The original design needs nfs to be mounted beforehand, although users can use "mount -t nfs" for nfs4, but findmnt will get the right "nfs4" fstype, also the related modules(nfsv4.ko) were loaded after the mount, so there is no problem for instmods to install "nfsv4,ko".
The current implementation of dracut: function inst1mod() { <snip> # If we are building a host-specific initramfs and this # module is not already loaded, move on to the next one. [[ $hostonly ]] \ && ! module_is_host_only "$_mod" \ && return 0
module_is_host_only() { local _mod=$1 local _modenc a i _k _s _v _aliases _mod=${_mod##*/} _mod=${_mod%.ko} _modenc=${_mod//-/_}
[[ " $add_drivers " == *\ ${_mod}\ * ]] && return 0 # check if module is loaded [[ ${host_modules["$_modenc"]} ]] && return 0Thus for $hostonly mode, it will fail to install any ko not loaded if not explicitly added via "--add-drivers".
I am not quite clear about "mount_needs" you mentioned, from the code it seems also to be only related to dracut's module check.
mount_needs is introduced for adding dracut modules for --mount needed, but yes it only handles dracut modules in check() function, it may need to extend to inst kernel modules.
OTOH, since we have mount_needs why do we need to add 95nfs dracut modules in kdump code? Shouldn't it been added via mount_needs check?
Yes, agree, I think kdump needn't add "nfs" dracut module explicitly. The check_mount should be able to add it properly for us, as we have nfs "--mount" info, the host_fs_types[] will contain the "nfs*" fstype.
Another issue is we may need use force_add because we are using hostonly mode along with mount_needs, we can not use mount_needs but without respecting hostonly for adding non-hostonly kernel modules.. So we should still force add 95nfs dracut modules in out code and extend force add to unset hostonly during handling kernel modules. It make sense because force-add already do that in module check functions it has already unset hostonly that means it has higer priority than hostonly.
force_add is semantically better for the purpose of this patch, but OTOH this patch actually doesn't only deal with nfs, it's for a general purpose "--mount".
So I would rather rely on mount_needs to force "instmods".
From my tests, unlike nfsv4, nfs/ext[234]/xfs can work properly, becasue in 90kernel-modules/module-setup.sh installkernel(): for i in $(host_fs_all); do hostonly='' instmods $i done
So for these fstypes, they have a valid mapping (or same) name to their ko names, say "xfs.ko" for "xfs", "ext4.ko" for "ext3", and they can be handled properly(as hostonly was unset).
But for fstype "nfs[2-4]", its ko is "nfsv[2-4].ko", if we do a mapping like discussed previously, tests show it can work properly:
for i in $(host_fs_all); do + if [[ $i = nfs[2-4] ]]; then + i=${i/nfs/nfsv} + fi hostonly='' instmods $i done
This will be a simple fix, and can omit explicitly kdump adding "nfs" dracut module for all cases.
Regards, Xunlei
For 2), extend --force-add to installkernel() is also reasonable, just pass some variables to instmods function may work like some EVN varialbes so it only affects the callback from specific dracut module.
But if 1) works maybe we can leave 2) in todo list and discuss it later when we have to do it.
From my description above, I'm afraid 1) can't work, or do I miss something?
Yes, agreed.
Thanks Dave
Regards, Xunlei
Thanks Dave
On 2016/06/12 at 13:16, Xunlei Pang wrote:
On 2016/06/12 at 12:01, Xunlei Pang wrote:
On 2016/06/12 at 10:35, Dave Young wrote:
On 06/12/16 at 10:05am, Xunlei Pang wrote:
On 2016/06/08 at 10:16, Dave Young wrote:
Hi, On 06/06/16 at 05:00pm, Xunlei Pang wrote:
On 2016/06/06 at 11:12, Dave Young wrote: > Hi Xunlei, > > On 06/06/16 at 10:43am, Xunlei Pang wrote: >> On 2016/06/06 at 09:55, Dave Young wrote: >>> On 06/06/16 at 09:01am, Xunlei Pang wrote: >>>> On 2016/06/02 at 16:48, Dave Young wrote: >>>>> On 06/02/16 at 04:21pm, Xunlei Pang wrote: >>>>>> On 2016/06/02 at 15:46, Dave Young wrote: >>>>>>> Hi, Xunlei >>>>>>> >>>>>>> Seems I sent wrong draft, here is the right one: >>>>>>> >>>>>>> Add a question about below >>>>>>> --add-driver "nfs nfsv4" >>>>>>> >>>>>>> Why should we add them? if we addes dracut 95nfs module then it will install >>>>>>> all the nfs kernel modules and network module. >>>>>> Yeah, dracut 95nfs module has >>>>>> installkernel() { >>>>>> instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files >>>>>> } >>>>>> >>>>>> But actually during my test, I found that if nfs was not mounted, some of the modules >>>>>> (for example nfsv4)will fail to be installed by instmods. >>>>> Hmm, it may related to we use hostonly, could you check the instmods function >>>>> to see if we can handle it without adding drivers in dracut args? >>>> You're right, it's due to the hostonly dracut option, and it's not nfs-only, it's a common >>>> issue due to the target not mounted beforehand. >>>> >>>> Currently, I can't think of a nice way to handle it without adding drivers explicitly. >>> Does --force-add works? >> I doesn't work, the "nfs" dracut module is ok, it's the "instmods" in dracut's "nfs" that doesn't work. >> But with the other reply to specify the right "nfsv4" filesytem type, it should work for us. > If --force-add is meant to bypass hostonly then it should be extended to > also work in instmods then we can use force-add for these --mount so > that one do not need add extra kernel modules. "--force_add" affects check() in module_setup.sh.
For nfs, it is: # called by dracut check() { # If our prerequisites are not met, fail anyways. require_any_binary rpcbind portmap || return 1 require_binaries rpc.statd mount.nfs mount.nfs4 umount || return 1
[[ $hostonly ]] || [[ $mount_needs ]] && { for fs in "${host_fs_types[@]}"; do [[ "$fs" == "nfs" ]] && return 0 [[ "$fs" == "nfs3" ]] && return 0 [[ "$fs" == "nfs4" ]] && return 0 done return 255 } return 0}
so only affects the dracut modules to be added.
For nfs instmods, dracut handles it in installkernel(), it is: # called by dracut installkernel() { instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files }
"The --force-add extension to instmods" will involve many dracut's fundamental changes.
So there are two problems here.
- --mount parsing and add nfs ko files in another reply
- --force-add only affects module check
For 1), the original logic about nfs module seems wrong. One can setup nfs4 in config files, but just use mount -t nfs, it will actually use nfs4 kernel module. (Need verification..). If I am right then in case mount_needs for nfs all nfs kernel module should be added.
The original design needs nfs to be mounted beforehand, although users can use "mount -t nfs" for nfs4, but findmnt will get the right "nfs4" fstype, also the related modules(nfsv4.ko) were loaded after the mount, so there is no problem for instmods to install "nfsv4,ko".
The current implementation of dracut: function inst1mod() { <snip> # If we are building a host-specific initramfs and this # module is not already loaded, move on to the next one. [[ $hostonly ]] \ && ! module_is_host_only "$_mod" \ && return 0
module_is_host_only() { local _mod=$1 local _modenc a i _k _s _v _aliases _mod=${_mod##*/} _mod=${_mod%.ko} _modenc=${_mod//-/_}
[[ " $add_drivers " == *\ ${_mod}\ * ]] && return 0 # check if module is loaded [[ ${host_modules["$_modenc"]} ]] && return 0Thus for $hostonly mode, it will fail to install any ko not loaded if not explicitly added via "--add-drivers".
I am not quite clear about "mount_needs" you mentioned, from the code it seems also to be only related to dracut's module check.
mount_needs is introduced for adding dracut modules for --mount needed, but yes it only handles dracut modules in check() function, it may need to extend to inst kernel modules.
OTOH, since we have mount_needs why do we need to add 95nfs dracut modules in kdump code? Shouldn't it been added via mount_needs check?
Yes, agree, I think kdump needn't add "nfs" dracut module explicitly. The check_mount should be able to add it properly for us, as we have nfs "--mount" info, the host_fs_types[] will contain the "nfs*" fstype.
Another issue is we may need use force_add because we are using hostonly mode along with mount_needs, we can not use mount_needs but without respecting hostonly for adding non-hostonly kernel modules.. So we should still force add 95nfs dracut modules in out code and extend force add to unset hostonly during handling kernel modules. It make sense because force-add already do that in module check functions it has already unset hostonly that means it has higer priority than hostonly.
force_add is semantically better for the purpose of this patch, but OTOH this patch actually doesn't only deal with nfs, it's for a general purpose "--mount".
So I would rather rely on mount_needs to force "instmods".
From my tests, unlike nfsv4, nfs/ext[234]/xfs can work properly, becasue in 90kernel-modules/module-setup.sh installkernel(): for i in $(host_fs_all); do hostonly='' instmods $i done
So for these fstypes, they have a valid mapping (or same) name to their ko names, say "xfs.ko" for "xfs", "ext4.ko" for "ext3", and they can be handled properly(as hostonly was unset).
But for fstype "nfs[2-4]", its ko is "nfsv[2-4].ko", if we do a mapping like discussed previously, tests show it can work properly:
for i in $(host_fs_all); do
if [[ $i = nfs[2-4] ]]; theni=${i/nfs/nfsv}fi hostonly='' instmods $i doneThis will be a simple fix, and can omit explicitly kdump adding "nfs" dracut module for all cases.
From "man nfs" : The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. So I guess we can add all related ko modules for "nfs" fstype here, like the patch below?
for i in $(host_fs_all); do + if [[ $i = nfs ]]; then + # From "man nfs": The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. + # For "nfs" fstype, we better install all the possible ko modules(from 95nfs/module-setup.sh installkernel). + i="nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files" + elif [[ $i = nfs[3-4] ]]; then + # For example, map nfs4 to use nfsv4.ko + i=${i/nfs/nfsv} + fi hostonly='' instmods $i done
Or, if it is not acceptable on dracut's side, we can add "--add-drivers" for "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files" in kdump code in this patch like that in the early versions, any comment?
Regards, Xunlei
From "man nfs" : The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. So I guess we can add all related ko modules for "nfs" fstype here, like the patch below?
for i in $(host_fs_all); do
if [[ $i = nfs ]]; then# From "man nfs": The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated.# For "nfs" fstype, we better install all the possible ko modules(from 95nfs/module-setup.sh installkernel).i="nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files"elif [[ $i = nfs[3-4] ]]; then# For example, map nfs4 to use nfsv4.koi=${i/nfs/nfsv}fi
It sounds good, just wonder if it can be improved by something like instmods =fs/nfs for all the nfs modules in the if section. Not tested, just a guess..
hostonly='' instmods $i doneOr, if it is not acceptable on dracut's side, we can add "--add-drivers" for "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files" in kdump code in this patch like that in the early versions, any comment?
It looks very odd actually :(
Thanks Dave
On 2016/06/15 at 14:15, Dave Young wrote:
From "man nfs" : The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. So I guess we can add all related ko modules for "nfs" fstype here, like the patch below?
for i in $(host_fs_all); do
if [[ $i = nfs ]]; then# From "man nfs": The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated.# For "nfs" fstype, we better install all the possible ko modules(from 95nfs/module-setup.sh installkernel).i="nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files"elif [[ $i = nfs[3-4] ]]; then# For example, map nfs4 to use nfsv4.koi=${i/nfs/nfsv}fiIt sounds good, just wonder if it can be improved by something like instmods =fs/nfs for all the nfs modules in the if section. Not tested, just a guess..
This is cool, it works. I'll try to make a dracut patch. BTW: I remembered we don't need to open a dracut bug upstream, but we still need a RHEL7 dracut bug, am I correct?
hostonly='' instmods $i doneOr, if it is not acceptable on dracut's side, we can add "--add-drivers" for "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files" in kdump code in this patch like that in the early versions, any comment?
It looks very odd actually :(
Yes, that's why I removed it in the following versions.
Regards, Xunlei
Thanks Dave
On 06/15/16 at 02:46pm, Xunlei Pang wrote:
On 2016/06/15 at 14:15, Dave Young wrote:
From "man nfs" : The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. So I guess we can add all related ko modules for "nfs" fstype here, like the patch below?
for i in $(host_fs_all); do
if [[ $i = nfs ]]; then# From "man nfs": The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated.# For "nfs" fstype, we better install all the possible ko modules(from 95nfs/module-setup.sh installkernel).i="nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files"elif [[ $i = nfs[3-4] ]]; then# For example, map nfs4 to use nfsv4.koi=${i/nfs/nfsv}fiIt sounds good, just wonder if it can be improved by something like instmods =fs/nfs for all the nfs modules in the if section. Not tested, just a guess..
This is cool, it works. I'll try to make a dracut patch.
Glad to see it work :)
BTW: I remembered we don't need to open a dracut bug upstream, but we still need a RHEL7 dracut bug, am I correct?
Yes, we need one..
hostonly='' instmods $i doneOr, if it is not acceptable on dracut's side, we can add "--add-drivers" for "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files" in kdump code in this patch like that in the early versions, any comment?
It looks very odd actually :(
Yes, that's why I removed it in the following versions.
Regards, Xunlei
Thanks Dave
On 2016/06/15 at 15:16, Dave Young wrote:
On 06/15/16 at 02:46pm, Xunlei Pang wrote:
On 2016/06/15 at 14:15, Dave Young wrote:
From "man nfs" : The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. So I guess we can add all related ko modules for "nfs" fstype here, like the patch below?
for i in $(host_fs_all); do
if [[ $i = nfs ]]; then# From "man nfs": The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated.# For "nfs" fstype, we better install all the possible ko modules(from 95nfs/module-setup.sh installkernel).i="nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files"elif [[ $i = nfs[3-4] ]]; then# For example, map nfs4 to use nfsv4.koi=${i/nfs/nfsv}fiIt sounds good, just wonder if it can be improved by something like instmods =fs/nfs for all the nfs modules in the if section. Not tested, just a guess..
This is cool, it works. I'll try to make a dracut patch.
Glad to see it work :)
Thinking more, it adds more nfs-related ko modules when using "=fs/nfs": -rw-r--r-- 1 root root 49513 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/blocklayout/blocklayoutdriver.ko -rw-r--r-- 1 root root 9249 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/grace.ko -rw-r--r-- 1 root root 9929 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/nfs_acl.ko -rw-r--r-- 1 root root 40705 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/filelayout/nfs_layout_nfsv41_files.ko -rw-r--r-- 1 root root 67393 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/flexfilelayout/nfs_layout_flexfiles.ko -rw-r--r-- 1 root root 456449 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfs.ko -rw-r--r-- 1 root root 69913 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv3.ko -rw-r--r-- 1 root root 856633 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv4.ko -rw-r--r-- 1 root root 42849 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/objlayout/objlayoutdriver.ko
Using "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files", have three less kernel modules installed: -rw-r--r-- 1 root root 9249 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/grace.ko -rw-r--r-- 1 root root 9929 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/nfs_acl.ko -rw-r--r-- 1 root root 40705 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/filelayout/nfs_layout_nfsv41_files.ko -rw-r--r-- 1 root root 456449 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfs.ko -rw-r--r-- 1 root root 69913 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv3.ko -rw-r--r-- 1 root root 856633 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv4.ko
Because "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files" is directly from 95nfs/module_setup.sh installkernel(), it should be safe enough to work.
Regards, Xunlei
BTW: I remembered we don't need to open a dracut bug upstream, but we still need a RHEL7 dracut bug, am I correct?
Yes, we need one..
hostonly='' instmods $i doneOr, if it is not acceptable on dracut's side, we can add "--add-drivers" for "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files" in kdump code in this patch like that in the early versions, any comment?
It looks very odd actually :(
Yes, that's why I removed it in the following versions.
Regards, Xunlei
Thanks Dave
On 06/15/16 at 04:33pm, Xunlei Pang wrote:
On 2016/06/15 at 15:16, Dave Young wrote:
On 06/15/16 at 02:46pm, Xunlei Pang wrote:
On 2016/06/15 at 14:15, Dave Young wrote:
From "man nfs" : The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. So I guess we can add all related ko modules for "nfs" fstype here, like the patch below?
for i in $(host_fs_all); do
if [[ $i = nfs ]]; then# From "man nfs": The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated.# For "nfs" fstype, we better install all the possible ko modules(from 95nfs/module-setup.sh installkernel).i="nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files"elif [[ $i = nfs[3-4] ]]; then# For example, map nfs4 to use nfsv4.koi=${i/nfs/nfsv}fiIt sounds good, just wonder if it can be improved by something like instmods =fs/nfs for all the nfs modules in the if section. Not tested, just a guess..
This is cool, it works. I'll try to make a dracut patch.
Glad to see it work :)
Thinking more, it adds more nfs-related ko modules when using "=fs/nfs": -rw-r--r-- 1 root root 49513 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/blocklayout/blocklayoutdriver.ko -rw-r--r-- 1 root root 9249 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/grace.ko -rw-r--r-- 1 root root 9929 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/nfs_acl.ko -rw-r--r-- 1 root root 40705 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/filelayout/nfs_layout_nfsv41_files.ko -rw-r--r-- 1 root root 67393 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/flexfilelayout/nfs_layout_flexfiles.ko -rw-r--r-- 1 root root 456449 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfs.ko -rw-r--r-- 1 root root 69913 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv3.ko -rw-r--r-- 1 root root 856633 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv4.ko -rw-r--r-- 1 root root 42849 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/objlayout/objlayoutdriver.ko
Using "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files", have three less kernel modules installed: -rw-r--r-- 1 root root 9249 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/grace.ko -rw-r--r-- 1 root root 9929 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/nfs_acl.ko -rw-r--r-- 1 root root 40705 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/filelayout/nfs_layout_nfsv41_files.ko -rw-r--r-- 1 root root 456449 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfs.ko -rw-r--r-- 1 root root 69913 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv3.ko -rw-r--r-- 1 root root 856633 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv4.ko
Because "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files" is directly from 95nfs/module_setup.sh installkernel(), it should be safe enough to work.
I think throw out the question and patch to dracut list is better than we discuss it here. Just cc 95nfs authors.
Not sure about the layout drivers, it may be useful for some variant of nfs. But we do not need nfs server side drivers.
Thanks Dave
On 2016/06/15 at 16:42, Dave Young wrote:
On 06/15/16 at 04:33pm, Xunlei Pang wrote:
On 2016/06/15 at 15:16, Dave Young wrote:
On 06/15/16 at 02:46pm, Xunlei Pang wrote:
On 2016/06/15 at 14:15, Dave Young wrote:
From "man nfs" : The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated. So I guess we can add all related ko modules for "nfs" fstype here, like the patch below?
for i in $(host_fs_all); do
if [[ $i = nfs ]]; then# From "man nfs": The fstype field contains "nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated.# For "nfs" fstype, we better install all the possible ko modules(from 95nfs/module-setup.sh installkernel).i="nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files"elif [[ $i = nfs[3-4] ]]; then# For example, map nfs4 to use nfsv4.koi=${i/nfs/nfsv}fiIt sounds good, just wonder if it can be improved by something like instmods =fs/nfs for all the nfs modules in the if section. Not tested, just a guess..
This is cool, it works. I'll try to make a dracut patch.
Glad to see it work :)
Thinking more, it adds more nfs-related ko modules when using "=fs/nfs": -rw-r--r-- 1 root root 49513 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/blocklayout/blocklayoutdriver.ko -rw-r--r-- 1 root root 9249 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/grace.ko -rw-r--r-- 1 root root 9929 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/nfs_acl.ko -rw-r--r-- 1 root root 40705 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/filelayout/nfs_layout_nfsv41_files.ko -rw-r--r-- 1 root root 67393 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/flexfilelayout/nfs_layout_flexfiles.ko -rw-r--r-- 1 root root 456449 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfs.ko -rw-r--r-- 1 root root 69913 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv3.ko -rw-r--r-- 1 root root 856633 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv4.ko -rw-r--r-- 1 root root 42849 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/objlayout/objlayoutdriver.ko
Using "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files", have three less kernel modules installed: -rw-r--r-- 1 root root 9249 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/grace.ko -rw-r--r-- 1 root root 9929 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs_common/nfs_acl.ko -rw-r--r-- 1 root root 40705 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/filelayout/nfs_layout_nfsv41_files.ko -rw-r--r-- 1 root root 456449 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfs.ko -rw-r--r-- 1 root root 69913 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv3.ko -rw-r--r-- 1 root root 856633 Jun 15 02:22 usr/lib/modules/3.10.0-431.el7.test.x86_64/kernel/fs/nfs/nfsv4.ko
Because "nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files" is directly from 95nfs/module_setup.sh installkernel(), it should be safe enough to work.
I think throw out the question and patch to dracut list is better than we discuss it here. Just cc 95nfs authors.
Not sure about the layout drivers, it may be useful for some variant of nfs. But we do not need nfs server side drivers.
ok, I will send out the patch after some tests.
Thanks Dave
-
Dave Young -
Pratyush Anand -
Xunlei Pang -
Xunlei Pang