Le 10/10/22 à 10:31, Ben Holmes a écrit :
G'day All,
When doing an update, I have noticed that I am getting more bad checksums than usual.
A few retries seem to fix the issue, but it is happening a lot. It is more in OBS repos (but it happened a little while ago from OSS main, and in amarok-lang from Packman). It occurs more in large files so retries are a pain. I have uninstalled a few games that I had on here that had big files (ufoai etc -- my son can reliably beat me now anyway).
This is a recent example from my last update (this time it is Ghidra from security:forensics, and although this one seems to be a major culprit, it happens randomly but more in large files in lesser-used OBS repos):
--------------
... Retrieving package ffe-0.3.2-2.969.x86_64 (68/76), 55.5 KiB ( 99.4 KiB unpacked) Retrieving: ffe-0.3.2-2.969.x86_64.rpm ..........................................................................[done (14.5 KiB/s)] Retrieving package ghidra-10.1.5-2.47.x86_64 (69/76), 275.3 MiB (929.7 MiB unpacked) Retrieving: ghidra-10.1.5-2.47.x86_64.rpm ........................................................................[done (1.2 MiB/s)]
Warning: Digest verification failed for file 'ghidra-10.1.5-2.47.x86_64.rpm' [/var/tmp/AP_0xxsKeL3/x86_64/ghidra-10.1.5-2.47.x86_64.rpm]
expected a3febe663353584c193bceb91497920d8626af01380184964c49437c7c517a2d but got 57c981239bfdb0fdef0fdfd1db81d2d193b086b382ae90d2c28def4bfd98d2dc
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 '57c9..' 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? [57c9/...? shows all options] (discard): Package ghidra-10.1.5-2.47.x86_64 (Forensics Tools and Libraries (openSUSE_Tumbleweed)) seems to be corrupted during transfer. Do you want to retry retrieval? Abort, retry, ignore? [a/r/i] (a): r Retrieving package ghidra-10.1.5-2.47.x86_64 (69/76), 275.3 MiB (929.7 MiB unpacked) Retrieving: ghidra-10.1.5-2.47.x86_64.rpm ........................................................................[done (2.2 MiB/s)]
Warning: Digest verification failed for file 'ghidra-10.1.5-2.47.x86_64.rpm' [/var/tmp/AP_0xxsKeL3/x86_64/ghidra-10.1.5-2.47.x86_64.rpm]
expected a3febe663353584c193bceb91497920d8626af01380184964c49437c7c517a2d but got 8552a9e101c1ed3e6540a3690d728e0ab27324a3741614a06bf3ca33094782b5
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 '8552..' 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? [8552/...? shows all options] (discard): Package ghidra-10.1.5-2.47.x86_64 (Forensics Tools and Libraries (openSUSE_Tumbleweed)) seems to be corrupted during transfer. Do you want to retry retrieval? Abort, retry, ignore? [a/r/i] (a): r Retrieving package ghidra-10.1.5-2.47.x86_64 (69/76), 275.3 MiB (929.7 MiB unpacked) Retrieving: ghidra-10.1.5-2.47.x86_64.rpm ........................................................................[done (2.5 MiB/s)] Retrieving package termshark-2.4.0-2.30.x86_64 (70/76), 5.1 MiB ( 16.4 MiB unpacked) Retrieving: termshark-2.4.0-2.30.x86_64.rpm ....................................................................[done (563.0 KiB/s)] ...
--------------
Refreshes and cleans do not seem to fix it, and it also occurs on other networks (all in Australia though). I have not been having any other trouble with data corruption (network or storage related) on this machine. My zypper cache is on an XFS partition, and it has been working fine for a long time. There are no changes that I can think of on my side that could be causing this.
Is anyone else having this issue?
Is there something broken with the closest mirrors to AP?
Am I just updating right at the same time that the mirrors are updating... about 3 times a week (seriously unlucky)!?
-- Ben
I've been seeing this as well (also in Australia: Telstra in Perth). It seems to me like bigger downloads are just being cut off halfway through. I saw it briefly a week or so ago (with some big debuginfo packages), and switched the debug repository over to the NZ mirror, which seemed to resolve it. But it is now showing up even for non-debug packages (e.g. kernel-source-vanilla-6.0.0-1.2.noarch). The "downloads" complete unusually quickly, so I'm guessing it's a problem with the mirror. (The debug packages, which are still on the NZ mirror, seem to be fine.) (After all that, I re-ran it while sending this email, and it worked fine… maybe that's just luck, though.) -- David