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,fmask22,dmask22,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
  • Partager ce contenu :
Vos réponses Page 1 / 2
Trier par : date / pertinence
Christophe PEREZ
Le #26570494
Le Sun, 28 Mar 2021 16:02:19 +0000, Christophe PEREZ a écrit :
Merci d'avance Í  qui me sortira de ce mauvais pas.

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 ?
Pascal Hambourg
Le #26570474
Le 28/03/2021 Í  18:02, Christophe PEREZ a écrit :
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>.

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.
Pour être plus précis, suite Í  une mise Í  jour de grub, j'ai cru bon (et
je me demande encore pourquoi) de lancer :

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.
grub-install --target=x86_64-efi --efi-directory=/boot

Tiens, Gentoo monte la partition EFI sur /boot ? Mauvaise idée AMA.
(après avoir pris soin de monter ma partition de boot)

Tiens, Gentoo ne monte pas la partition /boot en permanence ? Mauvaise
idée AMA.
(--target=x86_64-efi étant ici optionnel puisque mon grub ne contient que
ce mode)

Surtout, c'est par défaut si grub-install détecte que le système a été
démarré en mode EFI.
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:

C'est normal qu'il ne contienne pas Gentoo ?
# 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

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.
# tree /boot/
/boot/
|-- EFI
| |-- Microsoft
| | `-- Boot
| | `-- bootmgfw.efi
| `-- gentoo
| `-- grubx64.efi
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.

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.
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 ?

Parce que l'entrée de boot de Gentoo n'est pas dans le BootOrder.
Christophe PEREZ
Le #26570473
Le Mon, 29 Mar 2021 23:04:32 +0200, Pascal Hambourg a écrit :
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.

Ok.
Pour être plus précis, suite Í  une mise Í  jour de grub, j'ai cru bon
(et je me demande encore pourquoi) de lancer :

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.

C'est un peu ce que j'ai tendance Í  me dire, mais vu l'erreur, et ses
conséquences, j'ai commencé Í  douter ;)
grub-install --target=x86_64-efi --efi-directory=/boot

Tiens, Gentoo monte la partition EFI sur /boot ? Mauvaise idée AMA.

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.
(après avoir pris soin de monter ma partition de boot)

Tiens, Gentoo ne monte pas la partition /boot en permanence ? Mauvaise
idée AMA.

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.
(--target=x86_64-efi étant ici optionnel puisque mon grub ne contient
que ce mode)

Surtout, c'est par défaut si grub-install détecte que le système a été
démarré en mode EFI.

Oui bien sur.
Boot priority order :

C'est normal qu'il ne contienne pas Gentoo ?

Et bien c'est une question que je me pose aussi. Mais je n'en ai
évidemment pas la réponse.
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.

C'est ce que j'ai pensé aussi.
Tu pourrais essayer de modifier le BootOrder avec
efibootmgr --bootorder 0003,0001,2001,2002,2003
et contrÍ´le de BootCurrent après reboot.

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).
Et c'est ce que tu avais déjÍ  dÍ» faire la fois précédente, mais tu ne
t'en souviens plus.

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Í .
Vu le contenu de /boot/EFI et les variables de boot,
je ne vois pas d'autre explication possible.

Ça doit donc être ça.
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 ?

Parce que l'entrée de boot de Gentoo n'est pas dans le BootOrder.

Logique.
Merci pour tes éclairages.
Christophe PEREZ
Le #26570472
Le Mon, 29 Mar 2021 22:13:06 +0000, Christophe PEREZ a écrit :
Tu pourrais essayer de modifier le BootOrder avec efibootmgr
--bootorder 0003,0001,2001,2002,2003
et contrÍ´le de BootCurrent après reboot.

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).

# 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é" ?
Christophe PEREZ
Le #26570471
Pour tester, j'ai :
- 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.
Pascal Hambourg
Le #26570458
Le 30/03/2021 Í  01:08, Christophe PEREZ a écrit :
Le Mon, 29 Mar 2021 22:13:06 +0000, Christophe PEREZ a écrit :
Tu pourrais essayer de modifier le BootOrder avec efibootmgr
--bootorder 0003,0001,2001,2002,2003
et contrÍ´le de BootCurrent après reboot.



(...)
# 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é" ?

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.
Pascal Hambourg
Le #26570457
Le 30/03/2021 Í  01:37, Christophe PEREZ a écrit :
Pour tester, j'ai :
- enlevé /boot/EFI/Microsoft
- copié /boot/EFI/gentoo/grubx64.efi en /boot/EFI/gentoo/grub.efi (par

Inutile, la variable de boot gentoo pointe vers EFIgentoogrubx64.efi,
pas EFIgentoogrub.efi.
acquis de conscience puisque le --help de efibootmgr parle de defaults to
"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.
- désactivé le boot windows (efibootmgr -A -b 0001)
- rebooté
"No device" au boot.

Normal, la variable de boot gentoo est sans effet tant qu'elle n'est pas
dans le BootOrder.
Je boote sur la clé USB, et j'ai :

(...)
Plus de boot windows, normal, mais plus de boot gentoo non plus.

Ça n'aurait pas dÍ» affecter la variable de boot gentoo. Tu as copié ou
renommé grubx64.efi en grub.efi ?
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

Donc la variable de boot Windows est revenue toute seule. On dirait que
ce firmware est "marié" avec Windows.
# 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

Résultat attendu.
on revient donc Í  ta suggestion, Pascal, mais au reboot suivant :
# efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,2001,2002,2003
Boot0000* gentoo

(...)
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
Christophe PEREZ
Le #26570452
Le Tue, 30 Mar 2021 20:35:14 +0200, Pascal Hambourg a écrit :
Je boote sur la clé USB, et j'ai :

(...)
Plus de boot windows, normal, mais plus de boot gentoo non plus.

Ça n'aurait pas dÍ» affecter la variable de boot gentoo. Tu as copié ou
renommé grubx64.efi en grub.efi ?

Copié, comme j'avais dit.
Donc la variable de boot Windows est revenue toute seule. On dirait que
ce firmware est "marié" avec Windows.

Je crois aussi oui.
Firmware récalcitrant. C'est probablement pour cela que de guerre lasse
tu avais copié GRUB dans l'emplacement du chargeur de Windows.

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.
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

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 ?
Pascal Hambourg
Le #26570451
Le 31/03/2021 Í  01:28, Christophe PEREZ a écrit :
Le Tue, 30 Mar 2021 20:35:14 +0200, Pascal Hambourg a écrit :
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

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.
Christophe PEREZ
Le #26570448
Le Wed, 31 Mar 2021 07:03:36 +0200, Pascal Hambourg a écrit :
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.
Poster une réponse
Anonyme