Vous n'êtes pas identifié(e).
Dans GParted la partition est agrémentée d'un triangle orange et les informations me donnent un avertissement:
Lorsque je fais cette vérification je me retrouve avec la même première erreur.
Pouvez-vous m'aider.
d'avance merci.
Dernière modification par pomme (06-02-2024 23:17:24)
Hors ligne
Dernière modification par --gilles-- (05-02-2024 16:05:09)
Si tout le monde pense pareil, c'est qu'aucune personne ne pense beaucoup.
Intel® Core™2 Duo E8500 × 2
4,0 Gio DDR3 - 1333 MHz
Et si vous cherchiez votre solution dans le wiki => https://debian-facile.org/accueil
Hors ligne
Hors ligne
Ce à quoi l'on a pas accès par l'expérience vécue, on a pas d'oreilles pour l'entendre ..Nietzsche
Cela dit, bien que toute notre connaissance s’amorce avec l’expérience, il n’en résulte pas pour autant qu’elle découle dans sa totalité de l’expérience. E.Kant
une compréhension insane est elle forcément irrationnel ? ..lagrenouille
Hors ligne
Hors ligne
Dernière modification par raleur (05-02-2024 15:49:30)
Il vaut mieux montrer que raconter.
Hors ligne
Je me demande si ce bug est toujours d'actualité?
Auquel cas j'utilise le "workaround" du "comment4"?
Dernière modification par pomme (05-02-2024 16:29:07)
Hors ligne
Dernière modification par raleur (05-02-2024 18:07:11)
Il vaut mieux montrer que raconter.
Hors ligne
La taille de la partition est 80 Mo
La taille de la partition est 184 Mo ?
Dans l'après-midi j'ai tenté d'installer :"systemd-boot" et "systemd-boot-efi", il est indiqué dans Synaptic "Installing systemd-boot will configure and install it in the ESP."
C'est à ce moment que j'ai eu le message indiquant que /boot/efi n'avait plus d'espace disponible, malgré leur désinstallation le problème persiste.
Dernière modification par pomme (05-02-2024 17:31:09)
Hors ligne
La taille de la partition est 184 Mo ?
Oui, j'ai écrit "80" au lieu de "180".
Un simple "ls" est un peu court pour analyser l'occupation de la partition, il faudrait creuser un peu plus.
Je n'ai aucune idée de l'espace occupé par systemd-boot dans la partition EFI. Mais je ne suis pas étonné que la désinstallation de paquets laisse des fichiers dans la partition EFI, c'est pareil avec GRUB.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Hors ligne
ls -R /boot/efi
Tu aurais pu mettre les tailles, ça aurait aidé. Nous avons donc :
- EFI/debian : GRUB (~6 Mo) installé par Debian
- EFI/Boot : copie def GRUB dans le "chemin de support amovible" (~6 Mo)
- EFI/grub : GRUB probablement installé depuis un système live ou sans /etc/default/grub (~6 Mo)
- EFI/systemd : systemd-boot (taille inconnue)
- loader : fichiers de configuration des entrées du menu BLS (Boot Loader Specification) utilisées par systemd-boot (un seul pour le noyau 6.1.0-16 pour le moment)
- 8dbdb7e30d5445aa946f0f26aaa66a86 : répertoire contenant les noyaux et initramfs du système dont l'identifiant machine est 8dbdb7e30d5445aa946f0f26aaa66a86 (cf. /etc/-machine-id) référencés par les fichiers de configuration BLS
Chacun des deux noyaux 6.1 pèse ~8 Mo et son initramfs autour de 60 Mo selon les logiciels, pilotes et firmwares inclus. C'est cela qui occupe le plus d'espace dans la partition EFI. Forcément, 100 Mo ne suffisent pas pour en mettre deux, donc l'initramfs pour 6.1.0-17 n'a pas pu être copié.
La spécification BLS appliquée par systemd-boot impose de copier les noyaux et initramfs dans la partition EFI qui doit donc être dimensionnée en conséquence, contrairement à GRUB qui laisse ces fichiers dans /boot. Les outils disponibles ne permettent pas d'agrandir le système de fichiers existant donc pour l'agrandir il faudrait sauvegarder le contenu, reformater la partition avec le même identifiant FAT et restaurer le contenu (ou le regénérer avec grub-install et la commande équivalent pour systemd-boot). 180 Mo suffiraient pour deux noyaux, mais probablement pas trois or il y a des moment où trois noyaux sont transitoirement installés, après qu'un nouveau noyau ait été installé et avant que le plus ancien soit désinstallé par autoremove. En tout cas pas avec des initramfs génériques. Des initramfs "sur mesure" construits avec MODULES=dep dans /etc/initramfs-tools/ seraient plus compacts.
Tu devrais pouvoir supprimer EFI/grub qui est a priori inutile, mais ça ne récupère que 6 Mo. Pour supprimer systemd-boot, tu peux supprimer 8dbdb7e30d5445aa946f0f26aaa66a86, loader et EFI/systemd
Mais avant tu peux exécuter
pour afficher les variables de boot EFI actives et vérifier que GRUB prendra la main.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par pomme (06-02-2024 16:32:33)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (06-02-2024 17:45:04)
Il vaut mieux montrer que raconter.
Hors ligne
J'ai ensuite exécuter grub-install et:
Merci raleur..J'aurai sûrement d'autres questions, peut-être dans un autre post.
Dernière modification par pomme (06-02-2024 23:22:15)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dans /boot/efi/EFI/systemd, le fichier systemd-bootx64.efi fait 140.3 Ko ce qui correspond a la taille de /boot/efi/EFI/Boot/bootx64.efi.
Cela confirme ce que je soupçonnais : systemd-boot s'est aussi installé dans le "chemin de support amovible" (removable media path) à la place de shim(+grub), et c'est peut-être pour cela qu'il ne s'est pas enregistré dans les variables de boot EFI (visibles avec efiboomgr). Cet emplacement est utilisé par défaut par par le firmware UEFI quand les variables de boot EFI sont manquantes ou inopérantes.
Par conséquent, si un jour la variable de boot EFI pour Debian est supprimée (cela peut arriver à cause d'une mise à jour ou d'une réinitialisation du BIOS/UEFI, de l'intervention d'un autre système d'exploitation, changement de carte mère...) alors c'est systemd-boot qui sera lancé au lieu de shim+grub. Pour l'éviter, il faut réinstaller shim dans le chemin de support amovible soit manuellement en copiant shimx64.efi sur bootx64.efi, soit en exécutant grub-install avec l'option --force-extra-removable.
j'ai demandé plusieurs fois s'il serait possible de réinitialiser /boot/efi
Réinitialiser la partition EFI, ça aurait impliqué de ne pas restaurer le contenu de la partition EFI mais de le recréer à partir de zéro en réinstallant les chargeurs d'amorçage souhaités. Il n'y a pas encore de commande universelle pour faire cela, mais certains y pensent.
Dernière modification par raleur (07-02-2024 11:58:26)
Il vaut mieux montrer que raconter.
Hors ligne
(#13)-Tu devrais pouvoir supprimer EFI/grub qui est a priori inutile, mais ça ne récupère que 6 Mo. Pour supprimer systemd-boot, tu peux supprimer 8dbdb7e30d5445aa946f0f26aaa66a86, loader et EFI/systemd
Selon toi ce que tu as écrit est-il toujours valable? Il y a maintenant de la place, mais si ça ne sert à rien, je préfère supprimer.
La commande : # efibootmgr -v donne maintenant le résultat suivant:
Présence de 2 fois debian, cela te semble-t-il cohérent ?
Merci à toi.
Dernière modification par pomme (07-02-2024 14:30:39)
Hors ligne
Considères-tu que c'est ok maintenant?
Pour que GRUB soit lancé (via shim) dans tous les cas, oui.
Selon toi ce que tu as écrit est-il toujours valable?
Oui.
Présence de 2 fois debian, cela te semble-t-il cohérent ?
L'entrée Debian qui pointe vers GRUBX64.EFI n'a pas été créée par grub-install, mais je ne suis pas particulièrement surpris de la voir revenir puisqu'elle était déjà présente avant que grub-install la supprime et remplace par shimx64.efi. Je note aussi que le chemin cible de la "bonne" entrée Debian est passé de minuscules à majuscules. Je soupçonne le firmware UEFI d'en être responsable et de faire du zèle, j'ai déjà vu ça sur un PC et une carte mère Asus. Tant que le secure boot est désactivé ou que la "bonne" entrée Debian reste en place ce n'est pas gênant mais dans le cas contraire la présence de cette entrée qui n'est pas compatible avec le secure boot pourrait empêcher la machine d'utiliser le chemin de support amovible.
Il vaut mieux montrer que raconter.
Hors ligne
L'entrée "Boot0005" est toujours présente mais sans *.
Que faut-il en penser?
Merci
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne