Reprise du message précédent :

Puce dédiée (attention aux faux-amis !) !
 

Mais parce que Wayland, c’est le turfu, enfin ! Fedora ne veut plus que lui pour sa prochaine version (ou la suivante, mais ils ont explicitement dit vouloir en finir le plus vite possible avec X.org ; d’ailleurs, ils vont se désengager de sa maintenance l’an prochain, et comme ils seraient ses principaux mainteneurs…), Gnome l’utilise par défaut depuis la 3.24, je crois, et parce que X.org CEstTropVieuxCEstToutPourri, tavu…  
 
Sauf qu’à ma connaissance, Wayland ne permet toujours pas d’utiliser la moindre application de capture d’écran (hormis celle fournie par Gnome) ou capable de filmer le Bureau (comme Simple Screen Recorder, OBS Studio, etc.). Donc, oui, il est encore loin, loin d’être au point pour pouvoir remplacer X.org à l’heure actuelle.

 
Ou pas    
J'ai vécu pas mal d'années avec 2 PC fixes avec carte graphique N-vidia -> que des emmerdes. Bon ok c'était sous Ubuntu et j'étais loin d'avoir mon niveau actuel sous Linux mais j'ai tout de même subi quelques écrans noirs après mise à niveau de la distribution.
Et sinon récemment avec mon vieux PC fixe de 2004 sous Xubuntu -> carte graphique plus prise en charge par Nvidia ( end of life ) donc il ne reste plus le pilote libre et ses performances minables...
Jamais plus je n’achèterais de matos avec du N-vidia dessus ! c'est terminé, basta  

 
Désolé pour la franglisation  
 
Bha la raison d'exister de wayland c'est quand même de remplacer X.org et il y a quand même de bonnes raisons de le faire aussi, ça a été dit et redit tout au long des débats sur le projet. Certes, des arguments qui ne résonnent pas forcément quand on est utilisateur et qu'on a déjà tout ce qu'il faut avec X.org ça je veux bien l'admettre. Mais bon j'ai l'impression que ce projet en fini pas de vouloir le remplacer et que ça traîne pour arriver ne serait-ce qu'à un niveau où les gens ne voient plus de différence entre les deux serveurs graphiques.  
 
 
 
T'emballe pas, on a vu un renversement une fois, ça peut se reproduire. Genre NVidia qui devient gentil avec des drivers ouverts et qui supportent même les vieilles cartes, et AMD qui devient à son tour la mafia des CG
Et là la boucle sera bouclé et on pourra de nouveau cracher sur ATI et louer NVidia. Faut pas insulter l'avenir

D'un autre coté, vu mon utilisation une carte graphique dédiée est tout à fait superflue  

Flagged Out Of Date AUR Packages:  pamac-aur
Last Updated:  2019-11-18
Flagged out-of-date (2019-12-06)
18 jours depuis la dernière version -> faut se bouger le c**, on rigole pas sur Arch !  

Il ne faut pas forcément le prendre mal, avant de savoir qu'on pouvait avoir des alertes sur github c'est souvent d'autres qui m'informaient ainsi qu'il était temps de mettre a jour mes paquets.

Certains utilisateurs n'apprécient pas par contre que tu puisses mettres quelques jours a resoudre leur probleme... c'est moins drole.

C'est quoi la limite en jour pour faire une alerte " out of date " ?

18 jours, c'est que dalle. Sur certains paquets, j'en suis à presque 3 mois.

Pour mes paquets AUR, j'ai ces dates pour la dernière version :
2018-05-17
2018-05-18
2019-01-13
2019-03-27
2019-06-02
2019-09-07
2019-10-23
2019-11-18  -> pamac
2019-11-26
 
C'est donc le 2ème paquet le plus récent, mais le seul qui s'est pris un drapeau " out of date "
Cela prouve sa popularité !

Je l'ai remplacer par la version git, il y avait des lenteurs, c'est peut-être pour ça qu'il y a de la demande de mise à jour ...

Et maintenant j'ai des micro-freeze de l'interface, je ne vois pas trop ce que j'ai modifié qui puisse en être responsable.
edit : ah si j'avais mis openGL 3.1 pour le rendu des fenêtres, faut pas ...

En jour? 0 je pense, c'est Arch apres tout.
Par contre tu peux surement attendre quelques minutes/heures.

 
hélas je joue sous windows aussi, donc nvidia ces dernières années c'était assez incontournable
J'espère vivement que AMD saura rétablir une concurrence digne de ce nom en haut de gamme comme ils viennent de le faire avec les CPU, et je serais ravi de repasser chez les rouges...

J'ai une question sûrement un peu idiote mais jamais compiler mon propre noyau donc dans le domaine je suis un noob et je viens de faire un essai en suivant le wiki avec la config de base avec succès.  
 
Maintenant, est-ce que c'est possible d'incorporer directement dans le noyau le microcode intel (intel-ucode) plutôt que le charger par le initrd et/ou de renseigner "en dur" l’ensemble des autres paramètres que j'utilise ?
 

 
Le but final serait de n'avoir aucuns paramètres à spécifier et que ceux-ci soient renseignés par défaut.
 
Pour résumer rapidement, pourquoi cette drôle d'idée ? car mon portable boot en EFISTUB (cf: le noyau est directement appelé à partir du bios sans passer par un bootloader) mais en revanche le BIOS (Dell) est pourri car il ne prends pas en compte le moindre arguments.
Sans les arguments, forcement ça boot pas, Actuellement j'arrive malgré tout à faire ça avec un hook barbare qui merge tout le bordel : https://github.com/xdever/arch-efiboot
 
C'est pas quelque chose d'indispensable (avec la méthode précédente ça marche) mais j'aurais quand même voulu essayer une méthode "plus conventionnel" dans la mesure ou c'est possible.
 
 
edit : je le laisse mais ça me semble un peu à coté de la plaque ce que je demande en fait

Dans le noyau je ne crois pas que c'est possible, maintenant dans l'initrd peut-être.

Salut,
 
Je pose la question ici au cas où quelqu'un ait une idée (cross topic Lenovo Thinkpad) :
Contexte :  
Une des deux batteries internes de mon T460s a lâché d'un coup, corrompant totalement mon système. J'ai réinstallé Arch avec Gnome pour essayer (j'étais sur XFCE depuis 2012) donc le problème vient peut-être de là   En gros, la batterie neuve charge vite jusqu'à 75% et ensuite elle met quinze plombes pour atteindre 79/80%. gnome-power-manager me dit bien qu'elle n'est pas chargée, mais le voyant du laptop est vert comme si elle l'était.

 
https://forum.hardware.fr/hfr/Ordin [...] m#t1567156

Salut,

Vous auriez une idée pour éviter les 2 min d'attente que j'ai a chaque reboot après mise à jour du noyau :

Merci !

Au choix:

- Tu trouves ce qui bloque pendant tout ce temps et tu fais en sorte que ca ne bloque plus.

- Tu reduis le maximum qu'un service a pour s'arreter de 2m a moins (tu peux le faire pour le service en question ou globalement).

Ça marche, je vais essayer de trouver ce qui bloque, ça sera plus propre.

Merci

https://pro-domo.ddns.net/blog/boot [...] ec-systemd
 
systemd-analyze Affiche la durée du précédent boot.
systemd-analyze blame Affiche le temps nécessaire au chargement de chaque service.
systemd-analyze plot > plot.svg Produit un graphique au format svg avec les durées et l'ordre de chargement des services.
systemd-analyze critical-chain Affiche les services critiques qui ralentissent le système

Ce n'est pas au boot mais a l'arrêt son soucis, donc je ne sais pas pour blame et compagnie.

ah my bad j'avais pas capté

Au pif, ça peut peut-être aider (voir lien github): https://forum.hardware.fr/hfr/OSAlt [...] m#t1441659

Pour le graphique, on peut aussi demander à l’avoir (au moins) en PNG, si on veut, en précisant donc l’extension correspondante.

Merci pour les piste
 
Après recherche dans le journal de systemd, c'est sur le seconde ligne ci-dessous que le shutdown bloque pendant 1m30s :

 
La, je vois toujours pas pourquoi ça coince ...

Ça rame à chaque arrêt ?
 
Ça serait pas un service ou une application qui serait lancée en WM et qui galère à s'arreter proprement/correctement ?
C'est le genre de truc qui peu occasionnellement m’arriver à cause souvent d'une appli "web".
 
Par exemple une appli de cloud (owncloud etc..), un partage réseau monté, un lecteur RSS, steam, etc...
 
Si c'est quelque chose du genre et que ça se produit à chaque fois, ça doit être vérifiable en prenant soin de d'abord quitter un max d'appli "utilisateur" lancées avant d'éteindre l'ordi

Non, c'est uniquement après une mise à jour (soit du noyau, soit de systemd il me semble), le reste du temps la machine s'éteint correctement et très rapidement ...

Ca c'est juste l'arrêt de systemd, donc ca ne dit pas grand chose.
Si ton soucis ne se passe que quand tu mets a jour ton noyau, faudrait voir de ce cote la.
Es-tu en UEFI ou BIOS? Si UEFI comment mets tu a jour la partition EFI apres avoir un nouveau noyau?

Merci pour la réponse
 
Je suis en BIOS, donc je ne fais rien côté partition EFI ... Je ne sais pas trop où chercher du coup  

Hmmnm, je n'ai pas trop d'idée la.
 
Au hasard, reinstalle et reboot séparément le noyau et systemd pour voir lequel des 2 pose soucis. Quand tu les installes regarde bien les logs pour voir si quelque chose de mauvais se passe mais j'en doute.
 
Peut-être avant d'éteindre regarde du côté des % d'utilisation CPU et IO pour voir si quelque chose est toujours en train de travailler, et si oui quoi.

Ok, je vais tenter tout ça, et si je trouve pas, pas grave, 1m30 perdue lors d'une mise à jour c'est pas la mort ...
 
Merci pour les pistes en tout cas

Bonne chance!

Merci !
 
Si je trouve, je le posterai ici

Je l'espère bien.

Tu as vu mon lien? A priori c'est un Kernelbug, j'ai le même soucis sous Debian 10.

Ah mince non, j'ai pas approfondi, sorry
 
Je vais jeter un oeil, mais du coup si c'est un bug kernel, rien à faire à part corriger le kernel ?

Sur le lien ca dit que le soucis est corrigé depuis le 5.2 tout de même, et sous Arch on en est au 5.4.

Par contre le coup du ctrl-alt-f9 ca peut etre utile pour trouver le soucis, s'il s'avere en effet different .

J'essaye de me faire une nouvelle VM Arch (via VirtualBox sur Mac) et d'utiliser Anarchy pour la première fois et aller un peu plus vite, mais je tombe sur cette erreur :

Vous savez comment régler ça ? (dans l'installeur d'Anarchy).

La dépendance qui semble posé problème c'est libdmx  

 
Sur https://www.archlinux.org/packages/ [...] g-xdpyinfo libdmx est notée (virtual), je ne sais pas ce que ça signifie.
Donc dans l’immédiat, je dirais de simplement skip l'installation de screenfetch, c'est juste un utilitaire pour afficher des infos du système dans le terminal (ça fait pas parti des paquets de base d'Arch, il y à rien qui en dépend et ça n'a rien de vital).
 
 
PS : quelqu'un a signaler le même problème ici :
https://bugs.archlinux.org/task/649 [...] g-xdpyinfo
 
et là :
 
https://github.com/AnarchyLinux/installer/issues/934

J'ai bien fait de venir voir si quelqu'un avait le problème    
Comme quoi il faut toujours bien vérifier quand on se retrouve avec des paquets hors dépôts avant de les supprimer (et donc ne pas automatiser à outrance   )
Ce matin, après mise à jour, je me retrouve avec libdmx hors dépôts, alors que xorg-xdpyinfo en dépend, et qu'il est dans les dépôts    
Par contre xorg-server-xdmx semble pouvoir être viré sans souci, mais du coup je vais attendre…

 
Je ne sais pas comment fonctionne anarchy que je n'ai jamais utilisé, mais je suppose que tu dois te brancher sur le mirrorlist pour pacman.
Dans ce cas-là, ce que tu peux faire, c'est mettre l'image des dépôts d'hier, car aujourd'hui il y a manifestement un problème d'intégrité.
Pour ce faire, tu peux mettre ça dans ton mirrorlist :

Même souci chez moi, j'ai suivi ces indications pour débloquer le bazar
https://www.archlinux.org/news/xorg [...] ervention/
 
Après la mise à jour du système, le paquet xorgproto est marqué comme orphelin, je l'ai donc désinstallé sans trop de craintes    
Par contre une nouvelle recherche de mise à jour renvoie ceci :
avertissement : libx11 : la version locale (1.6.9-5) est plus récente que extra (1.6.9-4)
 
Du coup faut downgrader ou pas ?  
 
edit : c'est bien la version 1.6.9-5 qui est dans extra, je ne touche à rien, mon miroir n'est pas à jour tout simplement    
https://www.archlinux.org/packages/extra/x86_64/libx11/
Last Updated:  2019-12-20 14:08 UTC