Forum Linux.général Ext3 ca me saoule

Posté par  (site web personnel) .
Étiquettes : aucune
0
17
nov.
2004
Bonjour petit forum,
je te préviens j'ai envie de m'énerver.
Ca fait bien la 3ème fois en 3 mois que ce con d'OS m'affiche pour seul écran d'accueil : Kernel Panic ! (ext3 mount failed blablabla)
Ma question est la suivante : que me conseillez vous comme système de fichier pour mon pinguin ? Est-il possible de formatter une partoche dans un autre format que celui proposé dans sa distribution favorite ? (genre je peux mettre du reiserFS alors que la FC3 ne me le propose pas à l'install ?)
Parcque bon là j'en suis rendu à stocker mes données importantes sur une fat32, le seul système de fichier qui semble résister à l'erosion du temps qui passe.
Merci de me répondre dans les 1h, avant que je finisse de dl les 3 CD de la dernière Core 3 :)
Bisous petit journal

  • # FS ou Kernel Panic

    Posté par  . Évalué à 2.

    T'as fait une mise à jours ?

    > Kernel Panic ! (ext3 mount failed blablabla)

    Quoi d'autre ?
    Avec le kernel standard ou tu as recompilé le kernel ?
    Tu utilises les labels dans grub.conf (root=LABEL=/) ?

    Ce n'est pas forcément un problème de FS.
    Pour FC3, il faut :
    - Un initrd fait par mkinitrd >= 4.1.18
    - tmpfs de compilé dans le noyau
    - ne pas désigner root avec un label pour raid

    Ceci est valable avec tous les FS.

    > genre je peux mettre du reiserFS alors que la FC3 ne me le propose pas à l'install ?

    Pour utiliser reiserFS à l'installation :
    linux reiserfs selinux=0

    • [^] # Re: FS ou Kernel Panic

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

      alors j'ai rien recompilé du tout, j'utilise le noyau 2.6.9.667 (utilisait)
      j'ai pas touché au grub.conf, c'est celui de base.
      Je n'ai pas fait de mise du kernel depuis 3 jours et ca a bien marché jusqu'à ce matin donc :)
      En fait si je soupçonne le FS, c'est qu'il est impossible de faire un fsck sur la partition incriminée (sous knoppix). A vrai dire c'est la partition avec /home qui est partie en live, parfois c'est /boot, parfois /home (plus embêtant)
      Le plus rigolo c'est que quand le fsck semble pmarcher, certains dossiers disparaissent quand même, et se retrouve avec une taille négative (bref inutilisable)
      pour le coup du linux reiserfs je vais essayer, mais une question : c'est vraiment mieux comme système de fichier ? Pourquoi n'est-ce pas par défaut ?

      • [^] # Re: FS ou Kernel Panic

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

        Pardon c'est / qui est parti en live cette fois, pas /home

      • [^] # Re: FS ou Kernel Panic

        Posté par  . Évalué à 2.

        > En fait si je soupçonne le FS, c'est qu'il est impossible de faire un fsck sur la partition incriminée (sous knoppix).

        FC3 est en "avance" pour ext3.
        Le ext3 de FC3 n'est pas compatible avec des vieilles versions de e2fsprogs.

        > A vrai dire c'est la partition avec /home qui est partie en live, parfois c'est /boot, parfois /home (plus embêtant)
        > Le plus rigolo c'est que quand le fsck semble pmarcher, certains dossiers disparaissent quand même, et se retrouve avec une taille négative (bref inutilisable)

        Sous FC3 ou sous knoppix ?

        > c'est vraiment mieux comme système de fichier ?

        Il a ses défauts et qualité. Pas envis de troller.

        > Pourquoi n'est-ce pas par défaut ?

        Pour 4 "bonnes" raisons :
        - ext3 est plus solide (normalement :-))
        - ext3 est nfs compliant (flush)
        - ext3 est principalement développé par Red Hat
        - reiserfs ne supporte pas les attributs étendus et donc ne supporte pas SeLinux. Il parait qu'il y a un patch SuSE.

        Il y a de "gros" problèmes de compatibilité ext3 avec FC3. Par exemple, si tu es sous knoppix il faut une e2fsck qui supporte :
        - resize_inode dir_index attr_ext
        C'est spécifique Linux 2.6 et c'est standard (sauf resize_inode qui n'est pas encore en upstream).


        Tu pourrais être plus claire car là, j'ai l'impression que tu as un problème *depuis* knoppix et pas avec FC3.
        Attention, FC3 ajoute l'attribut "attr_ext" aux FS ext3 et certains versions d'e2fsck de certaines distributions n'aiment pas ça.

        Pour résumer, la cohabitation FC3 avec une autre distribution n'est pas facile car :
        - Selinux par défaut
        - resize_inode

        • [^] # Re: FS ou Kernel Panic

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

          Effectivement cette fois e2fsck a râlé parcque le système de fichier utilisait des options qu'il ne connaissait pas : j'ai bêtement cru que la partition était irrécupérable, comme ce fut le cas les fois précédente, sous FC2 (là par contre e2fsck me retournait autre chose, je sais plus quoi)
          Pour le coup des dossiers avec une taille inférieure à 0, c'était sous FC2, après avoir récupéré une partition avec e2fsck, donc le problème ne concernait pas du tout knoppix.
          M'enfin ce qui est bizzare c'est que d'habitude le kernel tente au moins un fsck (me le propose) avant de planter lamentablement. Là même pas. Enfin bon c'est la caca.
          En tout cas merci pour ton aide, tu as l'air de t'y connaître !
          Je vais essayer de trouver une version récente de e2fsck et essayer de la faire tourner sous knoppix
          (pour info j'avais désactivé SeLinux)

        • [^] # Re: FS ou Kernel Panic

          Posté par  . Évalué à 1.

          > sauf resize_inode qui n'est pas encore en upstream

          A été ajouté en upstream (2.6.10-rc1). Idem pour ext3-reservation qui fait aussi parti de FC3.

    • [^] # Re: FS ou Kernel Panic

      Posté par  . Évalué à 1.

      > root=LABEL=/

      Évidemment, il ne faut pas deux FS avec le label '/'.

    • [^] # Re: FS ou Kernel Panic

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

      Question a 2cetns : A quoi ca sert un initrd?

      Parce que perso j'en ai encore jamais eu besoin sur les install ou j'ai compilé le noyeau (slack et gentoo) et que je suis un peut curieux quand même mais pas asser pour lire la doc

      • [^] # Re: FS ou Kernel Panic

        Posté par  . Évalué à 1.

        Ça permet de faire des "petites choses" avant de monter la vrai partition racine.
        Red Hat utilise ça depuis longtemps. Par exemple, ça permet d'indiquer la partition racine avec le label de la racine et non avec le périphérique réel. Si le disque bouge, il n'y a pas de problème.

        Sans initrd :
        root=/dev/hdc
        Avec initrd :
        root=LABEL=root

        Si root passe de /dev/hdc à /dev/hdd, ça ne boote plus avec "root=/dev/hdc" mais ça boote toujours avec "root=LABEL=root".

        La partition root peut se trouver n'importe où. Sur un lvm, une partition raid, etc... C'est initrd qui va initialiser et fouiller les périphériques, raid, lvm pour récupérer les label et utiliser le bon périphérique.

        Avec udev, udev doit être initialisé avant de monter la partition root. Sauf si tu as un /dev avec déjà des nodes. Mais dans ce cas, c'est une "sous-utilisation" d'udev. Avec udev, /dev est un tmpfs mounté par initrd dans le ramfs initial.
        udev minimum (sans /etc/udev/rules.d) est initialisé par initrd. Puis la partition root est montée. Puis la partition /dev dans le ramfs initial est déplacé dans la partition racine.

        Avec FC3, on peut faire sans initrd mais il faut :
        - ne pas utiliser les label par la partition racine
        - avoir /dev static avec les nodes nécessaires au boot (/dev/partition_racine, /dev/null, /dev/console, etc).
        - tous les drivers pour la partition root doivent être dans le noyau et pas en modules.

  • # Plus d'infos ?

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

    Peux-tu nous donner un plus d'infos ? Quel noyau ?
    Tu as regardé les logs ? Le journal ?

    • [^] # Re: Plus d'infos ?

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

      Pour plus d'info, voir au dessus. Par contre désolé je n'ai pas regardé le journal ou les logs, d'ailleur je peux les trouver où ?

  • # XFS

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

    que me conseillez vous comme système de fichier pour mon pinguin ?

    je suis en XFS sous debian depuis 4 ans ... je te conseille la sarge beta2 qui le gere nativement.

    en 4 ans ... je n ai jamais eu de KP du au XFS. Le system est resistant aux badblocks. Il est _legerement_ plus fiable que l ext3 , et a une vitesse comparable.

    Pour info, j ai souvent vu des ext3 refuser de booter parce qu il voulaient un fsck manuel ...

    Il parait que la nouvelle version de reisor ( celle sortie il y a 18 mois ) est fiable. Je n y ai jamais touchee.

    XFS m as pose une seule fois probleme ( perte de toute une partition suite a un appui repete sur le bouton reset pendant 15 min .... environ 30 reboots en 15 mn - le / en XFS a pris cher). en fait j avais trop joue avec le driver, je n ai jamais pu reproduire de bug avec les noyeaux recents. Quand j ai parle de ce bug sur IRC, en gros ... mon noyeau etait perime depuis plus d un an, et n as jamais ete reporte par un tiers. Bref ... le seul pb que j ai eu en 4 ans est du a un appui a repetition sur le bouton que en theorie personne n utilise jamais.

    • [^] # Re: XFS

      Posté par  . Évalué à 1.

      > Pour info, j ai souvent vu des ext3 refuser de booter parce qu il voulaient un fsck manuel ...

      Problème de script de boot ou e2fsck plus exigent.
      Le fait d'atteindre fsck montre que le système a booté.
      Tu avais des disques IDE ?

      ext3 journalise les données, xfs (comme reiserfs) ne journalise que les méta-données. Si tu ne veux que journaliser les méta-données tu peux aussi.

      • [^] # Re: XFS

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

        C'est quoi la difference entre journalisation des données et des meta-données (ou qu'appel tu meta-données) ?

        • [^] # Re: XFS

          Posté par  . Évalué à 2.

          Les données, ce sont les données. Par exemple le contenu d'un fichier.
          Les meta-données indiquent où trouver les données (c'est la table d'inode, des blocks libre, etc).

          Ext3 est le seul FS a journaliser les données.
          Exemple :
          fd = open("toto") ;
          write(fd, "data") ;
          close (fd) (ou flush(fd)) ;
          // coupure de courrant ou reset

          Avec ext3, les données sont écrites, la taille du fichier est 4.
          Avec xfs, jfs, reiserfs, les données peuvent ne pas être écrite et "pire" l'inode peut ne pas être créé. Si l'inode est créé, le fichier a une taille de 4 octets. Par contre rien ne garanti que les données sont écrites. Dans ces 4 octets il peut y avoir un bout d'un ancien /etc/passwd par exemple. C'est génant.

          Si la coupure de courant ou le reset est fait avant le close() ou flush(), les données peuvent être écrite ou non. Par contre avec ext3 tu n'auras pas de mauvaises données. ext3 ne garantit l'ordre d'écriture que s'il y a un close() ou flush().

          Donc :
          fd = open("toto") ;
          write(fd, "data") ;
          seek(fd, quelque_part) // NB : ext3 mets les données à 0 si on va au-delà de la fin du fichier. Leur autres aussi sûrement (du moins s'il n'y a pas de coupure de courant ou reset).
          write(fd, "data2") ;
          // coupure de courant

          "data2" peut être écrit alors que "data" n'est pas écrit. Si tu utilises un flush(), tu es sûr que "data" et "data2" sont écrits. ext3 journalise les données en premier (garanti que les données sont là) puis les méta-données.

          C'est plus lent qu'un fs journalisé "classique" mais plus sûr. PostgreSQL (qui utilise flush comme d'autres SGBD, mais pas MySQL) sur ext3 est blindé.

          Ça dépend du hardware. Avec SCSI il n'y a pas de problème sur coupure de courant.

      • [^] # Re: XFS

        Posté par  . Évalué à 1.

        > ext3 journalise les données, xfs (comme reiserfs) ne journalise que les méta-données. Si tu ne veux que journaliser les méta-données tu peux aussi.

        Pour faire "plaisir" à doublehp qui ne comprend pas cette phrase (qui, il est vrai, est un peu ambigue).

        ext3 permet de journaliser :
        - données et meta-données (comportement par défaut)
        - méta-données uniquement (comportement forcé avec data=writeback (voir "man mount"))

        xfs, jfs et reiserfs ne journalise que les méta-données. Du moins à ma connaissance. Si j'ai faux (ce qui est tout à fait possible), veuillez indiquer la source qui me donnerait tord.

  • # hypothese

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

    T'a pas eu des modification du /etc/fstab ?

    • [^] # Re: hypothese

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

      Non non je n'ai eu aucune modification de fstab, en gros impossible de monter la partition qui contient la racine (d'où le kernel panic je suppose).
      En tout cas merci à tous ceux qui ont répondu !
      J'ai résolu le problème : 1h pour dl les isos de la FC3 + 15 minutes de réinstallation =/

Suivre le flux des commentaires

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