Verschlüsselten Datenträger im Terminal anlegen: Schritt-für-Schritt-Anleitung mit LUKS unter Linux

veröffentlicht am 12.01.2026 - aktualisiert am 15.01.2026 mit 2925 Worten - Lesezeit: 14 Minute(n) in * LINUX *

Anhand meines hier beschriebenen Laptops Fujitsu Lifebook E449 - Umrüstung Win 11 nach Debian 12 möchte ich testen, ob und wie sich eine komplette Debian-Installstion auf verschlüsseltem Datenträger gemäß diesem Artikel Linux-Installation (Debian) mit verschlüsseltem Datenträger (LUKS, LVM) auf einen neuen (größeren) Datenträger übertragen läßt (bei gleichzeitiger Anpassung einzelner Partitionsgrößen).

Vorarbeiten am alten Setup

Vorüberlegungen

Das Setup am alten Rechner bzgl. des Datenträgers (SSD) sieht folgendermaßen aus:

~# lsblk
NAME                    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                       8:0    0 238,5G  0 disk  
├─sda1                    8:1    0   487M  0 part  /boot/efi
├─sda2                    8:2    0   488M  0 part  /boot
└─sda3                    8:3    0 237,5G  0 part  
  └─sda3_crypt          254:0    0 237,5G  0 crypt 
    ├─fujitsu--vg-root  254:1    0  60,5G  0 lvm   /
    ├─fujitsu--vg-swap  254:2    0  18,6G  0 lvm   [SWAP]
    └─fujitsu--vg-Daten 254:3    0 158,3G  0 lvm   /home

Daraus ergeben sich folgende Schritte:

Identifizieren aller relevanten Daten:

• /boot/efi - unverschlüsselt und für Systemstart relevant
• /boot - unverschlüsselt
• / (60,5G) - verschlüsselte root-Partition, enthält das System und alle Anwendungen
• /home (158,3G) - verschlüsselte home-Partition, enthält alle Nutzerdaten
• Swap (18,6G) - Auslagerungsdatei, keine kritischen Inhalte.

Nun gäbe es prinzipiell die Möglichkeit, mittels z. B. dd ein 1:1-Abbild des Datenträgers auf den neuen Datenträger zu erstellen. Aber: ich möchte bei dem Umzug auch die Partitionsgrößen anpassen:

• Die /boot-Partition hat sich als zu klein herausgestellt, bei jedem Kernel-Update läuft man Gefahr, daß hier der Speicherplatz nicht reicht. Diese Partition soll auf 2GiB vergrößert werden.
• Auf meinen aktuellen Rechnern liegt die Größe der Root-Partition inzwischen durchgängig bei 100GiB
• Swap: nachdem ich RAM deutlich vergrößert habe an der Maschine, soll auch die Swap-Partition entsprechend angepaßt werden (nötig beim Nutzen von “Bereitschaft” (suspend-to-RAM))

Diese Änderungen sind nicht trivial, sodaß ich mich entschlossen habe, die Daten entsprechend zu speichern/sichern per “timeshift” und das Filesystem auf dem neuen Datenträger frisch aufzusetzen.

Allgemeines zu Migrationen: 1, 2

Am Anfang steht das Backup …

Das gesicherte System läuft auf dem neuen Datenträger natürlich nur dann, wenn es dort die bekannten Bedingungen vorfindet. Dazu müssen die UUIDs (blkid) und LUKS-Header-Details (cryptsetup luksDump) gesichert werden, da diese nach der Migration angepasst werden müssen.
Hierzu sind diese Ausgaben zu sichern:

