|
|
|
|
Hello, je pose la question parce que j'ai eu une erreur bizarre sous
kubuntu 18.10, après avoir changé de kernel (à 4.18.20) tout semblait aller bien, puis avant hier, une erreur de lecture sur le disque, cela a commencé par thunderbird qui était soi-disant lancé quand j'essayais de le lancer, mais pourtant absent dans le gestionnaire de tâche, et impossible de basculer dessus, ensuite en redémarrant, système planté, kernel impossible à charger, une erreur de lecture, et je me retrouve en ligne de commande sous "busybox", je tape help pour voir les commmandes puis je ne sais plus quelle commande (je crois que c'était fsck, qui m'avait été suggéré lors du message d'erreur) qui a corrigé les erreurs de partition sur le disque, puis j'ai pu lancer le système. J'ai remis le kernel 4.18.0-11 (d'origine), mais l'erreur s'est reproduite plus tard, application thunderbird impossible à lancer, système à nouveau planté au redémarrage, le kernel d'origine non plus ne se lançait pas et il y avait une erreur sur le disque. Est-ce possible que le changement de kernel avec ukuu foute le boxon dans le système de fichiers ? En attendant j'ai tout reformaté et mis xubuntu 18.10, et je suis sous kernel 4.18.0-12 (kernel de la distribution, mis à jour par l'OS), depuis hier, pas de problème pour le moment, mais bon j'ai pas testé de changement de kernel avec ukuu. |
|
|
Je crois que tu fais preuve d'un sacré niveau! Tu as un talent
hors-norme pour attirer les pannes. On se croirait sur un forum Windows... Mais dans le monde linux, je n'ai jamais vu un utilisateur provoquer autant de catastrophes! |
|
|
Le 05/12/2018 à 16:35, Pierre a écrit :
[..] > Est-ce possible que le changement de kernel avec ukuu foute le boxon dans le système de fichiers ? > En attendant j'ai tout reformaté et mis xubuntu 18.10, et je suis sous kernel 4.18.0-12 (kernel de la distribution, mis à jour par > l'OS), depuis hier, pas de problème pour le moment, mais bon j'ai pas testé de changement de kernel avec ukuu. avec quel filesystem ? si c'est ext4 possible |
|
|
Le 05/12/2018 à 18:50, denis.paris a écrit :
> Je crois que tu fais preuve d'un sacré niveau! Tu as un talent > hors-norme pour attirer les pannes. On se croirait sur un forum Windows... > Mais dans le monde linux, je n'ai jamais vu un utilisateur provoquer > autant de catastrophes! Je teste, c'est tout, après c'est sûr que si je ne teste rien du tout pour apprendre, la probabilité d'un plantage X ou Y diminue ;) Après la machine fait ce qu'elle a à faire, suite aux tests. Des plantages et bugs, j'en ai vu et testé sous toutes les distributions ubuntu : xubuntu, ubuntu, mate, kubuntu, lubuntu, linux mint... Faire comme si cela n'existait c'est soit ne pas avoir assez testé les différentes options (car il y a des bugs et plantages que je peux reproduire, en ayant compris dans quel contexte ils arrivaient, du coup je peux aussi les éviter quand j'ai compris), soit nier l'évidence. 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 ? Je sais que : - un changement de kernel (même prévu spécifiquement pour la distribution en question, version dite "stable") peut faire freezer le système, ça ne m'est pas arrivé à moi, mais pas plus tard que le 4.15.0-42 j'ai vu que c'est arrivé à quelqu'un pour le dernier noyau de la 16.04 (nota : là je suis linux mint noyau 4.15.0-42 et moi ça ne freeze pas contrairement à ce gars, comme quoi je n'attire pas toutes les pannes, il y en a aussi plein que j'ai vu que je n'ai pas eu ;) ) - un changement de kernel (même prévu spécifiquement pour la distribution en question, version "dite stable") peut couper le wifi, c'est du vu et du vécu Donc il reste à voir si cela peut aussi corrompre le système de partition (si ça fait partie des risques possibles), ce serait bon à savoir. |
|
|
Le 05/12/2018 à 19:05, Philippe Weill a écrit :
> Le 05/12/2018 à 16:35, Pierre a écrit : > avec quel filesystem ? si c'est ext4 possible > > Je crois bien que c'était ext4, pourquoi, il y a un problème en particulier avec ext4 ? Sinon, merci, info très intéressante, je vais éviter de tester trop longtemps la 4.19 du coup... ;) J'avais testé la 4.19.6 et à court terme je n'avais pas eu de problème, mais qui sait, c'était pareil pour la 4.18.20 sur laquelle je suis resté un peu plus longtemps pour voir, puis ensuite, il y a eu ce problème de corruption de la partition (en faisant rien de spécial en dehors de ça), et ce problème de corruption s'est répété post test kernel plus élevé alors que pendant de nombreux jours avant sous kubuntu 18.10, pas de problème, donc il y a peut-être un rapport. Peut-être que la 4.18.20 est touchée aussi par ce bug a?éatoire (vu que c'est pas arrivé de suite, le 2ème ou 3ème jour sous ce kernel). |
|
|
Le Wed, 05 Dec 2018 18:50:18 +0100, denis.paris a écrit :
> Mais dans le monde linux, je n'ai jamais vu un utilisateur provoquer > autant de catastrophes! C'est lui la vraie catastrophe ! |
|
|
Le 05/12/2018 à 19:49, Christophe PEREZ a écrit :
> Le Wed, 05 Dec 2018 18:50:18 +0100, denis.paris a écrit : >> Mais dans le monde linux, je n'ai jamais vu un utilisateur provoquer >> autant de catastrophes! > C'est lui la vraie catastrophe ! C'est pas moi le fautif, c'est juste que je teste, après, la machine fait ce qu'elle a à faire, c'est pas ma faute si par exemple un kernel dit "stable" peut corrompre un système de partition (ça c'est moi sous kubuntu 18.10), freezer un système (ça c'est pas moi, mais j'ai vu en cherchant dans google que c'est arrivé à quelqu'un qui a simplement mis son système avec le kernel 4.15.0-42, alors que là par exemple je suis le même kernel avec linux mint et j'ai aucun freeze ou plantage du système, lui ça a été direct, donc c'est une catastrophe aussi ce gars ?), ou couper le wifi (arrivé lors d'une mise à jour de kernel dit "stable" aussi, et c'est pas arrivé qu'à moi, j'ai vu sur google que c'est arrivé à plein de gens aussi, ce sont tous des catastrophes alors ???). Toi tu parles toujours pour rien, comme d'habitude, jamais de discussion sur le fond des questions. Philippe au moins, a fait une réponse très intéressante, et je l'en remercie : "avec quel filesystem ? si c'est ext4 possible https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-EXT4-Issue-Likely-MQ" Maintenant arrête de faire la sainte nitouche, des plantages et bugs sous linux, quelque soit la distribution, il en existe des milliers de possibles, j'en ai constaté sous toutes les distributions testées, à différents degrés, personnellement, mais SURTOUT, en cherchant un peu, j'ai vu des centaines et centaines de gens qui ont eu des plantages et bugs que je n'ai pas eu... Ce sont tous des catastrophes alors si on suit ton raisonnement. Peut-être à un moment, il faut accepter qu'aucun kernel n'est parfait et aucune distribution n'est parfaite, et ne pas toujours vouloir rejeter la faute sur moi dès qu'en faisant un test X ou Y, on constate une possibilité de bug. Quand quelqu'un teste et découvre un bug (qu'il peut reproduire par exemple, en refaisant la même chose, puisque j'en ai découvert que je peux reproduire une fois que j'ai compris comment), le fautif c'est celui qui découvre le bug ou celui qui a programmé la chose et qui a fait que cela bugge dans tel cas de figure ? |
|
|
Le 05/12/2018 à 19:30, Pierre a écrit :
[..] > Donc il reste à voir si cela peut aussi corrompre le système de > partition (si ça fait partie des risques possibles), ce serait bon à > savoir. Bon, Philippe a donné la réponse, oui un kernel peut avoir ce problème, et pas plus tard que les kernels très récents dits "stables" (j'ai testé un kernel très récent, classé dans les "stables") : "avec quel filesystem ? si c'est ext4 possible https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-EXT4-Issue-Likely-MQ" |
|
|
Le 05/12/2018 à 20:14, Pierre a écrit :
> Le 05/12/2018 à 19:30, Pierre a écrit : > Bon, Philippe a donné la réponse, oui un kernel peut avoir ce problème, > et pas plus tard que les kernels très récents dits "stables" (j'ai testé > un kernel très récent, classé dans les "stables") : > "avec quel filesystem ? si c'est ext4 possible > > https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-EXT4-Issue-Likely-MQ" Christophe Perez t'as vu ? Un kernel peut effectivement avoir ce problème, ce n'est en aucun cas ma faute si un kernel récent dit "stable" a éventuellement ce bug. Toi qui aimes bien te mêler de mes conversations. |
|
|
Le 05/12/2018 à 19:37, Pierre a écrit :
[..] > problème, donc il y a peut-être un rapport. > Peut-être que la 4.18.20 est touchée aussi par ce bug a?éatoire (vu que > c'est pas arrivé de suite, le 2ème ou 3ème jour sous ce kernel). Je comprends mieux ce qui a pu se passer, comme tous les kernels 4.19 ont ce bug : "All 4.19 kernels have filesystem corruption under memory pressure, upstream is doing triage " Le fait d'avoir testé le kernel 4.19 peut avoir endommagé le système de fichiers, et le problème s'être révélé plus tard, en étant de nouveau sous kernel 4.18.20 puis 4.18.0-11, le système de fichiers étant déjà corrompu par le test du kernel 4.19, c'est une possibilité. Nota : cette possibilité de corruption du système de fichiers ne m'était jamais arrivé en plus d'un an de tests divers sous linux, c'est vraiment spécifique. |
|
|
Le 05/12/2018 à 19:37, Pierre a écrit :
[..] > problème, donc il y a peut-être un rapport. > Peut-être que la 4.18.20 est touchée aussi par ce bug a?éatoire (vu que > c'est pas arrivé de suite, le 2ème ou 3ème jour sous ce kernel). En cherchant un peu, je vois que des problèmes sur les données du disque, avec une version de kernel, c'est pas nouveau : J'avais tourné au début sous kernel 4.10 (via linux mint), mais je n'avais pas eu ce problème, je découvre que ce n'est pas la 1ère fois que cela peut arriver donc, qu'un kernel cause des problèmes sur le système de fichiers voire sur des fichiers directement. Rien de nouveau en fait, si on fait la bonne recherche : Au hasard : "Software errors in the kernel can also cause file system corruption." |
|
|
Le 05/12/2018 à 20:17, Pierre Aribaut.com a écrit :
> Christophe Perez t'as vu ? Un kernel peut effectivement avoir ce > problème, ce n'est en aucun cas ma faute si un kernel récent dit > "stable" a éventuellement ce bug. > Toi qui aimes bien te mêler de mes conversations. Pas conversations, monologues! |
|
|
Le 06/12/2018 à 08:51, Michel a écrit :
> Le 05/12/2018 à 20:17, Pierre Aribaut.com a écrit : >> Christophe Perez t'as vu ? Un kernel peut effectivement avoir ce >> problème, ce n'est en aucun cas ma faute si un kernel récent dit >> "stable" a éventuellement ce bug. >> Toi qui aimes bien te mêler de mes conversations. > Pas conversations, monologues! Bah non, puisque déjà 4 personnes ont répondu sur ce topic, denis, christophe, philippe et toi... ;) |
|
|
Le 06/12/2018 à 09:39, Pierre a écrit :
> Le 06/12/2018 à 08:51, Michel a écrit : > Bah non, puisque déjà 4 personnes ont répondu sur ce topic, denis, > christophe, philippe et toi... ;) Oui mais bon, en ce qui me concerne, je trouve ce fil, que j'ai parcouru en diagonal, complètement délirant. Tu me fais penser à un type qui lance sa voiture à 100 km/h contre un mur en béton, et après vient mesurer la longueur de la caisse et trouve une valeur inférieure de moitié à celle donnée par le constructeur... et puis est-ce normal si le moteur est à la place du conducteur? Y-a un bug! |
|
|
Le 06/12/2018 à 09:53, denis.paris a écrit :
> Le 06/12/2018 à 09:39, Pierre a écrit : > Oui mais bon, en ce qui me concerne, je trouve ce fil, que j'ai parcouru > en diagonal, complètement délirant. Tu me fais penser à un type qui > lance sa voiture à 100 km/h contre un mur en béton, et après vient > mesurer la longueur de la caisse et trouve une valeur inférieure de > moitié à celle donnée par le constructeur... et puis est-ce normal si le > moteur est à la place du conducteur? Y-a un bug! Heu...tout ça juste pour avoir testé un kernel différent de la branche "stable" ? C'est si dangereux que ça de tester un autre kernel ? Comme lancer sa voiture à 100 km/h contre un mur ? Hé ben... |