Bonsoir,
J’ai fait un upgrade de ma machine en ligne de commande de la version 12.4 à 12.5, cela à échoué.
J’ai un beau kernel panic au redémarrage de ma machine et je ne voudrais pas perdre le seul kernel fonctionnel qu’il me reste à disposition… du coup j’aimerai pouvoir conserver plus que 1 seul ancien noyau, comment paramétrer cela ?
Merci pour vos conseils.
Tu as automatisé la désinstallation des anciens noyaux ?
Tu as du avoir le bug Bug kernel 6.1.0-18 (cause pilote nvidia propriétaire 525.147.05)
garde toujours le kernel précédent au cas où il y a un problème avec le nouveau 
Tu as automatisé la désinstallation des anciens noyaux ?
Salut Clochette,
Ce n’est pas la question… si tu fais une apt autoremove de temps en temps, tel que dois le faire tu perds les vieux kernel.
Je veux arriver à archiver 3-4 vieux kernels, car avec 2 c’est trop juste quand ça foire du côté de chez Debian. Si ton seul kernel encore fonctionnel se fasse sabrer lui aussi tu es bonne pour une réinstallation de ta machine… Et comme entre la version 12.4 et 12.5 ils sont un peu foireux sur les bords ces derniers temps dans leur manière de maintenir notre OS pour l’instant préféré, je cherche à prévenir plutôt que guérir…
J’en suis à me demander si j’ai fait le bon choix en installant Debian.
Tu as du avoir le bug Bug kernel 6.1.0-18 (cause pilote nvidia propriétaire 525.147.05)
garde toujours le kernel précédent au cas où il y a un problème avec le nouveau
Salut Zargos,
Oui merci, c’est ce que je fais mais en certains cas ce n’est pas assez… d’où ma question ci-dessus.
Non le comportement depuis maintenant pas mal de temps c’est de conserver l’actuelle et les deux derniers, maintenant si dans les deux derniers il y en a des défectueux c’est plutôt cela qu’il faut virer ^^
Et ne pas confondre les problèmes avec la construction d’un module d’un pilote propriétaire avec Debian 
Bien entendu va donc du côté de … ah bah non … n’en déplaise à certain Debian n’a pas vocation à être une distribution hyper à jour pour du poste de travail avec tous les derniers ajout technologique.
Sinon une fois que tu as un kernel fonctionnel tu peux le marquer de manière à ne plus le retirer mais c’est pas une solution d’après moi (au cas où apt-mark doit encore re utilisable avec la nouvelle monture de APT).
Bonjour,
Pour démarrer sur l’avant dernier noyau, il est possible de changer la valeur :
GRUB DEFAULT='1>2'
dans /etc/default/grub. Et update-grub par la suite …
Je n’ai aucune idée si cette action « marque » le second noyau ou pas. Pour plus d’assurance, j’aurai utilisé apt-mark, voire je l’aurai réinstallé manuellement.
J’ai un ordi qui fonctionne sous Bookworm, avec les mises à jour incluant les nouveaux noyaux, et qui boote sur un noyau 5.XXX, le noyau 6 ne fonctionnant pas bien sur cet ordi .
Il y a un correcteur d’ortographe qui transforme les guillemets dits anglais (?) en guillemets dits français !!??!!
mettre des double quote ou simple quote autour de 1>2 
" chez moi les guillemets anglais sont respectés" (bookworm, noyau 6.1.0-17)
mais pas ici : « 1>2 »
Il suffit de mettre des espaces:
" 1>2 "
et ça marche (ça fait semblant ).
ou d’utiliser des balise adéquat pour mettre du code
Je viens de mettre en forme.
Salut Clochette,
J’utilise une Debian pure depuis 7 ans maintenant après avoir utilisé Mint durant à peu près 10 ans. Je commence à bien connaître les subtilités de cet OS…
Comme je l’ai dit je veux conserver un nombre de kernel supérieur à 2, il doit bien avoir un moyen de faire cela non ??
Ce ne serai asp le fichier /etc/apt/apt.conf.d/01autoremove qui gère de ça ??
Et ne pas confondre les problèmes avec la construction d’un module d’un pilote propriétaire avec Debian
Pour répondre à ta prise de position ci-dessus, à partir du moment ou Debian intègre un pilote propriétaire dans sa distribution, c’est aux mainteneurs de cette dite distribution d’assurer la compatibilité et le bon fonctionnement du matos utilisant le pilote en question et de nous proposer des upgrades fonctionnels et non pas foireux tel que c’est le cas ce coup ci !!
Je ne cherche pas une distribution intégrant tous les derniers softs dispo, je veux juste qqch de fonctionnel qui en plante pas et qui soit correctement patché / mis-à-jour sans que j’aie besoin de mettre les mains dans le cambouis…
Je maîtrise le concept de apt-mark, je l’ai utilisé pour ne pas perdre le kernel qui fonctionne encore actuellement chez moi… Mais cela ne m’arrange pas du tout de devoir taguer manuellement tous les futurs kernels pour qu’ils en soient pas effacés et devoir désélectionner ainsi ceux que je veux supprimer, ce n’est pas vraiment une option pratique / fonctionnelle en un tel cas… je te rejoins en cela.
GRUB DEFAULT=‹ 1>2 ›
Bonjour Bub,
Merci pour ton idée à propos de Grub que je maîtrise déjà. Malheureusement cela ne m’avance guère. Et pour te répondre, non cela ne marque pas le noyau ainsi sélectionné et en cours d’utilisation de sorte à ce qu’il ne soit pas désinstallé.
Je maîtrise aussi le concept de apt-mark je l’ai utilisé pour ne pas perdre le kernel qui fonctionne encore chez moi… Mais cela ne m’arrange pas du tout de devoir taguer manuellement tous les futurs kernels pour qu’ils en soient pas effacés et devoir désélectionner aunsi ceux que je veux supprimer, ce n’est pas vraiment une option pratique / fonctionnelle en un tel cas.
Je pencherai plus du côté de /etc/apt/apt.conf.d/01autoremove qui m’a l’air d’être le fichier qui gère la suppression des kernels, mais j’aurais besoin des conseils d’un(e) expert(e) pour le modifier correctement, sans faire d’erreurs, je le crains…
Merci malgré tout et très bonne journée à toi.
Il te faudrait mettre les paquets des noyaux en HOLD avec apt. Je crois que ça empêche autoremove de les retirer.
nope c’est géré lors de l’installation du kernel tous ça 
, tu doit aussi avoir un fichier 01autoremove-kernels qui précise le dernier installer.
// DO NOT EDIT! File autogenerated by $0
APT::LastInstalledKernel "$1";
Du coup appelé durant l’autoremove avec le fichier apt-auto-removal
Mis à part marquer le/les kernel(s) fonctionnel(s) (à minima un) je ne vois pas comment faire.
C’est une chose géré du côté de DNF chez Redhat par contre
J’entends bien combien d’entre vous ici qui se plaigne du problème remonte en amont le problème ?
La seule chose que je dit c’est que le problème est bien moins grave que le dernier beaucoup plus gênant avec le système de fichier.
Si le rythme de sortie a été modifié c’est avant tout pour s’harmoniser avec le rythme soutenue des autres distributions afin de conserver et contenter la masse d’utilisateur utilisant Debian sur du Desktop.
N’utilisant pas de Nvidia a vrai dire … je ne vois pas vraiment de souci 
mais je comprend la tout de même la gêne de voir la partie Stable de Debian pas en capacité de gérer une upgrade de kernel avec la construction d’un moule … c’est pas habituel.
Maintenant ici on fait du support, basculé sur la pause café pour digresser sur ce genre de souci, voir prenez vos avis et envie et démarrer une discussion directement sur les listes de distribution ce sera encore plus enrichissant pour eux d’avoir des retours direct d’utilisateurs.
PS
Bien que je n’apprécia pas systemd que Debian a à mes yeux tristement adopté, chez Fedora tout comme chez Ubuntu d’ailleurs, ils semblent se donner les moyens de fournir des OS 100% fonctionnels sans bugs fonctionnels même minimes, versus Debian qui semble tristement ne pas faire de la chase aux bugs une de ses priorités ;-(
Si une telle politique semble poser moins de problèmes sur des serveurs, ce n’est pas le cas des stations de travail que Debian dit prendre nativement en charge…
Bonjour Zargos,
Merci pour ta réponse, mais tel qu’exprimé ci-dessus ce n’est pas la solution viable pour moi, elle ne répond que partiellement à ma question et est trop contraignante à utiliser.
J’entends bien combien d’entre vous ici qui se plaigne du problème remonte en amont le problème ?
Ce n’est pas parce que ce genre de problèmes ne remontent pas massivement jusqu’à ce forum que cela ne touche qu’une minorité d’utilisateurs… bien des gens ne font pas remonter les pannes. Et même si c’était le cas, cette minorité aurait tout de même le droit à un support vu que l’OS en question prétend prendre en charge ce type de configurations.
A mon avis la plupart des gens qui testent Debian y renoncent rapidement notamment en raison de ce type de problèmes et du fait que Debian ne soit guère « plug and play »…
Je me souviens par exemple de GDebi qui est resté inutilisable durant toute la durée de vie de Debian 10 parce qu’il était bugé et que ses mainteneurs s’en moquaient semble-t-il… Comment veux tu conserver des utilisateurs difficilement acquis avec de pareilles politiques ??
De mon point de vue Debian se tire volontairement une balle dans le pied en agissant ainsi ;-(
Pour moi c’est anecdotique, lorsque tu as la puissance de frappes de Ubuntu tu peu te permettre de maintenir une qualité constante et un rythme de sortie rapide attirant justement beaucoup d’utilisateur de desktop avide de faire fonctionner le matériel récent.
Gdebi, j’ai utilisé une fois, après j’ai appris à administrer à la main via une CLI ma Debian.
Je dit pas qu’il ne devrais pas y avoir d’interface graphique mais c’est clairement pas une obligation pour quelque chose qui est prévue pour installer des paquets deb hors d’un dépôts …
A demi vrai, il y a pas mal de problèmes parfois aussi …
J’ai bien peur que ce soit pour ce cas la seul façon de faire, la génération des fichiers de configurations étant liés à des scripts s’activant lors de l’installation, il faudrait fouiller plus en vant les scripts d’installation afin de modifier le nombre de kernel, hors celui actif, à conserver.
Autant placé en hold un kernel fonctionnel et de temps en temps mettre à jour celui-ci quand ça marche (pour maintenir tout de même un état récent et à jour.
Linus l’avait pourtant dit :
Tu oublies probablement que beaucoup des mainteneurs en question sont bénévoles.
Tu oublies probablement que beaucoup des mainteneurs en question sont bénévoles.
Non je ne l’oublie pas, mais de toute manière ce n’est pas une excuse pour laisser trainer des bugs durant 2 ans sur une version dite stable… Si un mainteneur n’a plus le temps voir la passion de faire le job qu’il a préalablement accepter d’assumer, il doit passer le relais à un(e) autre, sans quoi c’est toute le communauté qui est impactée !!