Écran noir au démarrage de Grub
Épilogue d’un problème que j’ai mis une bonne dizaine de jours à résoudre, si cela peut en aider d’autres.
Lors du démarrage de mon PC, depuis quelques semaines (mois ?), j’avais un écran noir assez long (1 minute lorsque je me suis décidé à m’attaquer au problème) avant l’affichage du menu Grub. Ce n’est pas la mort, ça permet d’aller aux toilettes pendant que ça démarre mais c’est assez casse-pied et ça doublait mon temps de démarrage : Papa, quand est-ce que tu règles le problème de démarrage ? Dixit mon gamin de 10 ans qui poireaute en attendant de jouer aux jeux vidéos ou de regarder des vidéos et va aux toilettes une fois que c’est démarré.
Bon, il fallait que je m’y attaque ! J’avais pour crainte que ce soit dû à ma carte mère vieillissante (bientôt 8 ans) ou un problème de matériel mal détecté au départ. C’est pourquoi, je suis allé un peu voir dans le BIOS pour vérifier les paramètres, débrancher les cartes annexes, chose qui m’a amenée à mon précédent billet. Sauf que rien de tout ça n’était à mettre en cause puisque, chose que je croyais avoir testée auparavant, le démarrage sur une clé USB ne provoque pas cet écran noir. Pour être sûr que le problème vient de Grub, on peut aussi ajouter un bip au démarrage du grub en décommentant la ligne suivante dans /etc/default/grub : GRUB_INIT_TUNE="480 440 1"
En cherchant un peu, je n’ai pas trouvé grand chose sur le net, si ce n’est un problème qui semblait similaire mais réglé indirectement ou une ouverture de bug. J’ai donc commencé à chercher un peu plus en détail dans les entrailles de Grub et en allant voir si les autres distributions installées ne mettaient pas le bazar quelque part. Il faut savoir que je travaille en général avec deux partitions de distributions par disque (une opérationnelle, Debian Stable, et une de test, Debian Testing en l’occurrence). Comme je suis passé sur un ssd il y a bien 2 ans, j’ai conservé mes partitions pour tester d’autres distributions afin de voir leur évolution ; j’ai notamment une LMDE que j’installe sur les PC de récup. Bref, j’ai donc 4 distributions sur mon PC (2 sur sda et 2 sur sdb).
Même si la cohabitation entre différentes distributions est bien plus pacifique qu’avec Windows qui tente toujours de reprendre la main, il y a quand même quelques trucs à savoir pour que tout se passe au mieux. Par exemple, je ne veux pas que la distribution de test installe son Grub, mais garder ma distribution principale comme maîtresse et par défaut donc j’empêche son installation (l’installeur me prévient que sans ça, mon système ne sera pas utilisable, oui, je sais ce que je fais). Lorsque ma machine redémarre, je repasse par ma distribution, je fais un update-grub et la nouvelle distribution apparaît dans le menu.
Une autre chose à savoir, c’est que certaines distributions (toutes ?) reformatent systématiquement la partition swap lors d’une installation, ce qui fait que la partition change d’UUID et les autres distributions ne la retrouvent pas. C’est lors du passage à SystemD que je me suis rendu compte de ça car SysVInit passait outre sans erreur critique et je vivais sans Swap (ce qui n’est pas problématique tant que la RAM ne vient pas à manquer) ; avec SystemD, on a par contre une temporisation de 1min30 au cas où la partition a besoin de temps pour être détectée. J’avais alors réglé le problème de la même façon que l’a rapporté récemment Olivyeahh.
Mais revenons à nos moutons, qu’est-ce qui cloche avec Grub ? Déjà, le update-grub mettait un certain temps, pour ne pas dire un temps certain. Celui-ci génère le fichier /boot/grub/grub.cfg qui contient les différentes lignes du menu qui va s’afficher. Quand j’ai vu que celui que j’avais sur ma distro principale faisait 1Mo (celui qui occasionnait 1min d’attente), je me suis dis que le problème venait de là. J’ai donc commencé à réinstaller grub, faire les mises à jour sur les autres distributions tout en éliminant les noyaux obsolètes, j’ai empiré le problème avec des grub.cfg qui atteignaient plusieurs Mo et un démarrage repoussé aux calendes grecques. J’avais bien entendu sauvegardé le grub.cfg initial ; d’ailleurs, on peut aussi tailler à la hache dedans pour éliminer toutes les occurrences inutiles, toute modif est temporaire puisqu’il est regénéré à chaque update-grub.
Après un appel lancé sur Diaspora*, c’est Pkadd (encore merci à lui) qui m’a donné la solution car il avait eu le même problème sur Manjaro. Pour faire bref, et parce que je ne suis pas allé voir le détail, grub-update prend en compte le grub.cfg de chaque distribution, je suppose que le fait d’avoir deux disques fait que selon qu’on soit sur l’un ou l’autre, il pense voir des choses différentes et multiplie les occurrences, ce qui augmente d’une puissance pour chaque distribution pour vite devenir exponentiel. Je ne sais pas si c’est un bug ou si le problème met du temps à venir, mais ça ne m’était pas encore arrivé et je n’ai pas trouvé beaucoup de cas similaires.
La solution est simple, lorsque le temps de boot est encore acceptable (de façon plus sale mais plus expéditive, on peut aussi supprimer tous les grub.cfg, en les renommant et d’appliquer la modif sur chaque partition depuis la distribution principale), il suffit de faire le tour de chaque distribution et d’ajouter dans chaque /etc/default/grub la ligne suivante :GRUB_DISABLE_OS_PROBER=true
suivi d’un update-grub, chose que je ferai désormais systématiquement sur les installations dont je ne veux pas du grub ; cela permet de ne recenser que la distribution de la partition sans s’occuper des autres systèmes.
Ensuite, on revient sur la distribution principale et on fait un update-grub. On apprécie alors sa légèreté (quelques Ko, au-dessus de 100Ko, c’est que le problème décrit commence à se profiler ou qu’il y a beaucoup de noyaux qui traînent). Au boot suivant, l’apparition du menu grub est instantanée.
