Tumbleweed: Probleme bei Install/Update "Media source '…' does not contain the desired medium", Docker+Kubernetes+AWS

Hinweis: In dem Thema Tumbleweed: Probleme bei Install/Update "Media source '…' does not contain the desired medium", Docker+Kubernetes+AWS gibt es 8 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Ich habe Probleme, Pakete zu installieren oder upzudaten. Die Fehlermeldung ist


    Media source 'http://download.opensuse.org/tumbleweed/repo/oss/' does not contain the desired medium


    Ausgangslage:


    Ich nutze OpenUSSE Tumbleweed in einem Dockercontainer (in einem Kubernetes-Cluster) auf Amazon AWS.


    Das Ausgangsimage ist "FROM opensuse:tumbleweed" von DockerHub, hier. ich versuche darauf aufbauend weitere Images zu bauen und dafür installiere ich über Dockerfile Pakete, im Grunde nicht anders als bei einer Desktopinstallation. Das klappt mitunter problemlos. Dann wieder nicht. Tritt der Fehler mal auf, bleibt er hartnäckig über Tage bestehen. Ich kann dann idR keine Pakete mehr installieren.


    Da ich schon Instanzen von Tumbleweed laufen habe, kann ich das Problem auch interaktiv reproduzieren und entsprechend debuggen. Leider weiß ich nicht, wo ich suchen muss.


    Code
    bash-4.4# zypper lr -d
    Repository priorities are without effect. All enabled repositories share the same priority.
    # | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service
    --+-------------+-------------+---------+-----------+---------+----------+--------+-------------------------------------------------------+--------
    1 | non-oss | NON-OSS | Yes | (r ) Yes | Yes | 99 | yast2 | http://download.opensuse.org/tumbleweed/repo/non-oss/ |
    2 | oss | OSS | Yes | (r ) Yes | Yes | 99 | yast2 | http://download.opensuse.org/tumbleweed/repo/oss/ |
    3 | repo-update | repo-update | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/tumbleweed/ |


    Patchstand System

    Code
    bash-4.4# zypper up
    Retrieving repository 'OSS' metadata .....................................[done]
    Loading repository data...
    Reading installed packages...
    Nothing to do.

    Triggern des Problems


    Das Logfile im Anhang ist /var/log/zypper.log vom Fehlschlag.


    Der Gag ist nun, dass wenn ich RETRY probiere, das Paket problemlos installiert wird!


    Leider ist ABORT die default-Auswahl im nicht-interkativen Modus. Aber selbst wenn RETRY default wäre, wäre das nur ein Workaround.


    Frage: Wo muss ich nach dem Fehler suchen? Welche Informationen kann ich noch bereitstellen, was kann ich noch prüfen?


    Danke im Voraus!


    Nachtrag: Meine Zypper-Configs sind alle Default:



    Dateien

    • zypper.log.txt

      (179,23 kB, 10 Mal heruntergeladen, zuletzt: )

    Einmal editiert, zuletzt von knorke () aus folgendem Grund: Nachtrag: zypper-config

    Für den Inhalt des Beitrages 106732 haftet ausdrücklich der jeweilige Autor: knorke

  • ... Leider weiß ich nicht, wo ich suchen muss. ...

    Im Dockerfile?


    Es ist ja löblich, dass du dich so bemüht hast, alle wichtigen Angaben gleich zu liefern,
    aber das Dockerfile wäre an erster Stelle wichtig gewesen.

    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 106739 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Sorry, ich war nicht explizit genug.


    Ja, das Ziel der Übung ist ein Image und das wird über ein Dockerfile erstellt.
    Das Problem tritt aber auch laufenden Containern auf, also in interaktiven Shells (Stichwort: docker exec bzw. hier kubectl exec).


    Ich habe eben versucht, ein Minimalbeispiel von Dockerfile zu erstellen, welches das Problem reproduziert. Das ist mir nicht gelungen. Allerdings habe ich eben gemerkt, dass auch das im OP beschriebene Problem aktuell nicht auftritt. Das heißt ich konnte das Image wie beabsichtigt und ohne irgendeine Änderung erstellen. Das schlug nicht nur heute mehrere Male fehl, sondern auch gestern und auch vor einigen Wochen…
    Der Gag dabei: Das Image was ich hier erstellt habe (noch nicht gestartet!), läuft ja noch, und habe ich für die CodeSnippets im OP benutzt. Das Dockerfile läuft durch und das Image (was noch läuft) kann interaktiv kein zypper install vim ausführen.


    Es ist also sehr sehr unwahrscheinlich, dass das Dockerfile das Problem ist:

    • wenn ich im zypper RETRY tipper, geht UPDATE oder INSTALL ja problemfrei durch. Lediglich der erste Anlauf scheitert. Damit ist --non-interactive für mich halt nicht benutzbar.
    • das Problem besteht nicht ständig, jetzt gerade (20:22 Uhr CET) beispielsweise nicht; aber dafür von gestern Mittag irgendwann bis halt heute Nachmittag irgendwann, zumindest auf dem Host der das Image baut
    • das Problem besteht seit heute Mittag etwa auf der Node, wo das Image (an dem ich rumschraube) aktuell läuft. Der Container läuft dort schon länger.
    • DNS-Issues war meine erste Vermutung. Aber scheidet aus, weil der Download von dem File funktioniert ja im RETRY zuverlässig
    • Throttling wäre noch eine Möglichkeit, also Begrenzung der Zugriffe auf Mirror oder sonstwo hin. Würde die Zeitkomponente erklären (mal gehts, mal nicht), aber warum geht dann RETRY?
    • Das Log verrät (IMHO) in keinster Weise, warum dem repo nach Meinung von zypper ein File fehlt, siehe die IMO relevanten Zeile
    Code
    2017-03-31 09:25:51 <1> jupyter-wvdgn(1956) [zypp++] MediaCurl.cc(doGetFileCopyFile):1494 URL: http://download.opensuse.org/tumbleweed/repo/oss/media.1/media
    2017-03-31 09:25:51 <1> jupyter-wvdgn(1956) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1361 HTTP response: 200
    2017-03-31 09:25:51 <1> jupyter-wvdgn(1956) [zypp++] MediaMultiCurl.cc(looks_like_metalink):1234 looks_like_metalink(/var/tmp/AP_0xIDMJXr/media.1/media.new.zypp.AAPPdV): 0
    2017-03-31 09:25:51 <1> jupyter-wvdgn(1956) [zypp] PathInfo.cc(rename):673 rename /var/tmp/AP_0xIDMJXr/media.1/media.new.zypp.AAPPdV -> /var/tmp/AP_0xIDMJXr/media.1/media
    2017-03-31 09:25:51 <1> jupyter-wvdgn(1956) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1477 done: /var/tmp/AP_0xIDMJXr/media.1/media{- 0644 0/0 size 26}
    2017-03-31 09:25:51 <1> jupyter-wvdgn(1956) [zypp++] MediaHandler.cc(provideFile):1000 provideFile(/media.1/media)
    2017-03-31 09:25:51 <1> jupyter-wvdgn(1956) [zypp++] MediaManager.cc(checkDesired):102 checkDesired(3): not desired (report by N4zypp4repo17SUSEMediaVerifierE)
    2017-03-31 09:25:51 <5> jupyter-wvdgn(1956) [zypp] Exception.cc(log):137 MediaManager.cc(checkDesired):106 THROW: Media source 'http://download.opensuse.org/tumbleweed/repo/oss/' does not contain the desired medium


    Für mich sieht das alles nach maximalem Fsckup im Zusammenspiel von AWS, Kubernetes+Docker und Zypper aus.


    Das Problem ist nun, dass ich die Tempfiles, die Zypper anlegt, nicht checken kann. Denn zwischen Download von "media.1/media" und dem löschen von dem File liegt zu wenig Zeit, um die Tempfiles analysieren zu können. Ich werde trotzdem versuchen, an die Tempfiles zu kommen (mal, sehen, irgendwas mit inotify hacken oder so). Mal gucken, ob der Content, der runtergeladen wird, korrekt ist. Das würde dann aber nicht erklären, warum RETRY funktioniert.


    Oder ich muss mich wirklich tief in den Code von den Zypperlibs begeben, um zu verstehen, was an der oben gepasteten Stelle im Detail passiert. :(


    Weitere Hilfe ist nach wie vor erwünscht und wird dankbar angenommen. :D

    Einmal editiert, zuletzt von knorke () aus folgendem Grund: weitere ideen

    Für den Inhalt des Beitrages 106746 haftet ausdrücklich der jeweilige Autor: knorke

  • Naaa, Kommando zurück. Image bauen geht nach wie vor nicht. Hatte mich vertan.


    Ich liefere so schnell es geht ein Minimalbeispiel.

    Für den Inhalt des Beitrages 106747 haftet ausdrücklich der jeweilige Autor: knorke

  • Im Dockerfile?
    Es ist ja löblich, dass du dich so bemüht hast, alle wichtigen Angaben gleich zu liefern,
    aber das Dockerfile wäre an erster Stelle wichtig gewesen.

    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 106748 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • So, ich habe nun ein Minimalbeispiel und ich kann ausschließen, dass Amazon (AWS) in irgendeiner Form beteiligt ist, denn ich kann das Problem lokal reproduzieren.



    Über dieses Dockerfile habe ich vor einer Woche (über docker-compose) ein Image gebaut.
    Der Vollständigkeit halber das compose-Fragment, was wiederum auch nur auf ein Verzeichnis zeigt, in welchem nur das Dockerfile von oben liegt.

    Code
    zyppertest:
    build: ../zyppertest
    network_mode: "host"


    Vermutlich wichtig: zwischen Erstellung des Images und Reproduzieren des Problems lagen 7 Tage. Ich kann das Problem nicht reproduzieren, wenn der das Alter zwischen base image und local image nicht stark (mehrere Tage?) abweicht.


    Container starten: docker-compose up zyppertest
    Shell holen: docker-compose exec zyppertest bash


    Es gibt ne Fehlermeldung, weil die locales nicht generiert wurden ($LANG). Vermutlich hängt das nicht mit dem Problem zusammen.


    Reproduzieren vom Fehler im Container

    docker_history_output.txt die Ausgabe von docker history --no-trunc compose_zyppertest
    docker inspect ausgabe vom laufenden Container im inspect_result.json.txt


    Also habe ich ein neues Image gebaut, basierend auf einer Frischen Version vom Tumbleweed base image.
    Befehl: docker-compose build --force-rm --no-cache --pull zyppertest
    Log: zyppertest_new_build.log.txt


    Die (docker) History-Ausgabe ist abgesehen von den Änderungen auf Remoteseite (base image) quasi identisch.

    Problem ist GONE.


    Hilft das weiter?

    Für den Inhalt des Beitrages 107032 haftet ausdrücklich der jeweilige Autor: knorke

  • Streiche mal schlicht die Anweisung ENV C.UTF-8.....

    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 107035 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Okay, habe ich gemacht. Rest vom Dockerfile ist gleich. Ich melde mich in ein paar Tagen mit dem Ergebnis.

    Für den Inhalt des Beitrages 107037 haftet ausdrücklich der jeweilige Autor: knorke

  • Ich habe zusätzlich zur obigen Änderung noch ein zweites Image erstellt, in dem überhaupt nur das base image mit meta/label und nem sleep-command ist.

    Code
    FROM opensuse:tumbleweed
    ARG GIT_COMMIT=unknown
    LABEL git-commit=$GIT_COMMIT
    CMD ["sleep", "600"]

    Ich werde berichten.


    Danke schon mal für die Hilfe.

    Für den Inhalt des Beitrages 107038 haftet ausdrücklich der jeweilige Autor: knorke