Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
la racine contenant les répertoires boot, tmp et var "en dur" (pas de raccourci)
Les points de montage sont de vrais répertoires, pas des liens symboliques. Ils sont simplement vides (en principe) puisque leur contenu est masqué par le montage.
Il vaut mieux montrer que raconter.
Hors ligne
(UUIDs, magic numbers et hash seeds bidons)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
(remplacer la valeur de label-id par la vraie affichée par fdisk)
Exécuter la commande suivante en mode simulé (en supposant que le disque est encore /dev/sdc) :
et vérifier que le résultat est conforme à ceci (re-vérifie que je n'ai moi-même pas fait d'erreur dans les positions et tailles) :
Si tout est correct, exécuter la commande sans "--no-act".
Deuxième option : corriger la numérotation pour qu'elle reflète l'ordre physique des partitions 5=racine/6=swap/7=home. Mais cela implique de déplacer et reformater la partition de swap, et surtout réinstaller GRUB car le numéro de la partition racine a changé.
Dernière modification par raleur (25-06-2020 09:00:14)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par 31hud (25-06-2020 09:38:33)
Hors ligne
…corriger la numérotation pour qu'elle reflète l'ordre physique des partitions 5=racine/6=swap/7=home. Mais cela implique de déplacer et reformater la partition de swap, …
Si besoin, je corrige l'ordre des partitions en utilisant l'option f des fonctions avancées de la commande fdisk :
… ce qui fait que je n'ai pas à déplacer ou reformater de partition.
Hors ligne
-r, --reorder device
Renumber the partitions, ordering them by their start offset.
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
Hors ligne
j'avais prévu de laisser 16Go pour la réaffectation de cellules défectueuses
Ça ne sert à rien, c'est du gâchis. Le SSD a déjà sa propre réserve interne pour la réallocation des blocs défectueux.
la partition de stockage supplémentaire en dernier (au format NTFS)
Alors pourquoi a-t-elle un identifiant de type FAT16 ? Certes cet identifiant n'est qu'indicatif, mais ça peut prêter à confusion.
Dans mon fichier table, tu peux remplacer type=6 par type=7. (EDIT : correction identifiant type partition)
sdx3 Partition étendue
sdx4 root, home ou swap au choix
sdx5 root, home ou swap au choix
sdx6 root, home ou swap au choix
Les trois partitions Linux sont des partitions logiques dans la partition étendue donc elles ne peuvent avoir des numéros inférieurs à 5, les numéros 1 à 4 étant réservés aux partitions primaires.
La partition de stockage est une partition primaire donc son numéro doit être compris entre 1 et 4.
On pourrait transformer la partition logique racine en partition primaire et reculer le début de la partition étendue derrière elle (nécessitant aussi de reculer la partition de swap pour laisser la place au secteur de partition étendu EBR). Et il faudra réinstaller GRUB à cause du changement de numéro de la racine.
On pourrait aussi transformer la partition de stockage primaire en partition logique et étendre la partition étendue jusqu'à la fin du disque.
Mais on sort un peu du sujet de la simple récupération. Si tu veux faire ça calcule le fichier de table de partition correspondant, je le vérifierai.
Concernant la renumérotation par fdisk, c'est hors sujet, à ne pas faire à la légère et inapplicable dans le cas présent.
Dernière modification par raleur (25-06-2020 10:53:59)
Il vaut mieux montrer que raconter.
Hors ligne
Ça ne sert à rien, c'est du gâchis. Le SSD a déjà sa propre réserve interne pour la réallocation des blocs défectueux.
Sans doute, mais je suis toujours dans cette optique d'avoir une marge de sécurité supplémentaire. Il me semblait avoir lu qu'un SSD pouvait utiliser l'espace non partitionné pour cette réaffectation (c'est que ça écrit vite ces petites bêtes-là !). Et comme il est à base de puces TLC, j'ai tendance à me méfier et à considérer la mémoire comme plus volatile qu'elle n'est. Stupide, mais ça me rassure. 
Alors pourquoi a-t-elle un identifiant de type FAT16 ?
Parce que le processus n'a pas pu aller jusqu'à son terme j'imagine. J'avais sélectionné "Volume simple" (maintenant je sais que ça veut dire partition primaire), format NTFS, formatage rapide.
Les trois partitions Linux sont des partitions logiques dans la partition étendue donc elles ne peuvent avoir des numéros inférieurs à 5, les numéros 1 à 4 étant réservés aux partitions primaires.
La partition de stockage est une partition primaire donc son numéro doit être compris entre 1 et 4.
Je savais qu'on ne pouvait créer que 4 partitions primaires par disque ou 3 primaires et une étendue, mais l'incidence sur le lettrage *NIX m'échappait totalement, merci pour la précision.
On pourrait transformer la partition logique racine en partition primaire et reculer le début de la partition étendue derrière elle (nécessitant aussi de reculer la partition de swap pour laisser la place au secteur de partition étendu EBR). Et il faudra réinstaller GRUB à cause du changement de numéro de la racine.
On pourrait aussi transformer la partition de stockage primaire en partition logique et étendre la partition étendue jusqu'à la fin du disque.
Mais on sort un peu du sujet de la simple récupération. Si tu veux faire ça calcule le fichier de table de partition correspondant, je le vérifierai.
Pour l'instant, je crois que je vais restaurer l'état d'avant-boulette (donc avec la bizarrerie et le risque d'erreurs si je manipule les partitions) et faire une sauvegarde complète du disque, chose que j'aurais dû faire bien avant. Je vais me laisser le temps de la réflexion (et de faire les vérifs et manips correspondantes), il sera toujours temps de rectifier le partitionnement par la suite pour avoir quelque chose de propre et refaire une sauvegarde complète.
Concernant la renumérotation par fdisk, c'est hors sujet, à ne pas faire à la légère et inapplicable dans le cas présent.
De toute façon je ne touche à rien tant que je ne suis pas sûr de ne pas faire de bêtise que je regretterai par la suite.
Hors ligne
Hors ligne
Il me semblait avoir lu qu'un SSD pouvait utiliser l'espace non partitionné pour cette réaffectation
Pas vraiment. C'est plus compliqué que ça.
Un SSD a deux niveaux :
- le niveau logique, les secteurs visibles et utilisables par le système hôte
- le niveau physique, les blocs de mémoire flash interne, non accessibles directement.
Le contrôleur intégré du disque maintient une correspondance entre les deux niveaux. Il y a plus de blocs physiques interne que de blocs logiques visibles, typiquement un SSD de 250 Go utiles a une capacité interne brute de 256 Gio (274 Go) puisque par construction la mémoire flash a des capacités en puissances de 2, comme la RAM. Cela implique qu'à un instant t certains blocs physiques ne correspondent à aucun bloc logique. Il peut s'agir de blocs effacés prêts à être écrits ou de blocs contenant des données périmées qui doivent être effacés avant de pouvoir recevoir de nouvelles données. Les blocs effacés non alloués peuvent serveur en interne pour la réallocation de blocs défecteux ou le nivellement de l'usure. La correspondance est dynamique : typiquement, un bloc logique est associé à un autre bloc physique (préalablement effacé) quand ses données sont modifiées car c'est plus rapide que d'effacer le bloc avant de réécrire les données, et ça permet le nivellement de l'usure causée par l'écriture.
le fichier table, je le place où ?
N'importe où.
Et est-ce que je dois spécifier son chemin complet dans la commande sfdisk ?
Seulement s'il n'est pas dans le répertoire courant.
Il vaut mieux montrer que raconter.
Hors ligne
Pour sdb7 / home, tu indiques un début au secteur 205479936 pour une taille de 87693312 secteurs, soit 2048 de moins. La partition swap se termine au secteur 205477887 pour moi.
L'autre différence que je constate, c'est celle de 2 secteurs au début de sdb6 / root : début à 156651520 contre 156651518 pour moi (taille 41015296 vs 41015298) alors que la première méthode était censée ne pas corriger l'anomalie d'alignement. Ça n'aura pas d'impact sur le démarrage ?
Et la 3ème partition NTFS (stockage) est corrompue à mon sens, on peut l'omettre si ça n'a pas de conséquences non plus.
Dernière modification par 31hud (26-06-2020 08:20:57)
Hors ligne
J'ai refait des calculs basés sur ce que donne Gparted dans "Informations" (message #17 page 1) et je ne trouve pas les mêmes secteurs de début pour root et home
Gparted n'affiche pas d'informations sur ces partitions manquantes (il en est incapable) mais sur les espaces non alloués à l'intérieur de la partition étendue. "Non alloué" ne signifie pas "utilisable". Un certain nombre de secteurs dans la partition étendue sont réservés pour contenir des tables de partition étendue imbriquées (EBR). Avant chaque partition logique il doit y avoir une table de partition étendue, donc au moins un secteur réservé qui ne fait pas partie de la partition logique.
Pour sdb7 / home, tu indiques un début au secteur 205479936 pour une taille de 87693312 secteurs, soit 2048 de moins. La partition swap se termine au secteur 205477887 pour moi.
Pour moi aussi. Or il faut un secteur EBR entre les deux, donc la partition home ne peut pas commencer juste après la partition de swap.
L'autre différence que je constate, c'est celle de 2 secteurs au début de sdb6 / root : début à 156651520 contre 156651518 pour moi (taille 41015296 vs 41015298)
156651518 est le début de la partition étendue, qui contient obligatoirement un EBR. Donc une partition logique ne peut pas commencer à cette position.
alors que la première méthode était censée ne pas corriger l'anomalie d'alignement
Il n'y a pas de défaut d'alignement des partitions logiques : leurs positions de début et leurs tailles sont toutes des multiples de 2048. Ce ne serait pas le cas avec tes positions de début.
Et la 3ème partition NTFS (stockage) est corrompue à mon sens, on peut l'omettre si ça n'a pas de conséquences non plus.
Qu'entends-tu par "corrompue" ? Si elle n'est pas formatée, il suffira de le faire.
Il vaut mieux montrer que raconter.
Hors ligne
Je te fais grâce de la situation antérieure, c'est identique à ce que donnait fdisk page précédente. J'ai renommé en /dev/sdb pour que la machine d'origine retrouve ses moutons. L'identifiant de disque a bien été renseigné dans le fichier table (je ne le reporte pas ici).
Comme c'est identique au tableau que tu as posté, j'ai repassé la même commande sans le --no-act, seule la dernière ligne change :
Y'a plus qu'à tester.
Dernière modification par 31hud (27-06-2020 16:16:12)
Hors ligne
Hors ligne
Dernière modification par raleur (27-06-2020 16:52:10)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par 31hud (27-06-2020 16:58:07)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
La sauvegarde a échoué : j'ai fait deux tentatives, l'une avec DiskImage de Roadkil présent sur le Hiren's Boot CD et l'autre avec Clonezilla qui se plaint que sdb6 et sdb7 contiennent des erreurs. Du coup j'hésite à me lancer dans cette rectification des partitions, je voulais au moins avoir une image complète du disque pour pouvoir revenir en arrière en cas d'échec. Je vais surtout sauvegarder mes données personnelles tant que j'ai un système fonctionnel et aviser ensuite.
Hors ligne
Clonezilla qui se plaint que sdb6 et sdb7 contiennent des erreurs
Quelles erreurs ?
je voulais au moins avoir une image complète du disque pour pouvoir revenir en arrière en cas d'échec.
Pas besoin de logiciels particuliers pour ça. Il suffit de dd et d'un disque de capacité égale ou supérieure.
Par contre si les erreurs sont des secteurs défectueux, c'est plus délicat.
Il vaut mieux montrer que raconter.
Hors ligne
Je pense que les tailles et offsets sont exprimés en octets.
Pour Clonezilla, voici ce que j'ai fait :
Que voulez-vous faire ? –> device <–> image
image à créer sur disque 2To (dans un répertoire)
sélection du périphérique source : SSD 250 Go
mode débutant
ne pas vérifier / réparer le système de fichiers
vérifier l'image disque
Je ne lui demande pas de réparer le système de fichiers pour ne rien modifier au disque, je préfère une méthode manuelle avec quelqu'un qui sait ce qu'il fait plutôt que de l'automatique.
Voici ce qu'il retourne :
partitions trouvées : sdb1 sdb2 sdb3 sdb5 sdb6 sdb7
data partitions to be saved : sdb1 sdb2 sdb6 sdb7
swap partition to be saved : sdb5
lancement de partclone v0.2.49 avec pigz - découpage de l'image chaque 2000 MB
Block size 4096 Byte
sdb1 total 88349 blocs used 73096
sdb2 total 19492869 blocs used 9239537
Pour sdb6, j'ai un message en rouge : Un problème a été rencontré !!!
échec après 2 secondes (étape Reading Super Block)
Completed: 60,33%extfsclone.c: bitmap error at 125 group.
Partclone fail, please check /var/log/partclone.log !
Checking the disk space...
(standard_in) 1: syntax error
idem avec sdb7,
Completed: 1.00%extfsclone.c: bitmap error at 25 group.
Ensuite il passe à la vérification des partitions Windows qui n'ont pas échoué et en rouge :
"Cette partition est défectueuse dans l'image: sdb6"
idem pour sdb7
"Des partitions endommagées ont été trouvées, ou bien certaines ne sont pas vérifiables dans cette image: *nom_image_disque*"
Je ne suis pas trop chaud pour utiliser dd parce que j'aurais trop vite fait de faire des dégâts avec une mauvaise commande ou une faute de frappe. Il est capable d'écrire dans un répertoire ? Parce que je n'ai pas vraiment de disque libre de taille identique ou supérieure (le 2To a une erreur CRC au SMART concernant 17 blocs mais pas de secteur défectueux ni ré-alloué ni pending).
Dernière modification par 31hud (29-06-2020 12:36:03)
Hors ligne
Pour DiskImage v1.6 c'est vite vu : il retourne juste "Failure: Image Creation Failed". Dans le fichier img créé, j'ai :
Il se plante manifestement sur les tailles et positions des partitions logiques et n'en voit pas une (partition racine). Peut-être à cause de la structure particulière du contenu de la partition étendue.
Completed: 60,33%extfsclone.c: bitmap error at 125 group.
Partclone fail, please check /var/log/partclone.log !
Que dit le log ?
Les partitions sont bien démontées ? Tu as essayé fsck dessus ?
Dernière modification par raleur (29-06-2020 20:57:41)
Il vaut mieux montrer que raconter.
Hors ligne
Que dit le log ?
Je n'ai pas pensé à le relever / consulter, je ne sais pas comment faire. Il va falloir que je recommence je pense mais je ne pourrai pas avant la fin de semaine. C'est sous forme de LiveCD (qui s'éjecte une fois que l'image système est chargée en mémoire), donc je me doute que le fichier n'est disponible que temporairement en RAM.
Les partitions sont bien démontées ?
Il me semble que Clonezilla le fait entre le moment où il détecte les partitions existantes et où il lance les outils de sauvegarde (partclone dans le cas présent) mais je n'irais pas le jurer.
Tu as essayé fsck dessus ?
C'est le genre de choses qui ne vient pas spontanément à l'esprit du +/- débutant que je suis : si ça remarche, ne touche à rien. Donc non, je n'ai pas lancé de fsck sur le SSD (Windows a lancé un CHKDSK à son premier redémarrage, ça semble s'être bien déroulé).
Hors ligne
Hors ligne