In 1st kernel, the iscsi device could be both software or hardware based. But we only use software iscsi in 2nd kernel. This is fine for software iscsi as it's consistent with 1st kernel. However kdump bringing up hardware iscsi in software mode could lead conflicts with dracut bringing up logic, depending on the configuration.
If boot disk is hardware iscsi, we should still use hardware iscsi in 2nd kernel. In this case, dracut will bring up the device like it does for normal boot. kdump don't need to do extra work to configure software iscsi.
Signed-off-by: WANG Chao chaowang@redhat.com --- dracut-module-setup.sh | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index d65c8c0..6f6648d 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -412,7 +412,11 @@ kdump_get_iscsi_initiator() { return 1 }
-# No ibft handling yet. +# Figure out if the iscsi session is based on iBFT or firmware +kdump_handle_hw_iscsi() { + [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ] +} + kdump_setup_iscsi_device() { local path=$1 local tgt_name; local tgt_ipaddr; @@ -435,6 +439,10 @@ kdump_setup_iscsi_device() { return 1 fi
+ if kdump_handle_hw_iscsi ${path}; then + return 0 + fi + tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name") tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")