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):
Generate your /etc/sysconfig/network-scripts/ifcfg-ctc0 of choice and the CTC device won't come up (using the network service).
/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.
NETTYPE seems like a broken configuration parameter to begin with. Any reason it couldn't be autodetected?
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.
The schedule is not an excuse to include bad hacks (and this process should have started years ago.)
What's the output of 'udevmonitor --env' on boot for these devices?
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?
Created attachment 360108 [details]
Something like this (untested). DEVICETYPE predates NETTYPE anyway; not sure why that was invented for mainframe.
(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:
driver TYPE DEVICE DEVICETYPE
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:
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
I use something similar here successfully.
------- Comment From email@example.com 2009-10-19 18:34 EDT-------
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:
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.
There is an open bug to move ccw_init to s390utils. I was waiting on that, and was going to move this there then.
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:
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.