Is this referring to the linuxrc script or to anaconda itself?  What dialogs in particular do you have in mind?

(In reply to comment #4)
> ------- Comment From clumens 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.

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 From MAIER.com 2009-07-06 11:34 EDT-------
accepted upstream in
http://git.fedorahosted.org/git/anaconda.git?p=anaconda.git;a=commit;h=9249e40f42ffbbdcf42cd1caad72e3d622c7a75b

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

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 From gmuelas.com 2010-09-27 12:18 EDT-------
Also @IBM verified ok.

Moving to VERIFIED based on comment 8.

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.