Signature verification failed for file 'repomd.xml' from repository 'openSUSE-Leap-42.2-Update'.

Hi
I would delete them all and any gpg pubkeys and add them back one at a time to see which ones work and which don’t. Run zypper clean all after you delete.

Removed repos.
Deleted the pubkey.

zypper clean -a
Could not clean the repositories because of errors.

zypper ar -f -g -n "openSUSE-Leap-42.2-Oss-Update" http://download.opensuse.org/update/leap/42.2/oss/ repo-oss-updateAdding repository 'openSUSE-Leap-42.2-Oss-Update' ............................................................................[done]
Repository 'openSUSE-Leap-42.2-Oss-Update' successfully added

URI         : http://download.opensuse.org/update/leap/42.2/oss/
Enabled     : Yes                                               
GPG Check   : Yes                                               
Autorefresh : Yes                                               
Priority    : 99 (default priority)                             

Repository priorities are without effect. All enabled repositories share the same priority.

zypper ref
Retrieving repository 'openSUSE-Leap-42.2-Oss-Update' metadata ------------------------------------------------------------------|]

New repository or package signing key received:

  Repository:       openSUSE-Leap-42.2-Oss-Update                       
  Key Name:         openSUSE Project Signing Key <opensuse@opensuse.org>
  Key Fingerprint:  22C07BA5 34178CD0 2EFE22AA B88B2FD4 3DBDC284        
  Key Created:      Mon May  5 03:37:40 2014                            
  Key Expires:      Thu May  2 03:37:40 2024                            
  Rpm Name:         gpg-pubkey-3dbdc284-53674dd4                        


Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): a
Signature verification failed for file 'repomd.xml' from repository 'openSUSE-Leap-42.2-Oss-Update'.
Warning: This might be caused by a malicious change in the file!
Continuing might be risky. Continue anyway? [yes/no] (no): 

Not sure what else to do.

And I’m thinking a DVD upgrade to 42.3 will not fix the issue, either?

Hi
So you didn’t play around with the zypper/zypp configuration files at some point?

Well, I don’t recall. I know on one OS version I changed the refresh interval to 0.

Quickly looking through /etc/zypp/zypp.conf and zypper.conf, dated 12/15/16, shows all comments, nothing active.
Anywhere else to check?

Hi
Well the only other thing I can think of is a funky mirror your being directed to…

So on this page;
http://download.opensuse.org/update/leap/42.2/oss/repodata/repomd.xml.mirrorlist

Pick a mirror and add that url instead of download.opensuse.org, eg;

http://www.gtlib.gatech.edu/pub/opensuse/update/leap/42.2/oss/

In /var/cache/zypp/raw/repo-oss-updatenmr1gy/repodata/, repomd.xml is a bunch of gibberish, binary or something. The .asc and .key appear to be public keys.

I’m directed to the very close mirrors are France and the Netherlands. Could that have a charset issue? Well, I used two in the U.S., texas, one of them and same thing. But this might be thinking in a right direction.

Hi
AFAIK, active repos ‘Alias’ should exist in raw and solv (includes @System) so if funky ones there delete them…

I’m speculating that your GPG library or the GPG app itself has somehow corrupted.

I’d recommend either

  1. Do a distro-upgrade. Over-ride the warning and proceed anyway. Doing this carries a small risk that someone might be re-directing you to an unofficial repo, but if the risk is acceptable then it’s possibly the fastest way to likely resolve, run the following with your LEAP 42.2 repos enabled
zypper dup
  1. Download a 42.2 DVD and do a repair, followed by an update (zypper up, not zypper dup). Unlike doing a “zypper dup” this utilizes only trusted install sources and should restore both your keys and the apps using those keys. This will likely take hours even over a fast Internet connection but should be a reliable and simple path to fix your problem.

TSU

I thought I’d try to say risk refreshing the update repo.


zypper ref repo-oss-update
Retrieving repository 'openSUSE-Leap-42.2-Oss-Update' metadata ------------------------------------------------------------------|]
Signature verification failed for file 'repomd.xml' from repository 'openSUSE-Leap-42.2-Oss-Update'.
Warning: This might be caused by a malicious change in the file!
Continuing might be risky. Continue anyway? [yes/no] (no): y
Retrieving repository 'openSUSE-Leap-42.2-Oss-Update' metadata ...............................................................[done]
Building repository 'openSUSE-Leap-42.2-Oss-Update' cache ....................................................................[done]
Error building the cache:
|] Failed to cache repo (1).
Skipping repository 'openSUSE-Leap-42.2-Oss-Update' because of the above error.
Could not refresh the repositories because of errors.

Don’t know what that means.

Maybe I’ll try the DVD repair next.

I thought there was a repair option on the DVD iso, but booting my ISO menu option just starts the install process. Do I not have an option correct on the menu entry?

 linux (loop)/boot/x86_64/loader/linux install=hd:$isofile nosplash showopts
 

A distro-upgrade, does that keep it at 42.2 or go to something else? Which repos are needed?

When it downloads the repomd.xml, the file contains garbage. But from the browser, I can open it and it’s an xml file.
Choosing a different mirror does not help.
The file size from the browser lists it as 3.7K while the temporary file from the refresh is 1.2K full of gibberish.
By comparison, the .asc and .key files have the right size and appears to be key info.

I made a DVD, selected the upgrade option, set up the network, it checked for online repos,
and listed none.

It also wanted to delete all my packages from packman (no repository) and downgrade existing packages. Not sure how this would be much different than a fresh install.

If I do zypper dup, will that be the same as far as downgrading? Maybe that’s what I want?

On the DVD menu, there is upgrade and rescue. Rescue goes to a command prompt. No repair option.

If I do the upgrade and it sets my system back, what would be the problems with using snapper to pick a previous time? Does it set the whole system back or only select files and therefore the problem would still exist?

Do the upgrade which downgrades everything. That ensures replacing existing files. It’s also why you will want to do an update after the downgrade to recover the latest versions of your files.

There won’t be a problem with Snapper. BTRFS images always increment (never decrement) no matter whether you roll back to old versions of anything. BTRFS history is never lost or corrupted. You can think of this as “Taking a step forward to go back in time.” And, just because you went back in time that doesn’t erase what you did with newer files before you went back.

You can do your DVD “upgrade” offline since you should be using files only on the DVD, nothing online.

Needless to say,
Although the chance of things going very wrong is small, you should back up or copy any/all important files to separate storage before doing any of this.

TSU

Thinking I’m getting to the state where it’s going to require a lot of work and internet time, I’m considering my system lost. So then I thought, why not ignore the integrity check. It downloaded a gibberish repomd.xml, so I used the browser to download a correct one, placed it in the /var/cache/zypp/raw/repo-oss-update/repodata/ directory, loaded Yast software update, and it showed the following only checked option in the patch list, two statements out of many I thought interesting:

