Hallo Gerhard, Gerhard Schmidt schrieb:

Die Festplatte ist nicht kaputt. Der Grub-Fehler hat wieder mal zugeschlagen. Workaround, der bei mir funktioniert hat: 11.1 neu durch installieren, dabei GRUB nicht anfassen, nach Installation neu starten, alles fein. Einstweilen darauf warten, dass die GRUB-Stricker sich dieses Problems annehmen.

Ich habe vorgestern einiges an Software installiert, nix jedoch am Grub geändert. ... Oder doch? Bin mir nicht mehr sicher, ob ich die Standard-Bootkonfiguration von 11.0 auf 11.1 nun vorgestern oder schon vorvorgestern gemacht habe. Verstehe ich deinen Vorschlag richtig? Installations-DVD der 11.1 rein Installieren wählen Neu installieren wählen und auch komplett neu installieren Mit Grub nicht anfassen, meinst du keine Rettungsversuche starten sondern die Grub Installation der 11.1 im Rahmen der normalen Installation laufen lassen? Nun, den Grub habe ich leider schon versucht neu anzulegen. Das Reparationstool bot mir eine neue Grub-Konf an, die zwar nicht meiner alten entsprach aber ich hoffte damit wenigstens das System wieder hoch zu kriegen. Hat aber nichts gebracht. Wenn nur der Grub nen Schuss hat, müsste das doch so gehen? Kann natürlich sein, dass wegen de falschen Plattenerkennung in Grub jetzt falsche Partitionen stehen. Und warum bringt er mir eine inkonsistente Partitionierung, nur wenn grub kaputt ist? Hast du eine Quelle, wo ich näheres über "den Grub-Fehler" mal nachlesen kann. Gruß Joachim -- 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

Hallo David, David Haller schrieb:

...

Was ergibt sich aus der Tatsache, dass im Reparatursystem die Platte nicht als sda sondern als sde erkannt wird?

[das laß ich einfach mal so stehen wg. Kontext zu lsscsi]

Nix. Knoppix z.B. lädt bei mir die Treiber auch in der falschen Reihenfolge, somit sind sda-sdf im Knoppix sde-sdj und sdg-sdj sind sda-sdd. Muß man (wie ich für's Image-ziehen vor dem Upgrade auf 11.1) eben umdenken ;)

Wie in meiner anderen Antwort auf Gerhard schon geschrieben, könnte das ein Grund sein, dass das Reparationstool eine falsche Grub-Konf vorschlägt. Leider habe ich da nicht im Detail reingeschaut, da ich da noch von ausging, dass es "nur" der Grub ist. Als dann noch die Partitionsierung als fehlerhaft bemeckert wurde, habe ich erstmal die Arbeiten eingestellt. Ich werde heute abend mal das normale Rettungssystem starten und da mir die Grub-Konf ankucken und ein lsscsi anschmeißen. Gruß Joachim -- 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

Hallo, Am Mit, 21 Jan 2009, Joachim Hussong schrieb: [..]

Die HD ist also da wo sie hin muss.

Gut.

2) Der Grub bietet mir alle Partitionen zum Booten an, die es gibt, da ist nix falsch dran. Nur wenn ich eine Bootpartition, z.B. meine eigentliche 11.1 oder 11.0, dann bootet er nicht sofort sondern bringt einen weiteren Grub hoch.

Es bleiben zwei Fragen:

1) wie kriege ich die unterschiedlichen Grub-Einträge wieder einheitlich hin? In jeder Bootpartition liegen nun grub.conf und alles anderen. Ich hätte natürlich nur einen, von dem aus ich alle booten kann.

Der im MBR scheint aus "chainloader" Einträgen zu bestehen, die jew. einen Grub in der jew. Partition starten. Grobes Vorgehen, für den Direktstart: Such dir einen Grub aus, der im MBR ist oder reinsoll, und füge in dessen menu.lst (erkennbar an den chainloader-Einträgen) die jew. gewollten Abschnitte aus den anderen menu.lst ein. Du mußt allerdings darauf achten, die (hdX,Y) Einträge anzupassen _FALLS_ die device.map der divseren Grubs voneinander abweichen.

