Comportement étrange de /sbin/init suite à restauration de backup

Le
Joe the Shmoe
Bonjour à tous,

Suite à une restauration d'un système entier sur PC, le noyau passe bien
la main à /sbin/init mais celui-ci ne fait rien

Si j'ajoute "init=/bin/bash" dans les arguments passés au noyau depuis
Grub j'ai bien le shell et je peux faire manuellement ce qu'est sensé
faire init tel décrit dans /etc/inittab

Pour l'instant j'arrive donc à booter le système correctement mais avec
la rustine suivante:

/etc/inittab: mise en commentaire de la ligne suivante le reste inchangé
# si::sysinit:/etc/init.d/rcS

modification de grub pour qu'il passe l'argument init=/root/rustine au
noyau.

et ajout de /root/rustine qui n'est autre que ce script tout bête:

#!/bin/bash

/etc/init.d/rcS
exec /sbin/init 2


Bref, ça marche mais:
- ce n'est pas beau
- je ne comprends pas ce qui ne fonctionne pas dans l'état nominal

Si ça se trouve c'est une grosse évidence, mais là, franchement, je
sèche ! Merci pour toute suggestion de test ou toute explication.

Joe
maintenant dit "la rustine"
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Damien Wyart
Le #25464642
* Joe the Shmoe
Si ça se trouve c'est une grosse évidence, mais là, franchement, je
sèche ! Merci pour toute suggestion de test ou toute explication.



Quelques vérifications que tu peux faire :
http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00255.html

Sinon, si le système a été mis à jour, il y a peut-être eu des modifs
dans les scripts de démarrage qui sont nécessaires mais que tu n'as pas
si tu es reparti d'un backup...

--
DW
Joe the Shmoe
Le #25466062
Le 07/06/2013 09:58, Damien Wyart a écrit :
* Joe the Shmoe
Si ça se trouve c'est une grosse évidence, mais là, franchement, je
sèche ! Merci pour toute suggestion de test ou toute explication.



Quelques vérifications que tu peux faire :
http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00255.html





Merci, j'ai vérifié les points énoncés dans cette discussion et tout à
l'air conforme sur ce système. Par contre, dans autre article de ce fil,
Pascal Bourguignon suggère (merci à lui) de renommer /sbin/init en
/sbin/init.original et de crée ce script en lieu et place de /sbin/init

-----(/sbin/init)------------------------
#!/usr/bin/strace /sbin/init.original
-----------------------------------------

/sbin/init.original semble s'arrêter parce qu'il ne trouve pas le
fichier /proc/filesystems !?!!!

les traces se terminent par (copie à vue simplifiée):

open("/proc/filesystems", O_RDONLY|O_LARGEFILE) = -1 ENOENT ...
umask(022)
geteuid32()
getpid()
write(2, "Usage: init.original { -e VAR[=VAR] | ....")
exit_group(1)

Donc, là il doit me manquer une info concernant la séquence de démarrage
d'un système unix, quelqu'un peut me confirmer ceci:

Dans ma compréhension des choses le noyau monte le système de fichier
racine puis exécute /sbin/init qui se charge de faire le reste dont en
particulier de monter /proc ? Non ?

[pas de Ramdisk / pivot_root dans mon cas]

A noter toutefois que le comportement est différent avec la méthode de
Pascal Bourguignon, ici il semble que du fait que c'est strace qui porte
le PID 1 [appel à getpid() ne semble pas anodin ici] init s'arrête car
j'ai aussi droit dans ce cas là à un beau kernel_panic "Attempted to
kill init!"
alors que quand init est lancé directement je n'ai pas de kernel panic
(donc le processus init est toujours présent) et le noyau semble
toujours vivant (la touche "VerrNum" allume et eteinte bien la LED
correspondante du clavier par exemple).

Il me reste à regarder les sources d'init :-/

Sinon, si le système a été mis à jour, il y a peut-être eu des modifs
dans les scripts de démarrage qui sont nécessaires mais que tu n'as
pas si tu es reparti d'un backup...



en mettant un echo "dans init" à la première ligne de /etc/init.d/rcS je
vois bien ce message apparaître avec ma rustine, mais ce message
n'apparaît même pas avec le vrai init... donc il semble que le problème
soit avant les scripts de démarrage...

Il faut croire effectivement, il y a bien quelque chose qui a changé, je
ne crois pas à la magie ... mais je ne vois pas quoi ni où ...

a+
Joe la rustine.
Joe the Shmoe
Le #25470232
Hello,

Mon problème était dû au fait que /sbin/init a besoin d'un jeu minimum
de fichiers spéciaux et tubes nommés dans /dev (/dev/null et
/dev/initctl, principalement).

Avant la sauvegarde, le système démarrait normalement car sur le disque
racine avant que udev ne monte son pseudo-filesystem sur /dev, ce même
répertoire /dev contenait déjà en statique quelques entrées tel null, ce
qui permettait à init de démarrer puis de lancer udev entre autres. Une
fois udev activé ces fichiers sont cachés et inaccessibles depuis le
système et ne peuvent donc pas être sauvegardés.

les solutions:
- utiliser un boot en ramdisk (ce qui est généralement le cas de noyau
fournis par les différentes distributions)
- peupler le répertoire /dev d'entrées statiques (bof...)
- activer la fonctionnalité devtmpfs du noyau linux dans "Network
Devices / Generic Driver Options":

[*] Maintain a devtmpfs filesystem to mount at /dev
[*] Automount devtmpfs at /dev, after the kernel mounted the rootfs


Pour ce qui est de init, effectivement s'il n'a pas son PID égal à 1 il
se comporte comme telinit. Il existe cependant l'option "-i" (non
documentée) qui permet de forcer son comportement même s'il n'a pas son
PID à 1.

Ainsi, remplacer /sbin/init par le script suivant permet de voir ce qui
se passe sans modifier le comportement de init:

mv /sbin/init /sbin/init.original
cat > /sbin/init <<EOF
#!/usr/bin/strace /sbin/init.original -i
EOF
chmod 0755 /sbin/init

++
Joe ex la rustine.
Publicité
Poster une réponse
Anonyme