~# blkid
/dev/mapper/fujitsu--vg-root: UUID="c4e8a1d2-7b3f-4f9a-9d2e-8a6b3f1c2e9d" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/fujitsu--vg-swap: UUID="f7b2d9a4-3c8e-4e1f-8b7d-1a9c4e6f3b2d" TYPE="swap"
/dev/mapper/sda3_crypt: UUID="X9a2QW-7dLm-4pT8-Zk3v-9rYb-2cHn-Q8fJtR" TYPE="LVM2_member"
/dev/sda2: UUID="e3d7b9a8-4f2c-4d1e-9b6a-7c8d3f2e1a4b" BLOCK_SIZE="1024" TYPE="ext2" PARTLABEL="boot" PARTUUID="a9d3f7b2-4c1e-4f8a-9d6b-3e2c7f1a8b4d"
/dev/sda3: UUID="b8f3d2a7-9c4e-4f1a-8b7d-2e6c3f9a1d4b" TYPE="crypto_LUKS" PARTLABEL="Linux" PARTUUID="c7e2a9d3-4b1f-4f8a-9d6b-2f3e8c1a7b4d"
/dev/sda1: UUID="4F2A-9C7D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI" PARTUUID="d3a9f7c2-4e1b-4f8a-9d6b-3c2e7f1a8b4d"
/dev/mapper/fujitsu--vg-Daten: UUID="a7d3f9b2-4c1e-4f8a-9d6b-2e3c7f1a8b4d" BLOCK_SIZE="4096" TYPE="ext4"

sowie bzgl. der verschlüsselten Teile des Datenträgers - das sieht beispielhaft so aus:

~# cryptsetup luksDump /dev/sda3
LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	b8f3d2a7-9c4e-4f1a-8b7d-2e6c3f9a1d4b
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  5
	Memory:     1048576
	Threads:    4
	Salt:       e0 4c ab f2 67 6c 48 d1 c5 11 8c e4 0a 03 d5 54 
                  56 79 cd 79 81 7c 8b a6 4a 48 42 27 fe c4 06 8e
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 98847
	Salt:       d9 34 59 0e 6a c2 2c 8d e7 24 22 25 ca b3 f3 40 
                  a1 f0 66 85 12 a4 16 e8 29 72 d1 05 60 c3 03 2d
	Digest:     30 d5 18 ae 13 72 46 d9 86 4b d0 1b db 92 a8 4c 
                  01 6e 54 66 5e bc 90 ac 98 a9 e8 7f f7 f9 0c db 

Man sollte ferner auch eine Header-Sicherung durchführen:

~# cryptsetup luksHeaderBackup /dev/sda3 --header-backup-file /home/{benutzername}/luks-header-sda3-fujitsu-256G.img

und die Metadaten der Volume Group sichern:

~# vgcfgbackup -f /home/benutzer/fujitsu-vg.backup fujitsu-vg
  Volume group "fujitsu-vg" successfully backed up.

Diese Metadaten umfassen Konfigurationsdetails wie VG-ID, Physical Volumes (PV), Logical Volumes (LV) mit deren Größen, Extent-Layouts, Stripe-Informationen und Statusflags - sie werden hier in einer kleinen Textdatei von ein paar kB Größe gespeichert. Die Daten können mit vgcfgrestore wieder hergestellt werden.

Neue SSD einrichten

Eine 1TB-SSD kann mit EFI (500MB), /boot (2GB), gefolgt von einer LUKS-verschlüsselten Partition für root (100GB), swap (64GB) und home (Rest) präzise partitioniert werden. Die Schritte erfolgen vollständig in der Kommandozeile eines Debian-Live-Systems (als root). Alle Daten auf der SSD gehen verloren – SSD-Gerät vorher mit lsblk bestätigen (z.B. /dev/nvme0n1 oder /dev/sda).

Partitionstabelle anlegen

Hierfür sind der Reihenfolge nach folgende Befehle einzugeben:

parted /dev/sda
mklabel gpt
mkpart ESP fat32 1MiB 501MiB
set 1 esp on
mkpart primary ext4 501MiB 2501MiB
mkpart primary 2501MiB 100%
quit

Das sieht dann in der Praxis so aus:

