[Toulibre] [DEBIAN9] Pbl de HDD/LUKS/Partition corrompue

Lun 30 Mai 12:22:44 CEST 2022

Bonjour,

On Mon, 30 May 2022 09:56:47 +0200
Sylvain via Toulouse-ll <toulouse-ll at toulibre.org> wrote:

> Tu peux essayer fsck.ntfs et ntfsfix (à installer peut-être).

sur des partitions contenant un system Ext* ? "Faiscommechezmoi" a dit:

"Sous une vielle Debian 9 (stretch) qui me sers de NAS"

> Je trouve un peu risqué d'avoir fait une partition NTFS sur un NAS 
> Debian.

Il y une partitions NTFS ? Il a juste parlé de partage Samba et d'accès depuis Windows
non ?

> Le 2022-05-29 12:37, toulibre.org--- via Toulouse-ll a écrit :

> > Sous une vielle Debian 9 (stretch) qui me sers de NAS, je dispose de 2
> > HDD identiques branchés en USB.

> > Ces HDD sont chiffrés en LUKS. Une seule partition par HDD.
> > Je n'utilise pas de LVM.
> >     lsblk -o KNAME,TYPE,SIZE
> > KNAME     TYPE    SIZE
> > sda       disk    1,8T
> > sda1      part    1,8T
> > dm-0      crypt   1,8T
> > sdb       disk    1,8T
> > sdb1      part    1,8T
> > mmcblk0   disk    7,4G
> > mmcblk0p1 part  113,3M
> > mmcblk0p2 part      1K
> > mmcblk0p3 part     32M
> > mmcblk0p5 part     60M
> > mmcblk0p6 part    7,2G
> > 
> > Une arborescence du HDD1 (sda) est partagée sur mon LAN avec Samba.
> > le HDD1 est rsync régulièrement vers le HDD2 (sdb).
> > 
> > Sur le HDD1, j'ai provoqué une corruption en bougeant les câbles
> > trop brusquement.
> > 
> > Le résultat donne ceci :
> > 
> > Les 6 premières lignes n'étaient pas d'origine. Elles apparaissent
> > car j'ai d'abord tenté de supprimer le répertoire, sans succès...

quelles 6 premières lignes ?

> > Pas de soucis sur le répertoire équivalent sur le HDD2.

À quoi ressemble le retour de lsblk sur celui-là par comparaison ?

> > Après avoir rebooté (les HDD1&2 ne sont pas déchiffrés ni montés
> > lors du boot), j'ai tenté de réparer comme suit :
> >     1- déchiffrage du HDD1
> >     cryptsetup luksOpen /dev/sda1 c1
> >     Saisissez la phrase secrète pour /dev/sda1 :
> >     => ok
> > 
> >     2- déchiffrage du HDD2
> >     cryptsetup luksOpen /dev/sdb1 c2
> >     Saisissez la phrase secrète pour /dev/sdb1 :
> >     => ok
> > 
> >     3- Vérification avec un fdisk :
> > 
> >> 
> >   4- tentative de montage du volume NTFS :

Ah oui, un volume NTFS : je croyais que c'était une Debian Stretch ?

> >     Mais si j'utilise le script d'outillage que je m'étais fait pour
> > automatiser les arrets/démarrages de la "fonction" NAS de ce serveur;
> > cela fonctionne bien; alors que la commande contenue dans le script
> > est rigoureusement la même ...

Cette partie ↑ est obscure. 

> >     Bref, une fois le volume monté et Samba démarré, je navigue
> > bien dans le partage samba, depuis un poste en windows.
> >     En revanche, j'ai des soucis d'écriture ..

Dans ce cas je ne vois qu'une chose à faire tant que c'est possible : faire une
sauvegarde générale vers un support de stockage sain.

> >     5- Je stoppe Samba et démonte les volumes et ferme les volumes
> > LUKS :
> >      /etc/init.d/samba stop
> >     umount /media/USBHDD1/shares
> >     umount /media/USBHDD2/shares
> >     cryptsetup luksClose c1
> >     cryptsetup luksClose c2

> >     6- Je tente un fsck sur .. justement ... je ne sais plus trop car
> > mes souvenirs sur la gestion des devices et la terminologie associée,
> > sont assez diffus :

aïe. :)

> >         J'essaye sur le périphérique :
> > 
> >> # fsck /dev/sdb

Non. man fsck dit: 
"fsck - check and repair a Linux filesystem"

fsck vérifie et répare des systèmes de fichiers Linux.
Donc si sdb contient des partitions ext2/3 ou ext4 ça marchera, à condition d'invoquer
fsck sur des volumes et non sur le disque.

Si c'est du ntfs, il existe le paquet ntfs-3g qui fournit ntfsfix, lequel peut aider à
réparer des fs ntfs.

(Essaie "ntfs<tab>"

> >> fsck from util-linux 2.20.1
> >> e2fsck 1.42.5 (29-Jul-2012)
> >> 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/sdb
> >> 
> >> Le superbloc n'a pu être lu ou ne contient pas un système de
> >> fichiers

sdb représente le disque complet. (Tu peux regarder le retour de "sudo fdisk -l /dev/sdb")

> >> ext2 correct. Si le périphérique est valide et qu'il contient
> >> réellement
> >> un système de fichiers ext2 (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>
> >      Ce qui ne me surprends qu'à moitié puisque le périphérique
> > est chiffré.

Non. On invoque fsck sur un système de fichiers. (insister sur "système de
fichiers"). sdb contient des volumes, des partitions, pas un système de fichiers.

> >     Si je déchiffre le périphérique et essaye la partition:
> > 
> >> fsck /dev/sda1
> >> fsck from util-linux 2.20.1
> >> fsck: fsck.crypto_LUKS: not found
> >> fsck: error 2 while executing fsck.crypto_LUKS for /dev/sda1
> > 
> > Auriez vous une idée ?

en regardant sur le web ce que ça dit à propos d'erreurs fsck.crypto_LUKS il y a pas mal
de messages. Par exemple:
https://unix.stackexchange.com/questions/646569/superblock-problem-on-a-crypto-luks-drive

“The filesystem on your root logical volume is corrupted, not the LUKS device
itself. /dev/sda5 is partition that holds the LUKS/dm-crypt device, with encryption (and
also LVM which you are also using), the storage works in layers, you can't run fsck on
the LUKS (encryption) layer, you must run it on the LVM logical volume layer
-- /dev/mapper/trisquel--vg-root in your case.”

Cela rejoint ce que te dit Sylvain:

"As-tu essayé fsck sur la partition /dev/mapper/c1 ? (décryptée et non 
montée)"

Par contre mon "apt-file update && apt-file search" ne trouve pas "fsck.ntfs". 

En conclusion, je commencerais par une sauvegarde complète (ou pas, si le disque miroir
ne rencontre pas de problème), et à déterminer quel type de systèmes de fichiers se
trouve(nt) sur les volumes /dev/mapper avant de choisir un outil à invoquer dessus.

Joyce

-- 
Orditux Informatique
https://orditux.org
https://orditux.org/aol/
https://orditux.org/floss