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.

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

maxire

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

Salut tout le monde,

Je ne comprends pas très bien comment lors d'un simple élargissement de partition via gparted La_Louche00 a réussi à transformer partiellement une table de partitions mbr en table de partitions gpt.
Enfin bref,

/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?

Ceci veut simplement dire qu'une table de partitons GPT localisée au delà des 512 premiers octets a été créée sans qu'une table de partitions mbr de protection ait été créée.
En somme le disque comporte sans doute 2 tables de partitions, une mbr et une gpt sans aucune synchronisation.
Je rappelle que la partition de protection mbr (protective mbr in english) réserve l'ensemble du disque afin de protéger la table de partitions gpt des méfaits de logiciels stupides incapables de reconnaître ce type de table.
Oui, je sais c'est une affreuse bidouille, mais l'informatique n'est pas une science c'est d'abord une technologie donc du bricolage parfois génial, le plus souvent bancal.

Ceci dit, c'est le bazar.
Je dirais à priori qu'il faudrait utiliser l'option de GDISK de transformation d'une table GPT en table MBR, soit l'option r (recovery and transformation options (experts only)) de gdisk puis l'option g (convert GPT into MBR and exit).
Avant de sauvegarder les modifications, la liste des partitions sera affichée et te permettra de te faire une idée de la pertinence de la table mbr proposée.
Pour sortir de gdisk sans rien sauvegarder taper q.

Bon courage!

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


Maxire
Archlinux/Mate + Ubuntu 22.04 + Archlinux/Gnome sur poste de travail

Hors ligne

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

La_Louche00

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

merci Maxire. En fait le gpt a été créé par erreur (j'ai eu le choix quand j'ai étendu la partition dans gparted et j'ai mis gpt),je suppose qu'il faudrait plutôt la supprimer. Est-ce possible ?
Du coup je relance testdisk, sans ce petit bout de GPT ça marchera peut-être mieux.

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

Hors ligne

#28 Le 09/05/2015, à 15:30

Bougron

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

C'est peut-être le moment de refaire la commande

sudo fdisk -l

Il faudrait quand même être capable de retrouver cela

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]

