La gestion des mises à niveau et des kernels continue à être sale

nam1962 · Le 29/10/2018, à 13:35

Je constate dans de nombreux fils d'aide que les sources, post mise à niveau vers la 18.04, gardent plein de scories de la version précédente :

Un exemple typique :

gille@gilles-hp-probook-470-g3:~$ cat /etc/apt/sources.list
# deb cdrom:[Ubuntu 16.04.2 LTS _Xenial Xerus_ - Release amd64 (20170215.2)]/ xenial main restricted

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial main restricted

## Major bug fix updates produced after the final release of the
## distribution.
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic universe main
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial universe
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-updates universe main
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu 
## team, and may not be under a free licence. Please satisfy yourself as to 
## your rights to use the software. Also, please note that software in 
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-updates multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-backports universe multiverse main
# deb-src http://fr.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
deb http://archive.canonical.com/ubuntu bionic partner
deb-src http://archive.canonical.com/ubuntu bionic partner

# deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
deb http://security.ubuntu.com/ubuntu bionic-security universe main
# deb-src http://security.ubuntu.com/ubuntu xenial-security universe
deb http://security.ubuntu.com/ubuntu bionic-security multiverse
# deb-src http://security.ubuntu.com/ubuntu xenial-security multiverse
deb http://archive.ubuntu.com/ubuntu bionic main # auto generated by ubuntu-release-upgrader
gille@gilles-hp-probook-470-g3:~$

Par ailleurs, et même si c'est plus ou moins décrit dans la doc officielle :

xubu1957 a écrit :

(...)
extrait a écrit :
hwe-16.04
DESCRIPTION
This represents the path where HWE Stack users on Ubuntu 16.04 LTS will automatically upgrade to newer HWE Stacks until reaching the final 18.04 HWE Stack in Ubuntu 16.04 LTS. Users will then remain on this final 18.04 HWE Stack for the remaining supported life of the Ubuntu 16.04 LTS. If the user fully upgrades to Ubuntu 18.04 LTS, they will remain on the GA Kernel delivered in Ubuntu 18.04 LTS and will not continue rolling forward on HWE Stacks delivered for 18.04. This is the path that users will be put on if choosing to install the HWE Stack from the 16.04.2 or newer LTS point release.
> wiki.ubuntu.com/Kernel/RollingLTSEnablementStack#Update_Schedule-1

En dépit d'un nettoyage complet, on retrouve des meta paquets de la version précédente dans les kernels (et... 3 versions de kernel, même après avoir marqué en "auto" et passé autoremove) :

gille@gilles-hp-probook-470-g3:~$ dpkg -l | grep -Ei " linux-(g|h|i|lo|m|si|t)" | sort -k3 | tr -s " " | cut -d" " -s -f1,2,3 | column -s" " -t
ii  linux-headers-4.15.0-34                4.15.0-34.37
ii  linux-modules-4.15.0-34-generic        4.15.0-34.37
ii  linux-modules-extra-4.15.0-34-generic  4.15.0-34.37
ii  linux-headers-4.15.0-34-generic        4.15.0-34.37
ii  linux-image-4.15.0-34-generic          4.15.0-34.37
ii  linux-headers-4.15.0-36                4.15.0-36.39
ii  linux-modules-4.15.0-36-generic        4.15.0-36.39
ii  linux-modules-extra-4.15.0-36-generic  4.15.0-36.39
ii  linux-headers-4.15.0-36-generic        4.15.0-36.39
ii  linux-image-4.15.0-36-generic          4.15.0-36.39
ii  linux-generic                          4.15.0.38.40
ii  linux-generic-hwe-16.04                4.15.0.38.40
ii  linux-headers-generic                  4.15.0.38.40
ii  linux-headers-generic-hwe-16.04        4.15.0.38.40
ii  linux-image-generic                    4.15.0.38.40
ii  linux-headers-4.15.0-38                4.15.0-38.41
ii  linux-modules-4.15.0-38-generic        4.15.0-38.41
ii  linux-modules-extra-4.15.0-38-generic  4.15.0-38.41
ii  linux-headers-4.15.0-38-generic        4.15.0-38.41
ii  linux-image-4.15.0-38-generic          4.15.0-38.41
gille@gilles-hp-probook-470-g3:~$

