Wie findet grub einen Kernel (gelöst)

[fischig]

Von lilo bin ich gewohnt, installierte Kerne selbst in die Datei /etc/lilo.conf einzutragen.
grub beansprucht, den/die installierten Kern(e) selbst zu finden und in /boot/grub/grub.cfg einzutragen.
Wovon hängt ab, ob grub einen installierten Kern findet/nicht findet?

[Livingston]

Der Kernel muss in einem gemounteten Verzeichnis liegen, vorzugsweise in oder unterhalb von /boot, bevor update-grub aufgerufen wird. Ob er auch woanders gefunden wird, müsste ich erst mühsam in den man-pages oder mit info grub herauszufinden versuchen.

[fischig]

Danke!
Alle meine Kernels (vmlinux*) liegen in /boot. Das scheint als Kriterium nicht auszureichen.

[schwedenmann]

Hallo


Meiner Meinung nach kommt os-prober ins Stolpern,wenn du merh als eine Platte im System hast.Nei nur 1Platte macht os-prober eigentlich seinen job.Aber du kannst zur Sicherheit ja auch manuell die /etc/grub.d/custom_40 benutzen.


mfg
schwedenman

[fischig]

os-prober will ich nicht nutzen.

Aber du kannst zur Sicherheit ja auch manuell die /etc/grub.d/custom_40 benutzen.

Sowas schwante mir nach der erfolglosen Diskussion mit grubenlicht schon. Aber ich hielte das dann für ein Armutszeugnis für grub. Und ich hoffe immer noch, dass auch ein einfacher User ihm helfen kann, die Kerne selbst zu finden.

Hintergund: der letzte Versuch mit grub endete damit, dass statt einen Kern zu booten ich hilflos vor einem grub-Prompt saß, und ich vermute, dass das daran lag, dass grub keinen der vorhandenen Kerne (die sich via lilo einwandfrei booten ließen) für bootwürdig hielt. Spekulation und könnt' jetzt 'ne längere Geschichte werden.

[MSfree]

Von lilo bin ich gewohnt, installierte Kerne selbst in die Datei /etc/lilo.conf einzutragen.

lilo hatte aber auch einen Automatismus, mit dem ein aktualisierter Kernel in lilo eingetragen wurde.

Wovon hängt ab, ob grub einen installierten Kern findet/nicht findet?

grub durchsucht das /boot-Verzeichnis nach Kerneln und trägt alle dort befindlichen in die /boot/grub/grub.cfg ein.

[Livingston]

os-prober will ich nicht nutzen.

Du musst ihn ja nicht in grub einbinden. Aber Du könntest dieses Script einfach mal freihändig ausprobieren:

Code: Alles auswählen

$ os-prober

Ja, es funktioniert sogar als einfacher Nutzer, da wir es mit einem simplen Bash-Script zu tun haben, dass einfach nur allgemein-zugängliche Informationen sammelt und nichts anderes macht, als eine Liste auszugeben.

[fischig]

grub durchsucht das /boot-Verzeichnis nach Kerneln und trägt alle dort befindlichen in die /boot/grub/grub.cfg ein.

Das macht er mit Sicherheit nicht - jedenfalls nicht hier. und ich fände gerne den Grund.

Okay, dann schau ich mal, ob die Benutzung von os-prober weitere Erkenntnisse liefert.

edit:

lilo hatte aber auch einen Automatismus, mit dem ein aktualisierter Kernel in lilo eingetragen wurde.

