Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1901440

Summary: leapp upgrade fails in reboot phase when /boot is merged into / on zVM
Product: Red Hat Enterprise Linux 7 Reporter: Renaud Métrich <rmetrich>
Component: leapp-repositoryAssignee: Leapp team <leapp-notifications>
Status: CLOSED ERRATA QA Contact: smitterl
Severity: high Docs Contact:
Priority: high    
Version: 7.9CC: cbesson, dhorak, fkrska, held, pstodulk, smitterl
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: leapp-repository-0.18.0-1.el7_9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-17 15:00:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1818077, 1818088    
Attachments:
Description Flags
zipl actor to reproduce on x86_64 systems (assumes /boot is not a dedicated partition)
none
Proposal (minimal, doesn't handle "leapp upgrade" retries on failure) none

Description Renaud Métrich 2020-11-25 08:43:53 UTC
Created attachment 1733292 [details]
zipl actor to reproduce on x86_64 systems (assumes /boot is not a dedicated partition)

Created attachment 1733292 [details]
zipl actor to reproduce on x86_64 systems (assumes /boot is not a dedicated partition)

Description of problem:

When /boot is not a dedicated partition, on Z systems, the leapp upgrade fails after rebooting, when the actor "remove_boot_files" deletes the upgrade initramfs/vmlinuz from /boot:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
ERROR    PID: 688 leapp.workflow.Preparation.remove_boot_files: Could not remove /boot/vmlinuz-upgrade.s390x: [Errno 2] No such file or directory: '/boot/vmlinuz-upgrade.s390x'.
ERROR    PID: 688 leapp.workflow.Preparation.remove_boot_files: Could not remove /boot/initramfs-upgrade.s390x.img: [Errno 2] No such file or directory: '/boot/initramfs-upgrade.s390x.img'.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This is a consequence of a severe bug happening when the "zipl_convert_to_blscfg" actor executes: a bind mount of /boot is made onto /var/lib/leapp/el8userspace/boot, zipl runs, then a cleanup of the bind mount /var/lib/leapp/el8userspace/boot is performed *without* unmounting it, causing a deletion of the content of host's /boot:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
DEBUG    PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: External command has started: ['rm', '-rf', u'/var/lib/leapp/el8userspace/boot']
DEBUG    PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: External command has finished: ['rm', '-rf', u'/var/lib/leapp/el8userspace/boot']
DEBUG    PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: External command has started: ['mount', '-o', 'bind', '/boot', u'/var/lib/leapp/el8userspace/boot']
DEBUG    PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: External command has finished: ['mount', '-o', 'bind', '/boot', u'/var/lib/leapp/el8userspace/boot']
DEBUG    PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: External command has started: ['systemd-nspawn', ...]
DEBUG    PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: External command has finished: ['systemd-nspawn', ...]
DEBUG    PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: External command has started: ['rm', '-rf', u'/var/lib/leapp/el8userspace/boot']
lib/leapp/el8userspace/boot': Device or resource busy^
DEBUG    PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: Command ['rm', '-rf', u'/var/lib/leapp/el8userspace/boot'] failed with exit code 1.
DEBUG    PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: External command has finished: ['rm', '-rf', u'/var/lib/leapp/el8userspace/boot']
WARNING  PID: 527 leapp.workflow.Preparation.zipl_convert_to_blscfg: Removing mount directory /var/lib/leapp/el8userspace/boot failed with: Command ['rm', '-rf', u'/var/lib/leapp/el8userspace/boot'] failed with exit code 1.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

The root cause for all this is Python2's bug https://bugs.python.org/issue29707: in a nutshell, "os.path.ismount(<mount>)" for Bind mounts is not working, in particular when the Bind mount is done on the same device (our case here), as shown in the example below (/mnt is hosted on /, /bind_mount also):

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# mkdir /bind_mount
# mount -o bind /mnt /bind_mount

# mount | grep bind
/dev/vda1 on /bind_mount type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

# python2 -c 'import os; print os.path.ismount("/bind_mount")'
False
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Due to using unreliable os.path.ismount() in "mounting.py" library, this breaks:

/usr/share/leapp-repository/repositories/system_upgrade/el7toel8/libraries/mounting.py:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
    def _cleanup(self):
        """ Cleanup operations """
        if os.path.exists(self.target) and os.path.ismount(self.target):        <<<<<<<<<<<<<<<< BREAKS HERE
            try:
                run(['umount', '-fl', self.target], split=False)
            except (OSError, CalledProcessError) as e:
                api.current_logger().warning('Unmounting %s failed with: %s', self.target, str(e))
        for directory in itertools.chain(self.additional_directories, (self.target,)):   <<<<<<< DELETE WHILE NOT UMOUNTED!
            try:
                run(['rm', '-rf', directory], split=False)
            except (OSError, CalledProcessError) as e:
                api.current_logger().warning('Removing mount directory %s failed with: %s', directory, str(e))
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


Version-Release number of selected component (if applicable):

leapp-repository-0.12.0-2.el7_9.noarch


How reproducible:

Always on Z with /boot merged into /


Steps to Reproduce: Hack to reproduce on any x86_64 system with /boot merged into /

1. Hack /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/ziplconverttoblscfg/actor.py to execute on x86_64

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
@@ -21,8 +21,8 @@ class ZiplConvertToBLSCFG(Actor):
     tags = (IPUWorkflowTag, PreparationPhaseTag)
 
     def process(self):
-        if not architecture.matches_architecture(architecture.ARCH_S390X):
-            return
+        #if not architecture.matches_architecture(architecture.ARCH_S390X):
+        #    return
         userspace = next(self.consume(TargetUserSpaceInfo), None)
         if not userspace:
             # actually this should not happen, but in such case, we want to still
@@ -44,15 +44,15 @@ class ZiplConvertToBLSCFG(Actor):
                 os.remove(userspace_zipl_conf)
             with mounting.NullMount(target=userspace.path) as userspace:
                 with userspace.nspawn() as context:
-                    context.copy_to('/etc/zipl.conf', '/etc/zipl.conf')
-                    # zipl needs this one as well
-                    context.copy_to('/etc/machine-id', '/etc/machine-id')
+                    #context.copy_to('/etc/zipl.conf', '/etc/zipl.conf')
+                    ## zipl needs this one as well
+                    #context.copy_to('/etc/machine-id', '/etc/machine-id')
                     try:
-                        context.call(['/usr/sbin/zipl-switch-to-blscfg'])
-                        if filecmp.cmp('/etc/zipl.conf', userspace_zipl_conf):
-                            # When the files are same, zipl failed - see the switch script
-                            raise OSError('Failed to convert the ZIPL configuration to BLS.')
-                        context.copy_from('/etc/zipl.conf', '/etc/zipl.conf')
+                        context.call(['/usr/bin/true'])
+                        #if filecmp.cmp('/etc/zipl.conf', userspace_zipl_conf):
+                        #    # When the files are same, zipl failed - see the switch script
+                        #    raise OSError('Failed to convert the ZIPL configuration to BLS.')
+                        #context.copy_from('/etc/zipl.conf', '/etc/zipl.conf')
                     except OSError as e:
                         self.log.error('Could not call zipl-switch-to-blscfg command.',
                                        exc_info=True)
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

(File attached for convenience)

2. leapp upgrade and reboot

Actual results:

Dies deleting /boot/*-upgrade* files + content of /boot of host being deleted


Expected results:

No deletion of /boot content


Additional info:

This is only reproducible on zVM because the affected actor only runs on Z, but potentially could affect any future update of leapp-repository.

Comment 5 Renaud Métrich 2020-11-25 09:20:14 UTC
Created attachment 1733301 [details]
Proposal (minimal, doesn't handle "leapp upgrade" retries on failure)

Comment 6 Petr Stodulka 2021-01-28 11:41:24 UTC
The fix will be delivered via the PR:
    https://github.com/oamg/leapp-repository/pull/634

Currently, it will fix this one particular issue. More generic fix for additional corner-cases will be delivered separately in future.

Comment 7 Petr Stodulka 2021-02-04 19:55:17 UTC
The fix mentioned above is causing additional issues in case of s390x machine. Regarding the urgency of the problem we have discovered to inhibit the upgrade (for now) for s390x machines when /boot is part of the rootfs:
-  https://github.com/oamg/leapp-repository/pull/641

Renaud, do you want to keep this BZ opened until the upgrade for such machines is possible or is the current fix ok for this particular BZ? (both works for me)

Comment 9 Renaud Métrich 2021-02-08 07:30:09 UTC
Hi Petr,

Please keep the BZ open until we have a real fix, we will need a fix anyway.

Renaud.

Comment 12 Mario Held 2022-12-06 10:31:40 UTC
The same problem was detected meanwhile on RHEL-8.7 (see https://bugzilla.redhat.com/show_bug.cgi?id=2129716). Could you please provide a fix which works for s390x machines.

Comment 13 smitterl 2022-12-15 17:02:51 UTC
IIUC, we have a draft fix for this upstream - https://github.com/oamg/leapp-repository/pull/991 but we didnt' have time to test this yet.

Comment 14 smitterl 2022-12-15 17:07:36 UTC
If somebody has the opportunity to test this before we can, the build is available at https://copr.fedorainfracloud.org/coprs/g/oamg/leapp/repo/epel-7/group_oamg-leapp-epel-7.repo where $basearch must be substituted by x86_64 (even on s390x)

# yum install "leapp-upgrade*pr991*"

Installs the package.

Comment 17 Petr Stodulka 2023-01-03 16:42:12 UTC
We have positive test results from IBM. Merging the PR in upstream. The fix will be part of the next build:
* https://github.com/oamg/leapp-repository/pull/991

Comment 21 Petr Stodulka 2023-01-23 14:03:26 UTC
This BZ is expected to be testing in cooperation with IBM. We have already positive feedback from upstream pre-testing. The analogical bug 2129716 is going to be tested for RHEL 8 where the very same fix is going to be delivered too.

Comment 23 smitterl 2023-01-24 14:37:41 UTC
It looks to me like the fixed in Version leapp-repository-0.17.0-5.el7_9 is wrong, Petr?

Comment 24 Petr Stodulka 2023-01-24 14:54:29 UTC
Hi Sebastian, it should be correct, but I forgot to update the release in the erratum - if you refer to that - thanks for the ping. It should be fixed now. Let me know if there is a different problem. I am sorry for the mistake - too much tickets & processes. The final build will contain bumped release (0.18.0).

Comment 25 Petr Stodulka 2023-01-24 14:55:33 UTC
corr: s/bumped release/bumped version/

Comment 26 smitterl 2023-01-24 15:51:55 UTC
The package is not yet in the latest EXTRA repo, I'll check some other day.

Comment 28 smitterl 2023-01-30 16:30:38 UTC
Confirmed with leapp-repository-0.17.0-5.el7_9 and /boot a mere folder on / that upgrade 7->8 succeeded (--no-rhsm).

Comment 29 Petr Stodulka 2023-02-27 10:51:58 UTC
The fix has been dropped in leapp-repository-0.17.0-9.el7_9 due to unplanned async release and will be added back after the rebase.

Comment 32 smitterl 2023-03-21 16:06:36 UTC
Versions:
leapp data https://github.com/oamg/leapp-repository/tree/32dc6b0ee9f2d91af1f3406b567e1237ac6d0769/etc/leapp/files (when using the official tar.gz leapp-data-21 I get an error)
leapp-upgrade-el7toel8-0.18.0-1.el7_9.noarch

I fail to finish preupgrade --no-rhsm. Error:

    Stderr: Host and machine ids are equal (9a34b694ac454a9e88d9a98004c2cb1e): refusing to link journals                                
            Failed to synchronize cache for repo 'baseos8', ignoring this repo.                                                         
            Failed to synchronize cache for repo 'appstream8', ignoring this repo.                                                      
            Error: Unable to find a match: dnf dnf-command(config-manager)


I believe the "Host and machine..." can be ignored.
Also, I believe the "Error: Unable to find match..." would be fixed if the caches for the RHEL 8 repos could be sync'd.
I checked and the repos in our leapp_upgrade_repositories.repo file look correct to me.

Petr, please can you help?

Comment 34 smitterl 2023-03-21 16:11:06 UTC
Nevermind, my custom repositories had https urls. After changing to http everything works now.

Comment 35 smitterl 2023-03-21 17:08:36 UTC
Verified
leapp data https://github.com/oamg/leapp-repository/tree/32dc6b0ee9f2d91af1f3406b567e1237ac6d0769/etc/leapp/files 
leapp-upgrade-el7toel8-0.18.0-1.el7_9.noarch

Comment 37 errata-xmlrpc 2023-05-17 15:00:24 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 (leapp and leapp-repository bug fix and enhancement update), and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHBA-2023:3187