Re bonjour,

Après quelques commandes :

sudo apt-get purge linux-image-x.x.x-x-generic

un nouveau

dpkg --list | grep linux-image

Pourquoi utiliser la ligne de commandes puisque l'interface GUI fonctionne ???

Bonjour enigma7,

Mon côté joueur ?

Ok pour le coté joueur, si cela ne fait pas fuir les nouveaux venus ou candidats.

Gaby-Jo a écrit :

Re bonjour,

Après quelques commandes :

sudo apt-get purge linux-image-x.x.x-x-generic

un nouveau

dpkg --list | grep linux-image

Bonjour,

Un peu d'accord avec enigma7 sur les nouveaux joueurs, dont je fais partie.

Je n'aurais jamais trouvé tout seul cette commande de listage, et je ne comprends pas pourquoi la commande de purge n'a pas tout supprimé, les noms qui restent semblent correspondre "x.x.x-x-generic", et pourtant ces trois derniers sont restés.

Bonjour à tous,

@ Didier , il faut supprimer noyau par noyau avec par exemple la commande :

sudo apt-get purge linux-image-6.8.0-100-generic

Si je voulais supprimer ce noyau.

Gaby-Jo a écrit :

Bonjour à tous,

@ Didier , il faut supprimer noyau par noyau avec par exemple la commande :

sudo apt-get purge linux-image-6.8.0-100-generic

Si je voulais supprimer ce noyau.

Oui,mais ce que je n'ai pas compris, c'est pourquoi les x.x.x-x dans ta commande ont réussi à cibler tous les noyaux, sauf ceux qui restent, et qui me semblent aux aussi correspondre à ce schéma de nommage.

Re ,

Non, j'ai fait noyau par noyau en les nommant comme cela :

sudo apt-get purge linux-image-6.8.0-51-generic

puis

sudo apt-get purge linux-image-6.8.0-55-generic

puis

sudo apt-get purge linux-image-6.8.0-56-generic

etc

Ah ok, j'ai cru qu'il y avait un truc genre *.*

C'est bon, merci !

Bonjour,

je veux simplement vous dire qu'avec un noyau Linux peut s'installer des dépendances comme linux-headers et linux-kbuild et encore linux-source. Pour tout voir dans l'exemple de Gaby-Jo je ferais

dpkg -l *6.8.0* | grep 'ii '

cette commande n'affiche que ce qui est installé en version 6.8.0 noyaux, headers, kbuilds et sources. On peut alors désinstaller tout ce qui concerne la version d'un noyau avec le noyau lui-même. Quand les différences de versions des noyaux sont mineures on peut ne pouvoir que désinstaller les anciens noyaux puisque les headers kuild et source peuvent servir au noyau actif. Peut-être qu'un

apt --purge autoremove

est ce qu'il y a de mieux à faire après avoir désinstaller un ancien noyau plutôtque de jouer manuellement avec ses dépendances.

Gaby-Jo a écrit :

Re ,

Non, j'ai fait noyau par noyau en les nommant comme cela :

sudo apt-get purge linux-image-6.8.0-51-generic

puis

sudo apt-get purge linux-image-6.8.0-55-generic

puis

sudo apt-get purge linux-image-6.8.0-56-generic

etc

Bonjour,

Merci de continué à alimenter ton sujet

J'ai testé ce que tu indiques pour "voir" mais sans finir, car après avoir lu enigma7, je voulais voir ce que donne l'autre méthode, et la façon de faire est +- la même tu sélectionnes juste ce que tu veux supprimer.

Edit : j'ai oublié de dire qu'après avoir cliqué sur appliquer, il y a un avertissement que d'autres choses vont également se désinstaller.

Bonjour à tous,

La commande :

apt --purge autoremove

ne passe pas chez moi.

Celle ci fonctionne :

sudo apt-get autoremove --purge

Mais ne trouve rien à désinstaller.

Parfait Gaby-Jo apt --purge autoremove passe chez moi sous Armbian basée sur Debian.

Logicien a écrit :

Parfait Gaby-Jo apt --purge autoremove passe chez moi sous Armbian basée sur Debian.

Car tu es root (ou as la permission autoremove d'une autre manière).

Logicien ,

C'est dans l'ordre inverse sous Mint (Ubuntu/Debian) :

Pas tout à fait basée sur Debian la Linux Mint. Intéressant tout de même.

Sous Debian les deux sont valables : apt-get --purge autoremove et apt --purge autoremove

Le retour est légèrement différent mais le résultat est le même.

Très étonnant que ce ne soit pas le cas sous Mint qui est un fork d'Ubuntu, lui même fork de Debian. Surtout que, comme déjà dit, depuis apt, apt-get est censé être utilisé par les scripts et apt par l'utilisateur. Faudrait que quelqu’un qui a une Ubuntu nous dise ce qu'il en est sous Ubuntu.

Sinon, il y a aussi la commande apt autopurge qui est équivalente à apt --purge autoremove

Edit : dans tous les cas, faut être root évidemment.

Je pense qu'il faut faire

sudo apt --purge autoremove

pour que ça passe, sans sudo c'est certain que ça ne passera pas à moins d'être déjà root. De toutes façons je pense que la gestion des noyaux sous Debian et compagnies n'est pas à son mieux à moins qu'une application que j'ignore puisse éviter à l'utilisateur de mettre les mains dans le cambouis.

Sous la Arch le noyau est en rolling release et seule la dernière version du noyau est installée comme celle de tous les autres paquets. La seule chose à faire est de redémarrer immédiatement après l'installation d'un nouveau noyau puisque les modules du noyau actif ont déjà été désinstallés.

Sous VoidLinux après être démarré sur le noyau le plus récent la commande

vkpurge -r all

supprime tous les anciens noyaux pour ne garder que le plus récent. On peut aussi être sélectif et ne choisir que les noyaux qu'on veut désinstaller:

vkpurge list

pour afficher les versions des noyaux installés

vkpurge -r linux-xyz

Il est joujours possible de désinstaller le noyau le plus récent et actif sous Debian Arch et VoidLinux mais il faut savoir ce que l'on fait. Sans noyau Linux installé seul ce qui est en mémoire vive du noyau actif tient le système en vie.

Pour moi, sous Ubuntu 24.04.4 LTS,

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.4 LTS
Release: 24.04
Codename: noble

apt-get --purge autoremove se lance et l'autre apt --purge autoremove ne se lance pas.

En modifiant le chemin, comme précisé dans le retour, c'est bon.

sudo /usr/bin/apt --purge autoremove
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

Logicien, je te dis merci pour la correspondance entre Linux-headers et Linux-image qui ne semble pas obligatoire d'après ce que j'ai percuté..

Voilà, précédée de sudo la commande apt --purge autoremove passe en mode utilisateur comme en root (mais superflu).

Bonjour à tous,

Je vous lis avec attention.

Sous Mint (Ubuntu/Debian) avec ou sans sudo :

Ça vient d'Ubuntu alors et Mint doit faire la même chose avec sa LMDE. Pour quel raison, mystère... Peut être qu'ils considèrent qu'autoremove est un script et qu'il doit donc être utilisé avec apt-get. Mais bon, que ce soit l'un ou l'autre, on s'en fiche, le résultat est le même.

Par contre, je ne suis pas d'accord avec toi Logicien, je trouve au contraire que la gestion des noyaux sous Debian est très simple et plus sécure que sous Arch qui par défaut ne conserve qu'un seul noyau (on peut en installer plusieurs par sécurité mais c'est à l'utilisateur de le faire). Sous Debian,. autoremove conserve par défaut les 2 dernières versions du noyau, ce qui est largement suffisant.

Re bonjour,

et Mint doit faire la même chose avec sa LMDE

Je testerai dans la journée.

A suivre.

Je ne garde qu'un seul noyau Linux avec chacune de mes distributions, le plus récent. Le noyau Linux fonctionne si bien que je me passe d'un noyau de réserve. Quant à autoremove ça doit être l'option qui évite à l'utilisateur de mettre les mains dans le cambouis. Je fais un apt-get --purge autoremove à chaque mise-à-jour ainsi que dpkg --configure -a question de vérifier que tout s'est bien passé.

Je m'assure manuellement que les anciens noyaux, headers, kbuilds et sources sont désinstallés.

R136a1

Ça vient d'Ubuntu alors et Mint doit faire la même chose avec sa LMDE. Pour quel raison, mystère...

Je trouve que Mint Zena et Ubuntu 24.04.4 sont presque identiques sans rentrer dans les profondeurs du système.

Je suis passé de Zena à Ubuntu 24.04.4 sans rien voir.

Zena est basé sur Ubuntu 24.04.4 il me semble.

D'après mes notes ce serait le Core 24 base snap le responsable.

C'est de ma faute donc j'ai viré/remplacé tous les snaps ainsi que le paquet snapd.

Re Bonjour,

Sous Gigi, cela donne :

.

La commande "apt --purge autoremove" ne passe pas.

A+

Est-ce que "sudo apt --purge autoremove" passe?

Je ne garde qu'un seul noyau Linux avec chacune de mes distributions, le plus récent. Le noyau Linux fonctionne si bien que je me passe d'un noyau de réserve. Quant à autoremove ça doit être l'option qui évite à l'utilisateur de mettre les mains dans le cambouis. Je fais un apt-get --purge autoremove à chaque mise-à-jour ainsi que dpkg --configure -a question de vérifier que tout s'est bien passé.

Je m'assure manuellement que les anciens noyaux, headers, kbuilds et sources sont désinstallés.

Logicien c'est aussi parce que tu gères ça tranquillement, tu connais bien et t'as de la pratique comme R136a1 ou Enigma7 et d'autres.J'en suis encore au stade où j'aime avoir un ou 2 kernels de base fonctionnels et démarrables en secours.

Et j'apprécie de plus en plus la sécurité et modularité Linux associées aux bureaux, kernels, paquets....

Logicien a écrit :

Est-ce que "sudo apt --purge autoremove" passe?

Bonjour à tous,

Non, voilà ce que cela donne:

Bonjour skale,

c'est certain que l'expérience change les pratiques. Je suis du type à ne rien garder de superflu question d'y voir clair pour ne pas me perdre.

Gaby-Jo

Change le chemin de la commande sudo apt --purge autoremove par /usr/bin/apt et elle fonctionne.

C'est pinailler un peu puisque l'autre commande est efficace aussi.

Il y a donc deux commandes apt sous Mint /usr/local/bin/apt et /usr/bin/apt, celle de Mint et celle de Debian. C'est d'autant plus drôle que le chemin /usr/local/bin/ est recherché avant /usr/bin/ dans le PATH mais c'est dans les détails mêmes insignifiants qu'on y voit plus clair.

@ skale

Oui Zena est basée sur Ubuntu 24, c'est la même distribution mais avec les plus-values apportées par Mint. Les forks sont toujours très proches des distributions mères puisqu'elles sont basées sur elles (CachyOS vs Arch, Bazzite vs Fedora etc).

@ Logicien

Sous Arch j'ai toujours installé le kernel LTS en plus du Vanilla. Sous Debian, j'utilise beaucoup autoremove, du coup je le laisse faire son travail avec les kernels aussi puisque c'est la politique de Debian. Après c'est vrai que je n'ai jamais eu besoin des kernels de secours sous Arch comme sous Debian...

Sinon, Gaby-Jo et skale, vous avez essayé avec apt autopurge ?

Mon noyau Linux préféré sous la Arch est linux-hardened.

pacman -Ss linux-hardened
extra/linux-hardened 6.18.17.hardened1-1 [installé]
The Security-Hardened Linux kernel and modules
extra/linux-hardened-docs 6.18.17.hardened1-1 [installé]
Documentation for the Security-Hardened Linux kernel
extra/linux-hardened-headers 6.18.17.hardened1-1 [installé]
Headers and scripts for building modules for the Security-Hardened Linux kernel
extra/usbctl 1.2-3 [installé]
Linux-hardened deny_new_usb control

R136a1

Sinon, Gaby-Jo et skale, vous avez essayé avec apt autopurge ?

Fonctionne et je n'ai pas de pb de paquets.

J'y fais attention.

Gaby-Jo a écrit :

Logicien a écrit :

Est-ce que "sudo apt --purge autoremove" passe?

Bonjour à tous,

Non, voilà ce que cela donne:

Je répète sans doute depuis le début, sous Mint on utilise l'interface graphique (qui met également à jour les Cinnamon spices). Pourquoi s'enmerder ? Itou pour faire le ménage dans les noyaux. Je fais ainsi depuis que j'utilise Mint (CAD 2018) sur 3 machines et 0 problème.

Je me mets à la place d'un nouvel arrivant sur Linux, ehh ben vous en faites des salades pour rien ....

J'ai tout de même remarqué que la mise à jour graphique sous Ubuntu et même sous Mint à l'époque que celle-ci s'actualisait en retard par rapport à l'APT.

Ou c'est moi qui n'ai pas vu ou raté une auto actualisation via l'interface graphique lié au système en temps réel ou proche.

Et je vois souvent pour ne pas dire toujours mintupdate l'exécutable pour lancer l'interface graphique du petit écusson restait avec le point orange en demande d'actualisation alors que je l'ai faite via le terminal en APT depuis 5 minutes.

Ce retard je n'aime pas sinon elle est pratique oui.

On ne peut pas parler uniquement que de sujets qui sont accessibles aux débutants surtout dans un forum Linux générique. Il y a autre chose que Linux Mint et les débutants.

D'accord avec Logicien. Et puis si des débutants ont envie de découvrir le terminal et ses commandes, il faut les aider plutôt que de les critiquer... Les uns préfèrent les outils graphiques, les autres le terminal et encore d'autres les deux. C'est aussi ça linux, le choix d'utiliser les outils qu'on veut.

skale a écrit :

J'ai tout de même remarqué que la mise à jour graphique sous Ubuntu et même sous Mint à l'époque que celle-ci s'actualisait en retard par rapport à l'APT.

Ou c'est moi qui n'ai pas vu ou raté une auto actualisation via l'interface graphique lié au système en temps réel ou proche.

Et je vois souvent pour ne pas dire toujours mintupdate l'exécutable pour lancer l'interface graphique du petit écusson restait avec le point orange en demande d'actualisation alors que je l'ai faite via le terminal en APT depuis 5 minutes.

Ce retard je n'aime pas sinon elle est pratique oui.

Le point rouge veut dire qu'il faut rebooter (suite à kernel update ou autre). Si tu fais un rafraîchissement tu as les updates en même temps que via apt car l'interface graphique se base dessus.