On 03/10/2019 00.31, Lew Wolfgang wrote:
On 10/2/19 12:48 AM, Carlos E. R. wrote:
On 02/10/2019 06.49, Lew Wolfgang wrote:
On 10/01/2019 05:03 PM, Felix Miata wrote:
Lew Wolfgang composed on 2019-10-01 16:44 (UTC-0700):
...
It's a fresh install on a blank partition, the installation is being stopped by the error. I'm able to "ignore" the error, but that "could" be ill-advised.
I just tried "zypper -v in -f -d libxcb-icccm4" on a running 15.1 system on the same subnet which produced no error. So it's something the installation process is doing? Well, it means, probably, that there was an error on the download of that package. And a retry hits the same error because the file is already downloaded and cached (thus the "zypper clean").
This was a fresh install on a newly formatted partition, nothing should have been in cache.
But when zypper runs, there is. The rpm is downloaded and has to be written somewhere; then it is installed, and the rpm can be deleted.
You could, on another terminal (ctrl-alt-X gives a terminal during installation), find that file in the disk and delete it, then retry. Should be under "/var/cache/zypp/packages/*".
Nope, nothing in there.
Oops. That's the path for the running system, not the hard disk.
The alternative is to just skip that package, and install it later, after rebooting the system. Even then, you might have to locate the cached file and delete it.
I then "ignored" the digest warning and the install proceeded. But at first reboot the system came up with a black screen with the cursor stuck in the middle. I was able to login remotely and then ran "zypper in libxcb-icccm4-0.4.1-lp151.2.2.x86_64", rebooted, and all seems to be well.
Well, all is good if it ends well :-)
As a guess, maybe I was hitting a mirror containing a corrupted libxcb-icccm4 rpm that failed the hash check? Then, hit a different mirror after rebooting? Maybe I should have run a "zypper lr -U" while it was still in the install mode. Maybe next time?
It is a possibility. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)