J'ai eu quelques mauvaises expériences avec GRUB2 . Je pourrais dire (et avoir dit) certaines choses désagréables à propos de son processus de conception et de développement. Je n'aime particulièrement pas ses moyens de mise à jour :pour une raison quelconque, il doit mettre à jour semi-automatiquement plusieurs scripts - l'un indirectement via un autre dans une chaîne - pour chaque mise à jour du noyau - ou de nombreux autres mineurs (et apparemment sans rapport) modifications de configuration.
Cela contraste directement avec les expériences précédentes que j'ai eues avec LILO – auquel j'envisage sérieusement de revenir – car je n'ai jamais eu de problèmes avec, et sa configuration était assez simple. D'une part, si je m'en souviens, je n'avais qu'à mettre à jour (ou plutôt, il n'a jamais été mis à jour) un seul fichier texte de configuration géré simplement par mise à jour du noyau.
Alors, comment LILO fonctionne-t-il sur du matériel moderne avec les noyaux d'aujourd'hui ? Comment fonctionne GRUB ? Comment fonctionnent les autres bootloaders ? Dois-je remplir des conditions préalables ou s'agit-il simplement d'écrire le fichier de configuration et d'exécuter lilo commande comme je m'en souviens avec tendresse dans l'ancien temps ? La mise à jour du paquet du noyau (Debian/Ubuntu) met-elle à jour LILO comme elle le fait avec GRUB2 ?
Réponse acceptée :
ELILO
Gestion des chargeurs de démarrage EFI pour Linux :utilisation d'ELILO
C'est vraiment difficile pour moi de décider quelle partie de cela copier + coller parce que tout est vraiment bon, donc je vous demanderai simplement de le lire.
Rod Smith
Écrit et maintient à la fois gdisk et rEFInd .
Mais avant que vous ne le fassiez, j'aimerais faire un petit commentaire à ce sujet. Le lien ELILO ci-dessus est vers l'une des nombreuses pages sur le démarrage UEFI que vous trouverez sur rodsbooks.com écrites par Rod Smith. C'est un rédacteur technique accompli, et si vous avez déjà cherché sur Google le sujet du démarrage UEFI et que vous n'avez pas lu quelque chose de lui, c'est probablement parce que vous avez sauté plusieurs résultats.
Démarrage Linux UEFI
Fondamentalement, le noyau Linux peut être directement exécuté par le micrologiciel.
Dans le lien ci-dessus, il mentionne le chargeur de stub EFI du noyau Linux - c'est ce que vous devriez utiliser, à mon avis, car il permet au noyau Linux d'être appelé directement par le micrologiciel lui-même. Indépendamment de ce que vous faites quelque chose est exécuté par le firmware - et il semble que quelque chose est grub . Si le micrologiciel peut charger directement le noyau de votre système d'exploitation, à quoi sert un chargeur de démarrage ? Le micrologiciel UEFI monte une partition GPT au format FAT avec l'indicateur esp par la table de partition et y exécute un chemin qu'il a enregistré en tant que variable de démarrage UEFI dans un module de mémoire flash intégré. Donc, une chose que vous pourriez faire est de placer le noyau Linux sur cette partition FAT et de stocker son chemin dans cette variable de démarrage. Soudain, le noyau est lui-même chargeur de démarrage.
Bootloaders
Sur les systèmes UEFI, les bootloaders sont redondants – ELILO inclus.
Le problème que les chargeurs de démarrage ont été conçus pour résoudre était que les systèmes BIOS ne lisaient que dans le premier secteur du démarrage partition signalée et exécutez-la. Il est un peu difficile de faire quoi que ce soit de significatif avec un noyau de 512 octets, donc la chose courante à faire était d'écrire un petit utilitaire qui pouvait monter un système de fichiers où vous gardiez le réel noyau et chargez-le en chaîne.
Connexe :déterminer le shell dans le script pendant l'exécution ?
En fait, les 512 octets n'étaient souvent pas suffisants, même pour les chargeurs de démarrage. grub , par exemple, se charge en chaîne avant même de charger votre noyau en chaîne, car il bloque sa deuxième étape dans l'espace vide entre le secteur de démarrage et le premier secteur de votre système de fichiers. C'est une sorte de piratage sale - mais ça a marché.
Gestionnaires de démarrage
Par souci de simplicité de configuration, certains l'intermédiaire peut être utile.
Ce que rEFInd de Rod Smith fait, c'est se lancer en tant qu'application EFI – il s'agit d'un concept relativement nouveau. Il s'agit d'un programme qui est exécuté à partir du disque par – et qui revient vers – le firmware. Ce que fait rEFInd, c'est vous permettre de gérer les menus de démarrage, puis de renvoyer votre sélection de démarrage au firmware éxécuter. Il est livré avec des pilotes de système de fichiers UEFI – ainsi, par exemple, vous pouvez utiliser le chargeur de stub EFI du noyau sur un non-FAT partition (telle que votre /boot actuel ). Il est très simple à gérer - si une telle chose est nécessaire - et il ajoute la simplicité d'un noyau système exécutable à la commodité d'un gestionnaire de démarrage configurable.
Indirection atomique
Le noyau n'a pas besoin de liens symboliques - il peut mount --bind .
S'il y a un chemin sur votre / où vous devriez interdire les liens symboliques, c'est /boot . Un lien symbolique orphelin dans /boot n'est pas le genre de problème que vous devriez avoir à résoudre. Pourtant, c'est une pratique assez courante de configurer des indirections élaborées dans /boot par plusieurs distributions - même si c'est une idée horrible - afin de gérer les mises à jour du noyau sur place et/ou plusieurs configurations de noyau.
C'est un problème pour les systèmes EFI pas configuré pour charger les pilotes de système de fichiers (tels que ceux fournis avec le package rEFInd) parce que FAT est un système de fichiers assez stupide dans l'ensemble, et il ne les comprend pas.
Personnellement, je n'utilise pas les pilotes de système de fichiers UEFI fournis avec rEFInd, bien que la plupart des distributions incluent un package rEFInd qui peut être installé via le gestionnaire de packages et oublié d'utiliser simplement leur propre horrible lien symbolique /boot config et les pilotes de système de fichiers UEFI empaquetés de rEFInd.
Ma configuration
Une fois, j'ai écrit un ensemble d'instructions dessus et je l'ai posté ici, mais ça ressemble à :
% grep esp /etc/fstab &&
> ls /esp/EFI
LABEL=ESP /esp vfat defaults 0 1
/esp/EFI/arch_root /boot none bind,defaults 0 0
arch_root/ arch_sqsh/ arch_xbmc/ BOOT/ ipxe/
Donc je viens de mettre ces deux lignes dans mon /etc/fstab pointant vers un dossier que j'ai l'intention de contenir /boot de la nouvelle installation Linux et je suis presque fini de s'inquiéter de tout ça. Je dois aussi faire :
cat /boot/refind_linux.conf
"Arch" "root=LABEL=data rootflags=subvol=arch_root,rw,ssd,compress-force=lzo,space_cache,relatime"
En plus d'installer le refind-efi paquet via pacman pour le premier, c'est tout ce qui est nécessaire pour configurer autant d'installations/configurations distinctes que je le souhaite. Notez que la majorité de cette chaîne ci-dessus consiste en des options de montage spécifiques à btrfs spécifiées en tant que paramètres du noyau. Un /boot/refind_linux.conf plus typique ressemblerait probablement à :
"Menu Entry" "root=/dev/sda2"
Et c'est tout ce qu'il faut.
rodsbooks.com
Si vous voulez toujours ELILO, vous pouvez trouver les instructions d'installation sur le lien ci-dessus. Si vous voulez rEFInd, vous trouverez des liens vers celui-ci dans le premier paragraphe. Fondamentalement, si vous souhaitez effectuer une configuration de démarrage UEFI, lisez d'abord rodsbooks.com.
Connexe :N alternative à sed qui prend en charge Unicode ?