iscsi_auto flag should use --fwparam_network in addition to -b

[David Britton]

Right now, the following logic is used if you pass iscsi_auto as a kernel option:

modprobe iscsi_ibft
iscsistart -b

However, in a PXE boot environment, the interface initialized will be something like the "primary" interface of the system, probably not where your iscsi traffic is running.

The '-N' flag of iscsistart should also be used to configure the networking before attempting to create a session to the target.

so:

modprobe iscsi_ibft
iscsistart -N
iscsistart -b

This change should go into the scripts/local-top/iscsi script. I'll attach a patch. Note that this code path is not traversed unless you are booting the kernel with iscsi_auto. Also if you boot the kernel this way and you do not have IBFT in your ethernet adapter, you will already fall into an (initramfs) prompt as iscsistart -b will fail.

The only consideration is if the IBFT does not have correct networking information in it, which should be a configuration error.

[David Britton (dpb)]

Patch for /usr/share/initramfs-tools/scripts/local-top/iscsi

[David Britton (dpb)]

Alternatively an even safer approach might be:

iscsistart -N || /bin/true
iscsistart -b

[Scott Moser (smoser)]

This seems sane, my one concern is when the device attached with 'iscsistart -b' ends up being the root device.
In the other iscsi path (iscsi_target_name=.... iscsi_target_ip=... iscsi_target_port=... and 'ip=..') the 'ip' command writes the configured network information into /run/net-eth0.conf and then open-iscis's initramfs script writes 'eth0' to /run/initramfs/open-iscsi.interface . That instructs open-iscsi's "net-interface-handler" to fake the configuring of 'eth0' without bringing it down.

So, in the iscsistart -N path we need some way to convince ifup that the interface is up. If the interface up code thinks it fails to bring the network up (because its already up, or possibly even had different config), then the network-online.target (static-networking-up in trusty) might not fire, causing things that depend on it to not run.

Second thing I'm not sure of, is how interface names are kept consistent between initramfs and post-initramfs. Ie, if iscsistart -N brings up the interface 'eth0', but /etc/network/interfaces and udev rules have set that to be named 'eth1', I'm not what would happen.

Third thing, is if there was any networking needed beyond the things that iscsistart could configure (vlan or bonding or additional routes in the configured system for that interface) then I'm not sure if they'd get applied.

[David Britton (dpb)]

New patch, with -N and -b unbundled. Sorry, I thought I tested that fully but I did not. My tests were all with -N and -b on separate lines.

[Scott Moser (smoser)]

Fourth issue, applies to SRU also.
Currently, to get auto iscsi to work, you had to pass 'iscsi_auto'' and 'ip=' flags to the initramfs.
The suggested change would have a problem in the following scenario:
 a.) ip= provides correct / desired networking to bring up device 'eth0' (ip=::::eth0)
 b.) iscsi_auto is provided and the iBFT config also provides configuration for eth0 but provides *different* config.

Currently, 'ip=' config would get set. With the provided patch, I'm not sure if the iBFT data configuration would get applied or not. If iscsistart -N would *deconfigure* the ip= device, then that would break a user. If iscsistart -N says "oh, device is configured already, do nothing", then we'd be OK.

[Scott Moser (smoser)]

I'm marking this fix-released. Per the debian bug, this should be in any open-icsi >= 2.0.873+git0.3b4b4500-13