et réécrire la table en ayant pris soin de sélectionner les  partitions   1  2 4 5 7 (si ce n'est pas sélectionné)
et de valider l'écriture..

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

Hors ligne

#29 Le 09/05/2015, à 15:34

La_Louche00

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

Bougron a écrit :

C'est peut-être le moment de refaire la commande

sudo fdisk -l

et voilà  :

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

c'est mieux, je n'ai plus l'erreur de GPT. Par contre je n'ai plus mes partitions, mais du coup je pense que testdisk (qui tourne) arrivera à les retrouver.
Voilà l'analyse de Testdisk maintenant :

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 27 25135   2 19  400719872 [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]

plus de doublons de partitions. Par contre, je ne peux pas passer à l'étape d'après, il me dit qu'il n'y a pas de partitions... bizarre

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

Hors ligne

#30 Le 09/05/2015, à 16:05

Bougron

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

Bonjour maxire

maxire a écrit :

Je dirais à priori qu'il faudrait utiliser l'option de GDISK de transformation d'une table GPT en table MBR, soit l'option r (recovery and transformation options (experts only)) de gdisk puis l'option g (convert GPT into MBR and exit).
Avant de sauvegarder les modifications, la liste des partitions sera affichée et te permettra de te faire une idée de la pertinence de la table mbr proposée.
Pour sortir de gdisk sans rien sauvegarder taper q.
Bon courage!

Je ne connaissais pas cette option de remise en état sans perte de données.
C'est peut-être la dessus que testdisk s'appuie. Sinon il va y avoir de plus en plus de mélange.
J'ai aussi vu que si elle est utilisée, pour valider ce qu'il propose c'est la commande W

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

Hors ligne

#31 Le 09/05/2015, à 16:16

maxire

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

Oubliez ce que j'ai écrit, la_Louche00 a supprimé la table GPT avec fixparts, le problème maintenant est que la table mbr est fausse, et peut-être que les 440 premiers octets n'hébergent plus de programme de démarrage.
Oui, pour écrire la nouvelle table sous gdisk c'est w, mais je laisse à l'utilisateur le plaisir de trouver cette option par lui-même.
L'important est qu'il sache qu'il peut réaliser toutes les simulations de tables qu'il désire sans conséquences à condition de sortir de gdisk avec l'option q.


Maxire
Archlinux/Mate + Ubuntu 22.04 + Archlinux/Gnome sur poste de travail

Hors ligne

#32 Le 09/05/2015, à 16:19

maxire

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

Complément, je vois que testdisk détecte 5 partitions ===> si table mbr nécessité d'une partition étendue + 1 ou plusieurs partitions logiques.
Comment régler ce problème?


Maxire
Archlinux/Mate + Ubuntu 22.04 + Archlinux/Gnome sur poste de travail

Hors ligne

#33 Le 09/05/2015, à 16:20

Bougron

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

La_Louche00 a écrit :

Voilà l'analyse de Testdisk maintenant :

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 27 25135   2 19  400719872 [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]

plus de doublons de partitions. Par contre, je ne peux pas passer à l'étape d'après, il me dit qu'il n'y a pas de partitions... bizarre

Je vois plus ou moins le problème.
lors de la conversion en GPT, elles ont toutes été passées en primary, L'opération inverse n'est pas possible car on est limité a 4 partitions primaires. La première est déjà retrouvée.
Je pense que dessous tu as des menus qui te permettent de faire des actions complémentaires.
Je ne sais pas dire comment faire une partition étendue
Je te propose de dire qu'il faut supprimer  Linux swap  et de dire que les 4 autres sont a utiliser.
C'est avec l'appui sur le caractère A   que la partition sera sélectionnée.
puis tu descends sur la seconde ligne     et A
puis tu descends sur la 3eme ligne    et A
puis tu descends sur la 5eme  ligne   et A
et après tu devrais avoir l'option W puis  sa confirmation.

C'est un ajout trop tardif.
    Il n'y a pas lieu de créer la partition étendue, car elle est créée automatiquement si on décide de définir une ou plusieurs partitions en L au lieu de P

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

Hors ligne

#34 Le 09/05/2015, à 16:29

La_Louche00

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

Bougron a écrit :

Je ne sais pas dire comment faire une partition étendue
Je te propose de dire qu'il faut supprimer  Linux swap  et de dire que les 4 a utiluiser
C'est avec l'appui sur le caractère A   que la ligne sera selectionnée.

Si je comprends bien, je dois affecter "P" à chaque partition, et virer Linux Swap ?

Hors ligne

#35 Le 09/05/2015, à 16:38

La_Louche00

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

je peux mettre les "P" comme cela :

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]
 P HPFS - NTFS            191  89 27 25135   2 19  400719872 [Windows7_OS]
   HPFS - NTFS            191  89 27 37128 101 29  593393664 [Windows7_OS]
 P Linux                34779   7 45 36122 176 22   21585920
   Linux Swap           36122 208 55 37128 101 29   16154624
>P HPFS - NTFS          37128 101 30 38913   5  4   28669952 [Lenovo_Recovery]
   HPFS - NTFS          37128 101 30 38913  37 36   28672000 [Lenovo_Recovery]

La lettre A ajoute une partition, je me sers des flèches pour mettre le "P" devant.

Hors ligne

#36 Le 09/05/2015, à 16:45

Bougron

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

C'est comme cela que je vois le résultat .
Pour le lenovo recovery, je verrais plutôt la seconde ligne que la première. il ne reste plus qu'a écrire

Pour cela, je pense qu'il faut faire ENTER pour avoir la grille d'écriture

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

Hors ligne

#37 Le 09/05/2015, à 16:50

La_Louche00

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

Ecrit !
Voilà ce que donne le fdisk -l :

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 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
/dev/sda2         3074048   403793919   200359936    7  HPFS/NTFS/exFAT
/dev/sda3       558725120   580311039    10792960   83  Linux
/dev/sda4       596467712   625139711    14336000    7  HPFS/NTFS/exFAT

ça a l'air mieux. Je vais peut-être réécrire le MBR avec testdisk, non ?

Hors ligne

#38 Le 09/05/2015, à 16:55

Bougron

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

Bravo.
Fais avec testdisk. Cela sera l'occasion de voir (Je ne sais pas comment on fait) .. Sinon cela  sera redevenu du classique avec boot-repair
Je vais devoir m'absenter.

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

Hors ligne

#39 Le 09/05/2015, à 17:01

La_Louche00

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

Bougron a écrit :

Bravo.
Fais avec testdisk. Cela sera l'occasion de voir (Je ne sais pas comment on fait) .. Sinon cela  sera redevenu du classique avec boot-repair
Je vais devoir m'absenter.

C'est fait, mais ça boote pas ! Je vais essayer avec boot repair, y'a dejà du mieux, les partitions sont reconnues.
Merci beaucoup, on a déjà bien avancé, ça m'a énormément aidé.

AJOUT : Boot repair a fait "presque" ce qu'il fallait. ça boote, mais je ne peux pas démarrer Windows.
Je crois approcher du but, si vous avez une petite idée pour réparer ça, ce serait super.

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

Hors ligne

#40 Le 09/05/2015, à 17:46

Bougron

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

Tu relances ubuntu et tu fais la commande

sudo os-prober

     Si tu vois une ligne dans laquelle il y a écrit windows ,tu fais la commande

sudo update-grub

    Sinon tu fais un boot-info  https://doc.ubuntu-fr.org/tutoriel/boot-info
Il y a probablement un drapeau boot à remettre en place.

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

Hors ligne

#41 Le 09/05/2015, à 18:03

La_Louche00

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

voilà le boot-info :
http://paste.ubuntu.com/11045774/
Windows n'apparait pas dans le os-prober, et si j'essaie de l'ajouter j'ai une erreur :

/usr/sbin/grub-probe: error: failed to get canonical path of `/cow'.

Hors ligne

#42 Le 09/05/2015, à 18:16

Bougron

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

Tu nous as joué un sacré tour.
Voila ce que je vois dans ton boot-info

=================== UEFI/Legacy mode:
BIOS is EFI-compatible, and is setup in EFI-mode for this live-session.

Cela ce n'est bon du tout
Ni windows ni le ubuntu que tu as installé n'ont de quoi booter en EFI
Il faut que tu modifies le bios pour le remettre LEGACY et que tu ré-installes le boot via boot-repair

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

Hors ligne

#43 Le 09/05/2015, à 18:26

La_Louche00

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

Tout d'abord, tout remarche comme avant. J'ai booté sur Windows et Linux, les deux fonctionnent.
Merci beaucoup à tous (et à toutes !) de votre aide, c'était vraiment hyper sympa et ça m'a énormément aidé.

Bougron a écrit :

Cela ce n'est bon du tout
Ni windows ni le ubuntu que tu as installé n'ont de quoi booter en EFI
Il faut que tu modifies le bios pour le remettre LEGACY et que tu ré-installes le boot via boot-repair

Secundo, il faut que je modifie maintenant mon BIOS ? Là ça me fait peur ... Est-ce que ce n'est pas tout simplement parce que je bootais sur la clé USB ?
voilà le nouveau Boot-info, en démarrant sur mon DD.
http://paste.ubuntu.com/11046063/

la partie sur le Legacy mode est :

=================== UEFI/Legacy mode:
This installed-session is not in EFI-mode.
EFI in dmesg.
[    0.000000] ACPI: UEFI 0x00000000DAFDF000 00003E (v01 LENOVO TP-G7    00002600 PTL  00000002)
[    0.000000] ACPI: UEFI 0x00000000DAFDE000 000042 (v01 PTL    COMBUF   00000001 PTL  00000001)
[    0.000000] ACPI: UEFI 0x00000000DAFDA000 0002A6 (v01 LENOVO TP-G7    00002600 PTL  00000002)
SecureBoot disabled.

Hors ligne

#44 Le 09/05/2015, à 18:56

Bougron

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

Non surtout pas puisque tu bootes.
Mais je ne comprends pas pourquoi.
  Le message que tu indiques (This installed-session is not in EFI-mode)  signifie que la session ubuntu est installée en LEGACY (non EFI) ce qui est normal.

Le message que j'ai indiqué  ( BIOS is .... setup in EFI-mode ) signifie que la session qui est lancée  a un bios positionné en mode  EFI. Du moins c'est ce que j'avais toujours compris jusqu'à ce jour.

Dans un tel cas de configuration cela ne devrait pas booter sauf si tu disposes d'un bios capable de constater qu'il ne peut pas booter en EFI et qui décide de tenter une seconde fois en LEGACY.  Il est possible que cela existe . Mais je ne le savais pas.
Je vais comparer les deux boot-info.

Dans ton boot-info, on voit bien que windows est détecté dans les deux partitions.

=================== os-prober:
/dev/sda3:L'OS actuellement utilisé - Ubuntu 14.04.2 LTS CurrentSession:linux
/dev/sda1:Windows 7 (loader):Windows:chain

/dev/sda2:Windows 7 (loader):Windows1:chain
comme tu l'as dit, que le session n'est pas en EFI

=================== UEFI/Legacy mode:
This installed-session is not in EFI-mode.

et que boot-repair prévoit de faire la réparation correctement

=================== Suggested repair
The default repair of the Boot-Repair utility would reinstall the grub2 of sda3 into the MBRs of all disks (except USB without OS).

Dans le premier boot-info on voit que la session est en EFI

=================== UEFI/Legacy mode:
BIOS is EFI-compatible, and is setup in EFI-mode for this live-session.

Qu'il y a plein de supports de boot-EFI don pas mal de partitions du disque dur.

=================== efibootmgr -v
BootCurrent: 000D
Timeout: 0 seconds
BootOrder: 0000,0001,0002,0003,0007,0008,0009,000A,000B,000C,000D,000E,000F,0010,0011,0012
Boot0000  Setup
Boot0001  Boot Menu
Boot0002  Diagnostic Splash Screen
Boot0003  Lenovo Diagnostics
Boot0004  Startup Interrupt Menu
Boot0005  ME Configuration Menu
Boot0006  Rescue and Recovery
Boot0007* USB CD	030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0008* USB FDD	030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0009* ATAPI CD0	030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35401
Boot000A* ATA HDD0	030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot000B* ATA HDD1	030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f601
Boot000C* ATA HDD2	030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f602
Boot000D* USB HDD	030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot000E* PCI LAN	030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot000F* ATAPI CD1	030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35404
Boot0010  Other CD	030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35406
Boot0011* ATA HDD3	030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f604
Boot0012  Other HDD	030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f606
Boot0013* IDER BOOT CDROM	ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0)
Boot0014* IDER BOOT Floppy	ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0)
Boot0015* ATA HDD	030a2400d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f6
Boot0016* ATAPI CD:	030a2400d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a354
Boot0017* PCI LAN	030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803

Je vais en conclure pour ce soir que ton ordinateur est bien positionné en EFI et que lorsque rien n'est bootable en EFI, il se rabat sur le boot MBR qu'il a fallut reconstituer. Pourtant, il me semblait que tu l'avais fais mais peut-être  fallait-il un boot via une clé USB pour que la modif soit prise en compte!

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

Hors ligne

#45 Le 09/05/2015, à 19:37

Bougron

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

Je reviens sur le problème de la dernière  partition du disque. "HPFS - NTFS          37128 101 30 38913   5  4   28669952 [Lenovo_Recovery]'
J'ai proposé de la conserver car je ne savais pas si tu avais fait  le nécessaire pour la mettre ailleurs.
C'est avec cette partition que tu peux réinstaller windows lorsque le disque est détruit (On a passé assez près)
Lenovo a du te dire de faire un support de sauvegarde pour utilisation en cas de besoin de restauration
C'est le moment d'utiliser les outils qu'il met à ta disposition pour le faire.
   
Lorsque cela sera fait, Tu supprimeras cette partition et tu feras une partition swap avec l'espace récupéré .
Tu le cadreras vers la droite.

Hors ligne

#46 Le 09/05/2015, à 19:46

michel_04

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

Bonjour,

Bougron a écrit :

Dans un tel cas de configuration cela ne devrait pas booter sauf si tu disposes d'un bios capable de constater qu'il ne peut pas booter en EFI et qui décide de tenter une seconde fois en LEGACY.  Il est possible que cela existe . Mais je ne le savais pas.


C'est le cas du BIOS Lenovo Thinkpad E320 - 1431193560.jpg


A+

Hors ligne

#47 Le 10/05/2015, à 01:31

Bougron

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

Comme quoi on a le droit à une seconde chance!!!!
Je retiens que ce grand pays est sacrement en avance en informatique libre.

Hors ligne

#48 Le 10/05/2015, à 10:14

moko138

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

Bougron a écrit :

Je retiens que ce grand pays est sacrement en avance en informatique libre.

"Lenovo" : c'est bien de la Chine que tu parles ?


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

Hors ligne

#49 Le 10/05/2015, à 10:35

Bougron

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

Bonjour moko138.
Force est de constater que ce micro possède  un bios positionné en EFI et qui réussit à booter sans la présence de windows. Ce n'est pas le cas de quelques ordinateurs fabriqués dans un monde 'libéral'.

Hors ligne

#50 Le 10/05/2015, à 10:49

moko138

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

Merci Bougron.

J'ai appris hier que l'armée de l'air française sous-traite auprès de Lenovo (!)


maxire a écrit :

Je ne comprends pas très bien comment lors d'un simple élargissement de partition via gparted La_Louche00 a réussi à transformer partiellement une table de partitions mbr en table de partitions gpt.

Je ne vois pas d'autre explication que celle-ci :
Précipitation entraînant, au lieu de
clic sur la partition à agrandir puis menu "Partition">Redimensionner,
cette manoeuvre-ci :
menu "Périphérique">Créer une table de partitions.


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

Hors ligne