MAJ grub et plus de boot systeme
Le
Christophe PEREZ
Bonjour,
Sur un portable Acer Aspire ES 11, sur lequel j'avais remplacé Windows
par Gentoo Linux, suite Í mise Í jour de grub, je ne parviens plus Í
booter le système.
J'ai un message d'erreur grub, indiquant « error symbol grub_calloc not
found » avec le shell grub rescue>.
Pour être plus précis, suite Í une mise Í jour de grub, j'ai cru bon (et
je me demande encore pourquoi) de lancer :
grub-install --target=x86_64-efi --efi-directory=/boot
(après avoir pris soin de monter ma partition de boot)
(--target=x86_64-efi étant ici optionnel puisque mon grub ne contient que
ce mode)
Et je n'ai pas eu de message d'erreur, comme quand je l'ai relancé
depuis :
# grub-install --efi-directory=/boot
Installation pour la plate-forme x86_64-efi.
Installation terminée, sans erreur.
Après avoir modifié l'ordre de boot dans le bios qui est donc
actuellement :
Boot priority order :
1. EMMC: BJNB4R32G
2. USH HDD: Corsair Flash voyager
3. Windows Boot Manager
4. USB FDD:
5. USB CDROM:
6. HDD1:
7 ATAPI CDROM:
8 Network Boot-IPV4:
9 Network Boot-IPV6:
Je peux booter sur ma clé USB, et accéder Í mon système, mais je ne
parviens pas Í comprendre ce qui coince, et encore moins comment résoudre
le problème.
Il ne me semble pas que j'avais eu de problème Í l'installation, puisque
je n'avais pas tenté de conserver Windows (carte MMC 32G).
Je ne comprends donc pas ce qui peut coincer maintenant.
Je fais forcément une erreur, mais o͹ ?
Merci d'avance Í qui me sortira de ce mauvais pas.
Les infos récoltées :
# fdisk -l /dev/mmcblk1
Disque /dev/mmcblk1Â : 29,12 GiB, 31268536320Â octets, 61071360Â secteurs
Unités : secteur de 1 Í— 512 = 512 octets
Taille de secteur (logique / physique)Â : 512Â octets / 512Â octets
taille d'E/S (minimale / optimale)Â : 512Â octets / 512Â octets
Type d'étiquette de disque : gpt
Identifiant de disque : 37FB54ED-3FE3-4ACC-A9CA-6F1C764B28E7
Périphérique Début Fin Secteurs Taille Type
/dev/mmcblk1p1 2048 195312 193265 94,4M Système EFI
/dev/mmcblk1p2 196608 4390911 4194304 2G Système de fichiers Linux
/dev/mmcblk1p3 4390912 61071326 56680415 27G Système de fichiers Linux
# efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 2001,0001,2002,2003
Boot0001* Windows Boot Manager HD(1,GPT,a615c5c7-8eab-427d-85a0-
facdc932e1d4,0x800,0x2f2f1)/File(EFIMicrosoftBootbootmgfw.efi)RC
Boot0002* USB HDD: Corsair Flash Voyager PciRoot(0x0)/
Pci(0x15,0x0)/USB(1,0)/USB(0,0)/HD(1,MBR,0x6b8b4567,0xc0,0x331c)RC
Boot0003* gentoo HD(1,GPT,a615c5c7-8eab-427d-85a0-
facdc932e1d4,0x800,0x2f2f1)/File(EFIgentoogrubx64.efi)
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC
# mount | grep /boot
/dev/mmcblk1p1 on /boot type vfat
(rw,relatime,fmask 22,dmask 22,codepageC7,iocharset=iso8859-1,shortname=mixed,errors=remount-
ro)
# tree /boot/
/boot/
|-- EFI
| |-- Microsoft
| | `-- Boot
| | `-- bootmgfw.efi
| `-- gentoo
| `-- grubx64.efi
|-- System.map-5.4.97-gentoo
|-- config-5.4.97-gentoo
|-- grub
| |-- fonts
| | `-- unicode.pf2
| |-- grub.cfg
| |-- grubenv
| |-- locale
| | `-- fr.mo
| |-- themes
| | `-- starfield
| | |-- COPYING.CC-BY-SA-3.0
[]
| | `-- theme.txt
| `-- x86_64-efi
| |-- acpi.mod
[]
| `-- zstd.mod
`-- vmlinuz-5.4.97-gentoo
Sur un portable Acer Aspire ES 11, sur lequel j'avais remplacé Windows
par Gentoo Linux, suite Í mise Í jour de grub, je ne parviens plus Í
booter le système.
J'ai un message d'erreur grub, indiquant « error symbol grub_calloc not
found » avec le shell grub rescue>.
Pour être plus précis, suite Í une mise Í jour de grub, j'ai cru bon (et
je me demande encore pourquoi) de lancer :
grub-install --target=x86_64-efi --efi-directory=/boot
(après avoir pris soin de monter ma partition de boot)
(--target=x86_64-efi étant ici optionnel puisque mon grub ne contient que
ce mode)
Et je n'ai pas eu de message d'erreur, comme quand je l'ai relancé
depuis :
# grub-install --efi-directory=/boot
Installation pour la plate-forme x86_64-efi.
Installation terminée, sans erreur.
Après avoir modifié l'ordre de boot dans le bios qui est donc
actuellement :
Boot priority order :
1. EMMC: BJNB4R32G
2. USH HDD: Corsair Flash voyager
3. Windows Boot Manager
4. USB FDD:
5. USB CDROM:
6. HDD1:
7 ATAPI CDROM:
8 Network Boot-IPV4:
9 Network Boot-IPV6:
Je peux booter sur ma clé USB, et accéder Í mon système, mais je ne
parviens pas Í comprendre ce qui coince, et encore moins comment résoudre
le problème.
Il ne me semble pas que j'avais eu de problème Í l'installation, puisque
je n'avais pas tenté de conserver Windows (carte MMC 32G).
Je ne comprends donc pas ce qui peut coincer maintenant.
Je fais forcément une erreur, mais o͹ ?
Merci d'avance Í qui me sortira de ce mauvais pas.
Les infos récoltées :
# fdisk -l /dev/mmcblk1
Disque /dev/mmcblk1Â : 29,12 GiB, 31268536320Â octets, 61071360Â secteurs
Unités : secteur de 1 Í— 512 = 512 octets
Taille de secteur (logique / physique)Â : 512Â octets / 512Â octets
taille d'E/S (minimale / optimale)Â : 512Â octets / 512Â octets
Type d'étiquette de disque : gpt
Identifiant de disque : 37FB54ED-3FE3-4ACC-A9CA-6F1C764B28E7
Périphérique Début Fin Secteurs Taille Type
/dev/mmcblk1p1 2048 195312 193265 94,4M Système EFI
/dev/mmcblk1p2 196608 4390911 4194304 2G Système de fichiers Linux
/dev/mmcblk1p3 4390912 61071326 56680415 27G Système de fichiers Linux
# efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 2001,0001,2002,2003
Boot0001* Windows Boot Manager HD(1,GPT,a615c5c7-8eab-427d-85a0-
facdc932e1d4,0x800,0x2f2f1)/File(EFIMicrosoftBootbootmgfw.efi)RC
Boot0002* USB HDD: Corsair Flash Voyager PciRoot(0x0)/
Pci(0x15,0x0)/USB(1,0)/USB(0,0)/HD(1,MBR,0x6b8b4567,0xc0,0x331c)RC
Boot0003* gentoo HD(1,GPT,a615c5c7-8eab-427d-85a0-
facdc932e1d4,0x800,0x2f2f1)/File(EFIgentoogrubx64.efi)
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC
# mount | grep /boot
/dev/mmcblk1p1 on /boot type vfat
(rw,relatime,fmask 22,dmask 22,codepageC7,iocharset=iso8859-1,shortname=mixed,errors=remount-
ro)
# tree /boot/
/boot/
|-- EFI
| |-- Microsoft
| | `-- Boot
| | `-- bootmgfw.efi
| `-- gentoo
| `-- grubx64.efi
|-- System.map-5.4.97-gentoo
|-- config-5.4.97-gentoo
|-- grub
| |-- fonts
| | `-- unicode.pf2
| |-- grub.cfg
| |-- grubenv
| |-- locale
| | `-- fr.mo
| |-- themes
| | `-- starfield
| | |-- COPYING.CC-BY-SA-3.0
[]
| | `-- theme.txt
| `-- x86_64-efi
| |-- acpi.mod
[]
| `-- zstd.mod
`-- vmlinuz-5.4.97-gentoo
Evidemment, c'est toujours Í peine après avoir posté qu'une idée me
vient, même si pourtant j'ai bien attendu avant. Bref.
J'ai tenté le coup d'écraser
/boot/EFI/Microsoft/Boot/bootmgfw.efi par /boot/EFI/gentoo/grubx64.efi
en remettant la priorité du boot sur "Windows Boot Manager"
et j'ai pu booter.
J'avoue qu'une fois de plus, tout ça me dépasse un peu.
Pourquoi le boot gentoo n'était-il pas pris en compte ?
Cette erreur signifie que la version de l'image de GRUB qui a été
amorcée ne correspond pas avec les modules de GRUB qui sont
(normalement) installés dans /boot/grub. Lorsque cela se produit après
avoir exécuté grub-install, cela veut généralement dire que c'est
l'ancienne version de l'image de GRUB qui est amorcée et pas la nouvelle.
Parce que ça ne sert Í rien de mettre Í jour les paquets grub* si on ne
réinstalle pas le chargeur d'amorçage GRUB lui-même.
Tiens, Gentoo monte la partition EFI sur /boot ? Mauvaise idée AMA.
Tiens, Gentoo ne monte pas la partition /boot en permanence ? Mauvaise
idée AMA.
Surtout, c'est par défaut si grub-install détecte que le système a été
démarré en mode EFI.
C'est normal qu'il ne contienne pas Gentoo ?
O͹ on peut voir qu'il y a une entrée de boot pour Gentoo (0003) mais
qu'elle n'est pas listée dans BootOrder. Pourtant grub-install aurait dÍ»
la mettre en premier. Tu pourrais essayer de modifier le BootOrder avec
efibootmgr --bootorder 0003,0001,2001,2002,2003
et contrÍ´le de BootCurrent après reboot.
Et c'est ce que tu avais déjÍ dÍ» faire la fois précédente, mais tu ne
t'en souviens plus. Vu le contenu de /boot/EFI et les variables de boot,
je ne vois pas d'autre explication possible.
Parce que l'entrée de boot de Gentoo n'est pas dans le BootOrder.
Ok.
C'est un peu ce que j'ai tendance Í me dire, mais vu l'erreur, et ses
conséquences, j'ai commencé Í douter ;)
Non, ça c'est moi. En fait, la doc gentoo, selon qu'on prend la doc
générale ou la doc grub, propose les 2 cas.
Moi j'avais choisi cette option parce que je n'aimais pas voir /boot/EFI/
efi. Je trouvais ça un peu ridicule.
A l'époque de ma 1ère installation Gentoo, en multiboot, c'était
recommandé oui. J'en ai gardé l'habitude, quand j'ai une partition
distincte. Je ne vois pas l'intérêt de l'avoir montée en permanence. Ça
diminue (un peu) les risques. Mais j'avoue que c'est plus par habitude
que par choix réfléchi.
Oui bien sur.
Et bien c'est une question que je me pose aussi. Mais je n'en ai
évidemment pas la réponse.
C'est ce que j'ai pensé aussi.
Je ferai ça dès que j'aurai Í nouveau la main assez longtemps sur la
machine (celle de ma femme, et lui sert pour le boulot).
Je sais que je l'avais fait pour une autre portable, dont nous avions
longuement discuté ici Í cause du boot windows. Mais je ne m'en souvenais
pas du tout pour celui lÍ .
Ça doit donc être ça.
Logique.
Merci pour tes éclairages.
# efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,2001,2002,2003
Boot0000* gentoo
Boot0001* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
# efibootmgr --bootorder 0000,0001,2001,2002,2003
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001,2001,2002,2003
Boot0000* gentoo
Boot0001* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
# reboot
# efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,2001,2002,2003
Boot0000* gentoo
Boot0001* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
Ça ne me semble pas trop normal. A moins qu'il y ait quelque chose Í
faire pour que ce soit "enregistré" ?
- enlevé /boot/EFI/Microsoft
- copié /boot/EFI/gentoo/grubx64.efi en /boot/EFI/gentoo/grub.efi (par
acquis de conscience puisque le --help de efibootmgr parle de defaults to
"EFIGentoogrub.efi")
- désactivé le boot windows (efibootmgr -A -b 0001)
- rebooté
"No device" au boot.
Je boote sur la clé USB, et j'ai :
# efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot0000* USB HDD: Corsair Flash Voyager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
Plus de boot windows, normal, mais plus de boot gentoo non plus.
J'ai replacé /boot/EFI/Microsoft, reboot, et :
# efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,2001,2002,2003
Boot0001* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
# grub-install --efi-directory=/boot
Installation pour la plate-forme x86_64-efi.
Installation terminée, sans erreur.
# efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001,2001,2002,2003
Boot0000* gentoo
Boot0001* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
on revient donc Í ta suggestion, Pascal, mais au reboot suivant :
# efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,2001,2002,2003
Boot0000* gentoo
Boot0001* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
On se mord la queue.
(...)
Certains firmwares UEFI exigent qu'on "approuve" une entrée de boot pour
qu'elle soit active. Ou alors tu as affaire Í un firmware récalcitrant
qui n'aime que Windows.
Inutile, la variable de boot gentoo pointe vers EFIgentoogrubx64.efi,
pas EFIgentoogrub.efi.
Ça c'est valable quand on crée une variable de boot directement avec
efibootmgr.
Quand c'est grub-install qui l'invoque (ou plutÍ´t l'invoquait, les
versions récentes de GRUB n'en ont plus besoin), il lui passe les
options qui vont bien.
Normal, la variable de boot gentoo est sans effet tant qu'elle n'est pas
dans le BootOrder.
(...)
Ça n'aurait pas dÍ» affecter la variable de boot gentoo. Tu as copié ou
renommé grubx64.efi en grub.efi ?
Donc la variable de boot Windows est revenue toute seule. On dirait que
ce firmware est "marié" avec Windows.
Résultat attendu.
(...)
Firmware récalcitrant. C'est probablement pour cela que de guerre lasse
tu avais copié GRUB dans l'emplacement du chargeur de Windows.
Quand on se retrouve face Í un firmware UEFI qui gère les variables de
boot en dépit du bon sens, un solution possible consiste Í installer
GRUB dans le "chemin de support amovible" (removable device path). C'est
ce qu'on utilise pour rendre une clé USB amorçable en mode UEFI. J'avais
dÍ» le faire avec les firmwares UEFI de plusieurs portables HP qui
semblaient totalement ignorer les variables de boot existantes.
Pour un firmware UEFI x64, l'emplacement est EFI/Boot/bootx64.efi.
On peut y copier grubx64.efi ou y installer GRUB directement avec
# grub-install --removable --efi-directory=/boot
Copié, comme j'avais dit.
Je crois aussi oui.
Sans doute.
Cette fois-ci, je l'ai noté, je m'en souviendrai. C'est étonnant que je
ne l'ai pas fait d'origine. Normalement je note tout. Un oubli sans doute.
Et l'intérêt par rapport Í la solution de copier comme je l'ai fait ?
Juste pour ne plus avoir de mention erronée de boot windows ?
Entre autres. Ça ne nécessite pas de copie/renommage après l'exécution
de grub-install. C'est plus universel car ça ne dépend pas d'une
"affinité" du firmware UEFI avec Windows. Ça ne crée pas d'entrée
factice pour Windows dans le menu de GRUB.
D'accord, je vais essayer.
Merci encore.