Version-Release number of selected component: mock-1.4.21-1.fc32 Additional info: reporter: libreport-2.11.3 cgroup: 0::/user.slice/user-1000.slice/user/gnome-terminal-server.service cmdline: /usr/bin/python3 -tt /usr/libexec/mock/mock -r fedora-rawhide-i386 --resultdir /home/mikhail/packaging-work/mesa/results_mesa/19.3.0~rc4/1.fc32 --rebuild /home/mikhail/packaging-work/mesa/mesa-19.3.0~rc4-1.fc32.src.rpm crash_function: logOutput exception_type: KeyboardInterrupt executable: /usr/libexec/mock/mock interpreter: python3-3.8.0-1.fc32.x86_64 kernel: 5.4.0-0.rc8.git0.2.fc32.x86_64 runlevel: N 5 type: Python3 uid: 0 Truncated backtrace: #1 [/usr/lib/python3.8/site-packages/mockbuild/util.py:551] logOutput #2 [/usr/lib/python3.8/site-packages/mockbuild/util.py:705] do_with_status #3 [/usr/lib/python3.8/site-packages/mockbuild/trace_decorator.py:95] trace #4 [/usr/lib/python3.8/site-packages/mockbuild/util.py:652] do #5 [/usr/lib/python3.8/site-packages/mockbuild/plugins/selinux.py:106] _selinuxDoYum #6 [/usr/lib/python3.8/site-packages/mockbuild/trace_decorator.py:95] trace #7 [/usr/lib/python3.8/site-packages/mockbuild/package_manager.py:154] execute #8 [/usr/lib/python3.8/site-packages/mockbuild/trace_decorator.py:95] trace #9 [/usr/lib/python3.8/site-packages/mockbuild/package_manager.py:195] builddep #10 [/usr/lib/python3.8/site-packages/mockbuild/trace_decorator.py:95] trace
Created attachment 1639906 [details] File: backtrace
Created attachment 1639907 [details] File: cpuinfo
Created attachment 1639908 [details] File: environ
Created attachment 1639909 [details] File: mountinfo
Created attachment 1639910 [details] File: namespaces
Created attachment 1639911 [details] File: open_fds
To reproduce this, simply start a mock build, wait a couple of seconds, then hit Control-C. Now try to start the mock build again and you get this error. The user cannot fix it. Mock doesn't clean up the problem itself, nor does mock --clean, and the user doesn't have permission to unmount the problematic filesystem. Only root can unmount the filesystem so that the buildroot is usable again. Note that recently, I've found myself needing to sudo umount *two* filesystems: <mock-root>/root/proc/filesystems <mock-root>/root/var/cache/dnf It would be great if mock --clean, at least, could do that.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
I believe those two, especially the second ... https://github.com/rpm-software-management/mock/commit/2ecc9071df3cf2ceb10765c65abc8a8d82414b57 https://github.com/rpm-software-management/mock/commit/2185a51110e7129c90b61ac3abd7cefcd6c458da ... fixed these kind of issues. My explanation would that -> we killed `dnf install` command in the middle of the transaction -> some background process was kept working hard on background -> the process had opened some file descriptors that refused mock to umount all the mountpoins -> mock failed hard, and -> the mount layout ended up in inconsistent state enough so even further `mock --scrub=all` failed. I'm attaching this into 2.2 bodhi update. Please reopen if you see the same problems with mock 2.2+.
FEDORA-2020-fba9845e22 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fba9845e22
FEDORA-2020-6b7c342fb4 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6b7c342fb4
FEDORA-2020-85df0014c1 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-85df0014c1
FEDORA-2020-fba9845e22 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-fba9845e22` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fba9845e22 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-85df0014c1 has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-85df0014c1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-85df0014c1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-6b7c342fb4 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6b7c342fb4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6b7c342fb4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-fba9845e22 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-6b7c342fb4 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-85df0014c1 has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report.