On 01/05/2017 11:10 AM, Andrew Patterson wrote:
>
> On 01/04/2017 04:11 PM, Christian Seiler wrote:
>> Control: reopen -1
>>
>> Hi,
>> (reopening the bug report since iscsiuio doesn't actually work
>> according to what you're telling me)
>>
>> On 01/04/2017 11:30 PM, Andrew Patterson wrote:
>>> 1. In debian/extra/initramfs.local-top and
>>> debian/extra/initramfs.local-bottom /sbin/iscsuio creates a pid file
>>> in /run/iscsiuio.pid. You cannot override it on the command-line. The
>>> --pidfile option for start-stop-daemon should point to this location
>>> instead of /run/initramfs/iscsiuio.pid.
>>
>> Gah. I thought I had fixed that before the upload. :-(
>> A good thing there's experimental...
>>
>> 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.
>
>>
>>> 2. The /sbin/iscsiuio deamon is trying to create a logfile in
>>> /var/log/iscsiuio.log. The /var/log directory does not exist in the
>>> initramfs.
>>
>> Unfortunately that's hardcoded. OTOH from reading the code
>> this shouldn't be an issue.
>>
>>> 3. The iscsiuio daemon is dieing before or during iscsistart -b. I am
>>> investigating why. It works fine when run after boot.
>>
>> This is weird, on my test VM (no offloading NIC though) it
>> does start (and shut down again).
>>
>> Question: does the network card require firmware for offloading
>> to work? If that's the case we might need to add the firmware
>> to the initramfs or this to work properly...
>
> Yes, the card requires firmware. But it has been loaded (according to
> kernel output).
>
>>
>>> 4. The commit 02c3051 "Don't ignore offloading NICs in iscsistart"
>>> will cause the interface to be configured in both iscsistart -N and in
>>> iscsistart -b for cards with iscsi hardware offload. I suspect we
>>> instead need a flag in iscsistart to bring up the NIC in iscsistart
>>> regardless if the NIC uses an offloadable driver. The local-top script
>>> can use this flag if /sbin/iscsiuio is not present, e.g.,
>>>
>>> ISCSISTART_FLAGS=""
>>> if [ ! -x /sbin/iscsiuio ] ; then
>>> ISCSISTART_FLAGS="-S"
>>> fi
>>
>> Hmm, now I see what you mean. I also dug up this commit which
>> gives a little insight.
>>
>> https://github.com/open-iscsi/open-iscsi/commit/ee115be828362653478e6fe7cd4c6ee3318223ff
>>
>> However, I think the solution is different from what you suggest: the
>> "fix" for #850057 is wrong I believe.
>>
>> Debian sid package (w/o -DOFFLOAD_BOOT_SUPPORTED):
>>
>> - cxgb*i: iscsistart -N ignores interface
>> iscsistart -b doesn't configure offloading
>> => won't work
>>
>> - bnx2i (any mode): iscsistart -N ignores interface
>> iscsistart -b doesn't configure offloading
>> => won't work
>>
>> Current upstream situation (w/ -DOFFLOAD_BOOT_SUPPORTED):
>>
>> - cxgb*i: iscsistart -N ignores interface
>> iscsistart -b configures offloading
>> => should work
>> (but don't have hardware)
>> (also: remind me to check whether we copy the
>> module into the initramfs)
>>
>> - bnx2i non-hba: iscsistart -N ignores it
>> iscsistart -b doesn't configure offloading
>> => won't work
>>
>> - bnx2i hba: iscsistart -N ignores it
>> iscsistart -b configures offloading
>> => should work (once iscsiuio is running)
>>
>> "Fix" for 850057 (in experimental):
>>
>> - cxgb*i: iscsistart -N configures interface on host
>> iscsistart -b configures offloading
>> => no idea what happens thereafter
>> (since MAC address is the same on these cards: is
>> this a problem if they have the same IP?)
>>
>> - bnx2i non-hba: iscsistart -N configures interface
>> iscsistart -b doesn't configure offloading,
>> but enables software iSCSI
>> => should work
>>
>> - bnx2i hba: iscsistart -N configures interface
>> iscsistart -b configures offloading
>> => same IP, different MAC addresses
>> => will cause trouble
>>
>> 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. We need to
> use some sort of signal from the admin, hence my suggestion to check
> for the presence of iscsiuio or to use a flag.
>
>>
>> That still leaves us with the question why iscsiuio doesn't
>> appear to work in the initramfs on your system. You could
>> just add strace to your initramfs and call iscsiuio in a
>> detached strace, a la
>>
>> old:
>> start-stop-daemon ... /sbin/iscsiuio
>>
>> new:
>> start-stop-daemon ... /bin/strace -- -D -f \
>> -o /run/initramfs/iscsiuio.trace -- /sbin/iscsiuio
>>
>> (The first -- is for start-stop-daemon, the second one for
>> strace itself.)
>>
>
> 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?
>
The copy_exec function only copies libraries found with ldd, e.g.,
# ldd /sbin/iscsiuio
linux-vdso.so.1 (0x00007fff868c1000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0de9051000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f0de8e34000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0de8a89000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0de9480000)
The iscsiuio daemon must be dloading libgcc. Here is strace output on
a running system after running iscsistart -b:
4168 msync(0x7effb477e000, 56, MS_SYNC <unfinished ...>
4167 <... mmap resumed> ) = 0x7effb4759000
4168 <... msync resumed> ) = -1 EINVAL (Invalid argument)
4167 close(11 <unfinished ...>
4168 select(9, [8], NULL, NULL, {0, 100} <unfinished ...>
4167 <... close resumed> ) = 0
4167 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4167 open("/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 11
4168 <... select resumed> ) = 0 (Timeout)
4167 read(11, <unfinished ...>
4168 select(9, [8], NULL, NULL, {0, 100} <unfinished ...>
Is there a supported way to copy this library and its dependencies over?
Andrew
--
Andrew Patterson
Hewlett-Packard Enterprise
