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