Manjaro KDE, wie viel Speicherplatz für Home Partition in 1TB Partition?

[gio127]

EDIT: Und wenn du ein zweites Linux installierst ist es vielleicht ratsam, wenn du kein zusätzliches Grub installierst, sondern das vorhandene Grub von deinem Hauptsystem aus aktualisierst. Ansonsten kann es sein, dass wenn du dein Test/Lern-System löschst auch kein Grub mehr da ist um dein Hauptsystem zu starten.

Kann zwar sein, dass du es über das EFI-Bootmenü (F11) noch starten kannst, aber ich würde Grub immer nur für das Hauptsystem installieren und aktualisieren, dann findet es auch neu installierte Systeme.

Meistens kann man im Installer auch während der manuellen Partitionierung auswählen wohin Grub geschrieben oder ob es gar nicht installiert werden soll.

 

[7vor10]

Ich weiß, dass ich - obwohl ich Windows (inclusive seiner 100MB efi Partition) installiert hatte - meine Fedora Installation nicht starten wollte, mit der Meldung, dass eine /boot/efi Partition notwendig ist.

Grundsätzlich würde ich immer empfehlen, in allen Multi-Boot-Szenarien von der Methode der manuellen Partitionszuweisung Gebrauch zu machen.
Von den Methoden der automatischen Aufteilung und Zuweisung (alongside etc.) halte ich nichts. Die Installer-Programme sind leider nicht so schlau wie es wünschenswert wäre. Da kann es schnell zu Mißverständnissen kommen; sei es von seiten des Programms oder des Benutzers (, der evtl. etwas Anderes erwartet hätte).

Fedora 39 habe ich erst kürzlich testweise auf meine USB-SSD installiert (, wo zuvor schon Windows 10 als erstes System aufgespielt worden war). Ich habe bei der Installation Fedora die vorbereitete Partition für '/' zugewiesen und als EFI-Ort die bestehende EFI-Partition, wo schon der Windows-BootManager sich befindet. Resultat: Fedora besitzt einen eigenen Starteintrag im UEFI-Auswahlmenü, von dem aus es in sein Grub-Menü verzweigt, wo wiederum neben Fedora auch das externe Windows und das ebenfalls auf der SSD installierte Mint zur Auswahl angeboten wird.

Fedora braucht - wenn es als UEFI-System laufen soll - natürlich zwingend eine EFI-Partition, aber nicht unbedingt eine eigene, private. '/boot/efi' bezeichnet den Einhängepunkt dieser Partition nicht die Partition selbst.


Ich vermute auch, dass alle Einträge (beim TE) sich in derselben EFI-Partition befinden. Aber besser, man überprüft es selbst, indem man ein Linux-Live-System startet und die zu untersuchenden Partitionen temporär in der Sitzung einhängt, um sie sich im Explorer anzuschauen. Dasselbe sollte man nach jeder Installation so machen, um zu schauen, was sich verändert hat (Zeitstempel). Ich nehme für solche Zwecke immer das Tool 'gnome-disks' (= Disks bzw. Laufwerke); es liegt fast allen Live-ISOs bei. Das Tool mounted die gewünschte Partition auch automatisch an einem geeigneten Ort (in der Regel unter /mount oder /media).

Es ist auch nie verkehrt, Multi-Boot-Szenarien schon einmal vorab in einer VM durchzuspielen. Das beugt eventuell bösen Überraschungen vor.
Auch wenn es sich manchmal beim Lesen so anfühlt: das Installieren von (mehreren) OSen ist keine Raketenwissenschaft. Es braucht nur etwas Übung. Und für den Fall, dass einem während der Installation irgendwas nicht geheuer vorkommt, sofort auf Abbrechen gehen, bevor noch was auf Disk geschrieben wurde. Und dann zurück auf Anfang (z.B. auf den dieses Absatz).

Nach Manjaro Installation habe ich immer noch Fedora Eintrag, wenn ich F11 drücke

Das ist nicht weiter verwunderlich. Das UEFI weiß nämlich nichts davon, dass Du die Fedora-Partition mit Manjaro überschrieben hast. In der EFI-Partition sind ja nur die Bootstarter hinterlegt (Windows BootManager für Windows, ubuntu (Grub) für Ubuntu, Mint etc., Fedora (Grub) für Fedora usw.). Und diese Starter werden nicht automatisch gelöscht, wenn das zugehörige OS gar nicht mehr vorhanden ist.

Was das explizite Entfernen von obsoleten Systemen angeht, habe ich bisher wenig eigene Erfahrung. Ich würde es im Bedarfsfall wohl so machen wie es @gio127 veranschaulicht (Post # 20).

EDIT: Und wenn du ein zweites Linux installierst ist es vielleicht ratsam, wenn du kein zusätzliches Grub installierst, sondern das vorhandene Grub von deinem Hauptsystem aus aktualisierst. Ansonsten kann es sein, dass wenn du dein Test/Lern-System löschst auch kein Grub mehr da ist um dein Hauptsystem zu starten.

Jedes neu installierte Linux bringt sein eigenes Grub mit. Genauer gesagt, sofern es nicht denselben Startordner im EFI verwendet, wie ein schon bereits installiertes. Ich kenne das eigentlich nur von Ubuntu & Co. Also z.B. Ubuntu (Gnome), Kubuntu und Mint tragen sich im selben Startordner ein (den mit Namen ubuntu). Von daher: lieber ein Grub mehr als zuwenig. Denn standardmäßig (also nicht bei allen) werden alle zum Zeitpunkt der Installation vorgefundene OSe in das Grub-Menü eingetragen.

Es fehlen natürlich OSe, die erst nach dem Zeitpunkt der letzten Aktualisierung installiert worden sind. Ebenso sind Verweise auf danach gelöschte oder signifikant veränderte Systeme (neuer Kernel) nicht mehr gültig. Also erst wieder, sobald auch das entsprechende Grub aktualisierte wurde. Dies geschieht meist automatisch, wenn das mit dem Grub verknüpfte Hauptsystem aktualisiert wurde.

 

[gio127]

Grundsätzlich würde ich immer empfehlen, in allen Multi-Boot-Szenarien von der Methode der manuellen Partitionszuweisung Gebrauch zu machen.

Ja, das war eine manuelle Partitionierung, falls du auf mein Beispiel eingehen wolltest, mache ich immer. Aber am Ende meiner manuellen Partitionierung hat der Installer mich darauf hingewiesen, dass /boot/efi fehlt.
Ich hätte die Windows boot also unter /boot/efi einhängen können, so wie es aussieht.

Ich habe bei der Installation Fedora die vorbereitete Partition für '/' zugewiesen und als EFI-Ort die bestehende EFI-Partition, wo schon der Windows-BootManager sich befindet. Resultat: Fedora besitzt einen eigenen Starteintrag im UEFI-Auswahlmenü, von dem aus es in sein Grub-Menü verzweigt, wo wiederum neben Fedora auch das externe Windows und das ebenfalls auf der SSD installierte Mint zur Auswahl angeboten wird.

Ok, das geht also wirklich. Ich hätte mich das nicht getraut, weil ich mein vorhandenes Windows nicht verhauen wollte. Aber sehr interessante Info, danke.

In meinem Fall (2 unterschiedliche SSDs) würde ich zwar trotzdem eine eigene /boot/efi Partition auf meine Linux SSD erstellen, aber gut zu wissen, dass es geht.
Andererseits wissen wir auch, dass zwei efi Partitionen (1x Windows 1x Linux) kein Problem sind.

Nur ein zwei Fragen, vielleicht weisst du @7vor10 das:

• Windows boot ist nur 100MB groß und die Empfehlungen unter Linux sind bis zu 1GB, wieviele Linux Systeme kann man denn bei 100MB parallel in den Bootloader schreiben?
• Reicht es die Einträge per efiboomgr wieder zu löschen um den Platz wieder frei zu machen?

Aber besser, man überprüft es selbst, indem man ein Linux-Live-System startet und die zu untersuchenden Partitionen temporär in der Sitzung einhängt, um sie sich im Explorer anzuschauen.

Geht das nicht auch irgendwie im normalen Betrieb?

Jedes neu installierte Linux bringt sein eigenes Grub mit.

Es gibt mittlerweile die Option (in den Installern die ich kenne) Grub nicht zu schreiben. Und bei einer Arch Installation wird Grub sowieso nur installiert, wenn man das so angibt.

lieber ein Grub mehr als zuwenig. Denn standardmäßig (also nicht bei allen) werden alle zum Zeitpunkt der Installation vorgefundene OSe in das Grub-Menü eingetragen.

Ich weiß nicht wie sich das jetzt mit UEFI verhält. Aber als Grub noch in den MBR geschrieben wurde, ließ man nur das Hauptsystem seinen Grub-Bootloader in den MBR schreiben. Ansonsten konnten hinterher installierte und wieder gelöschte Testinstallationen dazu führen, dass kein funktionierendes Grub mehr da war.
Und weil ich mich mit UEFI noch nicht so gut auskenne halte ich es nach wie vor so.

 

[7vor10]

Ich hätte die Windows boot also unter /boot/efi einhängen können, so wie es aussieht.

Im Prinzip schon. Man beachte aber, dass die diversen Installer-Programme (Ubiquity, Calamares, Anaconda und was es sonst noch so geben sollte) unterschiedliche Benutzerführungen haben. Am einfachsten war der Ubiquity-Installer, den z.B. Ubuntu oder Mint verwenden. ("Einfach", wahrscheinlich deswegen, weil ich den am häufigsten genutzt habe. ) Allerdings hat dieser Installer die nervige Angewohnheit, den Bootstarter immer in die erste gefundene EFI-Partition zu schreiben; egal, was der User haben will. Daher muß man bei Verwendung dieses Installers immer alle sonstigen EFI-Partitionen, die während der Installation sichtbar sind, ausblenden. Ich mache das sicherheitshalber immer auch bei anderen Installern. Obwohl zumindest der Calamares-Installer diese Unart nicht besitzen soll.

Im Prinzip genügt auch eine einzige EFI-Partition für alle intern installierten OSe. Allerdings wollen sich manche User die Option offen halten, eine interne Disk später auszubauen, um sie andernorts zu booten. Dann müssen natürlich OS und zugehörige EFI-Partition auf diesem Datenträger sein.
OSe, die extern auf eine USB-HDD/SSD installiert werden, sollten hingegen immer eine eigene EFI-Partition auf dieser externen Disk unterhalten. Sonst kann es schon Probleme geben, wenn man den Rechner ohne angeschlossene, externe Disk hochfährt.

Windows boot ist nur 100MB groß und die Empfehlungen unter Linux sind bis zu 1GB, wieviele Linux Systeme kann man denn bei 100MB parallel in den Bootloader schreiben?

Die interne Disk bei mir mit Windows 10 plus zweimal Ubuntu (gleicher Starter für Ubuntu und Mint) belegt 35% der EFI-Partition mit 100 MB. Rein rechnerisch könnte ich die Anzahl der Systeme noch locker mehr als verdoppeln. Ähnlich verhält es sich auf meinen beiden Multi-OS-USB-Disks. Dennoch würde ich bei mehr als drei OSen (mit jeweils eigenen Startordner) sicherheitshalber mehr Speicher spendieren. Ein paar hundert MB sind ja fast gar nichts auf Platten in TB-Dimensionen.

Ich habe auch schon Empfehlungen gelesen für EFI-Größen von 1 GB und sogar noch weit mehr. Möglicherweise bestehen Unklarheiten darüber, was auf eine EFI-Partition überhaupt gespeichert werden soll. Bei mir befindet sich auf der EFI-Partition stets ein Ordner namens 'Boot' sowie jeweils einer pro Linux-Version (mit eigenem Bootstarter). Fedora hat, wie ich gesehen habe, noch zwei weitere winzige Objekte hinterlegt.

Was aber definitiv nichts auf der EFI-Partition zu suchen hat, sind diese ganzen Linux-Systemdateien (initrd*, vmlinuz* etc.). Die verschlingen schnell mehr als 1 GB. Die befinden sich aber auf der root-Partition und sind unter '/boot' eingehängt (nicht '/boot/efi'). Es soll auch Leute geben, die beim Installieren eine eigene Partition für '/boot' erzeugen. Sowas habe ich aber bisher nie ausprobiert, weil ich für meine Zwecke darin keinen Nutzen sehe.

Reicht es die Einträge per efiboomgr wieder zu löschen um den Platz wieder frei zu machen?

Gute Frage. Ich stand allerdings bisher noch nie vor der Notwendigkeit so etwas zu tun. Ich schätze mal, dass man den jeweils Linux-eigenen EFI-Ordner gefahrlos löschen kann. Beispiel: man hat Ubuntu und Mint installiert und überschreibt beide durch andere Distributionen; dann könnte man den EFI-Ordner 'ubuntu' löschen. Besser ist es natürlich, man macht solche Aktionen geordnet über dafür vorgesehene System-Tools. Oder spielt das Szenario in einer Mega-VM einmal durch. (Soviel ich weiß, simuliert mittlerweile auch VirtualBox 'echtes' EFI-Verhalten, nicht nur der VMware Player.)


Stichwort: EFI-Partition examinieren.

Geht das nicht auch irgendwie im normalen Betrieb?

Wenn mit 'normalen Betrieb' gemeint ist, dass das zu untersuchende System selber gerade läuft, dann ist entweder Terminal-Gefummel oder alternativ (besser) ein Datei-Explorer mit optional erhöhten Rechten angesagt. Der Nemo-Explorer unter Mint beispielsweise bietet die Option 'Als Systemverwalter öffnen' an. Dann öffnet man den Ordner '/boot' und schaltet auf diese Weise (nach Passworteingabe für den priviligierten Account) in den Admin-Modus. Danach läßt sich '/boot/efi' öffnen und lesen.

Es gibt mittlerweile die Option (in den Installern die ich kenne) Grub nicht zu schreiben. Und bei einer Arch Installation wird Grub sowieso nur installiert, wenn man das so angibt.

Wieder was dazugelernt. Arch-basierte Systeme habe ich bisher noch nicht unter UEFI installiert.

Passend zum Thema: bei Fedora habe ich vor ein paar Tagen feststellen müssen, dass es zwar die extern installierten OSe im Grub zur Auswahl anbietet, nicht aber die internen. Und das obwohl kurz nach der Installation ein Mega-Update fällig war, was bei ubuntoiden Systemen fast immer eine automatische Aktualisierung des Grub-Menüs nach sich zieht.

Aber als Grub noch in den MBR geschrieben wurde, ließ man nur das Hauptsystem seinen Grub-Bootloader in den MBR schreiben.

Ja, das ist auf Legacy-Systemen halt immer das Problem gewesen. Dass neue Installationen standardmäßig den alten Bootloader im MBR überschreiben.
Auch bei UEFI ist nicht alles Gold. Aber ein Vorteil ist, dass man mehrere Bootstarter parallel in Koexistenz unterhalten kann. Damit sind auch mehrere Grub-Auswahlmenüs auf der zweiten Boot-Ebene möglich, da jedes Auswahlmenü dem darunterliegenden Bootstarter im UEFI auf der ersten Boot-Ebene zugeordnet ist.

 

[andy_m4]

Was aber definitiv nichts auf der EFI-Partition zu suchen hat, sind diese ganzen Linux-Systemdateien

Naja. "Definitiv nichts zu suchen" fände ich jetzt ein wenig zu dogmatisch.
Der Vorteil wenn der Kernel auf der EFI-Partition liegt ist halt, das Du kein Bootloader mehr brauchst.
Und der Kernel selbst ist i.d.R. auch nicht riesen groß. Klar sollte man das berücksichtigen. Aber diese Möglichkeit jetzt kategorisch auszuschließen, das ist mir dann ein bisschen zuviel des Guten.

Es soll auch Leute geben, die beim Installieren eine eigene Partition für '/boot' erzeugen.

Das ist ein wenig historisch bedingt und hatte auch immer unterschiedliche Gründe. Ein Grund war zum Beispiel mal, das es für frühere PCs schwierig fürs BIOS war Festplattenspeicher jenseits einer bestimmten Sektorengrenze zu addressieren, was halb man dann nicht booten konnte. Die Lösung war /boot an den Anfang der Platte zu legen.
Ein weiterer Grund war/ist, das Bootloader nicht mit jedem Dateisystem umgehen können und daher dann den Kernel nicht rausfischen können. Auch hier ist ne Lösung eine eigene Boot-Partition mit einem Dateisystem, welches der Loader versteht.

Dass neue Installationen standardmäßig den alten Bootloader im MBR überschreiben.

Wobei das primär das Problem eines gewissen Betriebssystemherstellers aus Redmond war. Die Installer gängiger Linux-Distributionen schauten schon gefühlt ewig nach, ob GRUB installiert ist und fügen sich dann einfach mit ein.

 

[Garmor]

Ein weiterer Grund war/ist, das Bootloader nicht mit jedem Dateisystem umgehen können

Bzw. Verschlüsselungen. Grub kann oder konnte z.B. LUKS 2 nicht.

 

[gio127]

Es soll auch Leute geben, die beim Installieren eine eigene Partition für '/boot' erzeugen. Sowas habe ich aber bisher nie ausprobiert, weil ich für meine Zwecke darin keinen Nutzen sehe.

Wenn man sein Laufwerk verschlüsseln will, dann ist eine seperate /boot Partition notwendig.
EDIT: @Garmor hat es schon erwähnt.

Wobei das primär das Problem eines gewissen Betriebssystemherstellers aus Redmond war. Die Installer gängiger Linux-Distributionen schauten schon gefühlt ewig nach, ob GRUB installiert ist und fügen sich dann einfach mit ein.

Nicht nach meiner Erfahrung. Ich hab nur einmal den Fehler gemacht und eine zweite Linux Test-Installation Grub in den MBR schreiben lassen. Nachdem ich aus meinem Hauptsystem die Partition wieder gelöscht habe, auf der meine Test Installation lag, war kein Grub mehr da.
Im Installer gab es aber schon immer - solange ich auf Linux bin - die Möglichkeit Grub auf die / Partition zu schreiben, anstatt in den MBR. Da kann er dann mit der Installation wieder gelöscht werden und das Grub des Hauptsystem bleibt unangetastet. Man muss halt nur nach der Installation des Test-Systems Grub aus dem Hauptsystem heraus updaten, damit die neue Installation gefunden wird.
Und mittlerweile sehe ich bei allen Installern die ich probiert habe (Fedora, Calamares, openSuse...) die Option Grub gar nicht mehr schreiben zu lassen.

 

[gio127]

Passend zum Thema: bei Fedora habe ich vor ein paar Tagen feststellen müssen, dass es zwar die extern installierten OSe im Grub zur Auswahl anbietet, nicht aber die internen.

Ich weiß jetzt nicht genau was du meinst. Externe OS auf externen Datenträgern und interne auf der selben SSD wie Fedora?

Hast du versucht Grub manuell upzudaten? Das geht unter Fedora mit:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

 

[andy_m4]

Ich hab nur einmal den Fehler gemacht und eine zweite Linux Test-Installation Grub in den MBR schreiben lassen.

Du schreibst also mit Absicht in den MBR und wunderst Dich, wenn das was davor drin war kaputt ist.
Okay .... :-)

Nachdem ich aus meinem Hauptsystem die Partition wieder gelöscht habe, auf der meine Test Installation lag, war kein Grub mehr da.

Das liegt daran, das GRUB nicht komplett im MBR liegt. Moderne Bootloader/Bootmanager wie GRUB sind viel zu groß, als das sie in den MBR passen würden. Was im MBR liegt ist daher nur eine minimale Logik, um den Rest vom Bootloader/Bootmanager zu finden.

Im Installer gab es aber schon immer - solange ich auf Linux bin - die Möglichkeit Grub auf die / Partition zu schreiben

Ja. Wobei das nicht unbedingt das Problem löst. Das alte GRUB bleibt dann zwar intakt. Aber was man ja eigentlich will ist, das nicht irgendwie ein neuer GRUB mit eigener Konfiguration dazu kommt, sondern das bestehende GRUB angepasst wird.

Und das ging schon vor 20 Jahren. Ich wäre jetzt mal davon ausgegangen, das es danach eher besser wird und nicht schlechter. :-)
Gut. Heutzutage ist die Situation wegen UEFI etc. ohnehin anders. Da braucht man ja eigentlich nicht mehr groß rumhampeln und benötigt nicht mal mehr einen GRUB, da das UEFI selbst die Funktionalität mitbringt.
Aber bei legacy BIOS/MBR-Systemen sollte es trotzdem keine Probleme geben. Und wenn der Installer da trotzdem was versucht, dann einfach den Schritt überspringen und die GRUB-Konfig. manuell anpassen.

 

