logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#26 24-06-2020 09:13:54

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

31hud a écrit :

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

#27 24-06-2020 18:56:57

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Oui, je me suis sûrement mal exprimé : ce que je voulais dire, c'est que j'avais un doute quant au fait que tmp et var aient été des partitions séparées à l'installation mais il semble bien qu'il n'y ait que root, home et swap-linux. Absolument pas grave si la partition swap perd 2 secteurs (elle est vide de toute manière de ce que j'ai compris), et j'utilise vm.swappiness=1 au cas où ça importerait.

Voici les retours de dumpe2fs avec le -h (bien moins longs en effet) :

dumpe2fs -h /dev/sdc6


dumpe2fs 1.43.4 (31-Jan-2017)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          4dcc098d-0e0a-4401-bbd1-0b472c815b39
Filesystem magic number:  0xAB12
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1283632
Block count:              5126912
Reserved block count:     256345
Free blocks:              3497555
Free inodes:              1091245
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8176
Inode blocks per group:   511
Flex block group size:    16
Filesystem created:       Fri Nov 29 09:28:54 2019
Last mount time:          Fri May 29 16:49:15 2020
Last write time:          Fri May 29 18:49:15 2020
Mount count:              147
Maximum mount count:      -1
Last checked:             Fri Nov 29 09:28:54 2019
Check interval:           0 (<none>)
Lifetime writes:          36 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      5a119dac-4210-7492-cbdf-6357f58aacec
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x99155034
Fonctionalités du journal :  journal_incompat_revoke journal_64bit journal_checksum_v3
Taille du journal :         128M
Longueur du journal :      32768
Séquence du journal :      0x0002d51f
Début du journal :         0
Type de csum du journal:   crc32c
Csum du journal:          0x81267454

dumpe2fs -h /dev/sdc7


dumpe2fs 1.43.4 (31-Jan-2017)
Filesystem volume name:   <none>
Last mounted on:          /home
Filesystem UUID:          f77cfb28-8e78-471b-8eae-75bb16b7f4c7
Filesystem magic number:  0xBC23
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2744320
Block count:              10961664
Reserved block count:     548083
Free blocks:              9830457
Free inodes:              2704058
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Nov 29 09:28:55 2019
Last mount time:          Fri May 29 16:49:16 2020
Last write time:          Fri May 29 16:50:43 2020
Mount count:              147
Maximum mount count:      -1
Last checked:             Fri Nov 29 09:28:55 2019
Check interval:           0 (<none>)
Lifetime writes:          67 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      f250b9f1-5c04-b12a-15ea-bffbd1df7440
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x841af063
Fonctionalités du journal :  journal_incompat_revoke journal_64bit journal_checksum_v3
Taille du journal :         256M
Longueur du journal :      65536
Séquence du journal :      0x000582bc
Début du journal :         0
Type de csum du journal:   crc32c
Csum du journal:          0xc7006e03

(UUIDs, magic numbers et hash seeds bidons)

Hors ligne

#28 25-06-2020 07:31:37

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Les tailles des systèmes de fichiers correspondent bien aux tailles des partitions identifiées par testdisk que j'ai reprises dans mon message #18.
Peux-tu poster le contenu du fichier /etc/fstab de la partition racine ?

Il vaut mieux montrer que raconter.

Hors ligne

#29 25-06-2020 07:49:43

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Bonjour raleur,

Le voici :

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system>                           <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb6 during installation
UUID=4dcc098d-0e0a-4401-bbd1-0b472c815b39 /               ext4    errors=remount-ro 0       1
# /home was on /dev/sdb7 during installation
UUID=f77cfb28-8e78-471b-8eae-75bb16b7f4c7 /home           ext4    defaults        0       2
# swap was on /dev/sdb5 during installation
UUID=bcb69c1c-3f0f-4120-bc1a-9ba1f99be96e none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Hors ligne

#30 25-06-2020 08:54:53

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Je comprends un peu mieux la structure initiale des partitions logiques, mais pas complètement comment cela a été créé.
Cela confirme aussi la numérotation des partitions logiques qui ne sont pas dans l'ordre de leurs positions physiques.
Il y a deux possibilités.

Première option : restaurer la table de partition comme à l'origine, avec les mêmes numérotations et positions pour le swap.
Avantage : il n'y aura aucune autre modification à faire.
Inconvénient : la structure des partitions restera "bizarre" et peut causer des problèmes avec certains programmes de manipulation des partitions.

Créer un fichier "table" contenant :

label: dos
label-id: 0xabcd1234
device: /dev/sdc
unit: sectors

/dev/sdc1 : start=          63, size=       706797, type=7, bootable
/dev/sdc2 : start=      706860, size=    155942955, type=7
/dev/sdc3 : start=   156651518, size=    136521730, type=5
/dev/sdc4 : start=   293173248, size=    162883584, type=6
/dev/sdc5 : start=   197666816, size=      7811072, type=82
/dev/sdc6 : start=   156651520, size=     41015296, type=83
/dev/sdc7 : start=   205479936, size=     87693312, type=83
 


(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) :

sfdisk --no-act --no-reread --no-tell-kernel --wipe-partitions never /dev/sdc < table


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) :

Nouvelle situation :
Type d'étiquette de disque : dos
Identifiant de disque : 0xabcd1234

Périphérique Amorçage     Début       Fin  Secteurs Taille Id Type
sdc1         *               63    706859    706797 345,1M  7 HPFS/NTFS/exFAT
sdc2                     706860 156649814 155942955  74,4G  7 HPFS/NTFS/exFAT
sdc3                  156651518 293173247 136521730  65,1G  5 Étendue
sdc4                  293173248 456056831 162883584  77,7G  6 FAT16
sdc5                  197666816 205477887   7811072   3,7G 82 partition d'échange Linux / Solaris
sdc6                  156651520 197666815  41015296  19,6G 83 Linux
sdc7                  205479936 293173247  87693312  41,8G 83 Linux


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

#31 25-06-2020 09:24:21

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Au moment de l'installation, je passe toujours une vingtaine de minutes à réfléchir à la taille des partitions pour éviter autant que possible d'avoir à y revenir par la suite. Sur cette installation-ci, je suis très probablement revenu en arrière avant la création de la table des partitions, ce qui explique peut-être l'incohérence de leur ordre physique / logique.

Je vois qu'on arrive au moment de prendre une décision : dans l'idéal, je préfère rétablir la suite des partitions comme elles étaient avant, au moins par ensembles, c'est-à-dire les partitions Windows en premier, suivies des partitions Linux dans la partition étendue et la partition de stockage supplémentaire en dernier (au format NTFS). Peu importe l'ordre des partitions au sein d'un groupe (Windows / Linux) du moment que leurs tailles ne varient pas trop ; et la partition swap est vide a priori, donc pas grave du tout si elle est reformatée. Et j'avais prévu de laisser 16Go pour la réaffectation de cellules défectueuses au cas où. Je ne sais pas si ça t'aide à comprendre ce que j'ai en tête.

Donc ça donnerait quelque chose comme :
sdx*1   WinRE amorçable
sdx2    Windows system
sdx3    Partition étendue
sdx4    root, home ou swap au choix
sdx5    root, home ou swap au choix
sdx6    root, home ou swap au choix
sdx7    espace de stockage au format NTFS (75 Gio environ) dans la partition étendue ou en dehors, peu importe, mais en laissant 16Go de réserve derrière

* Le disque est /dev/sdc tant que je le branche sur cet ordi depuis lequel j'écris, il se nomme /dev/sdb dans sa machine d'origine (et j'ai la possibilité de le brancher ici en interne à la place du sdb actuel s'il faut).

Dernière modification par 31hud (25-06-2020 09:38:33)

Hors ligne

#32 25-06-2020 09:45:10

MicP
Membre
Inscription : 29-02-2016

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Bonjour

@raleur

raleur a écrit :

…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 :

fdisk /dev/sda


Bienvenue dans fdisk (util-linux 2.33.1).
Les modifications resteront en mémoire jusqu'à écriture.
Soyez prudent avant d'utiliser la commande d'écriture.


