[Résolu] Démarrage impossible après modification disque GParted

GuiguiPX · 20-11-2018 23:39:39

Bonjour à tous! Et merci d’avance à tous ceux qui pourront m’apporter de l’aide!
Voici mon problème :
J’utilise Mint mais j’ai aussi Windows 7 sur mon ordinateur. Mon disque dur est partitionné de la sorte:
- 1 partition pour windows,
- 1 partition swap
- 1 partition pour Linux Mint
- 1 partition pour /home.

J’ai voulu augmenter ma partition swap car je souhaite augmenter ma RAM également. J’ai donc utilisé GParted pour réduire Home de 4gb pour ensuite augmenter mon swap d’autant.
Sauf que l’espace libéré n’etait pas à côté du swap actuel et que j’ai du « déplacer » mes partition home et Linux vers la droite pour ensuite pouvoir recréer un swap de 8gb. Sauf que manifestement il ne fallait pas faire ça

Désormais quand je démarre, je n’ai plus accès à rien, ni au multi boot, ni à Linux , j’ai le message suivant:

Error: file ‘/boot/grub/i386-pc/normal.mod’ not found.
Entering rescue mode...
grub rescue>_

J’ai beau arpenter les forums je ne trouve pas de réponse à mon problème et je ne me sens pas de continuer à essayer des manips au petit bonheur la chance...
Pour info j’ai accès à mes partitions en lançant une version live de Mint.

Merci d’avance à ceux qui prendront la peine de m’aider !

Dernière modification par GuiguiPX (22-11-2018 18:48:31)

raleur · 20-11-2018 23:57:42

Tu as agrandi la partition de swap ou bien tu l'as supprimée et as recréé une nouvelle partition de swap ?
Je suppose que le disque est au format DOS/MBR et que Mint utilise des partitions logiques. Quand on supprime une partition logique, les autres sont renumérotées. Si le swap était n° 5 et la racine n° 6, alors la racine doit être devenue n° 5.

A l'invite grub rescue, tape la commande "ls" pour afficher les partitions et la commande "set" pour afficher la valeur de la variable "prefix". Si je ne me trompe pas, prefix=(hd0,msdos6)/boot/grub. Pour chaque partition affichée par "ls", tape

ls (hd0,X)/

où X est le numéro de chaque partition, jusqu'à ce que ça affiche bin/ boot/ dev/ etc/... Logiquement ça devrait être X=5. Modifie la valeur de $prefix :

set prefix=(hd0,X)/boot/grub

insmod normal

normal

Cela devrait afficher le menu de démarrage. Après avoir démarré Mint, tu pourras réinstaller GRUB avec

grub-install /dev/sda

PS : si tu as supprimé et recréé le swap, tu risques aussi de rencontrer des problèmes avec la détection du swap qui a changé d'UUID. Il faudra corriger.

Dernière modification par raleur (21-11-2018 00:08:32)

GuiguiPX · 21-11-2018 09:35:25

Bonjour!

C'est exactement ça. La racine est bien devenue 5. J'ai fait ce que tu m'as dit et c'est reparti sans problème

Pour répondre à ta question j'ai bien supprimé avant de recréer le swap car je n'arrivais pas à l'agrandir directement --> résultat que tu as deviné, il n'est pas détecté

Autre petit problème restant, il me reste un petit espace non alloué de 1Mo au début de ma partition Linux dont je ne peux rien faire et qui n'était pas là avant. Rien de bien grave mais ça n'est pas très propre.. Est ce que je peux faire quelque chose pour ça? (désolé je n'arrive pas à insérer une impression d'écran de GParted)

En tout cas, merci beaucoup pour ta réponse rapide, claire et efficace!!

Dernière modification par GuiguiPX (21-11-2018 09:35:39)

raleur · 21-11-2018 09:58:50

Le swap n'est plus détecté car il a été recréé avec un nouvel UUID qui ne correspond plus à celui enregistré dans les fichiers de configuration /etc/fstab et éventuellement /etc/initramfs-tools/conf.d/resume. Il y a deux façons de restaurer la correspondance des UUID :

a) Modifier l'UUID dans les fichiers de configuration. L'UUID actuel du swap est affiché par blkid. Si tu modifies /etc/initramfs-tools/conf.d/resume, il faut aussi reconstruire l'initramfs avec "update-initramfs -u".

b) Reformater la partition de swap pour qu'elle ait le même UUID qu'avant, présent dans /etc/fstab. Il faut d'abord désactiver le swap avec "swapoff -a" si tu l'as activé manuellement puis

mkswap -U uuid-originel /dev/sdY

où /dev/sdY est la nouvelle partition de swap.

Edit : concernant l'espace non alloué de 1 Mo, il est probablement lié à la structure de la partition étendue /dev/sda2 qui contient les partitions logiques. En gros il faut une table de partition étendue (EBR) qui occupe un secteur avant chaque partition logique, et à cause de l'alignement des partitions sur des limites de blocs de 2048 secteurs (1 Mio), cela peut laisser des espaces non alloués de 2047 secteurs avant les partitions logiques. Il y a la même chose entre le MBR et la première partition, ce qui permet d'y installer une partie de GRUB.

Dernière modification par raleur (21-11-2018 10:27:40)

empanada · 21-11-2018 15:02:09

Cas très intéressant dans lequel j'ai une doute: Si GuiguiPX aurait réussi à agrandir le swap sans le supprimer (donc pas de renumération des partitions logiques)...il n'aurait pas eu le même problème?
De la solution j'entends que non, qu'il n'y aurait pas eu lieu, bien que la table des partitions ait changé (pas le numero de partitions ni leur position relative, mais oui ces positions de début et final). Mais, dans ce cas j'ai encore une doute...Pourquoi mettre la table des partitions dans la "core image" du grub?

raleur · 21-11-2018 20:58:48

empanada a écrit :

Si GuiguiPX aurait réussi à agrandir le swap sans le supprimer (donc pas de renumération des partitions logiques)...il n'aurait pas eu le même problème?

Normalement non, car a priori Gparted n'aurait pas renuméroté les partitions (j'espère) et conservé l'UUID du swap. (On ne peut pas redimensionner un swap, mais Gparted le recrée avec le même UUID). Mais avec leur numérotation dynamique, il faut toujours s'attendre à des surprises quand on manipule des partitions logique. Je les ai abandonnées depuis longtemps en faveur du format GPT qui permet de créer par défaut jusqu'à 128 partitions "normales" (équivalentes à des partitions primaires à numérotation fixe).

empanada a écrit :

Pourquoi mettre la table des partitions dans la "core image" du grub?

grub-install ne met pas la table de partition dans la core image mais le numéro de la partition qui correspond au contenu du "répertoire de boot" (/boot/grub par défaut, ou spécifié par l'option --boot-directory), lorsque celle-ci est sur le même disque que la core image. En revanche lorsque la partition de boot est sur un autre disque, c'est l'UUID du système de fichiers qui est enregistré car GRUB ne sait pas identifier un disque entier de façon fiable. Pourquoi ne le fait-il pas systématiquement ? Par souci de simplicité, je suppose.

A noter que lorsque le contenu du répertoire de boot est dans un volume "logique" (LVM, RAID, LUKS...), il me semble c'est l'identifiant persistant du volume logique qui est enregistré dans la core image.

GuiguiPX · 21-11-2018 21:32:49

raleur a écrit :

Le swap n'est plus détecté car il a été recréé avec un nouvel UUID qui ne correspond plus à celui enregistré dans les fichiers de configuration /etc/fstab et éventuellement /etc/initramfs-tools/conf.d/resume. Il y a deux façons de restaurer la correspondance des UUID :

a) Modifier l'UUID dans les fichiers de configuration. L'UUID actuel du swap est affiché par blkid. Si tu modifies /etc/initramfs-tools/conf.d/resume, il faut aussi reconstruire l'initramfs avec "update-initramfs -u".

b) Reformater la partition de swap pour qu'elle ait le même UUID qu'avant, présent dans /etc/fstab. Il faut d'abord désactiver le swap avec "swapoff -a" si tu l'as activé manuellement puis
mkswap -U uuid-originel /dev/sdY

où /dev/sdY est la nouvelle partition de swap.

Merci pour ces explications, j'ai compris. La méthode a) a parfaitement fonctionné!
Encore merci pour les explications et les étapes détaillées de résolution, vous êtes d'une efficacité redoutable!
Et me voilà sorti d'affaire \o/

deuchdeb · 22-11-2018 17:54:39

Salut GuiguiPX,

Voir le tuto : C'est résolu ! Bravo mais il faut l'indiquer dans l'titre.

GuiguiPX · 22-11-2018 19:01:39

deuchdeb a écrit :

Salut GuiguiPX,

Voir le tuto : C'est résolu ! Bravo mais il faut l'indiquer dans l'titre.

Merci j'étais en train de chercher comment faire. Et si tu as pu gagner 1 point pour un carré de chocolat grâce à moi j'en suis ravi !

empanada · 22-11-2018 20:11:54

J'avais lu ça il y a quelques semaines:
"Having embedded and/or patched the core image, grub-bios-setup will load the boot image, patch it with the first sector of the core image and also copy the existing partition table into it, and then write it to the installation device's first sector. At this point, installation is completed."
ici: GRUB 2 on a lower level. Ce la raison de ma doute.

raleur a écrit :

empanada a écrit :
Pourquoi mettre la table des partitions dans la "core image" du grub?

grub-install ne met pas la table de partition dans la core image mais le numéro de la partition qui correspond au contenu du "répertoire de boot"

C'est ce que j'ai suspecté suite à tes mots dans le message #2 mais n'était pas ce que je rappelais de cet article...donc je vois qu'il est trompé et/ou mal expliqué. Le numéro de partition (ou l'UUID selon le cas), ce n'est pas la "partition table".

raleur a écrit :

En revanche lorsque la partition de boot est sur un autre disque, c'est l'UUID du système de fichiers qui est enregistré car GRUB ne sait pas identifier un disque entier de façon fiable. Pourquoi ne le fait-il pas systématiquement ? Par souci de simplicité, je suppose

Tout du coup je me souviens que tu avais déjà dit dans un autre fil, donc implicitement c'était la aussi la réponse à ma question.
Alors si le changement fait par GuiguiPX dans la table des partitions aurait été dans un disque différent à ceci qui a le GRUB , il n'aurait pas eu soucis surement non plus, puisque les UUID seraient les mêmes, bien que les partitions logiques peuvent changer leur numération...n'est-ce pas.

raleur a écrit :

Mais avec leur numérotation dynamique, il faut toujours s'attendre à des surprises quand on manipule des partitions logique. Je les ai abandonnées depuis longtemps en faveur du format GPT qui permet de créer par défaut jusqu'à 128 partitions "normales" (équivalentes à des partitions primaires à numérotation fixe)

Oui, c'est une raison pour migrer vers GPT...si t'as besoin de plus de quatre partitions.
Je préfère rester dedans le quatre partitions, et, si non, je mets les partitions de système (quoi que ce soit le système d'exploitation) comme primaires, de façon que:
a) dans le pire des cas elles peuvent être amorcés par un MBR "générique" si elles ont la marque d'amorçage active.
b) La performance des disques c'est meilleure quand les secteurs sont le plus proches au début du disque
Dans beaucoup des cas, je n'ai pas besoin que de trois partitions , même avec un multiboot: une partition système pour debian, une autre pour Windows, et une troisième pour les données.
Comme des autres membres du forum , je suis dans la tendance de "couper" les systèmes le moins possible, et je mets tout le système dans une seule partition ext4 , même le "/home", puisque je l'utilise seulement comme une espèce de "/etc" pour utilisateurs, et je préfère garder les données dans des partitions exclusives pour données. De cette façon l'ensemble "/" c'est un tout de [système, logiciels et préférences] facilement exportable , par exemple pour clonage.
Quand au swap, pour un usage normale (oui,je sais, le mot "normale" c'est très subjectif), à partir de 4 Go je ne le vois pas nécessaire.
Et si je nécessite plus de quatre partitions, les partitions système primaires (ça permet jusqu'au trois systèmes d'exploitation dans des primaires) et le reste dans la partition étendue , et le nombre de logiques nécessaire).

J'ai une autre doute:

concernant l'espace non alloué de 1 Mo, il est probablement lié à la structure de la partition étendue /dev/sda2 qui contient les partitions logiques. En gros il faut une table de partition étendue (EBR) qui occupe un secteur avant chaque partition logique, et à cause de l'alignement des partitions sur des limites de blocs de 2048 secteurs (1 Mio), cela peut laisser des espaces non alloués de 2047 secteurs avant les partitions logiques. Il y a la même chose entre le MBR et la première partition, ce qui permet d'y installer une partie de GRUB.

"En gros il faut une table de partition étendue (EBR) qui occupe un secteur avant CHAQUE partition logique,"

Il y un EBR avant chaque partition logique? Ce n'est pas un EBR pour partition étendue?

Salut

Dernière modification par empanada (22-11-2018 20:13:40)

raleur · 22-11-2018 21:14:25

empanada a écrit :

J'avais lu ça il y a quelques semaines:
"Having embedded and/or patched the core image, grub-bios-setup will load the boot image, patch it with the first sector of the core image and also copy the existing partition table into it, and then write it to the installation device's first sector. At this point, installation is completed."

Tu as mal compris. Il s'agit de l'écriture de la boot image dans le MBR, pas de la core image. Le MBR contient la table de partition DOS.

empanada a écrit :

Alors si le changement fait par GuiguiPX dans la table des partitions aurait été dans un disque différent à ceci qui a le GRUB , il n'aurait pas eu soucis surement non plus, puisque les UUID seraient les mêmes, bien que les partitions logiques peuvent changer leur numération...n'est-ce pas.

Correct.

empanada a écrit :

Il y un EBR avant chaque partition logique? Ce n'est pas un EBR pour partition étendue?

Oui, et oui. Il y a une partition étendue imbriquée dans la précédente pour chaque partition logique, mais le noyau et les outils de gestion des partitions n'exposent que la première, celle qui contient toutes les autres.

partition étendue sda2

+ partition logique sda5

+ partition étendue cachée

  + partition logique sda6

  + partition étendue cachée

    + partition logique sda7

      etc.

empanada · 22-11-2018 22:23:05

raleur a écrit :

empanada a écrit :
J'avais lu ça il y a quelques semaines:
"Having embedded and/or patched the core image, grub-bios-setup will load the boot image, patch it with the first sector of the core image and also copy the existing partition table into it, and then write it to the installation device's first sector. At this point, installation is completed."

Tu as mal compris. Il s'agit de l'écriture de la boot image dans le MBR, pas de la core image. Le MBR contient la table de partition DOS.

T'as raison . L'article est un peu dense et l'anglais ce n'est pas ma langue maternelle .

raleur a écrit :

Il y a une partition étendue imbriquée dans la précédente pour chaque partition logique, mais le noyau et les outils de gestion des partitions n'exposent que la première, celle qui contient toutes les autres.

partition étendue sda2
+ partition logique sda5
+ partition étendue cachée
+ partition logique sda6
+ partition étendue cachée
+ partition logique sda7
etc.

Étonnante ...alors chaque fois qu'on ajoute ou supprime une partition logique, tous ces EBR's sont modifiés...

Debian-facile

#1 20-11-2018 23:39:39

[Résolu] Démarrage impossible après modification disque GParted

#2 20-11-2018 23:57:42

Re : [Résolu] Démarrage impossible après modification disque GParted

#3 21-11-2018 09:35:25

Re : [Résolu] Démarrage impossible après modification disque GParted

#4 21-11-2018 09:58:50

Re : [Résolu] Démarrage impossible après modification disque GParted

#5 21-11-2018 15:02:09

Re : [Résolu] Démarrage impossible après modification disque GParted

#6 21-11-2018 20:58:48

Re : [Résolu] Démarrage impossible après modification disque GParted

#7 21-11-2018 21:32:49

Re : [Résolu] Démarrage impossible après modification disque GParted

#8 22-11-2018 17:54:39

Re : [Résolu] Démarrage impossible après modification disque GParted

#9 22-11-2018 19:01:39

Re : [Résolu] Démarrage impossible après modification disque GParted

#10 22-11-2018 20:11:54

Re : [Résolu] Démarrage impossible après modification disque GParted

#11 22-11-2018 21:14:25

Re : [Résolu] Démarrage impossible après modification disque GParted

#12 22-11-2018 22:23:05

Re : [Résolu] Démarrage impossible après modification disque GParted

Pied de page des forums