13.1: grub2-mkconfig erkennt OpenSuse-Factory-Version nicht

Ich hab mir die Version 20140630 heruntergeladen und sie parallel zu 13.1 installiert.
Das hat ohne Probleme funktioniert.
Die beiden Installationen sind auf unterschiedlichen Festplatten, so dass ich über das BIOS beide starten kann.

Ich habe immer eine 2. Installation auf dem Rechner, meistens - immer wenn einer der üblichen Verdächtigen ein neues Release veröffentlicht hat - jeweils das Neueste.

In 13.1 erzeuge ich dann mit grub2-mkconfig und grub2-install ein passendes grub-Menü, so dass ich die Installationen auch starten kann ohne über das BIOS zu gehen.

Mit der Factory-Version ist zum ersten Mal dieses Problem aufgetreten:

grub2-mkconfig erkennt die zweite Installation nicht.

20140630 liegt auf einer btrfs-Partition. Liegt es daran?
Die Partition habe ich in 13.1 gemountet und kann dort lesen und schreiben.

Am btrfs-Filesystem sollts eigentlich nicht liegen, denke ich.

In YaST->System->Bootloader->Bootloader-Optionen ist “Fremdes OS testen” aber schon aktiviert, oder? (bzw. “GRUB_DISABLE_OS_PROBER=false” in /etc/default/grub)
Wird die Factory-Installation von “os-prober” erkannt? Das wird nämlich von grub2-mkconfig verwendet, um die installierten Betriebssysteme zu ermitteln.
Wenn nicht wär das evtl. einen Bug-Report wert…

Notfalls könntest du dir aber einfach einen eigenen Menü-Eintrag erstellen. Trage den einfach in /boot/grub2/custom.cfg ein (die Datei anlegen falls sie noch nicht existiert), am Besten nimmst du einen existierenden aus /boot/grub2/grub.cfg her (“menuentry {…}”) und änderst ihn entsprechend.

Hallo,

die Parameter in yast und in /etc/default/grub waren richtig gesetzt. Mit os-prober habe ich ein wenig rumprobiert. Danke für den Hinweis.

Hier verschiedene Ausgaben von os-prober:

20140626:


nexus:/tmp # os-prober 
  WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!
  /dev/sdd: open failed: Kein Medium gefunden
  /dev/sde: open failed: Kein Medium gefunden
  /dev/sdf: open failed: Kein Medium gefunden
  /dev/sdg: open failed: Kein Medium gefunden
  No volume groups found
/dev/sda1:openSUSE 20140626 (x86_64):SUSE:linux
/dev/sdc1:openSUSE 13.1 (x86_64):SUSE1:linux

13.1 - btrfs auf /dev/sda1:


nexus:/tmp # os-prober
  /dev/cdrom: open failed: Kein Medium gefunden
  /dev/sdd: open failed: Kein Medium gefunden
  /dev/sde: open failed: Kein Medium gefunden
  /dev/sdf: open failed: Kein Medium gefunden
  /dev/sdg: open failed: Kein Medium gefunden
  No volume groups found

13.1 - ext4 auf /dev/sda1:


nexus:/tmp # os-prober 
  /dev/cdrom: open failed: Kein Medium gefunden
  /dev/sdd: open failed: Kein Medium gefunden
  /dev/sde: open failed: Kein Medium gefunden
  /dev/sdf: open failed: Kein Medium gefunden
  /dev/sdg: open failed: Kein Medium gefunden
  No volume groups found
/dev/sda1/:openSUSE 20140626 (x86_64):SUSE:linux

sdd bis sdg ist ein Kartenleser - ohne Karten kann dort nichts gefunden werden.

Es ist wohl so, dass os-prober unter 13.1 die btrfs-Partition nicht ausliest und dort nichts findet.
Ich habe 20140626 auf /dev/sda1 neu installiert - diesmal mit ext4 - und schon funktioniert auch grub2-mkconfig.
(auf 13.1 - bei 20140626 hat es auch mit btrfs funktioniert)

Einen Kommentar erlaube ich mir noch:
Einen Menüeintrag selbst erstellen hatte ich auch als Idee, bei grub oder lilo auch nur kurz gezuckt und es getan.
Aber die Syntax bei grub2 finde ich dermaßen kompliziert und aufgebläht, dass ich keine Lust habe, mich hiermit zu beschäftigen.
“einfach” gibt es imho bei grub2 nicht.
Wie hieß das Prinzip der Unix-Erfinder? KISS glaube ich.

Aber egal - wenn zukünftige Distributionen als zweites System auf meinem Rechner landen und sie btrfs verwenden, weiß ich was passiert.
Und ab November wird 13.2 das erste System sein und grub2-mkconfig dann wieder richtig funktionieren.

Ok, wenn os-prober die Installation nicht findet, ist natürlich klar dass kein Menüeintrag angelegt wird.
Allerdings sollte os-prober auch in 13.1 btrfs Partitionen unterstützen, die Skripts enthalten speziellen Code dafür.
Z.B. /usr/lib/os-probes/init/10filesystems ganz am Anfang:

FILESYSTEMS='ext2 ext3 ext4 reiserfs xfs jfs msdos vfat ntfs minix hfs hfsplus qnx4 ufs btrfs'

Allerdings wird das Betriebsystem anhand von verhandenen Dateien erkannt. Evtl. läuft da was schief in 13.1?
Oder os-prober ist verwirrt, weil die btrfs Partition schon gemountet ist. Probier ihn vielleicht mal zu starten nachdem du sie ungemountet hast.

Einen Kommentar erlaube ich mir noch:
Einen Menüeintrag selbst erstellen hatte ich auch als Idee, bei grub oder lilo auch nur kurz gezuckt und es getan.
Aber die Syntax bei grub2 finde ich dermaßen kompliziert und aufgebläht, dass ich keine Lust habe, mich hiermit zu beschäftigen.
“einfach” gibt es imho bei grub2 nicht.
Wie hieß das Prinzip der Unix-Erfinder? KISS glaube ich.

Naja, gar so kompliziert ist es aber auch wieder nicht. Eigentlich nicht viel anders als bei grub1, nur ist grub2 halt modularer deswegen musst du zusätzlich die notwendigen Module laden (für das Filesystem usw.).
Die Standard-Einträge, die von grub2-mkconfig erzeugt werden, sind aber natürlich flexibel gehalten, sodass sie auf allen unterstützten Betriebssystemen/Distributionen/Installationen funktionieren.

Folgendes in /boot/grub2/custom.cfg sollte einen funktionierenden Menü-Eintrag liefern:

menuentry 'openSUSE Factory' --class 'opensuse' --class gnu-linux --class gnu --class os {
        set root='hd0,msdos1'
        echo    'openSUSE Factory wird geladen …'
        linux   /boot/vmlinuz root=/dev/sda1 resume=/dev/sda2 splash=silent quiet showopts
        echo    'Initiale Ramdisk wird geladen …'
        initrd  /boot/initrd
}

Nach dem Anlegen/Ändern dieser Datei brauchst du auch nicht grub2-mkconfig aufrufen oder den Bootloader neu zu installieren, weil diese Datei dynamisch von grub.cfg geladen wird.
Nicht wirklich komplizierter als bei grub legacy, oder? :wink:

Die Partitionen und Dateinamen (und evtl. die Kernel-Optionen) musst du natürlich entsprechend anpassen (also die Zeilen mit “set root=”, “linux” und “initrd”). Wichtig ist hier dass grub2 die Partitionsnummerierung bei 1 beginnt, nicht bei 0 wie grub1. Also ist ‘hd0,msdos1’ (bzw. ‘hd0,gpt1’ wenn du GPT verwendest) die erste Partition auf der ersten Platte (/dev/sda1).
Falls du GPT statt der altmodischen msdos Partitionierung verwendest, musst du eben “gptX” statt “msdosX” in Zeile 5 schreiben.
Die “–class” Angaben in der ersten Zeile kannst du auch weglassen, die dienen nur dazu das entsprechende Icon anzuzeigen. Und die “echo” Zeilen sind sowieso überflüssig… :wink:

Je nach System können aber auch noch zusätzliche Zeilen notwendig sein:

  • “load_video” z.B. lädt den entsprechenden “Grafiktreiber”.
  • es könnte sein, dass du den Filesystemtreiber laden musst. Dazu folgende Zeile vor “set root=…” einfügen:
insmod btrfs

Bei mir wird aber beides bereits vom globalen Teil der grub.cfg erledigt.
Allerdings hab ich 13.1 mit btrfs installiert. Wenn das ein anderes Filesystem benutzt, wird btrfs wohl nicht geladen denke ich…

Außerdem gibts auch grafische Hilfsprogramme die es erlauben das Menü zu editieren, z.B.:
https://launchpad.net/grub-customizer
http://software.opensuse.org/package/grub-customizer

