Hallo, Am Mon, 21 Jun 2010, Sebastian Siebert schrieb:
Am 21.06.2010 21:50, schrieb David Haller:
Wenn die Partition nicht verschwunden wäre, könnte man nur die betroffene Partition ein Image abziehen. Aber da seine Partition komplett verschwunden ist, ist es ein bissle kriminell in den Partitionstabellen rumzuwuseln und dann die betreffende Partition ein Image abziehen. Man müsste sonst die Größe der Partition genau kennen, um dieses Risiko dennoch einzugehen.
Naja, Image ziehen ist ja kein Risiko. Und das Ende der Partitionen davor und danach kenn man ja. Per 'offset' beim loop-mount kann man evtl. Ungenauigkeiten ausgleichen.
Wenn man es so ausloten kann, warum nicht. Man muss nur treffen können.
Grob geschossen anhand der Zylinderangaben von fdisk -l (+1 Zylinder "Zugabe" an beiden Enden z.B.) sollte reichen ;)
Ansonsten _konnte_ man durchaus per Hand in den Partitionstabellen rumschrauben. Seit LBA48 und GPT kenn ich mich damit aber nimmer gut genug aus. Ich hab mal mit der c't 6/97, nem Taschenrechner (für bin<->hex<->dec), Stift, nem Blatt Papier, ner DOS-Bootdiskette und debug.com eine komplett überschriebene Erw. Partitionstabelle (also die einer Erw. Partition, die dann auf die folgenden log. verweist) anhand der Daten in den einzelnen Partitionen rekonstruiert. Das so reparierte System lief dann noch einige Zeit (~1 Jahr?) sauber bis zum Umzug auf die nächste Festplatte. Ich hab auch hier in der ML schon einige Male helfen können.
Was für eine Fummelei. :-) Das kriegt man heute doch bestimmt schneller hin. ;-)
Dafür lernt man nicht so viel. Wenn du mal mit debug.com, also Assembler via BIOS INT13 an deiner Platte im EPBR rumgeschrieben hast, hast du ein ganz anderes Verständnis vom Bootvorgang (modulo GPT/EFI). a100 mov ax, 1000 mov bx, 0301 mov cx, 0001 mov dx, 0080 int 13 (oder so in dem Stil ;) Auswending bekomm ich's nimmer hin, aber die c't (war IIRC doch die 5/97 (Mai halt, damals noch monatlich ;), der Folgeartikel war dann in 6/2000 IIRC, da war das mit debug.com aber IIRC nimmer mit drin, dafür anderes nützliche) hab ich noch :)
Besser wäre es jedenfalls gewesen, wenn man die Partitionstabelle von Anfang an weggesichert hätte. Dann hat man diesen Ärger hinterher nicht. :-) Meine Partitionstabelle habe ich auf meiner externen Festplatte und auf meinem Netbook gesichert. Sicher ist sicher. Ich bin in der Vergangenheit schon oft genug auf die Nase geflogen und gerade weil da was mit Windoof im Spiel war (im Moment auch noch). Aus Schaden wird man klug. ;-)
ACK. Naja, seit einiger Zeit sehen meine Partitonstabellen typischerweise so aus: # fdisk -l /dev/hdd Disk /dev/hdd: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdd1 1 60801 488384001 83 Linux Erstellt mit fdisk /dev/hdd ENTER n ENTER p ENTER ENTER ENTER v ENTER w ENTER (oder so ;), entsprechend auch bei 2 TB SATA-Platten ;)
Ist alles eine Frage der Details und der Geduld ;) BTW: auch die LILO (Tech) Doku enthält sehr viel über den Aufbau der Partitionstabellen und den Boot-Vorgang. Keine Ahnung, ob/wie das aktualisiert wurde.
LILO hat eine Doku darüber? Das schaue ich mir bei Gelegenheit genauer an.
Eine verdammt gute, aber wie aktuell die heute noch ist (bzgl. LBA48/GPT/EFI) weiß ich nicht. user.dvi / user.ps.gz ist auch sehr lesenswert. Und das README. Im Zweifelsfall tarball besorgen ;) Bei GRUB liegt (zumindest im Tarball, bin grad nicht sicher was SUSE alles mit einpackt) auch interessante Doku bei, allein die .info ist ja schon recht ausführlich bzgl. Details. Ah, und es schadet auch nicht, sich die (gut kommentierten) Quellcodes von LILO, Grub und dem Kernel mal anzugucken. Welche genau müßte ich jetzt aber wieder raussuchen. Jedenfalls: ein normaler MBR/Bootmanager macht nix anderes als vom BIOS gestartet zu werden, ggfs. ein Menü anzuzeigen (woher? s.u.), ggfs. gemäß Auswahl das richtige in den Speicher zu kloppen (typisch: Linux-Kernel oder ein Windows-Bootsektor, Grub, sonstwas per "chainloader" in grub), und den grad geladenen Code zu starten (das BIOS macht auch nix anderes: such Bootcode (Sektorende mit 0x55 0xAA) auf $FLOPPY, $USB, $SATA, $IDE in Sektor 0, klopp den Sektor ins RAM und starte den Code ;) Zumindest bei DOS-Bootkrams. EFI ist ne andere Baustelle. "Schwierig" ist, woher bekommt ein Bootmanager seine Infos, was er zu laden hat? Im MBR hat er nur 446 Bytes! Daher kommt Grub z.B. in mehreren "Stages" daher (wobei AFAIK stage1 im MBR steckt, stage1.5 im freien Bereich dahinter, dort liegen dann die FS-"Treiber", und stage2 liegt dann im FS des Install-OS). Oder so. LILO hingegen merkt sich einfach nur die Sektoradressen der zu ladenden Dateien, daher muß lilo auch jedes Mal "installiert" werden, wenn man die Konfiguration ändert, wohingegen Grub, dank der FS-Treiber aus Stage1.5 via FS seine menu.lst findet.
PS: heute nähm ich die nächstbeste Linux-Boot-CD mit vche und bc ;) (und dd/ddrescue + Backupmedium natürlich für's vorherige Image ziehen).
Äh, sicher? Ich nehme lieber mc statt vche, der bringt einen eigenen Hex-Editor mit. Die nächstbeste Linux-Boot-CD ist für mich SystemRescueCD. Da ist alles drin, was ich für die Datenrettung brauche. Ansonsten dito. ;-)
Dann versuch mal 'mcedit /dev/sda4'. Oder 'mcedit /dev/sda'. Und die SystemRescueCD ist bei mir im Zweifelsfall immer veraltet und bootet nimmer. Da nehm ich lieber die letzte {Knoppix, ac'tivaid (ex Knoppicilin), OpenSUSE,...}-DVD aus der c't (die hab ich halt abonniert, da kommen "frische" Boot-DVDs mit, ich selber brenn in dem Bereich nix mehr (auch nicht zum installieren, das läuft wie HDD oder direkt aus dem ISO, je nachdem ;)) Es gibt einen sehr guten Grund, warum ich vche (und nicht z.B. xemacs hexl-mode, mcedit, ...) genannt habe! HTH, -dnh, dem dabei einfällt, daß er für den Fall der Fälle mal gucken sollte, ob, wo und wie vche für aktuelle SUSEn gepackt wird (und es ggfs. selber zu machen ;) -- Wußtest Du, daß Menschen fliegen können? Doch wirklich. Geh auf ein hohes Gebäude, spring über das Geländer, und Du wirst sehen: es funktioniert. Völlig problemlos. Oder hat Dir schon mal jemand aus erster Hand berichtet, bei ihm habe es nicht geklappt? Siehst Du. -- Erik Meltzer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org