SSDs, SATA, NVMe, UEFI und Partitionen

[MegaVolt]

Ich bin gerade dabei, meine langsame Daten-HDD durch eine tolle neue M.2 NVMe SSD zu ersetzen (daher auch dieses Topic, die alte HDD ist eine der Platten die ich dann "übrig" haben werde).
Nun bin ich allerdings unentschlossen, wie ich das am besten aufsetze. Ich habe da ein paar Ideen und teilweise auch Präferenzen, würde aber ein Experten-Brainstorming zu den Optionen sehr begrüßen.

Aktuelles Setup:
- 250 GB SATA SSD mit Windows und viel gespielten Spielen
- 60 GB SATA SSD mit Linux
- 2 TB HDD für Daten und alles was nicht auf den Systemlaufwerken liegt (inkl. Spielen die nicht auf die Windows SSD passen)
Diese HDD wird nun durch eine gleichgroße NVMe SSD ersetzt.

Frage 1
Ich könnte die beiden SATA SSDs herauswerfen und einfach diverse Partitionen auf der neuen SSD anlegen, Platz hat sie ja genug. Alternativ kann ich die alten SSDs als Systemplatten behalten und dann "saubere" (d.h. tatsächlich physisch getrennte) Platten für die unterschiedlichen Betriebssysteme haben. Aktuell tendiere ich zu letzterem, habe dafür aber keine wirklichen Argumente außer "das macht man halt so" - wieso macht man das eigentlich so? Oder ist alles auf die NVMe SSD packen vielleicht sogar die bessere Idee?

Angenommen ich behalte die SATA SSDs, dann hätte ich diverse Möglichkeiten das System aufzusetzen. Die einfachste wäre, alles so zu lassen wie es ist und wirklich nur die HDD durch die SSD zu ersetzen, fertig.
Allerdings ist mein System aktuell als legacy MBR boot aufgesetzt. So doof ich EFI auch aus OCD-Gründen finde (wer will schon seine Festplatte mit einer doofen FAT32-Partition verschandeln, einfach grauenhaft), es ist wohl an der Zeit mal umzustellen, also würde ich tendenziell die Gelegenheit nutzen wollen.

Frage 2
Ich tendiere dazu, die EFI-Bootpartition auf der M.2-SSD einzurichten. Das ist die einzige Platte, die mich mit an Sicherheit grenzender Wahrscheinlichkeit noch sehr lange begleiten wird, die kleineren werden ggf. ausgemustert, d.h. wenn eine Platte den Bootvorgang steuern sollte dann diese, oder?
Alternativ könnte ich auch jeweils eine EFI-Partiton auf jede der Platten packen, so dass jede für sich alleine bootbar wäre, und dann über die Firmware die auswählen, auf die ich gerade Lust habe, oder? So ist es bei der ganzen EFI-Geschichte natürlich nicht vorgesehen, aber würde ich damit ggf. etwas kaputt machen? Würde etwas dagegen sprechen?

Das führt dann auch zum nächsten Punkt, nämlich EFI-Bootmanager vs Linux-Bootloader. Eine Linux-Partition im System ist gesetzt. Der normale Weg dabei ist es ja, dass vom EFI-Bootmanager (auf welcher Partition das auch immer untergebracht sein möge) an den Linux Bootloader übergeben wird und dieser dann den Kernel läd. Ich würde entsprechend den EFI-Boot so einrichten, dass er immer direkt an Linux übergibt und der Linux-Bootloader kann dann entweder den Kernel oder Windows booten.
Theretisch wäre es allerdings auch machbar, direkt im EFI-Bootmanager zwischen Linux-Bootloader und Windows zu entscheiden und dann den nachgelagerten Linux-Bootloader automatich und ohne Auswahl direkt Linux laden zu lassen.

Frage 3
Das macht man allerdings eher nicht, da die Firmware-gesteuerten EFI-Bootmanager oft suboptimal sind und der Linux-Bootloader in der Regel viel besser ist, korrekt? Es gibt keinen Grund warum man zur Auswahl des zu startenden Betriebssystems den EFI-Bootmanager ggf. dem Linux-Bootloader gegenüber bevorzugen sollte, oder?

