Today I came across this fact: yesterday night it was released Kernel 6.16.3 stable on Bodhi for Fedora 41 and Fedora 42. I personally went into Fedora Updates System and I saw that Kernel 6.16.3 is effective released as stable, so I opened up my terminal and I typed: sudo dnf update nothing happens.
Then I remembered I used to overwrite my local mirrors with garr.it. The garr network is one of biggest in Europe for network speed and infrastructure. The fact is the garr mirrors is using a cron for fetching latest packages updates and then keeping them available for the users. So the latest kernel availability on Fedora, at the date I’m typing 6.16.3, for the European servers is delayed. I think no more than 1 day.
And then I’m coming to conclusions:
Do you European user think it worth temporally change local mirrors for an urgent upgrade? Or does is better updates are delayed for 1 - 2 days but you are sure minimal network delay and maximum speed?
I come at the conclusion, as Italian and European Linux user, I won’t change my mirrors just for having immediately the latest software release. I think 1-2 days is a reasonable amount of time. Better: you can check on the net for some possible bugs with latest releases before installing them.
Yes, this is interesting. If I understand correctly, you don’t have anything to worry about. You can remain pinned to garr.it it should sync soon! New Bodhi updates can take up to ~24 hours to reach every mirror, so a short delay is normal regardless of mirror used. I would give the full 1 to 2 days.
On that note, one nice thing about Fedora is that they now deal with this by default. Meaning that users no longer need to pin to a single mirror.
It was a long-standing good practice to pin to the mirror closest or preferred.
Almost 10 years ago, I worked for Evowise to set up mirrors for the most popular Linux distros, including Fedora, on an Anycast network.
Related reading for anyone interested:
It grew in popularity pretty fast! The mirror was dopted by Linux Mint, Ubuntu, Fedora, Debian, and others because it meant just pinning a single mirrors.evowise.com (now redirects to their main project). Linux Mint was one of the highest in bandwidth usage because when we offered it to them, they featured it at the VERY top of their mirror list.
But then rapidly, within a few years, the distros and other mirrors began implementing geo-aware mirrors. Cloudflare also offers (for Arch and Debian only): https://cloudflaremirrors.com/
This mirror project was my baby at the time. The servers built had 2x Intel Xeon E5-2630 v3,
64 GB RAM and 22 TB usable space (in RAID5). But Evowise eventually closed it down. Long after I moved on from maintaining it: https://forums.linuxmint.com/viewtopic.php?f=90&t=353485
I never followed up on the reasoning; my time with Evowise was 2016 to 2018.
Back on topic!!
Personally, I would put back Fedora’s default repo so that DNF uses their MirrorManager’s metalink. This is an automated process designed by Fedora to improve download speeds by directing you to nearby servers and avoiding issues like when a pinned mirror is offline and generally avoids out-of-date mirror issues.
That said, like with anything Linux related, if you prefer to pin to garr.it then you can decide in these cases to manually switch back and forth or not. For desktop PC or if not traveling with the machine, then, garr.it is a good call. Even if traveling, it really still is just personal preference.
How to “use geo-aware mirrors” on a Fedora client
You can easily revert to the defaults and refresh updates:
Restore the stock repo files (brings back metalink URLs)
sudo dnf reinstall -y fedora-repos
Clear cached metadata and force a fresh mirrorlist
sudo dnf clean all
sudo dnf --refresh update
After this, the repo files in /etc/yum.repos.d/ should show metalink=https://mirrors.fedoraproject.org/metalink?... rather than a fixed baseurl= to garr.it.
But yes, none of this is the right or wrong way. Like with most things Linux, it’s part of the many options available to us.
In the Caribbean, geolocation can be very inaccurate. From day to day, my computer is registered in St. Kitts, Antigua, Barbados and I have reached the UK. That said, when I was using Arch I used to force my mirrors to the US, as a few times I found updates were taking hours to download. And when I switched to a US mirror, it came down in a flash.
I am sure European users wouldn’t have that geolocation nightmare, so I agree with Hayden, waiting a day or two shouldn’t be too bad.
For Arch, especially for us in the Caribbean, where IPs can show your location as Barbados one hour and Antigua the next, you can set up Arch to pick mirrors by freshness and tested speed and rotate them automatically.
Using Reflector to rewrite your mirrorlist regularly:
sudo pacman -S reflector pacman-contrib
Then for “set-it-and-forget” runs (HTTPS, recent, fastest):
That said, if you prefer doing a manual refresh every now and then, you can use Arch’s official generator plus ranking and grep to filter in Miami only from USA. Something like:
If you do test that, I’ll be curious how well it works ha. But it should pull up-to-date mirrors from Miami and Brazil (tweak as needed), ranks by speed, saves the top 10, then forces a full DB refresh.
So based on the output, https://kali.download/kali is going through Kali’s geo-aware redirector (MirrorBits) and then being fronted by Cloudflare’s CDN (“cf-ray”). Cloudflare terminates in MIA (Miami) the closest major PoP to my current IP. From there, it will either serve content directly or cached by Cloudflare’s proxy edge server. So it’s always proper fast!
But yes, none of this is the right or wrong way. Like with most things Linux, it’s part of the many options available to us.
Yes indeed, for don’t complicate anymore I’ll stuck on garr.it, it’s the main Italian network of research and development, the central point of all upgrades and packages. Who cares if it’s not perfectly synced with main repos.
Good to know. I’ve used the facility that Endeavour OS provides to hunt for available mirrors for both EOS and Arch, most of the time successfully, but your additional information is helpful because I’m not as much of an expert with Arch derivatives as I am with Debian derivatives.
