[PATCH] dracut-module-setup: Mute the error message when kdump detects iSCSI session by iscsiadm

[Minfei Huang]

For independent hardware iSCSI HBA, the network config will be recorded
in the firmware BIOS. It fails to use normal means(like iscsiadm) to
detect iSCSI session details, since HBA firmware doesn't expose the
session to running kernel.

Mute the error message when kdump detects iSCSI session by iscsiadm.

Signed-off-by: Minfei Huang <mhuang(a)redhat.com&gt;
---
 dracut-module-setup.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index 9b398eb..1736315 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -512,9 +512,9 @@ kdump_setup_iscsi_device() {
     # 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
+    if ! /sbin/iscsiadm -m session -r ${path} 2>&- > /dev/null ; then
+        # Yes, it is hardware iscsi HBA.
+        return
     fi
 
     tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
-- 
2.1.0

[Dave Young]

Ccing Chris Leech who is maintaining the iscsi tools

Chris, kdump lacks hardware iscsi support for long time. One reason is we
kdump developer has no enough knowledge about it.

We have software initiator support, we call it software iscsi. As for hardware
iscsi, Minfei is working on it and find that there are independent hw iscsi
and dependent hw iscsi (ibft?). For independent hw iscsi it just works without
any fixes in kdump code, there's just an error message from iscsiadm. This patch
is for mute it.

For ibft, I think Minfei is still working on it.

Could you help to review, if our understanding is right? Anything else we missed.

Thanks
Dave

On 10/13/15 at 01:17pm, Minfei Huang wrote:
>  For independent hardware iSCSI HBA, the network config will be
> recorded
>  in the firmware BIOS. It fails to use normal means(like iscsiadm) to
>  detect iSCSI session details, since HBA firmware doesn't expose the
>  session to running kernel.
>  
>  Mute the error message when kdump detects iSCSI session by iscsiadm.
>  
>  Signed-off-by: Minfei Huang <mhuang(a)redhat.com&gt;
>  ---
>   dracut-module-setup.sh | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>  
>  diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  index 9b398eb..1736315 100755
>  --- a/dracut-module-setup.sh
>  +++ b/dracut-module-setup.sh
>  @@ -512,9 +512,9 @@ kdump_setup_iscsi_device() {
>       # 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
>  +    if ! /sbin/iscsiadm -m session -r ${path} 2>&- > /dev/null ; then
>  +        # Yes, it is hardware iscsi HBA.
>  +        return
>       fi
>   
>       tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>  -- 
>  2.1.0
>  
>  _______________________________________________
>  kexec mailing list
>  kexec(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/mailman/listinfo/kexec
>  
>

[Chris Leech]

On Mon, Oct 19, 2015 at 10:28:59AM +0800, Dave Young wrote:
>  Ccing Chris Leech who is maintaining the iscsi tools
>  
>  Chris, kdump lacks hardware iscsi support for long time. One reason is we
>  kdump developer has no enough knowledge about it.
>  
>  We have software initiator support, we call it software iscsi. As for hardware
>  iscsi, Minfei is working on it and find that there are independent hw iscsi
>  and dependent hw iscsi (ibft?). For independent hw iscsi it just works without
>  any fixes in kdump code, there's just an error message from iscsiadm. This patch
>  is for mute it.
>  
>  For ibft, I think Minfei is still working on it.
>  
>  Could you help to review, if our understanding is right? Anything else we missed. 
I'll try and take a look.

I think your dependent/independent hw differentiation may actually be
about the required setup?  Mostly the bnx2i driver needs to have a
network interface up, and has an additional iscsiuio user space driver
that works with iscsid.

iBFT is somewhat orthogonal, it's an ACPI table to pass iSCSI
configuration from the boot firmware to the OS.  iBFT is used with
non-offloading boot firmware and the iscsi_tcp driver, it's also used by
some offloading devices including bnx2i.

- Chris

>  
>  Thanks
>  Dave
>  
>  On 10/13/15 at 01:17pm, Minfei Huang wrote:
>  > For independent hardware iSCSI HBA, the network config will be recorded
>  > in the firmware BIOS. It fails to use normal means(like iscsiadm) to
>  > detect iSCSI session details, since HBA firmware doesn't expose the
>  > session to running kernel.
>  > 
>  > Mute the error message when kdump detects iSCSI session by iscsiadm.
>  > 
>  > Signed-off-by: Minfei Huang <mhuang(a)redhat.com&gt;
>  > ---
>  >  dracut-module-setup.sh | 6 +++---
>  >  1 file changed, 3 insertions(+), 3 deletions(-)
>  > 
>  > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  > index 9b398eb..1736315 100755
>  > --- a/dracut-module-setup.sh
>  > +++ b/dracut-module-setup.sh
>  > @@ -512,9 +512,9 @@ kdump_setup_iscsi_device() {
>  >      # 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
>  > +    if ! /sbin/iscsiadm -m session -r ${path} 2>&- > /dev/null ; then
>  > +        # Yes, it is hardware iscsi HBA.
>  > +        return
>  >      fi
>  >  
>  >      tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>  > -- 
>  > 2.1.0
>  > 
>  > _______________________________________________
>  > kexec mailing list
>  > kexec(a)lists.fedoraproject.org
>  > https://lists.fedoraproject.org/mailman/listinfo/kexec
>  > 
>  >

[Minfei Huang]

On 10/21/15 at 05:03pm, Chris Leech wrote:
>  On Mon, Oct 19, 2015 at 10:28:59AM +0800, Dave Young wrote:
>  > Ccing Chris Leech who is maintaining the iscsi tools
>  > 
>  > Chris, kdump lacks hardware iscsi support for long time. One reason is we
>  > kdump developer has no enough knowledge about it.
>  > 
>  > We have software initiator support, we call it software iscsi. As for hardware
>  > iscsi, Minfei is working on it and find that there are independent hw iscsi
>  > and dependent hw iscsi (ibft?). For independent hw iscsi it just works without
>  > any fixes in kdump code, there's just an error message from iscsiadm. This
> patch
>  > is for mute it.
>  > 
>  > For ibft, I think Minfei is still working on it.
>  > 
>  > Could you help to review, if our understanding is right? Anything else we missed.
>  
>  I'll try and take a look.
>  
>  I think your dependent/independent hw differentiation may actually be
>  about the required setup?  Mostly the bnx2i driver needs to have a
>  network interface up, and has an additional iscsiuio user space driver
>  that works with iscsid.
>  
>  iBFT is somewhat orthogonal, it's an ACPI table to pass iSCSI
>  configuration from the boot firmware to the OS.  iBFT is used with
>  non-offloading boot firmware and the iscsi_tcp driver, it's also used by
>  some offloading devices including bnx2i.
>  
>  - Chris 
Thanks Chris for your help.

I found this issue, when I tested the hardware iSCSI HBA which is the
iBFT loaded bnx2i module. Following is details.

 # iscsiadm -m session -P 1
Target: iqn.1992-04.com.emc:cx.fcn00122500421.a5 (non-flash)
    Current Portal: $_ip_:48140,6
    Persistent Portal: $_ip_:3260,6
        **********
        Interface:
        **********
        Iface Name: bnx2i.00:0a:f7:1e:6f:99
        Iface Transport: bnx2i
        Iface Initiatorname: $_iqn_
        Iface IPaddress: $_ip_
        Iface HWaddress: 00:0a:f7:1e:6f:99
        Iface Netdev: ens2f0
        SID: 1
        iSCSI Connection State: LOGGED IN
        iSCSI Session State: LOGGED_IN
        Internal iscsid Session State: NO CHANGE

        **********
        Interface:
        **********
        Iface Name: bnx2i.00:0a:f7:1e:6f:9b
        Iface Transport: bnx2i
        Iface Initiatorname: $_iqn_
        Iface IPaddress: 172.17.99.137
        Iface HWaddress: 00:0a:f7:1e:6f:9b
        Iface Netdev: ens2f1
        SID: 2
        iSCSI Connection State: LOGGED IN
        iSCSI Session State: LOGGED_IN
        Internal iscsid Session State: NO CHANGE

 # ls /sys/firmware/
acpi  dmi  ibft  memmap

 # ls /sys/devices/pci0000:00/0000:00:03.2/0000:0b:00.0/host6/session1
connection1:0  iscsi_session  power  target6:0:0  uevent

 # iscsiadm -m session -r
/sys/devices/pci0000:00/0000:00:03.2/0000:0b:00.0/host6/session1
iscsiadm: No records found

Under the session directory, we also find the iscsi_session directory is
existence. In kdump code, it represents that we can use command "iscsiadm"
to get session details. But it fails to get it.

So this patch tries to mute the error message, once kdump met the failure
of iscsiadm.

Thanks
Minfei

>  
>  > 
>  > Thanks
>  > Dave
>  > 
>  > On 10/13/15 at 01:17pm, Minfei Huang wrote:
>  > > For independent hardware iSCSI HBA, the network config will be recorded
>  > > in the firmware BIOS. It fails to use normal means(like iscsiadm) to
>  > > detect iSCSI session details, since HBA firmware doesn't expose the
>  > > session to running kernel.
>  > > 
>  > > Mute the error message when kdump detects iSCSI session by iscsiadm.
>  > > 
>  > > Signed-off-by: Minfei Huang <mhuang(a)redhat.com&gt;
>  > > ---
>  > >  dracut-module-setup.sh | 6 +++---
>  > >  1 file changed, 3 insertions(+), 3 deletions(-)
>  > > 
>  > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  > > index 9b398eb..1736315 100755
>  > > --- a/dracut-module-setup.sh
>  > > +++ b/dracut-module-setup.sh
>  > > @@ -512,9 +512,9 @@ kdump_setup_iscsi_device() {
>  > >      # 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
>  > > +    if ! /sbin/iscsiadm -m session -r ${path} 2>&- > /dev/null ;
> then
>  > > +        # Yes, it is hardware iscsi HBA.
>  > > +        return
>  > >      fi
>  > >  
>  > >      tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>  > > -- 
>  > > 2.1.0
>  > > 
>  > > _______________________________________________
>  > > kexec mailing list
>  > > kexec(a)lists.fedoraproject.org
>  > > https://lists.fedoraproject.org/mailman/listinfo/kexec
>  > > 
>  > >

[Dave Young]

Hi, Chris

Sorry for late reply.

On 10/21/15 at 05:03pm, Chris Leech wrote:
>  On Mon, Oct 19, 2015 at 10:28:59AM +0800, Dave Young wrote:
>  > Ccing Chris Leech who is maintaining the iscsi tools
>  > 
>  > Chris, kdump lacks hardware iscsi support for long time. One reason is we
>  > kdump developer has no enough knowledge about it.
>  > 
>  > We have software initiator support, we call it software iscsi. As for hardware
>  > iscsi, Minfei is working on it and find that there are independent hw iscsi
>  > and dependent hw iscsi (ibft?). For independent hw iscsi it just works without
>  > any fixes in kdump code, there's just an error message from iscsiadm. This
> patch
>  > is for mute it.
>  > 
>  > For ibft, I think Minfei is still working on it.
>  > 
>  > Could you help to review, if our understanding is right? Anything else we missed.
>  
>  I'll try and take a look.
>  
>  I think your dependent/independent hw differentiation may actually be
>  about the required setup?  Mostly the bnx2i driver needs to have a 
I have zero knowledge about these keywords, I think Minfei got them from
some VMware website, I guess it is about if it need OS setup or not.

>  network interface up, and has an additional iscsiuio user space
> driver
>  that works with iscsid.
>  
>  iBFT is somewhat orthogonal, it's an ACPI table to pass iSCSI
>  configuration from the boot firmware to the OS.  iBFT is used with
>  non-offloading boot firmware and the iscsi_tcp driver, it's also used by
>  some offloading devices including bnx2i. 
Thanks for the explanation about above, it is helpful to us.

I think this patch is for gracefully skip the error message of iscsiadm

But iscsiadm should have other error path, so IMO we should not regard it
as a no-setup-needed hardware iscsi device just because iscsiadm fails to
find the session infomation.

Do you have idea how to diffrenciate those no-setup-needed hardware iscsi
devices?

Thanks
Dave

>  
>  - Chris
>  
>  > 
>  > Thanks
>  > Dave
>  > 
>  > On 10/13/15 at 01:17pm, Minfei Huang wrote:
>  > > For independent hardware iSCSI HBA, the network config will be recorded
>  > > in the firmware BIOS. It fails to use normal means(like iscsiadm) to
>  > > detect iSCSI session details, since HBA firmware doesn't expose the
>  > > session to running kernel.
>  > > 
>  > > Mute the error message when kdump detects iSCSI session by iscsiadm.
>  > > 
>  > > Signed-off-by: Minfei Huang <mhuang(a)redhat.com&gt;
>  > > ---
>  > >  dracut-module-setup.sh | 6 +++---
>  > >  1 file changed, 3 insertions(+), 3 deletions(-)
>  > > 
>  > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  > > index 9b398eb..1736315 100755
>  > > --- a/dracut-module-setup.sh
>  > > +++ b/dracut-module-setup.sh
>  > > @@ -512,9 +512,9 @@ kdump_setup_iscsi_device() {
>  > >      # 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
>  > > +    if ! /sbin/iscsiadm -m session -r ${path} 2>&- > /dev/null ;
> then
>  > > +        # Yes, it is hardware iscsi HBA.
>  > > +        return
>  > >      fi
>  > >  
>  > >      tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>  > > -- 
>  > > 2.1.0
>  > > 
>  > > _______________________________________________
>  > > kexec mailing list
>  > > kexec(a)lists.fedoraproject.org
>  > > https://lists.fedoraproject.org/mailman/listinfo/kexec
>  > > 
>  > >

[Minfei Huang]

On 10/21/15 at 05:03pm, Chris Leech wrote:
>  On Mon, Oct 19, 2015 at 10:28:59AM +0800, Dave Young wrote:
>  > Ccing Chris Leech who is maintaining the iscsi tools
>  > 
>  > Chris, kdump lacks hardware iscsi support for long time. One reason is we
>  > kdump developer has no enough knowledge about it.
>  > 
>  > We have software initiator support, we call it software iscsi. As for hardware
>  > iscsi, Minfei is working on it and find that there are independent hw iscsi
>  > and dependent hw iscsi (ibft?). For independent hw iscsi it just works without
>  > any fixes in kdump code, there's just an error message from iscsiadm. This
> patch
>  > is for mute it.
>  > 
>  > For ibft, I think Minfei is still working on it.
>  > 
>  > Could you help to review, if our understanding is right? Anything else we missed.
>  
>  I'll try and take a look.
>  
>  I think your dependent/independent hw differentiation may actually be
>  about the required setup?  Mostly the bnx2i driver needs to have a 
Hi, Chris.

I think so. it is likely to be called a dependent hardware, if network
is necessary to bring up iSCSI device. Otherwise we don't do anything to
bring up iSCSI device, it is called an independent hardware.


>  network interface up, and has an additional iscsiuio user space
> driver
>  that works with iscsid. 
Yes. From my testing, I found that some be2iscsi cards also need
connected network.

>  
>  iBFT is somewhat orthogonal, it's an ACPI table to pass iSCSI
>  configuration from the boot firmware to the OS.  iBFT is used with
>  non-offloading boot firmware and the iscsi_tcp driver, it's also used by
>  some offloading devices including bnx2i. 
Thanks for your kind explanation.

Thanks
Minfei

>  > On 10/13/15 at 01:17pm, Minfei Huang wrote:
>  > > For independent hardware iSCSI HBA, the network config will be recorded
>  > > in the firmware BIOS. It fails to use normal means(like iscsiadm) to
>  > > detect iSCSI session details, since HBA firmware doesn't expose the
>  > > session to running kernel.
>  > > 
>  > > Mute the error message when kdump detects iSCSI session by iscsiadm.
>  > > 
>  > > Signed-off-by: Minfei Huang <mhuang(a)redhat.com&gt;
>  > > ---
>  > >  dracut-module-setup.sh | 6 +++---
>  > >  1 file changed, 3 insertions(+), 3 deletions(-)
>  > > 
>  > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
>  > > index 9b398eb..1736315 100755
>  > > --- a/dracut-module-setup.sh
>  > > +++ b/dracut-module-setup.sh
>  > > @@ -512,9 +512,9 @@ kdump_setup_iscsi_device() {
>  > >      # 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
>  > > +    if ! /sbin/iscsiadm -m session -r ${path} 2>&- > /dev/null ;
> then
>  > > +        # Yes, it is hardware iscsi HBA.
>  > > +        return
>  > >      fi
>  > >  
>  > >      tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")

[Dave Young]

Minfei,
ping. Any update on this?

We should find a proper way to diffrenciate hwiscsi cases with or without OS
setup needed.

Thanks
Dave

On 10/29/15 at 11:26am, Minfei Huang wrote:
> On 10/21/15 at 05:03pm, Chris Leech wrote:
> > On Mon, Oct 19, 2015 at 10:28:59AM +0800, Dave Young wrote:
> > > Ccing Chris Leech who is maintaining the iscsi tools
> > > 
> > > Chris, kdump lacks hardware iscsi support for long time. One reason is we
> > > kdump developer has no enough knowledge about it.
> > > 
> > > We have software initiator support, we call it software iscsi. As for
hardware
> > > iscsi, Minfei is working on it and find that there are independent hw
iscsi
> > > and dependent hw iscsi (ibft?). For independent hw iscsi it just works
without
> > > any fixes in kdump code, there's just an error message from iscsiadm.
This patch
> > > is for mute it.
> > > 
> > > For ibft, I think Minfei is still working on it.
> > > 
> > > Could you help to review, if our understanding is right? Anything else we
missed.
> > 
> > I'll try and take a look.
> > 
> > I think your dependent/independent hw differentiation may actually be
> > about the required setup?  Mostly the bnx2i driver needs to have a
> 
> Hi, Chris.
> 
> I think so. it is likely to be called a dependent hardware, if network
> is necessary to bring up iSCSI device. Otherwise we don't do anything to
> bring up iSCSI device, it is called an independent hardware.
> 
> 
> > network interface up, and has an additional iscsiuio user space driver
> > that works with iscsid.
> 
> Yes. From my testing, I found that some be2iscsi cards also need
> connected network.
> 
> > 
> > iBFT is somewhat orthogonal, it's an ACPI table to pass iSCSI
> > configuration from the boot firmware to the OS.  iBFT is used with
> > non-offloading boot firmware and the iscsi_tcp driver, it's also used by
> > some offloading devices including bnx2i.
> 
> Thanks for your kind explanation.
> 
> Thanks
> Minfei
> 
> > > On 10/13/15 at 01:17pm, Minfei Huang wrote:
> > > > For independent hardware iSCSI HBA, the network config will be
recorded
> > > > in the firmware BIOS. It fails to use normal means(like iscsiadm) to
> > > > detect iSCSI session details, since HBA firmware doesn't expose
the
> > > > session to running kernel.
> > > > 
> > > > Mute the error message when kdump detects iSCSI session by iscsiadm.
> > > > 
> > > > Signed-off-by: Minfei Huang <mhuang(a)redhat.com&gt;
> > > > ---
> > > >  dracut-module-setup.sh | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > > > index 9b398eb..1736315 100755
> > > > --- a/dracut-module-setup.sh
> > > > +++ b/dracut-module-setup.sh
> > > > @@ -512,9 +512,9 @@ kdump_setup_iscsi_device() {
> > > >      # 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
> > > > +    if ! /sbin/iscsiadm -m session -r ${path} 2>&- >
/dev/null ; then
> > > > +        # Yes, it is hardware iscsi HBA.
> > > > +        return
> > > >      fi
> > > >  
> > > >      tgt_name=$(kdump_iscsi_get_rec_val ${path}
"node.name")
> _______________________________________________
> kexec mailing list
> kexec(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/kexec
> 
>

[Minfei Huang]

On 12/04/15 at 05:33pm, Dave Young wrote:
>  Minfei,
>  ping. Any update on this?
>  
>  We should find a proper way to diffrenciate hwiscsi cases with or without OS
>  setup needed. 
Hi, Dave.

I will ask local Storage-qe for help to address this issue. If my patch
works for them, I would like to update version 2 to add the return test.

Thanks
Minfei
> 
> On 10/29/15 at 11:26am, Minfei Huang wrote:
> > On 10/21/15 at 05:03pm, Chris Leech wrote:
> > > On Mon, Oct 19, 2015 at 10:28:59AM +0800, Dave Young wrote:
> > > > Ccing Chris Leech who is maintaining the iscsi tools
> > > > 
> > > > Chris, kdump lacks hardware iscsi support for long time. One reason is
we
> > > > kdump developer has no enough knowledge about it.
> > > > 
> > > > We have software initiator support, we call it software iscsi. As for
hardware
> > > > iscsi, Minfei is working on it and find that there are independent hw
iscsi
> > > > and dependent hw iscsi (ibft?). For independent hw iscsi it just works
without
> > > > any fixes in kdump code, there's just an error message from
iscsiadm. This patch
> > > > is for mute it.
> > > > 
> > > > For ibft, I think Minfei is still working on it.
> > > > 
> > > > Could you help to review, if our understanding is right? Anything else
we missed.
> > > 
> > > I'll try and take a look.
> > > 
> > > I think your dependent/independent hw differentiation may actually be
> > > about the required setup?  Mostly the bnx2i driver needs to have a
> > 
> > Hi, Chris.
> > 
> > I think so. it is likely to be called a dependent hardware, if network
> > is necessary to bring up iSCSI device. Otherwise we don't do anything to
> > bring up iSCSI device, it is called an independent hardware.
> > 
> > 
> > > network interface up, and has an additional iscsiuio user space driver
> > > that works with iscsid.
> > 
> > Yes. From my testing, I found that some be2iscsi cards also need
> > connected network.
> > 
> > > 
> > > iBFT is somewhat orthogonal, it's an ACPI table to pass iSCSI
> > > configuration from the boot firmware to the OS.  iBFT is used with
> > > non-offloading boot firmware and the iscsi_tcp driver, it's also used
by
> > > some offloading devices including bnx2i.
> > 
> > Thanks for your kind explanation.
> > 
> > Thanks
> > Minfei
> > 
> > > > On 10/13/15 at 01:17pm, Minfei Huang wrote:
> > > > > For independent hardware iSCSI HBA, the network config will be
recorded
> > > > > in the firmware BIOS. It fails to use normal means(like iscsiadm)
to
> > > > > detect iSCSI session details, since HBA firmware doesn't
expose the
> > > > > session to running kernel.
> > > > > 
> > > > > Mute the error message when kdump detects iSCSI session by
iscsiadm.
> > > > > 
> > > > > Signed-off-by: Minfei Huang <mhuang(a)redhat.com&gt;
> > > > > ---
> > > > >  dracut-module-setup.sh | 6 +++---
> > > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > > > > index 9b398eb..1736315 100755
> > > > > --- a/dracut-module-setup.sh
> > > > > +++ b/dracut-module-setup.sh
> > > > > @@ -512,9 +512,9 @@ kdump_setup_iscsi_device() {
> > > > >      # 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
> > > > > +    if ! /sbin/iscsiadm -m session -r ${path} 2>&- >
/dev/null ; then
> > > > > +        # Yes, it is hardware iscsi HBA.
> > > > > +        return
> > > > >      fi
> > > > >  
> > > > >      tgt_name=$(kdump_iscsi_get_rec_val ${path}
"node.name")
> > _______________________________________________
> > kexec mailing list
> > kexec(a)lists.fedoraproject.org
> > https://lists.fedoraproject.org/mailman/listinfo/kexec
> > 
> >