[Pkg-iscsi-maintainers] Bug#850060: 2.0.874-2~exp1 issues

[Christian Seiler]

On 01/05/2017 07:10 PM, Andrew Patterson wrote:
> On 01/04/2017 04:11 PM, Christian Seiler wrote:
>> OTOH, initramfs should write to /run/initramfs only, so maybe
>> we should pass -p /run/initramfs/iscsiuio.pid to iscsiuio
>> instead as well.
> 
> Yes. I believe that will work. I wonder why this option is not in the
> man-page.

-ENOTIME on part of the developers perhaps. ;-)

>> The ideal solution would be to mirror the check that is done
>> for -b in -N. In that case we'd either configure the host
>> interface (and use software iSCSI), or configure offloading
>> (and use hardware iSCSI), but never both, and never neither.
>> So instead of the current patch for #850057 I would suggest
>> to do that instead. That should then also be upstream-able. I
>> can prepare a patch for that tomorrow.
> 
> That was my thought. However, I don't think you can programaticaly
> determine whether the card is configured for iscsi offload.

Well, according to the commit message I referenced in my
previous email [1], we have the following situation:

 - cxgb*i: always use offloading (which will apparently work,
   since offloading will reuse the MAC address)

 - bnx2*i: look at the MAC address to see if the MAC address
   from iBFT matches the offloading mac: if so, assume
   offloading, if not, assume software

 - otherwise: always assume software

This is what the code bracketed by -DOFFLOAD_BOOT_SUPPORTED
checks for, and we just need to mirror that code (or better:
extract into an own function and call it from both places)
for -b.

I'll prepare a patch, you can then test it.

[1] https://github.com/open-iscsi/open-iscsi/commit/ee115be828362653478e6fe7cd4c6ee3318223ff

> It looks like iscsuio is complaining about a missing libgcc:
> 
> writev(2, [{"libgcc_s.so.1 must be installed "..., 59]], 1) = 59
> 
> which is indeed missing.  I think pthreads needs libgcc, but shouldn't
> copy_exec take care of this?

Nope, since libgcc_s.so is dlopened() by pthread_cancel. So
the automatic library dependency detection doesn't work
properly.

We are not the only ones with that problem; luckily someone
already wrote a patch that does just this for btrfs, we can
just steal that:
https://bugs.debian.org/830883

I'll work on an updated package.

Regards,
Christian