Nun habe ich kürzlich vom tollen EFIStub erfahren (siehe https://wiki.archlinux.org/index.php/EFISTUB und https://wiki.debian.org/EFIStub). Kurzfassung: Man kann den Linux-Kernel auch auf der EFI-Partition unterbringen und diesen dann via UEFI direkt, ganz ohne Linux Bootloader, starten lassen.

Frage 4
Sehe ich es richtig, dass dieses Verfahren aktuell noch eher frickelig/experimentell ist? D.h. man muss den Kernel manuell kopieren oder sich dazu eigene Skripte schreiben (bzw. sie aus der Wiki übernehmen) und dann hoffen, dass bei Kernel-Updates nichts kaputt geht?
D.h. aktuell wäre es eher empfehlenswert, die Finge davon zu lassen? Umstellen geht ja später auch noch problemlos, falls eine Distribution das mal irgendwann ganz bequem und automatisch unterstützt.

Frage 5
Für diesen Fall würde es sich wahrscheinlich lohnen, die EFI-Partition etwas größer zu wählen, damit ausreichend Platz für zukünftige Linux-Kernel ist, oder? Ein paar GB sind ja bei einer TB-Platte reichlich egal. Im Internet finde ich viel zur Mindestgröße und kaum etwas zur Maximalgröße. Ist da FAT die einzige Limitierung oder gibt es einen Grund, die Partition eher klein zu halten?

Frage 6
Noch eine Kleinigkeit: Sollte man eigentlich immer noch den Windows Schnellstart bei Multi-Boot (mit Linux) deaktivieren oder wurden die damit verbundenen Probleme mittlerweile behoben? Ich finde hierzu leider nur recht alte Quellen und keine Aktualisierungen. Schreibzugriff auf die Windows-Partition brauche ich von Linux aus i.d.R. nicht.

Danke schon mal für die Unterstützung

 

[Shihatsu]

Antwort 1
Das dogma heisst "Seperation of Concerns" und kommt eigentlich aus der Software-Entwicklung, macht aber auch bei Hardware viel Sinn. Unabhängigkeit von Systemen (=Programmcodeteilen) die nichts miteinander zu tun haben ergeben bessere Skalierbarkeit, Wartbarkeit und Modularität - Imho ist das genau das was du brauchst. Windows SSD is kapott? Weg damit. Du willst kein Dual-Boot mehr? Weg mit der Linux-SSD (lol, geiles Beispiel, ich weiß). Eine der beiden geht kaputt? Gut, musst dich beim neukaufen und Backup rüberschmeissen nur um eine kümmern (pro-tip aus eigener Erfahrung vom letzten Freitag: Ne gesicherte Grub-Conf sollte man haben - FML, Shihatsu hassen diesen Tip).
Ja, die boot-partition "verschandelt" das alles, aber ich hab die im Dolphin halt unsichtbar gemacht in Places, sehe sie also nicht, und seit "neulich" mach ich von der auch nen Backup via GRSync. Soll sie doch da rumoxidieren.
Antwort 2
Ich hab ja kein Dual-Boot mehr, hatte das aber völlig getrennt: Eine SSD mit Linux-Bootloader (die die das jetzt immer noch macht, die schnelsste, neueste, größte im System, wegen genau deinen Gründen) und eine SSD mit Windows-Bootloader - und gebootet hab ich dann Linux, und nur wenn ich es brauchte bein Booten F8 gedrückt, einnmal Pfeil runter, Enter, hallo W10. Ihr fandet das alle doof, aber mir erschien es aus Seperation of Concerns Gründen am saubersten. Ausserdem wollte ich W10 ja eh über kurz oder lang loswerden, daher war das mein Weg, mal so als dritte Möglichkeit. Ne wirkliche Hilfe bin ich hier nicht, sorry.
Antwort 3-5
Ogott, das hört sich einfach falsch an. Mein Kopf tut allein vom lesen weh. Hier wird HArdware, Software, Bott und Kernel irgendwie in den Mixer geworfen und raus kommt nen bootbares System. Macht UEFI in meinen Augen NOCH intransparenter. Und das in Zeiten von IME, massiven Seitenkanalangriffen und einem HW-Bug nach dem nächsten. Do not want.
Antwort 6
Also vor nem Monat waren die Probleme noch nicht behoben. Die NTFS-PArtitionen von Windows waren immer read-only. Ansonsten hatte es aber keine Nachteile. Ich fands "hässlich".

 

[drwilly]

pro-tip aus eigener Erfahrung vom letzten Freitag: Ne gesicherte Grub-Conf sollte man haben

https://rodsbooks.com/refind/

edit: Als bootloader. Erkennt kernel im bootdir automatisch und eigentlich ist alles was man konfigurieren muss die partition die gebootet werden soll.

 

[Shihatsu]

Les ich mir mal später in Ruhe durch, keiner eurer Tips war bisher "schlecht" - magst du trotzdem nen kurzen tldr geben wofür du es nutzt?

 

[MegaVolt]

Cooler Link, danke. Von rEFInd hatte ich auch schon mal kurz gelesen und es klang interessant, bisher fehler mir aber die Muße mich damit auseinander zu setzen. Wird nun nachgeholt
tl;dr für Shi, jedenfalls nach meinem noch recht frischen Verständnis von der Sache, bitte korrigieren falls es falsch sein sollte:
rEFInd ist ein nettes Tool, welches den quasi-Linux-Standard GRUB für EFI-Systeme ersetzen kann. Es ist "nur" ein Bootmanager, kein Bootloader, d.h. es bietet "nur" ein Auswahlmenü beim Boot inkl. dahinterliegender Logik (welche im Wesentlichen die Einträge im Menü bestimmt), die dann zum eigentlichen Bootloading die standardmäßigen UEFI- bzw. Kernel-Funktionalitäten nutzt (und sogar noch legacy MBR support hat).
D.h. effektiv macht es fast das was ich oben als manuelles Gefrickel beschrieben habe, nur eben automatisiert, mit einem zusätzlichen schönen Bootmenü und ohne Kernel manuell herumkopieren zu müssen.

Klingt gut, werde ich wohl dann mal testen Bisher habe ich noch nie was anderes als GRUB ausprobiert, mal schauen wie das so läuft.

--- (Original und Edits gekennzeichnet, ich hoffe mal es ist nicht zu verwirrend )

Zum Verständnis (HD-Setup wird dann sein: ESP auf der M2 SSD, Linux auf einer SATA SSD, Windows auf der anderen SATA SSD):
Original: Mit GRUB würde die UEFI-Firmware erst an die ESP übergeben, diese übergibt dann an die Linux SSD von der GRUB startet, dieses würde dann den Linux-Kernel laden oder an die Windows-Platte übergeben.
Mit rEFInd wird dieser Prozess etwas verschlankt, UEFI übergibt an ESP, dort gibt dann rEFInd an den Bootloader des Linux-Kernels weiter oder an die Windows-Partition.
Korrekt? Dass ich beim booten von Windows ansonsten einen "Umweg" über die Linux-Partition machen würde hatte mich sowieso etwas gestört. Ist eher so eine OCD-Sache aber schön, dass es dann auch besser geht

Edit: Err das war wohl der alte BIOS-Weg, ohne ESP musste GRUB ja auf der Linux-Partition installiert werden was den Umweg unvermeidbar machte. Mit EFI kann GRUB auf der ESP installiert werden (oder?) und anders als rEFInd muss es Kernel nicht suchen sondern kriegt von einer Konfigurationsdatei gesagt wo sie liegen, d.h. es braucht bei einem UEFI-Setup in keinem Fall einen Umweg über die Linux-Partition um Windows zu booten. D.h. wenn man eine der beiden Platten abklemmt würde die andere problemlos bootbar bleiben. Korrekt?

Edit2: Argh. Die erste Annahme war wohl doch korrekt: GRUB i.d.R. wird auch bei UEFI so installiert, dass es an eine spezifische Linux-Installation gebunden ist, d.h. es zieht seine Konfiguration nicht aus der ESP sondern aus /boot einer Linux-Platte.
Macht das irgendeinen Sinn? Wieso würde man dies tun wollen? Klar, den Kernel nicht auf die ESP zu packen sehe ich ein, aber GRUB inkl. vollständiger Konfiguration dort gekapselt zu haben wäre doch viel besser?
Man kann es wohl irgendwie hinbiegen dass GRUB dies tut indem man die Pfade anpasst, ist aber halt wieder Aufwand.

---

Bei der Nutzung von nEFInd und direktem laden des Linux-Kernels muss dieser ja dennoch vom EFI aus lesbar sein.
Optionen hierfür:
a) Die ESP einfach als /boot mounten, so dass vollautomatisch alles darin landet. Pro: Super einfach. Con: Linux kann sie zumüllen (d.h. sie sollte groß genug sein), alle installierten Systeme können auf den Kernel zugreifen und man hat ein FAT32 /boot (keine Symlinks etc.), geht nur vernünftig mit genau einer Linux-Installation damit sich die Kernel nicht gegenseitig überschreiben.
b) Separate Linux-Boot-Partition als FAT32 erstellen. Fast wie a), nur mit ein klein wenig Trennung so dass mehere Linux-Installationen keine Probleme bereiten.
c) Boot-Partition als Ext2 oder Ext4 oder einfach als Teil der Ext4-Systempartition und Installation des Ext-Treibers in rEFInd. Pro: Kapselung, Windows sieht die Kernel nicht, ESP-Partition wird nicht zugemüllt, Symlinks etc. funktionieren. Con: Mehr Aufwand, Ext-Treiber laden kostet Zeit beim booten, ggf. fehleranfälliger?