[gio127]

Du schreibst also mit Absicht in den MBR und wunderst Dich, wenn das was davor drin war kaputt ist.

Ja, das war mein erstes Dual-Boot Test-Linux. Mittlerweile wundert mich gar nichts mehr

 

[7vor10]

Naja. "Definitiv nichts zu suchen" fände ich jetzt ein wenig zu dogmatisch.

"Dogmatisch" sollte es auch nicht rüberkommen. Die Ausgangsfrage war ja, welche Größe man für eine EFI-Partition ansetzen soll (bei so und soviel zu installierenden OSen). Dann geht man zunächst mal davon aus, was ein OS standardmäßig (also mindestens) auf die EFI-Partition schreibt. Wenn erfahrene User da auch noch zusätzliche Systemobjekte draufschreiben lassen, steht das auf einem anderen Blatt. Und man kann in dem Fall auch nur schwer eine Antwort auf die bestmögliche Größe der EFI-Partition geben.

m Installer gab es aber schon immer - solange ich auf Linux bin - die Möglichkeit Grub auf die / Partition zu schreiben, anstatt in den MBR. Da kann er dann mit der Installation wieder gelöscht werden und das Grub des Hauptsystem bleibt unangetastet.

Mache ich noch heute so auf meinem letzten verbliebenen Legacy-Rechner. Bei jeder neuen Linux-Installation wird dessen Bootstarter mit auf die Installations-Partition geschrieben. Danach rufe ich mein Offline-Windows 7 auf und integriere das gerade installierte Linux per EasyBCD in den Windows-BootManager. Wenn ich dann den Rechner nächstes Mal hochfahre, kommt zunächst das Auswahlmenü von Windows. Für gewöhnlich habe ich da das neue Linux an die erste Stelle gesetzt, sodass es von dort aus sein eigenes Grub-Menü startet (mit allen OSen zur Auswahl inklusive Windows), um zu seinem Login-Screen durchzustarten. Erst da muß ich erstmals tätig werden, indem ich das Passwort eingebe.

Dieses Verfahren gilt heutezutage als obsolet und ist in dieser Form unter UEFI auch nicht mehr machbar.

Ich weiß jetzt nicht genau was du meinst. Externe OS auf externen Datenträgern und interne auf der selben SSD wie Fedora?

Mit 'extern' meine ich OSe, die auf der angeschlossenen, externen Disk residieren. Mit 'intern' sind die OSe gemeint, die auf der bzw. den im Rechner verbauten Disks lagern. Von ubuntoiden OSen bin ich es gewohnt, dass diese auch die internen OSe mit in ihr Auswahlmenü eintragen. Das heißt, ich kann vom Grub eines Linux auf einer externen Disk aus auch Systeme starten, die sich auf einer internen Disk befinden. Das finde ich ganz praktisch, da ich auf diese Weise nicht jedesmal die externe Disk entfernen muß, um wieder an ein intern installiertes OS heranzukommen.
Fedora macht das anscheinend aber nicht automatisch; müßte man also demnach per manuellem Grub-Update anstossen.

 

[andy_m4]

"Dogmatisch" sollte es auch nicht rüberkommen.

Dann ist aber "definitiv" eine unglückliche Wortwahl. Da wäre so was wie "in dem Fall" unmissverständlicher.
Anyway: Du hast es ja nochmal gut erklärt und damit sind ja dann etwaige Unklarheiten ausgeräumt.

