On 12/04/14 at 03:51pm, Vivek Goyal wrote:
On Wed, Nov 26, 2014 at 06:46:23PM +0800, WANG Chao wrote:
iscsi configuration can be exposed in /sys/firmware/ibft or /sys/firmware/iscsi_bootX by iBFT or vendor specific driver (iBFT-like). With "rd.iscsi.firmware" set in cmdline, dracut can bring up the iscsi session regarding these exposed configurations. That means in this case, it's not necessary to pass these configurations to 2nd kernel, because dracut can directly use the exposed ones under sysfs.
If an iscsi session is based on firmware's configuration, then its node.discovery_type will be "fw". If that's the case, we tell dracut "rd.iscsi.firmware", and in 2nd kernel it will run "iscsistart -b" to bring up the session regarding the firmware's exposed configurations.
Signed-off-by: WANG Chao chaowang@redhat.com
dracut-module-setup.sh | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index b6218b3..c6ec035 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -411,7 +411,19 @@ kdump_get_iscsi_initiator() { return 1 }
-# No ibft handling yet. +# Figure out if the iscsi session is based on iBFT or firmware +kdump_handle_fw_iscsi() {
- local netroot_conf="${initdir}/etc/cmdline.d/50iscsi.conf"
- if [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]; then
# dracut will bring up the iscsi device from firmware's configuration
echo "rd.iscsi.firmware" >> $netroot_conf
return 0
- fi
- return 1
+}
kdump_setup_iscsi_device() { local path=$1 local tgt_name; local tgt_ipaddr; @@ -442,6 +454,10 @@ kdump_setup_iscsi_device() {
kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr
- if kdump_handle_fw_iscsi ${path}; then
return 0
- fi
So this function takes care of both hardware iscsi as well as ibft? What is this ibft mode (which is not hardware iscsi?)
Actually, I find some issues about this patch. When rd.iscsi.ibft or ip=ibft is specified in 1st kernel cmdline, we must not bring up the NIC. Otherwise dracut will die and say it can't handle duplicated ip configuration for same device.
I find hardware iscsi and ibft are very much complicated. I'm thinking about we first support the systems booting from hardware iscsi or ibft?
After that if customer request other corner case for iscsi, we can add the support case by case.
Also I think we need to have better organization of code. current kdump_setup_iscsi_device() primarily is code for setting up software iscsi connections.
I think we should have 2-3 functions for setting up each type of iscsi connection. kdump_setup_software_iscsi(), kdump_setup_hw_iscsi() etc and call respective function based on type of connection we detect.
Right. This sounds good to me.
Thanks WANG Chao
That way code should be more redabale.
Thanks Vivek
tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name") # get and set username and password details
-- 1.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec