Ubuntu-fr

kamaris

Re : Récupération de données sur disque crypté

Pas grave, comme ça :

sudo mount -t ext4 /dev/lubuntu-vg/root /mnt

?

Sapin64

Re : Récupération de données sur disque crypté

A tout hasard, si ça peut aider, je te donne la réponse à la commande conseillée (« dmesg | tail ») :

sapin@sapin-MS-7680:~/Bureau$  dmesg | tail
[ 5053.519950] usblp 1-1.2:1.0: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04F9 pid 0x02D1
[ 5101.886427] usblp0: removed
[ 5102.390014] usblp 1-1.2:1.0: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04F9 pid 0x02D1
[ 5130.967645] usblp0: removed
[ 5131.473774] usblp 1-1.2:1.0: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04F9 pid 0x02D1
[ 7871.392917] vboxdrv: 00000000 VMMR0.r0
[ 7871.620822] vboxdrv: 00000000 VBoxDDR0.r0
[ 7871.767042] usblp0: removed
[ 7901.055438] usb 1-1.2: reset high-speed USB device number 4 using ehci-pci
[ 7901.160383] usblp 1-1.2:1.0: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04F9 pid 0x02D1

Sapin64

Re : Récupération de données sur disque crypté

sapin@sapin-MS-7680:~/Bureau$ sudo mount -t ext4 /dev/lubuntu-vg/root /mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/lubuntu--vg-root,
       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.

kamaris

Re : Récupération de données sur disque crypté

Bon, essayons une réparation :

sudo fsck /dev/lubuntu-vg/root

Si il te demande pour réparer des blocs, tu fais « y ».

Sapin64

Re : Récupération de données sur disque crypté

Voila ce que j'obtiens :

sapin@sapin-MS-7680:~/Bureau$ sudo fsck /dev/lubuntu-vg/root
fsck de util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Numéro magique invalide dans le super-bloc
fsck.ext2 : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
fsck.ext2: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/mapper/lubuntu--vg-root

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

kamaris

Re : Récupération de données sur disque crypté

Ok, essaie ce qu'il te dit

e2fsck -b 8193 /dev/lubuntu-vg/root

ou

e2fsck -b 32768 /dev/lubuntu-vg/root

mais là, j'avoue que je suis un peu à l'aveugle : si quelqu'un de calé dans ce genre de choses passe par là…
Car là on a quitté la partie chiffrement en fait : ton système de fichiers a l'air d'avoir un bon souci…
(c'était d'ailleurs probablement pour ça qu'en #17 tu n'avais pas la complétion avec les volumes logiques)

Dernière modification par kamaris (Le 16/04/2020, à 22:01)

Sapin64

Re : Récupération de données sur disque crypté

sapin@sapin-MS-7680:~/Bureau$ e2fsck -b 32768 /dev/lubuntu-vg/root
e2fsck 1.42.13 (17-May-2015)
e2fsck: Permission non accordée lors de la tentative d'ouverture de /dev/lubuntu-vg/root
Vous devez avoir un accès r/w au système de fichiers ou être root
sapin@sapin-MS-7680:~/Bureau$ sudo e2fsck -b 32768 /dev/lubuntu-vg/root
e2fsck 1.42.13 (17-May-2015)
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/lubuntu-vg/root

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

sapin@sapin-MS-7680:~/Bureau$ sudo e2fsck -b 8193 /dev/lubuntu-vg/root
e2fsck 1.42.13 (17-May-2015)
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/lubuntu-vg/root

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

J'ai l'impression que ça bloque... Après ne te prends pas la tête, c'est déjà très sympa d'avoir passé tout ce temps sur mon problème.

kamaris

Re : Récupération de données sur disque crypté

T'inquiète, pas de problème, et puis on va bien finir par y arriver (enfin peut-être )
Fais voir ce que donne

sudo mke2fs -n /dev/lubuntu-vg/root

(Les numéros 8193 et 32768 n'étaient que des exemples en fait, j'ai cru que c'était des propositions intelligentes… )

Dernière modification par kamaris (Le 16/04/2020, à 22:17)

Sapin64

Re : Récupération de données sur disque crypté

sapin@sapin-MS-7680:~/Bureau$ sudo mke2fs -n /dev/lubuntu-vg/root
mke2fs 1.42.13 (17-May-2015)
En train de créer un système de fichiers avec 243743744 4k blocs et 60940288 i-noeuds.
UUID de système de fichiers=88c4d1a6-82b2-431c-83ac-25f2e34ab53f
Superblocs de secours stockés sur les blocs : 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848

kamaris

Re : Récupération de données sur disque crypté

Bon, alors

sudo e2fsck -b 98304 /dev/lubuntu-vg/root

Ou bien avec d'autres numéros de la liste ci-dessus, si ça ne marche pas.

Sapin64

Re : Récupération de données sur disque crypté

Bon j'ai essayé avec tous les numéros de la liste et j'ai à chaque fois le même message :

sapin@sapin-MS-7680:~/Bureau$ sudo e2fsck -b 102400000 /dev/lubuntu-vg/root
e2fsck 1.42.13 (17-May-2015)
e2fsck: Argument invalide lors de la tentative d'ouverture de /dev/lubuntu-vg/root

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

kamaris

Re : Récupération de données sur disque crypté

Bon, là tout de suite je n'ai plus d'idée.
J'essaierai de voir d'autres recherches, mais peut-être pas ce soir : si je trouve un truc, je te fais signe.

Sapin64

Re : Récupération de données sur disque crypté

Pas de souci. Encore merci.

kamaris

Re : Récupération de données sur disque crypté

Je doute de trouver grand chose de plus en fait, ou alors ce serait des expérimentations que je ne ferais que pour moi-même, et clavier en main.
Par contre, au cas où : as-tu essayé une vérification du système de fichiers dans gparted, ou autre logiciel de partitionnement graphique ?
Peut-être sortira-t-il de son chapeau une commande adaptée, et tu pourras probablement en avoir les logs le cas échéant (dans gparted en tout cas, c'est sûr).

Sapin64

Re : Récupération de données sur disque crypté

Je doute de trouver grand chose de plus en fait, ou alors ce serait des expérimentations que je ne ferais que pour moi-même, et clavier en main.
Par contre, au cas où : as-tu essayé une vérification du système de fichiers dans gparted, ou autre logiciel de partitionnement graphique ?
Peut-être sortira-t-il de son chapeau une commande adaptée, et tu pourras probablement en avoir les logs le cas échéant (dans gparted en tout cas, c'est sûr).

J'ai tenté ça hier soir avec Gparted. Mais la fenêtre s'est figée comme si l'ordi était trop lent et j'ai laissé mouliner comme ça pendant 2h et rien n'est revenu. Les autres applis (Firefox entres autres) tournaient normalement au même moment. Quand le sort s'acharne... A tout hasard ce soir j'essaierai cette manip depuis le live cd mais je n'y crois pas trop. Y a-t-il un autre programme que Gparted pour effectuer cette vérification?

Par contre, j'ai remarqué que lorsque je monte le volume le message d'erreur qui apparaît après avoir rentré la passphrase a changé. Maintenant j'ai :
   Impossible de monter "999 GB chiffrés"
   L’opération a été annulée
Dans Gparted le volume chiffré est bel et bien démonté. Pourtant lorsque je veut le monter via le terminal j'obtiens ceci (au passage, je ne suis très sûr de la commande que je tape...) :

sapin@sapin-MS-7680:~/Bureau$ sudo cryptsetup luksOpen /dev/sdb5 mnt
Saisissez la phrase secrète pour /dev/sdb5 : 
Impossible d'utiliser le périphérique /dev/sdb5 actuellement utilisé (déjà mappé ou monté).

Dernière modification par Sapin64 (Le 18/04/2020, à 13:02)

kamaris

Re : Récupération de données sur disque crypté

J'ai bien peur qu'il y ait un sérieux problème au niveau du système de fichiers, et cela de manière tout à fait indépendante du chiffrement.
Quand tu dis que gparted s'est figé, c'était dès l'ouverture, ou lorsque tu as lancé une vérification du système de fichiers ?
Sinon tu peux essayer avec Gnome-disks, que tu dois avoir d'installé par défaut : https://doc.ubuntu-fr.org/gnome-disk-utility

Concernant la commande que tu as rentrée, elle est inadaptée : il s'agit de la commande pour ouvrir le conteneur luks (situé en /dev/sdb5) qui contient le système de fichiers endommagé.
Or ce conteneur, tu l'as déjà ouvert graphiquement par la procédure suivie dans ton message #3 (en cliquant sur le volume dans ton gestionnaire de fichiers j'imagine, ou sur le bureau).
Donc là, tu lui demandes d'ouvrir un conteneur déjà ouvert, et de lui donner le nom « mnt », alors qu'il a déjà le nom « luks-1d1907e3-993e-4ed3-9cba-1f356baeb52f » (cf. la sortie que tu as donnée en #7).

Pour monter le système de fichiers, la bonne commande est bien

sudo mount /dev/lubuntu-vg/root /mnt

comme on a fait en #23-#24, mais le problème, c'est que le système de fichiers n'est pas montable, car endommagé…

Sapin64

Re : Récupération de données sur disque crypté

Pour ce qui est de Gparted, il s'est figé lorsque j'ai envoyé la vérification.

Du coup j'ai tenté ma chance avec Gnome-Disks. Voila le résultat de l'analyse :

_{Sur Toile Libre ou TDCT'Pix, choisir le lien « Insérer la miniature dans un forum : »}

           

Dernière modification par cqfd93 (Le 19/04/2020, à 09:50)

kamaris

Re : Récupération de données sur disque crypté

Oui mais ça c'est une analyse du disque, pas du système de fichiers qui se trouve sur une des partitions du disques.
Ça doit correspondre peu ou prou à ce que renverrait la commande

sudo smartctl -s on -a /dev/sdb

Du coup ça permet de voir que ton disque est en bon état, mais ce qu'il faudrait c'est faire une vérification du système de fichiers qui se trouve dans le conteneur luks en /dev/sdb5.
Je ne connais pas gnome-disks, mais j'imagine qu'il doit y avoir l'équivalent de la vérification proposée dans gparted (clic droit sur la partition -> vérifier…)

NB : ne pas oublier d'ouvrir le conteneur luks avant, comme déjà fait graphiquement en #3, ou bien par la commande

sudo cryptsetup open /dev/sdb5 luks-1d1907e3-993e-4ed3-9cba-1f356baeb52f

Sapin64

Re : Récupération de données sur disque crypté

Voici les dernières nouvelles.

J'ai finalement pu vérifier le disque avec Gparted depuis le livecd. Ça a mouliné toute la nuit pour finalement me dire qu'il n'y avait pas de système de fichier valide. Du coup je vais apporter le disque chez quelqu'un qui peut peut-être récupérer quelque chose pour pas trop cher. On verra bien...

Je donnerai des nouvelles. Encore merci pour tout!

kamaris

Re : Récupération de données sur disque crypté

Si on en est là (et j'ai bien peur qu'on en soit effectivement là), alors il existe des possibilités pour récupérer les données que tu peux tester toi-même.

@Naziel : si tu suis toujours ce fil, je crois que tu as traité plusieurs fois ce type de questions ?

Nuliel

Re : Récupération de données sur disque crypté

Oui, je suis toujours le fil mais je maîtrise pas trop lorsqu'il y a du chiffrement ni lvm (c'est pour cela que je ne suis pas trop intervenu). A la rigueur si j'ai un accès aux partitions non chiffrées, je peux peut être faire quelque chose, mais je veux bien que tu me dises comment elles sont nommées, parce que j'ai pas compris cela.

---

[ poster un retour de commande ] [ poster une photo ]

kamaris

Re : Récupération de données sur disque crypté

Une fois ouvert le conteneur luks, la partition se trouve en

/dev/lubuntu-vg/root

Nuliel

Re : Récupération de données sur disque crypté

Tout est dans une partition racine?

Tu peux donner

sudo fdisk -l /dev/lubuntu-vg/root

Dernière modification par Nuliel (Le 21/04/2020, à 10:59)

---

[ poster un retour de commande ] [ poster une photo ]

kamaris

Re : Récupération de données sur disque crypté

Oui, l'autre partition c'est du swap :

Donc, après avoir tapé la commande suivante :

sudo vgdisplay -v lubuntu-vg

J'obtiens :

sapin@sapin-MS-7680:~/Bureau$ sudo vgdisplay -v lubuntu-vg
    Using volume group(s) on command line.
  --- Volume group ---
  VG Name               lubuntu-vg
[…]
  --- Logical volume ---
  LV Path                /dev/lubuntu-vg/root
  LV Name                root
  VG Name                lubuntu-vg
  LV UUID                w7bVyf-bmUn-gyNg-BPb9-TJz5-MbSX-CDgdwa
[…]
  --- Logical volume ---
  LV Path                /dev/lubuntu-vg/swap_1
  LV Name                swap_1
  VG Name                lubuntu-vg
  LV UUID                BXY6PW-kPt2-mpFI-k06P-Dd6b-EiT9-jNYZhZ

Nuliel

Re : Récupération de données sur disque crypté

Ok, vu que la partition refuse de se monter, on peut essayer d'accéder aux données avec testdisk

sudo apt install testdisk

sudo testdisk /dev/lubuntu-vg/root

Ensuite tu choisis /dev/lubuntu-vg/root puis intel je pense (pas de partition gpt) puis analyse puis quick search, et tu laisses le terminal ouvert et tu copies le contenu du terminal avec ctrl+shift+c et tu le colles ici dans des balises code afin de voir ce qu'il trouve.

Dernière modification par Nuliel (Le 21/04/2020, à 11:15)

---

[ poster un retour de commande ] [ poster une photo ]