~# parted /dev/sda
GNU Parted 3.6
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt                                                      
Warning: The existing disk label on /dev/sda will be destroyed and all data on this disk will be lost.
Do you want to continue?
Yes/No? y                                                                 
(parted) mkpart ESP fat32 1MiB 501MiB                                     
(parted) set 1 esp on                                                     
(parted) mkpart primary ext4 501MiB 2501MiB                               
(parted) mkpart primary 2501MiB 100%                                      
(parted) quit                                                             
  align-check TYPE N                       check partition N for TYPE(min|opt) alignment
  help [COMMAND]                           print general help, or help on COMMAND
  mklabel,mktable LABEL-TYPE               create a new disklabel (partition table)
  mkpart PART-TYPE [FS-TYPE] START END     make a partition
  name NUMBER NAME                         name partition NUMBER as NAME
  print [devices|free|list,all]            display the partition table, or available devices, or free
        space, or all found partitions
  quit                                     exit program
  rescue START END                         rescue a lost partition near START and END
  resizepart NUMBER END                    resize partition NUMBER
  rm NUMBER                                delete partition NUMBER
  select DEVICE                            choose the device to edit
  disk_set FLAG STATE                      change the FLAG on selected device
  disk_toggle [FLAG]                       toggle the state of FLAG on selected device
  set NUMBER FLAG STATE                    change the FLAG on partition NUMBER
  toggle [NUMBER [FLAG]]                   toggle the state of FLAG on partition NUMBER
  type NUMBER TYPE-ID or TYPE-UUID         type set TYPE-ID or TYPE-UUID of partition NUMBER
  unit UNIT                                set the default unit to UNIT
  version                                  display the version number and copyright information of GNU
        Parted
(parted) quit                                                             
Information: You may need to update /etc/fstab.

Ergebnis: /dev/sda1 (EFI), /dev/sda2 (/boot), /dev/sda3 (LUKS) wurden angelegt, das kann per lsblk überprüft werden:

~# lsblk                                                      
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 953.9G  0 disk 
├─sda1   8:1    0   500M  0 part 
├─sda2   8:2    0     2G  0 part 
└─sda3   8:3    0 951.4G  0 part 

Verschlüsselung und LVM einrichten

Im nächsten Schritt wird innerhalb der erzeugten Partition sda3 ein verschlüsselter Container erstellt, in dem weitere Laufwerke erstellt werden können. Das passiert mithilfe der folgenden Einzelbefehle:

cryptsetup luksFormat /dev/sda3
cryptsetup open /dev/sda3 cryptlvm
pvcreate /dev/mapper/cryptlvm

Auch hier wieder die Widergabe der einzelnen Schritte aus dem Terminal:

~# cryptsetup luksFormat /dev/sda3

WARNING!
========
This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda3: 
Verify passphrase: 

~# cryptsetup open /dev/sda3 cryptlvm
Enter passphrase for /dev/sda3: 

~# pvcreate /dev/mapper/cryptlvm
  Physical volume "/dev/mapper/cryptlvm" successfully created.

Im nächsten Schritt wird innerhalb des erzeugten verschlüsselten Laufwerks eine Gruppe erzeugt, darin dann die einzelnen logischen Laufwerke für /, swap und /home

vgcreate fujitsu-vg /dev/mapper/cryptlvm
lvcreate -L 100G -n root fujitsu-vg
lvcreate -L 64G -n swap fujitsu-vg
lvcreate -l 100%FREE -n home fujitsu-vg

und im Detail incl. der Terminalausgaben:

~# vgcreate fujitsu-vg /dev/mapper/cryptlvm
  Volume group "fujitsu-vg" successfully created

~# lvcreate -L 100G -n root fujitsu-vg
  Logical volume "root" created.
~# lvcreate -L 64G -n swap fujitsu-vg
  Logical volume "swap" created.
~# lvcreate -l 100%FREE -n home fujitsu-vg
  Logical volume "home" created.

und damit sieht die Gesamt-Laufwerks-Konstellation jetzt so aus:

