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(a)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")
--
2.1.0
Show replies by date