Reprise du message précédent :
Est-ce qu'il existe dans le dépôt AUR un programme en ligne de commande permettant de dire si une action manuelle est nécessaire avant de faire un "pacman -Syu" ?
 
L'idée ce serait d'avoir un outil en ligne de commande qui irait lire dans une base de données présente sur le web la liste des actions manuelles à faire (celles qu'on voit dans la page d'accueil du site arch linux), et qui ensuite irait comparer avec les actions qu'a déjà faite l'utilisateur (en supposant qu'en local sur son PC on puisse indiquer ce qu'on a déjà fait en terme d'actions manuelles sur son PC dans une base de données, avec la date).
 
Si le programme constate qu'aucune action manuelle n'est à faire alors il renverra sur STDOUT (sortie console) la valeur "0", sinon il retourne "1" (synonyme de code d'erreur),
 
en gros je veux me créer un script bash de mise à jour de ce type :
 

 
check-actions étant le programme de vérification que je recherche, ici s'il retourne 0 alors la suite du script sera exécuté "pacman -Syu",
 
s'il retourne "1" (considéré comme un code d'erreur) alors le script s’arrêtera et le programme affichera en sortie la liste des actions manuelles à faire (en reprenant le texte de la page d'accueil du site arch linux), comme ça plus besoin de vérifier la page d'accueil du site archlinux.

Tiens, puisque Linux 6.5.6 est sorti (bien que pas encore proposé sur Arch, même sur Staging), vous pourrez dire si ce « kernel-modules-hook » fonctionne bien ? Vu que le dernier commit date d’il y a 3 ans…
 
(Ouais, je l’ai pas installé parce que j’attends des retours d’usage)

Installé de mon côté, en attente d'une maj du noyau pour tester, je te dirai

La Killer feature du weekend que j'aurais dû faire 2 ans plus tôt :

Plus besoin de restaurer manuellement le dual-screen quand il foire

Je n'ai pas encore redémarré mais ca a l'air de fonctionner ici.
Après il y a juste quelques lignes, c'est peut-être pour cela qu'il n'y a pas eu besoin de changer grand chose depuis.

Juste des commandes bash et l'utilisation de rsync si on regarde le code source :
https://github.com/saber-nyan/kernel-modules-hook

2 hooks pacman et un service systemd

Un petit coté bidouille mais ça fait le taf.

Personnellement je ne l'ai pas installé, car redemarrer après une mise à jour de noyau linux ne me gêne pas, sur un PC moderne équipé d'un SSD M.2 nvme le reboot est très rapide.

2 minutes ici sur les miens (qui n’ont pas de SSD), du test POST à l’apparition du Bureau après lancement de la session. Je peux survivre à ça, et ça reste toujours plus rapide qu’avec Windows.
 
EDIT :
 

Paquet révisé en 1.5.6-2 avec le correctif.

Le fait que tu utilises XFCE c'est parce que ton PC n'a plus assez de puissance pour faire tourner les bureaux lourds type plasma, gnome ?
 
Ou c'est un choix volontaire, esthétique (recherche de la sobriété, simplicité) ?
 
Moi j'utilise LXQT sur un vieux portable pentium 4 (ordinosaure, je l'utilise pour ses vieilles connectiques port parallèle, port série, firewire).

Quand j’ai découvert Arch en 2014 (purée, depuis la mi-août, ça fait déjà 9 ans…), c’était avant tout parce que c’était le DE que Fred Bézies installait dans ses vidéos de démo d’installation en 30 minutes, et je n’ai fait que l’imiter.
 
Par la suite, et dans la mesure où XFCE me plaisait parce que j’arrivais à le modeler à ma guise, je l’ai gardé. J’ai jamais vraiment eu envie d’installer autre chose (les vidéos montrant Gnome ou Plasma m’ont suffi à comprendre comment les manipuler, et il a existé DistroTest pour faire joujou avec si je voulais ; aujourd’hui, ce serait avec son successeur spirituel DistroSea). J’ai essayé MATE, mais j’ai pas accroché.

Enlightenment.
Il y a une résurrection pendant 2-3 ans, mais cela n'a pas percé. C'est assez dommage parce que, dans le genre léger, c'était dans les meilleurs.

C'est encore en dév mais c'est très ralenti ou alors il y a du lourd.

Est-ce que ça vaut le coup d'utiliser un vieux PC sous archlinux pour en faire un serveur de fichiers type NAS ?

Ou bien vaut-il mieux installer une distribution spécialisée type OpenMediaVault ?
https://fr.wikipedia.org/wiki/OpenMediaVault

Arch linux étant déjà installé sur ce vieux PC je me dis que c'est plus simple d'installer les paquets nécessaires pour un serveur de fichiers que de formater et d'installer OpenMediaVault.

J'arrive à reproduire la même erreur sur un PC complétement différent et bien plus moderne, le test a été fait cette fois sur un SSD NVME, je lance KDiskmark, le benchmark pour la lecture s'effectue bien, mais pas pour l'écriture (le score pour l'écriture reste à zéro), le plantage est silencieux (pas de message d'erreur de KDiskmark), mais si on regarde dans dmesg on voit que le programme fio (utilisé par Kdiskmark) a planté :

J'ai la même ici sur mon portable du taf (ssd nvme):

 
Il passe même pas l'ensemble des tests en lecture :

Oui j'ai ça aussi parfois,
 
en gros si on clique sur le bouton "tout" il fait que les tests en lecture (mais pas tous les tests en lecture, parfois il s'arrête que sur le premier, ou arrive à faire les 2 premiers mais pas les suivants).

J'ai pareil ici, j'ai essayé de recompiler avec différentes options en vain. Je pense qu'il faudrait commencer par un rapport de bog chez Arch et voir. J'avais dans l'idée que c'etait un soucis avec ASLR mais peut-être pas.

J'ai remarqué un autre problème, lié cette fois à l'option "PCIe ASPM" présent dans le bios (rubrique "power management" ) :

- sur un mini-pc "HP Prodesk 400 G4 DM" avec le noyau linux 6.5.7 : lorsque l'écran entre en veille alors quelques secondes plus tard le PC redémarre automatiquement,

si je désactive dans le bios l'option "PCIe ASPM" alors le bug disparait,
c'est une option qui permet au système d'exploitation de réduire la consommation électrique des périphériques PCI express quand ils sont peu ou pas utilisés,

sur ce mini-PC j'utilise que la carte graphique integrée au CPU (core i5 8500T), de l'intel  graphics UHD 630, j'ai mis à jour le bios : ça n'a rien changé.

Je pense que le bug concerne que ce type de carte graphique integrée et les mini-pc HP, et il me semble que sur un noyau linux plus ancien il n'y avait pas ce souci.
Et sur un vieux PC à base de core 2 quad Q9650 et une carte graphique radeon HD4650 il n'y a pas ce souci.

J'ai crée un rapport de bug sur le site du noyau linux, pas encore eu de réponse.

Réponse du développeur linux : vérifier si le bug est présent avec un noyau linux ancien, puis faire un git-bisect pour trouver le commit responsable du bug.

Je vais vérifier tout ça.

J'ai testé plusieurs versions de noyau linux : de la 5.16.1 à la 6.5.7,

et j'ai trouvé que la dernière bonne version du noyau (qui ne déclenche pas le bug du reboot sur ma config quand le moniteur entre en veille) est la 5.18.16 (qui date du 3 août 2022),

c'est à partir de la version suivante (5.19.0 du 6 août 2022) que le bug apparaît,
je vais donc faire un git-bisect entre la version 5.18.16 et la 5.19.0, afin de trouver le commit responsable de ce bug.

Un outil intéressant pour se créer une base de données des modules linux utilisés par sa config PC :
https://wiki.archlinux.org/title/Modprobed-db

ça permet ensuite de se créer un noyau linux le plus petit possible en taille, en ne compilant que les modules nécessaires.

Sur mon core i5 8500T le temps de compilation passe alors à 15 minutes environ au lieu d'une heure (avec un make -j6).
C'est utile aussi pour accélérer les git-bisect de noyau linux.

Enfin si PC trop lent ou paquet lourd à compiler (libreoffice par exemple) : on peut distribuer la compilation sur plusieurs PC en réseau, avec distcc, l'outil s’intègre bien avec makepkg d'arch linux :
https://wiki.archlinux.org/title/Distcc

Ce matin, Pacman me met cette erreur quand je veux mettre le système à jour :

Je ne comprends pas bien le problème. Vous avez une idée ?

Bizarre, j'ai fais ma maj ce matin (Kde plasma aussi), sans aucun souci.
 
Mais j'ai pas de paquets git liés à Kde (comme ton material-kwin-decoration-git ou kvantum-qt5-git), possible que les paquets git cassent les dépendances.
 
Sinon aucune idée  

En fait ce sont des vieux paquets que je n'utilise plus (sauf lightly-boehs-git), j'ai tout supprimé et la mise à jour passe.

Oui ces erreurs arrivent si on a des paquets orphelins, et des paquets AUR trop anciens ou orphelins aussi.

Ça peut aussi arriver à cause d'un paquet bogué non orphelin et issu d'un dépôt officiel mais c'est rare.

J'y ai aussi eu droit ce matin, j'ai essayé kwinft la semaine dernière d'un coup j'ai pensé que j'avais fait de la merde quelque part lors de la désinstallation  
 
J'ai un archiso custom qu'il suffit de boot/copier sur le disque au pire et je change de pc la semaine prochaine d'un coup j'ai pas fait de maj et j'ai pas cherché à comprendre

J'ai eu des soucis du même ordre, j'ai dû accepter de nouvelles clés et faire un peu de ménage aussi.
 
il y a encore un qui me pose problème : nodejs-lts-fermium, un paquet AUR, il ne veut pas se mettre à jour et je n'arrive pas à le supprimer.

Il se passe quoi, quand tu essaies de l’enlever (sudo pacman -Rs nodejs-lts-fermium) ?

ceci :

Le paquet nodejs est installé ? Parce que crains que tu n’aies pas d’autre choix que de désinstaller d’abord les quatre paquets mentionnés si tu veux pouvoir enlever ce paquet récalcitrant (« pacman -Qi nodejs-lts-fermium » te dira quels paquets ont besoin de lui).

j'ai continué dans pamac, j'ai supprimé npm, puis après nodejs-lts-fermium et c'est bon    

J'avais entendu parler de dracut depuis un moment mais je n'avais jamais tenté, puis hier j'ai vu booster et j'ai voulu essayé. C'est impressionnant! Ca me genère tous mes initrd en 1.5 secondes alors qu'il m'en faut pas mal plus pour une seul avec mkinitcpio.
 
Les images sont aussi plus petites mais je me dit que c'est surement un soucis de configuration.
 
https://wiki.archlinux.org/title/Booster

 
https://archlinux.org/news/incoming [...] ervention/
 
Les modifications à venir dans les packages JDK / JRE 21 peuvent nécessiter une intervention manuelle...

Si c'est pour du dev je te déconseille de passer par le gestionnaire de paquet pour gérer ce genre d'outils.

Il y a les images docker qu'on peut utiliser si on veut un environnement qui aura pile les bonnes versions des outils (serveur web, version de PHP, du framework web, bibliothèques).

https://fr.wikipedia.org/wiki/Docker_(logiciel)

Sinon il y a la configuration qui peut être stockée en local plutôt que dans /etc, créer dans son home un environnement virtuel (python par exemple) avec une version précise des modules que le projet de dev est censé utiliser,

la plupart des bons framework web gèrent déjà la possibilité de spécifier la version des dépendances à utiliser, il y a un fichier de config qui stocke les dépendances et leur version, et une commande en ligne permet automatiquement de télécharger les bonnes versions,
il faut juste installer via pacman les briques de base (nodejs, npm si utilisation de angular).

Ah, donc, c’est la branche de noyau Linux 6.6 qui sera la prochaine LTS quand la branche 6.7 sortira :
https://www.omgubuntu.co.uk/2023/11 [...] rm-support
 
Côté Arch Linux, on parie qu’on va encore avoir des paquets « linux-lts » en AVANCE de version sur les « linux » à ce moment-là (le passage à la branche suivante pour « linux » se faisant rarement avant la version ×.×.1, et le paquet « linux-lts » passant à la branche LTS suivante quand la non-LTS passe à la sienne) ?

Bonjour,
Est-ce que vous avez déjà configuré secure boot sous ArchLinux ? Et si oui, ça c'est bien passé ? des conseils ?
(j'ai un nouveau laptop et j'aimerais activer secure boot ; j'ai W11 aussi dessus)

Je viens de mettre à jour firefox vers la version 120, depuis les dépôts stables d'archlinux,

l'interface est repassée en anglais, car l'extension fr n'est pas compatible avec cette version :

Vous avez la même chose ?

Edit : résolu, il fallait activer la mise à jour automatique des modules, dont celui du pack langue.

Ah! je suis en train de réécrire mon archiso afin d'utiliser les repos de CachyOS et j'ai rencontré le même problème cet aprem.  
 
Je pensais que c'était une histoire de repo qui n'étaient pas encore synchro vue que cachyos recompile les binaires et que j'imagine que ça prends du temps alors jai pas trop cherché à comprendre, j'ai viré la langue fr pour pouvoir build en attendant.
 
Bref pas de solution, mais content d'apprendre que j'ai bien fait de pas chercher 3h lea source du problème au mauvais endroit

Avec la MAJ auto des extensions activée, j’ai pas eu de problème en ouvrant Firefox 120 après la mise à jour des paquets « firefox » et « firefox-i18n-fr » depuis les dépôts (sachant que je n’utilise aucun dépôt tiers dans pacman.conf) : c’était bien en français.
 
J’en ai profité pour cocher la case de refus de revente des données. Ça vaut ce que ça vaut (donc que dalle sur les sites qui ne veulent pas en tenir compte, soit la totalité de ceux amenés à collecter des données utilisateurs autres que la simple IP publique), mais ça a au moins le mérite d’exister.

Attention il y a des erreurs durant la mise à jour du noyau linux 6.6.2 avec le paquet archlinux, au niveau de l'étape des hooks :

Edit : ça venait en fait du paquet ceph, qui n'est plus dans le dépôt stable (paquet orphelin ou passé sur AUR récemment ?),
en le desinstallant les erreurs disparaissent.
Je ne l'ai jamais installé explicitement, il a probablement été installé automatiquement en tant que dépendance par un autre paquet à une époque.

La dernière installation de ce paquet remonte à septembre 2022 :

Ça, tu vois, c’est le genre de c××nerie qui fait qu’Arch n’est pas pour des novices !

Ils pourraient signaler quand un paquet, installé comme dépendance d’un autre, cesse d’être nécessaire et passe sur AUR/devient orphelin/est supprimé des dépôts (AUR compris). Ça éviterait ce genre de souci (et sa variante « la mise à jour de X casse la dépendance à Y ») quand on veut faire la MAJ de son système.

Concernant Ceph : justement, un jour, j’avais vu qu’il faisait partie des paquets AUR à recompiler. N’ayant aucun souvenir de l’avoir installé volontairement, j’ai fait un « pacman -Qi » dessus et vu que rien ne le nécessitait. Il a donc dégagé.

Et il est pas le seul dans ce cas : il y a une ou deux semaines, j’en ai viré un autre pour la même raison. Webkit2gtk, je crois (j’en avais deux versions installées en parallèle, mais une seule nécessaire).

Pour savoir ce qui l’a amené, faut faire une recherche dessus dans « /var/log/pacman.log » et regarder ensuite sur le site les historiques de mises à jour des autres paquets ayant pu impliquer son installation.

Garder l'exact raison de l'installation serait une bonne chose, trop souvent je vois installé pour un paquet, sans dire lequel... super! Il s'agit parfois de paquets nécessaires pour la compilation sur AUR, et donc si je les vire j'en aurais besoin encore plus tard.

Pour le passage de paquet vers AUR, j'imagine qu'il y a une ML pour et sinon pacman -Q peut aussi aider, je me suis fait un script pour que je lance de temps en temps pour nettoyer (en plus de Qmdtq).