PS: Hier gibts eine Anleitung, wie man grub legacy’s menu.lst in eine grub.cfg umwandeln kann. Grub2 bietet scheinbar auch einen legacy Kompatibiltätsmodus, in dem man sogar die menu.lst direkt benutzen kann.
https://wiki.archlinux.org/index.php/GRUB#Converting_GRUB_Legacy.27s_config_file_to_the_new_format

Hallo,

danke für die ausführlichen Erklärungen.

Kommt aber leider zu spät. Ich habe zwar geschrieben, dass ich keine Lust habe, mich mit grub2 zu beschäftigen. Da ich aber Sachen wie “splash=silent” grundsätzlich rausschmeiße und “radeon.dpmi=1” gerne annehme, musste ich mich schon damit auseinandersetzen.
Einen Umzug auf eine neue - zusätzlich eingebaute - Festplatte war ein weiterer Grund, da sich die Reihenfolge der Platten änderte.

Zugegeben, grub2 kann wesentlich mehr als die alten bootloader grub oder lilo. Ich bleibe aber bei meiner Meinung, dass es nicht mehr “einfach” zu handhaben ist. Details, ob man mit 0 oder mit 1 anfangen muss zu zählen oder was “hd0,msdos1” bedeuten soll, meine ich damit nicht, sondern

Ein Beispiel:
Bei grub musste ich in /boot/grub an der Datei menu.lst rumfrickeln und gut war - ein beliebiger Editor reichte!

  • Bei grub2 muss ich im Verzeichnis /boot/grub2 die Datei grub.cfg mit einem Programm erzeugen, dass bei Suse grub2-mkconfig heißt und bei Debian anders, und dann das Menü mit grub2-install installieren.
  • Bearbeiten soll man die Datei grub.cfg aber nicht. Will man was ändern, muss ich in das Verzeichen /etc/default. Hier darf ich aber immerhin noch einen beliebigen Editor nehmen. Mal schauen, wann es dafür auch ein spezielles Programmm gibt wie bei MS Windows.
  • Und dann habe ich jetzt gelernt, dass es auch noch das Verzeichnis /usr/lib/os-probes gibt, wo ich notfalls was nachgucken muss (btrfs ist übrigens in der besagten Datei vorhanden)
  • Neu gelernt habe jetzt auch, dass noch weitere Dateien dynamisch geladen werden.

Übersichtlich ist was anderes!

Nächstes Beispiel:

Meine letzte menu.lst im Einsatz (Juli 2012):


nexus:/tmp # wc  /mnt/nexus/Daten/backup/nexus/conf/menu.lst
  29  152 1311 /mnt/nexus/Daten/backup/nexus/conf/menu.lst

Und zum Vergleich die aktuelle grub.cfg:


nexus:/tmp # wc /boot/grub2/grub.cfg
  267   975 11356 /boot/grub2/grub.cfg

Mit beiden Dateien kann man zwei Installationen starten.
29 zu 267 Zeilen - Noch Fragen?

Wenn man sich hauptamtlich damit beschäftigt, ist sowas irgendwann völlig normal und ganz einfach - auch ich bin nicht frei von dieser Art “Tunnelblick”.
Wenn man sich aber damit beschäftigen muss um nur ein laufendes System zu haben, damit man die Programme aufrufen kann, die man eigentlich braucht, nervt es.

Das zukünftige 13.2 werde ich jetzt nicht noch einmal installieren - wichtig sind mir die Programmversionen, die mit der nächsten Suse kommen und nicht, ob grub2 die richtigen Menüeinträge erzeugt. Und mit ext4 kann ich es jetzt ja über grub2 starten.

Aber trotzdem noch mal Danke für die Hinweise und Erklärungen.

Grüße aus der westfälischen Provinz

Das kannst du aber auch in YaST machen.

Einen Umzug auf eine neue - zusätzlich eingebaute - Festplatte war ein weiterer Grund, da sich die Reihenfolge der Platten änderte.

Normalerweise wird die Festplatte in grub.cfg über die UUID angesprochen (außer /boot) also sollte da in den meisten Fällen gar keine Änderung nötig sein.
Ansonsten kannst du ja auch einfach YaST verwenden, in so einem Fall sollte es reichen einfach “Bootloader” zu öffnen und gleich wieder auf “OK” zu klicken.

Ein Beispiel:
Bei grub musste ich in /boot/grub an der Datei menu.lst rumfrickeln und gut war - ein beliebiger Editor reichte!

Wie gesagt, ist im Prinzip bei grub2 nicht viel anders. Aber grub2 ist halt viel flexibler.

  • Bei grub2 muss ich im Verzeichnis /boot/grub2 die Datei grub.cfg mit einem Programm erzeugen, dass bei Suse grub2-mkconfig heißt und bei Debian anders, und dann das Menü mit grub2-install installieren.

grub2-install installiert den Bootloader neu.
Das brauchst du nicht, wenn du nur die grub.cfg änderst, z.B. durch Aufruf von grub2-mkconfig. Es ist ja grub, nicht lilo… :wink:

Ich weiß jetzt nicht wie grub2-mkconfig bei Debian heißt, aber ich denke grub-mkconfig. openSUSE hat halt die Programme umbenannt, weil grub1 ja auch immer noch angeboten wird.
.

  • Bearbeiten soll man die Datei grub.cfg aber nicht. Will man was ändern, muss ich in das Verzeichen /etc/default.

Ja, weil grub.cfg eben automatisch erzeugt wird, durch Skripts in /etc/grub.d/ (die kannst du übrigens auch nach deinem Geschmack ändern…)…

Du kannst grub.cfg schon per Hand ändern, aber deine Änderungen würden verloren gehen, sobald der Bootloader neu installiert wird.
Bei Updates z.B. oder wenn du YaST->Bootloader aufrufst.

Hier darf ich aber immerhin noch einen beliebigen Editor nehmen. Mal schauen, wann es dafür auch ein spezielles Programmm gibt wie bei MS Windows.

Wieso?

  • Und dann habe ich jetzt gelernt, dass es auch noch das Verzeichnis /usr/lib/os-probes gibt, wo ich notfalls was nachgucken muss (btrfs ist übrigens in der besagten Datei vorhanden)

“os-prober” ist ein eigenständiges Programm, das halt von grub2-mkconfig verwendet wird um andere Betriebssysteme zu finden…
Und wer sagt, dass du in /usr/lib/os-probes was nachgucken musst?
Ich wollte damit nur zeigen, dass btrfs an sich unterstützt werden sollte.

  • Neu gelernt habe jetzt auch, dass noch weitere Dateien dynamisch geladen werden.

Naja, die menu.lst von grub legacy wird ja auch dynamisch geladen. Das ist ja grade der Hauptvorteil von grub gegenüber lilo, oder?

Und das weitere Konfigurations-Dateien (nicht nur eine) dynamisch geladen werden, ist aber ein häufig vorhandenes Prinzip in Linux. Du hast eine Konfigurationsdatei, die vom System/der Distribution erstellt wird, die dann weitere nachlädt wo andere Pakete bzw. der Administrator eigene Sachen reinschreiben können.
Sh. z.B. /etc/profile und /etc/profile.d/, /etc/X11/xorg.conf und /etc/xorg.xorg.conf.d/, /etc/bash.bashrc und /etc/bash.bashrc.local usw.

Nächstes Beispiel:

Meine letzte menu.lst im Einsatz (Juli 2012):

nexus:/tmp # wc /mnt/nexus/Daten/backup/nexus/conf/menu.lst
29 152 1311 /mnt/nexus/Daten/backup/nexus/conf/menu.lst

Und zum Vergleich die aktuelle grub.cfg:

nexus:/tmp # wc /boot/grub2/grub.cfg
267 975 11356 /boot/grub2/grub.cfg

Mit beiden Dateien kann man zwei Installationen starten.
29 zu 267 Zeilen - Noch Fragen?

Genau deswegen wird sie ja automatisch erzeugt und ist nicht dazu gedacht von Hand geändert zu werden.
Wie gesagt, da sind einige Sachen drinnen, die du vermutlich gar nicht brauchen würdest.
Prinzipiell ist die Konfiguration nicht komplizierter als bei grub legacy, nur umfangreicher weil flexibler.

Wenn man sich hauptamtlich damit beschäftigt, ist sowas irgendwann völlig normal und ganz einfach - auch ich bin nicht frei von dieser Art “Tunnelblick”.
Wenn man sich aber damit beschäftigen muss um nur ein laufendes System zu haben, damit man die Programme aufrufen kann, die man eigentlich braucht, nervt es.

Für ein laufendes System solltest du ja normalerweise überhaupt keine Notwendigkeit haben, grub’s Konfiguration zu ändern.

So nebenbei kannst du natürlich auch immer noch grub legacy verwenden, wenn dir das lieber ist (oder sogar lilo). openSUSE enthält es ja noch.
Leider kann das aber mit btrfs überhaupt nicht umgehen… :wink:

Ach, ich gebe auf.

Wenn man das Modul nachinstalliert hat. Den Hinweis dazu habe ich übrigens von dir.

