[PATCH] dracut-module-setup: Return from iscsi path immediately for hardward iscsi without iBFT
Hardware iscsi can export the iscsi device before starting to load the kernel code, which setups the iscsi card using the config stored in hardward iscsi card memory.
kdump need not do anything for this sort of hardware iscsi card, if this card does not have the feature iBFT. IBFT can export the iscsi configuration from hardware iscsi card memroy to current running kernel. Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m session -r /sys/block/xxx", due to limitation of iscsi info exported by kernel.
Once the machine is plugged in this sort of hardware iscsi card, kdump returns as soon as possible.
Signed-off-by: Minfei Huang mhuang@redhat.com --- dracut-module-setup.sh | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 9b398eb..e2fef9b 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -507,16 +507,6 @@ kdump_setup_iscsi_device() { local netroot_conf="${initdir}/etc/cmdline.d/50iscsi.conf" local initiator_conf="/etc/iscsi/initiatorname.iscsi"
- dinfo "Found iscsi component $1" - - # Check once before getting explicit values, so we can output a decent - # error message. - - if ! /sbin/iscsiadm -m session -r ${path} >/dev/null ; then - derror "Unable to find iscsi record for $path" - return 1 - fi - tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name") tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
@@ -583,7 +573,18 @@ kdump_check_iscsi_targets () { until [[ -d sys || -d iscsi_session ]]; do cd .. done - [[ -d iscsi_session ]] && kdump_setup_iscsi_device "$PWD" + if [[ -d iscsi_session ]]; then + dinfo "Found iscsi component $PWD" + + # Hardware iscsi without the iBFT will fail to get + # iscsi session info, and return non-zero + # We need not do anything for this sort of hardware iscsi + /sbin/iscsiadm -m session -r "$PWD" 2>&- >/dev/null + if [ $? -eq 0 ]; then + # start to take care of iBFT + kdump_setup_iscsi_device "$PWD" + fi + fi )
[[ $hostonly ]] || [[ $mount_needs ]] && {
On 09/24/15 at 01:29pm, Minfei Huang wrote:
Hardware iscsi can export the iscsi device before starting to load the kernel code, which setups the iscsi card using the config stored in hardward iscsi card memory.
kdump need not do anything for this sort of hardware iscsi card, if this card does not have the feature iBFT. IBFT can export the iscsi configuration from hardware iscsi card memroy to current running kernel. Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m session -r /sys/block/xxx", due to limitation of iscsi info exported by kernel.
Once the machine is plugged in this sort of hardware iscsi card, kdump returns as soon as possible.
Since we do not know much about iscsi, could you describe the basic infomation about them?
1. how many type of cases we should consider for iscsi?
2. what is the difference between them, how to diffrentiate them.
3. how to setup them (basic steps)
BTW, I found a basic documentation about initiator and targets: https://www.thomas-krenn.com/en/wiki/ISCSI_Basics#iSCSI_Initiator
Signed-off-by: Minfei Huang mhuang@redhat.com
dracut-module-setup.sh | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 9b398eb..e2fef9b 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -507,16 +507,6 @@ kdump_setup_iscsi_device() { local netroot_conf="${initdir}/etc/cmdline.d/50iscsi.conf" local initiator_conf="/etc/iscsi/initiatorname.iscsi"
- dinfo "Found iscsi component $1"
- # Check once before getting explicit values, so we can output a decent
- # error message.
- if ! /sbin/iscsiadm -m session -r ${path} >/dev/null ; then
derror "Unable to find iscsi record for $path"return 1- fi
There may be other case for iscsiadm error out, so silent fail here? Looks like Vivek intended to add such error message in original code.
tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name") tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn\[0\].address")@@ -583,7 +573,18 @@ kdump_check_iscsi_targets () { until [[ -d sys || -d iscsi_session ]]; do cd .. done
[[ -d iscsi_session ]] && kdump_setup_iscsi_device "$PWD"
if [[ -d iscsi_session ]]; thendinfo "Found iscsi component $PWD"# Hardware iscsi without the iBFT will fail to get# iscsi session info, and return non-zero# We need not do anything for this sort of hardware iscsi/sbin/iscsiadm -m session -r "$PWD" 2>&- >/dev/nullif [ $? -eq 0 ]; then# start to take care of iBFT
It was target for software iscsi, so how to take care of iBFT?
kdump_setup_iscsi_device "$PWD"fifi)
[[ $hostonly ]] || [[ $mount_needs ]] && {
-- 2.1.0
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 09/25/15 at 02:39pm, Dave Young wrote:
On 09/24/15 at 01:29pm, Minfei Huang wrote:
Hardware iscsi can export the iscsi device before starting to load the kernel code, which setups the iscsi card using the config stored in hardward iscsi card memory.
kdump need not do anything for this sort of hardware iscsi card, if this card does not have the feature iBFT. IBFT can export the iscsi configuration from hardware iscsi card memroy to current running kernel. Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m session -r /sys/block/xxx", due to limitation of iscsi info exported by kernel.
Once the machine is plugged in this sort of hardware iscsi card, kdump returns as soon as possible.
Since we do not know much about iscsi, could you describe the basic infomation about them?
- how many type of cases we should consider for iscsi?
There are three iscsi initiators we use more frequently. 1) software iscsi initiator 2) iSCSI HBA 3) iBFT
- what is the difference between them, how to diffrentiate them.
1) software iscsi initiator - We can setup the iscsi environemnt by using tgt suit. It is more continent to setup the iscsi without the hardware supporting.
2) iSCSI HBA - System has no ability to detect the iscsi session config. The usage of exported iSCSI device is the same as local SCSI device.
3) iBFT - The iSCSI Bios Firmware Table (iBFT) is a table that is created in memory which is mapped with the iSCSI card firmware. Thus we can get the session config according to the command iscsiadm.
- how to setup them (basic steps)
1) software iscsi initiator - According to the command iscsiadm to setup the available seesion, and the session info should be passed manually
2) iSCSI HBA - Do nothing, except for passing "rd.iscsi.firmware=1" to the kernel. The iSCSI device will use the config stored in firmware to setup the session.
3) iBFT - Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to the kernel to setup the session.
Thanks Minfei
On 09/25/15 at 06:03pm, Minfei Huang wrote:
On 09/25/15 at 02:39pm, Dave Young wrote:
On 09/24/15 at 01:29pm, Minfei Huang wrote:
Hardware iscsi can export the iscsi device before starting to load the kernel code, which setups the iscsi card using the config stored in hardward iscsi card memory.
kdump need not do anything for this sort of hardware iscsi card, if this card does not have the feature iBFT. IBFT can export the iscsi configuration from hardware iscsi card memroy to current running kernel. Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m session -r /sys/block/xxx", due to limitation of iscsi info exported by kernel.
Once the machine is plugged in this sort of hardware iscsi card, kdump returns as soon as possible.
Since we do not know much about iscsi, could you describe the basic infomation about them?
- how many type of cases we should consider for iscsi?
There are three iscsi initiators we use more frequently.
- software iscsi initiator
- iSCSI HBA
- iBFT
- what is the difference between them, how to diffrentiate them.
software iscsi initiator
- We can setup the iscsi environemnt by using tgt suit. It is more
continent to setup the iscsi without the hardware supporting.
iSCSI HBA
- System has no ability to detect the iscsi session config. The
usage of exported iSCSI device is the same as local SCSI device.
iBFT
- The iSCSI Bios Firmware Table (iBFT) is a table that is created in
memory which is mapped with the iSCSI card firmware. Thus we can get the session config according to the command iscsiadm.
- how to setup them (basic steps)
software iscsi initiator
- According to the command iscsiadm to setup the available seesion,
and the session info should be passed manually
iSCSI HBA
- Do nothing, except for passing "rd.iscsi.firmware=1" to the
kernel. The iSCSI device will use the config stored in firmware to setup the session.
So assume your patch is for addressing 2), if it is a boot disk there should be rd.iscsi.firmware=1 in /proc/cmdline, but if it is not a boot disk, we need pass this param to second kernel?
What if there's both 2) and 1) existed?
- iBFT
setup the session.
- Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to the kernel to
Thanks Minfei _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 09/30/15 at 11:10am, Dave Young wrote:
On 09/25/15 at 06:03pm, Minfei Huang wrote:
On 09/25/15 at 02:39pm, Dave Young wrote:
On 09/24/15 at 01:29pm, Minfei Huang wrote:
Hardware iscsi can export the iscsi device before starting to load the kernel code, which setups the iscsi card using the config stored in hardward iscsi card memory.
kdump need not do anything for this sort of hardware iscsi card, if this card does not have the feature iBFT. IBFT can export the iscsi configuration from hardware iscsi card memroy to current running kernel. Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m session -r /sys/block/xxx", due to limitation of iscsi info exported by kernel.
Once the machine is plugged in this sort of hardware iscsi card, kdump returns as soon as possible.
Since we do not know much about iscsi, could you describe the basic infomation about them?
- how many type of cases we should consider for iscsi?
There are three iscsi initiators we use more frequently.
- software iscsi initiator
- iSCSI HBA
- iBFT
- what is the difference between them, how to diffrentiate them.
software iscsi initiator
- We can setup the iscsi environemnt by using tgt suit. It is more
continent to setup the iscsi without the hardware supporting.
iSCSI HBA
- System has no ability to detect the iscsi session config. The
usage of exported iSCSI device is the same as local SCSI device.
iBFT
- The iSCSI Bios Firmware Table (iBFT) is a table that is created in
memory which is mapped with the iSCSI card firmware. Thus we can get the session config according to the command iscsiadm.
- how to setup them (basic steps)
software iscsi initiator
- According to the command iscsiadm to setup the available seesion,
and the session info should be passed manually
iSCSI HBA
- Do nothing, except for passing "rd.iscsi.firmware=1" to the
kernel. The iSCSI device will use the config stored in firmware to setup the session.
So assume your patch is for addressing 2), if it is a boot disk there should be rd.iscsi.firmware=1 in /proc/cmdline, but if it is not a boot disk, we need pass this param to second kernel?
Hi, Dave.
Yes. This patch is to solve the situation 2) non-iBFT iSCSI HBA.
What if there's both 2) and 1) existed?
We can inherit this parameter from 1st kernel. Thus we can do nothing to bring up the iSCSI device, either boot device or non-boot device.
Thanks Minfei
- iBFT
setup the session.
- Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to the kernel to
On 09/30/15 at 12:01pm, Minfei Huang wrote:
On 09/30/15 at 11:10am, Dave Young wrote:
On 09/25/15 at 06:03pm, Minfei Huang wrote:
On 09/25/15 at 02:39pm, Dave Young wrote:
On 09/24/15 at 01:29pm, Minfei Huang wrote:
Hardware iscsi can export the iscsi device before starting to load the kernel code, which setups the iscsi card using the config stored in hardward iscsi card memory.
kdump need not do anything for this sort of hardware iscsi card, if this card does not have the feature iBFT. IBFT can export the iscsi configuration from hardware iscsi card memroy to current running kernel. Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m session -r /sys/block/xxx", due to limitation of iscsi info exported by kernel.
Once the machine is plugged in this sort of hardware iscsi card, kdump returns as soon as possible.
Since we do not know much about iscsi, could you describe the basic infomation about them?
- how many type of cases we should consider for iscsi?
There are three iscsi initiators we use more frequently.
- software iscsi initiator
- iSCSI HBA
- iBFT
- what is the difference between them, how to diffrentiate them.
software iscsi initiator
- We can setup the iscsi environemnt by using tgt suit. It is more
continent to setup the iscsi without the hardware supporting.
iSCSI HBA
- System has no ability to detect the iscsi session config. The
usage of exported iSCSI device is the same as local SCSI device.
iBFT
- The iSCSI Bios Firmware Table (iBFT) is a table that is created in
memory which is mapped with the iSCSI card firmware. Thus we can get the session config according to the command iscsiadm.
- how to setup them (basic steps)
software iscsi initiator
- According to the command iscsiadm to setup the available seesion,
and the session info should be passed manually
iSCSI HBA
- Do nothing, except for passing "rd.iscsi.firmware=1" to the
kernel. The iSCSI device will use the config stored in firmware to setup the session.
So assume your patch is for addressing 2), if it is a boot disk there should be rd.iscsi.firmware=1 in /proc/cmdline, but if it is not a boot disk, we need pass this param to second kernel?
Hi, Dave.
Yes. This patch is to solve the situation 2) non-iBFT iSCSI HBA.
What if there's both 2) and 1) existed?
We can inherit this parameter from 1st kernel. Thus we can do nothing to bring up the iSCSI device, either boot device or non-boot device.
I think 1st kernel parameter is only for boot device. non-boot you still need pass extra parameter to 2nd kernel cmdline.
Again about the second question, have you consider the situation both 1 and 2 being used? ie. 1) for crash device, 2) for root device.
Thanks Minfei
- iBFT
setup the session.
- Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to the kernel to
On 09/30/15 at 01:07pm, Dave Young wrote:
On 09/30/15 at 12:01pm, Minfei Huang wrote:
On 09/30/15 at 11:10am, Dave Young wrote:
On 09/25/15 at 06:03pm, Minfei Huang wrote:
On 09/25/15 at 02:39pm, Dave Young wrote:
On 09/24/15 at 01:29pm, Minfei Huang wrote:
Hardware iscsi can export the iscsi device before starting to load the kernel code, which setups the iscsi card using the config stored in hardward iscsi card memory.
kdump need not do anything for this sort of hardware iscsi card, if this card does not have the feature iBFT. IBFT can export the iscsi configuration from hardware iscsi card memroy to current running kernel. Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m session -r /sys/block/xxx", due to limitation of iscsi info exported by kernel.
Once the machine is plugged in this sort of hardware iscsi card, kdump returns as soon as possible.
Since we do not know much about iscsi, could you describe the basic infomation about them?
- how many type of cases we should consider for iscsi?
There are three iscsi initiators we use more frequently.
- software iscsi initiator
- iSCSI HBA
- iBFT
- what is the difference between them, how to diffrentiate them.
software iscsi initiator
- We can setup the iscsi environemnt by using tgt suit. It is more
continent to setup the iscsi without the hardware supporting.
iSCSI HBA
- System has no ability to detect the iscsi session config. The
usage of exported iSCSI device is the same as local SCSI device.
iBFT
- The iSCSI Bios Firmware Table (iBFT) is a table that is created in
memory which is mapped with the iSCSI card firmware. Thus we can get the session config according to the command iscsiadm.
- how to setup them (basic steps)
software iscsi initiator
- According to the command iscsiadm to setup the available seesion,
and the session info should be passed manually
iSCSI HBA
- Do nothing, except for passing "rd.iscsi.firmware=1" to the
kernel. The iSCSI device will use the config stored in firmware to setup the session.
So assume your patch is for addressing 2), if it is a boot disk there should be rd.iscsi.firmware=1 in /proc/cmdline, but if it is not a boot disk, we need pass this param to second kernel?
Hi, Dave.
Yes. This patch is to solve the situation 2) non-iBFT iSCSI HBA.
What if there's both 2) and 1) existed?
We can inherit this parameter from 1st kernel. Thus we can do nothing to bring up the iSCSI device, either boot device or non-boot device.
I think 1st kernel parameter is only for boot device. non-boot you still need pass extra parameter to 2nd kernel cmdline.
Again about the second question, have you consider the situation both 1 and 2 being used? ie. 1) for crash device, 2) for root device.
I tested both boot and non-boot device as dumping target, and it works on beaker machine.
Thanks Minfei
- iBFT
setup the session.
- Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to the kernel to
I think 1st kernel parameter is only for boot device. non-boot you still need pass extra parameter to 2nd kernel cmdline.
Again about the second question, have you consider the situation both 1 and 2 being used? ie. 1) for crash device, 2) for root device.
I tested both boot and non-boot device as dumping target, and it works on beaker machine.
But how does it work? suppose rd.* param are mandatory, who will pass it to 2nd kernel? Suppose below case: rootfs: a local scsi disk sda after bootup, one can setup a non-boot disk for kdump ie. sdb.
There should be nothing in boot param.
Thanks Dave
On 09/30/15 at 02:37pm, Dave Young wrote:
I think 1st kernel parameter is only for boot device. non-boot you still need pass extra parameter to 2nd kernel cmdline.
Again about the second question, have you consider the situation both 1 and 2 being used? ie. 1) for crash device, 2) for root device.
I tested both boot and non-boot device as dumping target, and it works on beaker machine.
But how does it work? suppose rd.* param are mandatory, who will pass it to 2nd kernel? Suppose below case: rootfs: a local scsi disk sda after bootup, one can setup a non-boot disk for kdump ie. sdb.
There should be nothing in boot param.
Thanks Dave
For iSCSI HBA, the only way to bring up is to append the rd.* in the command. Thus the kernel will export this device.
If there is no proper parameter in command, the device cann't be visible, including 1st kernel.
Thanks Minfei
I do not think it depends on rd. param for non-boot device.
rd.* is for dracut only, it is not kernel params, so dracut will check these param and do some setup. For non-boot device, it is not mandatory for dracut to handle these setup. Since it is userspace scripts, one can setup them after bootup
[offlineimap is slow, thus reply in web mail, sorry for top reply]
----- Original Message ----- From: "Minfei Huang" mhuang@redhat.com To: "Dave Young" dyoung@redhat.com Cc: kexec@lists.fedoraproject.org, bhe@redhat.com Sent: Wednesday, September 30, 2015 2:44:04 PM Subject: Re: [PATCH] dracut-module-setup: Return from iscsi path immediately for hardward iscsi without iBFT
On 09/30/15 at 02:37pm, Dave Young wrote:
I think 1st kernel parameter is only for boot device. non-boot you still need pass extra parameter to 2nd kernel cmdline.
Again about the second question, have you consider the situation both 1 and 2 being used? ie. 1) for crash device, 2) for root device.
I tested both boot and non-boot device as dumping target, and it works on beaker machine.
But how does it work? suppose rd.* param are mandatory, who will pass it to 2nd kernel? Suppose below case: rootfs: a local scsi disk sda after bootup, one can setup a non-boot disk for kdump ie. sdb.
There should be nothing in boot param.
Thanks Dave
For iSCSI HBA, the only way to bring up is to append the rd.* in the command. Thus the kernel will export this device.
If there is no proper parameter in command, the device cann't be visible, including 1st kernel.
Thanks Minfei _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 09/30/15 at 02:47am, Dave Young wrote:
I do not think it depends on rd. param for non-boot device.
rd.* is for dracut only, it is not kernel params, so dracut will check these param and do some setup. For non-boot device, it is not mandatory for dracut to handle these setup. Since it is userspace scripts, one can setup them after bootup
[offlineimap is slow, thus reply in web mail, sorry for top reply]
As my known, the boot device should be exported before loading the dracut code.
Maybe I should test such a case without rd.* to boot from the iSCSI exported device.
Thanks Minfei
----- Original Message ----- From: "Minfei Huang" mhuang@redhat.com To: "Dave Young" dyoung@redhat.com Cc: kexec@lists.fedoraproject.org, bhe@redhat.com Sent: Wednesday, September 30, 2015 2:44:04 PM Subject: Re: [PATCH] dracut-module-setup: Return from iscsi path immediately for hardward iscsi without iBFT
On 09/30/15 at 02:37pm, Dave Young wrote:
I think 1st kernel parameter is only for boot device. non-boot you still need pass extra parameter to 2nd kernel cmdline.
Again about the second question, have you consider the situation both 1 and 2 being used? ie. 1) for crash device, 2) for root device.
I tested both boot and non-boot device as dumping target, and it works on beaker machine.
But how does it work? suppose rd.* param are mandatory, who will pass it to 2nd kernel? Suppose below case: rootfs: a local scsi disk sda after bootup, one can setup a non-boot disk for kdump ie. sdb.
There should be nothing in boot param.
Thanks Dave
For iSCSI HBA, the only way to bring up is to append the rd.* in the command. Thus the kernel will export this device.
If there is no proper parameter in command, the device cann't be visible, including 1st kernel.
Thanks Minfei _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 09/30/15 at 02:47am, Dave Young wrote:
I do not think it depends on rd. param for non-boot device.
rd.* is for dracut only, it is not kernel params, so dracut will check these param and do some setup. For non-boot device, it is not mandatory for dracut to handle these setup. Since it is userspace scripts, one can setup them after bootup
[offlineimap is slow, thus reply in web mail, sorry for top reply]
----- Original Message ----- From: "Minfei Huang" mhuang@redhat.com To: "Dave Young" dyoung@redhat.com Cc: kexec@lists.fedoraproject.org, bhe@redhat.com Sent: Wednesday, September 30, 2015 2:44:04 PM Subject: Re: [PATCH] dracut-module-setup: Return from iscsi path immediately for hardward iscsi without iBFT
On 09/30/15 at 02:37pm, Dave Young wrote:
I think 1st kernel parameter is only for boot device. non-boot you still need pass extra parameter to 2nd kernel cmdline.
Again about the second question, have you consider the situation both 1 and 2 being used? ie. 1) for crash device, 2) for root device.
I tested both boot and non-boot device as dumping target, and it works on beaker machine.
But how does it work? suppose rd.* param are mandatory, who will pass it to 2nd kernel? Suppose below case: rootfs: a local scsi disk sda after bootup, one can setup a non-boot disk for kdump ie. sdb.
There should be nothing in boot param.
Hi.
We needn't to do anything to bring up the iSCSI HBA device, including parameter rd.*.
Following is an example to show the detail. (sdd is non-boot device, and is exported by non-iBFT hardware iSCSI card)
kdump: dump target is /dev/sdd kdump: saving to /kdumproot/mnt//var/crash/127.0.0.1-2015-09-30-17:15:12/ [ 106.146401] EXT4-fs (sdd): re-mounted. Opts: data=ordered kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore Copying data : [100.0 %] - kdump: saving vmcore complete BOOT_IMAGE=/vmlinuz-3.10.0-320.el7.x86_64 root=/dev/mapper/rhel_storageqe--8100-root ro modprobe.blacklist=qla3xxx rd.lvm.lv=rhel_storageqe-8100/root rd.lvm.lv=rhel_storageqe-8100/swap console=ttyS1,115200 LANG=en_US.UTF-8 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug transparent_hugepage=never disable_cpu_apicid=0 elfcorehdr=852380K
Thanks Minfei
For iSCSI HBA, the only way to bring up is to append the rd.* in the command. Thus the kernel will export this device.
If there is no proper parameter in command, the device cann't be visible, including 1st kernel.
-
Dave Young -
Minfei Huang