Mailinglist Archive: opensuse-de (5689 mails)
| < Previous | Next > |
Re: Festplatte: Fehlerhafte Laufwerkgeometrie
- From: David Haller <david@xxxxxxxxxx>
- Date: Sat, 18 May 2002 16:25:05 +0200
- Message-id: <20020518142505.GD13431@xxxxxxxxxxxxxxxxxx>
Hallo,
On Fri, 17 May 2002, Christian Boltz wrote:
>Am Freitag, 17. Mai 2002 07:42 schrieb David Haller:
>> Allerdings hat das linux-fdisk einen "Bug", es schreibt v.a. bei
>> Aenderungen (logische) Partitionen nicht in der richtigen
>> ("physikalischen") Reihenfolge auf die Disk, was zwar den
>> Spezifikationen entspricht, aber mit der viele Tools nicht
>> zurechtkommen. Und Win verschluckt sich evtl. daran, wenn die Kette
>> der logischen Partitionen nicht der Geometrie entspricht. z.B:
>
>Du meinst sowas? (verträgt sich anscheinend mit Windoof 98 ganz gut ;-)
>
># fdisk -l /dev/hda
>
>Festplatte /dev/hda: 255 Köpfe, 63 Sektoren, 1653 Zylinder
>Einheiten: Zylinder mit 16065 * 512 Bytes
>
> Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp
>/dev/hda1 * 1 733 5887791 c Win95 FAT32 (LBA)
>/dev/hda2 734 1653 7389900 f Win95 Erw. (LBA)
>/dev/hda5 1273 1298 208813+ 82 Linux Swap
>/dev/hda6 1299 1653 2851506 83 Linux
>/dev/hda7 734 980 1983996 b Win95 FAT32
>
>Partition table entries are not in disk order
Genau. Das kann lange gutgehen, aber spaetestens, wenn ein anderes
Partitionierungstool dazukommt ist der Aerger vorprogrammiert. Und
IIRC gibt's auch nen Bug in Win9x, der bei obigen Beispiel /dev/hda7
ignorieren wuerde...
>Bitte wundere Dich nicht über die "Lücke", die noch zu füllen wäre.
>Dort liegt eine "verlorene" Partition, die ich mal versehentlich
>gelöscht habe.
>Inzwischen konnte ich die Partitionsdaten restaurieren (es geht nichts
>über log-Dateien ;-) Allerdings habe ich bisher noch keine Möglichkeit
>gefunden, sie einzutragen.
Im Zweifelsfall per Hand mit nem Diskeditor, dd + hexeditor + dd, DOS'
debug... :))
>Das Problem ist nämlich, dass die Partition auf Head 1 anfängt (davor
>lag vorher der Anfang der erweiterten Partition).
>Jetzt habe ich den Anfang der erweiterten Partition nach vorn
>verschoben und fdisk würde die Partition mit Head 0 als Anfang anlegen.
>Bei fdisk kann man leider den Head nicht angeben.
>Vorschläge?
Duerfte kein Problem sein, da jede log. Partition ja _in_ einer
Erweiterten Partition liegt (hab ich heute schon was zu geschrieben[1]).
D.h. _jede_ log. Partition beginnt auf "head 1", da head 0 durch den
"EPBR" belegt ist (s. [1]).
>So soll es aussehen:
>
>/dev/hda2 (erweiterte Partition im alten Zustand)
> System ID byte: 0x0F (Extended Partition (LBA))
> Starting at Cylinder: 992 Head: 0 Sector: 1
> Ending at Cylinder: 1022 Head: 254 Sector: 63
> CHS Values are NOT EFFECTIVE
>
>/dev/hda5 (leider aus Partitionstabelle gelöscht)
> System ID byte: 0x0B (Windows FAT32)
> Starting at Cylinder: 992 Head: 1 Sector: 1
>
>(dieses Head: 1 macht mir Probleme, da hda2 jetzt schon bei
>Zylinder 734 beginnt. Wie gesagt, schlimmstenfalls muss ich das
>zurückändern)
Noe, sollte auch so gehen. Schick mir bitte mal die relevanten
Sektoren der HD (Angaben in Werten fuer den skip= Parameter von dd):
1. den MBR: 'skip=0' (oder 'skip=' weglassen)
2. $ for c in 732 733 734 979 980 991 992 1021 1022 1023 1272 1273; do
echo "($c*255*63)-65; ($c*255*63)-2; ($c*255*63)+61" | bc; done
| xargs echo
11759515 11759578 11759641 11775580 11775643 11775706 11791645
11791708 11791771 15727570 15727633 15727696 15743635 15743698
15743761 15920350 15920413 15920476 15936415 15936478 15936541
16402300 16402363 16402426 16418365 16418428 16418491 16434430
16434493 16434556 20434615 20434678 20434741 20450680 20450743
20450806
count=1 bei Sektor 0, sonst bitte mit count=5 (ein offset -2 ist bei
den Sektorangaben mit drin). Ja, das duerfte ziemlich dauern, bis dd
sich jew. zum richtigen Sektor durchrattert hat[2] ;) Als 'of=' gebe
bitte immer 'cboltz.hda.<SEKTORNUMMER>' an, und pack das alles dann
in nen tarball...
Ahso: ich hab mir fuer diesen Zweck ein Tool 'dumpsector' geschrieben,
das (dank llseek) _wesentlich_ schneller als dd ist, aber eben leider
bisher kaum und nur von mir getestet ist[3], mehr ggfs. per PM, die
for-Schleife muesstest du dann leicht modifizieren... Dafuer duerfte
das ganze dann aber innerhalb von ca. 5s statt 10min (oder mehr)
erledigt sein :).
>> Diese Problem laesst sich AFAIK nur durch ein passendes "Anlegen in
>> Reihenfolge" im linux-fdisk umgehen.
>
>Nö, das betrachte ich nicht als Bug, sondern als Feature. Damit
>verschieben sich die Partitionsnummern nicht, wenn man weitere
>Partitionen anlegt. Somit muss man z. B. die /etc/fstab nicht
>überarbeiten. (Die Partitionsnummern verschieben sich erst, wenn man
>eine Partition löscht.)
Oehem, stimmt eigentlich. Leider kommt speziell Win* nicht mit solchen
Partitionstabellen klar... :(
>Und es ist garantiert kein Bug, da man es gleich korrigieren kann:
>mit x in den Expertenmodus wechseln und dann mit f (fix partition
>order) die Partitionen in der richtigen Reihenfolge durchnummerieren
>lassen.
*HUCH* Das hab ich wohl bisher immer uebersehen... Nein, stimmt ja gar
nicht: Bei meinem fdisk gibt's das schlicht und einfach noch nicht:
$ fdisk -v
fdisk v2.10f
>PPS: Mein oben genanntes Problem habe ich einem Fipptehler unter
> fdisk/DOS zu "verdanken"
"Selber schuld". Wer DoS' fdisk verwendet hat eh verloren... *eg*
-dnh
[1] Subject: Re: LILO: logisches Laufwerk verstecken
Message-ID: <20020518004721.GD1680@xxxxxxxxxxxxxxxxxx>
[2] Rechne mit bis zu 30 min fuer Sektoren > 10000000 ...
[3] da es aber eh _nur_ liest sollte es ok sein
--
Du vergisst die Kunden, die sich Windows-"Lösungen" andrehen lassen.
Die kaufen auch Scheiße in Dosen incl. Wartungsvertrag. -- Holger Marzen
On Fri, 17 May 2002, Christian Boltz wrote:
>Am Freitag, 17. Mai 2002 07:42 schrieb David Haller:
>> Allerdings hat das linux-fdisk einen "Bug", es schreibt v.a. bei
>> Aenderungen (logische) Partitionen nicht in der richtigen
>> ("physikalischen") Reihenfolge auf die Disk, was zwar den
>> Spezifikationen entspricht, aber mit der viele Tools nicht
>> zurechtkommen. Und Win verschluckt sich evtl. daran, wenn die Kette
>> der logischen Partitionen nicht der Geometrie entspricht. z.B:
>
>Du meinst sowas? (verträgt sich anscheinend mit Windoof 98 ganz gut ;-)
>
># fdisk -l /dev/hda
>
>Festplatte /dev/hda: 255 Köpfe, 63 Sektoren, 1653 Zylinder
>Einheiten: Zylinder mit 16065 * 512 Bytes
>
> Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp
>/dev/hda1 * 1 733 5887791 c Win95 FAT32 (LBA)
>/dev/hda2 734 1653 7389900 f Win95 Erw. (LBA)
>/dev/hda5 1273 1298 208813+ 82 Linux Swap
>/dev/hda6 1299 1653 2851506 83 Linux
>/dev/hda7 734 980 1983996 b Win95 FAT32
>
>Partition table entries are not in disk order
Genau. Das kann lange gutgehen, aber spaetestens, wenn ein anderes
Partitionierungstool dazukommt ist der Aerger vorprogrammiert. Und
IIRC gibt's auch nen Bug in Win9x, der bei obigen Beispiel /dev/hda7
ignorieren wuerde...
>Bitte wundere Dich nicht über die "Lücke", die noch zu füllen wäre.
>Dort liegt eine "verlorene" Partition, die ich mal versehentlich
>gelöscht habe.
>Inzwischen konnte ich die Partitionsdaten restaurieren (es geht nichts
>über log-Dateien ;-) Allerdings habe ich bisher noch keine Möglichkeit
>gefunden, sie einzutragen.
Im Zweifelsfall per Hand mit nem Diskeditor, dd + hexeditor + dd, DOS'
debug... :))
>Das Problem ist nämlich, dass die Partition auf Head 1 anfängt (davor
>lag vorher der Anfang der erweiterten Partition).
>Jetzt habe ich den Anfang der erweiterten Partition nach vorn
>verschoben und fdisk würde die Partition mit Head 0 als Anfang anlegen.
>Bei fdisk kann man leider den Head nicht angeben.
>Vorschläge?
Duerfte kein Problem sein, da jede log. Partition ja _in_ einer
Erweiterten Partition liegt (hab ich heute schon was zu geschrieben[1]).
D.h. _jede_ log. Partition beginnt auf "head 1", da head 0 durch den
"EPBR" belegt ist (s. [1]).
>So soll es aussehen:
>
>/dev/hda2 (erweiterte Partition im alten Zustand)
> System ID byte: 0x0F (Extended Partition (LBA))
> Starting at Cylinder: 992 Head: 0 Sector: 1
> Ending at Cylinder: 1022 Head: 254 Sector: 63
> CHS Values are NOT EFFECTIVE
>
>/dev/hda5 (leider aus Partitionstabelle gelöscht)
> System ID byte: 0x0B (Windows FAT32)
> Starting at Cylinder: 992 Head: 1 Sector: 1
>
>(dieses Head: 1 macht mir Probleme, da hda2 jetzt schon bei
>Zylinder 734 beginnt. Wie gesagt, schlimmstenfalls muss ich das
>zurückändern)
Noe, sollte auch so gehen. Schick mir bitte mal die relevanten
Sektoren der HD (Angaben in Werten fuer den skip= Parameter von dd):
1. den MBR: 'skip=0' (oder 'skip=' weglassen)
2. $ for c in 732 733 734 979 980 991 992 1021 1022 1023 1272 1273; do
echo "($c*255*63)-65; ($c*255*63)-2; ($c*255*63)+61" | bc; done
| xargs echo
11759515 11759578 11759641 11775580 11775643 11775706 11791645
11791708 11791771 15727570 15727633 15727696 15743635 15743698
15743761 15920350 15920413 15920476 15936415 15936478 15936541
16402300 16402363 16402426 16418365 16418428 16418491 16434430
16434493 16434556 20434615 20434678 20434741 20450680 20450743
20450806
count=1 bei Sektor 0, sonst bitte mit count=5 (ein offset -2 ist bei
den Sektorangaben mit drin). Ja, das duerfte ziemlich dauern, bis dd
sich jew. zum richtigen Sektor durchrattert hat[2] ;) Als 'of=' gebe
bitte immer 'cboltz.hda.<SEKTORNUMMER>' an, und pack das alles dann
in nen tarball...
Ahso: ich hab mir fuer diesen Zweck ein Tool 'dumpsector' geschrieben,
das (dank llseek) _wesentlich_ schneller als dd ist, aber eben leider
bisher kaum und nur von mir getestet ist[3], mehr ggfs. per PM, die
for-Schleife muesstest du dann leicht modifizieren... Dafuer duerfte
das ganze dann aber innerhalb von ca. 5s statt 10min (oder mehr)
erledigt sein :).
>> Diese Problem laesst sich AFAIK nur durch ein passendes "Anlegen in
>> Reihenfolge" im linux-fdisk umgehen.
>
>Nö, das betrachte ich nicht als Bug, sondern als Feature. Damit
>verschieben sich die Partitionsnummern nicht, wenn man weitere
>Partitionen anlegt. Somit muss man z. B. die /etc/fstab nicht
>überarbeiten. (Die Partitionsnummern verschieben sich erst, wenn man
>eine Partition löscht.)
Oehem, stimmt eigentlich. Leider kommt speziell Win* nicht mit solchen
Partitionstabellen klar... :(
>Und es ist garantiert kein Bug, da man es gleich korrigieren kann:
>mit x in den Expertenmodus wechseln und dann mit f (fix partition
>order) die Partitionen in der richtigen Reihenfolge durchnummerieren
>lassen.
*HUCH* Das hab ich wohl bisher immer uebersehen... Nein, stimmt ja gar
nicht: Bei meinem fdisk gibt's das schlicht und einfach noch nicht:
$ fdisk -v
fdisk v2.10f
>PPS: Mein oben genanntes Problem habe ich einem Fipptehler unter
> fdisk/DOS zu "verdanken"
"Selber schuld". Wer DoS' fdisk verwendet hat eh verloren... *eg*
-dnh
[1] Subject: Re: LILO: logisches Laufwerk verstecken
Message-ID: <20020518004721.GD1680@xxxxxxxxxxxxxxxxxx>
[2] Rechne mit bis zu 30 min fuer Sektoren > 10000000 ...
[3] da es aber eh _nur_ liest sollte es ok sein
--
Du vergisst die Kunden, die sich Windows-"Lösungen" andrehen lassen.
Die kaufen auch Scheiße in Dosen incl. Wartungsvertrag. -- Holger Marzen
| < Previous | Next > |