Forum Linux.embarqué Comment déboguer utilement un système linux embarqué?

Posté par .
Tags : aucun
2
28
nov.
2012

Bonjour à tous,

Il n'y a qu'une petite année que je manipule Linux embarqué avec émerveillement mais je suis forcé de constater que l'on se sent souvent très seul lorsque quelque chose ne vas pas ou ne vas plus (comparativement à la facilité de trouver des réponses aux problèmes en développement microchose)!

En l'occurrence j'utilise des distributions spécialisées pour les routeurs (openwrt, dd-wrt) afin de déployer des petits serveurs web d'information ponctuelle…

Lorsqu'il s'agit d'ajouter des applications à ces distributions, les développeurs ont mis à notre disposition un gestionnaire qu'il est possible d'installer manuellement et une belle suite de paquets prêts à l'emploi.

Le revers de la médaille est que Je me retrouve fréquemment dans l'impasse avec ces solutions pré-machées, j'ai régulièrement des bugs qui me prennent un temps de débogage tellement long (installation, configuration, dmesg, ldd, gdb, ajout des dépendances manquantes,… marche toujours pas…) que j'aurais largement plus vite fait de les cross-compiler moi-même depuis la source du logiciel.

J'aimerais trouver au près de vous quelque support afin de me corriger un peu et tenter d'améliorer mes techniques de maintenance/débogage linux open source. HELP!!! (outils skype, VNC… à disposition! :) )

