Signature verification failed

[f.gruber]

Das KDE-Plasma Aktualisierungs Miniprogramm meldet bei einem meiner Suse Rechner, es handelt sich um Suse 15.2 auf einer VirtualBox VM:

Code: Alles auswählen

Signature verification for Repository packman.inode.at-openSUSE_Leap_$releasever failed 

... aber nicht nur beim Packman Repositorys sondern auch bei (allen?) anderen.

Habe alles Erdenkliche probiert:
Habe mit YAST / Repositories die GPG Schlüssel alle gelöscht und dann alle Repos gelöscht - mit YAST oder auch auf Dateisystemebene:

Code: Alles auswählen

/etc/zypp/repos.d

und dann mit YAST die Community Repos wieder neu hinzugefügt. Es wird brav abgefragt, ob ich den Signaturschlüsseln traue. Alles OK ...

Doch dann starte ich das Applet aus dem Systemtray und es kommen wieder die gleichen Fehlermeldungen.

Eine einfache Lösung ist, die Softwareaktualisierung im Systemabschnitt der Kontrolleiste zu deaktivieren, das ist mir schon klar.

Aber mich würde doch interessieren, wie man das reparieren kann.

Da ich mehrere Suse Rechner habe, könnte ich ja gewisse Verzeichnisse einfach drüberbügeln, ich denka da an /etc/zypp und /var/cache/zypp bzw. /var/cache/zypper oder /var/cache/PackageKit.

Weiß nicht, ob solche Methoden zu empfehlen sind.

Kann mir jemand einen Rat geben?

[Sauerland]

Poste:

Code: Alles auswählen

zypper up

[f.gruber]

Nachdem ich zypper up gestartet habe, werde ich erwartungsgemäß gefragt, ob ich dem Signaturschlüssel vertraue. Ich wähle "i" - also immer vertrauen. Die Aktualisierung wird durchgeführt.
Hier die Ausgabe von zypper up

Code: Alles auswählen

Neuen Signierungsschlüssel für Repository oder Paket erhalten: 

 Repository:               Packman Repository 
 Name des Schlüssels:      PackMan Project (signing key) <packman@links2linux.de> 
 Schlüssel-Fingerabdruck:  F8875B88 0D518B6B 8C530D13 45A1D067 1ABD1AFB 
 Schlüssel erstellt:       Di 16 Sep 2014 00:18:00 CEST 
 Ablauf des Schlüssels:    Fr 13 Sep 2024 00:17:21 CEST 
 RPM-Name:                 gpg-pubkey-1abd1afb-54176598 


Wollen Sie den Schlüssel abweisen, ihm temporär oder immer vertrauen? [a/t/i/?] (a): i 
Metadaten von Repository 'Packman Repository' abrufen ....................................................................[fertig] 
Cache für Repository 'Packman Repository' erzeugen .......................................................................[fertig] 
Repository-Daten werden geladen... 
Installierte Pakete werden gelesen... 

Die folgenden 9 Pakete werden aktualisiert: 
 libQtWebKit4 libsystemd0 libsystemd0-32bit libudev1 libudev1-32bit sddm-branding-openSUSE systemd-32bit systemd-bash-completion 
 yast2-nis-client

Sicherheitshalber habe ich nachher das System neu gestartet.

Und das Aktualisierungswidget beklagt sich wieder, dass der Signaturschlüssel nicht verifiziert werden kann ...

Code: Alles auswählen

Signature verification for Repository packman.inode.at-openSUSE_Leap_$releasever failed 

[Sauerland]

Poste mal:

Code: Alles auswählen

ls -al /etc/zypp/repos.d/

[f.gruber]

Code: Alles auswählen

ls -al /etc/zypp/repos.d/
insgesamt 44
drwxr-xr-x  2 root root 4096  7. Nov 17:04 .
drwxr-xr-x 11 root root 4096  6. Nov 15:39 ..
-rw-r--r--  1 root root  203  7. Nov 17:37 packman.inode.at-openSUSE_Leap_$releasever.repo
-rw-r--r--  1 root root  176  7. Nov 17:37 repo-debug.repo
-rw-r--r--  1 root root  189  7. Nov 17:37 repo-debug-update.repo
-rw-r--r--  1 root root  178  7. Nov 17:37 repo-non-oss.repo
-rw-r--r--  1 root root  168  7. Nov 17:37 repo-oss.repo
-rw-r--r--  1 root root  178  7. Nov 17:37 repo-source.repo
-rw-r--r--  1 root root  211  7. Nov 17:37 repo-update-non-oss.repo
-rw-r--r--  1 root root  174  7. Nov 17:37 repo-update.repo
-rw-r--r--  1 root root  127  7. Nov 17:37 suse.repo

[Sauerland]

Jetzt poste mal:

Code: Alles auswählen

cat /etc/zypp/repos.d/packman.inode.at-openSUSE_Leap_$releasever.repo

Code: Alles auswählen

-rw-r--r--  1 root root  203  7. Nov 17:37 packman.inode.at-openSUSE_Leap_$releasever.repo

Mal löschen und mit anderem Namen hinzufügen.
Keine Sonderzeichen.......

[f.gruber]

Ich habe die Variable $releasever ersetzt durch "15.2".
Die URL hab ich im Internet überprüft, sie existiert.

Code: Alles auswählen

[packman.inode.at-openSUSE_Leap_15.2]
name=Packman Repository
enabled=1
autorefresh=1
baseurl=http://packman.inode.at/suse/openSUSE_Leap_15.2/
path=/
type=rpm-md
priority=90
keeppackages=0

Jodoch geholfen hat es nicht. Die Fehlermeldung beim Abrufen der Aktualisierungen bleibt.

[susejunky]

Hallo f.gruber,

Das KDE-Plasma Aktualisierungs Miniprogramm meldet bei einem meiner Suse Rechner, es handelt sich um Suse 15.2 auf einer VirtualBox VM:

Code: Alles auswählen

Signature verification for Repository packman.inode.at-openSUSE_Leap_$releasever failed 

... aber nicht nur beim Packman Repositorys sondern auch bei (allen?) anderen.

ich nehme an Du meinst hier plasma5-pk-updates welches wiederum auf PackageKit basiert.

Vorab: Ich verwende keines dieser Programme und habe sie auf meinen Systemen auch nicht installiert.

Soweit mir bekannt, hat PackageKit zwar ein zypper-Backend verwaltet aber die GPG-Signaturen zum Verifizieren der Pakete selbst. Vielleicht hilft Dir

Code: Alles auswählen

> man pkcon

oder http://ww.packagekit.org weiter.

... Aber mich würde doch interessieren, wie man das reparieren kann.

Da ich mehrere Suse Rechner habe, könnte ich ja gewisse Verzeichnisse einfach drüberbügeln, ich denka da an /etc/zypp und /var/cache/zypp bzw. /var/cache/zypper oder /var/cache/PackageKit.

Ich vermute, dass Dein Problem ausschließlich durch PackageKit verursacht wird, kann Dir aber leider nicht sagen, wo und wie PackageKit seine Daten ablegt und welche davon Du löschen (d.h. weg-kopieren) könntest, um Dein Problem zu lösen.

Viele Grüße

susejunky

[f.gruber]

Tut mir leid, ich habe die Geduld verloren.

Ich habe von einer anderen Maschine per rsync das System über die VM drübergebügelt.
/etc/fstab, die Passwortdateien, /home und noch ein paar Sachen habe ich excluded.

Dann konnte ich zwar die VM starten aber Plasma blieb hängen. Nach langem Herumprobieren kam mir dann doch die rettende Idee. Ich vermutete dass es was mit den Virtualbox Gasterweiterungen zu tun haben könnte.

Der Displaymanager hat ja funktioniert. Ich konnte mich einloggen mit dem icewm Windowmanager und so konnte ich Dolphin starten und die GuestAdditions als virtuelles Laufwerk einhängen. Dass man das auch auf der Konsole könnte, weiß ich zwar, habe aber vergessen, wie es geht

Nun habe ich das Installationsscript der Virtualbox Gasterweiterungen gestartet und nach einem Reboot war alles ok.