[gelöst] XFS-Partition vom Strom getrennt, Sicherung auf gleicher Festplatte

ffsepp

User

Beiträge: 8

Registrierungsdatum: 07.03.2014

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

1

08.03.2014, 19:56

XFS-Partition vom Strom getrennt, Sicherung auf gleicher Festplatte

Hallo,

erstmal vielen Dank für die ganzen Posts hier:

[gelöst] Probleme mit XFS Dateisystem

Das
hat mich schon ein großes Stück weiter gebracht. Grundsätzlich habe ich
ein sehr ähnliches Problem wie der dortige OP, meine Festplatte mit xfs wurde
nicht richtig ausgehängt und wird nun nicht mehr recht erkannt. Mir wurde dort geschrieben, ich solle lieber einen neuen Thread für mein Problem aufmachen.

Ich habe per ddrescue auch eine Sicherung erstellt, diese dann wie in den Posts beschrieben (nochmal vielen Dank hierfür) eingehängt:

Quellcode

sudo losetup /dev/loop0 /media/sepp/Archiv/sicherung.dd 
sudo file -s /dev/loop0
/dev/loop0: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
sudo xfs_repair /dev/loop0
Phase 1 - Superblock finden und überprüfen...
Phase 2 - ein internes Protokoll benutzen
    	- Null-Protokoll...
FEHLER: Das Dateisystem hat wertvolle Metadaten-Änderungen in einem
Protokoll, das wiederholt werden sollte. Hängen Sie das Dateisystem ein,
um das Protokoll zu wiederholen und hängen Sie es wieder aus um
xfs_repair erneut auszuführen. Wenn Sie außer Stande sind, das
Dateisystem einzuhängen, benutzen Sie die -L-Option um das Protokoll zu
zerstören und versuchen Sie eine Reparatur.
Beachten Sie, dass die Zerstörung des Protokolls Schaden verursachen
kann -- bitte versuchen sie das Dateisystem einzuhängen ehe Sie dies tun.

Dementsprechend hab ich dann auch die -L Option benutzt. Das sah bei mir dann aber nicht so schön wie beim OP aus:

Quellcode

sudo xfs_repair -L /dev/loop0
Phase 1 - Superblock finden und überprüfen...
Phase 2 - ein internes Protokoll benutzen
- Null-Protokoll...
ALARM: Das Dateisystem hat wertvolle Metadaten-Änderungen in einem
Protokoll, das zerstört wird, weil die -L-Option benutzt wird.
- freier Speicher und Inode-Karten des Dateisystems werden
gescannt...
sb_ifree 23, counted 22
- Wurzel-Inode-Stück gefunden
Phase 3 - für jedes AG...
- agi unverknüpfte Listen werden gescannt und bereinigt...
- bekannte Inodes werden behandelt und Inode-Entdeckung wird
durchgeführt...
- agno = 0
correcting nblocks for inode 43327169, was 577 - counted 562
correcting nblocks for inode 43327170, was 796795 - counted 797168
imap claims a free inode 43327177 is in use, imap wird korrigiert und Inode bereinigt
cleared inode 43327177
imap claims a free inode 61153390 is in use, imap wird korrigiert und Inode bereinigt
cleared inode 61153390
- agno = 1
- agno = 2
- agno = 3
- neu entdeckte Inodes werden behandelt...
Phase 4 - auf doppelte Blöcke überprüfen...
- Liste mit doppeltem Ausmaß wird eingerichtet...
- es wird geprüft ob Inodes Blocks doppelt beanspruchen...
- agno = 0
- agno = 2
- agno = 1
- agno = 3
entry "20130518181407.mta" at block 1 offset 3376 in directory inode 133 references frei inode 61153390
clearing inode number in entry at offset 3376...
entry "20140207214029.mta" at block 3 offset 4016 in directory inode 133 references frei inode 43327177
clearing inode number in entry at offset 4016...
Phase 5 - AG-Köpfe und Bäume werden erneut gebildet...
- Superblock wird zurückgesetzt...
Phase 6 - Inode-Verbindbarkeit wird geprüft...
- Inhalte der Echtzeit-Bitmaps und Zusammenfassungs-Inodes werden zurückgesetzt
- Dateisystem wird durchquert ...
entry "20130518181407.mta" (ino 76428237) in dir 133 is a duplicate name
entry "20130518181407.mta" (ino 76428243) in dir 133 is a duplicate name
entry "20130518181407.mta" (ino 76428269) in dir 133 is a duplicate name
entry "20130518181407.mta" (ino 76428280) in dir 133 is a duplicate name
entry "20140207214029.mta" (ino 4871) in dir 133 is a duplicate name
entry "20140207214029.mta" (ino 4872) in dir 133 is a duplicate name
entry "20140207214029.mta" (ino 4913) in dir 133 is a duplicate name
entry "20140207214029.mta" (ino 4919) in dir 133 is a duplicate name
rebuilding directory inode 133
- durchqueren beendet ...
- nicht verbundene Inodes werden nach lost+found verschoben ...
disconnected inode 4871, gehe zu lost+found
disconnected inode 4872, gehe zu lost+found
disconnected inode 4913, gehe zu lost+found
disconnected inode 4919, gehe zu lost+found
disconnected inode 76428237, gehe zu lost+found
disconnected inode 76428243, gehe zu lost+found
disconnected inode 76428269, gehe zu lost+found
disconnected inode 76428280, gehe zu lost+found
Phase 7 - Verweisanzahl wird geprüft und berichtigt...
erledigt

