Debian Debian-France Debian-Facile Debian-fr.org Debian-fr.xyz Debian ? Communautés

Debian-facile

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

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

#26 09-01-2021 01:04:18

phux
Membre
Lieu : Sud-Est / Sud-Ouest
Distrib. : debian Buster
Noyau : 4.19.0 amd64
(G)UI : Gnome 3
Inscription : 21-05-2020

Re : [Résolu] Conseils pour récupérer des partitions écrasées

Bonsoir raleur,

Je n'ai pas encore lancé les commandes que tu m'as données, je ne les connais pas et je veux pas écrire sur le disque tant que je n'ai pas fait la sauvegarde de mes partitions. C'est pas que j'ai pas confiance, note bien, mais une connerie, ça m'a vacciné.

Je laisse la partition 1 (ntfs) de côté pour l'instant.

Si j'ai bien suivi, la partition 2 démarre exactement au bloc 10001x2048 et se termine juste avant la partition 3, qui démarre au bloc 110001x2048.

Il faudrait donc que je lance dd avec les paramètres suivants :

# dd if=/dev/sdb of=/media/chezmoi/Sauvegarde_A/partition2.img bs=4096 skip = $((10001*2048)) count=$((100000x2048))


avec 100000=110001-10001.

Je pose la question qui parait triviale, mais je m'y perds entre décomptes en GiO et GO. Je comprends que dd compte en mebi-octets (1024x1024 octets) et gibi-octets (1024x1024x1024), mais que le disque a été partitionné en giga-octets (1000x1000x1000). J'ai bon ?

Pour la partition 3, voici ce que renvoie hdparm :

# /usr/sbin/hdparm -I /dev/sdb
 


/dev/sdb:

ATA device, with non-removable media
  Model Number:       ST1000LM035-1RK172                      
  Serial Number:      WL1QPL23
  Firmware Revision:  SDM4    
  Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
  Used: unknown (minor revision code 0x001f)
  Supported: 10 9 8 7 6 5
  Likely used: 10
Configuration:
  Logical   max current
  cylinders 16383 16383
  heads   16  16
  sectors/track 63  63
  --
  CHS current addressable sectors:    16514064
  LBA    user addressable sectors:   268435455
  LBA48  user addressable sectors:  1953525168
  Logical  Sector size:                   512 bytes
  Physical Sector size:                  4096 bytes
  Logical Sector-0 offset:                  0 bytes
  device size with M = 1024*1024:      953869 MBytes
  device size with M = 1000*1000:     1000204 MBytes (1000 GB)
  cache/buffer size  = unknown
  Form Factor: 2.5 inch
  Nominal Media Rotation Rate: 5400



Entre CBS / LBA et LBA48 addressable sectors, quel est la bonne valeur ? Et de quelle taille de secteur parle-ton ? logique ou physique ?

Le LBA adressable sectors et des secteurs de 4096 octets me donne la valeur la plus proche, mais je ne tombe pas pile sur la taille du disque renvoyée par hdparm :
268 435 455 * 512 / 1024 / 1024 = 1 048 575,99 MiO


p....n de courbe d'apprentissage !

Hors ligne

#27 09-01-2021 10:58:09

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Conseils pour récupérer des partitions écrasées

phux a écrit :

Je n'ai pas encore lancé les commandes que tu m'as données, je ne les connais pas et je veux pas écrire sur le disque


man est ton ami. Ces commandes n'écrivent rien sur le disque et je ne vois pas comment tu pourrais te tromper en les tapant et écrire sur le disque. Même si tu intervertis if= et of= dans la première méthode, il faudrait en plus que le fichier source spécifié par if= existe et ne soit pas vide, ce qui n'est normalement pas le cas puisque le but est de créer ce fichier). Si tu as quand même peur, utilise une des deux autres méthodes qui n'écrivent rien du tout.

Arrête de te prendre la tête, tu as plus de chances de te tromper dans tes calculs pour sauvegarder la partition. Si tu veux faire une sauvegarde fiable, fais-en une du disque entier.

Dernière modification par raleur (09-01-2021 11:03:23)


Il vaut mieux montrer que raconter.

Hors ligne

#28 09-01-2021 11:16:20

phux
Membre
Lieu : Sud-Est / Sud-Ouest
Distrib. : debian Buster
Noyau : 4.19.0 amd64
(G)UI : Gnome 3
Inscription : 21-05-2020

Re : [Résolu] Conseils pour récupérer des partitions écrasées

J'ai bien lu les pages du manuel, mais c'est assez abscons. Sans pratiquer, difficile de comprendre ce que les paramètres font.

dd if=/dev/sdb count=4 skip=$((10001*2048)) count=32 of=partition1
/usr/sbin/tune2fs -l partition1


/usr/sbin/tune2fs: Attempt to read block from filesystem resulted in short read while trying to open partition1
Couldn't find valid filesystem superblock.
 



Apparemment, je ne trouve pas le début de la partition. neutral

Dernière modification par phux (09-01-2021 12:06:49)


p....n de courbe d'apprentissage !

Hors ligne

#29 09-01-2021 12:27:40

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Conseils pour récupérer des partitions écrasées

Si, car sinon le message d'erreur serait différent ("Bad magic number in super-block"). Le message indique que le fichier est trop court.
Pourtant chez moi ça marche. Essaie d'augmenter la valeur de count. Ou utilise une des autres méthodes.
Edit : erreur dans la commande dd, count=4 est en trop (mais a priori ça ne devrait pas être pris en compte).

Dernière modification par raleur (09-01-2021 13:13:43)


Il vaut mieux montrer que raconter.

Hors ligne

#30 09-01-2021 13:16:48

phux
Membre
Lieu : Sud-Est / Sud-Ouest
Distrib. : debian Buster
Noyau : 4.19.0 amd64
(G)UI : Gnome 3
Inscription : 21-05-2020

Re : [Résolu] Conseils pour récupérer des partitions écrasées

Dans la commande dd, il y a deux count, un avant skip, l'autre après. Je ne comprends pas pourquoi. Lequel dois-je augmenter ?

Pour les autres commandes :

losetup -o $((10001*2048*512)) -f --show /dev/sdb


/dev/loop0


tune2fs -l /dev/loop0 | grep Bloc


Block count:              25600000
Block size:               4096
Blocks per group:         32768
 



addpart /dev/sdb 1 $((10001*2048)) 2048
tune2fs -l /dev/sdb1 | grep Bloc


Block count:              25600000
Block size:               4096
Blocks per group:         32768
 



La taille de ma première partition ext4 est de 204800000 secteurs (25600000*4096/512). Je retrouve bien les 100 Go de mon partitionnement initial.

Si je fais la même chose pour la troisième partition (seconde partition ext4) :

losetup -o $((110001*2048*512)) -f --show /dev/sdb


/dev/loop1


tune2fs -l /dev/loop1 | grep Bloc


Block count:              216030208
Block size:               4096
Blocks per group:         32768



Seconde partition ext4 : 1 728 241 664 secteurs ou 843868 Mio.

Je viens de reprendre la première méthode avec dd et count=64, voici le résultat :

tune2fs -l partition1


tune2fs 1.44.5 (15-Dec-2018)
Filesystem volume name:   Donnees
Last mounted on:          /media/Donnees
Filesystem UUID:          66d9f802-5ca5-492d-bb98-e60193e45814
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 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:              6406144
Block count:              25600000
Reserved block count:     1280000
Free blocks:              24277811
Free inodes:              6402558
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1017
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Jul 15 22:31:27 2020
Last mount time:          Sat Jan  9 11:46:27 2021
Last write time:          Sat Jan  9 11:46:27 2021
Mount count:              520
Maximum mount count:      -1
Last checked:             Wed Jul 15 22:31:27 2020
Check interval:           0 (<none>)
Lifetime writes:          8 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:      82ca8a78-e26a-4611-8601-159b2621e827
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x22bf05ad
 



Le block count est cohérent avec les deux autres méthodes.

Et maintenant ?

Dernière modification par phux (09-01-2021 13:32:53)


p....n de courbe d'apprentissage !

Hors ligne

#31 09-01-2021 13:17:28

phux
Membre
Lieu : Sud-Est / Sud-Ouest
Distrib. : debian Buster
Noyau : 4.19.0 amd64
(G)UI : Gnome 3
Inscription : 21-05-2020

