Recréer le MBR par analyse du contenu du disque dur

Babdu89 · Le 15/10/2013, à 22:25

Bonsoir.

Enfin, excusez-moi, malbo et Babdu89, j'ai bien pris note des résultats de vos tests mais je ne suis toujours pas convaincu que Ubiquity m'ait vraiment demandé sur quel support je voulais faire l'installation.

Il ne demande rien. Dans l'interface il y a un champ "Sélectionner le disque" dans lequel le premier disque est proposé par défaut. /dev/sda.
Et si on ne change pas pour un autre, il prend çà pour argent comptant, et il fait son travail. Il efface le disque proposé par défaut dans le champ en question .
Et c'est bien là le souci... Cette proposition du premier hdd par défaut. Il vaudrait mieux qu'il n'y ai pas de proposition par défaut. Et que l'on soit obligé d'ouvrir le déroulant, pour indiquer sur quel disque on veut faire l'installation en effaçant le disque entier . Il y aurait moins de soucis.

C'est la même chose pour l'installation de Grub stage1 plus loin dans l'installation, en cas de configuration multi disques .
Normalement. Il propose le disque choisi pour l'installation, mais j'ai vu bien des fois où il laissait le hdd /dev/sda par défaut . Ce, sur pas mal de versions de Ubuntu.
En cas d'installation en multi disques, surtout lorsque l'on à des hdd usb branchés.
Je m'en méfie comme de la peste. De ce truc là .

J'ai oublié de mentionner que les deux clés, celle avec laquelle j'ai amorcé le PC sur l'iso de la 12.04 et celle sur laquelle je voulais faire cette installation, étaient, au point de vue matériel, strictement identiques. Cette similitude des clés a peut-être masqué la clé où je voulais installer aux yeux d'Ubiquity.

Moi aussi j'ai fais pas mal de tests avec deux clés identiques.
Si elles ne sont pas partitionnées, il peut y avoir confusion. Ce n'est pas grave puisqu'il n'y a rien dessus. Mais si une est partitionnée et l'autre pas, Ubiquity s'y retrouve.

Je te souhaite bien du courage pour la récupération de tes données. Çà ne va pas être une partie de plaisir si tu ne peux pas retrouver les "catalogues".

Bon courage.

@+. Babdu89 .

packard · Le 16/10/2013, à 11:52

Babdu89 dit:

Et que l'on soit obligé d'ouvrir le déroulant

Le mieux,c'est qu'il n'y ai pas de déroulant qui passe le plus souvent inaperçu, mais une page entière considérée comme une étape obligatoire a l'installation de Grub, dédiée au choix du disque et à la partition d’installation.

Dernière modification par packard (Le 16/10/2013, à 11:53)

moko138 · Le 16/10/2013, à 20:32

Arbiel, au #50 a écrit :

Lorsque je modifie à la main la taille d'une partition dans le MBR, ce que j'ai fait par /dev/sda1, je ne modifie pas la zone en question,

De quelle "zone" parles-tu ?

Arbiel, au #50 a écrit :

Mais cela signifie aussi qu'il [testdisk] trouve quelque part la taille des partitions.

Peut-être que testdisk trouve cette taille de sda1 (la nouvelle au lieu de l'ancienne) dans son fichier log, commencé - arrête-moi si je me trompe - avant tes rectifications manuelles. Dans cette hypothèse, il serait intéressant de renommer et déplacer son fichier log, puis de relancer testdisk.

Arbiel · Le 17/10/2013, à 00:08

Bonsoir

@moko138

Après sélection du disque que je veux analyser, testdisk affiche les partitions telles qu'elles sont décrites dans le MBR et les EBR. J'ai modifié à la main (par dd) la description de la partition /dev/sda1 pour la cadrer sur ce que je pense être ce qu'elle était avant ma tentative malheureuse. Dans cette première étape, testdisk m'affiche bien la taille que j'ai inscrite.

Dans un deuxième temps, testdisk fait une "analyse" rapide et il me présente les partitions telles qu'elles étaient après l'arrêt brutal, mais trop tardif, d'Ubiquity : une /dev/sda1 qui a même origine que mon ancienne /dev/sda1 et qui fait la presque totalité du disque, un peu moins de 500 Go, alors que la mienne faisait environ 15 Go, et une swap dans la petite partition étendue qu'Ubiquity a créée en fin de disque. Comme tu me l'as suggéré, j'ai renommé, puis détruit, le fichier log de testdisk. Rien n'a changé au niveau de cette analyse rapide : testdisk retrouve, et affiche ces deux partitions, celles créées par Ubiquity. Comme j'ai détruit le fichier log de testdisk, ce n'est pas là qu'il retrouve ces informations, mais quelque part sur le disque, et ce "quelque part sur le disque" est la zone que je ne sais pas modifier, car je ne sais pas (encore) où elle est.

Lorsqu'ensuite je lui demande une analyse approfondie, il inspecte le contenu des secteurs pour y trouver, disons, des signatures de partitions, et me les propose comme origines potentielles de mes anciennes partitions. Ce faisant, il ne peut plus voir mon ancienne partition /dev/sda1 dont l'origine est la même que celle qu'Ubiquity a créée. Et c'est cette dernière, celle d'Ubiquity qu'il me propose. Par contre, comme Ubiquity a créé une énorme partition qui fait presque tout le disque, et qu'il n'a pas eu le temps de tout effacer, la plupart de mes autres partitions sont intactes, et j'ai pu à peu près les identifier pour demander à testdisk de les recréer, ce qu'il a fait. Et dans ces partitions recrées par testdisk, je retrouve bien mes fichiers.

En conclusion, la taille de la partition doit être inscrite quelque part dans la partition. Et cette supposition est d'autant plus réaliste que cette taille peut servir (mais cela, c'est une pure hypothèse de ma part) à déterminer l'endroit où se trouve ce que je serais tenté d'appeler le "catalogue" des fichiers, l'endroit où sont stockés leurs propriétés (nom, droit d'accès, nature de fichier, gestion des liens physiques, ...). On peut en effet penser que, pour optimiser les temps d'accès aux fichiers, comme il faut systématiquement passer par ce catalogue, son endroit optimum se situe aux alentours du milieu de la partition, ou peut-être un peu décentré vers le début de la partition, mais pas à une place prédéterminée.

Et je pense avoir une petite chance, si je réussis à modifier dans la partition les quelques octets qui contiennent la talille de la partition, de retrouver aussi mes fichiers.

Si quelqu'un a une petite idéesur ce sujet, je le remercie vivement de m'en informer.

Arbiel

moko138 · Le 17/10/2013, à 09:16

Arbiel, #54 a écrit :

"Comme j'ai détruit le fichier log de testdisk [pour mémoire, je t'avais proposé "de renommer et déplacer" le log, pas de le détruire], ce n'est pas là qu'il retrouve ces informations, mais quelque part sur le disque,"

OK ! Info intéressante ! Le quelque part en question, n'est-ce pas le nouvel EBR de sda1 ? Or c'est l'ancien que nous cherchons... OU PAS.
Si oui

Nasman, #21 a écrit :

"Le travail à effectuer sur les ebr est globalement le même que pour le mbr. La difficulté consiste surtout à repérer le début et la taille des partitions à récupérer. La réécriture des ebr est une plaisanterie à côté de cela."

Or tu connais la taille, 15 Go (vraiment si peu ? En #10, tu avais dit "La première partition était ma partition Data qui devait avoir repris strictement la place qu'occupaient antérieurement les deux premières partitions (je pense que c'était vraiment les deux premières, "recovery" et "tools") du PC. Sa taille devait être de quelques petites dizaines de Gio.").
Peut-être même as-tu l'habitude de cocher dans gparted "aligner sur les frontières de cylindre", ce qui simplifierait la reconstitution du sda1 antérieur.
Les origines des deux derniers sda1 coïncident-elles parfaitement ou sont-elles voisines ?

Arbiel, #12 a écrit :

"Sait-on retrouver tous les rapports BootRepair produits par un utilisateur donné ?"

Oui, même ceux que tu n'as pas envoyés ! Babdu89 te l'a rappelé au #18 ; ils sont dans les /var/log/boot-sav/ de TOUS les linux de ton pc.
Or,

Arbiel, #54 a écrit :

"la plupart de mes autres partitions sont intactes, et j'ai pu à peu près les identifier pour demander à testdisk de les recréer, ce qu'il a fait. Et dans ces partitions recrées par testdisk, je retrouve bien mes fichiers."

Donc tu peux y relire ton dernier rapport boot-repair.

Si nous faisons l'impasse sur l'EBR
Piste 1 : les inodes, mais le peu que j'en sais, je le tiens de tiramiseb.
Piste 2 : ce que tu appelles "catalogue des fichiers"
/usr/share/doc/thunar-data/html//fr/advanced-topics.html#to-bulk-rename-files
"Les dossiers sont aussi des fichiers dans le système de fichiers UNIX. Pour être exact, un dossier est un fichier spécial, contenant une liste de noms de fichiers faisant référence aux fichiers contenu (sic) dans le dossier."
Donc en cherchant (avec hexdump ?) quelques noms de fichiers qui te sont familiers, tu vas bien localiser un dossier et le nom de ce dossier, nom à partir duquel tu pourras remonter récursivement dans l'arborescence de ton ancien sda1.

@ Experts : merci de rectifier mes approximations.

Arbiel · Le 18/10/2013, à 18:31

Bonjour à tous

Pour l'instant, j'abandonne la recherche de mes fichiers sur /dev/sda1. En fait la perte est moins importante que je le craignais. En particulier, je pensais avoir perdu toute ma messagerie, mais je l'ai retrouvée, et avec elle tous les documents que j'ai transmis à mes correspondant en pièce jointe de mes messages. J'ai également retrouvé mon profil firefox.

J'ai essentiellement perdu les mises à jour de mes fichiers personnels dont la dernière sauvegarde remonte à début juillet, ce qui n'est pas une énorme perte vue la baisse d'activité en juillet et en août. J'ai également perdu ma partition 12.04, que j'ai bien sûr réinstallée, et que j'ajusterai à mes besoins au fil du temps, ce qui signifie que je dois réécrire quelques lanceurs et scripts. C'est un peu de travail, mais rien de catastrophique car j'ai pu recommencer à travailler sur mes dossiers familiaux.

A l'occasion de cette réinstallation j'ai constaté que ma partition /dev/sda1, celle que j'ai reconstruite en "dd-isant" mon MBR, provoque un dysfonctionnement de celles des fonctions de grub que j'utilise pour amorcer mon PC directement depuis un fichier iso. Il s'agit plus particulièrement de la fonction search de grub, utilisée pour trouver le nom grub ( du style (hd0,msdos1) et non /dev/sda) de la partition sur laquelle se trouve le fichier iso que je lui demande d'utiliser. Bien évidemment, cette fonction fait le tour des partitions, et ce faisant tombe sur ma partition foireuse et retourne un message d'erreur quelque peu surprenant. J'en parlerai aux développeurs de grub.

Par la même occasion, j'ai constaté qu'elle empêchait le fonctionnement d'une clé crée par USB-creator. Je ne sais pas ce qu'il en est d'une clé initialisée par UNetbootin, car ma partition Windows a également souffert. Je ne sais absolument pas dire s'il s'agit là du même problème que pour "mon" système personnel d'amorçage.

J'ai neutralisé cette partition /dev/sda1 en remettant à zéro son entrée dans le MBR, ce qui fait que l'espace disque correspondant est (relativement) à l'abri de toute modification, ce qui me permettra d'y revenir plus tard si le besoin s'en fait sentir. J'ai également recopié le contenu de la partition dans un fichier, que je vais essayer d'exploiter avec foremost.

J'ai néanmoins l'intention de continuer à chercher où peut bien être stockée la taille d'une partition, probablement quelque part dans le deuxième secteur, puis, comme le suggère moko138, chercher des zones contenant mes noms de fichiers, pour essayer de remonter à l'origine du répertoire général.

J'ai également l'intention de poursuivre, sur un PC qui ne craint rien, l'analyse du comportement d'Ubiquity avec l'idée de faire supprimer cette option qui, à mes yeux, est vraiment stupide, même si sa suppression peut entraîner quelques difficultés supplémentaires pour les débutants qui ne sauraient pas comment réorganiser, ou effacer, leur disque pour accueillir une distribution GNU/Linux. Elle est bien sûr stupide à mes yeux, puisque j'ai agi stupidement, du fait de son existence. Mais elle m'apparaît stupide aussi car sa principale motivation me semble être de permettre l'installation d'une distribution sans réfléchir à l'organisation de ses données (ce que je me suis permis de faire). Or ceci ne me semble pas une bonne approche.

Microsoft pousse le commun des mortels à utiliser ses systèmes sans aucune connaissance (circulez, il n'y a rien à voir, pardon, il n'y a rien à comprendre, je m'occupe de tout, il n'y a qu'à payer). Beaucoup peuvent s'en satisfaire, et il n'y a aucun reproche à leur adresser. Pour ce qui nous concerne, je pense que nous formons une communauté dans laquelle la compréhension de ce que nous faisons est à la base de notre désir d'autonomie. Et cette façon de penser et d'agir est en contradiction avec "Efface tout et installe comme tu veux, je ne veux rien en savoir".

Cela étant, je vous remercie, les uns et les autres pour les efforts que vous avez faits et le temps que vous avez pris pour me venir en aide.

Je laisse pour l'instant la discussion ouverte, même s'il ne s'agit plus vraiment de reconstruire mon "MBR par analyse du contenu du disque dur".

Arbiel

Dernière modification par Arbiel (Le 18/10/2013, à 18:34)

moko138 · Le 10/11/2013, à 11:30

Apparemment, le besoin d'une correction de l'installateur est de plus en plus patent :
http://forum.ubuntu-fr.org/viewtopic.ph … #p15162362

moko138 · Le 10/11/2013, à 12:40

...newubuntu y dit que le pb (écrasement de toutes les sdaX) s'est manifesté avec ubuntu 13.10 mais n'avait pas eu lieu lors des 4 installations précédentes de Cubuntu sur le même disque.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 15/10/2013, à 22:25

Re : Recréer le MBR par analyse du contenu du disque dur

#52 Le 16/10/2013, à 11:52

Re : Recréer le MBR par analyse du contenu du disque dur

#53 Le 16/10/2013, à 20:32

Re : Recréer le MBR par analyse du contenu du disque dur

#54 Le 17/10/2013, à 00:08

Re : Recréer le MBR par analyse du contenu du disque dur

#55 Le 17/10/2013, à 09:16

Re : Recréer le MBR par analyse du contenu du disque dur

#56 Le 18/10/2013, à 18:31

Re : Recréer le MBR par analyse du contenu du disque dur

#57 Le 10/11/2013, à 11:30

Re : Recréer le MBR par analyse du contenu du disque dur

#58 Le 10/11/2013, à 12:40

Re : Recréer le MBR par analyse du contenu du disque dur

Pied de page des forums