~# lsblk
NAME                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                      8:0    0 953.9G  0 disk  
├─sda1                   8:1    0   500M  0 part  
├─sda2                   8:2    0     2G  0 part  
└─sda3                   8:3    0 951.4G  0 part  
  └─cryptlvm           253:0    0 951.4G  0 crypt 
    ├─fujitsu--vg-root 253:1    0   100G  0 lvm   
    ├─fujitsu--vg-swap 253:2    0    64G  0 lvm   
    └─fujitsu--vg-home 253:3    0 787.4G  0 lvm  

Dateisysteme formatieren

Im letzten Schritt wurden eine Reihe einzelner Partitionen erstellt, diese müssen jetzt mit einem Filesystem formatiert werden, um sie nutzen zu können, auch hier wieder die Befehle zunächst “trocken” als Aufzählung

mkfs.vfat -F32 /dev/sda1
mkfs.ext4 /dev/sda2
mkfs.ext4 /dev/fujitsu-vg/root
mkfs.ext4 /dev/fujitsu-vg/home
mkswap /dev/fujitsu-vg/swap

und hier wieder die interaktiven Anzeigen im Terminal:

~# mkfs.vfat -F32 /dev/sda1
mkfs.fat 4.2 (2021-01-31)

~# mkfs.ext4 /dev/sda2
mke2fs 1.47.2 (1-Jan-2025)
Discarding device blocks: done                            
Creating filesystem with 512000 4k blocks and 128000 inodes
Filesystem UUID: b0958927-6c56-49ec-97b5-7b32f2c83905
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done 

~# mkfs.ext4 /dev/fujitsu-vg/root
mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: d764c441-b362-4ef2-8f5f-af17ee9d2399
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done   

~# mkfs.ext4 /dev/fujitsu-vg/home
mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 206414848 4k blocks and 51609600 inodes
Filesystem UUID: cacc611c-b7d5-4a13-8b84-484ef2fefd78
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done     

~# mkswap /dev/fujitsu-vg/swap
Setting up swapspace version 1, size = 64 GiB (68719472640 bytes)
no label, UUID=0c946c5a-210e-45e2-b455-18d9fae4d22a

Mounts vorbereiten

Inzwischen sind Partitionen erstellt, innerhalb derer ggf. auch eine verschlüsselte Volumen-Gruppe, darin wiederum logische Laufwerke, und diese alle sind jeweils mit einem Dateisystem formatiert. Im nächsten Schritt müssen die einzelnen Laufwerke “gemountet” werden, damit sie gezielt angesprochen und genutzt werden können.
Die Befehle “trocken” vorab:

mount /dev/fujitsu-vg/root /mnt
mkdir -p /mnt/boot/efi
mkdir -p /mnt/home
mount /dev/sda2 /mnt/boot
mount /dev/sda1 /mnt/boot/efi
mount /dev/fujitsu-vg/home /mnt/home
swapon /dev/fujitsu-vg/swap

Erklärung: mkdir -p /mnt/boot/efi erstellt sowohl /mnt/boot als auch das Unterverzeichnis efi (das -p verhindert Fehler, falls /mnt/boot schon existiert).

Diese Befehle liefern im Erfolgsfall allesamt keine Ausgabe - deshalb spare ich mir hier die Terminal-Wiedergaben.

Im Ergebnis sollte der Datenträger jetzt einsatzbereit sein:

~# lsblk
NAME                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                      8:0    0 953.9G  0 disk  
├─sda1                   8:1    0   500M  0 part  /mnt/boot/efi
├─sda2                   8:2    0     2G  0 part  /mnt/boot
└─sda3                   8:3    0 951.4G  0 part  
  └─cryptlvm           253:0    0 951.4G  0 crypt 
    ├─fujitsu--vg-root 253:1    0   100G  0 lvm   /mnt
    ├─fujitsu--vg-swap 253:2    0    64G  0 lvm   [SWAP]
    └─fujitsu--vg-home 253:3    0 787.4G  0 lvm   /mnt/home

System wieder einspielen

Man könnte jetzt auf den vorbereiteten Datenträger ein frisches System installieren, ich möchte aber versuchen, die oben erstellte Timeshift-Sicherung (rsync-Backup) in die neuen Partitionen einzuspielen. Timeshift-Backups enthalten das komplette System inklusive Pakete, Konfigurationen und Initramfs, sodass danach ein funktionsfähiges System vorhanden sein sollte – vorausgesetzt, die Sicherung passt zur Partitionierung (ext4, LUKS/LVM-kompatibel). Dies spart Zeit und übernimmt /etc/fstab und crypttab automatisch.

Timeshift aus Live-System installieren

In meinem Debian-Live-System muß ich Timeshift zunächst nachinstallieren:

~# apt install timeshift
Installing:                     
  timeshift

Summary:
  Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 189
  Download size: 723 kB
  Space needed: 4,175 kB / 15.8 GB available

Backup wiederherstellen

Timeshift läuft im Live-System und greift auf die Backup-Quelle zu (z.B. externe Festplatte mit /timeshift).

Im nächsten Schritt wird die erstellte Sicherung ausgewählt, die eingespielt werden soll:

Die gespeicherten Pfade werden den oben erstellten Mountpunkten zugeordnet: und ferner lassen sich Optionen für den Bootloader einstellen:

Nach einem “Trockenlauf” und einer Bestätigung sowie einer Warnung mit übersichtlicher Zusammenstellung der gewählten Zuordnungen wird der gewählte Schnappschuss eingespielt:

Das kann dann einige Zeit dauern (in meinem Fall hier ca. 1/2h) bis zum Abschluss:

Chroot und Bootloader nachbearbeiten

Zunächst müssen in den beiden Dateien /etc/fstab und /etc/crypttab die UUIDs (Adressen der Dateisysteme) geprüft und ggf. angepaßt werden. Dazu werden zunächst per blkid die UUIDs ermittelt. Die genannten Dateien können dann per Editor nano angesehen und ggf. editiert werden.
In die /etc/crypttab kommt dabei diejenige UUID, deren Eintrag in blkid mit TYPE="crypto_LUKS" gekennzeichnet ist.

Beispielhaft liefert blkid diese Ausgabe:

~# blkid
/dev/mapper/fujitsu--vg-root: UUID="fb4313be-447D-AB8D-3aff-66fc61df2985" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/fujitsu--vg-swap: UUID="951c5a96-30B5-1303-3a15-05b8ea5fb8f8" TYPE="swap"
/dev/mapper/sda3_crypt: UUID="284e0d92-6849-FB27-90c7-6ede546af39d" TYPE="LVM2_member"
/dev/sda2: UUID="db81c9cb-91EC-DC66-40f1-501fe5b661ff" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="6993ca4b-0EC9-9C54-aa65-e1ea0a72af23"
/dev/sda3: UUID="0056c472-97D5-AD76-5e98-74bb36318b1a" TYPE="crypto_LUKS" PARTLABEL="primary" PARTUUID="a3bd3905-E8D0-DAF9-9ee1-d1c0d6334459"
/dev/sda1: UUID="82C5-29B3" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ESP" PARTUUID="97a2cbcb-E814-4FBB-913a-3a30f7a28c0c"
/dev/mapper/fujitsu--vg-home: UUID="fe1b7ca4-F115-40C1-1bc4-19617626a9d9" BLOCK_SIZE="4096" TYPE="ext4"

Dann sehen die genannten Dateien so aus:

• /etc/fstab

  # <file system> <mount point> <type> <options> <dump> <pass>
  
  UUID=fb4313be-447D-AB8D-3aff-66fc61df2985	/	ext4	errors=remount-ro	0	1
  UUID=db81c9cb-91EC-DC66-40f1-501fe5b661ff	/boot	ext4	defaults	0	2
  UUID=82C5-29B3	/boot/efi	vfat	umask=0077	0	1
  UUID=fe1b7ca4-F115-40C1-1bc4-19617626a9d9	/home	ext4	defaults	0	2
  /dev/mapper/fujitsu--vg-swap	none	swap	sw	0	0
  

