Toshiba NB520, démarrage aléatoire

Le
BERTRAND Joël
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 ?

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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
mrr
Le #26335421
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/54c369d3$0$2880$
BERTRAND Joël
Le #26335425
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Sylvain L. Sauvage
Le #26335432
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 !?

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 o rdre de chargement,
ça signifierait que le problème dans le module serait de son
fait. Ce serait pas un peu tuer le messager ?

Un module n’a pas à se « vautrer lamentablement sur un
segfault » à cause d’une dépendance. Un module d oit ne pas se
charger si une dépendance manque. D’ailleurs, je doute qu⠀™un
module se charge s’il manque une dépendance…

--
Sylvain Sauvage

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
mrr
Le #26335464
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/54c3ac22$0$2334$
Sylvain L. Sauvage
Le #26335472
Le samedi 24 janvier 2015, 15:28:50 mrr a écrit :
[…]
> Un module n’a pas à se « vautrer lamentablemen t sur un
> segfault » à cause d’une dépendance. Un modu le 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é!



Ça n’est pas une suite logique. Ce sont deux affirmation s
d’intention (« quand on écrit un module noyau il faut … »)
suivies d’une remarque sur ce qui est (à savoir qu’ un module
noyau ne se charge pas s’il lui manque des dépendances).

Maintenant, si tu arrives, dans un cadre de fonctionnement
normal (c’est-à-dire sans changer le code d’udev, du noyau ou de
ses modules), à charger un module noyau un tant soit peu
standard (c’est-à-dire pas un module créé spé cifiquement dans ce
but) sans que ces dépendances ne soient déjà chargé es, juste
fais-le qu’on rigole ensemble.

--
Sylvain Sauvage

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
BERTRAND Joël
Le #26335576
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Publicité
Poster une réponse
Anonyme