Reprise du message précédent :

C’est un zombie : un logiciel mort (depuis 10 ans, quand même !) qui bouge juste suffisamment (une petite MAJ de pure maintenance de temps à autres, mais très partielle) pour faire illusion, mais ça reste fondamentalement un cadavre logiciel. La dernière vraie version date de 2014, et il n’y a plus eu la moindre évolution fonctionnelle depuis.
 
Paix à ses octets, comme dit « tonton »…

Je voulais dire LibreOffice.

J'ai l'impression que le paquet chromium 121.0.6167.85-1 pour archlinux a un bug :

- chez moi il plante au démarrage (sans afficher d'interface graphique), en lançant depuis une console je vois ces messages d'erreur, un problème pour utiliser l'accélération GPU :

j'ai une vieille carte graphique AMD Radeon 4650 Pcie,

Trit aura peut-être le même souci avec son PC portable équipé d'un CPU intel core 2 duo et d'une carte graphique AMD Radeon 4xxx de génération assez proche ?

En supprimant le paquet libva-vdpau-driver ça résout (ou contourne le problème), j'ai trouvé l'info ici :

https://forum.manjaro.org/t/chromiu [...] le-goodbye

VDPAU a une réputation de bibliothèque boguée, j'ai installé il y a plusieurs années VDPAU, puis ensuite VAAPI tout en conservant VDPAU,
récemment j'ai pu réussi à faire en sorte que VLC utilise LIBVA au lieu de VDPAU.

Idéalement il faudrait qu'il y ait une seule API de référence pour l'accélération graphique dédiée à la lecture vidéo, pour faciliter la vie de l'utilisateur en terme de configuration.

Même si je l’ai gardé installé, je n’utilise pas Chromium, mais Vivaldi (dont la version 6.5 actuelle est basée sur Chromium 120 LTS, pas la 121). De plus, je viens de vérifier et je n’ai pas ce paquet « libva-vdpau-driver » installé. Et je vois que ça va faire deux ans qu’il n’a plus été mis à jour, de toute façon…

Et un rapport de bug lié à ce paquet qui est toujours ouvert depuis plus de 2 ans :
https://gitlab.archlinux.org/archli [...] -/issues/1

Trit : est-ce que la commande "vainfo" fonctionne correctement chez toi ? (il vient du paquet libva-utils 2.20.1-1)

Si je désinstalle le paquet libva-vdpau-driver alors vainfo plante :

si j'installe libva-vdpau-driver alors vainfo ne plante plus (mais chromium replante du coup) :

les paquets que j'ai installé de type "libva" :

et ceux de type VDPAU

récemment, j'ai eu ce meme probleme avec vlc
après avoir désinstallé le dit paquet libva-vdpau-driver, vlc fonctionnait normalement

J’ai pas « vainfo » : quand je tape « vain », ça n’autocomplète pas.
 
Mais bon : un paquet abandonné depuis 2 ans, étonne-toi que ça commence à coincer…  
 
(Je peux parler, moi qui ai plein de paquets marqués « absents d’AUR » depuis des années et dont certains me servent toujours quotidiennement…)

 
Ca sera probablement vulkan video sous Linux.

Dites : y a que moi qui ne reçois plus de MAJ d’Arch Linux ? Depuis hier, Pacman et Yay me disent qu’« il n’y a rien à faire » (pourtant, sur archlinux.org, j’en vois, des paquets qui ont été mis à jour récemment !).

C’est mon miroir qui déconne ? Je suis sur mir.archlinux.fr (qui semble toujours fonctionnel).

Si vous en utilisez un autre, de préférence proche de Montpellier, n’hésitez pas à me l’indiquer.

J'ai fait des maj ce matin, aucun souci.
 
J'utilise reflector pour mettre à jour mes dépôts régulièrement.

je viens de faire la maj avec pamac, ras.
 
Je suis toujours sur des miroirs choisis par reflector, dont l'automatisation ne fonctionne pas, j'ai l'impression, il faut que j'approfondisse..., j'ai dû faire à la main.

Tant que je suis la, question fscrypt, que j'utilise pour chiffrer mon /home (imposé par mon taf).
 
Hier j'ai voulu modifier mon mot de passe user, et ce matin impossible de démarrer ma session car mon /home n'était pas délocké.
 
Lors de l'install, j'avais suivi le wiki Arch : https://wiki.archlinux.org/title/Fscrypt et plus particulièrement la partie "2.4 Pam module"
 
Je pensais bêtement que changer mon user pwd serait automatiquement pris en compte, mais faut croire que non
 
Voici le détail de mon install (après retour arrière sur mon ancien mdp pour pouvoir accéder à ma partition) :
Status fscrypt  

 
Du coup comment faire en sorte que mon changement de mdp soit pris en compte par fscrypt ? Faut que je fasse la maj manuelle côté fscrypt après modification de mon mdp ? Si oui comment ?
 
Merci

+

Ah, ben, avec le miroir de Cyberbits (à jour de ce matin vers 10h, d’après le site de la distro), ça marche déjà mieux : il m’en a trouvé, des MAJ !
 
Bon, y en a une de btrfs-progs, qui va me réclamer un redémarrage après… Je m’en occuperai avant d’aller manger.

La mauvaise nouvelle du jour : c’est aujourd’hui que sort Mesa 24.x sur Arch Linux. Sauf que cette nouvelle version est incompatible avec mes ordis de 2009 et leurs CG AMD utilisant le pilote Radeon (puisque le support est abandonné).
 
Au redémarrage du PC fixe : écran noir avec souris figé, pas d’invite de LightDM.
 
L’installation de mesa-amber donne un affichage pas du tout réactif, donc j’ai dû revenir en 23.3 et bloquer les mises à jour, en espérant que rien ne nécessitera Mesa 24.x dans un avenir prévisible…

 
elles ont quelle âge tes cartes ? mesa amber c'est pour celles antérieures à la 9500 sorties à partir de fin 2002. Toutes les suivantes ont encore un pilote gallium dans mesa.

Oh, Mesa a sorti une version 23.3.6 censée corriger des bugs de la 23.3.5. Mais je pense que sur Arch, il faudra compiler le paquet correspondant soi-même…

PC portable : ATI Radeon Mobility HD 4530 (ordi acheté en juillet 2009).
PC fixe : AMD Radeon R7 240 (achetée début 2021 pour remplacer une GeForce 210 qui ne fonctionnait plus bien avec Nouveau et les noyaux 5.10, même si la prise en charge était très bonne).

Du RV710 et du Oland, pour les références données par Inxi.

Dans les deux cas, j’utilise le pilote radeon/radeonsi, pas AMDGPU.

J’avoue ne pas avoir tenté de redémarrer le PC portable en voyant que le fixe se retrouvait planté avec Mesa 24.0.1 (heureusement que je pouvais me connecter dessus en SSH pour tenter Mesa-Amber qui donnait un affichage dont la réactivité était juste horriblement lente, et finalement rétrograder en 23.3.5 qui m’a redonné un affichage correct). Enfin, pas avant d’avoir préventivement remis le 23.3.5 (vu qu’il y avait eu aussi la MAJ du noyau).

Je mettais ça sur le compte de l’abandon du pilote Radeon, mais si tu me dis que je peux tenter de faire un rapport de bug côté Arch pour éventuellement avoir une chance de faire tourner mes bécanes (que je compte bien continuer à utiliser tant que faire se pourra)…

La AMD Radeon R7 240 peut tourner avec amdgpu je crois, et sur radeonsi donc improbable que Mesa ne la supporte plus.
 
La R700 est plus vieille mais ca devrait toujours utiliser r600g qui doit encore y etre non?

1. Et pourtant… Force m’a été de constater que ça ne fonctionnait pas : j’ai bien un affichage graphique, mais ça semble planter entre le chargement de X.org (j’ai un pointeur de souris, mais impossible de le faire bouger, ou de basculer sur un autre TTY) et l’affichage de l’invite de connexion de LightDM (qui n’apparaît donc jamais).
 
2. J’ai pas du tout eu envie de tester la chose (parce que si j’avais eu les deux ordis plantés, là, c’était vraiment foutu), ayant eu ma dose de trucs qui foirent pour aujourd’hui.

 
Pour revenir sur mon sujet, j'ai pu finalement modifier mon mot de passe user, mais en deux fois :
1. Modification du mot de passe de mon utilisateur avec pwd
2. Modification du mot de passe du protector avec le nouveau mot de passe (qui n'est pas mis à jour en auto par pwd) : fscrypt metadata change-passphrase --protector=/:xxxxxxxxxxxxxxxx (avec xxxxxxxxxxxx le code du protector utilisé sur la partition)
 
A+

 
Pour info pas de souci avec ma carte radeon HD4650 Pci express (qui doit dater de 2009 ou 2010) et mon vieux CPU de type intel core 2 quad, j'utilise le pilote radeon, gestionnaire de connexion SDDM, bureau plasma.
 
Version de mesa : 1:24.0.1-1, noyau linux 6.7.5-arch1-1.
 
Regarde si ça ne vient pas plutôt de ton gestionnaire de connexion graphique LightDM (s'il appelle mal des fonctions de la dernière version de mesa ou de Xorg), tu peux essayer avec GDM par exemple,
 
tu peux tenter aussi d'utiliser "startx" (xinit) en ligne de commande pour lancer ton environnement de bureau, au lieu du gestionnaire de connexion graphique.
https://wiki.archlinux.org/title/Xinit_(Fran%C3%A7ais)
 
La lecture des fichiers logs permettrait d'en savoir plus sur la cause de l'erreur (les fichiers logs de Xorg, de journalctl, la sortie de dmesg).
Si tu crées un rapport de bug les développeurs vont te demander d'ajouter en pièce jointe ces fichiers logs.
 
Voir aussi ces vieux fils :
https://forum.manjaro.org/t/lightdm [...] vers/33044
https://bbs.archlinux.org/viewtopic.php?id=265098
 
S'assurer que les miroirs que tu utilises sont à jour, il y a quelques jours tu nous avais indiqué avoir un souci de miroir, un miroir mal synchronisé peut expliquer certains bugs.
 
La commande "pacman -Syyu" permet de forcer l'actualisation des listes de paquets, après avoir vérifié que la liste des miroirs sélectionnés dans /etc/pacman.d/mirrorlist est correcte.
 
Je n'utilise qu'un seul miroir :
 

Vu l’heure, je ne répondrai qu’à une seule chose dans l’immédiat : oui, j’ai aussi envisagé une incompatibilité avec LightDM.
 
Et évidemment que j’ai songé à faire une passe de « sudo pacman -Syy » lorsque j’ai changé de miroirs (en l’occurrence, celui de Cyberbits.eu ; et moi aussi, je n’utilise qu’un seul miroir à la fois)… Ça ne vient d’ailleurs sûrement pas de là.

Il peut toujours y avoir un bog ca je ne dis pas mais je doute que le pilote n'y soit plus.
Ca se vérifie facilement avec glxinfo par exemple.
As tu essayé de lancer ton DE sans passer par LDM? Regarde dans Xorg.0.log s'il y a un message pouvant aider a tout hasard mais si le truc vient de Mesa j'en doute.

La commande pour lister les messages d'erreur de Xorg,  à faire si on a accès à une console immédiatement après le plantage :

pour le journal de systemd :

https://www.linuxtricks.fr/wiki/sys [...] de-systemd

Et comme dit plus haut il faut essayer avec startx (xinit) en désactivant le service LightDM qui est peut-être le fautif.

Voir aussi comment tu lances le noyau linux, si tu as mis des options de démarrage particuliers pour le noyau par rapport à la gestion de la carte graphique.

Activer le mode verbose de systemd au démarrage peut aussi aider à faire afficher des messages d'erreur, les échecs de démarrage de services dans l'écran de boot (plutôt qu'un écran noir ou un logo qui fait joli mais qui masque les messages d'erreurs et les warnings).

Tu peux faire le grep directement pas besoin de cat. Perso je suis passé a ripgrep que je préfère (et d'autres aussi comme fd, choose, eza, etc.)

Juste pour vous dire : je vous ai lus, mais je pourrai pas faire de nouveaux essais avant demain minimum. En attendant, je reste sur Mesa bloqué en 23.3.5 et puis vaille que vaille (parce que là, au moins, ça marche et que j’ai besoin d’ordis qui fonctionnent).

On dirait qu’il existe maintenant un rapport de bug sur ce problème, vu que les symptomes présentés sont identiques et que seule la rétrogradation rétablit un fonctionnement correct :
 
[RadeonSI] causes segmentation fault on startup with LightDM since 1:24.0.1-1 upgrade
 
Edit pour compléter un peu : ça a déjà été signalé avant, et il y aurait déjà un correctif qui n’attend que d’être publié (une question de jours, j’imagine).
 
C’est bien, et ça prouve que c’était bien Mesa le fautif (un « NULL » mis à la place d’un « priv »).

Sur le PC portable équipé d'une radeon HD4530 : tu utilises le pilote radeon, ou bien radeonsi pour les fonctionnalités 3D ?

Normalement c'est le pilote radeon tout court que tu dois utiliser pour les cartes de la famille r600/700.

Radeonsi c'est à partir des cartes HD7xxx (hormis les HD7350, HD7450-HD7670)

https://www.x.org/wiki/RadeonFeature/

Normalement tu ne devrais pas avoir de plantage avec la dernière version de mesa sur ton PC portable, j'ai une R700 (HD4650) et pas de plantage (mais je n'utilise pas LightDM).

Es-tu sûr de parler des mêmes choses?
Radeon dans Mesa, a part pour R100, il n'y a pas, radeon c'est surtout le pilote dans le noyau, radeonsi est le pilote Gallium3D. Voulais-tu dire r600g? Et dans ce cas-la je ne crois pas qu'il y est de choix possible.

passer sous debian

Oui je voulais dire r600g.

RadeonSI c'est le pilote pour la partie 3D pour les cartes de la famille "S. Islands" et supérieur.

Trit a une carte graphique R700 dans son vieux PC portable de 2009 (nom marketing HD4xxx comme ce que j'ai dans mon PC fixe) alors pas de radeonSi possible (d'ailleurs ça plantera il me semble si on force l'utilisation de radeonSi).

Trit met en lien un rapport de bug avec la mention "radeonsi" dans le titre, or sur son PC portable ça ne devrait pas utiliser radeonsi, c'est ça que je voulais souligner.
Ceci dit possible que la fonction défaillante indiquée dans le rapport de bug soit aussi utilisée par r600g.

J’ai jamais essayé de voir ce que donnait Mesa 24 sur le portable : quand j’ai vu que ça m’avait planté le fixe, j’ai immédiatement récupéré les paquets de 23.3.5 et les ai réinstallés sur les deux machines.
 
Du reste, voici l’« inxi -G » du portable :

Et celui du fixe (mais lancé depuis une connexion SSH, là) :

Dans les deux cas, j’ai fait qu’installer le paquet « xf86-video-ati » et c’est le système qui a fait sa tambouille de son côté.
 
Mais oui : j’utilise le DRI « r600 » sur le portable, et pas « radeonsi ».

Je pense que tu peux installer mesa 24 sur ton PC portable, comme je n'ai pas eu de problèmes entre ma HD4650 et Mesa 24 alors ça devrait bien se passer aussi pour toi.
 
Le nom de code renvoyé par glxinfo :
 

 
et l'utilitaire système de KDE pour les infos sur la carte graphique :
 

 
 
 
Au pire tu fais un downgrade du paquet Mesa si ça se passe mal, en démarrant sur une clé USB contenant l'ISO d'install d'archlinux, tu fais ensuite un chroot pour downgrader le paquet Mesa, la précédente version étant conservée dans /var/cache/pacman/pkg/.

Salut à tous,
 
Petit message pour dire que je suis assez content, ma SurfaceGo 1 tourne comme un charme sous Arch Linux. J'en avais un peu marre de Fedora et de ses quelques lenteur dû à la faible config, ici ça à l'air quand même un poil plus leger. Gnome 45 sur la Fedora ainsi que sur la Arch!
 
Je commence tout juste à apprivoiser Pacman!
 
Je suppose que j'ai raison de plutôt passer par une install via Pacman, par exemple pour Signal, que de prendre la version Flatpack dans l'app Logiciels de Gnome. J'ai l'impression que le paquet "natif" sera mieux intégré et plus rapide que Flatpack qui va prendre toute ses dépendances à part si j'ai bien saisi le concept?
 

Il arrive parfois que les développeurs de logiciels utilisent un système d'exploitation qui n'est pas de type rolling-release (Ubuntu LTS par exemple), ils vont alors tester leur logiciel avec ces bibliothèques et noyau Linux pas forcément à la dernière version, et conclure que leur logiciel n'est pas bogué,

mais sous archlinux c'est différent, tous les paquets sont à la dernière version, le logiciel de ce développeur peut se comporter différemment dans cet environnement rolling-release, si le logiciel n'a pas pris en compte certains changements d'API, ou si la bibliothèque contient un bug (comme Mesa en version 24).

Les logiciels distribués sous forme de AppImage, avec toutes les bibliothèques dedans n'auront pas ce souci normalement, ou beaucoup moins, l'inconvénient c'est que ça prend plus de place sur le disque dur.

Pour résumer archlinux c'est bien si on recherche l'aspect dernier cri/nouvelles fonctionnalités, mais en terme de robustesse c'est pas garanti, à cause de ce manque de recul, l'utilisateur archlinux sera un peu comme un cobaye, il sera parfois le premier à remonter les bugs aux développeurs, si le bug a échappé aux bêta-testeurs officiels, ou si la phase de test n'est pas rigoureuse chez ce développeur, une version sortie à la va-vite.

Je vais tester ça sur la durée, j’avoue je suis tout content de l’avoir déjà juste installé sur un PC et ma SurfaceGo 1.
 
Prochaine étape mon PC de jeux avec un vieux SSD en plus de mon nvme pour pas toucher à Windows 11    
 
J’ai bien aimé la simplicité et l’UI du navigateur internet de Gnome. Assez étonné ça marche c’est propre et beau! Après je garde Firefox malgré tout  

D’après ce message, il se pourrait que le noyau 6.7.6 corrige le bug de la surconsommation de RAM par les noyaux 6.7.x ! Il était temps !  
 
https://bbs.archlinux.org/viewtopic [...] 7#p2152757
 
EDIT : un redémarrage plus tard, c’est confirmé !
 
Bon, ben, j’ai pu virer le paramètre « transparent_hugepage=never » du fichier « /etc/default/grub » et régénérer un nouveau « /boot/grub/grub.cfg ».
J’ai quand même gardé une copie de la version précédente du fichier, pour pouvoir rétablir ce paramètre facilement au cas où, sans avoir à chercher dans les méandres d’Internet.

J'ai détecté un problème dans le paquet firefox d'arch linux (123.0-1) :

- le curseur de souris n'a pas la même couleur que le curseur de souris dans les autres programmes et dans plasma : chez moi j'ai un curseur de souris de couleur blanche, mais dans l'interface de firefox le curseur de souris a une couleur noire et a un style différent.

Vous avez la même chose ?

Mon thème de curseur est "oxygen blanc", j'utilise plasma, il semblerait que firefox 123.0-1 s'obstine à utiliser le thème "adwaita" (curseur noir) au lieu de celui configuré par l'utilisateur.

J'ai testé avec un nouveau profil de firefox mais le problème persiste.

Voir aussi ce vieux sujet :
https://bbs.archlinux.org/viewtopic.php?id=213058

Bug confirmé :
https://bugzilla.mozilla.org/show_bug.cgi?id=1881143
https://bugzilla.mozilla.org/show_bug.cgi?id=1876366

Le problème apparait qu'avec certains thèmes de curseurs, comme ceux de la série "oxygen", si j'utilise la série "brise" (thème de curseur clair, sombre) alors le bug disparait.

Un article indiquant que la plateforme linux dépasse parfois windows pour l'usage de jeux vidéos en terme de performance, avec arch linux en tête :
https://www.tomshardware.fr/rien-ne [...] erformant/