This issue is now fixed. If you’re monitoring this thread for a proper solution, this is now done. Simply run garuda-update to update your system as usual.
Now, if you are on the more technically inclined side... (or just curious)
Here is the root cause analysis:
About the time the issue occurred, something interesting happened on Arch’s mirror status service. For some reason, all but 2 mirrors are listed as having a completion percentage of less than 100%. One of those mirrors is an rsync mirror, which we don’t make use of, and the other is, you guessed it, mirror.cyberbits.asia.
By default, rate-mirrors and reflector both only test and add mirrors to the mirror list that have 100% completion, so both tools would do the reasonable thing and follow the statistics provided by Arch’s mirror status service.
It probably doesn’t surprise you that that server is not so happy about being the only mirror being accessed by quite a number of clients now, so I assume it buckled under the load and isn’t responding to requests anymore, causing this entire issue.
As usual, it takes multiple things to go wrong in the Swiss cheese model, from the default configuration of rate-mirrors, to the interesting situation on the mirror status service and the mirror going offline. Take any of these factors away, and this issue would’ve never occurred in the first place.
Luckily, garuda-update is a very solidly written piece of software with many backups and failsafes, so even with a corrupted mirrorlist, we were able to effortlessly roll out an update to garuda-update via our usual channels that is automatically applied by one of the failsafes that kicked in, which allowed us to decrease the required completion percentage to 98%, which allows rate-mirrors and reflector to once again provide a valid mirrorlist that can then be used to update the system as normal.