Au début, la barre de progression rouge sur un fond noir pendant que votre OS démarre est cool. Et puis vous réalisez qu’il s’agit certainement d’un d’hommage à Microsoft Windows !

Plus tard, vous rencontrez un problème et  l’affichage du démarrage des services, comme avant, vous aiderait bien. Heureusement, (F2) permet d’afficher les services lors du boot.

Et puis, vous rencontrez un problème plus grave encore et vous finissez par maudire cette barre de démarrage, les développeurs Redhat qui l’ont installée et ceux d’Oracle qui ont trouvé intelligent de la passer en rouge mais surtout de la garder.

Cet écran de malheur, c’est cool pour Fedora, Mint ou Ubuntu, mais pourquoi laisser ça sur un serveur ? Heureusement, « nettoyer » cette configuration est simple !

La configuration « idéale »

La configuration efficace consiste à supprimer les 2 paramètres suivant de la ligne « kernel » de votre configuration /boot/grub/grub.conf :

• rhgb signifie redhat graphic boot et indique que la séquence de boot doit être réalisé en mode graphique. C’est le nom de l’ancien package de gestionnaire graphique de boot désormais remplacé par Plymouth
• quiet signifie que les messages d’indication avant le démarrage du noyau ne s’affichent pas.

Ces 2 options supprimées, le boot s’effectue avec tous les messages qu’il faut pour déboguer des situations de crash. Vous pouvez aussi simplement supprimer ces 2 options en accédant au menu grub et en éditant la ligne kernel lors d’un démarrage.

Deux mots à propos de Plymouth

Il est possible, quoique sans doute d’un intérêt limité, de garder le démarrage en mode graphique et malgré tout afficher l’ensemble des messages des services. Il faut, pour cela, modifier le paramétrage de Plymouth. Utilisez le thème details plutôt que le thème par défaut (rings). Connectez-vous root et lancez la commande ci-dessous :

plymouth-set-default_template details --rebuild-initrd

Note:
Dans ce cas comme dans le précédent, vous modifiez la configuration grub ou du fichier initrd et donc le paramétrage est réalisé pour un unique noyau et est sujet à modification avec votre configuration grub.

Si vous êtes septique…

Vous vous dites, qu’est-ce qu’il peut m’arriver pour qu’un démarrage en mode graphique me pénalise d’aucune sorte ? Et bien, voici un exemple que tous les F2 du monde, tous les changements de kernel ou même les démarrages en mode « Rescue » ne vous permettra jamais de résoudre :

Ce problème ne laisse aucune trace ni aucun fichier d’aucune sorte et pour peut qu’il ait été généré par une erreur de plusieurs semaine en arrière, retrouver le fichier fautif est loin d’être une sinécure. Si vous êtes entêté, Google peut peut-être vous aider à en trouver la cause. Ca ne l’a pas fait pour moi et la solution n’est pas vraiment sur la première page de recherche.

En mode de démarrage idéal, la solution apparait comme par magie en grand juste avant le Kernel Panic :

Vous n’aurez sans doute aucun mal à reproduire ce problème. Pour ce qui est de vos configurations grub, vous aurez peut-être envie de la changer comme de passer le paramètre timeout à 30 ce qui vous laissera le temps de démarrer une console VNC après avoir démarré un Dom-U sous Xen, par exemple…