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.
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.
Aller plus loin
- daPatch (4 clics)
# Aie...
Posté par the_freeman . Évalué à 1.
Il n'y avait pas déjà un bug du même genre dans dans le 2.4.12 ?
[^] # Re: Aie...
Posté par kalahann . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Aie...
Posté par matiasf . Évalué à 1.
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 (site web personnel) . Évalué à 1.
Echap
:1,$s/2.2/2.4/g
[^] # Re: Aie...
Posté par Miod in the middle . Évalué à 1.
Donc :
:%s/2\.2/2.4/g
[^] # Re: Aie...
Posté par Alphonse Oncle . Évalué à 1.
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 . Évalué à 1.
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 Étienne . Évalué à 1.
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 . Évalué à 1.
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 Étienne . É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 . Évalué à 1.
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 Étienne . Évalué à 1.
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 . Évalué à 1.
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 Étienne . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
[^] # Re: il court il court le kernel
Posté par Maxime . Évalué à 1.
Dans tous les cas, lisez The Cathedral And The Bazaar !
[^] # Re: il court il court le kernel
Posté par zeiram . Évalué à 1.
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 . Évalué à 1.
http://www.linuxfr-france.org.invalid/article/these/cathedrale-bazar/cathedra(...)
[^] # Re: il court il court le kernel
Posté par Jerome . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 Graveen . Évalué à 1.
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>
[^] # Re: ...et alors, t'es pas content ?(et pourquoi tu l'agresses ?)
Posté par Frédéric RISS . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
Il faut lire :
"moindre avec un x.y.z (y pair) qu'avec un x.y.z (y impair).
[^] # Re: evolution !
Posté par Okki (site web personnel, Mastodon) . Évalué à 1.
# Pas de bol
Posté par Neryel . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
Parfois .. y'a des kwak (pas des coin, non)
# Kernel stable buggé
Posté par Gilles Denat . Évalué à 1.
[^] # Re: Kernel stable buggé
Posté par Schwarzy . Évalué à 1.
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 . Évalué à 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 . Évalué à 1.
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 . Évalué à 1.
[^] # Re: 2.4.15-pre8 plutôt
Posté par daniel . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 Jiquem . Évalué à 1.
comment je fais pour appliquer le patch donner en lien avec la news ?
[^] # Re: Pas de panique
Posté par matiasf . Évalué à 1.
$ 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 Jiquem . Évalué à 1.
En fait j'ai modifier le fichier de patch en remplacant les S15 par linux et ca à fonctionner !
# Hehe :)
Posté par Anonyme . Évalué à 1.
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 . Évalué à 1.
Donc ca veut dire que c'est bon ou je me gourre completement ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.