FAQ: Windows -> GNU/Linux - Umstieg, Einstieg, Aufstieg

ich werds nachher nochmal probieren, aber eins vorweg:
das user-verzeichnis liegt bereits auf einem anderen laufwerk.
dort etwas zu löschen löst das problem nicht.

(Vom Linux noob für den Linux noob)
Nachdem ich unter Linux fatigue gelitten hatte (distros asuprobieren... *kotz*), hab ich in letzter Zeit wieder etwas herumprobiert, diesmal mit Bazzite.
Bisher für mich das Beste vom Gefühl, Useability und Gesamteindruck. (also nach Ubuntu bzw gleichauf)

Hab aber noch nichts komplexeres probiert wie hypervisor +vm oder hibernation usw, da wirds dann immer kritisch. Aber es stimmt mich etwas hoffnungvoll als alternative für Gaming.

Ich hab was vor, dass für mich nicht so alltäglich ist.
Vielleicht kann einer der Linux Sysadmin Veteranen hier mir etwas Input geben ob mein Plan erfolgsversprechend klingt.

Ausgangsszenario:
"Entwicklungsserver" der immer mehr daily Services hostet soll von einer sehr gebrauchten alten SSD auf zwei neue in Raid 1 übersiedeln.

Mein Plan:

• Neue SSDs einbauen
• Von einer Live ISO booten
• Die neuen SSDs partitionieren, mit mdadm das Raid erstellen und dann formatieren
• Mit rsync von der alten SSD auf das neue Raid "kopieren"
• In das neue Filesystem am Raid chrooten
• Dort fstab, mdadm config, grub und initramfs updaten
• Reboot & pray

Hab ich etwas vergessen? Irgendwelche Tools die das einfacher/sicherer machen könnten?

Wäre es evtl an der Zeit an ein anderes, resilienteres Setup zu denken?
Je nach Services auf Virtualisierung oder Containerisierung gehen?
Damit ist das Backup und eine rasche Wiederherstellung leichter (bzw durch den Prozess schon vorbereitet)

Ich hab mich eine Weile mit der Frage der ESP-Redundanz beschaeftigt und im Zuge dessen fuer den Debian-Installer Patches beigesteuert, die ab Forky (Debian 14) zumindest mal mit preseed-Installationen eine der denk- und machbaren Varianten dafuer ermoeglichen. Imo ist das ganze ein tragischer Defekt der EFI-Spec, wo man dieses Problem einfach via "irgendeine Hardware-RAID-Kacke wird es schon fuer uns regeln, YOLO" "geloest" hat.

In der Praxis muss man schauen, dass alle ESPs im System zu jeder Zeit inhaltsgleich ist. Proxmox hat fuer diesen Zweck z. B. das proxmox-boot-tool im Lieferumfang; mein Ansatz fuer Debian ist (zugegeben ein bissi out of Spec, aber es hat noch auf jeder Plattform, die ich versucht habe, funktioniert) ein mdadm-RAID1 mit einem Superblock-Layout, das fuer die Firmware "unsichtbar" bleibt.

In allen Faellen hat man ggf. mit der Problematik zu kaempfen, dass ein OS, das sich nicht an den einen verwendeten Mechanismus zum Syncen aller ESP-Dateisysteme haelt, den Bootvorgang empfindlich (zer)stoeren kann. Das wird uns wohl bis in alle Ewigkeit/bis zur Abloese von UEFI erhalten bleiben.

Mit BIOS/MBR-Boot hat man dieses Problem in der tat nicht, aber man verliert in der Praxis durch das Aktivieren des CSM immer mehr Features, die man tendenziell haben moechte - insb. im Server - wie z. B. PCIe-Passthru.


Was mir recht lange nach der Einfuehrung von EFI und tatsaechlichem Booten davon nicht klar war:

"GRUB installieren" mit BIOS/MBR bedeutet, dass grub seinen stage0-Loader in den ersten Sektor der ersten (bzw. einfach aller, weil es keinen Unterschied macht) Disk(s) im System schreibt, wo ein bisschen x86-Machine-Code dafuer sorgt, dass die spaeteren Stages auf der selben Disk in /boot auf quasi beliebigen Dateisystemen (GRUB muss sie unterstuetzen, aber die Firmware muss nix davon wissen - und GRUB versteht auch sowas wie ext4 md RAID6) gefunden werden kann. Wenn man also diese 448 Byte auf die Disks bringt, ist alles relativ leiwand, und RAID-Metadaten und Dateisysteme sind davon unbeeindruckt.

"GRUB installieren" auf einem EFI-System bedeutet, mind. eine EFI-Binary (grub als PE fuers EFI-Target kompiliert) an einen (optional "magischen" Default-)Pfad auf der ESP zu kopieren, und, von gewissen Faktoren abhaengend, auch noch eine Konfigurationsdatei im Binary zu embedden oder mit auf die ESP zu legen. Die ESP (EFI System Partition) ist eine Partition in der GUID Partition Table, die eine spezielle, reservierte Unique ID hat, und die (meistens - aber das ist kein Muss) FAT32 formatiert ist. Das ist alles. Wenn man dann mag, kann man dann auch noch (z. B. via efibootmgr) im NVRAM der Firmware festlegen, dass es bitte zu diesem Loader eine Boot-ID geben soll, und dass bzw. ob die Default-Boot-ID werden soll - diese Information liegt aber nicht innerhalb der ESP, sondern afaiui meistens (immer?) in ein paar Bloecken des SPI-NAND, die u. A. auch die Firmware des Motherboards selber beherbergen.

Vielleicht ist das ja fuer den einen oder anderen Mitlesenden hier auch 2026 noch eine neue Information

HDMI 2.1 mit amdgpu ist inzwischen fast vollständig von zwei Leuten via reverse Engineering implementiert.