Partition immontable après convert MBR to GPT - Apprenons en s’amusant
Salut,
Je suis nouveau sur Linux, ça fait quelques mois que je tentais de m’occuper de mon Raspberry, mais seulement une semaine que je m’y mets sérieusement. Avant toutes choses, je précise que ça n’est pas un cas d’urgence : j’ai réalisé un backup de ma carte SD avec dd, tout est safe, et de toutes façons je n’avais rien d’important sur la SD et réinstaller tout from scratch ne me posait pas de problème.
Alors certains dirons : “mais qu’est-ce que tu viens faire ici ?”. Eh bien je viens m’amuser à essayer de comprendre gdisk :java:, le formatage, le partitionnement, le resizing, le déplacement de partition, etc. En tant que technicien (formation T@I), je veux maîtriser la chose, même basiquement. Et depuis 48h je m’éclate à découvrir plein de trucs (et à me gaver de pages web), mais disons que j’aurais besoin d’un coup de main venant de gens habitués, pour essayer de rattraper les choses en mode “réel” plutôt que de rebalancer le backup sur la SD et abandonner. :ccool:
Pour ceux qui ont la flemme de lire et veulent un résumé : j'ai converti (depuis une VM Debian) la MBR d'une microSD en GPT grâce à gdisk, ai ou n'ai pas écrit sur le disque (incertitude), puis ai déplacé une partition pour créer de la place pour le backup de la GPT, et ai sauvé sur le disque. Mais la partition ext4 ne se monte plus et dmesg | tail renvoie "Echec de lecture du tampon de noyau". J'ai partx puis rebooté la VM sans succès.
Alors voici ce qui s’est passé dans un premier temps :
- A1. J’ai installé Raspbian Strech avec “/home” sur root “/”, et réussi à configurer les choses suivantes (je ne prends que le plus important) : modifier le pass de l’utilisateur pi, rendre le Raspi accessible en LAN (IP fixe), activer le SSH, étendre la partition root sur toute la SD.
- A2. J’ai tranquillement acquis le déplacement dans les dossier, l’édition de fichiers, certaines bonnes pratiques (visudo -f), la connexion en TTY, etc.
- A3. Ayant après coup envie de séparer boot et OS (OS sur clé USB par exemple), mais aussi de créer une partition /home séparée, je me suis mis en tête de bidouiller les partitions de la SD dans l’optique de déjà créer une nouvelle partition pour y déplacer /home, puis de réaliser les opérations pour copier sur une clé USB et éditer les config de boot. Oui, je sais, je n’ai pas pris la solution de facilité qui consistait à réinstaller Raspbian en choisissant l’option “partition /home séparée”, et j’ai décidé de faire les choses en mode “imaginons qu’un disque avec des données personnelles déjà présentes arrive dans mes mains”. Pour ça, j’ai lu beaucoup de tutos (vous balancer les liens serait inbuvable).
- A4. La première étape qui s’est imposée à moi était de convertir la MBR en GPT, afin d’obtenir des PARTUUID entre autre (nécessaires pour booter sur des nouvelles partitions).
Et voici ce qui s’est passé ensuite :
- B1. J’ai installé gdisk, et j’ai tenté immédiatement de “load MBR and build fresh GPT from it”. J’ai eu un message d’erreur me disant que la partition n°2 dépassait de 33 blocs blablabla. Je suis sorti du menu avec “q” je crois (je ne sais plus exactement, malheureusement beaucoup de choses se sont enchaînées). Le menu “q”, c’est pour sortir sans valider.
- B2. Après quelques tests (df -h, gdisk -l), il m’apparaissait que je n’avais pas réussi à convertir en GPT. Je n’avais aucun moyen de savoir si c’était dû à une possible sortie du menu sans valider, ou à un échec naturel de la conversion.
- B3. J’ai compris qu’il fallait créer un espace à la fin du support pour permettre le backup de la GPT. J’ai trouvé des infos sur comment m’y prendre : supprimer la partition n°2, et la recréer avec quelques blocs en moins pour laisser de l’espace (QUID des données à déplacer en début de partition ou pas ?). J’ai donc réalisé celà, avec l’assistant de gdisk, en prenant bien note des numéros de blocs. Là, ce coup-ci j’ai validé avec “w” (write to disk). L’écriture s’est déroulée avec succès. :yaisse2:
- B4. J’ai refait un test gdisk -l /dev/sdb, la conversion semblait bonne cette fois-ci :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 15351808 sectors, 7.3 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 7A67D414-6FD0-4749-89A8-298F8CDF880E
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 15351774
Partitions will be aligned on 2048-sector boundaries
Total free space is 8552 sectors (4.2 MiB)
Number Start (sector) End (sector) Size Code Name
1 8192 93813 41.8 MiB 0700 Microsoft basic data
2 94208 15351774 7.3 GiB 8305 Linux ARM64 root (/) |
Ah oui, j’ai omis que la première fois, j’avais utilisé le type de fichier “8300” (Linux filesystem). Après échec de montage (comme on va le voir juste après), j’ai essayé de mettre “8305” puisque la partition incriminée est celle du root.
- B5. Fort de ma réussite, j’ai donc tenté de monter les partitions : d’abord mount /dev/sdb1 /mnt/SD_Rasp_boot, le montage s’est réalisé avec succès ! J’accède à la partition de boot. Par contre, mount /dev/sdb2 /mnt/SD_Rasp me renvoie :
Code:
1
2
3
4
5
| mauvais type de système de fichiers, option erronée, superbloc erroné
sur /dev/sdb2, page de code ou programme auxiliaire manquant, ou autre erreur
Dans certains cas des renseignements utiles sont dans le journal
système — essayez « dmesg | tail » ou quelque chose du genre. |
La commande dmesg | tail me renvoie quant à elle :
Code:
dmesg: échec de lecture du tampon de noyau: Opération non permise
Voilà où j’en suis à l’heure actuelle.
Je pense que la conversion MBR to GPT s’est mal passée, et/ou que le resizing de la partition n°2 a fait planter la bonne lecture des données.
Pour moi il est impossible d’avancer plus loin, n’ayant pas les connaissances de niveau “supérieur” pouvant m’amener à investiguer. Aucune lecture aléatoire de tutos ne me permettra, à mon avis, de progresser, et je pense que ça pourrait être l’occasion pour moi comme pour vous de s’améliorer dans la restauration de données si on s’y mettait à plusieurs pour opérer (en ligne de commande bien sûr, je précise !).
Merci à ceux qui auront lu :coucou:
