What Is a Checksum Error? 7 Causes and How to Fix Each

A checksum error, in one paragraph

A checksum error means a block of data failed its integrity check. A short value was calculated from the data when it was written or sent. A second value was calculated when it was read or received. The two did not match, which proves the data changed somewhere in between. That is the entire meaning of the message. It says nothing about what changed the data, which is why the identical error covers a two dollar battery and a dying hard drive.

This is the reason searching the phrase is so unhelpful. The results are a wall of forum threads, each one solving a different problem, and none of them telling you which problem is yours.

So start with the table below. Find the row that matches where you saw the message, then jump to that section. Everything after that is the fix.

Identify Your Checksum Error in 60 Seconds

The context tells you nearly everything. Match the row, then read only that section.

The short version. If it appeared before your operating system loaded, it is hardware configuration and it is usually cheap. If it appeared in a storage tool, take it seriously and stop writing to that pool. If it appeared in a packet capture on your own machine, it is probably not real.

Checksums, Briefly, So the Rest Makes Sense

A checksum is a small value derived from a larger block of data by running it through a fixed calculation. Two properties make it useful. The same input always produces the same output, and changing even one bit of the input produces a completely different output.

That gives you a cheap integrity test. Compute the value when you store or transmit the data, keep it alongside, then recompute it when you read or receive the data. Matching values mean the data is almost certainly unchanged. Differing values prove something altered it.

The important limitation, and the source of most confusion about these errors: a checksum detects change, it does not identify or repair it. The system knows the data is wrong. It has no idea whether a cosmic ray flipped a bit, a cable dropped a signal, or a download stopped halfway. That is why the same three-word error covers seven unrelated faults, and why fixing one always means working out the context first.

Repair is a separate capability that requires redundancy. ZFS can rebuild a corrupted block because a mirror or parity copy exists elsewhere. ECC memory corrects single-bit errors because it stores extra bits for that purpose. A plain checksum on its own can only raise the alarm.

CMOS Checksum Error on Boot

This is the most common version by a wide margin, and the least alarming.

Your motherboard keeps BIOS or UEFI settings, along with the real-time clock, in a small block of memory powered by a coin cell battery when the machine is unplugged. A checksum is stored alongside those settings. At every power-on, the firmware recomputes it and compares.

When the battery drops below usable voltage, the stored settings decay and the checksum no longer matches. The firmware reports the mismatch, discards the settings it can no longer trust, and loads factory defaults so the machine can still boot.

Confirming it

The clock is the giveaway. Enter BIOS setup and look at the date. If it has reset to something like 2010 or the board's manufacture year, the battery is flat. A second confirmation: the error returns every time the machine is fully unplugged, but not on a warm restart.

Fixing it

1. Power down fully and unplug from the wall.
2. Locate the coin cell on the motherboard. It is almost always a CR2032, roughly the size of a small coin.
3. Note the orientation, release the retaining clip, and swap in a fresh cell the same way up.
4. Boot into BIOS setup, set the correct date and time.
5. Reapply anything custom: boot order, XMP or EXPO memory profile, fan curves, SATA mode, virtualisation.
6. Save and exit.

If it comes back. A new battery that fails again within days points at the board, not the cell. Common causes are a cracked solder joint at the battery holder, a failed voltage regulator, or a firmware corruption that needs a reflash. On a laptop, check whether the cell is soldered rather than socketed before ordering parts.

Checksum Errors on a ZFS or Btrfs Pool

This is the version that actually matters, and the one worth acting on immediately.

ZFS and Btrfs checksum every block they write and verify it on every read. That is the entire point of these filesystems: they catch corruption that a traditional filesystem would hand you silently. A non-zero CKSUM count means the filesystem read a block whose contents no longer matched what it wrote.

zpool status -v tank

Read the output carefully, because the columns mean different things:

The distinction is the useful part. Read and write errors point at the drive. Checksum errors point at the whole path between the platter and the CPU, and that path includes the cable, the backplane, the HBA, the power supply and system memory. Assuming the drive is at fault is the most common and most expensive mistake here.

Working through it

