Re: Récupérer une table de partition GUID
Vincent DUVERT a écrit :
Bonjour à tous,
Dans la série des "erreurs bêtes", j'en ai fait une grosse toute à
l'heure.
Oui, c'est le genre de truc qui arrive au moins une fois dans la vie
d'un admin, après on réfléchit à deux fois avant de presser la touche
entrée sous root, on prend son temps pour taper les commandes délicates
/ dangereuses, on se fait un petit éthylo-test avant de prendre les
droits de super-utilisateur...
Moi mon ultime bêtise ça a été un rm -drf dossier/ fichier *
en fait l'auto completion m'avait foutu un espace derrière "fichier" et
j'ai mal visé la touche entrée donc j'ai appuyé sur * et entrée en même
temps...
le temps que je réagisse quelque centaines de fichiers précieux étaient
détruits et ça m'a pris 3 jours pour faire le tri et remettre des noms
sur les fichiers récupérés avec reiserfsck -S --rebuild-tree (ça scan
tout le disque et ça recupère les fichiers effacés mais pas leur nom)...
Je voulais repartitionner une clé USB sur mon Mac Intel (en étant sous
Debian Testing). Sauf que j'avais oublié que contrairement à mon PC
portable, le disque dur était en SATA et que /dev/sda n'était pas la
clé USB mais... le disque !
Résultat, j'ai remplacé ma table de partitions (sur ces nouveaux Macs,
c'est plus un partitionnement "Mac", mais un partitionnement GUID) par
une table de partitions PC. Et bien évidemment, il n'y a plus rien qui
marche.
J'ai éteint aussitôt le Mac (j'avais peur que ça commence à écrire des
trucs partout).
Mauvais réflex! Comme tu le sais surement, en général un reboot est
necessaire après une modification du partitionnement, pour que le noyau
charge et utilise la nouvelle table de partition. Ce qui signifie que
tant que tu n'éteins pas ou que tu ne reboot pas, il continue d'utiliser
l'ancienne qui est stockée quelque part (au hasard /proc/partitions) et
il n'y a pas de risque particulier pour les données donc tu as le temps
de réfléchir, rechercher, prendre un shoot de /proc et le sauvegarder
sur un support amovible ( ça peu servir par la suite ) ainsi que les
données utilisateurs les plus précieuses.
Je peux accéder au disque dur interne par FireWire, par contre je ne
peux pas en faire une image (pas de disque dur assez grand et assez
vide).
Ca ça dépend de la valeur que tu accordes aux données présentes sur le
disque (documents t'aillant demandé des dizaines d'heures de boulot,
photos numériques, etc. Essai de te faire prêter un disque assez grand,
ou achètes en un, au pire tu peux toujours aller en acheter un dans une
grande surface, le déballer proprement, résoudre rapidement ton
problème, l'effacer proprement (genre dd if=/dev/zero
of=/dev/le_disque_a_effacer), et demander à te le faire rembourser sous
prétexte que ton vieux celeron 1200 ne gère pas le LBA32 et qu'il ne
supporte donc pas les DD de plus de 130Go... au hasard Au.han rembourse
sans trop de difficultés et en espèce ;)
Dans tous les cas il vaut mieux faire une sauvegarde avant d'envisager
toute modification.
Tu peux la compresser avec gzip pour diminuer de moitié l'espace
nécessaire, par exemple si le disque endommagé est /dev/sda, le disque
de sauvegarde est monté sur /mnt/backup :
dd if=/dev/sda ¦ gzip -9 ¦ dd of=/mnt/backup/backup.gz
Y a-t-il des utilitaires permettant de retrouver la table des
partitions ? J'ai testé testdisk, mais il ne fonctionne pas avec le
schéma de partition GUID...
Ca me surprend un peu que testdisk ne connaisse pas les partitions guid
mais juste un peu, il faudrait voir avec la dernière version...
Sinon il y a GNU parted, le plus universel / puissant / dangereux /
difficile à utiliser que je connaisse... lui je suis sure qu'il connait
les partitions guid et il y a une commande rescue qui cherche les
partitions effacées...
Je te conseil vivement de faire une sauvegarde avant toute tentative et
puis rtfm !
Vincent
Bonne chance.
@+
Reply to: