Journal Debian/dash, ou comment ne plus booter

Posté par  .
Étiquettes :
0
27
juin
2010
(J'ai mis un bout de temps à résoudre ça, alors autant le documenter, ça peut servir à quelqu'un d'autre)

Pour les ahuris comme moi qui sont en debian sid avec plein de paquets experimental, je signale un petit souci que j'ai connu avec une mise à jour récente de dash (0.5.6.1-1~exp0).

Tou à coup, le système ne bootait plus du tout, avec pour seul message
/bin/sh: Can't open /etc/init.d/rcS

Le fichier est pourtant bien accessible (sauf en écriture, vu qu'à ce moment le FS est monté read-only). Pas de mise à jour récente des paquets sysvinit et amis.

En fait, le problème se trouve être dans dash. Pour le régler, il faut remettre bash comme interpréteur de boot
dpkg-reconfigure dash -> dire d'utiliser bash

Je ne sais pas si c'est parce que cette version a d'autorité décidé de remplacer bash, ou si cette décision est plus ancienne et c'est tout simplement un bug de dash.

  • # cette décision est plus ancienne

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

    Sous ubuntu (dérivée de debian donc) c'est dash par défaut depuis la 6.10, donc octobre 2006, donc ce doit aussi l'être sous debian depuis ce temps là, voir même avant.

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: cette décision est plus ancienne

      Posté par  . Évalué à 2.

      Faux ubuntu a était le premier à le sortir bien que le travail a commencé avec Debian.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # ...

    Posté par  . Évalué à 10.

    Tu aurais été faire un tour sur le bug report de dash, tu serais tombé sur http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586807

    Oui c'est bien un bug dans dash qui n'execute plus les scripts read-only.

    • [^] # Re: ...

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

      Mickaël L : Bonne remarque de Matthieu C, tu trouveras en effet souvent ton bonheur directement dans les rapports de bugs du paquet en question, spécialement si tu évolues en sid avec des paquets de la version experimentale :)

    • [^] # Re: ...

      Posté par  . Évalué à 3.

      Ah...
      Non, c'est juste que j'avais pas fait le lien avec celui-là. La relation entre "ça empêche de booter" et "impossible d'exécuter des script read-only" ne m'a pas frappé sur le moment. Après coup, ça semble évident.

      De là à dire que ça ne vaut pas le coup de le signaler...

      • [^] # Re: ...

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

        Mickaël L : ah mais si ça vaut le coup de le signaler, mais surtout au mainteneur du paquet via l'outil Reportbug dans Debian.

        • [^] # Re: ...

          Posté par  . Évalué à 3.

          Ben je suis pas tout à fait un perdreau de l'année
          http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587353
          (la sévérité "important" c'est parce que l'outil particulier que j'ai utilisé permettait pas d'en mettre une plus élevée ; mais j'ai jamais trouvé la version formulaire en ligne pour remplir un bug, je trouve que reportbug est inutilisable)

          • [^] # Re: ...

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

            Mickaël L : ne t'inquiète pas pour le niveau de gravité, le mainteneur du paquet le modifiera pour l'adapter selon son appréciation de la situation. Pour info il n'y a pas de formulaire en ligne pour remplir un rapport de bug.

            • [^] # Re: ...

              Posté par  . Évalué à 3.

              > Pour info il n'y a pas de formulaire en ligne pour remplir un rapport de bug.

              J'aurais pensé que depuis le temps que des gens le demandent, ç'aurait été fait. Ne pas en avoir reste tout de même le meilleur moyen de dissuader les utilisateurs de faire des rapports de bugs.

              • [^] # Re: ...

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

                Mickaël L : je me permets de te diriger vers ce billet de mon blog pour une explication détaillée.

                • [^] # Re: ...

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

                  J'ai dû me tromper dans mon code HTML.

                  Le lien : http://carlchenet.wordpress.com/2010/01/24/reportbug-vs-laun(...)

                  • [^] # Re: ...

                    Posté par  . Évalué à 8.

                    Ca explique rien du tout, il n'y a aucun argument (et je ne vois pas ce que launchpad vient faire là dedans). Il y a juste une explication qui dit : on préfère faire avec des mails et puis c'est tout.

                    Rien n'empêche 'envoyer des mails depuis une interface web, pour ceux qui veulent des mails.

                    Et le fait que les *développeur* préfèrent des mails n'empêche pas que les *utilisateurs* (ceux qui sont censés faire les rapports de bugs) peuvent être dissuadés (je l'ai été à de nombreuses reprises ; ce rapport, j'ai failli l'abandonner quand reportbug m'a demandé une config, et encore une fois quand il a segfault).

                    Pour moi, reportbug ne devrait être qu'*un* client du BTS parmi d'autres.

                    • [^] # Re: ...

                      Posté par  . Évalué à 1.

                      Enfin, on s'égare là...

                    • [^] # Re: ...

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

                      > Pour moi, reportbug ne devrait être qu'*un* client du BTS parmi d'autres.

                      C'est le cas, reportbug-ng est un autre client pour soumettre un bug.

                      L'avantage de reportbug, c'est que ton rapport de bug énumère les versions de toutes les dépendances, la version contre laquelle l'utilisateur rapporte le bug et quelques autres informations utiles.

                      Quand en tant que mainteneur pour un autre système de paquets je reçois des bugs avec très peu d'informations qui en plus auront besoin d'être triés (le paquet n'est pas précisé dans le bon champ, je n'ai pas été mis en copie), qu'après avoir reçu le mail m'informant du bug, je dois me connecter à l'interface web (alors que répondre directement au rapporteur aurait été plus efficace) ou que le bug vient d'une bibliothèque non mise à jour, je me dis que reportbug, c'est la meilleure façon de faire.

                      • [^] # Re: ...

                        Posté par  . Évalué à 1.

                        Sauf qu'en général, quand je rapporte un bug, je le fais pas depuis l'ordi planté où il a eu lieu, mais depuis un autre à côté.
                        En l'occurence, le rapport sur ce bug, je l'ai fait depuis mon portable.

                        • [^] # Re: ...

                          Posté par  . Évalué à 2.

                          Sauf qu'en général, quand je rapporte un bug, je le fais pas depuis l'ordi planté

                          Mais la majorité des reports de bogue ne sont pas dus à un système inutilisable, mais seulement une partie. Par exemple, chez moi, il est impossible d'installer le paquet grub-pc, mon système est quand même fonctionnel avec grub-legacy.

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Sid

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

    Comme quoi Sid, c'est bien pour tester, mais dans une utilisation courante, mieux vaut une testing (oui je sais c'est bizarre). J'avais arrêté d'utiliser Sid depuis une fuite mémoire dans Xorg (ou XFree86 à l'époque ?), qui faisait planter le système au bout d'un temps fini, d'autant plus court qu'on avait peu de RAM.

    On peut toujours au cas par cas choisir d'installer la version Sid de tel ou tel paquet, mais pour ce qui est du coeur du système, je reste en testing, et encore seulement sur mes machines utilisateur (le serveur est en stable).

    • [^] # Re: Sid

      Posté par  . Évalué à 5.

      c'est pas faux mais il était en sid+experimental, pas juste sid

      • [^] # Re: Sid

        Posté par  . Évalué à 1.

        Exact, sid n'a vraiment rien à voir là dedans, et est absolument stable (en fait trop stable, en ce moment ça va, mais il y a un problème : quand ils freezent testing, sid bouge plus, et ça c'est n'importe quoi).

        Et si ça casse de temps en temps, c'est pas la mort.

    • [^] # Re: Sid

      Posté par  . Évalué à 3.

      Ça dépend. Je suis en testing, mais j'utilise souvent des noyaux Linux Sid et n'ai jamais de soucis.

      La plupart des problèmes que j'ai eu en utilisant Sid venaient des décalages de versions entre librairies et logiciel : le logiciel attend telle version particulière, mais celle-ci ne vient pas en dépendance et c'est la précédente qui est installée. Heureusement, c'est rapidement corrigé, mais on peut en faire les frais.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Sid

      Posté par  . Évalué à 1.

      Pas forcément vrai, j'ai jamais eu de problèmes bloquants depuis des années d'utilisation quotidienne (et sur une machine "de production" comme on dit) de Sid.

    • [^] # Re: Sid

      Posté par  . Évalué à 2.

      Sauf qu'en testing, tu peux attendre les corrections pendant des plombes. Faire rentrer un paquet dans testing est beaucoup plus long que dans sid. C'est bien pour éviter de casser les choses en allant trop vite, mais quand testing est cassée (à cause d'un bug qu'on n'a pas vu dans sid), elle met aussi longtemps à être réparée ...

Suivre le flux des commentaires

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