When i usually get “Warning: Digest verification failed” for some repo which goes away normally, but this time i don’t know why so many of my repos are affected. Even tried reboot and its the same.
Like KUF repo, Mega client repo etc ( i guess these don’t have mirror brain like the official leap repos).
Full list of Warnings/Errors- http://paste.opensuse.org/73327416 .
- you only refreshed your repositories, you might want to update your OSS repos first, before refreshing your other repos later. This would generally resolve any possible issue that might exist on your machine.
zypper update
- If you’ve updated your machine and that refresh all your repos (not in the same step), then you might
a. Check whether the repo URI are still valid. I see those errors like for your Cinnamon repo which aren’t found altogether, not just that the hash can’t be unencrypted
b. Inpsect and if necessary post the exact locations (uri) of your repos, the following command not only lists by name but also describes the URI
zypper lr -d
TSU
Before your reply i got some instructions from the irc, so i will summarize it :
My zypper lr -uPE - ( SUSE Paste )
After it was suspected curl might be broken-
zypper --no-refresh se -si curl
S | Name | Type | Version | Arch | Repository
–±----------------±--------±-------------±-------±----------------------
i | curl | package | 7.37.0-7.1 | x86_64 | (System Packages)
i | libcurl4 | package | 7.37.0-7.1 | x86_64 | (System Packages)
i | python-pycurl | package | 7.19.0-3.2 | x86_64 | openSUSE-Leap-42.1-Oss
i | python3-pycurl | package | 7.19.5.1-2.2 | x86_64 | openSUSE-Leap-42.1-Oss
i | qemu-block-curl | package | 2.3.1-12.1 | x86_64 | (System Packages)
Seems “Systempackages” means there should be OSS, So i was asked to downdload curl,libcurl4,python-pycurl,python3-pycurl,qemu-block-curl rpms from here - http://download.opensuse.org/distribution/leap/42.1/repo/oss/suse/x86_64/
and install them manually with **rpm -Uhv --force **.
while installing them, i don’t get why there were version changes.
sudo rpm -Uhv --force curl-7.37.0-5.2.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:curl-7.37.0-5.2 ################################# 50%]
Cleaning up / removing...
2:curl-7.37.0-7.1 ################################# [100%]
sudo rpm -Uhv --force libcurl4-7.37.0-5.2.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:libcurl4-7.37.0-5.2 ################################# 50%]
Cleaning up / removing...
2:libcurl4-7.37.0-7.1 ################################# [100%]
sudo rpm -Uhv --force python-pycurl-7.19.0-3.2.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:python-pycurl-7.19.0-3.2 ################################# [100%]
sudo rpm -Uhv --force python3-pycurl-7.19.5.1-2.2.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:python3-pycurl-7.19.5.1-2.2 ################################# [100%]
udo rpm -Uhv --force qemu-block-curl-2.3.1-7.2.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:qemu-block-curl-2.3.1-7.2 ################################# 50%]
Cleaning up / removing...
2:qemu-block-curl-2.3.1-12.1 ################################# [100%]
But after this the “zypper ref” worked fine. And when i tried “zypper up” after this i again get updates for those curl and curl related packages which i just installed via rpms.
The curl packages that are available for me are only from the official leap repos and my Leap repos are prioritized well. But i don’t know why different versions of curl exist inside Leap repos itself.
I still don’t know how curl was broken or what ever happened that caused so many “Digest Verification Failed Warnings” for almost all repos. I am going to try “zypper up” and try to update all packages along with those curl packages and hope the same thing doesn’t repeat.
So you understand what you did,
You downloaded and installed package versions from when LEAP was first released,
Then you did a “ref” and re-updated these packages installing latest versions available.
Which is fine.
It’s unknown whether your system had corrupted packages or faulty installed packages (In my experience usually the latter).
Running “zypper up” <most likely> would have accomplished the same end result without so much manual work downloading those curl packages individually and forcing downgrades and then re-installing new.
Glad to hear your problem was resolved and got good advice on IRC,
TSU
Is there anyway to tell how it got the corrupted packages or installed faulty packages in the first place ? Since among the repos(which are well prioritized) and only the official repos offered ‘curl’ packages i am not able to figure how this happened.
“Things” happen that are not explainable sometimes,
There are a lot of things that happen under the surface which can cause anomalies, as a User you need to just be attentive to anything that might be even slightly not right and evaluate their immediate and possible cumulative effects.
So, for instance…
You might have had a network glitch which might have disrupted the stream of packets to your machine.
TCP/IP <should> test for integrity to a limit(not fail safe) and ask to resend any missing or damaged packets.
Out of order packets have to be re-constructed properly.
Your machine needs to install your package which means not only writing new files, possibly replacing old files and <also> make modifications to any files or configurations that interact with the files you are newly installing.
If <anything> glitches during what is described above, then something <might> not function correctly.
It’s sometimes a wonder that things work so reliably considering everything that <might> go wrong so when an anomaly is detected, you just need to recognize what the problem is, and address it (re-install re-doing configurations).
Your experience is with a relatively simple function (zypper).
For SysAdmins who build complex systems, the chance for glitches can be manyfold, so it then becomes almost a necessity to allow time to re-build multiple times to be sure the install went properly.
TSU