Bug 462908
| Summary: | Enter the portnumber for the OSA-Express3 device. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Jeff Burke <jburke> | ||||
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.3 | CC: | ddumas, dzickus, gmuelas, jjarvis, lwang, pbunyan, rvykydal, syeghiay | ||||
| Target Milestone: | beta | Keywords: | TestBlocker | ||||
| Target Release: | --- | ||||||
| Hardware: | s390x | ||||||
| OS: | Linux | ||||||
| URL: | http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=4366751 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-09-30 14:08:38 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Jeff Burke
2008-09-19 16:20:13 UTC
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 |