Ah, nun sieht die Ausgabe von blkid ja vollständiger aus.
aki, ich bin keineswegs ein Experte für dmraid. Eigentlich bin ich überrascht, dass es noch eigenständig existiert. Ich dachte, das sei längst von md und mdadm geschluckt worden. Das Arch-Wiki bezeichnet dmraid inzwischen als "wird nicht mehr weiterentwickelt" und rät von dessen Verwendung ab. Ich habe keine Ahnung, wie gut dmraid noch mit aktuellen Systemen und insbesondere Systemd zusammenarbeitet.
Was mich stört ist, dass auf sda bis sdd überhaupt eigenständige Partitionen erkannt werden. Das sollte so nicht sein. Eigentlich sollte da nur:
/dev/sda: TYPE="promise_fasttrack_raid_member"
stehen, wie in obigem Beispiellink.
An deiner Stelle würde mir das ziemliche Sorgen bereiten und ich würde mich fragen, wie unzuverlässig dmraid inzwischen ist.
Systemd versucht inzwischen eigenständig, Swap-Partitionen zu erkennen und in Betrieb zu nehmen. Wenn das deine /dev/sdd5 oder /dev/sdc5 sieht und "versehentlich" in Betrieb nimmt, macht es dein Raid kaputt.
Was du als "logisch" empfindest, nämlich mehrfach vergebene UUIDs, macht den Sinn von UUIDs kaputt, die sollen nämlich "Unique", also einzigartig sein.
Korrekt zugeordnet werden sie auch nicht, wie dein
ls -l /dev/disk/by-uuid/
zeigt. Die UUIDs müssten auf /dev/mapper/... zeigen.
Auf deine "Laufwerksbuchstaben" /dev/sda, /dev/sdb u.s.w. kannst du dich auch nicht verlassen ... mal hat sdb1 die UUID 4963ef0f-c4b8-4294-97f0-0ba593008031, gehört also zu gijeeead, mal die UUID dec4fa5e-97ba-40f1-9382-59c4485cfc39, gehört also zu baeahcegi.
Du darfst also weder UUIDs noch /dev/sdX verwenden. Und du musst Systemd die Autoerkennung abgewöhnen (wobei der Sinn von Swap auf Raid1 eh fraglich ist und Systemd da nicht wirklich was kaputt machen dürfte, solange du kein Suspend-To-Disk machst).
Zu deinem eigentlichen Problem:
systemd beschwert sich, dass es /dev/mapper/pdc_baeahcegi5 nicht starten kann:
dev-mapper-pdc_baeahcegi5.device: Job dev-mapper-pdc_baeahcegi5.device/start failed with result 'timeout'.
Warum nicht? Keine Ahnung. Das Arch-Wiki erwähnt einen "dmraid.service", aber den finde ich unter Debian weder bei Systemd noch in den dmraid-Paketen. Wenn ich den Debian-Ansatz richtig verstehe, handhabt Debian dmraid komplett in der initramdisk, und da gibt's noch kein Systemd. Systemd sollte also bereits ein existierendes /dev/mapper/pdc_baeahcegi5 vorfinden und es gar nicht erst zu starten versuchen. Andererseits scheint dmraid in Debian in der initramdisk kaputt zu sein, wenn ich mir diesen einsamen Bugreport so angucke:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=864423
Das sieht mir so aus, als ob dmraid demnächst aus Debian rausfliegt.
Wann auch immer du deine Raids zusammenbastelst, Systemd scheint /dev/mapper/pdc_baeahcegi5 noch nicht zu finden. Warum das so ist, verstehe ich nicht - immerhin ist auf baeahcegi dein root-Dateisystem. baeahcegi müsste also laufen, inklusive /dev/mapper/pdc_baeahcegi5.
Entweder fummelst du das auseinander, oder du nimmst swap ganz aus der fstab und startest es per Hand, genau wie du es mit /mnt/Backup machst.
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
.