Ich würde zu c) tendieren (und dann gar keine Bootpartition anlegen sondern einfach Ext4 für die Systemplatte nutzen) oder spricht da etwas gegen?

Wenn GRUB direkt über die ESP läuft (falls das wirklich so konfigurierbar ist?) sehe ich allerdings den Vorteil von rEFInd an der Stelle nicht mehr. Der wesentliche Unterschied wäre dann nur noch, dass GRUB nach Konfigurationsdateien startet während rEFInd bei jedem hochfahren einen Scan durchführt. Imo eher ein Nachteil (kostet Zeit) als ein Vorteil.
Netter Link mit allen Vor-/Nacheilen rEFInd vs GRUB: https://askubuntu.com/a/760971

Gott ist dieser ganze EFI-Kram bescheuert. Wie kann man sich nur so einen Schwachsinn ausdenken und dann auch noch zum Standard machen?! Vielleicht bleibe ich doch einfach beim legacy MBR boot ...

 

[parats']

GPT hat schon seine Vorteile gegenüber MBR. Gerade die isolierte Schicht mit getrennten System im dual boot.

 

[MegaVolt]

Das hätte man aber doch sicherlich auch irgendwie geschickter hinbekommen können.

Ich hätte noch eine weitere Variante für die rEFInd-Options-Liste oben:
d) M2 und SATA2 abklemmen, Windows inkl. eigener ESP auf SATA1 installieren. Dann SATA1 ab und SATA2 anklemmen, Linux mit eigener ESP auf SATA2 installieren. Dann M2 anschließen, von Linux aus inkl. ESP partitionieren, rEFInd auf M2 ESP einrichten, der UEFI firmware sagen dass sie bitte die ESP auf SATA1 und SATA2 ignorieren und stattdessen M2 ESP booten soll.

