Linux 2.4.5

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
26
mai
2001
Noyau
La nouvelle livraison du noyau Linux vient d'arriver.
Au programme de cette nouvelle version sortie hier soir, on peut citer l'habituelle correction de bugs, des mises à jour des parties USB et ISDN ainsi qu'un meilleur support PPC et ARM.

A vos compilos ;)

Aller plus loin

  • # Problème...

    Posté par  (site web personnel) . Évalué à 1.

    Vous je sais pas mais moi, pour la première fois avec un noyau stable (et j'ai utilisé tous les noyaux stables depuis le 2.0.14), ça ne marche pas :

    A la fin du chargement du noyau et avant le démarage d'init, il me fait un joli "kernel panic while unmounting old root". Le pire est que ça me fait le meme bug sur 3 PC différents (un AMD, un Intel normal et un Intel bipro), avec un noyau compilé spécifiquement pour chaque PC avec gcc ou kgcc (oui, j'utilise une RH 7, je sais...).

    Ca prouve au moins un truc : mes 3 machines sont bien d'équerre point de vue config :-)

    Bon, ben je reviens en 2.4.5-pre1 en attendant... Je vais regarder à nouveau si tous les prérequis sont bien là...
    • [^] # Re: Problème...

      Posté par  . Évalué à 1.

      je l'ai compilé tout à l'heure et à part des gros problèmes avec pcmcia, rien à signaler. Conseil : oubliez le support pcmcia/cardbus du kernel et utilisez les modules de pcmcia-cs, vous gagnerez du temps ;)
    • [^] # Re: Problème...

      Posté par  . Évalué à 1.

      Redhat 7.0 ?
      Je crois que la version de gcc livrée avec cette Redhat est buggée notament pour la compilation du noyau ... enfin il me semble ...
      • [^] # Re: Problème...

        Posté par  (site web personnel) . Évalué à 5.

        C'est un peu plus tordu que ça.

        En fait le gcc de base était vraiment un peu trop "moderne" (2.96) et RH a publié par la suite des correctifs pour faire en sorte que cette version "moderne" se comporte à peu prés normalement (il va de soi que mes machines sont à jour de ce coté).

        D'un autre côté, comme cette version était bien trop "en avance" (vous notez l'emploi des guillemets hein ;), RH fournissait sur les CD d'install de la 7.0 un package nommé kgcc (sous entendu le gcc capable de compiler le kernel !) qui correspond en fait à egcs 1.1.2, c'est à dire gcc 2.91.66 qui est la version mini officiellement nécessaire pour compiler le noyau ces jours-ci.

        Aprés la sortie de la RH 7, les choses ont plus ou moins évoluées et je crois que gcc 2.96 est maintenant supporté pour compiler le noyau. De toutes façons, meme la dernière MDK utilise gcc 2.96...

        Dans mon cas, j'ai essayé les 2, dans le passé comme maintenant et les versions précédentes des noyaux fonctionnaient, quel que soit le compilo alors que là, ça ne marche avec aucun.

        Ca fonctionnait encore avec le 2.4.5-pre1 (celui que j'utilise en ce moment et depuis 15 jours). Si je suis très courageux, je m'amuserai peut-être à tester tous les 2.4.5-pre pour isoler quand est apparu le bug mais là... j'ai la flemme :-)
        • [^] # Re: Problème...

          Posté par  . Évalué à 0.

          Je confirme le probleme de chgmt de fs root.

          Chez moi c'est une Mandrake 8.0, j'ai recrée mon initrd-2.4.5.img en m'inspirant de celui que
          j'avais crée pour le 2.4.4 mais rien a faire, au chgmt de fs root, j'ai droit a un kernel panic
          me signalant une reference a NULL

          Je precise que mon 2.4.4 fonctionnait au poil...
        • [^] # Re: Problème...

          Posté par  . Évalué à 0.

          Faut quand meme rappeler que "moderne" c'est RedHat qui l'a choisi. Ce qu'ils ont pris c'est un snapshot de gcc sur une branche de développement, mais *jamais* les développeurs gcc n'ont sorti de version 2.96 officielle (pas meme une version non officielle)
        • [^] # Re: Problème...

          Posté par  (site web personnel) . Évalué à 1.

          Il n'y a pas de gcc 2.96... Les dernières versions de gcc sont les 2.95.3 et 2.95.3. Toutes les versions 2.96, 2.97, pre-3.0 et autres ne sont que des versions CVS instables du futur 3.0... La vraie 3.0 est prévu pour le 15 juin (avec date de sortie flottante depuis un an :( ).
    • [^] # Re: Problème...

      Posté par  . Évalué à 0.

      probleme identique sous slackware 8.0 sur un athlon 1.1 ...
      que je penne leur version ( slack) fournie , ou ma version optimisée recompilée , ca freeze sur un kernel panic au remount ...
      par contre en slack 7.2 marche tres bien ( PII 400) ...
      je ne comprend pas d'ou provient l'erreur ..
  • # euh pb sous sparc...

    Posté par  . Évalué à 0.

    dites, vous devez savoir ca.
    equipe d'une sympatique sparc avec un GNU/linux, je me suis dit : je m'en va recompiler la kernelle...
    j'ai fait ma tentative avec le 2.4.4

    pas de souci jusqu'au moment ou la compil attaque memory.c
    la, j'ai un crash....
    ok, j'ai pas essaye le 2.4.5

    question : mis a part gcc, la compil du kernel ne necessite rien de particulier....

    desole pour les accents, le clavier n'en a pas...
    qwerty oblige.
    ;-)

    C01N C01N will save you...
  • # BTTV ?

    Posté par  . Évalué à 0.

    yop,

    un petit bug chez moi a signaler sur une compil en SMP
    xawtv ne display plus rien en 2.4.5. Que ce soit en mode Television ou en entree composite pour recuperer le signal de l'amiga.

    je dispose d'un dual screen et le signal video ne passe pas sur les 2 cartes.
  • # Mouais, et combien de versions ac x....

    Posté par  . Évalué à 0.

    Bon, je sais , le noyau evolue sans cesse, mais faudrait peut etre prendre son temps entre chaque release de noyau.

    6 versoins 2.4 en 5 mois, c'est vraiment trop.

    Bon pour ma part, étant débutant, j'attend avec impatience la sortie de la SuSE 7.2, en esperant voir trouver un noyau 2.4.6, USB 2 et Netscape 6.1


    A+
    • [^] # Re: Mouais, et combien de versions ac x....

      Posté par  . Évalué à 1.

      déja usb 2 ?
      • [^] # Re: Mouais, et combien de versions ac x....

        Posté par  . Évalué à 0.

        vi, il y a déja une nouvelle évolution de USB
        bien plus rapide.

        mais heu... coté hardware (aussi bien prise que peripherique) cela est pauvre, voir inexistant (encore que jesuis peut etre pas à jour :) )

        de toute facon, coté interface haut debit, je pense que Firewire/Ilink est deja bien répandu, et faudrait plutot viser de ce coté la plutot que de encore se fourguer dans une nouvelle norme qui à quasi pas de support hors informatiques (et meme dans l industrie informatique c est mal parti...)

        enfin bon bref, usb2 c pas grave si linux ne le supporte pas encore. on a le temps de voir venir :)
    • [^] # Re: Mouais, et combien de versions ac x....

      Posté par  . Évalué à 0.

      non, c'est tres important de faire des releases frequentes car tout le monde n'essaye pas les patch ac* et pre*. En sortant des versions majeures chaque mois, les developpeurs incitent les distribs, les utilisateurs non avances ... enfin tous les gens qui ne patchent pas tous les jours leur kernel a upgrader. Ils ont donc plus de feedback, peuvent tester la qualite de leur code a plus grande echelle, sur plus de plateformes et de materiel, reduire les bugs, enfin ... que des avantages, tu es le premier a en beneficier. Et puis d'ailleurs c'est debile ce que tu dis, et je vais te le prouver (je me tairais volontairement sur le ridicule d'attendre une distrib pour la mise a jour d'un kernel) .. oui c'est stupide, tu dis d'une part en avoir marre du 'kernel of the month', mais tu dis etre tres impatient pour la release de suze 7.2, avec je cite, le 'kernel 2.4.6'. Tu te rends compte comme c'est debile ?
      • [^] # Re: Mouais, et combien de versions ac x....

        Posté par  . Évalué à 0.

        surtout que personne ne lui demande d'installer le dernier noyau a la mode !!
        une idée: aka faire comme si les noyaux 2.4.1, 2.4.2, 2.4.3, 2.4.4 et 2.4.5 n'avaient jamais vu le jour. Tu te reveilles et t'installes directement le 2.4.6 ce qui te fait un nouveau noyau en 5 mois ...

        En fait, si tu lis le changelog, tu peux tres bien te rendre compte que ta config n'est pas impactée par les modifs qui ont été faites et attendre la prochaine release qui corrige des problemes POUR TA CONFIG.

        PLuG
      • [^] # Re: Mouais, et combien de versions ac x....

        Posté par  . Évalué à 0.

        Bon, stupide je le suis, mais curieux aussi.

        J'ai testé le noyau 2.4.0 et 2.4.3, et je suis plutot ravi meme si coté utilisateur y a pas de grandes differences avec les 2.2.x (sauf USB : plus besoin de rebooter pour pouvoir utiliser la souris USB, par contre pour les camera digitales, c'est pas PnP)


        Ce que je voulais dire c'est que, quand tu vois la sortie du noyau 2.4.4 avec 4 ac en deux jours, on voit bien que c'est sorti à la vas vite (D'ailleurs Torvalds on le voit plus, c'est alan Cox qui fait le boulot)

        Bon, j'attend le 2.4.6 si suse sort ça avec. Je me trincballe toujours une Vieille SuSE 6.3 que j'ai eu dans Linux+.

        A la rigueur je peux telecharger ce noyau 2.5 mais quand je vois les pb que les utilisateurs de MAndrake on eut, j'ai un peu peur (Les noyau testé ont été fait à l'Epita).

        Voila, A+
        • [^] # Re: Mouais, et combien de versions ac x....

          Posté par  . Évalué à 0.

          >D'ailleurs Torvalds on le voit plus, c'est alan Cox qui fait le boulot

          Rien a voir, cela fait des annees que des versions "ac" existent.
          Alan Cox et Linus n'ont pas les memes objectifs et ne font donc pas l'integration de la meme maniere. Alan est beaucoup plus tenté de tester les nouveaux drivers et autres correctifs (d'ailleur il fait souvent des retour/corrections sur ce qu'il a deje intégré dans le ac precedent.).
          Linus, recoit principalement les patchs de la part d'alan. Il refait un tri et supprime ce qui ne lui plait pas, modifie ce qui n'est pas beau ...
          Quand ca lui plait, un nouveau noyau 2.4.x officiel sort ... bref il continue son boulot comme avant en faisant l'integration finale et les choix d'architectures sur la mailing list. Si un truc lui plait pas, ca ne sort pas, c'est lui qui a le dernier mot ...

          Pourquoi dis tu qu'il ne fout plus rien ???

          >Les noyau testé ont été fait à l'Epita
          Bon la ca va troller a mort. "fait" veut sans doute dire compiler parceque si des gens savaient coder a l'Epita on le saurait :-) J'en conclu donc qu'a l'Epita, y en a un qui a trouvé "make" mais s'est gourré en compilant les noyaux puisque ca marche pas ?

          PLuG
          • [^] # Re: Mouais, et combien de versions ac x....

            Posté par  . Évalué à 0.

            >>Les noyau testé ont été fait à l'Epita
            >Bon la ca va troller a mort. "fait" veut sans doute dire compiler parceque si des gens savaient coder a l'Epita on le saurait :-)

            C'est certain. Mais je ne comprends toujours pas pourquoi ils ont recompilé le noyau?!?
            Y'a pas besoin de le mettre à jour pour jouer à Quake.

            De toute façon, NT est beaucoup plus adapté pour ça (y'a cstrike en plus).
        • [^] # Re: Mouais, et combien de versions ac x....

          Posté par  . Évalué à 1.

          Je n'ai pas le temps de retrouver l'interview de Linus mais les premières versions d'un noyau stable ont toujours des problèmes. Linus sort ainsi pas mal de versions au début pour corriger les défauts de jeunesse. N'oubliez pas que les noyaux de développement sont évalués par beaucoup moins de personnes.

          En résumé, quand un nouveau noyau sort, la version x.y.0 est relativement stable puis dans les versions x.y.(1...4), l'instabilité augmente avant de régresser à partir de la version x.y.5.

          La remarque précédente n'est pas de moi mais de Linus (expérience acquise sur les séries 2.0 et 2.2). Moralité, si vous vouler la stabilité attendez quelques mois entre de changer de noyau.

          Au passage, carton rouge aux distributions qui foncent de suite sur les premières versions d'un noyau, l'utilisateur peut en souffrir et l'image de Linux avec.
          • [^] # Re: Mouais, et combien de versions ac x....

            Posté par  . Évalué à 2.

            Exact, je me souvient de cela.
            C'est d'ailleur pour eviter de faire comme le noyau 2.2.x que Linus a tant attendu avant de livrer un vrai 2.4.0. C'est aussi pour cela qu'il a sorti autant de 2.4.0-testXX. Il n'y avait pas eu de 2.2.0-testXX a l'époque. Pour mémoire le 2.2.x avait été relivré plusieurs fois en 15 jours:
            2.2.0 le 25/01
            2.2.1 le 28/01
            2.2.2 le 22/02
            ...
            2.2.9 en mai !!

            Autre probleme du 2.2 c'est que quand il est sorti, Linus a tout de suite créé la branche 2.3 pour la préparation du 2.4 et tous les developpeurs noyau se sont mis au boulot sur les nouveaux trucs cool a coder (2.3.x) ... personne ne bossait plus sur le 2.2 !!
            Cette fois toujours pas de branche 2.5, linus attend la maturité du 2.4 pour cela ...

            D'un autre côté il y a une volonté forte delivrer les mises à jour de drivers rapidement. Ca fait des relivraisons de kernels qui ne concernent que peu de personnes. Car le vrai probleme du 2.2 c'est que le 2.2.0 etait VRAIMENT buggé.

            Bref il essaie de ne pas commettre 2 fois les mêmes erreurs ... c'est vrai que malgré tout ils galèrent pas mal avec le 2.4 qui a déjà trop été relivré.

            PLuG
            • [^] # Re: Mouais, et combien de versions ac x....

              Posté par  . Évalué à 1.

              c'est vrai que malgré tout ils galèrent pas mal avec le 2.4 qui a déjà trop été relivré.

              Non: c'est volontaire. C'est justement pour le faire tester par tout le monde que Linus a laché dans la nature le 2.4.0. Il l'a d'ailleurs dit dans son message d'annonce du 2.4.0.

              Rien de tel de nombreux utilisateurs pour déboguer. MicroSoft en sait quelque chose. Mais ici, la différence, c'est que les bogues sont corrigés (et corrigeables :-)).

              PK
        • [^] # Re: Mouais, et combien de versions ac x....

          Posté par  . Évalué à 1.

          je dirais rapidement qu'heureusement qu'il ya des gens pour poser rapidement des correctifs de bugs.
          En etendant la reflexion on pourrait dire que c'est aussi chiant de devoir upgrader son sendmail parce qu'il existe un trou de secu. L'attente de la prochaine Distro de tes reves pour corriger ce trou de sécu n'etant pas serieux, je trouve que le passage du 2.4.4 a l'ac4 etait important par exemple ( bugfix scsi, htp336, usb, nfs ).

          Il reste aussi une autre solution... Celle d'attendre les Live Update de 40Mo de microsoft dont l'utilisateur ne sais rien du tout en general.

          +a.
          mued
          • [^] # Re: Mouais, et combien de versions ac x....

            Posté par  . Évalué à 0.

            > Il reste aussi une autre solution... Celle d'attendre les Live Update de 40Mo de microsoft dont l'utilisateur ne sais rien du tout en general.

            Ouh là.... Live update => (C)SYMANTEC. Tu voulais propablement parler de "Service Pack" et autre "Service Release" (C)Microsoft.
          • [^] # Re: tiens, on va parler de SendMail justement...

            Posté par  . Évalué à -1.

            > on pourrait dire que c'est aussi chiant de devoir upgrader son sendmail parce qu'il existe un trou de secu

            Nan, y'a pas un trou de sécu dans SendMail... Y'a toujours au moins un trou de sécu sur une machine qui héberge un SendMail... Nuance ;o)

            C'est vrai que ce soft est encore pas mal utilisé, mais à mon avis, c'est parce qu'il est implanté un peu partout pour des raisons historiques. Maintenant, il y a d'autres solutions, et il peut même être plus simple et plus avantageux de passer à autre chose genre PostFix ou QMail, beaucoup plus sûrs à mon gout. En plus, certains outils de migration Sendmail->Qmail existent (ca doit être le cas pour PostFix aussi), donc pourquoi se priver, au lieu d'upgrader tout le temps son SendMail ?


            Voila, c'était juste un p'tit cri de colère, un post semi-automatique généré par le bot qui réside en moi ("bot in the shell") ;o)

Suivre le flux des commentaires

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