Un changement de kernel peut-il entra=c3=aener une corruption du syst=c3=a8me de partition =3f

Le 06/12/2018 à 15:32, Jo Engo a écrit :

Le Wed, 05 Dec 2018 19:30:32 +0100, Pierre www.zetrader.fr a écrit :

Mais sinon si cela ne répond pas à cette question importante : est-ce
qu'un changement de kernel (même en version dite "stable" comme la
4.18.20) qui n'a pas été fait spécifiquement pour la distribution peut
corrompre le système de partition ?

Non.

Pourtant c'est bien possible pour le kernel 4.19 :
https://www.google.fr/search?q=kernel+4.19+corruption

Qu'est-ce qui te permet d'être aussi affirmatif ?
Quand c'est arrivé sous Kubuntu, je ne faisais rien d'autre que de
naviguer, mieux que ça, j'avais laissé quelques onglets ouverts sur des
sites habituels, donc pas d'activité particulière de nature à corrompre
une partition : utiliser google chrome, thunderbird, rien de spécial.
J'ai évidemment pensé à Kubuntu mais rien trouvé qui indique que ce soit
une faille, un bug qui vienne de Kubuntu.
C'est une autre possibilité mais je ne trouve rien dans ce sens, par
contre pour le kernel oui.
Je suis ensuite revenu sous Xubuntu 18.10 (kernel 4.18.0-12), pas de
problème particulier, mais je trouve qu'il peut ramer pas mal quand pas
mal d'onglets ouverts, puis là Linux Mint (Cinnamon c'est mon préféré)
19, qui d'ailleurs tourne plutôt pas mal sous le dernier noyau de la
distribution (4.15.0-42 là), étrangement il prend plus de RAM que
Xubuntu avec les mêmes onglets ouverts MAIS il ne rame pas comme Xubuntu
à même niveau d'occupation de mémoire voire plus, c'est assez étrange,
on dirait que Mint gère mieux la mémoire ou les processeurs, en tout cas
le résultat est que c'est rapide au final sous Mint quand j'ai laissé
longtemps ouvert avec plusieurs onglets.

Kubuntu est très léger (au démarrage en tout cas), encore plus que
Xubuntu, c'est impressionnant, mais j'aime pas trop l'interface, je
préfère Xubuntu ou Cinnamon (j'ai aussi essayé Cinnamon sur Xubuntu,
mais je préfère via Linux Mint en fait, quitte à utiliser Cinnamon).
Pour que le test soit complet, faudrait que je teste ce même kernel
4.18.20 sous Linux Mint 19, quelques jours.
Car actuellement je ne sais pas si c'est le fait d'avoir mis le kernel
4.19.6 temporairement sur Kubuntu qui a fait ce problème, ou si le
kernel 4.18.20 est fautif aussi.
Le kernel 4.19 ne m'intéressant pas en soi (aucune nouveauté
intéressante pour ma machine), c'était plutôt de la curiosité de tester
le dernier kernel stable.
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com

Pierre www.zetrader.info wrote on 06-12-18 11:29:

Pour les autres erreurs que j'ai eu en changeant de kernel, j'ai pu le
régler aussi souvent, comme le wifi coupé, en revenant au kernel juste
avant le wifi revenait, problème identifié, ensuite en retestant de
nouveau le kernel fautif, j'avais trouvé la manip pour faire marcher
le wifi sous ce kernel.

Il me semble que lorsque le wifi avait disparu c'était après avoir
installé un kernel STABLE ...
Si c'est le cas, c'est inadmissible.

Le 06/12/2018 à 23:02, Rambo a écrit :

Pierre www.zetrader.info wrote on 06-12-18 11:29:

Pour les autres erreurs que j'ai eu en changeant de kernel, j'ai pu le
régler aussi souvent, comme le wifi coupé, en revenant au kernel juste
avant le wifi revenait, problème identifié, ensuite en retestant de
nouveau le kernel fautif, j'avais trouvé la manip pour faire marcher
le wifi sous ce kernel.

Il me semble que lorsque le wifi avait disparu c'était après avoir
installé un kernel STABLE ...
Si c'est le cas, c'est inadmissible.

Exact, c'était pas un kernel générique "stable" cette fois, mais un
kernel spécifique "stable" de cette version de distribution, je n'étais
pas allé chercher un kernel plus haut non prévu par la distribution,
j'avais simplement fait la mise à jour que me suggérait cette version de
distribution.
Et des problèmes suite à une simple mise à jour de kernel suggérée par
la distribution, google en regorge, c'est pas que moi, donc dire que
c'est moi la cata pour un bug sur un simple test de kernels "stables",
c'est vouloir nier l'évidence, être de mauvaise foi face à l'avalanche
de plantages et de bugs qu'on peut voir sur certaines versions "stables"
de kernel et d'ubuntu : gel du système, cassage du bios, pc qui ne
démarre plus etc...
Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit
rappel pour rafraîchir la mémoire à certains :
https://www.google.fr/search?q=ubuntu+17.04+bios
https://www.google.fr/search?q=kernel+freeze
https://www.google.fr/search?q=kernel+freeze+4.15
Etc etc...
Ceux de la distribution sont sous la forme 4.xx.0-yz, ceux génériques
4.xx.yz.
Exemple pour ubuntu 18.10 et dérivés, kernel 4.18 qui en est à 4.18.0-12
(4.18.0-10 lors de l'installation), il y a donc eu plusieurs mises à
jours, corrections, spécifiques pour cette version d'ubuntu (ou dérivé,
cela utilise le même noyau), si je mets le kernel 4.18.1 ou 4.18.20
(voir branche "stable" sur https://www.kernel.org/ ), alors il s'agit
d'une version très générique, pas spécialement optimisée pour cette
version d'ubuntu, avec a priori des risques de bugs supplémentaires,
mais bon cela peut se passer bien aussi, c'est à tester, selon la
version de kernel, le hardware qu'on a etc...
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com

Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :

Et des problèmes suite à une simple mise à jour de kernel suggérée par
la distribution, google en regorge, c'est pas que moi, donc dire que
c'est moi la cata pour un bug sur un simple test de kernels "stables",
c'est vouloir nier l'évidence, être de mauvaise foi face à l'avalanche
de plantages et de bugs qu'on peut voir sur certaines versions "stables"
de kernel et d'ubuntu : gel du système, cassage du bios, pc qui ne
démarre plus etc...
Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit
rappel pour rafraîchir la mémoire à certains :
https://www.google.fr/search?q=ubuntu+17.04+bios
https://www.google.fr/search?q=kernel+freeze
https://www.google.fr/search?q=kernel+freeze+4.15
Etc etc...

Un kernel qui "casserait" le bios, là franchement ça devient du délire.
C'est du hardware, il faut "flasher" la ROM pour le modifier et faudrait
imaginer des programmeurs linux particulièrement fous pour se lancer
dans ces procédures qui sont étroitement liées au matériel et de la
seule responsabilité des constructeurs.

Linux est "libre", apparemment tu n'as pas encore intégré ce concept (ce
que tu as seulement compris c'est que c'est gratuit), mais ça veut dire
aussi que le code est constamment relu et corrigé, et un élément
logiciel qui se permettrait de modifier le hardware d'un constructeur
serait tout de suite repéré et éliminé. Du moins j'ose l'espérer!

Dans le pire des cas, un code qui partirait en vrille pourrait peut-être
altérer en provoquant un crash des paramètres de bios, comme l'ordre de
boot ou l'UEFI, Mais tous les bios possèdent une commande de
restauration aux paramètres usine.

Tu es obsédé par le "kernel", le noyau rien que le noyau, c'est ton
credo, tu l'as découvert parce que venant du monde Windows, cette notion
n'était pas claire tellement le cœur du système Windows (qui existe
cependant) est mélangé avec les éléments graphiques (ce qui en fait un
système difficile à maintenir).

Mais il y a bien d'autres sources possibles de dysfonctionnements dans
un système linux (même si le principal c'est souvent l'utilisateur): il
y a toute la sauce annexe, c'est à dire la "distribution". Et là il y a
à boire et à manger, certaines distributions sont mal foutues, de même
que certains éléments peuvent avoir du mal à s'adapter à certains
hardware. C'est le cas par exemple du "grub", ou grub2 qui parfois gère
mal certains types de disques (selon la façon dont ils sont gérés par le
BIOS de certaines machines) et qui fait qu'on peut se retrouver en effet
avec une machine qui ne boote plus, suite à un "update-grub" qui s'est
mal passé. Un utilisateur expérimenté sait en général réparer cela, mais
je peut comprendre qu'un "end-user" soit dérouté et déverse sa
frustration sur Internet...

Mais il ne faut pas croire tout ce qu'on lit sur Internet! Le
comportement pourtant très courant qui consiste à avoir une idée
préconçue, à la formuler dans une requête à destination de Google et de
crier victoire quand on croit avoir trouvé quelqu'un "qui a le même
problème" est assez naïf, car compte tenu des millions de possibilités
on trouve toujours un compagnon d'infortune...

Le 07/12/2018 à 10:47, denis.paris a écrit :

Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :

Et des problèmes suite à une simple mise à jour de kernel suggérée par
la distribution, google en regorge, c'est pas que moi, donc dire que
c'est moi la cata pour un bug sur un simple test de kernels "stables",
c'est vouloir nier l'évidence, être de mauvaise foi face à l'avalanche
de plantages et de bugs qu'on peut voir sur certaines versions
"stables" de kernel et d'ubuntu : gel du système, cassage du bios, pc
qui ne démarre plus etc...
Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit
rappel pour rafraîchir la mémoire à certains :
https://www.google.fr/search?q=ubuntu+17.04+bios
https://www.google.fr/search?q=kernel+freeze
https://www.google.fr/search?q=kernel+freeze+4.15
Etc etc...

Un kernel qui "casserait" le bios, là franchement ça devient du délire.
C'est du hardware, il faut "flasher" la ROM pour le modifier et faudrait
imaginer des programmeurs linux particulièrement fous pour se lancer
dans ces procédures qui sont étroitement liées au matériel et de la
seule responsabilité des constructeurs.

Dans ce cas précis, je n'ai pas dit que c'était le kernel, c'est
justement pour ce cas que j'ai rajouté dans ma phrase certaines versions
"stables" de kernel *et d'ubuntu*, il n'y a qu'à voir le lien google que
je mets, c'est la version d'ubuntu 17.04 ou plutôt 17.10 (après
recherche) qui modifiait le bios de certains pc :
https://www.omgubuntu.co.uk/2017/12/ubuntu-corrupting-lenovo-laptop-bios
https://forum.ubuntu-fr.org/viewtopic.php?id 17786
J'en avais parlé ici même à l'époque et évité d'installer cette version
d'ubuntu pour pas niquer mon BIOS (la solution n'est pas sortie de
suite, pour réparer le BIOS).
Je n'ai pas eu ce problème mais plein de gens l'ont eu, et pendant
qu'ils n'avaient pas de solution, ils étaient en galère, parce que cela
les empêchait aussi de charger d'une clé USB.
Ubuntu avait même suspendu pendant un bon moment le téléchargement de la
dite version, vu la gravité du bug.

Linux est "libre", apparemment tu n'as pas encore intégré ce concept (ce
que tu as seulement compris c'est que c'est gratuit), mais ça veut dire
aussi que le code est constamment relu et corrigé, et un élément
logiciel qui se permettrait de modifier le hardware d'un constructeur
serait tout de suite repéré et éliminé. Du moins j'ose l'espérer!

Tout de suite, non, c'est là ton erreur, cela peut mettre un certain
temps, par exemple pour la version de kernel qui avait coupé mon accès
au wifi, j'ai dû revenir sur la version précédente un certain temps,
puis une nouvelle version de kernel est sortie, et elle me coupait aussi
l'accès au wifi, c'est là que je me suis dit qu'il faut que je trouve
une solution pour faire marcher le wifi avec ces nouvelles versions de
kernel où "par défaut" le wifi ne marche plus sur ma machine.
BIEN PLUS TARD, les versions de kernel suivantes n'avaient plus ce
problème de me couper l'accès au wifi par défaut, par défaut cela
fonctionnait de nouveau, il y a donc eu une série de kernels foireux par
rapport à ma carte wifi.
Je sais que c'est libre et gratuit, que c'est complexe, qu'ils font ce
qu'ils peuvent pour être compatible avec un maximum de matériel, donc
c'est normal qu'ils mettent un peu de temps parfois à résoudre le
problème, voire que pour certains matériels, ils abandonnent toute
tentative d'amélioration (déjà occupés sur d'autres problèmes), c'est
aussi pour ça que des modules alternatifs ou propriétaires sont utilisés
parfois, quand les modules intégrés sont vraiment trop foireux.

Dans le pire des cas, un code qui partirait en vrille pourrait peut-être
altérer en provoquant un crash des paramètres de bios, comme l'ordre de
boot ou l'UEFI, Mais tous les bios possèdent une commande de
restauration aux paramètres usine.

Tu es obsédé par le "kernel", le noyau rien que le noyau, c'est ton
credo, tu l'as découvert parce que venant du monde Windows, cette notion
n'était pas claire tellement le cœur du système Windows (qui existe
cependant) est mélangé avec les éléments graphiques (ce qui en fait un
système difficile à maintenir).

Sur Windows, c'est simple, tu changes de windows pour changer de
"kernel", cela n'existe pas en effet.
Mais je trouve ça très bien qu'on puisse changer de kernel, pour chaque
machine, cela permet de savoir lequel est le plus approprié.
Ce n'est pas un reproche, je constate juste que cela comporte des
risques, et la seule chose que je demandais, c'est en savoir plus sur la
nature des risques.
Je comprends aussi que le mot "stable" n'a pas forcément le même sens
que sous windows, et que cela n'exclut pas justement certaines
instabilités ou bugs.
Les bugs, je connais ça depuis l'amstrad ou l'atari st, ça fait partie
de la vie normale du développement, des jeux et des logiciels, qu'on
puisse repérer des bugs, des failles, et que ce soit encore corrigé ou
non, certaines versions resteront avec leurs bugs et c'est tout.
À la limite si le bug est pas trop gênant et qu'on sait comment l'éviter
ou minimiser son impact, c'est pas la fin du monde non plus.

Mais il y a bien d'autres sources possibles de dysfonctionnements dans
un système linux (même si le principal c'est souvent l'utilisateur): il
y a toute la sauce annexe, c'est à dire la "distribution". Et là il y a
à boire et à manger, certaines distributions sont mal foutues, de même
que certains éléments peuvent avoir du mal à s'adapter à certains
hardware. C'est le cas par exemple du "grub", ou grub2 qui parfois gère
mal certains types de disques (selon la façon dont ils sont gérés par le
BIOS de certaines machines) et qui fait qu'on peut se retrouver en effet
avec une machine qui ne boote plus, suite à un "update-grub" qui s'est
mal passé. Un utilisateur expérimenté sait en général réparer cela, mais
je peut comprendre qu'un "end-user" soit dérouté et déverse sa
frustration sur Internet...

Pour ma part, je ne déverse pas de frustation, j'apprends, les bugs et
les failles font partie des systèmes et des logiciels, j'ai vu tous les
systèmes avoir des bugs, des plantages : atari st, amiga, dos/windows,
linux, android...
Je ne suis pas en train de dire que Linux c'est nul, au contraire, je
suis en train d'apprendre où sont les bugs, pour ensuite à l'avenir
comment utiliser Linux de la manière la plus stable possible.
J'ai aussi appris sous dos/windows, en faisant planter un max au début,
en voyant les programmes qui faisaient planter le système, les commandes
dangereuses etc...ensuite j'ai pu tourner sous le même windows pendant
des années sans plantages, parce que je savais plus ou moins ce qui
était à risque et ce qui ne l'était pas.
Je suppose que sous Linux, ce n'est pas très différent pour cette partie
là, il faut savoir ce qui est risqué, quels types de risques etc... pour
ensuite pouvoir avoir un système on peut rester durablement sans trop de
problèmes, et aussi savoir quoi faire selon les problèmes qui se
pointent (si on a déjà expérimenté avant, on a plus de chances de savoir).

Mais il ne faut pas croire tout ce qu'on lit sur Internet! Le
comportement pourtant très courant qui consiste à avoir une idée
préconçue, à la formuler dans une requête à destination de Google et de
crier victoire quand on croit avoir trouvé quelqu'un "qui a le même
problème" est assez naïf, car compte tenu des millions de possibilités
on trouve toujours un compagnon d'infortune...

Dans le problème précis que j'ai rencontré sous Kubuntu, je n'ai
effectivement pas la certitude que Kubuntu n'ait pas sa part de
culpabilité, ayant déjà constaté des endroits buggés dans Kubuntu (par
exemple un endroit du menu, si j'y reviens, systématiquement, il
plantera, et ça c'est pas la faute du kernel).
Ubuntu Mate a un autre défaut de menu, un bug que je peux déclencher
quasi systématiquement si je veux, Linux Mint Cinnamon, depuis le début
quoique je fasse, je n'ai jamais réussi à faire planter un quelconque
menu, aucun menu n'a jamais planté, tout cela n'a effectivement rien à
voir avec le kernel.
Cependant je n'ai pas trouvé de pistes indiquant que le problème de
corruption du système de partition vienne de Kubuntu (j'ai cherché), en
revanche pour les kernel 4.19 il y a le fait que tous les kernel en 4.19
(pour le moment, ce sera corrigé j'imagine) puissent corrompre le
système de fichiers, hors j'avais testé un kernel 4.19 sur Kubuntu,
c'est ce qui me fait émettre l'hypothèse d'avoir corrompu le système de
fichiers sans m'en rendre compte (n'ayant pas eu d'erreur immédiate et
en ayant pu revenir au kernel 4.18.20 sans erreur), en testant
rapidement ce kernel.
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com

Le 07/12/2018 à 10:47, denis.paris a écrit :

[...]
Un kernel qui "casserait" le bios, là franchement ça devient du délire.

Pourtant : https://bugs.launchpad.net/bugs/1734147

JBF

--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents

["Followup-To:" header set to fr.comp.os.linux.configuration.]
Le 2018-12-07, denis.paris nous expliquait dans
fr.comp.os.linux.configuration
(<5c0a41a0$0$5473$426a34cc@news.free.fr>) :

Un kernel qui "casserait" le bios, là franchement ça devient du délire.
C'est du hardware, il faut "flasher" la ROM pour le modifier et faudrait
imaginer des programmeurs linux particulièrement fous pour se lancer
dans ces procédures qui sont étroitement liées au matériel et de la
seule responsabilité des constructeurs.

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é).

Pour le reste, changer de noyau sans raison par un plus récent ne
garanti pas que de nouveaux bugs pires que ceux qu'on essayent de
corriger aient été introduits.

Encore une fois, un débutant devrait rester sur une version "stock" de
la version stable (if any) de la distribution de son choix et au fur et
à mesure de sa meilleure compréhension du système tenter des expériences
(on n'apprend que par ses erreurs). C'est en se sortant lui même, à force
de lecture de man pages, des erreurs commises que l'utilisateur
progresse.

Par contre venir se plaindre ici ou relater des histoires de drivers à la con
dont tout le monde se contrefout ne présente aucun intérêt sinon de
faire du "moi je" comme le fait M. Michu lorsqu'il expose sur Internet les
photos de son chien ou de sa femme à la plage (la différence est souvent
ténue).

Un peu comme si Madame Michu expliquait sur fr.rec.bricolage qu'ayant
chier à coté des toilettes elle trouve dommage que jacob Delafon n'ait
pas prévu le cas et que le cas ne lui était jamais arrivé avec un
chiotte Porcher (tout en oubliant de préciser qu'elle n'a jamais chier à
coté lorsqu'elle utilisait un Porcher).

Bref on nage en pleine médiocrité, et plutôt la partie basse de la
moyenne.

--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

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. Mais le point important
dans ce que tu signales c'est le "rapidement corrigé". 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".

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é.

Certes, je respecte la volonté d'apprendre et de progresser, mais là je
trouve que la méthode est très lourdingue...

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.

--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

Le 07/12/2018 à 12:13, denis.paris a écrit :

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. Mais le point important
dans ce que tu signales c'est le "rapidement corrigé". 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".

Par rapport à tous les bugs possibles sous Linux que j'ai lu sur les
forums, sur internet en général, je suis très très loin d'avoir eu tous
les bugs possibles, il y en a des milliers et des milliers, c'est facile
à trouver sur le net, et sur des kernel en version STABLE, pas bêta...
La question est plutôt l'inverse : quand il y a des milliers de bugs
possibles rien que sur les kernels en version STABLE (je ne parle même
pas des bêta, ça ce serait normal que ce soit truffé de bugs), n'est-il
pas normal en faisant des tests que parfois on tombe sur un bug ?
Je ne vois pas ce qu'il y a de choquant en testant, de tomber sur un bug
de temps en temps parmi des milliers possibles que l'on peut constater
sur le net.
Pour le rappel, je n'ai jamais utilisé un seul kernel en version bêta,
que des kernels en version STABLE, et qui ont déjà eu pas mal de
corrections (insuffisantes parfois, la preuve, il existe des milliers de
cas de figures de bugs rapportés sur le net, il faut être aveugle ou
être dans le déni pour ne pas vouloir le voir).
Cela dit, quand on utilise un kernel que l'on sait stable (par
expérience, par usage pendant un certain temps) pour sa machine, il n'y
a pas plus de problème qu'un autre système, mais pour cela, il faut
avoir essayé différents kernels pendant un certain temps, pour savoir
lesquels sont effectivement plus stables ou moins buggés pour notre machine.
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com