Posts by Fox-Jet

Quote from framp

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

Folgendes bekomm ich ausgegeben:

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"

Wo find ich die?

Quote from framp

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)

Ist Ansichtssache, aber ich geb dir schon recht. Stabile Container welche tagtäglich durchgehend laufen, sollten eigentlich „always“ als start policy haben

Quote from framp

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.

Sendet raspiBackup automatisch einen SIGTERM command an die Container oder wie sollten diese wissen dass sie die laufenden Prozesse stoppen sollten? (Sofern dies vor dem Backup nötig ist)

Quote from llutz

Wozu?

Wenn du Docker stoppst, schickt der Docker-Daemon ein SIGTERM an alle Container und wartet 10/30 Sekunden (default Timeout Linux/Windows-Container) , damit sie sich beenden können. Nach diesen 10/30 Sekunden erhalten die Container ein SIGKILL.

Das bedeutet jetzt was? Es ist nicht notwendig die Docker Container vor dem raspiBackup zu stoppen?

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.

#!/bin/bash

# Liste der laufenden Container abrufen und speichern
running_containers=$(docker ps --format "{{.Names}}")

# Falls keine Container laufen, Skript beenden
if [ -z "$running_containers" ]; then
    echo "Keine laufenden Container gefunden."
    exit 0
fi

# Container-Namen in eine Datei speichern
echo "$running_containers" > running_containers.txt

echo "Folgende Container werden gestoppt:"
echo "$running_containers"

# Container stoppen
echo "$running_containers" | xargs docker stop

echo "Alle Container wurden gestoppt."

# 2. Teil
# Funktion zum Neustarten der Container
restart_containers() {
    if [ ! -f running_containers.txt ]; then
        echo "Keine gespeicherten Container gefunden."
        exit 1
    fi
    echo "Container werden erneut gestartet:"
    cat running_containers.txt | xargs docker start
    echo "Alle Container wurden gestartet."
}

Fox-Jet

Alles klar, danke!

Quote from simonz

mache einmal ein

Bash

lsblk -f

Hier sieht man nun das ext4 DateiSystem

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

Quote from simonz

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:

admin@raspberrypi:~ $ sudo fdisk -l
...
...

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 83 Linux

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:

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 :

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:

admin@raspberrypi:~ $ sudo mkfs.ext4 /dev/sdc1
mke2fs 1.47.0 (5-Feb-2023)
/dev/sdc1 contains a exfat file system labelled 'USB Stick'
Proceed anyway? (y,N) y
Creating filesystem with 122095622 4k blocks and 30531584 inodes
Filesystem UUID: 9852a3e6-e61a-4ecb-967c-566c62021ae2
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done     

• 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?

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

admin@raspberrypi:~ $ sudo mkfs.ext4 /dev/sdc1
mke2fs 1.47.0 (5-Feb-2023)
/dev/sdc1 contains a ext4 file system
	created on Mon Feb 24 20:40:51 2025
Proceed anyway? (y,N) y
Creating filesystem with 122095622 4k blocks and 30531584 inodes
Filesystem UUID: e05d0e2e-9dc4-45df-ac1d-74dad0a3996e
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done     

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?

Wurde ausgebessert, danke

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

   Bash

   #!/bin/bash
   
   # Benutzer fragen, ob das System neu gestartet oder heruntergefahren werden soll
   echo "Möchten Sie das System neustarten oder herunterfahren? (reboot/shutdown)"
   read action
   
   if [[ "$action" != "reboot" && "$action" != "shutdown" ]]; then
       echo "Ungültige Eingabe. Skript wird beendet."
       exit 1
   fi
   
   # Alle laufenden Docker-Container stoppen
   docker stop $(docker ps -a -q)
   
   # Warte und überprüfe regelmäßig, ob noch Container laufen
   while [[ -n "$(docker ps -q)" ]]; do
       echo "Noch laufende Container: $(docker ps -q | wc -l)"
       sleep 3
   done
   
   echo "Alle Container wurden erfolgreich gestoppt."
   
   # System herunterfahren oder neustarten
   if [[ "$action" == "reboot" ]]; then
       echo "System wird in 5 Sekunden neu gestartet."
       sleep 5
       shutdown -r now
   else
       echo "System wird in 5 Sekunden heruntergefahren."
       sleep 5
       shutdown -h now
   fi

   Display More
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

Quote from RTFM

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

Quote from llutz

Korrigiere mal bitte

Code

,gid=1000

Jackpot Jetzt funktioniert es problemlos. Vielen Dank!

Leider gibt es für MacOS keine guten OpenSource alternativen um EXT4 lesen und schreiben zu können.

Quote from Franjo G

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?

UUID
NAME MOUNTPOINT UUID                                 PARTUUID
sda                                                  
├─sda1
│               67E3-17ED                            9e0b8eec-6f5c-4c22-bdbe-9f4ee54331b9
└─sda2
                403F-1A00                            fb736042-c743-417f-b133-e7380846f80e
sdb                                                  
├─sdb1
│    /boot/firm 4EF5-6F55                            bd153b09-01
└─sdb2
     /          ce208fd3-38a8-424a-87a2-cd44114eb820 bd153b09-02

# 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

Würdest du exFAT einer FAT32 formatierung vorziehen? Unter der Berücksichtigung, dass ich die SSD auch mit Mac-OS und Windows-OS benutzen kann?

Quote from Franjo G

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?

Quote from RTFM

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:

admin@raspberrypi:~ $ lsblk -f
NAME FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                          
├─sda1
│    vfat   FAT32 EFI    67E3-17ED                                           
└─sda2
     vfat   FAT32 RASPI 1TB
                         403F-1A00                                           
sdb                                                                          
├─sdb1
│    vfat   FAT32 bootfs 4EF5-6F55                             454.5M    11% /boot/firmware
└─sdb2
     ext4   1.0   rootfs ce208fd3-38a8-424a-87a2-cd44114eb820  428.5G     1% /

fstab:

# 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:

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 /