For many months now, almost all COPR jobs on armhfp have been failing.
Something like this: [...]
installing package guile22-2.2.7-2.fc34.armv7hl needs 201MB more space on the / filesystem installing package make-1:4.3-4.fc34.armv7hl needs 203MB more space on the / filesystem installing package gcc-11.0.0-0.19.fc35.armv7hl needs 270MB more space on the / filesystem installing package fuse3-libs-3.10.2-1.fc34.armv7hl needs 270MB more space on the / filesystem installing package fuse3-devel-3.10.2-1.fc34.armv7hl needs 270MB more space on the / filesystem installing package annobin-9.60-1.fc34.armv7hl needs 271MB more space on the / filesystem installing package valgrind-1:3.16.1-18.fc34.armv7hl needs 299MB more space on the / filesystem Error Summary ------------- Disk Requirements: At least 299MB more space needed on the / filesystem. Copr build error: Build failed
Taken from https://download.copr.fedorainfracloud.org/results/barsnick/fed-newer/fedora-34-armhfp/01966771-bindfs/builder-live.log.gz
Check the respective columns e.g. on one of my monitors: https://copr.fedorainfracloud.org/coprs/barsnick/fed-newer/monitor/
@praiskup I am thinking that whatever is doing the arm emulation is full?
Metadata Update from @smooge: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: aws, copr, medium-gain, medium-trouble, ops
It is this problem: https://bugzilla.redhat.com/show_bug.cgi?id=1895363
We applied work-around (disabling boostrap chroot in copr) for older chroots, but I bet that we should actually apply the work-around in mock-core-configs, too. This is taking too long to wait.
Ah no, the bootstrap is not on the "default" value, but explicitly enabled 'ON':100: https://copr.fedorainfracloud.org/coprs/barsnick/fed-newer/edit/
This beats our defaults defined by work-around: https://pagure.io/fedora-infra/ansible/blob/c394c808e671dbb12048c5e2da6a5d2b30e3b238/f/roles/copr/backend/files/provision/files/mock/fedora-rawhide-armhfp.cfg#_1-7
I think this is fixed now? if not, continue on upstream bug?
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
No, not fixed. I had a few jobs passing, but most of them are still starving on armhfp. https://copr.fedorainfracloud.org/coprs/barsnick/non-fed/builds/
@barsnick Please don't enable bootstrap for armhfp chroots. We intentionally keep bootstrap disabled there, as that's the only work-around we have now.
I never enabled anything explicitly, I just simply added these distro version architectures to my copr.
"Bootstrap" isn't documented either on the settings page nor in the docs. I'm pretty sure "Enable" was the default setting.
If there are no side effects, I guess I can just disable bootstrap (only globally, apparently). Actually, there are four options of which I do not know the impacts.
Okay, it's in the change notes. And those arch branches (and the issues) are older than said release 2020-11-13, AFAIR.
The bootstrap was enabled mistakenly about 4 years ago?, so you might be right that it is long-time inheritance (you have Project ID: 712). Those days we considered bootstrap immature, so we disabled it for newly created projects... and quite recently we turned bootstrap ON by default again. Sorry for being imprecise.
The thing is to use the "use mock-core-configs default" option now. Then you have bootstrap=on set for most of the chroots, and bootstrap=off for armhfp chroots.
Issue status updated to: Open (was: Closed)
Issue status updated to: Closed (was: Open) Issue close_status updated to: Fixed
Login to comment on this ticket.