Learn more about these different git repos.
Other Git URLs
I don't know what is happening or why. But for a few days, i686 builds have been randomly failing linker issues due to /usr/bin/ld not being found by compilers.
For example: https://koji.fedoraproject.org/koji/taskinfo?taskID=120389816
This is apparently happening on both rawhide and f40 and possibly other branches too.
It does not seem to be a persistent issue with buildroots, since resubmitted builds usually succeed.
Would be great to get fixed before the mass rebuild. Otherwise there might be a high number of random failures.
N/A
Random build failures on i686 continue until morale improves.
All the failures I found seemed to be on buildhw-x64-12, so I disabled that builder...
but looking in the failed chroots, it looks like there's no ld link, which should be made by alternatives. :( I do see ld.bfd there installed just fine.
So, could this be some sbin move/alternatives race? Or something else.... not sure.
So, have you (or anyone else) seen this since I disabled that builder?
Metadata Update from @phsmoura: - Issue tagged with: low-gain, low-trouble, ops
I haven't seen it, but I haven't done any koji builds in the last two days, so it's not really a good sample :(
In the past, this was a side effect of update-alternatives experiencing breakage due to 64-bit inode numbers. It's just the first issue that breaks. I don't it's a good use of our time to fix chkconfig because lots of other things will be broken by this, too.
update-alternatives
chkconfig
If the builder uses btrfs, you need to recreate the file system. If it's XFS, there's a mount option (inode32, recommended for 32-bit chroots only). I don't think ext4 has this problem.
inode32
Yeah, I remember that issue, but this machine wasn't installed longer ago than any others I don't think. ;(
Is there some way to see if it's actually affected by that? It is btrfs... I can definitely just reinstall it, but would be good to confirm thats what was going on...
@kevin Just create a file in the relevant file system and obtain its inode number:
$ touch file $ ls -i file 327287527 file
In my case, it's at about 15% utilization.
Ah ha. Right, that makes sense. Thanks.
This was indeed that issue and I long since fixed that builder. Will keep a eye out for any getting near.
Metadata Update from @kevin: - Issue close_status updated to: Fixed with Explanation - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.