Neu Installation auf 128GB SD Karte Klipper

Hallo zusammen,

ich versuche gerade den Repetier-Server auf eine 128GB SD Karte zu installieren.
Dieser lief vorher auch auf einer 128GB Karte.
Ein defekt der Karte kann ausgeschlossen werden, da ich bereits 2 Ersatzkarten getestet habe.

Ich habe  das Image Repetier-Server-Image_1_3_0_v28 auf eine SD Karte mit BalenEtcher geschrieben. Alternativ wurde auch RasperryOI Imager ausprobiert, das Ergebnis ist das selbe.

Ich erhalte bei der Installation von Klipper folgende Fehlermeldung :

--2023-01-17 15:49:53--  http://download1.repetier.com/files/server/extras/klipperInstaller.shResolving download1.repetier.com ;(download1.repetier.com)... 94.130.164.39Connecting to download1.repetier.com (download1.repetier.com)|94.130.164.39|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 5842 (5.7K) [application/octet-stream]Saving to: '/tmp/klipperInstaller.sh'     0K .....                                                 100% 25.2M=0s2023-01-17 15:49:53 (25.2 MB/s) - '/tmp/klipperInstaller.sh' saved [5842/5842]Install klipper with parameter: Ender7Klipper
Shell: /bin/bash
No version given, selecting 0.10
/tmp/klipperInstaller.sh: 29: /tmp/klipperInstaller.sh: Syntax error: "(" unexpected
Operation beendet mit Exit Code 0

Das Image Repetier-Server-Image_1_4_6_v34 lässt sich zwar auf eine SD Karte Schreiben aber es wird keine Ausgabe erzeugt. Der Monitor zeigt nur einen schwarzen Bildschirm an.

Kann mir hier jemand weiterhelfen.

