Beiträge von knorke

  • Lange Pause vor dem Grub-Menü nach Passworteingabe

    Hallo Alero,

    wenn systemd startet, ist das Problem ja schon vorbei. Die Pause ist *vor* dem grub-Menü. Mittlerweile wurde mir empfohlen, die Iterations der Key Derivation Function (KDF) zu reduzieren. Vielleicht nehme ich auch einen anderen Algorithmus.


    Den gewünschten Output habe ich trotzdem angehangen, falls die KDF nicht die Ursache ist. Denn wenn ich ein verschlüsseltes FS aus dem laufenden System heraus mit "luksOpen" öffne, dann dauert die Operation nur 4,8s…


    UPDATE: um cross-posts zu vermeiden; im IRC wurde mir noch mitgeteilt, dass grub-decryption auch deshalb langsam ist, weil die crypto-relevanten CPU-Befehle ggf. nicht benutzt werden. Also *falls* KDF die Ursache ist, wäre mein Problem quasi gelöst. Dann spiele ich mal mit Iteration Count und anderen Algos rum…

  • Lange Pause vor dem Grub-Menü nach Passworteingabe

    Hallo,

    ich habe auf zwei Systemen Tumbleweed laufen. Über den Installer habe ich das root-FS verschlüsselt (Btrfs, LUKS). Beim Booten kommt wie erwartet das Passwortprompt von Grub zum Entschlüsseln vom Dateisystem. Nach korrekter Eingabe dauert es aber 20s (auf dem zweiten System noch länger), bis ich in das Grub-Menü komme. Kann ich diese Pause zwischen Eingabe und Bootmenü abkürzen oder loswerden? Was passiert in der Zeit? Ein FSCK sollte ja erst beim Hochfahren (also *nach* dem Grub-Menü) passieren.


    Danke im Voraus!

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

    Ich habe ein Dockerfile mit folgendem Inhalt:


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


    Wenn ich das Image baue und starte (ich nutze docker-compose), kann ich wie gewohnt zypper benutzen, um Pakete zu verwalten.


    Wenn ich dieses Image jedoch liegen lasse (eine Woche), dann kann ich mit exakt diesem image zypper nicht mehr gescheit benutzen, denn es wird ein Fehler gemeldet. Manchmal (nicht immer!) behebt ein RETRY das Problem, d.h. im zweiten Versuch lässt sich das Paket installieren. Da ich jedoch automagisch (nicht-interaktiv) zypper ausführen muss, ist RETRY keine Option.




    Eine längliche Problembeschreibung, die zum obigen Minimalbeispiel führt, findet sich >hier im Forum<.


    Es wäre großartig, wenn jemand mal das Dockerfile von oben testen könnte, d.h. Image bauen, irgendein Paket installieren (sollte gehen), den Container dann beenden und eine Woche liegen lassen. Dann versuchen, das gleiche Paket zu installieren (mit oder ohne REFRESH vorher, spielt keine Rolle).


    Docker version 17.03.1-ce, build c6d412e


    Danke!

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

    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?

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

    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

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

    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: