Je suis un peu démuni devant ce problème alors je viens vers vous, au
cas où quelqu'un aurait une idée de génie.
Sur ma machine, gentoo, udev-058. Aucun problème.
Lors d'une mise à jour normale, il m'est proposé udev-068, j'accepte,
compilation, installation, etc-update j'accepte toutes les modifs.
Je lance udevstart pour voir, aucun message, tout roule.
Je reboote, udevstart : segmentation default
/dev n'est pas peuplé, donc le boot ne peut évidemment pas se poursuivre.
J'ai donc du 'downgrader' udev, mais cette solution ne me convient pas des
masses car il va bien falloir qu'un jour à l'autre, je passe à une
version supérieure de udev, et là, j'aurai à nouveau le problème.
De quoi cela peut-il venir selon vous ?
Je précise que j'ai tenté l'expérience 2 fois, en pensant que quelque
chose s'était peut-être mal passé à la compil.
Mon problème ne semble pas quelque chose de fréquent, en tout cas, je
n'en trouve pas de trace dans les forums gentoo.
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
Christophe PEREZ
Le Mon, 05 Sep 2005 10:08:32 -0400, Christophe PEREZ a écrit:
Mon problème ne semble pas quelque chose de fréquent, en tout cas, je n'en trouve pas de trace dans les forums gentoo.
La seule chose que j'ai trouvée qui me semble avoir un rapport est : http://bugs.gentoo.org/show_bug.cgi?id564
Et la seule solution que j'ai trouvée a été de commenter la ligne : KERNEL=="tpm*", NAME="%k", OWNER="tss", GROUP="tss", MODE="0600" dans 50-udev.rules (j'aurais pu aussi créer un user/group tss, mais comme je ne sais pas à quoi il correspond, ni même ce qu'est ce tpm*...)
Ça ne vient donc pas de ma config, mais d'un contexte très particulier. Par contre, je ne sais pas pourquoi mon serveur n'a pas eu le problème, alors que j'avais 2 postes en carafe pour la même raison. Probablement une option de config de noyau.
Je présume qu'une prochaine version de udev | nss_ldap | baselayout réglera le problème.
Si ça peut servir à quelqu'un...
-- Christophe PEREZ Écrivez moi sans _faute !
Le Mon, 05 Sep 2005 10:08:32 -0400, Christophe PEREZ a écrit:
Mon problème ne semble pas quelque chose de fréquent, en tout cas, je
n'en trouve pas de trace dans les forums gentoo.
La seule chose que j'ai trouvée qui me semble avoir un rapport est :
http://bugs.gentoo.org/show_bug.cgi?id564
Et la seule solution que j'ai trouvée a été de commenter la ligne :
KERNEL=="tpm*", NAME="%k", OWNER="tss", GROUP="tss", MODE="0600"
dans 50-udev.rules
(j'aurais pu aussi créer un user/group tss, mais comme je ne sais pas à
quoi il correspond, ni même ce qu'est ce tpm*...)
Ça ne vient donc pas de ma config, mais d'un contexte très particulier.
Par contre, je ne sais pas pourquoi mon serveur n'a pas eu le problème,
alors que j'avais 2 postes en carafe pour la même raison.
Probablement une option de config de noyau.
Je présume qu'une prochaine version de udev | nss_ldap | baselayout
réglera le problème.
Le Mon, 05 Sep 2005 10:08:32 -0400, Christophe PEREZ a écrit:
Mon problème ne semble pas quelque chose de fréquent, en tout cas, je n'en trouve pas de trace dans les forums gentoo.
La seule chose que j'ai trouvée qui me semble avoir un rapport est : http://bugs.gentoo.org/show_bug.cgi?id564
Et la seule solution que j'ai trouvée a été de commenter la ligne : KERNEL=="tpm*", NAME="%k", OWNER="tss", GROUP="tss", MODE="0600" dans 50-udev.rules (j'aurais pu aussi créer un user/group tss, mais comme je ne sais pas à quoi il correspond, ni même ce qu'est ce tpm*...)
Ça ne vient donc pas de ma config, mais d'un contexte très particulier. Par contre, je ne sais pas pourquoi mon serveur n'a pas eu le problème, alors que j'avais 2 postes en carafe pour la même raison. Probablement une option de config de noyau.
Je présume qu'une prochaine version de udev | nss_ldap | baselayout réglera le problème.