Der Automatismus war allenfalls ein halber:das Kommando (sbin/lilo setzte um, was ich in die lilo.conf geschrieben hatte. Für mich vergleichbar mit update-grub. Aber wenn die App keinen Kern findet ist man aufgeschmissen. Oder aber fügt ihn selbst hinzu (z.B. via 40_custom dem Nichts hinzu) und dann ist aus mit dem schönen Automatismus und offen bleibt, warum, zum Henker, er den/die Kerne nicht selbst finden konnte.

[HumiNi]

IIRC werden verschiedene Kernel aus der gleichen Partition in der untergeordneten Ebene des grub-Menüs angezeigt. Ohne Garantie!

[towo]

Das macht er mit Sicherheit nicht - jedenfalls nicht hier. und ich fände gerne den Grund.

Doch, genau das macht update-grub und wenn du das nicht glaubst, guck halt in /etc/grub.d/10_linux!

[MSfree]

Das macht er mit Sicherheit nicht - jedenfalls nicht hier. und ich fände gerne den Grund.

Nunja, grub selbst macht das natürlich nicht, das erledigt das Programm update-grub, das eine neue grub.cfg in /boot/grub anlegt.

[Upi2017]

@ fischig und @all
Bitte betrachtet meine Antwort nur als Kleinlaut, da ich von nichts Ahnung habe. Als reiner Anwender.

Wenn es um ein anderen Kernel geht, dann schaue ich gerne in der Synaptic nach signierten Kernel nach.
Diese finde ich dann auch in Grub wieder
Dies sollte eigentlich nur mal eine Idee am Rande sein. Mehr nicht.

[grubenlicht]

...dass statt einen Kern zu booten ich hilflos vor einem grub-Prompt saß

das hast du aber dort nirgends erwähnt, sonst hätte ich nämlich vorgeschlagen, auf die grub Konsole zu wechseln (Taste c), mit ls das gewünschte device herauszufinden, mit set root=<device> grub zu informieren und dann mit linux /boot/vmlinuz40935x61.0a root=<device> zu booten.
An der Stelle kann man auch mit search -f /boot/vmlinuz40935x61.0a nach dem zugehörigen device suchen lassen.

und ich vermute, dass das daran lag, dass grub keinen der vorhandenen Kerne (die sich via lilo einwandfrei booten ließen) für bootwürdig hielt. Spekulation und könnt' jetzt 'ne längere Geschichte werden.

ich vermute vielmehr,

– Du weißt gar nicht, was und wie gebootet wird, denn in der gezeigten grub.cfg steht dein kernel nicht.
– Willst auch nicht das bootinfoscript laufen lassen.
– Schreibst keinen 40_custom (und schaust dann in die grub.cfg, ob das dann entsprechendes erscheint)
– willst den Vorschlag GRUB-TIMEOUT-STYLE=menu nicht wenigstens mal probieren
– etc. etc…

[grubenlicht]

Meiner Meinung nach kommt os-prober ins Stolpern,wenn du merh als eine Platte im System hast.

sorry, aber das ist Unsinn!

test@gc:~$ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
├─sda2 vfat FAT32 DBD3-E1E8 505,8M 1% /boot/efi
└─sda3 ext4 1.0 5acd50f3-8ac8-446b-bfd9-ba558920a999 8,6G 50% /
sdb
├─sdb1
├─sdb2 vfat FAT32 6F88-8C32
└─sdb3 ext4 1.0 33524b84-0f27-460b-8809-b771fb749cab 4,3G 64% /media/test/33524b84-0f27-460b-8809-b771fb749cab
sr0
test@gc:~$ sudo os-prober
/dev/sdb3:Ubuntu 22.04.1 LTS (22.04):Ubuntu:linux
test@gc:~$

[fischig]

sonst hätte ich nämlich vorgeschlagen, auf die grub Konsole zu wechseln (Taste c), mit ls das gewünschte device herauszufinden, mit set root=<device> grub zu informieren und dann mit linux /boot/vmlinuz40935x61.0a root=<device> zu booten.
An der Stelle kann man auch mit search -f /boot/vmlinuz40935x61.0a nach dem zugehörigen device suchen lassen.

danke sehr! Das wäre gewsen was ich gerne gemacht hätte. Ob meine scripting-Kenntnisse ausreichen, werden wir sehen, wenn ich wieder soweit bin. Ich hatte das System zuletzt neu aufgesetzt - ohne den ominösen 4.2.45.

das hast du aber dort nirgends erwähnt,

Du könntest dich ja mal fragen, warum ich das vielleicht nicht erwähnt hatte. Dass grub zumindest nicht ALLE Kerne fand, wusstest du, h#ttest du wissen können! Selbstreflexion ist auch eine Tugend!

[grubenlicht]

...Du könntest dich ja mal fragen, warum ich das vielleicht nicht erwähnt hatte.

oops? ! Der ist gut!
Wer will hier Hilfe, du oder ich? Ich habe wohl beharrlich genug versucht, die Infos aus der Nase zu ziehen, allein, DU spielst nicht mit.

Ob meine scripting-Kenntnisse ausreichen

für das Schreiben von Zeilen in die grub> Konsole braucht man keine Skriptkentnisse, sie stehen ja auch schon da

[schwedenmann]

Hallo

sorry, aber das ist Unsinn!

ne, die devnamen könne sich ändern

beisspiel

sda1
sda2
sda3

Jeweils ein Linux.


bei eine Platte kein Problem, da sind es immer sda1 sda2 sda3

bei 2 Platten ahst du
a. sda1,sda2,sda3
sdb

oder eben
sda

sb1, sdb2 sdb3


je nachdem wie Plattenreighenfolge ist und wann dann os-prober ausgeführt wurde,zeiegn die Einträge ins leere.

mfg
schwedenmann

Dein Beispiel ist unsinn, mach dasselbe mal nach einem reboot,wenn dann sda und sdb vertauscht sind,zeigen die Menüeinträgfe auf die falsvhe Platte.

mfg
schwedenmann

[grubenlicht]

ne, die devnamen könne sich ändern

ja, das ist richtig, aber wenn man derart ins System eingreift, macht man für gewöhnlich auch ein update-grub. Hier auf einer Maschine mit 2 int. SATA Platten laufen die immer unter sda und sdb, selbst, wenn ich eine USB Platte beim Start anstecke.
Und selbst, wenn die sich ändern würden, ich weiß die kernel zu finden und zu booten aus 'grub>' heraus, und eine SG²D wäre zur Not auch zur Hand.

Darüberhinaus kratzt mich das ganze gescripte rund um grub sowieso nicht, ich verwende 'stand-alone' grub und benutze UUID und schreibe meine grub.cfg selber.

[fischig]

Im mit lilo bootbaren System gibt's drei Eigenbaukerne (vmlinuze) unter /boot

Also, es bleibt dabei, in /boot/grub/grub.cfg stehen keine zu bootenden Kerne, ergo grub findet sie nicht.. Ich lande an einem grub-Prompt.

Ich habe versucht, grubenlichts letzten Hinweis umzusetzen.
Eingabe von c hat nichts gebracht. Ich vermute weil ich mich bereits automatisch da befand, wo mich grubenlicht erst hinführen wollte: grub.prompt.
ls funktioniert. Die Ausgabe ist (hd0) (hd0,msdos6) (hd0,msdos5) (gh0,msdos1) / ist, wenn ich recht sehe, auf hd0,msdos6

mit set root=<device> grub zu informieren und dann mit linux /boot/vmlinuz40935x61.0a root=<device> zu booten.

Habe ich so versucht umzusetzen (Tastaturbelegung nicht deutsch):

Code: Alles auswählen

set root=hd0,msdos6
linux boot/vmlinuz40935x61.0a root=hd0,msdos6

lief ohne Fehlermeldung durch.Eine Möglichkeit, den grub.prompt zu verlassen, habe ich nicht gefunden.

Wer will hier Hilfe, du oder ich?

Das musste kommen. Schau mal in den letzten Thread von altmetaller. Ich kann deiner Hilfe mitunter nicht folgen und ich vermute, dass das auch daran liegt, dass du weder meine Rückmeldungen noch Vorschläge anderer berücksichtigt.

Darüber hinaus kratzt mich das ganze Gescripte rund um grub sowieso nicht,

Mir ist dieser grub-Bohai ebenso zuwider. Aber der „alleinstehende" grub ist dann wieder 'ne neue Baustelle mit ungewissem Ausgang. Wenn ich wüsste, wie ich lilo zum Booten von USB bewegen könnte, ersparte ich mir den Bohai liebend gerne.

[grubenlicht]

...es bleibt dabei, in /boot/grub/grub.cfg stehen keine zu bootenden Kerne, ergo grub findet sie nicht.. Ich lande an einem grub-Prompt.

dann stimmt ja schon diese grub-Installation nicht (denn wenn die richtig wäre, zeigt sich – je nach Einstellung – das grub Menü mit den Einträgen für die kernel / weiter O/S mittels os_prober, oder des System mit GRUB_DEFAULT= üblicherweise …=0) bootet direkt. Oder aber – da irgend etwas nicht gefunden wird., fällt grub in die Konsole zurück)

Habe ich so versucht umzusetzen (Tastaturbelegung nicht deutsch):

Code: Alles auswählen

set root=hd0,msdos6
linux boot/vmlinuz40935x61.0a root=hd0,msdos6

lief ohne Fehlermeldung durch.

die Aussage werden wohl die meisten hier so interpretieren: Das Starten von Linux mit kernel vmlinuz40935x61.0a hat funktioniert, Linux läuft.

Eine Möglichkeit, den grub.prompt zu verlassen, habe ich nicht gefunden.

wozu dann noch das? (btw., Mögliche Ausstiege wären 'halt' oder 'reboot' ansonsten -> Startpage "grub konsole befehlsliste" erster Eintrag, ist zwar archiviert, dennoch)

Schau mal in den letzten Thread von altmetaller.

hä?

Ich kann deiner Hilfe mitunter nicht folgen und ich vermute, dass das auch daran liegt, dass du weder meine Rückmeldungen noch Vorschläge anderer berücksichtigt.

nein, das liegt daran, daß DU nicht auf meine Vorschläge [bootinfoscript] eingehst bzw Rückfragen nicht beantwortest. Wenn du etwas nicht verstehst, dann mußt du das explizit sagen.

[fischig]

Das Starten von Linux mit kernel vmlinuz40935x61.0a hat funktioniert, Linux läuft.

Wenn du das so erkennst? - ich nicht. einen Debian-Prompt grub> habe ich in 20 Jahren nicht gesehen.

edit:
@Livingston: os-prober dürfte ohne funktionierenden grub nicht nutzbar sein - richtig?

[Livingston]

@Livingston: os-prober dürfte ohne funktionierenden grub nicht nutzbar sein - richtig?

Falsch. os-prober ist einfach nur ein Bash-Script und läuft solo. Meist wird er zusammen mit grub verwendet, der den Output nutzt, um Hinweise auf weitere Betriebssysteme zu finden.
Wie gesagt: Einfach mal aufrufen, dann siehst Du, das da auch einfach nur mit Wasser gekocht wird. Oder ins Script direkt reinsehen. Ich find's nicht uninteressant - ist aber Geschmackssache

[KP97]

So, ich hab mal in uralten Dateien in meinen Backups gesucht und drei configs rausgefischt. Zu dieser Zeit hatte ich Hardware ohne EFI und meine eigenen Kernel liefen ohne initrd,
also genauso wie jetzt bei Dir. Zwei configs gehören zu Lilo, eine zu Extlinux. Extlinux habe ich damals sehr gerne genutzt, den gibt es auch immer noch im Repo.
Ich vermute mal stark, da kannst Du Dir was zusammenkopieren, so wie Du es brauchst. Mußt Du natürlich an Deine Bezeichnungen anpassen, aber das weißt Du ja.
Die Endungen .txt mußt Du wieder entfernen, die waren zum Hochladen nötig.
42248
42249
42250

[baeuchlein]

Ich versuch' mal, hier ein paar offen gebliebene Dinge anzusprechen. Vielleicht hilft irgendwas davon fischig. Geschrieben wurde das hier vor dem Beitrag von KP97, der ist also hier nicht mehr berücksichtigt.

Das in einem grub-Prompt eingegebene

Code: Alles auswählen

set root=hd0,msdos6
linux boot/vmlinuz40935x61.0a root=hd0,msdos6

bewirkt vermutlich, dass der Kernel startet, dann aber mit einer Meldung stehen bleibt, dass er das "boot device" nicht findet. Das "root=" in der zweiten Zeile wird nämlich meines Wissens vom Linux-Kernel ausgewertet, nicht mehr von grub. Und grub teilt dem Kernel meines Wissens auch nicht mit, welches Gerät sich hinter "hd0,msdos6" verbirgt. Da sollte eher sowas wie "/dev/sda3" o.ä. stehen. Auch etwas wie "root=UUID=[irgendeine UUID]" ist wohl möglich - Hauptsache, der Kernel versteht es.

Es kann aber auch weit mehr notwendig sein, damit grub den Kernel booten kann. Beispielsweise muss es u.U. Code für bestimmte Partitionierungsarten laden; für "msdos" (=Partitionierung im MBR, keine moderne GPT-Partitionierung) muss was anderes geladen werden als für GPT. Und die Partitionsart muss dem grub auch gesagt werden.

grub selber sucht auch meines Wissens nicht nach Partitionen. Im Wesentlichen guckt grub sich /boot/grub/grub.cfg an und macht nahezu blind das, was darin vorgeschrieben wird. Allerdings gibt's Hilfsprogramme (grub-mkconfig und evtl. auch grub-install), die diese grub.cfg neu schreiben - in der grub.cfg meines Linux' steht auch fett eine enstprechende Warnung drin. Daher habe ich mit einigen Mühen dafür gesorgt, dass "mein" grub nur /boot/grub/custom.cfg auswertet und das ganze automatische Gedönse abgewürgt wird - es rotzt mir mit der Zeit immer mehr eigene Einträge vor meine händisch erstellten, und diese automatisch erstellten haben meistens Bezeichnungen, die mir wenig sagen. "Debian 11.11, Kernel 5.15.125" o.ä. sagt mir viel eher, welcher von mir selbst erstellte Kram dahinter steckt.

Das, was diese automatischen Suchprogramme da so alles suchen und finden, habe ich auch noch nicht kapiert. Drum sage ich ja immer: Die beste Automatik ist eine, die man auch abstellen kann.

In dieser /boot/grub/custom.cfg stehen Einträge drin, wie sie früher auch in /boot/grub/grub.cfg drin standen (wie's heute aussieht, weiß ich nicht genau). Zwei Beispiele:

Code: Alles auswählen

menuentry "Debil 11, Kernel 5.15.7 (vesafb)" --class debian --class gnu-linux --class gnu --class os {
        load_video
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos3)'
        echo    'Lade Kernel ...'
        linux   /usr/src/linux-5.15.7/arch/x86/boot/bzImage root=/dev/sdb3 ro nohdparm radeon.si_support=0 amdgpu.si_support=0 video=vesafb vga=0x318 pata_legacy.all=1
}

startet einen Kernel von der dritten Partition einer Platte mit alter "MBR-Partitionierung", also nix mit GPT, und

Code: Alles auswählen

menuentry "Debian 10.13, Kernel 5.15.125 (Textmodus & VESA f. X; GPT)" --class debian --class gnu-linux --class gnu --class os {
        load_video
        insmod gzio
        insmod part_gpt
        insmod ext2
        set root='(hd1,gpt3)'
        echo    'Lade Kernel ...'
        linux   /usr/src/linux-5.15.125/arch/x86/boot/bzImage root=/dev/sdb3 ro nomodeset
}

startet einen Kernel von der dritten Partition einer GPT-partitionierten Platte.

"set root= ..." gibt bei sowas diejenige Partition an, auf der der Kernel herumliegt, während der "root= ..."-Parameter in der mit "linux" beginnenden Zeile angibt, wo das Linux installiert ist, das mit diesem Kernel gestartet werden soll. Im ersten Beispiel ist zu sehen, dass von der ersten Platte ("hd0", nach BIOS-Reihenfolge gezählt!) auf der dritten Partition ("msdos3") ein Kernel geladen werden soll, der dann aber ein Linux starten soll, das auf der zweiten Platte (sdb3, nicht sda3!) in deren dritter Partition herumlungert. Die anderen Parameter für den Kernel erklär' ich jetzt mal nicht, das hat meistens nix mit dem Laden und Starten des Kernels zu tun.

Die meisten der Zeilen zwischen den beiden geschweiften Klammern (erste und letzte Zeile) sind diejenigen Dinge, die man auch auf der grub-Kommandozeile eingeben kann. "insmod part_gpt" ist z.B. nötig, damit grub überhaupt eine GPT-Partitionierung versteht, und "insmod ext2" sorgt dafür, dass grub mit ext2- und ext3-Partitionen (bzw. den Dateisystemen darauf) umgehen kann. Das braucht es vermutlich, um den Kernel davon laden zu können - für alles Andere nach dem Start des Kernels ist dieser Kernel selber zuständig.

Da grub meines Wissens unter Debian immer so eingestellt wird, dass es auch die /boot/grub/custom.cfg auswertet, würde ich erste selbstgeschriebene Experimente darin einordnen. Die custom.cfg wird im Gegensatz zur grub.cfg auch nicht von irgendwelchen mit der Axt im Walde tätigen Automatiken befummelt, also ist man da drin schon mal selber der Boss, und nicht irgendein automatisches "Ding".

Die in custom.cfg eingetragenen Dinge sollten am Ende der von grub angezeigten Einträge erscheinen. Wenn man dann später mal will, dass sie ganz nach oben kommen, kann man die Reihenfolge der Dateien in /etc/grub.d verändern. Das beachten dann auch die ganzen Automatiken... oder zumindest hat mir da noch nie eine die Tour versaut.


Wie gut die Automatiken vorhandene Linuxe und Kernels finden, weiß ich nicht. Tatsächlich aber kann man mit "info grub" auch nachlesen, dass sie normalerweise nur in /boot nach Kernels suchen. Irgendwo steht da auch, wie man sie in einem anderen Verzeichnis wühlen lassen kann. Damit habe ich aber keine Erfahrung.

[fischig]

Hach baeuchlein, diese akribischen, nüchternen, sachlichen und empirischen Beobachtungen gehen runter wie Butter!

Dank auch an KP97 und Livingston!

Das in einem grub-Prompt eingegebene

Code: Alles auswählen

set root=hd0,msdos6
linux boot/vmlinuz40935x61.0a root=hd0,msdos6

bewirkt vermutlich, dass der Kernel startet, dann aber mit einer Meldung stehen bleibt, dass er das "boot device" nicht findet.

Meine Beobachtung: es gibt keine Meldung. Es erscheint wieder der Boot-Prompt. Es gibt insbesondere keine boot-Meldungen. Meine Vermutung: Das Programm ist angesichts der nicht gefundenen Kerne schlicht ratlos. Wenn ich recht erinnere, wird gar keine /boot/grub/grub.cfg.erzeugt.
Aber wir müssen das nicht weiter diskutieren. Deine Darstellung enthält viele Anregungen, was ich noch probieren könnte, um das vermaledeite Tool besser zu verstehen, bzw. wie man das Nicht- Verstehbare umschiffen könnte.

Zu os-prober:
Detailierte Info (z.B. manpage) habe ich keine gefunden. Auf einer anderen Maschine mit bookworm, auf der grub leidlich tut, was ich erwarte, immerhin einige Kerne (auch Eigenbau) selbst findet, habe ich os-prober mal unabhängig von grub laufen lassen:

Code: Alles auswählen

# os-prober
/dev/sda5:Debian GNU/Linux 12 (bookworm):Debian:linux

Sagt mir nichts. ich habe mittlerweile auch registriert, dass man os-prober auch in einer grub-config (/etc/default/grub?) aktivieren kann.

@MSfree

lilo hatte aber auch einen Automatismus, mit dem ein aktualisierter Kernel in lilo eingetragen wurde.

Wenn ich recht erinnere, wurde nach einer Kernel-Installation zwar /sbin/lilo automatisch aktualisiert (und damit ein parallel installierter grub deaktiviert ), aber in die /etc/lilo.conf musste man den schon selbst schreiben, um ihn mit lilo nutzen zu können.

Was mir gerade noch so durch den Kopf geht: benötigt ein Debian-grub etwa einen Link /vmlinuz auf ein vmlinuz* unter /boot?