Bug 2178951
| Summary: | Leapp upgrade hangs to 8.x | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | walid.douagi <walid.douagi> | ||||||||
| Component: | leapp-repository | Assignee: | Leapp Notifications Bot <leapp-notifications-bot> | ||||||||
| Status: | NEW --- | QA Contact: | upgrades-and-conversions | ||||||||
| Severity: | urgent | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 7.9 | CC: | cbesson, igulina, lagordon, pstodulk, walid.douagi | ||||||||
| Target Milestone: | rc | Keywords: | Upgrades | ||||||||
| Target Release: | --- | Flags: | walid.douagi:
needinfo-
|
||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| 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: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
walid.douagi@avaxia-group.com
2023-03-16 09:29:55 UTC
Created attachment 1951215 [details]
screenshot of leapp log
Hello, thank you for the report. We are not able to reproduce the issue in our scenarios so cannot say why this is happening, so we need /var/lib/leapp/leapp.db and the sosreport to be able to do any investigation. Also, from the view of the storage in the screenshot, it's possible you do not have enough space on /var. So I would try to extend the size of /var partition. In case the system has XFS partitions formatted without ftype attributes (default until RHEL 7.3), it's most likely the root cause. Created attachment 1952282 [details]
leapp db
Created attachment 1952284 [details] sosreport link https://we.tl/t-ALHzWfvO9w @pstodulk Thanks for your feedback, I uploaded db file and the sosreport. regarding to /var, it is enough space that usually I use it and no issue on that. using XFS type, I already upgraded the Quality system from 7.9 to 8.6 without issues as shown with screenshots on this link https://we.tl/t-5GGxzvsE9u. Hi, sorry for the late response. Neither of we.tl links works for me - I get to page but cannot download anything - seeing just adverts. Regarding leapp.db file, we have possibly enough information for further investigation, but possibly we will need later the sosreport also. When you speak about the Quality system, do you mean a different system or the same one? If a different one, the leapp.db file from such system (should be still present unless leapp packages have been already removed manually to finish the upgrade) could help us to see differences between those systems. Currently we are busy, so cannot say when we will be able to continue with the additional investigation. Additional notes: * Detected SAP solutions on Azure (adding Irina Gulina to Cc) * I see some parameters are different from the standard / default XFS format used in my VM which could be (but does not have to) related to the issue. * * We should compare it with the configuration on our Azure machines, just to see whether it's possible clue or not. * System seems to be up-to-date regarding the installed packages Just got a tip, that you could try to enforce our XFS ftype=0 workaround solution for your all XFS partitions, however it will need much more space on /var/lib/leapp. In case it works, we will know it's caused by some parameters used for XFS partitions:
~~~
In /usr/share/leapp-repository/repositories/system_upgrade/common/libraries/overlaygen.py insert one line (52) to define an array in _prepare_required_mounts():
46 def _prepare_required_mounts(scratch_dir, mounts_dir, mount_points, xfs_info):
47 result = {
48 mount_point.fs_file: mounting.NullMount(
49 _mount_dir(mounts_dir, mount_point.fs_file)) for mount_point in mount_points
50 }
51
52 xfs_info.mountpoints_without_ftype = [ "/", "/var", "/usr", "/boot" ] # <<< e.g. like this. adapt to your list of XFS partitions
53 if not xfs_info.mountpoints_without_ftype:
54 return result
~~~
In case you have a possibility set up a dedicated partition for /var/lib/leapp to extend the needed storage space for the experiment, it could be possibly the easiest way to handle it (format such a partition with EXT4 in such a case).
See "How to set up a dedicated /var/lib/leapp for upgrade" for detail instructions:
https://access.redhat.com/solutions/5057391
It's just a try.
Just sharing the info we have already sos report provided from one of our customers who hit the very same issue so no other needed data is required. Sharing the info that inmounting /usr/sap and /opt/sap before the leapp executions resolved the problem. No idea still what caused the original issue exactly. |