Comments

  • Ok zuerst sehe ich das du offenbar das alte image mit dem alten  Repetier-Server nutzt, also nicht erst server aktualisiert hast. Bei dir ist:
    Install klipper with parameter: Ender7Klipper

    Bei der aktuellen version steht da:
    Install klipper with parameter: KlipperTest tags/v0.11.0 1 https://github.com/Klipper3d/klipper.git

    Also 4 Parameter. Muss ich mir noch genauer ansehen das er defaultwerte nimmt. Vermutlich führt das fehlen der parameter zum Problem. Früher hat er nur master installiert, jetzt eine ausgewählte version. Auch wenn ich grad denke das ich was anderes gewählt hatte. Check ich noch.

    Das mit dem schwarzen schirm ist pauschal nicht klärbar. In bullseye nutzt das image den neuen Bildschirmtreiber. Kann also sein das die Konfiguration da anders ist als mit dem alten Treiber. Wenn du in der shell
    sudo raspi-config
    aufrufst und für raspi-cam legacy einstellst wechselt er auf den alten Treiber zurück. Wenn das ein Display ist das zusätzliche Treiber benötigt weil es kein hdmi/dsi nutzt könnte das die Ursache sein.

  • Hallo,

    danke erstmal für die tolle erklärung. (wirklich positiv gemeint)
    Ich hatte beim neuen Image einen standard 19 Zoll Monitor drangehängt, also nichts spezielles.
    Eine Console wird mir nicht direkt angezeigt. Werde aber versuchen durch die einzelnen ttys zu wechseln.
    Ist denn ein gravierender unterschied zwischen den beiden Images?

  • Ja ein sehr großer. V28 ist das letzte Image mit dem alten Raspbian basierend auf debian buster und erhält so gut wie keine Updates mehr. Das andere nutzt das aktuelle Raspbian basieren auf Debian bullseye und hat aktuellere Kerner/Treiber und erhält weiter updates für Linux. Leider haben die auch den Grafiktreiber ausgetauscht weshalb einige Displays jetzt anders reagieren, insbesondere wenn die keine Meldung über Fähigkeiten machen. Das ist ja in /boot/config.txt konfiguriert und da kann man auch explizit einen Modus wählen was vermutlich hilft. Beim pi 4 auch den richtigen hdmi Anschluß wählen. Bin nicht sicher in wie weit sich das da unterscheidet.

    In unserem Interface unter Globale Einstellungen->Terminal kommst du auch auf die Konsole oder halt klassisch mit ssh pi@ipnummer in der Powershell.
  • Hallo,

    danke für die Erläuterung.
    Es macht den Anschein, dass der pi zu keinem  Zeitpunkt eine Netzwerk Adresse bezieht.
    Es handelt sich um einen Pi 3.
    Der Cursor blinkt oben links nur, ein tty lässt sich über strg + alt + F1-F8 nicht öffenen.
    Nach einiger Zeit friert der Cursor ein, kein blinken mehr und kurze Zeit später verliert der Monitor sein Signal.

    Der Pi startet kurz neu und es ist auf fast full Screen das Repetier Logo zu sehen.

    Daher kann ich leider wie oben beschrieben nicht die Config überprüfen.
    Gibt es eine Möglichkeit, den Monitor irgendwie wieder funktionsfähig zu bekommen?

    Viele Grüße

  • > Es macht den Anschein, dass der pi zu keinem  Zeitpunkt eine Netzwerk Adresse bezieht.
    Am einfachsten ethernet Kabel anschließen dann bekommt er eine IP. Ansonsten wird er einen Access Point erstellen mit dem Namen repetierserver über den man sich auch verbinden kann. Pi 3 hat doch schon wifi ode rist das pi 3+?

    Hier
    https://www.raspberrypi.com/documentation/computers/config_txt.html#video-options
    findest du infoes zur config.txt mit Bildschrimeinstellungen. Mir scheint display an sicht klappt bis zu dem Punkt wo der X-Server startet. Ab da wird möglicherweise ein Modus gewählt der fürs Display zu viel ist.

    Ich würde versuchen
    hdmi_group=1
    hdmi_mode= <modus aus liste>

    Oder 
    hdmi_group=2
    hdmi_mode= aus dmt liste wie

    9

    = 800x600 mit 60Hz

    Sollte natürlich zum Monitor passen.
  • Den Fehler konnte ich nun etwas eingrenzen,
    es liegt offenbar an der Partitionierung der SD Karte.
    Wird ein Abbild einer 64GB SD Karte auf 128 GB extrahiert, ist ein booten und betreiben möglich. Der Freie Speicherplatz beträgt 64Gb.
    Sofern die Größe verändert wird, ist ein booten und der Betrieb nicht mehr möglich.
  • Heist das bei 128gb ging nicht nur der Monitor nicht sondern gar nichts? Und bei 64gb geht beides plötzlich?

    Für den ersten reboot setzen wir ein flag um das Dateisystem zu erweitern, was etwas dauert je nach größe. Wenn das wirklich bei 128gb nicht klappt muss ich mal so eine große Karte auftreiben. Möglicherweise liegt es an einem overflow bei der Sektorenberechnung. Wobei das hier der Code ist:
    if fdisk -l | grep "Disk /dev/mmcblk0" ; then

    # Get the starting offset of the root partition
    PART_START=$(/sbin/parted /dev/mmcblk0 -ms unit s p | /bin/grep "^2:" | /usr/bin/cut -f 2 -d: | /bin/sed -e 's/s//g')
    [ "$PART_START" ] || return 1
    # Return value will likely be error for fdisk as it fails to reload the
    # partition table because the root fs is mounted
    /sbin/fdisk /dev/mmcblk0 <<EOF
    p
    d
    2
    n
    p
    2
    $PART_START

    p
    w
    EOF
    /sbin/partprobe
    /sbin/resize2fs /dev/mmcblk0p2
    fi
    Wobei 
    sudo /sbin/parted /dev/mmcblk0 -ms unit s p
    BYT;
    /dev/mmcblk0:124735488s:sd/mmc:512:512:msdos:SD SH64G:;
    1:8192s:532479s:524288s:fat32::lba;
    2:532480s:124735487s:124203008s:ext4::;

    ergibt bei 64gb, letzter sektor ist 124735487 wa snicht hoch ist und das doppelte ist auch weit von einem 32 bit Überluf entfernt. Ext4 kann ja auch tb.

    Möglicherweise ist die Bootpartition das Problem da fat32 offenbar nur 32gb kann. Wobei sie ja am Anfang liegt und nicht vergrößert wird. Und bei meiner 64gb Karte geht es auch.

  • Ich hatte anfangs nur 128 GB hier.
    Ziel war ja den Repetier neu aufzusetzen, da die Drucker Löschung auf dem alt Sstem nicht mehr funktioniert.
    128 GB funktioniert kein output somit habe ich keinerlei Konsole oder ähnliches zur Verfügung. Der tritt hier bei 2 128GB Karten auf. Testinstallation von MainSail ohne Probleme mit Grafik Output auf der Konsole. Ob dies in einem Zusammenhang mit dem PI 3 steht kann nicht beurteilen, da ich nur diesen habe.

    Sofern aber das Abbild von Bullseye von der 64 GB KArte auf die 128 kopiert wird funktioniert auch der output auf dem Monitor.
    Die Partitionierung sieht dann wie folgt aus:

    Freier Platz 4,2 MB
    Boot 268 MB FAT (Partition 1)
    Rootfs  64GB ext4 (Partition 2)
    64 GB nicht Formatiert und feier Speicher

    Als ich dato Repetier erworben haben lief der bislang ohne Probleme auf einer 128 GB Karte.


  • Ja komsich. Hab ja mit dem offiziellen Bullseye Image angefangen. Womit auf welchem OS hast du das image aufgespielt? Hab eine 256GB Karte gefunden aber unter windows ging Balena Etcher und Raspi-Installer nicht. Haben Fehler beim aufspielen gemeldet. Ist jedenfallswas ich noch genauer untersuchen muß. Gibt ja noch größere das sollte heutzutage nicht unmöglich sein wenn das alte Linux das noch konnte.
  • Ich verwende als OS Ubuntu Mate 22.04 LTS Jammy Jellyfish
    Geflasht habe ich die SD Karten mit Ubuntu eigenem Toll (Laufwerke) Balena Etcher (als snap) und Raspi-Installer.
    Aber bin bei dir, da stimmt was nicht. Die 128GB Karte ist schneller geflasht als die 64 GB Karte. Finde ich sehr merkwürdig.
  • Ok einem linux user kann ich ja vielleicht dd als Lösung anbieten wenn das schreiben problematisch ist. Aber aufpassen nicht die flaschele Platte überschreiben und image vorher entpacken.

    Oder wenn deine 128 mit 64gb karte funktioniert könntest du
    sudo touch /usr/local/Repetier-Setup/etc/needExpandFS
    sudo /usr/local/Repetier-Setup/bin/firstRun

    ausführen, was das Dateisystem expandiert mit unserer methode.

    Es könnte sein das da noch ein expander ist, da seit einiger Zeit pibaker nicht mehr am mac funktioniert, mit dem ich die Images gemacht habe. Jetzt hab ich eine Linux Lösung und die hat denke ich auch ein expand skript. Das mussich noch mal genauer untersuchen. Nicht das doppelt expandiert wird und die sich in die quere kommen weils bei 128gb so lange dauert.

  • Ich habe das Wochenende nochmals mit Testen verbracht.

    Auch durch Formatierung mit einem Windows PC ist die neuere Version nicht auf einer 128GB SD Karte Lauffähig.
    Die Hilfe mit der Config.txt lässt den Bildschirm auch nicht aufhellen. Eine Netzwerkverbindung wird zu keinem Zeitpunkt hergestellt.
    Habe nun erst mal die ältere Version genutzt.
    Kann ich irgendeine Unterstützung zur Fehleranalyse beitragen?
  • Ok, hab auch noch mal getestet mit der 256gb Karte.
    Am pi 3 unser image, bootet nicht. Original Raspbian Bullseye von der pi homepage bootet auch nicht.

    Dann gleiche Karte in einen pi 4 und er fährt normal hoch. Als ob dem pi 3 die Karte nicht gefällt. Kein blinken nur rotes dauerleuchten.

    Auf der Homepage den Hinweis gefunden:
    Because of a hardware limitation in the Raspberry Pi Zero, 1 and 2, the boot partition on the SD card must be 256GB or less otherwise the device will not boot up. Later models of Raspberry Pi 2 — with a BCM2837 SoC — along with the Raspberry Pi 3, 4, Zero 2 W, and the Raspberry Pi 400 do not have this limitation. This does not affect Raspberry Pi OS, which always uses a small boot partition.

    Sollte also eigentlich klappen. War eine SanDisk SDXC Karte.

    Hier
    https://elinux.org/RPi_SD_cards
    gibts auch erfolgsberichte, aber alles alte infos also mit alterm linux.

    > Kann ich irgendeine Unterstützung zur Fehleranalyse beitragen?
    Eventuell auch mal testen ob das Original Raspbian bei dir klappt oder nicht. Das ist ja das startimage wo wir dann die extra Skripte etc alle hinzugefügt haben. Wenn das auch nicht klappt ist klar das da ein Zusammenhang ist, auch wenn ich nicht wirklich viele gefunden habe die das Problem zu haben scheinen. 
  • Kurzer nachtrag.

    Der Grund warum der pi 3 nicht gebootet hat hängt wohl mit einem Duet board zusammen das plötzlich dazu führt das Booten nicht klappt. Keine ahnung warum, muss ich noch untersuchen. Aber ohne ihm kann ich das bullseye Image booten.

    Bei unserem image ging es ein paar mal an/aus und dann ging nichts, vermutlich genau was du gemerkt hast.

    Starten mit einem bereits expandierten Image klappt aber unser expander macht es dann kaputt. Werde das noch genauer untersuchen.
  • Ok denke ich weiß jetzt was schief läuft. Der Dateisystemcheck erzeugt ein timeout nach 35% bei mir was also weniger als 128 gb entspricht. Danach muss man enter in der Konsole eingeben (was man nicht sieht) um zu booten. Werde den test rausnehmen auch weil er dann schneller bootet.
    Wenn du das selber versuchen willst in /boot/cmdline.txt einfach fsck.mode=force rausnehmen und es sollte klappen. Oder auf nächstes Image warten.
Sign In or Register to comment.