[Boot] Failed to mount /boot/efi (résolu)

[trapangle]

Bonjour,

C'est un système qui marche depuis plusieurs années sans que j'aie touché aux partitions ou au boot, mais ce matin il ne démarre plus. Hier avant d'éteindre le PC j'ai fait des mises à jour Pacman (via yay) et j'ai essayé de supprimer le plus possible de paquets AUR. J'ai supprimé reiserfsprogs entre autres, parce que je ne trouvais pas de reiserfs dans mon /etc/fstab. Je le mentionne parce qu'il y a un problème de système de fichier mais je ne sais pas si c'est important.

Au boot, il plante sur

Code : Tout sélectionner

Failed to mount /boot/efi
See systemctl status boot-efi.mount for details

Ce qui donne :

Code : Tout sélectionner

mount: /boot/efi: type de système de fichier 'vfat' inconnu

Mon /etc/fstab :

Code : Tout sélectionner

#/dev/sda2
UUID=...    /    ext4    rw,relatime,data=ordered   0 1
#/dev/sdb1
UUID=...    /home    ext4    rw,relatime,data=ordered   0 2
#/dev/sda1
UUID=...    /boot/efi    vfat    rw,relatime,fmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro   0 2

J'ai un liveusb sur lequel je peux booter, /dev/sda1 y est montée automatiquement sur /run/archiso/bootmnt, aussi efivarfs sur /sys/firmware/efi/efivarfs.
Je n'arrive pas à faire un chroot sur bootmnt, je ne trouve pas de bash.

Avez-vous une idée de ce que je pourrais essayer ?

[benjarobin]

Bonjour,
C'est très étrange que /dev/sda1 soit automatiquement monté, cela ne devrait pas être le cas !
Attention, les noms changent être chaque boot, donc ici, quand je parle de /dev/sda, cela implique ton disque qui possède la partition ESP. C'est pour cela qu'il est préférable de toujours monter via les UUID ou vérifier à quoi correspond /dev/sdX.

Pourquoi parles-tu de bootmnt, et pourquoi essayes-tu de faire un chroot de cette partition, cela n'a pas de sens... Je ne suis pas sûr de comprendre ce que tu dis et/ou fais en fait.

Si tu montes /dev/sda2 (enfin ce qui correspond à cette partition et qui contient ton fstab), dans /mnt, et que tu fais un arch-chroot comme pour une installation, cela ne fonctionne pas ? Si tu n'y arrives pas, c'est très mauvais signe...

Le mieux est que tu donnes le contenu non censuré de ton fstab (pourquoi cela?) ainsi que la sortie de : blkid

