Commandes pour purger les kernels

YannUbuntu · Le 23/11/2017, à 01:52

bonjour
Je transfère ici des commandes qui se trouvaient sur la doc https://doc.ubuntu-fr.org/kernel , pour éviter d'éventuels contributeurs anonymes de la doc d'y glisser des commandes dangereuses.
Cela simplifiera la surveillance de la doc.

ancien contributeur de la page kernel a écrit :

Autre façon de nettoyer pleins de noyaux d'un seul coup. Depuis un terminal, saisir les commandes suivantes :
- Lister les noyaux à supprimer :
dpkg -l | awk '{print $2}' | grep -E "linux-(image|headers)-$(uname -r | cut -d- -f1).*" | grep -v $(uname -r | sed -r -e 's:-[a-z]+.*::') | cut -d- -f-4 | sort -t- -k3,4 | uniq | head -n-2
- Si la liste est cohérente, on supprime en utilisant le résultat en paramètre de la commande [[:apt-get#suppression_purge|apt-get purge]] :
sudo apt-get purge $(dpkg -l | awk '{print $2}' | grep -E "linux-(image|headers)-$(uname -r | cut -d- -f1).*" | grep -v $(uname -r | sed -r -e 's:-[a-z]+.*::') | cut -d- -f-4 | sort -t- -k3,4 | uniq | head -n-2)
- Redémarrer le PC. Le menu GRUB ne proposera plus que deux noyaux.
Si la commande ci-dessus ne fonctionne pas, essayez celle ci :
- Lister les vieux noyaux sauf un:
dpkg -l | egrep 'linux-(image|headers)-[0-9]' | cut -d' ' -f3 | grep -v $(uname -r | cut -d- -f1,2) | cut -d- -f-4 | sort -t- -k3,4 | uniq | head -n-2
- Supprimer les anciens noyaux sauf un:
sudo apt-get purge $(dpkg -l | egrep 'linux-(image|headers)-[0-9]' | cut -d' ' -f3 | grep -v $(uname -r | cut -d- -f1,2) | cut -d- -f-4 | sort -t- -k3,4 | uniq | head -n-2)

d'ailleurs, si vous y voyez des erreurs, n'hésitez pas à les signaler dans cette discussion.

moko138 · Le 23/11/2017, à 02:26

Merci Yann ! je vois qu'en effet la Doc a été modifiée et que les lignes de nany ont été remplacées par un lien vers le message #7 de son fil ./viewtopic.php?pid=21300891#p21300891
Mais...

Attention ! il vaut mieux s'y reporter car nany le tient à jour (comme il faisait avec la Doc).
Alors que ta sauvegarde ci-dessus est antérieure à la correction du 21/8/2017 (ajout relatif à hwe).

YannUbuntu · Le 25/11/2017, à 12:01

ok, merci Moko, je supprime de la doc le lien vers cette discussion alors. (et laisse celui vers le post de Nany)

moko138 · Le 25/11/2017, à 12:11

Merci Yann !

(Et je suis content de te lire de nouveau. )

YannUbuntu · Le 25/11/2017, à 12:24

Pour alléger la doc, je déplace ici une note du paragraphe "via autoremove" qui est probablement obsolète vu que le bug en question est marqué résolu depuis longtemps.

ancien contributeur wiki a écrit :

Il est possible que cette méthode ne fonctionne pas si les noyaux sont marqués comme installés manuellement, ce même si vous effectuez normalement les mises-à-jour. Si la commande suivante vous donne des résultats, vous êtes concerné :
apt-mark showmanual | egrep 'linux-.*[0-9]' | grep -v "hwe"
Ceci est probablement un bug (celui-ci ?) mais peut être contourné temporairement lorsque vous souhaitez récupérer de l'espace, en marquant à nouveau tous les paquets relatifs au noyau comme installé en automatique avec cette commande:
sudo apt-mark auto $(apt-mark showmanual | egrep 'linux-.*[0-9]' | grep -v "hwe")
Ensuite vous pouvez faire un nettoyage automatique comme indiqué précédemment.
En cas de présence d'un grand nombre d'anciens noyaux, la mise à jour de Grub peut prendre énormément de temps.

@tous: si vous arrivez à reproduire ce bug sur une version active d'Ubuntu, merci de le signaler dans cette discussion, il faudra probablement re-ouvrir le bug , ou en créer un nouveau sur Launchpad.

YannUbuntu · Le 25/11/2017, à 12:51

(autre sujet en rapport avec le nettoyage des kernels: https://forum.ubuntu-fr.org/viewtopic.php?id=2018182 )

nam1962 · Le 25/11/2017, à 13:20

Le bug structurel n'est-il pas le fait même de garder plus de 2 noyaux ? Je ne retrouve ce comportement ni sur Debian, ni sur Manjaro.

Sinon, je vois sur la même doc une mention de ubuntu-tweak (qui n'était pas sans risque, mais surtout qui est déprécié et abandonné !)

grandtoubab · Le 25/11/2017, à 13:30

Salut
Sur Debian,
[ mode provoc]
un système qui gère bien les kernels
[/ fin du mode provoc]
je me contente de apt list linux-image* | grep install

 apt list linux-image* | grep install

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

linux-image-4.13.0-1-amd64/testing,unstable,now 4.13.13-1 amd64  [installé, automatique]
linux-image-4.9.0-4-amd64/stable,now 4.9.51-1 amd64  [installé]
linux-image-amd64/testing,unstable,now 4.13+86 amd64  [installé]

YannUbuntu · Le 25/11/2017, à 13:53

Merci nam, j'ai nettoyé la doc des référence à Ubuntu-Tweak.

Concernant le fait de conserver plus de 2 noyaux, libre à chacun de suggérer un comportement différent pour Ubuntu sur Launchpad. (je suppose que ça a déjà été suggéré d'ailleurs, il faudrait faire une recherche).

nam1962 · Le 25/11/2017, à 14:33

...j'ai regardé là : https://launchpad.net/~ubuntu-kernel-team , rien trouvé (ni compris comment leur en parler)

Zakhar · Le 25/11/2017, à 15:44

Bonjour les gens, en réalité ça me semble désormais fort simple de faire ce ménage des anciens noyaux.

Regardez :

$ ls -l /boot/vmlinuz-4.4.0-*generic
-rw------- 1 root root 7104240 nov.  10 21:41 /boot/vmlinuz-4.4.0-101-generic
-rw------- 1 root root 7101968 sept. 12 19:59 /boot/vmlinuz-4.4.0-96-generic
-rw------- 1 root root 7102864 sept. 19 22:29 /boot/vmlinuz-4.4.0-97-generic
-rw------- 1 root root 7103856 oct.  10 18:19 /boot/vmlinuz-4.4.0-98-generic

$ uname -a
Linux myself 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ sudo apt-get upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  linux-headers-4.4.0-96 linux-headers-4.4.0-96-generic linux-headers-4.4.0-97 linux-headers-4.4.0-97-generic linux-image-4.4.0-96-generic linux-image-4.4.0-97-generic linux-image-extra-4.4.0-96-generic
  linux-image-extra-4.4.0-97-generic linux-signed-image-4.4.0-96-generic linux-signed-image-4.4.0-97-generic
Veuillez utiliser « sudo apt autoremove » pour les supprimer.

J'ai 96, 97, 98, 101, comme le montre la première commande.

La deuxième commande montre que je tourne bien en 101.

La troisième commande montre que, si je veux faire le "ménage" il suffit de faire

sudo apt autoremove

... et ça va retirer tout ce qui concerne les noyaux 96 et 97, ne laissant subsiter que 98 et 101.

N'est-ce pas la fonctionnalité souhaitée : faire le ménage en une commande simple ?

Dernière modification par Zakhar (Le 25/11/2017, à 15:44)

nam1962 · Le 25/11/2017, à 16:16

Alors ça fonctionne plus ou moins suivant les cas et quand à appeler çà une solution, oui et non : pourquoi une commande que 90% des utilisateurs basiques grand public ne connaissent pas et ne savent pas passer pour régler un problème inconnu sur les autres distributions ?

grandtoubab · Le 25/11/2017, à 17:26

c'est documenté ici
https://help.ubuntu.com/community/RemoveOldKernels

root@debian:/etc/apt/apt.conf.d# cat 01autoremove-kernels
// DO NOT EDIT! File autogenerated by /etc/kernel/postinst.d/apt-auto-removal
APT::NeverAutoRemove
{
   "^linux-image-4\.13\.0-1-amd64$";
   "^linux-image-4\.9\.0-4-amd64$";
   "^linux-headers-4\.13\.0-1-amd64$";
   "^linux-headers-4\.9\.0-4-amd64$";
   "^linux-image-extra-4\.13\.0-1-amd64$";
   "^linux-image-extra-4\.9\.0-4-amd64$";
   "^linux-signed-image-4\.13\.0-1-amd64$";
   "^linux-signed-image-4\.9\.0-4-amd64$";
   "^kfreebsd-image-4\.13\.0-1-amd64$";
   "^kfreebsd-image-4\.9\.0-4-amd64$";
   "^kfreebsd-headers-4\.13\.0-1-amd64$";
   "^kfreebsd-headers-4\.9\.0-4-amd64$";
   "^gnumach-image-4\.13\.0-1-amd64$";
   "^gnumach-image-4\.9\.0-4-amd64$";
   "^.*-modules-4\.13\.0-1-amd64$";
   "^.*-modules-4\.9\.0-4-amd64$";
   "^.*-kernel-4\.13\.0-1-amd64$";
   "^.*-kernel-4\.9\.0-4-amd64$";
   "^linux-backports-modules-.*-4\.13\.0-1-amd64$";
   "^linux-backports-modules-.*-4\.9\.0-4-amd64$";
   "^linux-tools-4\.13\.0-1-amd64$";
   "^linux-tools-4\.9\.0-4-amd64$";
};
/* Debug information:
# dpkg list:
iF  linux-image-4.13.0-1-amd64            4.13.13-1                         amd64        Linux 4.13 for 64-bit PCs
ii  linux-image-4.9.0-4-amd64             4.9.51-1                          amd64        Linux 4.9 for 64-bit PCs
ii  linux-image-amd64                     4.13+86                           amd64        Linux for 64-bit PCs (meta-package)
# list of installed kernel packages:
4.13.0-1-amd64 4.13.13-1
4.9.0-4-amd64 4.9.51-1
# list of different kernel versions:
4.13.13-1
4.9.51-1
# Installing kernel: 4.13.13-1 (4.13.0-1-amd64)
# Running kernel: 4.13.13-1 (4.13.0-1-amd64)
# Last kernel: 4.13.13-1
# Previous kernel: 4.9.51-1
# Kernel versions list to keep:
4.13.13-1
4.9.51-1
# Kernel packages (version part) to protect:
4\.13\.0-1-amd64
4\.9\.0-4-amd64
*/
root@debian:/etc/apt/apt.conf.d#

Mon script perso de maintenance

root@debian:/etc/cron.weekly# cat perso-apt
#!/bin/sh
# pour tracer demasquer set -x
#set -x
#
# listage utilisation disque avant
echo " listage occupation du disque"
df -h
# tempo pour éviter les conflits de verrou
sleep 300
export DEBIAN_FRONTEND=noninteractive
echo "**********"
echo " Nettoyage"
echo " apt clean"
apt-get clean
echo "resultat de la commande apt clean ="$?
echo "*************************************"
echo " apt autoclean"
apt-get autoclean
echo "resultat de la commande apt autoclean ="$?
echo "*****************************************"
echo " apt purge"
apt-get purge --autoremove -y 
echo "resultat de la commande apt autoremove ="$? 
echo "******************************************"
# listage utilisation disque après
echo " listage occupation du disque après nettoyage"
df -h
#
root@debian:/etc/cron.weekly#

c'est cadeau

Et voilà le résultat dans le mail, ce matin

/etc/cron.weekly/perso-apt:
 listage occupation du disque
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               1,8G       0  1,8G   0% /dev
tmpfs              370M    6,6M  364M   2% /run
/dev/sda1           19G     12G  5,9G  68% /
tmpfs              1,9G     24M  1,8G   2% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              1,9G       0  1,9G   0% /sys/fs/cgroup
tmpfs              1,9G     36K  1,9G   1% /tmp
/dev/sda6          268G    217G   37G  86% /home
tmpfs              370M     20K  370M   1% /run/user/1001
**********
 Nettoyage
 apt clean
resultat de la commande apt clean =0
*************************************
 apt autoclean
Lecture des listes de paquets…
Construction de l'arbre des dépendances…
Lecture des informations d'état…
resultat de la commande apt autoclean =0
*****************************************
 apt purge
Lecture des listes de paquets…
Construction de l'arbre des dépendances…
Lecture des informations d'état…
Les paquets suivants seront ENLEVÉS :
  libopenimageio1.7* libopenvdb3.2*
0 mis à jour, 0 nouvellement installés, 2 à enlever et 0 non mis à jour.
Après cette opération, 12,3 Mo d'espace disque seront libérés.
(Lecture de la base de données... 
(Lecture de la base de données... 5%
(Lecture de la base de données... 10%
(Lecture de la base de données... 15%
(Lecture de la base de données... 20%
(Lecture de la base de données... 25%
(Lecture de la base de données... 30%
(Lecture de la base de données... 35%
(Lecture de la base de données... 40%
(Lecture de la base de données... 45%
(Lecture de la base de données... 50%
(Lecture de la base de données... 55%
(Lecture de la base de données... 60%
(Lecture de la base de données... 65%
(Lecture de la base de données... 70%
(Lecture de la base de données... 75%
(Lecture de la base de données... 80%
(Lecture de la base de données... 85%
(Lecture de la base de données... 90%
(Lecture de la base de données... 95%
(Lecture de la base de données... 100%
(Lecture de la base de données... 205653 fichiers et répertoires déjà installés.)
Suppression de libopenimageio1.7 (1.7.17~dfsg0-1+b1) ...
Suppression de libopenvdb3.2 (3.2.0-2.1) ...
Traitement des actions différées (« triggers ») pour libc-bin (2.24-17) ...
resultat de la commande apt autoremove =0
******************************************
 listage occupation du disque après nettoyage
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               1,8G       0  1,8G   0% /dev
tmpfs              370M     12M  359M   4% /run
/dev/sda1           19G     12G  5,9G  68% /
tmpfs              1,9G     16M  1,8G   1% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              1,9G       0  1,9G   0% /sys/fs/cgroup
tmpfs              1,9G     44K  1,9G   1% /tmp
/dev/sda6          268G    217G   37G  86% /home

Dernière modification par grandtoubab (Le 26/11/2017, à 10:21)

claudiux · Le 14/01/2018, à 23:15

Je regrette profondément ce "nettoyage" arbitraire de la page kernel. Cette astuce m'est encore utile sur certains ordinateurs et c'est sur cette page que je viens la chercher.

moko138 · Le 17/01/2018, à 08:03

grandtoubab,
Dans ton script, il y a clean puis autoclean.

Si tu lis le man, tu verras que clean supprime tous les .deb de /var/cache/apt/archives.
Donc après clean, autoclean a une action nulle.

autoclean ne sert que dans les conditions décrites dans le man, et à condition de ne pas faire de clean ni juste avant ni juste après.

grandtoubab · Le 17/01/2018, à 09:20

moko138 a écrit :

autoclean ne sert que dans les conditions décrites dans le man

Exact
j'ai mis autoclean en commentaire dans le script
Ceci dit du point vu du temps d'exécution du script ça ne change pas grand'chose

JulienD · Le 29/01/2018, à 13:30

@tous: si vous arrivez à reproduire ce bug sur une version active d'Ubuntu, merci de le signaler dans cette discussion, il faudra probablement re-ouvrir le bug , ou en créer un nouveau sur Launchpad.

Reproduit sur 14.04, qui est toujours censée être active jusque 2019 si je ne me trompe pas

malbo · Le 16/02/2018, à 07:41

Reproduit également sur Ubuntu 17.10. YannUbuntu ferait bien mieux de s'occuper d'autre chose que de sabrer dans la doc.
1) Je passe la commande du post #5 et j'en donne le retour complet :

malbo@monpc:~$ apt-mark showmanual | egrep 'linux-.*[0-9]' | grep -v "hwe"
linux-headers-4.13.0-17
linux-headers-4.13.0-17-generic
linux-image-4.13.0-17-generic
linux-image-extra-4.13.0-17-generic
linux-image-extra-4.13.0-31-generic
malbo@monpc:~$

On y voit que j'ai le noyau 4.13.0-17 est considéré par le système comme ayant été installé manuellement. Donc la commande de nettoyage automatique ne va pas pouvoir le supprimer.

2) Je passe quand même cette commande afin de montrer ensuite ce qu'il convient de faire pour compléter le nettoyage :

sudo apt-get autoremove --purge

Je ne colle pas le résultat de cette commande (trop indiscret) mais je donne l'extrait correspondant dans le fichier /var/log/apt/history.log :

Start-Date: 2018-02-16  06:46:58
Commandline: apt-get autoremove --purge
Requested-By: malbo (1000)
Purge: linux-image-4.13.0-21-generic:amd64 (4.13.0-21.24), linux-image-4.13.0-25-generic:amd64 (4.13.0-25.29), linux-image-extra-4.13.0-19-generic:amd64 (4.13.0-19.22), linux-headers-4.13.0-19-generic:amd64 (4.13.0-19.22), linux-image-extra-4.13.0-21-generic:amd64 (4.13.0-21.24), linux-headers-4.13.0-19:amd64 (4.13.0-19.22), linux-headers-4.13.0-21:amd64 (4.13.0-21.24), linux-headers-4.13.0-25:amd64 (4.13.0-25.29), linux-image-extra-4.13.0-25-generic:amd64 (4.13.0-25.29), linux-headers-4.13.0-21-generic:amd64 (4.13.0-21.24), linux-headers-4.13.0-25-generic:amd64 (4.13.0-25.29), linux-image-4.13.0-19-generic:amd64 (4.13.0-19.22)
End-Date: 2018-02-16  06:55:17

Comme attendu, le noyau 4.13.0-17 n'a pas été supprimé.

3) je passe la deuxième commande du post #5 qui va faire considérer par le système que tous les noyaux sont installés automatiquement :

malbo@monpc:~$ sudo apt-mark auto $(apt-mark showmanual | egrep 'linux-.*[0-9]' | grep -v "hwe")
[sudo] Mot de passe de malbo : 
linux-headers-4.13.0-17 passé en « installé automatiquement ».
linux-headers-4.13.0-17-generic passé en « installé automatiquement ».
linux-image-4.13.0-17-generic passé en « installé automatiquement ».
linux-image-extra-4.13.0-17-generic passé en « installé automatiquement ».
linux-image-extra-4.13.0-31-generic passé en « installé automatiquement ».
malbo@monpc:~$

4) Et enfin je repasse la commande de nettoyage automatique :

sudo apt-get autoremove --purge

Extrait correspondant à cette commande dans le fichier /var/log/apt/history.log :

Start-Date: 2018-02-16  07:09:01
Commandline: apt-get autoremove --purge
Requested-By: malbo (1000)
Purge: linux-image-extra-4.13.0-17-generic:amd64 (4.13.0-17.20), linux-headers-4.13.0-17-generic:amd64 (4.13.0-17.20), linux-headers-4.13.0-17:amd64 (4.13.0-17.20), linux-image-4.13.0-17-generic:amd64 (4.13.0-17.20)
End-Date: 2018-02-16  07:11:41

Cette fois, le noyau 4.13.0-17 n'a pas échappé à la purge.

Investigations sur le noyau récalcitrant :
Extrait des archives dans /var/log/apt/ :

Start-Date: 2017-11-26  16:06:05
Commandline: /usr/bin/unattended-upgrade
Install: linux-image-extra-4.13.0-17-generic:amd64 (4.13.0-17.20, automatic), linux-headers-4.13.0-17-generic:amd64 (4.13.0-17.20, automatic), linux-headers-4.13.0-17:amd64 (4.13.0-17.20, automatic), linux-image-4.13.0-17-generic:amd64 (4.13.0-17.20, automatic)
Upgrade: linux-headers-generic:amd64 (4.13.0.16.17, 4.13.0.17.18), linux-image-generic:amd64 (4.13.0.16.17, 4.13.0.17.18), linux-generic:amd64 (4.13.0.16.17, 4.13.0.17.18)
End-Date: 2017-11-26  16:09:38

L'eusses-tu cru ? Le rapport mentionne que le noyau a été installé automatiquement. Bizarre.

EDIT : je viens de modifier le paragraphe 5.1 Via autoremove pour y ajouter :
-------------------------------------------------------------------
En pratique, si un ou plusieurs vieux noyaux résistent à la purge, il suffit de passer cette commande dans le terminal :

sudo apt-mark auto $(apt-mark showmanual | egrep 'linux-.*[0-9]' | grep -v "hwe")

Puis de repasser la commande de nettoyage automatique :

sudo apt-get autoremove --purge

Après cela, il ne restera que le dernier noyau et l'avant-dernier

----------------------------------------------------------------------

Dernière modification par malbo (Le 16/02/2018, à 08:52)

moko138 · Le 16/02/2018, à 08:41

malbo a écrit :

Reproduit également sur Ubuntu 17.10. (...)

Merci malbo, de cette démonstration !

claudiux · Le 20/06/2018, à 03:25

malbo a écrit :

YannUbuntu ferait bien mieux de s'occuper d'autre chose que de sabrer dans la doc.

+1

jbubuntu · Le 20/06/2018, à 08:53

bonjour,
avez vous pensé à Uuku
Ubuntu update kernel utilty
compliment au produit
à priori cela fonctionne trés bien, c'est graphique

nam1962 · Le 20/06/2018, à 09:22

C'est surtout juste pour du test...

?? · Le 20/06/2018, à 09:24

Bonjour

Il me semble que la commande apt autoremove n'a pas encore été intégrée automatiquement en avant première de la commande qui installe un nouveau noyau et je n'ai pas réussi à mettre la main sur le rapport de bug qui signale cette absence d'exécution.

Nota même si la commande autoremove n'est pas efficace à 100%, elle fait quand même quelques épurations de noyaux.

moko138 · Le 20/06/2018, à 10:11

En #5, YannUbuntu a écrit :

Pour alléger la doc, je déplace ici une note du paragraphe "via autoremove" qui est probablement obsolète vu que le bug en question est marqué résolu depuis longtemps.
ancien contributeur wiki a écrit :
Il est possible que cette méthode ne fonctionne pas si les noyaux sont marqués comme installés manuellement, ce même si vous effectuez normalement les mises-à-jour. Si la commande suivante vous donne des résultats, vous êtes concerné :
apt-mark showmanual | egrep 'linux-.*[0-9]' | grep -v "hwe"
Ceci est probablement un bug (celui-ci ?) mais peut être contourné temporairement lorsque vous souhaitez récupérer de l'espace, en marquant à nouveau tous les paquets relatifs au noyau comme installé en automatique avec cette commande:
sudo apt-mark auto $(apt-mark showmanual | egrep 'linux-.*[0-9]' | grep -v "hwe")
Ensuite vous pouvez faire un nettoyage automatique comme indiqué précédemment.
@tous: si vous arrivez à reproduire ce bug sur une version active d'Ubuntu, merci de le signaler dans cette discussion, il faudra probablement re-ouvrir le bug , ou en créer un nouveau sur Launchpad.

Le bug est toujours présent dans Trusty (14.04).

Et le système, lorsque je lance la simulation

sudo apt-get autoremove --purge -s

peut proposer de conserver les trois noyaux ou deux ou un seul !

Le critère "apt-mark showmanual"
La dernière fois que j'ai enregistré le retour de "apt-mark showmanual", ma Trusty était munie des noyaux 3.13.0-142 et 3.13.0-119, je venais d'installer le 3.13.0-145 (le 29/4/2018 selon history.log.3.gz).
J'ai alors lancé, avant de redémarrer :

moko@lubuntu-1404:~$ [[ $(apt-mark showmanual | egrep 'linux-.*[0-9]' | grep -v "hwe") ]] && sudo apt-mark auto $(apt-mark showmanual | egrep linux-.*[0-9] | grep -v "hwe")
[sudo] password for moko: 
linux-headers-3.13.0-142 passé en « installé automatiquement ».
linux-headers-3.13.0-142-generic passé en « installé automatiquement ».
linux-headers-3.13.0-145 passé en « installé automatiquement ».
linux-headers-3.13.0-145-generic passé en « installé automatiquement ».
linux-image-3.13.0-142-generic passé en « installé automatiquement ».
linux-image-3.13.0-145-generic passé en « installé automatiquement ».
linux-image-extra-3.13.0-142-generic passé en « installé automatiquement ».
linux-image-extra-3.13.0-145-generic passé en « installé automatiquement ».
moko@lubuntu-1404:~$

= =

Sans le critère "apt-mark showmanual", à l'occasion de l'installation de chaque nouveau noyau, j'ai enregistré divers retours de commandes, dont "autoremove -s", avant et après redémarrage.
Je les tiens à votre disposition.

Dernière modification par moko138 (Le 20/06/2018, à 10:13)

nam1962 · Le 20/06/2018, à 10:51

?? a écrit :

(...) je n'ai pas réussi à mettre la main sur le rapport de bug qui signale cette absence d'exécution.

Ceux-là ?
https://bugs.launchpad.net/ubuntu/+sour … ug/1440608
https://bugs.launchpad.net/ubuntu/+sour … ug/1446269

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 23/11/2017, à 01:52

Commandes pour purger les kernels

#2 Le 23/11/2017, à 02:26

Re : Commandes pour purger les kernels

#3 Le 25/11/2017, à 12:01

Re : Commandes pour purger les kernels

#4 Le 25/11/2017, à 12:11

Re : Commandes pour purger les kernels

#5 Le 25/11/2017, à 12:24

Re : Commandes pour purger les kernels

#6 Le 25/11/2017, à 12:51

Re : Commandes pour purger les kernels

#7 Le 25/11/2017, à 13:20

Re : Commandes pour purger les kernels

#8 Le 25/11/2017, à 13:30

Re : Commandes pour purger les kernels

#9 Le 25/11/2017, à 13:53

Re : Commandes pour purger les kernels

#10 Le 25/11/2017, à 14:33

Re : Commandes pour purger les kernels

#11 Le 25/11/2017, à 15:44

Re : Commandes pour purger les kernels

#12 Le 25/11/2017, à 16:16

Re : Commandes pour purger les kernels

#13 Le 25/11/2017, à 17:26

Re : Commandes pour purger les kernels

#14 Le 14/01/2018, à 23:15

Re : Commandes pour purger les kernels

#15 Le 17/01/2018, à 08:03

Re : Commandes pour purger les kernels

#16 Le 17/01/2018, à 09:20

Re : Commandes pour purger les kernels

#17 Le 29/01/2018, à 13:30

Re : Commandes pour purger les kernels

#18 Le 16/02/2018, à 07:41

Re : Commandes pour purger les kernels

#19 Le 16/02/2018, à 08:41

Re : Commandes pour purger les kernels

#20 Le 20/06/2018, à 03:25

Re : Commandes pour purger les kernels

#21 Le 20/06/2018, à 08:53

Re : Commandes pour purger les kernels

#22 Le 20/06/2018, à 09:22

Re : Commandes pour purger les kernels

#23 Le 20/06/2018, à 09:24

Re : Commandes pour purger les kernels

#24 Le 20/06/2018, à 10:11

Re : Commandes pour purger les kernels

#25 Le 20/06/2018, à 10:51

Re : Commandes pour purger les kernels

Pied de page des forums