1. Scrub the pool. Run zpool scrub tank. Every block gets read and verified, and anything repairable from redundancy is repaired in place.
2. Read the scrub result. Repaired blocks with no permanent errors means redundancy did its job. Files listed under permanent errors are unrecoverable and need restoring from backup.
3. Check whether errors are spread or concentrated. Errors on one device suggest that device, its cable or its port. Errors across several devices at once point at shared infrastructure: memory, the controller, or the power supply.
4. Test memory before replacing drives. Non-ECC RAM with an intermittent fault will corrupt data on its way to disk and produce exactly this pattern. Run a full memory test overnight.
5. Reseat and replace cables. A marginal SATA cable is cheap to swap and a common culprit.
6. Clear counters and re-scrub. zpool clear tank resets the counts. If they climb again, the fault is live.

Before you troubleshoot. Verify your backups first. A pool reporting checksum errors is a pool actively corrupting data, and diagnostic work involves heavy reads and writes. If the data matters and the backup is stale, take the backup before you start.

Invalid Checksum When Installing Software

An installer that refuses to run with an invalid checksum message is doing its job. The vendor published a checksum for the file. Your copy does not match it. The file you received is not the file they shipped.

In the overwhelming majority of cases this is a mundane transfer problem rather than anything sinister:

• The download was interrupted and resumed badly, leaving a file the right size but wrong contents.
• A proxy, corporate filter or antivirus modified the stream in transit.
• A download manager assembled parallel chunks incorrectly.
• The browser served a partially cached copy.
• Disk space ran out mid-write.

Fixing it

1. Delete the file. Do not resume it. A resumed corrupt download usually stays corrupt.
2. Clear the browser download cache.
3. Disable any download accelerator, and pause antivirus scanning of the download folder if policy allows.
4. Download again from the vendor's official domain, not a mirror or aggregator.
5. Verify it yourself before running it, using the commands in the verification section below.

One genuine security case. If a file repeatedly fails verification from a clean connection and a known-good source, stop and consider that the copy you are being served is not the vendor's. Never disable checksum verification to force an installer through. That check is the only thing standing between you and executing an unknown binary.

Checksum Errors in Wireshark and tcpdump

If your packet capture is full of outgoing packets flagged with bad checksums, the near-certain explanation is that nothing is wrong.

Modern network cards perform checksum offloading, meaning the TCP, UDP and IP checksums are calculated by the NIC hardware immediately before the frame goes on the wire. Wireshark captures packets before they are handed to the network adapter, so it never sees the correct checksum because it has not been calculated yet, and because most operating systems do not bother initialising that field, you are often looking at leftover memory contents. The result is a screen full of alarming red text describing a problem that does not exist on the wire.

Two details make this diagnosable rather than merely annoying. The effect only applies to frames sent from the monitoring host; anything captured from the wire, such as on a mirrored or spanned port, is not falsely flagged. And recent Wireshark releases disable checksum validation by default precisely because offloading is so widespread in modern hardware and operating systems.

Confirming it on Linux

# Is offloading on? ethtool -k eth0 | grep checksum # Disable TX offload temporarily for an accurate capture ethtool -K eth0 tx off tcpdump -i eth0 -w /tmp/capture.pcap # Turn it back on afterwards, it matters for performance ethtool -K eth0 tx on

If the errors disappear once TX offload is off, they were an artefact. If they survive, you have a real problem worth chasing: a faulty NIC, a bad DMA path, unstable memory, or a middlebox rewriting packets without recalculating.

In Wireshark itself you can suppress the noise under Edit, Preferences, Protocols, TCP by unchecking checksum validation. One caveat worth knowing: packets marked with bad checksums are excluded from TCP reassembly, so leaving validation on can quietly break your analysis of a stream rather than just cluttering the display.

Drive and Cable CRC Errors

Storage devices protect the link between drive and controller with a CRC on every transfer. When the receiving end computes a different value, the transfer is retried and a counter increments.

On SATA drives this appears in SMART attribute 199, usually named UDMA_CRC_Error_Count.

sudo smartctl -A /dev/sda | grep -i crc

The critical point about this counter is that it counts interface errors, not media errors. A rising CRC count is far more often a cable or connector problem than a dying drive. The data on the platters may be perfectly intact.

Note that these counters never reset. A drive showing a count of 4 accumulated three years ago is not failing. What matters is whether the number is increasing now, which means recording it and checking again in a week.

Firmware Flash Checksum Mismatch

Flashing firmware to a router, BIOS, microcontroller or audio device almost always involves a checksum embedded in the image. The device verifies it before writing, because writing a bad image can leave the hardware unbootable.

A rejection at this stage is the system protecting you. Common causes, in order of likelihood:

• Wrong image for the hardware revision. Manufacturers frequently ship visually identical devices with incompatible internals. Check the revision printed on the label, not just the model number.
• A corrupted download. Same problem as installers, same fix. Verify the file before flashing.
• Unreliable transfer. TFTP over a flaky link, or a USB stick with a marginal controller.
• A partially written previous attempt leaving the device in a mixed state.

Do not force this one. Some flashing tools offer a switch to skip verification. On a firmware write, that switch is how devices get bricked. Verify the image against the vendor's published checksum first, confirm the exact hardware revision, and use a wired connection. If the checksum still fails, the file or the file source is wrong.

DIMM and Memory Checksum Errors

A POST message naming DIMMs and a checksum usually refers to SPD data: a small EEPROM on each memory module that tells the board the module's timings, capacity and voltage. If the board cannot read that block cleanly, it cannot configure the memory safely.

Work through it in this order, cheapest first:

1. Reseat every module. Power off, unplug, remove and refit each stick until the clips click. Contact oxidation and partial seating cause a surprising share of these.
2. Test one module at a time in the board's primary slot, to identify whether one stick is responsible.
3. Rotate slots with a known-good module to rule out a dead slot.
4. Clear CMOS and retry at stock settings. An aggressive XMP or EXPO profile can make marginal memory unreadable.
5. Check the QVL. Modules outside the board's qualified list, particularly mixed kits, can fail SPD negotiation even when each stick is individually fine.

If a single module fails in every slot while others pass, that module is faulty. Memory is usually covered by a lifetime warranty, so check before discarding it.

Verifying a File Checksum Yourself

Whichever error brought you here, being able to verify a file independently is the single most useful habit to take away. Every major OS ships the tooling.

To verify against a published checksum file rather than by eye:

# Linux and macOS sha256sum -c SHA256SUMS 2>/dev/null | grep file.iso # PowerShell, comparing to a known value (Get-FileHash file.iso -Algorithm SHA256).Hash -eq "PUT_EXPECTED_HASH_HERE"

What verification actually proves. A matching checksum proves the file is identical to the one whose checksum you compared against. It does not prove that file is safe or authentic. If you download both the file and its checksum from the same compromised page, they will match perfectly. For authenticity you need a signature, such as a GPG-signed checksum file, verified against a key you obtained separately.

CRC32, MD5 and SHA-256 Compared

Different jobs call for different algorithms, and knowing which you are dealing with tells you how much a mismatch is worth worrying about.

Two practical takeaways. A CRC is a specific kind of checksum, not a different thing: it uses polynomial division and is far better at catching the clustered errors that transmission lines produce, which is why it sits under Ethernet and SATA. And MD5 remains fine for spotting accidental corruption while being unfit for proving a file has not been deliberately altered, since deliberate collisions are practical. If a vendor still publishes only MD5, treat a match as evidence the download completed, not as evidence the file is genuine.

Deciding Whether It Is Serious

Sorted by how much of your attention each deserves.

One pattern is worth carrying away. When checksum errors appear in several unrelated places at once, on multiple drives, in memory tests, in downloads, stop diagnosing individual components and look at what they share. Unstable power and failing RAM both produce corruption that looks like a dozen separate faults, and both get misdiagnosed as a string of coincidental drive failures.

On sourcing. The Wireshark checksum offloading behaviour described above, including the reason captured packets show uninitialised checksum fields and the fact that recent releases disable validation by default, is taken from Wireshark's own documentation and wiki rather than from secondary write-ups. Command syntax was verified against current tooling.

Hardware guidance is deliberately conservative: reseat and swap cables before replacing drives, and test memory before concluding a disk is at fault. Both reflect the failure patterns that produce checksum errors most often and cost least to rule out.

Frequently Asked Questions

What is a checksum error? A checksum error means a block of data failed its integrity check. A short value was calculated from the data when it was written or sent, and a second value calculated when it was read or received did not match. The mismatch proves the data changed somewhere in between. It does not tell you what changed it, which is why the same message appears for a dead motherboard battery, a corrupt download and a failing hard drive.

Is a checksum error serious? It depends entirely on where it appeared. A CMOS checksum error at boot usually means a two dollar battery. Checksum errors in Wireshark on your own machine are usually a harmless artefact of checksum offloading. Checksum errors on a ZFS pool or rising CRC counts on a drive are serious and mean data is being corrupted. The message is identical in all four cases.

How do I fix a CMOS checksum error? Replace the CR2032 battery on the motherboard, then enter BIOS setup, reset the date and time, reapply any custom settings such as boot order or XMP, and save on exit. If the error returns after a battery replacement, the fault is usually the board itself rather than the battery.

Does a checksum error mean my hard drive is failing? Not necessarily. Checksum errors on a storage pool can come from a bad cable, a failing SATA port, unstable memory or a power supply problem just as often as from the drive itself. Before replacing a drive, check the SMART UDMA CRC error count, reseat or replace the data cable, and run a memory test. Cable faults are one of the most common causes and the cheapest to rule out.

Why does Wireshark show checksum errors on almost every outgoing packet? Because of checksum offloading. Modern network cards calculate the TCP, UDP and IP checksums in hardware, immediately before the packet goes on the wire. Wireshark captures the packet before that happens, so it sees an uncalculated field. These are false positives on packets sent from the monitoring machine. Packets captured from the wire, such as on a mirrored port, are not affected.

What causes an invalid checksum error when installing software? Almost always an incomplete or corrupted download. The installer compares the file it received against the checksum the vendor published, and the values do not match. Delete the file rather than resuming it, clear the download cache, disable any download manager or proxy that might be modifying the stream, and download again from the official source.

How do I check a file's checksum myself? On Windows run certutil -hashfile filename SHA256. On macOS run shasum -a 256 filename. On Linux run sha256sum filename. Compare the output against the value published by whoever supplied the file. If the two strings match character for character, the file is intact.

What is the difference between a checksum and a CRC? A CRC is one particular type of checksum. Checksum is the general term for any short value derived from a block of data for the purpose of detecting change. A cyclic redundancy check uses polynomial division and is much better at catching burst errors than a simple additive checksum, which is why CRC32 is used in Ethernet frames and storage systems. Cryptographic hashes such as SHA-256 are also checksums, designed additionally to resist deliberate tampering.

Can a checksum error be a false alarm? Yes, and two cases are common. Checksum offloading produces false errors in packet captures taken on the sending machine. Verifying a download against a checksum published on the same compromised page proves nothing about authenticity, only that the file matches what that page claimed. Outside those cases, treat a checksum error as real until you have ruled out cable, memory and drive faults.

Can a checksum error be repaired? A plain checksum can only detect that data changed, not restore it. Recovery depends on redundancy existing elsewhere. A ZFS or Btrfs pool with a mirror or parity can rebuild the damaged block automatically during a scrub. A corrupt download is fixed by downloading again. Error correcting codes such as those in ECC memory and optical media can repair small errors directly, but an ordinary checksum cannot.

Closing Thought

A checksum error is not a diagnosis. It is an alarm, and the alarm sounds identically whether the cause is a flat coin cell or a memory module quietly corrupting every file you write.

Everything useful comes from the context. Before the OS loads, it is configuration and it is cheap. Inside a storage tool, it is data integrity and it deserves your full attention. Inside a packet capture on the machine doing the capturing, it is probably an artefact of hardware doing its job correctly.

The habit worth building is the one in the middle of this article: verify files yourself, with a command you trust, before you run them. Most of the versions of this error that cost people real time would have been caught in the ten seconds that takes.