2) was ist nun mit den Fehlermeldungen, die im Reparaturmodus von der Partitionstabelle gemeldet wurden? Ist die Partitionstabelle OK oder doch kaputt. Alle fsck waren erfolgeich, d.h. es wurden keine Fehler gefunden.

Das Tool (gpart?) sucht einfach auf der Platte nach Dateisystemsignaturen, das können aber auch einfach nicht überschriebene Reste von älteren Partitionen sein, somit werden dann "Geisterpartitionen" gefunden, die "quer" über den aktuellen Partitionen liegen. Kurz: vergiss es, scheint alles in Ordnung zu sein. Zeig aber zur Sicherheit nochmal die Ausgabe von fdisk -l. -dnh -- When I woke up this morning, the cat was barfing on me. Things have gone downhill since then. -- Michel Buijsman -- 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

Hallo, Hab zwar nicht Alles gelesen... Joachim Hussong schrieb:

Sowas habe ich mir gedacht. Nur, wie schaffe ich es, dass wenn zum Beispiel in der 11.0 ein kernel-Update gefahren wurde und da der grub angepasst wird, dass das bis zum Master-Grub durchschlägt? In jeder Installation müssten die Konfigurationsdateien identisch gehalten werden.

Verwende beim "Master-Grub" den symbolischen Link (vmlinuz und initrd). z.B.(Eintrag in menu.lst): title openSUSE 11.0 mit Symlink root (hd0,0) kernel /boot/vmlinuz root=/dev/disk/by-id/scsi-SATA_Hitachi_HDP7250_GEA530RE2KBAWE-part1 resume=/dev/sda2 splash=silent showopts vga=0x31a initrd /boot/initrd Also: "kernel /boot/vmlinuz-2.6.25.20-0.1-default" in "kernel /boot/vmlinuz" und initrd /boot/initrd-2.6.25.20-0.1-default in "initrd /boot/initrd" ändern. Dann ist es egal sein, wenn ein Kernel Update durchgeführt wurde. Funktioniert wunderbar. ;)

Wenn ich zwei Installationen wirklich mit einem Grub booten will, dann müssten die /boot-Verzeichnisse beider Installationen physikalisch identisch sein, d.h. ich müsste mir eine /boot-Partition anlegen, die für beide Installationen gilt, in der alle Kernel verlinkt sind uswusf. Oder?

Nein, muss nicht. mfg Hannes -- 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

Am Donnerstag, 22. Januar 2009 11:10:51 schrieb Joachim Hussong:

Hallo Hannes,

Johannes Krottmayer schrieb:

...

Verwende beim "Master-Grub" den symbolischen Link (vmlinuz und initrd).

z.B.(Eintrag in menu.lst): title openSUSE 11.0 mit Symlink

root (hd0,0) kernel /boot/vmlinuz root=/dev/disk/by-id/scsi-SATA_Hitachi_HDP7250_GEA530RE2KBAWE-part1 resume=/dev/sda2 splash=silent showopts vga=0x31a initrd /boot/initrd

Also: "kernel /boot/vmlinuz-2.6.25.20-0.1-default" in "kernel /boot/vmlinuz" und initrd /boot/initrd-2.6.25.20-0.1-default in "initrd /boot/initrd" ändern.

Dann ist es egal sein, wenn ein Kernel Update durchgeführt wurde. Funktioniert wunderbar. ;)

ich weiß nicht, ob mich das weiter bringt.

1) Wenn über die Updatefunktion ein Kernelupdate gefahren wird, dann fummelt Yast im Grub rum und aktualisiert dort die Einträge. Das ist hier hin und wieder ein Thema, da Leute gerne Ihre Menü-Einträge in Grub selber editieren wollen und das jedesmal durch Yast wieder gebügelt wird. Auch da steht die Absicht hinter, zwei Versionen von Linux gleichzeitig und parallel installiert zu haben. Meist sind das der aktuelle Kernel und die Version vorher oder wie in meinem Fall, das aktuelle Suse Release und den Vorgänger.

2) Wenn ich "nur" zwei Kernel des selben Release parallel installiert haben will, kann ich die Kernel in eine Partition hauen, in der auch der Rest des Releases steht, denn der ist bis auf vielleicht einige wenige Kernelmodule identisch. Habe ich zwei verschiedene Releases, dann wirds komplexer, denn dann unterscheiden sich eben nicht nur einige Kernelmodule sondern wesentlich mehr. Daher reime ich mir zusammen, dass ich dann eine separate Partition /boot benötige, in der die vmlinuze und initrdse der beiden liegen. Der Rest muss daber aber für ein Release separat in anderen Partitionen liegen. Ansonsten bräuchte ich ein /etc.11.1 und ein /etc.11.0 usw.

/boot auf sda1 für beide Releases gleichzeitig / auf sda2 für eine 11.0 / auf sda3 für eine 11.1 /home auf sda4 für beide

So könnte/sollte es sein???

3) Mein aktuelles System ist durch verschiedene Problematiken nun allerdings so (ungünstig) aufgebaut, dass die jeweiligen Boot-Verzeichnisse in den Root-Partitionen mit drin liegen und daher das eine Release vom anderen nix wissen kann. Für mich bleibt die Frage unbeantwortet, wie ich es in meinem System erreichen kann, dass in einen Fall 1) ein Update der 11.0 und das rumfummeln in der Grub-conf keine Inkonsistenzen in der 11.1 erzeugen.

Wie lautet das optimale Rezept, wenn man ein zwei unterschiedliche Releases parallel installiert haben will?

Das System das bei mir hauptsächlich läuft stellt den Grub im MBR und das 2te wird über einen Chainloadereintrag im Hauptgrub mit seinem eigenen Grub, der auf der Rootpartition des 2ten Systems liegt, gestartet. Dann die Wartrezeit im 2ten Grub auf null gestellt und der Chainloadereintrag läuft praktisch durch so sieht der zusätzliche Eintrag aus (geht auch über Yast zuerstellen) title 11.1 grub rootnoverify (hd1,1) chainloader (hd1,6)+1 Daniel

Gruß

Joachim

-- 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

Hallo, Am Don, 22 Jan 2009, Joachim Hussong schrieb:

David Haller schrieb:

...

Der im MBR scheint aus "chainloader" Einträgen zu bestehen, die jew. einen Grub in der jew. Partition starten. Grobes Vorgehen, für den Direktstart: Such dir einen Grub aus, der im MBR ist oder reinsoll, und füge in dessen menu.lst (erkennbar an den chainloader-Einträgen) die jew. gewollten Abschnitte aus den anderen menu.lst ein.

Du mußt allerdings darauf achten, die (hdX,Y) Einträge anzupassen _FALLS_ die device.map der divseren Grubs voneinander abweichen

Sowas habe ich mir gedacht. Nur, wie schaffe ich es, dass wenn zum Beispiel in der 11.0 ein kernel-Update gefahren wurde und da der grub angepasst wird, dass das bis zum Master-Grub durchschlägt? In jeder Installation müssten die Konfigurationsdateien identisch gehalten werden.

Bei mir liegt eine 11.1 in sda8 und eine 11.0 in sda6. Das wären somit hd(0,7) und hd(0,5). Jetzt biege ich in der 11.1 um auf ebenfalls hd(0,5), so dass sich der 11.1er grub die Daten von der 11.0 holt. jetzt holt sich beim Start der 11.1 der Grub seine Daten aus der 11.0 und will aber dann auch hd(0,5) als Bootlaufwerk und dann gibt es ein Problem, weil da gar kein 11.1er Kernel liegt.

Irgendwie habe ich da einen Knoten im Hirn.

*Schwert für den Knoten auspack*

Wenn ich zwei Installationen wirklich mit einem Grub booten will, dann müssten die /boot-Verzeichnisse beider Installationen physikalisch identisch sein, d.h. ich müsste mir eine /boot-Partition anlegen, die für beide Installationen gilt, in der alle Kernel verlinkt sind uswusf. Oder?

