Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#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 :
1545500251-2-img-20181222-182515.png et si je lance "help", il déroule
1545500256-3-img-20181222-182737.png
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 :
1545500257-1-img-20181222-182630.png
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
1545500256-4-img-20181222-182917.png
Ensuite je rentre ma phrase de passe et ça déroule
1545500256-5-img-20181222-183117.png
Si j'attends sans toucher à rien sur cet écran, il affiche ensuite
1545500257-6-img-20181222-183006.png
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

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 :

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

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

Hors ligne

#7 Le 24/12/2018, à 17:44

MPR

Re : Pourquoi une partition chiffrée est devenue innacessible

., a écrit :
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 hmm

Pour ce qui est de ta phrase suivante, super, merci !

Bonne soirée (et fêtes ?)

Hors ligne