[Fwd: bootlogd : ioctl (/dev/ttyzf, TIOCCONS): Bad file descriptor]
2 réponses
Julien Valroff
-------- Message transféré --------
> De: Julien Valroff <julien-nospam@kirya.net>
> À: debian-user-french@lists.debian.org
> Objet: bootlogd : ioctl (/dev/ttyzf, TIOCCONS): Bad file descriptor
> Date: Sun, 06 Feb 2005 21:15:49 +0100
> Bonsoir !
>
> Sur 2 machines (un portable et un fixe), bootlogd ne démarre plus me
> donnant l'erreur citée en référence.
>
> Si j'en crois les dates des derniers journaux, cela doit correspondre
> aux dates d'installation de udev.
>
> Voici le résultat de mes différents tests :
> * /dev/ttyzf existe bien une fois le système en place (je ne saurais pas
> dire à quel moment il est créé)
>
> * avec une image de noyau Debian (kernel-image-2.6.10-1-k7 en
> l'occurence, tout fonctionne correctement)
> Je ne vois pas du tout à quelle option du noyau cela pourrait
> correspondre
>
> * j'ai mis à jour udev en installant la version en unstable (0.051-1)
> sans changement
>
> J'ai trouvé plusieurs rapports de bug ouverts (en particulier #265929,
> sans réponse, #256369 avec une réponse pas vraiment encourageante...)
> mais tous datent du milieu de l'année dernière (entre temps les paquets
> udev et initscripts ont été upgradés plusieurs fois)
C'était sans compter sur le Bug #240481, un peu plus vieux, qui comporte
un élément de réponse, ou plutôt un moyen de contourner le problème.
Dans mon cas, j'ai recompilé mon noyau avec CONFIG_LEGACY_PTYS=y et tout fonctionne de nouveau. Pourtant, il ne s'agit pas d'une réelle solution.
Dans le but de comprendre le problème, quelqu'un pourrait-il expliquer le passage suivant :
"mounting devpts to /dev/pts inside the udev init scripts fixes the problem and IMHO it looks like the correct thing to do anyhow."
Euh, pourtant, tout est indiqué dans le rapport de bogue que tu cites, non ?
the problem is that without CONFIG_LEGACY_PTYS a program (i.e. bootlogd) can open a pty only after devpts is properly mounted under /dev/pts. but right now we have the following:
S02mountvirtfs mounts devpts under the disk-based /dev.
(devpts est monté à partir du système /dev/ physique)
S04udev moves the disk-based /dev out of the way, mounts a memory-based fs on /dev and creates /dev/pts. but it does not mount devpts.
(udev masque le système /dev physique par sa propre arborescence, il crée /dev/pts, mais ne monte pas devpts)
S05bootlogd tries to open a new-style pty, but fails due to the missing devpts, then it tries an old-style /dev/ptsxx, but fails again because the kernel doesn't support them. boot messages are lost :(
(bootlogd tente d'utiliser devpts et échoue car celui-ci n'est plus visible)
S35mountall.sh or S35mountkernfs (depending on the setup) finally mount devpts under the memory-based /dev. from here on everything is normal.
(devpts est monté sur le /dev logiciel fourni par udev, mais c'est trop tard pour bootlogd).
mounting devpts to /dev/pts inside the udev init scripts fixes the problem and IMHO it looks like the correct thing to do anyhow.
Le contournement proposé (mais ce n'est pas une solution propre) est de monter devpts à la fin du script d'udev, bootlogd pourra alors y accéder sans soucis (il n'est pas non plus facile de créer proprement un script séparé car il n'y a pas de numéro entre S04 et S05 à moins de lui donner un nom dans l'ordre alphabétique entre S04u et S05b).
Fred
-- Comment poser les questions de manière intelligente ? http://www.gnurou.org/documents/smart-questions-fr.html Comment signaler efficacement un bug ? http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Dans mon cas, j'ai recompilé mon noyau avec CONFIG_LEGACY_PTYS=y et tout
fonctionne de nouveau.
Pourtant, il ne s'agit pas d'une réelle solution.
Dans le but de comprendre le problème, quelqu'un pourrait-il expliquer
le passage suivant :
"mounting devpts to /dev/pts inside the udev init scripts fixes the
problem and IMHO it looks like the correct thing to do anyhow."
Euh, pourtant, tout est indiqué dans le rapport de bogue que tu cites,
non ?
the problem is that without CONFIG_LEGACY_PTYS a program (i.e. bootlogd)
can open a pty only after devpts is properly mounted under /dev/pts. but
right now we have the following:
S02mountvirtfs mounts devpts under the disk-based /dev.
(devpts est monté à partir du système /dev/ physique)
S04udev moves the disk-based /dev out of the way, mounts a memory-based
fs on /dev and creates /dev/pts. but it does not mount devpts.
(udev masque le système /dev physique par sa propre arborescence, il
crée /dev/pts, mais ne monte pas devpts)
S05bootlogd tries to open a new-style pty, but fails due to the
missing devpts, then it tries an old-style /dev/ptsxx, but fails
again because the kernel doesn't support them. boot messages are
lost :(
(bootlogd tente d'utiliser devpts et échoue car celui-ci n'est plus
visible)
S35mountall.sh or S35mountkernfs (depending on the setup) finally
mount devpts under the memory-based /dev. from here on everything is
normal.
(devpts est monté sur le /dev logiciel fourni par udev, mais c'est trop
tard pour bootlogd).
mounting devpts to /dev/pts inside the udev init scripts fixes the
problem and IMHO it looks like the correct thing to do anyhow.
Le contournement proposé (mais ce n'est pas une solution propre) est de
monter devpts à la fin du script d'udev, bootlogd pourra alors y accéder
sans soucis (il n'est pas non plus facile de créer proprement un script
séparé car il n'y a pas de numéro entre S04 et S05 à moins de lui donner
un nom dans l'ordre alphabétique entre S04u et S05b).
Fred
--
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/documents/smart-questions-fr.html
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Dans mon cas, j'ai recompilé mon noyau avec CONFIG_LEGACY_PTYS=y et tout fonctionne de nouveau. Pourtant, il ne s'agit pas d'une réelle solution.
Dans le but de comprendre le problème, quelqu'un pourrait-il expliquer le passage suivant :
"mounting devpts to /dev/pts inside the udev init scripts fixes the problem and IMHO it looks like the correct thing to do anyhow."
Euh, pourtant, tout est indiqué dans le rapport de bogue que tu cites, non ?
the problem is that without CONFIG_LEGACY_PTYS a program (i.e. bootlogd) can open a pty only after devpts is properly mounted under /dev/pts. but right now we have the following:
S02mountvirtfs mounts devpts under the disk-based /dev.
(devpts est monté à partir du système /dev/ physique)
S04udev moves the disk-based /dev out of the way, mounts a memory-based fs on /dev and creates /dev/pts. but it does not mount devpts.
(udev masque le système /dev physique par sa propre arborescence, il crée /dev/pts, mais ne monte pas devpts)
S05bootlogd tries to open a new-style pty, but fails due to the missing devpts, then it tries an old-style /dev/ptsxx, but fails again because the kernel doesn't support them. boot messages are lost :(
(bootlogd tente d'utiliser devpts et échoue car celui-ci n'est plus visible)
S35mountall.sh or S35mountkernfs (depending on the setup) finally mount devpts under the memory-based /dev. from here on everything is normal.
(devpts est monté sur le /dev logiciel fourni par udev, mais c'est trop tard pour bootlogd).
mounting devpts to /dev/pts inside the udev init scripts fixes the problem and IMHO it looks like the correct thing to do anyhow.
Le contournement proposé (mais ce n'est pas une solution propre) est de monter devpts à la fin du script d'udev, bootlogd pourra alors y accéder sans soucis (il n'est pas non plus facile de créer proprement un script séparé car il n'y a pas de numéro entre S04 et S05 à moins de lui donner un nom dans l'ordre alphabétique entre S04u et S05b).
Fred
-- Comment poser les questions de manière intelligente ? http://www.gnurou.org/documents/smart-questions-fr.html Comment signaler efficacement un bug ? http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le mardi 08 février 2005 à 15:21 +0100, Frédéric Bothamy a écrit :
* Julien Valroff [2005-02-07 21:44] :
[...] > > Dans le but de comprendre le problème, quelqu'un pourrait-il explique r > le passage suivant : > > "mounting devpts to /dev/pts inside the udev init scripts fixes the > problem and IMHO it looks like the correct thing to do anyhow."
Euh, pourtant, tout est indiqué dans le rapport de bogue que tu cites, non ?
Oui, relativement clair, merci en tout cas pour cette petite explication de texte ;-)
[...]
mounting devpts to /dev/pts inside the udev init scripts fixes the problem and IMHO it looks like the correct thing to do anyhow.
Le contournement proposé (mais ce n'est pas une solution propre) est de monter devpts à la fin du script d'udev, bootlogd pourra alors y accé der sans soucis (il n'est pas non plus facile de créer proprement un script séparé car il n'y a pas de numéro entre S04 et S05 à moins de lui donner un nom dans l'ordre alphabétique entre S04u et S05b).
C'est justement sur ce point que je buttais. Je croyais comprendre que cette solution était "plus propre" que celle que mettre CONFIG_LEGACY_PTYS=y dans les options du noyau ; cette impression est renforcée par l'aide du menu de configuration du noyau : "This scheme has a number of problems, including security. This option enables these legacy devices; on most systems, it is safe to say N."
C'est pour cela que je demandais des avis contradictoires sur le sujet. Bien sûr, il s'agit d'une station de travail, la sécurité n'a pas à avoir le même niveau que celle d'un serveur en production.
Il s'agit plus de curiosité qu'autre chose ;-)
Qu'en pensent les autres ?
@+ Julien
--=-yxSptP9fs1XWzwsQMCuM Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?numériquement?= =?ISO-8859-1?Q?_signée? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux)
[...]
>
> Dans le but de comprendre le problème, quelqu'un pourrait-il explique r
> le passage suivant :
>
> "mounting devpts to /dev/pts inside the udev init scripts fixes the
> problem and IMHO it looks like the correct thing to do anyhow."
Euh, pourtant, tout est indiqué dans le rapport de bogue que tu cites,
non ?
Oui, relativement clair, merci en tout cas pour cette petite explication
de texte ;-)
[...]
mounting devpts to /dev/pts inside the udev init scripts fixes the
problem and IMHO it looks like the correct thing to do anyhow.
Le contournement proposé (mais ce n'est pas une solution propre) est de
monter devpts à la fin du script d'udev, bootlogd pourra alors y accé der
sans soucis (il n'est pas non plus facile de créer proprement un script
séparé car il n'y a pas de numéro entre S04 et S05 à moins de lui donner
un nom dans l'ordre alphabétique entre S04u et S05b).
C'est justement sur ce point que je buttais. Je croyais comprendre que
cette solution était "plus propre" que celle que mettre
CONFIG_LEGACY_PTYS=y dans les options du noyau ; cette impression est
renforcée par l'aide du menu de configuration du noyau :
"This scheme has a number of problems, including security. This option
enables these legacy devices; on most systems, it is safe to say N."
C'est pour cela que je demandais des avis contradictoires sur le sujet.
Bien sûr, il s'agit d'une station de travail, la sécurité n'a pas à
avoir le même niveau que celle d'un serveur en production.
Il s'agit plus de curiosité qu'autre chose ;-)
Qu'en pensent les autres ?
@+
Julien
--=-yxSptP9fs1XWzwsQMCuM
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Ceci est une partie de message
=?ISO-8859-1?Q?numériquement?= =?ISO-8859-1?Q?_signée?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Le mardi 08 février 2005 à 15:21 +0100, Frédéric Bothamy a écrit :
* Julien Valroff [2005-02-07 21:44] :
[...] > > Dans le but de comprendre le problème, quelqu'un pourrait-il explique r > le passage suivant : > > "mounting devpts to /dev/pts inside the udev init scripts fixes the > problem and IMHO it looks like the correct thing to do anyhow."
Euh, pourtant, tout est indiqué dans le rapport de bogue que tu cites, non ?
Oui, relativement clair, merci en tout cas pour cette petite explication de texte ;-)
[...]
mounting devpts to /dev/pts inside the udev init scripts fixes the problem and IMHO it looks like the correct thing to do anyhow.
Le contournement proposé (mais ce n'est pas une solution propre) est de monter devpts à la fin du script d'udev, bootlogd pourra alors y accé der sans soucis (il n'est pas non plus facile de créer proprement un script séparé car il n'y a pas de numéro entre S04 et S05 à moins de lui donner un nom dans l'ordre alphabétique entre S04u et S05b).
C'est justement sur ce point que je buttais. Je croyais comprendre que cette solution était "plus propre" que celle que mettre CONFIG_LEGACY_PTYS=y dans les options du noyau ; cette impression est renforcée par l'aide du menu de configuration du noyau : "This scheme has a number of problems, including security. This option enables these legacy devices; on most systems, it is safe to say N."
C'est pour cela que je demandais des avis contradictoires sur le sujet. Bien sûr, il s'agit d'une station de travail, la sécurité n'a pas à avoir le même niveau que celle d'un serveur en production.
Il s'agit plus de curiosité qu'autre chose ;-)
Qu'en pensent les autres ?
@+ Julien
--=-yxSptP9fs1XWzwsQMCuM Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?numériquement?= =?ISO-8859-1?Q?_signée? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux)
