Reprise du message précédent :
Je pense à un problème lors du rebuild du mkinitcpio...

Edit : pourtant, les entrées du kernel standard et du LTS sont identiques dans refind.conf :

"Boot with standard kernel" "root=PARTUUID=b5f45c1f-6630-9c45-ae6f-2f05f2793c37 rw add_efi_memmap quiet acpi=force i915.fastboot=1 initrd=\boot\intel-ucode.img initrd=\boot\initramfs-linux.img resume=UUID=0e870c5e-b3a3-40f7-8ead-d75451c7bb6b"
"Boot with LTS kernel" "root=PARTUUID=b5f45c1f-6630-9c45-ae6f-2f05f2793c37 rw add_efi_memmap quiet acpi=force i915.fastboot=1 initrd=\boot\intel-ucode.img initrd=\boot\initramfs-linux-lts.img resume=UUID=0e870c5e-b3a3-40f7-8ead-d75451c7bb6b"

Il faudrait regarder le log avec la commande journalctl, afin de voir le message d'erreur détaillé, en mode root :

et aussi la commande :

Tu as peut-être des modules incompatibles avec le noyau LTS, un paquet AUR qui utilise un module incompatible avec le noyau LTS, un module manquant, notamment si dans le log de journalctl tu vois ce genre de message :

Voir aussi ces messages :
https://forums.archlinux.fr/viewtop [...] 15&t=21284
https://forums.archlinux.fr/viewtopic.php?t=21285

As-tu installé le paquet linux-lts-headers ?
Mais son absence ne devrait pas poser de problèmes, sauf si d'autres paquets en ont besoin pour compiler des modules pour le noyau LTS en utilisant l'outil dkms, qui lui a besoin du paquet headers de chaque noyau installé,
des logiciels comme virtualbox utilisent des modules qu'ils compilent à partir du paquet headers du noyau concerné.

Si tu es du genre à avoir une configuration qui s'éloigne de celle d'un utilisateur lambda (c'est à dire utilisation de logiciels et de matériels dernier cri, parfois en version expérimentale, du wayland, des pilotes vidéos propriétaires douteux, des logiciels AUR à la pelle, un montage de partitions compliqué avec chiffrage) alors ça augmente le risque de problèmes si le noyau LTS ne supporte pas ces aspects hyper high-tech.

Mais la par exemple aujourd'hui j'ai tourné sur le LTS, c'est le standard qui foire. Quand c'est pas l'un c'est l'autre, mais c'est pas forcément le LTS.

Je regarderai les logs de systemd, merci.

Ah, le Gestionnaire de tâches de XFCE…
 
Hier, il avait eu droit à une MAJ mineure qui corrigeait enfin le problème de la barre d’état qui s’affichait à chaque ouverture sur la version 1.5.2, quand bien même on désirait la masquer (parce que la légende des couleurs, c’est plus utile une fois que tu sais à quoi ça correspond).
 
Aujourd’hui, c’est la version 1.5.3 qui débarque ! Alors, outre un passage au CSD (décoration côré client, les barres d’en-tête de Gnome qui ne sont plus gérées par le gestionnaire de fenêtre), un nouveau bug est apparu : il s’affiche uniquement en anglais ! Bref, sur une Arch installée et réglée en français, la localisation est pétée (comme c’est le cas avec XScreenSaver depuis la version 6.03 de fin février dernier et toujours pas corrigée, au passage).
 
J’ai évidemment envoyé un rapport de bug (qui reprend d’ailleurs mot pour mot les termes de celui pour XScreenSaver, en en changeant juste les mots et nombres qu’il faut). À voir combien de temps ils vont mettre à réagir et proposer un paquet corrigé…
 
EDIT 16h28 : bug corrigé (enfin, plus exactement contourné) avec la version 1.5.3-2 du paquet, publiée il y a une quinzaine de minutes.

Depuis une mise à jour de plusieurs paquets je remarque maintenant qu'un bip se fait entendre du haut parleur interne du PC à l'extinction,
 
Avez-vous remarqué la même chose ?
 
J'ai un vieux PC de 2007, socket 775 pour CPU Intel core 2.

De toute évidence, c’est la petite nouveauté de Systemd 251 (avec le message pas alarmant du tout « The system is going down to poweroff NOW!!! », qui apparaît même en mode « quiet »).
Ça me le fait sur le PC fixe, mais pas sur le portable (puisque pas équipé de bipeur interne, mais c’est clairement la seule raison).

À noter que le bip se déclenche si j’appuie sur le bouton de la tour pour déclencher l’arrêt depuis ma session utilisateur, ou que je demande un redémarrage depuis le menu qui va bien ; mais ça ne le fait pas si je demande un redémarrage depuis l’écran de connexion de LightDM, par exemple (le message qui veut faire peur s’affiche quand même, lui).

Oui c'est bien à cause de systemd :
https://www.reddit.com/r/archlinux/ [...] rading_to/
https://forum.endeavouros.com/t/sol [...] down/27389

Ce bip à l'extinction fait peur dans le sens où le haut-parleur intégré à la carte mère sert pour le bios à indiquer une anomalie (problème matériel, barrette mémoire HS, température CPU trop élevée), excepté le cas du bip court au démarrage pour indiquer que tout est Ok.

https://www.vulgarisation-informati [...] s-bios.php

(DE: kde plasma) et j'ai aucun bip durant le boot ou shutdown   en meme temps je m'en plaint pas   (bip classique du bios/post : actif)  
quand aux message "shutdown" je ne le voit pas et je n'ai rien dans les logs, l'affichage défile trop vite pour le voir (si il y en a un) idem avec "quiet" viré :

A essayer :

N'étant pas impacté je ne peux pas tester mais en toute logique "blacklist pcspkr" devrait supprimer ce bip (si c'est pas le cas désolé), sinon attendre une prochaine maj de systemd si y'a un souçi ça sera sans doute assez vite corrigé.

Faut voir si dans le mixer audio le haut-parleur PC n'est pas mis sur la position "mute".

Et voir si le module pcspkr est bien chargé au boot.

D'après ta config tu as une carte mère UEFI récente, il y a peut-être une option dans le bios UEFI qui désactive le haut-parleur PC une fois le système d'exploitation lancé, ou bien le module pcspkr qui ne reconnait pas le haut-parleur PC sur ta config.
Moi j'ai une vieille carte mère qui n'est pas compatible avec UEFI.

L’hypothèse la plus simple est encore que l’ordi de Sokarz ne soit pas équipé d’un HP bipeur interne (comme c’est le cas de mon PC portable). Voilà pourquoi il entend pas de bip, lui : ça veut pas dire qu’il n’est pas émis par le système, mais juste qu’il n’y a pas le matériel nécessaire pour qu’il se produise.

exact (bien vu ^^) ! modules chargé mais... j'avais oublier que j'avais retirer le speaker (volontairement l'année dernière, syndrome de la femme qui gueule, toussa, bref...) du coup même avec le modules chargé ça risque pas de faire bip lol
 

C'est couillon mais j'avais oublié.
 
Ceci dit si "vous" blacklister pcspkr logiquement ça devrait plus faire ce bip du à la maj systemd ?

Attention, si vous utilisez XFCE comme DE sur Arch : il y a eu un bug avec la mise à jour du paquet libx11 en version 1.8.1, qui fait que XFCE ne se lance pas (on reste sur un écran noir avec juste le pointeur de souris).
 
Le bug est connu, et corrigé contourné avec la version 1.8.1-2 du paquet pour Arch, mais si elle n’est pas encore dispo sur les miroirs, il faut rétrograder en version 1.8 (sortie le 30 avril) pour retrouver un XFCE fonctionnel en attendant.

La MAJ foireuse du jour : yay (sur AUR)…
 
Déjà, premier problème : alors que j’avais bien récupéré le PKGBUILD et que j’en avais lancé la compilation, il n’est pas parvenu à télécharger le paquet go en dépendance (il en réclamait une version 1.17 minimum, c’est la 1.18 qui est dans les paquets…).
Ensuite, même en ayant téléchargé manuellement go, une fois la compilation, et l’installation de yay 1.12 faites, ce dernier segfault… Inutilisable. J’ai dû revenir à la version 1.11.2 pour retrouver une version fonctionnelle.
 
Le plus bizarre, c’est que c’est l’auteur du logiciel qui en est le mainteneur du PKGBUILD, et j’ai vu aucun message signalant un tel bug, aussi bien sur AUR que sur le GitHub…
 
EDIT : fausse alerte, ça a marché à la deuxième tentative. Mais pourquoi ça a foiré à la première, alors ? Parce qu’il y avait eu des MAJ du noyau et de zstd, et que j’avais pas encore redémarré ? Ça aurait pas dû faire foirer…

à propos de zstd sur arch j'ai lu ça aujourd'hui : https://www.phoronix.com/scan.php?p [...] zarre-Zstd
(je ne pense pas qu'il y ait un rapport)
 
sinon de mon coté yay à été maj du 1er coup, mais j'avais rebooter entre temps (maj kernel + reboot : fait avant la maj de yay, je dis ça de mémoire mais j'en suis quasi sur)

À voir si ça avait un lien avec le fait que les MAJ de Wine mettaient pas moins de 30 secondes à se faire, dernièrement (alors que celle de ce matin a été faite en dix fois moins de temps)…

Vous utilisez Guake (affiche une pop-up de ligne de commande comme dans Quake, Wolfenstein…) ? Alors ne mettez surtout pas à jour libnotify en version 0.8 : ça va l’empêcher de se lancer ensuite !
 
J’ai dû rétrograder libnotify en version 0.7.9 pour pouvoir le faire fonctionner de nouveau…
 
Rapport de bug ici :
https://bugs.archlinux.org/task/75329
 
J’ignore si d’autres paquets sont touchés par cette incompatibilité (qui touche à des modules Python), cela dit.

J'ai la version 0.7.12-1, est-elle touchée par ce bug ?
 

Non : elle, ça va. C’est la version 0.8.0 mise hier dans les dépôts qui pose problème. Ne mets surtout pas ce paquet à jour et bloque-le dans /etc/pacman.conf jusqu’à nouvel ordre.
 
Ça a même été remonté sur le GitHub de Guake.
 
0.7.12 ? Ah, oui : le site des archives de paquets a un classement assez rudimentaire, et j’étais assez pressé de remettre une version qui devait fonctionner… J’avais pas vu que les versions les plus récentes des 0.7.x étaient en début de liste. Je viens de la réinstaller à la place de la 0.7.9, du coup. Merci !

Peut-être un moyen de contournement pour guake vu l'erreur :

si tu édites le fichier /usr/lib/python3.10/site-packages/guake/notifier.py à la ligne 23, en remplaçant la ligne :

par

alors il se peut que l'erreur disparaisse avec la version 0.8 de libnotify.

https://github.com/Guake/guake/blob [...] otifier.py

Ça mérite d’être essayé, oui. En tout cas, j’ai signalé ta proposition sur le bugtracker d’Arch et sur le GitHub de Guake.

EDIT 16/7 : apparemment, ta bidouille marche ! Merci pour eux !

Bonjour,
 
Bidouille approuvée : https://github.com/trinaldi/guake/c [...] eb4e33459e
 
Bien vu    

Ah, d’accord… Y a un type, il a patché le paquet libnotify, pour faire en sorte que celui-ci renvoie une version 0.7 au lieu de la 0.8 ! Total : Guake encore cassé car il faut défaire ta bidouille, Elbarto ! Heureusement, je sais comment faire, donc j’ai déjà pu le réparer, mais bon…
 
Mais lorsque l’équipe de Guake va en sortir une nouvelle version qui s’appuiera, elle, sur libnotify en version 0.8, il faudra dépatcher ce dernier.
 
J’ai l’impression qu’ils ont pris le problème par le mauvais côté, là.

Bonjour,
J'ai suivi le sujet sans être concerné: je n'utilise pas quake.
Par contre, je me suis rendu compte que cinnamon-control-center ne se lançais plus. Après une mise à jour, dont libnotify, il fonctionne de nouveau. Libnotify requis par cinnamon-setting-deamon.
J'ai aussi Vera-crypt en défaut, mais là c'est dû à wxWidgets-3.2, je creuse...    

Non, mais j’y crois pas… Le paquet libnotify a été mis à jour en 0.8.1 (peut-être pas encore dans les miroirs, ça date de 15 minutes seulement), et le patch pour le faire fonctionner avec Guake a été retiré (donc, il va à nouveau falloir re-patcher le fichier indiqué par Elbarto)…
 
Bon, c’est fini, ces va-et-vients incessants ? J’aime pas les girouettes, moi !
 
EDIT : ou peut-être pas, finalement… Et je vois que ça affectait aussi system-config-printer et GNOME Tweak, ce « bug ».

C'est devenu une belle m*rde tiens ça ... On sent que tout le passage vers Qt n'a pas eu le même intérêt chez wxWidgets. Le passage vers wxWidgets > 3.0 a fait du mal et était indispensable suite à python 3.10 ou wxpython 4.0.7post2 qui était dans la majeure partie des distribs avec des patchs de wxpython 4.1 à gogo ... et d'un autre côté on a un truc pas très clair où les devs balancent peu de releases mais certains soft se basent sur des préversions dispo pour windows et mac mais pas pour linux ... La release de la 3.2 est une surprise pour moi !

J'ai remarqué que ma carte PCI-E USB3 "supageek" n'est plus détectée par le système, si je fais un "lspci" je ne vois plus la carte PCI-E USB3,

j'ai cru à un bug du noyau linux, mais j'ai la même chose avec le noyau LTS,

puis je me suis dit que c'était peut-être une surchauffe liée à la canicule : j'éteins le PC, j'attends 5 minutes que ça refroidisse, je rallume et je constate que la carte PCI-E USB3 est de nouveau détectée,

quelqu'un a déjà eu ce problème ?
C'est une vieille carte mère de 2007 (socket 775, chipset intel P35),

lscpi renvoie cette information sur cette carte PCI-E USB3 :

https://www.amazon.fr/gp/product/B07FK28BXX

Moi, c’est le Wi-Fi qui m’a lâché deux fois sur le PC portable, dernièrement. Dans les deux cas, un simple redémarrage (pas besoin de tout éteindre) a suffi à le refaire fonctionner, mais je comprends pas pourquoi (à part le fait que le composant date, comme le reste de l’ordi à l’exception du disque dur où Arch est installée, de 2009).

Une erreur aujourd'hui en voulant faire un pacman -Syu :
 

 
 
Le paquet wxgtk2 n'est plus sur les dépôts officiels, je l'ai donc supprimé et la mise à jour a pu se faire.

wxgtk2 est censé disparaître, chez moi ça s'est bien passé tout a été remplacé/désinstallé correctement sans que j'intervienne.

Ton miroir est peut-être à moitié synchronisé.
Attends quelques heures ou changes-en.

EDIT: Ah j'ai raté la dernière ligne. Mais normalement y a rien à faire.

Le dernier pacman -Syu chez moi remonte à plus d'une semaine,
 
j'utilise comme miroir : http://archlinux.polymorf.fr/$repo/os/$arch
 

C’est justement ce qui est préconisé sur le site d’Arch.
 

Sur le fixe, j’ai rien eu à faire. Mais sur le portable, il m’a fallu le désinstaller manuellement parce que la MAJ échouait à cause de lui. Pas de bol : ça a entraîné la suppression d’Arnold, un émulateur CPC qui avait, lui aussi, disparu des dépôts et d’AUR depuis déjà un moment…

Je remarque que sur le site français d'archlinux on ne trouve pas l'info de desinstallation de ce paquet sur la page d'accueil :
https://archlinux.fr/

alors que sur la version anglaise on voit cette info datant du 14 juillet :
https://archlinux.org/

Sinon une question :
est-ce qu'il est possible de booter le PC depuis un port USB 3 ?

Ou bien le bios ou l'UEFI ne gère que l'USB 2 et 1 pour le boot USB ?
https://forum.pcastuces.com/booter_ [...] s81468.htm

Ma carte PCI-E contrôleur USB 3.0 n'est active qu'après qu'un système d'exploitation soit lancé, le bios ne le voit pas au boot, ma carte mère date de 2007 et a un bios classique.

En effet, en regardant dans les logs, j'avais wxgtk3, pas wxgtk2, sûrement pour ça que tout a été automatique

archlinux.fr n'est pas le site français d'archlinux.
C'est un site communautaire non officiel.

Je le fais, mais ce sont des ports de la CM c'est peut-être pour cela...

Il est possible que ça vienne de mon bloc d'alimentation, il a plus de 10 ans, et le +12 volts est hors des tolérances de la norme ATX : il délivre 12.74 volts au lieu des 12.6 volts maximum (la norme ATX impose 5% de tolérance maximum, soit des valeurs comprises entre 11.4 et 12.6 volts).

J'ai commandé un nouveau bloc d'alimentation sur une boutique en utilisant un bon d'achat, un 650 watts, pour remplacer le 400 watts que j'ai actuellement.

Marque Asus gaming TUF, je ne sais pas ce que ça vaut en bloc d'alimentation, c'est une boutique cadeau qui avait que ce modèle en stock, ça m'a rien couté grâce au bon d'achat :
https://www.asus.com/fr/Motherboard [...] /techspec/

J'ai pensé au bloc d'alim suite à cet utilisateur qui avait le même souci (détection aléatoire de la carte USB3 PCIe au boot, obligé d'éteindre le PC et de le rallumer pour que la carte soit détectée), ça a été résolu en changeant de bloc d'alim :
https://superuser.com/questions/128 [...] e-on-anoth

Bloc d'alim asus TUF gaming 650 watts reçu,

ça semble avoir résolu le problème de détection aléatoire de la carte PCIe USB3, le 12 volts est maintenant mesuré à 12.35 volts au lieu de 12.74.

J'espère que ça résoudra aussi un crash aléatoire que j'ai avec ma carte tuner TNT PCI, de manière aléatoire lors d'un zapping avec VLC l'affichage peut se figer, ainsi qu'archlinux (la souris, le clavier ne répondent plus), j'ai mis la faute pour l'instant sur un bug du pilote libre radeon pour l'accélération graphique h264, mais ça pourrait venir aussi d'une instabilité du bloc d'alimentation.

Au cas ou ce problème toucherait quelqu'un: https://bugs.archlinux.org/task/75478

https://gitlab.com/anarchyinstaller [...] 4972e73b31

Mieux vaut faire ça en effet, plutôt que de laisser pourrir les choses en empêchant un éventuel nouveau mainteneur de prendre la suite  

Est-ce que c'est dans le domaine du possible de normaliser une installation archlinux via une API (qui serait alors maintenue par les développeurs de l'iso archlinux) ?

L'idée c'est de fournir à ces développeurs d'installateur graphique une bibliothèque de fonctions, leur permettant d'avoir un niveau d'abstraction suffisant pour ne plus être pris en traître quand des changements importants sont faits dans l'iso archlinux, un peu comme un développeur de jeux vidéos qui utilise l'API OpenGL ou Vulkan (ou mieux : un framework) pour se faciliter la vie, au lieu de taper directement dans les fonctions du pilote vidéo.

Une installation archlinux c'est souvent des étapes classiques :

- configuration de la langue, du clavier, réseau, configuration des dépôts, partitionnement et formatage du disque dur/SSD, choix du shell (bash, zsh), installation de paquets de base du système, création d'un compte utilisateur et de son home, choix du bureau (plasma, gnome)

une API "installation" avec des fonctions gérant les étapes ci-dessus simplifirait la tâche du développeur dans la création de son installateur graphique, il aura juste à gérer les fenêtres de l'installateur, l’enchaînement des étapes, en passant en arguments à ces fonctions de l'API le choix de l'utilisateur (langue française, clavier azerty, type de partitionnement etc...).