Description of problem:
During actualization there error is displayed
package ethtool-1:5.4-1.mga7.x86_64 does not verify: Payload SHA256 digest: BAD (Expected 69fbcb0b7f96f3d7284837fa5faf2dc99433bd6f590aa259c59b22eacef3c578 != a589484a735d0b19931989f284aa262aab6f756d18a3e852bde59cd916282df3)
Version-Release number of selected component (if applicable):7.3
error repeats on multiple instalations
Steps to Reproduce:
2. confirm actualization
Can you please clarify "actualization"? Do you mean a system update?
On my own system I see that 'ethtool' was indeed updated very recently, from ethtool-5.3-1.mga7 to ethtool-5.4-1.mga7; so I guess that is what you are talking about.
Did it stop all the pending updates, or do the others?
If this happened with the automatic system update check, or via Mageia Control Centre-Manage Software-Update your System, you are given the list of updates available, with the option to UNtick some. So if the failure did block all the other updates, UNtick 'ethtool' in the list to get the rest done.
> Payload SHA256 digest: BAD
means the checksum for the downloaded pkg was incorrect. It almost always means a bad download. You say it happens repeatedly; can you try, or have you tried, a different mirror? It is important to do this in such a situation: it is possible that the copy on the mirror you are using is corrupt.
[Very rarely indeed this sort of error can mean that the checksum itself is wrong, but this cannot be the case here, otherwise many people (myself included) would have already suffered the same fault.]
If it was a bad download, it may be necessary to run "urpmi --clean" (as root)
to delete the corrupt copy, so that it will then re-download a complete copy.
The rpm package itself is ok, and with it the ethtool command is working
here, both in Mageia 7 and Cauldron.
This has been adequately addressed by Lewis and Dave's comments. Thanks guys.
ethtool package actualization is impossible due to checksum error =>
ethtool package installation is impossible due to checksum errorResolution:
(In reply to Dave Hodgins from comment #2)
> If it was a bad download, it may be necessary to run "urpmi --clean" (as
> to delete the corrupt copy, so that it will then re-download a complete copy.
Good reminder. I had forgotten this point (having proposed it in the past...)
"urpmi --clean" colved the problem. Probably, there was load corrupted RPM from the mirror ftp.fi.muni.cz and without --clean urpmi was unable to reload correct version. Now, the content of this mirror is OK.