Wenn ich nun die weiteren Schritte auszuführen versuche, bekomme ich

Quellcode

sudo xfs_check /dev/loop0
sudo mount -o loop,ro /media/sepp/Archiv/sicherung.dd /home/sepp/xfs
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
   	missing codepage or helper program, or other error
   	Manchmal liefert das Syslog wertvolle Informationen – versuchen
   	Sie  dmesg | tail  oder so

Ich bekomme das System also leider nicht mehr gemountet. Gibt es noch irgendwelche Chancen, die Daten doch noch zu retten? Vielen Dank für alle Hilfe!

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »ffsepp« (11.03.2014, 20:00) aus folgendem Grund: Präzisierung des Problems in Anbetracht der Lösung

Zum Seitenanfang

floogy

User

Beiträge: 3 071

Registrierungsdatum: 10.03.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: debian

2

09.03.2014, 10:37

Zitat von »ffsepp«

sudo xfs_check /dev/loop0
sudo mount -o loop,ro /media/sepp/Archiv/sicherung.dd /home/sepp/xfs
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
Manchmal liefert das Syslog wertvolle Informationen – versuchen
Sie dmesg | tail oder so

Versuch mal:

	Quellcode
1 2 3	sudo mount -o loop,ro /media/sepp/Archiv/sicherung.dd /home/sepp/xfs dmesg\|tail sudo mount -t xfs -o loop,ro /media/sepp/Archiv/sicherung.dd /home/sepp/xfs

Edit: Die Lösung dürfte eher in der Art wie Du losetup verwendet hast liegen, das ist bei Images aus Partitionen nicht nötig, nur bei Images ganzer partitionierter Festplatten.
Der mount-Befehl funktioniert so nicht, da er auf /dev/loop0 zugreift, losetup aber /dev/loop1 eingerichtet hat.

	Quellcode
1	sudo mount -t xfs -o ro /dev/loop1 /home/sepp/xfs

oder

	Quellcode
1 2	sudo umount /home/sepp/xfs sudo mount -o loop,ro /media/sepp/Archiv/sicherung.dd /home/sepp/xfs

sollten aber gehen.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »floogy« (09.03.2014, 12:28)

Zum Seitenanfang

ffsepp

User

Beiträge: 8

Registrierungsdatum: 07.03.2014

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

3

10.03.2014, 20:15

Vielen Dank für die Hinweise. Ich glaube, die Funktionsweise von losetup war/ist mir nicht so ganz klar.

Ich habe mal nach dem Edit angefangen zu probieren:

	Quellcode
1 2	sudo mount -t xfs -o ro /dev/loop1 /home/sepp/xfs mount: /dev/loop1: Konnte den Superblock nicht lesen

Dann dort die zweite Variante:

Quellcode

sudo umount /home/sepp/xfs
umount: /home/sepp/xfs ist nicht eingehängt
sudo mount -o loop,ro /media/sepp/Archiv/sicherung.dd /home/sepp/xfs
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
   	missing codepage or helper program, or other error
   	Manchmal liefert das Syslog wertvolle Informationen – versuchen
   	Sie  dmesg | tail  oder so

Also ungefähr das, was vorher war.

Ich habe noch mal den ersten Befehl mit dmsg|tail ausgeführt:

Quellcode

