Grub refuse sa mise a jour

Support Debian
,
Tags: #<Tag:0x00007f574d719110> #<Tag:0x00007f574d718fa8>
#5 
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

#6

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:

#7

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.

#8

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
#9

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:

#10

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 »"

#11

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.

#12

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:

#13

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

#14

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 !

#15

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:

#16

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

#17

(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 !

#18

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.

#19

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.

#20

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
#21

Oui, j’ai noté qu’on n’avait pas la même stratégie. Personnellement je privilégie nettement la détection avec une surveillance intense avec entre autres des outils personnels nécessitant une analyse de la machine une fois qu’on est dessus donc du temps à découvert, un autre choix est de privilégier l’étanchéité de la machine, mais je crois que l’étanchéité parfaite est impossible. En clair je préfère la stratégie des «7 Samourais», mais c’est peut être une erreur.

#22

La détection de quoi? en quoi celle-ci influence-t-elle l’architecture d’une machine ou son MCO?
Pour les outils personnels tu parles en particulier des scripts? Si c’est personnel les seuls impacts potentiels sont l’utilisation de certaines librairie, ou de mal les utiliser en l’occurrence.
Qu’appelles tu « étanchéité »?

Quid?

#23

:slight_smile: Pour les 7 samourais, regarde le film, franchement il vaut le coup. Sinon dis toi bien qu’on ne joue pas dans la même catégorie; Moi j’ai eu à faire à des serveurs cruciaux mais à durée d’existence limitée (genre 2-3 mois), des serveurs de routines n’évoluant pas et en tout cas à architecture immuable. Pour tout te dire, j’ai un serveur avec un noyau 4 et des plumettes. Par étanchéité, je veux dire intrusion impossible. En tout cas, depuis la Bo, j’ai eu quelques intrusions, toutes détectées et supprimées ds les quelques heures après leur survenue. Il y a même un challenge de root-me que j’ai fait à partir de la première intrusion, tu peux le regarder si tu veux, tu as toute la discussion sur la liste debian donnée en doc. J’ai bcp appris.

#24

je l’ai vu; précurseur des 7 mercenaires, dont j’ai vu les différentes versions :slight_smile: