Le Bottin des Jeux Linux

Articles avec le tag ‘Déboires’

Le 27 août dernier, dans le cadre de mon papier « REX Sysvinit vs Systemd-sysv », je vous parlais d’un souci avec mon contrôleur USB.

Rappel des faits (reprise de l’article) :

« (…) En ce moment mon PC de production a des soucis avec les ports USB au démarrage. J’ai des messages du type « usb 8-1 : device descriptor read/64, error -110″ (répété plusieurs fois) puis « usb 8-1 : device descriptor read/8, error -110″ puis « MCFG at e00000000 is not E820 reserved » accompagnés de longues pauses au boot. Une fois qu’il est parvenu sous gdm, je n’ai plus accès ni au clavier ni à la souris pendant 1 minute ou deux et ensuite tout redevient normal / fonctionne correctement jusqu’au prochain redémarrage. J’avais évidemment pensé à systemd-sysv mais le PC présente les mêmes symptômes en démarrant avec plusieurs (j’en ai testé 2) vieux CD de démarrage Debian (il faudrait que je télécharge un CD plus récent mais mes soucis de démarrages avec Debian s’étaient arrêtés avec la suppression de lilo et la stabilisation de grub/grub2). J’ai lu sur le net que certains avaient réglé le problème tout simplement en débranchant physiquement le cordon d’alimentation du PC (problème électrique ?). Chez moi çà n’a pas fonctionné, j’ai toujours cette anomalie (carte mère ASUS avec problème de contrôleur USB ?). A suivre … »

La perte du contrôle des périphériques USB était systématique pendant toute la phase de boot, ensuite les périphériques USB redevenaient disponibles après 1 minute et 1 à 2 secondes (une précision assez étonnante) à partir de l’apparition de la mire gdm (j’avais testé la durée en m’amusant à appuyer x fois sur la touche « Verr Num » jusqu’à ce que le voyant s’allume).

Et puis ce matin, après une bonne vingtaine de redémarrages et de tests (on est content de ne plus être sous ext3 ) j’ai trouvé d’où venait ce satané souci : mon scanner EPSON Perfection 3490 est visiblement entrain de rendre l’âme. Je n’ai aucun moyen de tester électriquement ce qu’il envoi sur le port USB de mon PC, mais çà ne doit pas être joli.

Le constat est sans appel : lorsque je débranche son câble, les messages « usb 8-1 : device descriptor read … » disparaissent aussitôt, le PC redevient véloce et je récupère le contrôle du clavier (dès la mire grub; Sans clavier c’était assez gênant) et de la souris (dès le démarrage de gdm).

Le souci était assez vicieux car je n’utilise pas beaucoup mon scanner (une photocopie de temps en temps) et en dépit de ce souci électrique, j’arrivais à le faire fonctionner à force d’initialisations (je suspectais à tort un souci avec le driver).

Donc si vous avez un message au boot du type « usb 8-1 : device descriptor read/ » et/ou que vous n’avez plus accès à votre clavier : débranchez un à un vos périphériques USB et vérifiez au boot que les messages disparaissent !

Ouuuuf !

Sous ce titre barbare je tenais à vous faire profiter de mon retour d’expérience d’amateur sur ma petite mésaventure avec le paquet systemd-sysv (à ne pas installer dans l’immédiat selon moi).

Attention, la suite de cet article risque de provoquer le sourire/l’hilarité chez certains spécialistes .

Suite à la lecture des excellents articles « jchroot : chroot avec isolation améliorée » de Vincent Bernat et « Linux Évolutions techniques de systemd » de Sébastien Koechlin sur LinuxFR, en bon inconscient – tête brûlée de l’informatique que je suis, je me suis dit « tiens, çà a l’air pas mal systemd, on va tester çà ! ». Compte-rendu de mes déboires d’amateur …

Donc avec la prudence qui me caractérise, j’installe çà sur mon PC « de production » (du Bottin) puis sur le PC du gamin …

Résultat : si sur mon PC de production çà à fonctionné mais avec des pauses du système sous KDE, en revanche le PC du gamin est complètement planté depuis une semaine (nous en avons un autre mais il est moins bien) car je n’ai pas eut le temps/l’envie de m’en occuper tout de suite (il nous fait un arrêt cardiaque docteur, il va falloir jouer du chroot).

En fait, ne jetons pas le bébé avec l’eau du bain : le souci venait de systemd-sysv. Ce paquet désinstalle sysvinit (du fait des dépendances). Aujourd’hui, je vous écrit de mon PC de production (et tout fonctionne correctement) sur lequel sont installés les paquets : systemd, systemd-gui, sysvinit et sysvinit-utils !

Bon avouons-le : là je n’ai pas fais exprès, suite à mes soucis que j’avais assimilé à systemd je croyais avoir désinstallé ce dernier au profit d’un retour à sysvinit et en fait, en réinstallant ce dernier je n’avais désinstallé que systemd-sysv, c’est vous dire le pro que je suis .

Aujourd’hui donc, tout fonctionne correctement et je ne sais pas si mon système démarre avec sysvinit (je pense que oui mais n’en suis pas sûr) ou systemd, puisque les deux sont installés.

Quels étaient les symptômes de systemd-sysv/la désinstallation de sysvinit sur mon PC de production ? Le démarrage semblait (mais ce n’est qu’une impression) plus rapide mais avec beaucoup moins de messages lors du boot (un peu inquiétant au début car on a l’impression que le PC est planté, alors qu’il semble qu’il démarre en multi-tâches, mais là je ne suis pas sûr de ces derniers propos). Une fois démarré et sous KDE, tout semblait fonctionner mais à l’inverse du boot, j’avais l’impression que mon système redevenait mono-tâche pour certaines prestations. Je m’explique : à la fin d’un téléchargement d’un fichier (avec firefox) tout se figeait une dizaine de secondes puis repartait. Sous Synaptic j’ai aussi eut un ou deux plantages à l’installation (tout était figé) que l’on pourrait peut-être attribuer à systemd-sysv. J’ai quand-même tourné quelques jours avec systemd-sysv le temps d’identifier / de m’assurer que le souci venait de ce paquet et c’est les seuls symptômes que j’ai remarqué et que je puis attribuer à l’installation de ce paquet (j’ai d’autres soucis avec mes ports USB mais je ne pense pas que cela vienne de cela).

Donc à présent – je me répète (pour ce qui suit), tout fonctionne bien avec systemd, systemd-gui, sysvinit et sysvinit-utils installés.

Autres soucis – à déconnecter du message ci-dessus :

En ce moment mon PC de production a des soucis avec les ports USB au démarrage. J’ai des messages du type « usb 8-1 : device descriptor read/64, error -110″ (répété plusieurs fois) puis « usb 8-1 : device descriptor read/8, error -110″ puis « MCFG at e00000000 is not E820 reserved » accompagnés de longues pauses au boot. Une fois qu’il est parvenu sous gdm, je n’ai plus accès ni au clavier ni à la souris pendant 1 minute ou deux et ensuite tout redevient normal / fonctionne correctement jusqu’au prochain redémarrage. J’avais évidemment pensé à systemd-sysv mais le PC présente les mêmes symptômes en démarrant avec plusieurs (j’en ai testé 2) vieux CD de démarrage Debian (il faudrait que je télécharge un CD plus récent mais mes soucis de démarrages avec Debian s’étaient arrêtés avec la suppression de lilo et la stabilisation de grub/grub2 ). J’ai lu sur le net que certains avaient réglé le problème tout simplement en débranchant physiquement le cordon d’alimentation du PC (problème électrique ?). Chez moi çà n’a pas fonctionné, j’ai toujours cette anomalie (carte mère ASUS avec problème de contrôleur USB ?). A suivre …

Bon, l’information n’est pas nouvelle (et même franchement réchauffée, puisque LINUX.FR en parlait déjà en 2004), mais je le découvre en 2011 grâce au billet de Raphaël Hertzog « 5 raisons pour lesquelles Debian unstable ne mérite pas son nom ».

C’est quoi « Apt-listbugs » ?

Selon le wiki du paquet, « Ce paquet disponible dans les dépôts permet de se prémunir, pour ceux qui sont en testing ou instable, de l’installation d’un paquet « bugué ». Il est très simple d’installation et d’utilisation !  »

Comment à marche ?

Vous installez apt-listbugs (en dépôts) c’est tout. Par la suite, à chaque fois que vous installerez un nouveau paquet, apt-listbugs va consulter la base de données des bogues des paquets Debian et vous signaler en console (sous Synaptic si vous voyez que l’installation ne progresse plus, cliquez sur « Informations détaillées ») s’il est bogué. Vous aurez alors le choix de marquer la version de ce paquet (il vous faudra ensuite quitter votre mise à jour pour que ce marquage soit effectif), d’interrompre votre mise à jour ou de l’installer tout de même. En cas de marquage du paquet, celui-ci ne vous sera présenté à la mise à jour qu’en cas de nouvelle version.

Et çà marche ?

Nous avons attendu un peu avant de rédiger ce billet de voir l’outil à l’œuvre. Il nous a signalé tout à l’heure un bogue avec gedit. Nous l’avons installé malgré tout et … gedit fonctionne . Mais nous ne doutons pas du bogue, il n’est simplement pas visible au 1er lancement.

C’est fiable ?

Cela nécessite évidemment que les bogues soient répertoriés mais c’est déjà une sacré bonne idée de nous signaler au moins ceux qui sont répertoriés.

Nous vous suggérons fortement la lecture des 3 liens énoncés ci-avant : très intéressants !