OK, es hat funktioniert. Ich konnte Debian vollständig so wie sonst über GRUB-UEFI die Konsole laden
Das init in der dann folgenden (ash?) Konsole wurde nicht zum Erfolg. Es funktionierte nicht. Aber ich habe ich von dem Skript einiges übernommen.
Zunächst habe ich den Pfad zum eigentlichen Kernel angegeben. Und zum System zum Root-System
Wir müssen ja bedenken. Wir haben den Kernel zwei Mal. Und auch das initramd ist eigentlich nur eines : Es ist ein kleiner gepackter Teil, eine Abbildung des Root Verzeichnisses. Es existiert doppelt. Ein initramfs ist ein Abbild eines Dateisystems, das init steht dafür, dass es das init am Anfang betrifft.
Es ist gepackt und wird vom Kernel entpackt. Nun gibt es verschlüsselte Dateisysteme. Mit lvm. Überhaupt gibt es andere Dateisysteme.
Es gibt Module, die in den Kernel von Anfang an geladen werden können. Diese ermöglichen das Lesen eines Dateisystems schon zur Boot-Zeit. Doch: Eigentlich lässt sich ein Dateisystem erst lesen, wenn der Kernel gestartet ist.
Rein theoretisch ist jedes Dateisystem denkbar und rein theoretisch gibt es unendlich viele.
Es gibt Netzwerkdateisysteme und wir können unsere eigenen Schreiben, die irgendwie funktionieren. Wir müssen sie halt in den Kernel einbinden.
Das ist das berühmte mount. Dafür müssen wir dem Kernel eine Schnittstelle zur Verfügung stellen. Es gibt auch FTP, unter Linux lässt sich das Einbinden, wie alles andere
Nur, für den Kernel am Anfang geht das nicht. Es geht, deswegen gibt es: Module.
Nur, das ist was anderes. Das ist dafür da, dass der Kernel kann. Problem: der Kernel kann ein Dateisystem lesen, aber der Kernel muss ja erst da sein. Aus solchen Gründen gibt es ein initrd - ein initramfs. Nicht zu verwechseln mit initd - dem kernprozess, der alle anderen weiteren lädt.
Besonders blöd wird es, wenn es verschlüsselt wird. Deswegen gibt es eine Partition, neben initrd, indem sie das noch mal auftaucht, die garantiert lesbar ist, FAT32. Warum muss die nicht verschlüsselt sein?
Nun verschlüsselung bedeutet. Ich kann das Dateisystem nicht lesen. Den Kernel muss ich nicht verschlüsseln. Laden sie sich Linux runter, der Kernel ist immer dabei, da gibt es keine Geheimnisse.
Also, das init in der Konsole ash, die dann kam zeigte nicht die gewünschte Wirkung, aber schauen wir hier rein
load_video
insmod gzio
if [ x\$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 2ddb9013-cdc0-4dfe-b1a0-551ba99f3e7c
echo 'Loading Linux 5.10.0-15-amd64 ...'
linux /vmlinuz-5.10.0-15-amd64 root=/dev/mapper/git--vg-root ro quiet
echo 'Loading initial ramdisk ...'
initrd /initrd.img-5.10.0-15-amd64
Ich habe dazu noch angegeben:
root=/dev/mapper/git--vg-root
Das ist wichtig. Und war wohl das ausschlagebende, aber auch:
insmod gzio
insmod part_gpt
insmod ext2
Das versteht Grub. Ich weiss nicht, was von beiden jetzt wichtig war. Aber ich will es nicht ausprobieren.
Übrigens - die lieben Leute, ein Betriebssystem schreiben ist gar nicht so schwer. Klingt komisch. Aber: Zunächst mal, müssen sie wissen, dass sie auf ihren Computer hören müssen. Der Prozessor und die Hardware, sagt, was sie will.
Die Befehle des Prozessors sind wichtiger als man meint. Sie müssen nur ein Programm in Computerbefehlen schreiben, was den PC startet, und das ist relativ einfach, weil hier geben IBM und Intel den Ton an und dann sollte es gewisse Dinge können, wie auf die Festplatte schreiben und das vernünftig anordnen. Lassen sie sich inspirieren, machen sie ihre eigenen Versuche, wie, wo, was steht. Und dann sollte ihr OS noch eines können: Programme starten.
Dann hätten sie schon eines. Was die Leute sich im Nachhinein bei Grub dachten, ist ihre Idee - aber auch, das versteht man schnell
wer einen Überblick über das hat, was ein Betriebssystem ist, der wird auch schnell verstehen, was so ein Kernel tut. Da ist natürlich viel drin implementiert.