Nein. Du denkst viel zu kompliziert. Du kürst _einen_ grub zum "MBR-Grub". Zu welcher Distri gehört der, der grad im MBR ist? Ansonsten nimm den der 11.1, dann kannst du den am längsten verwenden. So, und jetzt zum Vorgehen: du kopierst den Eintrag für die 11.0 in die menu.lst des "MBR-Grub". Ein Beispiel bei mir verdeutlicht es: ==== Hallerlix : /dev/hdc5 = (hd2,4) : MBR-Grub (nach /dev/hda installiert) ==== [..] title SuSE 6.2 (2.4.33.2-dnh-1, hdc5) kernel (hd2,4)/boot/bzImage-2.4.33.2-dnh-1 root=/dev/hdc5 ... # Direktstart der 9.1, Eintrag ist aus der menu.lst der 9.1 kopiert title SUSE 9.1 (final/2.6.4-52-default) kernel (hd1,2)/boot/vmlinuz root=/dev/hdb3 ... initrd (hd1,2)/boot/initrd ## Eintrag um den Grub der 9.1 zu starten, den ich auf /dev/hdb ## installiert hab title hdb-MBR (GRUB SUSE91 final) root (hd1) chainloader +1 ==== ==== SuSE 9.1 : /dev/hdb3 = (hd1,2) : GRUB SUSE91 (nach /dev/hdb installiert) ==== [..] # Eintrag der 9.1, Vorlage für den Eintrag im MBR-Grub title Linux kernel (hd1,2)/boot/vmlinuz root=/dev/hdb3 ... initrd (hd1,2)/boot/initrd ## Eintrag um den MBR-GRUB nochmal zu starten title hda-MBR root (hd0) chainloader +1 ###Don't change this comment - YaST2 identifier: Original name: failsafe### title Failsafe kernel (hd1,2)/boot/vmlinuz root=/dev/hdb3 ... initrd (hd1,2)/boot/initrd ==== Ich habe bei der Installation der 9.1 Grub auf hdb installiert (hätte auch die Rootpartition der 9.1 also hdb3 sein können, ist egal), also jedenfalls nicht in den MBR. Das ist also einer wie bei dir, den man per chainloader aus dem MBR-GRUB starten kann. Yast hat mir dann den obigen Eintrag erstellt (bzw. die äquivalente Form): ==== title Linux root (hd1,2) kernel /boot/vmlinuz root=/dev/hdb3 ... initrd /boot/initrd ==== Welche Form der Eintrag hat ist egal. Diesen Eintrag vom 9.1er Grub habe ich als einfach in die Menu.lst des MBR-Grub im "Hallerlix" kopiert. Achso, die root=/dev/... Bezeichnugen darfst du nicht ändern, die interpretiert ja schon der jew. Kernel, d.h. bei mir der Kernel der 9.1. das "root=/dev/hdb3". Nur die Grub-Bezeichnungen (hdX,Y) müßtest du anpassen, falls die device.map die Platten unterschiedlich bezeichnen. Zurück zu dir. Angenommen es ist der Grub der 11.1 der im MBR ist. Dann kopierst du den "Linux" Eintrag aus der menu.lst der 11.0, fügst ihn in die menu.lst der 11.1 ein, änderst den Titel des Eintrags (von Linux auf "SUSE 11.0" oder so), falls nötig passe die (hdX,Y) an und das war es auch schon :) Die Konfiguration des Grub der 11.0 bleibt komplett unverändert, die menu.lst der 11.1 bekommt nur einen zusätzlichen Eintrag. Das ganze ist schwieriger zu beschreiben als umzusetzen ;) Achso, bei einem Kernelupdate musst du eben evtl. den Eintrag im MBR-Grub aktualsieren, wenn du die symlinks ohne Version verwendest nicht. Ueber den 'chainloader' Eintrag kannst du aber weiterhin den Grub der Distri starten, und der wurde beim Kernelupdate ja aktualisiert. Achso, du musst halt die menu.lst des MBR-Grub vor Yast schuetzen, eine Kopie aktuell halten und dann ggfs. den neuen Eintrag uebernehmen. Das ist echt nervig an Kernelupdates...

...

Kurz: vergiss es, scheint alles in Ordnung zu sein. Zeig aber zur Sicherheit nochmal die Ausgabe von fdisk -l.

Die Ausgabe war OK. Da hatte ich schon reingekuckt.

Gut. -dnh -- Listen, three eyes, don't you try to outweird me. I get stranger things than you free with my breakfast cereal. -- Zaphod Beeblebrox -- 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

Kann das so gewesen sein? Gibt es andere Erklärungsansätze? Wäre es ratsam den Grub der ersten Stufe direkt in den MBR zu setzen? Kann man mit den Suse-Mitteln überhaupt eine Grub nachträglich von einer Stelle z.B. Root-Partition an eine andere Stelle (z.B. MBR) transferieren?

Meinem Verständnis nach geht das eigentlich gar nicht anders, als daß das Bios auf seiner 1ten Platte im MBR nachschaut und dann wird aus dem MBR der "erste Stufe" Grub gebootet. Ich denke nicht, daß du als erstes von einer Partition aus den Grub im MBR aufrufen kannst. Bei mit liegt der Grub von 11.0 im MBR und verweist dann auf den Grub von 11.1 und den Grub von ner Factory per Chainloader, die jeweils in der jeweiligen Rootpartition liegen. Ich hatte mal das Problem mit 2 Platten, das das neu aufgespielte System den MBR auf die für das Bios falsche Platte legte. Boote das 1te System aus dem Reperaturmodus und lass den Grub neu in den MBR schreiben. dann Bootest du das 2te System aus dem Reperaturmodus und läßt dessen Grub dessen Rootpartition schreiben. Dann noch einen Chainloader in den MBR Grub und fertig. -- 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

Hallo, Am Fre, 23 Jan 2009, Joachim Hussong schrieb: [..]

Bios kuckt im MBR und startet dort einen ersten Code. Wenn ich den Grub nicht im MBR installiere, muss zumindest im MBR ein Verweis auf den tatsächlichen Ort des Grub liegen.

Im MBR (im ersten Sektor der vom BIOS gestarteten Platte) muß Bootcode sein -- Grub, Lilo, andere Bootmanager, DOS oder Windows Bootcode. [..]

Endete aber wieder in einem "kein OS".

Ich steig da (heute[1]) nicht durch...

Ich habe den Verdacht, dass die Installationsroutine in bestimmten Fällen nicht wirklich den Grub Code installiert sondern nur die Konfig-Dateien ändert.

Jo, da gibt's macken. Ich laß Yast irgendwo (wo was frei ist, meist Root-Partition) hin installieren, und mach den Rest dann per Hand.

Kann das so gewesen sein? Gibt es andere Erklärungsansätze? Wäre es ratsam den Grub der ersten Stufe direkt in den MBR zu setzen?

Was willst du sonst im MBR haben? Einen DOS-Bootcode, der die aktive Partition startet und hoffen, daß dort ein GRUB sitzt?

Kann man mit den Suse-Mitteln überhaupt eine Grub nachträglich von einer Stelle z.B. Root-Partition an eine andere Stelle (z.B. MBR) transferieren?

Ja. grub-install '(hd0)' Was '(hd0)' ist, steht in Grubs device.map, die du also auch kontrollieren solltest.

Ich hoffe meine Versuche, die Strukturen etwas ASCII-Grafisch zu gestalten werden einigermaßen verständlich angezeigt.

Einfacher wäre es eindeutig benamste (also mit SUSE-Version und Root-Partition benamste) device.map, menu.lst und /etc/grub.conf zu zeigen (per PM). Schreib auch dazu, welchen Grub du in den MBR haben willst. Ich schreib dir dann nen Vorschlag (angepasste Konfigurationsdateien). -dnh [1] bin etwas angeschlagen -- Es ist heutzutage nicht einfach, eine komplette Desktop-Umgebung zu finden, die so schlank wie Emacs ist. -- Florian Diesch -- 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

n'abend, Joachim Hussong schrieb:

Danke für das Angebot. Ich denke, ich habe verstanden, wie es prinzipiell tun soll. haha, was'n Witz!

Im Moment läuft alles, wie es soll. Bin mal gespannt für wie lange.

Also jetzt weiß ich auch nicht mehr weiter. meine menu.lst sieht für Vista so aus ###Don't change this comment - YaST2 identifier: Original name: windows### title Windows rootnoverify (hd0,0) chainloader +1 und das war schon immer so! Nur klappt das jetzt nicht mehr. Mein Grub sitzt nun im MBR und wenn ich Vista auswähle, dann kommt Vista nicht hoch sondern immer nur das Bootmenu von grub. Vista sitzt auf der ersten Partition der ersten und einzigen Platte, also hd(0,0) Was hat den Grub nu mit meinem Vista gemacht? Das muss damit zu tun haben, dass Grub jetzt im MBR sitzt. Und wie krieg ich Vista wieder gestartet? Wenn ich in Yast jetzt für den Grub eine neue Konfiguration vorschlagen lasse, taucht da Vista nicht mehr auf! Kaputt? Och menno, eigentlich wollte ich mich die Tage mit was anderem beschäftigen. Gruß Joachim -- 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

Hallo, Am Sam, 24 Jan 2009, Johannes Krottmayer schrieb:

...

###Don't change this comment - YaST2 identifier: Original name: windows### title Windows rootnoverify (hd0,0) chainloader +1 [..] Ich vermute, dass Grub den chainloader-Eintrag nicht mag, weil keine Festplatte/Partition angegeben ist.

Wird doch.

Ändere mal deinen Eintrag in "chainloader (hd0)+1".

Das ist falsch. '(hd0,0)+1' wäre richtig und absolut äquivalent zu root (hd0,0) chainloader +1 Noch Fragen? -dnh --

Als Newbie möchte ich wissen ob man unter Linux Vieren befürchten muß? Rein statisch gesehen, ist die Wahrscheinlichkeit, unter Linux von einer Vier erwischt zu werden, nicht größer, als eine Null verpaßt zu bekommen. -- Christoph Lorentz in dcoulm! -- 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

Tag, David Haller schrieb:

Fehlermeldung? Ansonsten mach mal (VORSICHT! Verstehen und nicht vertippen!)

dd if=/dev/sda1 count=1 | strings

1+0 Datensätze ein 1+0 Datensätze aus 512 Bytes (512 B) kopiert, 0,0261633 s, 19,6 kB/s NTFS ZRrK D|f1 GRUB Geom Hard Disk Read Error MGR is compressed Press Ctrl+Alt+Del to restart

Wenn da u.a. "GRUB" auftaucht, hast du GRUB mal dahin installiert, bei nem Windows Bootsektor müßte IIRC der String "WINDOWS" oder "WIN" auftauchen...

Sowas dachte ich mir schon. Das muss passiert sein, als ich versucht habe, über den Reparaturmodus den Grub zu installieren. Ich hatte geschrieben, dass meine Eingaben teilweise ignoriert bzw. zurückgesetzt wurden. Gerade da wo Grub hininstalliert werden sollte wurde immer wieder zurückgesetzt. Ein hd(0,5) wurde ständig auf hd(0,0) gestellt.

Abhilfe: Vista CD/DVD booten, Rettungskonsole, "fixboot" (nicht fixmbr).

Abgesehen davon, dass ich keine Vista DVD habe, denn ich habe nur eine OEM, würde dann durch dieses fixboot der Grub auch wieder verändert? Ich hoffe mal nein, denn der Winbooter müsste doch auch am Amfang der hd(0,0) gelegen haben. Und Grub liegt nun im MBR. Ich werde mal sehen, ob in der Recovery-Sicherung von Vista ein Reparaturmodus existiert. Gruß Joachim -- 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

David Haller schrieb:

dd if=/dev/sda1 count=1 | strings

...

1+0 Datensätze ein 1+0 Datensätze aus 512 Bytes (512 B) kopiert, 0,0261633 s, 19,6 kB/s NTFS ZRrK D|f1 GRUB Geom Hard Disk Read Error MGR is compressed Press Ctrl+Alt+Del to restart

*Gwärks* Da hast du GRUB in den NTFS Bootsektor installiert...

Yepp und das mit voller NIchtabsicht! Mich ärgert, dass gerade der Reparationsmodus der Suse 11.1 wohl buggy ist. ES macht keinen Spaß, wenn man in einem Programm Eingaben macht und die verloren gehen. Und dann noch bei einer so heiklen Sache wie dem Bootmechanismus.

...

Abgesehen davon, dass ich keine Vista DVD habe, denn ich habe nur eine OEM,

Anytime Upgrade? Ansonsten sollte es auch bei der OEM die/den Rettungskonsole/-modus geben. Oder ist das so eine, die die Platte komplett überschreibt?

Ich habe von meinem Vista 64bit nur eine Recovery DVD, die ich selbst erstellt habe. Sie stellt den Zustand kurz nach dem Kauf wieder her und bügelt auch alle Partitionen platt. Diese DVD hat keinen Rettungsmodus. Man kann nur Hardware testen und eben das Recovery aufspielen. Vom Laptop meiner Frau habe ich noch eine Anytime Upgrade, doch das ist eine 32bit-Version. Joachim -- 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

n'abend, David Haller schrieb:

ACK. Naja, ich verlasse mich eh nicht auf automatismen (und kontrolliere bei der Inst. z.B. die generierte menu.lst etc.)

Bisher hatte ich da noch keine negativen Erfahrungen gemacht. Werde jetzt mal wieder besser aufpassen. Aber wer denkt denn dran, dass in einem solchen Programm, dass es nun auch schon einige Jahre gibt, ein solcher Fehler steckt. Der muss doch auffallen. Ich denke mal nicht, dass meine Version die einzige ist, die da Probleme macht. Wahrscheinlich hatte man da mal wieder was verschlimmbessert. Ich habe da nun überhaupt keine Ahnung und Erfahrung mit den Bug-Tickets. Falls hier noch jemand mitliest, der das mal testen will, kann dies gerne tun. Er/Sie muss ja nicht auf OK klicken. Es reicht, im Bootloader-Einrichtungsformular des Reparaturmodus im Teil "Abschnittsverwaltung" mit "Bearbeiten" dort Einträge ändern (ich hatte da hd(0,0) auf (hd(0,5) gesetzt) und anschließend im Teil "Boot-Loader Installation" z.B. den Ort von "Root-Partition" auf "MBR" setzen. Dann zurück. Bei mir war da jedesmal die jeweils vorher geänderte Einstellung zurückgesetzt. Wahrscheinlich passiert das beim Wechsel von einem Reiter zum anderen. Und da ich in beiden was zu ändern hatte, war nach einem OK-Klick eine der beiden Einstellungen wieder hin. Hat 'ne Weile gedauert, bis ich dahinter gestiegen bin. Habe das dann in zwei Etappen erledigt.

...

Vom Laptop meiner Frau habe ich noch eine Anytime Upgrade, doch das ist eine 32bit-Version.

Das ist doof. Ich hab keine Ahnung, ob sich fixboot bei 64bit/32bit unterscheiden, das Dateisystem ist ja das gleiche. Kannst du dir evtl. von jemandem eine DVD leihen?

In unserer IT-Abteilung hatte ich schon mal nachgefragt. Inne Firma wird aber noch ausschließlich XP gefahren ;-) Man kann sich auch einen Datenträger bei MS bestellen, gegen geringe Gebühr. Das sind dann 12,-€ und Versand kommt noch extra. Vielleicht hat ein Kollege eine DVD rumliegen. Joachim -- 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

David Haller schrieb:

Hallo,

Am Son, 25 Jan 2009, Joachim Hussong schrieb:

...

Man kann sich auch einen Datenträger bei MS bestellen, gegen geringe Gebühr. Das sind dann 12,-? und Versand kommt noch extra. Vielleicht hat ein Kollege eine DVD rumliegen.

Waren 6.90 Versandkosten, aber anscheinend hat M$ diesen Service eingestellt.

echt? Ich habe gerade folgenden Link gefunden und zumindest die Seite scheint noch aktiv! http://www.microsoft.com/windowsvista/1031/ordermedia/de-de/default.mspx Wenn ich allerdings versuche, mich durch zu hangeln, tritt ein Fehler auf, der vermuten lässt, dass der Service doch tot ist. hmm Zitat: Leider traten die folgenden Fehler auf: Windows Vista Service Pack 1-Alternativmedien bestellen Joachim -- 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

Hallo Joachim, Am Samstag, 31. Januar 2009 14:39:49 schrieb Joachim Hussong:

Support vom PC-Hersteller nix Support von Microsoft nix

Naja, die werden auch die Finanzkrise in den USA im Hinterkopf haben :)

Heute in ich auf das Tool testdisk gestoßen, das es sowohl für Windows als auch Vista gibt. Unter Linux installiert und damit mit der Kopie des Bootsektors diesen wieder hergestellt. Es läuft wieder, hurra!!

Gratuliere

Dieses Tool scheint wirlich was zu taugen. Es bietet viele Möglichkeiten die unterschiedlichsten Sachen zu reparieren. Ein Zugriff auf NTFS von Linux aus, ist praktisch und funktioniert.

Ich empfehle auch immer wieder die SGD (SuperGrubDisk) im Schreibtisch zu haben. Mit der kannste alles starten was auf dem PC mal funktioniert hatte. Gibts als CD, USB-Version und Diskette. Damit lassen sich ebenfalls Bootloader und Partitionstabellen wieder herstellen. http://www.supergrubdisk.org/ https://www.adminlife.net/tool/linux-mbr-reparieren-mit-super-grub-disk/ http://www.tecchannel.de/news/themen/linux/1769142/super_grub_disk_09745/ http://download.freenet.de/archiv_s/super_grub_disk_8741.html Gruß Thomas

Gruß

Joachim

-- 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

Hallo Joachim, ich hatte letze Woche ein ähnliches Problem mit dem XP-Bootsektor. (Hatte bei 11.1 in yast einen falschen Haken gesetzt:-( Auch booten der XP-CD half nicht, weil auch die Reparaturkonsole keine XP-Installation findet. Zum Glück bin ich dann auf meiner geliebten SystemRescueCD (www.sysresccd.org) auch auf Testdisk gestoßen. Ein tolles Tool :-) Am besten fand ich, dass es einen Textbetrachter hat, wo man sich gleichzeitig den Inhalt vom Bootsektor und Backupbootsektor einer Partition ansehen kann. Da habe ich erst gesehen, dass "Grub" am Bootsektor war... Gruß Michael Joachim Hussong schrieb:

Joachim Hussong schrieb:

...

Guten Abend allerseits,

ich sitze hier und meine Festplatte ist hin (?). Ich habe gestern einiges an Software (11.1) installiert und alles ordnungsgemäß runtergefahren. Fehlermeldungen oder ähnliches gab es nicht. Als ich heute Abend nun den Rechner wieder starten wollte, kommt die Meldung, dass kein OS gefunden werde könne.

Also nach langem hin und her, habe ich es heute geschafft.

Ursache für das Problem war letztendlich ein (unbeabsichtigtes) Überschreiben verschiedener Bootsektoren und damit der Verlust der Bootfähigkeit aller Installationen. Die Linux-Installationen konnte ich wieder herstellen, doch Vista in sda1 blieb nicht bootbar. Bei dem Versuch eine Vista DVD aufzutreiben um damit eine Wiederherstellung anzugehen schlug komplett fehl.

Im Bekanntenkreis war keine DVD auftreibbar. Bei meinen IT-Kollegen auch nicht. Irgendwie scheuen diese Vista wie der Teufel das Weihwasser. Ansonsten hatte ein Kollege ebenfalls eine OEM-Version, die mir nicht witerhelfen kann.

Support vom PC-Hersteller nix Support von Microsoft nix

Heute in ich auf das Tool testdisk gestoßen, das es sowohl für Windows als auch Vista gibt. Unter Linux installiert und damit mit der Kopie des Bootsektors diesen wieder hergestellt. Es läuft wieder, hurra!!

Dieses Tool scheint wirlich was zu taugen. Es bietet viele Möglichkeiten die unterschiedlichsten Sachen zu reparieren. Ein Zugriff auf NTFS von Linux aus, ist praktisch und funktioniert.

Gruß

Joachim

-- 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