Titel: [Status: gelöst] update fehlgeschlagen, community mirror 404
Beitrag von: Dietrich am 04. März 2025, 19:40:27
Seit 2 Tagen läuft mein update nicht durch, wird abgebrochen, siehe unten
Erste Abhilfe meinerseits
I edited /etc/pacman.conf and commented out
# [community]
# Include = /etc/pacman.d/mirrorlist
so das update ist für den Rest durchgelaufen. Werde in ein paar Tagen mal schauen ob community wieder erreichbar ist.
[sudo] Passwort für dietrich:
:: Paketdatenbanken werden synchronisiert …
endeavouros ist aktuell
core ist aktuell
extra ist aktuell
community.db konnte nicht heruntergeladen werden
multilib ist aktuell
Fehler: Konnte Datei 'community.db' nicht von de.arch.niranjan.co übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von berlin.mirror.pkgbuild.com übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von archlinux.thaller.ws übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirror.kumi.systems übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von arch.phinau.de übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirror.moson.org übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirror.lcarilla.de übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirror.pseudoform.org übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von packages.oth-regensburg.de übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von pkg.fef.moe übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirror.hugo-betrugo.de übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von arch.jensgutermuth.de übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirrors.niyawe.de übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirror.sunred.org übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von arch.kurdy.org übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirror.selfnet.de übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirrors.xtom.de übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirrors.n-ix.net übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von mirror.fra10.de.leaseweb.net übertragen : The requested URL returned error: 404
Fehler: Konnte Datei 'community.db' nicht von archlinux.richard-neumann.de übertragen : The requested URL returned error: 404
Fehler: Keine Datenbank konnte synchronisiert werden (Konnte manche Dateien nicht übertragen)
|
Titel: Re:update fehlgeschlagen, community mirror 404
Beitrag von: Andreas am 05. März 2025, 08:33:05
Hier die Erklärung dazu (die KI-Antwort ganz oben erklärt es sehr gut). Hättest Du die pacman.conf.pacnew verfolgt wäre Dir das nicht passiert ::) Ich meine das war igendwann um den 20. Februar rum wo das in der pacnew zu finden war...
https://search.brave.com/search?q=community+repository+archlinux&source=desktop&summary=1
LG
Andreas |
Titel: Re:update fehlgeschlagen, community mirror 404
Beitrag von: Sebastian am 05. März 2025, 12:56:20
Oder wenn man die Arch News verfolgt hätte, wüsste man auch darüber Bescheid.
In den News Cleaning up old repositories (https://archlinux.org/news/cleaning-up-old-repositories/) vom 17.02.25 (aktuell sogar noch die neuste News) wurde von Arch auch noch einmal daran erinnert, dass das Community Repo vor 2 Jahren durch extra ersetzt wurde und am 01.03.25 komplett entfernt wird. Und solch ein Fehler zu erwarten ist, wenn man es drin stehen lässt in seiner pacman.conf.
Ansonsten ist es auch sehr schlechte Praxis ein Haupt Arch Repo nur zu Testzwecken abzuschalten. Um zu schauen, ob es in ein paar Tagen später wieder funktioniert. Denn jedes Update, was man in der Zwischenzeit gemacht hätte, hätte pacman höchstwahrscheinlich den Benutzer mit zich Hinweisen gewarnt, das viele Abhängigkeiten nicht aufgelöst werden können. Da ja ein komplettes Repo fehlt, worauf viele Arch Pakete darauf aufbauen.
Wenn dann noch die schlechte Angewohnheit dazu kommt, mit --ignore zu arbeiten, ohne zu wissen, was man da macht (nur damit das Update durchläuft) wäre man da in Teufels Küche gekommen.
Hier die News, wo es damals am 15.05.23 bekannt geben wurde. Git migration announcement (https://archlinux.org/news/git-migration-announcement/)
Ansonsten, wenn du ein EndevourOS System hast. Kannst du hin und wieder auch einfach mal das Skript eos-pacdiff starten. Dies sucht auf deinem System nach .pacnew Dateien und fragt dich dann, was du damit machen möchtest. Eine Option ist es z.B. sich die Änderungen mit meld zwischen der .pacnew und der Originaldatei anzeigen zu lassen. So kann man ziemlich schnell aktuelle Änderungen sehen/hinzufügen/anpassen. Und falls eine Option/Konfiguration neu dazu gekommen ist, die man nicht versteht. Kann man in dem Moment recherchieren, warum diese Anpassung gemacht wurde. Bevor man sie übernimmt.
So kann man ziemlich einfach sein System bequem pflegen und lernt stetig dazu.
LG
Sebastian |
Titel: Re:update fehlgeschlagen, community mirror 404
Beitrag von: Andreas am 05. März 2025, 13:40:20
Ja, ich sehe hier auch, dass viel nach "Gewohnheiten" und "Automatismen" vorgegangen wird als mit "ich-will-verstehen-was-da-los-ist". Aber Dietrich hat ja bereits einmal gesehen, dass dadurch ab und an so gewaltige Probleme entstehen können dass es vielleicht doch besser wäre, die Zeit für solche Reparaturen in Lernvorgänge gesteckt wird. Lernvorgänge in die Zusammenhänge, in die Kommunikation des Arch-Projektes mit seinen Nutzern. Dadurch bekommt man ein Feeling. Das ist unabdingbar, wenn man eben doch mal ein --ignore= verwenden will: man muss sich sicher sein, dass das an dieser Stelle ok ist. Und dass die News von Arch in Englisch sind: das darf 2025 niemanden mehr abschrecken.
LG
Andreas |
Titel: Wartungs Gewohnheiten
Beitrag von: Sebastian am 05. März 2025, 18:19:56
Lernvorgänge in die Zusammenhänge, in die Kommunikation des Arch-Projektes mit seinen Nutzern. Dadurch bekommt man ein Feeling.
|
|
Besser hätte ich es nicht sagen können. Und tatsächlich, wenn ich meine Vorgehensweise für mich reflektiere, dann komme ich auch zu dem Schluss das ich nach Gewohnheiten/Automatismen handel. Nur sehen meine Gewohnheiten so aus, dass ich zum schluss in dieses Feeling komme.
Als Erstes klappere, wenn mir etwas komisch vorkommt, ich erst mal die üblichen News Seiten ab, ob da schon was bekannt gegeben wurde.
https://archlinux.org/ (Weil meine Distro darauf basiert)
https://forum.endeavouros.com/c/important-notifications/125 (Weil meine Distro EndeavorOS ist)
Wenn ich schon länger kein Update mehr gemacht habe, dann halte ich mich sogar noch hieran Read before upgrading the system (https://wiki.archlinux.org/title/System_maintenance#Read_before_upgrading_the_system)
Die nächste Gewohnheit die ich habe, ist die Ausgabe des Updatevorgangs zu verfolgen oder zumindest grob im pacman log noch mal nachzulesen. Aufgrund der Empfehlung die hier im Arch Wiki gemacht wird. Act on alerts during an upgrade (https://wiki.archlinux.org/title/System_maintenance#Act_on_alerts_during_an_upgrade)
Und hin und wieder benutzte ich das eos-pacdiff Skript um zu kontrollieren, dass ich keine unbearbeiteten .pacnew Dateien auf meinem System habe. Aber spätestens dann, wenn ich eine .pacnew Datei in der Ausgabe des Updatevorgangs sehe. Aufgrund Lage dieser Empfehlung Deal promptly with new configuration files (https://wiki.archlinux.org/title/System_maintenance#Deal_promptly_with_new_configuration_files). Meistens (zumindest bei meinen Paketen) werden häufig nur Kommentare in Konfigurationen angepasst. Aber falls doch eine neue Einstellung hinzukommt, die sich mir nicht erschließt, dann forsche ich in den Release Notes der jeweiligen Software, nach, was sich da getan hat (meistens erschließt es sich dann schon, warum es die neue Konfiguration gibt und was die macht). Ansonsten geht es weiter mit Recherchen in Arch Wiki und zum Schluss die gute alte Internetsuche mit Brave.
Damit bin ich bisher immer ganz gut gefahren. Und wie du schon sagtest, dadurch kommt man irgendwie in so einen Flow, und fühlt sich verbunden mit der Community, da man Teil von vom großen ganzen Ökosystem rund um Linux wird.
LG
Sebastian
|
Titel: Re:update fehlgeschlagen, community mirror 404
Beitrag von: Dietrich am 05. März 2025, 20:35:23
Hallo Andreas / Sebastian,
Ok...wenn ich mir Eure Kommentare zu meinem handeln/ nicht handeln durchlese, sollte man meinen es ist besser zu warten,bis andere vielleicht anfragen.
Weit gefehlt liebe Leser, last Euch nicht davon abschrecken es zu tun!!!
1. Ich werde mich vor einem update besser informieren müssen
2. Wenn denn schon auf Änderungen in der Zukunft, hier mit einer "Handlungsempfehlung" darauf hingewiesen wird, es nicht auf später
verschieben um es dann zu vergessen, sowie hier geschehen. Dann ist der eine oder andere Kommentar schon gerechtfertigt.
Danke Sebastian für Deinen "Waschzettel" zur Vorbereitung des Updates.
Ja die Geschichte mit den alten Gewohnheiten ist zu überdenken. |
Titel: Re:update fehlgeschlagen, community mirror 404
Beitrag von: Andreas am 06. März 2025, 08:32:08
Danke für deinen Kommentar, Dietrich! Es ist ja nicht so, dass ich das nicht auch an mir selbst kenne - ich habe früher in vielen Belangen genau die gleichen Bequemlichkeiten gehabt. Heute bin ich da total anders... Wenn ich schon in so eine Falle getappt bin (wie Repo nicht erreichbar) dann bemühe ich zunächst eine Suchmaschine. Hätte in diesem Fall sofort die richtige Zündschnur gelegt. Und je öfter man ein Problem selbst gelöst hat (also ohne aktive Hilfe von anderen) - desto größer wird auch das Selbstbewusstsein und der Biss, es immer zu versuchen. Deswegen ist es auch wichtig, darauf hingewiesen zu werden, dass das ein Problem "mit Ansage" war. Das ist ja nicht aggressiv oder ablehnend gemeint - ganz im Gegenteil. Es ist konstruktive Kritik. Für mich hat die Wichtigkeit von "konstruktiver Kritik" einen sehr hohen Stellenwert im eigenen Lernprozess: ich nehme sie stets an, freue mich über sie und bin den Gebern dankbar. Leider ist auch diese Fähigkeit bei weiten Teilen der Bevölkerung völlig verkümmert und wird oft als Angriff oder "Niedermachen" empfunden. Das liegt vermutlich an der Tatsache, dass unsere Profit-, Erfolgs- und Konsumgesellschaft dieses Instrument nicht kennt. Und was man nicht kennt lehnt man ab...
In so fern danke für deine Anfrage - sie hat definitiv für Dich und hoffentlich auch für andere einen Sinn gehabt!
LG
Andreas |
Titel: Re:update fehlgeschlagen, community mirror 404
Beitrag von: Dietrich am 06. März 2025, 11:54:49
Hallo Andreas,
ich verstehe die Kritik genauso wie von Dir geschrieben, als Ansporn besser zu werden.
Es bringt uns, den nicht Wissenden, nichts wenn wir nur warten bis jemand etwas für uns löst. Das da ggf. mal eine Kommentar kommt gehört dazu und sollte ernst genommen werden, aber nicht persönlich.
LG
Dietrich |
Titel: Re:update fehlgeschlagen, community mirror 404
Beitrag von: Sebastian am 06. März 2025, 14:17:28
Tatsächlich habe ich mir auch schon gedacht, wenn jemand das liest, dass es auch schnell als Angriff und nicht als konstruktive Kritik gesehen werden kann.
Ich möchte auf jedenfall niemand angreifen oder vor den Kopf stoßen sondern nur die Vorgänge im Detail ein wenig beleuchten. Damit (hoffentlich auch andere) sehen können, welche alternativen Vorgehensweisen zu bevorzugen wären, da man ansonsten sich selbst seine Probleme mit seinem System schafft.
Es ist halt wie bei jedem Werkzeug, Werkzeuge möchten gepflegt werden wenn man lange an ihnen Spass haben möchte. Das eine mehr und das andere weniger. Und auch da gibt es untereschiedliche Arten der Pflege:
- Ich Pflege überhaupt nicht, und Nutze es so lange bis kaputt, dann kommt was Neues (Hallo Wegwerfgesellschaft)
- Ich Pflege semi, und nimm im Kauf das öfter was kaputtgehen kann. Und schaue dann, wie man es wieder repariert bekommt. Oder der schlimmere Fall wäre ich suche jemanden, der mir es nach Möglichkeit kostenlos Repariert
- Ich gebe mir Mühe bei der Pflege, und erkundige mich, wie man sein Werkzeug Pro aktiv in Ordnung halten kann. Man liest sich ein, was kann das Werkzeug (System) was brauch das System was sind best practice um es zu warten etc.
Ein auf Arch Linux basiertes System, ist für den letzten Typ Mensch gemacht. Deswegen ist das Arch Wiki auch so umfangreich und die Community informiert Regelmäßig. Was die Community aber nicht macht, ist es den Leuten das Wissen hinterherzutragen. Die Community hat ja schon sehr viel Zeit und mühe in die Dokumentation gesteckt und informiert. Da kann man nicht noch erwarten, das jetzt noch jemand zum Vorlesen kommt, und immer wieder sagt, lese das, sonst fällst du auf die Nase. Klar wird das auch gemacht, genau das machen wir hier ja auch. Aber eigentlich sollte es so sein das man dies nicht tun muss und jeder selbst sich seine Lektüre besorgt. Und wenn dann es noch zu irgendwas fragen gibt (weil man vielleicht eine gewisse Lektüre nicht ganz versteht) dann sollte man fragen und darüber diskutieren. Dann bekommt man Hilfe und Dokumentartionen können weiter verbessert und überarbeitet werden.
Aus diesen Grund bin ich auch froh Dietrich, das du dich hier Trotzdem gemeldet hast. Und das auch genau richtig aufgefasst hast. Und ich denke, du bist mit den Tipps wahrscheinlich wieder ein Stück weiter gekommen.
Mal so eine Frage, sagte dir das Skript eos-packdiff vorher schon etwas?
Als Bonus lege ich hier mal ein Lern Geschenk drauf wie man an eine Originalkonfigurationsdatei herankommt, falls man seine ,pacnew Datei schon aus Versehen gelöscht hat und man doch noch mal nachschauen möchte wie die Originaldatei aussieht:
Code:
paccat <Paket Name> <Konfiguartionsdatei>
|
|
Ausgebenen wird die Datei dann auf den stdout.
Gummipunkte gibt es wer mir sagen kann, wie man an den Paketnamen herausfinden kann von der Datei, die man haben möchte? Und wie man die Ausgabe (stdout) in eine Datei umleitet. ;)
LG
Sebastian
|
Titel: Re:[Status: gelöst] update fehlgeschlagen, community mirror 404
Beitrag von: Dietrich am 06. März 2025, 22:00:57
Hallo Sebastian,
ich arbeite jetzt die Infos ab.
Ja eos-packdiff sagt mir jetzt schon etwas, es scheint aber ratsam zu sein, zu schauen was in den pacnew Dateien steht.
stumpf anschauen und O drücken kann nicht die reine Wahrheit sein.
Bin dran....
LG
Dietrich |
Titel: Re:[Status: gelöst] update fehlgeschlagen, community mirror 404
Beitrag von: Sebastian am 07. März 2025, 16:58:25
Hallo Sebastian,
ich arbeite jetzt die Infos ab.
Ja eos-packdiff sagt mir jetzt schon etwas, es scheint aber ratsam zu sein, zu schauen was in den pacnew Dateien steht.
stumpf anschauen und O drücken kann nicht die reine Wahrheit sein.
Bin dran....
LG
Dietrich
|
|
Das ist korrekt, einfach stumpf alle Konfigurationsdateien mit ihrer .pacnew Version mit Overrite zu überschreiben, wäre nicht sinnvoll. Da eine .pacnew Datei ja auch nur entsteht, wenn pacman feststellt, dass diese vom Original abweicht, weil man selbst oder vielleicht der Distributor Veränderungen an dieser Datei vorgenommen hat. Quasi immer dann wenn sie nicht mehr dem Orginal wie sie im Paket ausgeliefert wird entspricht und pacman die Änderungen nicht selbst herein Schreiben kann (woher soll es wissen was gebraucht wird?) .Und man möchte üblicherweise ja seine eigenen Einstellungen in der Datei nicht zurücksetzen.
Deswegen ist es eher ratsam sich mit View sich die Änderungen der alten und der neuen Version als Gegenüberstellung (diff) anzeigen zu lassen und dann selbst die neuen Änderungen hinzufügen. Auf diese Weise bekommt man auch ein besseres gefühl/Verständnis, warum sich das System auf einmal anderes verhalten kann. Da man so besser mit bekommt das sich etwas Grundsätzliches in einem Programm verändert hat. Und man dann viel schneller darauf kommt die Fehlerquelle zu finden.
Trotzdem gibt es natürlich auch für die Override Funktion seine dar seins Berechtigung. So z.b. bekomme ich durch ein Update des Paketes endeavouros-mirrorlist eine neue Version der Datei:
/etc/pacman.d/endeavouros-mirrorlist
auf mein System gespielt. Die auch sogleich von dem Pacman Hook eos-rankmirrors.hook nach dem Update sofort umsortiert wird. Und dann auch als eine endeavouros-mirrorlist.pacnew Datei abgelegt wird. Da ich nun also weis das diese Konfigurationsdatei eh immer nach solch einen Update neu generiert wird. Kann ich diese Version der Datei ungeprüft mit Override von der .pacnew datei überschreiben lassen.
Wie man hierbei gut erkennen kann, gilt auch hier, wenn die Abläufe verstanden wurden, erst dann ist man in der lange bei Fragen solcher Tools auch eine informierte Antwort zu geben.
Und wie die diese Zahnräder ineinander greifen, das habe ich durch das verfolgen und lesen des Updatevorgangs vor langer Zeit schon herausbekommen. Da dies auch da in der Ausgabe drin steht.
LG
Sebastian |
Titel: Re:[Status: gelöst] update fehlgeschlagen, community mirror 404
Beitrag von: Dietrich am 07. März 2025, 17:07:02
Hallo Sebastian,
bin weiter dran, will den Gummipunkt haben, habe die Frage nicht vergessen
erster Test mit bekannter Datei, OHNE suche,
[dietrich@dietrich-medion ~]$ paccat pacman -- pacman.conf > testlog1
das klappt wird im Home Verzeichnis ausgegeben..
die Suche schiebe ich dann nach
|
Titel: Re:[Status: gelöst] update fehlgeschlagen, community mirror 404
Beitrag von: Sebastian am 08. März 2025, 08:13:10
Hallo Sebastian,
bin weiter dran, will den Gummipunkt haben, habe die Frage nicht vergessen
erster Test mit bekannter Datei, OHNE suche,
[dietrich@dietrich-medion ~]$ paccat pacman -- pacman.conf > testlog1
das klappt wird im Home Verzeichnis ausgegeben..
die Suche schiebe ich dann nach
|
|
Supi, Tipp:
Frag mal dein Paketmanager in welchem Paket sich die Datei /usr/bin/eos-update drin befindet, wenn du ein EndeavorOS System hast. Dein Paketmanager hat die Datei ja installiert, also muss er auch wissen aus welchem Paket diese stammt. Wenn du das weißt hast du auch keine Probleme für paccat immer den richtigen Paketnamen anzugeben, falls du mal eine Originaldatei aus einem Paket herausholen möchtest.
LG
Sebastian |
Titel: Re:[Status: gelöst] update fehlgeschlagen, community mirror 404
Beitrag von: Dietrich am 14. März 2025, 13:51:23
Hallo Sebastian,
nicht vergessen, hoffe jetzt gibt es noch den Gummibär oder nen Rüffel ;D ;D
[dietrich@dietrich-medion bin]$ pacman -Qo eos-update
/usr/bin/eos-update ist in eos-bash-shared 25.3.2-1 enthalten
[dietrich@dietrich-medion bin]$
|
Titel: Re:[Status: gelöst] update fehlgeschlagen, community mirror 404
Beitrag von: Sebastian am 14. März 2025, 15:48:25
Hallo Sebastian,
nicht vergessen, hoffe jetzt gibt es noch den Gummibär oder nen Rüffel ;D ;D
[dietrich@dietrich-medion bin]$ pacman -Qo eos-update
/usr/bin/eos-update ist in eos-bash-shared 25.3.2-1 enthalten
[dietrich@dietrich-medion bin]$
|
|
Das gibt nen super Gummibären ;D
Da habe ich jetzt sogar noch etwas dazu gelernt. Ich wusste nicht das pacman -Qo auch in der $PATH Variable nach einer Datei sucht. Ich dachte bisher es muss immer der Vollständige Pfad zur einer Datei angeben werden.
Also behalte das im Hinterkopf, falls du mal wissen möchtest zu welchem Paket eine Datei gehört und diese nicht zufällig ein Programm ist, das in deiner $PATH Variable drin vorkommt. Das du auch einen vollständigen Pfad angeben kannst.
Mit diesem Hintergrund wissen, weist du jetzt:
A: zu welchem Paket gehört Datei X und
B: mit dieser Information kannst du paccat richtig bedienen, um dir schnell eine Originaldatei aus einem Paket zu holen, falls du diese zu Referenzzwecken noch einmal benötigst.
Zudem ist mit Sicherheit jetzt das Verständnis größer geworden, was passiert, wenn man Programme mit einer anderen Methode installiert, ohne pacman zu benutzen. Denn dann kann pacman diese Fragen wozu gehört die Datei nicht beantworten. Und weiß nicht, was Konflikte verursachen kann etc. deswegen ist es wichtig nach Möglichkeit Programme immer mit seinem Paketmanager zu installieren. Und falls nicht dann muss man wissen was man da macht. ;)
Und --ignore bedeutet einfach so viel ignoriere einfach das ich das Paket X installiert habe und tuhe so als ob die Dateien die zu diesem Paket gehören nicht auf meinen System existieren. Sprich er prüft dann auch nicht ob das zu Konfliekten führen kann. :)
Ich gehe davon aus das dich das jetzt schon sehr viel weiter von verständins bringt :)
LG
Sebastian |
Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|