Bug 462973 - [LTC 6.0 FEAT] 201679:Change list of Anaconda network alternatives to indicate supported devices on System z
[LTC 6.0 FEAT] 201679:Change list of Anaconda network alternatives to indicat...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
6.0
s390x All
high Severity high
: alpha
: 6.0
Assigned To: Anaconda Maintenance Team
Release Test Team
: FutureFeature
Depends On:
Blocks: 356741 554559 555224 555228
  Show dependency treegraph
 
Reported: 2008-09-19 18:20 EDT by IBM Bug Proxy
Modified: 2012-03-31 14:36 EDT (History)
10 users (show)

See Also:
Fixed In Version: anaconda-12.38.5-1.el6
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-10 14:34:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description IBM Bug Proxy 2008-09-19 18:20:54 EDT
=Comment: #0=================================================
Emily J. Ratliff <emilyr@us.ibm.com> - 2008-09-16 18:21 EDT
1. Feature Overview:
Feature Id:	[201679]
a. Name of Feature:	Change list of Anaconda network alternatives to indicate supported devices on
System z
b. Feature Description
Anaconda gives the user an equal choice between four types of network devices to use (ctc, iucv,
qeth, lcs) even though the Install Guide states that two of those options (ctc, netuicv) are
deprecated. This increases the chance for unexperienced users to choose the wrong type of network.
The choice should explicitly state, which options are deprecated and they should only be chosen by
the user, if he knows that they are necessary e.g. due to a specific hardware configuration. The
corresponding architecture specific installation documentation should be updated accordingly.

2. Feature Details:
Sponsor:	zSeries
Architectures:
s390x

Arch Specificity: Purely Arch Specific Code
Affects Installer: Yes
Delivery Mechanism: Request Red Hat development assistance
Category:	Installation
Request Type:	Installer - Enhancement from Distributor
d. Upstream Acceptance:	No Code Required
Sponsor Priority	1
f. Severity: High
IBM Confidential:	no
Code Contribution:	no
g. Component Version Target:	n/a

3. Business Case
These changes will improve the installation experience for customers by making the intallation
workflow more usable and efficient, which will result in an improvement of the customer satisfaction.

4. Primary contact at Red Hat: 
John Jarvis
jjarvis@redhat.com

5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, mgrf@de.ibm.com, Boeblingen 49-7031-16-3978

Technical contact(s):
Gonzalo Muelas Serrano, gmuelas@de.ibm.com

IBM Manager:
Thomas Schwarz, t.schwarz@de.ibm.com
Comment 2 Bill Nottingham 2008-11-20 11:52:20 EST
If iucv/ctc are deprecated even in RHEL 5, I'm not sure it's worth supporting them in RHEL 6.
Comment 3 IBM Bug Proxy 2008-11-25 07:50:47 EST
(In reply to comment #5)
> If iucv/ctc are deprecated even in RHEL 5, I'm not sure it's worth supporting
> them in RHEL 6.

Hi Bill,

AFAIK, we still fix problems with ctc and iucv upstream, even though they are already deprecated since RHEL 5. Based on this, I assume the drivers and necessary infrastructure will still be part of RHEL 6. If so, then we would like to make this deprecation explicit to the user during the install dialog.
Comment 4 Bill Nottingham 2008-11-25 10:06:35 EST
Generally, if an item is deprecated in RHEL X, it is removed in RHEL X-1. I'm not sure it's worth special code to tell users 'you shouldn't use this'.
Comment 5 Brad Hinson 2008-11-25 11:26:36 EST
CTC is a hard requirement for hercules.  If we remove it completely, it would invalidate a lot of work done in a widely used emulator.  Can we leave in CTC, and add a deprecation warning?
Comment 6 Bill Nottingham 2008-11-25 12:05:59 EST
Is there a reason hercules can't emulate the newer hardware interfaces?
Comment 7 IBM Bug Proxy 2008-11-25 13:00:40 EST
(In reply to comment #9)
> Is there a reason hercules can't emulate the newer hardware interfaces?
>

AFAIK nobody implemented the emulation of other network devices besides ctc and lcs so far, at least from what I can see on the website.
Comment 8 Brad Hinson 2008-11-25 13:34:10 EST
Related thread (note: qeth requires qdio):

http://www.nabble.com/can-Hercules-support-QDIO-for-TCPIP-now--td6385747.html

[snip]
>   Can Hercules support QDIO Mode for TCPIP now?
> Any response are appreciated.

DOES it? No.

CAN it? (i.e. COULD it?) Sure (I think), but it'd probably take some
effort to do, so don't expect it anytime soon.

It's on my personal list of things to look into (research), but
hasn't bubbled its way anywhere near the top yet. Perhaps some other
developer / energetic user could look into it in the mean time?

Bottom line: No. Sorry. You're SOL I'm afraid. :( 
[snip]
Comment 9 IBM Bug Proxy 2009-02-26 11:30:51 EST
This feature has been implemented by extending the existing linuxrc.s390
-- the script performing the initial installation dialog for RHEL on
System z.

A second version integrating review comments from the anaconda-devel
mailing list has been posted [4] for another review and upstream
integration.

The code fully implements the following feature requests:

LTC bug 48097 / RH bug 462975 - [LTC 6.0 FEAT] 201676:Improve checking mechanisms and workflow of Linux on System z Anaconda install process

LTC bug 48098 / RH bug 462974 - [LTC 6.0 FEAT] 201677:Dialog defaults for Linux on System z specific Anaconda

LTC bug 48099 / RH bug 462973 - [LTC 6.0 FEAT] 201679:Change list of Anaconda network alternatives to indicate supported devices on System z

In addition, the implementation already contains those parts of the
following feature requests, that need to be implemented in linuxrc.s390,
which means a lot of work has already been done but
those features require other additional code or documentation:

LTC bug 47960 / RH bug 463544 - [LTC 6.0 FEAT] 201085:cio_ignore entry in generic.prm for LPARs

LTC bug 48039 / RH bug 463656 - [LTC 6.0 FEAT] 201360:OSA 2 Ports per CHPID Support - Installer and tools Enhancements

LTC bug 48101 / RH bug 463177 - [LTC 6.0 FEAT] 201686:Installer - HiperSockets MAC Layer Routing Support

LTC bug 48102 / RH bug 463180 - [LTC 6.0 FEAT] 201687:Installer - QETH Componentization

LTC bug 48103 / RH bug 463187 - [LTC 6.0 FEAT] 201688:Installer migration - Merge CTCMPC into CTC device driver

INTRODUCTION

After booting the installation environment on System z, there are no
local storage devices such as a CD/DVD drive available to install RHEL
from. Hence, only installation from network sources is possible, which
requires an initial setup of a network device to reach such an
installation source.

Due to the possibly large number of hardware network devices
(hundreds) and the way they are configured in the hardware setup,
Linux does not automatically detect and allocate all available network
devices. There is need for a dialog from which the user can choose a
sensible device configuration.

The least common multiple of console devices on System z is limited in
functionality -- it only supports line mode. The initial network setup
also provides the ability for users to login over the network from a
curses capable text terminal, to provide an X window display, or to
use VNC in order to continue installation.

DOWNSIDES OF CURRENT LINUXRC.S390

The initial network setup was done with a simple error-prone dialog
without any possibility for the user to correct wrong input. On
getting stuck, the only option for the user was a reboot, which of
course means that he had to manually enter values all over again.

The user was asked various questions and had to know exactly what
answers to provide for a successful network setup. Linuxrc.s390
provided no guidance or support to simplify the choice of correct
answers for the user.

Configuration happened after the user had answered all questions which
could lead to situations where configuration failed due to an earlier
incorrect answer the user was not informed about.

User feedback has shown, that these downsides can be an obstacle for a
successful installation of RHEL on System z.

IMPROVEMENTS OF NEW LINUXRC.S390

- dialog allows the user to correct single answers
- dialog allows to restart configuration,
providing previous answers as default values
- dialog provides a sub shell for problem determination
- cut-down question text prevents frequent scrolling on line mode
terminal
- explaining help text is shown for each question on user demand
- automated decision which questions the user has to answer
- semi-automatic configuration of network devices by providing
a selection list of possible hardware configurations
- manual configuration remains possible as before
- sensible default answers are provided where possible
- superfluous questions (NETWORK, BROADCAST) have been removed
- answers by the user are strictly checked for syntax and semantics
- whenever possible, each answer is used to do a configuration step
and provide timely feedback to the user in case of an error
- user transparent support of System z device blacklist (cio_ignore)
for short boot times on systems with many (thousands) devices
- basic support for installation from FCP-attached CD/DVD drive
(our version of linuxrc.s390 is based on rhel5.3-snap1-20081029)
- basic support for installation over IPv6
(full functionality would require further support in loader)
- prints answers in a format which can directly be used for parm/conf
file (c.f. /root/anaconda-ks.cfg)
- may serve as a specification on how to configure network devices on
System z outside of an installer, e.g. in init scripts or
configuration tools such as system-config-network
- reworked to conform to fedora rawhide

Otherwise, our version is fully compatible with the current version
including the processing of parm/conf files. We made sure that
existing parm/conf files from users are processed with the same
outcome as previously. Also the interactive mode asks the user
questions in the same order as before, so users do not have to adapt
to a completely new structure of the initial network configuration.

TEST

The first version of linuxrc.s390 and the helper script lsznet.raw
(called by linuxrc.s390 to enumerate sensible network hardware
configurations) submitted to anaconda-devel on 2008-11-14 [1] for review
[2,3] have been tested within an installer initrd taken from RHEL
5.2. Full installation cycles both without and with kickstart mode have
been performed. We considered different network hardware (both real and
virtual) and installed from sources accessible over different protocols
(FTP, HTTP, NFS).

We will test and if necessary fix our reworked, second version submitted
to anaconda-devel on 2009-02-24 [4] with fedora on s390x as soon as it
is available.

REFERENCES

[1] https://www.redhat.com/archives/anaconda-devel-list/2008-November/msg00183.html
[2] https://www.redhat.com/archives/anaconda-devel-list/2008-December/msg00102.html
[3] https://www.redhat.com/archives/anaconda-devel-list/2009-January/msg00000.html
[4] https://www.redhat.com/archives/anaconda-devel-list/2009-February/msg00392.html
Comment 10 IBM Bug Proxy 2009-07-06 11:43:17 EDT
------- Comment From MAIER@de.ibm.com 2009-07-06 11:34 EDT-------
accepted upstream in
http://git.fedorahosted.org/git/anaconda.git?p=anaconda.git;a=commit;h=9249e40f42ffbbdcf42cd1caad72e3d622c7a75b
Comment 11 Denise Dumas 2009-09-11 16:50:48 EDT
Patch will be picked up for Alpha2
Comment 13 Jan Stodola 2010-06-21 07:28:21 EDT
Hello IBM,
were you able to test this feature with any recent snapshot of RHEL6.0?
I would like to make sure you accept implementation of this feature.
Thank you for your feedback.
Comment 14 Jan Stodola 2010-08-17 05:45:31 EDT
ctc is marked as deprecated, iucv is not supported:

Scanning for available network devices... 
Autodetection found 0 devices. 
Note: There is a device blacklist active! (Clearing might take long) 
c) clear blacklist, m) manual config, r) rescan, s) shell: 
m
 
* NOTE: To enter default or empty values press enter twice. * 
 
Network type (qeth, lcs, ctc, ? for help). Default is qeth: 
?
 Help text for network type: 
  qeth: OSA-Express Fast Ethernet, Gigabit Ethernet (including 1000Base-T), 
        High Speed Token Ring, Hipersockets, and ATM (running Ethernet LAN emula
tion) 
        features in QDIO mode. 
        Ýdefault¨ 
  lcs:  OSA-2 Ethernet/Token Ring, OSA-Express Fast Ethernet in non-QDIO mode, 
        OSA-Express High Speed Token Ring in non-QDIO mode and Gigabit Ethernet 
        in non-QDIO mode. 
  ctc:  Deprecated, useful for migration. 
 
Network type (qeth, lcs, ctc, ? for help). Default is qeth: 

This is with anaconda-13.21.68-1.el6, build RHEL6.0-20100807.0.
Moving to VERIFIED.
Comment 15 IBM Bug Proxy 2010-09-27 11:53:58 EDT
------- Comment From gmuelas@de.ibm.com 2010-09-27 11:40 EDT-------
Also @IBM verified ok.
Comment 16 releng-rhel@redhat.com 2010-11-10 14:34:27 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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