stand alone grub

[smutbert]

Dann versuche ich beim Thema zu bleiben:

ich verwende schon einige Jahre lang einen standalone grub, auf der (einzigen) EFI System Partition und habe ihn von meinem normalen, laufenden Debian aus installiert, allerdings mit einigen anderen Optionen als @grubenlicht es vorgeschlagen hat (ESP wieder unter »/mnt« gemountet):

Code: Alles auswählen

grub-install --target=x86_64-efi --no-uefi-secure-boot --bootloader-id=grub --efi-directory=/mnt --boot-directory=/mnt

Einige der Optionen, die ich anders gewählt habe, picke ich gleich heraus:

1. normalerweise wird grub in das UEFI Bootmenü eingetragen, also in den nichtflüchtigen Speicher des Mainboards und wenn man das ganze von Debian aus macht, mit dem Namen „Debian“. Um dem Eintrag einen anderen Namen zu geben gibt es die Option --bootloader-id.
   
   Das ganze passiert aber nur, wenn das Debian bereits im UEFI-Modus gebootet ist/wird.
2. wird Debian noch nicht im UEFI-Modus gebootet, können die Optionen --removable oder --force-extra-removable helfen. Dann wird das grub-Image auf der ESP nach »/boot/efi/EFI/BOOT/BOOTX64.efi« kopiert, von wo grub dann üblicherweise auch manuell erstellten Booteintrag booten können.
3. das --boot-directory unterscheidet sich bei mir auch von grubenlichts Variante. In dem Unterverzeichnis »grub« dieses Verzeichnisses werden die weiteren Dateien (Konfigurationsdatei, grub-Module, u. s. w.) gespeichert.
   (Bei grubenlicht wie bei mir liegt alles von grub auf der ESP, nur eben bei mir in »/mnt/grub« und bei grubenlicht in »/mnt/boot/grub«.)

Ich meine es gab dann auch noch die Möglichkeit alle Funktionen und sonstigen notwendigen Dateien, inklusive der Konfigurationsdatei direkt in das grub-Image zu packen, aber erstens finde ich das nicht mehr (vielleicht habe ich mir das nur eingebildet) und zweitens wäre eine eingebettete Konfigurationsdatei in diesem Szenario ohnehin eher unpraktisch, weil man die Konfiguration vielleicht doch gelegentlich ändern will.

In der Konfigurationsdatei trage ich dann übrigens nicht direkt das Kernelimage wie /boot/vmlinuz-6.5.0-0.deb12.4-amd64 und die initrd ein sondern den symbolischen Link, der in / darauf erstellt wird (/vmlinuz und /initrd.img). Dann muss die Konfiguration nicht bei jedem Kernelupdate angepasst werden und mit dem Zusatz .old gibt es auch noch passende Links für den vorigen Kernel.

Die Konfigrationsdatei »/mnt/grub/grub.cfg« kann dann recht übersichtlich aussehen:

Code: Alles auswählen

insmod all_video
insmod part_gpt
insmod ext2
insmod gfxterm
insmod gettext

set locale_dir=$prefix/locale
set gfxmode=1920x1200
set gfxpayload=keep
set timeout=2

terminal_output gfxterm
loadfont $prefix/fonts/unicode.pf2

set uuid=uuid_des_/_Dateisystems

menuentry 'Debian GNU/Linux (bookworm)' --class debian {
	search --no-floppy --fs-uuid --set=root $uuid
	linux /vmlinuz root=UUID=$uuid ro quiet loglevel=2
	initrd /initrd.img
}

menuentry 'Firmware setup' {
	insmod efifwsetup
	fwsetup
}

menuentry 'Reboot system' --class system {
	reboot
}

Ich hoffe ich habe da jetzt keinen Fehler eingebaut, weil ich meine Konfiguration mit etwas anderen Pfaden und btrfs angepasst habe. Bei den zu ladenden Modulen (insmod ...) muss man auch aufpassen, dass man die Unterstützung für die verwendete Partitionierung, das Dateisystem, u. s. w. lädt.

[isabena]

ich verwende schon einige Jahre lang einen standalone grub, auf der (einzigen) EFI System Partition und habe ihn von meinem normalen, laufenden Debian aus installiert, ..........

vielen Dank für die ausführliche Erläuterung !

nun hätte ich dazu zwei kleine Fragen:

die Zeile im Konfigurationsskript 'set uuid=uuid_des_/_Dateisystems' steht oberhalb des menuentry-Eintrages

wenn dort die UUID des Betriebssystems, aus der ich diese stand alone grub - Partition erstelle, eingetragen wird,
bedeutet das denn nicht, daß der stand alone grub an dieses BS gebunden ist und nicht mehr aufgerufen wird, falls dieses BS einmal gelöscht wird ?

und wird die bis dato verwendete ESP einfach gelöscht ?

sorry, bin keine Expertin und versuche zu verstehen und dazuzulernen

[Livingston]

1. Die Variable uuid wird im ersten menuentry (2. Zeile) benutzt. Man könnte auch auf die Variable verzichten und den Wert dort direkt hinschreiben.
2. Wenn Du ein Betriebssystem löschst, ohne Grub anzupassen, hast Du natürlich einen Eintrag, der ins Leere geht. Das könnte Dir auch mit einer herkömlichen Grub-Installation widerfahren. Ein wenig aufpassen musst Du also auf alle Fälle und im Zweifelsfalle manuell checken, ob noch nachzuarbeiten ist.
3. Die ESP ist erst mal nix anderes als eine eigenständige Partition, in der sich Bootmanager aller Art verewigen. Grub wird niemals die komplette ESP löschen oder neuschreiben. Nur die Support-Scripte von grub nehmen hier Änderungen vor. In smutberts Beispiel kümmert sich hier grub-install mit den entsprechenden Parametern darum. Um ein Studium der Parameter kommst Du dabei leider nicht herum.

[isabena]

1.

Die Variable uuid wird im ersten menuentry (2. Zeile) benutzt

hmm -- reden wir jetzt aneinander vorbei ?

das set root=(hdx,y) od. UUID meine ich nicht sondern hier

terminal_output gfxterm
loadfont $prefix/fonts/unicode.pf2

set uuid=uuid_des_/_Dateisystems

