Beiträge von dlueth

Und, noch ne Frage, vermutlich vossi68 : Hat nur Bookworm auf den RPI 5 die 16k Pagesize oder auch schon Bullseye?

Ah, OK! Das mit dem PiZeroW leuchtet mir übrigens ein, der braucht armv6 und nicht v7. Ist halt nur die Frage warum es vorher lief. vossi68

Tja, das klingt schonmal gut! Aber wir bekommen wir jetzt ganz genau heraus was wo und vor allem warum läuft? XD

Weil eigentlich bestätigst Du ja, vossi68 , dass der bisherige Build schon läuft...

Starfoxfs hm, das ist doch merkwürdig. Weil alle mit Problemen waren ja RPI Nutzer mit einer Pagesize von 16k?

Starfoxfs Bist Du Dir wegen des "ohne Veränderungen" sicher? Ich dachte mit Umstellung auf Bookworm hätte RPI generell auf 16k Pagesize umgestellt? Oder hast Du es einfach via config auf 4k zurückgestellt?

Bitte nochmal um Klärung/Feedback in Bezug auf die RPIs, wo meine Binaries jetzt laufen:

"arm"-Binary aus dem GitHub-Repo: müsste auf den 32-Bit RPIs mit Pi OS auf Basis von Buster & Bullseye (und Bookworm mit via config auf 4k zurückgerehter Pagesize), also 4k Pagesize, laufen

"arm64"-Binary aus dem GitHub-Repo: müsste auf den 64-bit RPIs mit PiOS auf Basis von Buster & Bullseye (und Bookworm mit via config auf 4k zurückgerehter Pagesize), also 4k Pagesize, laufen

"arm16k"-Binary aus meinem Post oben: müsste auf den 32-Bit RPIs mit Pi OS auf Basis von Bookworm, also 16k Pagesize, laufen

"arm6416k"-Binary aus meinem Post oben: müsste auf den 64-Bit RPIs mit Pi OS auf Basis von Bookworm, also 16k Pagesize, laufen

Mögen/können das vielleicht ein paar Leute bestätigen?

easy4me entweder nimmst du die binaries aus meinem repo oder ich gebe dir die passenden Scripte für GitHub. Was auch immer die lieber ist ggf )

Und: sollte buers übrigens Recht haben, dann könnten tatsächlich in dem entsprechenden Archiv wohl tatsächlich die libs einfach gegen die des Betriebssystems getauscht werden

Im Anhang dann mal 2 Binaries der aktuellen 0.13.5 für die RPIs mit 16k Pagesize, also vermutlich Bookworm based Pi OS:

Download Data package from December 26th.

filetransfer.io

buers es gibt hier einen Unterschied, Recht deutlich: die von nuitka erstellten "standalone binaries" sind streng genommen weder standalone, noch echte binaries. Das ist eher eine Art Archiv, was im Normalfall die libs aus dem Betriebssystem nutzt. Da die aber anders heißen oder evtl auch nicht vorhanden sind, muss man sie manuell mit rein packen, aus dem erstellenden Betriebssystem heraus.

Und hier müssen dann die libs halt (teilweise) von der Pagesize her passen.

Nochmal zur Verdeutlichung:

Ich baue eigentlich einen Docker-Container für Telerising-Binaries. Damit dieser möglichst klein ist erstelle ich die Binary und packe sie in einen Scratch-basierten Container. "Scratch" bedeutet, dass es sich um ein absolut minimales Linux handelt, das im Prinzip nur und ausschließlich bootfähig, aber ansonsten komplett nackt ist. Da Docker grundsätzlich Container für mehrere Architekturen erlaubt bei denen es dann selbst entscheidet, welcher Container passt, baue ich aktuell hierfür für amd64, arm32v7 und arm64v8. Das ist das, wofür ich mich aktuell eigentlich verantwortlich fühle - und das bauen dauert momentan ca. 3-4 Stunden für diese 3 Versionen. Als OS für das Bauen wird dabei noch ein Debian Buster benutzt, da es hier in der Vergangenheit mit neueren Versionen Probleme gab.

Nun gab es mit den anderweitig bereitgestellten Binaries immer mal wieder Probleme, so das ich letztlich (weil ich sie eh bauen muss) in meinem Repo die Standalone Binaries mit an das Release hänge. Die meisten von Euch verwenden irgendein Modell des RPIs und haben jetzt irgendwie gefühlt den Anspruch, es müsse da doch laufen...

Dazu kann ich Euch nur sagen: Nein, muss es nicht. Denn leider ist in diesem Zusammenhang ARM sehr viel komplizierter als AMD64 und die Entscheidung von Raspberry einfach mal so von 4k Pagesize (was normal ist) auf 16k umzustellen macht die Sache nochmal deutlich komplizierter. Docker z.B. ist gar nicht dazu in der Lage die Pagesize irgendwo mit einfließen zu lassen. Ein Image ist armv7, oder eben nicht. Passt es von der Architektur her zusammen, dann wird es genommen. Laufen muss es deswegen aber nicht zwangsläufig.

Ich bin gerne bereit meine Binaries, ab vom Docker, etwas zu erweitern. Dafür brauche ich aber Eure Unterstützung. Was die RPIs dieser Welt angeht gehe ich momentan von folgendem aus:

RPI mit Pi OS auf Basis von Debian Buster:

=> Da die Pagesize hier 4k sein müsste und die Binaries für Docker auf Buster gebaut werden sollten hier die arm32v7 bzw. arm64v8 binaries laufen

RPI mit Pi OS auf Basis von Debian Bullseye:

=> Auch hier ist die Pagesize meines Wissens nach 4k und es sollten eigentlich die arm32v7 bzw. arm64v8 binaries aus Buster laufen

RPI mit Pi OS auf Basis von Debian Bookworm:

=> Pagesize ist hier 16k, ergo müssen sowohl die arm32v7 als auch die arm64v8 binaries explizit darauf/dafür gebaut werden

Für Pi OS auf Basis von Bullseye und auch Bookworm gibt es Docker base-images. Die könnte ich also bauen. Allerdings dürfte Bullseye eigentlich nicht nötig sein, da hier die Buster-binaries laufen sollten. Ergo gehe ich aktuell davon aus, dass lediglich Bookworm-binaries neu hinzukommen.

Ist das so korrekt?

Und bitte immer mit angeben auf welcher Basis Euer Pi läuft, Buster/Bullseye oder Bookworm und auch ob es 32 oder 64bit sind...

vossi68 ja, das ist so weit auch logisch. Die Umstellung auf 16k Pagesize erfolgte mit bookworm, unabhängig von 32 oder 64 bit. Ergo braucht es für beides explizite builds, ich habe neulich auf die schnelle aber nur einen für 64 bit gebaut.

Auf bullseye müssen eigentlich die normalen 4k binaries laufen, sowohl bei 32 als auch 64 bit.

Buster basierende OS dürften nochmal wieder ein anderes Thema sein, eigentlich. Allerdings sollte da auch ein Update erfolgen, Buster ist einfach uralt

bendsch dann ist das aber Imho kein Problem mit der Pagesize. Du bist aber noch auf Buster unterwegs, das ist doch uralt...

bendsch Das würde dann bedeuten, dass auch Bullseye mittlerweile die Pagesize auf 16k bekommt und nicht mehr 4k. Kannst Du das bestätigen?

Was gibt folgendes aus?

getconf PAGESIZE

bendsch ich bin hier leider auf Feedback angewiesen, da ich selber nicht Mal mehr einen rpi habe. Reden wir hier von 64 bit rpis mit einem auf Debian bookworm basierenden OS?

easy4me ne Vermutung was das problem war?

ergänzende Frage noch in Bezug auf die RPIs dieser Welt: Gibt es diesen Pagesize Wahnsinn nur bei 64 bit oder auch bei den 32 bit Varianten von Pi OS?

buers Ich bin mir da ehrlich gesagt nicht ganz sicher. Ich bin zwar Softwareentwickler, allerdings weniger auf der Binary-Ebene. Ich glaube wir können Docker an der Stelle auch außen vor lassen, denn es läuft ja schon die "Standalone-Binary" nicht, ohne Docker.

Grundsätzlich sind die vermeintlich statischen Binaries (die via Nuitka aus Python-Code erstellt werden) eben nicht wirklich "statisch", da sie durchaus Libs aus dem Betriebssystem brauchen und mitbringen. Ich bin jetzt gerade nicht sicher, ob es der "Binary"-Teil ist, der Probleme macht oder der Lib-Part (die ja aus dem erstellenden System kommen). Nimmst Du das Archiv einer Binary und entpackst es, siehst Du auch die Libs die inkludiert sind. Ich baue meine Binaries im Docker auf Basis von Debian Buster mit Python 3.9.

Was ich jetzt testweise einfach mal gemacht habe ist, dass ich ein anderes Baseimage, nämlich ein Pi OS mit Python 3.9 auf Basis von Bookworm verwendet habe. Das scheint so weit zu laufen. Ich kann Dir aber nicht sagen, ob die Pagesize dabei jetzt beim erstellen der Binary wichtig ist oder schlicht die Libs entsprechend mit einer anderen Pagesize erstellt wurden.

Es könnten rein die Libs sein, denn ich meine mich zu erinnern, dass ich mal per E-Mail einen Kontakt zu einem QNAP-Nutzer hatte wo das OS auch eine andere Pagesize hatte. Und der hat, meine ich, einfach die Libs im Archiv ausgetauscht, nach dem Entpacken, und es lief - meine ich.

Was den Docker angeht ist das echt mistig. Ein Image kann Multi-Arch sein und Docker wählt das zur Architektur passende Image selber aus (amd64/arm64/arm). Allerdings interessiert ihn dabei die Pagesize natürlich nicht und es gibt auch keine Möglichkeit Images für die gleiche Architektur bei unterschiedlicher Pagesize zu hinterlegen.

Es wird vermutlich darauf hinauslaufen, dass ich neben dem normalen Docker-Tag noch spezielle für den Pi bereitstellen muss. Diese dann an die zugrundeliegende Debian-Version zu hängen macht nicht wirklich Sinn, oder? Die Umstellung erfolgte zwar mit Umzug zu Bookworm, allerdings kann man den Kernel ja via config wieder auf 4k Pagesize zurückdrehen. Ergo erscheint es mir am sinnigsten ggf. sowas wie rpi-4k und rpi-16k zu verwenden.

Was meint Ihr?

Ok, dann war das die Testversion, das ist schonmal gut! Und die andere, aus dem repo, lief ja problemlos unter bullseye?

Pagesize war 4k unter bullseye und 16k unter bookworm, korrekt?