I tried to installed Fedora Rawhide (2014-06-15) on a computer with RHEL 7 (installed on a BRTFS partition). The installer hangs recognizing partitions and the only thing I can do is to quit the installation.
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.