Une petite astuce - pour ne pas laisser filer - concernant Grub :
Il y a quelques semaines, un changement « majeur » a été annoncé pour Grub, du fait que par défaut les autres OS installés sur le même ordinateur ne seront plus détectés et donc encore moins affichés dans le menu de Grub. C’est effectif sur Sid, et le deviendra à terme sur Stable.
Avec des droits admins|root :
⇒ Pour réactiver cette option - attention pour des raisons de sécurité dues à des failles dans os-prober, ce n’est pas recommandé - il est nécessaire :
d’éditer le fichier /etc/default/grub pour y ajouter l’option GRUB_DISABLE_OS_PROBER=false - par exemple, en fin de fichier.
⇒ ou configurer soit-même en éditant le fichier /etc/grub-d/40_custom pour ajouter les informations adéquates - voire le post ci-dessous
Pour finir, exécuter le binaire update-grub pour que Grub détecte à nouveau ledit(s) OS et les affiche dans son menu au démarrage de votre machine.
Mais, du coup, il ne faudrait pas s’assurer que le paquet os-prober soit installé ?
Logiquement, il ne devrait plus être installé automatiquement si les autres OS n’apparaissent plus.
Raison invoquée : possibles failles de sécurité dans les scripts de détection d’os-prober.
Ou bien en profiter pour abandonner os-prober, qui n’est pas sans défauts, et ajouter soi-même la prise en charge des autres systèmes installés dans /etc/grub.d/40_custom. Ce n’est pas très compliqué, par exemple :
Et, bien non ce n’est pas si simple - car il faut connaître en premier l’UUID concernant la partition où se trouve le système d’exploitation, et ensuite il faut adapter l’exemple que tu mentionnes - donc, je corriges l’exemple que tu donnes et en sus j’en donnerais pour Windows.
En admettant que la partition où se situe l’OS en question soit sur le premier ou seul disque dur, tel que /dev/sda, et soit la troisième, soit /dev/sda3 :
Sauf si Windows a été installé en UEFI, il faut cibler la partition UEFI !
Puis concernant le fichier 40_custom dans le répertoire /etc/grub.d, il faut ajouter :
menuentry "Windows" --class windows --class os {
insmod ntfs # à commenter si UEFI
search --no-floppy --set=root --fs-uuid COPIEZ-UUID
ntldr /bootmgr # à commenter si UEFI
# chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi # à décommenter si UEFI
}
PS : j’ai essayé de nommer le fichier tel que 20_windows et de le sourcer dans le fichier 40_custom, mais l’entrée ne se fait pas dans Grub - cf le fichier README.
Et, pour finir, bien sûr, exécuter upgrade-grub
Voilà !
Là, l’information utile est complète.
PS : Donc, non ce n’est pas simple, loin s’en faut car il ne faut pas se tromper d’UUID, de type de partition, etc…
PS 2 : j’ai modifié le premier post en conséquence !
Je n’ai pas écrit que c’était simple, seulement que ce n’est pas très compliqué.
On peut aussi utiliser la commande grub-probe fournie par GRUB, dont la sortie est au format attendu par GRUB :
# grub-probe -d -t fs_uuid /dev/sda3
Et au cas où le système de fichiers n’est pas dans une partition mais un volume logique LVM ou un ensemble RAID, on peut utiliser une variante de cette commande qui affiche le nom de périphérique GRUB :
On peut alors remplacer la commande « search » dans l’entrée de menu par :
set root=lvmid/mDfh0M-5reQ-KjbV-G4Xp-kqqm-oZTb-loInBz/ExmVBR-8D6d-x5Fo-ti1i-B8s3-dwjW-1bwbpo
ou bien directement sans passer par grub-probe :
set root=lvm/VG_name-LV_name
(les parenthèses sont facultatives dans la variable $root)
La première forme basée sur les UUID LVM internes est plus robuste, la seconde basée sur les noms de VG et LV est plus lisible. C’est un peu comme les UUID et les LABEL.
Oui, et aussi que GRUB soit installé pour l’amorçage UEFI sinon ce n’est pas compatible.
Note : pas besoin de mettre (${root}) devant le chemin, c’est implicite.
Sourcé comment ?
Si tu crées un nouveau fichier contenant une entrée de menu, il faut qu’il commence par les 2 premières lignes du fichier 40_custom :
#!/bin/sh
exec tail -n +3 $0
Edit : et il doit être exécutable (chmod +x) puisque c’est un script shell. Ainsi il est exécuté automatiquement par grub-mkconfig (lui-même appelé par update-grub), pas besoin de le sourcer.
Je n’irais pas jusque là, mais c’est une bonne introduction. Pour ajouter un OS Linux j’ai utilisé la commande configfile pour charger son fichier grub.cfg, mais ça ne fonctionne que si ce fichier existe et est compatible avec le GRUB principal. Si la partition /boot est séparée, il faut spécifier cette partition et non la racine, et le chemin est /grub/ au lieu de /boot/grub/. Certaines distributions nomment le répertoire « grub2 » au lieu de « grub ».
En l’absence de fichier grub.cfg compatible, il y a d’autres méthodes possibles comme chaîner le chargeur d’amorçage (secteur d’amorce BIOS ou exécutable EFI) avec chainloader ou amorcer la core image BIOS de GRUB (/boot/grub/i386-pc/core.img) avec multiboot.
Pour motiver les troupes, voici quelques avantages par rapport à os-prober :
ce n’est à faire qu’une fois par OS à inclure dans le menu
ça fonctionne dans certains cas où os-prober ne fonctionne pas correctement
on peut donner le nom souhaité à l’entrée de menu (utile avec Windows 11 qui n’est pas correctement identifié - ceci dit le patch est trivial, ou si on a plusieurs instances d’une même distribution)
l’exécution de update-grub est plus rapide
pas besoin d’exécuter update-grub sur l’OS principal après avoir ajouté ou supprimé un noyau ou modifié les paramètres du noyau dans un OS secondaire
Je te remercie pour les explications complémentaires.
Je reste d’avis suivant : « pourquoi faire simple quand on peut faire très compliqué ! » (c’est de l’ironie, bien-sûr) - exit os-prober, vive la complexité - dans ce cas - de la configuration manuelle…
D’accord, j’ai passé un peu de temps pour la mise en place, mais maintenant c’est un vrai confort sur une machine dont le disque contient plus de 20 partitions et volumes logiques LVM et 5 OS. Je ne regrette pas l’investissement.
