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 >
