Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
partitionstabelle und /dev/sda-Einträge stimmen nicht überein
13 views
Skip to first unread message
Uwe Bosse
Apr 7, 2012, 5:27:38 PM4/7/12
to
Hallo,
nachdem eine Windows-Installation ein Teil meiner Partitionstabelle
zerschossen hat, habe ich sie mit fdisk wieder herstellen können - na ja
beinahe jedenfalls.
Ich habe nun aber folgendes Phänomen:
In der Partitionstabelle stehen
sda1 bis sda3 als Primäre Partion,
sda4 als erweiterte, mit
sda5 sda6, sda7 und sda8 als Linux-Partitionen.
Greife ich mit hexedit /dev/sda auf die gesamte Festplatte zu
und rechne die Einträge in der Partitionstabelle in Byte-Offsets um,
so komme ich korrekt immer an den Anfang der jeweiligen Partition.
Aber: mount /dev/sda7 mountet mir sda6 ebenso wie mount /dev/sda6.
mount /dev/sda8 mountet mir sda7 ???
Der Kernel scheint also irgendwie anders als über die Partitionstabelle
seine Dateisysteme zu finden.
Was läuft da schief und muss ich fürchten, dass mir alles bald um die Ohren
fliegt?
nachdem eine Windows-Installation ein Teil meiner Partitionstabelle
zerschossen hat, habe ich sie mit fdisk wieder herstellen können - na ja
beinahe jedenfalls.
Ich habe nun aber folgendes Phänomen:
In der Partitionstabelle stehen
sda1 bis sda3 als Primäre Partion,
sda4 als erweiterte, mit
sda5 sda6, sda7 und sda8 als Linux-Partitionen.
Greife ich mit hexedit /dev/sda auf die gesamte Festplatte zu
und rechne die Einträge in der Partitionstabelle in Byte-Offsets um,
so komme ich korrekt immer an den Anfang der jeweiligen Partition.
Aber: mount /dev/sda7 mountet mir sda6 ebenso wie mount /dev/sda6.
mount /dev/sda8 mountet mir sda7 ???
Der Kernel scheint also irgendwie anders als über die Partitionstabelle
seine Dateisysteme zu finden.
Was läuft da schief und muss ich fürchten, dass mir alles bald um die Ohren
fliegt?
Gabriel Schumann
Apr 7, 2012, 5:45:23 PM4/7/12
to
Am 07.04.2012 23:27, schrieb Uwe Bosse:
> [Partitionen zerschossen und dann repariert]
Gruß
Gabriel
> [Partitionen zerschossen und dann repariert]
>
> Aber: mount /dev/sda7 mountet mir sda6 ebenso wie mount /dev/sda6.
> mount /dev/sda8 mountet mir sda7 ???
>
Mal die Funktion "fix partition order" in den Expert-Einstellungen versucht?
> Aber: mount /dev/sda7 mountet mir sda6 ebenso wie mount /dev/sda6.
> mount /dev/sda8 mountet mir sda7 ???
>
Gruß
Gabriel
Uwe Bosse
Apr 11, 2012, 6:07:43 PM4/11/12
to
Gabriel Schumann wrote:
> Mal die Funktion "fix partition order" in den Expert-Einstellungen
> versucht?
das liefert "keine Korrekturen notwendig".
> Mal die Funktion "fix partition order" in den Expert-Einstellungen
> versucht?
Irgendwoanders her muss der Kernel seine Information über die Dateisysteme
gewinnen als (nur) durch die Partitionstabelle. Kann das sein?
Thomas Rachel
Apr 13, 2012, 3:50:33 AM4/13/12
to
Am 07.04.2012 23:27 schrieb Uwe Bosse:
> Aber: mount /dev/sda7 mountet mir sda6 ebenso wie mount /dev/sda6.
> mount /dev/sda8 mountet mir sda7 ???
Kannst Du das präzisieren? Woran ist zu erkennen, daß sda6 und 7
> Aber: mount /dev/sda7 mountet mir sda6 ebenso wie mount /dev/sda6.
> mount /dev/sda8 mountet mir sda7 ???
dasselbe mountet?
Stehen in der fstab die sdaX-Einträge oder greifst Du über
/dev/disks/by-* zu? Stimmen die dortigen Einträge? Insbesondere für
by-label sollte diese Frage gut entscheidbar sein.
Ist das Verhalten über Reboots hinweg reproduzierbar?
Stimmen die Major- und Minor-Einträge bei den Blockdeviceeinträgen in /dev/?
Desweiteren:
Was sagt cat /proc/partitions?
Und was head -n 99 /sys/block/sda/sda*/{start,size}?
Das ist das, was der Kernel von der Platte hält...
> Der Kernel scheint also irgendwie anders als über die Partitionstabelle
> seine Dateisysteme zu finden.
o.ä. enthält. Was in diesem Fall Vorrang hat, weiß ich nicht, würde aber
auf GPT tippen...
> Was läuft da schief und muss ich fürchten, dass mir alles bald um die Ohren
> fliegt?
nicht garantiert, daher sollte man dennoch herausfinden, warum etwas
nicht so läuft wie erwartet.
Thomas
Uwe Bosse
Apr 15, 2012, 8:46:27 AM4/15/12
to
> Kannst Du das präzisieren? Woran ist zu erkennen, daß sda6 und 7
> dasselbe mountet?
sda6 eine Datei, dann taucht sie in sda7 erstmal nicht auf, wenn ich aber
neu mounte, dann ist sie sowohl in sda6 als auch sda7 da.
>
> Stehen in der fstab die sdaX-Einträge oder greifst Du über
> /dev/disks/by-* zu? Stimmen die dortigen Einträge? Insbesondere für
> by-label sollte diese Frage gut entscheidbar sein.
ein sudo tune2fs -l liefert die gleichen Daten für sda6 wie sda7
> Ist das Verhalten über Reboots hinweg reproduzierbar?
> Stimmen die Major- und Minor-Einträge bei den Blockdeviceeinträgen in
> /dev/?
>
>
> Desweiteren:
> Was sagt cat /proc/partitions?
8 0 976762584 sda
8 1 20971520 sda1
8 2 3145728 sda2
8 3 62914560 sda3
8 4 1 sda4
8 5 157286400 sda5
8 6 62914560 sda6
8 7 62914560 sda7
8 8 209715200 sda8
8 9 10485760 sda9
> Und was head -n 99 /sys/block/sda/sda{6,7}/{start,size}?
==> /sys/block/sda/sda6/start <==
488642560
==> /sys/block/sda/sda6/size <==
125829120
==> /sys/block/sda/sda7/start <==
488642560
==> /sys/block/sda/sda7/size <==
125829120
>
> Das ist das, was der Kernel von der Platte hält...
Partitionen sind.
Die Partitionstabelle (sudo fdisk -l /dev/sda ) ist da aber anderer Meinung:
Gerät boot. Anfang Ende Blöcke Id System
/dev/sda1 * 43 873856 20971520 c W95 FAT32 (LBA)
/dev/sda2 873857 1004928 3145728 82 Linux Swap / Solaris
/dev/sda3 1004929 3626368 62914560 83 Linux
/dev/sda4 3626369 40698441 889729752 5 Erweiterte
/dev/sda5 3626411 10180011 157286400 83 Linux
/dev/sda6 10180054 12801494 62914560 83 Linux
/dev/sda7 12801537 21539670 209715200 83 Linux
/dev/sda8 21539713 21976619 10485760 83 Linux
Etwas seltsam sind die "Löcher" zwischen den Partitionen. Wie die entstanden
sind, weiß ich nicht. Vielleicht liegt ja da der Hund begraben.
Bleibt die Frage: muss ich mir Sorgen machen?
Thomas Rachel
Apr 15, 2012, 5:15:38 PM4/15/12
to
Am 15.04.2012 14:46 schrieb Uwe Bosse:
>> Kannst Du das präzisieren? Woran ist zu erkennen, daß sda6 und 7
>> dasselbe mountet?
>
> an den Dateien. Die sind in jedem Fall exakt die gleichen. Schreibe ich in
> sda6 eine Datei, dann taucht sie in sda7 erstmal nicht auf, wenn ich aber
> neu mounte, dann ist sie sowohl in sda6 als auch sda7 da.
Au weia. Nach dem, was Du unten schreibst (start und size), zeigen die
>> Kannst Du das präzisieren? Woran ist zu erkennen, daß sda6 und 7
>> dasselbe mountet?
>
> an den Dateien. Die sind in jedem Fall exakt die gleichen. Schreibe ich in
> sda6 eine Datei, dann taucht sie in sda7 erstmal nicht auf, wenn ich aber
> neu mounte, dann ist sie sowohl in sda6 als auch sda7 da.
Partitionen auf denselben Bereich, was absolut nicht sein sollte. Da der
Kernel davon nichts weiß, kann und wird gleichzeitinges Mounten und
damit arbeiten zu Chaos führen, da die Schreibzugriffe nicht aufeinander
abgestimmt sind.
>> Und was head -n 99 /sys/block/sda/sda{6,7}/{start,size}?
> ==> /sys/block/sda/sda6/start<==
> 488642560
>
> ==> /sys/block/sda/sda6/size<==
> 125829120
>
> ==> /sys/block/sda/sda7/start<==
> 488642560
>
> ==> /sys/block/sda/sda7/size<==
> 125829120
> Dann findet der Kernel also dass sda6 und sda7 exakt die gleichen
> Partitionen sind.
gesagt, Schreibzugriffe werden nicht synchronisiert und führen zu
Dateisystemschäden.
> Die Partitionstabelle (sudo fdisk -l /dev/sda ) ist da aber anderer Meinung:
>
> Gerät boot. Anfang Ende Blöcke Id System
> /dev/sda1 * 43 873856 20971520 c W95 FAT32 (LBA)
> /dev/sda2 873857 1004928 3145728 82 Linux Swap / Solaris
> /dev/sda3 1004929 3626368 62914560 83 Linux
> /dev/sda4 3626369 40698441 889729752 5 Erweiterte
> /dev/sda5 3626411 10180011 157286400 83 Linux
> /dev/sda6 10180054 12801494 62914560 83 Linux
> /dev/sda7 12801537 21539670 209715200 83 Linux
> /dev/sda8 21539713 21976619 10485760 83 Linux
> Etwas seltsam sind die "Löcher" zwischen den Partitionen. Wie die entstanden
> sind, weiß ich nicht. Vielleicht liegt ja da der Hund begraben.
"doppelte Partition", und verwunderlich ist die Abweichung. Daher
nochmal die Frage nach GPT: Kann es sein, daß Du zusätzlich eine
GPT-Tabelle hast, die von dieser hier abweicht? Dann hat evtl. die
Vorrang, oder beide werden "irgendwie" verwendet, was zu besagtem
Durcheinander führt.
Die GPT anzeigen kannst Du mit gdisk oder mit parted.
> Bleibt die Frage: muss ich mir Sorgen machen?
Welche Partitionen haben denn Nutzdaten und wie wichtig sind die jeweils?
Thomas
Sieghard Schicktanz
Apr 15, 2012, 6:41:45 PM4/15/12
to
Hallo Thomas,
Du schriebst am Sun, 15 Apr 2012 23:15:38 +0200:
> >> Und was head -n 99 /sys/block/sda/sda{6,7}/{start,size}?
> > ==> /sys/block/sda/sda6/start<==
> > 488642560
> > ^^^^^^^^^
> > ==> /sys/block/sda/sda6/size<==
> > 125829120
... |||||||||
> Urks.
In der Tat. Da passt gleich garnichts zusammen, da ist eine "doppelte
Partition" eher noch ein kleineres Problem.
Da scheint eher die _Plattenzuordnung_ im System durcheinandergeraten zu
sein.
Der Originalfrager sollte mal mitteilen, _ob_ er mehrere Platten in der
Maschine hat, und wenn ja, _alle_ ihre Partitionstabellen untersuchen.
Vielleicht hat ja eine _tatsächlich_ mehrere identische Partitionseinträge
- evtl. hat da aus irgendeinem Grund die Tabelle für die "logische"
Partition 6 _zwei_ Einträge erhalten, und das System kommt deswegen "leicht"
durcheinander?
> > Etwas seltsam sind die "Löcher" zwischen den Partitionen. Wie die
...
Partitionen liegt jeweils eine ungenutzte "Spur" dazwischen, die lediglich
die Partitionstabelle für die Verkettung enthält. Damit gehen normalerweise
63 Sektoren "verloren", hier sind's 43, wohl wegen einer anderen Geometrie.
> "doppelte Partition", und verwunderlich ist die Abweichung. Daher
> nochmal die Frage nach GPT: Kann es sein, daß Du zusätzlich eine
> GPT-Tabelle hast, die von dieser hier abweicht? Dann hat evtl. die
> Vorrang, oder beide werden "irgendwie" verwendet, was zu besagtem
> Durcheinander führt.
>
> Die GPT anzeigen kannst Du mit gdisk oder mit parted.
Das ist hier aber reichlich müßig (bis evtl. sogar gefährlich, wenn man
einen falschen Schalter erwischt und die Platte damit umpartitioniert wird)
- _wenn_ fdisk eine sinnvolle Partitionierung anzeigt, dann ist das keine
GPT-Partitionierung. Eine solche hätte nur eine einzige Partition für fdisk
mit der entsprechenden Kennung (ee), die der erkennt und mit einer Warnung
quittiert.
> > Bleibt die Frage: muss ich mir Sorgen machen?
>
> Angesichts der Doppelbelegung: ja.
Ja, das ist sehr bedenklich und sollte jedenfalls geklärt werden.
Vielleicht ist die Ursache trivial (falsche Plattenzuordnung), aber ein
Fehler auf einer Platte oder im System ist das auf jeden Fall, und der
sollte beseitigt werden.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Du schriebst am Sun, 15 Apr 2012 23:15:38 +0200:
> >> Und was head -n 99 /sys/block/sda/sda{6,7}/{start,size}?
> > ==> /sys/block/sda/sda6/start<==
> > 488642560
> > ==> /sys/block/sda/sda6/size<==
> > 125829120
... |||||||||
> > Die Partitionstabelle (sudo fdisk -l /dev/sda ) ist da aber anderer
...
> > Gerät boot. Anfang Ende Blöcke Id System
> > /dev/sda6 10180054 12801494 62914560 83 Linux
... ^^^^^^^^ ||||||||
> Urks.
In der Tat. Da passt gleich garnichts zusammen, da ist eine "doppelte
Partition" eher noch ein kleineres Problem.
Da scheint eher die _Plattenzuordnung_ im System durcheinandergeraten zu
sein.
Der Originalfrager sollte mal mitteilen, _ob_ er mehrere Platten in der
Maschine hat, und wenn ja, _alle_ ihre Partitionstabellen untersuchen.
Vielleicht hat ja eine _tatsächlich_ mehrere identische Partitionseinträge
- evtl. hat da aus irgendeinem Grund die Tabelle für die "logische"
Partition 6 _zwei_ Einträge erhalten, und das System kommt deswegen "leicht"
durcheinander?
> > Etwas seltsam sind die "Löcher" zwischen den Partitionen. Wie die
> Etwas seltsam schon. Aber erstmal kein Problem. Großes Problem ist die
Nicht nur kein Problem, sondern prinzipbedingt - bei den "logischen"
Partitionen liegt jeweils eine ungenutzte "Spur" dazwischen, die lediglich
die Partitionstabelle für die Verkettung enthält. Damit gehen normalerweise
63 Sektoren "verloren", hier sind's 43, wohl wegen einer anderen Geometrie.
> "doppelte Partition", und verwunderlich ist die Abweichung. Daher
> nochmal die Frage nach GPT: Kann es sein, daß Du zusätzlich eine
> GPT-Tabelle hast, die von dieser hier abweicht? Dann hat evtl. die
> Vorrang, oder beide werden "irgendwie" verwendet, was zu besagtem
> Durcheinander führt.
>
> Die GPT anzeigen kannst Du mit gdisk oder mit parted.
einen falschen Schalter erwischt und die Platte damit umpartitioniert wird)
- _wenn_ fdisk eine sinnvolle Partitionierung anzeigt, dann ist das keine
GPT-Partitionierung. Eine solche hätte nur eine einzige Partition für fdisk
mit der entsprechenden Kennung (ee), die der erkennt und mit einer Warnung
quittiert.
> > Bleibt die Frage: muss ich mir Sorgen machen?
>
> Angesichts der Doppelbelegung: ja.
Vielleicht ist die Ursache trivial (falsche Plattenzuordnung), aber ein
Fehler auf einer Platte oder im System ist das auf jeden Fall, und der
sollte beseitigt werden.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Thomas Rachel
Apr 17, 2012, 5:57:17 AM4/17/12
to
Am 16.04.2012 00:41 schrieb Sieghard Schicktanz:
>> Die GPT anzeigen kannst Du mit gdisk oder mit parted.
>
> Das ist hier aber reichlich müßig (bis evtl. sogar gefährlich, wenn man
> einen falschen Schalter erwischt und die Platte damit umpartitioniert wird)
> - _wenn_ fdisk eine sinnvolle Partitionierung anzeigt, dann ist das keine
> GPT-Partitionierung. Eine solche hätte nur eine einzige Partition für fdisk
> mit der entsprechenden Kennung (ee), die der erkennt und mit einer Warnung
> quittiert.
Das ist der Normalfall. Es gibt aber auch die hybride Partitionierung
>> Die GPT anzeigen kannst Du mit gdisk oder mit parted.
>
> Das ist hier aber reichlich müßig (bis evtl. sogar gefährlich, wenn man
> einen falschen Schalter erwischt und die Platte damit umpartitioniert wird)
> - _wenn_ fdisk eine sinnvolle Partitionierung anzeigt, dann ist das keine
> GPT-Partitionierung. Eine solche hätte nur eine einzige Partition für fdisk
> mit der entsprechenden Kennung (ee), die der erkennt und mit einer Warnung
> quittiert.
(http://www.rodsbooks.com/gdisk/hybrid.html), bei der es so ist (oder
sein sollte), daß der MBR keinen "blockierenden" Eintrag enthält,
sondern die GPT-Partitionierung nachbildet, um alten Systemen dieselbe
Partitionierung bieten zu können.
Wehe, es gibt dann Redundanzen...
Thomas
Uwe Bosse
Apr 17, 2012, 3:47:51 PM4/17/12
to
Ich hab mal vorsichtshalber die Finger von gdit gelassen und stattdessen mit
hexedit den Anfang von /dev/sda untersucht.
Wenn ich wikipedia richtig verstehe müsste man eine GUID partition table
daran erkennen, dass sie mit EFI PART (Signatur) beginnt. So etwas ist weder
an Adresse 0x200 noch innerhalb der nächsten paar kB.
Die Platte war mal eine zweite Platte (/dev/sdb). Damals wurde sie
formatiert und wurde möglicherweise mit einer anderen Festplattengeometrie
(Anzahl Köpfe, Zylinder) erkannt als jetzt. Jedenfalls spricht eine alte
von mir gesicherte Ausgabe von fdisk -l /dev/sdb dafür.
Dann wurde sie erste Platte, die andere habe ich rausgeschmissen. Sie ist
jetzt also einzige.
Eine letztendlich missglückte Installation von Win XP auf /dev/sda1 hat mir
den ganzen Schlamassel eingebrockt. Plötzlich waren die Partitionen sda6
bis sda8 weg! (d.h. tauchten in fdisk nicht auf) Ich hab die
Partitionstabelle wieder hergestellt, möglicherweise nicht ganz präzise so,
wie sie war, weil die Einheit auf dem Ausdruck, den ich hatte, nicht
Sektoren waren. Mir schienen zu Beginn von /dev/sda6 ein Paar Nullen zuviel
(mehr als beim ebenfalls mit ext4 formatierten /dev/sda3). Dennoch wurde
die Partition erkannt und konnte gemountet werden.
Jetzt habe ich die Partitionstabelle korrigiert, sda6 beginnt nun ein paar
sektoren früher, die Anzahl der Nullen vor den Daten ist bei sda6 nun genau
gleich wie bei sda3, nur dass das geschilderte Problem jetzt auftaucht.
Wenn ich euch richtig verstehe, sollte ich die Daten schleunigst sichern
(bereits geschehen), die Partitionen alle Platt machen und komplett neu
formatieren. Oder?
hexedit den Anfang von /dev/sda untersucht.
Wenn ich wikipedia richtig verstehe müsste man eine GUID partition table
daran erkennen, dass sie mit EFI PART (Signatur) beginnt. So etwas ist weder
an Adresse 0x200 noch innerhalb der nächsten paar kB.
Die Platte war mal eine zweite Platte (/dev/sdb). Damals wurde sie
formatiert und wurde möglicherweise mit einer anderen Festplattengeometrie
(Anzahl Köpfe, Zylinder) erkannt als jetzt. Jedenfalls spricht eine alte
von mir gesicherte Ausgabe von fdisk -l /dev/sdb dafür.
Dann wurde sie erste Platte, die andere habe ich rausgeschmissen. Sie ist
jetzt also einzige.
Eine letztendlich missglückte Installation von Win XP auf /dev/sda1 hat mir
den ganzen Schlamassel eingebrockt. Plötzlich waren die Partitionen sda6
bis sda8 weg! (d.h. tauchten in fdisk nicht auf) Ich hab die
Partitionstabelle wieder hergestellt, möglicherweise nicht ganz präzise so,
wie sie war, weil die Einheit auf dem Ausdruck, den ich hatte, nicht
Sektoren waren. Mir schienen zu Beginn von /dev/sda6 ein Paar Nullen zuviel
(mehr als beim ebenfalls mit ext4 formatierten /dev/sda3). Dennoch wurde
die Partition erkannt und konnte gemountet werden.
Jetzt habe ich die Partitionstabelle korrigiert, sda6 beginnt nun ein paar
sektoren früher, die Anzahl der Nullen vor den Daten ist bei sda6 nun genau
gleich wie bei sda3, nur dass das geschilderte Problem jetzt auftaucht.
Wenn ich euch richtig verstehe, sollte ich die Daten schleunigst sichern
(bereits geschehen), die Partitionen alle Platt machen und komplett neu
formatieren. Oder?
Sieghard Schicktanz
Apr 17, 2012, 6:01:38 PM4/17/12
to
Hallo Uwe,
Du schriebst am Tue, 17 Apr 2012 21:47:51 +0200:
> Jetzt habe ich die Partitionstabelle korrigiert, sda6 beginnt nun ein
> paar sektoren früher, die Anzahl der Nullen vor den Daten ist bei sda6
> nun genau gleich wie bei sda3, nur dass das geschilderte Problem jetzt
> auftaucht.
Das könnte die Ursache für das Problem sein - die Struktur einer _primären_
Partition ist etwas anders als die einer _"logischen"_ - bei letzterer
steht _immer_ eine (nur teilweise genutzte) Partitionstabelle in einer
reservierten Spur davor, bei ersterer _nur_ vor der _allerersten_.
> Wenn ich euch richtig verstehe, sollte ich die Daten schleunigst sichern
> (bereits geschehen), die Partitionen alle Platt machen und komplett neu
> formatieren. Oder?
Vergiß nicht, eine _Komplettkopie_ der Platte zu machen, falls Dir die
Daten auf den "unzugänglichen" Partitionen was wert sind - mit der (noch
besser mit einer Tertiär-Kopie) kannst Du dann noch bisserl an der
Partitionierung "spielen", um die ggfs. wieder herszustellen oder zumindest
mit einem Disk-Editor o.ä. die wesentlichen Daten rekonstruieren.
Du schriebst am Tue, 17 Apr 2012 21:47:51 +0200:
> Jetzt habe ich die Partitionstabelle korrigiert, sda6 beginnt nun ein
> paar sektoren früher, die Anzahl der Nullen vor den Daten ist bei sda6
> nun genau gleich wie bei sda3, nur dass das geschilderte Problem jetzt
> auftaucht.
Partition ist etwas anders als die einer _"logischen"_ - bei letzterer
steht _immer_ eine (nur teilweise genutzte) Partitionstabelle in einer
reservierten Spur davor, bei ersterer _nur_ vor der _allerersten_.
> Wenn ich euch richtig verstehe, sollte ich die Daten schleunigst sichern
> (bereits geschehen), die Partitionen alle Platt machen und komplett neu
> formatieren. Oder?
Daten auf den "unzugänglichen" Partitionen was wert sind - mit der (noch
besser mit einer Tertiär-Kopie) kannst Du dann noch bisserl an der
Partitionierung "spielen", um die ggfs. wieder herszustellen oder zumindest
mit einem Disk-Editor o.ä. die wesentlichen Daten rekonstruieren.
Ansgar Strickerschmidt
Apr 18, 2012, 8:04:12 AM4/18/12
to
Also schrieb Uwe Bosse:
> Wenn ich euch richtig verstehe, sollte ich die Daten schleunigst sichern
> (bereits geschehen), die Partitionen alle Platt machen und komplett neu
> formatieren. Oder?
Oder.
Wirf mal mit Hilfe einer Rescue-CD Deines Vertrauens ein "testdisk" an,
und lass das nach verlorenen Partitionen suchen.
Ansgar
--
*** Musik! ***
> Wenn ich euch richtig verstehe, sollte ich die Daten schleunigst sichern
> (bereits geschehen), die Partitionen alle Platt machen und komplett neu
> formatieren. Oder?
Wirf mal mit Hilfe einer Rescue-CD Deines Vertrauens ein "testdisk" an,
und lass das nach verlorenen Partitionen suchen.
Ansgar
--
*** Musik! ***
Uwe Bosse
Apr 19, 2012, 2:52:27 AM4/19/12
to
> Das könnte die Ursache für das Problem sein - die Struktur einer
> _primären_ Partition ist etwas anders als die einer _"logischen"_ - bei
> letzterer steht _immer_ eine (nur teilweise genutzte) Partitionstabelle in
> einer reservierten Spur davor, bei ersterer _nur_ vor der _allerersten_.
>
Das sah nicht nach Partitionstabelle aus. Aber wenn der Start der Daten
einer Partition bei einer in einer erweiterten liegenden bei einem anderen
Offset erwartet wird als bei einer primären, dann ist das schon eine
mögliche Ursache für mein Problem.
Werde auf alle Fälle die Daten regelmäßig sichern (Bilder und Töne) und
natürlich nie beide gleichzeitig einbinden. Auf die primäre Partition sda3
sollte sich der Fehler ja nicht auswirken.
Mein sch... Windows, das mir das alles eingebrockt hat, funktioniert
übrigens überhaupt nicht. Es bootet in einen Bluescreen.
Danke für Eure Hilfe.
Sieghard Schicktanz
Apr 19, 2012, 4:48:05 PM4/19/12
to
Hallo Uwe,
Du schriebst am Thu, 19 Apr 2012 08:52:27 +0200:
[Partitionstabelle]
"Spur" (der "S"-Wert in der CHS-Geometrieangabe) davor, und nur im
allerersten Sektor steht was drin, und das auch nur in den ersten beiden
Tabelleneinträgen (Adressen 446 [0x1BE]..509 [0x1FE]), und ein "Flag"-Wort
0xAA55 (oder 0x55AA, weiß ich jetzt nicht genau) auf 510 [1FE].
> natürlich nie beide gleichzeitig einbinden. Auf die primäre Partition
Das wäre ein sicheres Rezept für Durcheinander, ja.
> sda3 sollte sich der Fehler ja nicht auswirken.
Nicht, wenn die Angaben in den Systemtabellen (/proc/partitions und
/sys/block/sda/sda?/(start|size) untereinander und - mit gleichen Einheiten
- von "fdisk -l /dev/sda" übereinstimmen.
> Mein sch... Windows, das mir das alles eingebrockt hat, funktioniert
> übrigens überhaupt nicht. Es bootet in einen Bluescreen.
Wahrscheinlich deswegen. Es kam da mit irgendwas bei Deiner Einrichtung
offenbar nicht zurecht. Möglicherweise sind ein paar Partitionen nicht an
einer "Zylindergrenze" ausgerichtet, das könnte es verwirrt haben.
Du schriebst am Thu, 19 Apr 2012 08:52:27 +0200:
[Partitionstabelle]
> ok, das könnte sein. Allerdings waren nur lauter Nullen vor der
> Partition. Das sah nicht nach Partitionstabelle aus. Aber wenn der Start
_Wieviele_ "lauter Nullen" hast Du Dir angeschaut? Da liegt eine komplette
> Partition. Das sah nicht nach Partitionstabelle aus. Aber wenn der Start
"Spur" (der "S"-Wert in der CHS-Geometrieangabe) davor, und nur im
allerersten Sektor steht was drin, und das auch nur in den ersten beiden
Tabelleneinträgen (Adressen 446 [0x1BE]..509 [0x1FE]), und ein "Flag"-Wort
0xAA55 (oder 0x55AA, weiß ich jetzt nicht genau) auf 510 [1FE].
> natürlich nie beide gleichzeitig einbinden. Auf die primäre Partition
> sda3 sollte sich der Fehler ja nicht auswirken.
/sys/block/sda/sda?/(start|size) untereinander und - mit gleichen Einheiten
- von "fdisk -l /dev/sda" übereinstimmen.
> Mein sch... Windows, das mir das alles eingebrockt hat, funktioniert
> übrigens überhaupt nicht. Es bootet in einen Bluescreen.
offenbar nicht zurecht. Möglicherweise sind ein paar Partitionen nicht an
einer "Zylindergrenze" ausgerichtet, das könnte es verwirrt haben.
0 new messages