Re : [Résolu] Conseils pour récupérer des partitions écrasées

Question subsidiaire : mon disque fait 1 To, mon disque sauvegarde aussi. Si je fais une copie intégrale de sdb sur un fichier image, je vais manquer de place à cause du partitionnement de mon disque de sauvegarde, non ?
Et même en écrasant sa partition, il est un peu plus petit.

Disque /dev/sdb : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs --> le disque à sauvegarder
Modèle de disque : ST1000LM035-1RK1
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets


Disque /dev/sdc : 931,5 GiB, 1000202043392 octets, 1953519616 secteurs --> le disque cible
Modèle de disque : Elements 1042  
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x0002846e
 


p....n de courbe d'apprentissage !

Hors ligne

#32 09-01-2021 13:39:40

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Conseils pour récupérer des partitions écrasées

phux a écrit :

Dans la commande dd, il y a deux count, un avant skip, l'autre après. Je ne comprends pas pourquoi. Lequel dois-je augmenter ?


Voir l'édition de mon message précédent.

phux a écrit :

mon disque fait 1 To, mon disque sauvegarde aussi. Si je fais une copie intégrale de sdb sur un fichier image, je vais manquer de place à cause du partitionnement de mon disque de sauvegarde, non ?
Et même en écrasant sa partition, il est un peu plus petit.


La 2e partition finit au secteur 110001*2048+216030208*4096/512-1 = 1953523711 donc l'autre disque est effectivement trop petit.
La première partition commence au secteur 10001*2048 = 20482048 et finit au secteur 10001*2048+25600000*4096/512-1 = 225282047 donc juste avant le début de la seconde (110001*2048 = 225282048), ce qui est cohérent.

Si les données utiles n'occupent pas 1 To, tu peux recréer les partitions virtuellement avec addpart, les monter et recopier les données sur l'autre disque.

addpart /dev/sdb 1 $((10001*2048)) $((25600000*8))
mount -r /dev/sdb1 /point/de/montage1
addpart /dev/sdb 2 $((110001*2048)) $((216030208*8))
mount -r /dev/sdb2 /point/de/montage2



