Bug 1110322
| Summary: | The installer hangs on detecting BTRFS partitions installed by RHEL7 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jiri Eischmann <eischmann> |
| Component: | coreutils | Assignee: | Ondrej Vasik <ovasik> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | admiller, anaconda-maint-list, eischmann, g.kaviyarasu, jonathan, kdudka, kzak, lczerner, ooprala, ovasik, p, twaugh, vanmeeuwen+fedora, vpodzime |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-10-03 13:00:08 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: | |||
|
Description
Jiri Eischmann
2014-06-17 12:50:53 UTC
Please attach the log files from /tmp to this bug as individual, text/plain attachments. I have the reproducer-laptop on my desk. The issue is that Anaconda tries to determine the architecture of the installed RHEL 7 system by running the 'arch' utility in the /mnt/sysimage chroot (the installed RHEL 7 system root). However, that hangs which hangs the whole Anaconda's storage-probing thread. Further investigation reveals that 'chroot /mnt/sysimage' doesn't work at all. Running 'strace chroot /mnt/sysimage' ends with access("/etc/ld.so.preload", R_OK) returning -1.
coreutils maintainers, any idea? Reassigning the bug cause it doesn't seem like anything anaconda could do something about.
So ENOENT? Or which errno? Is ltrace more helpful there? Adding Lukas Czerner to cc - as this might be btrfs filesystem issue - I haven't seen such report before. (In reply to Ondrej Vasik from comment #4) > So ENOENT? Or which errno? Is ltrace more helpful there? Adding Lukas > Czerner to cc - as this might be btrfs filesystem issue - I haven't seen > such report before. Don't have time now to run the whole process again to find out the errno, but listing the /etc/ dir didn't show the ld.so.preload file so I'm quite sure it was ENOENT. Probably the more important information is that an older compose (~2 weeks old) works without any issues on the same laptop. So it seems like some problematic change in 'chroot' or something related. No, there was no change in chroot or arch of these utilities in the past several months. I would suspect kernel or glibc more... Any update here? As I said, no change in chroot/arch in these days and I don't have reproducer here. I tend to close it insufficient data - as without further analysis it doesn't have sense to reassign to glibc/kernel - which was likely the culprit. (In reply to Ondrej Vasik from comment #7) > Any update here? As I said, no change in chroot/arch in these days and I > don't have reproducer here. I tend to close it insufficient data - as > without further analysis it doesn't have sense to reassign to glibc/kernel - > which was likely the culprit. I'm okay with CLOSED INSUFFICIENT_DATA. Ok, thanks, closing. |