Accéder à un système LUKS manuellement

Après la mise à jour journalière de mon pc portable (sous Archlinux) et le redémarrage hebdomadaire, le drame : on entre le mot de passe de déchiffrement (LUKS) et…

_

Oui, juste « _ »

Pas d’erreur, rien.

_

Première étape : on augmente le loglevel et on retire le quiet dans la ligne de GRUB (voir CentOS / RHEL 6 : How to change the verbosity of debug logs during booting). De mon coté, le déchiffrement fonctionne (c’est-à-dire, il accède au contenu du disque et commence la procédure de boot) mais s’arrête abruptement sans plus d’info.

Ce que l’on peut voir avec loglevel supérieur

Pas des plus informatif sur la source du problème mais au moins, il arrive à démarrer (filmez votre écran et rejouez la vidéo en image par image).

Dans l’attente d’un message d’erreur lors du boot

Pas beaucoup d’info mais pas de stress, on crée un live USB (j’ai pris une clef USB Ubuntu, il n’est pas obligatoire d’utiliser le même OS que celui installé). On démarre et on lance un terminal:

$ sudo fdisk -l
..
Disk /dev/nvme0n1: 238.49 GiB, 256060514304 bytes, 500118192 sectors
Disk model: PC SN520 NVMe WDC 256GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: EECB8607-5D1A-4B49-BF5E-7D2012C5FB97
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 411647 409600 200M EFI System
/dev/nvme0n1p2 411648 500118158 499706511 238.3G Linux filesystem

Voici mon disque, une partition boot, en clair, sur nvme0n1p1 et une partition chiffrée avec LUKS sur nvme0n1p2. On va donc les monter pour y accéder:

$ sudo mount /dev/nvme0n1p2 /mnt/
mount: /mnt: unknown filesystem type 'crypto_LUKS'.
$ sudo cryptsetup luksOpen /dev/nvme0n1p2 mydisk
Enter passphrase for /dev/nvme0n1p2: *****
$ sudo vgscan
Found volume group "MyVolGroup" using metadata type lvm2
$ ls /dev/mapper/
control mydisk MyVolGroup-root
$ sudo mount /dev/mapper/MyVolGroup-root /mnt/
$ sudo mount /dev/nvme0n1p1 /mnt/boot/
$ sudo mount -B /dev /mnt/dev
$ sudo mount -B /dev/pts /mnt/dev/pts
$ sudo mount -B /proc /mnt/proc
$ sudo mount -B /sys /mnt/sys
$ sudo mount -B /run /mnt/run
$ sudo cp /etc/resolv.conf /mnt/etc/resolv.conf

Toutes ces commandes me permettent d’avoir un système fonctionnel dans le dossier /mnt. La dernière commande permet d’avoir accès à internet lors du chroot.

$ sudo chroot /mnt
# pacman -Syu
…
-> Running build hook: [encrypt]
-> Running build hook: [lvm2]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
==> Image generation successful
(11/17) Reloading system bus configuration…
Running in chroot, ignoring command 'try-reload-or-restart'
(12/17) Probing GDK-Pixbuf loader modules…
(13/17) Probing 32-bit GDK-Pixbuf loader modules…
(14/17) Updating icon theme caches…
(15/17) Updating the info directory file…
(16/17) Updating the desktop file MIME type cache…
(17/17) Updating the MIME type database…

Dans mon cas, il s’agissait probablement d’une mise à jour corrompue. Donc, mettre à jour le système (avec une mise à jour du paquet linux en bonus) a réglé le souci. Si vous aviez un autre problème (GRUB mal installé par exemple), le chroot est également une bonne façon de procéder. Une fois les manipulations finies, on sort du chroot et on referme tous les disques.

# exit
ubuntu@ubuntu:~$ sudo umount /mnt/dev/pts
ubuntu@ubuntu:~$ sudo umount /mnt/dev/
ubuntu@ubuntu:~$ sudo umount /mnt/sys
ubuntu@ubuntu:~$ sudo umount /mnt/run
ubuntu@ubuntu:~$ sudo umount /mnt/proc
ubuntu@ubuntu:~$ sudo umount /mnt/boot
ubuntu@ubuntu:~$ sudo umount /mnt
ubuntu@ubuntu:~$ sudo cryptsetup close MyVolGroup-root
ubuntu@ubuntu:~$ sudo cryptsetup close mydisk
ubuntu@ubuntu:~$ sudo reboot

Et après un redémarrage et un peu de sueur froide, le système redémarre correctement !

 Limberger's Victory (cinema 1915)
Vus : 379
Publié par mart-e : 65