samedi 04 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Articles

Liens connexes

daPatch (832 hits)

Dépêche modérée par

orebokech

Articles : Kernel 2.4.15/2.5.0 buggé. Attention !

Posté par woof (). Modéré le 24 novembre 2001.

"Using 2.4.15/2.5.0 can result in file system corruption due to a mishandling of dirty inodes. sync before unmounting and use a kernel prior to 2.4.15-pre9."

En gros ça dit que le 2.4.15/2.5.0 contient un bug dans la gestion des "sales inodes", et qui peut résulter dans un filesystem corrompu.

~~Ils recommandent de repasser en 2.4.15-pre9 le temps que le patch soit intégré aux sources du kernel.~~

Update du modérateur : l'auteur de la news originale s'étant trompé, je corrige : le bug étant apparu dans le 2.4.15-pre9, il faut utiliser un kernel antérieur, donc un 2.4.15-pre8.

daPatch (832 hits)

> Lire les commentaires (49 commentaires, moyenne: 1).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Aie...

Posté par the_freeman () le 24/11/2001 à 09:46. (lien). Évalué à 1.

Il était temps que Linus ouvre la branche des 2.5.x, cela permettra peut être de mieux tester les noyaux et de ne pas voir des bugs comme celui-ci apparaitre dans une version dite stable du noyaux.

Il n'y avait pas déjà un bug du même genre dans dans le 2.4.12 ?

[^]Re: Aie...

