Sagte ich schon, dass es besser ist, mit dem nicht funktionierenden Krypto-Quatsch aufzuhören und 'Tree verification' einfach auszuschalten?
Die Gentoo Entwickler haben hier einfach Mist programmiert. Das Ergebnis sind unzählige frustrierte Anwender und jede Menge Hilfe-Threads in den Foren.
Ich möchte gar nicht wissen, wie viele neue Nutzer (Anfänger) schon aufgegeben haben (ohne sich zu melden), weil sie 'emerge --sync' eingegeben haben und dann die völlig schwachsinnige Meldung 'gpg: keyserver refresh failed: General error ' erhalten haben, von der nicht einmal Experten wissen, was nun genau zu tun ist.
Auch dieser Thread treibt mir die Zornesröte ins Gesicht. ManfredB möchte (wenn ich es richtig verstehe) eigentlich Gentoo und Linux lernen, investiert hierfür eine Menge Zeit und bringt eine hohe Frustrationstoleranz mit sich (was ich sehr schätze). Aber er kommt gar nicht zu den spannenden Themen, für die es sich auch lohnen würde Zeit und Mühe zu investieren, weil er seine Zeit und Energie hier mit nicht funktionierendem Crypto-Quatsch verbringen muss. Was für ein Wahnsinn!
[gelöst] emerge --sync --quiet liefert wieder
Message
Danke für dein Statement, mike155
Aber nun kommts:
Ein neuer Schlüssel ist als importiert.
Ob das allerdings die Lösung ist, sei mal dahingestellt.
Gruß
Manfred
Aber nun kommts:
Code: Select all
gpg --keyserver hkps://keys.gentoo.org --search-keys "Gentoo Portage Snapshot Signing Key"
gpg: data source: https://keys.gentoo.org:443
(1) Gentoo Portage Snapshot Signing Key (Automated Signing Key)
Gentoo ebuild repository signing key (Automated Signing Key) <infrastr
4096 bit RSA key DB6B8C1F96D8BF6D, erzeugt: 2011-11-25, verfällt: 2020-07-01
(2) Gentoo Prefix Portage Snapshot Signing Key (Automated Signing Key)
2048 bit RSA key BA08091EC6317B3C, erzeugt: 2009-07-31, verfällt: 2020-07-25
(3) Gentoo Portage Snapshot Signing Key (Automated Signing Key)
1024 bit DSA key 0838C26E239C75C4, erzeugt: 2007-11-25, verfällt: 2012-05-23 (verfallen)
Keys 1-3 of 3 for "Gentoo Portage Snapshot Signing Key". Eingabe von Nummern, Nächste (N) oder Abbrechen (Q) > 1
gpg: /root/.gnupg/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel DB6B8C1F96D8BF6D: Öffentlicher Schlüssel "Gentoo Portage Snapshot Signing Key (Automated Signing Key)" importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg: importiert: 1
Ob das allerdings die Lösung ist, sei mal dahingestellt.
Gruß
Manfred
@ManfredB:
Also es scheint zu jetzt funktionieren? Aber erst nachdem du vorher ohne keyserver gpg suchen lässt.
Dieser Effekt wurde hier schon beschrieben:
Requesting HKPS service from non-HKPS gives "error searching keyserver: General error"
Die Lösung da:
Also es scheint zu jetzt funktionieren? Aber erst nachdem du vorher ohne keyserver gpg suchen lässt.
Dieser Effekt wurde hier schon beschrieben:
Requesting HKPS service from non-HKPS gives "error searching keyserver: General error"
Die Lösung da:
[...]
Try this with other VALID --keyserver combinations. Bang head against wall.
The ONLY command that seems to fix this persistent failure case:
$ gpg2 --search-keys 2071B08A33BD3F06
Suddenly, I can use --keyserver again, after this.
[...]
Fazit:
Das bezieht sich im Moment nur auf eine Gentoo amd64 Version.
(In einer der Gentoo-stable-Versionen hat es noch nicht funktioniert.)
Nach den vorgeschlagenen Schritten, die ich nacheinander durchgeführt habe,
musste ich in /etc/portage/repos.conf/gentoo.conf
die geänderten Zeilen wieder korrigieren.
Danach emerge --sync --quiet
längerer Prozess
und dann Ende ohne Fehlermeldung.
Damit sieht es für mich so aus:
Problem gelöst.
Ich danke allen, die sich hier um Lösungen bemüht haben und mir bei der Lösung helfen wollten,
ganz herzlich für die Geduld und die dringeneden Bemühungen.
Allen wünsche ich noch einen schönen Abend.
Gruß
Manfred
P.S. in den stable-Versionen habe ich mit den Wegen keinen Erfolg.
Der 2. Schriit endet immer mit dem Ergebnis
Worin der Unterschied zwischen stable und amd64 besteht, bleibt das Rätsel
Das bezieht sich im Moment nur auf eine Gentoo amd64 Version.
(In einer der Gentoo-stable-Versionen hat es noch nicht funktioniert.)
Nach den vorgeschlagenen Schritten, die ich nacheinander durchgeführt habe,
musste ich in /etc/portage/repos.conf/gentoo.conf
die geänderten Zeilen wieder korrigieren.
Danach emerge --sync --quiet
längerer Prozess
und dann Ende ohne Fehlermeldung.
Damit sieht es für mich so aus:
Problem gelöst.
Ich danke allen, die sich hier um Lösungen bemüht haben und mir bei der Lösung helfen wollten,
ganz herzlich für die Geduld und die dringeneden Bemühungen.
Allen wünsche ich noch einen schönen Abend.
Gruß
Manfred
P.S. in den stable-Versionen habe ich mit den Wegen keinen Erfolg.
Der 2. Schriit endet immer mit dem Ergebnis
Code: Select all
gpg --keyserver hkps://keys.gentoo.org --search-keys "Gentoo Portage Snapshot Signing Key"
gpg: error searching keyserver: Allgemeiner Fehler
gpg: Suche auf dem Schlüsselserver fehlgeschlagen: Allgemeiner Fehler
Hallo zusammen,
nun muss ich doch noch etwas mehr differenzieren:
1. In den Neuinstallationen mit ACCEPT_KEYWORDS="~amd64" in /etc/portage/make.conf
taucht das Problem auf und läßt sich mit den vorgeschlagenen 2 Schritten beheben.
In den Neuinstallationen Gentoo-stable kommt dieser Fehler auch und läßt sich nicht beheben.
Allerdings habe ich festgestellt, wenn ich einfach weiterhin emerge-webrsync durchführe
und anschließend emerge -avuDN world, kommen - sofern Updates da sind - diese zum Zuge.
Das ist sicher keine komplette Lösung, aber immerhin ein Weg, wie man das System am Laufen halten kann
durch Aktualisierung.
2. In bestehenden stable-Installationen, die weiterhin /usr/portage nutzen,
taucht in /etc/portage/repos.conf/gentoo.conf die Zeile mit hkps: nicht vor.
Allerdings meine ich hier die auf Profil 17.1 umgewandelten Installationen, andere habe ich nicht mehr.
Hier funktioniert emerge --sync --quiet ohne Probleme wie vor der Umstellung.
Diese Unterschiede sind schon auffallend.
Ich schließe daraus, daß in den amd64-Installationen die Entwicklung zur Normalität weiter ist
als in den stable-Installationen.
Was die Entwickler von gentoo da auf den Weg gebracht haben,
wird viele enttäuschen, denn der Grund für diese Fehlentwicklung ist bis jetzt nicht klar.
Aber immerhin die Schritte, wie man in der amd64-Version vorgehen muss, lösen das Problem.
Trotzdem wünsche ich allen immer noch Freude an gentoo, die mir auch noch längst nicht verlorengegangen ist.
Gruß
Manfred
nun muss ich doch noch etwas mehr differenzieren:
1. In den Neuinstallationen mit ACCEPT_KEYWORDS="~amd64" in /etc/portage/make.conf
taucht das Problem auf und läßt sich mit den vorgeschlagenen 2 Schritten beheben.
In den Neuinstallationen Gentoo-stable kommt dieser Fehler auch und läßt sich nicht beheben.
Allerdings habe ich festgestellt, wenn ich einfach weiterhin emerge-webrsync durchführe
und anschließend emerge -avuDN world, kommen - sofern Updates da sind - diese zum Zuge.
Das ist sicher keine komplette Lösung, aber immerhin ein Weg, wie man das System am Laufen halten kann
durch Aktualisierung.
2. In bestehenden stable-Installationen, die weiterhin /usr/portage nutzen,
taucht in /etc/portage/repos.conf/gentoo.conf die Zeile mit hkps: nicht vor.
Allerdings meine ich hier die auf Profil 17.1 umgewandelten Installationen, andere habe ich nicht mehr.
Hier funktioniert emerge --sync --quiet ohne Probleme wie vor der Umstellung.
Diese Unterschiede sind schon auffallend.
Ich schließe daraus, daß in den amd64-Installationen die Entwicklung zur Normalität weiter ist
als in den stable-Installationen.
Was die Entwickler von gentoo da auf den Weg gebracht haben,
wird viele enttäuschen, denn der Grund für diese Fehlentwicklung ist bis jetzt nicht klar.
Aber immerhin die Schritte, wie man in der amd64-Version vorgehen muss, lösen das Problem.
Trotzdem wünsche ich allen immer noch Freude an gentoo, die mir auch noch längst nicht verlorengegangen ist.
Gruß
Manfred
Last edited by ManfredB on Mon Aug 05, 2019 8:48 pm, edited 1 time in total.
In der aktuellen c't 17/2019, Seite 36 ist ein Artikel zu PGP. Sehr lesenswert.
Früher war ich mal begeisterter Fan von PGP - ich habe sogar Vorträge dazu gehalten. In den letzten Jahren hat meine Begeisterung immer mehr abgenommen. Und seit der Tree Verification Katastrophe in Gentoo ist sie endgültig beim Nullpunkt angelangt. Wobei ich fairerweise sagen muss, dass daran weniger PGP Schuld ist, als vielmehr die unzureichende Implementierung der Tree Verification in Gentoo.
Jedenfalls kann ich dem Artikel in der c't voll und ganz zustimmen. GnuPG ist mittlerweile so schlecht, dass es nur noch eine Lösung gibt: weg damit! Ich verwende es nicht mehr.
Früher war ich mal begeisterter Fan von PGP - ich habe sogar Vorträge dazu gehalten. In den letzten Jahren hat meine Begeisterung immer mehr abgenommen. Und seit der Tree Verification Katastrophe in Gentoo ist sie endgültig beim Nullpunkt angelangt. Wobei ich fairerweise sagen muss, dass daran weniger PGP Schuld ist, als vielmehr die unzureichende Implementierung der Tree Verification in Gentoo.
Jedenfalls kann ich dem Artikel in der c't voll und ganz zustimmen. GnuPG ist mittlerweile so schlecht, dass es nur noch eine Lösung gibt: weg damit! Ich verwende es nicht mehr.
Wieder eine neue Erfahrung.
Eben ist bei einer gentoo-stable-Installation folgendes vorgegangen.
Ich habe die neueste stage3 entpackt, die ersten Schritte im WIKI durchgeführt.
Nachdem ich /etc/portage/repos.conf/gentoo.conf herübergeholt hatte,
habe ich darin die Zeile mit hkps deaktiviert, außerdem
die Zeile sync-rsync-verify-metamanifest = yes in no umgewandelt.
Danach kam zuerst in der chroot-Umgebung:
emerge-webrsync
danach
emerge --sync --quiet
Und dieses letzte funktionierte, allerdings war der Prozess kürzer,
den die Holung des keys ist ausgeklammert.
Nun läuft das Update in der chroot-Umgebung: 218 Pakete Profil 17.1 plasma
Ob das nun so bleibt, wird sich zeigen.
Gruß
Manfred
Eben ist bei einer gentoo-stable-Installation folgendes vorgegangen.
Ich habe die neueste stage3 entpackt, die ersten Schritte im WIKI durchgeführt.
Nachdem ich /etc/portage/repos.conf/gentoo.conf herübergeholt hatte,
habe ich darin die Zeile mit hkps deaktiviert, außerdem
die Zeile sync-rsync-verify-metamanifest = yes in no umgewandelt.
Danach kam zuerst in der chroot-Umgebung:
emerge-webrsync
danach
emerge --sync --quiet
Und dieses letzte funktionierte, allerdings war der Prozess kürzer,
den die Holung des keys ist ausgeklammert.
Nun läuft das Update in der chroot-Umgebung: 218 Pakete Profil 17.1 plasma
Ob das nun so bleibt, wird sich zeigen.
Gruß
Manfred
Das ganze war vermutlich ein nicht mehr kompatibles gnutls binary im stage3 tarball,
siehe dazu auch im [bug=690760]Bug 690760[/bug]
Ein rebuild hätte wahrscheinlich geholfen.
siehe dazu auch im [bug=690760]Bug 690760[/bug]
Ein
Code: Select all
emerge -av1 gnutls