usbmount verhindert Partitionierung einer Partition und beendet deshalb raspiBackup fehlerhaft beim Restore

    Ich bin gerade an einem bloeden Problem dran was raspiBackup hat wenn ein Restore vorgenommen wird und usbmount installiert ist: usbmount mounted automatisch eine USB Partition und fuehrt zum Abbruch von raspiBackup weil eine Parition nicht formatiert werden kann. Die lapidare Meldung ist

    Code
    /dev/sda2 is apparently in use by the system; will not make a filesystem here!


    So wie es sich mir darstellt wird zwar die Partition nicht gemounted aber irgendwie laeuft da ein ext4 Journaling vom Kernel.


    Momentan stoppt raspiBackup wenn usbmount entdeckt wurde. Ist aber eine Kruecke. Weiss jemand wie ich die lapidare Meldung wegbekomme dass ich die Partitionen formatieren kann und somit usbmount nicht erst deinstalliert werden muss damit ein Backup restored werden kann? Es finden sich mehrere Hits zu der Meldung aber keine Loesung funktioniert bei mir :wallbash:


    Das ist offensichtlich ein Problem bei RaspbianOS Desktop. Bei RaspbianOS lite tritt der Effekt nicht auf weil usbmount nicht installiert ist. Warum das Problem auftritt versuche ich schon seit ein paar Tagen rauszufinden.


    Anbei mal Ausgaben meiner CM4 die ich von NVMe gebootet habe und versucht habe ein Backup von sich selbst auf /dev/sda - eine SSD - zu restoren. Wenn die SSD keine Partitionen hat funktioniert alles normal. Wenn aber schon Partitionen existieren gibt es Fehler. Ich habe mal die wichtigsten Ausgaben die ich denke wichtig sind beigefuegt:


    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
    Quote from framp

    Ich bin gerade an einem bloeden Problem dran was raspiBackup hat wenn ein Restore vorgenommen wird und usbmount installiert ist: usbmount mounted automatisch eine USB Partition und fuehrt zum Abbruch von raspiBackup weil eine Parition nicht formatiert werden kann. Die lapidare Meldung ist

    Code
    /dev/sda2 is apparently in use by the system; will not make a filesystem here!


    Teste mal ob es geht, wenn Du beim Formatieren gleichzeitig ein Label für diese Partition anlegst. Wenn nicht, dann vorher die UUID der Partition ändern (wenn sie in der jetzigen Form nicht benötigt wird).

    Wenn das auch nicht geht, dann versuchen mit fdisk das aktuelle Dateisystem der Partition, von ext4 nach ext4 zu ändern.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Like 1

    Sicher das usbmount vorinstalliert ist? Bei Raspberry Pi OS mit Desktop übernimmt doch der Dateimanager die automount Funktion. Mit usbmount wäre das dann doppelt.

    Jetzt habe ich versucht die UUID zu clearen und bekam die Meldung dass dass erst e2fsck zu laufen hat. Dann rief ich e2fsck auf und wieder die Meldung dass des Geraet in use ist :@ Dann bin ich beim Suchen im Netz ueber e2fsck und die Meldung auf eine Seite gestossen wo als Loesung service udev stop genannt wurde.

    und siehe da - jetzt was die ominoese Meldung weg und auch das Formatieren funktionierte :bravo2:


    Wieso udev da irgendwo sein Finger im Spiel hat ... :conf: ich suche noch mal ein wenig ob ich was weiter finde.


    Quote from daxb

    Sicher das usbmount vorinstalliert ist?

    Wenn ich es deinstalliere tritt das Problem nicht mehr auf.

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
    Quote from rpi444

    Teste mal ob es geht, wenn Du beim Formatieren gleichzeitig ein Label für diese Partition anlegst. Wenn nicht, dann vorher die UUID der Partition ändern (wenn sie in der jetzigen Form nicht benötigt wird).

    Wenn das auch nicht geht, dann versuchen mit fdisk das aktuelle Dateisystem der Partition, von ext4 nach ext4 zu ändern.

    Nachdem ich das durch Deinen Hinweis mit dem Deaktivieren von udev als moegliche Loesung gefunden habe:


    Ich habe schon gesehen dass bei mir auf der CM4 Partitionen mit gleichem Label, UUID und PARTUUID existieren. Sie sind ja ein Clone des Backups. Aus Deinen Vorschlaegen dort mal zu aendern entnehme ich dass Du meinst eine dieser Tatsachen ist die Ursache fuer das Problem? Ich habe auch mal mit wipefs getestet aber das hat nichts gebracht.


    Ich lege ja mit sfdisk dieselben Paritionen an wie im Backup und es scheint so zu sein dass in dem Moment usbmount zuschlaegt und die Rootparition mountet. Wenn keine Partitionen auf dem Restoremedium existieren funktioniert alles :conf:


    Warum durch usbmount jdb2 angeschmissen wird hae ich letzte Nacht leider nicht rausgefunden :(

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
    Quote from framp

    Aus Deinen Vorschlaegen dort mal zu aendern entnehme ich dass Du meinst eine dieser Tatsachen ist die Ursache fuer das Problem?

    Nein, ich meinte nicht, dass das die Ursache ist. Mir ging es darum (nur zu testen), ob Du diese Mitteilung:

    Code
    /dev/sda2 is apparently in use by the system;

    auch bekommst, wenn Du die vorgeschlagenen Änderungen machst und für den Fall, dass die oder eine der Änderung(en) erfolgreich durchgeführt werden konnte, das:


    Code
    sudo mkfs.ext4 /dev/sda2

    erfolgreich (d. h. ohne die Mitteilung) durchgeführt werden kann.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Ok. Ich habe ja nur mit dem Label getestet und bin darueber auf udev gestossen. Meinst Du es macht Sinn auch noch mal eine Aenderung der UUID sowie des Filesystems zu testen (Meinst Du wirklich ich soll von ext4 auf ext4 aendern - also eine Dummy Anderung)

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
    Quote from framp

    Meinst Du es macht Sinn auch noch mal eine Aenderung der UUID sowie des Filesystems zu testen (Meinst Du wirklich ich soll von ext4 auf ext4 aendern - also eine Dummy Anderung)

    Ob es Sinn macht, weiß ich nicht. Es sind ja nur Tests um zu sehen, wie das System (in diesem Fall) darauf reagiert und ob danach evtl. und wie, weiter gemacht werden kann. Man sollte aber immer im Auge behalten, dass man bei solchen Tests nichts zerstört.

    Die Änderung von ext4 auf ext4, meinte ich nur in Zusammenhang mit dem (neu)anlegen des Labels (der ja nicht vorhanden war). Wenn er jetzt vorhanden ist, dann durch ändern des Labels.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Quote from rpi444

    Ob es Sinn macht, weiß ich nicht.

    Ich habe es einfach mal getestet. Ist ja schnell getan.



    Wenn ich dass udev stoppe funktioniert alles. Es haengt an dem aktiven jdb2 auf der Parition - also dem ext4 Journaling


    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
    Quote from framp

    Wenn ich dass udev stoppe funktioniert alles. Es haengt an dem aktiven jdb2 auf der Parition - also dem ext4 Journaling

    Hm, ... schon merkwürdig, dass obwohl die Partition nicht gemountet (d. h. ausgehängt) ist, das aktive udev diese Auswirkung auf Tätigkeiten mit bzw. an der Partition, hat.

    Man müsste etwas finden, um das "aktive jdb2" temporär zu deaktivieren ohne das udev stoppen zu müssen.


    EDIT:


    Evtl. mit dumpe2fs und/oder mit tune2fs auf der Partition nachschauen, ob dort die Eigenschaft "has_journal" zu finden ist und wenn ja, ob man evtl. diese temporär mit tune2fs deaktivieren kann.

    Hinweis für andere user/Leser: Immer vorausgesetzt man weiß was man tut und man hantiert mit Partitionen an denen man nichts kaputt machen kann.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Edited 2 times, last by rpi444 ().

    Das usbmount installiert ist, habe ich nicht bezweifelt. :) Ich wollte eher wissen, ob es vielleicht automatisch (aptitude show usbmount) oder manuell installiert wurde. Oder ist usbmount schon im aktuellen Raspberry Pi OS Image enthalten?


    Hintergrund meiner Frage ist folgender: Hier unter Stretch wurde usbmount durch RetroPie automatisch installiert und ich musste es immer manuell deinstallieren, das es sonst zu Konflikten mit Raspberry Pi OS kommt.

    Quote from daxb

    Das usbmount installiert ist, habe ich nicht bezweifelt.

    Dann habe ich Dich missverstanden :blush:

    Quote from daxb

    ob es vielleicht automatisch (aptitude show usbmount) oder manuell installiert wurde

    Code
    pi@raspberrypi-bullseye-desktop:~ $ aptitude show usbmount | grep -i installed
State: installed
Automatically installed: no

    Hm ... ich war der Meinung es ist im RaspbianOS Desktop automatisch installiert. Ich habe allerdings usbmount schon mal deinstalliert und wieder installiert. Keine Ahnung ob das den Status dann aendert.

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
    Quote from rpi444

    Man müsste etwas finden, um das "aktive jdb2" temporär zu deaktivieren ohne das udev stoppen zu müssen.

    Ich habe einen systemctl restart udev ausprobiert und das funktioniert gut. Merkwuerdigerweise gibt es dasselbe Problem nochmal nachdem die Parition mit dem Backup befruchtet wurde und noch mal ein finaler fsck durchgefuehrt werden soll. Igrnedwann schlaegt usbmount nach einer gewissen Zeit offensichtlich wieder zu. Ich denke ein Restart von udev hilft da auch noch mal. Ist aber schon unbefriedigend irgendein Timing bzw Racecondition zu haben.

    Quote from rpi444

    Evtl. mit dumpe2fs und/oder mit tune2fs auf der Partition nachschauen, ob dort die Eigenschaft "has_journal" zu finden ist und wenn ja, ob man evtl. diese temporär mit tune2fs deaktivieren kann.

    Gute Idee. :thumbup: Ich sehe mir das mal an.

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:

    Hiernach sollte das einfach gehen. Leider nicht :(

    Code
    root@raspberrypi-bullseye-desktop:~# tune2fs -l /dev/sda2|grep journ
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

root@raspberrypi-bullseye-desktop:~# tune2fs -O ^ĥas_journal /dev/sda2
tune2fs 1.46.2 (28-Feb-2021)
Invalid filesystem option set: ^ĥas_journal

    Das Filesystem ist nicht gemounted. Auch ein Stoppen von udev hilft nicht.

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
    Quote from framp

    Hiernach sollte das einfach gehen. Leider nicht :(

    Das Filesystem ist nicht gemounted. Auch ein Stoppen von udev hilft nicht.

    Hm, ... ja. Bleibt nur noch die force-Option (... nur zum testen, wenn man nichts kaputt machen kann ...), die aber m. E. für den produktiven Einsatz _nicht_ geeignet ist.


    BTW: Was passiert wenn Du die jdb2-Prozesse über ihre PID killst (mit Signal -15 oder evtl. mit -9)?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Quote from rpi444

    die aber m. E. für den produktiven Einsatz _nicht_ geeignet ist.

    Sehe ich auch so. Auch das Filesystem zu modifizieren ist nicht sehr attraktiv. Mal eben den usb zu restarten ist fuer mich soweit OK.

    Quote from rpi444

    BTW: Was passiert wenn Du die jdb2-Prozesse über ihre PID killst (mit Signal -15 oder evtl. mit -9)?

    Nichts. Die Prozesse bleiben mit derselben pid stehen :(

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
    Quote from framp

    Nichts. Die Prozesse bleiben mit derselben pid stehen

    OK. Was man noch probieren könnte, wären die mount-Optionen "data=writeback,lazytime", für die in Frage kommende Partition (mit dem ext4-Dateisystem).

    Dafür muss die boot-Option:

    Code
    rootflags=data=writeback

    in die /boot/cmdline.txt eingetragen sein. Mit "writeback" ist das journaling nur noch für die Metadaten, tätig/zuständig.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Interessanter Ansatz. Dafuer muss man aber leider das System modifizieren. Das ist unschoen.


    Ich versuche gerade rauszufinden ob man irgendwie den usbmount temporaer disablen kann. Es gibt in /etc/usbmount/usbmount.conf die Zeile ENABLED=0. Nach einem reboot ist dann auch der usbmount disabled. Nun muss ich nur noch rausfinden wie man den usbmount ohne reboot ein- bzw ausschaltet :conf:

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy:
    Quote from framp

    Interessanter Ansatz. Dafuer muss man aber leider das System modifizieren. Das ist unschoen.

    Ja, aber wenn Du es trotzdem mal probieren solltest, dann auch noch zusätzlich mit der mount-Option:

    Code
    barrier=0

    Denn diese mount-Option bewirkt (lt. manpage):

    Der Vollständigkeit halber, hier noch die mount-Optionen "norecovery/noload", mit denen man das journaling auch (temporär) außer Gefecht setzen können soll. Lt. der manpage von ext3/4 (von ext3 aber kompatibel mit ext4):

    Quote

    norecovery/noload


    Don't load the journal on mounting. Note that if the filesystem was not unmounted cleanly, skipping the

    journal replay will lead to the filesystem containing inconsistencies that can lead to any number of

    problems.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Quote from rpi444

    Ja, aber wenn Du es trotzdem mal probieren solltest,

    Werde ich machen :) Weniger weil das ein praktikabler Weg fuer raspiBackup ist als dass es der Beschreibung nach so klingt als wenn es so funktionieren koennte und das will ich schon wissen :)


    Inzwischen weiss ich durch reverse Engineering auch dass man mit

    Code
    DEVNAME="/dev/sda2" /usr/share/usbmount/usbmount add

    bzw remove den USBMOUNT fuer das angegebene Device Aktivieren bzw deaktivieren kann. So wird das Script offensichtlich vom udev Daemon aufgerufen.

    Hast Du schon Deine Raspberries gesichert :fies:

    Bei mir erledigt das raspiBackup vollautomatisch jede Woche :shy: