Grub refuse sa mise a jour

Tags: #<Tag:0x00007f57584562d8> #<Tag:0x00007f5758455ea0>

Bonjour,

Mon Grub il fait rien que expres de pas vouloir se mettre a jour !!! :slight_smile:
C’est la deuxieme mise a jour par Discover qui ne peut updater Grub.

Error while installing package: installed grub-pc package post-installation script subprocess returned error exit status 1

Sauf erreur, il me semble que le Kernel vient d’etre mis a jour.
Est ce que ca ne pourrait pas aboutir a une situation compliquée ?

Sauf erreur, j’en suis la :

Linux version 6.1.0-48-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.172-1 (2026-05-15)

Cdt

bonjour,
ton premier message d’erreur doit avoir des lignes avant ou après qui disent éventuellement pourquoi.

Bonjour
Je viens d’avoir un nouvel update…
la mise a jour se passe bien et au final j’ai a nouveau le meme message.
Je n’ai que ce message.
Un autre message a aller chercher dans des logs quelque part ?
Dans les mises a jour annoncées il 'est pas fait etat d’une mise a jour de grub.
Update garde en memoire les echecs et les relance indefiniment jusqu’a ce que ca passe ?
Cdt

À chaque mise à jour tu as un update grub qui se fait, tu peux voir ce qui se passe via un
«dpkg-reconfigure grub-pc». Mais le mieux est de regarder le script
/var/lib/dpkg/info/grub-pc.postinst. Tu t’aperçois qu’il fait une configuration qui a priori ne change pas suivi d’un update-grub. C’est sans doute ça qui coince. Essaye donc un

update-grub

sous root ou via sudo

Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.1.0-48-amd64
Found initrd image: /boot/initrd.img-6.1.0-48-amd64
Found linux image: /boot/vmlinuz-6.1.0-47-amd64
Found initrd image: /boot/initrd.img-6.1.0-47-amd64
Found linux image: /boot/vmlinuz-6.1.0-45-amd64
Found initrd image: /boot/initrd.img-6.1.0-45-amd64
Found linux image: /boot/vmlinuz-6.1.0-44-amd64
Found initrd image: /boot/initrd.img-6.1.0-44-amd64
Found linux image: /boot/vmlinuz-6.1.0-43-amd64
Found initrd image: /boot/initrd.img-6.1.0-43-amd64
Found linux image: /boot/vmlinuz-6.1.0-42-amd64
Found initrd image: /boot/initrd.img-6.1.0-42-amd64
Found linux image: /boot/vmlinuz-6.1.0-41-amd64
Found initrd image: /boot/initrd.img-6.1.0-41-amd64
Found linux image: /boot/vmlinuz-6.1.0-40-amd64
Found initrd image: /boot/initrd.img-6.1.0-40-amd64
Found linux image: /boot/vmlinuz-6.1.0-39-amd64
Found initrd image: /boot/initrd.img-6.1.0-39-amd64
Found linux image: /boot/vmlinuz-6.1.0-38-amd64
Found initrd image: /boot/initrd.img-6.1.0-38-amd64
Found linux image: /boot/vmlinuz-6.1.0-37-amd64
Found initrd image: /boot/initrd.img-6.1.0-37-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done

Ca cherche un « vidangeage » ??

Cdt

il ne fait pas de mise à jour de grub, mais si les autres mises à jour ont une dépendance avec grub, alors les postscripts de grub vont s’executer.

+1 :+1:

Sur quelle version de Debian es-tu? Car ce ne sont pas des version Trixie.

Il te faudrait aussi faire un apt --purge autoremove, car tu as un bine trop grand nombre de version.

Bon, le update-grub se passe bien, excepté la présence de plein de noya, tu devrais en virer qques uns.

Essaye de voir le contenu de /var/log/apt/term.log et le résultat de
journalctl -xe | grep -i grub

Oui surtout lors de l’installation d’un noyau

1 J'aime

OK c’est purgé… On verra pour la suite… mais c’est clair qu’il fallait faire du menage.
Quand je vois passer nvidia dans le terminal, j’ai les chevilles qui commencent a faire des castagnettes :slight_smile:

Effectivement je suis toujours sur la 12 .
Je suis en mode sécurisation… depuis 3 mois au moins :slight_smile:

Bonjour,

C’est quoi ça ? je ne connais pas ce mode ?


@fech Sinon, c’est quoi ce titre ?
Merci de le modifier pour en mettre un signifiant le problème !
Relire les règles du forum ne serait pas de trop, surtout le chapitre " PARTICULARITÉ POUR LES SECTIONS « SUPPORT DEBIAN » (SD), « FORUM INTERNE » (FI) ET « PROGRAMMATION »"

Il ne veux pas passer à Trixie parce qu’il a peur d’essuyer des platre. La notion de « sécurisation » ici n’en est pas une.

Ahhh, ok ! (je comprends mieux, merci à toi)

Depuis trois mois ? Soit !
On en est quand même à la version 5 de Trixie… on en est plus à « attendre au cas où il y aurait des plâtres à essuyer ».
Au moins @fech répond aux questions, c’est déjà ça :wink:

c’est un mode tres personnel
Mode j’ai pas envie de cracher mon systeme en faisant un upgrade majeur donc je repousse tjrs et encore la mise a jour… en mettant le plus de fichiers en sécurité, et en testant en parallele sur un autre ordi Trixie… avec une config differente mais bon, ca permet de voir

OK, pas de soucis.

Mais ça fait plus « j’ai tellement peur… que je suis paralysé », oui ? non ?
à moment donné, il faut le faire, car les mises à niveau apporte son lot de correctifs de sécurité principalement.
Attendre la v1, cela peut avoir du sens et n’est pas un soucis ; mais à la énième version qui n’apporte pas de changements majeurs, mais juste principalement des correctifs, c’est un « non-sens », une « paralysie personnelle » qui a pour conséquence de « figer le système » alors qu’il n’y a pas lieu, et qu’au final, ce serait mauvais pour le système qu’on veut « trop protéger en l’état, parce qu’au moins ça fonctionne ».

OK, on a déjà vu des versions mineures apportaient son lot de dysfonctionnement, mais le lendemain ou le surlendemain, un correctif de version était disponible. C’est une situation extrêmement rare.
Donc, là encore attendre quelques jours avant de mettre à jour son système, histoire de suivre l’actualité Debian et réaliser qu’il n’y a pas de soucis majeures à ces versions mineures… mais plusieurs mois, n’a pas de sens légitime.

Vous confondez vraiment !
Une nouvelle version de la Stable n’est pas un upgrade majeur, aucunement. Elle(s) apporte(nt) toutes principalement des mises à jours sécu, à utiliser au cas où cela n’aurait pas été fait par le biais de l’outil apt.

Par contre, il est vrai que certains binaires posent leur lot de soucis, tel ceux de Nvidia, mais dans cet exemple, cela signifie l’utilisation des micro-logiciels privatifs, et non pas de nouveau. Malheureusement, comme chaque machine est particulière, on ne peut savoir à l’avance, s’il y aura tel ou tel dysfonctionnement ; pour reprendre l’exemple de nvidia, une mise à jour peut très bien se passer, et une autre pas du tout, et inversement, sur une autre, ou aucun soucis nul part.
@Zargos est un « expert » nvidia ! :stuck_out_tongue:


PS : Merci d’avoir changé le titre !

Je suis d’accord avec ca :slight_smile:
Apres 2 crashs complets (pas la meme semaine heureusement :slight_smile: ) oui il y a hesitation… hesitation accentuée par le fait qu’il n’y a pas d’urgence… vu que la 12 est tjrs en vie, vu que les contraintes ne sont pas majeures et vu que l’occupation de cet OS est de grosso modo 50% du temps… j’irais jusqu’a 60 allez :slight_smile:
J’ai de toutes manières une Trixie qui tourne de temps en temps en VM, en concurrence avec une Fedora, une Leap et une ZorinOS… C’est du temps très partagé… sur la meme machine… ce qui pousse probablement à procrastiner la MAJ de la machine mère :slight_smile:
Merci pour cette analyse psychologique. Combien je te dois ? :slight_smile:

LA 12 est certes en vie, mais elle est considérée comme « oldstable » :wink:
Faudrait pas « sur-tarder »…

(Long Term Support – LTS) jusqu’au 30 juin 2028.
Y a peut etre moyen que je passe à la 14 en évitant le 13 :slight_smile: … ou pas !

Non, un upgrade se fait par palier successif:
12 → dist-upgrade → changement de sources.list version + 1 → upgrade → resolution pbm éventuels (rares) → dist-upgrade → adaptation suite à d’eventuels changements de réglages par defaut de logiciels → 13 fonctionnel → changement de sources.list → upgrade → resolution pbm éventuels (rares) → dist-upgrade → adaptation suite à d’eventuels changements de réglages par defaut de logiciels → 14 fonctionnel → … etc.
Je déconseille formetement les sauts de versions.
En revanche rien n’interdit de rester sur une bookworm.

Et il n’y a pas que toi, c’est clairement le conseil donné par l’équipe.

Passer de la 12 à la 14 doit absolument se faire soit par un support d’installation, et donc de formater les partitions adéquates, soit faire une montée en version : 12 → 13 → 14 et le faire correctement. :wink:

En effet, sauf mise à part très certainement l’aspect sécurité logiciels.

Ce qui est écrit sur la page LTS du wiki Debian est intéressant :

Debian LTS est géré par un groupe distinct de bénévoles et sociétés intéressés pour en faire un succès. Debian LTS n’est pas géré par les équipes en charge de la sécurité de Debian et de la publication de Debian. Ainsi, l’équipe Debian LTS prendra en charge les mises à jour de sécurité des différentes versions une fois que l’équipe en charge de la sécurité aura terminé son travail.

utile et à prendre en compte avant de faire le choix :wink:
Car cela signifie que les màj de sécurité pour la LTS se font vraiment « en bout de chaîne », ce sont les derniers servis.

Sauf que si c’est trop long peuvent se présenter des écarts d’architecture, ou des problèmes de sécurité qui ne sont pas forcement soluble sur la vieille version.

1 J'aime