Since a few days ago, every delta RPM seems to fail for me. I always had one or the other failing, but now it is every delta RPM in the transaction. The error I get is: md5 mismatch of result.
I am a bit concerned why this is the case. I know the package will be downloaded as normal RPM later, but why is there always a mismatch? Is this a sign for a virus? (which would infect installed packages, therefore the mismatch)
I had rkhunter, tripwire & unhide running for quite some time now, but they never detected anything out of ordinary.
I have already done $dnf clean packages (which was recommended in a similar topic from some years ago), but it didn’t help.
I am running Fedora 33, KDE spin, fully up-to-date against the updates-stable repo. Note that I came from F29 all the way here, so this isn’t a fresh installation.
That is an issue with as little as a single bit getting flipped during download. Dnf will retry until it gets a valid download or runs out of mirrors to try, and if the failure is on a drpm it falls back to the full rpm.
I am confused by your statement that you are using the updates-stable repo. AFAIK there is no repo by that name in fedora 33. The only main repos are fedora (containing the base packages) and updates (containing the latest updates). There is a repo called stable during beta testing of the upcoming release but for f33 that has been gone for more than 6 months.
I have done the system-upgrade route for several years and unless upgrading to the beta release I never see that stable repo.
Sorry for the confusion, I meant the “updates” repo (I said stable, since there is also updates-testing).
I know that that error can be caused by multiple reasons, including download bitflips. However, this never happened so often and persistent to me (as in 17 DRPMs got downloaded, and 17 failed), and I haven’t changed hardware. I mainly wanted to ask, since I am really paranoid. I wanted to reassure that this is not also a potential sign for malware.
Am I correct to assume that Delta RPMs compare the RPM I have locally installed and the “new” version that I’m upgrading? What I fear is that the update packages that I download are original, but that the local copy it is compared against got infected, and thus the delta RPM would fail.
I didn’t find any trace of malware yet, but I still have a strange feeling. Therefore, I wanted to post this here, in hope anyone would find an error in my reasoning & could disprove the malware thought.
I think rpm -Va should list any alterations made to installed package files. It might be a long list if you customized a lot of configurations files. If you see things listed in there that you don’t think should be different from their original installed version (e.g. binaries under /usr), that might be a sign that something is messing with your system.
I don’t know for sure, but I suspect that drpm uses essentially the same mechanism to check if the installed rpm has been modified. When you see a list of drpms failing, you might answer “no” to abort the installation and then examine the specific installed rpms with rpm -V <package-name> to see exactly what is causing the problem.
Just from reading the man page for applydeltarpm, it looks like it depends on the options that are passed at installation time:
applydeltarpm applies a binary delta to either an old rpm or to on-disk data to re-create a new rpm. The old rpm can be specified with the -r option, if no rpm name is provided on-disk data is used. You can use -p to make applydeltarpm print the percentage of completion, or -v to make it more verbose about its operation.
The second an third form can be used to check if the reconstruction is possible. It may fail if the on-disk data got changed (deltarpms are created in a way that config file changes do not matter) or the deltarpm does not match the rpm the delta was generated with. The -c option selects full (i.e. slow) on-disk checking, whereas -C only checks if the filesizes have not changed.
This is not at all malware. It’s a bug.
Basically zstd (the compression library) started compressing things differently and builders needed to be updated to use the new library. See 1873876 – md5 mismatch result of kernel-devel drpm for details.
Things should start working again soon, and in the mean time the only issue is that you have to download the full rpm.