Posté par kalahann () le 24/11/2001 à 10:30. (lien). Évalué à 1.
Bah y'avait pas que le 2.2.12.
2.2.10: nouvelle VM (le pire c'est que celui-là marchait à peu près!)
2.2.11 labellé "dontuse", peut corrompre le fs, no comment
2.2.12 le port parallèle ne compile pas2.2.15 encore une corruption possible du fs, rien que ça!

Mais en fait le bug du 2.4.15/2.5, c'est fait exprès. C'est juste pour bizuter Marcelo Tosseti!
- [^]Re: Aie...
  
  Posté par Anonyme () le 24/11/2001 à 11:47. (lien). Évalué à 1.
  s/2\.2/2.4/g
  - [^]Re: Aie...
    
    Posté par matiasf () le 24/11/2001 à 14:25. (lien). Évalué à 1.
    Des utilisateurs "sed" parlent aux utilisateurs "sed" (marche peut-être avec ed aussi?).
    
    s/2\.2/2.4/g :
    çà veut dire remplacer toute les occurences de la chaine "2.2" par "2.4".
    
    Glandium essai d'élargir ton public. Surtout pour dire des trucs aussi simple.
    
    PS: t'es pas le seul à faire une sorte d'"élitisme".
    - [^]Re: Aie...
      
      Posté par Frédéric Massot (page perso, ) le 24/11/2001 à 15:00. (lien). Évalué à 1.
      ça fonctionne aussi avec vi :
      
      Echap
      :1,$s/2.2/2.4/g
      - [^]Re: Aie...
        
        Posté par miod () le 24/11/2001 à 15:38. (lien). Évalué à 1.
        Certes, mais l'intervalle 1,$ peut etre avantageusement remplace par %.
        
        Donc :
        :%s/2\.2/2.4/g

[^]Re: Aie...

Posté par Alphonse Oncle () le 24/11/2001 à 11:55. (lien). Évalué à 1.
Je pense qu'ils font du mieux qu'ils peuvent.
Au pire si tu es un peu prudent et que tu installes pas en prod le dernier noyau (certes dit stable) dans l'heure qui suit sa sortie mais que tu attends un jour ou deux ca doit limiter deja le risque.

[^]Re: Aie...

Posté par Frederic Logier () le 24/11/2001 à 12:25. (lien). Évalué à 1.
Ne connaissant pas la gestion des kernels, je me demande pourquoi la branche instable n'est pas ouverte en meme temps que le branche stable ?!

Si la branche 2.5 était sortie en meme temps que la 2.4, ils pourraient développer sur la 2.5 et ensuite intégrer en 2.4 une fois testé un minimum.

Ca me semble tellement simple qu'il doit me manquer une info sur le fait qu'ils ne font pas ceci...

Et dire qu'il n'y a pas assez de gens pour tester les branches impaires, me semble un peu gros... si c'est pour cette raison, pourquoi les gens testeraient plus la branche 2.5 maintenant ?
- [^]Re: Aie...
  
  Posté par Etienne () le 24/11/2001 à 14:27. (lien). Évalué à 1.
  Parceque il arrive un moment où il faut prendre la décision de passer en version stable pour permettre d'avoir beaucoup plus de rapport de bug. Si tu reste en version instable il n'y a quasiment que les développeurs qui testent le noyau. Il faut donc décider à un moment que le noyau instable est assez stable pour ne pas faire prendre de risques à l'utilisateur mais en sachant que durant quelques mois il va y avoir beaucoup de bugfix à faire.
  
  Une fois que le noyau stable est jugé vraiement au point, on ouvre la branche instable et une personne (ici Marcelo Tosatti) est chargée du maintient de la branche stable.
  
  Bien entendu, pendant la période où il n'y a qu'une branche, il y a beaucoup de développeurs sur celle-ci, donc beaucoup de contributions, ce qui engendre un potentiel de bug plus important et des releases plus fréquentes.
  - [^]Re: Aie...
    
    Posté par Frederic Logier () le 24/11/2001 à 15:27. (lien). Évalué à 1.
    Donc une branche "stable" ne l'est vraiment que quand survient la version unstable ...
    
    Je voyais pas du tout l'organisation comme ça.
    Plutot un kernel 2.4.0 venant d'un 2.3.99 stabilisé.
    Ensuite l'ouverture immédiate d'un 2.5.0 et les développement en masse sur cette branche.
    Avec quelques commit en 2.4
    On se trouverait en 2.5.15 par exemple pour la branche unstable et en 2.4.2 pour la version stable.
    Le grand écart de version et donc de nouvelles possibilités en 2.5.x attirerait une grande partie des gens en unstable...
    A la manière de SID pour Debian qui incorpore les dernières nouveautés au contraire de la woody et encore plus pour la potato.
    
    Une fois que le noyau stable est jugé vraiement au point
    Cela éviterait ce genre de phrase, antinomique...
    
    Enfin je suppose que tout cela a déjà était pensé par la kernel team, mais je ne peux m'empécher de douter quand meme.
    
    <troll>
    au fait openbsd3 sort bientot...
    </troll>
    - [^]Re: Aie...
      
      Posté par Etienne () le 24/11/2001 à 16:48. (lien). Évalué à 1.
      
      Donc une branche "stable" ne l'est vraiment que quand survient la version unstable ...
      
      Disons qu'elle est moins suceptible de voir du nouveau code incorporé ce qui limite l'instabilité.
      
      A la manière de SID pour Debian qui incorpore les dernières nouveautés au contraire de la woody et encore plus pour la potato.
      
      Pas vraiement parceque sur Debian, ils ont en permanence 3 branches. Mais à certains moments l'évolution de la testing se rallentie pour passer en frozen puis en stable. Alors que l'unstable est toujours là pour avoir les dernières versions de soft.
      Et puis il est difficile de comparer le développement d'un noyau avec le packaging de softs que font Debian.
      
      Enfin je suppose que tout cela a déjà était pensé par la kernel team, mais je ne peux m'empécher de douter quand meme.
      
      Je ne pense pas que la kernel team ai pensé cela comme ça, mais cela s'avère le meilleur compromis pour permettre la finalisation du noyau et cela a évidemment des inconvénients.
      
      Enfin maintenant qu'on a une branche 2.5, le 2.4 va continuer à évoluer mais ce sera essentiellement des bugfixes et puis quelques backport du 2.5.
      
      Et puis je me demande pourquoi on fait tant de cas pour un noyau, combien de softs en version stable ont encore des bugs. Et tout le monde sait bien qu'il n'est jamais bon d'avoir les dernières versions de soft sur une machine en prod. Alors serveur Web, serveur SSH, client ssh ou noyau : on ne se précipite pas sur les dernières versions quand on a besoin de stabilité.
      - [^]Re: Aie...
        
        Posté par Frederic Logier () le 24/11/2001 à 17:33. (lien). Évalué à 1.
        mais cela s'avère le meilleur compromis pour permettre la finalisation du noyau et cela a évidemment des inconvénients.
        Je ne vois pas en quoi développer sur kernel dit stable s'avère un meilleur compromis que ce qu'ils ne font, que, maintenant :
        développer sur une branche unstable et intégrer de temps en temps en branche stable.
        Ils devraient y avoir du monde en unstable si les nouveauté sont en unstable (comparaison avec Debian, et qui leur réussi vu le nombre de gens en unstable, si t'as pas compris je compare le principe de dev...).
        Et l'on aura un vrai kernel pair stable, ou tout du moins pas avec les problèmes risibles que l'on a vu...
        
        Le vrai compromis est d'avoir au maximum un kernel en version pair stable. Stable n'est pas intégrer à tout va des nouveautés à peine testées. Et comment peuvent elles etre testé sans branche unstable ..
        Enfin, j'aime pas les langages de sourd et chacun sa vision.
        
        openbsd3 sort bientot... :)
        
        [^]Re: Aie...
        
        Posté par Etienne () le 24/11/2001 à 19:25. (lien). Évalué à 1.
        Ils devraient y avoir du monde en unstable si les nouveauté sont en unstable (comparaison avec Debian, et qui leur réussi vu le nombre de gens en unstable, si t'as pas compris je compare le principe de dev...).
        
        Justement, bien que le principe de dev soit à peu près identique, on ne peut pas comparer. Un noyau en version unstable est beaucoup plus risqué qu'une intégration d'un logiciel non testé dans une distrib. Puisque dans une distrib, ils intègrent des logiciels qui ont été testés par leurs auteurs, et le seul problème concerne les conflits entre packages. D'autre part, sur une Debian, la version stable s'avère très bien sur des serveurs, mais pour une utilisation domestique, on aprécis d'avoir des logiciels plus récents, alors que le kernel stable intègre tout ce dont l'immense majorité des utilisateurs ont besoin.
        
        Le vrai compromis est d'avoir au maximum un kernel en version pair stable. Stable n'est pas intégrer à tout va des nouveautés à peine testées. Et comment peuvent elles etre testé sans branche unstable ..
        Là on est d'accord, dans un version stable l'intégration de nouveau code ne devrait pas avoir sa place. Mais là c'est pas moi qui décide de la politique d'intégration (sinon XFS serait intégré depuis longtemps)
        
        [^]Re: Aie...
        
        Posté par Frederic Logier () le 24/11/2001 à 21:20. (lien). Évalué à 1.
        Un noyau en version unstable est beaucoup plus risqué qu'une intégration d'un logiciel non testé dans une distrib
        un kernel dit stable qui est instable c'est pas pire qu'un kernel dit unstable qui est instable ?
        
        D'autre part, sur une Debian, la version stable s'avère très bien sur des serveurs, mais pour une utilisation domestique, on aprécis d'avoir des logiciels plus récents
        Debian unstable c'est pas fait pour les chiens.
        
        alors que le kernel stable intègre tout ce dont l'immense majorité des utilisateurs ont besoin.
        le kernel dit stable doit etre AVANT TOUT stable avant d'intégrer quoique ce soit.
        
        Là on est d'accord, dans un version stable l'intégration de nouveau code ne devrait pas avoir sa place.
        En pratique ce n'est pourtant jamais le cas. En conséquence il me semble essentiel d'ouvrir la branche impaire au plutot.
        
        Et je te garantie que s'ils intégraient moins rapidement les nouveautés dans la branche stable, il y aurait plus de gens pour tester la branche instable
        exemple tu laisses trainer un peu le support usb en unstable, ou une autre "carotte".
        
        Ca me semble pourtant limpide à comprendre comme résonnement.
        
        Mais là c'est pas moi qui décide de la politique d'intégration
        La politique est peut etre de laisser des distributions avoir une longueur d'avance sur certaines feature des kernels officiels, genre ext3 depuis la Red Hat 7.2 .. Je dis ça mais j'ai rien dis, hein.
        
        [^]Re: Aie...
        
        Posté par Etienne () le 24/11/2001 à 22:25. (lien). Évalué à 1.
        Bon je crois que ca va être mon dernier post parceque on fait pas trop avancer le schmilblik.
        
        Mais c'est juste pour préciser qu'on gueule sur l'instabilité du kernel mais que depuis le début, tous les bugs critiques ont été relevés moins de 24heure après la sortie du noyau. Alors certe le noyau aurait dû etre d'avantage testé mais : d'une part tout le monde sait qu'on ne se jette pas sur un nouveau noyau dès sa sortie juste pour pouvoir dire qu'on a le dernier. D'autre part je ne crois pas qu'on puisse dire de la branche 2.4 qu'elle est instable si l'on tiens compte du fait que les solutions des problèmes critiques sont trouvées dans les 24 heures.
        
        [^]Re: Aie...
        
        Posté par Frederic Logier () le 24/11/2001 à 22:40. (lien). Évalué à 1.
        heu déjà je gueule pas, je ne comprend pas leur gestion des kernels c'est tout.
        
        Donc oui c'est pas très grave au fond ; il ya les 2.2.x ...
        
        et surtout openbsd3 sort le 1 décembre ... :)

il court il court le kernel

Posté par mcjyc (page perso, ) le 24/11/2001 à 09:49. (lien). Évalué à 1.

ne trouvez vous pas que le kernel evolue trop vite ces derniers temps ?

le changements de VM il y a peu, qui aurait tres bien pu, à mon avis, attendre la version 2.5

et une version dite "stable" avec un tel probleme...

je suis ravi de voir que le patch sorte si vite, mais cela ne signifierait il pas qu'il pourrait etre plus sage de ralentir un peu la cadence ?

[^]Re: il court il court le kernel

Posté par the_freeman () le 24/11/2001 à 09:57. (lien). Évalué à 1.
La cadence devrait être moins rapide maintenant que la branche des 2.5.x est ouverte. Espérons avoir des noyaux stables réellement stables !
- [^]Re: il court il court le kernel
  
  Posté par Maxime () le 24/11/2001 à 10:38. (lien). Évalué à 1.
  c'est discutable ... après avoir lu "The Cathedral And The Bazaar" (dispo online, cf Google) de Eric S. Raymond , on comprend mieux ce qui pousse les développeurs du noyo à sortir rapidement toutes ces nouvelles versions... Linus T. a toujours procédé de la sorte et il semblerait que ça ne lui ait pas trop mal réussi :-)
  Dans tous les cas, lisez The Cathedral And The Bazaar !
  - [^]Re: il court il court le kernel
    
    Posté par zeiram () le 24/11/2001 à 23:22. (lien). Évalué à 1.
    >Dans tous les cas, lisez The Cathedral And The Bazaar !
    
    Pour tous ceux que ce texte intéresse, voici un lien vers la page de ESR où l'on peut le trouver (ca évitera une recherche Google à certains) :
    http://tuxedo.org/~esr/writings/(...)
    - [^]Re: il court il court le kernel
      
      Posté par kadreg () le 25/11/2001 à 09:41. (lien). Évalué à 1.
      Et ceux qui ne parlent pas anglais, il a été traduit en français par par Sébastien Blondeel :
      
      http://www.linux-france.org/article/these/cathedrale-bazar/cathedra(...)
  - [^]Re: il court il court le kernel
    
    Posté par Jerome (page perso, ) le 25/11/2001 à 12:04. (lien). Évalué à 1.
    Je ne suis pas d'accord avec cette politique de sortir le plus vite possible un patch, ou ajouter n'importe qu'elle fonction sans l'avoir bien testé.
    Les correctifs rapides et les nouvelle fonctionnalités sont à inserer dans le noyau en développement. La branche stable est faite pour être stable et rien d'autre. Donc elle doit être testé à fond.
    Rien de plus chiant quand tu as un problème de le corriger et d'en ajouter un nouveau. Quand tu as identifier un bug, au moins tu sais pourquoi ça pète et tu ne cherche pas plus loin. Mais si tu installe un noyau qui doit te corriger le bug, mais qui t'en ajoute un autre alors tu reviens au point de départ, avec un nouveau bug.
    
    Ca ne sert à rien de sortir rapidement un patch sans le tester. Mais maintenant que la branche 2.5.0 est ouverte on ne devrait plus avoir de pb, enfin j'espère ...

[^]Re: il court il court le kernel (et alors, t'es pas content ?)

Posté par Frédéric RISS () le 24/11/2001 à 10:18. (lien). Évalué à 1.
Arrêtez donc de critiquer le développement du noyau ! Une release du noyau correspond à un snapshot des sources à un moment donné. Il peut arriver qu'un patch introduise un bug à ce moment donné. La revue de code qu'effectue Linus à beau être très importante, il ne peut pas tout voir ! Si au lieu de critiquer vous participez au développement. Non mais c'est vrai quoi ! Le noyau avance vite et vous devriez plutôt être content de cet état de fait. Si vous voulez un noyau stable utilisez donc les derniers 2.2 qui eux ne vous poserons pas de problèmes...

bon, -1 parce que j'aime pas les gens qui critiquent et là j'en fait partie
- [^]Re: il court il court le kernel (et alors, t'es pas content ?)
  
  Posté par mcjyc (page perso, ) le 24/11/2001 à 10:29. (lien). Évalué à 1.
  comme si une critique ne pouvait pas etre constructive ?
  je suis d'accord avec toi, et je me rejouis de voir l'arrivée du 2.5.0
  je suis d'accord qu'avec le systeme de developpement, il y est des bugs qui se glissent dans le noyau.
  mon propos etait le suivant : pourquoi ne pas trainer un peu plus en -pre9 ou -preN
  avant de passer en 2.4.15
  ca ne coute rien à ce que je sache ?
  et ca eviterait tres surement ce genre de chose.
  
  quand à la critique sur le developpement, il vaut mieux pour le kernel que je n'y touche pas.
  je suis un pietre developpeur.
  tout ce que je peux apporter au monde de linux, c'est de le faire decouvrir à ceux qui ne le connaisse pas, et apporter mon aide qui le decouvre.
  
  et j'aime par dessous tout dans le monde du logiciel libre, pouvoir apporter mon opinion, pour qu'on discute, sans qu'on demande gentillement de ne pas m'exprimer parce que " si on ne parle pas d'un probleme, il n'y a pas de probleme"
  
  cordialement,
  
  dunain dit "jyc" aussi
  - [^]Re: il court il court le kernel (et alors, t'es pas content ?)
    
    Posté par Frédéric RISS () le 24/11/2001 à 10:50. (lien). Évalué à 1.
    Franchement, je ne critiquais pas ta remarque en particulier... Il y a juste que ça m'insupporte qu'à chaque bug découvert dans le noyau tout le monde s'exclame : « Quelle honte dans un noyau dit stable ! »
    Ca a toujours été comme ça... Les premières version d'une série stable nécessite toujours du développement, jusqu'à l'ouverture de la branche alpha suivante, et je te rejoins sur ce point, l'arrivée du 2.5 est une bonne chose.
    Il n'empêche que trainer un peut plus sur les pre ne modifieras peut-être rien à l'affaire étant donné que le dernier patch est toujours succeptible d'amener un nouveau bug (une solution consisterais à figer le dev du noyau avant un release, mais cela entraînerais des retards, et personne ne le veut).
    A mon avis, celui qui utilise le dernier noyau (même d'une branche stable) doit s'attendre à trouver un problème et ne pas s'en étonner. C'est d'ailleurs pour ça que la série 2.2 est toujours maintenue, pour pouvoir utiliser une version testée exhaustivement...
- [^]...et alors, t'es pas content ?(et pourquoi tu l'agresses ?)
  
  Posté par F C () le 24/11/2001 à 10:51. (lien). Évalué à 1.
  Hum...
  
  Pour te répondre directement, il est normal qu'il y ait des bugs, il est par contre difficile de laisser passer certains types de bugs, ceux concernant la VM ou le FS, sujets SENSIBLES s'il en est, devraient faire l'attention de tous les soins.
  
  Or, l'augmentation des patchs et des releases est bien réelle depuis 4 mois.
  
  Le nombre de bugs et son suivi prend une certaine ampleur (bien que non-abonné à la KML ! Soit c'est LinuxFr, soit il y a une réelle augmentation des bugs !), dans une proportion qui tendrait plutôt à nuire ) à la performance globale du noyau
  La cause évidente:
  * guerres des tranchées entre AC,LT,...( c'est sûr, on le sait)
  qui a pour conséquence un problème de gestion des developpements - au sens projet du terme -.
  
  Parce que quelques bugs, c'est normal, trop de bugs c'est mal testé/débuggué, trop de bugs trop longtemps, c'est le signe que la coordination ne fonctionne pas, et la coordination... c'est la clef du succés.<- expression - je ne suis pas un décideur qui veut faire du fric ! :)
  
  La communautée Linux est certes immense et volontaire, mais tant de bonnes volontés ne doivent pas se disperser faute d'un malaise au sommet. Je ne remets pas en cause la compétence de notre communauté - je reprécise pour ceux qui interpretent ! - mais le fait que ce point-là est peut-être trop délicat pour pouvoir se passer de coordination entre les développeurs.
  
  On est déjà les meilleurs, mais un fédérateur nous aidera a l'être encore plus !!
  
  <troll>
  Poll: WhO Su><><>< mOrE: LiNuS oR aLaN ?
  </troll>
  
  --
  Salut, tu browses à combien, toi ?
  - [^]Re: ...et alors, t'es pas content ?(et pourquoi tu l'agresses ?)
    
    Posté par Frédéric RISS () le 24/11/2001 à 12:11. (lien). Évalué à 1.
    Je ne suis pas du tout d'accord avec toi... ce que tu considères comme des faiblesses, moi je trouve que c'est une force.
    On l'a bien vu avec le changement de VM ; les deux versions ont pu être testées en parallèle et améliorées en parallèle. Il y a eu une concurrence extrêmement saine entre les 2 développeurs. Aujourd'hui, tout le monde s'accorde pour dire que c'est la meilleure VM qui a gagné, et les gens sont bien content de l'avoir...
    Depuis toujours les premiers noyaux des branches dites « stables » ont eu besoins de grosses corrections. Si on voulait éliminer les bugs, la solution serait de sortir un noyau stable tous les 6 mois, mais ça non plus personne n'en veux, car le développement s'enliserait.
    Bref, la où tu veux de l'homogénéité, moi je réclame des divergences d'opinions et de la concurrence comme il y en a eu.

[^]evolution !

Posté par Samuel Pajilewski () le 24/11/2001 à 10:35. (lien). Évalué à 1.
En effet il cour le Kernel ! et c'est normal !

La branche 2.4 est sortie en Janvier 2001, et on a eu 16 releases en 11 mois : Il faut que la branche 2.4.x se stabilise !

Ce fut le meme probleme avec le 2.2.x : il a fallut attendre le noyau 2.2.13 pour pouvoir l'utiliser sans soucis...

Si tu veux qqchoses de stables, sans soucis, achte une distrib complete, un noyau telechargé comporte toujours des pb, qui sont corrigés dans les distribs.

Linux passe une periode cruciale : Face à Win XP et Mac OS X, il doit se demarquer, c'est pour cela qu'il evolue tres vite (non mais faite la difference entre le noyau 2.2.13 et 2.4.15 !, et faites la difference entre Mandrake 6.1/8.1, SuSE 6.2/7.3, Redhat 5.2/7.2 !)

C'est un peu comme KDE et Gnome on avait un KDe 1.x stable, nickel, presuqe sans bugs, et quand on est passé au KDE 2.x on a eu plein d'emmerdes, pourtant, avec l'arrivée recente de KDE 2.2.2, on regrette pas KDE 2.x, avec toutes ses ameliorations et son nouveaux Look : on en bavera avec KDE 3.x jusqu'a une release enfin finie !

Idem pour Netscape 6.x/ Mozilla : rappelez vous Netscape 6.0 et Mozilla M18 : tout le monde avait dit que le projet Mozilla et Netscape allaient mourir, pourtant quand on voit Netscape 6.2 et Mozilla 0.9.6 on reprend vite des couleurs, meme si il y a encore du boulot !

Maintenant, on peut aider ces projets dans la mesure de nos moyens : j'aimerai bien contribuer directement au code, mais mes capacités intellectuelles limites en info ne me le permmettent pas ! Donc j'envoies des FeedBack (rapports de Bugs) a Kernel.org, Mozilla, Netscape, KDE ou Gnome.

C'est bien beau de gueuler, mais faut faire avancer le Schmilblik...
- [^]Re: evolution !
  
  Posté par mcjyc (page perso, ) le 24/11/2001 à 10:58. (lien). Évalué à 1.
  tu vois quelqu'un gueuler ?
  ce que je dis n'est pas incompatible avec ce que tu dis.
  
  Tu dis que maintenant, linux doit se demarquer, et que c'est une periode cruciale pour le noyau.
  c'est clair, et je suis d'accord avec toi.
  Qu'il doit evoluer, et toujours aller de l'avant, sans soucis.
  on joue dans la meme equipe.
  mais se demarquer comment ?
  imagine cette nouvelles publiés sur un site de microsoft " le nouveau kernel stable linux corrompt votre systeme de fichier !"
  la, on se fait marquer en touche.
  
  on l'aime tous le noyau. mon propos etait juste le suivant: le noyau sort, et le lendemain, le patch sort pour corriger un bug tres important.
  
  cela n'aurait pas valu la peine d'attendre un jour ou deux ? et eviter ce genre de publicité ?
  
  la periode est cruciale ?
  ok, soyons exemplaire !
- [^]Re: evolution !
  
  Posté par matiasf () le 24/11/2001 à 14:37. (lien). Évalué à 1.
  Je t'appuis à fond !
  
  Sourtout, il ne faut pas oublier le boulot des distributions qui sont la pour fournir un environnement sans bug. Si tu "tapes" dans la dernière version de Linux tu prends des risques (moindre avec un x.y.z (y pair) qu'avec un x.y.z (z pair).
  
  La RedHat 7.2 est fournie avec un 2.4.7 (2.4.9 avec errata) car RedHat à largement testé/audité ce noyau.
  Autre exemple, la ditrib RedHat haute-disponibilité est basé sur un 2.2.19 !
  Pour le boulot, je prend un noyau uniquement fourni par RedHat. Je fait de même pour la partie serveur (apache/php, etc...) car au boulot je n'ai pas envis de mettre un truc risqué.
  Pour un usage perso, je m'amuse un peu plus :-).
  
  Intégré des logiciels critiques prend du temps...
  
  PS: je parle de RedHat car j'utilise RedHat. Je ne critique pas les autres...
  - [^]Re: evolution !
    
    Posté par Pascal Terjan (Jabber id, page perso, ) le 24/11/2001 à 14:56. (lien). Évalué à 1.
    moindre avec un x.y.z (y pair) qu'avec un x.y.z (z pair).
    tu aurais mis y impair au deuxieme j'aurais compris, mais la je vois pas. (et je pense pas que ce soit une faute de frappe puisque dans la suite tu justifie que RedHat ait mis un 2.4.7 par de nombreux tests...)
    - [^]Re: evolution !
      
      Posté par matiasf () le 24/11/2001 à 15:43. (lien). Évalué à 1.
      Désolé, c'est une faute de frappe.
      Il faut lire :
      "moindre avec un x.y.z (y pair) qu'avec un x.y.z (y impair).
  - [^]Re: evolution !
    
    Posté par Okki (page perso, ) le 24/11/2001 à 15:53. (lien). Évalué à 1.
    Dans x.y.z c'est le y qui compte et qui doit être pair pour une stabilité relative. Le z (sublevel), qu'il soit pair ou impair n'a aucune importance

Pas de bol

Posté par Neryel () le 24/11/2001 à 10:34. (lien). Évalué à 1.

Premiere fois que je me recompile un kernel, et il est buggé :-)

Sinon, une petite question sur les numéros de version : ils incrémentent de 0.0.1 quand ils estiment que c'est stable, ou parce que c'est pre9 ?

[^]Re: Pas de bol

Posté par Christophe Fergeau () le 24/11/2001 à 10:50. (lien). Évalué à 1.
Y a une incrémentation de 0.0.1 quand Linus estime que le noyau est stable. Cependant, il fait des fois des boulettes, nul n'est parfait, ca fait plusieurs fois dernièrement qu'il y a des noyaux un peu bugges qui sortent.
Les numéros après les pre ne correspondent pas à grand chose, ca permet juste de suivre la progression. Tu peux très bien avoir uniquement pre1, pre2 et pre3 avant une nouvelle version, ou bien ca peut éventuellement aller jusqu'à pre12 ou plus

[^]Re: Pas de bol

Posté par woof () le 24/11/2001 à 10:52. (lien). Évalué à 1.
le numéro de version augmente qd les -prex ont bien étés testés et que c'est sensé etre stable ..

Parfois .. y'a des kwak (pas des coin, non)

Kernel stable buggé

Posté par Gilles Denat () le 24/11/2001 à 10:43. (lien). Évalué à 1.

C'est quand meme etrange que des kernels dit "stables" comme le 2.4.10, 2.4.11, 2.4.15 soient buggés à ce point : surtout que l'annonce du bug intervient pratiquement le lendemeain de leur sortie. Je n'ai pas souvenir que ce soit arrivé avec les 2.2 . Ni y a-t-il tout simplement pas assez de testeurs pour les pré-versions, ce qui conduirait à sortir des kernels stables "pas tout à fait finis" ? D'autant plus que lors de la phase de stabilisation du 2.4.0, Linus avait lancé un appel pour qu'il y ait plus de testeurs (de facon à ce que la branche stable le soit vraiement), mais peut cet appel n'a pas été suivit...

[^]Re: Kernel stable buggé

Posté par Schwarzy () le 24/11/2001 à 10:57. (lien). Évalué à 1.
Je n'ai pas souvenir que ce soit arrivé avec les 2.2 .

oh que si !!! y'a aussi eu des versions vites jetées aux orties. comme la 2.2.1 qui avaient un exploit pour avoir l'acces root. Et j'ai souvenir d'une ou deux releases qui corompaient le file system (désolé j'ai pu les versions en têtes).

bref, la stabilisation des noyaux a toujours été un processus difficile.
et pour info la branche "stable" veut dire stabilisation des fonctionnalités (même si parfois il faut rejeter une partie comme la VM dans la 2.4) et chasse aux bugs. la branche "instable", c'est l'ajout de fonctionnalités aux prix d'une "stabilité" réduite.

[^]Re: Kernel stable buggé

Posté par fantomaxe (page perso, ) le 24/11/2001 à 11:39. (lien). Évalué à 1.
Il est certain que le fait de ne pas avoir eu de branche de développement (mais maintenant c'est reglé) et le rythme de sortie des noyaux ces derniers temps est une barrière psychologique pour des gens comme moi qui attendent les noyaux +0.0.1
De plus je ne crois pas vraiment être à la hauteur pour un debugage de kernel.

Le problème est - je crois que Linus l'avait dit lui même quelque part lors de la sortie de kernel 2.4 - qu'au bout d'un moment ce sont toujours les mêmes gens qui testent les mêmes choses. Le meilleur moyen de découvrir les bugs restants - lorsque les développeurs ne trouvent plus rien - est de le déclarer "stable" et donc d'utiliser ce kernel.
Tout ça n'est pas si dramatique, pour une utilisation professionnelle on utilisera de toute façon (en général) un kernel fourni et éventuellement patché et retesté par la distribution qui est rarement le dernier noyau sorti il y a 10 jours.

[^]Re: Kernel stable buggé

Posté par RoX ... () le 24/11/2001 à 11:51. (lien). Évalué à 1.
Apres avoir lu les commentaires ici present, je voudrais apporter un petit bemol la dessus .

Beaucoup grogne que le noyau est ete release alors qu'un bug subsistais, et ca je le comprends tres bien.

Mais voyez aussi ici la preuve de la force du libre !

Le kernel buggais ?
Le patch est sorti moins de 24 H apres !
Alors pourquoi crier au scandale ?
Parce que vous allez devoir telecharger 3Ko de patch ? Ou parce que vous devrez lancer un make oldconfig ?

Moi, personnellement, je suis SUPER content que le patch sois sorti ! car deja de une, je n'ai mis le kernel que sur une machine de test (chose que bcp de personnes n'ont pas la volonte ou les moyens de mettre en place), et de deux parce que cela prouve l'interet porte a l'eradication de bug de mon systeme favori !

Sur ce, merci aux developpers Kernel ! : You've made a great job, guys !

2.4.15-pre8 plutôt

Posté par Bouton Lionel () le 24/11/2001 à 11:06. (lien). Évalué à 1.

Le bug a été introduit dans la 2.4.15-pre9

[^]Re: 2.4.15-pre8 plutôt

Posté par daniel () le 24/11/2001 à 12:06. (lien). Évalué à 1.
En effet ils conseille de patcher le noyau ou de passer à n'importe quel noyau AVANT 2.4.15-pre9.

A part ça, apparemment la corruption du système de fichier peut être réglée par fsck, mais il faut forcer celui-ci car le fs est marqué comme "clean" à l'arret du système.
pour les anglophones : http://www.uwsg.indiana.edu/hypermail/linux/kernel/0111.2/1673.html(...)

Pas de panique

Posté par Serge Rossi (page perso, ) le 24/11/2001 à 13:01. (lien). Évalué à 1.

Bon, pour ceux qui sont déjà passé en 2.4.15 (comme moi), pas de panique. Linux ne corrompt pas les FS pendant l'utilisation, il y a juste un risque de perte au démontage des volumes.

Pour migrer au mieux, recompiler le noyau 2.4.15 avec le patch indiqué dans la news (ou un 2.4.14-pre8 ou avant).

- Passer en single user (init 1)
- taper sync pour mettre sur disque tout ce qui
est éventuellement encore caché en mémoire
- immédiatement démonter tous les FS qui ne sont
pas indispensables (tout sauf / quoi)
- rebooter avec le noyau corrigé.

Au pire, forcer un fsck sur tous les FS corrige les éventuels problèmes (rien de spécial chez moi).

Que les développeurs qui n'ont jamais découvert de bugs dans leur appli aprés une mise en prod leur jettent la première pierre :-)

[^]Re: Pas de panique

Posté par bmc () le 24/11/2001 à 14:08. (lien). Évalué à 1.
Si vous êtes tout seul sur la machine et que votre noyau est compilé avec les SysRq, vous pouvez faire:
alt-syst-s (le sync)
alt-syst-u (umount)
alt-syst-b (reboot)

La touche syst correspond en général à "Imprimer écran".
Cette séquence est très pratique en cas de crash sauvage de X, si vous n'avez pas d'accès distant possible sur votre machine pour récupérer, ça évite le fsck au reboot sur les partitions ayant un FS non journalisé.

Bon, -1 car un peu HS
- [^]Re: Pas de panique
  
  Posté par Jean-Michel Kelbert () le 24/11/2001 à 15:51. (lien). Évalué à 1.
  application du patch :
  
  comment je fais pour appliquer le patch donner en lien avec la news ?
  - [^]Re: Pas de panique
    
    Posté par matiasf () le 24/11/2001 à 16:18. (lien). Évalué à 1.
    exemple :
    $ cd /usr/src/linux
    $ patch -p1 < ~/le_patch_qui_va_bien.patch
    
    L'idéal est d'utiliser des sources propres.
    - tu vires /usr/src/linux et remet les sources depuis le tar.gz
    - OU "make mrproper" dans /usr/src/linux
    - [^]Re: Pas de panique
      
      Posté par Jean-Michel Kelbert () le 24/11/2001 à 16:23. (lien). Évalué à 1.
      Merci
      
      En fait j'ai modifier le fichier de patch en remplacant les S15 par linux et ca à fonctionner !

Hehe :)

Posté par Anonyme () le 24/11/2001 à 15:09. (lien). Évalué à 1.

Proposition de Andrea Dilger
http://marc.theaimsgroup.com/?l=linux-kernel&m=100655677919173&(...)

Hey, this gives Linus a good reason to make another 2.4.15 release,
and silence all of the people complaining about -greased-turkey (which,
as we all know, was Linus' prerelease for testing that everything was
working OK before he made an _official_ 2.4.15 release, and a good thing
he did or this bug wouldn't have shown up until the _official_ 2.4.15
release which would have been embarassing ;-).

Réponse de Linus
http://marc.theaimsgroup.com/?l=linux-kernel&m=100656696612467&(...)

Think of it this way: this is a good dry-run for Marcelo ;)

Linus "hates maintenance" Torvalds

le 2.4.16pre1 est sorti

Posté par Tame () le 25/11/2001 à 15:11. (lien). Évalué à 1.

Dixit Viande Fraiche, Inodes in iput() are now synced correctly. Pagecache readahead size is now tunable via /proc (was in -ac tree). PPC kernel compilation problems were fixed.
Donc ca veut dire que c'est bon ou je me gourre completement ?

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Articles : Kernel 2.4.15/2.5.0 buggé. Attention !

Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

[^]Re: Aie...

il court il court le kernel

[^]Re: il court il court le kernel

[^]Re: il court il court le kernel

[^]Re: il court il court le kernel

[^]Re: il court il court le kernel

[^]Re: il court il court le kernel

[^]Re: il court il court le kernel (et alors, t'es pas content ?)

[^]Re: il court il court le kernel (et alors, t'es pas content ?)

[^]Re: il court il court le kernel (et alors, t'es pas content ?)

[^]...et alors, t'es pas content ?(et pourquoi tu l'agresses ?)

[^]Re: ...et alors, t'es pas content ?(et pourquoi tu l'agresses ?)

[^]evolution !

[^]Re: evolution !

[^]Re: evolution !

[^]Re: evolution !

[^]Re: evolution !

[^]Re: evolution !

Pas de bol

[^]Re: Pas de bol

[^]Re: Pas de bol

Kernel stable buggé

[^]Re: Kernel stable buggé

[^]Re: Kernel stable buggé

[^]Re: Kernel stable buggé

2.4.15-pre8 plutôt

[^]Re: 2.4.15-pre8 plutôt

Pas de panique

[^]Re: Pas de panique

[^]Re: Pas de panique

[^]Re: Pas de panique

[^]Re: Pas de panique

Hehe :)

le 2.4.16pre1 est sorti