Reprise du message précédent :

En passant directement par Pacman, qui ne tient pas compte d’AUR lors de ses consultations des dépôt pour voir s’il y a des MAJ ?
 
Sinon, quand Yay te demande si tu veux exclure des paquets, il t’indique que tu peux entrer les numéros de ce ou ces paquets de diverses manières, ou les noms des dépôts eux-mêmes (donc « aur », dans ce cas).
 
Mais mettre à jour les paquets d’AUR est quand même nécessaire.
 
Dernière chose : si ce sont toujours les mêmes paquets, tu peux les renseigner parmi ceux à ignorer dans « /etc/pacman.conf » (une ligne à décommenter et les paquets concerner à noter à la suite ; mais là aussi, ça ne peut pas être une solution de long-terme : ça ne doit être utilisé que si une MAJ de paquet s’avère bugguée, uniquement le temps qu’une version corrigée sorte).

Oui je peux passer par pacman, mais j'ai pas envie de taper "sudo pacman -Syu" quand "yay" suffit.
 
Et oui je sais que je peux exclure des paquets mais j'ai la flemme de le faire à chaque fois.
 
Et oui je sais qu'il faut mettre à jour les paquets AUR mais j'ai plein de paquets AUR qui échouent à compiler, donc en général je mets à jour les paquets classiques en premier, puis je mets à jour les AUR un par un. D'où ma question.

Je me fais toujours un sudo pacman -Syu et ensuite un paru, j'avoue que je sais que paru peut tout faire en une fois mais comme j'ai jamais eu de problème en faisant ça...
 
Par contre pour un PC de jeux sur la TV j'envisage le retour à Windows, impossible d'avoir un Steam Big Picture Fluide, et je n'ai que des ennuis avec mes manettes Xbox Series avec le stick microsoft en 2,4ghz.  
 
Il faut toujours chiopter pour réussir à appairer la manette, tirer le stick le changer de port et redémarrer la manette pour qu'elle soit vue. ça ne marche jamais au boot directement. C'est con car j'adore être sous Gnome avec Arch tout est fluide rapide intuitif. Mais bon je me dis pour un PC qui va booter direct en big picture...  
 
Un poil déçu et pas envie de me lancer dans des bazite, garuga ou je ne sais quoi, aucune idée si c'est vraiment stable  

Pour ça, je garde des commandes que je veux pouvoir retrouver facilement au début de mon « ~/.bash_history » (que je purge chaque semaine, à l’exception de ces commandes-là ; de toute façon, il n’enregistre que les 500 dernières commandes et efface les plus anciennes quand ce seuil est atteint, donc…), dont un « time yay » (parce que j’aime savoir combien de temps prend une commande qui dure un moment à d’effectuer).
 

En vrai, je fais pareil : je fais d’abord les MAJ des paquets des dépôts, et je compile les AUR dans un deuxième temps ou quand je peux prendre le temps de le faire (je compile sur des Core 2, pas des i3/5/7…). Et encore, ça ne concerne que ceux dont j’ai vraiment besoin ou qui sont nécessaires à d’autres paquets (ceux qui se retrouvent mis sur AUR parce que c’étaient d’anciennes dépendances qui ne sont plus nécessaires, dont je n’ai pas l’usage et qui ne sont plus requis par personne dégagent).

yay met d'abord à jour les paquets des dépôts, puis ensuite ceux de AUR, donc je fais tout en une seule fois par yay.
 
Quand la compilation d'un paquet AUR plante, je relance en l'excluant jusqu'à la prochaine mise à jour.
 
Jusqu'à maintenant je n'ai jamais eu de souci de mise à jour en faisant comme ça.

Ah, moi, je ne dis pas que ça ne marche pas avec Yay (ce serait malheureux : l’outil a été conçu dans le but de s’occuper tout seul d’AUR en plus des dépôts contenant des paquets précompilés !) ; seulement que, quitte à devoir me farcir de la compilation, j’ai fini par préférer m’en occuper de manière séparée, via « yay -G » et ensuite un bon « time makepkg -sri » (ou « -sr » si c’est pas pour installer de suite, ni sur l’ordi où est faite la compilation) des familles !

Faut dire qu’avec deux ordis ou plus, autant ne compiler qu’une fois sur le plus puissant et éviter de répéter l’opération sur les autres, pour lesquels ça va plus vite de copier le paquet déjà compilé et l’installer manuellement avec « sudo pacman -U ».

Mais je sais que laisser Yay le faire fonctionne, en général (sauf rares exceptions signalées où il semble étrangement que la compilation avec lui échoue, quand une faite manuellement réussit).

Version 128.3.0-1 livrée. A la mise à jour hebdo du dredi... Nommée 128.3.0esr dans l'à-propos de Thunderbird.

J'ai installé le dernier kernel, et là c'est le drame
 
Ca boot pas...
 
dans le KVM, j'ai SYSLINUX xx : no configuration file found
 
 
Comment je répare ça ?

Essaie de démarrer sur l'image ISO de l'installateur d'arch linux, puis une fois arrivé dans la console tu regardes si tu arrives à monter tes partitions,

normalement le fichier de configuration de syslinux est /boot/syslinux/syslinux.cfg, il faudrait voir si ce fichier est toujours là,

tu peux aussi faire un chroot pour pouvoir réinstaller le paquet syslinux, ou downgrader le paquet responsable du souci,

la procédure du chroot :
https://wiki.archlinux.org/title/Chroot_(Fran%C3%A7ais)
https://wiki.archlinux.org/title/Chroot

le downgradage de paquets :
https://wiki.archlinux.org/title/Do [...] %C3%A7ais)

la fiche arch linux sur syslinux :
https://wiki.archlinux.org/title/Syslinux

On utilise plutôt grub que syslinux pour les installations de distribution linux sur disque dur/SSD :
https://wiki.archlinux.org/title/GRUB

Possible que le problème ne vienne pas d'arch linux mais de ton fichier de machine virtuelle, s'il y a eu une corruption de données (secteur défectueux sur ton disque dur, SSD, barrette mémoire défectueuse, PC instable).

merci pour ces liens.
 
il s'agit d'un serveur dedibox donc je ne peux pas booter sur ce que je veux.
 
pour l'instant je démarre en mode rescue depuis une image Ubuntu 22.04 (il n'y a pas arch dans la liste des images)
 

 
j'arrive à monter  
/dev/sda3 dans /mnt
/dev/sda2 dans /mnt/boot
 
j'ai une partition /dev/sda1 de 1Mo qui ne se monte pas.
 
Il ne semble pas y avoir de /mnt/boot/syslinux/syslinux.cfg <-- ce qui fait que j'ai ce message d'erreur au boot.
 
j'ai tenté un chroot /mnt, puis un pacman -Suy mais ca merde car /mnt/dev est pas monté comme il faut.
 
Je regarderai ca demain. J'ai juste fais un pacman -Suy avant le reboot qui a été fatal...
 
Si j'ai bien compris j'ai syslinux et non GRUB ?

Il faudra que je chroot avec ca : https://wiki.archlinux.org/title/Ch [...] vec_chroot

J'ai chroot suivant la doc mentionnée dans mon message d'au dessus
 
Et j'ai juste eu à faire un
 

 
et mon fichier /boot/syslinux/syslinux.cfg a été recréé, et ca boot !
 
Merci pour les liens

J'ai un gros problème depuis que j'ai migré vers Plasma 6.2.1, SDDM ne fonctionne plus (core dump). Même en downgradant les paquets. J'ai du lancer GDM et Gnome car Plasma refuse de se lancer depuis GDM. Je n'ai aucune idée de comment faire refonctionner SDDM...

J'ai remis à jour les paquets, SDDM est toujours cassé mais au moins je peux maintenant lancer Plasma depuis GDM...

Même problème que toi ce matin, sddm bloque et ne veut lancer aucun session disponible (ni plasma X11 ou wayland, ni Hyprland que j'ai aussi).
 
Plus simple que d'installer GDM, tu peux démarrer ta session dans un tty avec startplasma-wayland une fois loggué avec ton user.
 
Ensuite après quelques recherche, il s'avère que c'est le thème Breeze qui est tout pété si tu y met une image perso en arrière plan, j'ai switché sur un autre thème (Maldives, en y mettant aussi une image d'arrière plan perso), et la session démarre correctement.
 
Si je reviens sur le thème Breeze, ça rebloque l'ouverture de session, et même si j'essaie de virer l'image d'arrière plan perso, celle-ci reste sur le thème, faut que je trouve pourquoi, ça devrait débloquer le problème avec ce thème.

J'ai testé plusieurs thèmes que j'avais d'installé, aucun ne se lance et SDDM bascule sur son thème par défaut immonde (mais au moins, il fonctionne ).

Y'a que les thèmes intégrés qui fonctionnent (Maldives, etc.), tout ce qui est thème installé ne fonctionne pas et affiche le thème défaut pas beau, oui

Arf, chez moi, les thèmes téléchargés/installés fonctionnent

KDE Neon ... chut

Il y a un ticket ouvert pour suivre ce bug ?

Comme souvent ce sont les utilisateurs de distributions rolling-release qui se ramassent les bugs non détectés par les auteurs du logiciel fautif (SDDM ou une de ses dépendances).

Moi je mets à jour arch linux qu'une fois par semaine, et je n'ai pas encore mis à jour, j'attends que cette histoire de SDDM cassé soit résolue.

Je viens de faire la mise à jour, pas de souci avec SDDM mais je n'utilise que le thème intégré breeze.