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.
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
# mount | grep /boot
/dev/mmcblk1p1 on /boot type vfat
(rw,relatime,fmask 22,dmask 22,codepageC7,iocharset=iso8859-1,shortname=mixed,errors=remount-
ro)
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 ?
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 ?
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 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.
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:
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.
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.
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
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.
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.
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:
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 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 ;)
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.
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 ;)
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.
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 ;)
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 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é" ?
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).
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
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.
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é
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
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 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.
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
Ç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.
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 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
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 ?
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
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 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 ?
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 ?
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 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.
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.
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 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.
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.
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.
