Just trying to collate all relevant information in one thread, increasing its visibility.

As you have all probably noticed there are significant issues with timeouts when you try and download the Solus ISO or install / update packages on your system. This is due to issues at RIT.

It seems to be an intermittent firewall issue where things get accidentally blocked and then unblocked. Weird bug they are trying to track down.

Source: https://discuss.getsol.us/d/7983-delay-friday-updates/9

This is not a Solus specific issue and there is not a lot we can do but wait for them to fix it.

Due to this and other reasons Solus has decided to defer this weeks updates.

Update 2022-02-12 00:09:21 +01:00

Sync has been completed but RIT issues remain. I advise people to update via the command line using this command:
until sh -c 'sudo eopkg up -y';do echo 'Trying again ...';done
It can still timeout but if it fails, it will keep trying until it is completed successfully so you need not baby sit it.

Update 2022-02-17 09:13:56 +11:00

RIT server issues appear to be resolved. But we are still looking for feedback / testing from users.

Final update.

Thank you all for your patience with this incredibly frustraiting issue and helping confirm it is resolved. 🎉

Additionally @joebonrichie 's great work on eopkg was part of this weeks sync. Which means eopkg now handles timeouts properly making it much, much more resilent to connection issues. So you will not need until sh -c 'sudo eopkg up -y';do echo 'Trying again ...';done anymore.

Most users should be good with the default number of retries as in testing while the server was 💩 I managed to download 1156 packages without it failing, but if you have a particularly bad connection to the server you can increase the number of retries as explained here.

Harvey stickied the discussion .

you all (team) had a stressful week. day in day out I see you clawing thru it.

Thank you very much for informing us. Uncertainty, not knowing what to expect, does a lot of damage to any project such as Solus, this is why I appreciate that you take the time to write a brief message like this explaining the situation.

George No Solus only briefly used fastly a few years ago.

George About a dozen distros use RIT as a mirror, and the RIT server is non-functional at this point, regardless of distro. I tried to download Ubuntu from the RIT server yesterday (using Firefox running on Solus Budgie) and the result was three failed download attempts over the course of an afternoon. The issue is also OS and browser agnostic. I had no better luck this morning downloading Solus DE's using Microsoft Edge running on Windows 11:

Whatever the issue might be (overloading, firewall bugs, choke settings, mutant aliens, whatever), the issue is at RIT.

The current failures don't bother me so much as the fact that the problem, although intermittent, also keeps repeating. We've had the issue on and off for several years. I don't remember it ever being this bad, but if you read back in the forum, you'll find a lot of discussion of broken update downloads, usually blamed on a faulty Software Center, but always ending up in "sudo eopkg up repeat and repeat" solutions, which itself tells anyone paying attention that the problem is upstream.

At some point after this go-round settles down, I think the Solus team should consider relocating to a more reliable mirror, before reviews like this one from Distrowatch last week become commonplace:

    Previous timeout issues and this issue are unrelated. Many / most times users have reported timeouts in recent memory the issue has been with the users connection (wifi vs ethernet) / the route the traffic takes from their computer to the server being congested / having faults.

    With prior issues while they are getting timeouts or unable to reach the server at all at the exact same time I have been able to download at 13MB/s sustained from Australia without issue. This clearly has absolutely nothing to do with RIT. Regional mirrors may sometimes help this sort of scenario but a CDN is very expensive due to how much traffic we will need.

    This is made worse by eopkg not handling timeouts gracefully and software centre not providing enough information about issues or freezing when they occur. It is not an easy issue to fix because a library eopkg uses (not made by us) returns a timeout as success.

    When it has been RIT before with congestion the issue has resolved itself in about an hour, I personally can not remember the last time there was an actual issue.

    But I understand people being frustrated with how long RIT are taking to fix this specific issue, its driving me nuts.

      Harvey thanks for differentiating between the common timeout problem and what's going on with RIT on the server end. Informative.
      I wonder if all the hosted distros sit on a big RAID somewhere, segregated completely from the huge personnel/academic side, and what we are seeing is the result of then updating their own intranet system/policies
      with the distro hosting raid a temporary casualty of the law of unintended consequences that happens with every policy change. This theory has a nice Occams feel to it; i will keep it🙂

      Harvey Howdy! I encountered this issue with my sister many miles away from me as I’m helping her get Solus Budgie onto her Thinkpad. The timeouts were still an issue, obviously, but we circumvented it via bit torrent which got me thinking:

      Is there any sort of organized torrent/seeding we (meaning me and others interested) might be able to do to help solve this issue for others by hosting the ISO’s via torrent? Or do we already do this and there’s a way I can participate in seeding the ISO?

        CorvusRuber still a WIP. They are trying to track down the bug, while also ordering new hardware to build an upgraded system.

          DataDrake
          I do not miss the times when I had to handle similar issues. My condolences to the team.

          Harvey Gotcha, no, I created my own and seeded it to her privately! I'll seed that one now. Thanks for the reminder!