Und man kann in dem Fall auch nur schwer eine Antwort auf die bestmögliche Größe der EFI-Partition geben.

Ja. Kommt auch immer darauf an, wie viel Speicherplatz man insgesamt übrig hat. Und wenn da irgendwie 1 TB Gesamtplatz vorgesehen ist, dann kann man die EFI-Partition (wie Du ja auch sagst) im Grunde auch großzügiger auslegen.

 

[D.S.i.u.S.]

Arch oder ein Derivat als Grundgerüst, damit macht man nichts verkehrt.
Custom Kernel rauf zb tkg. mesa selber bauen oder "paru/yay mesa-tkg-git"
"paru/yay proton-ge-custom-bin" und Spaß haben.

Danke für den Tipp. Ich habe nvme0n1 mit Manjaro und Windows 11 formatiert und Arch Linux installiert. Weil ich mehrmals installiert habe, habe ich einiges gelernt ;D Zuerst unverschlüsselt und ohne archinstall, dann verschlüsselt mit langem PW über archinstall , dann unverschlüsselt mit archinstall, aber mit falschem Kernel(man soll den Kernel mit Leertaste statt Enter-Taste wählen) und dann vor archinstall sector size von 512 auf 4096 byte geändert und mit "linux-zen" Kernel installiert.

Ich habe bei archinstall "proprietäre Treiber" gewählt und es wurde nichts installiert. Ich denke, wenn man es wählt, teilt man nur mit, dass man die Treiber später selber installiert.
Dann habe ich linux-tkg Kernel geholt, aber es stand während des Bootvorgangs nicht zur Auswahl.
Seitdem ich eine conf Datei in "entries" dafür erstellt habe, läuft alles wie geschmiert.

Ach ja, für "/home" habe ich keine extra Partition erstellt. Ich muss mich noch informieren, wie es mit Btrfs snapshots geht. Keine Ahnung davon.