Sinon, ton problème est typiquement dû à 2 problèmes :
- initramfs incomplet (mais je ne pense pas ici que cela soit le cas, car l'initramfs n'essaye pas de monter l'ESP normalement)
- Tu démarres sur le mauvais kernel : Typiquement dû à un problème d'installation et confusion entre partition de boot et partition ESP, problème de montage d'une de ces partitions lors de la mise à jour, ...

[trapangle]

Bonjour,

Merci benjarobin pour ta réponse rapide et désolé de n'avoir pas pu réagir plus tôt.

Il n'y a pas de censure, juste de l'ignorance et de la paresse (je tape ces messages sur mon téléphone, y compris le recopiage des blocs de code).

Je parlais de bootmnt parce que quand j'ai essayé de la monter sur /mnt (via /dev/sdx, je ne savais pas que ça se monte par UUID), j'ai eu un message d'erreur disant qu'elle était déjà montée sur run/archiso/bootmnt. Aussi, le liveusb que j'utilise a été écrit sur la clé USB il y a quelques années, il n'est plus récent.

J'ai essayé de faire un chroot sur la partition de boot parce que c'était la première piste que j'avais trouvée.

Mon fstab complet :

Code : Tout sélectionner

#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda2
UUID=da65c091-a39a-4a31-8726-237c887ef8bb    /    ext4    rw,relatime,data=ordered   0 1

#/dev/sdb1
UUID=89672862-681f-42ee-940e-31c2a8ef3ef3    /home    ext4    rw,relatime,data=ordered   0 2

#/dev/sda1
UUID=7687-7EC4    /boot/efi    vfat    rw,relatime,fmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro   0 2

Mon blkid :

Code : Tout sélectionner

/dev/sdb1: UUID="89672862-681f-42ee-940e-31c2a8ef3ef3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="554f047c-9492-46dd-98d5-0215191d2f9e"
/dev/sda2: UUID="da65c091-a39a-4a31-8726-237c887ef8bb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="9c038832-21c8-4eb7-b81b-3d44dfeb4c02"
/dev/sda1: UUID="7687-7EC4" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="1ea1ff60-3243-4ed1-97f5-fbc1c72e6e5b"

[benjarobin]

Hum, c'est étrange. La sortie du blkid est bien celle depuis le l'ISO d'installation, car il manque les partitions de l'ISO d'installation ?
Je pense que tu dois tout reprendre depuis le début, utilise un ISO d'installation récent.
Identifie ta partition principale via blkid, par exemple via son UUID.
Puis, montes cette partition dans /mnt, puis fais un arch-chroot.
Si tu as le moindre souci, entre, n'hésite pas à prendre des photos, même si ce n'est pas idéal...

[trapangle]

Ah, non c'était le fstab et le blkid depuis le mode rescue.
Les voici depuis l'ISO (Linux archiso 5.5.6-arch1-1) :
/etc/fstab est vide.
blkid :

Code : Tout sélectionner

/dev/sda1: BLOCK_SIZE="2048" UUID="2020-03-01-09-32-57-00" LABEL="ARCH_202003" TYPE="iso9660" PTUUID="3372b9d9" PTTYPE="dos" PARTUUID="3372b9d9-01"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="ARCHISO_EFI" LABEL="ARCHISO_EFI" UUID="117D-40D7" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3372b9d9-02"
/dev/sdb1: UUID="7687-7EC4" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="1ea1ff60-3243-4ed1-97f5-fbc1c72e6e5b"
/dev/sdb2: UUID="da65c091-a39a-4a31-8726-237c887ef8bb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="9c038832-21c8-4eb7-b81b-3d44dfeb4c02"
/dev/sdc1: UUID="89672862-681f-42ee-940e-31c2a8ef3ef3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="554f047c-9492-46dd-98d5-0215191d2f9e"
/dev/loop0: TYPE="squashfs"

Ok pour graver un ISO d'installation récent.

[benjarobin]

Je pense que tu n'en as pas forcément besoin... Tu peux déjà essayer avec l'ISO actuel.
Tu peux constater que, depuis l'ISO la partition racine se nomme /dev/sdb2 et non sda2. Donc, tu avais juste essayé de monter la mauvaise partition.
Quel chargeur de démarrage est utilisé, Grub ? Si oui, peux-tu donner aussi son fichier de configuration grub.cfg ? Sais-tu comment tu l'avais installé ?
Depuis le mode rescue, quelle est la sortie de : uname -a
Et depuis le chroot, donc à partir de l'ISO, quelle est la sortie de :

Code : Tout sélectionner

pacman -Q linux
ls -l /lib/modules

[trapangle]

En mode rescue :

Code : Tout sélectionner

uname -a
Linux earth 6.17.3-arch2-1 #1 SMP PREEMPT_DYNAMIC Fri, 17 Oct 2025 13:29:06 +0000 x86_64 GNU/Linux

Ce n'est pas Grub, je pense que c'est EFI boot stub et je ne me souviens plus comment je l'ai configuré
Sur le liveUSB (toujours le vieux) :

Code : Tout sélectionner

mkdir /mnt/r
mount /dev/sdb2 /mnt/r
cd /mnt/r
arch-chroot .    #le prompt change 
pacman -Q Linux
linux 6.17.9.arch1-1
ls -l /lib/modules 
total 4
drwxr-xr-x 4 root root 4096 Dec 14 09:15 6.17.9-arch1-1

Donc je n'ai pas la même version de linux sur mes partitions racine et boot.
Dois-je faire un pacman -S linux en mode rescue ?
Si je dois le télécharger, il va d'abord falloir que je configure le réseau, un ping ne passe pas.

Merci pour toute ton aide jusqu'ici !

[benjarobin]

Surtout, ne fais rien, tant que l'on n'a pas compris ce qui cloche. Ceci ne devrait jamais arriver, et ne peut pas arriver, depuis une installation fonctionnelle.
Si, par contre, c'est ta première mise à jour depuis ton installation, et que tu as ce problème, c'est juste ton installation qui est incorrecte.
Quelle est la sortie si tu fais ceci depuis l'ISO d'installation :

Code : Tout sélectionner

mount /dev/sdb2 /mnt
ls -l /mnt/boot /mnt/boot/efi
grep ALL_kver /mnt/etc/mkinitcpio.d/linux.preset
mount /dev/sdb1 /mnt/boot/efi
ls -l /mnt/boot/efi

Et aussi la sortie de :

Code : Tout sélectionner

efibootmgr -v

En effet, si tu es réellement en EFI boot stub, le kernel doit se trouver dans la partition ESP. Hors par défaut, le kernel est copié dans /boot, et non dans la partition ESP, qui est montée dans ton cas dans /boot/efi.
Donc avant de faire plus de spéculation, je vais attendre la sortie des commandes demandées afin d'y voir plus clair.

[trapangle]

Non, ce n'est pas la première mise à jour depuis l'installation.
En mode rescue, efibootmgr -v :


Sur l'ISO :

Code : Tout sélectionner

# mount /dev/sdb2 /mnt
# ls -l /mnt/boot /mnt/boot/efi
/mnt/boot:
total 136748
-rw-r--r-- 1 root root    307200 Dec 1 23:00  amd-ucode.img
drwxr-xr-x 2 root root      4096 May 1 2017   efi
-rw------- 1 root root 123263979 Dec 14 08:15 initramfs-linux.img
-rw-r--r-- 1 root root  16445632 Dec 14 08:15 vmlinuz-linux

/mnt/boot/efi:
total 0
# grep ALL_kver /mnt/etc/mkinitcpio.d/linux.preset
ALL_kver="/boot/vmlinuz-linux"
# mount /dev/sdb1 /mnt/boot/efi
# ls -l /mnt/boot/efi
total 4
drwxr-xr-x 3 root root 4096 May 1 2017 EFI
# ls-l /mnt/boot/efi/EFI
total 4
drwxr-xr-x 2 root root 4096 May 13 2019 arch
# ls-l /mnt/boot/efi/EFI/arch
total 353368
-rwxr-xr-x 1 root root     31232 May 13 2019  amd-ucode.img
-rwxr-xr-x 1 root root 121358038 Oct 25 13:59 initramfs-linux.img
-rwxr-xr-x 1 root root 224378368 Oct 25 13:59 initramfs-linux-fallback.img
-rwxr-xr-x 1 root root  16073216 Oct 25 13:59 vmlinuz-linux.efi

[benjarobin]

Comme cela, j'ai envie de dire que le contenu de ton linux.preset n'est pas bon. C'est les valeurs par défaut. En tout cas c'est comme cela maintenant que l'on fait afin de déployer le kernel et l'initramfs dans un chemin personnalisé.
Tu n'aurais pas changé le contenu de ce fichier ?
Où il y a un autre mécanisme sur ton système qui fait la recopie dans la partition ESP du kernel et de l'initramfs.
Tu es le seul à savoir comment était configuré ton PC, en tout cas à première vue, c'est parfaitement normal que cela ne fonctionne pas.

Pour réparer entre temps, au moins juste pour pouvoir démarrer, recopie l'initramfs et le kernel du dossier de boot, dans la partition ESP, en écrasant les vieux fichiers (bien garder les noms de fichiers qui sont dans la partition ESP)

[trapangle]

Bonjour et merci.
Oui, je me souviens que quand j'ai configuré ça, je ne comprenais pas ce que je faisais et que j'ai du bricoler avant que ça fonctionne...
Pour vérifier si j'ai bien compris avant de le faire, en chroot sur l'ISO :

Code : Tout sélectionner

mount /dev/sdb2 /mnt
mount /dev/sdb1 /mnt/boot/efi
cp /mnt/boot/initramfs-linux.img /mnt/boot/efi/EFI/arch
cp /mnt/boot/vmlinuz-linux  /mnt/boot/efi/EFI/arch/vmlinuz-linux.efi

Puis reboot et ça devrait fonctionner jusqu'au prochain update du paquet linux, c'est bien ça ?

[benjarobin]

Cela me semble bon, en effet.
Mais, très honnêtement, cette façon de faire est un peu vieillotte, personnellement, je préfère la méthode UKI.
Une fois que tu peux démarrer, je te conseillerai de passer à une image UKI qui contient tout, le kernel, l'initramfs, le microcode pour ton CPU, et les paramètres kernel.
Cette image UKI est une application EFI, qui peut être lancée de la même manière (directement depuis le firmware EFI, donc sans passer par un chargeur de démarrage).
D'ailleurs le wiki en parle : https://wiki.archlinux.org/title/EFI_bo ... rnel_image

Une fois que tu peux démarrer normalement, je serai curieux du retour de :

Code : Tout sélectionner

rg -F "vmlinuz-linux.efi" /etc/ /usr/

Si tu n'as pas la commande rg d'installée : pacman -S ripgrep

[trapangle]

Voilà, il démarre à nouveau normalement.

Code : Tout sélectionner

$ rg -F "vmlinuz-linux.efi" /etc/ /usr/ 2>/dev/null
/etc/systemd/system/efistub-update.service
6:ExecStart=/usr/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-linux.efi

$ cat /etc/systemd/system/efistub-update.service 
[Unit]
Description=Copy kernel in ESP
[Service]
Type=oneshot
ExecStart=/usr/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-linux.efi
ExecStart=/usr/bin/cp -f /boot/initramfs-linux.img /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/

$ systemctl status efistub-update.service
○ efistub-update.service - Copy kernel in ESP
     Loaded: loaded (/etc/systemd/system/efistub-update.service; static)
     Active: inactive (dead)
TriggeredBy: ● efistub-update.path

$ systemctl status efistub-update.path
● efistub-update.path - Copy kernel in ESP
     Loaded: loaded (/etc/systemd/system/efistub-update.path; enabled; preset: disabled)
     Active: active (waiting) since Tue 2025-12-16 09:55:43 CET; 52min ago
 Invocation: edb8a16b51e04770b3f0c8fb0d6920d4
   Triggers: ● efistub-update.service
   
$ cat /etc/systemd/system/efistub-update.path 
[Unit]
Description=Copy kernel in ESP
[Path]
PathChanged=/boot/initramfs-linux-fallback.img
[Install]
WantedBy=multi-user.target
WantedBy=system-update.target

Je vois à peu près la même chose sur https://wiki.archlinux.org/title/EFI_system_partition donc je suppose que c'est là que je l'ai pris à l'époque.
Le service efistub-update.service est démarré par efistub-update.path qui est lui-même actif, ça m'a l'air bon.
Par contre efistub-update.path est censé se déclencher par un changement sur /boot/initramfs-linux-fallback.img or ce fichier est absent de mon /boot. Est-ce que ça pourrait expliquer le problème ?

[benjarobin]

Est-ce que ça pourrait expliquer le problème ?

Définitivement. La question, c'est pourquoi il n'est pas présent dans le dossier de boot. À moins que tu ais modifié le fichier /etc/mkinitcpio.d/linux.preset tel que décrit ci-dessous
Tu devrais avoir plutôt ceci :

Code : Tout sélectionner

PathChanged=/boot/vmlinuz-linux
PathChanged=/boot/initramfs-linux.img

Mais tu pourrais supprimer tous ces services et remplacer par une modification de /etc/mkinitcpio.d/linux.preset
Avec ces valeurs :

Code : Tout sélectionner

default_image="/boot/efi/EFI/arch/initramfs-linux.img"
ALL_kver="/boot/efi/EFI/arch/vmlinuz-linux.efi"

Et si tu n'as pas besoin de fallback (actuellement tu n'as pas d'entrée pour cela), tu peux aussi modifier cette variable ainsi :

Code : Tout sélectionner

PRESETS=('default')

Et supprimer toute trace de vielle version de initramfs-linux-fallback.img

[trapangle]

Mon /etc/mkinitcpio.d/linux.preset avant modification :

Code : Tout sélectionner

# mkinitcpio preset file for the 'linux' package
#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"
#ALL_kerneldest="/boot/vmlinuz-linux"
PRESETS=('default')
#PRESETS=('default' 'fallback')
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux.img"
#default_uki="/efi/EFI/Linux/arch-linux.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"
#fallback_config="/etc/mkinitcpio.conf"
#fallback_image="/boot/initramfs-linux-fallback.img"
#fallback_uki="/efi/EFI/Linux/arch-linux-fallback.efi"
#fallback_options="-S autodetect"

La ligne PRESETS=('default' 'fallback') est déjà commentée, ça explique pourquoi initramfs-linux-fallback.img est absent.
Comme je n'ai jamais mis les doigts auparavant dans ce /etc/mkinitcpio.d/linux.preset, aurait-il pu être modifié par une mise à jour récente ?

Mon /etc/mkinitcpio.d/linux.preset après modification (seulement les lignes non commentées) :

Code : Tout sélectionner

ALL_kver="/boot/efi/EFI/arch/vmlinuz-linux.efi"
PRESETS=('default')
default_image="/boot/efi/EFI/arch/initramfs-linux.img"

J'ai désactivé (stop & disable) les services efistub-update.path et efistub-update.service.
Puisqu'ils ne sont plus mis à jour, j'ai supprimé (déplacé dans un autre dossier) :

Code : Tout sélectionner

/boot/initramfs-linux.img
/boot/vmlinuz-linux et 
/boot/efi/EFI/arch/initramfs-linux-fallback.img

Est-ce que je peux aussi supprimer /boot/amd-ucode.img et /boot/efi/EFI/arch/amd-ucode.img ?
Je suppose que ça ne vaut plus non plus la peine d'avoir deux partitions pour /boot et pour /boot/efi/EFI/arch. Est-ce que je peux supprimer la partition /boot et créer un dossier /boot/efi dans ma partition racine, ça marcherait comme ça ?
Comment est-ce que je peux tester que ça fonctionne ? Je dois attendre la prochaine mise à jour ?

[benjarobin]

Mon /etc/mkinitcpio.d/linux.preset avant modification ...
La ligne PRESETS=('default' 'fallback') est déjà commentée, ça explique pourquoi initramfs-linux-fallback.img est absent.
Comme je n'ai jamais mis les doigts auparavant dans ce /etc/mkinitcpio.d/linux.preset, aurait-il pu être modifié par une mise à jour récente ?

Ce fichier n'est pas touché automatiquement, cela vient de toi. Mais dans ce cas je n'explique pas comment cela pouvait fonctionnait avant !
En effet c'était la génération de l'initramfs de fallback qui déclenchait la copie des fichiers...

Mon /etc/mkinitcpio.d/linux.preset après modification (seulement les lignes non commentées)
...
J'ai désactivé (stop & disable) les services efistub-update.path et efistub-update.service.
Puisqu'ils ne sont plus mis à jour, j'ai supprimé (déplacé dans un autre dossier) ...

Parfait

Est-ce que je peux aussi supprimer /boot/amd-ucode.img et /boot/efi/EFI/arch/amd-ucode.img ?

Tu ne peux pas supprimer ce fichier !

Mais je ne sais pas s'il est utilisé. Peux-tu donner la sortie de : efibootmgr -v -u

Je suppose que ça ne vaut plus non plus la peine d'avoir deux partitions pour /boot et pour /boot/efi/EFI/arch. Est-ce que je peux supprimer la partition /boot et créer un dossier /boot/efi dans ma partition racine, ça marcherait comme ça ?

Tu n'as pas de partition /boot, tu as un dossier nommé boot dans la partition racine.
La partition ESP est maintenant recommandée d'être montée dans /efi au lieu de /boot/efi. Mais cela ne change rien. Tu peux très bien garder cela ainsi. Si tu fais le changement, il faut bien penser à adapter tous les chemins...
Donc, tu ne dois rien supprimer !

Comment est-ce que je peux tester que ça fonctionne ? Je dois attendre la prochaine mise à jour ?

C'est le mieux

[trapangle]

Voici :

Code : Tout sélectionner

$ efibootmgr -v -u
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0003
Boot0000* ArchLinux	HD(1,GPT,1ea1ff60-3243-4ed1-97f5-fbc1c72e6e5b,0x800,0x100000)/\EFI\arch\vmlinuz-linux.efiroot=UUID=da65c091-a39a-4a31-8726-237c887ef8bb rootfstype=ext4 initrd=\EFI\arch\amd-ucode.img initrd=\EFI\arch\initramfs-linux.img rw add_efi_memmap rcu_nocbs=0-15 processor.max_cstate=5
      dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 60 ff a1 1e 43 32 d1 4e 97 f5 fb c1 c7 2e 6e 5b 02 02 / 04 04 3c 00 5c 00 45 00 46 00 49 00 5c 00 61 00 72 00 63 00 68 00 5c 00 76 00 6d 00 6c 00 69 00 6e 00 75 00 7a 00 2d 00 6c 00 69 00 6e 00 75 00 78 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
    data: 72 00 6f 00 6f 00 74 00 3d 00 55 00 55 00 49 00 44 00 3d 00 64 00 61 00 36 00 35 00 63 00 30 00 39 00 31 00 2d 00 61 00 33 00 39 00 61 00 2d 00 34 00 61 00 33 00 31 00 2d 00 38 00 37 00 32 00 36 00 2d 00 32 00 33 00 37 00 63 00 38 00 38 00 37 00 65 00 66 00 38 00 62 00 62 00 20 00 72 00 6f 00 6f 00 74 00 66 00 73 00 74 00 79 00 70 00 65 00 3d 00 65 00 78 00 74 00 34 00 20 00 69 00 6e 00 69 00 74 00 72 00 64 00 3d 00 5c 00 45 00 46 00 49 00 5c 00 61 00 72 00 63 00 68 00 5c 00 61 00 6d 00 64 00 2d 00 75 00 63 00 6f 00 64 00 65 00 2e 00 69 00 6d 00 67 00 20 00 69 00 6e 00 69 00 74 00 72 00 64 00 3d 00 5c 00 45 00 46 00 49 00 5c 00 61 00 72 00 63 00 68 00 5c 00 69 00 6e 00 69 00 74 00 72 00 61 00 6d 00 66 00 73 00 2d 00 6c 00 69 00 6e 00 75 00 78 00 2e 00 69 00 6d 00 67 00 20 00 72 00 77 00 20 00 61 00 64 00 64 00 5f 00 65 00 66 00 69 00 5f 00 6d 00 65 00 6d 00 6d 00 61 00 70 00 20 00 72 00 63 00 75 00 5f 00 6e 00 6f 00 63 00 62 00 73 00 3d 00 30 00 2d 00 31 00 35 00 20 00 70 00 72 00 6f 00 63 00 65 00 73 00 73 00 6f 00 72 00 2e 00 6d 00 61 00 78 00 5f 00 63 00 73 00 74 00 61 00 74 00 65 00 3d 00 35 00
Boot0003* CD/DVD Drive	BBS(CDROM,,0x0)
      dp: 05 01 09 00 03 00 00 00 00 / 7f ff 04 00
    data: 00 00 47 4f 00 00 4e 4f b9 00 00 00 01 00 00 00 75 00 48 00 4c 00 2d 00 44 00 54 00 2d 00 53 00 54 00 20 00 44 00 56 00 44 00 52 00 41 00 4d 00 20 00 47 00 48 00 32 00 30 00 4e 00 53 00 31 00 30 00 00 00 05 01 09 00 03 00 00 00 00 7f ff 04 00 02 01 0c 00 d0 41 03 0a 00 00 00 00 01 01 06 00 03 01 01 01 06 00 01 00 03 12 0a 00 01 00 ff ff 00 00 7f ff 04 00 01 04 3e 00 ef 47 64 2d c9 3b a0 41 ac 19 4d 51 d0 1b 4c e6 35 00 4b 00 37 00 34 00 4a 00 41 00 34 00 4c 00 32 00 30 00 20 00 32 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 00 00 7f ff 04 00 00 00 42 4f
Boot0004* Hard Drive	BBS(HD,,0x0)
      dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
    data: 00 00 47 4f 00 00 4e 4f bb 00 00 00 01 00 00 00 75 00 53 00 61 00 6d 00 73 00 75 00 6e 00 67 00 20 00 53 00 53 00 44 00 20 00 38 00 35 00 30 00 20 00 45 00 56 00 4f 00 20 00 32 00 35 00 30 00 47 00 42 00 00 00 05 01 09 00 02 00 00 00 00 7f ff 04 00 02 01 0c 00 d0 41 03 0a 00 00 00 00 01 01 06 00 03 01 01 01 06 00 01 00 03 12 0a 00 03 00 ff ff 00 00 7f ff 04 00 01 04 3e 00 ef 47 64 2d c9 3b a0 41 ac 19 4d 51 d0 1b 4c e6 32 00 53 00 36 00 52 00 58 00 4e 00 4a 00 30 00 32 00 32 00 38 00 31 00 35 00 34 00 20 00 52 00 20 00 20 00 20 00 20 00 00 00 7f ff 04 00 00 00 42 4f 00 00 4e 4f ad 00 00 00 01 00 00 00 75 00 53 00 54 00 32 00 30 00 30 00 30 00 44 00 4d 00 30 00 30 00 36 00 2d 00 32 00 44 00 4d 00 31 00 36 00 34 00 00 00 05 01 09 00 02 00 00 00 00 7f ff 04 00 02 01 0c 00 d0 41 03 0a 00 00 00 00 01 01 06 00 03 01 01 01 06 00 01 00 03 12 0a 00 05 00 ff ff 00 00 7f ff 04 00 01 04 3e 00 ef 47 64 2d c9 3b a0 41 ac 19 4d 51 d0 1b 4c e6 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 35 00 5a 00 30 00 36 00 32 00 44 00 34 00 57 00 00 00 7f ff 04 00 00 00 42 4f

Je vois que /boot/efi/EFI/arch/amd-ucode.img est utilisé, mais pas /boot/amd-ucode.img, à moins qu'il n'y ait un autre système de copie du deuxième au premier ?

[benjarobin]

Sauf que /boot/amd-ucode.img appartient à un paquet. Et donc tu ne dois pas le supprimer, car il est géré via pacman.
Actuellement, tu n'as aucun système qui va recopier le fichier amd-ucode.img dans la partition ESP, donc tu dois utiliser une vielle version.
Tu peux déjà mettre à jour manuellement amd-ucode.img

Mais comme indiqué, le plus propre serait de passer à une image UKI, puis de supprimer l'entrée affichée par efibootmgr, et en créer une nouvelle

[trapangle]

Merci, je vais lire la doc sur UKI.
Aurais-tu aussi de la doc récente sur les procédures de boot et de mise à jour du noyau ? (qu'est-ce qui se passe exactement, dans quel ordre ?)
Je ne peux pas modifier le titre du sujet, peux-tu mettre le "(résolu)" ?