Herr_Krolik
16.10.08, 20:56
Liebe Forumsmitglieder!
Nach dem Tod eines alten Notebooks (Motherboard war unwiederbringlich kaputtgegangen) wurde ein neues Laptop gekauft, auf dem jetzt ein Dualboot-System (mit Vista und Ubuntu 8.04) angelegt ist. Die kleine 2,5 Zoll Festplatte von dem alten NB scheint trotz allen Befürchtungen gerettet zu sein und kann (mittels IDE/USB-Adapter) unter Linux gemountet werden. Um die alten Daten von der NTFS-Partition (/dev/sdc1) sauber zu retten, habe ich nun wie folgt gehandelt:
1. Die gemounteten Partitionen der alten Festplatte Sicherheitshalber aushängen
myname@SARTAN:~$ df | grep sdc
/dev/sdc1 5118088 4607809 510279 91% /media/disk
/dev/sdc4 2217480 1275920 828916 61% /media/disk-1
/dev/sdc3 2267924 1769252 498672 79% /media/disk-2
myname@SARTAN:~$ sudo umount /dev/sdc1
[sudo] password for myname:
myname@SARTAN:~$ sudo umount /dev/sdc3
myname@SARTAN:~$ sudo umount /dev/sdc4
2. Entsprechend dem Artikel http://groups.google.de/group/ch.comp.os.linux/msg/29977f6f8bc994c3
myname@SARTAN:~$ ls -l /dev/sd
sda sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sdc sdc1 sdc2 sdc3 sdc4
myname@SARTAN:~$ sudo dd if=/dev/sdc1 bs=512 conv=noerror,sync | gzip -1 > /home/myname/Bilder/PRINZESSIN_sdb1.gz
dd: Lesen von „/dev/sdc1“: Input/output error
2912+0 Datensätze ein
2912+0 Datensätze aus
1490944 Bytes (1,5 MB) kopiert, 5,40569 s, 276 kB/s
...
1555456 Bytes (1,6 MB) kopiert, 84,0148 s, 18,5 kB/s
dd: Lesen von „/dev/sdc1“: Input/output error
2912+127 Datensätze ein
3039+0 Datensätze aus
1555968 Bytes (1,6 MB) kopiert, 84,0148 s, 18,5 kB/s
10236049+128 Datensätze ein
10236177+0 Datensätze aus
5240922624 Bytes (5,2 GB) kopiert, 1706,97 s, 3,1 MB/s
3. Image wird auf die große Partition der neuen Festplatte (/dev/sda8) entpackt und gemountet
myname@SARTAN:~$ gzip -cd Bilder/PRINZESSIN_sdb1.gz > /media/Common/PRINZESSIN_sdb1
myname@SARTAN:~$ sudo mount -o loop /media/Common/PRINZESSIN_sdb1 /media/sdb1
[sudo] password for myname:
myname@SARTAN:~$ mount | grep 512
/dev/sdc1 on /media/disk type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=512)
/dev/loop1 on /media/sdb1 type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=512)
4. Inhalt eines Dateiverzeichnisses im Image ("Eigene Dateien") wird zu Testzwecken gelesen
myname@SARTAN:~$ ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/ | grep Dateien
drwxrwxrwx 1 root root 45056 2008-06-30 12:56 Eigene Dateien
myname@SARTAN:~$ ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
ls: lese Verzeichnis /media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/: Input/output error
insgesamt 0
5. Inhalt desselben Dateiverzeichnisses der alten Festplatte lässt sich aber problemlos auf das Terminal ausgeben
myname@SARTAN:~$ ls -l /media/disk/Dokumente\ und\ Einstellungen/Sergej/ | grep Dateien
drwxrwxrwx 1 root root 45056 2008-06-30 12:56 Eigene Dateien
myname@SARTAN:~$ ls -l /media/disk/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
insgesamt 2123
-rwxrwxrwx 2 root root 10164 2003-04-20 15:16 AGB_WEB.Cent.txt
-rwxrwxrwx 2 root root 12219 2003-04-20 15:05 AGB_WEB.DE.txt
....
-rwxrwxrwx 2 root root 663 2006-11-30 00:46 ZIPDaten_LinuxPartition.txt
6. Mit Hilfe von strace wird nun versucht die Gründe des ls-Absturzes zu erforschen
myname@SARTAN:~$ strace ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
execve("/bin/ls", ["ls", "-l", "/media/sdb1/Dokumente und Einste"...], [/* 34 vars */]) = 0
brk(0) = 0x805f000
...
lstat64("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
lgetxattr("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", "security.selinux", 0x8068b20, 255) = -1 EOPNOTSUPP (Operation not supported)
getxattr("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
...
open("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8000 0) = 3
fstat64(3, {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents64(3, 0x806a860, 512) = -1 EIO (Input/output error)
Trotz den durchgeführten Schritten bleibt mir unklar, wieso der ls-Befehl abstürzt, wenn er auf das Image zugreift, tut es aber nicht, wenn er auf die Originalpartition (auf die alte Festplatte unmittelbar) zugreift? Kommt es auf die Existenz der geschädigten Blöcke in dieser NTFS-Partition oder auf die schlauen Permission bits des getesteten Dateiverzeichnisses an?
Die alte Festplatte wurde schon auch mal unter MS Vista über die USB-Schnittstelle angehängt und mit der Utility chkdsk getestet, welches ausspuckte: "Das Dateisystem wurde überprüft. Es wurden keine Probleme festgestellt."
Für weitere Kommentare und Ratschläge (http://forum.ubuntuusers.de/topic/image-einer-ntfs-partition-verhaelt-sich-ande/) bin ich im voraus sehr dankbar.
Nach dem Tod eines alten Notebooks (Motherboard war unwiederbringlich kaputtgegangen) wurde ein neues Laptop gekauft, auf dem jetzt ein Dualboot-System (mit Vista und Ubuntu 8.04) angelegt ist. Die kleine 2,5 Zoll Festplatte von dem alten NB scheint trotz allen Befürchtungen gerettet zu sein und kann (mittels IDE/USB-Adapter) unter Linux gemountet werden. Um die alten Daten von der NTFS-Partition (/dev/sdc1) sauber zu retten, habe ich nun wie folgt gehandelt:
1. Die gemounteten Partitionen der alten Festplatte Sicherheitshalber aushängen
myname@SARTAN:~$ df | grep sdc
/dev/sdc1 5118088 4607809 510279 91% /media/disk
/dev/sdc4 2217480 1275920 828916 61% /media/disk-1
/dev/sdc3 2267924 1769252 498672 79% /media/disk-2
myname@SARTAN:~$ sudo umount /dev/sdc1
[sudo] password for myname:
myname@SARTAN:~$ sudo umount /dev/sdc3
myname@SARTAN:~$ sudo umount /dev/sdc4
2. Entsprechend dem Artikel http://groups.google.de/group/ch.comp.os.linux/msg/29977f6f8bc994c3
myname@SARTAN:~$ ls -l /dev/sd
sda sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sdc sdc1 sdc2 sdc3 sdc4
myname@SARTAN:~$ sudo dd if=/dev/sdc1 bs=512 conv=noerror,sync | gzip -1 > /home/myname/Bilder/PRINZESSIN_sdb1.gz
dd: Lesen von „/dev/sdc1“: Input/output error
2912+0 Datensätze ein
2912+0 Datensätze aus
1490944 Bytes (1,5 MB) kopiert, 5,40569 s, 276 kB/s
...
1555456 Bytes (1,6 MB) kopiert, 84,0148 s, 18,5 kB/s
dd: Lesen von „/dev/sdc1“: Input/output error
2912+127 Datensätze ein
3039+0 Datensätze aus
1555968 Bytes (1,6 MB) kopiert, 84,0148 s, 18,5 kB/s
10236049+128 Datensätze ein
10236177+0 Datensätze aus
5240922624 Bytes (5,2 GB) kopiert, 1706,97 s, 3,1 MB/s
3. Image wird auf die große Partition der neuen Festplatte (/dev/sda8) entpackt und gemountet
myname@SARTAN:~$ gzip -cd Bilder/PRINZESSIN_sdb1.gz > /media/Common/PRINZESSIN_sdb1
myname@SARTAN:~$ sudo mount -o loop /media/Common/PRINZESSIN_sdb1 /media/sdb1
[sudo] password for myname:
myname@SARTAN:~$ mount | grep 512
/dev/sdc1 on /media/disk type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=512)
/dev/loop1 on /media/sdb1 type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=512)
4. Inhalt eines Dateiverzeichnisses im Image ("Eigene Dateien") wird zu Testzwecken gelesen
myname@SARTAN:~$ ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/ | grep Dateien
drwxrwxrwx 1 root root 45056 2008-06-30 12:56 Eigene Dateien
myname@SARTAN:~$ ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
ls: lese Verzeichnis /media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/: Input/output error
insgesamt 0
5. Inhalt desselben Dateiverzeichnisses der alten Festplatte lässt sich aber problemlos auf das Terminal ausgeben
myname@SARTAN:~$ ls -l /media/disk/Dokumente\ und\ Einstellungen/Sergej/ | grep Dateien
drwxrwxrwx 1 root root 45056 2008-06-30 12:56 Eigene Dateien
myname@SARTAN:~$ ls -l /media/disk/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
insgesamt 2123
-rwxrwxrwx 2 root root 10164 2003-04-20 15:16 AGB_WEB.Cent.txt
-rwxrwxrwx 2 root root 12219 2003-04-20 15:05 AGB_WEB.DE.txt
....
-rwxrwxrwx 2 root root 663 2006-11-30 00:46 ZIPDaten_LinuxPartition.txt
6. Mit Hilfe von strace wird nun versucht die Gründe des ls-Absturzes zu erforschen
myname@SARTAN:~$ strace ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
execve("/bin/ls", ["ls", "-l", "/media/sdb1/Dokumente und Einste"...], [/* 34 vars */]) = 0
brk(0) = 0x805f000
...
lstat64("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
lgetxattr("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", "security.selinux", 0x8068b20, 255) = -1 EOPNOTSUPP (Operation not supported)
getxattr("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
...
open("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8000 0) = 3
fstat64(3, {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents64(3, 0x806a860, 512) = -1 EIO (Input/output error)
Trotz den durchgeführten Schritten bleibt mir unklar, wieso der ls-Befehl abstürzt, wenn er auf das Image zugreift, tut es aber nicht, wenn er auf die Originalpartition (auf die alte Festplatte unmittelbar) zugreift? Kommt es auf die Existenz der geschädigten Blöcke in dieser NTFS-Partition oder auf die schlauen Permission bits des getesteten Dateiverzeichnisses an?
Die alte Festplatte wurde schon auch mal unter MS Vista über die USB-Schnittstelle angehängt und mit der Utility chkdsk getestet, welches ausspuckte: "Das Dateisystem wurde überprüft. Es wurden keine Probleme festgestellt."
Für weitere Kommentare und Ratschläge (http://forum.ubuntuusers.de/topic/image-einer-ntfs-partition-verhaelt-sich-ande/) bin ich im voraus sehr dankbar.