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. Ich habe daraufhin den Reparationsmodus der 11.1 gestartet und die Analysetools angeschmissen. Hier fiel mir auf, dass die (einzige) Festplatte nicht als sda sondern als sde gefunden wird. Im Bios nachgeschaut, ergab sich nichts besonderes. Festplatte und DVD-Laufwerk werden korrekt erkannt. Der Reparationsmodus (Automatik) bringt mir Meldungen, die mich etwas verwirren. Zum ersten werden alle Partitionen gefunden und mit fscheck geprüft. Es werden nur OKs ausgegeben, alles scheint in Ordnung. Ich habe dann versucht, den Bootloader (grub) neu zu installieren. Nach Neustart kommt dennoch die Meldung, kein bootbares OS gefunden! Also Reparatursystem wieder angeschmissen, diesmal den Expertenmodus. Bevor ich mir den Bootloader erneut vornehmen wollte, habe ich den Partitionscheck angeschmissen. Am Ende kam die Meldung, dass die Platte fehlerhaft ist und mir werden zwei Optionen zur Wahl gestellt: 1) "1. gefundene Partition, zum Wiederherstellen der Zylinder 0-14533 muss /dev/sde1 gelöscht werden." 2) "4. gefundene Partition, zum Wiederherstellen der Zylinder 27845-89263 muss die Partition /dev/sde2 gelöscht werden." Gleicher Wortlaut für sde2, sde3, sde6 und sde7 Mir stellt sich nun die Frage, was ich tun soll. Ich habe keine Ahnung, welche Option oben mir was bringt und welche nicht Die Platte ist eine Sata, WD 640GB und wie folgt aufgeteilt: sda1 Vista sda2 swap sda3 11.1 RC1 sda6 11.0 sda7 /home sda8 11.1 sda9 ungenutzt Obige Option 1 würde Vista wegputzen, die zweite Option mein komplettes Linux. Zwar existieren Backups der Daten, doch nicht tagesaktuell. Vista ist nur ein OEM, also ohne Datenträger und das Rettungssystem kann nicht laufen, denn ich habe die Partionen geändert. Das Bios (Amibios) bietet mir drei verschiedene Tests der Laufwerke an. Ich weiss nicht, was das für (Self-)Tests sind. Soll ich die mal anschmeissen? Soll ich ein "normalles" Rettungsssytem starten und versuchen, die Daten auf extern USB zu sichern? Wenn die Partistionstabelle hin ist, ist dann das Lesen via rsync sicher, d.h. die gelesenen Daten konsistent? Was ergibt sich aus der Tatsache, dass im Reparatursystem die Platte nicht als sda sondern als sde erkannt wird? Ich werde jetzt nichts weiter tun und mal die Antworten hier abwarten und hoffen, dass mir einer einen Hinweis geben kann, wie ich das meiste der Platteninhalte retten kann. Falls die Platte hin ist, hat sie noch Gewährleistung. Sie ist gerade ein halbes Jahr alt. Nicht gerade ein Trost. Sniff 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
Am Dienstag, 20. Januar 2009 23:16:30 schrieb Joachim Hussong:
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.
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. mfg gerd -- 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 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, Am Die, 20 Jan 2009, Joachim Hussong schrieb:
Mir stellt sich nun die Frage, was ich tun soll. Ich habe keine Ahnung, welche Option oben mir was bringt und welche nicht
Nix an der Partitionierung ändern. Grub-Config herzeigen, also den Inhalt die Ausgabe von: /etc/grub.conf /boot/grub/devices.map /boot/grub/menu.lst lsscsi
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 ;) -dnh -- +-------------------------------------------------------------------+ |-- SELF-ASSEMBLY MOEBIUS-STRIP - SEE OTHER SIDE FOR INSTRUCTIONS --| +-------------------------------------------------------------------+ -- 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
n'abend, Joachim Hussong schrieb:
Ich werde heute abend mal das normale Rettungssystem starten und da mir die Grub-Konf ankucken und ein lsscsi anschmeißen.
So, ich melde mich nun von meinem restaurierten System. Ich habe mit lsscsi im Rettungssystem nachgeschaut und es ergab [0:0:0:0] disk ATA WDC WD6400AAKS-6 01.0 /dev/sda [1:0:0:0] cd/dvd TSSTcorp CDDVDW TS-H653Q 0303 /dev/sr0 [6:0:0:0] disk Generic- Compact Flash 1.00 /dev/sdb [6:0:0:1] disk Generic- SM/xD-Picture 1.00 /dev/sdc [6:0:0:2] disk Generic- SD/MMC 1.00 /dev/sdd [6:0:0:3] disk Generic- MS/MS-Pro 1.00 /dev/sde Die HD ist also da wo sie hin muss. Danach habe ich in eine Installation in eine geeignete ungenutzte Partition reingehauen. Soweit scheint wieder alles zu gehen, mit folgenden Ausnahmen: 1) Mein Bildschirm wird mal wieder nicht erkannt. Also beginnt das Spielchen von neuem. 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. 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. 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
Moin David, 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. 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?
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. 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, 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
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? 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
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
-------- Original-Nachricht --------
Datum: Thu, 22 Jan 2009 11:10:51 +0100 Von: Joachim Hussong <suse2@jhussong.de> An: OPENSUSE_DE <opensuse-de@opensuse.org> Betreff: Re: Festplatten Crash
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. Genauser: Die Einträge in /boot/grub/menu.lst werden aktualisiert. Alle anderen Teile der Grub-Installation bleiben unverändert. 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. Wenn du, wie gewünscht, die 11.0 Installation direkt aus dem Bootmenü der 11.1 bootest, must du diesen Eintrag in die /boot/grub/menu.lst der 11.1 jedesmal bei einem Kernelupdate der 11.0 manuell nachziehen wenn den Eintrag 1:1 ( also mit versioniertem Kernel statt den Links) einträgt. Denn ein Kernelupdate der 11.0 kennt nur die nicht mehr aktive /boot/grub/menu.lst der 11.0. Deswegen auch die Lösung, das das Menü ( also die /boot/grub/menu.lst) der 11.0 nachgeladen wird und du so ein zweistufiges Menu erhälst. Solche zusätzlichen Einträge in die aktuelle /boot/grub/menu.lst haben bei mir noch nie zu einem Problem geführt, wenn ein reguläres Kernelupdate kommt. -- 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
Guten morgen allerseits, David Haller schrieb:
Das ganze ist schwieriger zu beschreiben als umzusetzen ;)
...
Ich habe gestern abend alles noch einmal durchdacht und mich für die Vorgehensweise der Bootketten entschieden. Dies wird von Suse bei der Installation und beim Reparieren auch so angelegt, doch schien mir das zunächst unpraktisch. Mich störte, dass ich dann zwei Bootmenüs habe. An die Möglichkeit den Delay der zweiten Stufe auf 0 zu setzen habe ich nicht gedacht. Manchmal sieht man eben vor lauter Bäumen die Försterin nicht mehr. Nach meinen Rettungsversuchen vorgestern abend konnte ich das System ja wieder booten und habe mich an die Umsetzung gemacht. Ich habe auch mehrmals gebootet, alles kein Problem. Am Ende waren die Booteinträge im Grub-Menu allerdings etwas zahlreich und ich habe daher die Einträge gelöscht, die ich nicht benötige. Das war z.B. der Eintrag, der 11.1 Installation, die ich nur Testweise draufgehauen hatte. Nun, was soll ich sagen? Als ich mich am Ziel wähnte und nun das finale Reboot starten wollte, fiel ich vom Stuhl. Erneut kein OS auf der Platte auffindbar! Wieder Grub-Fehler!? Grummel, System erneut aufgesetzt, diesmal wieder in eine andere noch freie Partition. Grub im Installationskonfigurationsmenu bearbeitet und System fertig und komplett installiert. Es erfolgt dabei ja kein Neustart mehr und man kann sich am Ende einloggen. Dann die Kiste rebootet und .... kein OS!! Grub-Fehler oder "Fatal Error:silly Operator" ?? Langsam habe ich den Verdacht des zweiten. Mein Verständnis vom Bootprozess ist das folgende, ich bitte um Hinweise auf den Denkfehler. 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. Man hat hier ja eine vielfältige Auswahl zwischen "MBR", "erweiterter Partition", "Boot-Partition", "Root-Partition" und noch ein paar anderen. Die 11.0 setzt sich standardmäßig in die Root-Partition, die Installation der 11.1 gab als Vorschlag immer die erweiterte Partition. Der 11.1 Vorschlag sieht dann so aus und war ursprünglich so installiert MBR -> Grub 11.1 A (erweiterte Partition ) ----> boot auf sda8 |----> Grub 11.0 (Root-Partition) -> boot auf sda6 (11.0) Dann kam der Crash. Das bedeutet, es müsste so ausgesehen haben MBR -|- Grub 11.1 A (erweiterte Partition ) ----> boot auf sda8 |----> Grub 11.0 (Root-Partition) -> boot auf sda6 (11.0) Die Verbindung zwischen MBR und Grub war wohl gekappt. Dann meine Rettungsversuche vorgestern, d.h. Neuinstallation 11.1 (B) in freie Partition, ursprüngliche 11.1 (A) belassen. MBR -> Grub 11.1 B (erweiterte Partition ) ----> boot auf sda3 (11.1 B) |----> boot auf sda8 (11.1 A) |----> Grub 11.0 (Root-Partition) -> boot auf sda6 (11.0) Der Grub 11.1 (A) müsste durch den der (B) in der erweiterten Partition überschrieben worden sein. Mehrfaches Booten war OK! Dann meine Versuche gestern abend, den Grub der B dahingehend geändert, dass er nicht mehr auf B zeigt sondern nur wieder auf A. MBR -> Grub 11.1 B (erweiterte Partition ) ----> boot auf sda8 (11.1A) |----> Grub 11.0 (Root-Partition) -> boot auf sda6 (11.0) Und dann kam nach dem Reboot kein OS MBR -|- Grub 11.1 B (erweiterte Partition ) ----> boot auf sda8 (11.1A) |----> Grub 11.0 (Root-Partition) -> boot auf sda6 (11.0) Eine Neuinstallation einer dritten 11.1 (C) hätte ergeben sollen, diesmal mit geänderter Position des ersten Grub und löschen der unnötigen Links zur 11.1A und 11.1B die standardmäßig noch vorgeschlagen wurden MBR -> Grub 11.1 C (Root Partition ) ----> boot auf sda9 (11.1C) |----> Grub 11.0 (Root-Partition) -> boot auf sda6 (11.0) Endete aber wieder in einem "kein OS". Ich habe den Verdacht, dass die Installationsroutine in bestimmten Fällen nicht wirklich den Grub Code installiert sondern nur die Konfig-Dateien ändert. Im letzten Fall könnte es so gewesen sein, dass die Installationsroutine fälschlich davon ausging, dass sie den Verweis im MBR nicht zu ändern bräuchte. Dieser war aber gebrochen und hatte nachwievor keine Verbindung zur Installation 11.1 B. 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? Ich hoffe meine Versuche, die Strukturen etwas ASCII-Grafisch zu gestalten werden einigermaßen verständlich angezeigt. 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
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 Joachim, 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. Man hat hier ja eine vielfältige Auswahl zwischen "MBR", "erweiterter Partition", "Boot-Partition", "Root-Partition" und noch ein paar anderen. Die 11.0 setzt sich standardmäßig in die Root-Partition, die Installation der 11.1 gab als Vorschlag immer die erweiterte Partition.
Du musst den GRUB (stage 1) im MBR installieren. Für nähere Info (besser kann ich es nicht beschreiben): http://de.wikipedia.org/wiki/GRUB#Funktionsweise Kleine Geschichte: Bei meinem alten PC hatte ich auch 2 Partition (3 insgesamt, wenn man die swap dazuzählt). Auf der ersten Windows und auf der zweiten GNU/Linux zu Testzwecken. GNU/Linux wurde nachträglich installiert, also inklusive Grub. Dann habe ich Windows einmal neu aufgesetzt. Neugestartet -> Grub war weg. Was ich jetzt sagen will, das Windows-Setup hat den MBR verändert. Ich könnte des ganze noch näher beschreiben, warum-wieso, aber wie gesagt obiger Link. -> Da stehts genauer. ;) 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
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
Hallo David David Haller schrieb:
Endete aber wieder in einem "kein OS".
Ich steig da (heute[1]) nicht durch...
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?
Nein, ich meinte die Auswahl bei der Grub-Installation. Da habe ich bisher immer Root-Partition eingetragen. Jetzt habe ich mal MBR probiert. Also für den Grub, der als erstes starten soll natürlich!
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).
Danke für das Angebot. Ich denke, ich habe verstanden, wie es prinzipiell tun soll. Das was ich nicht verstehe, liegt wohl am Fehlverhalten von Grub. Aber auch das Reparatursystem der Suse hat seine Macken. So bin ich heute wieder ein paar mal ins Leere gelaufen, weil offensichtlich Eingaben eigenmächtig zurückgestellt wurden. Ich wollte eigentlich meine 11.0 booten und landete immer wieder in Vista. Mir fiel dann auf, dass eine falsche Partition in der grub.conf eingetragen war. Mir ist es nicht gelungen, da was anderes einzutragen. Aus einem hd(0,5) wurde vom Reparatursystem immer wieder eigenmächtig ein hd(0,0) und das ist Vista. Auch hatte ich wieder mal "kein OS", weil da eigenmächtig ein von mir angeklicktes "in MBR installieren" in "in Boot-Partition" umgestrickt wurde. Sowas nervt unendlich, wenn man sich nicht drauf verlassen kann, dass die Eingaben so bleiben wie sie mal eingestellt waren. Ich habe nun ein Notsystem konfiguriert und mache gerade den Rest zu Fuß. Im Moment läuft alles, wie es soll. Bin mal gespannt für wie lange.
[1] bin etwas angeschlagen
Geht mir auch so. Ich bin müde und dann dieser Suse Mist. Ich mach Feierabend. Gute Nacht! 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, 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,
###Don't change this comment - YaST2 identifier: Original name: windows### title Windows rootnoverify (hd0,0) chainloader +1
Vista sitzt auf der ersten Partition der ersten und einzigen Platte, also hd(0,0)
Mein Eintrag für XP sieht so aus: title Windows XP rootnoverify (hd0,0) chainloader (hd1)+1 map (hd0) (hd1) map (hd1) (hd0) Die letzten zwei Zeilen sind nötig damit Windows startet. Hier wird Windows vorgegaukelt, dass es sich auf der primären Festplatte befindet. Wirst du aber nicht brauchen, weil dein Vista sowieso auf der 1. Partition liegt. Ich vermute, dass Grub den chainloader-Eintrag nicht mag, weil keine Festplatte/Partition angegeben ist. Ändere mal deinen Eintrag in "chainloader (hd0)+1". 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
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
Hallo, Am Sam, 24 Jan 2009, Joachim Hussong schrieb:
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.
Fehlermeldung? Ansonsten mach mal (VORSICHT! Verstehen und nicht vertippen!) dd if=/dev/sda1 count=1 | strings 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... Abhilfe: Vista CD/DVD booten, Rettungskonsole, "fixboot" (nicht fixmbr). HTH, -dnh -- Words fail me. Thank goodness I can make gestures. -- Mark Hughes -- 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
Hallo, Am Son, 25 Jan 2009, Joachim Hussong schrieb:
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
*Gwärks* Da hast du GRUB in den NTFS Bootsektor installiert...
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... [..] Abhilfe: Vista CD/DVD booten, Rettungskonsole, "fixboot" (nicht fixmbr).
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?
würde dann durch dieses fixboot der Grub auch wieder verändert?
Nein, fixboot schreibt nur den Bootsektor der Partition neu. -dnh -- Ein Hund denkt: Sie füttern mich, sie sorgen für mich, sie streicheln mich: das müssen Götter sein. Eine Katze denkt: Sie füttern mich, sie sorgen für mich, sie streicheln mich: ich muss ein Gott sein. -- Konni Scheller -- 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
Hallo, Am Son, 25 Jan 2009, Joachim Hussong schrieb:
David Haller schrieb:
*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.
ACK. Naja, ich verlasse mich eh nicht auf automatismen (und kontrolliere bei der Inst. z.B. die generierte menu.lst etc.)
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.
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? -dnh -- "I used to be better at logic problems, before I just dumped them all into TeX and let Knuth pick out the survivors." -- Plorkwort, 26 September 2004 on alt.religion.kibology -- 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
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. -dnh -- echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc -- P. Tomblin -- 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
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
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,
Joachim Hussong schrieb:
Im Bekanntenkreis war keine DVD auftreibbar. Bei meinen IT-Kollegen auch nicht. Irgendwie scheuen diese Vista wie der Teufel das Weihwasser.
Tun wir bei uns in der Firma auch ;-)
Heute in ich auf das Tool testdisk gestoßen, das es sowohl für Windows als auch Vista gibt...
Dieses Tool scheint wirlich was zu taugen. Es bietet viele Möglichkeiten die unterschiedlichsten Sachen zu reparieren.
Stimmt. Hat mir auch schon mal das Neuinstallieren erspart, als Windows (Dual-Boot-System) meinte, die Partitionsliste "korrigieren" zu müssen. Anschließend waren alle Partitionen weg und ich war kurz vor einem Wutanfall erster Klasse, als ich Testdisk auf einer Knoppix fand. 5 Minuten später war alles wieder in Butter. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@web.de / ________________________________/ -- 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
participants (9)
-
"Markus Koßmann" -
Daniel Fuhrmann -
David Haller -
Gerhard Schmidt -
Joachim Hussong -
Johannes Krottmayer -
Michael Born -
Michael Höhne -
Thomas Schirrmacher