Sequence de boot spécifique avec insserv sous Squeeze

Support Debian
#1

Bonjour, je suis un vieil utilisateur de debian, mais là je crois que je suis trop vieux, je ne trouve plus la doc… alors je viens demander conseil.
L’histoire c’est le passage du système de boot sysV (que je maîtrise a peu près) à un nouveau système. J’ai une machine à installer, qui a une sequence de boot bidouillée. Le truc n’ayant pas d’écran ni de console série, j’utilise bootlogd et espeak pour donner l’état de la machine à des moments-clés. Le “concept” a fonctionné sur base de Lenny.
Je veux le porter vers Squeeze, et là, problème, je ne sais pas comment spécifier un ordre exact pour certains scripts.
(Ex: [espeak ‘Je lance le réseau’]->[networking]->[espeak ‘Mon IP est X.X.X.X’] ou bien: [stop-bootlogd]->[publier-bootlogd])

Je boote avec CONCURRENCY=“none” à peu-près correctement mais ça n’est pas tout à fait ça. Je ne veux pas vraiment aller vers le mode “legacy” vu que Wheezy va laisser tomber le séquencement sysV, d’après ce que je lis.

Je n’ai trouvé jusqu’ici que des docs obsolètes et contradictoires. X-Start-Before: me va bien mais X-Start-After: me manque. $all est bien sympa, mais les services qui s’y réfèrent sont tassés en désordre, et spécifier entre eux au-delà de “Require-Start: $all” crée des références circulaires. Un ordonnancement custom sur un script via sysv-rc-conf (ex: S99xxxx) semble détruit à toute invocation ultérieure de insserv. Etc.

Bref. Comment fait-on pour spécifier précisément une séquence / placer des points de passage séquentiels avec le système de boot nouvelles normes. Ceci avec le minimum de modif par rapport aux scripts standards ?

Merci pour toute info.

#2

Salut epoch,
d’après ce que j’ai lu, debian va implémenter insserv, qui est une évolutions de systemV. J’aurais préféré systemd, mais bon …
D’après ce que j’ai compris, tout les scripts de démarrage doivent être modifiés afin d’y inclure les dépendances de boot.
wiki.debian.org/LSBInitScripts/D … yBasedBoot
Il ne te reste plus qu’a modifier tout tes scripts …
Sans console série, pas évident à débugger.
essaie peut étre bootchart
packages.debian.org/fr/sid/bootchart
Tu as au moins un accès ssh sur cette machine ? sinon installe un écran sur port usb (ça fait un peu marteau pilon …)

#3

Merci de ta réponse :slightly_smiling:
Oui j’ai la machine sous la main, elle est juste “headless” en production mais comme pour le moment on n’est est pas encore j’ai clavier - écran.
J’ai déjà vu la page de wiki que tu as mise en lien. C’est pour avoir plus d’info que j’étais venu vous voir :wink: Si je comprends ce que tu dis, tu vas dans mon sens, et ça sent pas bon : si je veux un boot custom bien “rigide”, il faut recopier tous les headers LSB dans le répertoire “overrides”, et se re-tartiner les champs, pour tous les fichiers.
Si c’est bien le cas, par rapport à l’ancien temps où on rajoutait un unique fichier avec le bon numéro d’ordre, la régression est franchement massive.
(J’avais pensé à créer des targets spéciales -des trucs à moi en plus de $local_fs, $all …- mais j’ai le sentiment que ça ne sera pas suffisant pour résoudre mon besoin de couplage fort et d’ordonnancement entre certains scripts.)

Donc plutôt que de tout me repalucher, j’ai désactivé le mode de boot parallèle. Avec concurrency=none, le boot s’effectue dans l’ordre lexicographique des liens.
Après, la question reste comment empêcher insserv de se déchainer sur mes liens à numéros custom et de regénérer des liens tout neufs (et pas corrects) à chaque install-désinstall d’un paquet.
A ça je n’ai pas trouvé de réponse claire. Lancer insserv à la main détruit tout, c’est sûr. Mais, peut être pas un effet de bord de la présence du Concurrency=none, je crois que mes installs de paquet sur Squeeze ne lancent plus insserv (ou en tout cas la re-génération des liens.)

Pour une install de serveur, c’est franchement pourri comme situation. M’enfin en attendant mieux…

Quant j’aurai le temps j’essaierai “file-rc” dans une VM. J’ai peur que file-rc soit désormais lié à insserv. Mais la perspective de pouvoir bidouiller un fichier texte m’intrigue. J’espère aussi qu’il y aura bien un gars de chez IBM qui va expliquer aux devs qu’on n’attend pas la même chose du boot d’un serveur que de celui d’un téléphone.

Si je progresse je posterai.

#4

ma réflexion n’est pas allé aussi loin que la tienne. J’avais compris que si on ne mettait rien dans les en-tête LSB des scripts, ça se passait comme avant. Pour les 2 scripts qui me concernait, ça ne posait pas de problème.
Mais apparemment j’avais tord, c’était un coup de chance si ça marchait.