View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000438 | AlmaLinux-8 | -OTHER | public | 2023-11-06 14:15 | 2023-11-06 15:36 |
| Reporter | kludge | Assigned To | |||
| Priority | normal | Severity | block | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0000438: Interesting issue with Leapp when upgrading from Centos 7 -- filesystem problem | ||||
| Description | So, I have a Centos 7 machine, and what was interesting about this system is that if you did a df -T, it listed the /run filesystem as being an xfs filesystem instead of tmpfs. I found this out when I run the leapp preupgrade script, and it failed with: 2023-11-06 08:34:30.873 DEBUG PID: 25972 leapp.workflow.FactsCollection.xfs_info_scanner: External command has started: ['/usr/sbin/xfs_info', '/run'] 2023-11-06 08:34:30.891 DEBUG PID: 25972 leapp.workflow.FactsCollection.xfs_info_scanner: xfs_info: specified file ["/run"] is not on an XFS filesystem 2023-11-06 08:34:30.898 DEBUG PID: 25972 leapp.workflow.FactsCollection.xfs_info_scanner: Command ['/usr/sbin/xfs_info', '/run'] failed with exit code 1. Which of course is a problem. So, I did a mount tmpfs -t tmpfs /run and it now shows up as tmpfs and everything is groovy there BUT... when I run a leapp preupgrade it still fails, as if the information is cached somewhere. So, I removed the database in /var/lib/leapp/ and that didn't fix the problem. So.... how do I get whatever cached data exists to be removed.... or how do I get the preupgrade to just skip over the xfs_info stuff... or how do I alter the cached data to get it to stop looking at /run? | ||||
| Steps To Reproduce | I don't know how to reproduce the problem per se because I don't know how you get a system in the first place with /run listed with the wrong filetype. For the time being I am not too worried about debugging that long-term since I hope to soon have an upgraded system anyway. | ||||
| Tags | No tags attached. | ||||
| abrt_hash | |||||
| URL | |||||
|
|
Okay, so I wrote a wrapper script to /sbin/xfs_info that ignores /run and that seems to be okay.... except.... new and related problem.... This system had the /etc/redhat-release tampered with it so that the security scanner run on our facility would think it was running a supported red hat version until such time as we could get upgraded to oracle 8.... and when I ran leapp preupgrade, it thought we were running redhat and came up with the error " Actor: target_userspace_creator Message: Cannot set the container mode for the subscription-manager." So, I put the original redhat-release file back, BUT.... leapp still keeps giving the same error because that data seems to be cached somewhere. Removing that database file and rebooting does nothing. Where is this being stored? |
