#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
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
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
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
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
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é.
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,
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 -
A+
:D
De la bonne manière de poser les questions - Trouver de l'aide grâce au Groupe des Parrains Linux - Le Pacte des Gnous
PCs sous Debian Stable & Debian Sid.
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
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 (!)
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