Bei meinem raspberry pi ist nach der Einrichtung von pihole und einem Stromabbruch ein eingehängtes Dateisystem /dev/mmcblk0p2 entstanden, für dass kein Mountpoint erzeugt wurde. "fsck" lässt sich nicht ausführen und weist aus mögliche Schäden hin - ein Neu-Formatieren der SD-Card scheitert, egal mit welchen Tool. Wie kann ich mein Dateisystem auf der SD-Card umhängen/retten oder die CD-Card formatieren? Das eingehängte Dateisystem funktioniert dabei einwandfrei, es lässt sich jedoch keine Aktualisierung zu.
eingehängtes Dateisystem ohne Mountpoint aushängen
- Ersteller nobbs11
- Erstellt am
bei mir funktioniert kein fsck.
hier die Ergebnisse der Anzeigen von df:
pi@raspberrypi:~ $ df
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root 61876988 5386840 53922028 10% /
devtmpfs 468148 0 468148 0% /dev
tmpfs 472756 1420 471336 1% /dev/shm
tmpfs 472756 12432 460324 3% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 472756 0 472756 0% /sys/fs/cgroup
/dev/sda1 15133384 127072 15006312 1% /media/nobstick
/dev/mmcblk0p1 64456 22256 42200 35% /boot
tmpfs 94552 0 94552 0% /run/user/1000
tmpfs 94552 0 94552 0% /run/user/999
von lsblk:
pi@raspberrypi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 14,5G 0 disk
`-sda1 8:1 1 14,5G 0 part /media/nobstick
mmcblk0 179:0 0 60,1G 0 disk
|-mmcblk0p2 179:2 0 60G 0 part /
`-mmcblk0p1 179:1 0 63M 0 part /boot
von fsck:
pi@raspberrypi:~ $ fsck
fsck from util-linux 2.25.2
e2fsck 1.43.3 (04-Sep-2016)
/dev/mmcblk0p2 ist eingehängt.
WARNUNG!!! Das Dateisystem ist eingehängt. Wenn Sie fortfahren, WERDEN
Sie SCHWERWIEGENDE Schäden am Dateisystem verursachen.
Wirklich fortfahren<n>?
Das Dateisystem ist eingehängt, aber ohne Mountpoint. Wenn ich brutalerweise die letzte Frage mit "j" beantworte, werden mir fehlende Berechtigungen angezeigt:
fsck.ext4: Keine Berechtigung beim Versuch, /dev/mmcblk0p2 zu öffnen
Sie benötigen r/w- oder root-Rechte für das Dateisystem.
wenn ich mich als su anmelde:
pi@raspberrypi:~ $ sudo fsck
fsck from util-linux 2.25.2
e2fsck 1.43.3 (04-Sep-2016)
/dev/mmcblk0p2 ist eingehängt.
e2fsck: Fortsetzung nicht möglich, wird abgebrochen.
bin etwas ratlos!!
hier die Ergebnisse der Anzeigen von df:
pi@raspberrypi:~ $ df
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root 61876988 5386840 53922028 10% /
devtmpfs 468148 0 468148 0% /dev
tmpfs 472756 1420 471336 1% /dev/shm
tmpfs 472756 12432 460324 3% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 472756 0 472756 0% /sys/fs/cgroup
/dev/sda1 15133384 127072 15006312 1% /media/nobstick
/dev/mmcblk0p1 64456 22256 42200 35% /boot
tmpfs 94552 0 94552 0% /run/user/1000
tmpfs 94552 0 94552 0% /run/user/999
von lsblk:
pi@raspberrypi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 14,5G 0 disk
`-sda1 8:1 1 14,5G 0 part /media/nobstick
mmcblk0 179:0 0 60,1G 0 disk
|-mmcblk0p2 179:2 0 60G 0 part /
`-mmcblk0p1 179:1 0 63M 0 part /boot
von fsck:
pi@raspberrypi:~ $ fsck
fsck from util-linux 2.25.2
e2fsck 1.43.3 (04-Sep-2016)
/dev/mmcblk0p2 ist eingehängt.
WARNUNG!!! Das Dateisystem ist eingehängt. Wenn Sie fortfahren, WERDEN
Sie SCHWERWIEGENDE Schäden am Dateisystem verursachen.
Wirklich fortfahren<n>?
Das Dateisystem ist eingehängt, aber ohne Mountpoint. Wenn ich brutalerweise die letzte Frage mit "j" beantworte, werden mir fehlende Berechtigungen angezeigt:
fsck.ext4: Keine Berechtigung beim Versuch, /dev/mmcblk0p2 zu öffnen
Sie benötigen r/w- oder root-Rechte für das Dateisystem.
wenn ich mich als su anmelde:
pi@raspberrypi:~ $ sudo fsck
fsck from util-linux 2.25.2
e2fsck 1.43.3 (04-Sep-2016)
/dev/mmcblk0p2 ist eingehängt.
e2fsck: Fortsetzung nicht möglich, wird abgebrochen.
bin etwas ratlos!!
mensch183
Captain
- Registriert
- Jan. 2008
- Beiträge
- 3.666
Das ist wie "Ich hänge mein Handtuch an einen Haken. Haken gibts keinen." Sowas gibts grundsätzlich nicht.nobbs11 schrieb:
Ist das rot markierte nicht das gesuchte /dev/mmcblk0p2 mit seinem Mountpunkt / ? Es taucht in der Liste also nur unter einem anderen Namen auf als erwartet. Warum auch immer.nobbs11 schrieb:
Die Namen der Gerätedateien, über die man ein Gerät anspricht, sind beliebig änderbar. Und du kannst für jedes Gerät beliebig viele davon anlegen. Ist sinnlos und stiftet Verwirrung, aber geht halt.
Schau dir mit "ls -l /dev/root /dev/mmcblk0p2" an, was sich hinter den Namen versteckt. Beispiel:
$ ls -l /dev/sda1
brw-rw---- 1 root disk 8, 1 May 14 23:36 /dev/sda1
Wenn bei deinen beiden Gerätefiles der Gerätetyp (das b ganz links steht für Blockgerät) und die beiden Gerätenummern (die 8 und die 1) übereinstimmen, sind beide Gerätefiles verschiedene Namen fürs gleiche "Gerät", bei dir also für die gleiche Partition. Wenn du sie unter dem einen Namen mountest und dann unter dem anderen Namen versuchst anzusprechen, ist sie trotzdem gemountet. Sind wirklich nur 2 Namen fürs gleiche Ding.
Zuletzt bearbeitet:
Hab' ich schon versucht!
pi@raspberrypi:~ $ ls -l /dev/root /dev/mmcblk0p2
ls: Zugriff auf /dev/root nicht möglich: Datei oder Verzeichnis nicht gefunden
brw-rw---- 1 root disk 179, 2 Feb 4 19:17 /dev/mmcblk0p2
hier noch mal die Anzeige von blkid:
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="0EF2-CA4B" TYPE="vfat" PARTUUID="24f2bb2e-01"
/dev/mmcblk0p2: UUID="e093a5bb-b180-4f87-9d60-467b3e79811d" TYPE="ext4" PARTUUID="24f2bb2e-02"
/dev/sda1: UUID="0F4C-7EE1" TYPE="vfat" PARTUUID="2a365227-01"
/dev/mmcblk0: PTUUID="24f2bb2e" PTTYPE="dos"
zum Handtuchgleichnis: Ich hab den Strick eines Galgens um den Hals, doch keiner zieht ihn zu! Ich würde den Strick gern entfernen, doch das geht nicht.
pi@raspberrypi:~ $ ls -l /dev/root /dev/mmcblk0p2
ls: Zugriff auf /dev/root nicht möglich: Datei oder Verzeichnis nicht gefunden
brw-rw---- 1 root disk 179, 2 Feb 4 19:17 /dev/mmcblk0p2
hier noch mal die Anzeige von blkid:
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="0EF2-CA4B" TYPE="vfat" PARTUUID="24f2bb2e-01"
/dev/mmcblk0p2: UUID="e093a5bb-b180-4f87-9d60-467b3e79811d" TYPE="ext4" PARTUUID="24f2bb2e-02"
/dev/sda1: UUID="0F4C-7EE1" TYPE="vfat" PARTUUID="2a365227-01"
/dev/mmcblk0: PTUUID="24f2bb2e" PTTYPE="dos"
zum Handtuchgleichnis: Ich hab den Strick eines Galgens um den Hals, doch keiner zieht ihn zu! Ich würde den Strick gern entfernen, doch das geht nicht.
mensch183
Captain
- Registriert
- Jan. 2008
- Beiträge
- 3.666
Dann wurde der Name /dev/root eben wieder entfernt. Das ändert nichts an meiner restlichen Beschreibung. Das ist NUR EIN NAME.
Ich gehe weiterhin davon aus, dass das fragliche Filesystem nach / gemountet ist. Der Mountpunkt (denk an den Handtuch-Haken) IST NICHT VERSCHWUNDEN.
Fsck will nicht drauf rumwerkeln, weil fsck ggf. beim Reparieren das Filesystem schrotten würde, wenn nebenbei noch jemand anderes drauf rumschreibt. Alles ganz normal. Kannst es read-only remounten (mount -o remount,ro /), wenn du das vermeiden willst. Darf nur nicht in Benutzung sein.
Ich gehe weiterhin davon aus, dass das fragliche Filesystem nach / gemountet ist. Der Mountpunkt (denk an den Handtuch-Haken) IST NICHT VERSCHWUNDEN.
Fsck will nicht drauf rumwerkeln, weil fsck ggf. beim Reparieren das Filesystem schrotten würde, wenn nebenbei noch jemand anderes drauf rumschreibt. Alles ganz normal. Kannst es read-only remounten (mount -o remount,ro /), wenn du das vermeiden willst. Darf nur nicht in Benutzung sein.
Zuletzt bearbeitet:
Die Ausgabe der Kernel-Bootparameter kann helfen - siehe
Die Raspberry Pi ARM Platform benutzt SD-Karten mit 2 Partitionen. Eine Boot auf denen zB Kernel und Konfiguration gespeichert werden und eine ROOTFS Partition.
Technische Details in Englisch zB hier . Die Bootphasen der Hardware sind doch ausreichend dokumentiert.
Im normalen Kartenleser kann doch das rootfs überprüft werden. Ebenso kann via Noobs/PINN ein anderes Linux-Derivat installiert werden und das zum Check genutzt werden.
Ansonsten gibt es doch anleitungen zum force check währen boots beim Raspi zb. hier
/proc/cmdlineDie Raspberry Pi ARM Platform benutzt SD-Karten mit 2 Partitionen. Eine Boot auf denen zB Kernel und Konfiguration gespeichert werden und eine ROOTFS Partition.
Technische Details in Englisch zB hier . Die Bootphasen der Hardware sind doch ausreichend dokumentiert.
Im normalen Kartenleser kann doch das rootfs überprüft werden. Ebenso kann via Noobs/PINN ein anderes Linux-Derivat installiert werden und das zum Check genutzt werden.
Ansonsten gibt es doch anleitungen zum force check währen boots beim Raspi zb. hier
... das Problem ist, dass das Dateisystem in meinem Fall immer in Benutzung ist. Ich würde die SD-Card notfalls gerne neu formatieren, doch das ist weder in einer Kamera noch mit Linux-Live-Systemen o.ä. zu bewerkstelligen. Jegliches "format" bricht mit einer Fehlermeldung ab und das vorhandene System läuft weiter wie bisher. Updates auf das Betriebssystem oder Anwendungen werden ebenso verworfen.
Wie hast du überhaupt die SD-Karte für den Raspberry tauglich beschrieben ? Dort einfach neu formatieren.
Im laufenden System kann theoretisch ohne Probleme die SD-Karte beschrieben werden, es sei denn diese ist defekt oder es ist etwas im read-only modus eingestellt - zB wird ein nicht modifizierbares read-only rootfs verwendet. Die Kernelparameter zum check des FS wurden schon verlinkt.
Mit Noobs oder PINN gibt es mehrere Systeme unabhängig voneinander auf dem Raspi und dann können auch einzelne Systeme gelöscht werden ohne die anderen zu beeinflussen. Dualboot/Multiboot also. Es gibt dann quasi mehrere Partitionen auf der SD-Karte - alle unabhängig voneinander. Damit kann dann zuverlässig die "kaputten" Partititionen gelöscht oder neu aufgesetzt werden.
Ansonsten kann der Raspberry eigentlich auch über USB oder Netzwerk booten. Damit wird der SD-Kartenleser nicht genutzt und die Karte kann da dann komplett neu aufgesetzt werden.
Außerdem geht im laufenden Betrieb beim Raspi meines wissen ohne Probleme ein Überschreiben der Partitionsdaten und des MBRs der SD-Karte, da Linux im laufenden Betrieb die Bootpartition nicht benötigt.
Die Karte sollte dann als leer erkannt werden (da FAT32 überschrieben) und in Kameras neu formatiert werden können.
Erfahrene Anwender:
USB, Netzwerkboot, Multiboot sind aber alle einfacher einzurichten.
Im laufenden System kann theoretisch ohne Probleme die SD-Karte beschrieben werden, es sei denn diese ist defekt oder es ist etwas im read-only modus eingestellt - zB wird ein nicht modifizierbares read-only rootfs verwendet. Die Kernelparameter zum check des FS wurden schon verlinkt.
Mit Noobs oder PINN gibt es mehrere Systeme unabhängig voneinander auf dem Raspi und dann können auch einzelne Systeme gelöscht werden ohne die anderen zu beeinflussen. Dualboot/Multiboot also. Es gibt dann quasi mehrere Partitionen auf der SD-Karte - alle unabhängig voneinander. Damit kann dann zuverlässig die "kaputten" Partititionen gelöscht oder neu aufgesetzt werden.
Ansonsten kann der Raspberry eigentlich auch über USB oder Netzwerk booten. Damit wird der SD-Kartenleser nicht genutzt und die Karte kann da dann komplett neu aufgesetzt werden.
Außerdem geht im laufenden Betrieb beim Raspi meines wissen ohne Probleme ein Überschreiben der Partitionsdaten und des MBRs der SD-Karte, da Linux im laufenden Betrieb die Bootpartition nicht benötigt.
Die Karte sollte dann als leer erkannt werden (da FAT32 überschrieben) und in Kameras neu formatiert werden können.
Erfahrene Anwender:
- können auch per PC via USB-Seriell Kabel auf der seriellen Konsole den Bootloader (U-Boot) unterbrechen und haben dort evtl. auch einige Befehle zum Neuformatieren und Lesen/Schreiben auf der SD-Karte - dazu besser boot_delay anpassen
- Ein RAM-only Linux von irgendwoher SD/USB/Netzwerk booten und dann dort mit den Tools den Stick neu aufsetzen.
USB, Netzwerkboot, Multiboot sind aber alle einfacher einzurichten.
Noch einmal zur Info. Ich habe ein wunderbar funktionierendes Debian Stretch System auf meinem raspberry pi laufen, dass außer meinen Update-Wünschen alles verarbeitet, was ich von ihm verlange. Updates oder Upgrades gelingen, doch dann wünscht der Raspberry einen Neustart und alle durchgeführten Änderungen werden verworfen. Den Neustart zu verweigern hilft nichts, da das BS jede weitere Tätigkeit vor einem Neustart ablehnt.Ich kann jeden Text editieren und abspeichern, jedes Programm zur Steuerung der Hardware kompilieren, doch ist die Änderung der eigenen Hardware - sprich Neuformatierung der BS-SD-Karte - ist nicht möglich, da irgendein Prozess den Zugriff verweigert. Das erstaunliche ist, dass ich mit meinem System arbeiten kann, das ich hauptsächlich für Transferaufgaben nutze. Kann es sein, dass ich während eines Speicherungsprozesses die Stromversorgung unterbrochen habe, das zu dem vorliegenden Ereignis ohne Mountpoint führte?
mensch183
Captain
- Registriert
- Jan. 2008
- Beiträge
- 3.666
Wir sind hier im Thread in der Sache keinen Millimeter weitergekommen, weil wir nur um längst beerdigte Mythen herumtanzen, statt angebliche Fehler überhaupt mal zuverlässig zu verifizieren (Aufforderung in #3 hast du nie befolgt), geschweige denn Ursachen zu finden und zu beheben. Das widerlegte Märchen vom "Mount ohne Mountpunkt" lebt weiter. Die unsinnige Verwunderung, dass ein vollständig gebootetes Linux-System sein Root-Filesystem verwendet und nicht zerschossen haben will, herrscht noch immer. Die anderen gegebenen Beschreibungen darf man mittlerweile als ähnlich "zuverlässig" bewerten. Null Erkenntnisgewinn. Null Fortschritt.
Mein Rat: Nimm dir mal jemanden direkt am Gerät zur Seite, der sich ein ganz klein wenig mit Linux auskennt und sich nicht von Schauergeschichten ablenken lässt. Er/Sie würde wohl schauen, was an Filesystemen von welchen Geräten in Verwendung ist, die Updaterei testen und - falls tatsächlich was geändert wurde und tatsächlich einen Reboot nicht überlebt - dem Speichermedium mit manuellen Schreibtests(schreiben via Filesystem, sync, cache flush, Lesetest) ganz gezielt auf den Zahl fühlen.
Mein Rat: Nimm dir mal jemanden direkt am Gerät zur Seite, der sich ein ganz klein wenig mit Linux auskennt und sich nicht von Schauergeschichten ablenken lässt. Er/Sie würde wohl schauen, was an Filesystemen von welchen Geräten in Verwendung ist, die Updaterei testen und - falls tatsächlich was geändert wurde und tatsächlich einen Reboot nicht überlebt - dem Speichermedium mit manuellen Schreibtests(schreiben via Filesystem, sync, cache flush, Lesetest) ganz gezielt auf den Zahl fühlen.
Es ist sicherlich eine gute Idee einen minimal erfahrenen User direkt an mein System zu lassen, um heraus zu bekommen, woran es liegt, dass ich die SD-Card, auf der das BS bis zur Installation von pihole sauber funktioniert hat, nicht neu formatieren kann bzw. sich das BS nicht aktualisieren lässt. Meine o.g. Infos sind, bis auf die Umlaute, unmodifizierte Screenshots.
Meine Anfrage lautet einfach, was kann ich ändern, dass ich die SD-Card wieder wie gewöhnlich nutzen kann. Sicherlich ist es, bei den Preisen der Speichermedien, am einfachsten das System neu aufzusetzen, doch hatte ich mir Rat von erfahrenen User versprochen, die mir erklären können, warum bei einem df "mmcblk0p2" nicht angezeigt wird und bei einem lsblk in der Notation ein anderes führendes Symbol angezeigt wird
|-mmcblk0p2 179:2 0 60G 0 part /
als bei den übrigen Devices.
`-mmcblk0p1 179:1 0 63M 0 part /boot
Lassen wir es, der Neukauf und die Neuinstallation verlaufen stressfreier
Meine Anfrage lautet einfach, was kann ich ändern, dass ich die SD-Card wieder wie gewöhnlich nutzen kann. Sicherlich ist es, bei den Preisen der Speichermedien, am einfachsten das System neu aufzusetzen, doch hatte ich mir Rat von erfahrenen User versprochen, die mir erklären können, warum bei einem df "mmcblk0p2" nicht angezeigt wird und bei einem lsblk in der Notation ein anderes führendes Symbol angezeigt wird
|-mmcblk0p2 179:2 0 60G 0 part /
als bei den übrigen Devices.
`-mmcblk0p1 179:1 0 63M 0 part /boot
Lassen wir es, der Neukauf und die Neuinstallation verlaufen stressfreier
Also Du vermischst hier verschiedene Sachen. 1. In der Partition mmcblk0p2 ist Dein Filesystem, welches man auch nicht unmounted, weil es zum Betrieb gebraucht wird, ist so wie bei einem fahrendem Auto den Zündschlüssel abzuziehen. 2. fsck kann nicht bei einem laufenden Filesystem angewendet werden, so wie ich gelesen habe führt man es zum Boot aus. 3. df und lsblk zeigen unterschiedliche Sachen an, mehr dazu findest du mit man heraus, einfach vor den entsprechenden Befehl stellen. Der Prefix beim output von lsblk ist Teil eines (Datei)baums welcher die Zugehörigkeit darstellt, so gehören die Partionen mmcblk0p1 und mmcblk0p2 zu der SD-Karte mmcblk0. 4. Was ich soweit gesehen habe sieht für mich normal aus, Du schreibst ja auch das normal funktioniert. Abstürtze durch Stromverlust sind beim Raspy normal, sollte kein Problem sein. Ich denke, Dein eigentliches Problem ist das die Updates nicht gehen.
Twostone
Rear Admiral
- Registriert
- Dez. 2013
- Beiträge
- 5.128
nobbs11 schrieb:
Das wiederum klingt für mich nach Verwendung eines overlayFS, Änderungen im FS werden nur im RAM gespeichert und der Commit beim herunterfahren bleibt aus.
Man kann natürlich auf diese Weise wunderbar die SD-Karte schonen, man muß eben nur in regelmäßigen Abständen tatsächlich mal die Änderungen auf's zu Grunde liegende Dateisystem zurückschreiben, sonst sind sie bei einem reboot oder einem Wegfall der Spannungsversorgung verloren.
Wie sieht denn Deine fstab aus? Hast Du udev-Regeln, die da mit reinfunken?
Hier meine fstab:
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
UUID=0F4C-7EE1 /media/nobstick/ vfat utf8,uid=pi,gid=pi,noatime 0
udev Regeln, die ich selbst erstellt hätte, sind mir unbekannt.
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
UUID=0F4C-7EE1 /media/nobstick/ vfat utf8,uid=pi,gid=pi,noatime 0
udev Regeln, die ich selbst erstellt hätte, sind mir unbekannt.
