# \[cryptsetup\] Device /dev/sdc3 is not a valid LUKS device **URL:** \ **Category:** Support Debian\ **Created:** [Octobre 14, 2019, 5:04 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395 "2019-10-14T17:04:24Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![r-one](https://www.debian-fr.org/user_avatar/www.debian-fr.org/r-one/32/8936_2.png) [@r-one](https://www.debian-fr.org/u/r-one)\ **Post date:** [Octobre 14, 2019, 5:04 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395/1 "2019-10-14T17:04:24Z")
Bonjour à tous, J’ai eu une rupture de courant alors que mon ancien SSD partiellement chiffré était monté sur ma Debian Buster. Depuis, à chaque tentative de montage des partitions chiffrées de ce SSD j’obtiens une erreur “_Device /dev/sdc3 is not a valid LUKS device_” : ```nohighlight # fdisk -l [...] Disk /dev/sdc: 232.9 GiB, 250059350016 bytes, 488397168 sectors Disk model: 2105 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: dos Disk identifier: 0x9e1584aa ``` ```nohighlight Device Boot Start End Sectors Size Id Type /dev/sdc1 * 2048 1953791 1951744 953M 83 Linux /dev/sdc2 1953792 70313983 68360192 32.6G 83 Linux /dev/sdc3 70313984 472852479 402538496 192G 83 Linux /dev/sdc4 472852480 488396799 15544320 7.4G 83 Linux ``` ```nohighlight # cryptsetup luksOpen /dev/sdc3 old-home Device /dev/sdc3 is not a valid LUKS device. ``` ```nohighlight # cryptsetup luksOpen /dev/sdc4 swap Device /dev/sdc4 is not a valid LUKS device. ``` ```nohighlight # cryptsetup -v isLuks /dev/sdc3 Command failed with code -1 (wrong or missing parameters). ``` ```nohighlight # cryptsetup -v isLuks /dev/sdc4 Command failed with code -1 (wrong or missing parameters). ``` Pour info, les partitions sdc1 et sdc2 non chiffrées du même SSD se monte correctement. (sdc4 = swap chiffrée avec clé aléatoire) Et ça ne vient pas - à priori - de LUKS puisque mes autres partitions chiffrées sont correctement déchiffrées : ```nohighlight # ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 100 Oct 14 11:51 ./ drwxr-xr-x 19 root root 3700 Oct 14 17:45 ../ crw------- 1 root root 10, 236 Oct 14 11:50 control lrwxrwxrwx 1 root root 7 Oct 14 11:50 sda3_crypt -> ../dm-0 lrwxrwxrwx 1 root root 7 Oct 14 11:51 sdb1_crypt -> ../dm-1 ``` Après recherches, j’ai bien trouvé sur le Net des personnes ayant eu ce même message d’erreur mais, soit ils n’ont pas eu de réponses, soit le problème était différent et donc la solution inadaptée. Quelqu’un pourrait me conseiller/m’aider svp ? Merci d’avance, R-One ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Octobre 15, 2019, 9:48 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395/2 "2019-10-15T09:48:06Z")
> [@r-one](#): > > sdc4 = swap chiffrée avec clé aléatoire A ma connaissance, on ne peut pas utiliser une clé aléatoire avec LUKS, seulement avec « plain dm-crypt ». Que disent `blkid` et `file -s` de ces deux partitions ? Que contient /etc/crypttab ? ---
**Author:** ![r-one](https://www.debian-fr.org/user_avatar/www.debian-fr.org/r-one/32/8936_2.png) [@r-one](https://www.debian-fr.org/u/r-one)\ **Post date:** [Octobre 15, 2019, 1:32 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395/3 "2019-10-15T13:32:44Z")
Merci pour ta réponse PascalHambourg. Voici le résultat des commandes : `# blkid /dev/sdc3 /dev/sdc3: PARTUUID=“9e1584aa-03”` `# file -s /dev/sdc3 /dev/sdc3: data` `# blkid /dev/sdc4 /dev/sdc4: PARTUUID=“9e1584aa-04”` `# file -s /dev/sdc4 /dev/sdc4: data` `# cat /etc/crypttab sda3_crypt /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap sdb1_crypt UUID=5c8c6ef1-d9ed-40fe-9606-698d8f0edc72 none luks` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Octobre 15, 2019, 3:10 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395/4 "2019-10-15T15:10:15Z")
Je ne sais plus si `file` sait identifier un en-tête LUKS, mais `blkid` le sait, et il n’en trouve pas dans ces deux partitions. Elles ne sont pas non plus déclarées dans /etc/crypttab. Comment étaient-elles ouvertes auparavant ? Est-ce qu’elles appartiennent à ce système ou à une autre installation ? Notes : - Comme je l’expliquais, le swap chiffré avec clé aléatoire sda3\_crypt défini dans /etc/crypttab n’utilise pas LUKS mais “plain dm-crypt”, contrairement à l’autre volume sdb1\_crypt. - Spécifier le volume physique par son nom de périphérique /dev/sd\* dans /etc/crypttab est une erreur à éviter, comme dans /etc/fstab. Les noms /dev/sd\* ne sont pas stables et peuvent changer à chaque démarrage lorsqu’il y a plusieurs “disques”. Dans le cas d’un volume chiffré avec LUKS, la conséquence sera seulement l’impossibilité de l’ouvrir (c’est pourquoi on identifie le volume avec l’UUID de son en-tête LUKS comme ici pour sdb1\_crypt). Mais cette erreur peut avoir des conséquences beaucoup plus graves avec le chiffrement plain dm-crypt, car il n’y a aucune vérification du format de la partition ; si ce n’est pas la bonne partition, elle sera utilisée quand même et son contenu sera écrasé à la première écriture (donc à l’ouverture puisque l’option “swap” provoque le formatage en tant que swap). On ne peut pas utiliser l’UUID car il n’y en a pas, mais on peut utiliser un des alias persistants créés dans `/dev/disk/by-{id,partuuid,partlabel}/` qui pointent vers la partition. ---
**Author:** ![r-one](https://www.debian-fr.org/user_avatar/www.debian-fr.org/r-one/32/8936_2.png) [@r-one](https://www.debian-fr.org/u/r-one)\ **Post date:** [Octobre 15, 2019, 5:28 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395/5 "2019-10-15T17:28:57Z")
Alors : - sda (SSD 500Go) et sdb (HD 1To) appartiennent tous les deux à l’install d’une Debian Stretch, mise à jour dernièrement (mais après la coupure de courant) en Debian Buster et que j’utilise actuellement. - sdc (SSH 256Go) quant à lui appartient à une install Debian Stretch faite sur un ancien pc. `# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 953M 0 part /boot ├─sda2 8:2 0 457.4G 0 part / └─sda3 8:3 0 7.5G 0 part └─sda3_crypt 254:0 0 7.5G 0 crypt [SWAP] sdb 8:16 0 931.5G 0 disk └─sdb1 8:17 0 931.5G 0 part └─sdb1_crypt 254:1 0 931.5G 0 crypt /home sdc 8:32 0 232.9G 0 disk ├─sdc1 8:33 0 953M 0 part /media/erwan/a58f0c01-3f11-4725-b9f1-510528517781 ├─sdc2 8:34 0 32.6G 0 part /media/erwan/fe8f7c6c-e7e7-4722-8f44-8756738f80be ├─sdc3 8:35 0 192G 0 part └─sdc4 8:36 0 7.4G 0 part sr0 11:0 1 1024M 0 rom` Jusqu’à présent, après démarrage de mon pc, je branchais et montais régulièrement la partition /home chiffrée (sdc3) du SSD de 256Go, via une station d’accueil USB et en tapant les commandes suivantes : `# cryptsetup luksOpen /dev/sdc3 old-home` et une fois la passphrase correctement renseignée : `# mount /dev/mapper/old-home /mnt/usb` Les partitions sdc1 et sdc2 se montent automatiquement via l’explorateur de fichiers que j’utilise : “SpaceFM”. Sinon, merci pour tes conseils sur la façon de renseigner `/etc/crypttab` et/ou `/etc/fstab` : c’est très instructif ! J’ai donc modifié `/etc/crypttab` de la sorte : `# cat /etc/crypttab sda3_crypt /dev/disk/by-partuuid/cf196c2f-03 /dev/urandom cipher=aes-xts-plain64,size=256,swap sdb1_crypt UUID=5c8c6ef1-d9ed-40fe-9606-698d8f0edc72 none luks` (Pour info, le contenu de `/etc/crypttab` indiqué dans mon précédent post était celui crée par l’install initiale de Debian Stretch) Tu penses qu’il y aurait pu avoir “mélange” entre les partitions et que l’actuelle sdc3 ait été formatée en tant que swap ? (Bien que - sauf erreur de ma part - le SSD de 256Go n’est normalement pas branché au démarrage du pc) ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Octobre 15, 2019, 9:53 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395/6 "2019-10-15T21:53:41Z")
Je ne peux pas m’empêcher de remarquer que l’ancienne partition home /dev/sdc3 a le même numéro que la partition de swap chiffré actuelle /dev/sda3. S’il est arrivé une fois que le SSD de 250 Go soit présent au démarrage et vu comme /dev/sda au lieu de /dev/sdc, alors l’ancienne partition home s’est retrouvée vue comme /dev/sda3 et a été réinitialisée comme swap chiffré conformément au contenu dangereux de /etc/crypttab. Je sais que c’est l’installateur Debian qui crée /etc/crypttab de cette façon, et je le déplore. Si tu n’avais pas sauvegardé l’en-tête LUKS de la partition, elle est irrécupérable. Même dans le cas contraire, son système de fichiers sera probablement endommagé. ---
**Author:** ![r-one](https://www.debian-fr.org/user_avatar/www.debian-fr.org/r-one/32/8936_2.png) [@r-one](https://www.debian-fr.org/u/r-one)\ **Post date:** [Octobre 16, 2019, 11:10 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395/7 "2019-10-16T11:10:56Z")
Ton hypothèse m’a travaillé presque toute la nuit ! Au vu de tes explications, c’est effectivement ce que je crains. Je me pose cependant une question : au démarrage, l’ordinateur a 2 possibilités de boot, vu que chacun des 2 SSD contient une partition /boot. - Si le SSD de 500Go est vu comme `/dev/sda` (la normalité) alors il n’y a pas pu avoir “écrasement” de `/dev/sdc3` : en effet, c’est le fichier `/etc/crypttab` de `/dev/sda` (et donc du SSD de 500Go) qui a été pris en compte. Dans ce cas la ligne contenant la mention `/dev/sda3` de ce fichier pointe bien vers la bonne partition. (la 3ème de ce même SSD de 500Go, c’est à dire la swap) - Si par contre, c’est le SSD de 256Go qui est vu comme `/dev/sda` (et le SSD de 500Go comme `/dev/sdc`) c’est toujours le fichier `/etc/crypttab` de `/dev/sda` (et donc ici du SSD de 256Go) qui a été pris en compte. Or celui-ci contient : `$ cat /media/erwan/fe8f7c6c-e7e7-4722-8f44-8756738f80be/etc/crypttab sda3_crypt UUID=1e012b00-8a68-461d-8202-c92e65de1e4f none luks sda4_crypt /dev/sda4 /dev/urandom cipher=aes-xts-plain64,size=256,swap` Comment y aurait-il pu avoir “écrasement” en ce cas ? Je ne sais pas si je m’explique correctement 🙄 En fait je comprends ta logique, mais j’avoue ne pas savoir comment l’appliquer dans ce qui semble m’être arrivé. ---
**Author:** ![r-one](https://www.debian-fr.org/user_avatar/www.debian-fr.org/r-one/32/8936_2.png) [@r-one](https://www.debian-fr.org/u/r-one)\ **Post date:** [Octobre 16, 2019, 11:46 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395/8 "2019-10-16T11:46:19Z")
PascalHambourg, ton hypothèse semble malheureusement se confirmer de plus en plus : `# cryptsetup luksDump /dev/sdc3 Device /dev/sdc3 is not a valid LUKS device.` `# cryptsetup luksDump /dev/sdc4 Device /dev/sdc4 is not a valid LUKS device.` `# cryptsetup luksDump /dev/sda3 Device /dev/sda3 is not a valid LUKS device.` `# cryptsetup luksDump /dev/sdb1 LUKS header information for /dev/sdb1` `Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 512 MK digest: 9a 62 35 7a 74 bb 25 ff 38 ce c4 90 1c 28 ae 0c 50 5f 2e 37 MK salt: 69 5f f0 5c cf b9 98 d1 14 99 b7 ae f1 a8 b0 7a 42 a2 f6 60 20 ac 0c bd da 8f 80 d8 5e 31 9e 66 MK iterations: 197500 UUID: 5c8c6ef1-d9ed-40fe-9606-698d8f0edc72` Key Slot 0: ENABLED Iterations: 1610062 Salt: 3d 0c af 5f 93 04 ba 9b b2 82 55 10 fd d5 cb 03 44 5c c3 22 7f b2 9f fc d7 0e a0 73 95 36 7f 3f Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED 😭 Il n’y a pas un moyen d’être sûr à 100%, genre consulter les valeurs hexadécimales du header de la partition ? J’imagine qu’une partition “plain dm-crypt” doit avoir un header particulier par rapport à un header LUKS, non ? Sinon pour info, je n’ai aucune sauvegarde de l’en-tête LUKS (je ne savais même pas qu’il fallait le faire !) ni aucune sauvegarde de la partition : je m’apprêtais justement à en faire une lorsque la coupure a eu lieu ! (elle a même flingué un des 4 disques constituant mon raid-Z2, mais je n’ai perdu ici aucune donnée) ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Octobre 16, 2019, 12:22 UTC](https://www.debian-fr.org/t/cryptsetup-device-dev-sdc3-is-not-a-valid-luks-device/80395/9 "2019-10-16T12:22:06Z")
> [@r-one](#): > > au démarrage, l’ordinateur a 2 possibilités de boot, vu que chacun des 2 SSD contient une partition /boot. > > - Si le SSD de 500Go est vu comme `/dev/sda` (la normalité) Il n’y a pas de corrélation entre le disque de boot ni la numérotation des disques par le BIOS/UEFI et le nommage des disques /dev/sd\*. Les disques sont nommés dans l’ordre de leur détection par le noyau, ordre qui n’est pas déterministe. Le disque de boot peut très bien être vu comme /dev/sdb ou /dev/sdc. Le pilote usb-storage qui gère les disques USB introduit un délai (1 seconde par défaut) qui retarde la détection et le nommage des disques USB, de sorte que les disques internes sont généralement détectés et nommés avant. Mais les pilotes sont chargés et détectent les périphériques de façon asynchrone, et il n’est pas impossible que le pilote USB soit chargé avant le pilote SATA et que l’intervalle entre la detection du disque USB et des disques SATA soit supérieur à 1 seconde, conduisant le disque USB à être nommé « sda ». Tu pourrais rechercher dans les anciens logs du noyau /var/log/kern.\* s’il est arrivé que le disque USB soit vu comme « sda ». > [@r-one](#): > > Il n’y a pas un moyen d’être sûr à 100%, genre consulter les valeurs hexadécimales du header de la partition ? > J’imagine qu’une partition “plain dm-crypt” doit avoir un header particulier par rapport à un header LUKS, non ? Tu peux examiner le contenu hexadecimal d’une partition avec la commande `hd` (hexdump), en limitant la taille aux xxx premiers octets avec l’option `-n xxx`. Mais non, le chiffrement « plain dm-crypt » n’a pas d’en-tête particulier. C’est du contenu chiffré par dm-crypt brut. C’est pourquoi il faut spécifier les paramètres de chiffrement lors de l’ouverture avec cryptsetup ou crypttab (ex : `cipher=aes-xts-plain64,size=256`). Il n’y a aucune vérification de validité de la clé de chiffrement spécifiée : les données sont simplement chiffrées et déchiffrées avec cette clé, que le contenu soit intelligible ou non. Le format LUKS, c’est un en-tête LUKS qui contient notamment les paramètres de chiffrement, la clé de chiffrement (protégée par 1 à 8 passphrases) et un UUID pour l’identifier, suivi par les données chiffrées par dm-crypt.