Ich habe meinen eigenen Kernel (4.19.37) erstellt und hatte keine Probleme beim Erstellen ( make) oder Installieren ( make install_modules+ make install). Alles scheint gut zu laufen, bis ich ausführe grub2-mkconfig -o /boot/grub2/grub.cfg. Wenn ich diesen Befehl ausführe, findet Grub sowohl meinen vorhandenen als auch meinen neuen vmlinuz-*Kernel in /boot/sowie die entsprechenden initramfs-*.img. An diesem Punkt bleibt das System jedoch auf unbestimmte Zeit hängen (> mehrere Stunden). Ctrl+Cscheint es nicht zu stoppen und ich muss neu starten. Ich habe dieses Problem untersucht und alles, was ich gefunden habe, was ein Problem sein könnte, ist die Suche nach bootfähigen Betriebssystemen auf Wechseldatenträgern, die ich behoben habe, indem ich sie sowohl entfernt als auch zu GRUB_DISABLE_OS_PROBER=truepro /etc/default/grubhinzugefügt habe.dieser SE-Beitrag. Beides hat nicht geholfen.
Beim Neustart lande ich in der grub>Befehlszeile, vermutlich weil ich grub2-mkconfignie fertig wurde und die Grub-Konfigurationsdatei beschädigt wurde. Hier kann ich sowohl den alten als auch den neuen Kernel sowie initramfs problemlos laden, aber wenn ich boot ausführe, tritt eine Kernel-Panik auf:
end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Natürlich gehe ich davon aus, dass mit meinem etwas nicht stimmt, initramfs-4.19.37.imgwas durch meinen Build-Prozess verursacht wurde. Als Experiment habe ich getestet, ob ich den neuen Kernel laden, aber das alte initramfs (4.19.10) verwenden kann, und tatsächlich bootet es in emergency mode. Das Gegenteil, alter Kernel mit neuem initramfs, kann ich jedoch nicht tun. Also stimmt etwas mit meinem neuen initramfs-Image nicht.
Um schlauer zu werden, habe ich in meinem letzten Experiment das alte und das neue Initramfs-Image mit gemountet mount. Beide werden erfolgreich und ohne Fehler gemountet und scheinen identische Dateistrukturen zu haben. Ich habe auch meine neuen und alten .configDateien für die Kernel-Builds verglichen und die Unterschiede sind unbedeutend.
Einige weitere Anmerkungen/Beobachtungen:
- Im Bild oben sehen Sie,
List of all partions:dass nichts erzeugt wird, daher frage ich mich, ob es ein Problem mit dem Dateisystemtyp gibt. Meine Festplatte istxfs, was ist das Dateisystem für dasinitramfs? CPIO? - In der
grub>Befehlszeilels /wird das angezeigt, was ich erwarte/boot. Es enthält alle meinevmlinuz-*undinitramfs-*.imgDateien - Mein Dateisystem ist
xfs - Ich habe verschiedene andere Kernel-Versionen mit den gleichen Ergebnissen ausprobiert
- Ich habe zweimal erfolgreiche Builds und Installationen durchgeführt, einmal mit dem vorhandenen Kernel (4.19.10), es war ein Upgrade, und ein zweites Mal mit demselben Kernel mit einem
low-latencyPreemption-Modell. Ich kann beim besten Willen nicht herausfinden, was ich damals anders gemacht habe.
Die letzte(n) Frage(n) lautet(en): Was ist falsch an der initramfsForm dieser Builds? Was kann ich sonst noch tun, um ihre Integrität zu überprüfen? Gibt es Änderungen, die ich beim Erstellen des Kernels für das Dateisystem .configvornehmen sollte ?xfs
Haftungsausschluss: Dies ist eigentlich eine Fortsetzung vondiese Frage, aber ich habe das Problem etwas vereinfacht. Einige Hintergrundinformationen könnten relevant sein.