SLE15-SP1 Digest verification failed (using RMT)

SUSE Linux Enterprise Server SLES Configure-Administer
1

Hey,
This is what I’m recently getting (using RMT). Anything to worry about?

# zypper ref -fs
Refreshing service 'Basesystem_Module_x86_64'.
Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'.
Refreshing service 'Server_Applications_Module_x86_64'.
All services have been refreshed.
Forcing raw metadata refresh
Retrieving repository 'SLE-Module-Basesystem15-SP1-Pool' metadata ................................................................................................................................................................................[done]
Forcing building of repository cache
Building repository 'SLE-Module-Basesystem15-SP1-Pool' cache .....................................................................................................................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'SLE-Module-Basesystem15-SP1-Updates' metadata --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------[/]

Warning: Digest verification failed for file 'a6c99477e7e2ed666cfdc957f7612ead3384cd0a6961d7f669c6bb0678e55136-primary.xml.gz'
[/var/tmp/AP_0xdXEfCu/repodata/a6c99477e7e2ed666cfdc957f7612ead3384cd0a6961d7f669c6bb0678e55136-primary.xml.gz]

  expected a6c99477e7e2ed666cfdc957f7612ead3384cd0a6961d7f669c6bb0678e55136
  but got  2729cc39951a708e8fb271fddfdfe0a6b0df0af28fb122f4ebbe0857c3b007e5

Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise.

However if you made certain that the file with checksum '2729..' is secure, correct
and should be used within this operation, enter the first 4 characters of the checksum
to unblock using this file on your own risk. Empty input will discard the file.

Best regards,
Marki

2

Hi
I would suggest discarding the file and try again later, in my experience it’s been updates syncing with the CDN mirrors and a transient issue. Wait a few hours and try again.

3

It turns out this seems to have been related to a full disk on the RMT server. hits head on table

4

Hi
Oh dear!!! thanks for reporting back on the underlying issue…