Reprise du message précédent :

L'UEFI est un poil lent...

systemd-analyze ne donne qu'à partir du kernel :

Comment tu fais pour avoir ce qui se passe avant ?

Tu as installé en MBR ou en GPT ?

Enfin, c’est bien gentil, de comparer vos temps de démarrage. Mais c’était pas ma question, et ça m’aide pas à voir où le lancement de XFCE coince, chez moi… Je serais prêt à parier qu’il doit y avoir aussi un souci avec nouveau (le PC qui met du temps à ouvrir une session XFCE a une carte Nvidia plus prise en charge, alors que l’autre PC qui n’a pas ce problème a un GPU AMD). Maintenant, est-ce que ça peut être réglé, ou dois-je rester condamné à attendre une minute pour chaque ouverture de session, ça…
Non, parce que c’est vraiment relou et ça me gonfle vraiment, là. Alors, j’ai pas envie de lâcher l’affaire, m’voyez. Même au passage à XFCE 4.14 en août, tout refait en GTK3, ça ne mettait pas si longtemps (ça a dû se produire vers fin septembre ou courant octobre, seulement).

Si je peux au moins savoir pourquoi, après avoir ouvert une première session, juste après le démarrage, Tumblerd a un numéro de processus dans les 740, et Thunar --daemon est à près de 9000, alors que sur l’autre PC, il est vers 850 seulement… On dirait apparemment qu’il y a une tonne de processus créés et supprimés dans l’intervalle, et que ce n’est qu’après une lutte âpre contre je-sais-pas-quoi qui l’empêche d’y arriver que le bureau parvient enfin à se charger et apparaître à l’écran. Mais ce truc-là, c’est quoi, déjà ?

 
C'est visible lorsque le bios est en UEFI (et non pas legacy) mais part contre je ne sais plus s'il faut aussi démarrer en "EFI Boot stub"  
(https://wiki.archlinux.fr/EFI_Boot_Stub)

systemd-analyze montre le temps de boot à partir du bios (ou) du kernel jusqu'à graphical.target qui corresponds à ton gestionnaire de session (gdm, sddm etc..) si je dit pas de bêtise.
A partir de là, le temps restant : [gestionnaire de session] --> ouverture de session --> [bureau] ne rentre pas en compte donc si ça met 2min à ce niveau là ça me semble normal que systemd-analyze n'aide pas vraiment dans ton cas.
 
D'un coup vu il faut plus regardé du coté des logs (jourrnalctl) pour le reste et voir ce qui mouline.  
peu être aussi avec systemctl --all --failed  
 
sur un pc récents (ou du moins avec de la ram, un sdd, sans 5000 appli d'installées)  sddm boot en quelques secs

@Trit'
Peut-être un manque d'entropie, t'as essayé d'installer haveged ? (en l'activant au démarrage)

Ah desolé, je n'avais pas compris que ce topic n'était que pour tes questions et qu'on ne pouvait pas communiquer sans y répondre.

Je n'utilise pas stub, enfin je crois, mais systemd-boot avec l'interface appelée depuis l'UEFI.

ça peut t'aider à relativiser ton problème, à avoir un référentiel, si on donne nos temps de démarrage et qu'ils sont proches du tien, avec une config CPU similaire,

j'ai un CPU de 2009 de la même famille que le tien, et je viens de chronométrer précisément le temps de démarrage, et en fait c'est moins lent que ce que je pensais :

- chrono déclenché après un clic sur l'entrée "archlinux" de grub, et mis en pause après le chargement de sddm :

42.32 secondes

- puis je continue le chrono après avoir tapé mon login et mot de passe, je stoppe le chrono qu'à la fin du chargement du bureau de plasma (lorsque la led du disque dur ne clignote plus) :

1 minute, 16 secondes et 44 centièmes

donc refait le même test (en excluant les temps de démarrage du bios, et celui mis lorsque tu tapes ton login et ton mot de passe), avec un CPU proche du mien, 8 Go de ram, un disque dur 7200 tours/min, peu de démons exotiques, pas de wifi/réseau qui met des plombes à s'initialiser (j'utilise que du filaire ethernet), et que tu testes sur du plasma (ou un bureau plus léger, adapté aux ordinosaures) tu dois pouvoir te rapprocher de mon chrono,

regarde bien l'activité de la led disque dur, peut-être un démon de type "indexeur de fichiers" qui ralentit le boot, il faut regarder les fichiers log (journalctl en mode sudo/root, Xorg, dmesg) pour en savoir plus, regarder combien tu as de services systemd qui tournent en arrière plan.

Les seuls services qui ont échoué sont : logrotate, systemd-hostnamed et upower.
Un rapide parcours de journalctl semblerait me désigner plutôt xfsettingsd comme un coupable potentiel (il coredumpe souvent au début du chargement de session).

J’y ai pensé. Une fois, pendant que je poireautais devant cet écran noir où seul le pointeur de souris s’affiche, j’ai essayé de bouger le mulot, et j’ai remarqué que le pointeur bougeait avec quelques saccades.

Oh, je sais que c’est pas dramatique, puisqu’une fois que ça charge enfin, il n’y a plus de souci. Mais passer de 5 secondes de temps de chargement à plus d’une minute (voire deux encore récemment), ça fait se poser des questions.

Le boot lui-même n’est pas touché. Il y a juste parfois le service Dynamic Linker Cache qui s’amuse à traînasser deux secondes au démarrage, parfois, mais ce n’est pas systématique.

 
en général ça ralentit tout le système quand un fichier coredump est crée et que ce fichier fait plusieurs centaines de Mo (voire Go), le disque dur va être fortement mis à contribution, et ralentir le reste des programmes,
 
tu peux tenter de désactiver la génération du fichier coredump :
 
https://wiki.archlinux.org/index.ph [...] core_dumps

Je sais pas si ces infos sont toujours valables mais pour continuer l'investigation t'a peu être ça que tu peu aussi essayer :
 

afin de (peu être) voir un peu plus minutieusement quel conf coince  
 
https://docs.xfce.org/xfce/xfce4-settings/xfsettingsd

Elbarto et rokin-k : je note, merci.

En attendant de faire la manip d’Elbarto de couper la génération des fichiers coredump (j’ai pas encore osé le faire), j’ai remarqué une bizarrerie, depuis hier, sur le même ordi : au démarrage, quand systemd se lance, il affiche le résultat d’un fsck rapide sur la partition racine. Sur ce PC, j’ai installé Linux sur un deuxième disque dur, acheté pour l’occasion il y a 3 ans. Jusqu’ici, c’était donc marqué « /dev/sdb3 » (1, c’est /boot ; 2, c’est le swap).
Ben, hier, c’était marqué « /dev/sdc3 ». Et ce matin, c’était « /dev/sdd3 »…
Il faut savoir que ce PC embarque un lecteur de cartes 4-en-1, qui étaient aussi bien montés (même si vides) sous le Windows d’origine que sous Arch (les lecteurs ne sont pas montés, mais apparents, et vont normalement de /sdc à /sdf).
Apparemment, depuis les dernières MAJ du noyau (5.5.2-arch2 hier matin, 5.5.3 ensuite), l’OS cafouille un peu lors de l’attribution des /dev/sdx… Heureusement que le fichier fstab note les UUID, plutôt que les chemins en dur !
Je me demande quand même jusqu’où ça va aller : simple répartition aléatoire entre /sdb et /sdf au démarrage (/sda semble réservé au disque dur d’origine, et je n’ai pas ce problème sur mon PC portable qui n’a qu’un seul disque interne à la fois, de toute façon), ou ça va aller jusqu’à /sdz et après… Il est censé se comporter comment, ensuite ?

Après /dev/sdz ça devient /dev/sdaa :

https://askubuntu.com/questions/474 [...] -after-sdz
https://rwmj.wordpress.com/2011/01/ [...] 26-devsdz/

cool je vais pouvoir mettre plus de 26 disques  

C’était trop beau, les choses marchaient trop bien…
 
Sur ce fameux PC (toujours le même, oui), je fais les MAJ de la journée, je redémarre… et paf : écran noir avec curseur gris clignotant. LightDM ? « Status=1/FAILURE, start request repeated too quickly », me dit un « systemctl status ».
 
Je commence par tenter un redémarrage (heureusement que je peux utiliser les consoles TTY !) → Échec.
Rétrograder systemd à la version 244.2-2 ?→ Échec.
Redémarrer sur le noyau LTS ? → Échec.
 
Un « less /var/cache/pacman.log » ne me laisse plus qu’un seul suspect possible dans la liste : mesa. Je rétrograde donc à la version précédente (c’est là qu’on voit qu’il ne faut pas vider le contenu de /var/cache/pacman/pkg de manière inconsidérée ! Parce que son contenu peut vous sauver la vie ! ). Redémarrage… LightDM se lance !  
 
OK : MESA 19.3.4 ne marche pas sur ce PC. Soit qu’il est incompatible avec Nouveau, soit qu’il l’est avec une CG Nvidia Geforce 210. En tout cas, pour l’instant, je dois le laisser bloqué sur la version 19.3.3. Ou trouver un moyen pour que la 19.3.4 veuille bien s’entendre avec LightDM sur cette CG.
 
Bon, ben, je vais remettre systemd à jour, vu que lui semble être innocent dans cette histoire…
 
EDIT : et donc, voilà : https://bugs.archlinux.org/task/65498

Ouaip, j'ai eu le souci ce matin moi aussi : après màj, des applis refusaient de se lancer et/ou de s'afficher dans la barre des tâches.
Du coup je me suis dit : bah, un petit reboot ? Mauvaise idée  
Comme j'étais bloqué, j'ai même pas pensé à tester si j'avais accès aux tty : j'ai fait reboot -> clef usb d'install -> archchroot -> branchement du mirror.list sur le archive.archlinux.org d'hier -> pacman -Syyuu
Mais du coup, merci pour l'info que c'est à cause de mesa, ça m'évitera de chercher  

RAS chez moi en tout cas, malgré plus de 40 mises à jour aujourd'hui !

Bonne (on se comprend) nouvelle : bug confirmé chez d’autres personnes, et ne touchant pas seulement LightDM ! Au moins trois personnes sont dessus, d’après ce que je vois sur le bugtracker. Il y a même un sujet sur le forum, que je n’avais pas trouvé tout à l’heure :
https://bbs.archlinux.org/viewtopic.php?pid=1887597
 
 
C’est quoi, ta CG ? Parce que sur mon portable qui a une AMD (enfin, ça s’appelait encore ATI, à l’époque) n’a, lui non plus, aucun souci avec MESA 19.3.4 et les pilotes libres xf86-video-ati.
Ouais, non : c’est juste qu’ayant fait la MAJ ce matin, sur lui, la 19.3.4 n’était pas encore proposée ; et je vois que même les CG AMD ne sont pas épargnées… Bon, ben, ici aussi, je la bloque. Par précaution.
 
Je vous avoue que ce serait très ennuyeux, si je devais ne plus pouvoir mettre ce paquet à jour sur ces ordis.

Tous mes PC sont en 100 % Intel ( processeur avec chipset graphique intégré )
Souvent gage de fiabilité avec Linux  

Ça a quand même l'air de concerner un peu de monde, donc il devrait bien y avoir une solution d'apportée…
J'ai voté pour le bug en tout cas, c'était l'occasion de me créer un compte sur bugs.archlinux.org du coup.
Et j'ai bloqué les màj de mesa, lib32-mesa et mesa-vdpau : je sais pas si il était nécessaire de bloquer les trois, mais je préfère garder une cohérence de version entre ces trois-là.
En tout cas en bloquant ça et en mettant à jour tout le reste, pas de problème au reboot  

J’ai moi aussi créé un compte à cause de ça.  
 

Merci de me rappeler de bloquer aussi lib32-mesa sur le portable (le seul où j’ai activé Multilib pour installer Wine).
 
En tout cas, ça touche aussi Manjaro, puisque Burn2, à côté, vient de se plaindre que la MAJ foirait sur ce paquet. Et Philip Müller, la papa de Manjaro, vient de poser un commentaire sur mon signalement, après en avoir fait un chez FreeDesktop (les créateurs de MESA), où on voit dans les commentaires de ce dernier que ce serait ce commit qui serait la cause de nos soucis…

 
D'une fiabilité sans faille  

Salut
 
Y'a personne sous arch + firefox qu'a des problèmes avec netflix ?
 
J'ai un plugin qui crash (il ne me dit pas lequel...) je soupçonne Widevine en     4.10.1582.2 qui a récemment été MAJ.
 
Merci

C'est bien le plugin Widevine qui plante, j'ai la même chose avec Prime Vidéo et Netflix, obligé de passer par Chrome pour l'instant ...

 
Yep https://bugs.archlinux.org/task/65469.
 
Solution pas top pour la sécu lancer ff avec la var d'env MOZ_DISABLE_GMP_SANDBOX=1

Le bug de MESA est pour ainsi dire corrigé : une version 19.3.4 patchée vient d’apparaître sur le canal Testing. À noter que ce bug affectait aussi la préversion RC3 de MESA 20, mais pas la RC2. Si j’ai bien lu, le correctif sera apporté aux préversions suivantes aussi.
J’adore quand les choses s’arrangent aussi vite (même pas 24 heures entre mon signalement et l’annonce d’un patch fonctionnel) !
 
Je tiens à dire une chose : c’était mon tout premier signalement sur le bugtracker d’Arch Linux (j’ai créé un compte là-bas à cause de ça), et devinez qui a découvert le commit responsable de ce chaos ? Patrick Volkerding, le papa de la distribution Slackware – la plus ancienne encore en vie, même si elle vivoterait plutôt, dernièrement – lui-même ! Si ça, c’est pas la classe !  
 
Bon, j’attends plus que cette version corrigée arrive en stable, et je tenterai de l’installer.

Pourquoi les testeurs officiels de mesa n'ont pas réussi à détecter ce bug durant la phase de test ?
Ils avaient tous une configuration matériel (carte graphique particulière, de type intel) qui empêchait le bug de se déclencher ?
Ils utilisaient tous une distribution linux de type ubuntu LTS dans leur environnement de développement et de tests (paquets systèmes non récents) ?

En théorie il y a plusieurs filets de sécurité pour empêcher qu'un gros bug apparaisse dans la version finale du logiciel :

- le ou les développeurs du logiciel, ils sont censés tester avant de proposer une version alpha ou bêta
- les testeurs officiels du logiciel
- le mainteneur du paquet du logiciel chez une distribution linux lambda, s'il voit que le paquet est dangereusement bogué alors il ne doit pas proposer cette version
- les utilisateurs des dépôts testing

Tu oublies la cause la plus probable : ils doivent tous utiliser eux-mêmes du matériel trop récent pour que celui-ci puisse être victime du bug en question (il y en a beaucoup, des développeurs qui bossent sur des PC dont la configuration matérielle n’a pas bougé depuis 8 ans, voire plus ? Surtout en ce qui concerne la carte vidéo ?). Ça et le fait que nombre d’entre eux doivent aussi avoir plutôt recours aux machines virtuelles.

