Auteur Sujet: Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed" (Lu 13820 fois)

Thornhill · « **Réponse #24 le:** 05 janvier 2020 à 18:22:22 »

Que donne ceci :

grep -i efivar /proc/mounts

kgersen · « **Réponse #25 le:** 05 janvier 2020 à 19:04:09 »

Citation de: vivien le 05 janvier 2020 à 14:15:22

On m'a soufflé (merci Jean-christophe) que sur https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518 il y a une solution de contournement en #11

qu'on t'avais indiqué en #2 ici meme depuis le début de ton souci...

vivien · « **Réponse #26 le:** 05 janvier 2020 à 19:36:21 »

Désolé, en fait ma compréhension du pb a bien évolué au cour de ce sujet...

Citation de: Thornhill le 05 janvier 2020 à 18:22:22

Que donne ceci :

Code: [Sélectionner]
grep -i efivar /proc/mounts

Voila :

Code: [Sélectionner]

$ grep -i efivar /proc/mounts
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0

Thornhill · « **Réponse #27 le:** 05 janvier 2020 à 21:15:42 »

Tout à l'air ok au niveau efivarfs.
En regardant le code du driver efivars, on ne peut pas y écrire n'importe quoi, le contenu des fichiers doit être valide (sinon il renvoie EINVAL).
https://code.woboq.org/linux/linux/drivers/firmware/efi/vars.c.html

Cf validate_load_option()

Le souci est donc plus dans ce que la routine tente d'écrire à l'intérieur du fichier.
Pas simple...

hwti · « **Réponse #28 le:** 06 janvier 2020 à 00:54:54 »

Citation de: vivien le 05 janvier 2020 à 17:14:53

C'est un espace de la NVRAM qui est exposé là sur /sys/firmware/efi/efivars/ ou un espace de la partition ESP ? (partition EFI System, d'une taille généralement de 500 Mo si on laisse Ubuntu la créer, qui est habituellement sur /dev/sda1)

