Bug 462975 - [LTC 6.0 FEAT] 201676:Improve checking mechanisms and workflow of Linux on System z Anaconda install process
[LTC 6.0 FEAT] 201676:Improve checking mechanisms and workflow of Linux on Sy...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
s390x All
high Severity high
: alpha
: 6.0
Assigned To: Anaconda Maintenance Team
Release Test Team
: FutureFeature, OtherQA
Depends On:
Blocks: 356741 554559
  Show dependency treegraph
Reported: 2008-09-19 18:21 EDT by IBM Bug Proxy
Modified: 2010-11-10 14:34 EST (History)
8 users (show)

See Also:
Fixed In Version: anaconda-12.38.5-1.el6
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-10 14:34:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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:21:09 EDT
=Comment: #0=================================================
Emily J. Ratliff <emilyr@us.ibm.com> - 2008-09-16 18:21 EDT
1. Feature Overview:
Feature Id:	[201676]
a. Name of Feature:	Improve checking mechanisms and workflow of Linux on System z Anaconda install
b. Feature Description
There should be better syntactic and also (if possible) semantic checking of user input. On
syntactically or semantically wrong answers, the user should have the possibility to correct entries
   immediately.  After having specified all necessary parameters, anaconda should present an
overview of all user input and give the user the choice to correct single user-chosen entries
without starting all over again. If anaconda is unable to configure vital devices, the user should
be presented meaningful error messages. The corresponding architecture specific installation
documentation should be updated accordingly.

2. Feature Details:
Sponsor:	zSeries

Arch Specificity: Both
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

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 1 Chris Lumens 2008-09-26 16:41:02 EDT
Is this referring to the linuxrc script or to anaconda itself?  What dialogs in particular do you have in mind?
Comment 2 IBM Bug Proxy 2008-10-08 12:12:13 EDT
(In reply to comment #4)
> ------- Comment From clumens@redhat.com 2008-09-26 16:41:02 EDT-------
> Is this referring to the linuxrc script or to anaconda itself?  What dialogs in particular do you have in mind?

This refers to linuxrc.s390.

We have the entire user dialog of linuxrc.s390 in mind, i.e. all parameters possibly being asked from the user such as NETTYPE, SUBCHANNELS, PORTNAME, LAYER2, VSWITCH, MACADDR, CTCPROT, PORTNO, PEERID, HOSTNAME, IPADDR, NETMASK, GATEWAY, DNS, SEARCHDNS.
I left out BROADCAST and NETWORK intentionally since they should be calculated from IPADDR and NETMASK so the user does not have to manually specify unnecessary parameters.
Comment 3 IBM Bug Proxy 2009-02-26 11:31:21 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

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


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.


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.


- 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
- 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.


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

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.


[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 4 IBM Bug Proxy 2009-07-06 11:44:31 EDT
------- Comment From MAIER@de.ibm.com 2009-07-06 11:34 EDT-------
accepted upstream in
Comment 5 Chris Lumens 2009-09-04 16:33:11 EDT
Putting into MODIFIED on the basis of comment #4.  We'll be rebasing anaconda
in RHEL6 before the final release so the updated script in head will get pulled
Comment 7 Jan Stodola 2010-06-21 07:28:59 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 8 IBM Bug Proxy 2010-09-27 12:20:43 EDT
------- Comment From gmuelas@de.ibm.com 2010-09-27 12:18 EDT-------
Also @IBM verified ok.
Comment 9 Jan Stodola 2010-09-29 03:05:39 EDT
Moving to VERIFIED based on comment 8.
Comment 10 releng-rhel@redhat.com 2010-11-10 14:34:37 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.