Das wäre besser als c), falls Windows seine Updates weiter munter in seine SATA1 ESP schreibt und man unter Linux die gekapselte SATA2 ESP einhängt, in die die Distro dann sonstwas schreiben kann (außer man will rEFInd aktualisieren natürlich, dann wird die gemounted). Damit würde man effektiv verhindern, dass irgendein anderes System die tolle schön konfigurierte ESP zerschießt, auf M2 ESP würde dann hoffentlich kein System etwas automatisch installieren. Kann das klappen oder ist die Idee total doof (abgesehen von der dann noch weiter um sich greifenden FAT32-Verschandelung des Systems)?
Hätte den angenehmen Nebeneffekt, dass jede Platte alleine für sich bootbar ist, falls doch mal das M2 EFI irgendwie ausfällt, d.h. man hat den Fallback geschenkt.

 

[MegaVolt]

Mal ein kleines Update, es ist alles aufgesetzt und funktioniert wunderbar:
- M2SSD hat eine EFI-Partition mit rEFInd und ist ansonsten die Datenplatte
- SSD60 trägt ein frisch aufgesetztest und im EFI-Modus installiertes Manjaro Linux, aus dem heraus ich rEFInd installiert und dann auch GRUB deinstalliert habe
- SSD250 trägt weiterhin mein altes Windows, nicht neu installiert

Beim booten über rEFInd lade ich sowohl die Ext4- als auch NTFS-Treiber. Dank dem Ext4-Treiber erkennt es die Kernel auf meiner SSD60 und kann diese über EFISTUB direkt laden, ohne dass ein echter Bootloader nötig wäre. Klappt prima und schnell. Dank dem NTFS-Treiber wird auch meine alte Windows-Partition erkannt und kann im legacy MBR boot gestartet werden. Irgendwann formatiere ich die bestimmt auch mal und setze es dann als GPT/EFI auf, bisher war ich allerdings dafür zu faul und rEFInd kann ja den legacy boot.
Netter Nebeneffekt: Da Windows denkt der Rechner laufe im alten MBR boot kann es nie versuchen, die Kontrolle von rEFInd zu übernehmen.

Das einzurichten war überraschend einfach. Das rEFInd Install-Skript macht fast alles schon automatisch, nur den NTFS-Treiber musste ich per Hand rüber kopieren und dann in der Konfigurationsdatei noch einrichten, dass auch nach legacy OS gesucht werden soll.

 

[parats']

Windows 10 kannst du relativ einfach ohne Neuinstallation von legacy MBR auf GPT/EFI switchen.

https://www.windowscentral.com/how-convert-mbr-disk-gpt-move-bios-uefi-windows-10

 

[MegaVolt]

Jo, hatte auch schon davon gelesen und es klingt recht nett. Aber: Wenn ich das ausprobiere würde ich vorher dennoch Backups machen für den Fall dass es die Partition doch irgendwie zerschießt. Und wenn ich die Backups sowieso schon habe dann kann ich auch gleich formatieren und dabei Altlasten loswerden, Backups zurückspielen ist ja trivial.
Wenn ich Backups schreibe meine ich im Wesentlichen savegames. Meine Windows-Partition heißt aus gutem Grund "Wintendo" Formatieren tut da nicht besonders weh.

 

[parats']

Ich hab es selbst gemacht vor einigen Monaten und hatte keine Probleme. Paranoid wie ich bin, habe ich aber dennoch vorher einen snapshopt sowie backup der privaten files gemacht (welche nicht eh aufs NAS fliegen).

 

[tzui]

habe das schon bei ner menge systeme gemacht, ging immer gut, aber naja murphy undso

zu grub, die linux gemeinde streitet sich gefuehlt seit jahrzehnten wegen grub.
die eine seite um lennart poettering (dem systemd entwickler) findet grub scheisse, outdated und in efi zeiten einen voellig unoetigen und unsicheren zwischenschritt.
die andere seite schaetzt grubs backward Kompatibilität und seine Flexibilität wenn mal etwas nicht klappt (manuelles temporäres editieren der vg's oder lv's, oder einfaches starten vom Notfall System/Backup Kernel)
,
googles chromebook booten btw mega save in eine signierte efi binary die den signierten chromebook kernel laed. nur im dev mode duerfen andere/eigene systeme gestartet werden. deswegen verstehe ich shis unbehagen nicht, secure boot direkt in den kernel ist ne feine und sichere sache

wenn grubs config zerschossen ist wird das debuggen zum nightmare!