apt update "Hash Sum Mismatch" and "File Has Unexpected Size (Mirror Sync in Progress?)" on Kali, Ubuntu and Debian, Plus "Release File Is Not Valid Yet" and NOSPLIT Fixed

If apt update fails with "Hash Sum mismatch" or "File has unexpected size ... Mirror sync in progress?", the index file you downloaded does not match the checksum the repository published for it. Nine times out of ten the mirror was halfway through updating, or something between you and the mirror (a proxy, a cache, an antivirus web filter) handed you a stale copy. Run sudo apt clean && sudo rm -rf /var/lib/apt/lists/* && sudo apt update. If it still fails, wait 20 minutes, or switch your repository URL from http:// to https://, which no transparent proxy can quietly rewrite. "Release file is not valid yet" is your clock; "Clearsigned file isn't valid, got 'NOSPLIT'" is a Wi-Fi login page.

Ethan updated the shop's Kali laptop on a Saturday morning and got a screen full of hashes and the words Hash Sum mismatch. He ran it again ten minutes later and it worked. On Monday, on the café's Wi-Fi across the street, the same command failed with something about NOSPLIT. "Is the laptop broken?" Jake asked. "Neither time," Ethan said. "Saturday the mirror was moving its shelves around while I was shopping. Today the café wants us to click 'I agree' first."

New to this? apt is the tool Kali, Debian, Ubuntu and Raspberry Pi OS use to install and update software, and apt update is the step that refreshes its list of available packages from the internet. Nothing is installed or changed on your system during apt update; it only downloads catalogs. That is good news: every error on this page is about a catalog download, and none of them means your system is damaged. If apt, dpkg and sudo are new words, apt, dpkg and sudo explained covers them in five minutes.

What apt update actually checks (in plain English)

Every repository, such as Kali's http.kali.org, publishes one small file per release called InRelease. It is a signed packing slip: a list of every catalog file in the repository (the Packages files, one per component and architecture), with each file's exact size and its checksums. A checksum, or hash, is a short fingerprint computed from a file's contents. Change one byte of the file and the fingerprint changes completely.

apt update does three things in order:

1. Downloads InRelease and checks its signature against the repository's key, so it knows the packing slip is genuine.
2. Checks the dates on the packing slip against your computer's clock.
3. Downloads each catalog file, computes its size and fingerprints, and compares them with the packing slip.

Each step has its own failure, and each failure has its own message. Step 1 fails with signature errors (covered in Kali apt update: signatures invalid or NO_PUBKEY) or, if what came back was not a packing slip at all, with NOSPLIT. Step 2 fails with "not valid yet" or "expired". Step 3 fails with Hash Sum mismatch or File has unexpected size. Knowing which step failed tells you where to look.

Jake: "So it's like checking a delivery against the packing slip."

Ethan: "Right. And a mismatch doesn't mean someone stole from you. Usually the warehouse sent this morning's box with last night's slip."

Read the Hash Sum mismatch error: the two timestamps that solve it

The full error looks frightening because it prints every fingerprint. These are the exact lines apt 3.3.3 printed for a catalog file that had one byte changed after the packing slip was made (the long SHA512 and weak SHA1 and MD5 lines are trimmed here):

Get:4 http://127.0.0.1:8000 test/main amd64 Packages [356 B]
Err:4 http://127.0.0.1:8000 test/main amd64 Packages
  Hash Sum mismatch
  Hashes of expected file:
   - Filesize:356 [weak]
   - SHA256:0b67326b499b025ff7de07e8ab35bd9d4b2ae24df1bd001157a190a662e2a2ae
  Hashes of received file:
   - SHA256:d095016220e0eca062e697be92db963fccb0645f171ea29140cffded9524e339
   - Filesize:356 [weak]
  Last modification reported: Thu, 22 Oct 2026 23:28:54 +0000
  Release file created at: Thu, 22 Oct 2026 23:28:53 +0000
...
E: Failed to fetch http://127.0.0.1:8000/dists/test/main/binary-amd64/Packages.gz  Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead.

Skip the fingerprints; they are just two different long numbers. Read the last two lines of the block instead:

• Last modification reported is when the server says it last changed the file you received.
• Release file created at is when the packing slip was made.

Catalogs are normally written a little before their packing slip, so a file a few seconds or minutes older than the slip is expected. If the file was modified after the slip was created, as here (23:28:54 against 23:28:53), you received a newer catalog than the slip describes: the classic sign of a mirror caught in the middle of updating, or of a cache that mixed old and new files. If the file is hours or days older than the slip, a cache, a proxy or a lagging mirror is serving you an old copy. Either way, the problem is on the network path, not on your machine.

Notice the last line too: They have been ignored, or old ones used instead. apt keeps using your previous catalogs, so you can still install software; you just will not see the newest versions until an update succeeds. On apt 3 and later, apt prints Error: where apt-get prints E:. They are the same errors with different labels, which matters only when you search for them.

The fix ladder: from ten seconds to ten minutes

Work down the list and stop when apt update finishes cleanly. Most people stop at step 2.

1. Run it again. sudo apt update. A mirror sync usually takes minutes, and a second try often lands after it.
2. Throw away the downloaded catalogs and start fresh.

   sudo apt clean
   sudo rm -rf /var/lib/apt/lists/*
   sudo apt update

   This is safe. /var/lib/apt/lists holds only downloaded catalogs, and apt update rebuilds it completely. Partly downloaded files in /var/lib/apt/lists/partial are a common cause of repeat failures, and this clears them too.
3. Wait 20 to 30 minutes and try again if the timestamps point to a mirror mid-update. You cannot hurry a mirror, and nothing is wrong on your side.
4. Switch to HTTPS. Edit your Kali sources (next section) and change http://http.kali.org/kali to https://http.kali.org/kali. Kali's redirector answers HTTPS and sends you to an HTTPS mirror such as kali.download. Over HTTPS, no proxy, café router or ISP cache can substitute an old file without breaking the connection, so the "stale copy" causes disappear in one edit.
5. Bypass caches for one run. sudo apt -o Acquire::http::No-Cache=true update asks caching proxies to fetch fresh copies instead of serving stored ones.
6. Look for a proxy you forgot about. apt-config dump | grep -i proxy shows any proxy apt is configured to use, and env | grep -i proxy shows proxy variables. An old apt-cacher-ng address from another network is a frequent find.
7. Rule out your own machine if it fails on every network, every mirror and every day: check free space with df -h /var, because a full disk truncates downloads, and only then consider failing RAM or storage.

Ethan: "Step two fixes it so often that I type it without thinking."

Jake: "And step four?"

Ethan: "Step four stops it coming back."

Why this error hits Kali more often than Debian or Ubuntu

This is the part most fix guides leave out. Debian and Ubuntu repositories publish their catalogs twice: once under their normal names, and once under a name made of their own fingerprint, in a by-hash folder. Their InRelease files say so with the line Acquire-By-Hash: yes. When that line is present, apt downloads each catalog by its fingerprint name, and a mirror halfway through an update cannot hand you the wrong version under the right name, because the new file has a different name entirely.

Kali's rolling InRelease, in October 2026, has no Acquire-By-Hash line:

$ grep -E '^(Origin|Suite|Date|Valid-Until|Acquire-By-Hash|Components):' \
    /var/lib/apt/lists/http.kali.org_kali_dists_kali-rolling_InRelease
Origin: Kali
Suite: kali-rolling
Date: Thu, 22 Oct 2026 18:05:44 UTC
Components: main contrib non-free non-free-firmware

So apt fetches Kali's catalogs by their plain names (main/binary-amd64/Packages.gz and so on). Kali rolling also updates far more often than a stable release, so the window in which a mirror has a new catalog under an old packing slip, or the other way around, comes around more often than on a stable release. That is not a defect you can fix on your side. It is the reason "wait and retry" works so well on Kali, and the reason HTTPS plus a clean list folder is the best defense.

The same output shows another useful fact: Kali's InRelease carries no Valid-Until date. That matters for the "expired" error below.

Where your Kali sources live in 2026, and the HTTPS edit

Since Kali 2026.2, the network repository is configured in /etc/apt/sources.list.d/kali.sources, in apt's newer multi-line format. A clean install contains exactly this:

Types: deb
URIs: http://http.kali.org/kali/
Suites: kali-rolling
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg

Older installs use the one-line format in /etc/apt/sources.list instead:

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

Running sudo apt modernize-sources converts the old file into the new one and keeps a .bak copy. Either way, the HTTPS fix is one word:

# new format
sudo sed -i 's#URIs: http://http.kali.org/kali/#URIs: https://http.kali.org/kali/#' /etc/apt/sources.list.d/kali.sources

# old format
sudo sed -i 's#deb http://http.kali.org/kali#deb https://http.kali.org/kali#' /etc/apt/sources.list

sudo apt update

Afterwards, the Get: lines show the HTTPS mirror you were sent to, for example Get:5 https://kali.download/kali kali-rolling/main amd64 Packages [21.8 MB]. Keep third-party sources in their own files under /etc/apt/sources.list.d/, never inside the Kali sources file: mixing other distributions' repositories into it is one of the most common ways to break a Kali install. If your sources file looks nothing like the above, Kali "Unable to locate package" walks through restoring it.

"File has unexpected size (357 != 356). Mirror sync in progress?"

This is the Hash Sum mismatch's sibling, and apt even guesses the cause for you. It appears when the catalog file's size does not match the packing slip, which apt checks before it bothers computing fingerprints:

Err:4 http://127.0.0.1:8000 test/main amd64 Packages
  File has unexpected size (357 != 356). Mirror sync in progress? [IP: 127.0.0.1 8000]
  Hashes of expected file:
   - Filesize:356 [weak]
   - SHA256:1b0d5a753ae24d05d97ec777297a943ce566ce33184d25e9f4135c0b15a6de6f
  Release file created at: Thu, 22 Oct 2026 23:29:07 +0000

Read the numbers in the brackets as "received != expected". A received size that is a little different from the expected one means a different version of the file: a mirror syncing, or a cache serving another day's copy. A received size that is much smaller than expected means the download was cut short, which points to a flaky connection, a proxy with a size limit, or a full disk. The [IP: ...] part tells you which server actually answered, which is useful when a redirector sends you to a different mirror each time.

The fixes are the same ladder as above. One difference: if the size is wildly wrong and the same on every try, open the URL from the error in a browser. If you see a web page instead of a download, something on your network is answering in the repository's place, and you are really looking at the NOSPLIT problem in disguise.

Jake: "So 357 against 356 is a box with one extra screw in it."

Ethan: "One extra screw, and apt refuses the whole box. Which is exactly what you want from the thing that installs your software."

Hash Sum mismatch during apt install or upgrade

The same words can appear when you install or upgrade, not just during apt update. This time the file that failed is a package (.deb), checked against the fingerprint listed in the catalog you downloaded earlier:

Get:1 http://127.0.0.1:8000 test/main amd64 shopnote all 1.0 [752 B]
Err:1 http://127.0.0.1:8000 test/main amd64 shopnote all 1.0
  Hash Sum mismatch
  Hashes of expected file:
   - SHA256:1b5ddb5314fced390ada66158a75ce5d1e1dcae8a07ee7daa8971fa0b7373816
   - Filesize:752 [weak]
  Hashes of received file:
   - SHA256:b33616a562f0a7df84ae333ed9f838ca115d62c8455f3c5a56cd356ab98b8434
   - Filesize:752 [weak]
E: Failed to fetch http://127.0.0.1:8000/pool/shopnote_1.0_all.deb  Hash Sum mismatch
E: Unable to fetch some archives, maybe run apt update or try with --fix-missing?

apt suggests two things on the last line, and only one of them helps. Running apt update first is right: if your catalog is older than the mirror's, the expected fingerprint is out of date, and a fresh catalog fixes it. --fix-missing is not a repair for a mismatch. On the package above, apt-get install --fix-missing printed the same mismatch again and then E: Internal Error, ordering was unable to handle the media swap, which sounds alarming and means nothing more than "I still could not get that file".

1. sudo apt clean to empty the package download folder (/var/cache/apt/archives).
2. sudo apt update so the expected fingerprints are current.
3. Retry the install or upgrade. Once the server sent the correct file, the same install went straight through to Setting up shopnote (1.0) ..., with no leftover bad copy to clear by hand.
4. If one package keeps failing on every try, the mirror's copy is bad: use HTTPS, or wait for the mirror to resync.

A failed upgrade halfway through can also leave dpkg itself unfinished. If the next command complains that dpkg was interrupted, fix "dpkg was interrupted" first.

Proxies, caches and antivirus: the usual stale-copy culprits

If the error comes back on every retry, at every hour, the mirror is probably fine and something between you and it is keeping old files. The common ones:

• Transparent proxies on corporate, school, hotel and some ISP networks. They cache plain HTTP downloads to save bandwidth and occasionally serve a catalog older than the packing slip. HTTPS defeats them completely.
• apt-cacher-ng or another package cache on your own network. If you set one up once, every machine pointing at it gets its mistakes. Delete the cached copy of the failing file on the cache server, or restart the cache with an emptied cache folder, then retry.
• A proxy line in apt's settings left over from another network. Find it with apt-config dump | grep -i proxy; it usually lives in a file under /etc/apt/apt.conf.d/.
• Security software that scans downloads, on the host computer when Kali runs in a virtual machine. Some web-filtering features rewrite or delay HTTP downloads. HTTPS usually sidesteps them too.

To see whether a cache is in the way, try sudo apt -o Acquire::http::No-Cache=true update. If the No-Cache run works and a normal run fails, a cache is the culprit. The [IP: ...] at the end of an error line also tells you which server answered; a private address such as 192.168.x.x or 10.x.x.x there means a box on your own network answered, not a Kali mirror.

Check the hashes yourself in one minute

It helps to see the check apt does, once, with your own eyes, because it turns the error from magic into arithmetic. Download Kali's packing slip and one small catalog, then compare:

curl -sL -o InRelease https://http.kali.org/kali/dists/kali-rolling/InRelease
curl -sL -o nff.gz https://http.kali.org/kali/dists/kali-rolling/non-free-firmware/binary-amd64/Packages.gz

grep " non-free-firmware/binary-amd64/Packages.gz$" InRelease | tail -1
 dad59e171e34d2cfdc92240cc002e0f5f2573da227b355c0aac1fab49152163f 16252 non-free-firmware/binary-amd64/Packages.gz

sha256sum nff.gz; stat -c %s nff.gz
dad59e171e34d2cfdc92240cc002e0f5f2573da227b355c0aac1fab49152163f  nff.gz
16252

The packing slip lists the file's SHA256 fingerprint and size (the last of several lines for that file name is the SHA256 one), and the downloaded file produces exactly the same fingerprint and exactly 16,252 bytes. That is all apt update does, for every file, plus checking the slip's signature. On the day you get a Hash Sum mismatch, the same two commands against the mirror in your error message show you whether that mirror's file really differs, which settles "is it the mirror or my network" in a minute. Your numbers will differ from these, because Kali publishes new catalogs often; what matters is whether the two numbers on your screen match.

See which server really answered

When a redirector, a proxy or a cache is involved, the fastest way to see what happened is apt's own HTTP debug output:

sudo apt-get update -o Debug::Acquire::http=true 2>&1 | grep -E '^(GET|HTTP/|Host:|Location|Last-Modified|Content-Length|Via|X-Cache)'

GET /dists/test/InRelease HTTP/1.1
Host: 127.0.0.1:8000
User-Agent: Debian APT-HTTP/1.3 (3.3.3)
HTTP/1.0 200 OK
Content-Length: 3126
Last-Modified: Thu, 22 Oct 2026 23:39:44 GMT

Each request apt makes appears with the reply's status and headers. Three things to look for: a Location line after a 302, which names the mirror the redirector sent you to (against http.kali.org, an HTTPS request is redirected to an HTTPS mirror such as kali.download); a Via or X-Cache header, which proves a proxy or cache answered; and Last-Modified dates far older than the packing slip's. This works for plain http:// sources; for https:// sources use -o Debug::Acquire::https=true instead.

"Release file is not valid yet": your clock is behind

Every packing slip has a creation date. If your computer's clock says it is earlier than that date, apt refuses the slip, because from its point of view the file comes from the future:

E: Release file for http://127.0.0.1:8000/dists/test/InRelease is not valid yet (invalid for another 4h 59min 50s). Updates for this repository will not be applied.

The "invalid for another" part is how far behind your clock is, near enough. Hours usually mean a time zone problem; days or years mean the clock was never set. The usual reasons:

• A virtual machine restored from a snapshot or resumed after a long pause, with the clock still at the moment it was frozen.
• Dual-boot with Windows, which keeps the hardware clock in local time while Linux expects UTC, putting Linux off by your time zone offset.
• A Raspberry Pi or other small board without a battery-backed clock, which starts at an old date until it reaches a time server.
• WSL after the host computer slept, where the Linux clock can fall behind Windows.
• A Kali live USB on a network that blocks time servers.

Fix the clock, not apt:

timedatectl                          # shows local time, UTC and whether NTP sync is active
sudo timedatectl set-ntp true        # turn on automatic time sync
sudo date -s "2026-10-22 23:45:00"   # or set it by hand if no time server is reachable
sudo hwclock -s                      # WSL: copy the host's time into Linux

For dual-boot machines, sudo timedatectl set-local-rtc 1 tells Linux the hardware clock is in local time, which stops the offset coming back after every Windows boot. If you are stuck without any way to fix the clock right now, sudo apt -o Acquire::Check-Date=false update skips this one date check for one run; it worked against the future-dated repository above. Use it once to get unstuck, then fix the clock, because a wrong clock breaks HTTPS, logins and certificates too.

"Release file is expired": a clock ahead, or a repository that stopped

Some repositories put an expiry date in their packing slip, in a Valid-Until line, so that an attacker cannot keep feeding you an old, vulnerable catalog forever. When that date passes, apt stops trusting the slip:

E: Release file for http://127.0.0.1:8000/dists/test/InRelease is expired (invalid since 3d 0h 0min 0s). Updates for this repository will not be applied.

There are only two explanations. Either your clock is ahead (check with timedatectl), or that repository, or the mirror you use for it, has stopped publishing fresh packing slips. Here is the Kali-specific shortcut: Kali's rolling InRelease has no Valid-Until line at all, as shown above. So if you see "is expired" on Kali, the URL in the message is almost certainly not http.kali.org. It is a third-party repository, a Debian repository someone added to the Kali sources, or an archive of old snapshots. Read the URL, then fix or remove that source.

For deliberate use of old archives, such as snapshot.debian.org or a frozen internal mirror, sudo apt -o Acquire::Check-Valid-Until=false update is the intended switch, and it skipped the check against the expired repository above. For anything else, an expired repository is a repository you should stop using.

"Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)"

This message is apt's way of saying "I asked for a signed packing slip and received something that is not one". The bracketed question is the right guess almost every time: you are on a network with a login page (a café, hotel, airport, train or guest Wi-Fi), and every web request is answered with that page until you accept the terms. Here is what apt prints when a web page comes back in place of InRelease:

Get:1 http://127.0.0.1:8000 test InRelease [89 B]
Err:1 http://127.0.0.1:8000 test InRelease
  Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
E: Failed to fetch http://127.0.0.1:8000/dists/test/InRelease  Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
E: The repository 'http://127.0.0.1:8000 test InRelease' is not signed.

That 89-byte "InRelease" was a one-line welcome page. A real Kali InRelease is tens of kilobytes. NOSPLIT means apt found no signature boundary in the file, because a web page has none.

1. Open a browser and visit any plain http:// site. The login page appears; accept it.
2. Check from the terminal if you have no browser: curl -sI http://http.kali.org/kali/dists/kali-rolling/InRelease. A 302 to a hotel or router address instead of a Kali mirror confirms the portal.
3. Run sudo apt update again. No cleanup is needed.

On a machine with no desktop, such as a Kali install you reach over SSH or a Raspberry Pi without a screen, you can still find the portal. Request a site that never uses HTTPS, so the portal can answer in its place: curl -sL http://neverssl.com | head -20 prints the portal's page, including the address of its login form. Some portals accept a simple form submission with curl; others need a real browser, in which case a text browser such as w3m or lynx (installable from Kali's repository once you are online somewhere else) or a quick login from your phone with the device's MAC address registered is the practical route.

The same message can come from a corporate web filter that returns a "blocked" page, or from a proxy demanding a password. HTTPS sources help here as well: instead of a confusing NOSPLIT, you get a clear certificate or connection error that says "this is not the server you asked for". The second line, is not signed, is a follow-on, not a separate problem. It disappears with the first one. Never respond to it by marking the repository trusted, for the reason in the trusted=yes trap.

Jake: "So apt got the café's menu instead of the shop's packing slip."

Ethan: "And to its credit, it noticed."

"The repository ... does not have a Release file"

This one comes from step 1 failing in the most basic way: there is no packing slip at the address in your sources at all.

Ign:1 http://127.0.0.1:8000 test InRelease
Err:2 http://127.0.0.1:8000 test Release
  404  File not found [IP: 127.0.0.1 8000]
E: The repository 'http://127.0.0.1:8000 test Release' does not have a Release file.

The quoted part names the address and the suite. In practice the causes are:

• A typo or old name in the suite. Kali's main branches are kali-rolling and kali-last-snapshot; old names from years-old guides, such as kali or sana, no longer exist.
• A wrong URL, such as a mirror that was retired, or http.kali.org/kali/kali after a copy-paste.
• A third-party repository that does not support your release. Many vendors publish only for Debian or Ubuntu code names; adding one with Kali's suite name, or with an Ubuntu name it never published, produces exactly this.
• An Ubuntu release past its end of life, whose repositories moved to old-releases.ubuntu.com.

Third-party repositories on Kali deserve one more sentence, because Kali's suite name is not one vendors recognize. Many vendors use a generic suite such as stable (Google Chrome's and Visual Studio Code's repositories do), and their lines work unchanged on Kali. Vendors that publish one suite per release, named after Debian or Ubuntu versions, will never have a kali-rolling suite, so a line that substitutes Kali's name always fails with this exact error. Use the vendor's Debian instructions as written, and expect occasional dependency trouble, since Kali rolling moves faster than any Debian release.

Fix the line, or remove the third-party source file from /etc/apt/sources.list.d/, and run sudo apt update. For Kali, compare your file with the clean version in the sources section.

A calmer option: the kali-last-snapshot branch

If you use Kali for coursework or a fixed lab and do not need the newest version of every tool, Kali's other main branch is worth knowing. kali-rolling, the default, changes constantly. kali-last-snapshot follows Kali's point releases instead: the more stable branch, updated quarterly. Fewer changes means fewer moments when a mirror is halfway through one, and fewer surprise breakages in general.

# switch to the quarterly branch
sudo sed -i 's/^Suites: .*/Suites: kali-last-snapshot/' /etc/apt/sources.list.d/kali.sources
sudo apt update