sudo mount -t xfs -o ro /dev/loop1 /home/sepp/xfs
mount: /dev/loop1: Konnte den Superblock nicht lesen
dmesg|tail
[22935.086755]  [<ffffffffa067a480>] ? xfs_parseargs+0xc10/0xc10 [xfs]
[22935.086788]  [<ffffffffa0678a95>] xfs_fs_mount+0x15/0x20 [xfs]
[22935.086794]  [<ffffffff811abdf9>] mount_fs+0x39/0x1b0
[22935.086801]  [<ffffffff811c5b97>] ? alloc_vfsmnt+0xd7/0x1b0
[22935.086807]  [<ffffffff811c5d17>] vfs_kern_mount+0x67/0x100
[22935.086814]  [<ffffffff811c825e>] do_mount+0x23e/0xa20
[22935.086823]  [<ffffffff8115a2eb>] ? strndup_user+0x4b/0xf0
[22935.086829]  [<ffffffff811c8ac3>] SyS_mount+0x83/0xc0
[22935.086838]  [<ffffffff816f74dd>] system_call_fastpath+0x1a/0x1f
[22951.130916] XFS (loop1): SB validate failed with error 5.

Dann habe ich noch mal per losetup das alles ausgehängt und wieder eingehängt, xfs_repair -L und xfs_check durchgeführt. Dann bekomme ich:

Quellcode

sudo mount -o ro /dev/loop1 /home/sepp/xfs
mount: /dev/loop1: Konnte den Superblock nicht lesen
dmesg | tail
[23535.456866]  [<ffffffff8115a2eb>] ? strndup_user+0x4b/0xf0
[23535.456874]  [<ffffffff811c8ac3>] SyS_mount+0x83/0xc0
[23535.456885]  [<ffffffff816f74dd>] system_call_fastpath+0x1a/0x1f
[23561.748804] XFS (loop0): Filesystem has duplicate UUID f4efad37-b93d-4d09-ace0-fdcdaf44796c - can't mount
[23570.012286] EXT3-fs (loop1): error: unable to read superblock
[23570.012354] EXT4-fs (loop1): unable to read superblock
[23570.012393] FAT-fs (loop1): unable to read boot sector
[23586.734952] EXT3-fs (loop1): error: unable to read superblock
[23586.735032] EXT4-fs (loop1): unable to read superblock
[23586.735072] FAT-fs (loop1): unable to read boot sector

Schließlich mit losetup -d /dev/loop1 noch mal ausgehängt und dann

Quellcode

sudo mount -t xfs -o ro,loop /media/sepp/Archiv/sicherung.dd /home/sepp/xfs
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
   	missing codepage or helper program, or other error
   	Manchmal liefert das Syslog wertvolle Informationen – versuchen
   	Sie  dmesg | tail  oder so

sudo mount -t xfs -o loop,ro /media/sepp/Archiv/sicherung.dd /home/sepp/xfs
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
   	missing codepage or helper program, or other error
   	Manchmal liefert das Syslog wertvolle Informationen – versuchen
   	Sie  dmesg | tail  oder so

dmesg | tail
[23655.530693]  [<ffffffff811c5d17>] vfs_kern_mount+0x67/0x100
[23655.530697]  [<ffffffff811c825e>] do_mount+0x23e/0xa20
[23655.530702]  [<ffffffff8115a2eb>] ? strndup_user+0x4b/0xf0
[23655.530706]  [<ffffffff811c8ac3>] SyS_mount+0x83/0xc0
[23655.530712]  [<ffffffff816f74dd>] system_call_fastpath+0x1a/0x1f
[23762.410237] EXT3-fs (loop1): error: unable to read superblock
[23762.410370] EXT4-fs (loop1): unable to read superblock
[23762.410462] FAT-fs (loop1): unable to read boot sector
[23786.678226] XFS (loop0): Filesystem has duplicate UUID f4efad37-b93d-4d09-ace0-fdcdaf44796c - can't mount
[23796.774011] XFS (loop0): Filesystem has duplicate UUID f4efad37-b93d-4d09-ace0-fdcdaf44796c - can't mount

Hoffe, das war jetzt nicht zu verwirrend...

Zum Seitenanfang

floogy

User

Beiträge: 3 071

Registrierungsdatum: 10.03.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: debian

4

10.03.2014, 20:55

Quellcode

1
2

[23786.678226] XFS (loop0): Filesystem has duplicate UUID f4efad37-b93d-4d09-ace0-fdcdaf44796c - can't mount
[23796.774011] XFS (loop0): Filesystem has duplicate UUID f4efad37-b93d-4d09-ace0-fdcdaf44796c - can't mount

