|
|
|
Grub2 perturbé par réparation de W7
| ||||||||
Astucien  | Bonjour, Mon PC comporte deux disques durs dont le premier comporte trois partitions :
Windows 7 est installé sur le second disque dur. A l'origine, la partition étendue /dev/sda3 ne contenait que les deux partitions (logiques) de Squeeze (/racine et /home) qui étaient alors identifiées respectivement /dev/sda5 et /dev/sda6 ; mon disque se présentait alors comme ceci :
Ensuite, j'ai réduit la partition de stockage /dev/sda2 (primaire) d'une dizaine de Go pour y installer LinuxMint Debian (LMDE) dont les partitions /racine et /home ont été identifiées respectivement /dev/sda7 et /dev/sda8 Enfin, j'ai encore réduit la partition de stockage /dev/sda2 d'une dizaine de Go pour y installer ArchLinux dont les partitions /racine et /home ont été identifiées /dev/sda9 et /dev/sda10. Au finale, la partition étendue /dev/sda3 contenait de gauche à droite /dev/sda9, /dev/sda10, /dev/sda7, /dev/sda8 et tout à droite /dev/sda5 et /dev/sd6 - pour être plus clair : 9,10,7,8,5,6 C'était un peu illogique mais ça marchait, le bootloader étant géré par Squeeze (Grub2). Voici quelques semaines, j'ai voulu désinstaller Commodo Firewall de Windows XP car il bloquait la mise à niveau 2012 de Avira Antivir Premium. Cette tentative de désinstallation a foiré et provoqué des dysfonctionnements qui m'ont amené à réinstaller WinXP avec une image Acronis prise peu avant l'installation de Seven. Ce faisant, le bootloader initial de XP a remplacé celui de Grub2 de sorte qu'au démarrage, je n'avais plus accès qu'à WinXP. Grâce au disque de réparation de Seven, j'ai rétabli le bootloader permettant le choix entre Windows 7 (réparé) et "une "ancienne version de Windows", puis grâce au CD d'installation de Squeeze en mode rescue, j'ai rétabli le bootloader initial avec grub2.
Bref, tout semblait rentré dans l'ordre ... sauf que je n'arrivais plus à booter Archlinux. A l'analyse, il s'est avéré qu'au cours des opérations de réparation de XP et/ou Seven, la désignation des partitions logiques avait été modifiée en ce sens que leurs désignations avaient été remises dans un ordre logique (5,6,7,8,9,10).
Bref, les partititions d'Archlinux était dorénavant désignées /dev/sda5 et /dev/sda6 au lieu de /dev/sda9 et /dev/sda10. Normalement, l'opération "update-grub" exécutée sous Squeeze aurait dû générer un grub.cfg prenant en compte cette modification, ce qui semblait être le cas car le menu (voir capture d'écran du menu de démarrage) confirme que Archlinux se trouve bien sur /dev/sda5. Or, rien à faire, chaque tentative de booter Archlinux plantait. Finalement, j'ai examiné grub.cfg et j'ai constaté ceci :
Il en résulte que Grub2 localise ArchLinux sur /dev/sda5 (ce qui est correct) mais qu'en revanche il situe la partition racine (root) sur /dev/sda9 (désignation antérieure de son emplacement et qui est maintenant l'emplacement de la racine de Squeeze). Ce qui est étonnant, c'est que l'UUID de recherche (search) est bel et bien celle de /dev/sda5 et que sauf erreur /dev/sda/msdos6 (set root) correspond aussi à /dev/sda5 Quelle que soit la distribution avec laquelle j'exécute "update-grub", j'obtiens ce résultat. Il n'est pas très compliqué de rectifier le tir, mais j'aimerais quand même savoir pourquoi cette discordance apparaît. Merci d'avance et désolé d'avoir été long. Amicalement,
| |||||||
Publicité | ||||||||
|
| ||||||||
 Astucien | Salut Mimile, je pense que tu dois rectifier manuellement le /boot/grub/grub.cfg de Squeeze afin qu'il te permette de démarrer tous tes systèmes sans problème. Cela implique de corriger /etc/fstab de chacune des distributions Linux. Je viens de lire sans comprendre le fichier /etc/grub.d/30_os-prober sous Debian Wheezy/Sid. Je ne sais pas à quoi ce script se réfère pour déterminer les systèmes à démarrer. Je pense que si tu as Grub d'installé sous ArchLinux, tu devrais lui faire faire grub-mkconfig -o /boot/grub/grub.cfg et vérifier si tout concorde dans le fichier /boot/grub/grub.cfg d'ArchLinux. Faire de même pour toutes les distributions Linux installées. Si Grub de Squeeze se réfère au fichier grub.cfg des autres distributions Linux pour créer le sien, il est de mise que ces fichiers soient cohérents avec ta nouvelle table de partitions. Un fstab cohérent est aussi indispensable. Peut-être que la commande blkid exécutée sur chaque distribution te dira si tout concorde. Puis refaire update-grub sous Squeeze. Si rien ne marche, peut-être que désinstaller (purge) Grub2 sous Squeeze et le réinstaller peut aider. J'essai de ne pas déplacer de partition vers la gauche, encore moins une partition étendue. Entre autres conséquences, il faut déplacer des données. Ton expérience démontre la complexité de maintenir les numéros des partitions représentatifs de leurs positions sur le disque. En plus, cela demande de modifier au moins le chargeur et fstab. Pour utilisateurs expérimentés seulement. Édition: je pense t'avoir déjà suggéré comme possibilité dans un autre message de désactiver /etc/grub.d/30_os-prober sous Squeeze et d'utiliser /etc/grub.d/40_custom afin de te créer manuellement des entrées valides.
Modifié par Logicien le 04/05/2012 18:50 | |||||||
| Astucien | Bonjour Paul, Merci de venir une fois de plus à mon aide. Précision préalable : j'utilise le grub2 de Squeeze pour l'excellente raison que son CD d'installation permet facilement (en mode rescue) de restaurer le MBR qui aurait été modifié par l'installation d'une autre distribution. Les fichiers fstab de chacune de mes quatre distributions sont basés sur les UUID et non par les désignations /dev/sd? Pour le surplus :
Effectivement et c'est cette méthode que j'utilise à chaque fois qu'il y a installation d'un nouveau noyau sur l'une de mes partitions (sauf Archlinux) qui n'ajoute pas son nouveau noyau à l'ancien mais écrase purement et simplement celui-ci de sorte q'il n'y a pas nécessité de modifier le bootloader. En effet, grub.cfg ne se préoccupe pas de l'identification du noyau d'Arch : il se contente d'indiquer son emplacement :
tandis que les distributions type Debian précisent le n° du noyau :
Et quand LMDE a changé de noyau, il a automatiquement exécuté update-grub si bien que je me suis retrouvé avec le menu Grub2 de LMDE et Lenny qui apparaissait six fois ! Je reviens donc au réel sujet de mon poste : Pourquoi diable Grub2 (quelle que soit la distribution Squeeze ou LMDE) persiste-t'il à situer le noyau d'Arch (vmlinuz-linux) en /dev/sda9 alors qu'au niveau du menuentry et de la racine, il les situe bien en /dev/sda5 ? SI on réfléchit bien : à l'origine, Squeeze occupait /dev/sda5 et sda6 et Arch occupait /dev/sda9 et sda10. Quand Win7 a réorganisé les partitions logiques, les désignations se sont inversées : Squeeze s'est retrouvé (dans les mêmes partitions mais désignées /dev/sda9 et sda10 tandis que Arch s'est retrouvé dans les mêmes partitions mais désignées /dev/sda5 et sda6 (en fait, il n'y a que LMDE qui a gardé ses partitions d'origine /dev/sda7 et sda8). SI Grub2 est perturbé par ce changement de désignation, pourquoi cela n'affecte-t'il pas aussi Squeeze ? Tu me diras que dans la mesure où c'est le Grub2 de Squeeze que j'utilise, il retrouve fatalement et sans ambiguïté ses propres partitions. Mais quand j'ai ré-installé LMDE (mise à jour avortée) dans les mêmes partitions qu'elle occupait auparavant, son Grub2 a bien identifié les partitions de Squeeze mais a commis la même erreur quant aux partitions d'Arch. Il y a là un mystère qui reste entier pour moi.
Modifié par Mimile le 06/05/2012 11:57 | |||||||
| Astucien | Jette un coup d'oeil sur un moteur de recherche, le noyau d'ArchLinux a de la difficulté à démarrer lorsqu'on lui donne la partition racine par UUID en paramètre. Je pense que les éditeurs de partitions Linux que tu as utilisés ont bien fait leur travail. Tu avais Squeeze qui occupait tout l'espace de la partition étendue 5 et 6. Puis tu as agrandi vers la gauche, Lmde, 7 et 8 et finalement un deuxième agrandissement vers la gauche pour ArchLinux, 9 et 10. En respectant l'ordre de création de gauche à droite et par numéros croissants des partitions que suivent par défaut les éditeurs, ta partition étendue contient du premier au dernier secteur, trois groupes descendant contenant chacun deux partitions ascendantes.
Tu admettras que Windows n'est pas le mieux placé pour renuméroter des partitions Linux. Par curiosité autant que pour trouver la cause de ton problème, j'aimerais voir la sortie de la commande blkid -o full Assure-toi aussi que cette sortie est la même sur Squeeze, Lmde et ArchLinux. Libre à toi évidemmement. Je te recommande aussi de vérifier /etc/default/grub de Squeeze et de désactiver root=UUID # Uncomment if you want GRUB to pass to the Linux kernel the old parameter Je pense que c'est nécessaire pour ArchLinux. Puis refaire update-grub
Modifié par Logicien le 07/05/2012 07:49 | |||||||
| Astucien | Bonjour, voici le résultats des blkid -o full de chacune de mes distributions : Archlinux :
LMDE :
Lenny :
Squeeze :
A priori, chaque distributions identifie de manière identique les différentes partitions. Pour le surplus, en résumé : - je suis passé sous Squeeze - j'ai réactivé : chmod +x /etc/grub.d/{10_linux,20_linux_xen,25_memtest86+,30_os-prober} (qui étaient désactivés conformément à tes indications pour résoudre mon problème avec la localisation d'Arch - j'ai désactivé 40_custom pour qu'il n'interfère pas - j'ai modifié /etc/default/grub en décommentant la ligne GRUB_DISABLE_LINUX_UUID=true dans /etc/default/grub - j'ai exécuté update-grub qui m'a fournit le grub.cfg que voici (extrait concernant les menuentry) :
Toujours ce problème de décalage entre /dev/sda5 et /dev/sda9 ... Ce qui est bizarre, c'est que Grub continue d'identifier les partitions "search" avec leurs UUID malgré GRUB_DISABLE_LINUX_UUID=true NB : En ce qui concerne le démarrage d'Arch qui serait problématique en indiquant l'UUID de son image, personnellement, je n'ai jamais rencontré de difficulté (après correction de son emplacement : remplacé /dev/sda9 par l'UUID de /dev/sda5 tel que cela apparaît dans les différents résultats blkid qui précèdent).
Modifié par Mimile le 07/05/2012 12:07 | |||||||
| Astucien | Dans le cas où tu ne crées pas d'entrées manuelles dans 40_custom, tous les autres scripts dans /etc/grub.d doivent avoir le droit d'excécution. Tu peux même laisser 40_custom exécutable en principe. C'est mieux de le désactiver. C'est bien un mystère. Compare la sortie de la commande dumpe2fs -h /dev/sda5 | less dans tes distributions. Regarde le contenu des fichiers /etc/blkid.tab et /etc/blkid.tab.old dans tes distributions afin de voir s'il n'y aurait pas erreur. Tu peux supprimer ces fichiers dans toutes tes distributions Linux. Le fichier /etc/blkid.tab est recréé imédiatement par l'exécution de la commande blkid . Regarde et supprime tous les fichiers /boot/grub/grub.cfg* et /boot/grub/menu.lst* que tu trouves sous tes distributions Linux ainsi que tout contenu que tu as créés dans /etc/grub.d/40_custom. Peut-être se cache-il quelque-part un sda9 associé à ArchLinux auquel Squeeze se réfère. Pour finir exécute sous squeeze update-grub2 Modifié par Logicien le 07/05/2012 12:07 | |||||||
| Astucien | Cher Paul, Je suis fort occupé par le boulot ces moments-ci et je manque de temps pour effectuer les manips que tu suggères. Je veillerai à te répondre dès que possible. Amicalement,
| |||||||
| ||||||||
Les bons plans du moment PC Astuces | Tous les Bons Plans | ||||||||||||||||||
| |||||||||||||||||||
| Forum PC Astuces | © 1997-2024 Webastuces |  |
À LA UNE
PRATIQUE
LOGITHÈQUE
TABLETTE ET MOBILE
BONS PLANS
FONDS D'ÉCRAN
JEUX
FORUM