(extraits de ce fil récent : http://forum.ubuntu-fr.org/viewtopic.ph … #p21996221 )

Deux questions :

- pourquoi l'outil de mise à niveau ne vire t'il pas tout simplement toute trace de la version précédente ?
- comment nettoyer proprement et sans danger les résidus de méta-paquets de kernels d'une version précédente ?

Dernière modification par nam1962 (Le 29/10/2018, à 13:36)

xubu1957 · Le 29/10/2018, à 13:48

Le système avait conservé deux noyaux et intégrait dans les dernières mises à jour, le noyau 4.15.0-38.

Au redémarrage, on arrive à trois noyaux.

nany · Le 29/10/2018, à 13:58

nam1962 a écrit :

- pourquoi l'outil de mise à niveau ne vire t'il pas tout simplement toute trace de la version précédente ?

Bonne question. Ça mériterait peut-être un rapport de bug s’il n’en existe pas déjà un.

- comment nettoyer proprement et sans danger les résidus de méta-paquets de kernels d'une version précédente ?

Je pencherais pour traiter le problème au cas par cas. Dans le cas présent, comme tout est en version 4.15, il suffit de virer les méta-paquets :

sudo apt purge linux*hwe-16.04

À noter que des paquets linux-modules sont apparus avec 18.04.

xubu1957 a écrit :

Le système avait conservé deux noyaux et intégrait dans les dernières mises à jour, le noyau 4.15.0-38.
Au redémarrage, on arrive à trois noyaux.

Oui, et le gestionnaire de mise à jour devrait proposer la désinstallation du noyau le plus ancien d’ici quelques jours.

xubu1957 · Le 29/10/2018, à 15:37

Je rapatrie de la documentation officielle :

> ubuntu.com/about/release-cycle

> wiki.ubuntu.com/Kernel/FAQ

xubu1957 · Le 30/10/2018, à 14:48

Bonjour,

Je profite de cette discussion, pour demander votre avis sur les noyaux edge, en raison de ce fil [résolu]Paquet cassé - tables.h absent

suite de > Problèmes à répétition ubuntu 16 - .

_ _ _

Noyau intéressant pour la prise en compte de matériel récent > [Résolu]Souci d'installation (Acer Aspire 3 A315-21-645X)

Dernière modification par xubu1957 (Le 30/10/2018, à 15:53)

moko138 · Le 30/10/2018, à 15:46

nam1962 a écrit :

- pourquoi l'outil de mise à niveau ne vire t'il pas tout simplement toute trace de la version précédente ?

Si tu parles des noyaux 4.13.0 quand on a démarré sur un 4.15.0,
je suppose que c'est un choix délibéré. En tout cas, il y a de rares cas où ça se justifie par une fonction perdue avec la mise à niveau ; je pense au cas récent de fwehrli, dont le tableau blanc interactif (TBI) est pris en charge par ses noyaux 4.13 mais pas par 4.15.
Et comme il en a besoin tous les jours ou presque, au boulot...

moko138 · Le 30/10/2018, à 15:55

xubu1957 a écrit :

Je profite de cette discussion, pour demander votre avis sur les noyaux edge, en raison de ce fil [résolu]Paquet cassé - tables.h absent

Pas encore tout lu, mais en #20 je vois un truc qui me fait frémir quand je repense à une gaffe bourde mémorable de ma part :
un astérisque dans la ligne de commande de sudo apt.
Je n'ai pas le niveau pour manipuler ce genre de bombe.

Dernière modification par moko138 (Le 30/10/2018, à 15:57)

xubu1957 · Le 30/10/2018, à 16:01

@moko138

J'étais parti de la commande du #3 de nany :

sudo apt purge linux*hwe-16.04

pour proposer une simulation :

sudo apt -s purge linux*hwe-16.04-edge

Dernière modification par xubu1957 (Le 30/10/2018, à 16:09)

Nuliel · Le 30/10/2018, à 16:07

J'ai déjà cassé une install avec un astérisque et apt autoremove très généreux du coup.
@moko138: l'erreur que tu as faite, c'était sur le système de emena? Si oui c'est quoi la commande? (simplement pour simuler sur mon pc ce qui serait supprimé)

Dernière modification par Nuliel (Le 30/10/2018, à 16:09)

moko138 · Le 30/10/2018, à 17:03

xubu1957 : oui j'avais vu le -s.

Naziel : non c'est beaucoup plus vieux que ça.
C'était ./viewtopic.php?pid=17743361#p17743361 dans le cadre d'un trop-plein de noyaux, j'avais conseillé :

sudo apt-get remove linux-headers-3.11.0-1* linux-headers-3.11.0-1*-generic linux-image-3.11.0-1*-generic linux-image-extra-3.11.0-1* --purge

qui visait à supprimer les noyaux les plus anciens... et qui avait enlevé, je crois, tous les noyaux.

Pris, trop tard, d'un doute, j'avais demandé ses lumières à tiramiseb ; j'ai gardé son courriel de réponse - détaillé - en .pdf. Je viens de le retrouver.
Je ne peux pas le résumer, je tâcherai de le mettre en forme sur le forum, mais in extenso.
Ce que je peux dire très vite :
- derrière apt, le point ne fonctionne pas comme ailleurs ;
- derrière sudo commande *, l'astérisque ne fonctionne pas comme ailleurs : il y a
d'abord commande *, qui fonctionne... ou pas, faute de permission,
PUIS
sudo agit sur le résultat de commande *, souvent incomplet ou absurde, faute de permission, donc.

xubu1957 · Le 30/10/2018, à 17:12

J'avais eu cette réponse :

Le 27/04/2017, cqfd93 a écrit :

xubu1957 a écrit :
@ cqfd93
sudo rm /boot/*-4.4.0-21-generic
On obtient l'effacement du noyau pareil ?
Ça supprime les fichier de /boot mais apt croit toujours que le noyau est installé, il faut donc aussi désinstaller le noyau avec apt purge.
On peut utiliser le joker * pour supprimer en grappe avec rm mais attention, avec apt ça ne marche pas pareil et on peut supprimer bien trop de choses et faire des dégâts donc par précaution, ne pas utiliser de joker avec apt !

> [Résolu] Ubuntu 16.04 LTS Logithèque mise à jour bloquée

grandtoubab · Le 30/10/2018, à 17:15

Salut
je me suis ajouté un script kernel-automatique dans le calendrier hebdomadaire /etc/cron.weekly

root@debian:/etc/cron.weekly# cat kernel-automatique

#!/bin/bash
#
#set -x
export DEBIAN_FRONTEND=noninteractive
apt-mark auto $(apt-mark showmanual | grep -E "^linux-([[:alpha:]]+-)+[[:digit:].]+-[^-]+(|-.+)$")
#
bash /etc/kernel/postinst.d/apt-auto-removal
apt autoremove -y
apt list --installed | grep linux-image
apt list --installed | grep linux-headers

exit 0

NB je lis avec Thunderbird les compte-rendus des scripts cron qui sont envoyés à root

Dernière modification par grandtoubab (Le 30/10/2018, à 17:17)

Mornagest · Le 30/10/2018, à 17:37

moko138 a écrit :

xubu1957 : oui j'avais vu le -s.

Naziel : non c'est beaucoup plus vieux que ça.
C'était ./viewtopic.php?pid=17743361#p17743361 dans le cadre d'un trop-plein de noyaux, j'avais conseillé :
sudo apt-get remove linux-headers-3.11.0-1* linux-headers-3.11.0-1*-generic linux-image-3.11.0-1*-generic linux-image-extra-3.11.0-1* --purge
qui visait à supprimer les noyaux les plus anciens... et qui avait enlevé, je crois, tous les noyaux.
Pris, trop tard, d'un doute, j'avais demandé ses lumières à tiramiseb ; j'ai gardé son courriel de réponse - détaillé - en .pdf. Je viens de le retrouver.
Je ne peux pas le résumer, je tâcherai de le mettre en forme sur le forum, mais in extenso.
Ce que je peux dire très vite :
- derrière apt, le point ne fonctionne pas comme ailleurs ;
- derrière sudo commande *, l'astérisque ne fonctionne pas comme ailleurs : il y a
d'abord commande *, qui fonctionne... ou pas, faute de permission,
PUIS
sudo agit sur le résultat de commande *, souvent incomplet ou absurde, faute de permission, donc.

Est-ce que apt et apt-get réagissent de la même manière sur ce point ?

moko138 · Le 30/10/2018, à 17:38

D'après la dernière réponse de vicric, il s'en était sorti par la mise à niveau vers 14.04 que son pc lui proposait. Ça implique qu'il avait conservé au moins un noyau, malgré ma bourde.

Mais ça m'a rendu prudent avec les points et les astérisques dans les contextes que je viens de décrire !

- -

Je me souviens aussi - mais là je n'y étais pour rien - d'un malheureux sudo apt remove wine*, vraisemblablement lancé deux fois.
La deuxième fois, apt avait désinstallé - de mémoire - tous les paquets contenant
soit w soit i soit n soit e :
il ne restait plus grand-chose...

moko138 · Le 30/10/2018, à 17:50

Mornagest a écrit :

Est-ce que apt et apt-get réagissent de la même manière sur ce point ?

A priori oui.
Tu peux toujours tester à condition de NE PAS OUBLIER L'OPTION -s

Dans ma 14.04, comme le soulignait déjà tiramiseb à l'époque :

man apt-get
           Quand aucun paquet ne correspond à l'expression donnée en paramètre et que cette
           expression contient l'un des caractères « . », « ? » ou « * », elle est considérée
           comme une expression rationnelle POSIX et elle est appliquée à tous les paquets de
           la base de données. Tout paquet correspondant est installé (ou supprimé). Veuillez
           noter que la comparaison est effectuée par sous-chaîne et « lo.* » correspond aussi
           bien à « how-lo » qu'à « lowest ».

moko138 · Le 30/10/2018, à 17:56

[HS] Naziel,
Dans "[Jeu] Vous êtes un dictionnaire..", vois ./viewtopic.php?pid=21544361#p21544361
[/HS]

Nuliel · Le 30/10/2018, à 19:31

[HS]Je ne devrais donc plus avoir ce problème le matin [/HS]

Si on utilise ^ en début de nom de paquet, on évite les surprises non?
Par exemple, ^lo.* va retourner que lowest (je reprends l'exemple du man)

Dernière modification par Nuliel (Le 30/10/2018, à 19:39)

nam1962 · Le 30/10/2018, à 19:52

moko138 a écrit :

nam1962 a écrit :
- pourquoi l'outil de mise à niveau ne vire t'il pas tout simplement toute trace de la version précédente ?
Si tu parles des noyaux 4.13.0 quand on a démarré sur un 4.15.0,
(...)

Non, là je parle des dépôts.

Voir comme dans l'illustration ci-dessus du xenial, même commenté, sur une source bionic est trrrès pas beau !

Dernière modification par nam1962 (Le 30/10/2018, à 20:21)

moko138 · Le 30/10/2018, à 20:26

Naziel a écrit :

Si on utilise ^ en début de nom de paquet, on évite les surprises non?
Par exemple, ^lo.* va retourner que lowest (je reprends l'exemple du man)

C'est un aspect du man

           Si ce n'est pas le comportement souhaité,
           l'expression peut être ancrée avec un caractère « ^ » ou un caractère « $ », une
           autre possibilité étant d'utiliser une expression plus précise.

auquel je ne comprends rien. Ni pour ^ ni pour $, ni pour leur syntaxe complète. Ni pour le simple sens de "ancrée".

Si tu peux m'éclairer... Merci !

Nuliel · Le 30/10/2018, à 20:37

J'ai pas lu cette partie du man
En fait, *, ?, ^, $ permettent de faire des expressions régulières. Le man dit simplement que afin d'éviter d'avoir des blagues genre how-lo quand on recherche lo* et qu'on sait que le paquet commence par lo, alors faire ^lo* permet d'avoir tous les paquets commençant par lo
Pour les paquets finissant par lo, il faut faire lo$

Un petit tableau pour résumer : https://www.quennec.fr/book/export/html/414

Mais j'arrive pas à trouver d'exemple parlant

Dernière modification par Nuliel (Le 30/10/2018, à 20:57)

moko138 · Le 30/10/2018, à 23:04

Merci, tableau très intéressant !

Pour ^, ça marche :

sudo apt-get remove -s ^part* | grep -v "et ne peut donc être supprimé"
Lecture des listes de paquets...
Construction de l'arbre des dépendances...
Lecture des informations d'état...
Les paquets suivants seront ENLEVÉS :
  parted
0 mis à jour, 0 nouvellement installés, 1 à enlever et 1 non mis à jour.
Remv parted [2.3-12]
moko@cb:~$

gpart, gparted et libparted0debian1:i386 ne sont pas supprimés.

Mais pour *XXX$ :

sudo apt-get remove -s *part$ | grep -v "et ne peut donc être supprimé"
Lecture des listes de paquets...
Construction de l'arbre des dépendances...
Lecture des informations d'état...
E: Impossible de trouver le paquet *part$
E: Erreur de compilation de l'expression rationnelle - Expression régulière précédente invalide
E: Impossible de trouver de paquet correspondant à l'expression rationnelle « *part$ »

Pourtant j'ai bien :

dpkg -l |grep part
(...)
ii  gpart                                0.1h-11+b1                         i386         Guess PC disk partition table, find lost partitions
ii  gparted                              0.12.1-2                           i386         GNOME partition editor
ii  libparted0debian1:i386               2.3-12                             i386         disk partition manipulator - shared library
ii  parted                               2.3-12                             i386         disk partition manipulator

Je n'arrive pas non plus à utiliser :

ton lien a écrit :

\<expression Début d'un mot. Caractères pouvant faire partie d'un mot : [A-Za-z0-9_]
expression\> Fin d'un mot

moko@cb:~$ dpkg -l | grep \<part
moko@cb:~$

sudo apt-get remove -s *part\> | grep -v "et ne peut donc être supprimé"
Lecture des listes de paquets...
Construction de l'arbre des dépendances...
Lecture des informations d'état...
E: Impossible de trouver le paquet *part>
E: Erreur de compilation de l'expression rationnelle - Expression régulière précédente invalide
E: Impossible de trouver de paquet correspondant à l'expression rationnelle « *part> »

moko138 · Le 30/10/2018, à 23:12

Ah ben ouiche ! Ça m'apprendra à lire en diagonale !

. (point) Un caractère quelconque
* 0 à n fois le caractère ou regroupement précédent

Et en effet, avec un point, ça va mieux :

sudo apt-get remove -s .part$ | grep -v "et ne peut donc être supprimé"
(...)
Les paquets suivants seront ENLEVÉS :
  gpart
0 mis à jour, 0 nouvellement installés, 1 à enlever et 1 non mis à jour.
Remv gpart [0.1h-11+b1]

Nuliel · Le 30/10/2018, à 23:12

Pareil, je comprends pas, comme si les expressions régulières n'étaient pas interprétées par rapport aux paquets

naziel@naziel-HP-desktop:~$ sudo apt-get remove -s ^part* | grep -v "et ne peut donc être supprimé"
Lecture des listes de paquets…
Construction de l'arbre des dépendances…
Lecture des informations d'état…
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  bluefish-data bluefish-plugins
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les paquets suivants seront ENLEVÉS :
  bluefish gvfs gvfs-backends gvfs-daemons gvfs-fuse parole parted
  ubuntu-standard udisks2
0 mis à jour, 0 nouvellement installés, 9 à enlever et 7 non mis à jour.
Remv bluefish [2.2.10-1]
Remv gvfs-backends [1.36.1-0ubuntu1.1]
Remv gvfs-fuse [1.36.1-0ubuntu1.1]
Remv gvfs [1.36.1-0ubuntu1.1]
Remv gvfs-daemons [1.36.1-0ubuntu1.1]
Remv parole [1.0.1-0ubuntu1]
Remv udisks2 [2.7.6-3ubuntu0.2]
Remv ubuntu-standard [1.417]
Remv parted [3.2-20]
naziel@naziel-HP-desktop:~$ sudo apt-get remove -s part* | grep -v "et ne peut donc être supprimé"
Lecture des listes de paquets…
Construction de l'arbre des dépendances…
Lecture des informations d'état…
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  bluefish-data bluefish-plugins
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les paquets suivants seront ENLEVÉS :
  bluefish gvfs gvfs-backends gvfs-daemons gvfs-fuse parted ubuntu-standard
  udisks2
0 mis à jour, 0 nouvellement installés, 8 à enlever et 7 non mis à jour.
Remv bluefish [2.2.10-1]
Remv gvfs-backends [1.36.1-0ubuntu1.1]
Remv gvfs-fuse [1.36.1-0ubuntu1.1]
Remv gvfs [1.36.1-0ubuntu1.1]
Remv gvfs-daemons [1.36.1-0ubuntu1.1]
Remv udisks2 [2.7.6-3ubuntu0.2]
Remv ubuntu-standard [1.417]
Remv parted [3.2-20]
naziel@naziel-HP-desktop:~$

(je comprends pas le rapport avec *part*)

? devrait marcher aussi (c'est 0 ou 1 caractère)

Dernière modification par Nuliel (Le 30/10/2018, à 23:15)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 29/10/2018, à 13:35

La gestion des mises à niveau et des kernels continue à être sale

#2 Le 29/10/2018, à 13:48

Re : La gestion des mises à niveau et des kernels continue à être sale

#3 Le 29/10/2018, à 13:58

Re : La gestion des mises à niveau et des kernels continue à être sale

#4 Le 29/10/2018, à 15:37

Re : La gestion des mises à niveau et des kernels continue à être sale

#5 Le 30/10/2018, à 14:48

Re : La gestion des mises à niveau et des kernels continue à être sale

#6 Le 30/10/2018, à 15:46

Re : La gestion des mises à niveau et des kernels continue à être sale

#7 Le 30/10/2018, à 15:55

Re : La gestion des mises à niveau et des kernels continue à être sale

#8 Le 30/10/2018, à 16:01

Re : La gestion des mises à niveau et des kernels continue à être sale

#9 Le 30/10/2018, à 16:07

Re : La gestion des mises à niveau et des kernels continue à être sale

#10 Le 30/10/2018, à 17:03

Re : La gestion des mises à niveau et des kernels continue à être sale

#11 Le 30/10/2018, à 17:12

Re : La gestion des mises à niveau et des kernels continue à être sale

#12 Le 30/10/2018, à 17:15

Re : La gestion des mises à niveau et des kernels continue à être sale

#13 Le 30/10/2018, à 17:37

Re : La gestion des mises à niveau et des kernels continue à être sale

#14 Le 30/10/2018, à 17:38

Re : La gestion des mises à niveau et des kernels continue à être sale

#15 Le 30/10/2018, à 17:50

Re : La gestion des mises à niveau et des kernels continue à être sale

#16 Le 30/10/2018, à 17:56

Re : La gestion des mises à niveau et des kernels continue à être sale

#17 Le 30/10/2018, à 19:31

Re : La gestion des mises à niveau et des kernels continue à être sale

#18 Le 30/10/2018, à 19:52

Re : La gestion des mises à niveau et des kernels continue à être sale

#19 Le 30/10/2018, à 20:26

Re : La gestion des mises à niveau et des kernels continue à être sale

#20 Le 30/10/2018, à 20:37

Re : La gestion des mises à niveau et des kernels continue à être sale

#21 Le 30/10/2018, à 23:04

Re : La gestion des mises à niveau et des kernels continue à être sale

#22 Le 30/10/2018, à 23:12

Re : La gestion des mises à niveau et des kernels continue à être sale

#23 Le 30/10/2018, à 23:12

Re : La gestion des mises à niveau et des kernels continue à être sale

Pied de page des forums