• /etc/crypttab

  sda3_crypt	UUID=0056c472-97D5-AD76-5e98-74bb36318b1a	none	luks,discard,nofail
  

Um nach der Wiederherstellung diejenigen Nacharbeiten durchführen zu können, die das neu eingespielte System startfähig machen, müssen weitere “mounts” durchgeführt werden und der Root-Zugang vom Live-System auf das neue System umgeschaltet werden (= chroot):

mount -t proc none /mnt/proc
mount --rbind /sys /mnt/sys
mount --rbind /dev /mnt/dev
mount --rbind /run /mnt/run
cp /etc/resolv.conf /mnt/etc/
chroot /mnt /bin/bash

(siehe an dieser Stelle auch die Reparaturhinweise)

Diese Befehle liefern im Regelfall keine Ausgabe (es sei denn, irgendwas ist schief gegangen).

Im Chroot, also als root auf dem neuen System, müssen dann durchgeführt werden:

apt update
update-initramfs -u -k all
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Debian --recheck
update-grub

Aushängen und starten

Root muß sich vom neuen System wieder abmelden (zurückkehren auf das Live-System) und die gemounteten Laufwerke freigeben. Im Anschluss erfolgt ein Neustart.

exit
swapoff -a
umount -R /mnt
reboot

Beim Unmount kam es bei mir regelmäßig zu Problemen:

/# umount -R /mnt
umount: /mnt/run/user/0: target is busy.

Die einfachste und zuverlässigste - aber keineswegs die sauberste - Methode, dieses Problem zu lösen, besteht aus der zusätzlichen Option -l (“lazy unmount”, Ubuntu Manpage: umount - Dateisysteme aushängen):

/# umount -l -R /mnt

Im Idealfall sollte das System nach dem obigen Befehl reboot in das eingespielte System starten, nach dem Linux-Bootmanager GRUB sollte die Passwortabfrage des verschlüsselten Datenträgers erfolgen und dann nach einiger Zeit der Desktop erscheinen … das war bei mir nicht der Fall, deshalb:

Reparatur-Zugriff auf den Datenträger vom Live-System aus

Sollte der Neustart mißlingen, dann muß repariert werden. In meinem Fall zeigte sich nach dem Linux-Bootmanager und einiger Wartezeit diese “schöne” Meldung:

Also muss repariert werden.
Dazu startet man das Live-System (in meinem Fall eine Debian-Live-CD, Root-Terminal durch sudo su -l) und führt als erstes diese Schritte aus:

user@debian:~$ sudo su -l
root@debian:~# cryptsetup luksOpen /dev/sda3 sda3_crypt
Enter passphrase for /dev/sda3:

Gegenüber der obigen Beschreibung füge ich an dieser Stelle einen Befehl hinzu:

root@debian:~# vgchange -a y
  3 logical volume(s) in volume group "fujitsu-vg" now active

Kontrolle zeigt, daß alle relevanten Laufwerke/Partitionen angezeigt werden:

root@debian:~# lsblk
NAME                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                      8:0    0 953.9G  0 disk  
├─sda1                   8:1    0   500M  0 part  
├─sda2                   8:2    0     2G  0 part  
└─sda3                   8:3    0 951.4G  0 part  
  └─sda3_crypt         253:0    0 951.4G  0 crypt 
    ├─fujitsu--vg-root 253:1    0   100G  0 lvm   
    ├─fujitsu--vg-swap 253:2    0    64G  0 lvm   
    └─fujitsu--vg-home 253:3    0 787.4G  0 lvm   

Dann sind die Partitionen zu mounten:

root@debian:~# mount /dev/fujitsu-vg/root /mnt
root@debian:~# mount /dev/sda2 /mnt/boot
root@debian:~# mount /dev/sda1 /mnt/boot/efi
root@debian:~# mount /dev/fujitsu-vg/home /mnt/home
root@debian:~# swapon /dev/fujitsu-vg/swap

und im nächsten Schritt muß CHROOT vorbereitet werden - auch hier ist der erste Befehl geändert gegenüber der Reihe von Befehlen in der obigen Beschreibung:

root@debian:~# for folder in dev sys proc tmp; do mount -o bind "/${folder}" "/mnt/${folder}"; done

Wiederum Kontrolle der Auswirkungen:

root@debian:~# lsblk
NAME                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                      8:0    0 953.9G  0 disk  
├─sda1                   8:1    0   500M  0 part  /mnt/boot/efi
├─sda2                   8:2    0     2G  0 part  /mnt/boot
└─sda3                   8:3    0 951.4G  0 part  
  └─sda3_crypt         253:0    0 951.4G  0 crypt 
    ├─fujitsu--vg-root 253:1    0   100G  0 lvm   /mnt
    ├─fujitsu--vg-swap 253:2    0    64G  0 lvm   [SWAP]
    └─fujitsu--vg-home 253:3    0 787.4G  0 lvm   /mnt/home

Root wechselt in das zu reparierende und gemountete System

root@debian:~# chroot /mnt /bin/bash

und führt die Reparatur durch:

root@debian:/# update-initramfs -u -k all
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
perl: warning: Setting locale failed.
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Falling back to the standard locale ("C").
update-initramfs: Generating /boot/initrd.img-6.1.0-41-amd64
cryptsetup: WARNING: sda3_crypt: ignoring unknown option 'nofail'

update-initramfs erstellt oder aktualisiert das initramfs-Image, ein temporäres Dateisystem im RAM, das beim Booten des Linux-Kernels geladen wird. Das initramfs enthält essentielle Treiber und Skripte, um Hardware wie Festplatten zu erkennen und das echte Root-Dateisystem zu mounten, bevor das System vollständig startet.

Im nächsten Schritt muß der Bootmanager aktualisiert werden:

root@debian:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Debian --recheck
Installing for x86_64-efi platform.
grub-install: warning: EFI variables are not supported on this system..
Installation finished. No error reported.

root@debian:/# update-grub
Generating grub configuration file ...
Found background image: .background_cache.png
Found linux image: /boot/vmlinuz-6.1.0-41-amd64
Found initrd image: /boot/initrd.img-6.1.0-41-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done

update-grub generiert die GRUB-Bootloader-Konfigurationsdatei (/boot/grub/grub.cfg) neu oder aktualisiert diese. Er scannt das System nach verfügbaren Kerneln, Initramfs-Dateien und anderen Bootoptionen (z. B. in /boot) und erstellt daraus automatisch Boot-Menüeinträge basierend auf Einstellungen in /etc/default/grub.

Danach kann Root das zu reparierende System wieder verlassen und der Rechner kann neu gestartet werden:

root@debian:/# exit
exit
root@debian:~# swapoff -a
root@debian:~# umount -R /mnt
root@debian:~# reboot

Und diesmal fährt die Maschine tatsächlich hoch und ich lande in meinem gewohnten Desktop … 😄

Literatur:

• Linux reparieren: Ubuntu mit LUKS und LVM [IT-MÜCKE]
• LVM Installation auf LUKS Basis – Installation und manuelle Partitionierung – OpenSource is a lifestyle …
• Livesystem › chroot › Wiki › ubuntuusers.de
• LUKS Volumes mit einem Wiederherstellungsschlüssel versehen | Curius
• Datenträger unter Linux mit cryptsetup (LUKS) verschlüsseln/sichern/wiederherstellen | My-IT-Brain

weitere Artikel

• Linux-Installation (Debian) mit verschlüsseltem Datenträger (LUKS, LVM)
• Personalausweis zur Identifizierung nutzen unter Linux
• Google Chrome: Datenschutz vs. Tracking - gibt es eine Alternative?
• Ein Blog mit Hugo erstellen - Tutorial Teil 1 - Installation
• Zwei Programmversionen unter Linux