Les variables EFI sont en NVRAM, c'est la façon dont tous les réglages UEFI sont stockés.
La taille dépend du système, et additionner la taille des variables ne suffit pas, ça peut être fragmenté (mais l'UEFI doit essayer de défragmenter si nécessaire).

Citation de: vivien le 05 janvier 2020 à 17:14:53

On est donc plus sur un pb lié au serveur, que lié à l'OS (j'aurais le même bug avec un autre Linux, le fait que cela se soit produit lors de la mise à jour de début décembre n'est pas lié à la mise à jour proposée)

Il y a eu des vérifications ajoutées dans le kernel car certains PC portables se sont retrouvés HS quand il ne restait plus assez d'espace libre : la protection peut être désactivée avec "efi_no_storage_paranoia", mais il faut redémarrer pour ça...
Avec une autre distribution, tout dépend si elle lance efibootmgr automatiquement lors de mises à jour ou pas. La commande a peut-être supprimé l'ancienne entrée Ubuntu, avant d'échouer à en recréer une nouvelle $:-\$

Est-ce que tu as essayé de supprimer les entrées de boot Windows avec efibootmgr ? Elles ne servent pas, et si ça fonctionne peut-être que la place libérée sera suffisante.

Citation de: thenico le 05 janvier 2020 à 15:16:16

Sinon, tu peut essayer de copier EFI\ubuntu\shmix64.efi dans EFI\BOOT\BOOTX64.EFI puis tu active le boot sur le Fixed disk Boot Device 1 avec efibootmgr -o 5

Sur Fedora c'est le cas par défaut, et ça rajoute automatiquement l'entrée de boot pour pointer ensuite sur shimx64.efi, je ne sais pas si c'est le cas sur Ubuntu.
Si Boot5 corresponde bien à la partition EFI, ça pourrait effectivement fonctionner.

hwti · « **Réponse #29 le:** 06 janvier 2020 à 01:17:36 »

Sinon, il y a d'autres problèmes en ce moment avec des machines Dell grand public et shim / grub : https://bugzilla.redhat.com/show_bug.cgi?id=1779611 sous Fedora.
Certains grubx64.efi n'arrivent pas à démarrer un kernel (écran noir ou reboot de la machine).

On voit que ce type de mise à jour présente toujours un risque.
Sous Fedora, grub n'était jamais mis à jour automatiquement sur les machine BIOS (il faillait faire un grub-install manuellement après mise à jour du paquet), mais quand ils ont eu besoin de faire des changements (https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault) ça a créé plein de problèmes.
Sur les machines UEFI, le paquet met directement à jour le grubx64.efi dans l'ESP.

vivien · « **Réponse #30 le:** 06 janvier 2020 à 10:21:33 »

Citation de: hwti le 06 janvier 2020 à 00:54:54

Est-ce que tu as essayé de supprimer les entrées de boot Windows avec efibootmgr ? Elles ne servent pas, et si ça fonctionne peut-être que la place libérée sera suffisante.

Voila :

# efibootmgr -Bb 0004 BootCurrent: 0001 Timeout: 0 seconds BootOrder: 0000,0002,0003,0005 Boot0000* Windows Boot Manager Boot0002* EFI Network 1 Boot0003* EFI Network 2 Boot0005* EFI Fixed Disk Boot Device 1 # efibootmgr -Bb 0000 BootCurrent: 0001 Timeout: 0 seconds BootOrder: 0002,0003,0005 Boot0002* EFI Network 1 Boot0003* EFI Network 2 Boot0005* EFI Fixed Disk Boot Device 1 # efibootmgr -v BootCurrent: 0001 Timeout: 0 seconds BootOrder: 0002,0003,0005 Boot0002* EFI Network 1 PcieRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/MAC(90b11c522ca3,0)/IPv4(0.0.0.00.0.0.0,0,0) Boot0003* EFI Network 2 PcieRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x1)/MAC(90b11c522ca4,0)/IPv4(0.0.0.00.0.0.0,0,0) Boot0005* EFI Fixed Disk Boot Device 1 PcieRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,c188b9a0-7588-4e8c-a27b-c87039655832,0x800,0x100000) # efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shmix64.efi" Could not prepare Boot variable: Invalid argument

vivien · « **Réponse #31 le:** 06 janvier 2020 à 10:34:36 »

Citation de: hwti le 06 janvier 2020 à 00:54:54

Sur Fedora c'est le cas par défaut, et ça rajoute automatiquement l'entrée de boot pour pointer ensuite sur shimx64.efi, je ne sais pas si c'est le cas sur Ubuntu.
Si Boot5 corresponde bien à la partition EFI, ça pourrait effectivement fonctionner.

Il semblerait que non, mais les deux fichiers présents ont été mis à jour en même temps que ceux du dossier Ubuntu.

Voici les différents dossiers de ma partition /boot/efi :

# ls -l /boot/efi total 4 drwx------ 5 root root 4096 janv. 5 14:08 EFI # ls -l /boot/efi/EFI/ total 12 drwx------ 2 root root 4096 nov. 10 2018 BOOT drwx------ 3 root root 4096 nov. 10 2018 Dell drwx------ 2 root root 4096 nov. 10 2018 ubuntu # ls -l /boot/efi/EFI/ubuntu/ total 3644 -rwx------ 1 root root 108 déc. 30 12:31 BOOTX64.CSV -rwx------ 1 root root 126 déc. 30 12:31 grub.cfg -rwx------ 1 root root 1116024 déc. 30 12:31 grubx64.efi -rwx------ 1 root root 1269496 déc. 30 12:31 mmx64.efi -rwx------ 1 root root 1334816 déc. 30 12:31 shimx64.efi # ls -l /boot/efi/EFI/BOOT total 2492 -rwx------ 1 root root 1334816 déc. 30 12:31 BOOTX64.EFI -rwx------ 1 root root 1213032 déc. 30 12:31 fbx64.efi # ls -l /boot/efi/EFI/Dell/ total 4 drwx------ 2 root root 4096 nov. 10 2018 BootOptionCache # ls -l /boot/efi/EFI/Dell/BootOptionCache/ total 4 -rwx------ 1 root root 282 nov. 10 2018 BootOptionCache.dat

Contenu de BootOptionCache.dat :
# cat /boot/efi/EFI/Dell/BootOptionCache/BootOptionCache.dat
��l�vBoot0005bubuntu��u�N�{�p9eX24\EFI\ubuntu\shimx64.efi�nBoot0005�.EFI Fixed Disk Boot Device 1��u�N�{�p9eX2�

hwti · « **Réponse #32 le:** 06 janvier 2020 à 11:56:28 »

Citation de: vivien le 06 janvier 2020 à 10:21:33

# efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shmix64.efi"
Could not prepare Boot variable: Invalid argument

C'est shimx64.efi, et pas shmix64.efi. Mais je n'ai pas l'impression que le kernel vérifie ça.
Sinon, attention avec les \, le résultat peut dépendre du shell utilisé pour cette ligne de commande (pour bash c'est correct).

Le code du kernel me semble plutôt remonter ENOSPC quand il n'y a pas passez de place, mais bizarrement pour certaines personnes efi_no_storage_paranoia était nécessaire pour ne pas avoir EINVAL.

Le code qui valide le contenu de ce que efibootmgr écrit est https://code.woboq.org/linux/linux/drivers/firmware/efi/vars.c.html#validate_load_option.
Tu peux utiliser l'option "--test boot0001.bin" pour écrire dans un fichier, on pourra essayer de le valider ensuite (soit avec du code, soit sur une autre machine, avec un "cp boot0001.bin /sys/firmware/efi/efivars/Boot1234-8be4df61-93ca-11d2-aa0d-00e098032b8".

vivien · « **Réponse #33 le:** 06 janvier 2020 à 16:52:23 »

quand je mets --test filename (Don't write to NVRAM, write to filename) j'ai systématiquement : efibootmgr: unrecognized option '--test'

j'ai essayé en mettant l'option en premier, même comportement.

Ca serait une option introduite dans une version plus récente ? (Note: J'ai le même problème avec efibootmgr version 15, version livrée avec Ubuntu 19.10)

Code: [Sélectionner]

# efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shimx64.efi" --test boot0001.bin
efibootmgr: unrecognized option '--test'
efibootmgr version 15
usage: efibootmgr [options]
	-a | --active         sets bootnum active
	-A | --inactive       sets bootnum inactive
	-b | --bootnum XXXX   modify BootXXXX (hex)
	-B | --delete-bootnum delete bootnum
	-c | --create         create new variable bootnum and add to bootorder
	-C | --create-only	create new variable bootnum and do not add to bootorder
	-D | --remove-dups	remove duplicate values from BootOrder
	-d | --disk disk       (defaults to /dev/sda) containing loader
	-r | --driver         Operate on Driver variables, not Boot Variables.
	-e | --edd [1|3|-1]   force EDD 1.0 or 3.0 creation variables, or guess
	-E | --device num      EDD 1.0 device number (defaults to 0x80)
	-g | --gpt            force disk with invalid PMBR to be treated as GPT
	-i | --iface name     create a netboot entry for the named interface
	-l | --loader name     (defaults to "\EFI\ubuntu\grub.efi")
	-L | --label label     Boot manager display label (defaults to "Linux")
	-m | --mirror-below-4G t|f mirror memory below 4GB
	-M | --mirror-above-4G X percentage memory to mirror above 4GB
	-n | --bootnext XXXX   set BootNext to XXXX (hex)
	-N | --delete-bootnext delete BootNext
	-o | --bootorder XXXX,YYYY,ZZZZ,...     explicitly set BootOrder (hex)
	-O | --delete-bootorder delete BootOrder
	-p | --part part        (defaults to 1) containing loader
	-q | --quiet            be quiet
	-t | --timeout seconds  set boot manager timeout waiting for user input.
	-T | --delete-timeout   delete Timeout.
	-u | --unicode | --UCS-2  handle extra args as UCS-2 (default is ASCII)
	-v | --verbose          print additional information
	-V | --version          return version and exit
	-w | --write-signature  write unique sig to MBR if needed
	-y | --sysprep          Operate on SysPrep variables, not Boot Variables.
	-@ | --append-binary-args file  append extra args from file (use "-" for stdin)
	-h | --help             show help/usage

Thornhill · « **Réponse #34 le:** 06 janvier 2020 à 17:07:53 »

J'ai bien cette option sur RHEL6/OL6/RHEL7/OL7, mais le versionnage RedHat suit une numérotation différente :

Code: [Sélectionner]

# efibootmgr -V
version 0.5.4
# efibootmgr -h 2>&1 |grep test
           | --test filename    don't write to NVRAM, write to filename.

Sinon avec strace tu peux avoir le contenu complet du buffer écrit sous forme ASCII/Hexa avec l'option "-e write=all".
A priori, il utilise le file descriptor 3 pour écrire, donc pour éviter que ce soit trop verbeux, "-e write=3" devrait suffire.

Code: [Sélectionner]

write(3, "\7\0\0\0\1\0\0\0b\0u\0b\0u\0n\0t\0u\0\0\0\4\1*\0\1\0\0\0"..., 122) = -1 EINVAL (Invalid argument)

la commande deviendrait donc :

Code: [Sélectionner]

strace -fe write=3 efibootmgr ....

hwti · « **Réponse #35 le:** 06 janvier 2020 à 21:30:58 »

Citation de: vivien le 06 janvier 2020 à 16:52:23

quand je mets --test filename (Don't write to NVRAM, write to filename) j'ai systématiquement : efibootmgr: unrecognized option '--test'

En fait c'est une ancienne option, je n'aurais pas dû faire confiance à une page de man trouvée sur internet.

Donc pour récupérer les données que efibootmgr essaye d'écrire, soit tu fais comme Thornhill suggère, soit il y a une autre méthode gérée dans la libefivars utilisée :

Code: [Sélectionner]

mkdir /tmp/efivars
EFIVARFS_PATH=/tmp/efivars/ efibootmgr ...

Avec ça, efibootmgr va créer des fichiers normaux.
Dans ce cas précis ce sera avec un point de départ vide, si on veut simuler de manière plus précise on peut faire un "cp /sys/firmware/efi/efivars/Boot* /tmp/efivars", mais ça ne devrait changer que le numéro qu'il va utiliser, donc le nom du fichier, pas le contenu.