Reprise du message précédent :

Merci pour le lien. Ce serait donc la faute des pilotes Nvidia…
 

 
Pas ma faute s’ils l’ont publié quand la version suivante est sortie en amont !

Petite question : sur le PC fixe qui a une AMD Radeon R7 240, Linux 6.19 force l’usage du pilote « amdgpu » à la place de « radeon ». Mais ça provoque des bugs gênants (clignotements de l’écran et même crash qui ramène sur l’écran de connexion). J’ai remarqué que ça disparaissait quand je désactivais Xflux (oui, je continue à l’utiliser) et la rasterization GPU dans Vivaldi (mais ça cause une surconso CPU quand j’ouvre un onglet sur une instance Mastodon, et jusqu’à longtemps après que je l’ai fermé).
 
J’aimerais donc reprendre « radeon », mais si le wiki est ce qu’il est, il est pas super clair sur la marche à suivre dans ce sens-là (et j’ai pas envie de me louper…). Déjà, je vais faire un test en redémarrant demain sur le noyau LTS (qui vient de passer en 6.18.16, tiens…), histoire de voir quel pilote est chargé dans ces conditions.

La radeon R7 240 est de la génération Southern Islands, d'après le wiki Arch Linux le pilote amdgpu supporte les cartes de la génération Southern Islands et les générations suivantes :
 

 
https://wiki.archlinux.org/title/AMDGPU
 
Le wiki de gentoo confirme aussi que depuis le noyau 6.19 ta vieille carte graphique utilise maintenant le pilote amdgpu :
 

 
https://wiki.gentoo.org/wiki/AMDGPU
 
Il y avait cette page ancienne qui donnait le pilote amdgpu qu'à partir de la génération Volcanic Islands mais ça a dû changer depuis les versions récentes des noyaux Linux :
https://www.x.org/wiki/RadeonFeature/
 
regarde si tu as installé le paquet xf86-video-amdgpu et vulkan-radeon, le wiki Arch Linux conseille l'installation de x86-video-amdgpu pour les cartes de la génération Southern Islands comme la tienne, si tu utilises Xorg, ils indiquent que l'installation du paquet xf86-video-amdgpu peut résoudre des bugs liés à cette génération de cartes Southern Islands :
 

 
Je dirai de persévérer avec ce pilote amdgpu, car je n'aime pas l'idée d'aller à contre-courant de ce qui est normalement prévu pour ta carte graphique en terme de pilote, forcer l’utilisation d'un pilote non prévu pour ta carte graphique c'est risqué si tu utilises le dernier noyau Linux, il est probable que les quelques bugs que tu as seront bientôt résolus, avec une mise à jour du paquet mesa ou avec la prochaine version du noyau Linux, ou bien ces bugs peuvent être contournés via une option de configuration.
 
Si les bugs sont trop gênants : essaie de rétrograder le noyau Linux vers la version 6.18 ou 6.17, en attendant que les développeurs résolvent le problème, il y a peut-être un rapport de bug sur ce problème des cartes graphiques AMD de la génération Southern Islands sur le bugzilla de mesa ou du noyau Linux.

C'est un gars de Valve qui a fait ce changement, mais je ne sais pas s'il a toutes ces anciennes cartes pour tester. Il a l'air sympa, je pense qu'il prendrait un rapport de bog la dessus serieusement.

Ça, c’est la théorie. Dans les faits, ça ne marche pas aussi bien qu’on veut le croire, dans mon cas. D’où mon précédent message.
 

Phoronix et OMG! Ubuntu ont suffisamment dit que c’était un changement effectif depuis le 6.19 pour que ce ne soit plus à considérer comme une possibilité, oui.
 

Pas besoin de vérifier : je sais que c’est « xf86-video-ati » que j’ai installé quand j’ai mis cette CG, en janvier 2021… Mais peut-être que je peux ajouter « xf86-video-amdgpu ». Ça pose pas de problème, d’avoir les deux ?
 

Bah, pour l’instant, on n’en est pas là… Mais j’ai vu sur le forum que d’autres avaient aussi des problèmes de crash d’AMDGPU depuis le 6.18.
 
Après, pour le côté « contre-courant »… La config date de 2009 (ou fin 2008, en vrai) ; les seuls composants non d’origine sont la CG et l’alimentation (en 2021)… Si c’est la question de la prise en charge du matos, je pense pas qu’être sur la toute dernière version soit primordial. Quant aux corrections de bugs…
 

Bah, une déconnexion brutale de la session et un retour à la mire de connexion, je sais pas pour toi, mais moi, je classe en effet ça dans le « trop gênant ».
 
Donc, oui, ce matin, j’ai démarré sur le 6.12 LTS (qui, lui, emploie bien « radeon » et « radeonsi » ; pas encore fait la MAJ vers le 6.18 LTS, que je soupçonne d’autres problèmes liés à l’affichage, mais plus simples à éviter), et je poursuivrai mes essais dans l’après-midi.
 

Pour des infos plus techniques, voilà ce que journalctl m’a pondu lors des deux crashs (à 14h30 et 16h10) :
 

Si vous pouvez en tirer quelque chose…

Bonjour  
Pour avoir un rappel des mise à jour j'ai installé apdatifier : https://store.kde.org/p/2135796
C'est cool, ça marche super bien mais ça me fait une grosse verrue sur le bureau.
Je cherche plutôt une simple icone de notification, vous me conseillez quoi ?
Merci

Sur cachy on a arch-update installé avec arch-update sys tray applet pour les notifs
(enfin là je vois que tout ça a été renommé en cachy-update... c'est très récent, ça doit être un fork maison)

 
Merci, j'ai trouvé le github : https://github.com/Antiz96/arch-update
 
Sinon je viens de voir que ça doit être possible aussi avec apdatifier :

https://store.kde.org/p/2135796

Sur PC portable identique Debian fait carrément des mises à jour firmware, j’étais étonné.
 
Je suppose que sous Arch il y a bien quelque chose qui Check ça ?

 
Désinstalle x86-video-ati et installe à la place x86-video-amdgpu, puis tu redémarres pour voir si les bugs ont disparus,
 
autre test : si le problème n'est pas résolu alors désinstalle tous les paquets en x86-video-*, y compris celui en amdgpu, cela utilisera alors un pilote intégré, comme ça on aura testé tous les cas de figure installation/absence de paquet x86-video*.
 
Tu peux aussi regarder si en mode wayland les bugs disparaissent.
 
Trouver un rapport de bug pour y ajouter ton cas aidera et incitera les développeurs à corriger au plus vite ce problème.

@trit' :  
La soluce est donnée dans la log  

 
Tu rajoutes ça dans la ligne de démarrage du noyau dans la config Grub et hop !

Donc, faut éviter les deux ensemble. Je note.
 

Y en a qu’un, de toute façon…
 

XFCE, donc pas de Wayland (sauf de façon très expérimentale, mais j’y toucherai pas sur un ordi utilisé aussi par les parents).
 

Il y a un fil sur le forum, je songeais à y apporter mon petit gravier…
 

J’ai vu cette ligne en relisant le log, mais je voulais m’assurer que c’était ça et pas autre chose à y mettre.
 
Mais je pense que je vais plutôt laisser le week-end passer avant d’y retoucher. Là, pour l’instant, je vois que tout est de nouveau d’équerre en 6.12.75 (et pour cause…), je vais laisser en l’état dans l’immédiat.
 
Merci à vous deux.

La mauvaise petite surprise, en faisant les MAJ sur le PC portable avant d’éteindre pour la nuit : au moment de la génération des initramfs de la nouvelle version 6.18.16 de « linux-lts », une erreur qui disait qu’il n’y avait plus de place sur le disque !
 
OK, nous avons ici affaire à une installation en MBR avec une partition « /boot » séparée de 512 Mo (soit 503 Mio), avec dedans GRUB et les deux images noyau « linux » et « linux-lts », et chacune ayant son initramfs « default » (dans les 45 Mio) et « fallback » (dans les 180 Mio).
 
Ah, mais les « fallback » ne sont plus censées être générées par défaut, non ? Bah, s’il est vrai qu’elles ne le sont plus sur la VM minimale que j’ai faite l’an dernier (mais avant ce changement), rien n’a changé pour les deux installations faites en dur, respectivement en 2016 (portable) et 2017 (fixe). Et sur ce dernier, en pré-MAJ, je vois que « /boot » n’a plus que 43 Mio de libres…
 
Donc, dans l’immédiat, j’ai dégagé le noyau LTS du portable (grub.cfg régénéré dans la foulée, évidemment) et vais voir à quoi ressemble le fichier « linux.preset » de la VM et modifier ceux des autres ordis en conséquence. Pour info, celui des autres machines date de 2023.
 
La question est : suffira-t-il simplement, ensuite, de refaire une passe de « mkinitcpio -p linux linux-lts » pour dégager les images « fallback » et redonner un peu d’air à ces partitions ? Et quid du fichier « linux-lts.preset.pacsave » ? Je peux le virer et il en régénérera un autre quand je le réinstallerai ?
 
À noter que, justement, sur le fixe, je suis actuellement sur le noyau LTS à cause de l’autre souci de ce week-end… Lui, je pense que je vais d’abord devoir rajouter les instructions noyau au démarrage, puis procéder ensuite à la présente manip… Ça va être simple, je sens !
 
Rendez-moi l’époque où j’avais qu’à faire un « time yay », Entrée, Entrée et zou, c’est fini !
 
EDIT : fichier de la VM récupéré et comparé avec celui du portable. Mais je vois d’emblée une bizarrerie :
 
Fichier du portable :

Fichier de la VM :

La ligne « ALL_config="/etc/mkinitcpio.conf" » est commentée sur la « nouvelle version » du fichier. Ça a de l’importance ? A priori, non, puisque les MAJ du noyau sur la VM se font aussi bien qu’ailleurs…
 
Bon, je commencerai par voir comment ça se passe en réinstallant le LTS et aviserai ensuite.

Le fichier linux.preset que j'utilise sur le PC fixe dont l'installation d'Arch Linux remonte à 2013 :
 

 
le partitionnement est de type MBR,
 
si ta partition /boot est trop petite alors tu peux l'agrandir avec gparted-livecd, en téléchargeant l'ISO pour la mettre sur une clé USB :
https://gparted.org/livecd.php
 
un tutoriel :
https://www.malekal.com/gparted-red [...] de-disque/
 
Il y a un petit risque de perte de données, il est conseillé de sauvegarder avant les données les plus précieuses.
 
Si tu ne veux pas prendre de risques alors tu peux essayer d'optimiser en installant qu'un seul noyau, ou 2 noyaux mais sans la version fallback (tu devras peut-être supprimer à la main le fichier image fallback du noyau Linux).
 
Tu peux aussi compiler un noyau avec uniquement les modules nécessaires (ceux utilisés par ton PC), le noyau sera alors très petit en taille, il faut générer un fichier contenant la liste des modules utilisés par ton PC portable, puis l'utiliser pour la compilation, la compilation peut se faire sur un autre PC beaucoup plus puissant, si le CPU du PC portable est trop lent pour la compilation du noyau Linux.
 
Sur un CPU Intel Core 2 quad Q9650 3 Ghz de 2009 je mets 30 minutes pour compiler un noyau Linux avec que les modules nécessaires au matériel du PC, sur un CPU plus récent avec plein de coeurs ça devrait être encore plus rapide, peut-être 15 minutes en utilisant 8 coeurs et un SSD plutôt qu'un disque dur pour les opérations de lecture et écriture des fichiers de compilation, certains utilisent un disque virtuel en mémoire vive pour aller encore plus vite pour la compilation.
 
On peut se servir du PKGBUILD du noyau Linux classique (ou LTS), pour changer son nom en "linux-custom" ou "linux-lts-custom", il sera alors ajouté dans le menu de Grub en compagnie des noyaux Linux existants, il sera de très petite taille si tu compiles que les modules du noyau utilisés par le matériel de ton PC :
 

 
https://wiki.archlinux.org/title/Ke [...] ild_system

Curieux que ta ligne « ALL_config » soit commentée aussi, alors qu’elle l’est pas chez moi (et je me souviens pas avoir touché à ces fichiers)… Bref.
 
Je pensais réinstaller le noyau LTS sur le portable (avec un nouveau fichier « linux-lts.preset » tout neuf qu’il devrait apporter, il ne devrait générer que l’initramfs « default », non ? Ça devrait laisser de la place sur /boot), et laisser le noyau non LTS avec les deux, au moins dans un premier temps.

Oui ça devrait générer que la version "default", si tu configures le fichier linux-lts.preset avec cette ligne en retirant "fallback" :
 

Point d’étape :

• PC portable à jour et à nouveau avec un noyau LTS en parallèle de l’autre !

Comme supposé, il a apporté son propre « linux-lts.preset » actualisé et son installation n’a généré qu’un seul initramfs. Il me reste donc dans les 157 Mio sur « /boot ».
 

• PC fixe : en attente.

Lui, j’ai d’abord préféré le relancer sur le noyau actuel en lui demandant de rester sur le pilote Radeon. A priori (je l’ai pas sous les yeux, là), ça lui a pas déplu, mais je verrai ça mieux dans l’après-midi. À voir si, avec un nouveau preset, il virera l’image initramfs en trop, ou si je devrai la gicler à la main (puisque apparemment, on peut), ou si je vire là aussi le noyau LTS pour mieux le réinstaller bien proprement dans la foulée.
 
Et en plus, il y a la palanquée des « linux-firmware » qui s’est invitée à la fête, entretemps…

bon anniversaire arch linux ! deja 24 ans !
1e version en mars 2002
https://fr.wikipedia.org/wiki/Arch_Linux

24 ans c'est pas mal du tout  
Bon anniversaire.

24 ans ! Bon anniv Arch
 
Moi ça fait que 16 ans que je suis dessus

Presque 12 ans d’Arch en dur ici (depuis le 8 avril 2015). Bon anniversaire !

2008 en ce qui me concerne...Je n'y croyais pas.

2013 de mon coté, et c'est toujours cette version installée en 2013 qui tourne actuellement, quand je change de SSD je clone la partition vers le nouvel SSD avec CloneZilla, et quand je change de PC (nouvelle carte mère) je réutilise le même SSD.
 
 
 
 
 

Purée belle durée et niveau maintenance ?

Les deux seules fois ou j'ai du réinstaller Arch sur ma machine perso en 16 ans, c'est à cause de défaillances matérielles (ssd), sinon mon installation d'origine serait toujours en place

PC fixe à jour !
Là, ce fut plus facile : je savais comment m’y prendre (virer le noyau LTS, régénérer grub.cfg, MAJ du reste, remettre le LTS dans sa nouvelle version, régénérer grub.cfg). Tout se serait passé sans accroc… si j’avais pas oublié de virer le « linux-lts.preset.pacsave » dans l’intervalle, ce dont je me suis aperçu quand j’ai vu la post-réinstallation du LTS… générer un initramfs « fallback » (qui a évidemment échoué car plus de place sur /boot) !
Désinstallation directe du LTS, suppression du fichier fautif, réinstallation qui n’a bien généré qu’un seul initramfs, grub.cfg régénéré… Je vous avoue : j’ai soufflé de soulagement quand j’ai vu que tout était fini !
 
Bon, je crois avoir mérité d’utiliser Arch, là !
 
Mais j’aimerais bien ne pas avoir à refaire de telles opérations trop souvent, même si je savais clairement comment m’y prendre.

 
Idem, j'ai fait trois installations d'Arch depuis que j'ai commencé avec cet OS. La première, je n'utilisais plus trop Linux, donc quand j'ai changé le SSD, j'ai rien récupéré. La deuxième installation c'était un netbook que je n'ai plus utilisé par la suite. Et la troisième maintenant et vu que je n'utilise plus les outils qui ne sont pas ou plus disponible sur Linux comme les outils Adobe et Microsoft (Office), j'ai pu repasser sur Linux à 100%.  
 
 
Après quand à la longévité de l'OS sur une installation, pas de quoi fouetter un chat, l'installation Windows que j'ai et qui attend juste une suppression des partitions, date de Windows Vista avec le passage par tous les OS qui sont sortis. Donc si c'est possible avec eux, évidemment que c'est possible avec Arch.

Putain la gueule que ton Windows doit avoir, perso je saurais pas, je sais que c'est une perte de temps de réinstaller, mais entre version majeure je réinstalle, c'est quand même plus réactif

Bah justement non. Niveau perfs et réactivité il n'y a rien à dire. J'ai monté des config neuves et pas de différences. Comme tout hfrien quand je change de matériel je fais des bench. Et pas de sous performance.
Puis comme dit le souci ne se posera plus. Je suis passé de Lightroom à Darktable et les jeux vidéos c'est plus un défaut.  

   
Jamais de réinstall, mais quelques chroot  

Par curiosité, quelle taille le pacman.log après toutes ces années ?

Ca va, il grossit pas trop. Je me demandais à quel point un fichier de ce genre jamais vidé pouvait grossir mais faut dire que j'en suis qu'à 2.5M en un peu plus d'1.5 an

13,1 Mio depuis le 16/7/2016 à 13:28:50.
 
261 « yaourt » (le prédécesseur de yay, abandonné en 2019).
19 « -Syu » (je passe rarement par Pacman même pour mettre à jour)
2 231 « -S -y -u » (c’est-à-dire « yay »).
2 511 procédures de mise à jour en tout, en 3 526 jours.

Pas trop de maintenance, il faut parfois regarder ce qu'il y a dans les fichiers de configuration *.pacnew, pour adapter les fichiers de configuration, car Arch Linux contrairement aux autres distributions ne met pas à jour les fichiers de configuration déjà existants, sauf peut-être dans certains cas.

Il faut aussi de temps en temps vérifier que le serveur miroir qu'on utilise pour pacman reste pertinent (en terme de vitesse, d'actualisation du contenu), il y a un fichier /etc/pacman.d/mirrorlist.pacnew qu'il faut inspecter pour prendre le miroir le plus performant, ou bien utiliser un outil en ligne de commande pour choisir le miroir le plus performant, un site en ligne existe aussi pour déterminer la liste des meilleurs miroirs.

L'autre aspect de la maintenance c'est qu'il faut penser de temps à temps à désinstaller les paquets orphelins, obsolètes, qui ne servent plus,

cela arrive quand le paquet n'existe plus sur le dépôt officiel stable, par exemple les bibliothèques type Qt qui sont passées en version supérieure, par exemple Qt6, quelqu'un qui a une vieille installation d'Arch Linux qui remonte à 10 ans aura probablement des paquets Qt5 en plus des paquets Qt6.

Cela se complique si on a installé des paquets AUR, ou des paquets qu'on a créé soit-même et qui n'existent dans aucun dépôt stable (un paquet pour le pilote de son imprimante qu'on a créé depuis l'outil makepkg et un fichier PKGBUILD écrit à la main), ça va être considéré comme un paquet étranger par la commande "pacman -Qm", mais ça ne veut pas dire qu'on doit les désinstaller, ces paquets peuvent être utiles si on les utilise encore.

Si on est fainéant on peut laisser traîner ces paquets obsolètes et attendre qu'un "pacman -Syu" échoue, quand ça arrive alors le message d'erreur de pacman indiquera que tel paquet ne peut pas s'installer car il casse la dépendance liée à une version de bibliothèque utilisée par tel paquet X (le paquet étranger/obsolète)", la solution sera alors de désinstaller le paquet obsolète, pour que le "pacman -Syu" puisse de nouveau fonctionner sans erreur.

Il y a aussi des outils tiers en ligne de commande pour faciliter la maintenance :
https://wiki.archlinux.org/title/Sy [...] %C3%A7ais)
https://wiki.archlinux.org/title/Pa [...] %C3%A7ais)

Le mien fait 18 méga-octets, 227 728 lignes, pour une installation qui date de 2013.

C'est à la fois une machine de dev et perso (pas de distinction pour moi), donc j'utilise pas mal pacman… (d'autant que je package tous les trucs que j'installe à la main)

@Elbarto Merci pour les tuyaux, je vais lire la doc, on ne sait jamais

J'étais en train de faire le ménage parmi les paquets inutiles en suivant le wiki Arch et je suis tombé sur une bizarrerie. Vous comprendrez peut-être mieux que moi

me renvoie entre autres "dbus-units-37-3"

Mais :

et

Si j'essaie de supprimer dbus-units avec "sudo pacman -Rs dbus-units", pacman est complètement OK pour le supprimer.
Et juste lui, il essaie pas de dégager systemd ou autre chose avec

Comment ça se fait ?

J'ai le même genre de blague avec pulse-native-provider qui est requis par gnome-settings-daemon mais que pacman semble accepter de supprimer.

Oui c'est assez spécial comme cas...
 
Perso j'ai dbus-daemon-units et donc pas les autres providers que sont dbus-units + dbus-broker-units
 
Tu as donc vraisemblablement aussi dbus-broker-units d'installé je suppose ?
Et dans ce cas pacman te laisserait supprimer dbus-units car dbus-broker-units fournit aussi dbus-units.
Donc supprimer le vrai dbus-units ne changerait rien du point de vue du résolveur de dépendances...
 
D'autant plus que dbus-units est... vide en fait
https://gitlab.archlinux.org/archli [...] heads#L108
package_dbus-units() ne package rien, si tu regardes les fichiers de ce package via pacman (-Ql) il affichera normalement rien.
Ça semble être un package de transition ou juste pour tirer les dépendances pour le choix multiple des provides de dbus-units... c'est un peu alambiqué pour pas grand chose.

Ouais et dbus-units est en effet vide...
Je pourrais sans doute le supprimer sans que ça casse quoi que ce soit du coup mais je vais laisser ce bordel comme il est, sait-on jamais

Je pense que systemd peut démarrer des services “à la demande” via un message D-Bus