# switch back to the default
sudo sed -i 's/^Suites: .*/Suites: kali-rolling/' /etc/apt/sources.list.d/kali.sources
sudo apt update

The change takes effect at the next apt update. Kali's extra branches such as kali-experimental and kali-bleeding-edge are meant to be used only on top of kali-rolling, and the kali-tweaks tool has a menu for them under its network repositories section if you would rather not edit files.

What Hit, Get, Ign and Err mean in apt update output

The lines before the error are not noise; each prefix is a status, and reading them makes every error above easier to place:

A plain 404 File not found under an Err: line, with no hash talk, means the server simply does not have that file. That happens when you ask for an architecture or component a repository does not publish, or when a mirror is missing files. Try the default http.kali.org redirector instead of a fixed mirror, or remove the extra architecture with sudo dpkg --remove-architecture if you added one you do not need.

When only one kind of file fails: Contents, Translation and i386

Look at the file name in the error. If the failing file is not a plain Packages catalog, the cause and the fix narrow down:

• Contents-amd64 files are downloaded only if you installed apt-file (the tool that answers "which package contains this file?"). They are large, so a mirror takes longer to sync them and they fail more often. Delete them with sudo rm -f /var/lib/apt/lists/*Contents* and retry, or run apt-file update later when the mirror has settled.
• Translation-en and other Translation-* files hold package descriptions in different languages. If one fails repeatedly and you do not need them, tell apt to skip them: create /etc/apt/apt.conf.d/99no-translations containing Acquire::Languages "none";.
• binary-i386 catalogs appear because someone enabled the 32-bit architecture, usually for Wine or an old game. If you no longer use it, sudo dpkg --remove-architecture i386 (after removing any i386 packages) halves the number of catalogs apt has to get right.
• A file from a third-party repository, such as a browser's or editor's own repository, means that vendor's server or CDN is the problem, not Kali. Wait, or disable that one source temporarily by renaming its file in /etc/apt/sources.list.d/ to end in .disabled, and update the rest.

A safe update routine for Kali that avoids most of these errors

Most of the errors on this page are about timing and the network path, so a routine that controls both prevents most of them. This is the one the shop's laptop uses:

timedatectl | grep -E 'Local time|synchronized'     # 1. clock correct and synced?
sudo apt update                                    # 2. refresh catalogs
sudo apt full-upgrade -y                           # 3. upgrade everything, dependency changes included
sudo apt autoremove -y                             # 4. tidy up packages nothing needs any more

• Use full-upgrade, not plain upgrade, on Kali rolling. It is allowed to add and remove packages when dependencies change, which a rolling distribution needs regularly; plain upgrade can leave packages held back.
• Use HTTPS sources once, as above, and most stale-copy problems never come back.
• Update on a network you trust, and after signing in to any Wi-Fi portal, not before.
• If you update rarely, expect a big download and give it a stable connection. A rolling distribution that has not been updated for months downloads a large share of its packages again. In a virtual machine, take a snapshot first, so a failed upgrade is one click to undo.
• If a mirror sync bites, retry automatically with sudo apt -o Acquire::Retries=5 update, which retries failed downloads before giving up.

Ethan: "Clock, catalogs, upgrade, tidy. Same order every time."

Jake: "Like opening the shop. Lights, till, door, sign."

Every apt update download error at a glance

The trusted=yes trap: the "fix" that switches off the alarms

Forum answers sometimes suggest adding [trusted=yes] to a sources line, or --allow-unauthenticated and --allow-insecure-repositories to the command, to make these errors go away. They do go away, and that is the problem. With [trusted=yes] on the same test repository, apt behaved very differently:

• A web page served in place of InRelease was silently ignored, and apt moved on without a word about NOSPLIT.
• With the packing slip deleted entirely, apt raised no "does not have a Release file" error and downloaded the catalogs anyway, with nothing to check them against.

What it did not switch off is just as telling. The same trusted repository still failed with Hash Sum mismatch when a catalog was altered, still refused a packing slip dated in the future, and still refused one whose Valid-Until date had passed. So trusted=yes does not even fix the errors people add it for. It only removes the checks that prove the files came from the real repository.

Every one of those checks exists to stop someone on your network from feeding you old or altered software. On a security distribution, used on public Wi-Fi more than most, switching them off is the one fix guaranteed to be worse than the error. trusted=yes has exactly one sensible use: a local repository on your own disk that you built yourself. For anything on the internet, fix the cause on this page instead.

Ethan: "The alarm is annoying. Pulling the battery out isn't a repair."

Ubuntu, Debian, Raspberry Pi and WSL: what changes

The messages and fixes on this page are apt's, so they apply to every apt-based system. The differences are in where things live:

• Ubuntu 24.04 and later keep the main sources in /etc/apt/sources.list.d/ubuntu.sources, in the same multi-line format as Kali's. Ubuntu's repositories use by-hash, so "Mirror sync in progress?" is rarer there, and a persistent Hash Sum mismatch on Ubuntu points even more strongly to a proxy or cache. Switching a slow country mirror to the main archive.ubuntu.com is a common fix.
• Debian uses deb.debian.org, a content delivery network that rarely shows mirror sync errors. Debian's security repository uses Valid-Until, so a clock that runs ahead shows up there first as "is expired".
• Raspberry Pi OS users see "not valid yet" more than anyone, for the clock reason above. Make sure the Pi reaches a time server before the first update after boot.
• WSL users fix clock drift with sudo hwclock -s or by restarting WSL from Windows with wsl --shutdown.

The two-minute checklist

1. Read which step failed: hashes and sizes (download), dates (clock), NOSPLIT or Release file (the address).
2. For hashes and sizes: sudo apt clean && sudo rm -rf /var/lib/apt/lists/* && sudo apt update.
3. Still failing? Compare "Last modification reported" with "Release file created at", then wait 20 minutes if the mirror is mid-sync.
4. Switch Kali sources to https://http.kali.org/kali.
5. Look for a leftover proxy: apt-config dump | grep -i proxy.
6. For dates: timedatectl, then sudo timedatectl set-ntp true.
7. For NOSPLIT: sign in to the Wi-Fi in a browser.
8. For a missing Release file: compare your sources with the clean Kali file and remove broken third-party sources.
9. Never use [trusted=yes] to silence an internet repository.

Frequently asked questions

The shop's laptop now points at Kali's HTTPS address, and Ethan has not seen a Hash Sum mismatch on it since; the café's login page still shows up now and then, but now he recognizes NOSPLIT on sight and reaches for the browser instead of the terminal. Jake has started reading apt update output over his shoulder. "It's a delivery log," he said. "Hit means the shelf's already stocked." Ethan didn't correct him.

Revision note. Written October 22, 2026, with apt 3.3.3 on Kali rolling, Kali's published InRelease of that date, and apt's own messages for each failure. "Haste makes waste," the proverb says, and with a mirror mid-sync, twenty minutes of patience beats an hour of edits.