[Partition EFI] Plus de place sur la partition /boot/efi

[lesebas]

Salut,

J'ai un problème je n'ai plus de place sur ma partition efi qui fait 268 Mo. Voici le message à la mise à jour de linux :

Code : Tout sélectionner

==> Creating zstd-compressed initcpio image: '/boot/efi/EFI/arch/initramfs-linux-fallback.img'
zstd: error 70 : Write error : cannot write block : No space left on device 

J'ai essayé de passer en compression xz mais ce n'est pas mieux. Faut-il que je supprime l'image fallback avant de lancer la réinstallation de ''linux"?

Edit :

J'ai suivi les reco sur ce post j'ai provisoirement supprimé l'option fallback dans linux.preset. Néanmoins est-ce reasonable?

https://bbs.archlinux.org/viewtopic.php?id=282472

Au passage mon PC refusait de démarrer sur l'image linux j'avais le message "triggering uevents" et ça restait bloqué. J'ai réussi à démarre sur le noyau LTS et c'est là en lançant la mise à jour que j'ai réalisé le problème de place sur la partition efi.

[benjarobin]

Bonjour,
Tu n'as pas trop le choix :
- Soit tu augmentes la taille de cette partition,
- Soit tu n'utilises pas la partition EFI comme partition de boot (Qu'est ce que tu utilises comme bootloader ?)
- Après oui désactiver fallback est une solution. Personnellement je n'ai jamais eu besoin de cette entrée (ou peut être 1 fois en plus de 10 ans).

[papajoke]

bonjour

Soit tu n'utilises pas la partition EFI comme partition de boot

C'est ce que j'ai perso
- *.img sont dans /boot
- dans /boot/efi/EFI/ uniquement un petit fichier (grub) .efi de moins de 200ko
Donc, aucun risque de taille pour moi qui suis beaucoup plus serré que toi :

Code : Tout sélectionner

df
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda1           96M     61M   36M  64% /boot/efi

https://wiki.archlinux.org/title/EFI_sy ... unt_points

[lesebas]

Je n'utilise pas de bootloader, je boot directement depuis le bios, les entrées sont modifiées avec efibootmgr. Perso depuis plus de 15 ans je n'ai jamais utilisé le fallback d'autant que j'ai le noyau LTS d'installé également (ça ça m'a servi quelques fois là pour le coup). Du coup si je supprime les fallback, quels fichiers je dois supprimer sur la partition efi pour faire de la place?

[benjarobin]

Si tu boot directement via des entrées configuré via efibootmgr (EFISTUB), tu ne peux de toute façon pas avoir d'entrée fallback (sauf erreur de ma part). Car tu ne peux avoir qu'une entrée par kernel (vmlinuz-linux) que je sache.
Bref, tu peux supprimer sans aucun souci : initramfs*fallback.img
Après pour plus de nettoyage, il nous faut le listing de ta partition EFI.

[lesebas]

Voila le contenu de la partition :

Code : Tout sélectionner

[root@Aquilam sebastien]# cd /boot/efi/
[root@Aquilam efi]# ls -R
.:
EFI

./EFI:
arch  arch-lts

./EFI/arch:
initramfs-linux-fallback.img  initramfs-linux.img  vmlinuz-linux.efi

./EFI/arch-lts:
initramfs-linux-lts-fallback.img  vmlinuz-linux-lts.efi
initramfs-linux-lts.im

Donc à priori j'enlève les *fallback.img et je désactive aussi le fallback pour LTS.

[benjarobin]

En effet. Par curiosité, tu confirmes que tu n'as pas d'entrée listé par efibootmgr associée au fallback ?

[lesebas]

Non je n'ai pas d'entrée qui charge les noyaux fallback, mais en soit je pense qu'on peut très bien en créé une :

https://wiki.archlinux.org/title/EFISTU ... efibootmgr

Une entrée de ce type doit fonctionner je pense :

Code : Tout sélectionner

# efibootmgr --create --disk /dev/sdX --part Y --label "Arch Linux fallback" --loader /vmlinuz-linux-fallback --unicode 'root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXXXXXX rw initrd=\initramfs-linux-fallback.img'

[lesebas]

Mince ce matin à nouveau même symptôme au démarrage : l'écran reste bloqué sur le message :

Code : Tout sélectionner

triggering uevents

Je ne suis pas chez moi, j'ai du aider ma femme a redémarrer sur le noyau LTS et là ça passe. Je n'ai pas encore fait le menage dans partition EFI mais je doute que ça vienne de là.

Récemment j'ai ajouté de la RAM, une CG de recup (Radeon RX560) et un SSD 240 Go NVMe PCIe via une carte d'adaptation sur slot PCIe x4. Donc je penserai plutôt pour un problème de matériel. Comment je peux vérifier ce qui bloque le boot?

[benjarobin]

Si tu n'as pas régénérer un initramfs valide depuis, c'est normal que cela coince au démarrage...
Donc fait le ménage dans cette partition de démarrage, et régénère les initramfs via : mkinitcpio -P

[lesebas]

Si j'ai régénéré les initramfs vu que j'ai mis à jour les paquets Linux et linux-lts depuis.

J'ai trouvé ce post, ça ressemble grandement à mon problème :

https://bbs.archlinux.org/viewtopic.php?id=292265

[lesebas]

Bon de retour ce soir chez moi je check le PC. J'avais guidé ma femme dans le BIOS pour démarre sur le noyau LTS. Je vérifie le noyau chargé :

Code : Tout sélectionner

[sebastien@Aquilam ~]$ uname -a
Linux Aquilam 6.8.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 05 Apr 2024 00:14:23 +0000 x86_64 GNU/Linux

Donc elle a du se tromper et lancer le noyau standard. Ca veut dire que : le chargement ne marchait pas, on rentre dans le bios, on sélectionne le boot manuellement et la ça marche

J'ai supprimé le le initramfs-linux-fallback.img, j'ai mis à jour mon bios (il y avait 2 versions supérieures à celle installée) et relancé mkinitcpio -P : pour le moment ça marche.

PS au passage l'ordre de boot UEFI avait été perdu lors de la mise à jour du bios. Impossible de le modifier avec efibootmgr, j'ai du le faire à la main directement dans le bios... A suivre.

[lesebas]

J'écris le post précédent, je redémarre une dernière fois par acquis de conscience... HAAA planté!

Bon j'applique REISUB, ça ne redémarre pas, je force. Là : alerte bios ''CPU overheat" !

Je suis rentré dans le bios j'ai passé le profil des ventirads de ''standard'' à ''turbo'' puis redémarrage, là ça boot! J'ai regardé le contenu du journal du boot -1 mais il s'agit du dernier boot réussi, on dirait que REISUB n'a eu aucun effet.

[lesebas]

Je n'avais pas vu que SysRq était désactivé par défaut, je viens de l'activer pour pouvoir récupérer le journal en cas de prochain plantage....