Comportement étrange de /sbin/init suite à restauration de backup
3 réponses
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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Damien Wyart
* Joe the Shmoe in fr.comp.os.linux.configuration:
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 <news@edrusb.is-a-geek.org> in fr.comp.os.linux.configuration:
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...
* Joe the Shmoe in fr.comp.os.linux.configuration:
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 07/06/2013 09:58, Damien Wyart a écrit :
* Joe the Shmoe in fr.comp.os.linux.configuration:
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
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.
Le 07/06/2013 09:58, Damien Wyart a écrit :
* Joe the Shmoe <news@edrusb.is-a-geek.org> in fr.comp.os.linux.configuration:
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
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ù ...
* Joe the Shmoe in fr.comp.os.linux.configuration:
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
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
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:
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:
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:
