Package content verification failing.

[Firstyear]

We have seen increasingly common reports of packages failing checksum validation.

For example:

Warning: Digest verification failed for file 'libeverest-3.6.6-1.2.x86_64.rpm'
[/var/tmp/zypp.tmp/AP_0xhEjTB9/x86_64/libeverest-3.6.6-1.2.x86_64.rpm]

  expected 7e2c964c447902d9d366068e2e54624d243111d14ec0e9fce0713323128077060e040aeca5b7fa04bc86f5a1ef2a05383fa3a6daa301bbc609521a01191464d1
  but got  125c6a48e9f30bacc002cb8b6699c260b7c59ed4f7e07b60d950b81d225bf6a7880e7da4859559d37176884e8495587c727413a9d39f1263d0f92050a7eefba0

There seems to be "no rhyme or reason" but there are multiple reports of this in community channels such as discord #support for opensuse.

I'm not sure of the "cause", but a possible reason is that OBS is rebuilding a package which creates a new signature, but retains the same version. This then causes mirrorcache to believe the file exists (since it will return 200 on HEAD), but will fail to pass checksums because the mirror may have the older version of the package content that doesn't match the repomd.xml data.

[Mirppc]

I have been having similar errors and assisting people with the same errors over on the OpenSUSE Discord support channel. I will post here when i run across it next.

Here is another example from earlier July 6th 2026
Why do I keep getting errors when upgrading? Annabuu  — 12:09 PM Discord

[/var/tmp/zypp.tmp/AP_0xsXUtOZ/x86_64/libmbedcrypto16-3.6.6-1.2.x86_64.rpm]

 expected 1521a56b09dc64e6c5511d8f3111c58a3b1bdb63ce0535273099fab5ecf2cf82aa1c946529d07d2a02b68654374192fd267df90ad3d3ab260631e79fe4c261af
 but got  f1905f58ec69b547e379a6b4181715105d740553682932ab1f581fd70135073288647b2473590a3b18fc7463ae1b0fb3f1b93332a0c838babe45ad3c4f07475f

Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise.

However if you made certain that the file with checksum 'f190..' is secure, correct
and should be used within this operation, enter the first 4 characters of the checksum
to unblock using this file on your own risk. Empty input will discard the file.

Unblock or discard? [f190/...? shows all options] (discard): 

[linuxiorr]

Yesterday & today (2026/07/07) I got the same one as Mirppc posted.

[Senzorei]

Experienced the same issue today (2026-07-07) with the following

Retrieving: libmbedcrypto16-3.6.6-1.2.x86_64 (repo-oss)                                                (452/2733), 617.1 KiB    
Retrieving: libmbedcrypto16-3.6.6-1.2.x86_64.rpm .........................................................................[done]

Warning: Digest verification failed for file 'libmbedcrypto16-3.6.6-1.2.x86_64.rpm'
[/var/tmp/zypp.tmp/AP_0xfo3vi4/x86_64/libmbedcrypto16-3.6.6-1.2.x86_64.rpm]

  expected 1521a56b09dc64e6c5511d8f3111c58a3b1bdb63ce0535273099fab5ecf2cf82aa1c946529d07d2a02b68654374192fd267df90ad3d3ab260631e79fe4c261af
  but got  f1905f58ec69b547e379a6b4181715105d740553682932ab1f581fd70135073288647b2473590a3b18fc7463ae1b0fb3f1b93332a0c838babe45ad3c4f07475f

Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise.

However if you made certain that the file with checksum 'f190..' is secure, correct
and should be used within this operation, enter the first 4 characters of the checksum
to unblock using this file on your own risk. Empty input will discard the file.

Unblock or discard? [f190/...? shows all options] (discard): 

[collindeel]

I also encountered the same issue:

Warning: Digest verification failed for file 'libp256m-3.6.6-1.2.x86_64.rpm'
[/var/tmp/zypp.tmp/AP_0x7HdEu0/x86_64/libp256m-3.6.6-1.2.x86_64.rpm]

  expected a6184346c252c426739292776f828f30fd0d3e1990f1242a264f75d5ad511d220fc8b725e0d2e17d751662aaa24f2030d7f3ca4bb24cb03f7bc6a1b6f0ce1e56
  but got  79183aca915dddebfecaa58b07ac4d3cd89287d40852c260b7df752a9f5a82e66621a9b7d6004c8f650a969e740da8401bfe4ddcbade65d5eb721be803342e83

All of these issues seem to be related to the mbedtls-3 package.

[andrii-suse]

Overall 3 common reasons may lead to this symptom:

1. The file is corrupted on some of mirror.
2. OBS did republish different file with the same name. It may happen e.g. if source rpm changed.
3. The file was corrupted during transfer.

To classify each case - one needs to review /var/log/zypper.log and corresponding mirrors, sometimes history of package on OBS, etc.

Unfortunately none of this problems is easy to fix on the MirrorCache side.

I have reported https://bugzilla.opensuse.org/show_bug.cgi?id=1271326 in attempt to work around it on the client side.

[Mirppc]

The Workarounds are not really a good solution as they are not easy to execute. This is a problem ithat is rearing its head up recently and more and more
1. Auto-Retry with Bypassed Mirrors: Upon a digest verification failure, Zypper should automatically discard the corrupted payload and attempt a retry.

It can and it does so for the same mirror with no option to change on the user end. Not a valid workaround

2. Bypass Redirection on Retry: To ensure the retry succeeds, Zypper should bypass the mirror network and request the package directly from the primary server. This can be easily achieved by appending ?nomirrors=1 or ?redirect=0 to the download URL (supported by MirrorCache/download.opensuse.org), forcing the main server to serve the authoritative, correct file directly.

Not a good option if the primary mirror is not in a good locale and performs horrible with consistent timeouts. This is especialy true when under a heavier load.

3. Fallback Strategy: If a download from a redirected mirror fails checksum verification: * Attempt 1: Try downloading again from a different mirror (if multiple are listed). * Attempt 2: Fallback to the main server directly with ?nomirrors=1 or ?redirect=0. * Only prompt/fail if the download from the authoritative main server also fails verification.

This is just a more indepth of workaround 1 and 2. "just use a different mirror".

So one example found is the Leaseweb mirrors including the SFO mirror and others in the US consistantly seem to have issues with libmbed and corresponding libraries.

Also choosing to just hit the primary mirror and only it (in the case of the US the Provo Mirror) defeats the point and purpose of mirrorcache. This is beginning to sound not only like a mirrorcache issue, but a zypper issue and an infastructure issue.

I do agree however about zypper needing to be able to resolve this. It should attempt to try with another mirror like it does when it hits a 404.

However i will post the logs from zypper the next time i experience this and i suggest others do the same. The barrier for entry here on github is less than the bugzilla.