Bug 507214 - Need to update /lib/udev/ccw_init since the name of s390 network device driver has changed from ctc to ctcm
Summary: Need to update /lib/udev/ccw_init since the name of s390 network device drive...
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 12
Hardware: s390x
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
Depends On: 539491
Blocks: ZedoraTracker 516998
TreeView+ depends on / blocked
Reported: 2009-06-21 18:12 UTC by Steffen Maier
Modified: 2014-03-17 03:19 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-05 06:49:30 UTC

Attachments (Terms of Use)
output of "udevadm monitor --environment" (5.68 KB, text/plain)
2009-09-05 18:34 UTC, Steffen Maier
no flags Details
potential patch (1.24 KB, patch)
2009-09-08 16:58 UTC, Bill Nottingham
no flags Details | Diff

Description Steffen Maier 2009-06-21 18:12:31 UTC
Description of problem:
Previously the name of the network device drivers, the ifcfg file parameter NETTYPE, and certain s390 network device paths in sysfs happened to be exactly the same. Since the merge of the drivers ctc and mpc into ctcm, the network driver module for CTC and also the sysfs paths are called ctcm.

Version-Release number of selected component (if applicable):

How reproducible:
Generate your /etc/sysconfig/network-scripts/ifcfg-ctc0 of choice and the CTC device won't come up (using the network service).

Additional info:

/lib/udev/ccw_init builds an internal variable called DIR using NETTYPE as part of the sysfs path. In case of NETTYPE being ctc, the sysfs path needs to be /sys/bus/ccwgroup/drivers/ctcm instead. Please add this little special case. Doing so lets existing ifcfg files continue working. I wouldn't want to force users to change all occurrences of ctc in ifcfg NETTYPE to ctcm.

Comment 1 Bill Nottingham 2009-06-22 18:30:00 UTC
NETTYPE seems like a broken configuration parameter to begin with. Any reason it couldn't be autodetected?

Comment 2 Steffen Maier 2009-06-23 12:51:06 UTC
My understanding was that time is a scarce resource and we want to get Fedora working on s390x ASAP. Therefore, we should fix all those simple little things as the issue in here, in order to have enough time to fix the more complicated issues at other places.

Comment 3 Bill Nottingham 2009-06-23 14:26:30 UTC
The schedule is not an excuse to include bad hacks (and this process should have started years ago.)

Comment 4 Bill Nottingham 2009-09-02 19:23:40 UTC
What's the output of 'udevmonitor --env' on boot for these devices?

Comment 5 Steffen Maier 2009-09-05 18:34:31 UTC
Created attachment 359877 [details]
output of "udevadm monitor --environment"

Screen log of dynamically defining (not different from boot scenario) one potential ccwgroup (2 ccw channels) making up one Linux network device for each of the 3 different CTC network adapter types. Dynamic definition is accomplished from within Linux under z/VM using vmcp to instruct the hypervisor to define channels. For each of the 3 pairs, the user would have an ifcfg-ctcX as follows (DEVICE, SUBCHANNELS, IPADDR, and GATEWAY different for each of course):

# IBM vCTC p-t-p

May I ask, what your plans for solving this are, Bill?

Comment 6 Bill Nottingham 2009-09-08 16:58:30 UTC
Created attachment 360108 [details]
potential patch

Something like this (untested). DEVICETYPE predates NETTYPE anyway; not sure why that was invented for mainframe.

Comment 7 Steffen Maier 2009-09-11 17:36:21 UTC
(In reply to comment #6)
> Created an attachment (id=360108) [details]
> potential patch
> Something like this (untested). DEVICETYPE predates NETTYPE anyway; not sure
> why that was invented for mainframe.  

DEVICETYPE is set by /etc/sysconfig/network-scripts/network-functions, either by choosing it based on TYPE from ifcfg-... or if that isn't specified on the prefix of the device name given in DEVICE. No ifcfg file on s390 I have seen so far had TYPE set explicitly (unless some admin inserted that manually). For the different network types on s390 this gives the following mapping:

qeth    Ethernet ethX   eth
lcs     Ethernet ethX   eth
ctcm    CTC      ctcX   ctc
netiucv IUCV     iucvX  iucv
(there are more mappings for other, non-s390 network device types)

DEVICETYPE is used by ifup and ifdown and their -post scripts. ifup/ifdown use it to call an ifup-$DEVICETYPE specific subscript if it exists, which is the case for ctc and iucv but neither for qeth nor for lcs which use the common ifup-eth.

NETTYPE is for s390 only and is set in linuxrc.s390, read by loader in loader.c and finally written by loader in net.c to ifcfg-...
To my surprise, anaconda's network.py sets self.info["TYPE"] to either CTC or IUCV, depending on what name the network device starts with (similar to what network-functions does) but this is used nowhere in anaconda.
Anyway, NETTYPE has the following mapping:

driver  NETTYPE
qeth    qeth
lcs     lcs
ctcm    ctc
netiucv iucv

NETTYPE is used by /lib/udev/ccw_init (and maybe other places I don't know of yet). Apparently, DEVICETYPE cannot distinguish between qeth and lcs but that is necessary in /lib/udev/ccw_init (if [ "$NETTYPE" = "lcs" ]; then ...) which is most probably why NETTYPE is used in there.

If you reduce and adapt your patch to the following, it should just work:

+if [ "$NETTYPE" = "ctc" ]; then
+	DIR="/sys/bus/ccwgroup/drivers/ctcm"
+	DIR="/sys/bus/ccwgroup/drivers/$NETTYPE"

I use something similar here successfully.

Comment 8 IBM Bug Proxy 2009-10-19 22:40:52 UTC
------- Comment From kumarr@linux.ibm.com 2009-10-19 18:34 EDT-------

Comment 9 Bug Zapper 2009-11-16 10:17:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:

Comment 12 Steffen Maier 2010-02-04 12:10:46 UTC
Bill, did you apply any patch to fix this?
I cannot find any changes in either master or rhel6-branch of initscripts
and ctcm network devices won't be configured in Rawhide and RHEL 6.

Comment 13 Bill Nottingham 2010-02-04 15:38:45 UTC
There is an open bug to move ccw_init to s390utils. I was waiting on that, and was going to move this there then.

Comment 14 Bug Zapper 2010-11-04 11:02:49 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 15 Bug Zapper 2010-12-05 06:49:30 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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