web-dev-qa-db-fra.com

rEFInd: démarrage très lent lors de l'utilisation d'EFI Stub Loader

Après une récente réinstallation, je me suis retrouvé face à un problème très étrange avec rEFInd: alors qu'il détecte à la fois GRUB et vmlinuz sur ma partition/boot, l'utilisation de cette dernière est extrêmement lent .

Plus précisément, immédiatement après avoir sélectionné "Boot vmlinuz-4.8.0-53-generic à partir de 191 MiB ext2 volume", un écran noir s'affiche avec le texte suivant:

Starting vmlinuz-4.8.0-53-generic
Using load options 'root=UUID=6641e1e2-6829-49cc-bf88-85ba5eefbff8 ro quiet splash nomodeset vt.handoff=7 initrd=\initrd.img-4.8.0-53-generic'

Après environ une minute d'attente (!), Linux démarre normalement (et plutôt rapidement).

Si je sélectionne par contre GRUB, je suis conduit dans le menu de démarrage GRUB et, après avoir sélectionné l'option par défaut, Linux démarre immédiatement.

Quelle pourrait en être la raison?

Ma configuration comprend un SSD (sur lequel Linux et Windows sont installés) et un disque dur (où se trouve mon/home), avec une partition ext2/boot et la partition EFI (créée initialement par Windows) montée sur/boot/efi. Voici mon/etc/fstab:

UUID=6641e1e2-6829-49cc-bf88-85ba5eefbff8 /               ext4    errors=remount-ro 0       1
UUID=3c804805-c41e-4b9d-af02-118b98858ae4 /boot           ext2    defaults        0       2
UUID=8EA5-5319  /boot/efi       vfat    umask=0077      0       1
UUID=bf088ec8-140d-4829-8de7-deb1d375b0e5 /home           ext4    defaults        0       2
UUID=E2A8CA84A8CA5727 /mnt/Windows    ntfs    defaults,umask=007,gid=46 0       0
UUID=3fb0b28d-87d8-4162-b469-1c157a4d00b0 none            swap    sw              0       0
bootuefigrub-efirefind
1
fstanis

Je suis le responsable de la recherche.

Ceci est un problème de pilote de système de fichiers. Pour des raisons que je ne comprends pas parfaitement, certains pilotes de système de fichiers de rEFInd (notamment le pilote ext2_x64.efi) sont lents sur certains ordinateurs. J'ai ajouté un cache de lecture anticipée brutal au code du pilote il y a plusieurs années, ce qui a beaucoup aidé - sous VirtualBox, la vitesse est passée d'un temps de chargement d'environ 3 minutes à quelques dizaines de secondes, IIRC. Cependant, certains ordinateurs continuent à avoir des problèmes même avec ce cache.

La solution consiste à changer de système de fichiers. Le pilote ext4fs de rEFInd est beaucoup plus rapide que son pilote ext2/3fs, et les pilotes Btrfs et ReiserFS sont encore plus rapides. (Notez que le pilote ext4fs peut lire ext2fs, mais n'apportera que peu ou pas d'amélioration de la vitesse. Il doit donc lire un système de fichiers ext4 réel pour améliorer la vitesse.) Dans le pire des cas, vous pourriez utiliser FAT, qui nécessite pas de pilote spécial (intégré à tous les EFI); ou sur un Mac, vous pouvez utiliser HFS +. (Il y a aussi un pilote HFS + fourni avec rEFInd, vous pouvez donc en principe utiliser HFS + même sur un PC non Mac, mais cela ne sert à rien ou à rien.) Il est toutefois déconseillé de le faire en dehors d'un système de fichiers Linux standard. Ubuntu s'appuie sur des liens symboliques pour certaines mises à jour du noyau (mais pas toutes), ce qui rend FAT un mauvais choix. et bien que HFS + devrait fonctionner, il n’est pas officiellement pris en charge par Ubuntu. Même ReiserFS n’est pas une option dans le programme d’installation d’Ubuntu, je l’éviterais donc pour Ubuntu. Cela laisse ext4fs et btrfs.

La commutation est assez simple, mais pas sans risque - si vous faites une erreur, votre système risque de ne plus être redémarré. La procédure à nu est la suivante:

  1. Copiez le nouveau pilote de système de fichiers dans le sous-répertoire rEFInd drivers ou drivers_x64 (/boot/efi/EFI/refind/drivers ou /boot/efi/EFI/refind/drivers_x64, probablement). Supprimer l'ancien fichier ext2_x64.efi de cet emplacement réduira le temps de chargement de rEFInd d'une seconde environ.
  2. Démontez le ESP (/boot/efi).
  3. Sauvegardez la partition /boot. Vous pouvez utiliser Zip, tar, cp ou un autre outil au niveau fichier pour cela.
  4. Démontez /boot.
  5. Créez un nouveau système de fichiers sur la partition /boot.
  6. Tapez Sudo blkid /dev/sda{x} (remplacez /dev/sda{x} par l'identificateur de votre partition /boot) pour connaître sa nouvelle valeur UUID.
  7. Editez /etc/fstab pour modifier la valeur UUID et le type de système de fichiers de la partition /boot.
  8. Tapez Sudo mount -a pour monter la nouvelle partition /boot. (Il se plaindra probablement qu'il n'y a pas de point de montage /boot/efi. Vous pouvez ignorer cet avertissement.)
  9. Restaurez les fichiers /boot sauvegardés sur le nouveau système de fichiers /boot.

À ce stade, vous devriez pouvoir redémarrer et cela fonctionnera mieux. Une erreur, cependant, pourrait rendre le système impossible à démarrer. Pour réduire ce risque, vous pouvez copier au moins un noyau fonctionnel, un fichier initrd et refind_linux.conf de /boot vers /boot/efi et tester votre capacité à démarrer le noyau à partir du ESP. avant que tu commences. Cela vous donnera un moyen de secours de démarrage en cas de problème. S'il n'y a pas de problèmes, vous pouvez bien sûr supprimer le noyau de ESP une fois que vous avez terminé.

Pour plus d'informations sur les pilotes de rEFInd, consultez sa documentation à ce sujet:

http://www.rodsbooks.com/refind/drivers.html

4
Rod Smith