Reprise du message précédent :
C'est trop tard pour moi maintenant que j'ai restauré manuellement tout ça mais à garder en tête si une connerie du même genre se reproduit

Je viens de découvrir Arch-Update (AUR), pas mal pour mettre à jour.
GitHub - Antiz96/arch-update: An update notifier & applier for Arch Linux with a systray applet that assists you with important pre / post update tasks.

Youtube - Arch-Update  : Notifie les updates de Arch et aide aux tâches importantes avant et après l'update.

C'est ce qui est utilisé sur CachyOS.
(y'a un applet arch-update sys tray aussi)

Dommage qu'il faille installer AUR pour ça, ça à l'air vraiment pas mal du tout.
 
J'ai un seul PC avec la fonction AUR installée, j'avoue parfois avoir peur d'avoir un AUR malveillant et de ne pas m'en rendre compte

D'ailleurs une fonction qui serait sympa c'est avoir un choix, mise à jour à l’extinction si on a le temps de la faire

Ça fait quoi de mieux que Pamac, l’outil venu de Manjaro ?
 

Encore une fois, ce que tu dis n’a aucun sens car on n’installe pas AUR : on télécharge, on compile et on installe des logiciels qui sont sur AUR, mais ce n’est pas en soi quelque chose qu’on installe ou autre. Je te l’avais déjà dit, j’aurais aimé que tu l’aies retenu.
 
Sinon, sache aussi que tous les logiciels autres que Pacman et qui gèrent les installations, mises à jour, etc. sont uniquement sur AUR, car l’équipe d’Arch ne les veut pas sur les dépôts officiels (seul Pacman y est admis) et ne veut pas fournir de support dessus. Donc, si tu veux un logiciel graphique pour gérer les paquets, t’auras pas le choix : c’est sur AUR et nulle part ailleurs (à part éventuellement un dépôt tiers où il serait déjà précompilé, mais c’est là que le risque de tomber sur un outil malveillant réside, en vrai ; sur AUR, tu peux lire le PKGBUILD pour savoir ce que ça fait et depuis où il prend sa source).

Techniquement, les logiciels ne sont pas sur AUR non plus
On y trouve juste des scripts qui packagent des logiciels récupérés ailleurs (c'est en effet là que ça peut être dangereux) pour pouvoir ensuite les installer avec pacman

C'est un peu pour cela qu'il faut, théoriquement, lire les PKGbuild.

 
Oui je sais qu’on installe la fonctionnalité d’aller chercher des scripts sur l’AUR via Yay ou Paru que j’apprécie    
 
Oui je lis mais je ne me fais pas confiance à 100%

Si y a pas 1000 dépendances elles-mêmes sur AUR sur ton truc, tu as même pas besoin d'aucun helper AUR:
git clone + makepkg

Il serait intéressant d'avoir un outil qui lirait automatiquement le PKGBUILD pour détecter toute ligne suspecte,
 
par exemple un lien URL qui ferait partie d'une liste noire de logiciels vérolés,ou un lien qui ne fait pas partie du github du logiciel censé être compilé,  
et une détection de commandes bash dangereuses, inappropriées dans les scripts post-install, la présence d'installation de démons, de services systemd douteux,
 
avec un LLM entraîné pour détecter les PKGBUILD vérolés,  
 
l'outil de vérification pourrait être une application web ou un service web, comme ça il n'y aura rien à installer sur son PC, la vérification pourrait se faire depuis le site AUR, lorsque quelqu'un soumet un PKGBUILD le site AUR vérifierait d'abord si le PKGBUILD ne contient pas de lignes dangereuses.

à la fin il gère les paquets orphelins et le nettoyage du cache.
Mais j'aime bien Pamac aussi.

 
Ce que j'ai trouvé utile et intéressant, c'est qu'à la fin, il signale les paquets pacnew et pacsave proposant de les traiter de suite avec pacdiff. (Pacdiff étant une dépendance AUR). Pour les orphelins et le cache, un coup d’œil de temps en temps...
Sinon, moi aussi j'aime bien Pamac, et il me suffit.

Je vois ça un peu comme une amélioration de yay qui permet d'avoir un indicateur sur les maj.

 

Je viens à l’instant de recevoir une notification RSS : noyau 6.18.13 en approche pour Arch Linux !

Il semble y avoir un bug dans le noyau Linux 6.18.9 pour les cartes graphiques AMD :

- j'étais en train de regarder une vidéo youtube avec Firefox, puis brutalement écran noir, avec le son qui continue,
la seule solution est d'ouvrir une console avec la combinaison de touches CTRL-ALT-F3, puis de tuer le processus Firefox, puis de faire la combinaison de touche CTRL + ALT + backspace pour fermer Plasma.

J'utlilise Plasma 6.6.0,

dans dmesg je vois ceci :

Mais je suis en retard dans les mises à jour Pacman, je vais les faire, car j'ai vu qu'il y a une nouvelle version de Plasma et du paquet linux-firmware-amdgpu.

Bizarre, le Linux-firmware-amdgpu, je l'ai eu avant le noyau. Hier, pour le firmware et aujourd'hui pour le noyau.
Je verrais ça demain si cela me fait claquer ma session.

Moi, je crois depuis que j’ai rebasculé sur le 6.18 après que le problème de pilote Wi-Fi Intel non reconnu a été résolu (chose qui a pris son temps, vu que le mainteneur du noyau est subitement devenu un gros flemmard¹ depuis le Nouvel An), j’ai ce souci embêtant sur le PC portable :

• Parfois, j’ai l’affichage qui se fige complètement (plus rien ne bouge, pas même le pointeur de souris).
• Le clavier ne réagit plus non plus (passage en TTY impossible).
• Accès distant par SSH depuis une autre machine impossible (« no route to host », alors que je vois pourtant la LED orange de la prise RJ-45 clignoter a priori normalement).
• Si j’écoutais quelque chose, le son se met en boucles répétitives d’une seconde (et si c’est au casque et que je le débranche, ça ne bascule pas sur les HP internes).

Et le ventilateur du CPU se met à accélérer.

Je sais pas ce qui cause ça, mais je soupçonne un bug récent du noyau avec le pilote Radeon (déjà qu’il semble qu’un bug similaire affecte Fedora).

Seule « solution », a priori : éteindre de force et rallumer l’ordi, en espérant que ça ne se reproduira pas sur ma session suivante.

Comme je connais rien aux commandes journalctl qui pourraient m’être utiles pour voir si quelque chose est consigné à ces moments-là (si tant est que l’OS fonctionne encore pour pouvoir le faire…), je prends.

¹ Jusqu’à preuve du contraire, c’est comme ça que je considérerai le fait qu’on attend parfois des semaines entières pour avoir ensuite des versions devenues obsolètes dans l’intervalle.

A chaque fois que j'ai flingué mon arch, c'était à cause d'une mise à jour foireuse du noyau. Il n'y a pas une méthode pour conserver plusieurs versions d'un noyau comme dans d'autres distros?

Installe le noyau LTS en secours, et après ça dépend de la config de ton bootloader, si c'est grub, un petit update de la config suffit après install pour rajouter l'entrée.

En installant le noyau LTS en plus (vu qu’il est généralement dans une version inférieure, bien que synchrone sur les correctifs de sécurité). Il faut régénérer le fichier grub.cfg pour le prendre ensuite en compte et qu’il te soit proposé dans les options avancées de démarrage.
 
Note que si tu installes le noyau LTS en deuxième (ce qui est le cas si t’as pas opté pour lui à l’installation), c’est lui qui sera systématiquement lancé par défaut, puisque celui ajouté le plus récemment. Pour éviter ça, tu peux demander à ce que Grub sauvegarde le dernier choix validé dans « /etc/default/grub », puis régénérer le fichier grub.cfg pour que ce soit pris en compte. Au démarrage suivant, tu vas dans les options avancées, puis tu choisis sur quel noyau démarrer (le dernier choisi étant pré-sélectionné).

Voici quelques captures d'écrans de ma Surface Go 1 sous Arch
 




 
Les deux première captures, la mise à jour datait de plus longtemps et la deuxième plus rapprochée.
 
C'est une config bureautique et quelques jeux sur Steam, marche au poil rien à voir avec Windows qui est inutilisable dessus.
 
Bref, j'ai 3 config sous Arch, aucun plantage pour le moment depuis quelques années, j'en suis très content.  
 
Je suis sous Debian sur mon PC jeux pour le test, il va bientôt rebasculer sous Arch, mais Debian va vraiment très bien, mais il est un chouia plus lent

Nota que dans certains cas rares, tu auras le meme noyau en standard et LTS. Choix douteux mais...

C'est aussi con que ça?
Sinon, j'utilise Systemd-boot. Je ne pense pas que cela soit radicalement différent de Grub.

J'utilise aussi systemd-boot, faut ajouter une entrée dans /loader/entries/ (tu dois déjà avoir arch.conf, fais-en une copie arch-lts.conf et met les infos du LTS dedans à la place du noyau classique).

Merci.

Cas de niche mais qui peut devenir chiant en effet.
Donc soit mettre le linux-lts en ignorepkg 99% du temps...
Ou bien installer un LTS de l'AUR soi-même (sans forcément le tenir à jour en permanence...) juste en secours, par exemple https://aur.archlinux.org/packages/linux-lts66

Heu, non, tu mets pas le LTS en IgnorePkg… Le problème signalé est valable uniquement quand le paquet « linux-lts » passe à la branche LTS suivante, alors que le paquet « linux » n’a pas eu le temps de passer à la LTS + 1 (donc 6.19, cette fois). Donc, en début d’année seulement.
 
Mais comme il n’y a aucune trace de 6.19 chez Arch (même pas sur le GitLab) et que le LTS semble vouloir rester en 6.12…
 
Quant aux noyaux sur AUR, merci, mais j’ai justement voulu voir pour celui-là et, même sur une VM avec 4 CPU, autant de jobs dans le makepkg.conf et 8 Gio de RAM, la compilation a pris des heures et des heures (je peux pas dire exactement combien : j’ai dû mettre la VM en pause pendant un moment et le chronométrage avec la commande « time » a tenu compte de l’heure de fin…). À faire en vraiment dernier recours et si on a vraiment une journée à perdre (et des watts à dépenser).

Mais oui, comment s'en remettre si ton kernel de secours est en 6.12.87 au lieu de 6.12.92  

J'ai installé différents noyaux, genre arch normaux, cachy (ou zen) en espérant qu'ils ne soient pas tous mis a jour en meme temps ce qui pourrait laisser le temps de faire ce qu'il faut.
A une epoque j'avais un double boot arch/arch pour reparer si besoin en etait, ou plutot pour pourvoir regarder des films pendant le dinner si l'OS principal etait en rad. (Le truc a l'origine c'etait juste d'etre passe d'un SSD a un autre et je ne savais pas quoi faire de l'ancien alors je l'ai garde branche puis un jour ca a servi et je l'ai garde ainsi...)

 
Je dois avoir du bol car 2 config Intel et AMD et aucun soucis jamais  

C'est juste une question de chance. Pour dire mon niveau, il y a quelques années, il y avait un bug Intel dans le noyau qui pouvait potentiellement flinguer la distro...Je l'ai eu avec un Ryzen.  

N'ayant jamais eu à réparer mon sytème en catastrophe, je me fourvoie peut-être complètement.
Mais il suffit pas de booter un Linux sur une clé USB prévue pour ça, de monter son disque puis de faire un chroot ? Ca me parait moins prise de tête que de gérer plusieurs noyaux en local.

Sur mon pc portable non test j’ai le choix du noyaux LTS et de celui en cours je les ai demandé à l’install avec Arch Install.
 
J’avais une fois dis que je ferai un topo sur les choix que je fais dans Arch Install je fais ça cette semaine  

Archinstall propose 3 noyaux: Celui de base, le Zen et le LTS.

C’est ça et j’ai le choix je me suis dis en cas de merde

Oui c'est une autre approche complètement valide, tu as raison.
Il y a plusieurs de façons de faire, ensuite chacun voit midi à sa porte.

l'histoire du chroot, je l'ai déjà fait aussi, car sddm ne fonctionnait plus suite à une personnalisation. Faut préparer la clé, faire la manip et tout, j'ai passé beaucoup de temps à chercher les infos de comment faire avant de réparer. Quand on n'a pas les bases de barbu ce n'est pas trop intuitif

Comme Targan, j'ai plusieurs noyaux pour démarrer, que j'ai dû choisir à l'installation avec archinstall ou architect, je ne sais plus trop.

D'ailleurs j'ai une photo (systemd-boot) :

On peut aussi démarrer sur une clé USB contenant l'image ISO de l'installateur d'Arch Linux, on tombe par défaut sur une console,  
 
de là on peut ensuite charger le clavier français, puis lancer le script qui fait un chroot, puis ensuite on peut downgrader le paquet qui empêche le démarrage normal du PC.
 
Sur le wiki de Arch Linux il y a un article qui explique tout cela.
 

 
https://wiki.archlinux.org/title/Chroot_(Fran%C3%A7ais)
https://wiki.archlinux.org/title/Chroot

@Trit' : réponse cross topic à propos de ta dernière intervention sur Le topic des 'uname -a'.
On en parle sur le forum Endeavour  https://forum.endeavouros.com/t/wha [...] 18-9/78228
Ce qui m'a fait sourire, c'est qu'on parle du fait que le Kernel 6.18.9 a été flagué out of date Qui aurait eu l'outrecuidance de faire ça?

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 !