Commande (m pour l'aide) : x

Commande pour spécialistes (m pour l'aide) : m

Aide (commandes pour spécialistes) :

  DOS (secteur d'amorçage)
   b   déplacer le début des données dans une partition
   i   modifier l'identifiant de disque

  Géométrie (pour l'étiquette actuelle)
   c   modifier le nombre de cylindres
   h   modifier le nombre de têtes
   s   modifier le nombre de secteurs par piste

  Générique
   p   afficher la table de partitions
   v   vérifier la table de partitions
   d   afficher les données brutes du premier secteur du périphérique
   D   afficher les données brutes de l’étiquette de disque du périphérique
   f   corriger l'ordre des partitions
   m   afficher ce menu

  Sauvegarder et quitter
   q   quitter sans enregistrer les modifications
   r   revenir au menu principal


Commande pour spécialistes (m pour l'aide) : q

… ce qui fait que je n'ai pas à déplacer ou reformater de partition.

Hors ligne

#33 25-06-2020 10:08:04

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Hello
je me posais la question si c'est ce que fait l'option de sfdisk

man sfdisk a écrit :

-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

En ligne

#34 25-06-2020 10:12:52

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

31hud a écrit :

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.

31hud a écrit :

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)

31hud a écrit :

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

#35 25-06-2020 10:46:49

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

raleur a écrit :

Ç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. big_smile

raleur a écrit :

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.

raleur a écrit :

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.

raleur a écrit :

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.

raleur a écrit :

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

#36 25-06-2020 12:27:06

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Question subsidiaire : le fichier table, je le place où ? Et est-ce que je dois spécifier son chemin complet dans la commande sfdisk ?

Hors ligne

#37 25-06-2020 12:58:44

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

31hud a écrit :

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.

31hud a écrit :

le fichier table, je le place où ?


N'importe où.

31hud a écrit :

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

#38 26-06-2020 08:08:04

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Ok, merci pour tes indications.

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 :

/dev/sdb1   WinRE   pri (7), bootable
sect début: 63
sect fin:   706859
taille en s: 706797

/dev/sdb2   Windows pri (7)
sect début: 706860
sect fin:   156649814
taille en s:155942955

/dev/sdb3   extended
sect début: 156651518
sect fin:   293173247
taille en s:136521730

/dev/sdb4   stockage pri (7)
sect début: 293173248
sect fin:   456056831
taille en s:162883584

/dev/sdb5   linux-swap x (82)
sect début: 197666816
sect fin:   205477887
taille en s:7811072

/dev/sdb6   root       x (83)
sect début: 156651518
sect fin:   197666815
taille en s:41015298

/dev/sdb7   home       x (83)
sect début: 205477888
sect fin:   293173247
taille en s:87695360

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

#39 26-06-2020 21:07:02

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

31hud a écrit :

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.

31hud a écrit :

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.

31hud a écrit :

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.

31hud a écrit :

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.

31hud a écrit :

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

#40 27-06-2020 16:14:48

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Ok, merci pour tes explications. Je ne connais pas l'EBR et du coup je ne comprenais pas le pourquoi de ces différences.
Je disais "corrompue" parce que la création de la partition avec diskmgmt a dû être interrompue et qu'elle est reconnue comme FAT16 ou "format inconnu" par les différents outils.

Voici le retour de

sfdisk --no-act --no-reread --no-tell-kernel --wipe-partitions never /dev/sdb < table

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).

>>> Script d’en-tête accepté.
>>> Script d’en-tête accepté.
>>> Script d’en-tête accepté.
>>> Script d’en-tête accepté.
>>> Création d'une nouvelle étiquette pour disque de type DOS avec identifiant de disque 0xabcd1234.
/dev/sdb1: Une nouvelle partition 1 de type « HPFS/NTFS/exFAT » et de taille 345,1 MiB a été créée.
La partition #1 contient une signature ntfs.
/dev/sdb2: Une nouvelle partition 2 de type « HPFS/NTFS/exFAT » et de taille 74,4 GiB a été créée.
La partition #2 contient une signature ntfs.
/dev/sdb3: Une nouvelle partition 3 de type « Extended » et de taille 65,1 GiB a été créée.
/dev/sdb4: Une nouvelle partition 4 de type « HPFS/NTFS/exFAT » et de taille 77,7 GiB a été créée.
/dev/sdb5: Une nouvelle partition 5 de type « Linux swap / Solaris » et de taille 3,7 GiB a été créée.
La partition #5 contient une signature swap.
/dev/sdb6: Une nouvelle partition 6 de type « Linux » et de taille 19,6 GiB a été créée.
La partition #6 contient une signature ext4.
/dev/sdb7: Une nouvelle partition 7 de type « Linux » et de taille 41,8 GiB a été créée.
La partition #7 contient une signature ext4.
/dev/sdb8: Terminé.

Nouvelle situation :

Périphérique Amorçage     Début       Fin  Secteurs Taille Id Type
/dev/sdb1    *               63    706859    706797 345,1M  7 HPFS/NTFS/exFAT
/dev/sdb2                706860 156649814 155942955  74,4G  7 HPFS/NTFS/exFAT
/dev/sdb3             156651518 293173247 136521730  65,1G  5 Étendue
/dev/sdb4             293173248 456056831 162883584  77,7G  7 HPFS/NTFS/exFAT
/dev/sdb5             197666816 205477887   7811072   3,7G 82 partition d'échang
/dev/sdb6             156651520 197666815  41015296  19,6G 83 Linux
/dev/sdb7             205479936 293173247  87693312  41,8G 83 Linux

Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
La table de partitions n’est pas modifiée (--no-act).

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 :

La table de partitions a été altérée.

Y'a plus qu'à tester.

Dernière modification par 31hud (27-06-2020 16:16:12)

Hors ligne

#41 27-06-2020 16:32:25

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

woohoo.gifmerci.gifmerci.gifmerci.gif

Le grub réapparaît comme avant et tout semble normal dans ma session. Je suis déjà super content, tu ne peux pas imaginer à quel point ! T'es vraiment un chef yes.gif

Hors ligne

#42 27-06-2020 16:50:49

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Ça a été un peu long et laborieux et j'ai pris beaucoup de précautions parce qu'avec les partitions logiques on n'a pas droit à l'erreur : contrairement aux partitions primaires ou à une table de partition GPT où on ne modifie que la table de partition et pas la zone des partitions elles-mêmes, des EBR sont écrits à l'intérieur de la partition étendue, et si on se trompe dans la position des partitions à recréer on risque d'écraser des données.

S'il n'y avait pas ce système Windows, je t'aurais suggéré de convertir au format GPT.

Dernière modification par raleur (27-06-2020 16:52:10)


Il vaut mieux montrer que raconter.

Hors ligne

#43 27-06-2020 16:56:07

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Et j'ai avancé à tout petits pas pour ne pas aggraver la situation, je te remercie pour ta patience et le temps passé. Je passe le sujet en [RÉSOLU] et j'en ouvrirai un autre pour rectifier l'ordre logique / physique des partitions. Là, je vais faire chauffer le 2To et une cafetière complète (je te dois au moins ça, sauf si tu bois du thé). Tu m'as tiré d'un mauvais pas.

Je ne suis pas sûr que le bios gère les partitions GPT : c'est du matériel qui date d'il y a 10/12 ans, avant l'arrivée des UEFI.

Dernière modification par 31hud (27-06-2020 16:58:07)

Hors ligne

#44 27-06-2020 17:05:53

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Le BIOS n'a pas à gérer le format de la table de partition, donc on peut utiliser GPT sans UEFI. C'est le cas sur le PC de 2005 avec lequel j'écris : il a 16 partitions qui changent souvent, je n'allais pas pas prendre le risque de tout casser avec des partitions logiques. C'est juste Windows qui ne peut pas booter sur un disque au format GPT sans UEFI.

Il vaut mieux montrer que raconter.

Hors ligne

#45 28-06-2020 14:26:18

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

hmm 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

#46 28-06-2020 18:12:43

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

31hud a écrit :

Clonezilla qui se plaint que sdb6 et sdb7 contiennent des erreurs


Quelles erreurs ?

31hud a écrit :

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

#47 29-06-2020 12:34:46

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Bonjour raleur,

Désolé pour la réponse tardive, mais il fallait que je reproduise mes manips pour noter les messages d'erreur. Pour DiskImage v1.6 c'est vite vu : il retourne juste "Failure: Image Creation Failed". Dans le fichier img créé, j'ai :

Nom       Taille         Format                 Offset         Primaire   CHS début   CHS fin
0.ntfs    361880064      NTFS                   32256          +          0-1-1       43-254-63
1.ntfs    79842792960    NTFS                   361912320      +          44-0-1      534-254-63
2.img     3999268864     Solaris / Linux-swap   101205409792   -          16-48-33    502-103-49
3         44900024320                           105204678656          
4         99954589696                           150104702976

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

#48 29-06-2020 19:37:16

raleur
Membre
Inscription : 03-10-2014

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

31hud a écrit :

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.

31hud a écrit :

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

#49 29-06-2020 20:44:18

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

raleur a écrit :

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.

raleur a écrit :

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.

raleur a écrit :

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

#50 30-06-2020 07:51:08

31hud
Membre
Lieu : proche Toulouse
Distrib. : Debian 10 stable
Noyau : 4.19.0-6-amd64
(G)UI : XFCE
Inscription : 13-03-2017

Re : [RÉSOLU] Récupération de partitions perdues suite à grub rescue

Bon, j'ai pu faire un fsck sur /home (sda7) depuis le mode rescue en faisant un umount avant, il est clean. Pour / (sda6), il le remonte systématiquement, j'ai préféré laisser tomber. En cherchant un peu, j'ai vu qu'il y avait la possibilité d'effectuer un systemd-fsck au démarrage en ajoutant une ligne au grub et en faisant un update-grub ( https://manpages.debian.org/jessie/syst … .8.en.html  et  https://www.freedesktop.org/software/sy … rvice.html ). La méthode décrite ici https://debian-facile.org/doc:systeme:fsck dans le Wiki au paragraphe "Démarrage" (création d'un fichier /forcefsck) n'est plus en vigueur depuis l'introduction de systemd.

Il me faudrait donc ajouter en fin de ligne 'fsck.mode=force' mais j'hésite pour 'fsck.repair= ' : il propose "preen" par défaut pour une réparation de ce qui peut l'être de façon sûre ou répondre toujours "oui" ou "non".

Hors ligne

Pied de page des forums