I have tried 4 times. Mirror list was updated. Last log that I saw before failure
2026-01-16 - 14:42:27 [6]: [PYTHON JOB]: "pacstrap: :: Retrieving packages..."
2026-01-16 - 14:43:08 [6]: DEBUG (Qt): Process is running in the background...
2026-01-16 - 14:44:08 [6]: DEBUG (Qt): Process is running in the background...
2026-01-16 - 14:45:08 [6]: DEBUG (Qt): Process is running in the background...
2026-01-16 - 14:46:08 [6]: DEBUG (Qt): Process is running in the background...
Welcome to the forum 
pacstrap: error: failed retrieving file 'linux-firmware-mediatek-20260110-1-any.pkg.tar.zst' from at.arch.mirror.kescher.at : OpenSSL SSL_read: OpenSSL/3.6.0: error:0A000119:SSL routines::decryption failed or bad record mac, errno 0"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: error: failed retrieving file 'perl-5.42.0-1-x86_64.pkg.tar.zst' from at.arch.mirror.kescher.at : OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: error: failed retrieving file 'gcc-libs-15.2.1+r447+g6a64f6c3ebb8-1-x86_64.pkg.tar.zst' from at.arch.mirror.kescher.at : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: warning: too many errors from at.arch.mirror.kescher.at, skipping for the remainder of this transaction"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: error: failed retrieving file 'linux-firmware-other-20260110-1-any.pkg.tar.zst' from at.arch.mirror.kescher.at : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: error: failed retrieving file 'linux-firmware-other-20260110-1-any.pkg.tar.zst' from archlinux.uk.mirror.allworldit.com : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: error: failed retrieving file 'perl-5.42.0-1-x86_64.pkg.tar.zst.sig' from archlinux.uk.mirror.allworldit.com : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: error: failed retrieving file 'linux-firmware-other-20260110-1-any.pkg.tar.zst' from mirror.trap.moe : Resolving timed out after 10001 milliseconds"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: error: failed retrieving file 'linux-firmware-amdgpu-20260110-1-any.pkg.tar.zst' from at.arch.mirror.kescher.at : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: error: failed retrieving file 'linux-firmware-other-20260110-1-any.pkg.tar.zst' from mirror.osbeck.com : Resolving timed out after 10001 milliseconds"
2026-01-16 - 14:46:13 [6]: [PYTHON JOB]: "pacstrap: warning: failed to retrieve some files
The above seems failing connections to the mirrors for some reason , as a result failing to download some packages. Maybe try again later or try to rank the mirrors (also the arch ones) again. You can also try a offline install and update later on.
2026-01-16 - 14:38:25 [6]: [PYTHON JOB]: "pacstrap: error: failed retrieving file 'linux-headers-6.18.5.arch1-1-x86_64.pkg.tar.zst.sig' from at.arch.mirror.kescher.at : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds"
Both runs showing the same mirror failing to fetch the same package.. mirror ranking is not always working good in every region.. you should remove this one from the list at.arch.mirror.kescher.at Go to rank mirrors before starting installer, from welcome .. and after generation check kate /etc/pacman.d/mirrorlist for that mirror and remove it or comment it with a # in front f the line.. safe the file and start installer.
and welcome here
this seems to be a ongoing issue with mirrors in general? I do have installs done that took forever to complete
personally i always use worldwide mirror when updating and it never fails.
So my question: is it possible to only use worldwide mirror for installs? I know that this might increase the load on that mirror but it seems to me more reliable?
Well I think this depends on where you are, and who your provider is , a temporary problem with arch (which is not necessary a mirror problem), or a mirror. Just ranked the mirrorllist with the Austria box ticked , and there was not a problem with the kescher.at mirror 
I think it is, and I’m working on this for the next ISO. But it is in early phase now, and still needs some work and testing to make it as reliable as possible.
For online installs the current ISO (Ganymede Neo) already supports doing mirror ranking before installing (either with the ranking tools or manually).
For offline installs currently the only way is to manually edit the Arch mirrorlist and set e.g. the Worldwide mirrors in the beginning of the list.
I tried to rank in both methods (arch and eos)
I installed os local and then updated packages with packman (after second try, because first time connection failed)
Thank @keescase and @joekamprad for answers and greetings
Would it be possible to do this automatically before starting calamares? some kind of script that ranks the mirrors and then start calamares
That’s the way it is handled already, for online installs but not offline.
Note that it may make starting calamares seem like it is not starting…
Over the last month we’ve seen increasing issues with mirrors becoming unresponsive, likely due to ongoing attacks or infrastructure changes caused by them.
Users can manually rank and select mirrors before starting the installer; if they do, those mirrors are used. If not, the installer ranks mirrors automatically during installation. We can’t hardcode global mirrors, as mirror quality depends heavily on location .. worldwide mirrors may work well in some regions and poorly in others.
Failed installs are almost always traceable to a mirror that was ranked as good but then fails hard. Installation happens in two phases (base system, then desktop/apps), and failures can occur in both, though most happen in phase one. These are usually caused by user-side network issues or mirror instability.
The installer retries with the next mirror, but in rare cases a hard failure breaks package installation. This used to be uncommon and mostly limited to remote areas, but today’s network landscape … with more restrictions and attacks—has changed. That’s a downside of pure netinstalls, though we’re actively working on solutions.
Absolutely true
A possible solution, and i don’t know if this is already thought about in the past, is to create more iso’s with different DE just as a bare install medium. And yes i know that would be more work and more maintenance but a lot safer
Not really true in the full cycle.
10 ISOs with 10 different setups outdated possible 5 Minutes after releasing.
And on a rolling release this is not safer in the full view of things, it may do install the system without issues from netinstall method, but on the other end it will install issues already resolved, you need to take care off all the time, and these needs to get resolved on the installed OS, user may changed setup, so its not predictable if it is even possible to fix it.
EndevourOS also following a strict way on testing ISOs before we release them, this will not even be possible with 10 ISO files done by users in their free time, its already a huge amount of time and work to do the same with one ISO.
Archlinux itself offers also only a network install on its own.
And it is also the case that most people do not have issues with the netinstall method at all.
So no, currently no one is willing to maintain 10 ISOs, and we do not plan to change the way we provide the ISO in general, we do work on solutions, and we keep it KISS as much as we can.
Thanks for your reply, i certainly can see it in your view!
It was just a thought, but i do understand that the team is too small to maintain 10 iso’s
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.