Beiträge von Franjo G

    Koenntest Du mir noch die Ausgabe von mount | egrep "nvme|over" zeigen ? Vermutlich sieht es dann genauso aus wie in Beitrag #4 fuer eMMC.

    Aber klar doch :)


    Code
    mount | egrep "nvme|over"
    /dev/nvme0n1p2 on /media/root-ro type ext4 (ro,relatime)
    overlayroot on / type overlay (rw,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_,uuid=on)
    /dev/nvme0n1p1 on /boot/firmware type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
    /dev/nvme0n1p3 on /media/root-ro/home type ext4 (ro,noatime)
    /media/root-ro/home on /home type overlay (rw,relatime,lowerdir=/media/root-ro/home,upperdir=/media/root-rw/overlay/home,workdir=/media/root-rw/overlay-workdir/home,uuid=on)

    //EDIT

    Ist bei mit etwas länger, da /home auf einer 3. Partition liegt. :)

    Wie gesagt, das funktioniert genau wie erwartet.

    Beim enablen des overlayfs wird zunächst /root enabled.
    Dann kommt eine Abfrage, ob /boot auch ro gestzt werden soll. Das habe ich bestätigt.

    Dann erfolgt ein Neustart.
    Nach dem reboot sind alle drei vorhandenen Partitionen auf der NVME ro.

    Beim disablen geht es umgekehrt.
    Zunächst wird das overlayfs auf /boot disabled.

    Da das ohne reboot nicht übernommen wird, kommt eine Meldung, dass /root nicht auf rw gesetzt werden kann, da /boot noch ro ist.
    Nach einem reboot kann ich dann auch das overlayfs auf /boot wieder disablen.

    Ok, wie Du schriebst, sind die wohl gepresst ...

    Also nicht ge- oder verschraubt.

    Ich kann nur von meinem sprechen. Die kann nur gepresst sein, da der Nippel oben und unten nicht übersteht. < 1mm. Da gibt es keine Möglichkeit zu schrauben. Außerdem haben die anderen Löcker kein Gewinde um da einen Nippel hereinzuschrauben.

    Ich habe es aber auch nicht mit Gewalt versucht, da die 2230 da stramm drinsitzt und flach auf dem Hat aufliegt. Die hält auch so perfekt.

    Bei dem 1001 liegt die SSD und der Nippel ein paar mm höher und ohne Nippel würde die in der Luft hängen und nach oben springen.

    Vielleicht lag ja Eurem Teil irgend ein Faltblatt bei.

    Nein, da liegt kein Faltblatt bei. Der Gewindeinsatz ist aber nur schwer herauszubekommen. Der ist eingepresst.

    Da ich die Version 1003 habe, ist das auch nicht erforderlich. Da die ssd so stramm im slot sitzt, dass sie von alleine hält. (Wird waagerecht in den Slot geschoben. Das heißt, die kann nicht nach oben hochklappen)

    Bei den anderen Modellen geht das nicht, da die ssd schräg eingesetzt und dann nach umten gedrückt wird.

    Ich habe leider keine RPi5 mit NVMe um das zu testen.

    Ich habe es gerade mal getestet. geht ohne Probleme.

    Code
     mount
    
    /dev/nvme0n1p2 on /media/root-ro type ext4 (ro,relatime)
    /dev/nvme0n1p1 on /boot/firmware type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
    /dev/nvme0n1p3 on /media/root-ro/home type ext4 (ro,noatime)


    //EDIT

    Beim enablen wurde zunächst /root enabled. Dann kam eine Abfrage, ob /boot auch enabled werden soll.
    Dann Reboot.

    Das disablen erfolgte in 2 Schritten. Zunächst wurde nur /boot disabled. Dann kam ein Hinweis, dass /root nicht rw gesetzt werden kann, da /boot noch ro war. Nach einem Reboot konnte ich dann auch /root disablen.

    Ich habe das bash Problem so geloest dass ich in die .ssh/rc folgendes reingeschrieben habe:

    So geht es natürlich auch. Aber dann muss ich den Code wieder in bash ändern. (echo -e) ^^

    # Da das Sensorauslesen Mainboardabhängig ist, bitte eigenen Befehl eintragen

    Man kann ja auch lm-sensors installieren. Dann gibt es noch ein paar Ausgaben mehr.

    Beispiel auf einem Pi 5 (Wobei mir der Critical-Wert der CPU Temperatur mit 110° recht hoch vorkommt.)
    Die tatsächliche Temperatur stimmt aber mit vcgencmd überein.

    Beispiel auf einem Fujitsu Mini PC (amd64)

    Nachdem Du die /etc/ssh/sshrc und ich mir das vorhergepostete Bild nochmal betrachtete, komme ich zu dem Schluß, da stimmt etwas nicht. Vermutlich hast Du unter /etc/aliases* etwas geändert, sonst würde

    Nein, da ist nichts verändert. Wenn ich eine .sh - Datei schreibe, muss ich mit -e arbeiten. In der rc-Datei funktioniert das aber nicht.

    So sieht das aus, wenn ich echo -e eingebe.

    Egal, ob mit oder ohne shebang #!/bin/bash



    //EDIT

    Das funktioniert genau so wie ich das gepostet habe. Sowohl uf einem Pi wie auch auf einem amd64

    Zu meiner Schande muß ich gestehen, das ich mich (vermutlich) noch nie mit /etc/ssh/sshrc beschäftigt habe

    Die sshrc wird genauso abgearbeitet wie die bashrc. Du kannst natürlich auch alles in die bashrc schreiben, aber so ist es "sauberer".


    Hier mal der Code zu obigem Beispiel:

    DEFAULT_PARTITIONBASED_BACKUP="1"

    DEFAULT_PARTITIONS_TO_BACKUP="3"

    Die Option ist dafür gedacht, dass sich auf dem Systemdatenträger mehr als die 2 Standardpartitionen (Boot und /) befinden.
    In deinem Fall mmcblk0p1 und mmcblk0p2.
    Für den Fall, dass sich auf der SD noch eine Partition mmcblk0p3 befinden würde, könntest du die mitsichern.
    Das macht aber bei einer SD-Karte keinen Sinn.
    Einen weiteren "Datenträger" (z.B. sdx) kannst du nicht ins Backup integrieren.

    Wenn es um die Schreibzyklen auf der SD geht, solltest du besser auf eine SSD umsteigen.