Posts by Fox-Jet

    Ansonsten findest Du den genauen Commandstring der mit der Meldung ausgegeben wird im Debuglog

    Folgendes bekomm ich ausgegeben:

    Code
    admin@raspberrypi:~ $ sudo grep -E "DEFAULT_ST.+SERVICES" /usr/local/etc/raspiBackup.conf
    DEFAULT_STOPSERVICES="systemctl stop containerd && systemctl stop cron && systemctl stop docker"
    DEFAULT_STARTSERVICES="systemctl start docker && systemctl start cron && systemctl start containerd"

    Docker wird jetzt in der aktuellen Release 0.7.0 beim Installer standardmäßig als zu stoppender Service angezeigt. Wer seinen aktuellen Installer updaten will kann das entweder über das UI selbst (M5) oder per Command sudo raspiBackupInstallUI -U tun.

    Kurzes Feedback zur neuen Dockerintegration:

    Ich habe das Backup gestern einmal durchlafen lassen. Bei den Services habe ich die beiden Docker-Services + cron ausgewählt.

    Habe das Backup mit sudo raspiBackup -m detailed gestartet und während dem Backup einmal geschaut welche Docker Container nun gestoppt wurden. Interresanter weise waren alle Container am Laufen (restart policy = "unless-stopped", "always"), außer die beiden welche als restart policy "none" hatten. Diese wurden auch am Ende des Backups nicht mehr gestartet (aus den oben genannten Gründen #12)

    D.h. der Normalfall ist mit systemctl stop docker abgedeckt.

    Die Frage ist nur welche Container wieder starten wenn du Docker daemon startest.

    Laut Dockerdocs werden nur diejenigen neu gestartet, welche auch als „restart policy“ „always“ verwendet.


    Deswegen wäre meine Idee auch gewesen (#1) nur die laufenden Container per ID oder Name zu beenden und dann nur diese Container auch wieder zu starten. Aber ich kann mir gut vorstellen, dass diese Implementierung einen höheren Aufwand darstellt + Docker selber wird damit nicht gestoppt.

    Grüß euch,
    Ich bin gerade dabei mich in raspiBackup genauer einzulesen und bin im Punkt "Services stoppen" (und damit Verbunden im FAQ18) auf die Liste der zu stoppenden Services (welches aktuell implementiert sind) gestoßen. Da ich meinen Raspberry Pi eigentlich nur als Docker Container Server nutze, ist mir aufgefallen dass die Funktion Docker Container zu stoppen und anschließend wieder zu starten bis dato noch nicht enthalten ist.

    Gibt es bereits Leute die hier Erfahrungen haben? Arbeitet raspiBackup ohne Probleme mit laufenden Docker Containern?

    Könnte man diese Funktion im raspiBackup ergänzen? Ein Skript könnte wie folgt aussehen.


    Fox-Jet

    mache einmal ein

    Bash
    lsblk -f

    Hier sieht man nun das ext4 DateiSystem :thumbup:

    Code
    admin@raspberrypi:~ $ lsblk -f
    NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
    sdc                                                                         
    └─sdc1
         ext4   1.0         e05d0e2e-9dc4-45df-ac1d-74dad0a3996e

    Fliegenhals Ab- und Anstecken hatte nichts gebracht

    Da es sich beim USB-Stick von Fox-Jet ja um eine MBR- ("DOS") und nicht um eine GPT-Partitionierung handelt, sollte das so mit fdisk gehen:

    Das hat nun funktioniert, habe jetzt "Linux" als Typ in der Partitionstabelle:

    Nachdem ich mit w (write) die neue Tabelle geschrieben habe, hab ich eine Ausgabe bekommen. Jedoch weiß ich nicht ganz was ich damit machen soll:

    Code
    Command (m for help): w
    The partition table has been altered.
    Calling ioctl() to re-read partition table.
    Syncing disks.

    Grüß euch,
    Ich habe mir soeben meinen USB Stick von exFAT auf ext4 formatiert um ihn als Backup-Device für RaspiBackup nutzen zu können, aber er wird mir noch als exFAT angezeigt.

    Was habe ich gemacht:

    • USB Stick angesteckt (aigo Z398Pro 512GB - hab ich mal als Firmengeschenk bekommen)
    • Sichergestellt dass er nicht gemountet ist :
    Code
    admin@raspberrypi:~ $ lsblk
    NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
    sdc      8:32   0 465.8G  0 disk 
    └─sdc1   8:33   0 465.8G  0 part 
    • auf ext4 formatiert:
    • USB Stick mit fsck überprüft:

      Code
      admin@raspberrypi:~ $ sudo fsck /dev/sdc1
      fsck from util-linux 2.38.1
      e2fsck 1.47.0 (5-Feb-2023)
      /dev/sdc1: clean, 11/30531584 files, 2197341/122095622 blocks

    Wenn ich mir jetzt aber die Formatierung mit sudo fdisk -l ansehen steht, dass die Partition sdc1 das Dateisystem HPFS/NTFS/exFAT hat?

    Code
    Disk /dev/sdc: 465.76 GiB, 500107862016 bytes, 976773168 sectors
    Disk model: aigo Z398Pro    
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disklabel type: dos
    Disk identifier: 0x55d440aa
    
    Device     Boot Start       End   Sectors   Size Id Type
    /dev/sdc1        8192 976773167 976764976 465.8G  7 HPFS/NTFS/exFAT


    Wenn die den Stick erneut formatieren möchte, steht jedoch dass dieser bereits ext4 formatiert ist :/

    Habe die Formatierung erneut durchlaufen lassen, jedoch gibt mir sudo fdisk -l die selbe Ausgabe aus wie oben.

    Weiß jemand wieso? Ist das problematisch oder kann ich den Stick ohne Probleme als Backup-Medium nutzen?

    Grüß euch,
    Ich dachte ich stelle hier meine Lösung für einen cleanen Rebooten und Shutdown vor, wenn der Raspberry Pi als Docker-Server genutzt wird.

    Diese Anleitung soll vor allem Leuten wie mir dienen, die wenig Ahnung vom Linux Betriebssystem haben und auf Nummer Sicher gehen wollen wenn sie ihren Raspberry Pi neue starten oder ausschalten möchten.

    Was macht das Skript:

    • Fragt ob das System neu gestartet (reboot) oder ausgeschalten (shutdown) werden soll. Bei Falscheingabe bricht das Skript ab
    • Stoppt alle Container und gibt in einem 3 Sekunden Rhythmus die noch laufenden Container (ID) aus
    • Wenn alle Container gestoppt wurden erscheint die Mitteilung "Alle Container wurden erfolgreich gestoppt."
    • Je nach Eingabe wird der Pi nach 5 Sekunden rebootet oder heruntergefahren

    That's it!

    Installation:

    1. Erstellen der Skript Datei für den root-User (Da ich das Skript später über "pi_shutdown" ausführen möchte erstelle ich die Datei dementsprechend. Ihr könnt natürlich jeden x-beliebigen Namen wählen):
      sudo nano /usr/local/bin/pi_shutdown.sh
    2. Skript einfügen und speichern

    3. Skript für den root-User ausführbar machen
      sudo chmod -v 750 /usr/local/bin/pi_shutdown.sh
    4. Überprüfen ob das Skript ausführbar ist:
      ls -l /usr/local/bin/pi_shutdown.sh 

      Ihr solltet anschließend folgende Ausgabe bekommen:

      Code
      admin@raspberrypi:/ $ ls -l /usr/local/bin/pi_shutdown.sh 
      -rwxr-x--- 1 root root 879 Feb 20 18:11 /usr/local/bin/pi_shutdown.sh


    Skript ausführen:

    Das Skript lässt sich nun mit sudo pi_shutdown.sh ausführen.


    Noch ein paar Worte zum Skript:

    1. Nutzen des Skriptes auf eigene Gefahr (ich bin leider kein Linux Profi somit kann ich Fehler welche durch das Ausführen des Skriptes entstehen könnten nicht abschätzen)
    2. Vergesst nicht wenn ihr den Pi neu startet, dass nicht alle Container automatisch wieder neu gestartet werden. Dies hängt mit den gesetzten Startbedingungen der Docker Container restart: none, on failure, always oder unless stopped zusammen.


    Ich hoffe, dass das Skript für den Einen oder Anderen nützlich sein könnte.

    Sollte es konstruktives Feedback geben bin ich gerne dafür offen.


    Beste Grüße
    Fox-Jet

    Was Du aber verschweigst ist der im Threadtitel enthaltene Bedingung "mit Zugriffsrechten für Docker Container" . Da hast Du in RE: Raspberry Pi 4B startet nach einem reboot von der SSD nicht mehr angeführt, dass Du ein reboot durchgeführt hast, ohne vorher alle Container (manuell) zu schliessen. Dadurch hast Du nicht nur ein paar Blätter, sondern einen ganzen Ast (oder mehrere) am Stamm des Filesystem-Baumes verloren, und die Rekonstruktion aus lost+found ist Dir zu beschwerlich.

    Das sind 2 Paar Schuhe.

    1. Wie bereits erwähnt habe ich meine Lieder als FLAC file auf einer NTFS Platte vorliegen. Beide Platten am Windows PC anzuschließen und auf die SSD rüber zu kopieren ist der einfachste Weg für mich.
    2. Dass die SSD nur wegen den "nicht heruntergefahrenen Containern" bei dem Reboot beschädigt wurde mutmaße ich nur. Wissen tu ich es nicht. Ich habe sogar ein paar Mal erneut versucht den Fehler zu rekonstruieren und auch als alle Docker-Container an waren ist mir die SSD trotz reboot und einem standard shutdown nicht abgeschmiert! (altes Setup!)
    3. Ich habe alle Files und Ordner im "lost+found" durchgesehen, doch ohne File-Endung wie *.flac, *.mp3, *.jpeg, usw. ist der Aufwand diese Files wiederherzustellen viel größer als einfach die Platte neu zu formatieren und die Datein neu rüber zu kopieren. Ein paar Files aus Paperless-ngx habe ich in der Tat "verloren", diese muss ich nun erneut mühselig aus meinen Mails und Ablagen erneut einlesen.

    Das neue Setup sieht nun so aus, dass ich meine Musik auf der 1TB SSD gespeichert habe und das System läuft auf der 500GB SSD. Docker ist auf der 500GB SSD installiert und hat auf die Musikordner nur read-only Rechte. Sollte die Boot-Partition erneut schaden nehmen (warum auch immer) hoffe ich dass die 1TB SSD von diesem Problem verschont bleibt, da kein DockerContainer auf diese SSD schreibt.

    Ich möchte mich hier nochmals an alle Unterstützer bedanken. Ein besonderer Dank geht an RTFM ohne ihn wäre ich keinen Schritt weiter gekommen.

    Letzten Endes habe ich die Festplatte neu aufgesetzt und alle Daten und Container neu raufgespielt bzw. installiert. Ich werde das nächste Mal ganz sicher ein Backup erstellen wenn wieder alles läuft!

    Aus meiner Sich kann dieser Post geschlossen werden.


    Vielen Dank
    Fox-Jet

    Wnn du per PARTUUID mountest, dann musst du auch die PARTUUID eingeben und nicht die UUID

    Habe jetzt erst verstanden was du gemeint hast. Bei mir mounten er es auch mit der PartUUID nicht nach einem reboot. Muss das Laufwerk vor dem Reboot bereits "dynamisch" einmal auf dem Mountpoint gemounted worden sein?


    Code
    # file_system         mount_point     type         options                   dump pass
    proc            /proc           proc    defaults          0       0
    PARTUUID=bd153b09-01  /boot/firmware  vfat    defaults          0       2
    PARTUUID=bd153b09-02  /               ext4    defaults,noatime  0       1
    PARTUUID=fb736042-c743-417f-b133-e7380846f80e    /SSDmusic       vfat    nofail,uid=1000,guid=1000  0   0
    # a swapfile is not a swap partition, no line here

    Wnn du per PARTUUID mountest, dann musst du auch die PARTUUID eingeben und nicht die UUID

    Die UUID ist doch genauso einzigartig wie die PartUUID, sollten hier nicht beide Optionen funktionieren?

    Eine knapp 1 TB grosse Partition mit FAT32 zu formatieren halte ich für ziemlich problematisch.

    Frag mich nicht warum, das musst Du Dir selbst erarbeiten.

    Die Idee war, dass ich meine Music auch mit meinem Mac und meinem Windows PC auf die SSD kopieren kann. Ich hatte damals ziemliche Probleme mit exFAT und dem Raspi. (höchstwahrscheinlich Anwenderfehler) Hast du dafür eine bessere Idee?

    Noch ist die Platte leer (bis auf 1 Album zum Testen)

    Dachte Manual pages gibt es nur von Befehlen. Danke für denk Hinweis :)

    ---

    Ich habe jetzt die USB SSD versucht per fstab statisch zu mounten, jedoch wurde die SSD nach einem reboot nicht gemountet.

    SSD UUID:

    fstab:

    Code
    # file_system         mount_point     type         options                   dump pass
    proc            /proc           proc    defaults          0       0
    PARTUUID=bd153b09-01  /boot/firmware  vfat    defaults          0       2
    PARTUUID=bd153b09-02  /               ext4    defaults,noatime  0       1
    PARTUUID=403F-1A00    /SSDmusic       vfat    nofail,uid=1000,guid=1000  0   0
    # a swapfile is not a swap partition, no line here
    #   use  dphys-swapfile swap[on|off]  for that

    Nach dem Reboot:

    Code
    admin@raspberrypi:~ $ lsblk
    NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
    sda      8:0    0 931.5G  0 disk 
    ├─sda1   8:1    0   200M  0 part 
    └─sda2   8:2    0 931.3G  0 part 
    sdb      8:16   0 465.8G  0 disk 
    ├─sdb1   8:17   0   512M  0 part /boot/firmware
    └─sdb2   8:18   0 465.3G  0 part /