Wie findet grub einen Kernel (gelöst)

[grubenlicht]

Hier ist das Ergebnis 42251
Ich fürchte, dass das nicht weiterbringt.

Mich irritiert das Ergebnis

linux /boot/vmlinuz40935x61.0a root=UUID ro

oder gar ganz ohne eine device Angabe für "/"

linux /boot/vmlinuz41429x61.0 ro

Da bin ich überfragt.

Wenn ihr der Meinung seid

Ich hätte längst das Stretch auf ein USB (oder auch intern) Gerät gepackt, einen stand-alone grub installiert, eine grub.cfg geschrieben, alles, was stört im PC ausgebaut, und mich auf das booten dieses Stretch konzentriert.

[fischig]

Ich hätte längst das Stretch auf ein USB (oder auch intern) Gerät gepackt.

Habe ich hoch - ganz ohne grub. Aber ich bin auch mitunter durchaus bereit, mir jede Menge Arbeit zu machen, um eine seltsame Idee zu realisieren. Durchaus im Sinne von: Der Berg kreiste - und gebar eine Maus.

[grubenlicht]

Ich hätte längst das Stretch auf ein USB (oder auch intern) Gerät gepackt.

Habe ich hoch - ganz ohne grub.

Und wie willst du dann booten? Lilo funktioniert – nach deinen Angaben – nicht, mit os-prober erzeugte Einträge tun es auch nicht (sehen imho auch seltsam aus) und einen stand-alone grub mit schlichtem Menüentrag in einer grub.cfg willst du nicht (versuchen).
Entsprechende grub Befehle (set root…, linux /… etc.) auf der grub Konsole zeigen eigenartige/keine Reaktionen.
Wer weiß, woran das nun liegt.

[fischig]

Und wie willst du dann booten?

Das habe ich doch irgendwo beschrieben. Ich nutze die Platte eingebaut, nicht per USB, und dann funktioniert die - mit lilo.

einen stand-alone grub mit schlichtem Menüentrag in einer grub.cfg willst du nicht (versuchen)

NOCH nicht, weil ich erst mal wissen will, warum der grub - via udate-grub (eh nur ein wrapper für grub-mkconfig oder wie das Original heißt, geschenkt, ich lese schon, was ich so im Netz finde , habe aber nicht die Absicht, bei der Entwicklung für grub mitzumischen) den einen kernel (bei dem was er selbst macht: [update-grub]) für würdig hält, akzeptiert, zu werden (FUNKTIONIERENDE Aufnahme ins boot-Menü), den anderen dagegen nicht.

[baeuchlein]

Das Geheimnis der von grub-mkconfig gefundenen/nicht gefundenen Kernels war etwas schwer aufzuklären, aber ich glaube, ich hab's jetzt entdeckt.

Wenn ich das, was in einer unveränderten Datei /etc/grub.d/10_linux drin steht, mal durchwühle, kommt irgendwann Folgendes zum Vorschein:

Code: Alles auswählen

machine=`uname -m`
case "x$machine" in
    xi?86 | xx86_64)
        list=
        for i in /boot/vmlinuz-* /vmlinuz-* /boot/kernel-* ; do
            if grub_file_is_not_garbage "$i" ; then list="$list $i" ; fi
        done ;;
    *)
        list=
        for i in /boot/vmlinuz-* /boot/vmlinux-* /vmlinuz-* /vmlinux-* /boot/kernel-* ; do
                  if grub_file_is_not_garbage "$i" ; then list="$list $i" ; fi
        done ;;
esac

Dort sieht man, dass für Rechner, die mit einem Kernel für 32-Bit-i386-Architektur oder "x86_64" (64-Bit i686) gestartet wurden, nur nach Kernels gesucht wird, deren Dateinamen mit "vmlinux-", "vmlinuz-" oder "kernel-" beginnen und die in / oder /boot drin sind. Ein Posting von fischig eine "Seite" vorher, in der "funktionierende" und "nicht funktionierende" Kernels angegeben sind, zeigt, dass die selbst erstellten, nicht funktionierenden Kernels kein Minuszeichen hinter "vmlinux" oder "vmlinuz" haben. Ein einfaches Umbenennen dürfte schon reichen, damit grub-mkconfig den Kram plötzlich und (un?)erwartet findet.

Hab' ich dann natürlich auch gleich mal ausprobiert. Einen Kernel-Selbstbau namens /boot/bzImage findet grub-mkconfig bei mir nicht, eine 1:1-Kopie namens /boot/vmlinuz-kacke dagegen schon. Die so gebaute grub.cfg zeigt, dass er dann beim Booten melden würde: "Loading Linux kacke". (Ich komm' vom Lande, da kann man sich an solchen Scherzen noch aufgeilen.)