Normalerweise ist ein Wort, dass ich Verbindung mit Computer verbannt habe; allenfalls so:
Normalerweise geht es schief.
Und da ich es machen musste, ging es ja auch schief. Ist etwa 2 Jahre her, Details habe ich verdrängt.

Hurra, noch ein Verzeichnis, noch mehr Dateien zum Ändern.

Schon wieder dieses Unwort.
Und wenn man wie ich gern neue Distributionen ausprobiert, kommt man nicht umhin an der Konfiguration etwas zu ändern. Ein Test in einer virtuellen Maschine ist nicht immer eine Alternative, da ich dort eine andere “Hardware” habe.

                                                      Hier darf ich aber immerhin noch einen beliebigen Editor nehmen. Mal  schauen, wann es dafür auch ein spezielles Programmm gibt wie bei MS  Windows.                      

Wieso?

Weiß ich nicht - mal Microsoft fragen!
Aber es ist das gleiche Thema. Früher konnte man mit einem beliebige Editor auf einem beliebigen Betriebssystem die Datei boot.ini bearbeiten, die auf der Platte liegt, die unter Windows C: ist. Heute braucht man das Windows-Programm bcdedit um das Boot-Menü zu bearbeiten, das auf der versteckten reservierten System-Partition ist.

Wir sollten das jetzt mal abschließen. Ich überzeuge dich nicht, du überzeugst mich nicht - und andere wird es wahrscheinlich langweilen.
Danke für deine Bemühungen.

Keine Angst.
Ich schreib sowieso nichts mehr.

Außer diese zwei Sachen:

Wenn man das Modul nachinstalliert hat. Den Hinweis dazu habe ich übrigens von dir.

Das ist falsch.
Das YaST Bootloader Modul ist standardmäßig installiert, schon seit Ewigkeiten.

Hurra, noch ein Verzeichnis, noch mehr Dateien zum Ändern.

Du musst da gar nichts ändern.
Du kannst sie ändern, wenn du mit dem Standardverhalten nicht zufrieden bist.
Diese Dateien sind übrigens im RPM-Paket als Konfigurationsdateien gekennzeichnet, Änderungen gehen also nicht verloren, selbst wenn du grub2 updatest.

Und wie gesagt, wenn du sowas wie grub legacy haben willst, verwende eben grub legacy.
So einfach ist das.

So, jetzt schreibe ich auch nichts mehr, kein Wort!:wink:
Schrecklich, wenn zwei einfach nicht aufhören wollen.

Also, dass mit yast habe ich verwechselt, sry :shame:
Nachinstalliert habe ich Systemeinstellungen - GRUB2-Bootloader.
Ist schon eine Weile her und meine Verdrängungsleistung bei unnützen Wissen ist außerordentlich - oder nenn es Alzheimer.

Ansonsten habe ich verstanden (und nicht erst jetzt), dass man das Alles machen kann und nicht muss

Außer man will es oder es gibt irgendwelche, meinetwegen auch obskure Gründe.
DANN habe ich bei grub2 VIELE Baustellen, wie du ja oben schön dargelegt hast.
Und das ist meine Kritik, die vielen Baustellen
(um es nochmal deutlich zu machen:
ich weiß, man muss sie nicht bearbeiten, aber manchmal doch, und dieses Thema ist doch genau ein Beispiel dafür)
Und auf grub oder gar lilo zurück zu fallen, ist für mich auch keine Option, denn alles was vom Standardverhalten einer Distribution abweicht, macht nur Arbeit und ich muss mich in Sachen einarbeiten, die mich eigentlich überhaupt nicht interessieren.
Es ist ja auch das erste Mal, dass grub2 nicht funktioniert, der Grund ist gefunden und wird sich mit 13.2 in Luft auflösen.

Zumindest bei 13.1 wird grub legacy (und sogar lilo, obwohl da eine Warnung kommt) noch vollständig von YaST und perl-Bootloader unterstützt.
D.h. bei Kernel-Updates werden automatisch Einträge im Bootmenü angelegt, und du kannst die Einträge auch in YaST->System->Bootloader bearbeiten.

Das Paket “grub” wird sogar auch noch standardmäßig installiert…

Die einzige “Arbeit”, die du hast, ist in YaST bzw. /etc/sysconfig/bootloader auf “GRUB” umzustellen.

Aber wie gesagt, mit grub legacy kannst du sowieso nicht von einer btrfs Partition booten also hätte das dein ursprüngliches Problem auch nicht gelöst…