Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 08/05/2015, à 18:11

La_Louche00

[Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

bonjour,

Je suis nouveau, en Linux et sur ce forum. Comme tout nouveau, je fais des boulettes... J'ai installe Xubuntu sur mon PC en suivant les instructions du site, parfait, tout marchait bien. Je l'avais mis en parallele de Windows 7, dont j'ai encore besoin pour utiliser Lightroom (au passage, si quelqu'un sait si Lightroom 4 tourne sous Wine ...).
J'avais alloue seulement 15 Gb de DD pour Linuxm ce qui se trouvait etre trop petit assez rapidement. Je desalloue alors du DD sous Windows, boot sur gparted pour etendre la partition Linux. J'arrive a l'etendre mais pas a "joindre" les deux bouts. Gparted me demande le type de partition pour le petit morceau, je mets GPT et la ca crashe. Tout mon disque se retrouve sous une partition GPT j'ai l'impression, impossible de booter.

Actuellement, je fais tourner testdisk qui trouve les bonnes partitions originelles. Mes questions sont : J'ai peur de faire encore une boulette, si vous voyez le probleme, y aurait-il une solution simple ? Si non, auriez-vous des instructions "pour les debutants" pour fdisk ?
Merci d'avance, et desole pour les accents, je boote avec un live usb et un clavier qwerty ...

Dernière modification par La_Louche00 (Le 10/05/2015, à 17:08)

Hors ligne

#2 Le 08/05/2015, à 18:52

michel_04

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Bonjour,

La_Louche00 a écrit :

Je l'avais mis en parallele de Windows 7, dont j'ai encore besoin pour utiliser Lightroom (au passage, si quelqu'un sait si Lightroom 4 tourne sous Wine

Je ne sais pas pour Lightroom, mais Lightzone fonctionne sous GNU/Linux How To Install LightZone 4.0 On Ubuntu 14.04/13.10/13.04/12.10/12.04, Linux Mint 16/15/14/13, Pear OS 8/7 And Elementary OS 0.2.

A+

Dernière modification par michel_04 (Le 09/05/2015, à 11:51)

Hors ligne

#3 Le 08/05/2015, à 19:29

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

===> Pour ceux qui liraient cette discussion  ==> la bonne solution est ici http://forum.ubuntu-fr.org/viewtopic.ph … #p19778951

Bonjour
Tu as pris la bonne solution. Testdisk va savoir retrouver les partitions.
Son option write va valider l'écriture.    Enfin cela marche lorsque la table de partition n'a pas été changée.
Comme tu as changé la table de partition, Je ne sais pas trop s'il va savoir remettre l'ancienne table ou s'il va conserver la nouvelle table.
Mais l'important est que tu retrouves les partitions dans une table de partition.
Le seul problème que je vois venir c'est que le MBR qui permet de booter aura été détruit  par la table de partition que tu as créée.   et on ne peut pas le remettre dans un disque GPT
Donc tu vas ramasser un second problème comment booter.......
Attendons de voir si testdisk a rebâtit une table de partition MSDOS ou pas.


Cependant, tu devrais regarder par le gparted de la live USB si tu visualises toutes tes partitions
Si oui quitte GPARTED et  regarde si tu peux y accéder. 
Si oui  tu n'as qu'un problème de boot à traiter

AJOUT. Je ne sais pas si TESTDISK sait modifier la table de partition. mais je  crois que OUI
Dans ce cas, tu pourras lui faire remettre le format MS-DOS.
Ce qui te permettras de refabriquer les secteurs de boot via boot-repair


AJOUT pour le clavier de la liveusb, il y a une commande à faire le plus vite possible.

 setxkbmap fr

Dernière modification par Bougron (Le 09/05/2015, à 18:40)

Hors ligne

#4 Le 09/05/2015, à 09:47

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Merci Bougron,
Testdisk retrouve les bonnes partitions. Sous Gparted, on ne voit rien, selon lui il n'y a qu'un disque non formate.
Je vais essayer d'ecrire la table avec testdisk, je vous tiens au courant.
Ce qui m'inquiete un peu est qu'il n'y  a pas le type de partition devant chaque partition. Voila la sortie : (desole je ne sais pas comment bien le mettre en forme)

Disk /dev/sdb - 320 GB / 298 GiB - CHS 38913 255 63
     Partition               Start        End    Size in sectors
 * HPFS - NTFS              0  32 33   191  89 26    3072000 [SYSTEM_DRV]
   HPFS - NTFS            191  89 27 25135   2 19  400719872 [Windows7_OS]
   HPFS - NTFS            191  89 27 37128 101 29  593393664 [Windows7_OS]
   Linux                34779   7 45 36122 176 22   21585920
   Linux Swap           36122 208 55 37128 101 29   16154624
   HPFS - NTFS          37128 101 30 38913   5  4   28669952 [Lenovo_Recovery]
>  HPFS - NTFS          37128 101 30 38913  37 36   28672000 [Lenovo_Recovery]

Sinon le clavier francais ne fonctionne pas, -fr non reconnu !


Modération : merci à l'avenir d'utiliser les balises code (explications ici).

Dernière modification par cqfd93 (Le 09/05/2015, à 11:07)

Hors ligne

#5 Le 09/05/2015, à 10:33

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Apres l'analyse, j'ai tout reecrit, et ca n'a rien change, il ne boote toujours pas.
Testdisk a une option pour reecrire le MBR, je l'avais effectue aussi.
Si un connaisseur de Testdisk passe par la ...

Hors ligne

#6 Le 09/05/2015, à 10:55

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Bonjour.
Le boot ne peut absolument pas se faire.
Avant ton action  le MBR  (Les 512 premiers octets du disque) étaient  ainsi constitué:
                                   une partie décrivant les 4 partitions primaires possibles.
                                   une très grande partie contenant de la programmation permettant de commencer à lire les secteurs qui contiennent de quoi booter.
                Lorsque tu lances le bios legacy, il lit cette partie et l'exécute pour lancer le vrai boot.

Après ton action, le MBR est ainsi constitué:
                             La totalité du MBR décrit les  128 partitions primaires possibles.
       Ton bios qui est resté LEGACY veut donc exécuter des descriptions de table primaires. Ce n'est plus du code correct.

Je ne sais pas trop comment  se passe la réparation du MBR par testdisk.
Tu pourrais tenter celle faite par boot-repair. Il devrait au moins remettre correct le MBR pour ubuntu.
Ce qui est embêtant c'est que gparted considère qu'il ne peut pas accéder aux partitions
       Je vais regarder sur internet  ce qui pourrait se passer si on lui demande de refabriquer une table de partition MSDOS.
        puis après de relancer le testdiskk tel que tu l'as fait car je pense que c'est la bonne solution.
J'ai vu que les formats des partitions sont restés corrects. Devant il y a "HPFS - NTFS" mais il y a des partitions qui se chevauchent  un peu me semble-t-il .

Pour la commande, Je suis désolé, J'ai fait une erreur que je viens de corriger (il ne faut pas de tiret).

Pour la mise en forme, tu sélectionnes la zone que tu veux mettre en forme et tu cliques sur le 11eme symbole (texte préformaté) qui est au-dessus de la zone de frappe.
A bientôt.

Dernière modification par Bougron (Le 09/05/2015, à 11:17)

Hors ligne

#7 Le 09/05/2015, à 11:07

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Merci Bougron !
J'ai executé Gparted, qui me dit qu'il ne peut pas lire le disque car il a une table en GPT.
Je crois que je commence à comprendre (c'est ça qui est bien avec les boulettes, on se plonge dedans).
J'ai ça :

/dev/sda contains GPT signatures, indicating that it has a GPT table.  However, it does not have a valid fake msdos partition table, as it should.  Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables.  Or perhaps you deleted the GPT table, and are now using an msdos partition table.  Is this a GPT partition table?

Faudrait-il que j'utilise gdisk ?

Hors ligne

#8 Le 09/05/2015, à 11:13

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Je suis en train de penser que tu as probablement mal utilisé testdisk
http://www.cgsecurity.org/wiki/TestDisk … partitions

En effet, il est écrit que testdisk se positionne par défaut sur la table de partition trouvée.
Dans ton contexte, il a certainement trouvé "EFI GPT"
Il ne faut pas que tu acceptes cette valeur mais que tu forces à 'intel'.
As-tu fais ce choix?

Dernière modification par Bougron (Le 09/05/2015, à 11:14)

Hors ligne

#9 Le 09/05/2015, à 11:18

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

oui, j'ai choisi Intel.
Mais effectivement, quand je choisis EFI GPT, il met un "P" devant une partition. J'essaie d'utiliser Boot Repair sinon, mais je n'y comprends pas grand chose...
Je vais peut-être réutiliser testdisk et réecrire à nouveau.

Hors ligne

#10 Le 09/05/2015, à 11:29

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

La_Louche00 a écrit :

Merci Bougron !
J'ai executé Gparted, qui me dit qu'il ne peut pas lire le disque car il a une table en GPT.
Je crois que je commence à comprendre (c'est ça qui est bien avec les boulettes, on se plonge dedans).
J'ai ça :

/dev/sda contains GPT signatures, indicating that it has a GPT table.  However, it does not have a valid fake msdos partition table, as it should.  Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables.  Or perhaps you deleted the GPT table, and are now using an msdos partition table.  Is this a GPT partition table?

Faudrait-il que j'utilise gdisk ?

Il dit surtout que la structure de la table GPT  n'est pas correcte.
Or perhaps you deleted the GPT table, and are now using an msdos partition table.
Ce qui voudrait dire que la table de partition est bien redevenue MS-DOS et que testdisk a bien fait son travail de récupération mais pas d'installation de secteur de boot.
     => tentes avec boot-repair
Pour le moment, N'utilises pas gdisk qui la rendrait correcte car après tu devras sauvegarder toutes tes données.
pour reformater entièrement  le disque avec une table de partition MSDOS.
    Si tu voulais rester avec une table de partition GPT; il faudrait que
            Ton bios ait la possibilité de booter en EFI ce qui est loin d'être sur!
           Le disque possède une table de partition en FAT32 contenant les programmes de boot. Ce qu'il n'a pas.
C'est pour cela qu'il faut revenir à un format MS-DOS tant que cela est possible et sans détruire  les partitions.

Dernière modification par Bougron (Le 09/05/2015, à 11:35)

Hors ligne

#11 Le 09/05/2015, à 11:35

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Message reçu !
La question est donc comment revenir au format MS-DOS ?
=> je vais donc essayer avec boot-repair

Dernière modification par La_Louche00 (Le 09/05/2015, à 11:37)

Hors ligne

#12 Le 09/05/2015, à 11:42

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

La_Louche00 a écrit :
Disk /dev/sdb - 320 GB / 298 GiB - CHS 38913 255 63
     Partition               Start        End    Size in sectors
 * HPFS - NTFS              0  32 33   191  89 26    3072000 [SYSTEM_DRV]
   HPFS - NTFS            191  89 27 25135   2 19  400719872 [Windows7_OS]
   HPFS - NTFS            191  89 27 37128 101 29  593393664 [Windows7_OS]
   Linux                34779   7 45 36122 176 22   21585920
   Linux Swap           36122 208 55 37128 101 29   16154624
   HPFS - NTFS          37128 101 30 38913   5  4   28669952 [Lenovo_Recovery]
>  HPFS - NTFS          37128 101 30 38913  37 36   28672000 [Lenovo_Recovery]

C'est quand même plus joli comme cela.
Je pense qu'à l'étape suivante de testdisk, il va éliminer les doublons et te proposer de réécrire la table.
Cela devrait alors être bon.
Le doublon est la

   HPFS - NTFS            191  89 27 25135   2 19  400719872 [Windows7_OS]
   HPFS - NTFS            191  89 27 37128 101 29  593393664 [Windows7_OS]

Si testdisk ne sait pas faire le choix
    Il faudra en faire un.  Je peux me tromper. Mais il y a deux tailles possibles.
        Dans ce contexte c'est plutôt une opération de rétrécissement qui a eu lieu. (Il peut y avoir des mois!!)
       Si tel est le cas et que cette opération a été terminée, tu choisis la petite taille (la première) sinon cela sera la seconde

il y a aussi celle-la

   HPFS - NTFS          37128 101 30 38913   5  4   28669952 [Lenovo_Recovery]
>  HPFS - NTFS          37128 101 30 38913  37 36   28672000 [Lenovo_Recovery]

Normalement c'est une partition qui a été sauvegardée  dès l'arrivée du micro et qui n'a pas tellement sa place sur le disque,
      Comment peux-tu l'utiliser pour restaurer windows lors d'une destruction totale du disque?
Je ne sais pas donner de conseil sur ce qu'il faut prendre comme choix. La plus grande probablement (la seconde)

Dernière modification par Bougron (Le 09/05/2015, à 12:10)

Hors ligne

#13 Le 09/05/2015, à 11:48

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Je le refais alors, je l'avais fait la première fois et ça n'avait rien changé.

Hors ligne

#14 Le 09/05/2015, à 12:02

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

La_Louche00 a écrit :

Je le refais alors, je l'avais fait la première fois et ça n'avait rien changé.

etais-tu allé jusqu'à l'opératiion write?

Si oui,  tu ne dois pas utiliser gparted pour lire le contenu des partitions msdos mais la commande

sudo parted -l 

Hors ligne

#15 Le 09/05/2015, à 12:39

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

j'avais fait l'opération write.
Ce que je trouve bizarre, c'est qu'il n'y a pas les lettres indiquant la qualité des partitions (P, E, L...). Faut-il les ajouter à la main ?
Au passage, je ne savais pas à quoi servait le Q, je ne m'en suis jamais servi.
Testdisk est en train de tourner, c'est long...

Hors ligne

#16 Le 09/05/2015, à 12:59

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Testdisk va certainement faire pour le mieux de son point de vue
Je n'ai pas fait attention au nombre de partitions qu'il va trouver
           S'il y en a moins de cinq, il te les mettra toutes primaires
          S'il y en a plus de 4 je ne suis pas ce qu'il va faire.
                   probablement créer une partition Etendue   et te les mettre toutes en logique
Comme tu dis que testdisk est long cette fois-ci..... Aurais-tu demandé un deep-search... On  devrait être capable  d'éviter cette opération.
     Car c'est une opération qui est faite pour recopier les répertoires du disque dans un autre disque lorsque vraiment tout est bien cassé.
J'ai le souvenir que l'opération Write est assez courte .

Que donne la commande. Tu peux la faire  en ouvrant une autre session (ctrl Alt T) pendant que testdisk tourne.

sudo parted -l

La commande Q c'est l'abreviation de Quit qui permet de remonter d'un cran dans les choix.

Dernière modification par Bougron (Le 09/05/2015, à 13:05)

Hors ligne

#17 Le 09/05/2015, à 13:17

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Je viens de voir que testdisk va trouver 5 partitions.
il va donc faire la table de partition qui lui convient.
Je ne sais pas s'il a besoin de  réorganiser l'espace disque pour cela. Si oui, c'est obligatoirement tres long... laisse tourner.

Hors ligne

#18 Le 09/05/2015, à 13:18

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

voilà la réponse de sudo parted -l :

Warning: /dev/sda contains GPT signatures, indicating that it has a GPT table.
However, it does not have a valid fake msdos partition table, as it should.
Perhaps it was corrupted -- possibly by a program that doesn't understand GPT
partition tables.  Or perhaps you deleted the GPT table, and are now using an
msdos partition table.  Is this a GPT partition table?
Yes/No? N                                              

et voici ce que testdisk a trouvé, avec le deep search :

Disk /dev/sda - 320 GB / 298 GiB - CHS 38913 255 63
     Partition               Start        End    Size in sectors
>  HPFS - NTFS              0  32 33   191  89 26    3072000 [SYSTEM_DRV]
   HPFS - NTFS            191  89 26   382 146 19    3072000
   HPFS - NTFS            191  89 27 25135   2 19  400719872 [Windows7_OS]
   HPFS - NTFS            191  89 27 37128 101 29  593393664 [Windows7_OS]
   Linux                34779   7 45 36122 176 22   21585920
   Linux                35325 236 48 36669 150 25   21585920
   Linux                35326  14 17 36669 182 57   21585920
   Linux                35331 137  7 36675  50 47   21585920
   Linux Swap           36122 208 55 37128 101 29   16154624
   HPFS - NTFS          37128 101 30 38672  85  5   24803328 [Lenovo_Recovery]
   HPFS - NTFS          37128 101 30 38913   5  4   28669952 [Lenovo_Recovery]
   HPFS - NTFS          37128 101 30 38913  37 36   28672000 [Lenovo_Recovery]

Je vais continuer testdisk...

Hors ligne

#19 Le 09/05/2015, à 13:38

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Peux-tu faire la commande

sudo fdisk -l

Hors ligne

#20 Le 09/05/2015, à 14:07

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

et voilà :

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 320.1 GB, 320072933376 bytes
90 heads, 26 sectors/track, 267154 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     3074047     1536000    7  HPFS/NTFS/exFAT

Hors ligne

#21 Le 09/05/2015, à 14:24

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Je suis un peu perdu
La première commande indique que la table gpt est incohérente
La seconde commande indique que la table ms-dos est incohérente
A croire que tesdisk n'a pas fait correctement l'écriture de la table.
Es-tu bien sûr de l'avoir fait. Tu as peut-être sauté l'étape de validation?
- Write : Valide et écrit les changements qui ont été faits (si on est sûr des modifications apportées) : TestDisk demande alors de confirmer : "Write partition table, confirm ? (Y/N)"
Je crois que dans ce forum, il n'y a qu'une personne capable de fabriquer manuellement une table de partition.

il serait bon que tu recommences au début pour bien noter.
C'est soit un oubli de ta part. soit un raté de testdisk.
   Si raté de tesdisk, Il faut bien que tu notes tout si on tente de prévenir le 'fabricant"
    Après je ne vois plus que deux pistes possibles
              La réparation manuelle de la table. Cela  je ne vais pas m'y lancer. Savoir que cela est possible me suffit.
                                               Si Nasman intervient, il guidera. Il n'est pas nécessairement disponible.
                                               Il verra peut-être cette discussion.
            La récupération des données.
                   Pour cela , il va falloir un disque externe et savoir ce que tu veux récupérer.
                  L'opération sera nécessairement très longue, Tu as vu la durée d'un deep-search, Qu'il faudra répéter un certain nombre de fois.
                        Je ne sais pas combien de répertoires  tu vas vouloir récupérer.
Pour le moment tes données sont intactes. Ne prend surtout pas la décision de formater.
Je te propose encore quelques essais  si je vois d'autre pistes ou d'autres outils
                et d'attendre  l'arrivée du sauveur  le temps que tu estimeras nécessaire.
                S'il ne vient pas, On pourra  lancer l'opération sauvetage lorsque tu donneras le TOP..

Dernière modification par Bougron (Le 09/05/2015, à 14:58)

Hors ligne

#22 Le 09/05/2015, à 15:04

moko138

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Ne rien précipiter...

Pour le clavier :
Si les touches sont gravées AZERTY et affichent QWERTY,
alors la commande setxkbmap fr est à taper en qwerty, comme ceci

setxkb,qp fr

Dernière modification par moko138 (Le 09/05/2015, à 15:06)


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#23 Le 09/05/2015, à 15:07

Bougron

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

ATTENTION
Peut-être une solution simple que  je n'ai jamais utilisée

http://manpages.ubuntu.com/manpages/tru … rts.8.html

la commande  est

sudo fixparts /dev/sda

et le logiciel est normalement installé.

Dernière modification par Bougron (Le 09/05/2015, à 15:22)

Hors ligne

#24 Le 09/05/2015, à 15:11

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Pour le clavier, c'est bon, merci.
Je n'ai pas vraiment de données à sauver, j'avais fait une sauvegarde avant d'installer Linux. Je voudrais garder Windows, c'est tout (pour faire tourner Lightroom, les progs similaires sont loin d'être aussi bien).
En fait, après le deep search (même sortie que précédemment), je ne peux rien faire d'autre, il dit qu'il n'y a pas de partition.
C'est quand même étonnant non ? Y aurait-il un autre outil que testdisk pour refaire une table de partition ? J'ai essayé avec gparted, il y a un item "créer table de partition" mais il y a un warning :

This will erase ALL DATA on the entire Disk /dev/sda 

ce qui ne fait pas très envie ...

Dernière modification par La_Louche00 (Le 09/05/2015, à 15:14)

Hors ligne

#25 Le 09/05/2015, à 15:18

La_Louche00

Re : [Résolu] Perte d'acces au DD pour cause de mauvaise allocation des par

Intéressant comme utilitaire.
Voilà ce que j'ai, j'ai mis Yes à la première question.

oading MBR data from /dev/sda

NOTICE: GPT signatures detected on the disk, but no 0xEE protective partition!
The GPT signatures are probably left over from a previous partition table.
Do you want to delete them (if you answer 'Y', this will happen
immediately)? (Y/N): Y
Erasing GPT data!

Warning: 0xEE partition doesn't start on sector 1. This can cause problems
in some OSes.

MBR command (? for help): 

si je mets "p", il m'affiche le MBR :

Disk size is 625142448 sectors (298.1 GiB)
MBR disk identifier: 0x00000000
MBR partitions:

                                                   Can Be   Can Be
Number  Boot  Start Sector   End Sector   Status   Logical  Primary   Code
   1      *           2048      3074047   primary     Y        Y      0x07

Apparemment ça a enlevé un truc GPT

Dernière modification par La_Louche00 (Le 09/05/2015, à 15:21)

Hors ligne