Gut dass Du selbst auf losetup -d zum Aushängen gekommen bist. umount reicht da natürlich nicht

(und schon garnicht, wenn nix gemountet ist

) Was sagt denn:

	Quellcode
1	sudo blkid

Zum Seitenanfang

ffsepp

User

Beiträge: 8

Registrierungsdatum: 07.03.2014

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

5

10.03.2014, 21:17

Quellcode

/dev/sda5: UUID="e3e811cd-6af8-425a-a215-03422056a33f" TYPE="crypto_LUKS" 
/dev/sda1: UUID="45c0db99-4901-4b5a-ab1c-3b9c9de0e147" TYPE="ext2" 
/dev/mapper/sda5_crypt: UUID="Cc8swL-RNW3-Krzq-FWXX-pmRD-7nzF-wEJlc8" TYPE="LVM2_member" 
/dev/mapper/ubuntu--vg-root: UUID="8c5f52a5-4bbb-46cf-993e-8e02c7039bd0" TYPE="ext4" 
/dev/mapper/ubuntu--vg-swap_1: UUID="ae86489d-31f2-4c11-9fba-4f02e654c88a" TYPE="swap" 
/dev/sdb1: LABEL="Aufnahmen" UUID="f4efad37-b93d-4d09-ace0-fdcdaf44796c" TYPE="xfs" 
/dev/sdb2: LABEL="Archiv" UUID="02FB2A7F15954A23" TYPE="ntfs"

sda müsste meine (teilweise verschlüsseltes) Systemplatte sein. /dev/sdb1 ist die Partition auf der externen Platte, die mir kaputt gegangen ist, /dev/sdb2 die Partition (auf der gleichen externen Platte) auf der sich die Sicherung befindet. Kann es vielleicht sein, dass da irgendetwas durch das mehrfache mounten und so kaputt gegangen ist und ich den Rechner mal komplett neu starten sollte?

Zum Seitenanfang

floogy

User

Beiträge: 3 071

Registrierungsdatum: 10.03.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: debian

6

10.03.2014, 21:25

Versuche bitte mal die Festplatte mit dem xfs auszuhängen:

	Quellcode
1	sudo umount $(mount \| grep '/dev/sdb1'\|cut -d' ' -f3)

Danach könnte es klappen das reparierte Image per -o loop zu mounten, ansonsten müsstest Du vorübergehend die Platte mit dem xfs abklemmen.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »floogy« (10.03.2014, 21:33)

Zum Seitenanfang

ffsepp

User

Beiträge: 8

Registrierungsdatum: 07.03.2014

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

7

10.03.2014, 21:44

Ah, verstehe das Problem...

Quellcode

sepp@sepp-laptop:~$ sudo umount $(mount | grep  '/dev/sdb1'|cut -d' ' -f3)
Usage: umount -h | -V
   	umount -a [-d] [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]
   	umount [-d] [-f] [-r] [-n] [-v] special | node...
sepp@sepp-laptop:~$ sudo umount $(blkid | grep  '/dev/sdb1'|cut -d' ' -f3)
umount: UUID="f4efad37-b93d-4d09-ace0-fdcdaf44796c": Nicht gefunden
sepp@sepp-laptop:~$ umount UUID="f4efad37-b93d-4d09-ace0-fdcdaf44796c"
umount: UUID=f4efad37-b93d-4d09-ace0-fdcdaf44796c ist laut „mtab“ nicht eingehängt
sepp@sepp-laptop:~$ sudo mount -o loop /media/sepp/Archiv/sicherung.dd /home/sepp/xfs
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
   	missing codepage or helper program, or other error
   	Manchmal liefert das Syslog wertvolle Informationen – versuchen
   	Sie  dmesg | tail  oder so

sepp@sepp-laptop:~$ dmesg | tail
[   44.564163]  [<ffffffff811c5bb7>] ? alloc_vfsmnt+0xd7/0x1b0
[   44.564165]  [<ffffffff811c5d37>] vfs_kern_mount+0x67/0x100
[   44.564168]  [<ffffffff811c827e>] do_mount+0x23e/0xa20
[   44.564172]  [<ffffffff8115a30b>] ? strndup_user+0x4b/0xf0
[   44.564174]  [<ffffffff811c8ae3>] SyS_mount+0x83/0xc0
[   44.564178]  [<ffffffff816f841d>] system_call_fastpath+0x1a/0x1f
[   44.564188] XFS (sdb1): Failed to recover EFIs
[   44.564190] XFS (sdb1): log mount finish failed
[  118.749963] XFS (loop0): Filesystem has duplicate UUID f4efad37-b93d-4d09-ace0-fdcdaf44796c - can't mount

Dann werde ich mir wohl erst mal eine andere Platte besorgen müssen, habe gerade keine da, die eine 500 GB Partition aufnehmen kann. Aber vielen vielen Dank bis hier hin erst mal. Sobald ich eine neue Platte habe, werde ich mich nochmal zurück melden... ...gegebenenfalls um den Thread als Gelöst zu markieren.

Zum Seitenanfang

ffsepp

User

Beiträge: 8

Registrierungsdatum: 07.03.2014

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

8

10.03.2014, 21:58

Habe gerade festgestellt, dass man ja auch die UUID von Partitionsbackups ändern kann. Dann ging alles und ich konnte wieder auf die Daten zugreifen.

Der Vollständigkeit halber, hier der Weg dahin:

Quellcode

sepp@sepp-laptop:~$ uuidgen 
fe30d715-576a-475a-acb3-0b57d0d2af49
sepp@sepp-laptop:~$ sudo losetup -f /media/sepp/Archiv/sicherung.dd 
sepp@sepp-laptop:~$ sudo xfs_admin -U fe30d715-576a-475a-acb3-0b57d0d2af49 /dev/loop0
Protokoll wird geleert und UUID gesetzt
Schreiben aller SBs
neue UUID = fe30d715-576a-475a-acb3-0b57d0d2af49
sepp@sepp-laptop:~$ sudo losetup -d /dev/loop0
sepp@sepp-laptop:~$ sudo mount -o loop /media/sepp/Archiv/sicherung.dd /home/sepp/xfs

Alle Dateien haben nun Unix-Zeit 0 (1970) aber zumindest kann ich erstmal wieder auf sie zugreifen. Werde mal schauen, ob ich die Aufnahmen nun auch wiederherstellen kann...

Zum Seitenanfang

floogy

User

Beiträge: 3 071

Registrierungsdatum: 10.03.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: debian

9

10.03.2014, 22:01

Gratuliere!

Zitat von »ffsepp«

Alle Dateien haben nun Unix-Zeit 0 (1970)

Das kommt durch den Metadatenverlust der Option -L, vor dem immer gewarnt wird. Oft gibt es aber keine andere Lösung.

Zitat

Aufnahmen nun auch wiederherstellen kann...

Man könnte per Skript mit touch und exiftool das Datum unter Umständen wiederherstellen! Im EXIF-Header der Bilddaten sollte das Aufnahmedatum vorhanden sein.

	Quellcode
1	exiftool /pfad/zu/image.ext

	Quellcode
1	disconnected inode 4871, gehe zu lost+found

	Quellcode
1	ls /mnt/lost+found

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »floogy« (10.03.2014, 22:06)

Zum Seitenanfang

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

10

10.03.2014, 22:35

Gefällt mir

Also lag es daran, daß beim loop-mount die defekte Partition mit logischerweise gleicher UUID auch noch da war. Das war bei DocHifi natürlich nicht der Fall.
Seltsam sind trotzdem die XFS-Fehler, die vor der Beschwerde über die doppelte UUID kamen. Ob sich XFS da von udev abtäuschen lässt und über die UUID auf die falsche (sprich die kaputte) Partition zugreift? Bei XFS arbeitet mount ja nicht selbst, sondern mit einem Helfer.

Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.

me is all sausage
but don't call me Ferdl

Zum Seitenanfang

floogy

User

Beiträge: 3 071

Registrierungsdatum: 10.03.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: debian

11

10.03.2014, 22:48

Ich denke, da war dann ein Gerät ohne xfs Dateisystem am Wickel.

Zum Seitenanfang

ffsepp

User

Beiträge: 8

Registrierungsdatum: 07.03.2014

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

12

11.03.2014, 19:58

Habe nun die Platte am Fernseher formatiert und die Daten wieder überspielt. Funktioniert alles bestens, eine einzige Aufnahme war kaputt, aber das ist nicht weiter wild. Die Sache mit dem falschen Datum ist auch egal, das Samsung-Gerät greift anscheinend ohnehin nur auf Metadaten zu, in meiner Aufnahmenübersicht stimmt jedenfalls alles (:

Nochmal ein großes Dankeschön für alle Ratschläge in diesem und in dem anderen Thread und ganz besonders für die schnellen Antworten, da ist ja mancher Chat langsamer (;