XeroHero Keine Ahnung ob ich auf die Verzichten kann.. wenn ich den HOOK raus nehme
Wie gesagt, du mußt es austesten. Für Wayland und die meisten anderen Grafikkarten-Module ist es unabdingbar/ratsam die KernelMode-Treiber zu verwenden(statt z.B. xf86-intel auch für XOrg). KMS ist also eine "Bedingung". Für's initramfs bzw. den weiteren Bootprozess stellt sich halt die Frage, zu welchem Zeitpunkt die KMS-Module verwendet werden sollen/müssen. EarlyKMS (und das bedeutet der KMS-Hook) wäre ggf. nur nötig für stark "gepimte" Bootloader-Themen oder Dinge wie Plymouth. Es kann sein, das EarlyKMS auchz notwendig ist bei ggf. Laptops(teils abgespecktes UEFI) und externem Monitor. Oder bei Monitoren mit 23k und HDR. Aber oft reicht die "späte" Initialisierung von KMS vollkommen aus, man kann also auf den KMS-Hook im initramfs verzichten.
Zum Austesten halt eine Möglichkeit parat haben die Änderung ggf. rückgängig machen zu können (wenn man in der UEFI oder rescue-shell landet statt eines normalen Boots).
So wie ich es sehe hast du auch eine NVidia-Karte.
Ich weiß nicht, welchen Treiber/Modul du verwendest (proprietär oder nouveau), aber mit dem KMS-Hook wird der nouveau-Treiber und die gesamte nvidia-Firmware eingebunden. Will man keinen nouveau muß man die nvidia_*-Module einbinden (siehe auch nvidia Wikiseite auf .org). Das macht das initramfs allerdings wieder "groß".
Wenn das "später" (also ohne KMS-Hook und ohne explizite MODULES=) ausreicht, ist das IMHO die beste Möglichkeit um das initramfs "klein" zu halten. Das "Ding" wird ein paar Sekunden genutzt und hat im späteren Betrieb keinerlei Wirkung mehr.¹
Nvidia (open oder proprietär Treiber) hat halt unter Linux immer noch ein paar Tücken (ich selbst fahre seit Jahrzehnten gut mit Linux+Nvidia). Ich habe seit >10 Jahren gerade mal mein System "neu" aufgesetzt (UEFI, BTRFS, Wayland) und mußte grundlegend nur das Problem mit dem simple_drm-Device "lösen", da nvidia und Kernel da Probleme haben.
Um simple_drm "los" zu werden verwende ich den Kernel-Bootparameter:
initcall_blacklist=simpledrm_platform_driver_init
Das verhindert simple_drm und bewirkt das meine NVidia auch als "erste" (hier einziges) DRM-Device gesehen wird, also als card0 angesprochen wird in /sys/class/drm/
Ohne diesen Parameter belegt das (später inaktiv) simpledrm-Device den Platz der card0 (nvidia-Treiber dann card1), was v.a. bei Tools wie gamemode o.ä. für "Verwirrung" sorgen.
¹ Ich kann mich noch an Zeiten erinnern, als der Linux-Kernel + System (Shell-Login) noch auf eine Diskette paßte (1,44 MB) !
//Edit: (zu initramfs generell)
Die aktuell Default verwendeten HOOKs in mkinitcpio.conf sehen ja so aus:
HOOKS=(base systemd autodetect microcode modconf kms keyboard keymap sd-vconsole block filesystems fsck)
Zum einen wird aktuell als "initramfs-Umgebungs-Shell" systemd statt busybox(udev) verwendet. Ich selbst nutze weiterhin udev statt systemd.
Und der KMS-Hook ist halt auch aktiviert (was default "Sinn" macht im Sinn von: das System soll möglichst universell funktionieren).
Beides bläht aber die Größe der Images (wie gesehen) immens auf, was dann zu eben jenen/deinem Problem mit dem Platz führt. Die ESP-Partition ist halt meist zu "klein" wenn man (teils veralteten Videos oder sonstigen Anleitungen) folgt. Oder durch bestimmte Installer beim Partitionieren. Oder wenn die ESP von bestimmten anderen Betriebssystemen angelegt wurde.
Das kann man auf verschiedene Arten "regeln", in deinem Fall wäre der Versuch ohne den kms-Hook halt der aussichtsreichste.
Weitere "Optimierungen" für das initramfs halte ich persnlich für Zeitverschwendung, v.a. wenn sich die "gesparte Bootzeit" im (Milli)-Sekundenbereich bewegt, oder die Größe im wenigen MB-Bereich. Man muß schon etliche Bootvorgänge machen um z.B. die in die "Optimierung" gesteckte Zeit wieder "aufzuholen".
Etwas anderes ist es, wenn bestimmte Hooks oder dadurch verwendete Software/Module den Bootvorgang signifikant beeinträchtigen.
//Edit2: Zur Einbindung von microcode
Der aktuelle Weg ist die ins initramfs per microcode-Hook. Andere/"alte" Verfahren z.B. per Bootloader-Image sind IMHO unnötig, die Methode über kernel-Presets wird irgendwann rausfallen.
Es ist also sehr ratsam, diesen Hook drin zu haben. Wenn man die (CPU)-Mitigations und die (UEFI)-Firmwareupdates nutzen will, dann soll/muß das zum frühstmöglichem Zeitpunkt geschehen. Nur ggf. "Hardcore-Gamer" verzichten auf den zusätzlichen Schutz durch microcode-Updates.