grub einrichten

[willy4711]

Purge ist überhaupt nicht nötig. /etc/boot/grub.cfg wird jeweils neu erzeugt, wenn man update-grub ausführt. Das ist auch der Grund, warum man nicht händisch an grub.cfg rumfummeln soll, denn die Änderungen wären mit dem nächsten Kernelupdate futsch.

Na er muss ja ein update-grub ausgeführt haben, um den Inhalt seiner /etc/grub.d/40_custom in die /boot/grub/grub.cfg
zu portieren.
Und danach hatte er doppelte Einträge -----> nach meinem Verständnis wurde die /boot/grub/grub.cfg
demnach nicht neu geschrieben.

Edit und Aha :

Wenn er wirklich nur ein System hat, wäre es ja erklärlich:
Grub sieht das eigene System und schreibt es in die /boot/grub/grub.cfg dann sieht er die /etc/grub.d/40_custom ,
die Gleiches beinhaltet, und kritzelt es auch noch dazu.

[MSfree]

Und danach hatte er doppelte Einträge -----> nach meinem Verständnis wurde die /boot/grub/grub.cfg
demnach nicht neu geschrieben.

Doch, aber wiederholtes aufrufen von update-grub führt zwangsläufig auch immer wieder zum selben Ergebnis, nämlich doppelten Einträgen.

Ich weiß natürlich nicht, was da in der /etc/grub.d/40_custom steht, aber die würde ich einfach mal auf default zurücksetzen:

Code: Alles auswählen

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

und danach update-grub ausführen.

[willy4711]

Edit und Aha :

Wenn er wirklich nur ein System hat, wäre es ja erklärlich:
Grub sieht das eigene System und schreibt es in die /boot/grub/grub.cfg dann sieht er die /etc/grub.d/40_custom ,
die Gleiches beinhaltet, und kritzelt es auch noch dazu.

Irgendwo hatte er zumindest vermuten lassen, dass er die Menü Eintrage aus der grub.cfg komplett in die 40_custom
kopiert hatte, um die ’Ausgaben’ zu verändern.

Das geht netürlich nicht bei nur einem System, wenn man nicht - wie smutbert sagte:

/etc/grub.d/10_linux löschen oder in ein anderes Verzeichnis verschieben oder dieser Datei die Ausführen-Rechte entziehen.

Dann ist aber jedes mal bei einem Kernel-Update "Handbetrieb" angesagt.
Außerdem weiß ich nicht, ob das ein Update von Grub überleben würde.

[fischig]

Ich weiß natürlich nicht, was da in der /etc/grub.d/40_custom steht, aber die würde ich einfach mal auf default zurücksetzen [...] und danach update-grub ausführen.

Da drin stehen lediglich die beiden menuentry{}-Einträge, die ich aus der /boot/grub/grub.cfg hineinkopiert habe (nur so weit abgeändert, dass ich sehe, ob das was bewirkt hat). Insofern weiß ich nicht, was das bringen soll, wenn ich sie wieder entferne. Ich vermute, dann bin ich die Verdopplung los, aber einen selbstdefinierten String im Auswahlmenü wird mir das nicht bringen.
Ich meine auch, mich zu erinnern, dass dort, wo ich mal tatsächlich was zum Inhalt dieser Datei erfahren habe, explizit geschrieben wurde, dass man da nur Ergänzungen anbringen kann, zu dem was grub sowieso für richtig hält.

Meine Herren, was für ein Geraffel!

Dann ist aber jedes mal bei einem Kernel-Update "Handbetrieb" angesagt

Was ist mit „Handbetrieb“ gemeint? Dass man bei jedem neuen Kern selbigen grub bekannt machen muss, indem man update-grub ausführt? Das wäre ich von lilo gewohnt und hielte es auch für selbstverständlich. Ich muss mir nochmal durchlesen, was smutbert zu dieser 10-linux gesagt hat. Die hatte ich bisher nicht auf dem Schirm.

edit:
Ja, im Prinzip geht's nur um „Kosmetik“. Sieht halt Scheiße aus so 'ne Cinemascope-Darstellung für zwei, drei Einträge. Und die Größe des Menüs darf ich wahrscheinlich nochmal woanders konfigurieren. Wobei - ich ändere immer auch die Namen meiner vmlinuze zusammen mit ihren configs, um sie handlicher zu haben.

[smutbert]

Bei der Kosmetik könnte es ja vielleicht helfen das Menü einfach auszublenden – es gibt da diverse Optionen, dass grub zB einfach ohne Menü wartet, das Menü nur auf einen Tastendruck anzeigt und andernfalls einfach nach ein paar Sekunden den Standardmenüeintrag startet.

Alternativ gäbe es auch grub-Themes mit eigenen Hintergrundbildern, anderen Schriftarten und allem drum und dran

Meine Herren, was für ein Geraffel!

Das ist finde ich ein bisschen unfair, aber ich fürchte auch hier ist etwas der Überblick verloren gegangen. Wenn wir einen groben Überblick haben wie grub arbeitet, dann fällt es vielleicht auch leichter zu verstehen wo man wie eingreifen könnte und welche Vor- oder Nachteile das hätte:

Du weißt zweifelsohne, dass der eigentliche Kernel, der vom Bootloader geladen werden muss, gemeinsam mit einer eventuellen initrd in /boot landet, zB /boot/vmlinuz-5.10.0-5-amd64 und /boot/initrd.img-5.10.0-5-amd64

1. bei jedem Kernelupdate und jeder anderen Kernelinstallation oder -deinstallation wird nun update-grub aufgerufen.
2. update-grub ruft seinerseits der Reihe nach alle ausführbaren Dateien, typischerweise Shellskripte, in /etc/grub.d auf und erstellt anhand deren Ausgabe die grub-Konfigurationsdatei (/boot/grub/grub.cfg) neu.
3. eines dieser aufgerufenen Skripte (/etc/grub.d/10_linux) sucht nach den aktuell installierten Kerneldateien in /boot und erzeugt Menüeinträge für die gefundenden Kernel. Es ist damit für das Erstellen der Booteinträge für Debian verantwortlich.
4. andere Skripte, zum Beispiel das erwähnte /etc/grub.d/40_custom dienen dazu, dass du den automatisch erstellten Menüeinträgen eigene hinzufügen kannst.

Das Verhalten dieser Skripte lässt sich sehr stark mit /etc/default/grub beeinflussen, allerdings glaube ich nicht so, dass man allein damit in die Nähe des Ergebnisses käme, das du dir vorstellst.


Eine „richtig“ Lösung wäre es meiner Meinung nach eigentlich das Skript /etc/grub.d/10_linux (3.) so anzupassen, dass es den Menüeintrag mit dem gewünschten Namen erzeugt. Ich habe schon ein paar Mal in das Skript hineingesehen und das ist zwar nicht ganz einfach, aber es könnte bzw. sollte machbar sein.

An 4. mit eigenen Menüeinträgen einzugreifen könnte man auch. Das hast du ja schon ein Stück weit ergründet und auch gemerkt, dass die eigenen Menüeinträge zusätzlich zu den anderen Menüeinträgen erstellt werden.
Jetzt könntest du wie vorgeschlagen das Skript aus 3. lahmlegen, aber dann hast du nur die selbst erstellten Menüeinträge, die du selbst anpassen musst, wenn ein anderer Kernel installiert wird. Das müsstest du also von Hand erledigen (das ist mit Handbetrieb gemeint), wovon ich aber abraten würde, weil man das früher oder später doch einmal vergisst und dann erst einmal nicht mehr booten kann.

Es gibt da noch die eine oder andere Möglichkeit es trotzdem mit eigenen Menüeinträgen zu machen, allerdings verkneife ich mir das für diesen Beitrag, weil ich vor allem für etwas Überblick sorgen wollte.

[fischig]

Alternativ gäbe es auch grub-Themes mit eigenen Hintergrundbildern, anderen Schriftarten und allem drum und dran

Soweit will ich's gar nicht treiben, das ist mir viel zu viel Schnickschnack.

Jetzt könntest du wie vorgeschlagen das Skript aus 3. lahmlegen, aber dann hast du nur die selbst erstellten Menüeinträge, die du selbst anpassen musst, wenn ein anderer Kernel installiert wird.

So habe ich das jetzt auch eingerichtet, nachdem ich deinen Beitrag nochmal durchgesehen hatte.

Das müsstest du also von Hand erledigen (das ist mit Handbetrieb gemeint), wovon ich aber abraten würde

Warum? Das mache ich bei lilo auch nach jedem neuen Kern.
Aber ich muss sagen, gefallen tut's mir nicht. Für meine Zwecke tut lilo, was es soll, und ist deutlich einfacher einzurichten.

weil man das früher oder später doch einmal vergisst und dann erst einmal nicht mehr booten kann.

Die Gefahr sehe ich nicht, da ich immer mindestens zwei Kerne habe, und deren Booten auch überprüft habe. Wenn ich nun den nächsten neuen fehlkonfiguriert habe (lilo fällt das übrigens meistens auf), bleiben immer noch die beiden alten. Und es gibt Schlimmeres als der Ausfall des Bootloaders. Das kann man reparieren. Im übrigen ist das auch nur eine Testmaschine, ich wollte sehen, ob ich darin noch mit dosemu und DOS-Pascal ohne systemd arbeiten kann. Und ich weiß jetzt: es funktioniert noch.

OK, bei efi ist dann endgültig Schluss mit lilo. Aber bei meiner zögerlichen Grundhaltung gegenüber neuer hardware (was brauche ich denn wirklich?) bin ich ernsthaft skeptisch, ob mich das in diesem Leben überhaupt noch erreichen wird. Gibt's eigentlich schon Rechner, die efi erzwingen, also nicht optional anbieten?

