Re: [Toulibre] [DEBIAN9] Pbl de HDD/LUKS/Partition corrompue
Certes :) # ntfsfix /dev/mapper/c1 Mounting volume... OK Processing of $MFT and $MFTMirr completed successfully. Checking the alternate boot sector... OK NTFS volume version is 3.1. NTFS partition /dev/mapper/c1 was processed successfully. Sans plus de succès ... Le 31/05/2022 à 12:40, Sylvain via Toulouse-ll a écrit : Au temps pour moi, fsck.ntfs n'existe pas... /dev/sda1 est la partition encryptée, donc normal qu'il ne trouve pas de bloc signature NTFS. Il me semble que la commande devrait être : ntfsfix /dev/mapper/c1 (ou l'endroit où tu as décrypté ta partition) -Sylvain Le 2022-05-30 18:03, Joyce MARKOLL via Toulouse-ll a écrit : On Mon, 30 May 2022 17:56:17 +0200 "toulibre.org--- via Toulouse-ll" wrote: Voici l'injure # ntfsfix /dev/sda1 Mounting volume... NTFS signature is missing. FAILED Attempting to correct errors... NTFS signature is missing. FAILED Failed to startup volume: Invalid argument NTFS signature is missing. Trying the alternate boot sector Unrecoverable error Volume is corrupt. You should run chkdsk. Je dirais, lancer smart (ou gsmartcontrol) depuis un live, et regarder ce que ça dit pour ce disque (par exemple depuis Parted Magic : https://partedmagic.com) et selon le résultat, changer de support, ou réinstaller à neuf. Joyce ___ Toulouse-ll mailing list Toulouse-ll@toulibre.org http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll ___ Toulouse-ll mailing list Toulouse-ll@toulibre.org http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll
Re: [Toulibre] [DEBIAN9] Pbl de HDD/LUKS/Partition corrompue
Au temps pour moi, fsck.ntfs n'existe pas... /dev/sda1 est la partition encryptée, donc normal qu'il ne trouve pas de bloc signature NTFS. Il me semble que la commande devrait être : ntfsfix /dev/mapper/c1 (ou l'endroit où tu as décrypté ta partition) -Sylvain Le 2022-05-30 18:03, Joyce MARKOLL via Toulouse-ll a écrit : On Mon, 30 May 2022 17:56:17 +0200 "toulibre.org--- via Toulouse-ll" wrote: Voici l'injure # ntfsfix /dev/sda1 Mounting volume... NTFS signature is missing. FAILED Attempting to correct errors... NTFS signature is missing. FAILED Failed to startup volume: Invalid argument NTFS signature is missing. Trying the alternate boot sector Unrecoverable error Volume is corrupt. You should run chkdsk. Je dirais, lancer smart (ou gsmartcontrol) depuis un live, et regarder ce que ça dit pour ce disque (par exemple depuis Parted Magic : https://partedmagic.com) et selon le résultat, changer de support, ou réinstaller à neuf. Joyce ___ Toulouse-ll mailing list Toulouse-ll@toulibre.org http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll
Re: [Toulibre] [DEBIAN9] Pbl de HDD/LUKS/Partition corrompue
On Mon, 30 May 2022 17:56:17 +0200 "toulibre.org--- via Toulouse-ll" wrote: > Voici l'injure > > # ntfsfix /dev/sda1 > Mounting volume... NTFS signature is missing. > FAILED > Attempting to correct errors... NTFS signature is missing. > FAILED > Failed to startup volume: Invalid argument > NTFS signature is missing. > Trying the alternate boot sector > Unrecoverable error > Volume is corrupt. You should run chkdsk. Je dirais, lancer smart (ou gsmartcontrol) depuis un live, et regarder ce que ça dit pour ce disque (par exemple depuis Parted Magic : https://partedmagic.com) et selon le résultat, changer de support, ou réinstaller à neuf. Joyce -- Orditux Informatique https://orditux.org https://orditux.org/aol/ https://orditux.org/floss ___ Toulouse-ll mailing list Toulouse-ll@toulibre.org http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll
Re: [Toulibre] [DEBIAN9] Pbl de HDD/LUKS/Partition corrompue
Voici l'injure # ntfsfix /dev/sda1 Mounting volume... NTFS signature is missing. FAILED Attempting to correct errors... NTFS signature is missing. FAILED Failed to startup volume: Invalid argument NTFS signature is missing. Trying the alternate boot sector Unrecoverable error Volume is corrupt. You should run chkdsk. Le 30/05/2022 à 15:14, toulibre.org--- via Toulouse-ll a écrit : Bonjour Sylvain, En effet, NTFS ce n'est pas top sous Linux... J'avais, à l'époque, pris cette option afin de pouvoir accéder au disque depuis un PC Win 7 mieux dimensionné qu'un Rasp pour faire ma première copie de tout ce que je voulais déplacer sur les HDD (et ce fut déjà bien long ...). J'avais utilisé LibreCrypt à l'époque pour déchiffrer le HDD en LUKS depuis Win7. Le truc est que maintenant je n'y parviens plus et que le projet est mort, et que je ne peux donc lancer un chkdsk depuis mon unique poste en Win toujours 7. Il semble qu'il y ait moyen de ruser depuis un Win 10 avec wsl2 ... mais je n'ai pas de Win 10 ... et n'en veux pas. Bref, je n'ai pas réussi a trouver le package Debian 9 qui installe fsck.ntfs , ni même celui sous un Debian 11 à partir du quel j'ai tenté les mêmes manip. J'ai également depuis, tenté un ntfsfix qui m'a injurié en indiquant de faire un chkdsk. Je ne suis pas spécialiste des systèmes de fichiers, mais j'observe que mes soucis ne sont présents que sur un répertoire en particulier et son contenu. J'ai donc crée un nouveau répertoire et mis à jour les chemins pointés par mes scripts de sauvegarde. Ca fonctionne bien mais je crains que le F.S. me pète à la face un jour... -Nico Le 30/05/2022 à 09:56, Sylvain via Toulouse-ll a écrit : Salut (faiscommechez)toi, As-tu essayé fsck sur la partition /dev/mapper/c1 ? (décryptée et non montée) Tu peux essayer fsck.ntfs et ntfsfix (à installer peut-être). Je trouve un peu risqué d'avoir fait une partition NTFS sur un NAS Debian. Si ce doit être refait, préfère un type Linux (ext4 ou autres), et cela marche aussi bien avec Samba. -Sylvain Le 2022-05-29 12:37, toulibre.org--- via Toulouse-ll a écrit : Bonjour, Je vous sollicite au sujet d'un soucis de corruption de système de fichier. 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... Pas de soucis sur le répertoire équivalent sur le HDD2. Je m'en suis aperçu ou bout de plusieurs jours,car le script qui écrit quotidiennement (depuis une autre machine) dans le partage samba qui pointe vers ce répertoire du HDD1, sortait en erreur. 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 : 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 ... 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 .. 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 : J'essaye sur le périphérique : # fsck /dev/sdb 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
Re: [Toulibre] [DEBIAN9] Pbl de HDD/LUKS/Partition corrompue
Bonjour Joyce, Il me semble avoir répondu à certaines de tes questions dans ma réponse à Sylvain. Les 6 premières lignes concernent la première capture d'écran : "impossible d'accéder ..." Le résultat du lsbk liste les 2 HDD : lsblk -o KNAME,TYPE,SIZE KNAME TYPESIZE sda disk1,8T sda1 part1,8T dm-0 crypt 1,8T sdb disk1,8T sdb1 part1,8T dm-1 crypt 1,8T mmcblk0 disk7,4G mmcblk0p1 part 113,3M mmcblk0p2 part 1K mmcblk0p3 part 32M mmcblk0p5 part 60M mmcblk0p6 part7,2G Nico Le 30/05/2022 à 12:22, Joyce MARKOLL via Toulouse-ll a écrit : Bonjour, On Mon, 30 May 2022 09:56:47 +0200 Sylvain via Toulouse-ll 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 TYPESIZE sda disk1,8T sda1 part1,8T dm-0 crypt 1,8T sdb disk1,8T sdb1 part1,8T mmcblk0 disk7,4G mmcblk0p1 part 113,3M mmcblk0p2 part 1K mmcblk0p3 part 32M mmcblk0p5 part 60M mmcblk0p6 part7,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" 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
Re: [Toulibre] [DEBIAN9] Pbl de HDD/LUKS/Partition corrompue
Bonjour Sylvain, En effet, NTFS ce n'est pas top sous Linux... J'avais, à l'époque, pris cette option afin de pouvoir accéder au disque depuis un PC Win 7 mieux dimensionné qu'un Rasp pour faire ma première copie de tout ce que je voulais déplacer sur les HDD (et ce fut déjà bien long ...). J'avais utilisé LibreCrypt à l'époque pour déchiffrer le HDD en LUKS depuis Win7. Le truc est que maintenant je n'y parviens plus et que le projet est mort, et que je ne peux donc lancer un chkdsk depuis mon unique poste en Win toujours 7. Il semble qu'il y ait moyen de ruser depuis un Win 10 avec wsl2 ... mais je n'ai pas de Win 10 ... et n'en veux pas. Bref, je n'ai pas réussi a trouver le package Debian 9 qui installe fsck.ntfs , ni même celui sous un Debian 11 à partir du quel j'ai tenté les mêmes manip. J'ai également depuis, tenté un ntfsfix qui m'a injurié en indiquant de faire un chkdsk. Je ne suis pas spécialiste des systèmes de fichiers, mais j'observe que mes soucis ne sont présents que sur un répertoire en particulier et son contenu. J'ai donc crée un nouveau répertoire et mis à jour les chemins pointés par mes scripts de sauvegarde. Ca fonctionne bien mais je crains que le F.S. me pète à la face un jour... -Nico Le 30/05/2022 à 09:56, Sylvain via Toulouse-ll a écrit : > Salut (faiscommechez)toi, > > As-tu essayé fsck sur la partition /dev/mapper/c1 ? (décryptée et non > montée) > > Tu peux essayer fsck.ntfs et ntfsfix (à installer peut-être). > > Je trouve un peu risqué d'avoir fait une partition NTFS sur un NAS > Debian. > Si ce doit être refait, préfère un type Linux (ext4 ou autres), et > cela marche aussi bien avec Samba. > > -Sylvain > > > Le 2022-05-29 12:37, toulibre.org--- via Toulouse-ll a écrit : >> Bonjour, >> >> Je vous sollicite au sujet d'un soucis de corruption de système de >> fichier. >> >> 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... >> >> Pas de soucis sur le répertoire équivalent sur le HDD2. >> >> Je m'en suis aperçu ou bout de plusieurs jours,car le script qui >> écrit quotidiennement (depuis une autre machine) dans le partage >> samba qui pointe vers ce répertoire du HDD1, sortait en erreur. >> >> 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 : >> >> 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 ... >> >> 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 .. >> >> 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 : >> >> J'essaye sur le périphérique : >> >>> # fsck /dev/sdb >>> 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 >>> 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
Re: [Toulibre] [DEBIAN9] Pbl de HDD/LUKS/Partition corrompue
Bonjour, On Mon, 30 May 2022 09:56:47 +0200 Sylvain via Toulouse-ll 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 TYPESIZE > > sda disk1,8T > > sda1 part1,8T > > dm-0 crypt 1,8T > > sdb disk1,8T > > sdb1 part1,8T > > mmcblk0 disk7,4G > > mmcblk0p1 part 113,3M > > mmcblk0p2 part 1K > > mmcblk0p3 part 32M > > mmcblk0p5 part 60M > > mmcblk0p6 part7,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" > >> 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 > > 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 > >
Re: [Toulibre] [DEBIAN9] Pbl de HDD/LUKS/Partition corrompue
Salut (faiscommechez)toi, As-tu essayé fsck sur la partition /dev/mapper/c1 ? (décryptée et non montée) Tu peux essayer fsck.ntfs et ntfsfix (à installer peut-être). Je trouve un peu risqué d'avoir fait une partition NTFS sur un NAS Debian. Si ce doit être refait, préfère un type Linux (ext4 ou autres), et cela marche aussi bien avec Samba. -Sylvain Le 2022-05-29 12:37, toulibre.org--- via Toulouse-ll a écrit : Bonjour, Je vous sollicite au sujet d'un soucis de corruption de système de fichier. 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 TYPESIZE sda disk1,8T sda1 part1,8T dm-0 crypt 1,8T sdb disk1,8T sdb1 part1,8T mmcblk0 disk7,4G mmcblk0p1 part 113,3M mmcblk0p2 part 1K mmcblk0p3 part 32M mmcblk0p5 part 60M mmcblk0p6 part7,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... Pas de soucis sur le répertoire équivalent sur le HDD2. Je m'en suis aperçu ou bout de plusieurs jours,car le script qui écrit quotidiennement (depuis une autre machine) dans le partage samba qui pointe vers ce répertoire du HDD1, sortait en erreur. 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 : 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 ... 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 .. 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 : J'essaye sur le périphérique : # fsck /dev/sdb 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 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 Ce qui ne me surprends qu'à moitié puisque le périphérique est chiffré. 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 ? ___ Toulouse-ll mailing list Toulouse-ll@toulibre.org http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll ___ Toulouse-ll mailing list Toulouse-ll@toulibre.org http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll
