Bug 463564
Summary: | [LTC 6.0 FEAT] 201092:Firstboot for System z | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | IBM Bug Proxy <bugproxy> |
Component: | firstboot | Assignee: | Martin Gracik <mgracik> |
Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.1 | CC: | borgan, cward, dmach, ejratl, fnadge, gmuelas, hpicht, jjarvis, jstodola, rwilliam |
Target Milestone: | beta | Keywords: | FutureFeature, OtherQA |
Target Release: | 6.1 | ||
Hardware: | s390x | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | firstboot-1.110.9-1 | Doc Type: | Enhancement |
Doc Text: |
Cause
Firstboot utility, which helps the user to setup a newly installed system didn't run automatically after installation on s390 architecture.
Consequence
Firstboot had to be run manually by the user.
Change
The automatic execution of firstboot was added.
Result
Firstboot utility is run automatically when the root user logs in to the system for the first time with a capable terminal.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2011-05-19 14:20:04 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: | |||
Bug Depends On: | |||
Bug Blocks: | 538808, 580566, 647893 |
Description
IBM Bug Proxy
2008-09-23 21:21:46 UTC
There's no longer the rhpxl requirement in firstboot that was preventing firstboot from working in s390. So that stumbling block has been removed. However, making sure it really works (and works well) is going to require work from the interested parties. The latest version of firstboot in Fedora should be working much better. This is where the work needs to happen. Please test and let me know where the deficiencies still exist. Hello Chris, I have tried in the latest build from Fedora on System z available (F9, because Fedora 10 for System z does not yet exist). Following things happen after installing with yum: - Reboot hanged by services starting boot process and showed the ncurses dialog from firstboot in 3215 Console, which did not help (issue which is fixed with RHEL 5.3 see Bug 217921). - After manually disabling the service in rc3.d, booted and logged via ssh, but firstboot did not come automaticly (of course, since I had to remove from the service) and then I run firstboot manually and all that is showed was "Timezone Configuration" This request, as with RHEL 5.3, address the need to: (1) Avoid ncurses dialog to be shown in 3215 Console (linemode) (fixed with RHEL 5.3) (2) Automaticly shows firstboot dialog when loging from a full screen capable terminal as root the first time, that is, right away after successfully starting the ssh session. (fixed with RHEL 5.3) (3) To have all the setup dialogs, including Security configuration: Firewall and SELinux. (fixed with RHEL 5.3) (4) And to have the rhn_register dialog as well as part of firstboot and not separately (I am not sure how do you want us to verify RHN with Fedora, since in Fedora there is only yum, correct?) (latest test version of firstboot from bug feature request was not yet fixed) Thank you, Gonzalo Muelas. Hello Red Hat, this request was not implemented in RHEL 5.3, so it has been requested again for RHEL 5.4 and RHEL 6. Here is an update in the description what this feature should provide: Description: After a fresh installation, RHEL on System z should run an automatically-triggered post-installation step and avoid the risk that a customer forgets to manually run any of the important setup tools by: - Bringing up this post-installation wizard automatically during the first boot/login, with no restrictions, other than it should not appear in a Line-Mode console/terminal, since the current wizard uses menus, unless you would like to implement the wizard without menus. - In the wizard the user must at least be prompted to setup all the critical tasks, for example, firewall, SELinux and RHN, and any other you could think of which are presented in RHEL in Intel and should also apply for System z customers. - Optionally, the user should be prompted to configure any other non critical tasks, for example managing users or any other you could think of which are presented in RHEL 6 in Intel and should also apply for System z customers. Thank you for your support, Gonzalo Muelas Serrano. Since it's been a few months since the last comment, how goes Firstboot for System z? Any update? ------- Comment From gmuelas.com 2010-01-13 08:45 EDT------- Hello Red Hat, any updates here? Thank you! To implement firstboot on System z according to the comments below, here's what I think we should do: 1) Firstboot should stop itself if run from the service init script. It should do this by calling its own writeSysconfigFile() function and then exiting. 2) Add firstboot.sh (and firstboot.csh) to /etc/profile.d to handle the s390x case. The script should do the following: a) Source /etc/sysconfig/firstboot if it exists. b) If we are on s390x and $RUN_FIRSTBOOT != "no" and we have a usable Linux terminal or an X terminal (not 3270), run /usr/sbin/firstboot This should allow us to run firstboot on the first login on s390x, whether or not that's via ssh or not. It also prevents firstboot from running if the terminal is incapable. Martin, what do you think of this? Is this something that is doable or not for RHEL-6? We are out of capacity to complete this for RHEL 6.0, adding to RHEL 6.1 tracker for consideration for that release. I have a candidate patch for this, which disables firstboot start after boot on s390, and instead of it, it runs it when a root user first logs in the system. It's being tested now, if it behaves how it should be. ------- Comment From mgrf.com 2010-04-16 06:12 EDT------- (In reply to comment #13) > I have a candidate patch for this, which disables firstboot start after boot on > s390, and instead of it, it runs it when a root user first logs in the system. > It's being tested now, if it behaves how it should be. Any test results ? Status for R6 inclusion? ------- Comment From mgrf.com 2010-09-08 06:48 EDT------- Hello Red Hat, I would prefer a short entry in release notes for this ticket Would you please post a proposal? *** Bug 633351 has been marked as a duplicate of this bug. *** IBM is signed up to test and provide feedback. Setting OtherQA ------- Comment From rsisk.com 2010-10-04 11:32 EDT------- Code Upstream Status: In Progress ------- Comment From rsisk.com 2010-10-04 10:42 EDT------- Code Upstream Status: No Code Required Fixed in version firstboot-1.110.9-1 This enhancement request was evaluated by the full Red Hat Enterprise Linux team for inclusion in a Red Hat Enterprise Linux minor release. As a result of this evaluation, Red Hat has tentatively approved inclusion of this feature in the next Red Hat Enterprise Linux Update minor release. While it is a goal to include this enhancement in the next minor release of Red Hat Enterprise Linux, the enhancement is not yet committed for inclusion in the next minor release pending the next phase of actual code integration and successful Red Hat and partner testing. Florian Nadge 2011-01-19 10:40:58 EST Please be so kind and add a few key words to the technical note of this bugzilla entry using the following structure: Cause: Consequence: Fix: Result: For details, see: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause What actions or circumstances induced the feature request. Consequence What action was inhibited by the feature’s absence. Change What was done to implement the feature. Note: backported from upstream is not an explanation. Result What now happens when the actions or circumstances above occur. Note: this is not the same as the feature request was fulfilled. Firstboot doesn't start after user log in using ssh for the first time. After the installation, /etc/sysconfig/firstboot contains: RUN_FIRSTBOOT=NO looks like this is triggered by following lines in instdata.py: 83 if iutil.isS390() or self.anaconda.isKickstart: 84 self.firstboot = FIRSTBOOT_SKIP anaconda version 13.21.97 Moving back to ASSIGNED. (In reply to comment #23) > Firstboot doesn't start after user log in using ssh for the first time. > > After the installation, /etc/sysconfig/firstboot contains: > RUN_FIRSTBOOT=NO > > looks like this is triggered by following lines in instdata.py: > > 83 if iutil.isS390() or self.anaconda.isKickstart: > 84 self.firstboot = FIRSTBOOT_SKIP > > anaconda version 13.21.97 > > Moving back to ASSIGNED. Ah, right. mgracik, this just needs changing in anaconda. The firstboot package is fine at this point. Yes, thanks for making the anaconda patch. (In reply to comment #23) > Firstboot doesn't start after user log in using ssh for the first time. > > After the installation, /etc/sysconfig/firstboot contains: > RUN_FIRSTBOOT=NO > > looks like this is triggered by following lines in instdata.py: > > 83 if iutil.isS390() or self.anaconda.isKickstart: > 84 self.firstboot = FIRSTBOOT_SKIP > > anaconda version 13.21.97 > > Moving back to ASSIGNED. Should be taken care of now. Fix is in anaconda-13.21.98-1, which will be in the next nightly. Moving this one back to ON_QA. Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,10 +1,11 @@ Cause - What actions or circumstances induced the feature request. + Firstboot utility, which helps the user to setup a newly installed system didn't run automatically after installation on s390 architecture. + Consequence - What action was inhibited by the feature’s absence. + Firstboot had to be run manually by the user. + Change - What was done to implement the feature. - Note: backported from upstream is not an explanation. + The automatic execution of firstboot was added. + Result - What now happens when the actions or circumstances above occur. + Firstboot utility is run automatically when the root user logs in to the system for the first time with a capable terminal.- Note: this is not the same as the feature request was fulfilled. ~~ Partners and Customers ~~ This bug was included in RHEL 6.1 Beta. Please confirm the status of this request as soon as possible. If you're having problems accessing 6.1 bits, are delayed in your test execution or find in testing that the request was not addressed adequately, please let us know. Thanks! With RHEL6.1-20110420.0 build, firstboot is started automatically after root logs in for the first time. Works in both text and graphical mode (using ssh X11 forwarding) Tested components: firstboot-1.110.10-1.el6 anaconda-13.21.115-1.el6 Moving to VERIFIED. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0742.html |