Ungemounted, mit dem für das Filesystem installierten check & repair Programm.
Servus !
Ungemounted, mit dem für das Filesystem installierten check & repair Programm.
Servus !
EDIT:
in welcher muss ich schauen?
Gemeint war < man systemd-fstab-generator >, sowie < man systemd.mount >
Mit < apropos systemd > bekommst Du alle Manpages angezeigt, in deren Beschreibungszeile ein systemd vorkommt. Ist der Scrollback Puffer zu klein, übergibst Du die Ausgabe dem more, oder less Programm < apropos systemd | less >
< man man > ist eigentlich selbsterklärend.
Die Abhängigkeiten, die Du in systemd suchst, sind auch in
< man systemd > und < man systemd.unit > grundsätlich dargestellt.
Servus !
Wenn ein (journalisierendes) Filesystem so korrupt wird, dass auch über das Journal nicht mehr verlässlich beschrieben werden kann, wird es auf ro (read only) remounted.
Nach einer erfolgreichen Reparatur des Filesystems wird es wieder rw gemounted.
Servus !
ok. enable hwclock.service funktioniert nicht,
Linux ist so höflich und sagt auch gleich dazu, warum Deine Eingabe fehlschlug.
Wenn Du nunmehr eine Anleitung aus diesem Forum verwendet haben willst, dann wurde dort aber sicher diskutiert, dass das RTC Modul an die 3,3 V Stromversorgung des Pi anzuschliessen ist, und nicht an 5 V "arduino-like"
Ich bin selbst nur (Linux)Anwender und kein Entwickler, oder Tutor und pflege keine Sammlung von Tutorials. Ich komme mit den mitinstallierten man Pages ganz gut zurecht.
Die "Anleitung" für das RTC lautet:
1. Gerätetreiber über dtoverlay einrichten [laut /boot/overlays/README]
2. hwclock.service aktivieren und fake-hwclock.service deaktivieren. [laut man pages und/oder Linux Grundkurs]
Servus !
Den Fehler hast Du Dir vermutlich durch die Anleitung (udev ?) selbst eingebaut. Wenn eine Anleitung kein Datum trägt, dann kann man wenigstens aus den Kommentaren(Datum) auf das Alter der Anleitung rückschliessen. In dem Fall stehts sogar ausdrücköich dabei: This guide was first published on Aug 31, 2012. It was last updated on Aug 31, 2012.
Rd. 10 Jahre später brauchst Du weder etwas installieren, noch Pakete löschen, oder udev Regeln ändern.
fake-hwclock.service und hwclock.service sind im Regelfall vorinstalliert, sollen aber nicht gleichzeitig benutzt werden. Deshalb ist bei enabletem fake-hwclock.service hwclock.service nicht nur disabled, sondern auch noch maskiert (=geblockt).
sudo -i
systemctl stop fake-hwclock.service
systemctl disable fake-hwclock.service
systemctl mask fake-hwclock.service
systemctl unmask hwclock.service
systemctl enable hwclock.service
systemctl start hwclock.service
exit
exit
macht das, was in < man systemctl > beschrieben ist.
Servus !
hwclock --test ?
Geh einmal 2 Schritte zurück:
RTC richtig angeschlossen
Batterie funktioniert/Sicherungslasche entfernt, wenn vorhanden
Batterie, oder Akku im RTC
richtiges dtoverlay installiert
fake-hwclock disabled /masked
kein overlay-Filesystem aktiviert
Neustart nach "halt" (statt reboot)
Servus !
Das hat vermutlich etwas mit der drift-Berechnung zu tun. Siehe < man hwclock >
Schalte die Verwendung von /etc/adjtime einmal weg, beachte aber den gesamten Hinweis zu --noadjfile.
Servus !
Daraus macht irgendwas die Bezeichnung
/media/USB/Datenträger 31 GB
Gemounted wird immer (wenn vorhanden) die im Filesystem des Sticks vergebene Bezeichnung ("label"). Wenn der Stick mit dem Fat Filesystem als /MP1 gemountet werden soll, muss das Label des zu mountenden Filesystems (von derzeit "Datenträger") auf "MP1" geändert werden. Alles das hat mit systemd nichts zu tun.
Servus !
PS: mit < man fatlabel > beispielsweise
Nein, der Mountpoint ist in der /etc/fstab (bei second field) eingetragen und der Filenamen der Mount-unit wird vom systemd-fstab-generator festgelegt.
Stimmt auch, es gibt eben mehrere Möglichkeiten, auch über den systemd-fstab-generatir. Steht alles in der Man Page drinnen.
Servus !
a) an deinem Beispiel mit media-amplefolder.mount, wo wird definiert was dieser Mounpoint? Woher weiß systemd welcher Mountpoint gemeint ist?
Der Mountpoint ergibt sich aus dem Filenamen der Mount-Unit.
media-amplefolder.mount wird als /media/amplefolder gemounted,
Siehe < man systemd.mount > :
"Mount units must be named after the mount point directories they control."
Servus !
Solange am Video Ausgang des Audio Extractors kein Monitor/TV angeschlossen ist, kann in der Grundkonfiguration des Pi kein HDMI Signal (und damit kein HDMI-Audio) erzeugt werden.
Servus !
Wenn nicht einmal der EEPROM Info-Screen am Monitor erscheint, dürfte das Pi4-EEPROM nicht besonders aktuell sein.
Zur Internetrecherche dürfte die Dokumentation von https://www.raspberrypi.org/help/ die erste Adresse sein.
Von https://www.raspberrypi.com/documentation/computers/
auch im Kapitel Raspberry Pi Hardware auch alle Seiten mit Pi4 Boot*
Servus !
Wie viel Volt die beiden Sticks ziehen finde ich leider nicht.
Mit der verbose Option von lsusb (-v) wird Dir zu jedem USB Gerät dessen "MaxPower" in mA angezeigt.
Servus !
Und die Kombination Pi (3) + Touch Display + 8 Relais dürfte die Stromversorgung des Pis auch überfordern.
Servus !
Du kannst versuchen, auf einem Linux System (z.B. Pi-OS light auf einer SD) mit "parted" und dessen rescue (start end) - Option, die Partitionen wiederherzustellen. < man parted >
Dabei durchsucht der Partitions-Editor zwischen den angegebenen Start- und End-Sektoren nach den Magic Numbers diverser Filesysteme und bietet bei Erfolg einen Eintragung in die Partitionstabelle an.
Was der Mac kann, weiss ich nicht. Da weiss ich nur, dass am Mac immer mit raw-Devices gearbeitet werden soll.
Servus !
Eine Frage hätte ich aber dennoch. Ich lasse ja die sda3 vor dem Backup unmounten.
Solange Du rsync mit der -x Option verwendest [ -x, --one-file-system don't cross filesystem boundaries laut < man rsync >], ist es egal, ob im aktiv rsyncten Filesyste (/dev/sda2) sich ein aktiver mount auf /dev/sda3 befindet. Es wird nur der Mountpunkt, nicht aber der Mountinhalt berücksichtigt. Deine mount/umount Bemühungen brauchst Du imho nicht. Und sudo ist auch zwecklos, wenn das Backup Programm selbst schon als root (via sudo, oder direkt) aufgerufen wird.
Dein Neuaufsetzen hat die vielen ACL Fehler beseitigt. Du hättest aber auch erwähnen können, dass Du jetzt mit NFS 3 Dein NAS mountest (vorher NFS 4).
Servus !
Wenn auf Deiner (neuen) Installation keine ACLs gesetzt sind [und auch kein anderer User gesetzt hat], kann ich mir nicht erklären, warum mehrere 100 mal am NSF4 gemountete Kopierziel "setfacl" auszuführen probiert wurde.
Da musst Du eventuell framps Antwort abwarten.
"setfacl" ist, selbst wenn die -acl Option im Mount Befehl gesetzt wäre, ungeeignet. Für NFS4 muss "nfs4_setfacl" verwendet werden. Das Mounten des Zielgerätes ist von Framps Programm nicht umfasst, das muss der Admin des Pis richtig konfigurieren.
Servus !
Du hast jede Menge ACLs gesetzt, vermutlich aus einem höheren Verzeichnis rekursiv.
Damit NFS ACLs überträgt, muss auch die -acl Option beim Mounten angegeben werden.
Dazu kommt, dass Linux/RasPi POSIX ACLs verwendet, die mit NFS4 ACLs nicht ident sind, d.h. dass selbst wenn Dein NAS NFS4 Acls unterstützt, POSIX ACLs vom Pi nicht angenommen werden könnten.
Servus !
Es ist auch ziemlich blauäugig, ein Systemkommando in einem Pythonscript durchzujagen, ohne den Rückgabewert (Shellvariable $?=0) abzufragen und zu berücksichtigen.
Ausserdem hängt es vom Dateisystem der Zielpartition (journalisierend, oder nicht) ab, und wann das letzte Check & Repair ausgeführt wurde.
Servus !
Da Deine Suchmaschine (#6) nicht funktioniert, hier ein passender Link
https://raspberrypi.stackexcha…lock-at-boot-raspberry-pi
"numlockx" ist bei den grossen GUIs (gnome/kde) vorinstalliert. Bei den abgespeckten ("light") Versionen muss es nachinstalliert werden.
Servus !