Bonjour,
j'ai un souci moyen qui pourrait devenir gros à l'avenir.
Sur mon OS Linux custom (basé sur LFS), j'utilise simpleinit-msb.
Tout allait bien avec devfs. Aujourd'hui, tout le travail d'autoconfiguration et compagnie (dbus, hotplug, hal, ...) s'appuie sur udev, et devfs est déjà annoncé obsolète. Donc je suis passé à udev, et ça fonctionne bien.
Mais le problème, c'est que j'ai besoin d'un filesystem /dev avant d'appeler init (à priori). Pour l'instant, j'utilise devfs, c'est dans le noyau donc pas de souci, mais ça fait des clashs avec udev (difficulté à tester et problèmes divers), et devfs sera "bientôt" viré du noyau.
J'ai besoin de cela parce que le init de simpleinit-msb est très à cheval sur la sécurité de son initctl (qui se trouve dans /dev évidemment). Si je ne veux pas avoir un / constamment modifié, je dois mettre mon /dev dans son propre filesystem (en tmpfs je crois). Or, init étant le premier processus lancé, je me retrouve à cacher l'initctl. Du coup, plus aucun outil d'administration lié à init ne fonctionne correctement.
J'ai essayé de créer un /dev dans initrd, mais le mieux que j'ai réussi à faire, c'est tout booter, mais init se bloque ensuite avant de lancer les sessions getty.
J'ai essayé de scripter un init.udev (qui crée le /dev puis lance init) , mais apparemment, malgré un exec, simpleinit ne retrouve pas ses petits avec cette solution (pas de boot).
Quelqu'un a-t-il une solution ?
# Mon expérience sur SourceMage
Posté par tipote . Évalué à 1.
Je ne suis pas spécialiste dans le domaine, mais j'ai pris quelques minutes pour regarder comment c'est organisé :
- Je n'ai jamais compilé le support du devfs dans le noyau.
- J'ai un runlevel nommé "%DEV" qui est lancé en tout premier par simpleinit-msb, contenant un unique script qui s'occupe de udev :
Il monte /sys, /proc, puis un ramfs dans /dev. Voilà la fonction appelée dans ce fichier (udev_root est sur /dev/ dans udev.conf):
start_udev()
{ (
. /etc/udev/udev.conf
# mount sysfs
echo "Mounting sysfs at /sys"
mount -n -t sysfs none /sys
# mount proc
echo "Mounting /proc"
mount -n -t proc none /proc
echo "Mounting ramfs at $udev_root"
mount -n -t ramfs none $udev_root
# create some needed stuff
ln -s /proc/self/fd $udev_root/fd
ln -s /dev/fd/0 $udev_root/stdin
ln -s /dev/fd/1 $udev_root/stdout
ln -s /dev/fd/2 $udev_root/stderr
mkdir $udev_root/shm
mkdir $udev_root/pts
# propogate /udev from /sys - we only need this while we do not
# have initramfs and an early user-space with which to do early
# device bring up
echo "Creating initial udev device nodes"
/sbin/udevstart
if [ -f /etc/udev/udev.missing ]; then
echo "Processing /etc/udev/udev.missing"
cd /dev
while read line; do
if [ "${line:0:1}" == "#" ]; then continue; fi
for ((i=0; i<7; i++)); do
val[$i]=${line%%:*}
line=${line#*:}
done
if [ "${val[1]}" == "d" ]; then
mkdir ${val[0]}
else
mknod ${val[0]} ${val[1]} ${val[2]} ${val[3]}
fi
chmod ${val[4]} ${val[0]}
chown ${val[5]}:${val[6]} ${val[0]}
done < /etc/udev/udev.missing
cd /
fi
echo "Telling init to reopen file descriptors"
kill -USR1 1
echo "Starting udevd"
/sbin/udevd &
) }
L'init se poursuit ensuite avec les autres runlevels.
J'espère t'avoir été utile. N'hésite pas à demander des précisions.
[^] # Re: Mon expérience sur SourceMage
Posté par ookaze . Évalué à 1.
Tu m'as été extrêmement utile !!!
Je n'en reviens pas que ça m'ait échappé. Les lignes qui m'intéressent sont sans doute les suivantes :
J'avais pas pensé aux signaux.
Bon, je ne sais pas si cela va réellement résoudre mon problème avec le pipe nommé, mais il y a des chances. Faudra que je revois la doc en tout cas.
Merci beaucoup
[^] # Re: Mon expérience sur SourceMage
Posté par ookaze . Évalué à 1.
Je ne voulais pas en arriver à patcher simpleinit-msb, mais j'ai tout essayé, et rien ne fonctionne. De plus, SourceMage a patché simpleinit-msb pour arriver à ses fins (c'est pour cela que je n'avais pas de signal USR1).
Du coup, je vais faire pareil, ça reste le moins contraignant.
Merci encore
[^] # Re: Mon expérience sur SourceMage
Posté par tipote . Évalué à 1.
Bon courage !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.