Wie findet grub einen Kernel (gelöst)

[KP97]

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

Nein, der Kernel vmlinuz... steht doch schon in /boot, wenn er denn richtig installiert wurde.
Irgendwie verstehe ich überhaupt nicht, was Du da eigentlich machst, oder ich habe was ganz Grundsätzliches überlesen.
Du hast einen USB-Stick mit ext4 formatiert, eine Partitiontabelle erstellt und darauf ein Stretch installiert bzw. kopiert. Das kopierte System hatte vorher lilo als Bootloader, dann ist das also auch auf dem Stick gelandet.
Stretch kann ja noch mit lilo umgehen, daher verstehe ich nicht, warum Du mit dem ungeliebten Grub kämpfst. Was in die lilo.conf gehört, weißt Du doch nach so vielen Jahren Benutzung, zudem habe ich noch eine conf aus meinem alten Fundus gepostet.
Jeder PC hat ein Bootmenü, aufzurufen mit F8 oder F11, ist unterschiedlich. Dort wählst Du den Stick, und der Bootloader im Stretch tut den Rest.
Da ist es Wurscht, welchen Bootloader Du installiert hast, Hauptsache es wird einer gefunden.

In meiner lilo.conf habe ich als Bemerkung zu chainloading auch auf das Eintragen von Fremdsystemen bzw. anderen Linux-Systemen hingewiesen.
Da muß der Stick natürlich im PC gemounted sein, üblicherweise nach /media/xxx/xxx, es genügt also, im Hauptsystem den kompletten Pfad einzutragen, dann kann auch das Stretch auf dem Stick gestartet werden.
Früher brauchten die alten Geräte bzw. Systeme noch einen Bootflag auf dem Stick, heute zwar nicht mehr, aber wenn Du mit Gparted einen solchen vergibst, schadet das auch nicht.

[fischig]

Stretch kann ja noch mit lilo umgehen, daher verstehe ich nicht, warum Du mit dem ungeliebten Grub kämpfst.

Weil ich das stretch von USB booten will (VM für Arme ). Wenn du mir zeigst, wie ich das mit lilo hinkriege, lasse ich von grub in dem Zusammenhang sofort die Finger.

Jeder PC hat ein Bootmenü, aufzurufen mit F8 oder F11

Das wusste ich bisher nicht.

Nebenbei: bookworm kann das immer noch (mit lilo umgehen). Und ich werde mir wohl auch die Sourcen gut aufheben.

Unter uns: ich gelobe feierlich, bei der nächsten Neuinstallation mal extlinux zu probieren.

[KP97]

Was ist denn mit dem Bootmenü F8 bzw. andere F-Taste? Taucht denn der Stick dort auf? Wenn ja, brauchst Du doch nur darauf zu klicken...

[HumiNi]

Irgendwie verstehe ich überhaupt nicht, was Du da eigentlich machst, oder ich habe was ganz Grundsätzliches überlesen.

Geht mir auch so. Auf die Gefahr, dass ich den aktuellen Stand überlesen habe:
1. Siehst du kein grub-Menü oder
2. Siehst du dort deine anderen Kernel nicht?

Falls 2. zutrifft, musst du in das grub-Submenü des aktuellsten Kernels gehen, um die anderen in dieser Partition (oder nur aus /boot dieser Partition?) zu sehen und zu starten.

[MSfree]

Was ist denn mit dem Bootmenü F8 bzw. andere F-Taste?

Jeder PC hat ein Bootmenü, aufzurufen mit F8 oder F11

Das wusste ich bisher nicht.

F8 oder F11 funktioniert nur bei Rechnern mit UEFI-Firmware. Alte Kisten noch mit BIOS können das in der Regel nicht.

Dazu kommt, daß UEFI-Systeme, wenn sie etwas neueren Datums sind, kein BIOS-Boot (aka legacy boot) mehr untersützen. Mein NUC11 kann z.B. nicht mit legacy Boot umgehen, lilo klappt hier also nicht.

(Bitte nicht mit secure Boot verwechseln. Auch UEFI-Boot geht (immer noch) ohne secure Boot.)

Rechner, die ein Bootmenü nach betätigen der F8/F11-Taste anzeigen, scannen alle angeschlossenen Massenspeicher (auch USB) nach einer UEFI-Partition auf der sich ein EFI-Bootloader befinden muß.

[fischig]

Danke für die Klarstellung, MSfree.

Und das ist hier der Fall. Die Maschine, auf der das stretch laufen soll, ist ein Thinkpad X61, ergo nix mit F8 und F11, wenn MSfree recht hat. Wäre ja auch zu schön gewesen.

Kleine Korrektur: Momentan sitzt das stretch auf einer HDD und Booten via USB ist nur endgültiges Ziel. Im Moment geht's darum, das stretch (intern angeschlossen (SATA, soweit ich weiß)) überhaupt mal mit grub zu booten. Und wie gesagt, am grub hängt mein Herz nun wahrlich nicht.

Dass das (am Endziel) mit USB-Boot funktionieren müsste, leite ich davon ab, dass das X61 ja prinzipiell davon bootet: z.B. GRML-Live-(DVD!)

[KP97]

F8 oder F11 funktioniert nur bei Rechnern mit UEFI-Firmware. Alte Kisten noch mit BIOS können das in der Regel nicht.

Hm, das habe ich anders in Erinnerung. Ich habe damals einen Stick mit einem Debian darauf über diesen Weg gestartet.
Ich habe hier noch ein HP Elitebook ohne EFI, das mit Esc+F9 genau so ein Bootmenü öffnet und einen eingesteckten Stick erkennt und startet.
Dann hatte ich vor einiger Zeit ein Laptop von Asus, ebenfalls ohne EFI. Da war es die F12 Taste, ist also von dem jeweiligen Gerät abhängig.
@fischig wird sich schon melden...

[fischig]

F8 und F11 habe ich negativ ausprobiert. Aber wenn das tatsächlich mit einer F-Taste zu machen wäre, dann wäre ja eine entsprechnde Bios-Option eigentlich sinnlos. Das scheint mir für MSfrees These zu sprechen.

[KP97]

Die Auswahl erscheint nur ganz kurz am Anfang, nachdem der PC gestartet wird und die POST Meldungen erscheinen. In diesen Meldungen wird auch die Taste angegeben,
für BIOS meist Entf oder F2, fürs Bootmenü wie erwähnt. Da muß man fix sein, am besten die richtige Taste bereits gedrückt halten.
Ist auch eine Einstellung im BIOS, ob man das Herstellerlogo oder die POST Meldungen sehen will.

[HumiNi]

Die Auswahl erscheint nur ganz kurz am Anfang, nachdem der PC gestartet wird und die POST Meldungen erscheinen. In diesen Meldungen wird auch die Taste angegeben,
für BIOS meist Entf oder F2, fürs Bootmenü wie erwähnt. Da muß man fix sein, am besten die richtige Taste bereits gedrückt halten.

Mein Tipp: Wenn man nicht sicher ist, mit hoher Frequenz abwechselnd <ESC> und <F2> drücken.

[fischig]

Mich laust der Affe, KP97 und MSfree! Das scheint zu funktionieren. Ich hatte vor grubenlichts entsprechendem Hinweis noch nie was von POST gehört, weiß auch jetzt noch nicht so recht, was das ist (umgestellt im Bios habe ich nichts), aber nichtsdestotrotz: das Bios reagiert auf F12 und bietet mir (bei eingesteckter! stretch-HDD) den Stretch-lilo zum Booten an.

Gebootet wurde von lilo dann aber das aktuelle, interne bookworm-System, aber das lag sicherlich daran, dass in der stretch-lilo-config noch sda* statt sdb* stand. Mal schauen, was passiert, wenn ich das ändere.

[fischig]

War leider letztlich nicht von Erfolg gekrönt: wieder kernel panic. Ich kontrollier' noch mal die Einträge in fstab und lilo.conf, versuche auch noch die UUID (für sdb (MBR?) kann lilo damit nicht, nur für sdbX - richtig?) aber viel Hoffnung habe ich nicht, da ich das ja schon (auf anderem Weg) durch hatte: viewtopic.php?t=190587

Ergo sind wir wohl wieder bei grub und nicht gefundenen Kernels.

[KP97]

Mich laust der Affe ... Das scheint zu funktionieren.

Mich wundert das nicht... das kenne ich schon seit ganz langen Jahren... so hatte ich ja auch meinen damaligen Stick mit lilo gestartet, die config hast Du ja auch.
Das verbirgt sich hinter POST:
https://de.wikipedia.org/wiki/Power-on_self-test

[fischig]

So, KP97 ich habe mir deine beiden lilo-configs angesehen: so wie ich das verstehe, booten die beide ein Linux-System auf der 1. (und das heißt für mich internen) Platte: sdaX. Beim Stick sitzt vielleicht lilo auf dem Stick (wohin auch immer der udev-Link: /dev/disk/by-label/BackupStick) zeigen mag). Ich dagegen möchte ein System booten, bei dem nicht nur lilo, sondern auch das Root-Dateisystem sich auf der 1. per USB angeschlossenen Platte sdbX Platte sitzt. Genau da scheitert's: Das Root-Dateisystem wird nicht gefunden.

Zeigt mir meine Denkfehler, so vorhanden. Wenn lilo das nicht kann, wird's wohl wieder auf grub (oder extlinux) hinauslaufen, bzw dann gebe ich angesichts meiner Probleme mit grub auf, per USB booten zu wollen; und wenn ich das stretch brauche, baue ich eben diese Platte ein. Das funktioniert - mit lilo.

[Livingston]

Die Bezeichnungen sda und sdb werden vom Kernel vergeben, und zwar in der Reihenfolge, wie es ihm einzureihen beliebt. Diese Zuweisung kann sich von Bootvorgang zu Bootvorgang ändern, d.h. die Gerätebezeichnungen sind zwischen zwei Bootvorgängen nicht stabil.
Also kann mal die Festplatte sda oder sdb sein, umgekehrt der USB-Stick mal sdb oder sda. Das hat nix damit zu tun, dass grub oder lilo das nicht "können", sondern damit, was sie vorfinden.

[grubenlicht]

an verschiedenen Stellen z.B. -> hier findet man

Code: Alles auswählen

      #root = /dev/sda1
      #root = "UUID=18843936-00f9-4df0-a373-000d05a5dd44"

vielleich versuchst du es mal mit der 2. Zeile root = "UUID=<UUID>".

[fischig]

Das ist alles bekannt, Livingston. Es geht aber nicht um mehrere/unterschiedliche Bootvorgänge mit variablen Systemdatenträgern. Ich habe noch nie erlebt, dass in einem einfachen statischen System eine einmal eingebaute Platte vom Linuxsystem (kernel) nicht als /dev/sda, sdaX bezeichnet wurde (und entsprechend dann die nächste per USB angeschlossene als dev/sdb, sdbX). Den Hinweis auf sich bei plug and play ändernde Gerätedateien halte ich für so generelle udev-Ideologie - womit ich gar nicht sagen will, dass die Software nicht ihre Berechtigung hat.

Aber egal, mit UUIDs funktioniert's ja auch nicht. Und grub tut's halt nicht, weil er die vorhanden Kerne gar nicht erst wahrhaben will. Der erstellt hier mit update-grub und meinen kernels keine grub.cfg (das Pendant zur lilo.conf), bzw. bis dahin (grub-update) komme ich ja gar nicht. Und er tut's auch in einem chroot nicht. Wenn ich den Weg weiter verfolgen wollte, müsste ich vielleicht noch vor einem grub-boot-Versuch in einem chroot schauen, ob er wenigstens /etc/grub.d angelegt hat und dort eine 40_custom anlegen/neu schreiben um ihm dort die Kerne händisch anzugeben - ohne die erforderliche Syntax genau zu kennen, bevor ich Aussicht auf ein erfolgreiches grub-update hätte um damit eine vielleicht funktionierende /boot/grub/grub.cfg zu bekommen. Ich fänd' das mit Verlaub ganz schön abgedreht.

Ich muss noch mal schauen, ob ich noch 'ne andere Idee in baeuchleins Beitrag finde. Aber eigentlich hängt mir das für diesen Zweck (gelegentlich veraltetes stretch-System auf USB-Platte/-Stick booten zu wollen) mittlerweile ziemlich zum Hals heraus.

@grubenlicht: dir ist bewusst das genau diese beiden von dir zitierten Zeilen in der verlinkten Beispiel-config auskommentiert sind? Aber ok, die Syntax: root = "UUID=<UUID>" hatte ich vielleicht noch nicht durch.

[grubenlicht]

die sind auskommentiert, weil sie eine Alternave darstellen, entweder sdx oder uuid

[baeuchlein]

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.

Ach, Mist, ich hab' was übersehen. Egal, welcher Kernel nun genau gestartet werden sollen - die zweite Zeile sollte mit

Code: Alles auswählen

linux /boot/ ...

beginnen. Der "Slash" vor "boot" fehlt in jedem Fall, und deswegen findet grub nach der Eingabe den Kernel nicht. Anstatt das mitzuteilen, geht es anscheinend einfach wieder auf den grub-Prompt zurück. (Und nicht vergessen: Im obigen Beispiel ist die "root=hd0,msdos6"-Angabe in der zweiten Zeile wohl falsch, da muss was mit "/dev/sdbX" o.ä. hin, oder evtl. was wie "root=UUID=[UUID der Linux-Partition auf dem Stick]".)

Davon mal abgesehen, noch 'ne Anregung: Falls du auf der fest eingebauten Platte ein Linux hast und das mit grub bootest, kannst du ja auch erst mal dessen Kernel starten, aber dem Kernel sowas wie "root=/dev/sdb3" als Kernel-Parameter mitgeben und ihm damit sagen, "Kernel, der du von /dev/sdaX geladen wurdest, starte gefälligst trotzdem ein Linux von sdb3". Statt sdb3 trägst du dann die "sdbX-Bezeichnung" für die Linux-Partition auf dem Stick ein. Wenn das dann tatsächlich vom Stick läuft, hast du zumindest schon mal ein grundsätzlich startfähiges System auf dem Stick. Auch ein "root=UUID=[UUID der Linux-Partition auf dem Stick]" könnte sich lohnen; das sollte dann sogar das Linux auf dem Stick noch finden, wenn irgendwas mal die Device-Bezeichnung des Sticks bzw. der Partition auf dem Stick ändert.

Sollte das System vom Stick booten, aber dann das Dateisystem nur "read-only" "gemountet" sein, oder ein unklares Geplärre der Sorte "Welcome to Emergency mode! Enter root password or press CTRL-D to proceed." angezeigt werden, dann könnte es sein, dass in der Datei /etc/fstab auf dem Stick noch ein unpassender /dev/sdbX-Bezeichner o.ä. steht. Hier kann man dann statt /dev/sdbX auch "UUID=[UUID der Linux-Partition auf dem Stick]" verwenden, oder mit "LABEL=[Dateisystem-Label des Linux-Dateisystems]" eben dieses Label des Dateisystems nutzen und somit auch wieder etwaige Änderungen der /dev/sdYX-Bezeichnung geschickt umschiffen.

Wenn dann mal sicher ist, dass das Linux auf dem Stick sich grundsätzlich starten lässt, kann man auch mal schauen, wie man eventuell einen grub auf dem Stick installiert, der dann statt des grub auf der internen Platte benutzt wird. Dann könnte sogar die Installation auf der Platte völlig kaputt gehen und man hätte immmer noch ein gut ausgestattetes Notfall-System.

Und wenn das alles nix bringt, kann man immer noch ein Fäkalwort brüllen und was anderes ausprobieren!

[grubenlicht]

Ach, Mist, ich hab' was übersehen. Egal, welcher Kernel nun genau gestartet werden sollen - die zweite Zeile sollte mit

Code: Alles auswählen

linux /boot/ ...

beginnen. Der "Slash" vor "boot" fehlt in jedem Fall, und deswegen findet grub nach der Eingabe den Kernel nicht. Anstatt das mitzuteilen, geht es anscheinend einfach wieder auf den grub-Prompt zurück.

das möchte ich bezweifeln, normalerweise kommen da schon Fehlermeldungen.

[fischig]

