Translation(s): English - Français

Configurer les couleurs du menu

Depuis Debian Wheezy, il n'y a plus de support pour modifier facilement les couleurs du menu graphique. /etc/default/grub n'a aucune variable qui puisse les configurer.

La façon la plus simple pour cela est de créer un nouveau fichier /boot/grub/custom.cfg et d'y ajouter votre configuration.

Exemple :

set color_normal=light-gray/black

Les variables contrôlant les couleurs du menu sont les suivantes :

Si vous configurez /boot/grub/custom.cfg, il n'est pas nécessaire de lancer la commande update-grub ; le fichier sera automatiquement chargé par /boot/grub/grub.conf au démarrage.

Configurer la splashimage

Depuis Bullseye, la splashimage est déterminé d'après l'ordre suivant :

Donc, mettre le fichier image de votre choix dans /boot/grub/ est la méthode la plus simple.

Si vous devez utiliser grub2-splashimages, faites ce qui suit.

aptitude install grub2-splashimages

Exemple :

GRUB_BACKGROUND="/usr/share/images/grub/Lake_mapourika_NZ.tga"

Voir aussi Grub/SplashImage (en anglais), GrubEFIReinstall (en anglais)

Configurer un répertoire /boot chiffré

Grub 2.02~beta2-29 prend en charge la lecture d'une partition /boot chiffrée.

En supposant que vous ayez déjà un système chiffré tel que configuré par l'installateur Debian :

  1. ajoutez GRUB_ENABLE_CRYPTODISK=y à /etc/default/grub

  2. faites une sauvegarde du contenu de votre partition /boot

  3. créez un container LUKS là où se trouve votre partition /boot et déverrouillez-là

  4. créez un système de fichier ext2 dans votre container LUKS et montez-le comme /boot

  5. restaurez la sauvegarde de votre partition /boot dans votre nouveau /boot chiffré

  6. exécutez les commandes grub-install et update-grub

Configuration / choix d’un noyau autre que celui par défaut ou plus ancien pour l’amorçage

Définissez GRUB_DEFAULT dans /etc/default/grub à une valeur autre que 0. Une bonne description se trouve dans les documents officiels Grub avec des exemples à l'adresse GRUB # Simple-configuration. Si SUBMENU n'est pas désactivé, utilisez le caractère '>' comme une touche d'entrée, par exemple, si vous voulez choisir la seconde entrée du menu (premier écran) et la troisième entrée du noyau dans le sous-menu (second écran), utilisez GRUB_DEFAULT=1>2. Rappelez-vous que les entrées dans grub2 commencent avec le compteur à 0.

Si vous avez modifié le fichier de configuration grub /etc/default/grub, assurez-vous d’exécuter update-grub pour mettre à jour sa configuration.

Démarrage UEFI vs BIOS

GRUB prend en charge le démarrage des systèmes x86 via la méthode BIOS traditionnelle (alias « Legacy » ou « CSM »), ou plus moderne UEFI (en anglais). La façon dont ils démarrent est assez différente, mais dans la plupart des cas, le résultat final devrait être pratiquement invisible pour l'utilisateur. Voici une comparaison de la façon dont chacun fonctionne.

Avec le BIOS

Le premier secteur est important - c'est ainsi que les PC démarrent. Le firmware est très stupide - il charge simplement le premier secteur et exécute directement le code à partir de celui-ci. Voir Master boot record pour plus d'informations sur la mise en page exacte.

Il n'y a pas beaucoup d'espace dans le premier secteur, juste assez pour la table de partition et un tout petit espace amorçable. Ce dernier en sait juste assez pour pouvoir localiser et charger le chargeur de deuxième niveau (alias GRUB core).

Le chargeur de deuxième niveau s'insère dans l'espace entre le premier secteur et la première partition. Sur la plupart des systèmes modernes, la première partition commencera à 1 Mio sur le disque, il y a donc un peu moins de 1 Mio d'espace pour le noyau GRUB. C'est beaucoup plus d'espace que le secteur de démarrage, mais c'est encore assez limité. Il intègre les principaux éléments du code GRUB : généralement des éléments clés comme le code pour lire différents stockages systèmes, partitionnements et systèmes de fichiers. Il dispose également d'un chargeur de module.

Les systèmes plus anciens qui ont un espace de partition plus petit ici deviennent de plus en plus difficiles à prendre en charge dans GRUB - l'espace devient de plus en plus restreint à mesure que le code de base se développe et que de nouvelles fonctionnalités sont ajoutées.

Le noyau localisera le répertoire /boot/grub comme indiqué par sa configuration, puis chargera potentiellement toutes sortes de fonctionnalités GRUB supplémentaires à partir des modules qu'il contient.

Finalement, GRUB chargera un noyau et initramfs et démarrera le noyau.

Avec UEFI

Dans UEFI, le firmware est beaucoup plus intelligent. Au lieu de simplement charger un secteur brut à partir du disque et d'exécuter du code directement à partir de celui-ci, le micrologiciel inclut une prise en charge (limitée) du stockage et des systèmes de fichiers. Cela permet de nombreuses autres options utiles au démarrage.

En définissant les variables de démarrage UEFI, le micrologiciel peut être configuré avec une liste de différents programmes UEFI pour tenter de charger et de démarrer. S'il ne trouve rien dans les emplacements de démarrage configurés, le micrologiciel reviendra à un emplacement codé en dur : le dénommé chemin de support amovible.

Pour plus de sécurité, le micrologiciel peut également être configuré pour autoriser uniquement l'exécution de programmes EFI signés avec des clés connues du micrologiciel (alias SecureBoot (en anglais)).

Pour GRUB, UEFI supprime bon nombre des anciennes limitations du BIOS. Il n'y a pas besoin de chargeurs comme GRUB. Au lieu de cela, le micrologiciel charge et exécute GRUB en tant que programme UEFI standard (généralement "grubx64.efi" sur une plateforme PC 64 bits).

La façon par défaut de configurer GRUB pour UEFI consiste à installer le noyau GRUB ici. Tout comme dans le cas de l'amorçage avec le BIOS, il peut alors trouver /boot/grub et charger des modules pour des fonctionnalités supplémentaires.

Dans le cas SecureBoot, cependant, le binaire GRUB EFI est différent. Comme GRUB n'inclut pas (encore !) de support pour les modules signés, il ne peut pas vérifier les modules qui pourraient être chargés ultérieurement. Donc, dans ce cas, le chargeur de module est désactivé. Tous les modules qui pourraient être nécessaires sont plutôt intégrés à un binaire monolithique plus grand qui peut être signé. Au moment de l'exécution, ce seul binaire est tout ce qui s'exécutera.