Plantage kernel au boot

Support Debian
#1

Bonjour,
j’ai besoin d’aide pour débloquer un probléme.
J’ai installé une stable sur un dreamplug (archi ARM). Tout est OK.
Je fais l’upgrade vers le kernel 2.6.38, tout est OK.
puis j’upgrade vers testing, et les ennuis commencent. Premier blocage au boot sur ce qui ressemble à un help d’ALSA. Je vire ALSA en chrootant, et maintenant le boot se bloque sans message d’erreur particulier:

puis plus rien.
Une idée pour trouver un indice ?
Une option à passer au kernel au boot pour qu’il soit plus bavard ?

#2

Supprimer le paramètre “quiet” de la ligne de commande du noyau dans la configuration du chargeur d’amorçage évite de masquer les messages du noyau.

Mais le message “Setting kernel variables” ne provient pas du noyau mais du script d’init /etc/init.d/procps lorsqu’il configure les variables du noyau (/proc/sys/) à partir des fichiers /etc/sysctl.conf et /etc/sysctl.d/*.conf. Le “done” indique qu’il se termine correctement. C’est peut-être un des scripts suivants qui bloque, voir la séquence dans /etc/rcS.d.

#3

Merci pour la piste, je vais creuser.
Pour info, c’est une archi ARM, lancement d’un kernel uImage par uboot, il n’y a pas d’option quiet.

#4

Le script suivant est lié à udev (S12udev-mtab ). Il semblerait que ce soit lui qui bloque.
Si je connecte une clef USB, j’ai des messages dans la console, mais pas d’action possible.
Est il possible de réinstaller udev depuis un chroot ,
Y a t il un problème de compatibilité entre le kernel 2.6.38 et la version udev de la testing ?

édit: en regardant de plus pret le contenu du script en question:

Ce serait ma partition racine qui serait corrompue …

#5

fausse piste. J’ai mis un echo en fin et en début de script, et ça passe.
IL va falloir que je fasse ça pour tout les scripts suivants …

#6

J’ai peut étre un début de réponse à l’origine de mon problème
http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html

Les scripts sont en train de migrer de rcS.d vers les rcX.d des runlevels correspondants.
Pour l’instant, j’ai tracé que tout s’exécutait bien jusqu’au script S18stop-bootlogd-single
Ca commence bien, jusqu’à


DAEMON=/sbin/bootlogd

[ -x "$DAEMON" ] || exit 0

Je ne comprends pas cette ligne de code, si quelqu’un pouvait m’éclairer
nota: /sbin/bootlogd n’existe pas

#7

La ligne de code signifie :
“si /sbin/bootlogd n’est pas exécutable alors terminer le script avec le code retour 0”

Si /sbin/bootlogd n’existe pas sur ta machine, alors il n’est évidemment pas exécutable et le script se termine. C’est peut-être pour cela que le echo que tu as mis en fin de script ne s’affiche pas. Je ne pense pas que le problème vienne de là. Essaie d’instrumenter le script suivant.

Jusqu’à l’actuelle stable Squeeze, /sbin/bootlogd était dans le paquet sysvinit-utils, et /etc/init.d/bootlogd dans le paquet initscripts en tant que conffile. Mais dans l’actuelle testing Wheezy, ils ont été regroupés dans un nouveau paquet bootlogd.

#8

Merci pour ces infos.
C’était le dernier script de rcS.d
bootlogd n’est pas installé sur la machine x86 en testing sans que cela pose de problème. Si je peux m’en passer, je ne l’installerais pas sur la machine ARM, car la place mémoire est très limitée.

Dans la séquence de boot, que se passe t il après rcS.d ? Si j’ai bien compris, ça part sur les scripts rcX.d, avec x étant le runlevel. Mais lequel est lancé après rcS.d ?

nota; j’ai déja réinstallé tout les paquets sysv (-rc , init, init-utils) en chroot sans succés.

#9

bootlogd n’est absolument pas indispensable. D’ailleurs il est désactivé par défaut.

Normalement, le runlevel par défaut dans Debian est le 2.
Tu n’as pas le message “INIT: Entering runlevel: 2” ?

#10

Je pers la trace pour l’instant en entrée de S18stop-bootlogd-single, aprés, plus rien.
Je vais regarder /etc/inittab qui semble décrire la sequence suivie au boot.
Chaque redémarrage est un peu long sur ce système (couper et remettre l’alim, changer les paramètres de uboot …)

#11

Tu peux essayer de démarrer en mode single, en ajoutant “single” à la ligne de commande du noyau, pour voir si tu arrives bien à la fin du runlevel S et à la demande du mot de passe root. En appuyant sur Ctrl+d pour poursuive avec le runlevel par défaut, la ligne “INIT: Entering runlevel: n” devrait s’afficher en premier.

#12

Je n’ai pas trouvé coment passer l’argument “single” au kernel via uboot.
J’ai essayé init=/bon/bash
J’ai bien une connexion en root, mais elle est très limitée.

#13

Comment as-tu passé cette option ? Il suffit de remplacer “init=/bin/bash” par “single”.

#14

Je l’ai ajoutée à la ligne bootargs de uboot.
Dans la liste des arguments acceptés par uboot, je n’ai pas vu l’option “single”

#15

Je ne connais pas uboot, mais il ne donne pas la possibilité d’ajouter n’importe quelle option arbitraire à la ligne de commande du noyau comme lilo ou grub ?

#16

j’ai ajouté S comme option de boot au kernel, qui doit nomalement le faire démarrer en single.
Mais même résultat, plus rien aprés bootlogd

#17

Quelqu’un sait il ce qu’il est supposé se passer après exécution des scripts de rcS.d ?

#18

Lors d’un démarrage en mode normal, l’entrée dans le runlevel final (2 par défaut pour Debian) et l’exécution des scripts correspondants.
Lors d’un démarrage en mode “single”, la demande du mot de passe root.

#19

Bonsoir Pascal,
mais quel script fait ça ?
quel est le cheminement à la fin des scripts de rcS.d ?
Je susi logué en init=/bin/bash, j’ai des accés très limité, mais je peux éditer des fichiers avec nano pour suivre l’éxécution des scripts.

#20

Eh, je ne sais pas tout !
D’après /etc/inittab, ça semble être /etc/init.d/rcS et /etc/init.d/rc.