Arch-Spielereien und aufgeworfene Fragen

[Korfox]

Ich bin gerade dabei anzufangen, mich mit Arch auseinanderzusetzen.

Grundsätzlich funktioniert die Installation so weit schon Mal ganz gut (ich denke, ich habe es jetzt ca. 10 Mal bis zum DE - MATE mit LightDM - installiert, das letzte Mal dann parallel zu Windows 10.
Und genau bei diesem letzten Mal sind mir ein paar Dinge aufgestoßen (Ziel ist es eigentlich, das Arch später anstelle meines aktuell laufenden Ubuntus parallel zu Windows 11 und mit Secure Boot zu betreiben).


Warum braucht GRUB eine zusätzliche 1MB-Partition auf UEFI-Systemen? Kann man das umgehen? Ist das sinnvoll?
Warum trage ich eine Brille, wenn ich dann doch überlese, dass das für GRUB im BIOS-Modus ist...

Aktuell arbeite ich mit systemboot - ist auch ok - die Frage ist hauptsächlich aus Interesse

Ist rEFInd eine sinnvolle Alternative zu systemboot oder GRUB, wenn man Secure Boot nutzt? Welcher der Bootloader ist da am "einfachsten" (ich vermute, dass ich shim als Chainloader nutzen wollen werde, weil es mir zu viel ist in den Keystores im UEFI rumzubasteln)
Ist es sinnvoll auf Wayland anstelle von X11 zu setzen? Klappt da alles schon problemfrei?
Muss man unbedingt den Kernel in /boot/efi liegen haben?

Wenn nein: Wie bringe ich Arch bei der Installation bei, den z.B. in /root abzulegen?
Wenn ja: Gibt es einen sinnvollen Weg, die EFI-Partition zu vergrößern, ohne den Workaround-Weg zu dem passenden GParted/libparted-Bug (https://bugzilla.gnome.org/show_bug.cgi?id=649324) zu nehmen?
Wie groß sollte die Partition sein, wenn ich keine weiteren großartigen Experimente machen möchte?
Hintergrund: Ich hasse es, mir Gedanken zu Partitionsgrößen und -strukturen machen zu müssen. Bevorzugt liegt bei mir alles auf /root, ich habe auch keine home-Partition oder so, sondern einfach nur / und swap.

Gibt es eine halbwegs verständliche Anleitung, wie ich mit shim dann Secure Boot hinbekomme
Für den Beitrag im Arch-Wiki (https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot) reichen weder meine Englisch- noch (oder dadurch?) meine Linux-Kenntnisse



Und nein, Calamares-Distributionen/Xen-Install sind für mich keine adäquaten Alternativen. Maximal archinstall würde ich noch akzeptieren, da ich die Installation des Grundsystems jetzt oft genug durchexerziert habe, um sie zu beherrschen und zu verstehen, was archinstall da tut (Ok, ich gebe zu, dass 8 von 10 Mal per SSH waren, weil irgendwann die Finger wund sind und Tippfehler so vermieden werden).

Nachtrag: Ja, ich habe noch einen langen Weg vor mir und ich rechne nicht damit, vor dem nächsten Winter produktiv Arch einzusetzen. Erst möchte ich es verstehen lernen.

[Berniyh]

Warum braucht GRUB eine zusätzliche 1MB-Partition auf UEFI-Systemen? Kann man das umgehen? Ist das sinnvoll?
Was für eine meinst du? Ich sehe nicht, warum das nötig wäre.
Oder meinst du die EFI Systempartition? Da kannst du auch die von Windows 11 nutzen, wenn du willst.
Das ist letztendlich nur eine FAT32 Partition, auf der Betriebssysteme jeglicher Art ihre Startdateien ablegen können.
Das ist typischerweise 1 Datei je Betriebssystem.

Aktuell arbeite ich mit systemboot - ist auch ok - die Frage ist hauptsächlich aus Interesse
Ist rEFInd eine sinnvolle Alternative zu systemboot, wenn man Secure Boot nutzt?

Sorry, dazu kann ich nichts sagen, ich nutze nie etwas anderes als Grub, da ich dessen Flexibilität brauche.
(e.g. Unterstützung von crypto, RAID etc. Zudem ist die Grub Konsole manchmal hilfreich.)
Ist es sinnvoll auf Wayland anstelle von X11 zu setzen? Klappt da alles schon problemfrei?
Jein, es kommt auf den Anwendungsfall an. Derzeit ist bei Wayland noch viel in der Mache. Ich nutze daher auf einem meiner PCs auch noch kwin auf X11, auf dem anderen kwin auf Wayland.

Vorteile von Wayland:
- Weniger Flackern/Grafikfehler. Die tauchen bei mir eigentlich nur noch bei Anwendungen auf die auf XWayland laufen, d.h. keinen nativen Wayland Modus haben (oder dieser deaktiviert wurde, wie ich das derzeit bei GTK Apps mache). Mich hat das Flackern bei X11 teilweise tierisch genervt, daher war mir das wichtig. Kann aber vom Compositor (ich nutze kwin) abhängig sein. Evtl. ist es mit anderen besser?
- Tendenziell etwas besser beim Displayscaling
- Besserer Support für 10bit (und höher) Displays
- Ich glaube auch es werden besser unterschiedliche Bildwiederholraten auf mehreren Monitoren unterstützt. iirc kann hier X11 nur eine Bildwiederholrate für alle Displays. Kann ich aber nicht sicher sagen, da ich keine solche Konstellation einsetze. Die Unterstützung für VRR soll meines Wissens auch besser sein.
- Manche Features wie z.B. HDR werden nur für Wayland umgesetzt werden. Aktuell ist das aber noch nicht gemacht worden.

Nachteile:
- Sollte der Compositor crashen, dann zieht das deine ganze Session runter, d.h. du landest wieder beim Login Bildschirm. Ist äquivalent zu einem Crash des X Servers, was früher häufiger mal passiert ist, heutzutage aber eher selten.
- Manche Protokolle sind noch in der Mache, z.B.:
• Hotkeys funktionieren glaube toolkit-/desktopübergreifend noch nicht optimal. Hab es aber noch nicht explizit getestet
• colord (also Farbkalibrierung) ist teilweise noch nicht komplett umgesetzt
• HDR wie oben erwähnt, aber das gibt es auf X11 ja auch nicht.
- Die wesentlichen Toolkits haben bereits Waylandunterstützung, aber nicht alle. Daher funktionieren manche Anwendungen unter Wayland nur mittels XWayland. Das ist im Normalfall kein Problem, aber es gibt immer wieder mal kleinere Probleme, weil XWayland Anwendungen nicht zu 100% so gut wie native Waylandanwendungen funktionieren. Für mich persönlich ist das kein Problem, aber es kann halt darauf ankommen welche Anwendungen du einsetzt.
- Es gibt derzeit auf Wayland (meines Wissens) keine Möglichkeit V-Sync zu deaktivieren. Wenn man einen VRR Monitor hat, dann ist das kein Problem, aber wenn man einen typischen Monitor mit fixen 60 Hz hat, dann kann das zu Output-Lag führen, was beim Spielen stören kann. Das ist für mich der wesentliche Grund, warum auf dem Spiele-PC noch X11 läuft.
- Manche Desktopumgebungen haben auch noch keinen oder nur halbgaren Support für Wayland. e.g. LXDE/LXQt, XFCE. Da musst du dich spezifisch für die DE informieren die du einsetzt.

Gibt bestimmt noch paar Dinge auf der Pro/Contra Seite, die ich vergessen hab.
Was du wie gewichtest musst du aber natürlich für dich entscheiden.
Tendenziell schlägt das Pendel aber langsam in Richtung Wayland aus. Vor einem Jahr (ich habe es immer mal wieder ausprobiert) war zumindest KDE auf Wayland echt untauglich, inzwischen läuft es echt gut. Eben so gut, dass ich es auf einem PC seit Anfang des Jahres durchgehend ohne größere Probleme einsetzen.
Ich denke im Laufe des Jahres wird sich da auch noch einiges tun. :)
Muss man unbedingt den Kernel in /boot/efi liegen haben?
Das dürfte vom Bootmanager abhängen.
Wenn nein: Wie bringe ich Arch bei der Installation bei, den z.B. in /root abzulegen?
Das solltest du nicht tun. /root ist das Benutzerverzeichnis des Benutzers root. Kerneldateien haben da nichts verloren.
Wenn ja: Gibt es einen sinnvollen Weg, die EFI-Partition zu vergrößern, ohne den Workaround-Weg zu dem passenden GParted/libparted-Bug (https://bugzilla.gnome.org/show_bug.cgi?id=649324) zu nehmen?[/quoted]
Du kannst ja die Partition im laufenden System löschen (vorher natürlich ggf. Dateien runterkopieren, wenn z.B. dein Kernelimage da liegt), dann vergrößern und dann neu anlegen.
Musst dann natürlich daran denken ggf. die UUIDs in /etc/fstab neu anzupassen und den Bootmanager neu zu installieren, so dass du es auch wieder booten kannst.
Prinzipiell muss die Partition jedenfalls nicht eingehängt/vorhanden sein, damit das System laufen kann, daher kann man die im laufenden System austauschen.
Wenn du das vorhast, dann sollten wir aber das noch mal im Detail durchgehen, denn da gibt es viele Fallstricke über die du stolpern kannst.
[quote] Wie groß sollte die Partition sein, wenn ich keine weiteren großartigen Experimente machen möchte?
Kommt auf die Bootmethode an. Bei mir liegt da nur die efi Datei von Linux (und ggf. Windows).
Da kommen nur ein paar MB zusammen.
Kernelimage liegt bei mir auf /boot. Wenn man das auch in die efi Partition schieben muss (weil der Bootmanager das so braucht), dann muss sie natürlich entsprechend größer sein.
Bei mir nehmen die Kerneldateien (also Kernelimage, initrd, initrd-fallback) so ca. 110 MB pro Version ein. Ich würde mal sicherheitshalber für mind. 5 Versionen planen, auch wenn man im Normalfall nur 2 installiert hat. Also mach am Besten eine 1 GB Partition.
Hintergrund: Ich hasse es, mir Gedanken zu Partitionsgrößen und -strukturen machen zu müssen. Bevorzugt liegt bei mir alles auf /root, ich habe auch keine home-Partition oder so, sondern einfach nur / und swap.
Ah, jetzt verstehe ich das mit /root. Bitte hier vorsichtig sein. / und /root sind nicht das gleiche.
Prinzipiell brauchst du auf einem UEFI System nur 2 Partitionen: / und die EFI Systempartition. Letztere kann auch mit Windows geteilt werden (so mache ich das). Alles andere ist optional.
Wenn man LVM oder btrfs nutzt, dann kann man sich das auch noch mal in Subvolumes unterteilen, denen man Platzbeschränkungen zuteilen kann, aber muss nicht sein.
swap kann man als Partition anlegen, inzwischen wird aber glaube ich auch swap als Datei ganz gut unterstützt.
Kann das aber nicht ganz sicher sagen, da ich keine swap nutze.

[Korfox]

Was für eine meinst du? Ich sehe nicht, warum das nötig wäre.
Erstmal: Danke für die ausführliche Antwort :). Die hast du getippt, während ich einen Ninja-Edit gemacht habe. Die erste Frage ist im Endeffekt geklärt.


Sorry, dazu kann ich nichts sagen, ich nutze nie etwas anderes als Grub, da ...
Wayland
...

Ok. Ich habe jetzt auch Mal mit GRUB installiert. Das gestaltet sich etwas komplizierter (os-prober findet mein Windows erst nach einem Reboot, aber zuverlässig scheint es tropsdem zu sein).
Zu Wayland: Dann bleibe ich wohl erstmal noch bei X11, bis die Doku im Arch-Wiki da deutlich stärker ausgereift ist. Ich habe da Zeit. Ich nutze im Endeffekt eh nur MATE in der Default-Config (was auch immer da Compositor ist... marco, vermute ich).

Das dürfte vom Bootmanager abhängen.

Kommt auf die Bootmethode an. Bei mir liegt da nur die efi Datei von Linux (und ggf. Windows).
Da kommen nur ein paar MB zusammen.
Kernelimage liegt bei mir auf /boot. Wenn man das auch in die efi Partition schieben muss (weil der Bootmanager das so braucht), dann muss sie natürlich entsprechend größer sein.
Bei mir nehmen die Kerneldateien (also Kernelimage, initrd, initrd-fallback) so ca. 110 MB pro Version ein. Ich würde mal sicherheitshalber für mind. 5 Versionen planen, auch wenn man im Normalfall nur 2 installiert hat. Also mach am Besten eine 1 GB Partition.

Das kapiere ich nicht... absolut nicht.
Ich gehe aktuell im Endeffekt nach der Anleitung im Arch-Wiki vor: https://wiki.archlinux.de/title/Anleitung_f%C3%BCr_Einsteiger
Teilweise mische ich das noch mit dem englischen Arch-Wiki oder ein paar Kleinigkeiten, die ich für mich als sinnvoller rausgefunden habe. Aber das relevante ist aus dem Wiki.

Wenn ich nach dem Arch-Wiki vorgehe, dann wird das EFI-Volume nach /boot gemounted (ist ja auch ok). Und die Installation des Kernels führt dann dazu, dass in /boot (also auf dem EFI-Volume) die Images abgelegt werden (mit je ca. 110MB und nochmal 110MB Fallback).

Unter Ubuntu wird das EFI-Volume nach /boot/efi gemountet und die Kernel-Images liegen auch unter /boot (was in dem Fall ja dann in meinem EXT4-Root-Dateisystem ist, weil da nichts weiter hingemountet wird...). In /boot/efi liegen nur ... naja da wird es für mich kryptisch :D.. shim und Konfig-Files, was dann zusammen halt GRUB chainloading betreibt (wobei mir der Mechanismus auch noch nicht 100% klar ist). Dadurch stört es nicht, dass das EFI-Volume nur 100MB groß ist (30-40MB braucht Windows, 4-5MG shim+Konfigfiles).

Jetzt bin ich eben einfach Mal kackendreist hingegangen und habe das EFI-Volume nach /boot/efi gemountet - und bums erzeugt er mir die Images in /boot/efi, wenn ich den Kernel installiere. Brachte also ... null.

Jetzt bin ich unsicher, wann die Images nach /boot/efi (bzw. /boot) geschrieben werden. Da fehlt mir dann wieder der Durchblick.

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Arch-Linux-grub
Installing for x86_64-efi platform.
grub-install: error: cannot copy `/boot/grub/x86_64-efi/core.efi' to `/boot/efi/EFI/Arch-Linux-grub/grubx64.efi': No space left on device.

Irgendo da muss es hängen. Wenn ich noch von außen den Kernel installiere, dann wandern die Images, wenn ich das richtig sehe, nach /boot. Erst in der chroot-Umgebung mache ich irgendwas, das die Images dann nach /boot/EFI kopiert.
Das ist im Endeffekt das Spiel, das ich da spiele. Ich möchte ja GRUB nach /boot/efi installieren (das sehe ich doch richtig, oder?).
Und anschließend liegen die Images zusätzlich wieder in /boot/efi...

Mir fällt gerade auf, dass ich die EFI-Partition ja Mal aufräumen könnte, damit meine alten Versuche sich da nicht mehr rumtummeln.

Ah, jetzt verstehe ich das mit /root. Bitte hier vorsichtig sein. / und /root sind nicht das gleiche.
Prinzipiell brauchst du auf einem UEFI System nur 2 Partitionen: / und die EFI Systempartition. Letztere kann auch mit Windows geteilt werden (so mache ich das). Alles andere ist optional.
Wenn man LVM oder btrfs nutzt, dann kann man sich das auch noch mal in Subvolumes unterteilen, denen man Platzbeschränkungen zuteilen kann, aber muss nicht sein.
swap kann man als Partition anlegen, inzwischen wird aber glaube ich auch swap als Datei ganz gut unterstützt.
Kann das aber nicht ganz sicher sagen, da ich keine swap nutze.
Ja, SWAP geht als file oder als Partition. Ich bin da irgendwie altmodisch... keine Ahnung. Aber bei SWAP weiß man auch immer, wie groß es sein muss: Wenn man Suspend/Hibernate nutzen möchte, dann mindestens RAM-Größe. Und größer muss es auch nicht sein.
Mir ist es halt zuwider mir Gedanken machen zu müssen:
So... EFI ist jetzt 300MB groß, 50MB gehen für Windows drauf, dann sind noch 2 Kernel-Images möglich, dann ist das voll.
HOME ist jetzt 40GB groß, dann kann ich noch 30 Filme speichern.
ROOT ist jetzt 10GB groß, da muss ich aufpassen, ob ich libreoffice noch installieren kann...
Und sorry für die Konfusion mit /, /root und ROOT. Ich meinte grundsätzlich die Partition, die im Wiki mit dem Label "ROOT" angelegt wird und das Wurzeldateisystem enthält. Da hätte ich gerne irgendwo die Images drauf liegen :D.

Wie man die EFI-Partition über Umwege größer kriegt weiß ich schon, Habe ich schon durchgespielt. Und genau deshalb fragte ich nach, ob es da elegantere Wege gibt, als Inhalt rauskopieren, auf ext4 formatieren, vergrößern, auf FAT32 formatieren, Inhalt rein kopieren.


EDIT: Gerade den Bootloader-Kram muss ich definitiv noch deutlich besser durchschauen. Ich will ja anschließend noch wegen Secure Boot mit shim chainloaden.

[Berniyh]

Zu Wayland: Dann bleibe ich wohl erstmal noch bei X11, bis die Doku im Arch-Wiki da deutlich stärker ausgereift ist. Ich habe da Zeit. Ich nutze im Endeffekt eh nur MATE in der Default-Config (was auch immer da Compositor ist... marco, vermute ich).
Da spricht auch nichts dagegen. X11 wird bis auf weiteres auch unterstützt werden. Nur neue Features wird es eben nicht geben.
Ich denke wenn HDR Support drin ist, dann kann man es sich lohnen es auszuprobieren, soweit das für einen interessant ist.

Das kapiere ich nicht... absolut nicht.
Ich gehe aktuell im Endeffekt nach der Anleitung im Arch-Wiki vor: https://wiki.archlinux.de/title/Anleitung_f%C3%BCr_Einsteiger
Teilweise mische ich das noch mit dem englischen Arch-Wiki oder ein paar Kleinigkeiten, die ich für mich als sinnvoller rausgefunden habe. Aber das relevante ist aus dem Wiki.

Wenn ich nach dem Arch-Wiki vorgehe, dann wird das EFI-Volume nach /boot gemounted (ist ja auch ok). Und die Installation des Kernels führt dann dazu, dass in /boot (also auf dem EFI-Volume) die Images abgelegt werden (mit je ca. 110MB und nochmal 110MB Fallback).

Unter Ubuntu wird das EFI-Volume nach /boot/efi gemountet und die Kernel-Images liegen auch unter /boot (was in dem Fall ja dann in meinem EXT4-Root-Dateisystem ist, weil da nichts weiter hingemountet wird...). In /boot/efi liegen nur ... naja da wird es für mich kryptisch :D.. shim und Konfig-Files, was dann zusammen halt GRUB chainloading betreibt (wobei mir der Mechanismus auch noch nicht 100% klar ist). Dadurch stört es nicht, dass das EFI-Volume nur 100MB groß ist (30-40MB braucht Windows, 4-5MG shim+Konfigfiles).

Jetzt bin ich eben einfach Mal kackendreist hingegangen und habe das EFI-Volume nach /boot/efi gemountet - und bums erzeugt er mir die Images in /boot/efi, wenn ich den Kernel installiere. Brachte also ... null.

Jetzt bin ich unsicher, wann die Images nach /boot/efi (bzw. /boot) geschrieben werden. Da fehlt mir dann wieder der Durchblick.
Ok, ich glaube ich verstehe jetzt woher die Verwirrung kommt.
Also erstmal, EF00 ist die EFI Systempartition. Dafür brauchst du in einem UEFI System mindestens eine. Mehr als eine ist nicht notwendig, kann man aber machen, wenn man z.B. die Windows EFI Partition nicht anrühren will.

Traditionell ist es so, dass Kernel Images, initrd (initial ramdisk) unter /boot liegen.
Oftmals ist /boot auch auf einer separaten Partition, zwingend notwendig ist das aber nicht.
Gründe, die dafür sprechen können sind:
- Bootloader unterstützt / Dateisystem nicht
- /usr liegt auf einer eigenen Partition, die erst gemounted werden muss, ggf. aus dem Netzwerk
- / ist verschlüsselt. Komplett verschlüsselt (also inkl. /boot) geht, ist aber komplizierter.

Für die typischen Desktopsysteme sind solche Gründe nicht so relevant, insofern kann man sich die separate /boot Partition auch sparen.
Wo die EFI Partition eingehängt wird ist im Prinzip erst einmal egal.
Man muss es seinem Bootmanager halt mitteilen wo das ist.
Hier mal als Beispiel meine Konfiguration am Spiele PC:
berniyh@draco:~ [i] $ find /boot
/boot
/boot/efi
/boot/efi/EFI
/boot/efi/EFI/Microsoft
/boot/efi/EFI/Microsoft/Boot
/boot/efi/EFI/Microsoft/Boot/memtest.efi
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
/boot/efi/EFI/Microsoft/Boot/cs-CZ
/boot/efi/EFI/Microsoft/Boot/cs-CZ/bootmgfw.efi.mui
/boot/efi/EFI/Microsoft/Boot/cs-CZ/bootmgr.efi.mui
--- snip ---
/boot/efi/EFI/Microsoft/Boot/zh-TW
/boot/efi/EFI/Microsoft/Boot/zh-TW/bootmgfw.efi.mui
/boot/efi/EFI/Microsoft/Boot/zh-TW/bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/BOOTSTAT.DAT
/boot/efi/EFI/Microsoft/Boot/Fonts
/boot/efi/EFI/Microsoft/Boot/Fonts/jpn_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/kor_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/wgl4_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/chs_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/cht_boot.ttf
/boot/efi/EFI/Microsoft/Boot/BCD.Backup.0001
/boot/efi/EFI/Microsoft/Boot/BCD
/boot/efi/EFI/Microsoft/Boot/BCD.LOG
/boot/efi/EFI/Boot
/boot/efi/EFI/Boot/bootx64.efi
/boot/efi/EFI/Arch Linux
/boot/efi/EFI/Arch Linux/grubx64.efi
/boot/grub
/boot/grub/fonts
/boot/grub/fonts/unicode.pf2
/boot/grub/locale
/boot/grub/locale/ast.mo
/boot/grub/locale/ca.mo
--- snip ---
/boot/grub/locale/zh_TW.mo
/boot/grub/themes
/boot/grub/themes/starfield
--- snip ---
/boot/grub/x86_64-efi
/boot/grub/x86_64-efi/acpi.mod
--- snip ---
/boot/grub/x86_64-efi/grub.efi
/boot/grub/grub.cfg.example
/boot/grub/grubenv
/boot/grub/grub.cfg.backup
/boot/grub/grub.cfg
/boot/amd-ucode.img
/boot/vmlinuz-linux-lts
/boot/vmlinuz-linux
/boot/initramfs-linux-lts.img
/boot/initramfs-linux-lts-fallback.img
/boot/initramfs-linux.img
/boot/initramfs-linux-fallback.img
/boot ist dabei keine eigene Partition, /boot/efi (also die EF00 Partition) hingegen schon.
Die Dateien in /boot/efi nehmen dabei inkl. der Windows Dateien bei mir 18 MB ein, ist also überschaubar.

Ob man so ein Layout mit anderen Bootmanagern verwenden kann, oder ob diese Bootmanager dann explizit die Kernel Images auf der EF00 Partition benötigen kann ich leider nicht sagen, da ich wie gesagt nie etwas anderes als GRUB verwendet habe.

Für GRUB müsste man hierfür dann einfach
--efi-directory=/boot/efi
als Parameter übergeben.
Warum die Anleitung hier
https://wiki.archlinux.de/title/GRUB
das nicht erwähnt ist mir unklar.
Letztendlich halte ich es zumindest für GRUB für ziemlich ungünstig die Images in die EFI System Partition zu installieren.


So... EFI ist jetzt 300MB groß, 50MB gehen für Windows drauf, dann sind noch 2 Kernel-Images möglich, dann ist das voll.
HOME ist jetzt 40GB groß, dann kann ich noch 30 Filme speichern.
ROOT ist jetzt 10GB groß, da muss ich aufpassen, ob ich libreoffice noch installieren kann...
Puh, 10 GB ist schon arg eng. Bei mir hat /usr 51 GB.

Und sorry für die Konfusion mit /, /root und ROOT. Ich meinte grundsätzlich die Partition, die im Wiki mit dem Label "ROOT" angelegt wird und das Wurzeldateisystem enthält. Da hätte ich gerne irgendwo die Images drauf liegen :D.
Ne, mach das nicht. Die sollen nach /boot, schon alleine, weil es Skripte gibt die die da erwarten.
Wenn du EFI separieren willst, dann mounte die nach /boot/efi oder /efi o.ä.
EDIT: Gerade den Bootloader-Kram muss ich definitiv noch deutlich besser durchschauen. Ich will ja anschließend noch wegen Secure Boot mit shim chainloaden.
Sorry, damit habe ich mich nie beschäftigt.
Ist für mich auch keine Option, denn die Windows 7 Installation, die da noch vor sich hingammelt funktioniert nicht mal ohne CSM, egal ob mit oder ohne Secure Boot.

Edit: hier gibt es einen Vergleich der Bootloader:
https://wiki.archlinux.org/title/Arch_boot_process#Feature_comparison

EFISTUB (ist das das was du verwendest?), systemd-boot mit/ohne UKI können dabei nur Dateien laden die auf der EFI Partition liegen, d.h. dafür muss die größer sein.

[Korfox]

Ich habe bisher Systemd-boot benutzt. Jetzt aktuell bin ich dabei auf Grub zu switchen. Und so, wie es bei dir ist, will ich es haben :D

Jetzt sind erst mal die Kinder dran. Insgesamt ist das alles nicht eilig. Das wird sich noch über Monate ziehen. Ist ja einfach nur Freizeit.

Nachtrag:
Großartig, das hat funktioniert :)
Dankeschön!
Dann muss ich noch shim lernen. Prinzipiell kann ich das bestimmt auf dem T420 spielen, aber wirklich testen kann ich das darauf nicht mangels Secure Boot. Mal sehen, wie ich das löse.

[Korfox]

Ich habe jetzt Mal aus Neugierde Endeavour und Reborn jeweils installiert und ein pacman -Q gemacht. Die Liste vergleiche ich mit meiner letzten manuellen Installation.

Hintergrund: Irgendwie habe ich Angst essentiell etwas zu vergessen :D. Zumal das ja am Ende auf einem Laptop laufen wird. Die Unterschiede sind gar nicht so massiv.

Jetzt muss ich mir bei Paketen, die ich nicht kenne, schauen, warum sie da sind oder nicht da sind (und raus finden, warum z.B. in meiner manuellen Installation ein Apache oben ist...). Die Konfigurationsdateien habe ich nicht gesichert - das wäre vielleicht auch noch eine Idee gewesen (ich vermute z.B. eher, dass es an einer COnfig liegt, als an einem fehlenden Schriftartenpackage, dass MATE eine hässliche Schriftart hat).