(Si tu avais utilisé addpart précédemment, il faut préalablement supprimer les partitions avec les commandes delpart que j'avais indiquées.)

Tu as tous les éléments pour recréer une table de partition. Il reste suffisamment d'espace à la fin du disque après la fin de la seconde partition pour créer une table de partition de type GPT qui écrit une copie de la table à la fin du disque. Si tu optes pour une table de partition DOS/MBR traditionnelle, crée seulement des partitions primaires et surtout pas de partition étendue/logique, cela pourrait écraser le début des partitions. Il ne faut pas effacer les données lors de la création des partitions, donc je me méfierais de Gparted. fdisk propose d'effacer les signatures, il faut lui répondre de les conserver.

Dernière modification par raleur (09-01-2021 14:00:59)


Il vaut mieux montrer que raconter.

Hors ligne

#33 09-01-2021 18:56:25

phux
Membre
Lieu : Sud-Est / Sud-Ouest
Distrib. : debian Buster
Noyau : 4.19.0 amd64
(G)UI : Gnome 3
Inscription : 21-05-2020

Re : [Résolu] Conseils pour récupérer des partitions écrasées

J'ai remonté les deux partitions ext4, copié les fichiers sur un disque externe, et lancé gdisk pour partionner en GPT.

gdisk /dev/sdb


GPT fdisk (gdisk) version 1.0.3

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: damaged

Found invalid MBR and corrupt GPT. What do you want to do? (Using the
GPT MAY permit recovery of GPT data.)
 1 - Use current GPT
 2 - Create blank GPT

Your answer: 1

Command (? for help): p
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Model: ST1000LM035-1RK1
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 45C3A22D-467A-45C3-B0DC-8B8842C1629D
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3437 sectors (1.7 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        20482047   9.8 GiB     0700  DATA
   2        20482048       225282047   97.7 GiB    8300  Donnees
   3       225282048      1953523711   824.1 GiB   8300  Stockage



Apparemment, le disque était bien partitionné en GPT. Je comprends qu'il charge la table backup, mais que les CRC ne sont pas bons, et qu'il faut que je répare le disque. Avant d'écrire sur le disque, peux-tu me confirmer que c'est bien la séquence r (restore) c (load backup partition table) ?

gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.3

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: damaged

Found invalid MBR and corrupt GPT. What do you want to do? (Using the
GPT MAY permit recovery of GPT data.)
 1 - Use current GPT
 2 - Create blank GPT

Your answer: 1

Command (? for help): r

Recovery/transformation command (? for help): b

Recovery/transformation command (? for help): m

Command (? for help): v

Problem: The CRC for the main partition table is invalid. This table may be
corrupt. Consider loading the backup partition table ('c' on the recovery &
transformation menu). This report may be a false alarm if you've already
corrected other problems.

Identified 1 problems!

Command (? for help): r

Recovery/transformation command (? for help): c
Warning! This will probably do weird things if you've converted an MBR to
GPT form and haven't yet saved the GPT! Proceed? (Y/N): y

Recovery/transformation command (? for help): m

Command (? for help): v

No problems found. 3437 free sectors (1.7 MiB) available in 2
segments, the largest of which is 2014 (1007.0 KiB) in size.
 


p....n de courbe d'apprentissage !

Hors ligne

#34 09-01-2021 20:34:20

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Conseils pour récupérer des partitions écrasées

phux a écrit :

Apparemment, le disque était bien partitionné en GPT.


Et on s'est fait suer pour rien. J'avais pourtant écrit dans mon premier message :

raleur a écrit :

Note : si la table de partition est au format GPT, il y a une table de secours à la fin du disque, que des outils comme gdisk peuvent utiliser pour restaurer la table principale.


Mais apparemment c'est passé inaperçu. Au moins on peut vérifier que nos calculs étaient exacts.

phux a écrit :

Je comprends qu'il charge la table backup, mais que les CRC ne sont pas bons, et qu'il faut que je répare le disque.


Ce sont les CRC de l'en-tête et la table principaux situés au début du disque qui sont incohérents. L'en-tête et la table de sauvegarde situés à la fin du disque sont intacts, et gdisk a pu retrouver les partitions grâce à eux.

phux a écrit :

Avant d'écrire sur le disque, peux-tu me confirmer que c'est bien la séquence r (restore) c (load backup partition table) ?


A mon avis pas besoin de s'embêter avec ça. Si la commande "p" affiche les bonnes partitions, alors il devrait suffire d'enregistrer avec "w".
Vérifie quand même que le MBR est bien de type MBR protecteur. Sinon il faudra passer par les fonctions expert avec "x" pour le reconstruire avec "n".

Dernière modification par raleur (09-01-2021 20:37:05)


Il vaut mieux montrer que raconter.

Hors ligne

#35 09-01-2021 20:48:56

jpt
Membre
Distrib. : Debian 10.8
Noyau : Linux 5.7.10 (backports)
(G)UI : LXDE
Inscription : 12-09-2020

Re : [Résolu] Conseils pour récupérer des partitions écrasées

Bonsoir

raleur a écrit :

Et on s'est fait suer pour rien.

Mais non : on a appris des trucs avec ta méthode, ta rigueur et ta précision.

Maintenant, quand je lis ça,

raleur a écrit :

GPT c'est bon, mangez-en.

j'aimerais bien en savoir un peu plus, en quelques phrases.
J'avoue humblement ne m'être jamais penché sur le sujet, mais on dirait que c'est peut-être le moment (la récup avec gdisk m'a bluffé).

Merci,


AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War

Hors ligne

#36 09-01-2021 22:18:45

phux
Membre
Lieu : Sud-Est / Sud-Ouest
Distrib. : debian Buster
Noyau : 4.19.0 amd64
(G)UI : Gnome 3
Inscription : 21-05-2020

Re : [Résolu] Conseils pour récupérer des partitions écrasées

raleur a écrit :

Et on s'est fait suer pour rien. J'avais pourtant écrit dans mon premier message :


Oui raleur, j'en suis bien conscient. Faute de savoir ce que faisait gdisk, et en particulier qu'il me permettait de savoir si la partition était en gpt, j'ai commencé avec le premier indiqué. Comment perdre des heures quand la solution est là, sous mon nez !

Mais tu m'a appris plein de trucs (les outils disque gpart, losetup, tune2fs, les paramètres de dd que je ne connaissais pas), et surtout, ce que je pressentais sans avoir eu vraiment la preuve, qu'un système ouvert et l'entraide sont les outils les plus puissants qui existent. Alors désolé de t'avoir fait perdre ton temps, désolé pour mes questions à la noix sur détail de la vis de 6, et encore un immense merci pour ta patience et ton aide.

A ce sujet, j'aimerais bien savoir comment tu as acquis une telle expertise sur les systèmes de fichiers, le matériel, et les outils linux. Ca fait un bout de temps que je tripote   linux, mais à part une utilisation basique de dd, je n'avais jamais entendu parler de toutes ces commandes.

raleur a écrit :

Vérifie quand même que le MBR est bien de type MBR protecteur. Sinon il faudra passer par les fonctions expert avec "x" pour le reconstruire avec "n".



Euh, comment je vérifie ça ? Voici ce que donne 'print protective MBR data' en mode expert :

Expert command (? for help): o

Disk size is 1953525168 sectors (931.5 GiB)
MBR disk identifier: 0x00000000
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1                     1   1953525167   primary     0xEE


p....n de courbe d'apprentissage !

Hors ligne

#37 09-01-2021 22:21:04

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Conseils pour récupérer des partitions écrasées

GPT est un format de table de partition défini par le standard UEFI mais qui peut être utilisé indépendamment. Parmi ses avantages par rapport au format traditionnel DOS/MBR, on peut citer :
- le support des disques et partitions de plus de 4Gi-secteurs, soit 2 Tio avec des secteurs de 512 octets
- une meilleure fiabilité grâce à la présence d'une copie de secours de la table de partition à la fin du disque et à l'abandon des partitions étendues et logiques et leur structure en liste chaînée fragile et peu pratique
- un nombre de partitions maximum défini à la création de la table de partition (128 par défaut)
- l'attribution à chaque partition d'un (vrai) UUID et d'un nom/étiquette de partition indépendants de son contenu (donc inchangés par un reformatage, contrairement à UUID et LABEL), reconnus par blkid en tant que PARTUUID et PARTLABEL et utilisables pour identifier les partitions dans /etc/fstab et autres, et même pour identifier la partition racine sans initramfs à partir du noyau 2.6.37 avec PARTUUID et 4.20 (trop tard pour buster) avec PARTLABEL (note: les noyaux précompilés de Debian ne peuvent pas monter la racine sans initramfs).

Il vaut mieux montrer que raconter.

Hors ligne

#38 09-01-2021 22:32:34

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Conseils pour récupérer des partitions écrasées

phux a écrit :

désolé de t'avoir fait perdre ton temps


Ce n'est pas moi qui ai perdu du temps. Je fais ça comme passe-temps.

phux a écrit :

comment tu as acquis une telle expertise sur les systèmes de fichiers, le matériel, et les outils linux


Des heures d'expérimentation, de lecture de la documentation et des forums. Et on n'imagine pas tout ce qu'on peut apprendre en essayant de résoudre problèmes des autres.

phux a écrit :

Voici ce que donne 'print protective MBR data'


Alors c'est bon.


Il vaut mieux montrer que raconter.

Hors ligne

#39 09-01-2021 22:55:53

phux
Membre
Lieu : Sud-Est / Sud-Ouest
Distrib. : debian Buster
Noyau : 4.19.0 amd64
(G)UI : Gnome 3
Inscription : 21-05-2020

Re : [Résolu] Conseils pour récupérer des partitions écrasées

J'ai corrigé avec le partitionnement qu'il a retrouvé à partir du backup. C'est tout bon, les partitions 2 et 3 sont remontées.

La première est morte, mais je le savais, et il n'y avait rien d'important dessus. Je viens de la recréer avec gparted.

Mille mercis. Je suis devenu fan de GPT. J'ai fait la sauvegarde des tables des deux disques pour ne pas compter que sur le backup.

Quelques questions pour parfaire mon savoir :

- comment forcer un formatage ou un partitionnement en GPT. Pour mon disque, est-ce que s'était déjà préformaté ou est-ce ça s'est fait tout seul lorsque j'ai créé les partitions avec gparted (je ne sais plus si j'ai réduit la partition ntfs initiale ou si je l'ai recréée "from scratch").
- Si je n'avais pas retrouvé les partitions avec gdisk, comment est-ce que j'aurais recréé la table à partir des adresses des secteurs ? Avec fdisk, sfdisk ? Et quels paramètres ?

Enfin, comment est-ce que je change le titre du fil en résolu ?

Dernière modification par phux (09-01-2021 23:07:03)


p....n de courbe d'apprentissage !

Hors ligne

#40 09-01-2021 23:06:35

phux
Membre
Lieu : Sud-Est / Sud-Ouest
Distrib. : debian Buster
Noyau : 4.19.0 amd64
(G)UI : Gnome 3
Inscription : 21-05-2020

Re : [Résolu] Conseils pour récupérer des partitions écrasées

jpt a écrit :

(la récup avec gdisk m'a bluffé).



Moi aussi. Tout le début du disque était écrasé à coup de zéros, et si j'avais démarré par gdisk, je récupérais tout en deux minutes chrono.

En plus, gdisk permet de faire une sauvegarde de la table en plus du backup. Ce que je viens de faire pour mes deux disques qui par chance sont tous deux en GPT.

Seul bémol, les disques boot pour lesquels il semble y avoir des problèmes (mais rien de tel pour mon ssd en mode uefi).


p....n de courbe d'apprentissage !

Hors ligne

#41 10-01-2021 00:39:03

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Conseils pour récupérer des partitions écrasées

phux a écrit :

- comment forcer un formatage ou un partitionnement en GPT


Il faut utiliser un programme de partitionnement compatible GPT et demander la création d'une table de partition (on dit aussi "disk label") de type GPT. Bien sûr cela écrase la table de partition existante et supprime les partitions présentes.

gdisk peut aussi convertir une table de partition DOS au format GPT sans supprimer les partitions existantes, si leur position le permet (il doit y avoir suffisamment d'espace non alloué au début et à la fin du disque pour les tables de partition principale et de secours). Si le disque est utilisé pour l'amorçage BIOS, il pourra être nécessaire de réinstaller le chargeur d'amorçage. Avec GRUB, il faudra créer une partition de type BIOS boot (non formatée, taille 100 ko minimum) et réinstaller GRUB dont une partie a été écrasée par la table de partition GPT. Avec certains BIOS, il faudra aussi activer le drapeau "boot" sur la partition GPT du MBR protecteur avec fdisk ou parted, je ne pense pas que gdisk permette de le faire. Si le disque est utilisé pour l'amorçage UEFI (ce qui devrait être rare, le format GPT étant utilisé par défaut ou obligatoirement avec ce mode d'amorçage), il pourra être nécessaire de réenregistrer GRUB dans les variables de boot EFI avec efibootmgr ou réinstaller GRUB avec grub-install.

phux a écrit :

Pour mon disque, est-ce que s'était déjà préformaté ou est-ce ça s'est fait tout seul lorsque j'ai créé les partitions avec gparted


Si le disque avait déjà une table de partition, alors Gparted a dû la conserver, à moins que tu aies demandé la création d'une nouvelle table.

phux a écrit :

- Si je n'avais pas retrouvé les partitions avec gdisk, comment est-ce que j'aurais recréé la table à partir des adresses des secteurs ? Avec fdisk, sfdisk ? Et quels paramètres ?


Avec fdisk, sfdisk, gdisk, parted... tu as le choix. Selon le programme pour chaque partition il faut indiquer la position de début et la position de fin ou la taille.

phux a écrit :

Seul bémol, les disques boot pour lesquels il semble y avoir des problèmes (mais rien de tel pour mon ssd en mode uefi).


Les seuls problèmes que je connais pour l'amorçage BIOS sont la possible nécessité de créer une partition BIOS boot pour GRUB et d'activer le drapeau "boot" de la partition GPT du MBR protecteur comme expliqué plus haut.


Il vaut mieux montrer que raconter.

Hors ligne

Pied de page des forums