Hallo, ein neu gekauftes Windows-Archivierungsprogramm für meine Windows-Partitionen hat mir zu meinem Entsetzen auf meiner Festplatte auch meine Linux-Partitionen mit den Arbeitsdaten zerhauen (fing plötzlich an, Größen zu ändern und die Partitionen zu verschieben, um Platz für sein "Sicherheits-Areal" zu schaffen. Den hat es dann sogar bekommen, aber weder Windows lässt sich noch starten, noch dieses Wunderprogramm, obwohl es das gerade mit seinem tollen Sicherheits-Areal angeblich können soll via Computerneustart. SuSE10.1 auf meiner 2. Festplatte sda habe ich aber retten können (Linux ist eben doch lenkbarer und robuster): Erst mein YASt-Backup eingespielt, dann noch ein bisschen rumgefeilt mit "Installation - Reparatur des Systems" und dann funktionierten auch meine Arbeitsdaten auf hda wieder. Aber ich mache mir Sorgen: Bei der Festplatte mit den zerschossenen Partitionen habe ich jetzt nämlich unterschiedliche Partitionierungsdaten zwischen YASt-Partitionierer und "fdisk -l".: Der YASt-Partitionierer sagt für hda1 = 0 -2198 hda2 = 2198 - 3766 hda4 = 3766 - 19456 extended usw fdisk -l sagt für die gleichen Partitionen für hda1 = 1 - 2336 hda2 = 2337 - 4002 hda4 = 4003 - 20673 extended usw Das sind ja erhebliche Unterschiede! Zusätzlich irritiert mich, dass unter YASt sich die Werte immer fortsetzen, also 0 - 2198, 2198-3766. Das ist auf der unbeschädigt gebliebenen Festplatte sda nicht, da ist alles ordentlich jeils um 1 erhöht, also z.B. 0-3394, 3395-3656 usw. Auf meiner sda-Platte macht mich zwar stutzig, dass fdisk -l gegenüber YASt immer um 1 abweicht also: fdisk -l = 1-3395, 3396-3657 YASt = 0-3394, 3395-3656 Das war aber glaube ich immer schon so. Meine SuSE_DVD mit dem Punkt "Installation - Reparatur des Systems" sagt zu allem nun bei jedem neuen Durchlauf euphorisch, dass trotzdem alles prima in Ordnung ist auch auf meiner hda-Platte, aber das kann ja kaum stimmen. Auch bricht es nach durchgeführter Prüfung immer plötzlich ab mit der Meldung "Bei der Installation trat ein Fehler auf" und kann überhaupt nicht sauber beendet werden. Meine Linux-Arbeitsdaten auf der zerhauenen Festplatte funktionieren zwar alle, aber diese Differenzen zwischen fdisk und YASt machen mich schon äußerst unruhig bezüglich der Datensicherheit auf meinen Arbeits-Partitionen. Soll ich nun am besten in den YASt-Partitionierer die fdisk-Daten eintragen, evtl, korrigiert um den Wert 1 wie auf meiner anderen Festplatte oder was muss ich sonst tun, um die Sicherheit für meine Arbeits-Partitionen wieder zu bekommen? Ich kann mich so ärgern, dass ich mir nicht die neuesten Ausdrucke von meinen neuen Partitionierungen neulich gemacht habe, dabei hätte ich schwören können, dass!!! Dann hätte ich alle Zahlen und Einträge nur abschreiben brauchen.... :-( So weit so schlecht und hoffentlich vielen Dank für eure Hilfe. Bernd
Hallo, Am Fre, 20 Okt 2006, Bernd Stäglich schrieb:
ein neu gekauftes Windows-Archivierungsprogramm für meine Windows-Partitionen hat mir zu meinem Entsetzen auf meiner Festplatte auch meine Linux-Partitionen mit den Arbeitsdaten zerhauen (fing plötzlich an, Größen zu ändern und die Partitionen zu verschieben, um Platz für sein "Sicherheits-Areal" zu schaffen. Den hat es dann sogar bekommen, aber weder Windows lässt sich noch starten, noch dieses Wunderprogramm, obwohl es das gerade mit seinem tollen Sicherheits-Areal angeblich können soll via Computerneustart.
*AUTSCH* Von Norton^WSymantec?
Bei der Festplatte mit den zerschossenen Partitionen habe ich jetzt nämlich unterschiedliche Partitionierungsdaten zwischen YASt-Partitionierer und "fdisk -l".:
Der YASt-Partitionierer sagt für hda1 = 0 -2198 hda2 = 2198 - 3766 hda4 = 3766 - 19456 extended usw
fdisk -l sagt für die gleichen Partitionen für hda1 = 1 - 2336 hda2 = 2337 - 4002 hda4 = 4003 - 20673 extended usw
Das sind ja erhebliche Unterschiede! Zusätzlich irritiert mich, dass unter YASt sich die Werte immer fortsetzen, also 0 - 2198, 2198-3766.
Ja, das ist bei primaeren Partitionen 1-4 flasch.
Das ist auf der unbeschädigt gebliebenen Festplatte sda nicht, da ist alles ordentlich jeils um 1 erhöht, also z.B. 0-3394, 3395-3656 usw. Auf meiner sda-Platte macht mich zwar stutzig, dass fdisk -l gegenüber YASt immer um 1 abweicht also: fdisk -l = 1-3395, 3396-3657 YASt = 0-3394, 3395-3656 Das war aber glaube ich immer schon so.
Jup. fdisk verwendet abweichend zu praktisch allen anderen Partitionierungstools einen Zaehlweise (fuer Zylinder) ab 1. Beide Angaben sind also (als) identisch (zu lesen).
Meine Linux-Arbeitsdaten auf der zerhauenen Festplatte funktionieren zwar alle, aber diese Differenzen zwischen fdisk und YASt machen mich schon äußerst unruhig bezüglich der Datensicherheit auf meinen Arbeits-Partitionen. Soll ich nun am besten in den YASt-Partitionierer die fdisk-Daten eintragen, evtl, korrigiert um den Wert 1 wie auf meiner anderen Festplatte oder was muss ich sonst tun, um die Sicherheit für meine Arbeits-Partitionen wieder zu bekommen?
Schau mal, was 'gpart' rät (am besten von einem Rettungsmedium wie Knoppix verwenden). Lass aber erstmal _nichts_ schreiben.
Ich kann mich so ärgern, dass ich mir nicht die neuesten Ausdrucke von meinen neuen Partitionierungen neulich gemacht habe, dabei hätte ich schwören können, dass!!! Dann hätte ich alle Zahlen und Einträge nur abschreiben brauchen.... :-(
Vielleicht liegt in /boot/ noch eine Kopie des MBR (=> Datum), Name waere /boot/boot.[MAJOR][MINOR]. Fuer hda also /boot/boot.0300. Wenn's vom Datum passt kann man die dortige ("primaere", MBR) Partitionstabelle auslesen: $ cat /proc/ide/hdc/geometry physical 19457/255/63 logical 19457/255/63 ### mit C / H / S $ /sbin/sfdisk -C 19457 -H 255 -S 63 -l DATEINAME Disk DATEINAME: cannot get size Disk DATEINAME: cannot get geometry read: Inappropriate ioctl for device sfdisk: read error on DATEINAME - cannot read sector ... [gekuerzt] Diese Fehlermeldungen von sfdisk sind in diesem Falle normal und kein Grund zur Sorge ;) Maile mir die Ausgabe von gpart per PM wenn diese zu gross wird (habe gpart nur mal vor Jahren gestetet, und da war die Ausgabe bei mir sehr gross, wegen vieler "Geister" ;) -dnh -- 274: Nikoma-Newsserver Museum für prähistorische Gruppen. (Ulrich Mindrup)
Hallo, Am Samstag, 21. Oktober 2006 00:31 schrieb David Haller:
Hallo,
Am Fre, 20 Okt 2006, Bernd Stäglich schrieb:
ein neu gekauftes Windows-Archivierungsprogramm für meine [..] *AUTSCH* Von Norton^WSymantec?
nein, Acronis. Das funktioniert jetzt aber wieder und auch Windows, nachdem ich das "Sicherheits-Areal" über den YASt-Partionierer gelöscht habe. SDas Programm scheint wohl insgesamt nicht so schlecht, wie ich es gemacht habe, nur eben bei der Mischung Windows/Linux muss man mit diesen Sonder-Features wohl besser aufpassen ;-)
[...]
Bei der Festplatte mit den zerschossenen Partitionen habe ich jetzt nämlich unterschiedliche Partitionierungsdaten zwischen YASt-Partitionierer und "fdisk -l".: [...] Das sind ja erhebliche Unterschiede! Zusätzlich irritiert mich, dass unter YASt sich die Werte immer fortsetzen, also 0 - 2198, 2198-3766.
Ja, das ist bei primaeren Partitionen 1-4 flasch.
Das verstehe ich nicht. Bei den primären Partitionen auf meiner heilen sda-Platte habe ich das Phänomen nicht bzw. auf der nicht-heilen hda-Platte setzt sich das Phänomen auch auf der erweiterten Partition fort?!
[...]
Meine Linux-Arbeitsdaten auf der zerhauenen Festplatte funktionieren zwar alle, aber diese Differenzen zwischen fdisk und YASt machen mich schon äußerst unruhig .... [...] Schau mal, was 'gpart' rät (am besten von einem Rettungsmedium wie Knoppix verwenden). Lass aber erstmal _nichts_ schreiben. [...] Vielleicht liegt in /boot/ noch eine Kopie des MBR (=> Datum), Name waere /boot/boot.[MAJOR][MINOR]. Fuer hda also /boot/boot.0300.
Wenn's vom Datum passt kann man die dortige ("primaere", MBR) Partitionstabelle auslesen: [...]
ok mache ich, muss für heute aber leider jetzt aus dem Haus und komme erst morgen weiter dazu. Wollte mich nur schon mal räuspern und vorab bedanken für /DeineEure bisherigen Eingänge.. Viele Grüße Bernd
Hallo, Am Sam, 21 Okt 2006, Bernd Stäglich schrieb:
Am Samstag, 21. Oktober 2006 00:31 schrieb David Haller:
Am Fre, 20 Okt 2006, Bernd Stäglich schrieb: [..]
Das sind ja erhebliche Unterschiede! Zusätzlich irritiert mich, dass unter YASt sich die Werte immer fortsetzen, also 0 - 2198, 2198-3766.
Ja, das ist bei primaeren Partitionen 1-4 flasch.
Das verstehe ich nicht. Bei den primären Partitionen auf meiner heilen sda-Platte habe ich das Phänomen nicht bzw. auf der nicht-heilen hda-Platte setzt sich das Phänomen auch auf der erweiterten Partition fort?!
Hm. Koennte auch spezifisch fuer Yast sein. Normal sollten die jew. naechste Partitionen auf dem naechsthoeheren Zylinder beginnen. Ausser bei der ersten logischen Partition ;) Beispiel: /dev/hdc1 1 13 104391 83 Linux /dev/hdc2 14 79 530145 82 Linux swap /dev/hdc3 80 19457 155653785 f Win95 Ext'd (LBA) /dev/hdc5 80 2629 20482843+ 83 Linux /dev/hdc6 2630 5179 20482843+ 83 Linux [weiter wie zw. hdc5 und hdc6] -dnh -- Oh, I am a C programmer and I'm okay I muck with indices and structs all day And when it works, I shout hoo-ray Oh, I am a C programmer and I'm okay [BSD fortune file]
Hallo David, Am Samstag, 21. Oktober 2006 00:31 schrieb David Haller:
Hallo,
Am Fre, 20 Okt 2006, Bernd Stäglich schrieb:
ein neu gekauftes Windows-Archivierungsprogramm für meine Windows-Partitionen hat mir zu meinem Entsetzen auf meiner Festplatte auch meine Linux-Partitionen mit den Arbeitsdaten zerhauen (fing plötzlich an, Größen
[...] Vielleicht liegt in /boot/ noch eine Kopie des MBR (=> Datum), Name waere /boot/boot.[MAJOR][MINOR]. Fuer hda also /boot/boot.0300.
gibt's bei mir nicht. Wenn ich in /boot das weitere Verzeichnis /boot anklicke, dann öffnet sich ein neuer Ordner /boot und immer so weiter. Ein boot.0300 ist nicht im entferntesten bei mir in Sicht :-( Es gibt in /boot aber eine Datei backup_mbr. Wenn ich die mit kwrite öffne, sieht's dann so aus: 1 � | ؉� f �# | ~ I f 1� g?u � f��� fJ � I f1�14 �� Bȃ���� � ��f� I fg^ f9�|cfVRfU A�Zf^rQfU 9�G� tBgf� gf� | gf� VRB�Z^sE��v � V�^��gv gN f f | f WRQ�YZ_s Ou�fb g} fU 9� I �| Invalid partition table No operating system Error loading operating system �� �? 1.@ -�9@ 9@ �, s $@ -� � �
Wenn's vom Datum passt kann man die dortige ("primaere", MBR) Partitionstabelle auslesen:
$ cat /proc/ide/hdc/geometry physical 19457/255/63 logical 19457/255/63 ### mit C / H / S
$ /sbin/sfdisk -C 19457 -H 255 -S 63 -l DATEINAME Disk DATEINAME: cannot get size Disk DATEINAME: cannot get geometry read: Inappropriate ioctl for device sfdisk: read error on DATEINAME - cannot read sector ... [gekuerzt]
ja das geht dann wohl alles nicht...
[...] Maile mir die Ausgabe von gpart per PM wenn diese zu gross wird (habe gpart nur mal vor Jahren gestetet, und da war die Ausgabe bei mir sehr gross, wegen vieler "Geister" ;)
ich hab mal knoppix (was ich überhaupt nicht kenne) von DVD gestartet und auf Konsole im Systemverwaltungsmodus gpart eingetippt (was ich noch viel weniger kenne). Da muss ich nun irgendwelche Optionen eingeben, sonst läuft da gar nix. Welche Option ist denn da nun die beste. Nicht dass mir nun noch was kaputt geht? Vielen Dank Bernd
Hallo, Am Son, 22 Okt 2006, Bernd Stäglich schrieb:
Am Samstag, 21. Oktober 2006 00:31 schrieb David Haller:
Hallo,
Am Fre, 20 Okt 2006, Bernd Stäglich schrieb:
ein neu gekauftes Windows-Archivierungsprogramm für meine Windows-Partitionen hat mir zu meinem Entsetzen auf meiner Festplatte auch meine Linux-Partitionen mit den Arbeitsdaten zerhauen (fing plötzlich an, Größen
[...] Vielleicht liegt in /boot/ noch eine Kopie des MBR (=> Datum), Name waere /boot/boot.[MAJOR][MINOR]. Fuer hda also /boot/boot.0300.
gibt's bei mir nicht. Wenn ich in /boot das weitere Verzeichnis /boot anklicke, dann öffnet sich ein neuer Ordner /boot und immer so weiter. Ein boot.0300 ist nicht im entferntesten bei mir in Sicht :-(
/boot/boot ist ein symlink auf "." also auf's aktuelle Verzeichnis, also /boot/.. Der ist fuer Grub wenn man /boot eine eigene Partition spendiert.
Es gibt in /boot aber eine Datei backup_mbr. Wenn ich die mit kwrite öffne,
*AUA* Aber ja, das ist ein Backup des MBR. Allerdings wohl ein ziemlich altes, das ist kein LILO oder GRUB Bootsektor. [..]
$ /sbin/sfdisk -C 19457 -H 255 -S 63 -l DATEINAME Disk DATEINAME: cannot get size Disk DATEINAME: cannot get geometry read: Inappropriate ioctl for device sfdisk: read error on DATEINAME - cannot read sector ... [gekuerzt]
ja das geht dann wohl alles nicht...
s.o. eben mit /boot/backup_mbr.
[...] Maile mir die Ausgabe von gpart per PM wenn diese zu gross wird (habe gpart nur mal vor Jahren gestetet, und da war die Ausgabe bei mir sehr gross, wegen vieler "Geister" ;)
ich hab mal knoppix (was ich überhaupt nicht kenne) von DVD gestartet und auf Konsole im Systemverwaltungsmodus gpart eingetippt (was ich noch viel weniger kenne). Da muss ich nun irgendwelche Optionen eingeben, sonst läuft da gar nix. Welche Option ist denn da nun die beste. Nicht dass mir nun noch was kaputt geht?
RTFM. Musste ich jetzt auch. Geraten: gpart -v -L /dev/hda Und nein, ich habe die manpage jetzt nicht gelesen. Ist ja nicht meine Platte die den Fehler hat. Ich habe nur kurz die Optionen ueberflogen. Und selbst wenn: wenn du ein Tool wie gpart, fdisk oder sonstwas in der Richtung verwendest musst _DU_ wissen was du tust, also verstehen was ein Befehl macht. -dnh -- "We must do something. This is something. Therefore we must do this." -- Military and Corporate Logic
Am 20.10.2006 23:57 schrieb Bernd Stäglich:
Ich kann mich so ärgern, dass ich mir nicht die neuesten Ausdrucke von meinen neuen Partitionierungen neulich gemacht habe, dabei hätte ich schwören können, dass!!! Dann hätte ich alle Zahlen und Einträge nur abschreiben brauchen.... :-(
Boote Knoppix, und starte testdisk aus einer Shell. Und schau mal was das so an Partitionen findet. Wenn es plausibel klingt dann kannst du die Partitionstabelle zurückschreiben lassen. VORSICHT: testdisk ist nicht ungefährlich. OJ -- "Tut mir leid Schatz, was hast du gesagt? Ich hab grad an Selbstmord gedacht." (Al Bundy, Staffel 1)
participants (4)
-
Bernd Stäglich -
David Haller -
Johannes Kastl -
Martin Schröder