J'ai un problème de RAM qui dépasse mes faibles compétences
informatiques.
Je viens d'acquérir un barebone Intel NUC7I3BNH, auquel j'ai ajouté
les éléments suivants :
* 1 SSD Kingston SSDNow M.2 SATA G2 - 120 Go, SATA 3 (6 Gb/s) pour les
partitions /boot et racine / ;
* 1 HD Seagate BarraCuda 2,5" 1 To, SATA 3 (6 Gb/s), pour les
partitions /home, /tmp, /var, et /swap ;
* la RAM Crucial SO-DIMM DDR4 2 x 8 Go 2133 MHz CAS 15, 1,20 Volts.
J'ai installé Debian 9 Strech LXDE.
Le BIOS de la machine détecte bien la RAM disponible :
Total Memory 16 GB
Memory Speed 2133 Mhz
Memory Clock 133 Mhz
SODIMM 1 (Memory Channel A) 8 GB
SODIMM 2 (Memory Channel B) 8 GB
Memory Voltage 1.2 V
Le problème est que le système rame comme un galérien...
Seulement 1,9 Go de RAM est reconnu sur les 16 Go réellement
disponibles, et htop m'indique que la swap est souvent sollicitée !
$ free -gth
total used free shared buff/cache available
Mem: 1,9G 720M 273M 31M 932M 962M
Swap: 18G 75M 18G
Total: 20G 795M 18G
le dimanche 08 octobre 2017 à 10:31 (+0200), Dominique Dumont a écrit:
C'est pas optimal. Les partitions /var et /home sont assez sollicitées au démarrage et au login. Il vaut mieux mettre /tmp /var et /home sur le SSD
Exactement. Idem pour le swap.
Je n'ai pas mis /var et /tmp sur le SSD pour éviter les écritures intempestives sur ce média.
Qu'est-ce qu'il ne faut pas lire. Acheter un SSD mais ne pas exploiter son potentiel de peur de l'user... Mesure le volume d'écriture dans ces éléments, compare au nombre de cycles d'écritures supporté par ton SSD et on en reparle.
Le 08/10/2017 à 14:31, sTriX a écrit :
le dimanche 08 octobre 2017 à 10:31 (+0200), Dominique Dumont a écrit:
C'est pas optimal. Les partitions /var et /home sont assez sollicitées au
démarrage et au login.
Il vaut mieux mettre /tmp /var et /home sur le SSD
Exactement. Idem pour le swap.
Je n'ai pas mis /var et /tmp sur le SSD pour éviter les écritures
intempestives sur ce média.
Qu'est-ce qu'il ne faut pas lire. Acheter un SSD mais ne pas exploiter
son potentiel de peur de l'user... Mesure le volume d'écriture dans ces
éléments, compare au nombre de cycles d'écritures supporté par ton SSD
et on en reparle.
le dimanche 08 octobre 2017 à 10:31 (+0200), Dominique Dumont a écrit:
C'est pas optimal. Les partitions /var et /home sont assez sollicitées au démarrage et au login. Il vaut mieux mettre /tmp /var et /home sur le SSD
Exactement. Idem pour le swap.
Je n'ai pas mis /var et /tmp sur le SSD pour éviter les écritures intempestives sur ce média.
Qu'est-ce qu'il ne faut pas lire. Acheter un SSD mais ne pas exploiter son potentiel de peur de l'user... Mesure le volume d'écriture dans ces éléments, compare au nombre de cycles d'écritures supporté par ton SSD et on en reparle.
Pascal Hambourg
Le 08/10/2017 à 19:57, Frederic MASSOT a écrit :
Le 08/10/2017 à 14:17, sTriX a écrit : Linux version 4.9.0-3-686 () (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) [...] 1084MB HIGHMEM available. 887MB LOWMEM available. Ton noyau 4.9.0-3-686 ne détecte que 1.9 Go de RAM, avec un noyau 32 bits non pae la valeur de HIGHMEM devrait être proche des 2 Go.
Tu ne regardes pas les bonnes lignes (Je ne laisse que les plages de RAM utilisable) : e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000100000-0x000000006e6a8fff] usable BIOS-e820: [mem 0x000000006e6ab000-0x000000007a173fff] usable BIOS-e820: [mem 0x000000007b3fe000-0x000000007b3fefff] usable BIOS-e820: [mem 0x0000000100000000-0x000000047effffff] usable Linux voit bien les 16 Gio de RAM utilisable. Les ~2 Go utilisés correspondent aux plages de RAM situées à des adresses inférieures à la frontière de 4 Gio (les 3 premières lignes). Le reste (la dernière ligne), soit environ 15 Go, est situé au-delà de cette frontière, donc inaccessible sans PAE.
En tout cas, pour générer plus de 4 Go en 32 bits il faut utiliser un noyau pae.
Voilà.
Le 08/10/2017 à 19:57, Frederic MASSOT a écrit :
Le 08/10/2017 à 14:17, sTriX a écrit :
Linux version 4.9.0-3-686
(debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian
6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19)
[...]
1084MB HIGHMEM available.
887MB LOWMEM available.
Ton noyau 4.9.0-3-686 ne détecte que 1.9 Go de RAM, avec un noyau 32
bits non pae la valeur de HIGHMEM devrait être proche des 2 Go.
Tu ne regardes pas les bonnes lignes (Je ne laisse que les plages de RAM
utilisable) :
Linux voit bien les 16 Gio de RAM utilisable. Les ~2 Go utilisés
correspondent aux plages de RAM situées à des adresses inférieures à la
frontière de 4 Gio (les 3 premières lignes). Le reste (la dernière
ligne), soit environ 15 Go, est situé au-delà de cette frontière, donc
inaccessible sans PAE.
En tout cas, pour générer plus de 4 Go en 32 bits il faut utiliser un
noyau pae.
Le 08/10/2017 à 14:17, sTriX a écrit : Linux version 4.9.0-3-686 () (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) [...] 1084MB HIGHMEM available. 887MB LOWMEM available. Ton noyau 4.9.0-3-686 ne détecte que 1.9 Go de RAM, avec un noyau 32 bits non pae la valeur de HIGHMEM devrait être proche des 2 Go.
Tu ne regardes pas les bonnes lignes (Je ne laisse que les plages de RAM utilisable) : e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000100000-0x000000006e6a8fff] usable BIOS-e820: [mem 0x000000006e6ab000-0x000000007a173fff] usable BIOS-e820: [mem 0x000000007b3fe000-0x000000007b3fefff] usable BIOS-e820: [mem 0x0000000100000000-0x000000047effffff] usable Linux voit bien les 16 Gio de RAM utilisable. Les ~2 Go utilisés correspondent aux plages de RAM situées à des adresses inférieures à la frontière de 4 Gio (les 3 premières lignes). Le reste (la dernière ligne), soit environ 15 Go, est situé au-delà de cette frontière, donc inaccessible sans PAE.
En tout cas, pour générer plus de 4 Go en 32 bits il faut utiliser un noyau pae.
Voilà.
=?iso-8859-1?q?Ga=EBtan?= Perrier
--=-xdBmYQAWhlPkmreyPlRK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le dimanche 08 octobre 2017 à 10:31 +0200, Dominique Dumont a écr it :
On Saturday, 7 October 2017 23:14:07 CEST sTriX wrote:
* 1 SSD Kingston SSDNow M.2 SATA G2 - 120 Go, SATA 3 (6 Gb/s) pour les partitions /boot et racine / ; * 1 HD Seagate BarraCuda 2,5" 1 To, SATA 3 (6 Gb/s), pour les partitions /home, /tmp, /var, et /swap ;
C'est pas optimal. Les partitions /var et /home sont assez sollicité es au démarrage et au login. Il vaut mieux mettre /tmp /var et /home sur le SSD et mettre sur le HDD uniquement les gros fichiers qui sont accédés moins souvent (ph otos, videos. musique..) Ca fait une config un peu plus compliquée mais ça optimise l'u tilisation des disques.
Avec 16 Go de RAM je mettrais /tmp en RAM ... Gaëtan --=-xdBmYQAWhlPkmreyPlRK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEd7zcTjS9jiJYzB4MTEjQapSg6ZkFAlnauqEACgkQTEjQapSg 6Zm1qwf9Gb6/7HGC6HVPkmoPn67U6Vyf5nPu8Rfe1RA5wgbG1DkMVSLxgTPY6406 syKkb/FDbpbG+8mJGvd6cyob3al0dAY50CsEY9GXv3zgbWnwdvYS/0Ix5BSFCSTg ZOvF0J9MsK7duuAFIjoZD2DpMEN7VJqynoFRi4Q1Ry4qEHlvcVKHGb5xJilPPzsT RO8mvp1xsEGB3oaxFHVFfMGeZ+c1IaYIK1FooC8Rujupq0JNGRButs3zqFfw/nG6 YVu8lFiMBrzwWIr5LN6EE7OPP1nlpUPDgeM8SZGoYQ6//DO62LJp2Bg2V0D+1nkI 1qv02KJyXHeAuDwacOwc9HE0c6iUfg= =vPEF -----END PGP SIGNATURE----- --=-xdBmYQAWhlPkmreyPlRK--
Le dimanche 08 octobre 2017 à 10:31 +0200, Dominique Dumont a écr it :
On Saturday, 7 October 2017 23:14:07 CEST sTriX wrote:
> * 1 SSD Kingston SSDNow M.2 SATA G2 - 120 Go, SATA 3 (6 Gb/s) pour les
> partitions /boot et racine / ;
> * 1 HD Seagate BarraCuda 2,5" 1 To, SATA 3 (6 Gb/s), pour les
> partitions /home, /tmp, /var, et /swap ;
C'est pas optimal. Les partitions /var et /home sont assez sollicité es au
démarrage et au login.
Il vaut mieux mettre /tmp /var et /home sur le SSD et mettre sur le HDD
uniquement les gros fichiers qui sont accédés moins souvent (ph otos, videos.
musique..)
Ca fait une config un peu plus compliquée mais ça optimise l'u tilisation
des
disques.
Avec 16 Go de RAM je mettrais /tmp en RAM ...
Gaëtan
--=-xdBmYQAWhlPkmreyPlRK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit
--=-xdBmYQAWhlPkmreyPlRK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le dimanche 08 octobre 2017 à 10:31 +0200, Dominique Dumont a écr it :
On Saturday, 7 October 2017 23:14:07 CEST sTriX wrote:
* 1 SSD Kingston SSDNow M.2 SATA G2 - 120 Go, SATA 3 (6 Gb/s) pour les partitions /boot et racine / ; * 1 HD Seagate BarraCuda 2,5" 1 To, SATA 3 (6 Gb/s), pour les partitions /home, /tmp, /var, et /swap ;
C'est pas optimal. Les partitions /var et /home sont assez sollicité es au démarrage et au login. Il vaut mieux mettre /tmp /var et /home sur le SSD et mettre sur le HDD uniquement les gros fichiers qui sont accédés moins souvent (ph otos, videos. musique..) Ca fait une config un peu plus compliquée mais ça optimise l'u tilisation des disques.
Avec 16 Go de RAM je mettrais /tmp en RAM ... Gaëtan --=-xdBmYQAWhlPkmreyPlRK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEd7zcTjS9jiJYzB4MTEjQapSg6ZkFAlnauqEACgkQTEjQapSg 6Zm1qwf9Gb6/7HGC6HVPkmoPn67U6Vyf5nPu8Rfe1RA5wgbG1DkMVSLxgTPY6406 syKkb/FDbpbG+8mJGvd6cyob3al0dAY50CsEY9GXv3zgbWnwdvYS/0Ix5BSFCSTg ZOvF0J9MsK7duuAFIjoZD2DpMEN7VJqynoFRi4Q1Ry4qEHlvcVKHGb5xJilPPzsT RO8mvp1xsEGB3oaxFHVFfMGeZ+c1IaYIK1FooC8Rujupq0JNGRButs3zqFfw/nG6 YVu8lFiMBrzwWIr5LN6EE7OPP1nlpUPDgeM8SZGoYQ6//DO62LJp2Bg2V0D+1nkI 1qv02KJyXHeAuDwacOwc9HE0c6iUfg= =vPEF -----END PGP SIGNATURE----- --=-xdBmYQAWhlPkmreyPlRK--
BERTRAND Jo=c3=abl
Gaëtan Perrier a écrit :
Le dimanche 08 octobre 2017 à 11:17 +0200, Michel a écrit :
Le 08/10/2017 à 10:40, Dominique Dumont a écrit :
On Saturday, 7 October 2017 23:14:07 CEST sTriX wrote:
* 1 SSD Kingston SSDNow M.2 SATA G2 - 120 Go, SATA 3 (6 Gb/s) pour les partitions /boot et racine / ; * 1 HD Seagate BarraCuda 2,5" 1 To, SATA 3 (6 Gb/s), pour les partitions /home, /tmp, /var, et /swap ;
C'est pas optimal. Les partitions /var et /home sont assez sollicitées au démarrage et au login. Il vaut mieux mettre /tmp /var et /home sur le SSD et mettre sur le HDD uniquement les gros fichiers qui sont accédés moins souvent (photos, videos. musique..) Ca fait une config un peu plus compliquée mais ça optimise l'utilisation des disques.
/home sur SSD, ok, mais var et tmp, je les préfère sur un disque classique. Les SSD sont limités en nombre d'écritures et avec des partitions sollicitées, on peut limiter le temps de vie d'un SSD.
Avec un SSD moderne faut arrêter de trop se prendre la tête ... Gaëtan
Ouhlà... J'en ai plusieurs dizaines de milliers dans la nature et, franchement, il faut se prendre la tête. J'ai des taux de panne largement supérieurs à ceux des disques à plateaux et, cerise sur le gâteau, ils lâchent presque toujours sans prévenir (smart remonte rarement d'informations utiles avant le plantage, elles sont très ou trop souvent masquées par le firmware). Les disques à plateaux n'aiment pas les vibrations (quoiqu'il existe des disques spéciaux comme ceux utilisés dans les calculateurs automobile qui se prennent plusieurs g sous des températures de 95°C). Mais les SSD n'aiment pas les températures supérieures à 60°C où ils claquent en quelques mois et n'aiment pas les écritures massives. Théoriquement, le SSD répartit les écritures. Ça, c'est la théorie et un calcul permet d'affirmer qu'on peut réécrire x fois la totalité du disque tous les jours durant plusieurs années. C'est faux car on oublie la taille de la cellule (information généralement passée sous silence), le firmware, complexe et souvent buggué qui laisse des goulots d'étranglement. Mon préféré est le SSD qui écrivait toutes les minutes sa liste de cellules défectueuses au même endroit du disque (je vous file le modèle du disque contre un carnet de timbres, ma boîte a perdu un très gros client à cause de ça.). Durée de vie du disque en question, moins de un an. Typiquement, j'ai eu des Kingston industriels dans des équipements. L'un des firmwares nous a planté _tous_ les SSD en trois mois. Le n-1 ou n+1 ne posait pas de problème. Il a fallu patcher _tous_ les OCZ Vertex pour les mêmes raisons. Aujourd'hui, lorsqu'un client demande du SSD, c'est de l'industriel en cellules SLC. Là, on arrive à faire quelque chose, mais c'est cher et ça ne se trouve pas chez le cataloguiste informatique du coin. Mais les MLC et maintenant TLC, pour avoir des bancs de test, ce sont des nids à merdes dont le taux de panne explose exponentiellement après 50°C. Mes bancs de test remontent même des informations bien pire que cela. Le taux de panne augmente actuellement parce qu'il faut toujours faire plus cher, plus rapide et moins consommateur d'énergie (or la mémoire flash restant la mémoire flash...). Pour Madame Michu, ça peut faire illusion. Dans une utilisation standard et critique... rien ne vaut un bon disque à plateaux. Enfin, je dis ça je dis rien, ça fait plusieurs années que je me tape ce genre de disques et que j'ai des bancs de test pour éviter les retour d'équipement sous garantie. Bien cordialement, JKB
Gaëtan Perrier a écrit :
Le dimanche 08 octobre 2017 à 11:17 +0200, Michel a écrit :
Le 08/10/2017 à 10:40, Dominique Dumont a écrit :
On Saturday, 7 October 2017 23:14:07 CEST sTriX wrote:
* 1 SSD Kingston SSDNow M.2 SATA G2 - 120 Go, SATA 3 (6 Gb/s) pour les
partitions /boot et racine / ;
* 1 HD Seagate BarraCuda 2,5" 1 To, SATA 3 (6 Gb/s), pour les
partitions /home, /tmp, /var, et /swap ;
C'est pas optimal. Les partitions /var et /home sont assez sollicitées au
démarrage et au login.
Il vaut mieux mettre /tmp /var et /home sur le SSD et mettre sur le HDD
uniquement les gros fichiers qui sont accédés moins souvent (photos,
videos.
musique..)
Ca fait une config un peu plus compliquée mais ça optimise l'utilisation
des
disques.
/home sur SSD, ok, mais var et tmp, je les préfère sur un disque
classique. Les SSD sont limités en nombre d'écritures et avec des
partitions sollicitées, on peut limiter le temps de vie d'un SSD.
Avec un SSD moderne faut arrêter de trop se prendre la tête ...
Gaëtan
Ouhlà... J'en ai plusieurs dizaines de milliers dans la nature et,
franchement, il faut se prendre la tête. J'ai des taux de panne
largement supérieurs à ceux des disques à plateaux et, cerise sur le
gâteau, ils lâchent presque toujours sans prévenir (smart remonte
rarement d'informations utiles avant le plantage, elles sont très ou
trop souvent masquées par le firmware). Les disques à plateaux n'aiment
pas les vibrations (quoiqu'il existe des disques spéciaux comme ceux
utilisés dans les calculateurs automobile qui se prennent plusieurs g
sous des températures de 95°C). Mais les SSD n'aiment pas les
températures supérieures à 60°C où ils claquent en quelques mois et
n'aiment pas les écritures massives. Théoriquement, le SSD répartit les
écritures. Ça, c'est la théorie et un calcul permet d'affirmer qu'on
peut réécrire x fois la totalité du disque tous les jours durant
plusieurs années. C'est faux car on oublie la taille de la cellule
(information généralement passée sous silence), le firmware, complexe et
souvent buggué qui laisse des goulots d'étranglement. Mon préféré est le
SSD qui écrivait toutes les minutes sa liste de cellules défectueuses au
même endroit du disque (je vous file le modèle du disque contre un
carnet de timbres, ma boîte a perdu un très gros client à cause de ça.).
Durée de vie du disque en question, moins de un an.
Typiquement, j'ai eu des Kingston industriels dans des équipements.
L'un des firmwares nous a planté _tous_ les SSD en trois mois. Le n-1 ou
n+1 ne posait pas de problème. Il a fallu patcher _tous_ les OCZ Vertex
pour les mêmes raisons. Aujourd'hui, lorsqu'un client demande du SSD,
c'est de l'industriel en cellules SLC. Là, on arrive à faire quelque
chose, mais c'est cher et ça ne se trouve pas chez le cataloguiste
informatique du coin. Mais les MLC et maintenant TLC, pour avoir des
bancs de test, ce sont des nids à merdes dont le taux de panne explose
exponentiellement après 50°C.
Mes bancs de test remontent même des informations bien pire que cela.
Le taux de panne augmente actuellement parce qu'il faut toujours faire
plus cher, plus rapide et moins consommateur d'énergie (or la mémoire
flash restant la mémoire flash...). Pour Madame Michu, ça peut faire
illusion. Dans une utilisation standard et critique... rien ne vaut un
bon disque à plateaux.
Enfin, je dis ça je dis rien, ça fait plusieurs années que je me tape
ce genre de disques et que j'ai des bancs de test pour éviter les retour
d'équipement sous garantie.
Le dimanche 08 octobre 2017 à 11:17 +0200, Michel a écrit :
Le 08/10/2017 à 10:40, Dominique Dumont a écrit :
On Saturday, 7 October 2017 23:14:07 CEST sTriX wrote:
* 1 SSD Kingston SSDNow M.2 SATA G2 - 120 Go, SATA 3 (6 Gb/s) pour les partitions /boot et racine / ; * 1 HD Seagate BarraCuda 2,5" 1 To, SATA 3 (6 Gb/s), pour les partitions /home, /tmp, /var, et /swap ;
C'est pas optimal. Les partitions /var et /home sont assez sollicitées au démarrage et au login. Il vaut mieux mettre /tmp /var et /home sur le SSD et mettre sur le HDD uniquement les gros fichiers qui sont accédés moins souvent (photos, videos. musique..) Ca fait une config un peu plus compliquée mais ça optimise l'utilisation des disques.
/home sur SSD, ok, mais var et tmp, je les préfère sur un disque classique. Les SSD sont limités en nombre d'écritures et avec des partitions sollicitées, on peut limiter le temps de vie d'un SSD.
Avec un SSD moderne faut arrêter de trop se prendre la tête ... Gaëtan
Ouhlà... J'en ai plusieurs dizaines de milliers dans la nature et, franchement, il faut se prendre la tête. J'ai des taux de panne largement supérieurs à ceux des disques à plateaux et, cerise sur le gâteau, ils lâchent presque toujours sans prévenir (smart remonte rarement d'informations utiles avant le plantage, elles sont très ou trop souvent masquées par le firmware). Les disques à plateaux n'aiment pas les vibrations (quoiqu'il existe des disques spéciaux comme ceux utilisés dans les calculateurs automobile qui se prennent plusieurs g sous des températures de 95°C). Mais les SSD n'aiment pas les températures supérieures à 60°C où ils claquent en quelques mois et n'aiment pas les écritures massives. Théoriquement, le SSD répartit les écritures. Ça, c'est la théorie et un calcul permet d'affirmer qu'on peut réécrire x fois la totalité du disque tous les jours durant plusieurs années. C'est faux car on oublie la taille de la cellule (information généralement passée sous silence), le firmware, complexe et souvent buggué qui laisse des goulots d'étranglement. Mon préféré est le SSD qui écrivait toutes les minutes sa liste de cellules défectueuses au même endroit du disque (je vous file le modèle du disque contre un carnet de timbres, ma boîte a perdu un très gros client à cause de ça.). Durée de vie du disque en question, moins de un an. Typiquement, j'ai eu des Kingston industriels dans des équipements. L'un des firmwares nous a planté _tous_ les SSD en trois mois. Le n-1 ou n+1 ne posait pas de problème. Il a fallu patcher _tous_ les OCZ Vertex pour les mêmes raisons. Aujourd'hui, lorsqu'un client demande du SSD, c'est de l'industriel en cellules SLC. Là, on arrive à faire quelque chose, mais c'est cher et ça ne se trouve pas chez le cataloguiste informatique du coin. Mais les MLC et maintenant TLC, pour avoir des bancs de test, ce sont des nids à merdes dont le taux de panne explose exponentiellement après 50°C. Mes bancs de test remontent même des informations bien pire que cela. Le taux de panne augmente actuellement parce qu'il faut toujours faire plus cher, plus rapide et moins consommateur d'énergie (or la mémoire flash restant la mémoire flash...). Pour Madame Michu, ça peut faire illusion. Dans une utilisation standard et critique... rien ne vaut un bon disque à plateaux. Enfin, je dis ça je dis rien, ça fait plusieurs années que je me tape ce genre de disques et que j'ai des bancs de test pour éviter les retour d'équipement sous garantie. Bien cordialement, JKB
le lundi 09 octobre 2017 à 11:37 (+0200), Frédéric MASSOT a écrit:
J'installe linux-image-4.9.0-4-686-pae directement ou je passe par le metapaquet linux-image-686-pae ?
Tu peux installer le méta-paquet linux-image-686-pae, par le jeu des dépendances il installera le dernier noyau 32 bits pae. Ton système aura toujours le dernier noyau disponible chez Debian.
Une fois cette installation faite, dois-je désinstaller l'ancien noyau linux-image-4.9.0-3-686 et linux-image-4.9.0-4-686 ?
Oui, autant les supprimer : apt-get --purge remove linux-image-4.9.0-3-686 linux-image-4.9.0-4-686
Merci Frédéric, c'est clair, net & précis. Bonne journée. -- Gérard http://gbonnetonphoto.free.fr
le lundi 09 octobre 2017 à 11:37 (+0200), Frédéric MASSOT a écrit:
> J'installe linux-image-4.9.0-4-686-pae directement ou je passe par le
> metapaquet linux-image-686-pae ?
Tu peux installer le méta-paquet linux-image-686-pae, par le jeu des
dépendances il installera le dernier noyau 32 bits pae. Ton système aura
toujours le dernier noyau disponible chez Debian.
> Une fois cette installation faite, dois-je désinstaller l'ancien noyau
> linux-image-4.9.0-3-686 et linux-image-4.9.0-4-686 ?
le lundi 09 octobre 2017 à 11:37 (+0200), Frédéric MASSOT a écrit:
J'installe linux-image-4.9.0-4-686-pae directement ou je passe par le metapaquet linux-image-686-pae ?
Tu peux installer le méta-paquet linux-image-686-pae, par le jeu des dépendances il installera le dernier noyau 32 bits pae. Ton système aura toujours le dernier noyau disponible chez Debian.
Une fois cette installation faite, dois-je désinstaller l'ancien noyau linux-image-4.9.0-3-686 et linux-image-4.9.0-4-686 ?
Oui, autant les supprimer : apt-get --purge remove linux-image-4.9.0-3-686 linux-image-4.9.0-4-686
Merci Frédéric, c'est clair, net & précis. Bonne journée. -- Gérard http://gbonnetonphoto.free.fr