Ich möchte an dieser Stelle nochmal dafür plädieren, eher nicht selbst die grub.cfg von Hand zu editieren. Es steht dick und fett da drin, dass man das nicht soll, und auch, warum nicht: Wenn dann endlich mal einer von grubs "Helfern" (grub-mkconfig o.ä.) gestartet wird, schmeißt der nämlich die mühsam erstellte grub.cfg gleich auf den Müll, und weg ist die mühevoll geschriebene eigene grub.cfg! Besser, man bastelt seine eigenen Einträge erst mal brav in /etc/grub.d/40_custom.cfg (oder wie diese "custom"-Datei genau heißen mag) und lässt grubs "Helfer" dann ihren Job machen - dann werden die Dinger von denen brav in die grub.cfg eingebaut, und was man so frickelt, geht auch nicht so leicht verloren.

[Livingston]

Hab das grad mit einer Textdatei namens /boot/vmlinuz-schrott gemacht. Wird einwandfrei gefunden und ins grub-Menü eingebaut.

[HumiNi]

Hab das grad mit einer Textdatei namens /boot/vmlinuz-schrott gemacht. Wird einwandfrei gefunden und ins grub-Menü eingebaut.

Genau das sagt dein Vorredner/Vorforist.

[Livingston]

Hab das grad mit einer Textdatei namens /boot/vmlinuz-schrott gemacht. Wird einwandfrei gefunden und ins grub-Menü eingebaut.

Genau das sagt dein Vorredner/Vorforist.

Was er nicht sagt, und was ich wissen wollte: update-grub prüft nicht auf den Inhalt, wie es z.B. mit dem Tool file möglich wäre.

[grubenlicht]

ich denke, es geht um os-prober, der findet u.a. auch /boot/vmlinuz41941x61.1 und trägt das in die grub.cfg
/etc/grub.d/10_linux ist zuständig für alles, was in (seinem eigenen) "/" steht.

[fischig]

Der Gewinner ist: baeuchlein! Tata!

Ich habe mal den 4.19er in seinem Sinne umbenannt und schon wird er von update-grub nicht nur gefunden sondern auch gebootet.

Eigentlich hätte ich gedacht, dass ich den Kern neu hätte installieren müssen, weil nicht nur der Kern selbst kompiliert, sondern auch sein vmlinuz von mir umbenannt wurde, war aber nicht nötig, nachdem ich die via dpkg erzeugten Bezeichner in /lib/modules daraufhin überprüft hatte.

ich denke, es geht um os-prober, der findet u.a. auch /boot/vmlinuz41941x61.1 und trägt das in die grub.cfg

Mitnichten, hier zumindest bewirkt ein in /etc/default/grub aktivierter os-prober lediglich, dass die auch ohne ihn gefundenen Kernels nochmals in /boot/grub/grub.cfg geschrieben werden.

Irgendwie kommt mir der quasi-Monopolist doch sehr proffessionell vor. Es mag wohl seinen Grund haben, dass GRML grub nicht benutzt.

Ich möchte an dieser Stelle nochmal dafür plädieren, eher nicht selbst die grub.cfg von Hand zu editieren. Es steht dick und fett da drin, dass man das nicht soll, und auch, warum nicht

Das hatte ich von Anfang an auf dem Schirm und deswegen entgegen so manchem Rat die Finger davon gelassen.

Ein Posting von fischig eine "Seite" vorher, in der "funktionierende" und "nicht funktionierende" Kernels angegeben sind, ...

Das darfst du doch nicht verraten, sonst müsste sich doch der eine oder andere Experte blind vorkommen oder mit Voreingenommenheit geschlagen!

[Livingston]

Was lange währt... Freut mich, dass es geklappt hat
Ich denke, ich baue tatsächlich mal ein Weihnachtstürchen zu grub zusammen. Mal systematisch durch die Ebenen der Konfiguration gehen, die Systematik hinter dem ganzen Kram zugänglicher machen etc.
Mal sehen, wie weit ich komme. Wenn ich in einer Woche ein Grundgerüst für den Artikel hinbekomme, wage ich eine Ankündigung im Kalender-Thread. Hängt davon ab, ob ich Zeit genug erübrigen kann.

[fischig]

Und ich kann jetzt mal probieren, wie das dann aussieht, die gewonnene Erkenntnis anzuwenden auf ein altes Debian-System, das auf einem per USB angeschlossenen Datenträger sitzt.
Aber vorher will ich mal sehen, wie ich mit meinem login-Problem weiterkomme, das echt lästig ist und bei dem rhHeini meint, dass ich auch da besser die Finger von lasse, weil ich nicht in der Lage bin, außer Prosa etwas ihm Gefälligeres zu fragen, womit er durchaus recht hat.

[KP97]

@fischig
Na siehste, kaum macht mans richtig....
Ich habe mich schon immer über Deine seltsamen Kernelbezeichnungen gewundert, die hast Du ja schon früher mal erwähnt.
Ich vermute, das kommt von diesen Einträgen in der Kernel config:

CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set

So habe ich das jedenfalls bei mir, und meine Bezeichnungen sind immer vmlinuz-version, momentan also vmlinuz-6.1.115
Anscheinend hat sich lilo aber nicht daran gestört, sonst hätte das ja schon früher Probleme gemacht.

@Livingston
Gute Idee, das hilft doch bestimmt einigen Leuten, auch wenn der Grub allgemein verbreitet und eingesetzt wird.
Da ja die alten Geräte ohne EFI mittlerweile im Aussterben begriffen sind, sind die anderen Bootloader auch nicht mehr wichtig bzw. bekannt.
Wenn Du das machen solltest, könnte ich meine Anleitung für systemd-boot auch hinter ein Türchen packen, das würde dann ja ganz gut zusammen passen.

[KP97]

Und ich kann jetzt mal probieren, wie das dann aussieht, die gewonnene Erkenntnis anzuwenden auf ein altes Debian-System, das auf einem per USB angeschlossenen Datenträger sitzt.

Vorher würde ich überlegen, allen meinen Geräten Label zuzuweisen. Die sind _immer_ eindeutig, ganz egal, welcher Gerätename durch den Kernel zugewiesen wird, sda, sdb oder sdc.
Klar, UUID's sind auch eindeutig, die kann man sich aber nicht merken, und die müssen auch in der fstab geändert werden, bei Label ist das nicht der Fall.
Mit

Code: Alles auswählen

tune2fs -L LABELNAME /dev/sda2                       #für ext4

und

Code: Alles auswählen

dosfslabel /dev/sdxx NAME  (11-st GROSS)             #für fat32

kann man das machen. Das hilft ungemein zum besseren Überblick.

So sieht das dann in meiner fstab aus:

Code: Alles auswählen

LABEL=MB		 /			       ext4	defaults    			                    0	 0
LABEL=EFI-HDD		/boot/efi 	 	vfat	umask=0077,iocharset=iso8859-1  0  0

[fischig]

Ich habe mich schon immer über Deine seltsamen Kernelbezeichnungen gewundert, die hast Du ja schon früher mal erwähnt.

Ich hab's nun mal gerne möglichst minimalistisch, das gilt auch für Bezeichner/Dateinamen. Zwischen „vmlinuz“ und der Kernelversion benötige ich keinen Bindestrich um das sinnvoll lesen zu können. Gleiches gilt hier für die lokale Version.

Das muss man nicht so sehen, aber wo ich's kann/darf, verfahre ich danach.

Vorher würde ich überlegen, allen meinen Geräten Label zuzuweisen.

Mach ich eigentlich immer. Aber da hier in über 20 Jahren meines Wissens noch nie jemand versucht hat, das im Zusammenhang mit einem bootloader zu nutzen, habe ich das bislang auch nicht probiert.
Ich denk' schon drüber nach, was mir auf meine Fragen rückgemeldet wird.
(letzter Satz geht nicht gegen dich! Aber ich habe momentan tatsächlich einen dicken Hals! )

[HumiNi]

Das Geheimnis der von grub-mkconfig gefundenen/nicht gefundenen Kernels war etwas schwer aufzuklären, aber ich glaube, ich hab's jetzt entdeckt.

Wenn ich das, was in einer unveränderten Datei /etc/grub.d/10_linux drin steht, mal durchwühle, kommt irgendwann Folgendes zum Vorschein:

Code: Alles auswählen

machine=`uname -m`
case "x$machine" in
    xi?86 | xx86_64)
        list=
        for i in /boot/vmlinuz-* /vmlinuz-* /boot/kernel-* ; do
            if grub_file_is_not_garbage "$i" ; then list="$list $i" ; fi
        done ;;
    *)
        list=
        for i in /boot/vmlinuz-* /boot/vmlinux-* /vmlinuz-* /vmlinux-* /boot/kernel-* ; do
                  if grub_file_is_not_garbage "$i" ; then list="$list $i" ; fi
        done ;;
esac

Gratuliere! Das nenne ich perfekte Fehlersuche.
(Man kann es außerdem lausigen Code nennen. Kernel aufgrund des Dateinamens identifizieren... )

[baeuchlein]

(Man kann es außerdem lausigen Code nennen. Kernel aufgrund des Dateinamens identifizieren... )

Sei bloß still... eins meiner selbst geschriebenen Skripte macht das genauso!