Salut

Sur une machine en F29 updatée depuis un F28, j'ai voulu passer au démarrage avec bls.

J'ai donc exécuté le script /sbin/grub2-switch-to-blscfg

Il a bien installé dans /boot/loader/entries les différents noyaux disponibles
Il a bien rajouté dans /etc/default/grub la ligne GRUB_ENABLE_BLS=true

Il a bien régénéré le fichier /boot/grub2/grub.cfg, dans lequel il n'y a plus les différentes entrées à présenter dans le menu,

Mais au démarrage, aucun noyau n'est présenté et je me retrouve avec le prompt GRUB>

Comme j'avais fait une copie du fichier config en grub.cfg.bon, j'ai pu démarrer grub au moyen de la directive "configfile boot/grub2/grub.cfg.bon"

Et comme je n'ai jamais réussi à faire fonctionner bls, je suis revenu à l'état antérieur.

Ma question est donc : où est-il possible de trouver une documentation précise sur comment fonctionne bls ?

Faut-il refaire un grub-install ? Le fait que ce grub ne se trouve pas sur sda est-il rédhibitoire ?

Voilà je suis perplexe.
Il y a eu combien d'updates avant F28 ?

Il est possible que tu rencontres ce bug pour commencer https://fedoraproject.org/wiki/Common_F30_bugs#GRUB_boot_menu_is_not_populated_after_an_upgrade après le forçage de l'utilisation de BLS.

Ensuite il y a eu un cas un peu similaire ne permettant pas d'utiliser BLS (d'ailleurs tu as dû voir le post), qui a conduit à ce rapport https://bugzilla.redhat.com/show_bug.cgi?id=1720829.

Concernant BLS https://systemd.io/BOOT_LOADER_SPECIFICATION il est possible d'avoir des informations complémentaires à https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault.
Oui en effet ils disent de refaire un grub2-install, ce que je n'ai pas fait, mais il semble d'après cette page que ça ne résolve pas le problème.

Bon c'était surtout par curiosité, rien ne presse.

@winmandrake: bls= boot_loader_specs
Bon j'ai trouvé la cause du souci.

Le script /sbin/grub2-switch-to-blscfg fait partie du paquet grub2 mis à jour. Dans ce paquet, le script grub2-install a aussi été modifié et il faut croire que le chargeur indique que les entrées sont à récupérer dans /boot/loader/entries.

En clair si on veut passer à l'utilisation de bls lors d'une mise à jour, il faut alors également modifier le chargeur en exécutant grub2-install /dev/xxxx

Là ça fonctionne nickel. Il va juste falloir apprendre comment rédiger les "entries".
Elles se rédigent toutes seules à l'installation des paquets kernel-core, qui dans leur script de post-install appelent le script kernel-install (un bon shell).

Question, ton menu grub au boot il liste bien les versions des kernels ? Chez moi il ne propose que le titre, donc j'ai 3 entrées "Fedora 30 (Workstation Edition)" ce qui n'est pas top. Pas encore trouvé comment configurer ce module blscfg de grub. Doit bien y avoir moyen de lui dire d'afficher la version en plus du title.

J'ai voulu tenter un grub2-install, ça ne fait pas de mal, mais j'obtiens: 
[root@taran entries]# grub2-install 
grub2-install : erreur : /usr/lib/grub/x86_64-efi/modinfo.sh n'existe pas. Veuillez utiliser --target ou --directory.
A priori normal vu que je suis en EFI.

Bref le passage vers BLS ne se fait pas en douceur...
Alors lors d'une installation fraîche, le passage à bls est invisible.

