Le 2018-12-07, denis.paris nous expliquait dans
fr.comp.os.linux.configuration
(<5c0a55f6$0$11049$) :Le 07/12/2018 à 11:55, Doug713705 a écrit :Pour le coup il y a bien eu un tel bug dans une release d'Ubuntu.
Rapidement corrigé mais qui a eu le temps de briquer quelques machines.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147
Mais c'est très exceptionnel voire un cas unique (pas vérifié).
Un cas unique pas formellement avéré, peut-être.
Le cas est avéré.Mais le point important dans ce que tu signales c'est le "rapidement corrigé".
Jamais assez rapidement pour ceux qui ont vu leur machine briquées.
Mais notons que c'est un bug qui a concerné uniquement Ubuntu et
éventuellement les quelques distributions qui en sont dérivées (Mint par
exemple).Donc à moins de tester comme un forcement les kernels en versions bêta et
d'être vraiment maudit, c'est à dire avoir la mauvaise distribution, la
mauvaise machine, etc. ce serait vraiment pas de chance d'avoir tous les
bugs simultanément, ainsi que cela semble être le cas pour notre "client".
Il semble avoir le profile idéal.En environnement Windows aucun utilisateurs ne teste le système dans des
conditions aussi extrêmes, sauf peut-être les bêta-testeurs semi-pro,
alors que rien n'empêche un utilisateur fouineur de linux d'en faire son
cheval de bataille, son truc, sans pour autant avoir les compétences
adéquates pour en comprendre les tenants et aboutissants, comme c'est le
cas pour certains très bon contributeurs de ce forum mais qui évidemment
ne trouvent pas judicieux d'intervenir sur un fil aussi fourre-tout et
aussi déjanté.
L'OP est en mode "write-only", il faudrait être fou pour répondre à quelqu'un
qui ne veut pas écouter.Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...
N'est-il pas ? ;-)
Personnellement j'ai filtré depuis très longtemps.
Le 2018-12-07, denis.paris nous expliquait dans
fr.comp.os.linux.configuration
(<5c0a55f6$0$11049$426a34cc@news.free.fr>) :
Le 07/12/2018 à 11:55, Doug713705 a écrit :
Pour le coup il y a bien eu un tel bug dans une release d'Ubuntu.
Rapidement corrigé mais qui a eu le temps de briquer quelques machines.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147
Mais c'est très exceptionnel voire un cas unique (pas vérifié).
Un cas unique pas formellement avéré, peut-être.
Le cas est avéré.
Mais le point important dans ce que tu signales c'est le "rapidement corrigé".
Jamais assez rapidement pour ceux qui ont vu leur machine briquées.
Mais notons que c'est un bug qui a concerné uniquement Ubuntu et
éventuellement les quelques distributions qui en sont dérivées (Mint par
exemple).
Donc à moins de tester comme un forcement les kernels en versions bêta et
d'être vraiment maudit, c'est à dire avoir la mauvaise distribution, la
mauvaise machine, etc. ce serait vraiment pas de chance d'avoir tous les
bugs simultanément, ainsi que cela semble être le cas pour notre "client".
Il semble avoir le profile idéal.
En environnement Windows aucun utilisateurs ne teste le système dans des
conditions aussi extrêmes, sauf peut-être les bêta-testeurs semi-pro,
alors que rien n'empêche un utilisateur fouineur de linux d'en faire son
cheval de bataille, son truc, sans pour autant avoir les compétences
adéquates pour en comprendre les tenants et aboutissants, comme c'est le
cas pour certains très bon contributeurs de ce forum mais qui évidemment
ne trouvent pas judicieux d'intervenir sur un fil aussi fourre-tout et
aussi déjanté.
L'OP est en mode "write-only", il faudrait être fou pour répondre à quelqu'un
qui ne veut pas écouter.
Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...
N'est-il pas ? ;-)
Personnellement j'ai filtré depuis très longtemps.
Le 2018-12-07, denis.paris nous expliquait dans
fr.comp.os.linux.configuration
(<5c0a55f6$0$11049$) :Le 07/12/2018 à 11:55, Doug713705 a écrit :Pour le coup il y a bien eu un tel bug dans une release d'Ubuntu.
Rapidement corrigé mais qui a eu le temps de briquer quelques machines.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147
Mais c'est très exceptionnel voire un cas unique (pas vérifié).
Un cas unique pas formellement avéré, peut-être.
Le cas est avéré.Mais le point important dans ce que tu signales c'est le "rapidement corrigé".
Jamais assez rapidement pour ceux qui ont vu leur machine briquées.
Mais notons que c'est un bug qui a concerné uniquement Ubuntu et
éventuellement les quelques distributions qui en sont dérivées (Mint par
exemple).Donc à moins de tester comme un forcement les kernels en versions bêta et
d'être vraiment maudit, c'est à dire avoir la mauvaise distribution, la
mauvaise machine, etc. ce serait vraiment pas de chance d'avoir tous les
bugs simultanément, ainsi que cela semble être le cas pour notre "client".
Il semble avoir le profile idéal.En environnement Windows aucun utilisateurs ne teste le système dans des
conditions aussi extrêmes, sauf peut-être les bêta-testeurs semi-pro,
alors que rien n'empêche un utilisateur fouineur de linux d'en faire son
cheval de bataille, son truc, sans pour autant avoir les compétences
adéquates pour en comprendre les tenants et aboutissants, comme c'est le
cas pour certains très bon contributeurs de ce forum mais qui évidemment
ne trouvent pas judicieux d'intervenir sur un fil aussi fourre-tout et
aussi déjanté.
L'OP est en mode "write-only", il faudrait être fou pour répondre à quelqu'un
qui ne veut pas écouter.Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...
N'est-il pas ? ;-)
Personnellement j'ai filtré depuis très longtemps.
J'ai posé une question qui n'appelait pas à débat ou critique.
Ma question (cf. le titre) était simple :
"Un changement de kernel peut-il entraîner une corruption du système de
partition ?"
La réponse c'est OUI/NON, dans tel cas ou tel cas.
Et c'est tout.
Le débat c'est vous qui voulez le faire, et c'est vous qui décidez
d'être choqués par un bug parmi des milliers existants et recensés pour
les kernels "STABLES".
La seule personne qui a répondu correctement sur ce fil, en se
concentrant sur les faits, sans chercher à faire de leçon de morale,
c'est Philippe.
Il a répondu OUI, et argumenté, dans tels cas (exposé des cas) par
exemple. C'est tout.
J'ai posé une question qui n'appelait pas à débat ou critique.
Ma question (cf. le titre) était simple :
"Un changement de kernel peut-il entraîner une corruption du système de
partition ?"
La réponse c'est OUI/NON, dans tel cas ou tel cas.
Et c'est tout.
Le débat c'est vous qui voulez le faire, et c'est vous qui décidez
d'être choqués par un bug parmi des milliers existants et recensés pour
les kernels "STABLES".
La seule personne qui a répondu correctement sur ce fil, en se
concentrant sur les faits, sans chercher à faire de leçon de morale,
c'est Philippe.
Il a répondu OUI, et argumenté, dans tels cas (exposé des cas) par
exemple. C'est tout.
J'ai posé une question qui n'appelait pas à débat ou critique.
Ma question (cf. le titre) était simple :
"Un changement de kernel peut-il entraîner une corruption du système de
partition ?"
La réponse c'est OUI/NON, dans tel cas ou tel cas.
Et c'est tout.
Le débat c'est vous qui voulez le faire, et c'est vous qui décidez
d'être choqués par un bug parmi des milliers existants et recensés pour
les kernels "STABLES".
La seule personne qui a répondu correctement sur ce fil, en se
concentrant sur les faits, sans chercher à faire de leçon de morale,
c'est Philippe.
Il a répondu OUI, et argumenté, dans tels cas (exposé des cas) par
exemple. C'est tout.
Le 07/12/2018 à 12:48, Pierre zetrader.fr a écrit :J'ai posé une question qui n'appelait pas à débat ou critique.
Ma question (cf. le titre) était simple :
"Un changement de kernel peut-il entraîner une corruption du système
de partition ?"
La réponse c'est OUI/NON, dans tel cas ou tel cas.
Et c'est tout.
Le débat c'est vous qui voulez le faire, et c'est vous qui décidez
d'être choqués par un bug parmi des milliers existants et recensés
pour les kernels "STABLES".
La seule personne qui a répondu correctement sur ce fil, en se
concentrant sur les faits, sans chercher à faire de leçon de morale,
c'est Philippe.
Il a répondu OUI, et argumenté, dans tels cas (exposé des cas) par
exemple. C'est tout.
En fait, ce que tu veux, c'est trouver une personne qui te conforte dans
ton analyse et qui ferait que tu te sentirais moins seul, et les
objections tu les écartes d'un revers de main. J'ai lu en diagonal dont
je ne sais pas ce que valent ces "arguments", mais la réponse à ta
question ce n'est pas "OUI ou NON" mais "OUI et NON":
NON, le seul changement d'un kernel "stable" ne provoque pas à lui tout
seul (donc "toutes choses égales par ailleurs") d'altération d'un
système de fichier aussi courant que le ext4,
Le 07/12/2018 à 12:48, Pierre zetrader.fr a écrit :
J'ai posé une question qui n'appelait pas à débat ou critique.
Ma question (cf. le titre) était simple :
"Un changement de kernel peut-il entraîner une corruption du système
de partition ?"
La réponse c'est OUI/NON, dans tel cas ou tel cas.
Et c'est tout.
Le débat c'est vous qui voulez le faire, et c'est vous qui décidez
d'être choqués par un bug parmi des milliers existants et recensés
pour les kernels "STABLES".
La seule personne qui a répondu correctement sur ce fil, en se
concentrant sur les faits, sans chercher à faire de leçon de morale,
c'est Philippe.
Il a répondu OUI, et argumenté, dans tels cas (exposé des cas) par
exemple. C'est tout.
En fait, ce que tu veux, c'est trouver une personne qui te conforte dans
ton analyse et qui ferait que tu te sentirais moins seul, et les
objections tu les écartes d'un revers de main. J'ai lu en diagonal dont
je ne sais pas ce que valent ces "arguments", mais la réponse à ta
question ce n'est pas "OUI ou NON" mais "OUI et NON":
NON, le seul changement d'un kernel "stable" ne provoque pas à lui tout
seul (donc "toutes choses égales par ailleurs") d'altération d'un
système de fichier aussi courant que le ext4,
Le 07/12/2018 à 12:48, Pierre zetrader.fr a écrit :J'ai posé une question qui n'appelait pas à débat ou critique.
Ma question (cf. le titre) était simple :
"Un changement de kernel peut-il entraîner une corruption du système
de partition ?"
La réponse c'est OUI/NON, dans tel cas ou tel cas.
Et c'est tout.
Le débat c'est vous qui voulez le faire, et c'est vous qui décidez
d'être choqués par un bug parmi des milliers existants et recensés
pour les kernels "STABLES".
La seule personne qui a répondu correctement sur ce fil, en se
concentrant sur les faits, sans chercher à faire de leçon de morale,
c'est Philippe.
Il a répondu OUI, et argumenté, dans tels cas (exposé des cas) par
exemple. C'est tout.
En fait, ce que tu veux, c'est trouver une personne qui te conforte dans
ton analyse et qui ferait que tu te sentirais moins seul, et les
objections tu les écartes d'un revers de main. J'ai lu en diagonal dont
je ne sais pas ce que valent ces "arguments", mais la réponse à ta
question ce n'est pas "OUI ou NON" mais "OUI et NON":
NON, le seul changement d'un kernel "stable" ne provoque pas à lui tout
seul (donc "toutes choses égales par ailleurs") d'altération d'un
système de fichier aussi courant que le ext4,
ce que tu as seulement compris c'est que c'est gratuit
Bref on nage en pleine médiocrité, et plutôt la partie basse de la
moyenne.
Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...
ce que tu as seulement compris c'est que c'est gratuit
Bref on nage en pleine médiocrité, et plutôt la partie basse de la
moyenne.
Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...
ce que tu as seulement compris c'est que c'est gratuit
Bref on nage en pleine médiocrité, et plutôt la partie basse de la
moyenne.
Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...
Le Fri, 07 Dec 2018 10:47:11 +0100, denis.paris a écrit :ce que tu as seulement compris c'est que c'est gratuit
En 1 an.
Le Fri, 07 Dec 2018 10:55:50 +0000, Doug713705 a écrit :Bref on nage en pleine médiocrité, et plutôt la partie basse de la
moyenne.
Tellement vrai !
Le Fri, 07 Dec 2018 12:13:58 +0100, denis.paris a écrit :Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...
Mais le pire, c'est quand même quand c'est lui qui vient donner des
conseils aux autres :D
Le Fri, 07 Dec 2018 10:47:11 +0100, denis.paris a écrit :
ce que tu as seulement compris c'est que c'est gratuit
En 1 an.
Le Fri, 07 Dec 2018 10:55:50 +0000, Doug713705 a écrit :
Bref on nage en pleine médiocrité, et plutôt la partie basse de la
moyenne.
Tellement vrai !
Le Fri, 07 Dec 2018 12:13:58 +0100, denis.paris a écrit :
Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...
Mais le pire, c'est quand même quand c'est lui qui vient donner des
conseils aux autres :D
Le Fri, 07 Dec 2018 10:47:11 +0100, denis.paris a écrit :ce que tu as seulement compris c'est que c'est gratuit
En 1 an.
Le Fri, 07 Dec 2018 10:55:50 +0000, Doug713705 a écrit :Bref on nage en pleine médiocrité, et plutôt la partie basse de la
moyenne.
Tellement vrai !
Le Fri, 07 Dec 2018 12:13:58 +0100, denis.paris a écrit :Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...
Mais le pire, c'est quand même quand c'est lui qui vient donner des
conseils aux autres :D
Le 07/12/2018 à 13:38, denis.paris a écrit :Le 07/12/2018 à 12:48, Pierre zetrader.fr a écrit :J'ai posé une question qui n'appelait pas à débat ou critique.
Ma question (cf. le titre) était simple :
"Un changement de kernel peut-il entraîner une corruption du système
de partition ?"
La réponse c'est OUI/NON, dans tel cas ou tel cas.
Et c'est tout.
Le débat c'est vous qui voulez le faire, et c'est vous qui décidez
d'être choqués par un bug parmi des milliers existants et recensés
pour les kernels "STABLES".
La seule personne qui a répondu correctement sur ce fil, en se
concentrant sur les faits, sans chercher à faire de leçon de morale,
c'est Philippe.
Il a répondu OUI, et argumenté, dans tels cas (exposé des cas) par
exemple. C'est tout.
En fait, ce que tu veux, c'est trouver une personne qui te conforte
dans ton analyse et qui ferait que tu te sentirais moins seul, et les
objections tu les écartes d'un revers de main. J'ai lu en diagonal
dont je ne sais pas ce que valent ces "arguments", mais la réponse à
ta question ce n'est pas "OUI ou NON" mais "OUI et NON":
NON, le seul changement d'un kernel "stable" ne provoque pas à lui
tout seul (donc "toutes choses égales par ailleurs") d'altération d'un
système de fichier aussi courant que le ext4,
Alors c'est quoi ça ?
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1806755
"4.19 kernels before 8.9 have filesystem corruption under memory pressure"
https://www.google.fr/search?q=kernel+4.19+ext4+corruption
Une "memory pressure" c'est quoi, par exemple mes onglets ouverts sous
google chrome puis le fait de vouloir lancer Thunderbird et que le
système utilise du swap disk ?
Parce qu'en dehors d'utiliser chrome et thunderbird, je n'avais rien
fait de spécial sous Kubuntu.
Ce que j'ai fait (dans l'ordre) :
- faire toutes les mises à jours demandées post installation, sudo
apt-get update / sudo apt-get upgrade...(je ne pense pas que cela soit
de nature à troubler le système de fichiers)
- désactiver les effets spéciaux dans l'interface de Kubuntu (idem)
- télécharger et installer chrome (idem)
- désactiver le module bluetooth (idem)
- des jours plus tard : installer ukuu (idem)
- mettre le kernel 4.18.20 avec ukuu, le tester, redémarrer plusieurs
fois avec, et tourner avec (ouverture d'onglets dans chrome, lectures de
vidéos avec vlc, thunderbird, le gestionnaire de fichiers...), faire
ensuite la même chose pour le kernel 4.19.6, puis ensuite revenir au
kernel 4.18.20, toujours avec ukuu (c'est visiblement après ces
manipulations que le problème survenu)
Puis ensuite en usage normal (utilisation de google chrome et
thunderbird, rien de spécial), le problème est survenu et au
redémarrage, lors du menu GRUB il y avait un problème sur la partition
qui empêchait de lancer le kernel, problème qu'il a fallu corriger avec
fsck pour pouvoir lancer kubuntu.
J'ai ensuite décidé de revenir au kernel d'origine (4.18.0-11) de la
distribution, mais malgré cela, le problème s'est reproduit plus tard.
C'est là que j'ai décidé de tout formater et mettre xubuntu 18.10, puis
plus tard linux mint 19 (sous lequel je suis en ce moment).
Le 07/12/2018 à 13:38, denis.paris a écrit :
Le 07/12/2018 à 12:48, Pierre zetrader.fr a écrit :
J'ai posé une question qui n'appelait pas à débat ou critique.
Ma question (cf. le titre) était simple :
"Un changement de kernel peut-il entraîner une corruption du système
de partition ?"
La réponse c'est OUI/NON, dans tel cas ou tel cas.
Et c'est tout.
Le débat c'est vous qui voulez le faire, et c'est vous qui décidez
d'être choqués par un bug parmi des milliers existants et recensés
pour les kernels "STABLES".
La seule personne qui a répondu correctement sur ce fil, en se
concentrant sur les faits, sans chercher à faire de leçon de morale,
c'est Philippe.
Il a répondu OUI, et argumenté, dans tels cas (exposé des cas) par
exemple. C'est tout.
En fait, ce que tu veux, c'est trouver une personne qui te conforte
dans ton analyse et qui ferait que tu te sentirais moins seul, et les
objections tu les écartes d'un revers de main. J'ai lu en diagonal
dont je ne sais pas ce que valent ces "arguments", mais la réponse à
ta question ce n'est pas "OUI ou NON" mais "OUI et NON":
NON, le seul changement d'un kernel "stable" ne provoque pas à lui
tout seul (donc "toutes choses égales par ailleurs") d'altération d'un
système de fichier aussi courant que le ext4,
Alors c'est quoi ça ?
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1806755
"4.19 kernels before 8.9 have filesystem corruption under memory pressure"
https://www.google.fr/search?q=kernel+4.19+ext4+corruption
Une "memory pressure" c'est quoi, par exemple mes onglets ouverts sous
google chrome puis le fait de vouloir lancer Thunderbird et que le
système utilise du swap disk ?
Parce qu'en dehors d'utiliser chrome et thunderbird, je n'avais rien
fait de spécial sous Kubuntu.
Ce que j'ai fait (dans l'ordre) :
- faire toutes les mises à jours demandées post installation, sudo
apt-get update / sudo apt-get upgrade...(je ne pense pas que cela soit
de nature à troubler le système de fichiers)
- désactiver les effets spéciaux dans l'interface de Kubuntu (idem)
- télécharger et installer chrome (idem)
- désactiver le module bluetooth (idem)
- des jours plus tard : installer ukuu (idem)
- mettre le kernel 4.18.20 avec ukuu, le tester, redémarrer plusieurs
fois avec, et tourner avec (ouverture d'onglets dans chrome, lectures de
vidéos avec vlc, thunderbird, le gestionnaire de fichiers...), faire
ensuite la même chose pour le kernel 4.19.6, puis ensuite revenir au
kernel 4.18.20, toujours avec ukuu (c'est visiblement après ces
manipulations que le problème survenu)
Puis ensuite en usage normal (utilisation de google chrome et
thunderbird, rien de spécial), le problème est survenu et au
redémarrage, lors du menu GRUB il y avait un problème sur la partition
qui empêchait de lancer le kernel, problème qu'il a fallu corriger avec
fsck pour pouvoir lancer kubuntu.
J'ai ensuite décidé de revenir au kernel d'origine (4.18.0-11) de la
distribution, mais malgré cela, le problème s'est reproduit plus tard.
C'est là que j'ai décidé de tout formater et mettre xubuntu 18.10, puis
plus tard linux mint 19 (sous lequel je suis en ce moment).
Le 07/12/2018 à 13:38, denis.paris a écrit :Le 07/12/2018 à 12:48, Pierre zetrader.fr a écrit :J'ai posé une question qui n'appelait pas à débat ou critique.
Ma question (cf. le titre) était simple :
"Un changement de kernel peut-il entraîner une corruption du système
de partition ?"
La réponse c'est OUI/NON, dans tel cas ou tel cas.
Et c'est tout.
Le débat c'est vous qui voulez le faire, et c'est vous qui décidez
d'être choqués par un bug parmi des milliers existants et recensés
pour les kernels "STABLES".
La seule personne qui a répondu correctement sur ce fil, en se
concentrant sur les faits, sans chercher à faire de leçon de morale,
c'est Philippe.
Il a répondu OUI, et argumenté, dans tels cas (exposé des cas) par
exemple. C'est tout.
En fait, ce que tu veux, c'est trouver une personne qui te conforte
dans ton analyse et qui ferait que tu te sentirais moins seul, et les
objections tu les écartes d'un revers de main. J'ai lu en diagonal
dont je ne sais pas ce que valent ces "arguments", mais la réponse à
ta question ce n'est pas "OUI ou NON" mais "OUI et NON":
NON, le seul changement d'un kernel "stable" ne provoque pas à lui
tout seul (donc "toutes choses égales par ailleurs") d'altération d'un
système de fichier aussi courant que le ext4,
Alors c'est quoi ça ?
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1806755
"4.19 kernels before 8.9 have filesystem corruption under memory pressure"
https://www.google.fr/search?q=kernel+4.19+ext4+corruption
Une "memory pressure" c'est quoi, par exemple mes onglets ouverts sous
google chrome puis le fait de vouloir lancer Thunderbird et que le
système utilise du swap disk ?
Parce qu'en dehors d'utiliser chrome et thunderbird, je n'avais rien
fait de spécial sous Kubuntu.
Ce que j'ai fait (dans l'ordre) :
- faire toutes les mises à jours demandées post installation, sudo
apt-get update / sudo apt-get upgrade...(je ne pense pas que cela soit
de nature à troubler le système de fichiers)
- désactiver les effets spéciaux dans l'interface de Kubuntu (idem)
- télécharger et installer chrome (idem)
- désactiver le module bluetooth (idem)
- des jours plus tard : installer ukuu (idem)
- mettre le kernel 4.18.20 avec ukuu, le tester, redémarrer plusieurs
fois avec, et tourner avec (ouverture d'onglets dans chrome, lectures de
vidéos avec vlc, thunderbird, le gestionnaire de fichiers...), faire
ensuite la même chose pour le kernel 4.19.6, puis ensuite revenir au
kernel 4.18.20, toujours avec ukuu (c'est visiblement après ces
manipulations que le problème survenu)
Puis ensuite en usage normal (utilisation de google chrome et
thunderbird, rien de spécial), le problème est survenu et au
redémarrage, lors du menu GRUB il y avait un problème sur la partition
qui empêchait de lancer le kernel, problème qu'il a fallu corriger avec
fsck pour pouvoir lancer kubuntu.
J'ai ensuite décidé de revenir au kernel d'origine (4.18.0-11) de la
distribution, mais malgré cela, le problème s'est reproduit plus tard.
C'est là que j'ai décidé de tout formater et mettre xubuntu 18.10, puis
plus tard linux mint 19 (sous lequel je suis en ce moment).
- mettre le kernel 4.18.20 avec ukuu, le tester, redémarrer plusieurs
fois avec, et tourner avec (ouverture d'onglets dans chrome, lectures de
vidéos avec vlc, thunderbird, le gestionnaire de fichiers...), faire
ensuite la même chose pour le kernel 4.19.6, puis ensuite revenir au
kernel 4.18.20, toujours avec ukuu (c'est visiblement après ces
manipulations que le problème survenu)
- mettre le kernel 4.18.20 avec ukuu, le tester, redémarrer plusieurs
fois avec, et tourner avec (ouverture d'onglets dans chrome, lectures de
vidéos avec vlc, thunderbird, le gestionnaire de fichiers...), faire
ensuite la même chose pour le kernel 4.19.6, puis ensuite revenir au
kernel 4.18.20, toujours avec ukuu (c'est visiblement après ces
manipulations que le problème survenu)
- mettre le kernel 4.18.20 avec ukuu, le tester, redémarrer plusieurs
fois avec, et tourner avec (ouverture d'onglets dans chrome, lectures de
vidéos avec vlc, thunderbird, le gestionnaire de fichiers...), faire
ensuite la même chose pour le kernel 4.19.6, puis ensuite revenir au
kernel 4.18.20, toujours avec ukuu (c'est visiblement après ces
manipulations que le problème survenu)
Mais du coup, tous les deux, vous avez bien conscience que vos réponses
ne servent à rien ? Lui ne les comprend pas, et les autres le savent
déjà;)
Mais du coup, tous les deux, vous avez bien conscience que vos réponses
ne servent à rien ? Lui ne les comprend pas, et les autres le savent
déjà;)
Mais du coup, tous les deux, vous avez bien conscience que vos réponses
ne servent à rien ? Lui ne les comprend pas, et les autres le savent
déjà;)
Le 07/12/2018 à 14:10, Pierre zetrader.fr a écrit :- mettre le kernel 4.18.20 avec ukuu, le tester, redémarrer plusieurs
fois avec, et tourner avec (ouverture d'onglets dans chrome, lectures
de vidéos avec vlc, thunderbird, le gestionnaire de fichiers...),
faire ensuite la même chose pour le kernel 4.19.6, puis ensuite
revenir au kernel 4.18.20, toujours avec ukuu (c'est visiblement après
ces manipulations que le problème survenu)
On ne bascule pas aussi facilement que ça d'un kernel à l'autre, comme
si tout le reste ne changeait pas. Quand on fait un upgrade via les
dépôts, même officiels, tout le reste de la distribution "qui va avec",
c'est à dire parfois des dizaines d'autres composants, ont été testés
avec le nouveau kernel, et ce n'est pas certain qu'en "revenant" au
précédent on retrouve un environnement stable. Au contraire, on peut
être sûr qu'il n'est pas identique puisqu'il n'y a pas de "retour
arrière" pour tous les paquets mis à jour au moment de l'upgrade. On se
retrouve dans un environnement non testé.
La possibilité de redémarrer sur un ancien noyau, si elle est très
facile à mettre en ½uvre, doit cependant être considérée comme une
mesure d'urgence au cas ou le nouveau noyau ne démarrerait pas. Cela
permet notamment de récupérer ses fichiers, mais l'ensemble du système
doit alors être considéré comme potentiellement instable.
La seule solution qui permet un retour arrière 100% fiable est la
sauvegarde complète du système. Personnellement, quand je fais un
upgrade majeur je sauvegarde la partition / et la /boot si elle est
séparée, mais sans les données /home, en "offline" (car un système actif
est difficile à sauvegarder d'une manière certaine), c.a.d en démarrant
le PC depuis une clé USB. J'utilise clonezilla qui est un logiciel
fabuleux et qui fait le job en moins de 10 mn en envoyant la sauvegarde
sur un NAS.
Tes allers-retours incessants entre différentes versions sont très
probablement une grande partie du problème.
Le 07/12/2018 à 14:10, Pierre zetrader.fr a écrit :
- mettre le kernel 4.18.20 avec ukuu, le tester, redémarrer plusieurs
fois avec, et tourner avec (ouverture d'onglets dans chrome, lectures
de vidéos avec vlc, thunderbird, le gestionnaire de fichiers...),
faire ensuite la même chose pour le kernel 4.19.6, puis ensuite
revenir au kernel 4.18.20, toujours avec ukuu (c'est visiblement après
ces manipulations que le problème survenu)
On ne bascule pas aussi facilement que ça d'un kernel à l'autre, comme
si tout le reste ne changeait pas. Quand on fait un upgrade via les
dépôts, même officiels, tout le reste de la distribution "qui va avec",
c'est à dire parfois des dizaines d'autres composants, ont été testés
avec le nouveau kernel, et ce n'est pas certain qu'en "revenant" au
précédent on retrouve un environnement stable. Au contraire, on peut
être sûr qu'il n'est pas identique puisqu'il n'y a pas de "retour
arrière" pour tous les paquets mis à jour au moment de l'upgrade. On se
retrouve dans un environnement non testé.
La possibilité de redémarrer sur un ancien noyau, si elle est très
facile à mettre en ½uvre, doit cependant être considérée comme une
mesure d'urgence au cas ou le nouveau noyau ne démarrerait pas. Cela
permet notamment de récupérer ses fichiers, mais l'ensemble du système
doit alors être considéré comme potentiellement instable.
La seule solution qui permet un retour arrière 100% fiable est la
sauvegarde complète du système. Personnellement, quand je fais un
upgrade majeur je sauvegarde la partition / et la /boot si elle est
séparée, mais sans les données /home, en "offline" (car un système actif
est difficile à sauvegarder d'une manière certaine), c.a.d en démarrant
le PC depuis une clé USB. J'utilise clonezilla qui est un logiciel
fabuleux et qui fait le job en moins de 10 mn en envoyant la sauvegarde
sur un NAS.
Tes allers-retours incessants entre différentes versions sont très
probablement une grande partie du problème.
Le 07/12/2018 à 14:10, Pierre zetrader.fr a écrit :- mettre le kernel 4.18.20 avec ukuu, le tester, redémarrer plusieurs
fois avec, et tourner avec (ouverture d'onglets dans chrome, lectures
de vidéos avec vlc, thunderbird, le gestionnaire de fichiers...),
faire ensuite la même chose pour le kernel 4.19.6, puis ensuite
revenir au kernel 4.18.20, toujours avec ukuu (c'est visiblement après
ces manipulations que le problème survenu)
On ne bascule pas aussi facilement que ça d'un kernel à l'autre, comme
si tout le reste ne changeait pas. Quand on fait un upgrade via les
dépôts, même officiels, tout le reste de la distribution "qui va avec",
c'est à dire parfois des dizaines d'autres composants, ont été testés
avec le nouveau kernel, et ce n'est pas certain qu'en "revenant" au
précédent on retrouve un environnement stable. Au contraire, on peut
être sûr qu'il n'est pas identique puisqu'il n'y a pas de "retour
arrière" pour tous les paquets mis à jour au moment de l'upgrade. On se
retrouve dans un environnement non testé.
La possibilité de redémarrer sur un ancien noyau, si elle est très
facile à mettre en ½uvre, doit cependant être considérée comme une
mesure d'urgence au cas ou le nouveau noyau ne démarrerait pas. Cela
permet notamment de récupérer ses fichiers, mais l'ensemble du système
doit alors être considéré comme potentiellement instable.
La seule solution qui permet un retour arrière 100% fiable est la
sauvegarde complète du système. Personnellement, quand je fais un
upgrade majeur je sauvegarde la partition / et la /boot si elle est
séparée, mais sans les données /home, en "offline" (car un système actif
est difficile à sauvegarder d'une manière certaine), c.a.d en démarrant
le PC depuis une clé USB. J'utilise clonezilla qui est un logiciel
fabuleux et qui fait le job en moins de 10 mn en envoyant la sauvegarde
sur un NAS.
Tes allers-retours incessants entre différentes versions sont très
probablement une grande partie du problème.
Le 07/12/2018 à 14:27, Christophe PEREZ a écrit :Mais du coup, tous les deux, vous avez bien conscience que vos réponses
ne servent à rien ? Lui ne les comprend pas, et les autres le savent
déjà;)
C'est un enfant qui vient de découvrir ses nouveaux jouets et qui
s'amuse à les jeter par terre... Des fois, ça casse!
Il faut savoir faire preuve d'un peu de patience! :)
Le 07/12/2018 à 14:27, Christophe PEREZ a écrit :
Mais du coup, tous les deux, vous avez bien conscience que vos réponses
ne servent à rien ? Lui ne les comprend pas, et les autres le savent
déjà;)
C'est un enfant qui vient de découvrir ses nouveaux jouets et qui
s'amuse à les jeter par terre... Des fois, ça casse!
Il faut savoir faire preuve d'un peu de patience! :)
Le 07/12/2018 à 14:27, Christophe PEREZ a écrit :Mais du coup, tous les deux, vous avez bien conscience que vos réponses
ne servent à rien ? Lui ne les comprend pas, et les autres le savent
déjà;)
C'est un enfant qui vient de découvrir ses nouveaux jouets et qui
s'amuse à les jeter par terre... Des fois, ça casse!
Il faut savoir faire preuve d'un peu de patience! :)