Description of problem: Automated installs no longer work on s390x. Install hands at a interactive prompt. Enter the portnumber for the OSA-Express3 device with 2 ports per CHPID (if unsu re, check with Admin. or use default) 0 for portnumber 0 (default) 1 for portnumber 1 Version-Release number of selected component (if applicable): RHEL5.3-Server-20080919.nightly How reproducible: Always Description of problem: * RHEL5.3-Server-20080919.nightly s390x * Error appears through automate RHTS testing * Behavior appears s390x dependent Expected results: Automated installs should work Additional info: This script is part of s390x's loader shell script.
This is a consequence of #439461. PORTNO parameter was added to CMS configuration file. If it is not present, user is asked. So to pass the test, CMS file (test) must be updated, or we must patch loader2/linuxrc.s390 to avoid the query if RUNKS CMS config parameter is 1.
Created attachment 317377 [details] patch suppressing PORTNO query in case of ks install
I don't agree with this patch, the PORTNO variable should be explicitly specified, and does not have a "default" value ... it refers to which port on an OSA express 3 hardware card the network devices are attached to. In environments where the OSA triplets are bound to port number 1, supplying a "0" default will cause the network interface to not come up ...
(In reply to comment #4) My reason for the patch is only to assure that we don't break existing OSA 3 automated install configurations using (by now the only one supported) portno 0 (i.e. not having any PORTNO value in CMS file). But I am not sure if it is a valid case.
my automated tests do not block when adding PORTNO=0 to the list of CMS conf paramters ...
Correct, doing echo 0 > portno on cards with one port per CHPID (like OSA-Express2) won't break the card and still works. What it is no good is to do echo 1 > portno on cards with one port per CHPID (like OSA-Express2), and that is why the question to user to choose only when having an OSA-Express3 with 4 ports (= 2 ports per CHPID, since there are 2 CHPIDs per card). The same as when it was introduced LAYER2 variable, the automated installations from RHEL 5 did not work in RHEL 5.1 without LAYER2 variable being set, now with RHEL 5.3 the automated installation which worked with RHEL 5.2, now need PORTNO variable to be set *by the user*, and that is why it should be documented in Installation Guide, Deployment Guide and Release Notes. Hope it helps... Gonzalo.
(In reply to comment #9 #10) > I think (agree with you) the customer should have the possibility to: > - Automactic (with CMS file and with Kickstart) to decide if he uses the > first port or the second port with a variable "PORTNO=0|1" to be used > whereever it is needed. I understood from the discussion in Bug, that only > in CMS is needed (like other options, for example LAYER2=0|1 variable). > Conserning automated install, without the patch customer will have not only possibility, but also obligation (which is not the case with the patch) to decide..., that is - PORTNO variable is mandatory. If you are OK with it, so am I. Thanks for clarification.
Hi Radek, yes, IBM is ok with this obligation to the customer (as mentioned, the same thing happened with Layer2). That is why I think it is so important that the customer is aware of this change everywhere possible in the documentation, and not only in online release notes like it happened with Layer2 when it was introduced. Thank you for your support, Gonzalo Muelas.
Closing as NOTABUG as the described behavior is correct. Summary for release notes and documentation was added to original bug #439461