Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Pourquoi l'option "splash" du chargement du noyau fait planter mon petit dém on ?

14 réponses
Avatar
Francois Lafont
Bonjour à tous,

Je suis sous Linux Ubuntu 9.04 et j'ai petit démon dont la
fonction "start" fonctionne parfaitement en ligne de
commande, mais ne fonctionne pas correctement lors du
démarrage du poste.

Par contre, si dans "/boot/grub/menu.lst", je désactive
l'option splash du chargement du noyau, c'est-à-dire que,
dans l'item du menu sélectionné par défaut de grub, je mets ceci

#------------------------------
kernel /boot/vmlinuz-2.6.28-18-generic
root=UUID=2028abef-28d5-4a55-960f-8e86ea99c82b ro quiet
#------------------------------

au lieu de cela (j'ai enlevé splash)

#------------------------------
kernel /boot/vmlinuz-2.6.28-18-generic
root=UUID=2028abef-28d5-4a55-960f-8e86ea99c82b ro quiet splash
#------------------------------

alors tout fonctionne correctement au démarrage, exactement
comme en ligne de commande (sans que je ne touche un iota de
mon script de démon).

Avez vous une explication ? Je serais très curieux d'avoir
le fin mot de l'histoire car j'ai passé une bonne semaine
sur mon démon croyant qu'il était incorrect alors que ce
n'est finalement pas le cas (enfin j'espère).

Si j'ai bien compris "splash" c'est juste une option pour
afficher une jolie image pendant le démarrage au lieu des
messages en noir et blanc un peu austères. Je ne vois pas
pourquoi cela aurait une incidence sur mon démon ?

Merci d'avance pour votre aide. :-)


Si plus de détails sont nécessaire, en voici.
Voici mon démon (il lance une machine virtuelle de Virtualbox) :

#------------------------------
#! /bin/sh
### BEGIN INIT INFO
# Provides: ztest
# Required-Start: $local_fs $remote_fs vboxdrv vboxnet
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: virtual machine
# Description: virtual machine hosted by VirtualBox
### END INIT INFO
#
# Author: Francois Lafont

PATH=/usr/sbin:/usr/bin:/sbin:/bin
NAME=ztest # le nom du fichier script
SCRIPTNAME="/etc/init.d/$NAME"
MANAGE_CMD=VBoxManage
START_CMD=VBoxHeadless
VM_OWNER=francois # le possesseur de la VM
VM_NAME="XPpro" # nom de la VM

# Pour faire un tracage du script
#set -x


# Pour lancer le demon
do_start()
{
# Return
# 0 --> le demon a demarre
# 1 --> le demon etait deja demarre
# 2 --> le demon n'a pas pu demarrer

# On verifie si la VM est deja en train de tourner
running=$(sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo
"$VM_NAME" | grep "^State:.*running" | wc -l)
if [ $running -eq 1 ]
then
echo " * $VM_NAME is already
running..............................[ OK ]"
return 1
fi

# Si elle n'est pas encore allumee, on la lance.
nohup sudo -H -u $VM_OWNER $START_CMD --startvm
"$VM_NAME" --vrdp off > /dev/null 2>&1 &

# On verifie que la VM est bien lancee.
sleep 2
running=$(sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo
"$VM_NAME" | grep "^State:.*running" | wc -l)
if [ $running -eq 0 ]
then
echo " * Failed to start
$VM_NAME..............................[ ERROR ]"
sleep 10 # Pour avoir le temps de voir le message
au demarrage
return 2
else
echo " * $VM_NAME
started..............................[ OK ]"
sleep 10 # Pour avoir le temps de voir le message
au demarrage
return 0
fi
}


# Pour arreter le demon
do_stop()
{
# sans intérêt pour le problème ici car c'est
# do_start qui est en cause
}

# Pour obtenir les statuts du demon
do_status()
{
sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo "$VM_NAME"
| grep "^State:"
}


case "$1" in
start)
do_start
;;
stop)
do_stop
;;
status)
do_status
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status}" >&2
exit 3
;;
esac
#------------------------------

Avec l'option splash, la VM est bien lancée mais quand je
tape /etc/init.d/mon_demon status, cela m'indique que la VM
est sur off. Ça pose problème car dans ce cas la fonction
do_stop() n'éteint pas la VM proprement vu qu'elle pense que
celle-ci est éteinte. En revanche, sans l'option splash,
tout marche parfaitement. Pourquoi ? Quel rapport ?



--
François Lafont

4 réponses

1 2
Avatar
Sergio
Le 10/05/2010 14:04, Francois Lafont a écrit :

J'ai lu le fil très en diagonale, mais je remarque que là :