Also ich denke, ich habe so ziemlich alle Vorschläge für Lilo-Kombinationen erfolglos durch.
Aber einen gewissen "Erfolg" gibt es:

Falls du auf der fest eingebauten Platte ein Linux hast und das mit grub bootest, kannst du ja auch erst mal dessen Kernel starten, aber dem Kernel sowas wie "root=/dev/sdb3" als Kernel-Parameter mitgeben und ihm damit sagen, "Kernel, der du von /dev/sdaX geladen wurdest, starte gefälligst trotzdem ein Linux von sdb3"

Das hat insofern erst mal funktioniert , indem ich die Zeile GRUB_CMDLINE_LINUX in /etc/default/grub so geändert habe:

Code: Alles auswählen

GRUB_CMDLINE_LINUX="root=/dev/sdb6"

damit wurde offenbar das stretch auf der USB-Platte laut /etc/debian_version (9.9) durchgebootet. Aber uname -r gab einen 6.*-Kern zurück und den gibt's bei mir nur im bookworm. Die Auflösung war mau und X konnte nicht gestartet werden, weder als root noch als einfacher Benutzer. Außerdem war das interne System danach nicht mehr bootfähig. Das musste ich via GRML und chroot wieder richten, indem ich den genannten Eintrag wieder herausnahm.

[Livingston]

Ich glaub, ich muss mal ein Weihnachtstürchen für grub aufmachen.

[fischig]

Ich habe jetzt mal im bookworm-grub vermutlich dieses os-prober aktiviert durch Entkommentieren der Zeile

Code: Alles auswählen

GRUB_DISABLE_OS_PROBER=false

in /etc/default/grub. Bei eingesteckter stretch-Platte listet update-grub jetzt zusätzlich zu den bereits vorher vorhandenen Systemen auf der internen Platte auch alle auf der externen Platte auf und danach erscheinen im grub-boot-Menü auch alle Kerne für diese Systeme. Booten kann man die Systeme auf der USB-Platte aber nicht.

[grubenlicht]

dann wäre ja mal interessant, was denn nun in der grub.cfg steht. Zeige mal

Code: Alles auswählen

more /boot/grub/grub.cfg  +/os-prober >os.txt

die os.txt hier.

[fischig]

Ich verstehe die Zeile nicht. Ich fasse die jetzt mal als ein „normales“ Kommando auf. Normal im Sinne von: ausführbar von jedem Benutzer. Ich vermute, dass alles, was links von der Spitzklammer steht, irgendwie in der Datei os.txt landen soll.
Hier ist das Ergebnis 42251
und hier die zugehörige/etc/default/grub 42252

Ich fürchte, dass das nicht weiterbringt. Wenn ihr der Meinung seid: „doch, kann weiterführen“, dann überspringt das Folgende.

Vielleicht konzentrieren wir uns alle erst mal einfach auf die Themenfrage in Bezug auf ein System auf einer internen Platte. Grub im MBR und Bookworm auf /dev/sda5: Wie findet grub dort selbständig Kernels? Bzw.: Welche dort unter /boot vorfindbaren Kerne registriert grub selbständig (via update-grub) in seinen configs.
Wenn ich nur os-prober in /etc/default/grub auskommentiere, keine externe Platte mit Debian- oder anderen Systemen an USB einstecke, dann steht nach update-grub das hier in /boot/grub/grub.cfg: 42253
Das entsprechende Boot-Menü zeigt vier Zeilen. In der zweiten und vierten Zeile steht nichts, aber wenn angewählt, wird der jeweils in der Zeile davor stehende Kern gebootet.
Die „Leer“zeilen erscheinen mir erst mal irrelevant.¹⁾ Außer den Kernen in der 1.(6.1 Eigenbau, sourcen von kernel.org) und 3. (bookworm-Standard-Kern) Zeile gibt es noch zwei weitere kernels unter /boot: 5.10 und 4.19. Die können (mit lilo) ebenfalls gebootet werden. Warum erscheinen die nicht im Boot-Menü von grub?

¹⁾ Vermutlich habe ich da beim Versuch, die „recovery mode“-Einträge im Bootmenü loszuwerden, beim Editieren von /etc/grub.d/10_linux Fehler gemacht.