Pour l’exemple, prends le cas de celui qui s’occupait de maintenir les pilotes propriétaires NVIDIA 340 (une version LTS maintenue jusqu’en septembre 2019) pour Arch Linux (pilotes qui devaient être mis à jour de manière synchrone à chaque mise à jour du noyau, et avec une version de ces pilotes en fonction du type de noyau : normal, LTS…). Il a jeté l’éponge au printemps dernier, en avertissant que d’ici deux semaines, il allait balancer les paquets nvidia-340xx sur AUR après les avoir déclarés orphelins (sans mainteneur), alors que ces versions de pilotes étaient encore prises en charge par NVIDIA jusqu’à fin septembre dernier. Pourquoi ? Parce que ça faisait longtemps qu’il n’avait plus chez lui de matériel adéquat pour tester en dur ces versions de pilotes, qu’il concevait donc ces paquets dans une machine virtuelle et à l’aveugle, et que ce n’était plus possible pour lui de continuer ainsi (d’ailleurs, on se rappelle que les dernières versions de ces pilotes avaient tendance à ne pas fonctionner du premier coup). Moi, utilisant une carte achetée en septembre 2012 sur le PC familial, j’ai dû me rabattre sur le duo xf86-video-nouveau + mesa-dri pour que je puisse éviter d’avoir à aller à la pêche à la CG pour PC âgé de 10 ans ne servant qu’à faire de la bureautique, de l’e-mail et de la navigation Web (et du réencodage de vidéo 720p dernièrement, parce que ça va plus vite avec son Core 2 Quad que le C2Duo de mon portable). Coup de bol : ce palliatif est largement suffisant, ici.

Autre cas : la version 4.18 de Linux, elle aussi affectée par un bug de la clocksource touchant les CPU Core 2 Duo (et certains AMD double-cœur, mais pas les Core 2 Quad ni autres quadri-cœurs et plus de la même époque ou plus récents) datant de la fin des années 2000. En attendant que le bug ne soit corrigé en amont dans la version 4.18.7 (sortie un mois après la 4.18.0 : c’était un été où la sortie des noyaux était pire que stakhanoviste), les seuls moyens à disposition des malchanceux – dont le PC cessait de répondre juste après le démarrage de systemd… – pour passer outre étaient de démarrer avec le noyau en mode « fallback », de démarrer avec le noyau LTS, ou de forcer le paramètre « clocksource=hpet » dans GRUB (lorsque la cause du bug a été identifiée, pour cette dernière option).

Ben, là, ça doit être à peu près la même chose pour les développeurs de MESA : leurs machines doivent être renouvelées en permanence, y compris celles des testeurs, et s’il y a un bug qui apparaît et qui pénalise les utilisateurs ayant du matériel désormais un peu ancien, ben, personne ne s’en rend compte et c’est là que le drame arrive.

Upgrade de mesa et mesa-vdpau vers 19.3.4-2, et reboot : no problemo    
lib32-mesa est resté en 19.3.4-1 par contre, j'imagine que ça l'impactait pas…

Ayé : mesa-19.3.4-2 disponible en stable !
 
Et… Déjà marqué comme obsolète ? Oh !  
 

Je le mettrai à jour demain matin (à cette heure-ci, je fais plus de MAJ ni de redémarrage), mais c’est bon à savoir.
Je suppose que c’était soit inutile pour lib32-mesa, soit que personne n’utilise de logiciels sous Wine chez les testeurs. Bah, on verra bien.

En fait je m'en sers plus jamais de wine maintenant, c'est une install résiduelle que je vais peut-être finir par virer.
Mais bon, je viens de tester vite fait un logiciel sous wine (captvty) et ça a l'air de marcher…

Après avoir débloqué les MAJ de MESA avant d’éteindre pour la nuit, puis lancé un coup de yay au rallumage (en TTY, s’il y avait besoin de redémarrer à cause d’une MAJ du noyau, c’est plus simple de n’avoir à charger que le strict nécessaire) et redémarré LightDM quand ce fut terminé, ça fonctionne ! Encore merci, Patrick !

La preuve (presque) en images :

(Reste encore le portable, mais ayant quelqu’un qui squatte ma chambre tous les samedis soir et dimanches, je vais devoir attendre qu’il se lève… Mais ça, c’est une autre histoire que j’aimerais aussi voir enfin appartenir le plus tôt possible au passé pour toujours, mais c’est pas moi qui décide, là)

EDIT : décidément, ils me les feront toutes… Bon ! Si vous avez l’habitude de vous connecter en SSH sur vos autres machines, après avoir fait les MAJ de ce matin, relancez le service sshd (sudo systemctl restart sshd) sur toutes vos machines de votre réseau : la MAJ d’OpenSSH casse le système d’identification en renvoyant une erreur « kex_exchange_identification: read: Connection reset by peer », tant que vous n’aurez pas relancé le service.

Après une GT710 ou équivalent AMD ET 230 ça coûte 42€, je suis sur que sur l'occasion on doit trouver des cartes raisonnablement récentes pour une bouchée de pain.

Il y a des cartes typées "e-sport" à pas cher, ça suffit pour la majorité des utilisateurs peu interessés par le jeu extrême, ou qui font que du retro-gaming (émulateurs de console de jeux, vieux jeux des années 80/90).

C'est pour cette raison que je tourne encore avec une radeon HD4650 pcie de 2009, elle suffit largement pour du retro-gaming, et tout ce qui est affichage de vidéo haute-définition, avec un CPU de 2009 aussi (intel core 2 quad core Q9650 3.0 Ghz, le haut de gamme de l'époque, vendu à 30 euros en occasion de nos jours).

En 10 ans les besoins en puissance ont très peu évolué pour les usages courants d'un simple particulier (surf internet, vidéos haute-définition, bureautique, retouche d'image), si tu ne fait pas de deep-learning, de graphisme 3D avancé (blender), de compression de vidéo h265 UHD, de jeu vidéo blockbuster alors on peut s'en sortir avec une config d'il y a 10 ans,

avec juste le changement d'un disque dur vers un SSD et l'augmentation de la mémoire à 8 Go pour plus de confort, l'adoption d'une distribution linux pas trop lourde, et une stratégie pour éviter les logiciels de type "obésiciel" (mal optimisés, excessivement gourmands en ressources, des mauvais choix de design de la part du développeur).

Ce qui a le plus enflé c'est le web et les navigateurs web, et c'est totalement injustifié, mais c'est comme ça

Oui pour le surf internet, un PC de la première moitié des années 2000 (celeron, duron, pentium 4, athlon XP) va ramer pour la navigation internet, parfois même aussi certains CPU de la seconde moitié de cette décennie (certains intel core 2 duo qui ont une faible fréquence),

principalement à cause de l'utilisation massive de javascript dans les sites web, les pages dynamiques qui s'adaptent selon le contexte (utilisateur, l'écran), les animations vidéos, des sites qui font office d'application en ligne, des pages comme celles de facebook, amazon, youtube sont un vrai supplice pour les ordinosaures,

alors qu'avant le web 2.0 les pages étaient relativement simples, fixes, affichaient du texte, avec parfois quelques images, très peu de pubs invasives, le web voulait imiter l'apparence d'un livre, d'une encyclopédie, quelque chose de simple, qui ne nécessitait pas une puissance importante.

Une solution serait d'avoir un navigateur qui transformerait le site visité en une version simplifiée (filtrage du javascript, css plus simple), un peu comme la fonction "mode lecture" de firefox (l'icône "feuille" dans la barre d'adresse à droite), ou un serveur proxy qui modifie la page en une version simplifiée avant de l'envoyer à l'ordinosaure.

Comme ce que fait Google avec son système AMP ?

J'aime bien les vieilleries mais au bout d'un moment je pense qu'on passe un seuil au niveau performance/watt et que ça ne vaut plus le coup. Rajouter à cela des instructions CPU qui améliorent les performances de certains usages.