Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 21-11-2018 00:39:39

GuiguiPX
Membre
Distrib. : MINT 19 TARA
Noyau : Linux version 4.15.0-20-generic
(G)UI : Cinnamon
Inscription : 20-11-2018

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

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 smile
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 19:48:31)

Hors ligne

#2 21-11-2018 00:57:42

raleur
Membre
Inscription : 03-10-2014

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

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 01:08:32)

Hors ligne

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

GuiguiPX
Membre
Distrib. : MINT 19 TARA
Noyau : Linux version 4.15.0-20-generic
(G)UI : Cinnamon
Inscription : 20-11-2018

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

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 big_smile
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é sad

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!! big_smile big_smile big_smile

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

Hors ligne

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

raleur
Membre
Inscription : 03-10-2014

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

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 11:27:40)

Hors ligne

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

empanada
Membre
Distrib. : Debian 9 (Stretch)
Noyau : 4.9.0-7-amd64
(G)UI : LXDE
Inscription : 19-09-2018

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

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?

"blues are the roots and the other musics are the fruits" . Willie Dixon

Hors ligne

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

raleur
Membre
Inscription : 03-10-2014

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

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.

Hors ligne

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

GuiguiPX
Membre
Distrib. : MINT 19 TARA
Noyau : Linux version 4.15.0-20-generic
(G)UI : Cinnamon
Inscription : 20-11-2018

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

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 smile  \o/

Hors ligne

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

deuchdeb
Moderato ma non troppo
Lieu : Ca va bouger
Distrib. : Debian 10 Buster
Noyau : Noyau stable
(G)UI : KDE Plasma 5.14
Inscription : 13-01-2010

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


Une fleur, c'est magique non? smile
Association Debian Facile

Hors ligne

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

GuiguiPX
Membre
Distrib. : MINT 19 TARA
Noyau : Linux version 4.15.0-20-generic
(G)UI : Cinnamon
Inscription : 20-11-2018

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



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 ! lol

Hors ligne

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

empanada
Membre
Distrib. : Debian 9 (Stretch)
Noyau : 4.9.0-7-amd64
(G)UI : LXDE
Inscription : 19-09-2018

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

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 21:13:40)


"blues are the roots and the other musics are the fruits" . Willie Dixon

Hors ligne

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

raleur
Membre
Inscription : 03-10-2014

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

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.
 

Hors ligne

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

empanada
Membre
Distrib. : Debian 9 (Stretch)
Noyau : 4.9.0-7-amd64
(G)UI : LXDE
Inscription : 19-09-2018

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

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 kernal_panic.gif. L'article est un peu dense et l'anglais ce n'est pas ma langue maternelle sad .

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 yikes ...alors chaque fois qu'on ajoute ou supprime une partition logique, tous ces EBR's sont modifiés...


"blues are the roots and the other musics are the fruits" . Willie Dixon

Hors ligne

Pied de page des forums