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

[Scott Moser]

On Mon, 9 Nov 2015, Christian Seiler wrote:

> 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.

in the specific case, the ip= was for eth0 and 2 other nics would be
configured per the iBFT.  I was just listing it as an example of where you
would possibly have ip= *and* want iscsistart --fwparam_network.

> > 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).

the /sys interface did not have a subnet mask.
 ie, /sys/firmware/ibft/ethernet0/subnet-mask had no trailing carriage
return.
>
> 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.

it seems to look fine.
reading from /sys isnt terribly hard, though. the mapping of nic name from
ibft to current linux nic name is easily enough made through:
 /sys/class/net/<name>/address == /sys/firmware/ibft/ethernet0/mac

your parser seems fine, and only incurs one subshell, so that is nice.

>
> Regards,
> Christian
>