Inital commit

2026-06-19 23:18:04 +02:00
commit 1bb79dc5a5
46 changed files with 3401 additions and 0 deletions
@@ -0,0 +1,76 @@
+# sdX-Vertauschung – Wechselnde Gerätenamen
+
+**Zusammenfassung**: Die Namen `/dev/sda`, `/dev/sdb`, `/dev/sdc` können sich bei jedem Neustart ändern. Dieses Dokument erklärt die Ursache, die Auswirkungen und wie persistente Referenzen das Problem lösen.
+**Quellen**: `chats/fstab und crypttab.md`
+**Zuletzt aktualisiert**: 2026-06-16
+
+---
+
+## Ursache
+
+Der Linux-Kernel vergibt die `/dev/sdX`-Namen in der **Reihenfolge, in der er die Geräte erkennt**. Diese Reihenfolge hängt ab von:
+
+- **USB-Controller-Initialisierung** (verschiedene Controller brauchen unterschiedlich lang)
+- **Port-Reihenfolge** (welcher Port zuerst scannt)
+- **Hub-Topologie** (Geräte an verschiedenen USB-Hubs)
+- **Geräte-Firmware** (manche Geräte melden sich schneller als andere)
+
+Selbst wenn die Laufwerke physisch in derselben Reihenfolge angeschlossen sind, können sie beim nächsten Boot **vertauscht** sein.
+
+## Konkretes Beispiel vom Raspberry PI5
+
+Beim ersten Boot:
+```
+sdb → Laufwerk A (bootfs, rootfs, LUKS)
+sdc → Laufwerk B (bootfs, rootfs, LUKS)
+```
+
+Beim nächsten Boot (nach Neustart):
+```
+sdb → Laufwerk B
+sdc → Laufwerk A
+```
+
+Die **UUIDs und PARTUUIDs** der Partitionen bleiben dagegen **immer gleich** – unabhängig davon, ob das Device gerade `/dev/sdb` oder `/dev/sdc` heißt.
+
+## Warum es auf dem Raspberry PI5 funktioniert
+
+Das System verwendet **durchgängig persistente Referenzen**:
+
+- **fstab** verwendet `PARTUUID=` und `/dev/disk/by-partuuid/` – diese folgen der Partition, nicht dem `/dev/sdX`-Namen
+- **crypttab** verwendet `UUID=` für die LUKS-Container – cryptsetup findet das richtige Device unabhängig vom Namen
+- **fstab mountet `/dev/mapper/...`** – diese Mapper-Namen sind stabil und werden von cryptsetup erzeugt
+
+Ergebnis: Selbst wenn sdb und sdc vertauschen, landen alle Mounts auf den **richtigen Partitionen** (Quelle: `chats/fstab und crypttab.md`).
+
+## Symptome einer sdX-Vertauschung erkennen
+
+Wenn in der Ausgabe von `lsblk` die Devices anders heißen als erwartet, die Mounts aber trotzdem stimmen, liegt eine Vertauschung vor:
+
+```bash
+lsblk -o NAME,PARTUUID,UUID,FSTYPE,LABEL,MOUNTPOINT
+```
+
+Achte auf:
+- `/boot/firmware` und `/` sollten auf dem **gleichen** Laufwerk liegen (gleicher PARTUUID-Präfix wie `228e9390-*`)
+- `/mnt/data` sollte auf dem entschlüsselten Container des primären Laufwerks liegen
+
+## Optionale udev-Regeln (für feste Zuordnung)
+
+Falls eine Zuordnung zu **physischen Ports** gewünscht ist, können udev-Regeln erstellt werden:
+
+```bash
+# Beispiel: Feste Symlinks basierend auf Seriennummer
+# Datei: /etc/udev/rules.d/99-feste-laufwerke.rules
+SUBSYSTEM=="block", ENV{ID_SERIAL}=="Seriennummer_Laufwerk_A", SYMLINK+="disk_laufwerk_a"
+SUBSYSTEM=="block", ENV{ID_SERIAL}=="Seriennummer_Laufwerk_B", SYMLINK+="disk_laufwerk_b"
+```
+
+Danach kann in fstab `/dev/disk_laufwerk_a` statt PARTUUID verwendet werden.
+
+## Verwandte Seiten
+
+- [persistente-blockgeraete](./persistente-blockgeraete.md) – UUID, PARTUUID, by-partuuid
+- [fstab](./etc/fstab.md) – Verwendet persistente Referenzen
+- [crypttab](./etc/crypttab.md) – UUID-Referenzen in crypttab
+- [luks-verschluesselung](./luks-verschluesselung.md) – LUKS-Referenzierung