Hallo Liste,
hier kommt mal ein etwas kniffligeres Problem. Ich habe hier eine 2 GB Festplatte liegen (mit ungesicherten Dateien), welche unter Windows urplötzlich anfing einzelne Dateien zu verunstalten (kein Kopieren, öffnen usw möglich). Also habe ich die ausgebaut und versucht mit Linux zu mounten. Das ging prompt schief.
# mount -t vfat -o ro /dev/hdc1 /windows mount: Falscher Dateisystemtyp, ungültige Optionen, der »Superblock« von /dev/hdc1 ist beschädigt oder es sind zu viele Dateisysteme gemountet
# fdisk -l
Festplatte /dev/hdc: 16 Köpfe, 63 Sektoren, 4092 Zylinder Einheiten: Zylinder mit 1008 * 512 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp /dev/hdc1 1 4088 2060320+ b Win95 FAT32 Partition 1 endet nicht an einer Zylindergrenze: phys=(1021, 63, 63) should be (1021, 15, 63) ^^^^^^^^^^^^^ Hier liegt vermutlich das Problem. Doch nun kommt meine Frage: Kriegt man das wieder korrigiert??
Ich habe mit # dd if=/dev/hdc of=dev_hdc_mbr versucht den MBR zu sichern. Darin findet sich genau zweimal der (dezimale) Wert 63. Kann man einfach einen (welchen??) Wert ändern und den MBR zurückkopieren?? Das wäre schön, aber es gibt doch bestimmt einen Haken an der Sache.
Achso es ist eine Seagate Medalist ST321122A 4092 Cyl 16 Heads 63 Sectors mit nur einer Windows Fat32 Partition
Jens
Hallo Jens,
Natuerlich machst Du das folgende auf Deine Gefahr hin...
On Thu, Feb 07, 2002 at 10:41:14PM +0100, Jens Weiße wrote:
Hallo Liste,
[Probleme mit Dateien unter Windows, mounten mit Linux schlaegt fehl]
# fdisk -l
Festplatte /dev/hdc: 16 Köpfe, 63 Sektoren, 4092 Zylinder Einheiten: Zylinder mit 1008 * 512 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp/dev/hdc1 1 4088 2060320+ b Win95 FAT32 Partition 1 endet nicht an einer Zylindergrenze: phys=(1021, 63, 63) should be (1021, 15, 63) ^^^^^^^^^^^^^ Hier liegt vermutlich das Problem. Doch nun kommt meine Frage: Kriegt man das wieder korrigiert??
Koennte auch ein "Geniestreich" von Windows sein. Die Grenzen der Partitionen sind neuerdings auch als Blocknummern noch in der Partitionstabelle eingetragen. Die Zylindernummer kommt mir allerdings komisch vor.
Ich habe mit # dd if=/dev/hdc of=dev_hdc_mbr versucht den MBR zu sichern. Darin findet sich genau zweimal der (dezimale) Wert 63. Kann man einfach einen (welchen??) Wert ändern und den MBR zurückkopieren?? Das wäre schön, aber es gibt doch bestimmt einen Haken an der Sache.
Ich habe gerade keine Doku der Struktur der Partitionstabelle zur Hand, aber die relevanten Daten sind in den Bytes 446-509. Danach kommen noch zwei "magic" Bytes. Solange Du nicht versuchst zu schreiben, ist es relativ ungefaehrlich mit dem MBR zu spielen (auf der nicht-Boot-Platte natuerlich).
Am sichersten ist natuerlich ein Low-Level-Backup der Platte, z.B. mit dd if=/dev/hdc of=datei wenn Du Dir das leisten kannst. gzip ist moeglicherweise einer Deiner Freunde.
Versuche dann mal, mit fdisk die Partition zu loeschen und dann genauso neu anzulegen. Unter Linux wird dabei nur in der Partitionstabelle geschrieben, solange man keine erweiterten Partitionen hat.
Du solltest auch mal das IDE-Interface und die Verkabelung im Zielrechner pruefen, denn selbst fuer Windows ist es ungewoehnlich, nach der Installation in den MBR zu schreiben.
Holger
Hi Holger, Hi Liste
Am Donnerstag, 7. Februar 2002 22:56 schrieb Holger:
Natuerlich machst Du das folgende auf Deine Gefahr hin...
So ein Murks! Nicht mal ein doppelter Boden und keine Schadensersatzforderungen? Ich steh nicht so sehr auf Adrenalin.
# fdisk -l
Festplatte /dev/hdc: 16 Köpfe, 63 Sektoren, 4092 Zylinder Einheiten: Zylinder mit 1008 * 512 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp/dev/hdc1 1 4088 2060320+ b Win95 FAT32 Partition 1 endet nicht an einer Zylindergrenze: phys=(1021, 63, 63) should be (1021, 15, 63) ^^^^^^^^^^^^^ Hier liegt vermutlich das Problem. Doch nun kommt meine Frage: Kriegt man das wieder korrigiert??
Koennte auch ein "Geniestreich" von Windows sein. Die Grenzen der Partitionen sind neuerdings auch als Blocknummern noch in der Partitionstabelle eingetragen. Die Zylindernummer kommt mir allerdings komisch vor.
Vermutlich liegst du richtig. Auf der Platte stehen ja auch 4092 Zylinder. Aber der Korrekturvorschlag scheint dies zu ignorieren.
Ich habe mit # dd if=/dev/hdc of=dev_hdc_mbr versucht den MBR zu sichern. Darin findet sich genau zweimal der (dezimale) Wert 63. Kann man einfach einen (welchen??) Wert ändern und den MBR zurückkopieren?? Das wäre schön, aber es gibt doch bestimmt einen Haken an der Sache.
Ich habe gerade keine Doku der Struktur der Partitionstabelle zur Hand, aber die relevanten Daten sind in den Bytes 446-509. Danach kommen noch zwei "magic" Bytes.
Die beiden relevanten Werte finden sich beim offset 451 und 454 Die Zylinderzahl habe ich nicht gefunden. Das kann aber auch an meinen (Un)Fähigkeiten mit dem Hex-Editor liegen.
Solange Du nicht versuchst zu schreiben, ist es relativ ungefaehrlich mit dem MBR zu spielen (auf der nicht-Boot-Platte natuerlich).
Nee, nee. So weit hab ich das auch schon durchschaut.
Am sichersten ist natuerlich ein Low-Level-Backup der Platte, z.B. mit dd if=/dev/hdc of=datei wenn Du Dir das leisten kannst. gzip ist moeglicherweise einer Deiner Freunde.
Das habe ich schon probiert. Allerdings hängt sich dd auf. Zumindest erreicht die Datei nur eine gewisse Grösse (mit gzip sind das 278 KByte). Danach passiert gar nix mehr. dd lässt sich auch nicht mit sanften Druck (kill -9 pid>) beenden.
Versuche dann mal, mit fdisk die Partition zu loeschen und dann genauso neu anzulegen. Unter Linux wird dabei nur in der Partitionstabelle geschrieben, solange man keine erweiterten Partitionen hat.
Das hebe ich mir für den Schluß auf.
Du solltest auch mal das IDE-Interface und die Verkabelung im Zielrechner pruefen, denn selbst fuer Windows ist es ungewoehnlich, nach der Installation in den MBR zu schreiben.
Vermutlich ist nicht nur Windows daran schuld. Das ist eine Festplatte im Wechselrahmen. Die Kontakte halten dem täglichen Stress anscheinend nicht stand. Aber trotzdem sollte sich der MBR nicht verändern. Nagut, ich werde die Kabel mal durchtesten.
Jens
Hallo Jens,
On Fri, Feb 08, 2002 at 12:17:49AM +0100, Jens Weiße wrote:
Die beiden relevanten Werte finden sich beim offset 451 und 454
Das ist im Bereich fuer die erste Partition.
Die Zylinderzahl habe ich nicht gefunden. Das kann aber auch an meinen (Un)Fähigkeiten mit dem Hex-Editor liegen.
Die Zylinderzahl wird auch in zwei Bytes codiert, moeglicherweise noch ein bissschen verschoben und mit der Kopfnummer zusammengepackt.
Am sichersten ist natuerlich ein Low-Level-Backup der Platte, z.B. mit dd if=/dev/hdc of=datei wenn Du Dir das leisten kannst. gzip ist moeglicherweise einer Deiner Freunde.
Das habe ich schon probiert. Allerdings hängt sich dd auf. Zumindest erreicht die Datei nur eine gewisse Grösse (mit gzip sind das 278 KByte). Danach passiert gar nix mehr. dd lässt sich auch nicht mit sanften Druck (kill -9 pid>) beenden.
Das stinkt gewaltig nach einem Hardware-Problem! Entweder Kabel/Stecker oder die Festplatte selber. Es sollte eigentlich zu dem Thema was im Syslog zu finden sein, wahrscheinlich als timeout.
Du solltest auch mal das IDE-Interface und die Verkabelung im Zielrechner pruefen, denn selbst fuer Windows ist es ungewoehnlich, nach der Installation in den MBR zu schreiben.
Vermutlich ist nicht nur Windows daran schuld. Das ist eine Festplatte im Wechselrahmen. Die Kontakte halten dem täglichen Stress anscheinend nicht stand. Aber trotzdem sollte sich der MBR nicht verändern.
Wenn durch Kontaktschwierigkeiten beim Schreiben eine falsche Sektoradresse an der Festplatte ankommt, kann es schon mal den MBR erwischen.
Holger
Hallo Holger
Am Freitag, 8. Februar 2002 00:33 schrieb Holger:
Das stinkt gewaltig nach einem Hardware-Problem! Entweder Kabel/Stecker oder die Festplatte selber. Es sollte eigentlich zu dem Thema was im Syslog zu finden sein, wahrscheinlich als timeout.
Die Idee mit dem Syslog war gut. Dort finden sich Seitenweise Fehlermeldungen. Hier ein kleiner Auszug (sozusagen das "Best-Of" :-( )
kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } kernel: hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest } kernel: hdc: drive not ready for command kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } kernel: hdc: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=234831627, sector=0 kernel: FAT: bogus logical sector size 0 kernel: VFS: Can't find a valid FAT filesystem on dev 16:01.
kernel: hdc: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } kernel: hdc: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=234831627, sector=0 kernel: ide1: reset: success kernel: hdc: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } kernel: hdc: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=234831627, sector=0 kernel: end_request: I/O error, dev 16:01 (hdc), sector 0 kernel: FAT: unable to read boot sector kernel: FAT: bogus logical sector size 64543 kernel: VFS: Can't find a valid FAT filesystem on dev 16:00. kernel: hdc: lost interrupt kernel: hdc: lost interrupt kernel: hdc: lost interrupt last message repeated 4 times
Nach dem "durch-grepen" ergeben sich diese Fehlerstellen.
LBAsect=234831627, sector=0 LBAsect=234831628, sector=0 LBAsect=234831630, sector=2 LBAsect=234831632, sector=4 LBAsect=234831634, sector=6
Ob weitere Sektoren streiken, weiss ich nicht. Kann man versuchen mit dd die Sectoren dahinter zu kopieren? Ich habe dann aber keine gültiges Dateisystem zum Einbinden mit dem loopback-Device und somit auch keine Chance die Dateien rauszuholen.
Wenn durch Kontaktschwierigkeiten beim Schreiben eine falsche Sektoradresse an der Festplatte ankommt, kann es schon mal den MBR erwischen.
Interessant. Ich habe mir nie eine Kopf über die Elektrizität im Rechner gemacht. Jetzt hängt die Platte in einem anderen Rechner direkt am IDE-Kabel, will aber immer noch keine Daten rausrücken.
Jens
----- Original Message ----- From: "Jens Weiße" jens.weisse@gmx.net To: lug-dd@schlittermann.de Sent: Friday, February 08, 2002 9:54 AM Subject: Re: defekter Master-Boot-Record
kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Hi Jens!
Nur so ne Idee:
Bringt das Abschalten der DMA-Unterstützung für dieses IDE-Device Besserung? Bei mir gibts ähnliche Fehlermeldungen(siehe Anhang), aber die HDD funktioniert. Sieht aus als würde die DMA-Unterstützung "stottern".
Viel Glück, (Ich hatte kürzlich keins, meine Platte wurde beim booten gar nicht mehr erkannt.->Schrott incl. allen noch ungesicherten Daten :-( )
Erik
Hi Erik,
dein Vorschlag wurde berücksichtigt und brachte etwas Linderung.
Am Freitag, 8. Februar 2002 10:21 schrieb Erik:
Bringt das Abschalten der DMA-Unterstützung für dieses IDE-Device Besserung?
Ja das hilft eine bisschen. Jetzt kann man schon einige Sektoren mehr lesen. Auch haben sich die Fehlermeldungen auf eine einzige reduziert:
Feb 8 11:42:09 dilbert kernel: hdc: lost interrupt
Leider scheint dd mit dieser Meldung (bzw der Ursache der Meldung) seine Probleme zu haben. Ausser durch einen reboot kann man dd nicht stoppen. dd hat sogar schon alle 100 angeforderte Sektoren gelesen 100+0 Records ein 100+0 Records aus und die Datei hat auch die richtige Größe.
Kann das eventuell am Kernel liegen? Es ist ein Standard Susi 7.3 Kernel (2.4.10 + viele undokumentierte Patches).
Viel Glück, (Ich hatte kürzlich keins, meine Platte wurde beim booten gar nicht mehr erkannt.->Schrott incl. allen noch ungesicherten Daten :-( )
Herzliches Beileid. Es ist zum GLÜCK nicht meine Festplatte :-) Die gehört meinem Vater. Das letzte Backup stammt vom 19.01.2002. :-o Meine Datensicherungsstrategie wurde auch kritisch überprüft. Statt kein Backup, habe ich jetzt schon ein aktuelles. :-)
Jens
hi!
die meisten festplatte unterstuetzen inzwischen S.M.A.R.T. damit kann man sehr leicht feststellen, ob eine platte fehler aufweist, allerdings eher auf sehr niedriger protokollebene. des weiteren kann man autooffline an und abstellen, was auch probleme verursachen kann, wenn die platte nach einiger zeit offline geht und der kernel nichts davon mitbekommt.
inwieweit dir das weiterhilft die daten herunter zu bekommen, weiss ich nicht, aber evtl. hilft es dir den fehler einzukreisen.
bis vor 2 tagen war unter http://lightside.eresmas.com/ ide-smart 1.4 zu bekommen, allerdings ist die seite offline. eine kopie findest du unter ftp://ftp.cyconet.org/pub/linux/packages/src/misc/ide-smart-1.4/, weiterhin zu empfehlen ist auch UCSC S.M.A.R.T. Suite welches auf http://csl.cse.ucsc.edu/smart.shtml zu finden ist.
viel glueck bei der datenrettung, jan :)
PS. ich glaube IBM hat auch irgendwo ein programm zur plattenreperatur unter linux auf den servern, zumindest errinnere ich mich, so etwas in der art mal bei denen gelesen zu haben
Hi Jan,
danke für den Tip mit S.M.A.R.T. Habe ich natürlich sofort ausprobiert. Aber die Platte weiss nichts von meinen Porblemen mit ihr. Mit dem ucsc Paket bekomme ich # /usr/local/sbin/smartctl -c /dev/hdc Device: ST32122A Supports ATA Version 2 Drive supports S.M.A.R.T. and is enabled Check S.M.A.R.T. Passed
Ich bastel mal weiter.
Jens
Am Donnerstag, 7. Februar 2002 22:56 schrieb Holger:
Am sichersten ist natuerlich ein Low-Level-Backup der Platte, z.B. mit dd if=/dev/hdc of=datei wenn Du Dir das leisten kannst. gzip ist moeglicherweise einer Deiner Freunde.
Die Festplatte lässt sich nicht überzeugen, größere Datenmengen herauszurücken (siehe unten).
Versuche dann mal, mit fdisk die Partition zu loeschen und dann genauso neu anzulegen. Unter Linux wird dabei nur in der Partitionstabelle geschrieben, solange man keine erweiterten Partitionen hat.
Deinem Vorschlag folgend habe ich die Partitionstabelle neu geschrieben und die korrekten Werte für Head und Cylinder eingetragen. Mounten lässt sich das Mistding nun schon wieder. Zumindest ein bis zweimal. Dann hat es die Tabelle schon wieder entschärft. Zwischendurch verschwinden nur Verzeichnisse. Warum sich bei laufendem System (mit neuem Kabel + andere Controller) die Platte selber auflöst ist mir allerdings schleierhaft.
Beim Versuch noch halbwegs brauchbare Dateien zu kopieren, entstehen ab und zu seitenweise diese hübsche Dinger:
kernel: Directory sread (sector 0x59503d62) failed
kernel: Filesystem panic (dev 16:01). kernel: FAT error kernel: File system has been set read-only kernel: Directory 440: bad FAT
kernel: attempt to access beyond end of device kernel: 16:01: rw=0, want=268702104,limit=2060320 kernel: attempt to access beyond end of device kernel: 16:01: rw=0, want=268702105,limit=2060320 kernel: hdc: lost interrupt
Einige Dateien (besonders die alten) liesen sich noch kopieren. Alle etwas neueren sind zwischen 20 GB und 40 GB groß. Davon gibt's sehr viele. Der Kompressionsalgorithmus ist die absolut Wucht. Mindestens 1 TB auf einer 2 GB Platte!!!
Auch mit dd lassen sich nur einzelne Sectoren-Bereiche kopieren. Sobald man den falschen erwischt, dann bekommt man auch ein "lost interrupt" und nix geht mehr.
Jens
hi!
Einige Dateien (besonders die alten) liesen sich noch kopieren. Alle etwas neueren sind zwischen 20 GB und 40 GB groß. Davon gibt's sehr viele. Der Kompressionsalgorithmus ist die absolut Wucht. Mindestens 1 TB auf einer 2 GB Platte!!!
ich will ja nicht vorlaut wirken, aber seit wann komprimiert fat32 daten? hab ich irgend eine weltveraendernde neuerung bei microsoft verpasst? :)
gruss, jan.
Am Freitag, 8. Februar 2002 15:51 schrieb Jan:
Einige Dateien (besonders die alten) liesen sich noch kopieren. Alle etwas neueren sind zwischen 20 GB und 40 GB groß. Davon gibt's sehr viele. Der Kompressionsalgorithmus ist die absolut Wucht. Mindestens 1 TB auf einer 2 GB Platte!!!
ich will ja nicht vorlaut wirken, aber seit wann komprimiert fat32 daten? hab ich irgend eine weltveraendernde neuerung bei microsoft verpasst? :)
Das sollte eigentlich ein Scherz sein. War wohl nur ein Rohrkrepierer. Microsoft komprimiert gar nicht. Aber die Einträge auf der Festplatte bringen einen arglosen und vertrauensvollen Pinguin leicht zu solchen Annahmen. Was eine zerstörte Dateistruktur doch für interessante Effekte hervorrufen kann.
Jens
On Fri, Feb 08, 2002 at 03:47:51PM +0100, Jens Weiße wrote:
Beim Versuch noch halbwegs brauchbare Dateien zu kopieren, entstehen ab und zu seitenweise diese hübsche Dinger:
kernel: Directory sread (sector 0x59503d62) failed
kernel: Filesystem panic (dev 16:01). kernel: FAT error kernel: File system has been set read-only kernel: Directory 440: bad FAT
kernel: attempt to access beyond end of device kernel: 16:01: rw=0, want=268702104,limit=2060320 kernel: attempt to access beyond end of device kernel: 16:01: rw=0, want=268702105,limit=2060320 kernel: hdc: lost interrupt
Durch eine defekte Partitionstabelle (ich weiß leider nicht mehr ob fdisk(DOS) oder fdisk(Linux) dran schuld war), versuchte Linux auch auf Bereiche zuzugreifen, welche hardwaremäßig gar nicht vorhanden waren. Das erzeugte, glaube ich, auch solche Fehlermeldungen.
In der Partitionstabelle wird doch einerseits <Cyl, Head, Sect> und andererseits eine absolute Sektornummer gespeichert, sowohl für den Anfang als auch für das Ende einer Partition. Diese beiden Adressierungen müssen auch irgendwie übereinstimmen.
kernel: 16:01: rw=0, want=268702105,limit=2060320
^^^^^^^^^^^^^ Korrespondiert dieser Wert irgendwie mit der Plattegröße? (Eventuell multipliziert mit 512, 1024 o.ä.)
Bert
Am Samstag, 9. Februar 2002 12:57 schrieb Bert:
Durch eine defekte Partitionstabelle (ich weiß leider nicht mehr ob fdisk(DOS) oder fdisk(Linux) dran schuld war), versuchte Linux auch auf Bereiche zuzugreifen, welche hardwaremäßig gar nicht vorhanden waren. Das erzeugte, glaube ich, auch solche Fehlermeldungen.
Die Partitionstabelle hatte ich mit fdisk neu geschrieben und alle Werte (Zylinder, Köpfe ...) wieder "hingebogen"
kernel: FAT error
Dann kam ab und zu die obige Meldung. So kam die brilliante Idee auf, Scandisk (M$) auszuprobieren. Das hat auch festgestellt, das die FAT defekt ist. Der Gedanke die FAT zu flicken klang auch logisch. Korrigieren konnte Scandisk diesen Fehler aber auch nicht.
Danach ließ sich mit der Platte nix mehr Anfangen. Ist also fast wie beim Arzt: "Operation misslungen, Patient tot"
Vielleicht kann man die Platte durch ordentliches Formatieren wiederbeleben. Der MBR ist noch beschreibbar, aber die wenigen Dateien, welche sich bisher noch lesen liessen sind fort. Experiement diese Art heb ich mir für die Semesterferien auf. Derzeit ist die Zeit etwas knapp. (Prüfungszeit)
In der Partitionstabelle wird doch einerseits <Cyl, Head, Sect> und andererseits eine absolute Sektornummer gespeichert, sowohl für den Anfang als auch für das Ende einer Partition. Diese beiden Adressierungen müssen auch irgendwie übereinstimmen.
kernel: 16:01: rw=0, want=268702105,limit=2060320
^^^^^^^^^^^^^ Korrespondiert dieser Wertirgendwie mit der Plattegröße? (Eventuell multipliziert mit 512, 1024 o.ä.)
want=749215413, limit=2060320 want=2147244493, limit=2060320 want=1044647421, limit=2060320 Die limit-zahl ist die Anzahl der Blöcke (gewesen). Ein Block ist 1024 Byte groß so das sich die Festplattengröße von 2.109.767.680 Byte (2GB) ergibt/ergab. Der want-Wert ist also vermutlich auch ein Block. Allerdings ergibt die Division/Multiplikation mit vielfachen von zwei nicht unbedingt sinnvolle Werte.
Danke für eure Hilfe, aber Vater wird wohl einige Zeit in die Wiederherstellung seiner Daten stecken müssen.
Jens
Hi Jens,
On Thu, Feb 07, 2002 at 22:41:14 +0100, Jens Weiße wrote:
H mount -t vfat -o ro /dev/hdc1 /windows mount: Falscher Dateisystemtyp, ungültige Optionen, der »Superblock« von /dev/hdc1 ist beschädigt oder es sind zu viele Dateisysteme gemountet
H fdisk -l
Festplatte /dev/hdc: 16 Köpfe, 63 Sektoren, 4092 Zylinder Einheiten: Zylinder mit 1008 * 512 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp/dev/hdc1 1 4088 2060320+ b Win95 FAT32 Partition 1 endet nicht an einer Zylindergrenze: phys=(1021, 63, 63) should be (1021, 15, 63)
Eventuell laesst sich das was mit gpart machen. Aber lieber vorher die Partition mit dd nach $BACKUPMEDIUM sichern.
bye, Chris
lug-dd@mailman.schlittermann.de
-
Bert Lange -
Christian Perle -
Erik Schanze -
Holger Dietze -
Jens Weiße -
Wagner Jan