---
title: sdx-vertauschung
description: 
published: true
date: 2026-06-28T14:30:05.704Z
tags: 
editor: markdown
dateCreated: 2026-06-28T14:30:03.962Z
---

# 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