Danke für den Hinweis auf 10_linux!

[smutbert]

Warum? Das mache ich bei lilo auch nach jedem neuen Kern.
Aber ich muss sagen, gefallen tut's mir nicht. Für meine Zwecke tut lilo, was es soll, und ist deutlich einfacher einzurichten.

Für mich wäre das nichts und das ist (war) aber auch bei lilo nicht das übliche Vorgehen!

Debian legt für den aktuellen und vorigen Kernel (und gegebenenfalls initrd) symbolische Links an und zwar

• /vmlinuz (und /initrd.img)
• /vmlinuz.old (und /initrd.img.old)

Trägt man diese Links statt der richtigen Kerneldateien in /boot in die lilo- oder grub-Konfiguration ein, dann muss die Konfiguration bei Kernelupdates auch nicht mehr angepasst werden. Bei grub muss dann gar nichts mehr gemacht werden, bei lilo genügt es lilo aufzurufen.


Auf das warum, kann ich auch leicht antworten:
Ich habe ein System, einen Raspberry Pi, bei dem ich mich nach jedem Kernelupdate um den Bootloader kümmern muss, genauer gesagt um das Eintragen der aktuellen initrd und ich vergesse das regelmäßig und muss das dann hinterher wieder in Ordnung bringen, damit das System bootet.
und ja, es gibt schlimmeres, aber lästig ist es trotzdem (und meiner Meinung nach weniger schlimm als ein zu langer Name eines Menüeintrags ).

[...]
OK, bei efi ist dann endgültig Schluss mit lilo. Aber bei meiner zögerlichen Grundhaltung gegenüber neuer hardware (was brauche ich denn wirklich?) bin ich ernsthaft skeptisch, ob mich das in diesem Leben überhaupt noch erreichen wird. Gibt's eigentlich schon Rechner, die efi erzwingen, also nicht optional anbieten?

ich glaube, es gibt schon uefi-Systeme, die keine BIOS-Kompatibilitätsschicht (CSM) mehr haben, aber für manche Dinge ist man Endeffekt ohnehin auf den uefi-Modus angewiesen, unabhängig davon ob es nun einen Kompatibilitätsmodus gibt oder nicht.



Mir gefällt es übrigens nicht übertrieben gut, dass die grub-Konfigurationsdatei nach jeder Kernel(de)installation neu erstellt wird, weshalb ich grub sozusagen komplett unabhängig von debian in einer eigenen Partition installiert habe.
Dann habe ich mir einmal selbst eine grub.cfg mit Menüeinträgen, die auf die oben erwähnten Links verweisen, geschrieben und habe jetzt die Menüeinträge genauso wie ich will und muss die grub-Konfiguration auch nicht anpassen.
(So eine selbst geschriebene grub.cfg kann im Gegensatz zu dem Monstrum der automatisch erstellen grub.cfg auch sehr kurz und übersichtlich sein.)

[fischig]

lästig ist es trotzdem und meiner Meinung nach jedenfalls weniger schlimm als ein zu langer Name eines Menüeintrags

Da kann ich wohl auch nach heftigem Nachdenken nicht anders, als dir zuzustimmen.

Aber es ist nicht nur die Länge, ich wähle die Einträge auch so, dass ich bei der Auswahl sehe, ob das mein eigener oder der Standardkern oder einer mit einer anderen Besonderheit ist. Das ist auch der Grund, warum ich eine Auswahl immer sehen will.

Ich habe [...] einen Raspberry Pi, bei dem ich mich nach jedem Kernelupdate um den Bootloader kümmern muss

Das ist mir in Fleisch und Blut übergegangen. Und ob ich jetzt „lilo“ oder „update-grub“ tippen muss, finde ich nicht so spannend.

Eine initrd benutze ich nicht bei meinen selbstgebauten Kernen. Das gibt einem dann auch gewisse Freiheiten udev betreffend.

Und vielleicht abschließend:

Meine Herren, was für ein Geraffel!

Das ist finde ich ein bisschen unfair, aber ich fürchte auch hier ist etwas der Überblick verloren gegangen.

In der Tat.

Aber: drei Verzeichnisse , acht Konfigurationsdateien, von denen man eine eigentlich gar nicht anrühren soll, gegenüber einer einzigen bei lilo. Mal muss man update-grub ausführen, mal nicht. Das finde ich alles schon ziemlich aufwendig, wobei ich gerne zugebe, dass ich letztlich nicht beurteilen kann, wie nötig dieser Aufwand unter Berücksichtigung aller möglichen Betriebssystemkombinationen auf einer Maschine ist. Ich fürchte, KISS ist das nicht.

[fischig]

umbenennen der vmlinuze scheint grub auch nicht besonders zu mögen. Es funktioniert, sofern man, wenn man eine initrd benutzt - und mit Debian-Standard-Kern muss man das - beide genau gleich umbenennt.