En revanche lorsqu'on fait un upgrade, le grub2-install n'est pas exécuté, et spécialement dans la mesure où le passage à bls n'est pas obligatoire ni même proposé. Si on découvre cette possibilité et qu'on le fait, il faut exécuter grub2-install (celui qui a été installé par l'upgrade, mais pas exécuté).

Celà dit ce n'est pas un bon choix et je viens de tout virer. En effet, osprober met le bazar, on ne sait pas comment rédiger un chainloader ni même si c'est possible. Donc marche arrière toute. Jusqu'à plus ample informé ce système n'est pas du tout destiné à un multiboot.
@nouvo09, à voir s'il y a un rapport de bug en ce sens du coup.

@madko, tu n'as pas précisé la destination.
Sinon j'ai les entrées de kernel détaillées sur la page du GRUB.

Si tu fais la commande suivante tu auras le kernel utilisé 
# grubby --default-kernel
Puis à voir si tu as la section title renseignée avec la commande 
# grubby --info <résultat_commande_précédente>
@ madko:
lors de l exécution du script /sbin/grub2-switch-to-blscfg, le grub2-mkconfig modifié, inscrit dans /etc/default/grub qu'il doit utiliser blscfg. Et de ce pas, il va régénérer un grub.cfg, qui va chercher dans /boot les noyaux disponibles et créer pour chacun un fichier dans /boot/loader/entries. Et c'est là que le nouveau grub modifié par grub-install viendra les lire pour les afficher au boot.

Vérifie aussi ta version de grub2-tools. Moi j'ai grub2-tools-2.02-62.fc29.x86_64
Nicoss wrote:à voir s'il y a un rapport de bug en ce sens du coup.
Je ne pense pas que ce soit un bug, mais un feature.
Erreur de copier/coller j'avais bien mis la destination pour le grub2-install, qui après avoir installé un paquet manquant (grub2-efi-tools ou qqchose dans le style), me dit que je ne dois pas faire de grub2-install car je suis en EFI. Désolé de ne pas avoir été assez clair.

Pour résumé, le nouveau grub qui n'en est pas un, a juste en module en plus, qui est le blscfg.mod. Le nouveau grub.cfg charge juste ce module. Ce module a pour unique tache d'aller à la recherche des fichiers dans /boot/loader/entries. Ainsi tout est dynamique, le fichier grub.cfg n'a plus à être mis à jour à chaque kernel. Et du coup, grubby partira à la retraite.

Dans mes fichiers entries j'ai bien le titre qui ne contient que "Fedora 30 (Workstation Edition)" pour chaque kernel. J'ai ensuite un champ version qui contient bien la version du kernel. J'aimerais donc trouver comment faire comprendre à grub ou au module blscfg d'afficher "$title-$version" au lieu de juste "$title". A suivre.
Le résultat de la commande avec aurait été plus clair...

Pour info j'ai 
grubby --info /boot/vmlinuz-5.1.12-300.fc30.x86_64
index=0
kernel="/boot/vmlinuz-5.1.12-300.fc30.x86_64"
args="ro rd.lvm.lv=Fedora_LVM/System elevator=noop"
root="/dev/mapper/Fedora_LVM-System"
initrd="/boot/initramfs-5.1.12-300.fc30.x86_64.img"
title="Fedora (5.1.12-300.fc30.x86_64) 30 (Thirty)"
id="c1d8c70102204fc49425c30228b0a846-5.1.12-300.fc30.x86_64"
Alors est-ce que tu auras une entrée complète lors du prochain kernel ?
Pour continuer dans la curiosité:
[root@taran entries]# ls /boot/
5a68123777134e458e146023b9704f82  efi  elf-memtest86+-5.01  extlinux  grub2  initramfs-0-rescue-5a68123777134e458e146023b9704f82.img  loader  lost+found  memtest86+-5.01  vmlinuz-0-rescue-5a68123777134e458e146023b9704f82
[root@taran entries]# rpm -ql kernel-core|grep boot
/boot/.vmlinuz-5.1.7-300.fc30.x86_64.hmac
/boot/System.map-5.1.7-300.fc30.x86_64
/boot/config-5.1.7-300.fc30.x86_64
/boot/initramfs-5.1.7-300.fc30.x86_64.img
/boot/vmlinuz-5.1.7-300.fc30.x86_64
/boot/.vmlinuz-5.1.8-300.fc30.x86_64.hmac
/boot/System.map-5.1.8-300.fc30.x86_64
/boot/config-5.1.8-300.fc30.x86_64
/boot/initramfs-5.1.8-300.fc30.x86_64.img
/boot/vmlinuz-5.1.8-300.fc30.x86_64
/boot/.vmlinuz-5.1.11-300.fc30.x86_64.hmac
/boot/System.map-5.1.11-300.fc30.x86_64
/boot/config-5.1.11-300.fc30.x86_64
/boot/initramfs-5.1.11-300.fc30.x86_64.img
/boot/vmlinuz-5.1.11-300.fc30.x86_64
/boot/.vmlinuz-5.1.12-300.fc30.x86_64.hmac
/boot/System.map-5.1.12-300.fc30.x86_64
/boot/config-5.1.12-300.fc30.x86_64
/boot/initramfs-5.1.12-300.fc30.x86_64.img
/boot/vmlinuz-5.1.12-300.fc30.x86_64
Pourtant rpm -qV kernel-core ne dit rien.

Sinon je ne pense pas que les entrées seront plus complètes au prochain boot, je n'ai rien fait.

ps: grubby comme dit sera vite déprécié avec bls:
[root@taran entries]# grubby --info /boot/vmlinuz-5.1.12-300.fc30.x86_64
The param /boot/vmlinuz-5.1.12-300.fc30.x86_64 is incorrect
[root@taran entries]# uname -a
Linux taran.in.noisy.linuxed.net 5.1.12-300.fc30.x86_64 #1 SMP Wed Jun 19 15:19:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@taran entries]#
Et dans 
# cat /boot/loader/entries/*-5.1.12-300.fc30.x86_64.conf
title Fedora (5.1.12-300.fc30.x86_64) 30 (Thirty)
version 5.1.12-300.fc30.x86_64
linux /vmlinuz-5.1.12-300.fc30.x86_64
initrd /initramfs-5.1.12-300.fc30.x86_64.img
options $kernelopts
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel
Là c'est le bordel:
[root@taran entries]# cat 5a68123777134e458e146023b9704f82-5.1.12-300.fc30.x86_64.conf 
title      Fedora 30 (Workstation Edition)
version    5.1.12-300.fc30.x86_64
machine-id 5a68123777134e458e146023b9704f82
options    BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.1.11-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.1.8-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.1.7-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.1.6-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.1.5-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.1.4-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.0.17-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.0.16-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.0.14-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.0.13-300.fc30.x86_64/linux BOOT_IMAGE=(hd0,gpt5)/5a68123777134e458e146023b9704f82/5.0.11-300.fc30.x86_64/linux BOOT_IMAGE=/vmlinuz-5.0.10-300.fc30.x86_64 root=/dev/mapper/taran-root ro resume=/dev/mapper/taran-swap rd.lvm.lv=taran/root rd.lvm.lv=taran/swap rhgb quiet reboot=efi i915.fastboot=1
linux      /5a68123777134e458e146023b9704f82/5.1.12-300.fc30.x86_64/linux
initrd     /5a68123777134e458e146023b9704f82/5.1.12-300.fc30.x86_64/initrd
Mais c'est intéressant de voir que toi ton title est bon.

J'ai aussi les options qui sont bizarres
On est bien d'accord.
Et lorsqu'on fait un grub2-mkconfig, grub ne sait pas quoi faire avec le résultat de os-prober qu'il stocke dans la rubrique 30 et qui provoque un plantage au démarrage.

Donc on cherche encore l'intérêt de ce "truc" hormis le fait qu'il sait booter tous les unixlike.
Que ce soit sur une machine installée toute propre de F30 ou une migration F29->F30 j'ai les mêmes résultats dans le fichier entries.

Par contre elles sont toutes issues d'une installation de version Fedora Server avec une utilisation Bureau ou Serveur selon les machines. Mais je ne pense pas que la version Workstation entraîne des différences de ce genre.
Je pense que ce qui a foutu le bordel dans mes entries c'est le fait d'être passé par la rawhide avant la sortie de la 30.

Dans ton grubenv tu retrouves bien le kernelopts ?
Tout à fait 
# cat /boot/grub2/grubenv 
# GRUB Environment Block
saved_entry=c1d8c70102204fc49425c30228b0a846-5.1.12-300.fc30.x86_64
kernelopts=root=/dev/mapper/Fedora_LVM-System ro rd.lvm.lv=Fedora_LVM/System
boot_success=1
boot_indeterminate=0
###################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################