Bug 1279019 - bootloader update failure is not detected
bootloader update failure is not detected
Status: NEW
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: redhat-upgrade-tool (Show other bugs)
6.7
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Michal Bocek
Release Test Team
: Extras
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-07 03:18 EST by Alois Mahdal
Modified: 2017-09-14 08:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alois Mahdal 2015-11-07 03:18:39 EST
Description of problem
======================

It's possible that even if bootloader update fails, redhat-upgrade-tool
will still finish with zero status and advice to go on with the upgrade.

This happens in one of use cases relevant to bug 1273867: a bug in
anaconda can lead to invalid record in zipl.conf.  If that happens,
zipl, called by r-u-t to to update bootloader will fail, but r-u-t does
not detect this.

    [...]
    HOOK-pkgdowngrades: INFO: DOWNGRADE: enforcing package installation 'tzdata.noarch'
    HOOK-pkgdowngrades: INFO: done
    Error: Image file '/boot/vmlinuz-2.6.32-573.el6.s390x.kdump' in section 'linux-kdump-2.6.32-573.el6.s390x.kdump': No such file or directory
    Error: Image file '/boot/vmlinuz-2.6.32-573.el6.s390x.kdump' in section 'linux-kdump-2.6.32-573.el6.s390x.kdump': No such file or directory
    redhat_upgrade_tool.sysprep WARNING: can't determine version of kernel image '/boot/vmlinuz-redhat-upgrade-tool'
    Error: Image file '/boot/vmlinuz-2.6.32-573.el6.s390x.kdump' in section 'linux-kdump-2.6.32-573.el6.s390x.kdump': No such file or directory
    Error: Image file '/boot/vmlinuz-2.6.32-573.el6.s390x.kdump' in section 'linux-kdump-2.6.32-573.el6.s390x.kdump': No such file or directory
    Continue with the upgrade [Y/N]? getting boot images...
    setting up update...
    testing upgrade transaction
    setting up system for upgrade
    Finished. Reboot to start upgrade.


Version-Release number of selected component
============================================

preupgrade-assistant-2.1.1-5.el6
preupgrade-assistant-contents-0.6.41-1.el6
redhat-upgrade-tool-0.7.43-1.el6


How reproducible
================

Always


Steps to Reproduce
==================

There are probably much more ways to have the bootloader update fail.
One of them, similar to the mentioned case:

 0. Install preupg et al. on an s390x machine

 1. Open /etc/zipl.conf, and add a boot record with `image=` path pointing
    to a non-existent file

 2. Run redhat-upgrade-tool with necessary parameters


Actual results
==============

redhat-upgrade-tool will finish with zero status, suggesting to re-boot
to start the upgrade


Expected results
================

redhat-upgrade-tool should detect the problem and gracefully exit
Comment 2 Alois Mahdal 2015-11-10 21:14:50 EST
Another case I managed to find by accident: is if you accidentally use different arch's repositories.

In this case, the message from sysprep is quite subtle:

    [....]
    HOOK-pkgdowngrades: INFO: DOWNGRADE: enforcing package installation 'python-requests.noarch'
    HOOK-pkgdowngrades: INFO: done
    redhat_upgrade_tool.sysprep WARNING: can't determine version of kernel image '/boot/vmlinuz-redhat-upgrade-tool'
    Continue with the upgrade [Y/N]? getting boot images...
    setting up update...
    testing upgrade transaction
    setting up system for upgrade
    Finished. Reboot to start upgrade.

In my case, it was s390x on x86_64.  Needless to say, the reboot is not possible with this setup; user will need to (manually?) select the original RHEL in bootloader menu.

(In theory, if a bootable combination existed, results could be worse---well, I don't think there is, at least not in *->RHEL7 but in future...)

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