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.

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

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.

Patch posted to resolve this issue.

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.

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.

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.

(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.

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.

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