Pour la première partie c'est mon point de vue un peu subjectif. Je devrais le réinstaller pour te lister les soucis qui m'ont fait râler.
Pour la NVRAM, alors là, ceux qui m'ont suivi sur la tribune ont pu suivre mes tribulations en temps réel. j'ai un setup pas si compliqué que ça, j'ai une machine en multiboot Mac/Linux. C'est un "hackintosh". Le premier EFI contient Clover, un bootloader bien sympathique. Quand j'installe Linux, je veux que ce soit sur le volume EFI d'un second disque, comme l'autorise la norme, et ensuite soit le "boot menu" de la carte mère me permet de démarrer dessus (les entrées de boot de la NVRAM), soit Clover énumère les volumes EFI et m'affiche une jolie icône Linux dans la liste, pour chainer le boot dessus.
C'est simple: si l'installateur propose bien l'installation des fichiers EFI sur une autre partition que la première (mais dans ce cas tu dois créer la partition EFI manuellement, tiens, voilà un exemple de réponse à ta première question), j'ai eu de très mauvaises surprises, notamment celle de voir que que grub continuait à modifier des choses sur la première en mode OSEF, mais surtout que mes entrées NVRAM n'étaient pas seulement modifiées, mais écrasées et corrompues. Au premier boot j'arrive sous Ubuntu, donc je veux logiquement remettre mon entrée par défaut sur Clover (première partition EFI, et clover peut ensuite chainer sur Grub, deuxième partition EFI) et là un efibootmgr m'affiche des entrées totalement folles avec des chaines de caractères aléatoires. Je remarque que mon fichier EFI\BOOT\BOOTX64.EFI sur la première partition EFI est en fait Grub, et pas Clover.
Toute tentative de remise en ordre se solde par un blocage intégral au boot au moment de la lecture et de la mise à jour de la NVRAM, ça crashe : je ne peux même plus accéder au setup de la carte mère. La seule solution pour m'en sortir est d'ouvrir ma tour et de débrancher tous mes disques, et par trois fois j'ai dû même forcer un RAZ total en forçant l'énumération du matériel en retirant une barrette de RAM (méthode bien connue). Ceci supprime les entrées corrompues, et enfin je peux accéder au boot menu du bios. Je dois alors booter sur ma clé USB de secours avec Clover pour le réinstaller, et ENFIN, je peux booter normalement sur tous mes OS.
Dans les forums, on trouve des types qui ont dû renvoyer leur carte mère en réparation, voire en changer, à cause de ça (pas forcément Ubuntu hein)...
On croit que c'est fini ? Mais non ! A chaque mise à jour d'Ubuntu, s'il y a grub ou un noyau dans la liste, rebelote ! La post-installation flingue tout à nouveau ! J'avais cru trouver le Graal avec le paramètre --no-nvram de Grub, mais de manière incroyable, il a disparu avec la dernière version LTS (20.04)... Je voulais ouvrir un rapport de bug, mais il y en avait déjà plusieurs, plus ou moins liés, alors j'ai laissé tomber.
J'en étais arrivé à un point où j'avais installé Ubuntu en mode MBR classique et je bootais via le boot menu du bios...
Bizarrement, l'installation d'une Fedora est impeccable: je choisis sur quel disque installer mon EFI, l'installateur me crée tout proprement, pas de corruption de la NVRAM, par d'écrasement de fichiers j'utilise efibootmgr pour remettre l'entrée d'origine, les mises à jour sont tranquilles, etc.
[^] # Re: Ubuntu ?
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche Interview de Sébastien Rohaut, auteur de livres notamment sur Linux. Évalué à 9.
Pour la première partie c'est mon point de vue un peu subjectif. Je devrais le réinstaller pour te lister les soucis qui m'ont fait râler.
Pour la NVRAM, alors là, ceux qui m'ont suivi sur la tribune ont pu suivre mes tribulations en temps réel. j'ai un setup pas si compliqué que ça, j'ai une machine en multiboot Mac/Linux. C'est un "hackintosh". Le premier EFI contient Clover, un bootloader bien sympathique. Quand j'installe Linux, je veux que ce soit sur le volume EFI d'un second disque, comme l'autorise la norme, et ensuite soit le "boot menu" de la carte mère me permet de démarrer dessus (les entrées de boot de la NVRAM), soit Clover énumère les volumes EFI et m'affiche une jolie icône Linux dans la liste, pour chainer le boot dessus.
C'est simple: si l'installateur propose bien l'installation des fichiers EFI sur une autre partition que la première (mais dans ce cas tu dois créer la partition EFI manuellement, tiens, voilà un exemple de réponse à ta première question), j'ai eu de très mauvaises surprises, notamment celle de voir que que grub continuait à modifier des choses sur la première en mode OSEF, mais surtout que mes entrées NVRAM n'étaient pas seulement modifiées, mais écrasées et corrompues. Au premier boot j'arrive sous Ubuntu, donc je veux logiquement remettre mon entrée par défaut sur Clover (première partition EFI, et clover peut ensuite chainer sur Grub, deuxième partition EFI) et là un efibootmgr m'affiche des entrées totalement folles avec des chaines de caractères aléatoires. Je remarque que mon fichier EFI\BOOT\BOOTX64.EFI sur la première partition EFI est en fait Grub, et pas Clover.
Toute tentative de remise en ordre se solde par un blocage intégral au boot au moment de la lecture et de la mise à jour de la NVRAM, ça crashe : je ne peux même plus accéder au setup de la carte mère. La seule solution pour m'en sortir est d'ouvrir ma tour et de débrancher tous mes disques, et par trois fois j'ai dû même forcer un RAZ total en forçant l'énumération du matériel en retirant une barrette de RAM (méthode bien connue). Ceci supprime les entrées corrompues, et enfin je peux accéder au boot menu du bios. Je dois alors booter sur ma clé USB de secours avec Clover pour le réinstaller, et ENFIN, je peux booter normalement sur tous mes OS.
Dans les forums, on trouve des types qui ont dû renvoyer leur carte mère en réparation, voire en changer, à cause de ça (pas forcément Ubuntu hein)...
On croit que c'est fini ? Mais non ! A chaque mise à jour d'Ubuntu, s'il y a grub ou un noyau dans la liste, rebelote ! La post-installation flingue tout à nouveau ! J'avais cru trouver le Graal avec le paramètre --no-nvram de Grub, mais de manière incroyable, il a disparu avec la dernière version LTS (20.04)... Je voulais ouvrir un rapport de bug, mais il y en avait déjà plusieurs, plus ou moins liés, alors j'ai laissé tomber.
J'en étais arrivé à un point où j'avais installé Ubuntu en mode MBR classique et je bootais via le boot menu du bios...
Bizarrement, l'installation d'une Fedora est impeccable: je choisis sur quel disque installer mon EFI, l'installateur me crée tout proprement, pas de corruption de la NVRAM, par d'écrasement de fichiers j'utilise efibootmgr pour remettre l'entrée d'origine, les mises à jour sont tranquilles, etc.
Ubuntu n'en est pas à son premier coup. En 2017, la 17.10 flinguait des portables Lenovo https://linuxiumcomau.blogspot.com/2017/12/lenovo-bios-issues.html