Oui c’est normal. Mais j’ai oublié de mentionner qu’il faut exécuter la commande « boot » ensuite.
Bonsoir PascalHambourg,
en exécutant ensuite la commande boot, j’arrive bien à une invite de commande type Grub shell, qui semble bien correspondre au Grub installé sur ma clef !
Le problème se situerait donc au niveau du boot de la clef USB qui ne fonctionne pas ?
En particulier, dans la liste des options de boot de mon UEFI, j’ai :
- « USB » → affiche un texte du style « no boot device found »
- « UEFI: USB, Partition 1 » → affiche un écran noir et redémarre aussitôt (si je laisse faire, j’arrive au Grub système puis à Debian, qui est le choix par défaut)
Peut-être y’a-t-il une option de mon bios UEFI qui m’empêche de booter en uefi sur ma clef ??
Je viens de vérifier et mon disque nvme interne sur lequel Grub est installé possède bien une table gpt.
Merci beaucoup pour ton aide en tout cas, je progresse ^^
Bonne soirée à tous,
Donut
Ça doit être pour l’amorçage en mode BIOS/legacy.
C’est pourtant l’option pour l’amorçage en mode EFI. Peut-être un bug du firmware UEFI.
Je propose deux expériences :
1 .Refaire la clé en GPT avec la partition EFI en n° 2.
2. Refaire la clé avec une table DOS/MBR. Peu importe le numéro de la partition EFI.
Dans les deux cas, comparer l’intitulé de l’option UEFI USB et tester si ça boote.
Bonsoir Pascal,
merci pour ces suggestions, je vais tester cela.
Pour compléter mon message, voici les paramètres actuellement défini dans mon bios uefi :
- Fast Boot : Disabled
- CSM Support : Enabled
- LAN PXE Boot Option ROM : Disabled
- Storage Boot Option Control : UEFI Only
- Other PCI Device ROM Priority : UEFI Only
En première lecture, rien qui me choque. CSM c’est l’acronyme de « Compatibility Support Module ». Si je comprends bien, avec cela on accepte de booter en Bios classique (via des tables de partitions MBR donc). Fast Boot, j’ai cru comprendre que cela pouvait poser pb mais là de toute façon il est désactivé.
Bonne soirée,
Donut
Plus ou moins. Cela peut aussi signifier que des services BIOS sont disponibles en amorçage EFI.
En principe il n’y a aucun rapport entre le mode d’amorçage et le type de table de partition.
Bonjour,
bon j’ai eu l’occasion de tester sur un autre PC et j’ai observé le même comportement : le PC reboote lorsqu’on démarre sur la clef USB en UEFI.
Je vais tester tes suggestions ce soir.
A bientôt,
D.
Bonsoir,
je viens de tester la suggestion n°1.
Voici mes partitions :
$ sudo parted /dev/sdc print
Model: USB SanDisk 3.2Gen1 (scsi)
Disk /dev/sdc: 123GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 4295MB 4294MB ext4 dmboot
2 5369MB 6442MB 1074MB fat32 dmuefi boot, esp
J’observe exactement le même comportement qu’auparavant (à savoir, reboot de la machine).
Deux informations nouvelles :
- Lorsque, depuis mon « grub système » (ie pas celui de la clef, mais celui qui est sur mon disque interne) je fais :
set root=hd1,gpt1 # Ou hd1,gpt2 dans le cas de la suggestion n°1
chainloader /ef/boot/bootx64.efi
boot
Avant d’arriver à l’invite de commande grub minimale (sur fond noir, sans le fond d’écran Debian de mon « grub système »), il y a un message d’erreur qui s’affiche très brièvement (que ce soit dans la configuration initiale de la clef ou dans la configuration de la suggestion n°1) :
error: file '/boot/' not found.
error: no such device: /.disk/info.
error: no such device: /.disk/mini-info.
Du coup, je me demande si le grub sur fond noir que j’obtiens est bien celui de la clef et non pas mon « grub système » par défaut…
-
Lorsqu’au démarrage, je choisis de booter sur la clef en cliquant sur « UEFI: USB, Partition 1 » (qui au passage devient « UEFI: USB, Partition 2 » dans le cas de la suggestion n°1), JUSTE AVANT le reboot, j’ai vu passer ce message d’erreur :
System BootOrder not found. Initializing defaults.
Reset System.
Tout ceci me laisse à penser que ce ne sont pas mes partitions qui posent problème mais plutôt l’installation de grub.
Par exemple :
$ sudo mount /dev/sdc1 ./boot/ # Je suis dans le cas de figure de la suggestion n°1
$ sudo mount /dev/sdc2 ./efi/
$ sudo find ./boot -name core.img
$ sudo find ./efi -name core.img
$ sudo find ./efi -name boot.img
$ sudo find ./boot -name boot.img
Par ailleurs :
$ cat ./efi/EFI/BOOT/grub.cfg
search.fs_uuid bdc7041d-b5f8-4e3a-8652-909fe8cf1bd4 root hd2,gpt1
set prefix=($root)'/grub'
configfile $prefix/grub.cfg
$ ls ./boot/grub/grub.cfg
ls: impossible d'accéder à './boot/grub/grub.cfg': Aucun fichier ou dossier de ce type
J’ai supposé qu’en l’absence de grub.cfg, il allait m’afficher l’invite de commande grub mais c’est peut-être faux…
Bon j’ai des choses à creuser, il faut que je comprenne la structure des fichiers générés par grub-install
A bientôt,
Donut
Ça fait partie des comportements bizarres de l’image signée de GRUB installée avec --removable que j’ai évoqués à la fin de mon premier message. Cette image semble prévue pour l’installateur car les fichiers recherchés sont présents dans des images ISO d’installation, mais pourtant ce n’est pas cette image de GRUB qui est présente dans les images ISO.
Oui. Celui du système afficherait le menu.
Donc le firmware UEFI a bien pris en compte la table de partition GPT et identifié la bonne partition EFI.
Il me semble que ceci est un message du firmware UEFI, pas de shim ou GRUB. Qu’affiche efibootmgr ?
core.img est spécifique à la plate-forme PC BIOS (i386-pc), il n’existe pas dans les plates-formes UEFI. C’est le fichier grubx64.efi qui contient l’image pour la plate-forme PC UEFI 64 bits.
Correct.
Bonsoir PascalHambourg, bonsoir le forum,
super ça a marché !!
Effectivement, j’aurais du lire plus attentivement ton premier message, car c’est ce qui a résolu mon problème 
In fine, la commande grub-install posait problème et voici celle qui a permis de résoudre mon soucis :
sudo grub-install --target=x86_64-efi --bootloader-id="Donut-UEFI" --recheck --force-extra-removable --no-nvram --efi-directory="./efi" --boot-directory="./boot"
En revanche, aucune idée de pourquoi les deux options --force-extra-removable et --no-nvram ont résolu le soucis.
Le man indique à leur sujet :
--force-extra-removable force installation to the removable media path also. This option is only available on EFI. --no-nvram don't update the `boot-device'/`Boot*' NVRAM variables. This option is only available on EFI and IEEE1275 targets.
Bon en tout cas, merci beaucoup pour ton aide ! Et ça m’a forcé de me plonger plus en profondeur dans la doc, c’est dans ces moments qu’on apprend le plus ^^
Les étapes suivantes seront :
- peaufinage du grub.cfg pour avoir un truc joli (et si on pouvait charger automatiquement le clavier FR ce serait top)
- ajout des isos de plusieurs distributions de linux
- éventuellement vérifier dans quelle mesure ces images peuvent être persistantes (si ce sont des iso, j’en doute). On pourrait aussi envisager d’avoir une partition data de la clef pour stocker des choses dessus…
En tout cas, le sujet de ce fil est clôt !
Bonne soirée à tous
Pourquoi cette option ?
–force-extra-removable installe l’image « normale » de GRUB, la même que celle qui est installée par grub-install sans option ou incluse dans les images ISO.
–no-nvram ne sert qu’à éviter de modifier les variables de boot EFI. Cette option est implicite avec --removable mais pas avec --force-extra-removable.
C’est une grosse galère et c’est trop aléatoire selon les machines, j’ai laissé tomber.
En cherchant à résoudre mon soucis initial, j’étais tombé sur des exemples de commandes qui incluait cette option.
--bootloader-id=ID the ID of bootloader. This option is only available on EFI and Macs.
Je crois comprendre que ça permet de spécifier une chaîne de caractère pour identifier facilement le bootloader installé sur la clef. Je m’étais dit que c’était une bonne idée pour différencier le grub installé sur la clef de mon grub système.
Mais je n’ai pas encore vu où ce bootloader-id pouvait apparaître par la suite.
Ou alors j’ai mal compris l’utilité de cette option…
Bonne journée à tous !
L’option --bootloader-id, dont la valeur par défaut est « Debian » dans le cas de Debian, affecte deux points :
- le nom de la variable de boot EFI créée pour GRUB dans la NVRAM de la carte mère. Cela peut être utile pour ne pas interférer avec la variable de boot EFI créée pour le système installé. Mais ici l’option --no-nvram empêche la modification des variables de boot EFI ;
- le nom du répertoire où GRUB est installé dans la partition EFI spécifiée par --efi-directory . Là encore, cela peut être utile pour ne pas écraser une installation de GRUB existante dans cette partition EFI. Mais ici il n’y a pas d’autre instance de GRUB dans cette partition EFI.
Concernant le second point, il est important de noter que si on installe l’image de GRUB signée par Debian pour le secure boot (ce qui est le cas par défaut dans une installation normale de Debian), celle-ci va chercher un fichier grub.cfg initial dans le répertoire « debian » de la partition EFI (ce fichier va chercher ensuite le fichier grub.cfg principal à l’emplacement spécifié par --boot-directory) . Or grub-install installe le fichier grub.cfg initial dans le répertoire spécifié par --efi-directory, donc s’il diffère de « debian » GRUB ne le trouvera pas et ne pourra pas afficher le menu du fichier grub.cfg principal. Il faut donc créer le répertoire EFI/debian dans la partition EFI et y copier le fichier grub.cfg initial.
Hello,
je me permets de revenir sur cette remarque, qui me fait réfléchir depuis quelques temps :
Cette valeur de 550 MiO provient de ce tutorial de linuxconfig.org. Il y est écrit :
After this step, we can create the
EFIpartition and format it with afat32filesystem. The recommended size for the partition is550 MiB: on smaller partitions we could receive an error such as “not enough clusters for 32 bit FAT”
Donc c’est une façon implicite de signifier que la partition doit être en FAT32.
J’ai testé avec une partition beaucoup plus petite (10 MiB soit à peine plus que ce que prend Grub) et formatée en FAT16 : ça démarre tout aussi bien.
Et en regardant les spécifications de l’UEFI, section 13.3.1.1 « File System Format », il est écrit noir sur blanc :
The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system. What variant of EFI FAT to use is defined by the size of the media.
Donc pas de soucis à utiliser de petites partitions en FAT16 pour l’amorçage UEFI. L’article de linuxconfig.org est donc incorrect… sauf si, en pratique, il s’avère que certains firmwares ont du mal avec le FAT16 ?
Si tous les firmwares UEFI respectaient à la lettre les spécifications de l’UEFI, ça se saurait. En fait c’est plutôt le contraire : d’après mon expérience, tous les firmwares UEFI sont plus ou moins buggés en ce qui concerne la gestion de l’amorçage.
L’expérience m’a aussi appris que la phrase « What variant of EFI FAT to use is defined by the size of the media » ne doit pas être prise à la légère. J’ai constaté que certains firmwares ne reconnaissaient pas n’importe quelle combinaison de format FAT et de taille pour une partition EFI.
Je pense que toutes les recommandations qu’on peut lire ici et là et qui vont bien au-delà des spécifications de l’UEFI ont pour but d’assurer une compatibilité avec un maximum de firmwares et de configurations. Comme celle d’utiliser une table de partition au format GPT.
1 J'aime
Et donc, autant utiliser le démarrage à l’ancienne (legacy) ?
Oui à 100% tant que le firmware supporte l’amorçage legacy et quand l’amorçage EFI n’apporte rien voire complique tout. Notamment avec du RAID logiciel.
1 J'aime
OK, je regarderai ça quand j’aurais mon nouveau payçay (one of these days).
Là où ça peut coincer, c’est quand on veut utiliser une technologie moderne comme GPT avec l’amorçage legacy. Certains firmwares n’aiment pas, pour diverses raisons (ou plutôt bugs).
Qu’apporte GPT, à part un nom rigolo ?
- Les UUID et LABEL de partition qui résistent au formatage contrairement aux UUID et LABEL de système de fichiers
- une structure en table « plate » simple et robuste pour définir plus de 4 partitions au lieu de la structure en liste chaînée complexe et fragile des partitions étendues et logiques
- la possibiité de créer des partitions de plus de 2 Tio et/où dans l’espace disque au-delà de de 2 Tio (pour les supports avec des secteurs de 512 octets)
- une copie de secours de la table de partition à la fin du disque
et j’en oublie sûrement.
2 J'aime