Posts by Fox-Jet
-
-
-
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. -
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)
-
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.
Bash
Display More#!/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!
-
Hier sieht man nun das ext4 DateiSystem
Codeadmin@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:
Code
Display Moreadmin@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:
-
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 :
Codeadmin@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:
Code
Display Moreadmin@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:
Wenn ich mir jetzt aber die Formatierung mit sudo fdisk -l ansehen steht, dass die Partition sdc1 das Dateisystem HPFS/NTFS/exFAT hat?
CodeDisk /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
Code
Display Moreadmin@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?
-
-
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:
- 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 Skript einfügen und speichern
Bash
Display More#!/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
- Skript für den root-User ausführbar machen
sudo chmod -v 750 /usr/local/bin/pi_shutdown.sh Überprüfen ob das Skript ausführbar ist:
ls -l /usr/local/bin/pi_shutdown.sh
Ihr solltet anschließend folgende Ausgabe bekommen:
Skript ausführen:
Das Skript lässt sich nun mit sudo pi_shutdown.sh ausführen.
Noch ein paar Worte zum Skript:
- 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)
- 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.
- 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.
- 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!)
- 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 -
-
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
Display MoreUUID 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
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
-
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?
-
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:
Code
Display Moreadmin@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:
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: