They just changed/added Fastly as their CDN provider to see how that goes. This changes nothing, yet I see their mirror reinstated. See @parumoe ‘s argument. I strongly disagree with how the issue is being handled.
Small decisions like this will affect how Linux users perceive Fedora. Don’t make rash decisions. I’m not doing this out of spite. I really do care about Fedora and Linux community as a whole.
님,
제 mirrorwatch 스크립트 업데이트 하겠습니다. 생각해보니 KRFOSS 분들이 IP 기반 차단할 것 같아서. AWS Lambda로 공짜로 돌리기 쉽도록 수정할 계획. 원하신다면 저하고 같이 직접 돌리셔서 데이터 수집 같이 하시면 감사하겠습니다. 한 2-3개월 뒤에 또 터질 문제 같아서요.
이분들 일 처리한 것 보니까, 그냥 몇번 장애 터진걸로 간주하고 대충 넘어가려는 것 같음. 할건 제대로 하고 넘어가아죠. 왜 당사자가 해야 할 일을 내가 하고 있는지 모르겠네요… 하하.
There was a conversation on ROKFOSS Discord that didn’t seem to like Fedora that much.
수선화 (DevNergis) : I’m staying away from Fedora.
ㄴ Replying to 수선화 (DevNergis)
ㄴ ㄱㅁㅇ(kmw_) : I’m skipping it too.
하늘 (고요한하늘) : Let’s just toss it far away.
To add some context, this was the conversation when they received an error inquiry regarding the Fedora mirror back in October.
I find that a good direction they should work towards. That conversation should have been publicly available in the first place. Discord is not a good platform for the job by its closed nature.
By the tone of the conversation(basically bullying Fedora as a whole), that screenshot alone should be evidence good enough for grounds to oust them. Redhat do take the code of conduct seriously.
Thank you for sharing the info. If you could save the conversation in any publicly verifiable format(I doubt it’s possible in Discord, tho), that’d be nice. If they just choose to back out on their own accord, that gets rid of having to maintain the script I made.
Anyway, there’s a bug in libdnf where another mirror is not tried in metadata retrieval and validation phase. Fixing this in dnf will solve this issue altogether without fixing mirorrlist2 or the like. There’s two implementations of dnf(pre v5 in Python and v5 in C++), so there will be some time before the fix reaches the mainline.
In the meantime, if you’re having trouble caused by KRFOSS, you can always add &country= query param to your conf. In the lines found in /etc/yum.repos.d/fedora*.repo:
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
you could add &country=us or &country=jp, if you want faster response time.
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch&country=us
That’s if you didn’t know how to do this already 
. Just helping a mate out.
You have read a chat from some discord server that you didn’t like → Now you want other contributors ousted for this alone.
You had a conversation with me that you didn’t like → Now you advise others to shun me.
@dxdxdt Is exclusion really the only solution you see for people you dislike? Do you think exclusion is the way to build a healthy community?
I think the point you are trying to make could be valid. I think that there really could be problems with this mirror. I only very much disapprove the “solution” you want to enforce. And I disapprove of you arguing ad hominem.
It’s not good to use such discriminatory language.
I agree.
However, if hating community members is the issue, I believe the fact that derogatory remarks about the Fedora community were made in the official ROKFOSS Discord is already a serious and problematic matter in itself.
Furthermore, the participants in the conversation weren’t ordinary users.
The key point is that all of them are ROKFOSS mirror contributors.
수선화 (DevNergis) is one of the ROKFOSS developers, ㄱㅁㅇ (kmw_) is a ROKFOSS project contributor, and 하늘 (고요한 하늘) is the operator of ROKFOSS’s fifth official mirror.
The fact that these ROKFOSS contributors made such remarks seems like a major problem.
I was of the impression that the issue being discussed was a malfunction in one of the Fedora Mirrors, not some interpersonal drama. If it is a technical problem, then arguing ad hominem is wrong.
Where do you think this attitude of “they talk bad about you so I’ll go to you and talk bad about them so that you will be angry at them” will get us? You say they talk bad about Fedora and you say that that is a bad thing. So you create an account here and talk bad about them. Think about the implications.
This is all I have to say.
Would you please stay out of it if you’re not going to help while we’re trying to have a constructive discussion here?
The problem still persists as of 2026-04-17T09:09:52+00:00. You wanted the data, here’s your data. Just changed from HTTP 522/404 to 502. As I said, nothing changed.
@kmw0915 if you don’t love us, leave us. That’s all we’re asking.
I am sorry, I couldn’t tell.
I would like to sincerely apologize to all the contributors at ROKFOSS for my disrespectful remarks.
However, since quality control issues seem to keep coming up, I believe it’s better to find a solution rather than continuing this emotional back-and-forth.
Great, because all you have to do for that is wait a little, since @kevin , who is on the Fedora Engineering Steering Committee (FESCO, which is the technical leadership in Fedora), already offered to look into this when he has the time.
I mean, you already had the problem recognized by a FESCO member, there was really no need for all the drama (no, I don’t think @dxdxdt telling him he was on “corpo payroll”, as if being employed was a bad thing, or the other drama, was what did the trick).
감정소모 하지 마세요… dnf5 코드 보니까 100% 그분들 잘못도 아님. 주말 잘 보내세요.
I think you are right, the same happens when trying to download an rpm package.
hege@nx1:~$ curl "http://mirror.krfoss.org/fedora/linux/updates/43/Everything/x86_64/Packages/m/mariadb-devel-10.11.16-2.fc43.x86_64.rpm" | grep 'captcha'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 .captcha-main-container {
.captcha-content-wrapper {
.captcha-widget-wrapper {
.captcha-main-container {
100 175k 0 175k 0 0 857k 0 --:--:-- --:--:-- --:--:-- 861k <main id="main" class="captcha-main-container" tabindex="-1">
<div class="captcha-content-wrapper">
<div class="captcha-widget-wrapper">
If I save it as html, it looks like this:
curl "http://mirror.krfoss.org/fedora/linux/updates/43/Everything/x86_64/Packages/m/mariadb-devel-10.11.16-2.fc43.x86_64.rpm" > krfoss.html
Translation: “Verifying that you are human. This may take a few seconds.”
But more interestingly, when I just change the User Agent to that of libdnf, I get an error 404 instead:
curl --user-agent 'libdnf (Fedora Linux 43; workstation; linux.x86_64)' "http://mirror.krfoss.org/fedora/linux/updates/43/Everything/x86_64/Packages/m/mariadb-devel-10.11.16-2.fc43.x86_64.rpm" > krfoss.html
If I then open the resulting html:
It is very weird that just changing the user-agent has this effect.
It works perfectly if I use, for example, fr.mirrors.cicku.me :
curl --user-agent 'libdnf (Fedora Linux 43; workstation; linux.x86_64)' http://fr.mirrors.cicku.me/fedora/linux/updates/43/Everything/x86_64/Packages/m/mariadb-devel-10.11.16-2.fc43.x86_64.rpm --output test.rpm
file test.rpm
test.rpm: RPM v3.0 bin mariadb-devel-3:10.11.16-2.fc43
@kevin I think it would be a good idea to disable this mirror for now until the operators have fixed whatever is going wrong on their end.
Probably some bot protection or something they are running. I can reproduce what @parumoe tested and I suspect the same would happen for anyone.
The Fedora repository path on the ROKFOSS mirror staarts with /fedora/updates/43/... rather than /fedora/linux/updates/43/.... Therefore, it is only natural that a 404 error occurs.
To add a few points regarding this, the difference in path structure is not unique to the ROKFOSS mirror. In fact, if you compare the KAIST (Index of /fedora/
), Tsinghua University (https://mirrors.tuna.tsinghua.edu.cn/fedora
), Nanjing University (https://mirrors.nju.edu.cn/fedora
), and JAIST (Index of /pub/Linux/Fedora
) mirrors, you can see that the directory structures of the Fedora repositories are configured differently across each mirror. Therefore, it is difficult to conclude that there is a problem with the mirror simply because a 404 error occurred due to a path difference. If the path itself were the issue, it is highly likely that the same problem would have occurred on other mirrors as well.
Since the correct and aaccessible path is http://mirror.krfoss.org/fedora/updates/43/Everything/x86_64/Packages/m/mariadb-devel-10.11.16-2.fc43.x86_64.rpm, it seems more appropriate to verify using that link.
Yeah, indeed, you are right. It works. Sorry about that.
curl --user-agent 'libdnf (Fedora Linux 43; workstation; linux.x86_64)' http://mirror.krfoss.org/fedora/updates/43/Everything/x86_64/Packages/m/mariadb-devel-10.11.16-2.fc43.x86_64.rpm --output test-fed.rpm
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1181k 100 1181k 0 0 1615k 0 --:--:-- --:--:-- --:--:-- 1615k
file test-fed.rpm
test-fed.rpm: RPM v3.0 bin mariadb-devel-3:10.11.16-2.fc43
I’ve personally analyzed and monitored the ROKFOSS system, and I suspect the following is currently happening:
It appears that malicious traffic is being blocked on the mirror sites. This is estimated to have been in effect since November 17, 2024.
Also, seeing as they’re currently using Cloudflare as a proxy, it looks like they’re using a custom version of Cloudflare’s JS Challenge. Since they said to be Cloudflare partners, that’s probably correct.
Furthermore, they included a message in the Cloudflare JS Challenge advising against the use of VPNs and proxies.
I don’t know why they are taking these measures. I believe VPN, Proxy users should also be able to use the mirror.
And I question whether they can properly distinguish between data centers and proxies.
It seems highly likely that data center users will also be blocked.
I’m also attaching the results of tests conducted from data center:
[paru@moe ~]$ curl ipinfo.io
{
"ip": "0.0.0.0", // masked info
"hostname": "0.0.0.0.bc.googleusercontent.com", // masked info
"city": "North Charleston",
"region": "South Carolina",
"country": "US",
"loc": "32.8546,-79.9748",
"org": "AS15169 Google LLC",
"postal": "29415",
"timezone": "America/New_York",
"readme": "https://ipinfo.io/missingauth"
}
[paru@moe ~]$ curl https://mirror.krfoss.org/fedora/releases/43/KDE/aarch64/iso/Fedora-KDE-Desktop-Live-43-1.6.aarch64.iso | grep captcha
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 0 .captcha-main-container {
.captcha-content-wrapper {
.captcha-widget-wrapper {
.captcha-main-container {
100 175.6k 0 175.6k 0 0 397.8k <main id="main" class="captcha-main-container" tabindex="-1">
<div class="captcha-content-wrapper">
<div class="captcha-widget-wrapper">
0 0
And these blocks increase the occurrence of mirror errors.