Hi Gerd und Richi, Am 16.10.2015 um 00:51 schrieb Gerhard Schmidt:
Am Donnerstag, 15. Oktober 2015, 20:10:31 schrieb Richard Kraut:
Am Mittwoch, den 14.10.2015, 20:57 +0200 schrieb Gerhard Schmidt: [...]
Alternativ kannst Du auch alles von Hand machen. /etc/default/grub und /etc/grub.d sind Deine Freunde.
Ob man mit denen warm wird, besonders mit den Skripten, wage ich zu bezweifeln. Man wüsste aber ganz gerne, wo YaST die Einstellungen, die man in den Konfig-Menüs macht, speichert. Wenn das Klartext wäre, könnte man vielleicht draufkommen, was Schwierigkeiten macht.
Natürlich kannst Du auch die
/boot/grub/grub.cfg editieren - aber sobald der Bootloader neu geschrieben wird, bspw. bei einem Kernel-Update, gehen hier alle Deine Änderungen verloren, da die Datei neu generiert wird.
In dem Fall wäre ein Backup der grub.cfg Gerds Freund. Ich bin mir aber gar nicht sicher, ob Gerd überhaupt je ein Distri-Update machen will, wenn sie einmal läuft -- sollte er allerdings, wenigstens die zur Reparatur von Sicherheitslücken. Da kann der Kernel auch dabei sein. Dann müsste er den Eintrag des neuen Kernels in seine grub.cfg manuell übernehmen.
Möchte ich eigentlich nicht, dieses Fummeln in den Innereien.
Dann solltest Du aber die simplen Standardvorschläge des Installers akzeptieren oder nur geringfügig anpassen.
Fummele immer nur gerne an Sachen herum, die ich auch einigermaßen verstehe. Hat mir Suse so beigebracht (längere Forschungsarbeiten nach Upgrades auf neue Version).
Darin liegt der Irrtum. Wenn man die Bootloader-Konfiguration mittels YaST macht, dann versteht man nur _vermeintlich_, was man da tut. Ich halte es für eine Stärke von Linux, dass man so tief ins Innere schauen kann, wie man möchte. Nicht, dass ich falsch verstanden werde: Computer sind dazu da, möglichst viel automatisch zu erledigen, sonst käme man vor lauter Tüfteln ja nicht mehr zur produktiven Arbeit. Aber wie bei jeder Technik, die ein Werk des Menschen ist, gibt es unter manchen Bedingungen, die man nicht getestet hat, doch Fehler und somit Fragen. Und da auch Fragen menschlich ist, sollte man diesen Fragen auch selber nachgehen können und Wissen erwerben, denn: Wissen macht unabhängiger! Aber vielleicht hast Du im Vertrauen auf die SUSE-Automatiken auch die Warnung überlesen, dass diese Maßnahme ein sehr tiefer Eingriff in ein Linux-System ist und dazu führen kann, dass das System nicht mehr startet. Im schlimmsten Fall geht es nicht einmal von einer Install-DVD (Boot from Harddisk). Ich habe gerade so einen Fall, den ich hier aber nicht vertiefen will; nur soviel: GRUB 2 landet im Rescue-Modus (Prompt: "grub rescue>"), weil er aus unerfindlichen Gründen das Dateisystem, auf dem der Kernel, die grub.cfg und die *.mod-Files gespeichert sind, nicht erkennt. Dazu vielleicht später von mir noch einen eigenen Thread. Was habe ich oben mit "vermeintlichem" Verständnis gemeint? Wenn Du die Konfiguration im Modul yast-bootloader mit einer anhand des GRUB-Manual vergleichst, dann weißt was ich meine. Dazu brauchst Du Dir gar nicht das komplette Manual durchlesen, ein paar Befehle reichen (freilich gibt es mehrere Ebenen des Verständnisses; so könnte man auch den GRUB2-Code durchsehen oder debuggen). Im Netz der Netze findest Du neben dem GRUB2-Manual auch das eine oder andere Beispiel einer grub.cfg. Darin findest Du häufig benutzte GRUB-Befehle. Schau Dir auch ein paar Beispiele von Startproblemen an, dann verstehst Du Deines vielleicht ganz schnell. Man kann ja auch von fremden Fehlern lernen. Mit diesen Vorbereitungen kannst Du Dir selber eine grub.cfg basteln, die Du auch verstehst -- z.B. mit folgendem Grundgerüst für einen Boot-Menü-Eintrag: menuentry "Mein Linux" { # Ggf. GRUB-Module einlesen; nicht benötigte auskommentieren insmod ext2 # extN-Dateisysteme lesen insmod part_msdos # Alte Partitionstabelle im MBR, oder ... insmod part_gpt # ... GUID-Partitionstabelle insmod lvm # falls Kernel auf Logical Volume gespeichert # ..., und vielleicht noch andere # Ort der GRUB-Dateien und des/der Kernel setzen set root=(hd0,3) # Startmaschinerie von GRUB auf der ersten Platte und # dort auf der 3. Partition. Man beachte die nicht # einheitliche Nummerierung f. Geräte und Partitionen! # Kernel der Version n.n.n laden und starten (Root-FS auf sda3): linux /boot/vmlinuz-n.n.n root=/dev/sda3 ro quiet splash # Initrd der gleichen Version n.n.n laden initrd /boot/initrd.img-n.n.n } menuentry "Mein Windows" { # dazu möchte ich hier nichts schreiben; dazu findet man im Web und in # der Fachliteratur etliche Beispiele } Wenn Du die Startmaschinerie auf einem eigenen Dateisystem, also nicht auf dem Root-FS, hast, dann musst Du bei den Kommandos linux und initrd die Pfad-Teile /boot weglassen. Allerdings musst Du dann nach "set root=" andere Gerätenummern angeben, nämlich die, wo sich Dein *Boot*-Dateisystem befindet, z.B.: set root=(hd0,1). Dann könnte (hd0,2) eine Swap-Partition zwischen dem Boot- und dem Root-Dateisystem, letzteres auf (hd0,3), sein. Also nicht "root=(hdX,Y)" und "root=<Device-ID oder UUID der Root-Partition=...>" nach einem Befehl "linux" verwechseln! Alles, was in der von den Template-Skripten erzeugten grub.cfg vor dem ersten Menüeintrag steht und vom Template /etc/grub.d/00_header stammt, kannst Du ausprobieren, was gebraucht wird und was nicht. Letzteres auskommentieren. Dieses Vorgehen entspricht zwar nicht der Intention von openSUSE, aber Du kannst Dir so eine verhältnismäßig einfache grub.cfg schreiben und musst nicht Riesen-Shell-Skripte studieren. Wenn Du keine eigene grub.cfg willst, kannst Du eigene Menüeinträge in die Template-Datei /etc/grub.d/40_custom schreiben. Aber frag mich nicht, wie Du dann die vorherigen Menüeinträge loswirst -- vielleicht die Datei 10_linux umbenennen ohne Zahlpräfix bzw. woanders sichern und in /etc/grub.d löschen.
- Die Bootmanagerinstallation endet bei mir nun mit einer vielsagenden Fehlermeldung. Die sagt nämlich gar nix außer dass ein Fehler passiert sei.
Bei welchem Vorgang ist der Fehler aufgetreten?
Na, irgendwann beim Erzeugen der Bootloader-Konfiguration oder beim Schreiben des Bootloaders. Aber wann genau? Wer weiß das schon, denn der openSUSE-Installer bzw. das Modul yast-bootloader nennt leider wirklich keinen Grund, sondern bietet an, die Konfiguration zu wiederholen. Aber ohne die Ursache für den Fehlschlag zu kennen, probiert man mehr oder weniger ziellos herum.
Beim abschließenden Schreiben des Bootloaders mit Yast2 nach OK. Kommt so bis zu etwa 60%, dann kommt die Fehlermeldung.
Man wüsste auch gerne, was YaST gerade getan hat, wenn es den Fehler bemerkt. Dann käme man vielleicht selber auf die Fehlerursache. Bei mir lief es neulich dann durch, als ich die Installation in den MBR gewählt habe. Ich frage mich, warum man für GRUB2 die Installation in den Boot-Sektor einer Partition (Root-Partition & Boot-Partition, falls vorhanden) überhaupt wählen kann, wenn das im GRUB2-Manual ausdrücklich nicht empfohlen wird (habe ich auch erst danach gelesen). Gruß, Tom -- 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