Hallo, ich nutze hier seit Jahren mit mehr oder weniger Problemen ein Fake-RAID. Probleme habe ich insbesondere mit grub2 und/oder mkinitrd. Es wird mir immer in der Datei "/boot/grub2/grub.cfg" der Pfad zu meiner HDD fehlerhaft überschrieben. Statt "/dev/disk/by-id/raid-pdc_fjjhaaib-part7" steht dann immer überall "/dev/mapper/pdc_fjjhaaib_part7". Bislang habe ich das immer nachträglich von Hand geändert bzw. wenn ich das vergessen hatte mit einer bootbaren CD nachträglich geändert. Ich habe heute seit längerem mal wieder ein zypper dup durchlaufen lassen. Ich kann mich erinnern, dass ich irgendwo etwas von "grub2" gelesen hätte. Allerdings finde ich in "/var/log/zypper.log" nichts dazu. Das Problem hat sich jedenfalls verschärft: Ich habe den Pfad - wie immer - wieder auf disk/by-id zurückgesetzt. Allerdings ist grub2 ziemlich kreativ und bringt mir als Fehlermeldung nun als showstopper "symbol `grub_term_highlight_color´ not found" und ich lande auf der grub rescue console. Eine gültige boot partition wird allerdings nicht gefunden, so dass ich nichts booten kann. Mich vor einer Nachtschicht bewahrt hat mich eine aktuelle Super Grub2 Disc. Damit kann ich in das Linux booten. Reparieren lässt sich allerdings nichts mehr. Das bringt mich auch zu einer zweiten Fehlermeldung ovn mkinitrd. Dort erhalte ich als letzte Meldung immer den Hinweis "Perl-Bootloader: 2016-02-28 20:12:32 <3> pbl-7011.2 Core::GRUB2::GrubDev2UnixDev.215: Error: did not find a match for hd0 in the device map". In der Datei "/boot/grub2/device.map" steht aber der korrekte Eintrag "(hd0) /dev/disk/by-id/raid-pdc_fjjhaaib" drin. Hat jemand Ideen, wie ich das System wieder bootbar und damit retten kann? Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 28.02.16 20:14, Alex Winzer wrote:
Hallo,
[...]
Das Problem hat sich jedenfalls verschärft: Ich habe den Pfad - wie immer - wieder auf disk/by-id zurückgesetzt. Allerdings ist grub2 ziemlich kreativ und bringt mir als Fehlermeldung nun als showstopper "symbol `grub_term_highlight_color´ not found" und ich lande auf der grub rescue console. Eine gültige boot partition wird allerdings nicht gefunden, so dass ich nichts booten kann. Mich vor einer Nachtschicht bewahrt hat mich eine aktuelle Super Grub2 Disc. Damit kann ich in das Linux booten. Reparieren lässt sich allerdings nichts mehr.
Das bringt mich auch zu einer zweiten Fehlermeldung ovn mkinitrd. Dort erhalte ich als letzte Meldung immer den Hinweis "Perl-Bootloader: 2016-02-28 20:12:32 <3> pbl-7011.2 Core::GRUB2::GrubDev2UnixDev.215: Error: did not find a match for hd0 in the device map". In der Datei "/boot/grub2/device.map" steht aber der korrekte Eintrag "(hd0) /dev/disk/by-id/raid-pdc_fjjhaaib" drin.
Hat jemand Ideen, wie ich das System wieder bootbar und damit retten kann?
Gruß, Alex
Ich habe jetzt diverse Anleitungen[1] versucht - leider ohne Erfolg. Außerdem habe ich auf einem frischen Rechner mit BIOS-Fake-RAID 2 neue HDD installiert und mein System nachgebaut mit leap 42.1. Schon nach der Installation kam das System nicht hoch. Allerdings half es hier, den Rechner mit Super Grub zu booten. Danach konnte ich mittels yast2 den grub2 neu bzw. nachinstallieren. Damit bootet dieses System. Dasselbe vorgehen klappt aber nicht auf meinem Problemrechner. Ich habe dann mittels zypper in -f sämtliche Pakete mit grub2 im Namen neu installiereren lassen. Am Ende wird offenbar (mehrfach?) "grub2-probe" aufgerufen. Dieses gibt u.a. folgende Fehlermeldung aus: device-mapper: table ioctl on pdc_fjjhaaib_part5 failed: No such device or address device-mapper: table ioctl on pdc_fjjhaaib_part5 failed: No such device or address device-mapper: table ioctl on pdc_fjjhaaib_part5 failed: No such device or address grub2-probe: error: cannot find a GRUB drive for /dev/mapper/pdc_fjjhaaib_part5. Check your device.map. Ich habe dann unter /boot/grub2/device.map nachgesehen. Dort steht nirgends mehr etwas wie "mapper". Ich benutze keine verschlüsselten Partitionen, kein loop device. Mich wundert nach wie vor, dass diese Super Grub2 Disc das System booten kann und sich dabei offensichtlich der Datei /boot/grub2/grub.cfg zur Anzeige der verfügbaren System bedient. Warum schafft es openSUSE nicht, "sich selbst" zu reparieren? Wo kann ich noch diese ominöse device.map suchen, auf die grub2-probe zugreift? [1] z.B. http://forums.opensuse.org/content.php/128-Re-install-Grub2-from-DVD-Rescue -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Alex, Am Dienstag, 1. März 2016, 08:37:24 schrieb Alex Winzer:
On 28.02.16 20:14, Alex Winzer wrote:
Hallo,
[...]
Das Problem hat sich jedenfalls verschärft: Ich habe den Pfad - wie immer - wieder auf disk/by-id zurückgesetzt. Allerdings ist grub2 ziemlich kreativ und bringt mir als Fehlermeldung nun als showstopper "symbol `grub_term_highlight_color´ not found" und ich lande auf der grub rescue console. Eine gültige boot partition wird allerdings nicht gefunden, so dass ich nichts booten kann. Mich vor einer Nachtschicht bewahrt hat mich eine aktuelle Super Grub2 Disc. Damit kann ich in das Linux booten. Reparieren lässt sich allerdings nichts mehr.
Das bringt mich auch zu einer zweiten Fehlermeldung ovn mkinitrd. Dort erhalte ich als letzte Meldung immer den Hinweis "Perl-Bootloader: 2016-02-28 20:12:32 <3> pbl-7011.2 Core::GRUB2::GrubDev2UnixDev.215: Error: did not find a match for hd0 in the device map". In der Datei "/boot/grub2/device.map" steht aber der korrekte Eintrag "(hd0) /dev/disk/by-id/raid-pdc_fjjhaaib" drin.
Hat jemand Ideen, wie ich das System wieder bootbar und damit retten kann?
Gruß, Alex
Ich habe jetzt diverse Anleitungen[1] versucht - leider ohne Erfolg. Außerdem habe ich auf einem frischen Rechner mit BIOS-Fake-RAID 2 neue HDD installiert und mein System nachgebaut mit leap 42.1. Schon nach der Installation kam das System nicht hoch. Allerdings half es hier, den Rechner mit Super Grub zu booten. Danach konnte ich mittels yast2 den grub2 neu bzw. nachinstallieren. Damit bootet dieses System. Dasselbe vorgehen klappt aber nicht auf meinem Problemrechner.
Ich habe dann mittels zypper in -f sämtliche Pakete mit grub2 im Namen neu installiereren lassen. Am Ende wird offenbar (mehrfach?) "grub2-probe" aufgerufen. Dieses gibt u.a. folgende Fehlermeldung aus:
device-mapper: table ioctl on pdc_fjjhaaib_part5 failed: No such device or address device-mapper: table ioctl on pdc_fjjhaaib_part5 failed: No such device or address device-mapper: table ioctl on pdc_fjjhaaib_part5 failed: No such device or address grub2-probe: error: cannot find a GRUB drive for /dev/mapper/pdc_fjjhaaib_part5. Check your device.map.
Ich habe dann unter /boot/grub2/device.map nachgesehen. Dort steht nirgends mehr etwas wie "mapper". Ich benutze keine verschlüsselten Partitionen, kein loop device. Mich wundert nach wie vor, dass diese Super Grub2 Disc das System booten kann und sich dabei offensichtlich der Datei /boot/grub2/grub.cfg zur Anzeige der verfügbaren System bedient. Ich habe kein RAID und verstehe das Problem leider nicht ganz. Aber das Du 'Super Grub2 Disc' verwendest und damit das System starten kanst ist gut. Erstmal eine Frage: Hast Du boot aus erweiteter Partition aktiviert (nehme mal an das müste so sein wegen part5 im Namen)? Was sagt GRUB-comandline mit dem ls Kommando. Ist dort die Partition, die Du brauchst, aufgelistet?
Warum schafft es openSUSE nicht, "sich selbst" zu reparieren? Wo kann ich noch diese ominöse device.map suchen, auf die grub2-probe zugreift?
[1] z.B. http://forums.opensuse.org/content.php/128-Re-install-Grub2-from-DVD-Rescue
Gruss Hugo M. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo und Danke für die Antwort! On 01.03.2016 13:03, Hugo wrote:
Hallo Alex, Am Dienstag, 1. März 2016, 08:37:24 schrieb Alex Winzer:
On 28.02.16 20:14, Alex Winzer wrote:
Hallo,
[...]
Ich habe jetzt diverse Anleitungen[1] versucht - leider ohne Erfolg. Außerdem habe ich auf einem frischen Rechner mit BIOS-Fake-RAID 2 neue HDD installiert und mein System nachgebaut mit leap 42.1. Schon nach der Installation kam das System nicht hoch. Allerdings half es hier, den Rechner mit Super Grub zu booten. Danach konnte ich mittels yast2 den grub2 neu bzw. nachinstallieren. Damit bootet dieses System. Dasselbe vorgehen klappt aber nicht auf meinem Problemrechner.
Leap nutzt nach zypper dup grub2-2.02~beta2-76.1. Das nur am Rande
Ich habe dann mittels zypper in -f sämtliche Pakete mit grub2 im Namen neu installiereren lassen. Am Ende wird offenbar (mehrfach?) "grub2-probe" aufgerufen. Dieses gibt u.a. folgende Fehlermeldung aus:
... auf dem Problem-Rechner.
Ich habe dann unter /boot/grub2/device.map nachgesehen. Dort steht nirgends mehr etwas wie "mapper". Ich benutze keine verschlüsselten Partitionen, kein loop device. Mich wundert nach wie vor, dass diese Super Grub2 Disc das System booten kann und sich dabei offensichtlich der Datei /boot/grub2/grub.cfg zur Anzeige der verfügbaren System bedient.
Ich habe kein RAID und verstehe das Problem leider nicht ganz. Aber das Du 'Super Grub2 Disc' verwendest und damit das System starten kanst ist gut. Erstmal eine Frage: Hast Du boot aus erweiteter Partition aktiviert (nehme mal an das müste so sein wegen part5 im Namen)?
Das kann ich Dir gar nicht sagen, leider. Das System hatte ich im Dezember 2012 als 12.2 installiert und dann jeweils mittels zypper dup "problemlos" auf 12.3 und dann auf den jetzigen Stand von 13.1 aktualisiert. Seither hatte ich nie von Hand etwas an grub verändert. Lediglich wurde mit 12.1 noch grub 0.97 - glaube ich - installiert. Später dann hatte sich grub2 drüber installiert. Die Probleme mit den fehlerhaften Einträgen (/dev/mapper/... statt /dev/disk/by-id/...) kamen irgendwann später. Und auch da habe ich mich dann nur per Hand an /boot/grub2/grub.cfg vergriffen.
Was sagt GRUB-comandline mit dem ls Kommando. Ist dort die Partition, die Du brauchst, aufgelistet?
Meinst Du auf der rescue console? Das kann ich vor Freitag Abend nicht testen. Das System läuft produktiv und ich kann es mir nicht leisten, vor dem Wochenende einen Totalausfall zu riskieren. Ich bin froh, dass es im Moment läuft. Ich meine aber mich zu erinnern, dass ein ls mir mehrere Einträge à la (hd0,msdosX) anzeigte, wobei beim X augenscheinlich alle Partitionen vertreten waren. Ich war auch guter Hoffnung, es mit der Anleitung[2] lösen zu können. Allerdings kamen dann egal bei welcher Partition und auch bei ls (hd0,msdos5)/ immer die Meldung "error: bad filename". Das wiederum hat mich beunruhigt.
Warum schafft es openSUSE nicht, "sich selbst" zu reparieren? Wo kann ich noch diese ominöse device.map suchen, auf die grub2-probe zugreift?
Ich habe jetzt ein repo gefunden, dass grub2.02 auch für 13.1 bietet und das installiert. Ich bekomme nach wie vor Fehlermeldungen bei grub2-mkconfig. Allerdings ist jetzt in der /boot/grub2/grub.cfg jetzt statt mapper automatisch wieder die UUID zur boot-Partition eingetragen. Das macht mir Hoffnung für Freitag. Außerdem habe ich jetzt gesehen, dass man scheinbar im grub rescue nicht viel verkehrt machen kann - außer dass das System weiter nicht bootet. Ich werde also mal diesem Video[3] folgend Partition 5 "reinprügeln" und testen, was passiert. Eventuell ist "bad filename" auch normal und ich hätte statt "ls (hd0,msdo5)" wie hier[4] einfach bloß "ls (hd0,msdo5)/boot" eingeben müssen. Auch das werde ich testen und dann berichten. Gruß, Alex
[1] z.B. http://forums.opensuse.org/content.php/128-Re-install-Grub2-from-DVD-Rescue [2] http://www.it-muecke.de/grub-rescue [3] https://www.youtube.com/watch?v=dPOEdBF89zw [4] https://www.youtube.com/watch?v=hjAHd0NV-c4 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Alex, Am Mittwoch, 2. März 2016, 09:24:47 schrieb Alex Winzer:
On 01.03.2016 13:03, Hugo wrote:
Hallo Alex,
Am Dienstag, 1. März 2016, 08:37:24 schrieb Alex Winzer:
On 28.02.16 20:14, Alex Winzer wrote:
Hallo,
[...]
Ich habe jetzt diverse Anleitungen[1] versucht - leider ohne Erfolg. Außerdem habe ich auf einem frischen Rechner mit BIOS-Fake-RAID 2 neue HDD installiert und mein System nachgebaut mit leap 42.1. Schon nach der Installation kam das System nicht hoch. Allerdings half es hier, den Rechner mit Super Grub zu booten. Danach konnte ich mittels yast2 den grub2 neu bzw. nachinstallieren. Damit bootet dieses System. Dasselbe vorgehen klappt aber nicht auf meinem Problemrechner.
Leap nutzt nach zypper dup grub2-2.02~beta2-76.1. Das nur am Rande Ich bestätige die grub2 Version. Bei mir ist installiert: # rpm -qa | grep grub2 grub2-snapper-plugin-2.02~beta2-76.1.noarch grub2-branding-upstream-2.02~beta2-76.1.x86_64 grub2-x86_64-efi-2.02~beta2-76.1.x86_64 kcm-grub2-0.6.4-50.1.x86_64 grub2-i386-pc-2.02~beta2-76.1.x86_64 grub2-2.02~beta2-76.1.x86_64
Ich habe dann unter /boot/grub2/device.map nachgesehen. Dort steht nirgends mehr etwas wie "mapper". Was steht da? Bei mir -dual boot - steht # more /boot/grub2/device.map (hd0) /dev/sda
Grub2 comand line startest du mit starte rechner - grub Menü kommt. Taste 'C' dücken. Siehe z.B. https://wiki.ubuntuusers.de/GRUB_2/Shell/#Kommandozeile Dort das Kommando search --fs-uuid absetzen. Ich denke, dann kannst Du sehen, was grub erwartet. Vielleicht hilft das ja.
Mich wundert nach wie vor, dass diese
Super Grub2 Disc das System booten kann und sich dabei offensichtlich der Datei /boot/grub2/grub.cfg zur Anzeige der verfügbaren System bedient. Ich denke Deine Angabe ist irgendwo falsch. Ich stelle mir vor, das super grub einfach alle möglichen Partitionen testet. Und das dann anbietet. Erstmal eine Frage: Hast Du boot aus erweiteter Partition aktiviert (nehme mal an das müste so sein wegen part5 im Namen)? Ok, muss wohl eigentlich nicht sein. Ich habe Verschiedenes probiert und jetzt geht(yast textformat) bei MIR
│Boot Loader ┌Boot Loader Location │GRUB2▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓│ [x] Boot from Master Boot Record │ │ [x] Boot from Boot Partition │ │ [x] Boot from Extended Partition │ │ [ ] Custom Boot Partition │ /dev/sda4▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ └───────────────────────────────────────────────────────────── │ │ │ [ ] Set active Flag in Partition Table for Boot Partition │ │ │ [ ] Write generic Boot Code to MBR │ und dann fuer │ [Boot Loader Installation Details] was wo0hl in der /boot/grub2/device.map steht. │
Was sagt GRUB-comandline mit dem ls Kommando. Ist dort die Partition, die Du brauchst, aufgelistet?
Meinst Du auf der rescue console?
Siehe oben!!
Das kann ich vor Freitag Abend nicht testen. Das System läuft produktiv und ich kann es mir nicht leisten, vor dem Wochenende einen Totalausfall zu riskieren. Ich bin froh, dass es im Moment läuft.
Ja, Sicherheit ist wichtig.
Warum schafft es openSUSE nicht, "sich selbst" zu reparieren? Wo kann ich noch diese ominöse device.map suchen, auf die grub2-probe zugreift?
Gute Fragen.
Ich habe jetzt ein repo gefunden, dass grub2.02 auch für 13.1 bietet und das installiert. Ich bekomme nach wie vor Fehlermeldungen bei grub2-mkconfig. Allerdings ist jetzt in der /boot/grub2/grub.cfg jetzt statt mapper automatisch wieder die UUID zur boot-Partition eingetragen. Das macht mir Hoffnung für Freitag.
Klingt gut viel Erfolg.
Außerdem habe ich jetzt gesehen, dass man scheinbar im grub rescue nicht viel verkehrt machen kann - außer dass das System weiter nicht bootet. Ich werde also mal diesem Video[3] folgend Partition 5 "reinprügeln" und testen, was passiert. Eventuell ist "bad filename" auch normal und ich hätte statt "ls (hd0,msdo5)" wie hier[4] einfach bloß "ls (hd0,msdo5)/boot" eingeben müssen. Auch das werde ich testen und dann berichten.
Gruß Hugo Mahr -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Alex, Am Mittwoch, 2. März 2016, 09:24:47 schrieb Alex Winzer:
On 01.03.2016 13:03, Hugo wrote:
Hallo Alex, Am Dienstag, 1. März 2016, 08:37:24 schrieb Alex Winzer:
On 28.02.16 20:14, Alex Winzer wrote:
Hallo,
[...] Ich habe jetzt diverse Anleitungen[1] versucht - leider ohne Erfolg. Außerdem habe ich auf einem frischen Rechner mit BIOS-Fake-RAID 2 neue HDD installiert und mein System nachgebaut mit leap 42.1. Schon nach der Installation kam das System nicht hoch. Allerdings half es hier, den Rechner mit Super Grub zu booten. Danach konnte ich mittels yast2 den grub2 neu bzw. nachinstallieren. Damit bootet dieses System. Dasselbe vorgehen klappt aber nicht auf meinem Problemrechner. Leap nutzt nach zypper dup grub2-2.02~beta2-76.1. Das nur am Rande Ich bestätige die grub2 Version. Bei mir ist installiert: # rpm -qa | grep grub2 grub2-snapper-plugin-2.02~beta2-76.1.noarch grub2-branding-upstream-2.02~beta2-76.1.x86_64 grub2-x86_64-efi-2.02~beta2-76.1.x86_64 kcm-grub2-0.6.4-50.1.x86_64 grub2-i386-pc-2.02~beta2-76.1.x86_64 grub2-2.02~beta2-76.1.x86_64 Ich habe dann unter /boot/grub2/device.map nachgesehen. Dort steht nirgends mehr etwas wie "mapper". Was steht da? Bei mir -dual boot - steht # more /boot/grub2/device.map (hd0) /dev/sda Bei mir steht dort "(hd0) /dev/disk/by-id/raid-pdc_fjjhaaib" und das
Hallo, danke erstmal für die geduldige Hilfe. On 03.03.16 12:48, Hugo wrote: passt auch.
Grub2 comand line startest du mit starte rechner - grub Menü kommt. Taste 'C' dücken. Siehe z.B. https://wiki.ubuntuusers.de/GRUB_2/Shell/#Kommandozeile
Dort das Kommando search --fs-uuid absetzen. Ich denke, dann kannst Du sehen, was grub erwartet. Vielleicht hilft das ja.
Mich wundert nach wie vor, dass diese
Super Grub2 Disc das System booten kann und sich dabei offensichtlich der Datei /boot/grub2/grub.cfg zur Anzeige der verfügbaren System bedient. Ich denke Deine Angabe ist irgendwo falsch. Ich stelle mir vor, das super grub einfach alle möglichen Partitionen testet. Und das dann anbietet. Ja und nein. Die CD liest offenbar beides. Denn anderenfalls würde er mir nicht die Namen der Menüeinträge aus /boot/grub2/grub.cfg mit "openSUSE ", "advanced options für openSUSE", "openSUSE Memtest" etc. anzeigen.
Erstmal eine Frage: Hast Du boot aus erweiteter Partition aktiviert (nehme mal an das müste so sein wegen part5 im Namen)? Ok, muss wohl eigentlich nicht sein. Ich habe Verschiedenes probiert und jetzt geht(yast textformat) bei MIR
│Boot Loader ┌Boot Loader Location │GRUB2▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓│ [x] Boot from Master Boot Record │ │ [x] Boot from Boot Partition │ │ [x] Boot from Extended Partition │ │ [ ] Custom Boot Partition │ /dev/sda4▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ └───────────────────────────────────────────────────────────── │ │ │ [ ] Set active Flag in Partition Table for Boot Partition │ │ │ [ ] Write generic Boot Code to MBR │ und dann fuer
│ [Boot Loader Installation Details] was wo0hl in der /boot/grub2/device.map steht. │
Was sagt GRUB-comandline mit dem ls Kommando. Ist dort die Partition, die Du brauchst, aufgelistet? Meinst Du auf der rescue console?
Siehe oben!!
Das kann ich vor Freitag Abend nicht testen. Das System läuft produktiv und ich kann es mir nicht leisten, vor dem Wochenende einen Totalausfall zu riskieren. Ich bin froh, dass es im Moment läuft. Ja, Sicherheit ist wichtig.
Warum schafft es openSUSE nicht, "sich selbst" zu reparieren? Wo kann ich noch diese ominöse device.map suchen, auf die grub2-probe zugreift? Gute Fragen. Ich habe jetzt ein repo gefunden, dass grub2.02 auch für 13.1 bietet und das installiert. Ich bekomme nach wie vor Fehlermeldungen bei grub2-mkconfig. Allerdings ist jetzt in der /boot/grub2/grub.cfg jetzt statt mapper automatisch wieder die UUID zur boot-Partition eingetragen. Das macht mir Hoffnung für Freitag. Klingt gut viel Erfolg. Außerdem habe ich jetzt gesehen, dass man scheinbar im grub rescue nicht viel verkehrt machen kann - außer dass das System weiter nicht bootet. Ich werde also mal diesem Video[3] folgend Partition 5 "reinprügeln" und testen, was passiert. Eventuell ist "bad filename" auch normal und ich hätte statt "ls (hd0,msdo5)" wie hier[4] einfach bloß "ls (hd0,msdo5)/boot" eingeben müssen. Auch das werde ich testen und dann berichten. Gruß Hugo Mahr
Heureka. Ich hatte es gestern Abend leider nicht mehr geschafft. Heute Morgen habe ich zur Sicherheit noch schnell Backups gemacht, falls nachher gar nichts mehr geht. Was soll ich sagen: nach dem reboot meldete sich brav das Menü von grub2 und _der Rechner fährt wieder sauber hoch_. Ich mache dennoch keinen Zusatz wie "gelöst" in den Betreff. Denn so richtig weiß ich nicht, was verändert wurde und warum es jetzt klappt. Sofern jemand desselbe Problem hat, kann er im Archiv nachlesen, dass es - zumindest bei mir - mit grub2.02 beta 2 geklappt hat. Außerdem fahre ich den Rechner jetzt nicht nochmal hoch und runter. Es wird sich also erst am nächsten Wochenende und dem nächsten reboot zeigen, ob es wirklich an dem aktuelleren grub2 gelegen haben könnte... Ich denke schon ernsthaft darüber nach ein "zypper al grub*" abzusetzen und es ist hoffentlich Ruhe. Gruß und schönes Wochenende Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (2)
-
Alex Winzer -
Hugo