Bug 730023

Summary: Anaconda ignores non-zero status when writing bootloader
Product: Red Hat Enterprise Linux 6 Reporter: Jan Stodola <jstodola>
Component: anacondaAssignee: Samantha N. Bueno <sbueno>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: brueckner, jreed, ovasik, tlavigne
Target Milestone: rc   
Target Release: ---   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: anaconda-13.21.193-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 09:58:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 767187, 691780, 840685    
Attachments:
Description Flags
/tmp/*log none

Description Jan Stodola 2011-08-11 14:59:22 UTC
Created attachment 517824 [details]
/tmp/*log

Description of problem:
Latest nightly build of RHEL6.2 discovered a bug which appears when /boot is placed on LVM and user try to run 'zipl':

[root@rtt6 ~]# zipl
Using config file '/etc/zipl.conf'
Run /lib/s390-tools/zipl_helper.device-mapper /boot/
Error: Unrecognized device-mapper table format for device 'dm-2'
Error: Script could not determine target parameters
[root@rtt6 ~]# echo $?
1

This bug is about anaconda not showing any error/warning message when this type of error happens at the end of the installation. Instead of warning message, user see the "Congratulation" screen asking to reboot.

/tmp/program.log:
...
10:30:14,105 INFO    : Running... ['zipl']
10:30:14,180 INFO    : Using config file '/etc/zipl.conf'
10:30:14,180 INFO    : Run /lib/s390-tools/zipl_helper.device-mapper /boot/
10:30:14,180 ERROR   : Error: Unrecognized device-mapper table format for device 'dm-0'
10:30:14,181 ERROR   : Error: Script could not determine target parameters
10:30:14,212 INFO    : Running... ['chreipl', 'node', '/dev/dasdb']
...

Version-Release number of selected component (if applicable):
anaconda-13.21.126-1.el6
device-mapper-1.02.65-1.el6
RHEL6.2-20110811.n.0

How reproducible:
always

Steps to Reproduce:
1. run installation
2. make sure /boot is on lvm
3. finish the installation
4. check /tmp/program.log before reboot
  
Actual results:
errors when writing bootloader are shown in program.log, but user doesn't see any message in GUI/TUI

Expected results:
if there is an error writing bootloder, anaconda should display some warning/error screen

Comment 1 David Cantrell 2011-08-15 15:48:16 UTC
anaconda does handle non-zero return codes from the boot loader we're installing.  We catch that and display an error to the user.  In this case, it looks like zipl is not handling the failure from zipl_helper.device-mapper correctly.  In zipl/src/disk.c, it uses popen() to run the helper script and capture the output, but only checks to see if the output is empty, not any return codes from the helper script.

Reassigning.

Comment 3 Dan HorĂ¡k 2012-01-23 11:57:03 UTC
zipl seems to work correctly (s390utils-base-1.8.2-39.el6.s390x)

[root@devel2 ~]# zipl -V
Using config file '/etc/zipl.conf'
Run /lib/s390-tools/zipl_helper.device-mapper /boot/
Error: Script could not determine target parameters
[root@devel2 ~]# echo $?
1

but the writeZipl() method in booty/s390.py returns 0 in every case and IMHO the possible error is not propagated to upper layers

        ...
        if not justConfigFile:
            rc = iutil.execWithCapture("zipl", [], root = instRoot,
                                       stderr = "/dev/stderr")
            for line in rc.splitlines():
                if line.startswith("Preparing boot device: "):
                    # Output here may look like:
                    #     Preparing boot device: dasdb (0200).
                    #     Preparing boot device: dasdl.
                    # We want to extract the device name and pass that.

                    fields = line[23:].split()
                    self.setDevice(fields[0].replace('.', ''))

        return 0

Comment 7 Jesse Keating 2012-07-03 18:45:52 UTC
The problem is that we're calling iutil.execWithCapture() which does not concern itself with the return value of the execution, just whether or not a python error was generated.

We grab the output for parsing and grabbing the device used for zipl in a kickstart config, but this may not actually be used because zipl doesn't take a device option.

Discussing with team members how best to handle this.

Comment 8 Jesse Keating 2012-07-03 21:20:49 UTC
Patch posted to resolve this issue.

Comment 9 Jesse Keating 2012-07-05 17:10:07 UTC
Pushed upstream (master) as ee29fa9f1861787fb8e173d22c3bd39bef15a26e and 888e8d4a01045a59221d4b941e8346f50caed8dd  The second commit will have to be modified so that the changes go to booty/s390.py on rhel6 as opposed to pyanaconda/bootloader.py on master.

Comment 10 RHEL Product and Program Management 2012-07-16 22:46:17 UTC
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Comment 20 Jan Stodola 2013-01-07 11:41:37 UTC
Results from testing of updates.img from comment 19 look good, both tested cases passed:

1) If the kernel command line is too long, anaconda reports:
"There was an error installing the bootloader.
The system may not be bootable."

After clicking "OK", anaconda proceed to the final screen and user is able to reboot. Installed system will not boot, which is expected.

2) If the kernel command line is not longer than zipl limit, installation finishes without any issue.

Comment 21 Samantha N. Bueno 2013-01-07 16:06:06 UTC
(In reply to comment #20)
> Results from testing of updates.img from comment 19 look good, both tested
> cases passed:

Great; thanks for the help. Patches posted to resolve the issue.

Comment 24 Jan Stodola 2013-01-10 15:27:02 UTC
Retested on compose RHEL6.4-20130109.1 with anaconda-13.21.193-1.el6.
An error message is shown when bootloader fails to be installed.

Thanks, moving to VERIFIED.

Comment 25 errata-xmlrpc 2013-02-21 09:58:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0373.html