#1 Le 22/12/2018, à 17:17
- MPR
Pourquoi une partition chiffrée est devenue innacessible
Bonjour à tous,
Après plusieurs heures de recherches et d'essais variés, je sollicite finalement l'aide de la communauté. J'espère ne pas doublonner avec un autre sujet à côté duquel je suis passé ; si c'est le cas je vous prie de m'excuser et vous remercie pour toute aide me permettant de le localiser.
EDIT : plutôt que de passer le sujet en résolu, j'en modifie le titre. Bien que j'ai résolu mon problème par la méthode forte (réinstallation du système), je suis très intéressé si vous avez une idée de ce qui a pu causer le problème au départ (pour éviter que cela ne se reproduise).
J'utilise un SSD Corsair Force LE sur lequel il y a une partition en ext2 de 487mo, une partition "extended" de 223.09 Gio et à l'intérieur une partition "crypt-luks" de 223.09 Gio (état actuel des choses, infos telles que données par Gparted). Dedans il y a mon système ubuntu 16.04 LTS 64bits et mes données. (Ça vient du fait qu'à l'installation de ce système, j'ai choisit une installation chiffré avec partition LVM).
Tout a très bien fonctionné pendant des mois.
Sans raison identifiée par moi, lorsque je lance l'ordi sur ce disque, j'ai désormais un message d'erreur qui m'empêche de lancer le système. Je vous explique et mets les images ci-dessous si besoin mais je précise d'emblée que mon objectif n'est pas de faire fonctionner cet OS mais simplement de récupérer des données dessus, d'où ce que j'ai entrepris ensuite.
Donc, quand je boot sur ce disque, si je ne touche à rien, j'ai l'écran me demandant le pass de mon disque chiffré puis j'arrive là-dessus :
et si je lance "help", il déroule
Si je reboot et au lieu de ne toucher à rien je vais dans options avancées, voici la liste de ce que je peux lancer :
Si je lance les deux premières lignes (normal et upstart), j'obtiens le même résultat que si je n'avais touché à rien.
Si je lance la troisième ligne (recovery mode), j'obtiens un défilement très rapide, puis
Ensuite je rentre ma phrase de passe et ça déroule
Si j'attends sans toucher à rien sur cet écran, il affiche ensuite
Ensuite, j'ai essayé également de lancer depuis d'autres "lignes" depuis les options avancées, notamment la plus ancienne (ligne la plus basse), et j'obtiens la même chose (en fonction de normal et upstart d'une part et recovery mode de l'autre).
Mon seul besoin est de récupérer des données qui sont sur ce disque.
J'ai donc branché ce SSD dans un lecteur de disque sur une autre machine (en Ubuntu 16.04 aussi).
L'état actuel des choses, c'est que :
- en version graphique quand j'ouvre une fenêtre avec le programme "fichiers", le disque et ses partitions n'apparaissent pas dans la liste à gauche
- avec Gparted, il affiche donc une partition en ext2 de 487mo (en l'occurence sdb1), une partition "extended" de 223.09 Gio (sdb2) et à l'intérieur une partition "crypt-luks" de 223.09 Gio (sdb5) mais un clique droit ne permet pas l'option "monter" sur aucune des partitions
- en lignes de commandes,
sudo fdisk -l
renvoie
Disque /dev/sda : 55,9 GiB, 60022480896 octets, 117231408 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x25974e53
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 1001470 117229567 116228098 55,4G 5 Étendue
/dev/sda5 1001472 117229567 116228096 55,4G 83 Linux
Disque /dev/sdb : 223,6 GiB, 240057409536 octets, 468862128 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 4096 octets / 33553920 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xef8f650d
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdb1 * 2048 999423 997376 487M 83 Linux
/dev/sdb2 1001470 468860927 467859458 223,1G 5 Étendue
/dev/sdb5 1001472 468860927 467859456 223,1G 83 Linux
La partition 2 ne commence pas sur une frontière de cylindre physique.
Disque /dev/mapper/sda5_crypt : 55,4 GiB, 59506688000 octets, 116224000 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/mapper/ubuntu--vg-root : 47,5 GiB, 51019513856 octets, 99647488 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/mapper/ubuntu--vg-swap_1 : 7,9 GiB, 8476688384 octets, 16556032 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/mapper/luks-690e45f3-8834-4ed0-8a89-16c56663e391 : 223,1 GiB, 239541944320 octets, 467855360 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 4096 octets / 33553920 octets
sudo mount /dev/sdb1 /mnt
ne renvoie rien
sudo mount /dev/sdb2 /mnt
renvoie
mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
missing codepage or helper program, or other error
Dans certains cas des renseignements utiles sont dans le journal
système — essayez « dmesg | tail » ou quelque chose du genre
dmesg | tail
renvoie
[ 67.096186] intel_pstate: Turbo disabled by BIOS or unavailable on processor
[ 71.100476] intel_pstate: Turbo disabled by BIOS or unavailable on processor
[ 152.587636] sdb: sdb1 sdb2 < sdb5 >
[ 481.579949] sdb: sdb1 sdb2 < sdb5 >
[ 1091.512235] EXT4-fs (sdb2): unable to read superblock
[ 1091.512403] EXT4-fs (sdb2): unable to read superblock
[ 1091.512639] EXT4-fs (sdb2): unable to read superblock
[ 1330.490731] EXT4-fs (sdb2): unable to read superblock
[ 1330.490950] EXT4-fs (sdb2): unable to read superblock
[ 1330.491159] EXT4-fs (sdb2): unable to read superblock
sudo mount /dev/sdb5 /mnt
renvoie :
mount: type de système de fichiers « crypto_LUKS » inconnu
et
sudo cryptsetup luksOpen /dev/sdb1
(ou 2 ou 5) renvoie :
Le périphérique /dev/sdb1 n'existe pas ou l'accès y est interdit.
(ou 2 ou 5)
À la suite d'un reboot, au départ :
- en graphique, dans une fenêtre "fichiers", il y a bien un "volume de 511 Mo" qui s'ouvre quand on le clique, et dans lequel il y a un dossiers grub et des fichiers (rien d'autre)
- dans Gparted, le disque problématique est devenu sda et la partition sda1 de 487 Mo est montée (toujours impossible de monter sda2 et sda5)
- en ligne de commande
sudo mount /dev/sda2 /mnt
renvoie
mount: /dev/sda2 n'est pas un périphérique bloc valable
et
sudo mount /dev/sda5 /mnt
renvoie
mount: type de système de fichiers « crypto_LUKS » inconnu
Ensuite, si je démonte sda1,
sudo mount /dev/sda2 /mnt
renvoie à nouveau
mount: wrong fs type, bad option, bad superblock on /dev/sda2,
missing codepage or helper program, or other error
Dans certains cas des renseignements utiles sont dans le journal
système — essayez « dmesg | tail » ou quelque chose du genre.
et
dmesg | tail
renvoie
[ 52.613821] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
[ 52.629047] EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended
[ 52.629280] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[ 513.608292] sda: sda1 sda2 < sda5 >
[ 533.800986] EXT4-fs (sda2): unable to read superblock
[ 533.801297] EXT4-fs (sda2): unable to read superblock
[ 533.801578] EXT4-fs (sda2): unable to read superblock
[ 591.951009] EXT4-fs (sda2): unable to read superblock
[ 591.951226] EXT4-fs (sda2): unable to read superblock
[ 591.951355] EXT4-fs (sda2): unable to read superblock
et
sudo mount /dev/sda5 /mnt
renvoie
mount: type de système de fichiers « crypto_LUKS » inconnu
Je repars sur
cryptsetup open /dev/sda1 test
(ou sda2, ou 5) et qui renvoie toujours
Le périphérique /dev/sda1 n'existe pas ou l'accès y est interdit.
(ou sda2, ou 5).
Lorsque je ferme Gparted, d'un coup dans la colonne de gauche d'une fenêtre "fichier" (et directement dans la barre de navigation) apparaissent 2 icônes, 1 pour le volume chiffré de 511 Mo et 1 pour "240 GB chiffrés". Je clique sur le premier, ouverture sans problème (dossier grub et fichiers). Je clique sur le second, si mon mdp est faux (volontairement), il ne se passe rien et je réessaye ensuite. Si mon mdp est bon, l'icône disparaît sans donner de nouvelles. Je rouvre Gparted, aucun changement si ce n'est que sda1 (487Mo) est montée.
Une dernière précision :
J'ai mis le SSD problématique dans une machine comme seul disque, branché une liveUSB (d'Ubuntu 16.04 LTS pareil), et lancé "vérifier que le disque n'a pas d'erreur" et ça m'a renvoyé "check finished, no error found".
En étant sur la session live (liveusb Ubuntu 16.04 LTS), les résultats sont d'abord similaire PUIS le lendemain matin (sans que je sache ce qui a changé entre temps), légèrement différent :
- en mode graphique, je clique sur "240 GB chiffrés", on me demande ma passe phrase (si je me trompe volontairement, il m'affiche
Impossible d'accéder à "240 GB chiffrés"
Error unlocking /dev/sda5: Command-line `cryptsetup luksOpen "/dev/sda5" "luks-690e45f3-8834-4ed0-8a89-16c56663e391" ' exited with non-zero exit status 2: No key available with this passphrase.
), et là le message d'erreur qui affranchie dans une fenêtre prompt est différent : "Operation cancelled"
MAIS le disque est accessible malgré tout (avec de très nombreux problèmes de permissions et de droits d'accès à certains fichiers / dossiers et pas d'autres).
Surtout, l'énorme différence entre ce matin et hier soir, c'est que
sudo fdisk -l
ne renvoie plus d'erreurs physiques
Disk /dev/ram0: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram1: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram2: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram3: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram4: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram5: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram6: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram7: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram8: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram9: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram10: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram11: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram12: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram13: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram14: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram15: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/loop0: 1.4 GiB, 1497772032 bytes, 2925336 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
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: 0xef8f650d
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 1001470 468860927 467859458 223.1G 5 Extended
/dev/sda5 1001472 468860927 467859456 223.1G 83 Linux
Disk /dev/sdb: 3.8 GiB, 4034953216 bytes, 7880768 sectors
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: 0x15e2543d
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 3035519 3035520 1.5G 0 Empty
/dev/sdb2 14432 19295 4864 2.4M ef EFI (FAT-12/16/32)
Disk /dev/mapper/luks-690e45f3-8834-4ed0-8a89-16c56663e391: 223.1 GiB, 239541944320 bytes, 467855360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/ubuntu--vg-root: 215.1 GiB, 230963544064 bytes, 451100672 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/ubuntu--vg-swap_1: 8 GiB, 8531214336 bytes, 16662528 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
J'ai donc laborieusement récupérer les données les plus sensibles pour moi, et vais essayer de réinstaller totalement le système sur ce disque pour savoir si le disque (SSD) est défectueux / endommagé ou si c'est un simple problème logiciel. Je vous tiens au courant, si ça aide d'autres personnes de la communauté. EDIT : un
sudo fdisk -l
ne renvoie plus aucune anomalie après une réinstallation totale du système, et mes données sont récupérées (cf tout ce bazar au dessus).
En revanche, si quelqu'un a une idée pour identifier comment est née le problème (et éviter de refaire ce genre d'erreur, donc), ça serait vraiment génial !
Je vous réponds dès que possible pour vous donner toutes les infos dont vous aurez besoin.
Bonne journée,
Dernière modification par MPR (Le 24/12/2018, à 12:30)
Hors ligne
#2 Le 23/12/2018, à 06:53
- noje
Re : Pourquoi une partition chiffrée est devenue innacessible
Bonjour,
Pour le montage quand installer dans l'autre PC, il ne faut pas utiliser mount mais cryptsetup.
sudo cryptsetup luksOpen /dev/sda* "nom de volume"
Normalement la passphrases et demandé, par contre la passphrase n'est pas le mot de passe de session il me semble, mais une clé courte, générer aléatoirement lors de la création de la partition qu'il faut noter.
La documentation de cryptsetup si nécessaire
https://doc.ubuntu-fr.org/cryptsetup#applications
Bon courage.
- LTS 18.04 & 22.04 - jwm - cwm - zsh
Les seules vraies erreurs sont celles que nous commettons à répétition.
Les autres sont des occasions d'apprentissage. (Dalaï Lama)
Hors ligne
#3 Le 23/12/2018, à 13:30
- MPR
Re : Pourquoi une partition chiffrée est devenue innacessible
Bonjour à tous,
J'ai réussi à récupérer mes données laborieusement et à réinstaller intégralement le système et tout est rentré dans l'ordre (un
sudo fdisk -l
ne renvoie plus aucune anomalie.
En revanche, si quelqu'un a une idée pour identifier comment est née le problème (et éviter de refaire ce genre d'erreur, donc), ça serait vraiment génial !
Je vous réponds dès que possible pour vous donner toutes les infos dont vous aurez besoin.
Bonne journée,
Hors ligne
#4 Le 23/12/2018, à 14:28
- Nuliel
Re : Pourquoi une partition chiffrée est devenue innacessible
Quelles commandes as tu passé pour réparer le problème? fsck non?
Hors ligne
#5 Le 24/12/2018, à 12:26
- MPR
Re : Pourquoi une partition chiffrée est devenue innacessible
Quelles commandes as tu passé pour réparer le problème? fsck non?
Bonjour,
Et bien, je ne sais pas. Je m'explique :
Tout ce que j'ai fais est a priori détaillé dans mon post. Concrètement, le premier jour j'ai fait moult tentatives de monter / ouvrir la partition chiffrée, sans succès (à la fois en branchant le SSD comme périph extern dans un dock, à la fois en le branchant en SATA en interne et en bootant sur un autre disque ou en bootant depuis une live session - à l'aide des commandes
mount
et aussi
cryptsetup luksOpen
).
-> Le lendemain, j'ai a nouveau booté depuis une liveUSB avec le SSD problématique en SATA dans la tour, et j'ai accédé au disque du premier coup (malgré un message d'erreur "opération cancelled") en mode graphique (par une fenpetre "fichiers"). Je précise que j'avais également essayé aussi le lendemain de booté sur le SSD problématique, et que je m'étais classiquement confronté aux messages "initramfs" sur fond noir, cf photos dans le premier post).
En ce qui concerne les permissions (ce que je n'ai pas développé dans le message précédent édité), j'ai finis par bricoler une solution en formant des archives tar splittées en sudo depuis le disque problématique vers un autre espace de stockage (sinon, je n'arrivais pas à accéder aux données dont le propriétaire était "#1000").
Je n'ai pas appliqué de
fsck
par peur de perdre les données.
Dernière modification par MPR (Le 24/12/2018, à 12:26)
Hors ligne
#6 Le 24/12/2018, à 13:28
- .,
Re : Pourquoi une partition chiffrée est devenue innacessible
Naziel a écrit :Quelles commandes as tu passé pour réparer le problème? fsck non?
Bonjour,
Et bien, je ne sais pas. Je m'explique :
Je n'ai pas appliqué de
fsck
par peur de perdre les données.
Bonjour.
Si tu oublies le fait que tes données sont cryptées, tu trouveras, dans ce seul forum, des centaines de cas où il fut nécessaire faire manuellement cette commande.
La cause est très souvent un arrêt anormal de ubuntu. Mais elle peut aussi être liée à un mauvais état du disque que l'application smartmontools sait détecter. https://doc.ubuntu-fr.org/smartmontools
Hors ligne
#7 Le 24/12/2018, à 17:44
- MPR
Re : Pourquoi une partition chiffrée est devenue innacessible
MPR a écrit :Naziel a écrit :Quelles commandes as tu passé pour réparer le problème? fsck non?
Bonjour,
Et bien, je ne sais pas. Je m'explique :
Je n'ai pas appliqué de
fsck
par peur de perdre les données.
Bonjour.
Si tu oublies le fait que tes données sont cryptées, tu trouveras, dans ce seul forum, des centaines de cas où il fut nécessaire faire manuellement cette commande.
La cause est très souvent un arrêt anormal de ubuntu. Mais elle peut aussi être liée à un mauvais état du disque que l'application smartmontools sait détecter. https://doc.ubuntu-fr.org/smartmontools
Je te remercie (je vous remercie tous les trois) pour ta réponse.
Concernant fsck, le terminal renvoie un message indiquant qu'il va y avoir perte de données, d'où ma réticence. Il est possible que j'ai occulté les messages sur le forum qui passaient par cette commande à cause de cela. Au temps pour moi
Pour ce qui est de ta phrase suivante, super, merci !
Bonne soirée (et fêtes ?)
Hors ligne