Bug 463564 - [LTC 6.0 FEAT] 201092:Firstboot for System z
[LTC 6.0 FEAT] 201092:Firstboot for System z
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: firstboot (Show other bugs)
6.1
s390x All
high Severity high
: beta
: 6.1
Assigned To: Martin Gracik
Release Test Team
: FutureFeature, OtherQA
: 633351 (view as bug list)
Depends On:
Blocks: 538808 580566 647893
  Show dependency treegraph
 
Reported: 2008-09-23 17:21 EDT by IBM Bug Proxy
Modified: 2013-07-04 08:46 EDT (History)
10 users (show)

See Also:
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 10:20:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description IBM Bug Proxy 2008-09-23 17:21:46 EDT
=Comment: #0=================================================
Emily J. Ratliff <emilyr@us.ibm.com> - 2008-09-16 18:03 EDT
1. Feature Overview:
Feature Id:	[201092]
a. Name of Feature:	Firstboot for System z
b. Feature Description
Make firstboot available and work on System z. Note, we do not request for first boot run with a
3270 terminal but it should be runnable both out of a standard terminal (e.g. vt220 or xterm) and
once a graphical interface is available via X11 and vnc.  Related bugzillas are BZ36226 - RIT126279
and RH BZ 217921.

Additional Comments:	This feature is for validation, it is expected to get included into RHEL5.3 LTC
37758 - RHBZ 217921: 201092: Firstboot for System z

2. Feature Details:
Sponsor:	zSeries
Architectures:
s390x

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
Improve ease of use for RHEL.  Do not repel customer evaluating RHEL.

4. Primary contact at Red Hat: 
John Jarvis
jjarvis@redhat.com

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-23 18:49:04 EDT
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.
Comment 2 Gonzalo Muelas Serrano 2008-09-24 13:41:19 EDT
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.
Comment 3 IBM Bug Proxy 2009-02-06 04:50:58 EST
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.
Comment 4 Shawn Wells 2009-08-12 12:11:17 EDT
Since it's been a few months since the last comment, how goes Firstboot for System z?  Any update?
Comment 5 IBM Bug Proxy 2010-01-13 08:51:01 EST
------- Comment From gmuelas@de.ibm.com 2010-01-13 08:45 EDT-------
Hello Red Hat,

any updates here?

Thank you!
Comment 6 David Cantrell 2010-01-15 20:45:11 EST
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?
Comment 7 John Jarvis 2010-02-05 11:27:11 EST
We are out of capacity to complete this for RHEL 6.0, adding to RHEL 6.1
tracker for consideration for that release.
Comment 8 Martin Gracik 2010-02-17 12:49:07 EST
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 9 IBM Bug Proxy 2010-04-16 06:21:08 EDT
------- Comment From mgrf@de.ibm.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 11 IBM Bug Proxy 2010-09-08 06:51:09 EDT
------- Comment From mgrf@de.ibm.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?
Comment 12 David Cantrell 2010-09-13 16:00:23 EDT
*** Bug 633351 has been marked as a duplicate of this bug. ***
Comment 13 John Jarvis 2010-09-23 13:45:07 EDT
IBM is signed up to test and provide feedback.  Setting OtherQA
Comment 14 IBM Bug Proxy 2010-10-04 12:09:17 EDT
------- Comment From rsisk@us.ibm.com 2010-10-04 11:32 EDT-------
Code Upstream Status: In Progress
Comment 15 IBM Bug Proxy 2010-10-04 12:36:54 EDT
------- Comment From rsisk@us.ibm.com 2010-10-04 10:42 EDT-------
Code Upstream Status: No Code Required
Comment 16 Martin Gracik 2010-12-10 06:45:39 EST
Fixed in version firstboot-1.110.9-1
Comment 17 John Jarvis 2011-01-13 13:59:55 EST
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.
Comment 21 Florian Nadge 2011-02-11 05:34:10 EST
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
Comment 22 Florian Nadge 2011-02-11 05:34:11 EST
    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.
Comment 23 Jan Stodola 2011-02-14 09:37:35 EST
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.
Comment 24 David Cantrell 2011-02-14 15:02:36 EST
(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.
Comment 25 Martin Gracik 2011-02-15 02:40:43 EST
Yes, thanks for making the anaconda patch.
Comment 26 David Cantrell 2011-02-15 14:58:17 EST
(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.
Comment 27 Martin Gracik 2011-02-16 06:53:18 EST
    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.
Comment 29 Chris Ward 2011-04-06 07:06:19 EDT
~~ 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!
Comment 30 Jan Stodola 2011-04-27 10:35:05 EDT
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.
Comment 31 errata-xmlrpc 2011-05-19 10:20:04 EDT
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

Note You need to log in before you can comment on or make changes to this bug.