[Pkg-iscsi-maintainers] Bug#804591: Bug#804591: open-iscsi: iscsi_auto flag should use iscsistart --fwparam_network in addition to -b

[Christian Seiler]

Hi,

On 11/09/2015 10:40 PM, Scott Moser wrote:
>>> If we were to invoke 'iscsistart --fwparam_network' after having done
>>> configure_networking, then the iscsi parameters would be in affect.
>>> Its may be arguable that this is simply misconfiguration of the ip=
>>> parameter.
>>
>> On the other hand, one could argue that one might want to overwrite
>> the parameters set in the firmware with an explicit kernel commmand
>> line.
> 
> Agreed.
> 
>> I think the case is definitely clear if iscsi_auto is specified
>> without an ip= parameter, then iscsistart should take care of it.
> 
> Definitely.  Unfortunately, the case that I'm working on is with MAAS
> which specifies a ip= command line to its provided iscsi server.  The
> install environment is then provided over read-only iscsi.

Does the ip= match here or is there some problem with it? If
there's no problem and you are just mentioning it to be
cautious: I think it's fair to ask our users to not
misconfigure their network in initramfs. I mean, without
iscsi_auto and manual iSCSI config a wrong ip=  will also lead
to an unbootable system.

> It seems reasonable that you might have 'ip=' on the kernel command line
> for reasons unrelated to iscsi entirely, and possibly referencing
> different network devices.

Then maybe we should do the following: if iscsi_auto is specified,
call iscsistart -N first, then configure the network regularly.
Then ip= will always override iBFT, but other devices will also
be activated.

>> Btw. is there any way to test this in a VM? I don't have access to
>> the corresponding hardware that sets these values, so I can't
>> really test this myself.
> 
> Luckily, you *can* do it entirely within qemu and ipxe with a few minor
> limitations.  Figuring out how to do that is non-trivial, but I've managed
> my way through it.

Oh great, I don't have time today anymore (I'm in time zone UTC+01,
so it's quite late here ;-)), but I'll take a look at it during
the next few days.

> Right, that was my thought too.  I  might suggest not reading iscsistart
> -f, but rather the files from /sys/firmware/ibft.

The problem there is matching against the right network interface
name - it's certainly possible, but parsing the output of
iscsistart is probably a lot simpler.

> Here is some output
> from each, for those not adventuresome enough to try on their own. Note, i
> added a carriage return to subnet mask that did not have one.

Where exactly did it not have a carriage return? According to
the open-iscsi source, all values printed have \n there
(at least Debian's git snapshot, maybe that was a bug in the
version that was fixed between the version you use and the
version I have).

> [lots of output]

Thanks a lot!

I've created a VERY simple parser in POSIX shell that reads
the input of iscsistart -f and pseudo-creates the /run/net-
file and attached it to this email. If you don't have any
objections to it, I'll integrate that into the initramfs hook.

Regards,
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse_iscsistart.sh
Type: application/x-shellscript
Size: 1572 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-iscsi-maintainers/attachments/20151109/c7650e2d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-iscsi-maintainers/attachments/20151109/c7650e2d/attachment.sig>