Hide Forgot
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
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