Considérons une debian/testing sur un netbook Toshiba NB520. Avec
jessie est venue la saleté systemd. Depuis, c'est une catastrophe. La
machine démarre aléatoirement. Le système démarre, mais quelque chose
coince après le lancement de systemd et provoque la disparition de la
console. Aucun jaloux, pas de console texte, pas de X. Mais la machine
est totalement accessible par ssh.
Chose étrange, j'ai bien :
Root bolzano:[/etc] > ps auwx | grep X
root 2108 0.0 0.2 59324 5296 ? D 09:59 0:00
/usr/bin/X :0 vt7 -nolisten tcp -auth
/var/lib/wdm/authdir/authfiles/A:0-5PLVUi
avec un superbe état D...
Je ne sais plus où chercher. Naturellement ni journalctl ni les logs ne
contiennent quelque chose d'utilisable.
Une idée ?
Merci d'avance,
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54C36049.5000909@systella.fr
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
mrr
On 24/01/2015 10:10, BERTRAND Joël wrote:
Bonjour à tous,
Considérons une debian/testing sur un netbook Toshiba NB520. Avec jessie est venue la saleté systemd. Depuis, c'est une catastrophe. La machine démarre aléatoirement. Le système démarre, mais quelque chose coince après le lancement de systemd et provoque la disparition de la console. Aucun jaloux, pas de console texte, pas de X. Mais la machine est totalement accessible par ssh.
Chose étrange, j'ai bien : Root bolzano:[/etc] > ps auwx | grep X root 2108 0.0 0.2 59324 5296 ? D 09:59 0:00 /usr/bin/X :0 vt7 -nolisten tcp -auth /var/lib/wdm/authdir/authfiles/A:0-5PLVUi
avec un superbe état D...
Je ne sais plus où chercher. Naturellement ni journalctl ni les logs ne contiennent quelque chose d'utilisable.
Une idée ?
Et si tu démarrais en "single user" (enfin, si tu peux et si tu peux pas, cela exclut X) et que tu lançais X manuellement, là tu auras peut-être des logs? En pensant bien sûr à rediriger la commande vers un fichier bien sûr.
Si tu n'as pas d'accès ssh, c'est parce que tu n'as pas de réseau ou parce que sshd n'est pas lancé ou encore autre ?
Je crois que c'est systemd qui s'occupe du réseau maintenant (je sais pas, j'ai wheezy), dans ce cas peut-être que systemd bloque quelque part? Y doit bien y avoir des logs queques part, ou mince alors... Ah et avec un boot cd (avec systemd si on veux vraiment comparer), ça marche ?
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/54c369d3$0$2880$
On 24/01/2015 10:10, BERTRAND Joël wrote:
Bonjour à tous,
Considérons une debian/testing sur un netbook Toshiba NB520. Avec
jessie est venue la saleté systemd. Depuis, c'est une catastrophe. La
machine démarre aléatoirement. Le système démarre, mais quelque chose
coince après le lancement de systemd et provoque la disparition de la
console. Aucun jaloux, pas de console texte, pas de X. Mais la machine
est totalement accessible par ssh.
Chose étrange, j'ai bien :
Root bolzano:[/etc] > ps auwx | grep X
root 2108 0.0 0.2 59324 5296 ? D 09:59 0:00
/usr/bin/X :0 vt7 -nolisten tcp -auth
/var/lib/wdm/authdir/authfiles/A:0-5PLVUi
avec un superbe état D...
Je ne sais plus où chercher. Naturellement ni journalctl ni les
logs ne contiennent quelque chose d'utilisable.
Une idée ?
Et si tu démarrais en "single user" (enfin, si tu peux et si tu peux
pas, cela exclut X) et que tu lançais X manuellement, là tu auras
peut-être des logs?
En pensant bien sûr à rediriger la commande vers un fichier bien sûr.
Si tu n'as pas d'accès ssh, c'est parce que tu n'as pas de réseau ou
parce que sshd n'est pas lancé ou encore autre ?
Je crois que c'est systemd qui s'occupe du réseau maintenant (je sais
pas, j'ai wheezy), dans ce cas peut-être que systemd bloque quelque part?
Y doit bien y avoir des logs queques part, ou mince alors...
Ah et avec un boot cd (avec systemd si on veux vraiment comparer), ça
marche ?
Merci d'avance,
JKB
--
mrr
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54c369d3$0$2880$426a74cc@news.free.fr
Considérons une debian/testing sur un netbook Toshiba NB520. Avec jessie est venue la saleté systemd. Depuis, c'est une catastrophe. La machine démarre aléatoirement. Le système démarre, mais quelque chose coince après le lancement de systemd et provoque la disparition de la console. Aucun jaloux, pas de console texte, pas de X. Mais la machine est totalement accessible par ssh.
Chose étrange, j'ai bien : Root bolzano:[/etc] > ps auwx | grep X root 2108 0.0 0.2 59324 5296 ? D 09:59 0:00 /usr/bin/X :0 vt7 -nolisten tcp -auth /var/lib/wdm/authdir/authfiles/A:0-5PLVUi
avec un superbe état D...
Je ne sais plus où chercher. Naturellement ni journalctl ni les logs ne contiennent quelque chose d'utilisable.
Une idée ?
Et si tu démarrais en "single user" (enfin, si tu peux et si tu peux pas, cela exclut X) et que tu lançais X manuellement, là tu auras peut-être des logs? En pensant bien sûr à rediriger la commande vers un fichier bien sûr.
Si tu n'as pas d'accès ssh, c'est parce que tu n'as pas de réseau ou parce que sshd n'est pas lancé ou encore autre ?
Je crois que c'est systemd qui s'occupe du réseau maintenant (je sais pas, j'ai wheezy), dans ce cas peut-être que systemd bloque quelque part? Y doit bien y avoir des logs queques part, ou mince alors... Ah et avec un boot cd (avec systemd si on veux vraiment comparer), ça marche ?
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/54c369d3$0$2880$
BERTRAND Joël
mrr a écrit :
On 24/01/2015 10:10, BERTRAND Joël wrote:
Bonjour à tous,
Considérons une debian/testing sur un netbook Toshiba NB520. Avec jessie est venue la saleté systemd. Depuis, c'est une catastrophe. La machine démarre aléatoirement. Le système démarre, mais quelque chose coince après le lancement de systemd et provoque la disparition de la console. Aucun jaloux, pas de console texte, pas de X. Mais la machine est totalement accessible par ssh.
Chose étrange, j'ai bien : Root bolzano:[/etc] > ps auwx | grep X root 2108 0.0 0.2 59324 5296 ? D 09:59 0:00 /usr/bin/X :0 vt7 -nolisten tcp -auth /var/lib/wdm/authdir/authfiles/A:0-5PLVUi
avec un superbe état D...
Je ne sais plus où chercher. Naturellement ni journalctl ni les logs ne contiennent quelque chose d'utilisable.
Une idée ?
Et si tu démarrais en "single user" (enfin, si tu peux et si tu peux pas, cela exclut X) et que tu lançais X manuellement, là tu auras peut-être des logs?
Cela démarre de la même façon, les consoles sont inactives.
En pensant bien sûr à rediriger la commande vers un fichier bien sûr.
Si tu n'as pas d'accès ssh, c'est parce que tu n'as pas de réseau ou parce que sshd n'est pas lancé ou encore autre ?
Tout fonctionne, sauf les consoles.
Je crois que c'est systemd qui s'occupe du réseau maintenant (je sais pas, j'ai wheezy), dans ce cas peut-être que systemd bloque quelque part? Y doit bien y avoir des logs queques part, ou mince alors... Ah et avec un boot cd (avec systemd si on veux vraiment comparer), ça marche ?
Il n'y a pas de lecteur de CD sur la bête. Mais j'ai trouvé entre temps la source du problème. Le module noyau DRM pour i915 se vautre lamentablement sur un segfault plus ou moins aléatoire. Je suppose que systemd ne lance pas toujours les choses dans le même ordre et qu'une dépendance n'est pas gérée correctement. J'ai repris un noyau un peu plus ancien et ça roule.
Comment dit-on ça, déjà ? Single point of failure ? :-P
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
mrr a écrit :
On 24/01/2015 10:10, BERTRAND Joël wrote:
Bonjour à tous,
Considérons une debian/testing sur un netbook Toshiba NB520. Avec
jessie est venue la saleté systemd. Depuis, c'est une catastrophe. La
machine démarre aléatoirement. Le système démarre, mais quelque chose
coince après le lancement de systemd et provoque la disparition de la
console. Aucun jaloux, pas de console texte, pas de X. Mais la machine
est totalement accessible par ssh.
Chose étrange, j'ai bien :
Root bolzano:[/etc] > ps auwx | grep X
root 2108 0.0 0.2 59324 5296 ? D 09:59 0:00
/usr/bin/X :0 vt7 -nolisten tcp -auth
/var/lib/wdm/authdir/authfiles/A:0-5PLVUi
avec un superbe état D...
Je ne sais plus où chercher. Naturellement ni journalctl ni les
logs ne contiennent quelque chose d'utilisable.
Une idée ?
Et si tu démarrais en "single user" (enfin, si tu peux et si tu peux
pas, cela exclut X) et que tu lançais X manuellement, là tu auras
peut-être des logs?
Cela démarre de la même façon, les consoles sont inactives.
En pensant bien sûr à rediriger la commande vers un fichier bien sûr.
Si tu n'as pas d'accès ssh, c'est parce que tu n'as pas de réseau ou
parce que sshd n'est pas lancé ou encore autre ?
Tout fonctionne, sauf les consoles.
Je crois que c'est systemd qui s'occupe du réseau maintenant (je sais
pas, j'ai wheezy), dans ce cas peut-être que systemd bloque quelque part?
Y doit bien y avoir des logs queques part, ou mince alors...
Ah et avec un boot cd (avec systemd si on veux vraiment comparer), ça
marche ?
Il n'y a pas de lecteur de CD sur la bête. Mais j'ai trouvé entre temps
la source du problème. Le module noyau DRM pour i915 se vautre
lamentablement sur un segfault plus ou moins aléatoire. Je suppose que
systemd ne lance pas toujours les choses dans le même ordre et qu'une
dépendance n'est pas gérée correctement. J'ai repris un noyau un peu
plus ancien et ça roule.
Comment dit-on ça, déjà ? Single point of failure ? :-P
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54C38481.9080107@systella.fr
Considérons une debian/testing sur un netbook Toshiba NB520. Avec jessie est venue la saleté systemd. Depuis, c'est une catastrophe. La machine démarre aléatoirement. Le système démarre, mais quelque chose coince après le lancement de systemd et provoque la disparition de la console. Aucun jaloux, pas de console texte, pas de X. Mais la machine est totalement accessible par ssh.
Chose étrange, j'ai bien : Root bolzano:[/etc] > ps auwx | grep X root 2108 0.0 0.2 59324 5296 ? D 09:59 0:00 /usr/bin/X :0 vt7 -nolisten tcp -auth /var/lib/wdm/authdir/authfiles/A:0-5PLVUi
avec un superbe état D...
Je ne sais plus où chercher. Naturellement ni journalctl ni les logs ne contiennent quelque chose d'utilisable.
Une idée ?
Et si tu démarrais en "single user" (enfin, si tu peux et si tu peux pas, cela exclut X) et que tu lançais X manuellement, là tu auras peut-être des logs?
Cela démarre de la même façon, les consoles sont inactives.
En pensant bien sûr à rediriger la commande vers un fichier bien sûr.
Si tu n'as pas d'accès ssh, c'est parce que tu n'as pas de réseau ou parce que sshd n'est pas lancé ou encore autre ?
Tout fonctionne, sauf les consoles.
Je crois que c'est systemd qui s'occupe du réseau maintenant (je sais pas, j'ai wheezy), dans ce cas peut-être que systemd bloque quelque part? Y doit bien y avoir des logs queques part, ou mince alors... Ah et avec un boot cd (avec systemd si on veux vraiment comparer), ça marche ?
Il n'y a pas de lecteur de CD sur la bête. Mais j'ai trouvé entre temps la source du problème. Le module noyau DRM pour i915 se vautre lamentablement sur un segfault plus ou moins aléatoire. Je suppose que systemd ne lance pas toujours les choses dans le même ordre et qu'une dépendance n'est pas gérée correctement. J'ai repris un noyau un peu plus ancien et ça roule.
Comment dit-on ça, déjà ? Single point of failure ? :-P
C’est une suite logique que je ne comprends pas : 1. un module noyau se plante ; 2. tu changes le noyau et ça remarche ; 3. et c’est la faute à systemd !?
Câest une suite logique que je ne comprends pas :
1. un module noyau se plante ;
2. tu changes le noyau et ça remarche ;
3. et câest la faute à systemd !?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/1822989.28JNolWrZ6@earendil
C’est une suite logique que je ne comprends pas : 1. un module noyau se plante ; 2. tu changes le noyau et ça remarche ; 3. et c’est la faute à systemd !?
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
mrr
On 24/01/2015 13:40, Sylvain L. Sauvage wrote:
Le samedi 24 janvier 2015, 12:39:45 BERTRAND Joël a écrit :
[…]
Un module n’a pas à se « vautrer lamentablement sur un segfault » à cause d’une dépendance. Un module doit ne pas se charger si une dépendance manque. D’ailleurs, je doute qu’un module se charge s’il manque une dépendance…
mdr! J'adore ta suite logique, là je me suis (gentiment) marré!
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/54c3ac22$0$2334$
On 24/01/2015 13:40, Sylvain L. Sauvage wrote:
Le samedi 24 janvier 2015, 12:39:45 BERTRAND Joël a écrit :
[…]
Un module n’a pas à se « vautrer lamentablement sur un
segfault » à cause d’une dépendance. Un module doit ne pas se
charger si une dépendance manque. D’ailleurs, je doute qu’un
module se charge s’il manque une dépendance…
mdr!
J'adore ta suite logique, là je me suis (gentiment) marré!
--
mrr
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54c3ac22$0$2334$426a34cc@news.free.fr
Le samedi 24 janvier 2015, 12:39:45 BERTRAND Joël a écrit :
[…]
Un module n’a pas à se « vautrer lamentablement sur un segfault » à cause d’une dépendance. Un module doit ne pas se charger si une dépendance manque. D’ailleurs, je doute qu’un module se charge s’il manque une dépendance…
mdr! J'adore ta suite logique, là je me suis (gentiment) marré!
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/54c3ac22$0$2334$
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/3212300.7VhGs8X8Dk@earendil
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
BERTRAND Joël
Sylvain L. Sauvage a écrit :
Le samedi 24 janvier 2015, 12:39:45 BERTRAND Joël a écrit :
[…] Mais j'ai trouvé entre temps la source du problème. Le module noyau DRM pour i915 se vautre lamentablement sur un segfault plus ou moins aléatoire. Je suppose que systemd ne lance pas toujours les choses dans le même ordre et qu'une dépendance n'est pas gérée correctement. J'ai repris un noyau un peu plus ancien et ça roule.
Comment dit-on ça, déjà ? Single point of failure ? :-P
C’est une suite logique que je ne comprends pas : 1. un module noyau se plante ; 2. tu changes le noyau et ça remarche ; 3. et c’est la faute à systemd !?
Non, ce n'est pas ce que j'ai écrit. Avec le _même_ noyau, un coup ça démarre, un autre coup ça se bauge. C'est seulement en approfondissant que je me suis rendu compte que le système partait en vrille à cause d'un service qui n'était pas démarré correctement.
En gros, si systemd révèle un problème avec un module parce qu’il changerait (on n’est même pas sûr) un ordre de chargement, ça signifierait que le problème dans le module serait de son fait. Ce serait pas un peu tuer le messager ?
Qu'on le tue ! (ça se voit tant que cela que je suis un anti-systemd ?)
Un module n’a pas à se « vautrer lamentablement sur un segfault » à cause d’une dépendance. Un module doit ne pas se charger si une dépendance manque. D’ailleurs, je doute qu’un module se charge s’il manque une dépendance…
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Sylvain L. Sauvage a écrit :
Le samedi 24 janvier 2015, 12:39:45 BERTRAND Joël a écrit :
[…]
Mais j'ai trouvé
entre temps la source du problème. Le module noyau DRM pour
i915 se vautre lamentablement sur un segfault plus ou moins
aléatoire. Je suppose que systemd ne lance pas toujours les
choses dans le même ordre et qu'une dépendance n'est pas
gérée correctement. J'ai repris un noyau un peu plus ancien
et ça roule.
Comment dit-on ça, déjà ? Single point of failure ? :-P
C’est une suite logique que je ne comprends pas :
1. un module noyau se plante ;
2. tu changes le noyau et ça remarche ;
3. et c’est la faute à systemd !?
Non, ce n'est pas ce que j'ai écrit. Avec le _même_ noyau, un coup ça
démarre, un autre coup ça se bauge. C'est seulement en approfondissant
que je me suis rendu compte que le système partait en vrille à cause
d'un service qui n'était pas démarré correctement.
En gros, si systemd révèle un problème avec un module parce
qu’il changerait (on n’est même pas sûr) un ordre de chargement,
ça signifierait que le problème dans le module serait de son
fait. Ce serait pas un peu tuer le messager ?
Qu'on le tue ! (ça se voit tant que cela que je suis un anti-systemd ?)
Un module n’a pas à se « vautrer lamentablement sur un
segfault » à cause d’une dépendance. Un module doit ne pas se
charger si une dépendance manque. D’ailleurs, je doute qu’un
module se charge s’il manque une dépendance…
Ne _devrait_ pas se charger...
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54C411AC.1060106@systella.fr
Le samedi 24 janvier 2015, 12:39:45 BERTRAND Joël a écrit :
[…] Mais j'ai trouvé entre temps la source du problème. Le module noyau DRM pour i915 se vautre lamentablement sur un segfault plus ou moins aléatoire. Je suppose que systemd ne lance pas toujours les choses dans le même ordre et qu'une dépendance n'est pas gérée correctement. J'ai repris un noyau un peu plus ancien et ça roule.
Comment dit-on ça, déjà ? Single point of failure ? :-P
C’est une suite logique que je ne comprends pas : 1. un module noyau se plante ; 2. tu changes le noyau et ça remarche ; 3. et c’est la faute à systemd !?
Non, ce n'est pas ce que j'ai écrit. Avec le _même_ noyau, un coup ça démarre, un autre coup ça se bauge. C'est seulement en approfondissant que je me suis rendu compte que le système partait en vrille à cause d'un service qui n'était pas démarré correctement.
En gros, si systemd révèle un problème avec un module parce qu’il changerait (on n’est même pas sûr) un ordre de chargement, ça signifierait que le problème dans le module serait de son fait. Ce serait pas un peu tuer le messager ?
Qu'on le tue ! (ça se voit tant que cela que je suis un anti-systemd ?)
Un module n’a pas à se « vautrer lamentablement sur un segfault » à cause d’une dépendance. Un module doit ne pas se charger si une dépendance manque. D’ailleurs, je doute qu’un module se charge s’il manque une dépendance…
