Bug 533495 - [LTC 6.0 FEAT] 201085:cio_ignore - add wait to s-c-network
[LTC 6.0 FEAT] 201085:cio_ignore - add wait to s-c-network
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: system-config-network (Show other bugs)
6.0
s390x All
high Severity high
: rc
: 6.0
Assigned To: Harald Hoyer
desktop-bugs@redhat.com
: FutureFeature, Reopened
Depends On: 463544
Blocks: 554559 626825
  Show dependency treegraph
 
Reported: 2009-11-06 16:28 EST by Denise Dumas
Modified: 2010-09-08 20:13 EDT (History)
17 users (show)

See Also:
Fixed In Version: system-config-network-1.6.0-1
Doc Type: Enhancement
Doc Text:
If the qeth interface was previously configured using system-config-network 1.6.0.el6.2, the "OPTIONS=" line needs to be manually added to /etc/sysconfig/network-scripts/ifcfg-<interface>. After the configuration has been manually changed, activate the interface by either rebooting the system, or running the following commands: # /sbin/znet_cio_free # SUBSYSTEM="ccw" DEVPATH="bus/ccw/devices/<SUBCHANNEL 0>" /lib/udev/ccw_init # ifup <interface>
Story Points: ---
Clone Of: 463544
: 626825 (view as bug list)
Environment:
Last Closed: 2010-08-24 10:13:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch (11.67 KB, patch)
2010-08-24 09:55 EDT, Harald Hoyer
no flags Details | Diff

  None (edit)
Comment 1 Denise Dumas 2009-11-06 16:30:52 EST
This BZ tracks the following portion of the original request:

> - Patch device configuration tools (at this moment only system-config-network)
> to:
>    Unmask and wait for appearance of devices as needed during user-interactive
> configuration

This needs to be filed against the appropriate configuration tool, not
anaconda.
Comment 2 Steffen Maier 2009-11-07 09:48:24 EST
Please see anaconda's loader/linuxrc.s390:semantic_check_subchannels on how to treat s390 network subchannels for cio_ignore.
But then again, does s-c-n even dynamically configure s390 network devices or does it just write ifcfg files and tries to ifup, which fails if the ccwgroup has not been established and set online before? I could not find anything that triggers udev or calls /lib/udev/ccw_init to do the hardware setup for s390 network devices.
Comment 3 Phil Knirsch 2009-11-12 10:43:34 EST
Traditionally s-c-n didn't dynamically configure devices. Even for e.g. modems it was just using the ones that were already available.

So this is most likely actually a no-op for s-c-n.

Want a final word from the maintainer though first.

Thanks & regards, Phil
Comment 4 Harald Hoyer 2009-11-12 14:56:38 EST
well, it calls ccw_init in the lates RHEL5 releases, if a network devices is newly created, and someone wants to activate it immediately.
Comment 5 Steffen Maier 2009-11-12 15:22:12 EST
OK, then it would have to call /sbin/znet_cio_free after having written the ifcfg file but before calling ccw_init. That should do it.
Comment 6 Phil Knirsch 2009-11-16 08:11:02 EST
Sounds easy enough.

Are those FOO_cio_free scripts already available or are they still pending to be implemented? (see the other related bug #533494)

Thanks & regards, Phil
Comment 8 Steffen Maier 2009-11-16 11:48:43 EST
To the best of my knowledge, those scripts do not exist yet. Since they are distro specific, I was assuming someone at Red Hat could code them.
Comment 22 Vladimir Benes 2010-06-09 05:21:25 EDT
does this bug still make sense? If so, I don't know how to test. Is it enough to test that installation on affected system works?
Comment 23 Steffen Maier 2010-06-09 06:55:09 EDT
This bug has always been about system-config-network.
However, in april the component was changed to NM, which I don't understand.
I think this should be changed back to s-c-network.
After all, NM does not know or understand anything about s390 specific device preparation. That preparation is only on s390util's /lib/udev/ccw_init for an installed system and in anaconda's linuxrc.s390 for an installation.
Both dracut's modules.d/95znet/ for network root file systems
and s-c-n delegate preparation to s390util's /lib/udev/ccw_init.
NM does not even do that and that's fine.

Now for the test case with s-c-n:
Have an installed system, with at least one set of s390 network subchannels, that are ignored by means of cio_ignore. Such a state should be the default after installation for any network which is not the one used during installation.
Then fire up s-c-n and configure that currently still ignored network device with subchannels and whatever else is necessary for the device type (such as layer2, portname, portno, etc.) plus a static IP configuration.
If system-config-network-1.6.0-1 was correctly modified, then you should get a configured and working new network device, which is no longer in the cio_ignore list. Additionally, a correct ifcfg file should have been written, which is the prereq to bring up the new network also on the subsequent reboots.

Please let me know, if you have problems or need more details.
Comment 25 Dan Williams 2010-08-20 16:36:42 EDT
(In reply to comment #23)
> This bug has always been about system-config-network.
> However, in april the component was changed to NM, which I don't understand.
> I think this should be changed back to s-c-network.
> After all, NM does not know or understand anything about s390 specific device
> preparation. That preparation is only on s390util's /lib/udev/ccw_init for an
> installed system and in anaconda's linuxrc.s390 for an installation.
> Both dracut's modules.d/95znet/ for network root file systems
> and s-c-n delegate preparation to s390util's /lib/udev/ccw_init.
> NM does not even do that and that's fine.

NM expects the devices to be available before NM controls them at this point, so we expect that udev will handle the device creation.  My understanding of the process is that ccw_init looks at ifcfg files to determine which s390 network interfaces to create during bootup or whenever, and then creates those network interfaces.

When the interfaces show up, NetworkManager will take those interfaces over and apply the configuration from the appropriate ifcfg file to the interface.  Thus, ccw_init handles the actual s390 network interface *creation*, while NetworkManager is perfectly capable of handling the "ifup/ifdown" part of actually applying IP configuration to the interface.

I'm not aware of any specific handling of the cio_ignore stuff.  If the interface is specified in ifcfg files, and has been created with ccw_init, then NM will see it and manage it.

> Now for the test case with s-c-n:
> Have an installed system, with at least one set of s390 network subchannels,
> that are ignored by means of cio_ignore. Such a state should be the default

If they are ignored, is there still a valid ifcfg file for this subchannel?  What does the configuration look like when an interface is ignored?

> after installation for any network which is not the one used during
> installation.
> Then fire up s-c-n and configure that currently still ignored network device
> with subchannels and whatever else is necessary for the device type (such as
> layer2, portname, portno, etc.) plus a static IP configuration.
> If system-config-network-1.6.0-1 was correctly modified, then you should get a
> configured and working new network device, which is no longer in the cio_ignore

Does system-config-network attempt to trigger ccw_init here after the configuration has been written to the ifcfg file?  We could attempt to do this in NetworkManager when creating a new s390-specific network connection that is available to all users.
Comment 26 Dan Williams 2010-08-20 16:46:18 EDT
Looks like system-config-network does have some code to automatically start newly configured s390 interfaces:

if hw.Name == self.Device and (hw.Card.IoPort and hw.Card.IoPort1 and hw.Card.IoPort2):               
      os.system('/sbin/znet_cio_free; SUBSYSTEM="ccw" DEVPATH="bus/ccwgroup/drivers/qeth/%s" /lib/udev/ccw_init' % hw.Card.IoPort)
      break
Comment 27 Jan Stodola 2010-08-22 04:18:38 EDT
After running s-c-n and configuring new interface eth1, the interface doesn't bring up and is not even cleared from cio_ignore list:

[root@rtt6 ~]# cat /proc/cio_ignore 
0.0.0000-0.0.0008
0.0.000a-0.0.08ff
0.0.0903-0.0.3025
0.0.3027-0.0.315f
0.0.3162-0.0.ffff
0.1.0000-0.1.ffff
0.2.0000-0.2.ffff
0.3.0000-0.3.ffff
[root@rtt6 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 4096 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:11:25:be:2c:57 brd ff:ff:ff:ff:ff:ff
    inet 10.16.105.197/21 brd 10.16.111.255 scope global eth0
    inet6 fec0:0:a10:6f00:11:2500:2be:2c57/64 scope site dynamic 
       valid_lft 2591831sec preferred_lft 604631sec
    inet6 fe80::11:2500:2be:2c57/64 scope link 
       valid_lft forever preferred_lft forever
[root@rtt6 ~]# system-config-network
[root@rtt6 ~]# cat /proc/cio_ignore 
0.0.0000-0.0.0008
0.0.000a-0.0.08ff
0.0.0903-0.0.3025
0.0.3027-0.0.315f
0.0.3162-0.0.ffff
0.1.0000-0.1.ffff
0.2.0000-0.2.ffff
0.3.0000-0.3.ffff
[root@rtt6 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
GATEWAY=10.16.111.254
DEVICE=eth1
BOOTPROTO=none
NETMASK=255.255.248.0
TYPE=Ethernet
IPADDR=10.16.105.198
SUBCHANNELS=0.0.0a00,0.0.0a01,0.0.0a02
NETTYPE=qeth


Values entered in s-c-n:

┌────────┤ Devernet Configuration ├────────┐
│                                          │
│                                          │
│ Name                eth1________________ │
│ Device              eth1________________ │
│ Use DHCP            [ ]                  │
│ Static IP           10.16.105.198_______ │
│ Netmask             255.255.248.0_______ │
│ Default gateway IP  10.16.111.254_______ │
│ Read Device Bus ID  0.0.0a00____________ │
│ Data Device Bus ID  0.0.0a01____________ │
│ Write Device Bus ID 0.0.0a02____________ │
│ Options             layer2=1 portno=0___ │
│ MAC Address         ____________________ │
│                                          │
│      ┌────┐            ┌────────┐        │
│      │ Ok │            │ Cancel │        │
│      └────┘            └────────┘        │
│                                          │
│                                          │
└──────────────────────────────────────────┘

There is also missing OPTIONS="layer2=1 portno=0" in /etc/sysconfig/network-scripts/ifcfg-eth1.

This was tested on build RHEL6.0-20100818.0 with system-config-network-tui-1.6.0.el6.2-1.el6.noarch.rpm, moving back to ASSIGNED.
Comment 29 Steffen Maier 2010-08-23 14:00:38 EDT
(In reply to comment #25)
> NM expects the devices to be available before NM controls them at this point,
> so we expect that udev will handle the device creation.  My understanding of
> the process is that ccw_init looks at ifcfg files to determine which s390
> network interfaces to create during bootup or whenever, and then creates those
> network interfaces.

My point here is: Where do those ifcfg files come from?

During install linuxrc.s390 writes one
and all the others can currently only be created with s-c-n-tui
which is why the latter is still shipped with RHEL6 on s390x.

> When the interfaces show up, NetworkManager will take those interfaces over and
> apply the configuration from the appropriate ifcfg file to the interface. 
> Thus, ccw_init handles the actual s390 network interface *creation*, while
> NetworkManager is perfectly capable of handling the "ifup/ifdown" part of
> actually applying IP configuration to the interface.

Correct, but in order to fully replace s-c-n (and network service of initscripts), nm-c-e would also have to learn to at least write the interface creation part (SUBCHANNELS, OPTIONS, PORTNAME, CTCPROT, ...) into an ifcfg file.

I had a look at nm-c-e as shipped in the install.img of RHEL6.0-snap10.
For the one interface configured by linuxrc.s390, nm-c-e does not show or allow editing of SUBCHANNELS, OPTIONS, etc.
When trying to add a new network connection, there are no entry widgets for SUBCHANNELS, OPTIONS, etc.

> I'm not aware of any specific handling of the cio_ignore stuff.  If the
> interface is specified in ifcfg files, and has been created with ccw_init, then
> NM will see it and manage it.

As s-c-n, NM (or nm-c-e or both, not sure) would have to call znet_cio_free before triggering ccw_init. Otherwise ignored subchannels would not be visible to Linux and ccw_init would not have anything to work with.

During install, linuxrc.s390 does something like znet_cio_free.
During regular boot, an upstart event calls device_cio_free (which includes znet, dasd, and zfcp) which in turn frees all devices that are specified in already existing ifcfg files (plus other config files for the other device types).

> > Now for the test case with s-c-n:
> > Have an installed system, with at least one set of s390 network subchannels,
> > that are ignored by means of cio_ignore. Such a state should be the default
> 
> If they are ignored, is there still a valid ifcfg file for this subchannel? 

There can be valid ifcfg files for ignored subchannels. They are handled as described above.

However, there can be arbitrary subchannels (no matter if they are ignored or not) that are not explicitly specified in an ifcfg file. Such subchannels are just unused and no network device will be there (since ccw_init does not know what devices to create from such unused subchannels and how).
The user has to explicitly create an ifcfg file for each network device he wants to see in Linux and he needs a tool to accomplish that (currently s-c-n-tui).

> What does the configuration look like when an interface is ignored?

The ifcfg files looks the same whether subchannels specified in there are ignored or not.
The sysfs does not show ignored subchannels.

> Does system-config-network attempt to trigger ccw_init here after the
> configuration has been written to the ifcfg file? 

Yes, the code snippet you found in comment 26 is exactly that trigger.

Unfortunately, something in s-c-n-tui seems to be buggy as Jan found out in comment 27. To fix the funtionality that's already there, I re-assign to s-c-n, so Harald can fix it there.

Jan, are there any logs in which we could see what went wrong in s-c-n-tui?

> We could attempt to do this
> in NetworkManager when creating a new s390-specific network connection that is
> available to all users.

However, we would currently still miss the ability to even create an s390-specific network connection as discussed at the top of this comment, right?

Dan, if you would like to add this functionality to nm-c-e in order to replace s-c-n, you may re-assign this bug to you after Harald has fixed s-c-n, or (probably better) you could create a clone to track nm-c-e.
Comment 30 Jan Stodola 2010-08-24 04:25:13 EDT
(In reply to comment #29)
> Jan, are there any logs in which we could see what went wrong in s-c-n-tui?

This is all I found in /var/log/messages:

Aug 24 04:15:04 rtt6 system-config-network[1452]: chmod 0644 //etc/sysconfig/networking/devices/ifcfg-eth0
Aug 24 04:15:04 rtt6 system-config-network[1452]: chmod 0644 //etc/sysconfig/networking/devices/ifcfg-eth0
Aug 24 04:15:04 rtt6 system-config-network[1452]: chmod 0644 //etc/sysconfig/networking/devices/ifcfg-eth1
Aug 24 04:15:04 rtt6 system-config-network[1452]: chmod 0644 //etc/sysconfig/networking/devices/ifcfg-eth1
Aug 24 04:15:05 rtt6 system-config-network[1452]: ln //etc/sysconfig/networking/devices/ifcfg-eth1 //etc/sysconfig/networking/profiles//default/ifcfg-eth1
Aug 24 04:15:05 rtt6 system-config-network[1452]: ln //etc/sysconfig/networking/devices//ifcfg-eth1 //etc/sysconfig/network-scripts//ifcfg-eth1

There are no messages on terminal when running system-config-network-tui with "-d" or "-v" parameters.
Comment 31 Harald Hoyer 2010-08-24 09:55:55 EDT
Created attachment 440659 [details]
proposed patch

Patch will add "activate" and "deactivate" buttons, which will call /sbin/znet_cio_free and /lib/udev/ccw_init for "activate" and take it offline for "deactivate".

The patch also fixes the "Options" and various issues discovered in the bugfixing process.
Comment 32 Harald Hoyer 2010-08-24 10:07:53 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Users, who configured their qeth interface with system-config-network, have to add the "OPTIONS=" line to /etc/sysconfig/network-scripts/ifcfg-<interface>" manually.

To activate the interface the system has to be rebooted, or the user has to run:
# /sbin/znet_cio_free
# SUBSYSTEM="ccw" DEVPATH="bus/ccwgroup/drivers/qeth/<SUBCHANNEL 0>" /lib/udev/ccw_init
# ifup <interface>

Experienced users could alternatively patch system-config-network with https://bugzilla.redhat.com/attachment.cgi?id=440659
Comment 34 Harald Hoyer 2010-08-24 10:17:23 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1,4 @@
-Users, who configured their qeth interface with system-config-network, have to add the "OPTIONS=" line to /etc/sysconfig/network-scripts/ifcfg-<interface>" manually.
+Users, who configured their qeth interface with system-config-network version 1.6.0.el6.2, have to add the "OPTIONS=" line to /etc/sysconfig/network-scripts/ifcfg-<interface>" manually.
 
 To activate the interface the system has to be rebooted, or the user has to run:
 # /sbin/znet_cio_free
Comment 36 Steffen Maier 2010-08-26 12:29:42 EDT
Does that mean, the device.(de)activate member functions were already there but never called?

(In reply to comment #32)
> # SUBSYSTEM="ccw" DEVPATH="bus/ccwgroup/drivers/qeth/<SUBCHANNEL 0>" /lib/udev/ccw_init

While this works by accident (ccw_init only uses CHANNEL=${DEVPATH##*/} and does not use DEVPATH any further than to check it to be a non-zero-length string), it is incorrect and misleading, since the DEVPATH given above never exists. First the /sys prefix is missing. Secondly, the ccwgroup will only be there after ccw_init has run successfully, hence this would be a deadlock.

From within udev, ccw_init would be called with:
DEVPATH=/sys/devices/css<X>/<subchannel-ID>/<SUBCHANNEL 0>
Since we don't want to force the user to figure out css<X> and <subchannel-ID>, the general manual trigger of ccw_init would use:
DEVPATH=/sys/bus/ccw/devices/<SUBCHANNEL 0>
If you really want to restrict it to qeth devices, then:
DEVPATH=/sys/bus/ccw/drivers/qeth/<SUBCHANNEL 0>
Comment 37 Steffen Maier 2010-08-26 12:32:33 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -2,7 +2,7 @@
 
 To activate the interface the system has to be rebooted, or the user has to run:
 # /sbin/znet_cio_free
-# SUBSYSTEM="ccw" DEVPATH="bus/ccwgroup/drivers/qeth/<SUBCHANNEL 0>" /lib/udev/ccw_init
+# SUBSYSTEM="ccw" DEVPATH="/sys/bus/ccw/devices/<SUBCHANNEL 0>" /lib/udev/ccw_init
 # ifup <interface>
 
 Experienced users could alternatively patch system-config-network with https://bugzilla.redhat.com/attachment.cgi?id=440659
Comment 38 Steffen Maier 2010-08-26 12:35:27 EDT
Alternatively, the user could just trigger the exact same udev rule that would be triggered on boot or on dynamic addition of devices and thus trigger ccw_init indirectly without having to know the necessary environment variables:

echo add > /sys/bus/ccw/devices/<SUBCHANNEL 0>/uevent

[http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_a_Network_Device.html#ap-s390info-Adding_a_Network_Device-qeth_Device]
Comment 39 Harald Hoyer 2010-08-30 05:34:48 EDT
(In reply to comment #37)
>     Technical note updated. If any revisions are required, please edit the
> "Technical Notes" field
>     accordingly. All revisions will be proofread by the Engineering Content
> Services team.
> 
>     Diffed Contents:
> @@ -2,7 +2,7 @@
> 
>  To activate the interface the system has to be rebooted, or the user has to
> run:
>  # /sbin/znet_cio_free
> -# SUBSYSTEM="ccw" DEVPATH="bus/ccwgroup/drivers/qeth/<SUBCHANNEL 0>"
> /lib/udev/ccw_init
> +# SUBSYSTEM="ccw" DEVPATH="/sys/bus/ccw/devices/<SUBCHANNEL 0>"
> /lib/udev/ccw_init
>  # ifup <interface>
> 
>  Experienced users could alternatively patch system-config-network with
> https://bugzilla.redhat.com/attachment.cgi?id=440659

DEVPATH _never_ has "/sys" !!
Comment 40 Steffen Maier 2010-08-30 06:22:30 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -2,7 +2,7 @@
 
 To activate the interface the system has to be rebooted, or the user has to run:
 # /sbin/znet_cio_free
-# SUBSYSTEM="ccw" DEVPATH="/sys/bus/ccw/devices/<SUBCHANNEL 0>" /lib/udev/ccw_init
+# SUBSYSTEM="ccw" DEVPATH="bus/ccw/devices/<SUBCHANNEL 0>" /lib/udev/ccw_init
 # ifup <interface>
 
 Experienced users could alternatively patch system-config-network with https://bugzilla.redhat.com/attachment.cgi?id=440659
Comment 42 Ryan Lerch 2010-09-08 20:13:31 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,8 +1,6 @@
-Users, who configured their qeth interface with system-config-network version 1.6.0.el6.2, have to add the "OPTIONS=" line to /etc/sysconfig/network-scripts/ifcfg-<interface>" manually.
+If the qeth interface was previously configured using system-config-network 1.6.0.el6.2, the "OPTIONS=" line needs to be manually added to /etc/sysconfig/network-scripts/ifcfg-<interface>.
+After the configuration has been manually changed, activate the interface by either rebooting the system, or running the following commands:
 
-To activate the interface the system has to be rebooted, or the user has to run:
 # /sbin/znet_cio_free
 # SUBSYSTEM="ccw" DEVPATH="bus/ccw/devices/<SUBCHANNEL 0>" /lib/udev/ccw_init
-# ifup <interface>
+# ifup <interface>-
-Experienced users could alternatively patch system-config-network with https://bugzilla.redhat.com/attachment.cgi?id=440659

Note You need to log in before you can comment on or make changes to this bug.