menuentry 'Debian GNU/Linux (bookworm)' --class debian {
search --no-floppy --fs-uuid --set=root $uuid
linux /vmlinuz root=UUID=$uuid ro quiet loglevel=2
initrd /initrd.img

2.

Wenn Du ein Betriebssystem löschst, ohne Grub anzupassen, hast Du natürlich einen Eintrag, der ins Leere geht. Das könnte Dir auch mit einer herkömlichen Grub-Installation widerfahren. Ein wenig aufpassen musst Du also auf alle Fälle und im Zweifelsfalle manuell checken, ob noch nachzuarbeiten ist.

das ist ja bei jedem multiboot System so

3.

Die ESP ist erst mal nix anderes als eine eigenständige Partition, in der sich Bootmanager aller Art verewigen. Grub wird niemals die komplette ESP löschen oder neuschreiben. Nur die Support-Scripte von grub nehmen hier Änderungen vor. In smutberts Beispiel kümmert sich hier grub-install mit den entsprechenden Parametern darum. Um ein Studium der Parameter kommst Du dabei leider nicht herum.

auch da bin ich voll bei dir

Frage ist aber, ob die bisherige ESP gelöscht werden muß, oder ob es dann boot-Probleme gibt.
Zwei ESPen sind ja nicht gewollt

[Livingston]

Zu 1. Ne, genau das meine ich ja. Oben wird mit set uuid=... eine Variable namens uuid gesetzt. Später wird sie hier am Ende der 2. Zeile verwendet:

Code: Alles auswählen

menuentry 'Debian GNU/Linux (bookworm)' --class debian {
	search --no-floppy --fs-uuid --set=root $uuid

Man kann sie sich also oben sparen und im menuentry direkt schreiben:

Code: Alles auswählen

menuentry 'Debian GNU/Linux (bookworm)' --class debian {
	search --no-floppy --fs-uuid --set=root uuid_des_/_Dateisystems

[isabena]

@Livingston - danke habe ich jetzt verstanden
mit 70+ dauert es manchmal etwas länger

[isabena]

der stand alone grub ist eingerichtet und läuft insoweit;
lediglich mit der grub.cfg bin ich noch nicht so ganz klar bzgl kernelupdates
aber das wird noch -- hoffe ich jedenfalls

[isabena]

[*]eine grub.cfg anlegen in /mnt/boot (ich verwende die nur zum set root=<UUID> Verweis auf eine weitere Partition fat ohne Markierung, die ist dann leichter zu editieren (ohne root) und mit configfile /grub.cfg dann auf die verzweigen
[*]in der grub.cfg dann menuentry auf die SymLinks (vmlinuz und initrd.img) der zu startenden Systeme
[*]die Systeme jeweils mit der Installation von grub in den PBR, dann kann in der o.g. grub.cfg auch eine Eintrag wie configfile /boot/grub.cfg stehen, welcher das Menü der Installation aufruft, z.B., um andere als den aktuellen kernel zu starten. Man kann auch installieren ohne grub.
[/list]

verstehe ich das richtig, daß eine weitere Partition kreiert wird, mit FAT-Formatierung, in der letztlich die eigentliche (grub.configuration) liegt ?
mit einem Eintrag in der neu angelegten /boot/grub.cfg in Form von set root= >UUID< und configfile /grub.cfg wird darauf verwiesen ?
dann existieren anschließend zwei grub.cfg ? die sich gegenseitig nicht ausschließen oder behindern ?

wie schon geschrieben bin ich nur userin und bevor ich mein Gesamtsystem zerschieße, frage ich lieber dumm

[grubenlicht]

verstehe ich das richtig, daß eine weitere Partition kreiert wird, mit FAT-Formatierung, in der letztlich die eigentliche (grub.configuration) liegt ?

ja, allerdings ist diese 2. keineswegs notwendig, wenn du willst, schreibst du die ganzen menuentry in die erste grub.cfg (die auf der ESP). Weil man aber diese nur mit root Rechten bearbeiten kann, lege ich mir (besonders bei USB Sticks mit immer mal wieder wechselnden menuentry) eine weitere grub.cfg auf einem leicht zugänglichen Dateisystem (fat oder ntfs) an, die ich eben aus der grub.cfg von der ESP so aufrufe

Code: Alles auswählen

menuentry "cfg-file" {
	set root=(hd0,2)
	search --fs-uuid --set=root 063B94685E1DFBDF
	configfile /grub.cfg
}

Das Ganze auch, weil bei mir beide grubs (grub-efi und grub-pc) in jeweils eigenen Verzeichnissen in der ESP werkeln

Code: Alles auswählen

~$ ls /mnt
'$RECYCLE.BIN'   boot-bios   boot-efi   EFI  'System Volume Information'

jeder grub ruft dann dieses 'gemeinsame' config-file auf

mit einem Eintrag in der neu angelegten /boot/grub.cfg in Form von set root= >UUID< und configfile /grub.cfg wird darauf verwiesen ?
dann existieren anschließend zwei grub.cfg ? die sich gegenseitig nicht ausschließen oder behindern ?

die 2. wird von der ersten aufgerufen, da behindert sich nichts.
Und die menuentry sehen dann z.B. so aus

Code: Alles auswählen

menuentry "bullseye32 cfg" {
 search --no-floppy --fs-uuid --set=root 21bc15f4-4c2b-49af-999b-83e161f4e2c3
 configfile /boot/grub/grub.cfg
}

oder so

Code: Alles auswählen

 menuentry "Mate" {
 search --no-floppy --fs-uuid --set=root 019352d0-411b-4fa4-b965-e80df679743c
 linux /boot/vmlinuz root=UUID=019352d0-411b-4fa4-b965-e80df679743c
 initrd /boot/initrd.img
 }

oder für iso-files auf einem Stick dann so

Code: Alles auswählen

menuentry "debian-live-12.1.0-amd64-gnome" {
set root=hd0,3
loopback loop /debian-live-12.1.0-amd64-gnome.iso
linux (loop)/live/vmlinuz boot=live ramdisk_size=2100000 root=/dev/ram rw locale=de_DE bootkbd=de console-setup/layoutcode=de iso-scan/filename=/debian-live-12.1.0-amd64-gnome.iso
initrd (loop)/live/initrd.img
}

Schau einfach noch in das UUde Wiki -> Universal_stand-alone_grub…

wie schon geschrieben bin ich nur userin und bevor ich mein Gesamtsystem zerschieße, frage ich lieber dumm

Es gibt keine dummen Fragen!

[isabena]

herzlichen Dank für die Erläuterungen.

die menuentries habe ich genau auch in diesem Muster erstellt - in der "ersten" grub.cfg
läuft ja auch einwandfrei mit den 8 BSen.
klar, um einen Eintrag zu bearbeiten muß ich natürlich die ESP mounten und dann die grub.cfg editieren - beides als root
eine separate Partition vereinfacht die Bearbeitung der Konfigurationsdatei. werde es mal ausprobieren --

[smutbert]

Warum ich das mit der Variable für die uuid gemacht habe, wollte ich noch schreiben. Es geht dabei um Faulheit und Übersichtlichkeit:

Erstens kommt die UUID bei einem Menüeintrag schon doppelt vor

Code: Alles auswählen

[...]
	search --no-floppy --fs-uuid --set=root $uuid
	linux /vmlinuz root=UUID=$uuid ro quiet loglevel=2
[...]

zuerst um das Dateisystem auf dem Debian überhaupt installiert ist zu finden und als Ausgangspunkt festzulegen und dann um dem Kernel das /-Dateisystem mitzugeben. So werden die Menüeinträge deutlich kürzer und übersichtlicher und auch wenn man die grub-Konfiguration auf ein anderes System übernimmt, muss nur die UUID angepasst werden.

Darüber hinaus habe ich gerne auch noch einen zweiten Menüeintrag, der den vorigen Kernel startet, der sieht dann so aus:

Code: Alles auswählen

menuentry 'Debian GNU/Linux (bookworm, alter Kernel)' --class debian {
	search --no-floppy --fs-uuid --set=root $uuid
	linux /vmlinuz.old root=UUID=$uuid ro quiet loglevel=2
	initrd /initrd.img.old
}

(wieder zwei Mal UUID gespart ☺)

Zweitens kommt bei mir noch dazu, dass bei mir alles auf einem btrfs-Dateisystem liegt und ich darauf in subvolumes gleich mehrere Installationen habe und ich mir da gelegentlich auch wieder einmal andere Distributionen ansehe. Die UUID ist dann für alle dieselbe.


Genau dasselbe könnte man übrigens auch mit Labels (Namen für ein bestimmtes Dateisystem) machen. Man vergibt also beim Formatieren oder mit den entsprechenden Tools danach ein Label, wie z. B. "debian". Die Einträge könnten dann so aussehen

Code: Alles auswählen

menuentry 'Debian GNU/Linux (bookworm)' --class debian {
	search --no-floppy --label --set=root debian
	linux /vmlinuz root=LABEL=debian ro quiet loglevel=2
	initrd /initrd.img
}

(natürlich könnte man das auch wieder mit einer Variablen machen.
Ein Nachteil ist, dass man sich selbst darum kümmern muss, dass beim Booten nicht zufällig einmal ein USB-Stick mit einem Dateisystem mit identischem Label im PC steckt, damit grub nicht das falsche Dateisystem findet.)

[grubenlicht]

allerdings "erhöht" sich in diesem Anwendungsfall (8 O/S) dann aber der Aufwand, sowas wie $uuid1 bis $uuid8 erzeugen zu müssen. *duckundwäch*

[isabena]

Warum ich das mit der Variable für die uuid gemacht habe, wollte ich noch schreiben. Es geht dabei um Faulheit und Übersichtlichkeit
---
Darüber hinaus habe ich gerne auch noch einen zweiten Menüeintrag, der den vorigen Kernel startet,
---
Zweitens kommt bei mir noch dazu, dass bei mir alles auf einem btrfs-Dateisystem liegt und ich darauf in subvolumes gleich mehrere Installationen habe und ich mir da gelegentlich auch wieder einmal andere Distributionen ansehe. Die UUID ist dann für alle dieselbe.
---

das ist nachvollziehbar für mich und dafür meinen Dank !

im Gegensatz zu dir bin ich noch "oldschool" mit ext4 unterwegs;

wenn mehrere Distributionen genutzt werden, haben die ja jeweils einen menuentry mit ihrer eigenen UUID;
mit der vorab gesetzten Variablen würde das nicht funktionieren, also muß ich wohl den Aufwand in kauf nehmen und pro Distro und Kernel die UUID zweimal eintragen.

Oder habe ich jetzt irgendwo einen Denkfehler

EDIT:

da du gerade von Faulheit schreibst

wäre es eine realisierbare Idee, die bisher bestehende grub.cfg kpl in die neue zu kopieren ?

[smutbert]

Der Denkfehler betrifft nur btrfs. Da legt man typischerweise (mindestens) ein Subvolume für eine Linuxinstallation an und nutzt das dann als /. Auf einem Dateisystem können glaube ich maximal 2⁶⁴ Subvolumes erstellt werden und die liegen alle auf derselben UUID.
Natürlich muss in grub zusätzlich jeweils noch das Subvolume angegeben werden, aber so hatte ich zwischendurch gleichzeitig schon einige Debians (stable, testing, eine Kopie von stable zum Ausprobieren,...) und arch auf einem Dateisystem.

und bei einem normalen Dateisystem und mehreren Partitionen würde ich wahrscheinlich einfach noch eine zweite, dritte,... Variable anlegen (bookworm_uuid, testing_uuid oder etwas in der Art).

[smutbert]

wäre es eine realisierbare Idee, die bisher bestehende grub.cfg kpl in die neue zu kopieren ?

Natürlich geht das. Du brauchst sie auch gar nicht notwendigerweise kopieren sondern kannst sie in der neuen grub.cfg einfach mit so etwas wie

Code: Alles auswählen

search --no-floppy --fs-uuid --set=root xyz
configfile /boot/grub/grub.cfg

laden.

Die automatisch von Debian erzeugte grub.cfg ist halt recht umfangreich und meiner Meinung nach nicht so gut geeignet sie selbst zu pflegen. Außerdem verweist sie eventuell auf einige Dateien die im /boot Verzeichnis der zugehörigen Debianinstallation liegen, womit der grub oder zumindest dessen Konfiguration nicht mehr ganz so unabhängig/standalone ist.