D'avance merci pour vos réactions et vos propositions,
Eki

  • # je ne vois pas quoi rajouter

    Posté par . Évalué à 1.

    j'ai régulièrement des bugs qui me prennent un temps de débogage tellement long (installation, configuration, dmesg, ldd, gdb, ajout des dépendances manquantes,… marche toujours pas…) que j'aurais largement plus vite fait de les cross-compiler moi-même depuis la source du logiciel.

    on m'a toujours dit que lorsqu'on developpe c'est 20% du temps passé à faire le code, et 80% à le debugger.

    il est donc normal de passer du temps sur le debuggage si tu le fais toi meme.

    tu dois quand meme pouvoir t'aider avec de la cross-compilation et de la virtualisation, mais ensuite les procedures sont les memes que sur un ordinateur classique, et tu sembles deja connaitre tous ces outils.

    • [^] # Re: je ne vois pas quoi rajouter

      Posté par (page perso) . Évalué à -2. Dernière modification le 28/11/12 à 12:26.

      tu dois quand meme pouvoir t'aider avec de la cross-compilation et de la virtualisation, mais ensuite les procedures sont les memes que sur un ordinateur classique, et tu sembles deja connaitre tous ces outils.

      Ensuite, quand tu as fait toi même les premiers diagnostics, il y a les #irc dédiés qui sont généralement d'une grande aide.

  • # précisions

    Posté par . Évalué à -1.

    Hello,

    Merci pour vos commentaires, cependant j'aimerais préciser que je parle ici d'applications que je n'ai pas développées (je n'écris malheureusement que pour micromachin) et je parle d'outils que je manipules mais dont je ne suis pas certain de saisir toutes les subtilités (car employés de manière auto-didacte)

    Donc je souhaiterais faire un peu de vidéo-audio-conférence afin de montrer mes opérations de maintenance et pouvoir en discuter en temps réel… J'ai un grand manque de confiance en moi lorsque je travaille sous Linux, parce que je n'ai pas d'expérience solide et partagée avec d'autres.

    A bientôt,
    Eki

    • [^] # Re: précisions

      Posté par . Évalué à 3. Dernière modification le 28/11/12 à 12:41.

      Donc je souhaiterais faire un peu de vidéo-audio-conférence afin de montrer mes opérations de maintenance et pouvoir en discuter en temps réel…

      essaie deja les salons de discussion #IRC et les forums dédiés à ca.

      IRC c'est du chat, live, avec un groupe de personne, pendant le chat, tu peux t'isoler avec un mentor pour aborder certains sujets plus precis…

      et sinon, avec la virtualisation, tu backup ta machine avant de la bidouiller.
      si ca merde, tu ressors le backup, et tu repars comme c'etait avant.

      • [^] # Re: précisions

        Posté par . Évalué à 0.

        Merci Neox,

        Je connais fort bien IRC et les différents moyens d'y perdre son temps ;o)

        D'autre part, je vois que tu me conseilles de ne pas essayer de faire mieux que n'importe quoi avec un bon backup… C'est malheureusement ce que je fais déjà honteusement en secret! :)

        Las de rétablir des backups sans essayer de comprendre. j'espère trouver ici une véritable aide pour devenir plus performant en termes de capacité à déboguer les anomalies (donc à les identifier, les comprendre et si possible, les corriger ou appliquer une alternative fonctionnelle…).
        Pour faire analogie avec microtruc, si certaines de mes applications plantent, je suis toujours en mesure de trouver l'anomalie (dll manquante ou endommagée ou mauvaise version, ou fichier corrompu, liaison bdd interrompue, problème réseau, erreur dans la BDR…) et j'aimerais être capable de la même dextérité sous Linux (on peut rêver!)

        Je reste à l'écoute, même des Linuxiens-pros qui souhaiteraient me vendre ce support!

        Portez-vous bien,
        Eki

        • [^] # Re: précisions

          Posté par . Évalué à 0.

          Pour faire analogie avec microtruc, si certaines de mes applications plantent, je suis toujours en mesure de trouver l'anomalie ...
          ... et j'aimerais être capable de la même dextérité sous Linux (on peut rêver!)
          
          

          Si on suit ce que tu dis, tu voudrais être aussi performant sur un truc ou tu n'as de l’expérience (débogage sous linux) que sur le truc ou tu as de l’expérience (débogage sous window)?

          Je pense qu'il n'y a pas de recette miracle pour déboguer efficacement.
          Pose toi simplement la question pourquoi suis-je efficace dans un contexte et pas dans un autre?
          Pour moi c'est simplement qu'il y a un contexte ou tu as de l’expérience et l'autre ou tu l'en a pas. Au début t'étais mauvais sous Windows ?(mais ça tu t'en souvient déjà plus)
          Il ne te reste plus qu'a acquérir l’expérience qu'il te manque (via dicussion IRC/forum/viso conf/formation/et surtout de la pratique /ect …) et tu seras hyper balèze!!!

        • [^] # Re: précisions

          Posté par . Évalué à 1.

          je suis toujours en mesure de trouver l'anomalie (dll manquante ou endommagée ou mauvaise version, ou fichier corrompu, liaison bdd interrompue, problème réseau, erreur dans la BDR…)

          comment fais tu ?

          pour certaines erreurs tu les connais car tu as deja pratiqué.
          pour d'autres tu vas surement comme nous tous, sur internet, avec le message d'erreur, ou au moins le code de BSOD…

          voire simplement lire la documentation du framework que tu utilises pour savoir que la fonction F renvoie le code 2x323642E quand elle n'a pas de connexion reseau.

          Sous linux c'est pareil, mais apres si tu veux "gagner du temps" bah il va falloir aller faire des formations dans ce domaine.

        • [^] # Re: précisions

          Posté par . Évalué à 2.

          les problèmes microsoft et la façon de les gérer sont totalement différente, je ne sais pas si chez toi tu utilise linux, mais installe une slackware, tu appréhendras mieux les problèmes sous linux. tu n'a pas parler de strace/ltrace, et effectivement lire les commentaires du code sources peuvent aussi aider.

          Souvent si tu installe un paquet qui ne fonctionne pas un coup de strace ou ltrace te permet de voir ce qu'il manque.

          Tu peux gagner du temps en posant 2 principe :
          -c'est matériel
          -il manque une dépendance, ce n'est pas la bonne version.
          -le fichier de conf est mal écris / pas au bon endroit / mauvaise options

          si tu donnais le nom des logiciels que tu ajoute, mais en y pensant il y a surement des forum ddwrt ?

          après les pannes "à la Windows" c'est très rare, du moins ce que tu décris donc cherche sur d'autre problèmes.

  • # Question

    Posté par . Évalué à 4.

    As-tu lu ça ou ça ?
    Je n'ai pas lu la dernière version du bouquin référencé dans le premier lien, ni le bouquin référencé en second lien, mais je pense que tu pourras y trouver des informations pertinentes.

    Sinon la première version du bouquin en premier lien était assez intéressante pour débuter : à l'époque les ressources type mémoire de masse étaient assez cher, et on ne trouvait pas de distributions ou outils dédiés à l'embarqué comme aujourd'hui, et l'auteur proposait de partir d'une distribution et de récupérer les divers composants nécessaires (noyau, libc, fichiers so) pour constituer son propre environnement embarqué. Mais je ne sais pas si c'est la même chose dans la dernière édition.

    En cherchant j'ai trouvé ce lien : il s'agit justement de l'auteur du premier bouquin fourni en référence qui t'explique pas à pas comment prendre des bouts d'une distribution pour l'intégrer dans un environnement embarqué.

    Tiens d'ailleurs il y d'autres choses intéressantes sur sa page perso. Tiens, encore autre chose : je ne l'ai lu qu'en diagonale mauis tu devrais y trouver des infos également.

    Sinon, si tu veux comprendre Linux "bas niveau", regarde aussi du côté de Linux From Scratch ( ou LFS ) : tu y apprendras plein de choses.

    Ma suggestion : Si tu peux essaie de retrouver la première édition du livre de P. Ficheux en occaz, ou essaie de suivre ce qu'il a indiqué sur son site. Tu fais ça dans une petite VM X86 à la base histoire de comptrendre ce que tu fais et de ne pas avoir à gérer la partie cross-compilation, et après tu fais ça dns une VM arm ou autre. Mon avis est qu'il ne faut surtout pas mélanger tout et y aller progressivement.

Suivre le flux des commentaires

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