# VBoxHeadless --startvm XPpro --vrdp off



XPpro n'est pas entre guillemets alors là :

# su francois -c "VBoxHeadless --startvm "XPpro" --vrdp off"



il l'est. A creuser ?



Hélas, je ne crois pas que le problème se situe là. En fait
les guillements, c'est au cas où le nom de la VM ait des
espaces, ce qui est indifférent dans mon cas vu que la VM
s'appelle XPpro.



Justement :

si tu mets --startvm XPpro ou --startvm "XPpro" le paramètre XPpro (sans guillemets) sera passé à virtualbox par le shell
si tu mets --startvm "XPpro" le paramètre "XPpro" (*avec* guillemets) sera passé à virtualbox par le shell. Et virtualbox
cherchera le répertoire de configuration "XPpro" (avec guillemets, donc) qui n'existe pas.


PS: Les fichiers de configuration des machines se trouvent dans ~/.VirtualBox/Machines avec un sous-répertoire par machine.

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Avatar
Francois Lafont
Sergio a écrit :

Justement :

si tu mets --startvm XPpro ou --startvm "XPpro" le paramètre XPpro (sans
guillemets) sera passé à virtualbox par le shell
si tu mets --startvm "XPpro" le paramètre "XPpro" (*avec* guillemets)
sera passé à virtualbox par le shell. Et virtualbox cherchera le
répertoire de configuration "XPpro" (avec guillemets, donc) qui n'existe
pas.



D'accord, mais je persiste à penser que le problème n'est
pas là. :-)

1) Déjà l'échappement des guillemets, je ne le fais pas
comme tu l'écris ci-dessus. J'utilise l'échappement ici :

su $VM_OWNER -c "nohup $START_CMD --startvm "$VM_NAME"
--vrdp off > /dev/null 2>&1 &"

qui devient

su francois -c "nohup VBoxHeadless --startvm "XPpro"
--vrdp off > /dev/null 2>&1 &"

ce qui revient à dire « exécute en tant que francois cette
commande là : nohup VBoxHeadless --startvm "XPpro" --vrdp
off >/dev/null 2>&1 & » et donc les guillemets ne sont pas
un problème.

2) Autre raison : comme je le disais au départ, le script
que j'ai mis dans mon tout premier message marche a) en
ligne de commande et b) au démarrage du PC à condition que
le noyau soit chargé sans l'option splah. Si j'avais un
problème avec les guillemets, ça ne marcherait jamais, je pense.

Pour être au clair sur ce dont on parle, je vous donne
ci-dessous la totalité de mon script. (Même si, dans mon
problème, on se moque complètement des fonctions do_stop et
do_status car c'est do_start qui est en cause.)

http://sisco.laf.free.fr/codes/MyVM.txt
(c'est le même script que dans mon premier message, sauf que
j'ai changé les "sudo" pour des "su" comme me l'a suggéré
Erwan David).


--
François Lafont
Avatar
Francois Lafont
Francois Lafont a écrit :

http://sisco.laf.free.fr/codes/MyVM.txt
(c'est le même script que dans mon premier message, sauf que j'ai changé
les "sudo" pour des "su" comme me l'a suggéré Erwan David).



Voici un lien vers le même code mais en couleur :
http://sisco.laf.free.fr/codes/MyVM.html

--
François Lafont
Avatar
Francois Lafont
Le 10/05/2010 16:23, Francois Lafont a écrit :

Francois Lafont a écrit :

Voici un lien vers le même code mais en couleur :
http://sisco.laf.free.fr/codes/MyVM.html



Bon, je conclus ce fil car on va dire que le problème est
résolu. Le script de démon donné en lien ci-dessus, quand il
était exécuté sous Ubuntu 9.04, :

* marchait très bien en ligne de commande ;

* marchait très bien lors du boot (en tant que démon) à
condition que l'option "splash" du chargement du noyau soit
désactivée ou que l'on tape "CTRL+ALT+F1" au moment du boot
pour voir tous les messages un peu austères sur l'écran en
fond noir.

* ne marchait pas correctement lors d'un boot classique sur
Ubuntu, c'est-à-dire avec l'option "splash".

J'ai upgradé ma distribution Ubuntu pour passer à la version
10.04, et là le même script fonctionne parfaitement dans
tous les cas.

Du coup, je n'aurai pas le fin mot de l'histoire, mais
disons que tout ceci m'incite à penser que mon script
n'était pas vraiment en cause, et que ça concerne plus les
arcanes d'Ubuntu. Du coup, je vais en rester là... :-)

Merci aux intervenants pour leur aide.
A+


--
François Lafont
1 2