Bug 1225984

Created attachment 1031343 [details]
content of /sys/firmware/ibft/

This looks like an issue in dracut in converting ibft entries into network configuration entries in the modified command line.  A vlan device is created, but the IP configuration is tagged to the physical interface.

Actually I'll take this back, I'm so used to relying on dracut to do the network configuration for boot that I ignored the fact that iscsistart does have code to do this - and it doesn't handle VLANs.  There may additionally be a dracut issue.

I don't think this qualifies as a blocker, I'm not sure why it would be needed to verify bz 1111358.

Using iscsistart to configure the networking directly is problematic, as there's no proper handover to NetworkManager after booting.  Dracut provides it's own iBFT parsing and network configuration code, it does not use iscsistart for that.

Jan, can you confirm why you think this is blocking testing of dracut?

It is needed, because dracut does run "iscsistart -N", see modules.d/95iscsi/iscsiroot (dracut-004-386.el6)

Adding Harald to CC for additional comments.

(In reply to Jan Stodola from comment #6)
> It is needed, because dracut does run "iscsistart -N", see
> modules.d/95iscsi/iscsiroot (dracut-004-386.el6)
> 
> Adding Harald to CC for additional comments.

Thanks, I missed that change in the el6 code.  I'm not sure what it's doing there.

I can change iscsistart to match on vlan devices.  It's simpler if we require that the vlan device should already exist, but it could also create vlans.  There are some paths that match by MAC address where supporting vlans won't happen without additional work, like binding an iface record by MAC.

I have a patch to iscsistart to deal with this, it seems to work for the described test configuration at least.  It follow what I said in comment 7; it only configures vlan devices that already exists, and I believe there to be additional work to deal with things link binding an iface to hwaddress + vlan.

Although changing the dracut iscsi module to not call iscsistart -N works as well, the changes for bug 1111358 work fine if iscsistart -N isn't called at all resulting in changes to the routing table.

Created attachment 1037895 [details]
fix iscsistart -N when the iBFT includes a vlan tag

Chris, thanks for the packages, here are my results:

First of all, it will be possible to verify bug 1111358 with those changes, since booting from iSCSI using iBFT + VLAN works fine.

I tried to run "iscsistart -N" in the following 4 cases:

1) iBFT with no VLAN configured:
   It works as expected, the ibft0 device is configured according to the settings in iBFT.

2) iBFT + VLAN, the vlan device doesn't exist yet:
   It works as expected, the settings in iBFT are not applied to the base device.

3) iBFT + VLAN, the vlan device exists, but the base device is down:
   iscsistart complains that network is down and fails to configure the vlan interface:

   initqueue:/# ip a
   1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   2: ibft0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
   link/ether 52:54:00:ce:b4:64 brd ff:ff:ff:ff:ff:ff

   initqueue:/# ip link add link ibft0 name ibft0.1234 type vlan id 1234
   802.1Q VLAN Support v1.8 Ben Greear <greearb>
   All bugs added by David S. Miller <davem>

   initqueue:/# ip a
   1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   2: ibft0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
       link/ether 52:54:00:ce:b4:64 brd ff:ff:ff:ff:ff:ff
   3: ibft0.1234@ibft0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN 
       link/ether 52:54:00:ce:b4:64 brd ff:ff:ff:ff:ff:ff

   initqueue:/# iscsistart -N
   iscsistart: Could not bring up netdev ibft0.1234 (err 100 - Network is down)

   initqueue:/# ip a
   1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   2: ibft0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
       link/ether 52:54:00:ce:b4:64 brd ff:ff:ff:ff:ff:ff
   3: ibft0.1234@ibft0: <BROADCAST,M-DOWN> mtu 1500 qdisc noop state DOWN 
       link/ether 52:54:00:ce:b4:64 brd ff:ff:ff:ff:ff:ff
   initqueue:/#

4) iBFT + VLAN, the vlan device exists and the base device is up:
   it works as expected:

   initqueue:/# ip link add link ibft0 name ibft0.1234 type vlan id 1234
   initqueue:/# ip link set dev ibft0 up
   initqueue:/# iscsistart -N
   initqueue:/# ip a
   1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   2: ibft0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
       link/ether 52:54:00:ce:b4:64 brd ff:ff:ff:ff:ff:ff
   3: ibft0.1234@ibft0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
       link/ether 52:54:00:ce:b4:64 brd ff:ff:ff:ff:ff:ff
       inet 192.168.222.12/24 brd 192.168.222.255 scope global ibft0.1234


So, only the case 3) didn't work as I expected.
Chris, is it intentional not to bring up the base device in case 3 and do not configure the vlan interface?

Created attachment 1040182 [details]
fix iscsistart -N when the iBFT includes a vlan tag

v2: bring physical interface up as well as vlan

(In reply to Jan Stodola from comment #17)
> So, only the case 3) didn't work as I expected.
> Chris, is it intentional not to bring up the base device in case 3 and do
> not configure the vlan interface?

Not intentional, I was just aiming for the minimum vlan support to unblock the current dracut use case.  I've updated the patch to bring up the physical interface as well as the vlan.  Updated test RPMs in the same place as before, alongside the first set with version vlan.2

Retested with iscsi-initiator-utils-6.2.0.873-15.vlan.2.el6, all cases mentioned in comment 17 work as expected.

Tested iscsi-initiator-utils-6.2.0.873-15.vlan.2.el6 in our regression test and it worked well.

We are going to move this to 6.8, because we do not want to add risk this late in the release cycle (i.e., the RC build). 

This BZ should enable the Dracut BZ to pass QE testing: 

Bug 1111358 - Add support for iscsiboot with VLAN configured in ibft

(The code for that is already in 6.7.)

This, in turn, should allow Anaconda to add support for this feature:

Bug 831002 - Add support for iscsiboot with VLAN configured in ibft

Hi Jan,
could You please test this?
I'm running regression tests now.

I've retested the cases from comment 17, using iscsi-initiator-utils-6.2.0.873-15.el6, in a virtual machine.
All cases seem to work as I expect:

1) iBFT with no VLAN:
   The settings from iBFT are applied to the device and the device is brought up in case it was down before.

2) iBFT + VLAN, the vlan device doesn't exist:
   The iBFT settings are not applied to the base device and iscsistart warns that no matching vlan device was found.

3) iBFT + VLAN, the vlan device exists, but the base device is down:
   The iBFT settings are applied to the VLAN interface and both the base and the VLAN interfaces are brought up. 

4) iBFT + VLAN, the vlan device exists and the base device is up:
   The iBFT settings are applied to the VLAN interface and the device remains up

(In reply to Jan Stodola from comment #28)
Thanks Jan for testing this.
Regression tests did not found any new issue.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0833.html