Fix media verification to properly propagate media access errors. (bsc#1031093)

1032632 (bugzilla) : Unexpected zypper cache behavior

It restarted the online update and I let it update everything checked. It gave an error I recall seeing before:

Subprocess failed. Error: RPM failed: Free diskspace below /boot: 42603296 blocks
error: unpacking of archive failed on file /lib/modules/4.4.74-18.20-default/kernel/drivers/w1/slaves/w1_therm.ko: cpio: rename failed - No space left on device
error: kernel-default-4.4.74-18.20.1.x86_64: install failed

But checking the disk, there was 19.6 GiB free of 41.0 GiB.
Looking at y2log:


2017-07-24 10:43:43 <1> linux-0nfz(18869) [zypp++] ExternalProgram.cc(checkStatus):513 Pid 20929 successfully completed
2017-07-24 10:43:43 <1> linux-0nfz(18869) [Ruby] modules/PackageCallbacks.rb:520 Additional RPM otput: 
2017-07-24 10:43:44 <1> linux-0nfz(18869) [zypp++] ExternalProgram.cc(start_program):249 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-i' '--percent' '--noglob' '--force' '--nodeps' '--' '/var/cache/zypp/packages/repo-oss-update/x86_64/kernel-default-4.4.74-18.20.1.x86_64.rpm'
2017-07-24 10:43:44 <1> linux-0nfz(18869) [zypp++] ExternalProgram.cc(start_program):412 pid 20932 launched
2017-07-24 10:43:53 <1> linux-0nfz(18869) [zypp++] ExternalProgram.cc(checkStatus):506 Pid 20932 exited with status 1
2017-07-24 10:43:53 <5> linux-0nfz(18869) [zypp] Exception.cc(log):137 RpmDb.cc(doInstallPackage):2043 THROW:    Subprocess failed. Error: RPM failed: Free diskspace below /boot: 42603296 blocks
2017-07-24 10:43:53 <5> linux-0nfz(18869) [zypp] Exception.cc(log):137 error: unpacking of archive failed on file /lib/modules/4.4.74-18.20-default/kernel/drivers/w1/slaves/w1_therm.ko: cpio: rename failed - No space left on device
2017-07-24 10:43:53 <5> linux-0nfz(18869) [zypp] Exception.cc(log):137 error: kernel-default-4.4.74-18.20.1.x86_64: install failed
2017-07-24 10:43:53 <5> linux-0nfz(18869) [zypp] Exception.cc(log):137 
2017-07-24 10:43:53 <5> linux-0nfz(18869) [zypp] Exception.cc(log):137 
2017-07-24 10:43:53 <1> linux-0nfz(18869) [Ruby] modules/PackageCallbacks.rb:422 DonePackage(error: 3, reason: 'Subprocess failed. Error: RPM failed: Free diskspace below /boot: 42603296 blocks
error: unpacking of archive failed on file /lib/modules/4.4.74-18.20-default/kernel/drivers/w1/slaves/w1_therm.ko: cpio: rename failed - No space left on device
error: kernel-default-4.4.74-18.20.1.x86_64: install failed

I did a retry, and it continued installing, wanting to reboot now. Don’t know if any of this is useful.

Which, after rebooting, did not help. I would have to download the repomd.xml for each repo. Not the most convenient, but a lot more than going into the library to copy all the files.

Not sure why the repomd.xml file is getting scrambled on the update. From the browser, instead of saving as, I thought I would try dragging the file across to my local folder and it was scrambled, too. Never had much luck with dragging files over, so maybe it was copying it from somewhere else than the Internet.

If someone could tell me which part of Yast would be responsible for downloading the repomd.xml file, I could copy that across or revert to a previous version.

Another thought is since it is only the xml files, something is interpreting them in a scrambled way.

I noticed in http://download.opensuse.org/distribution/leap/42.2/repo/non-oss/
it flags “content” as having the verification problem.
When I try to open it up, it opens in Ark first as content.uncompressed. Opening that shows a readable file. Looking at the file’s properties shows it’s considered a Gzip archive. I can open it directly in kwrite. The filesize is 1,413 bytes but the one downloaded from the browser is 2587. The content looks like it matches between the two files.

Could that be what is happening to both content and repomd is that they are being archived?

It’s common for certain downloaded files to be compressed, and that can happen a number of different ways… by the application, by the web server, by a proxy server, etc. In any case, I doubt it’s going to lead to a solution.

I’m going to guess that since no one else seems to be experiencing the problem you’re describing that the problem has to be unique to your system and isn’t a widespread problem.

The steps I described using a DVD should solve this type of problem the most practical way… When no one can replicate a problem then it’s hard for anyone to know exactly what your problem is. For that reason, the DVD downgrade and then update steps I describe is more or less a “fix everything possible” approach rather than trying to pinpoint the specific problem which is likely difficult to identify.

TSU