Schau ich mir morgen an PvD - welches Tag nimmst Du beim Container?
Beiträge von dlueth
-
-
Kenkodi was für ein System hast Du denn und mit welchem OS?
Welchen Tag von Docker benutzt Du denn? Scheinbar einen expliziten, denn eigentlich sollte "latest" automatisch die Architektur auswählen
-
0.10.4 ist fertig gebaut
-
0.10.4 build läuft, ETA ca 3-4h im Docker Hub und den GitHub releases. Ist dann das erste automatische Release auf Buster-Basis.
-
Jo, entweder so, oder Du nimmst meine Binaries XD
Easy sieht das erstellen der Binaries eh nicht als seine Hauptaufgabe an und macht das mehr weil er's muss. Und ob Docker oder nicht steht ja nachwievor jedem frei. Ich bevorzuge Docker, weil ich isolierte Umgebungen mit inkludierten Dependencies habe. Haue ich den Conainer weg ist mein System nachwievor sauber. Und ich kann ggf. auch das System neu installieren und schneller wiederherstellen.
-
@DeBaschdi kein Problem, ich helfe wo ich kann
Was interessant ist:
Easy hat vorher seine armhf Binary auf einem 32-bit Buster gebaut. Die lief dann auch auf RPIs mit einem Raspian gleicher Basis. Das ist nun nicht mehr so. Du hast ja nun Deinen Container auf Bullseye hochgezogen, so das alles wieder zusammen passt. Sollte easy auf einem 64-bit System bauen, denn je nach RPI ist der ja durchaus 64-bit, dann wäre das jetzt eigentlich kein armhf build, sondern arm64 und dürfte auf armhf auch nicht mehr laufen.
Ich bin in die andere Richtung gegangen und habe meine binary builds auf Buster geändert. Daher laufen meine Binaries jetzt, anders als vorher, auch auf den softwaretechnisch älteren RPIs.
-
copain zukünftige automatische releases werden ab sofort immer auf Basis von Buster gebaut, für den Moment nicht mehr mit bullseye. Ich brauche dafür gar nichts zu tun
das ist das schöne, wenn man den Kram via GitHub in Docker baut -
Easy selbst hat das Problem jetzt wohl auch, denn sein rpi hat jetzt scheinbar auch bullseye drauf. Ergo haben es auch die Container von debaschdi
-
Ja: Es scheinen viele Leute ihre RPIs nicht upzudaten und/oder von 32-bit auf 64-bit umzustellen. Daher ergibt sich das Problem, dass die von mir bereitgestellten Binaries zwar generell auf arm aka armhf laufen, aber nicht, wenn das OS noch Buster-basiert ist. Die GLIBC-Version von Buster ist "zu alt" für die builds und da leider statische Builds unter Linux eben doch nicht ganz statisch sind wird das zum Problem.
Da wir ja aber nun wissen, dass eine unter Buster gebaute Binary durchaus auch auf Bullseye läuft kann ich da ja eine Version wieder runter gehen...
-
Jo, das dürfte dann Bullseye sein und damit die Ursache des problems für alle die noch Buster drauf haben
-
Build bei GitHub läuft für die 0.10.3 auf Debian Buster Basis, der Build wird wohl ca. 3-4 Stunden dauern und steht dann im Docker Hub als Image und auch bei den GitHub Releases als Binary bereit. Zukünftge Builds bei Release durch easy werden dann automatisch auch mit Buster gebaut und nicht mehr Bullseye
-
Starfoxfs kk danke - dann mach ich mich jetzt an den neuen release für die buster-version
-
Starfoxfs nimm bitte explizit die Version die ich oben verlinkt habe. Im Repo ist doch immer noch die Bullseye-Version und um die geht es ja nicht XD
-
@DeBaschdi nimmt direkt das von easy4me bereitgestellte Binary für die jeweilige Architektur aus dessen öffentlichem Repo. Für arm64 wird dabei ebenfalls die arm32/armhf binary genommen. Ergo müsste in diesem Fall das Problem irgendwo bei easy liegen. Vermutung, da ich das auch gerade bei meinem minimal Docker durch hab:
Easy baut jetzt auf einem Bullseye basierenden Debian/Raspbian, und das läuft dann nicht auf einem Buster basierenden Debian/Raspbian weil Bullseye eine neuere GLIBC Version mitbringt
-
dlueth armhf
Dir nochmals Respekt und vielen Dank für den unermüdlichen und schnellen Einsatz, was keineswegs selbstverständlich ist!
armhf 0.10.3 Buster läuft auf meinem System. Wie in Post #113 beschrieben, erhielt ich nach dem manuellen Rückkopieren der settings.json erneut 'Errno 13 Permission denied /etc/telerising/settings.json'. Danach habe ich mit der api wieder eine neue generiert, mit neuer uuid und leerem refresh_token.
Ich hoffe, dass das Rückkopieren künftig nach Updates mit dem Script wieder normal funktioniert. Oder habe ich allenfalls etwas übersehen und einen Fehler gemacht?
Kein Problem. Wenn es jetzt total exotische/spezielle Anforderungen wären würd ich's vermutlich ablehnen aus Zeitmangel. Aber da es um die normalen arm-binaries geht die meinerseits genau für die 32-bit RPIs gedacht waren, was ich aber nicht selbst testen kann, machts irgendwie Sinn XD
-
copain sieht so aus als würdest Du das sichern/wiederherstellen der settings.json mit einem anderen Benutzer und/oder anderen Rechten machen als dem, der die Binary dann letztlich ausführt. Wie startest Du denn aktuell die Binary bzw. mit welchem User? Welche "Rechte" haben die neu angelegte und die gesicherte settings.json?
-
Starfoxfs ja, aber das ist noch das bullseye-build. Das angehängte wäre Buster, also die vorige debian-Version
-
-
Alles anzeigen
dlueth armhf
Vielen Dank für Deine Bemühungen, die ich sehr schätze!
Deine Binary aus Post #111 läuft auf meinem System. Das Rückkopieren der settings.json hat allerdings nicht funktioniert. Ich musste mit der api eine neue generieren. Unterschied: NEUE uuid und refresh_token LEER ("").
GLIBC Abfrage:
ldd --version
ldd (Debian GLIBC 2.28-10+rpi1) 2.28
Es scheint, wenn Du Buster zum Generieren des Images verwendest, sollte es funktionieren.
Frage: Ist in Deinem Repo die armhf der Version 0.10.3 bereits auf Basis Buster? Falls dem so wäre, würde ich das Update mit dem Script ausführen.
Selbstverständlich stehe ich für weitere Tests gerne zur Verfügung.
was die settings.json angeht: das war wie gesagt noch eine ältere Version die ich da für Dich gebaut habe, nicht die ganz aktuelle. Generell kann das aber schon sein, weil Easy ja ein paar Sachen angepasst hatte in Sachen "ID-Generierung", wobei ich zugebenermaßen nicht genau weiß, was er da gemacht hat.
-
