171.0 E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/noble-updates/main/binary-amd64/Packages.gz File has unexpected size (2401604 != 2401605). Mirror sync in progress? [IP: 91.189.92.23 80]
171.0 Hashes of expected file:
171.0 - Filesize:2401605 [weak]
171.0 - SHA256:36c6ef4247ebaa9aba737157cae386cc82558337d51b2e68507d271b218466d8
171.0 - SHA1:60c6cba6177f8f753c432ada4ead63e6291d2b30 [weak]
171.0 - MD5Sum:4c38c2de97b4687ab8f5701f2e0b255c [weak]
171.0 Release file created at: Thu, 16 Apr 2026 08:26:07 +0000
171.0 E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/noble-updates/multiverse/binary-amd64/Packages.gz
171.0 E: Some index files failed to download. They have been ignored, or old ones used instead.
What I’ve Tried:
I’ve found this post which talks about a workaround, but the link is dead unfortunately!
Similar issue from my side, all of the requests to archive.ubuntu.com are extremely slow, and pipeline was running for 1h just to execute similar commands
I suspect this is related to the Canonical cloud provider having issues - they reported that their Kubernetes cluster is broken at the moment in a reply to the ubuntu.com Matrix Homeserver being broken right now.
Loading them in the browser from Hampshire via a VirginMedia connection is working fine. And with the status page showing they’re operational I’m now wondering if archive access for some folks might be indicating an internet routing (BGP) issue. Maybe some of the interconnect peerings around the UK are broken causing only some folk to be impacted?
That’s pure speculation on my part tho, and it might even be DNS (it’s usually DNS, after all )
Edit to add: Interestingly tho, running apt is a lot slower than usual - strangely it seems that using my browser to access files on the archive is normal speed, but doing it with apt is suuuper slow… confused pikachu gif
This is also just speculation, but the <country code>.archive.ubuntu.com mirrors as well as archive.ubuntu.com are CDN’s (content delivery network) which resolve to multiple IP address via DNS:
$ resolvectl query archive.ubuntu.com
archive.ubuntu.com: 2620:2d:4000:1::103
2a06:bc80:0:1000::16
2620:2d:4000:1::101
2620:2d:4002:1::101
2620:2d:4002:1::102
2a06:bc80:0:1000::18
2620:2d:4000:1::102
2620:2d:4002:1::103
2a06:bc80:0:1000::17
91.189.92.22
91.189.92.23
185.125.190.82
185.125.190.83
185.125.190.81
91.189.91.81
91.189.91.83
91.189.92.24
91.189.91.82
-- Information acquired via protocol DNS in 7.5ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
Each individual DNS reply shuffles those IP’s around on a round-robin basis, so the load is evenly spread. That also means that your browser is likely talking to a different mirror. Plus, your browser might be caching a lot of the actual data.
I was able to replicate this issue across two separate locations using Ubuntu Server. Both us.archive.ubuntu.com/ubuntu and security.ubuntu.com/ubuntu are either dropping connections entirely or crawling at near-dialup speeds — connections just hang with no progress. Confirming this from the US side.
Yeah performance appears significantly degraded. I thought it was me, but after testing in different networks across my cluster, seems like archive.ubuntu.com and us.archive.ubuntu.com are misbehaving - extremely slow at best. I switched to a local mirror and all went back to normal.
This in Portugal, connected over Vodafone and Digi. Yeah, yeah, I could be using any number of other mirrors, but I tend to just stick with the base url and leave it to figure it out.
That’s not how that works. You are supposed to select the CDN of the country you are actually situated in. By using US mirrors you are forcing the connections to cross the pond; there might even be a bottleneck just because of that.
Right, allow me to clarify - my containers had defaulted to archive.ubuntu.com - testing US was just to see what was up with that one and because it was the first mirror to come to mind. Whether there are better mirrors or not is irrelevant here - the very reason I initially opted to not use the Portuguese mirror way back, and why I never bothered changing it in my current config, was due to some issues with them at the time.
This usually happens when the Ubuntu mirror is in the middle of syncing, so the file size/hash doesn’t match yet.
You can try running apt-get update again after some time or switch to a different mirror.
Also doing apt-get clean before updating sometimes helps clear cached issues.
It’s a temporary issue in most cases, not something wrong with your setup
)
