Reprise du message précédent :
Moi j'ai ça :
 
HOOKS="base udev autodetect modconf block filesystems keyboard fsck"

Pour le logo, c’est le paquet Plymouth qui l’affiche.
 
Pour la date d’installation, tu peux regarder le début du fichier « /var/log/pacman.conf ».
 

C’est justement l’ancienne liste des hooks, ça. Elle date de quand, ta dernière MAJ ? Tu as bien mkinitcpio 40 ? Jamais modifié « /etc/mkinitcpio.conf » ?

ca te donne la date de création du filesystem (et donc généralement la date de l'install, à moins qu'il y ait eu des gros bricolos..)

Oui, il y a plein de manières de trouver la date. On peut aussi citer « (sudo) tune2fs [point de montage de /] | grep Created » pour trouver la date de création du système de fichiers de la partition où est monté « / ».

Je regarde ça ce soir    
 
Je ne savais pas pour le logo, c’était pour situer un peu la date d’installation comme je n’avais pas ça avant  

 
Je n'ai pas encore fait la mise à jour, j'ai la version 39.2-5.
 
La dernière modification du fichier de configuration doit remonter à plusieurs mois, quand il fallait faire une modification manuelle du fichier de configuration pour supprimer un élément obsolète.

yo,
sous arch, y'a pas eu une blague tres recemment, pour ceux qui utilisent du LVM ?
ici sous artix (fork de arch), apres upgrade des packets device-matter et lvm2, ca m'a viré des fichiers dans le dossier /usr/lib/initcpio/udev/
Du coup, le build de l'initramfs échouait  
Une fois ces 2 packages downgradés pour revenir à la version precedente, le mkinitcpio refait à nouveau son boulot sans erreur. ouf !

edit: ok, ca a l'air justememnt d'etre lié à la v40 de mkinitcpio dont vous parliez au dessus
https://gitlab.archlinux.org/archli [...] 3641c9b1dc
et ya des changements qui sont arrivés un peu trop tôt dans artix sans que mkinitcpio soit mis à jour correctement
du coup, pour anticiper, la modif du mkinitcpio.conf consisterait en quoi ?

 
J'ai trouvé un moyen de contournement pour avoir du son dans gwenview :
 
- définir la variable d'environnement QT_MEDIA_BACKEND sur gstreamer :
 

 
chez moi cette variable était vide, vous avez quelle valeur quand vous tapez "echo $QT_MEDIA_BACKEND" ?
 
J'ai essayé ensuite "export QT_MEDIA_BACKEND=ffmpeg" mais là pas de son, pourtant le backend ffmpeg pour qt6-multimedia est installé :
 

 
ainsi que gstreamer :
 

 
J'ai installé aussi tous les plugins de VLC, c'est donc étrange ce problème avec le backend ffmpeg pour qt6-multimedia.

Pas souvenir d’avoir modifié ce fichier. En tout cas, il m’a jamais signalé de .pacnew lors de la MAJ, ce qui serait arrivé si je l’avait fait…
 

Les joies des forks qui utilisent leurs propres dépôts, je suppose…

Ok, je me suis décidé à faire une petite recherche pour ce truc, et ça ne m'a pas pris longtemps : https://bbs.archlinux.org/viewtopic.php?id=310004
Donc en gros il suffit de mettre la liste de hooks donnée en exemple dans le fichier :

ET de changer de syntaxe dans /etc/default/grub :

au lieu de

Puis bien sûr 'grub-mkconfig -o /boot/grub/grub.cfg' et 'mkinitcpio -P'.
Ça doit être un peu plus rapide à booter qu'avant au final, mais c'est un peu bizarre, car il y a un service en attente de démarrage pendant qu'on tape le mot de passe luks et que ça déverrouille, de sorte qu'on se demande si le timeout va pas expirer… heureusement il est de 90 secondes en l'occurrence, mais bon…

Pareil ici. Ne pose pas de problèmes pour mon utilisation. Je prend note au cas ou.  

 
J'ai l'explication sur le fait que le backend ffmpeg de qt6-multimedia ne fonctionnait pas chez moi :
 
- c'est parce qu'il nécessite pipewire, le gestionnaire de son concurrent de pulseaudio,
 
or chez moi j'utilise pulseaudio comme serveur de son principal,
 
j'ai des paquets pipewire installés (sans doute une dépendance requise par d'autres paquets) mais ce n'est pas le gestionnaire de son sur mon PC, c'est pulseaudio,
 
pour débloquer la situation il faut configurer une variable d'environnement de Qt6 pour indiquer qu'on utilise pulseaudio :
 

 
Cela permet d'avoir du son dans les applications Qt6 qui utilisent le backend ffmpeg de Qt6 multimedia.

Je viens de passer à pipewire, pour remplacer pulseaudio,  
 
je remarque un meilleur son dans Qemu pour les machines virtuelles, il n'y a plus de craquement dans le son venant des machines virtuelles,
 
et il n'y a plus besoin du serveur Jack pour faire communiquer les applications de musique assistée par ordinateur, les connexions se font toutes seules avec pipewire, qui émule l'API Jack.
 

J'ai une petite question : mon Archlinux est installé dans un PC portable, sur un disque M2, avec une partition système et une partition /home.
 
Est-ce que, si je retire le disque M2, et que je le mets dans un adaptateur externe USB comme celui-là : https://www.amazon.fr/UGREEN-Bo%C3% [...] 317&sr=8-6
 
Et que je branche cet adaptateur avec le disque dedans, sur un port USB d'un autre PC, je serais capable de booter dessus ?

Sous réserve d’avoir déjà installé les pilotes (surtout vidéo) appropriés, je dirais que oui. L’avantage de Linux sur Windows, toutes distributions confondues, c’est qu’avec lui, tu peux installer sur un support externe et démarrer depuis ce dernier.

Fais aussi gaffe en cas d’installation en mode UEFI que tu voudrais démarrer sur une machine sans UEFI (ou celui-ci réglé en mode BIOS/CSM/Legacy). Et y désactiver SecureBoot, aussi.

Dites, j'ai voulu utiliser Rescuezilla (comme Clonezilla mais avec une GUI) pour cloner mon SSD M2 256 Go vers une clé USB 256 Go également. Seulement, Rescuezilla me dit que la clé est plus petite que le SSD, et donc il ne peut pas la cloner. Et effectivement, le SSD est indiqué comme faisant 239 Go alors que la clé, elle, ne semble en faire  que 233. C'est normal ? Y a-t-il moyen de corriger ça ?

À part essayer de réduire la partition du SSD pour que ça fasse moins de 233 Gio, je ne pense pas. Mais 256 Gio, c’est une appelation marketing : en réalité, c’est jamais vraiment 256 Gio, surtout une fois formaté (une disquette 3"½ marquée 1,44 Mio ne pouvait contenir qu’1,38 Mio après formatage).
 
En tout cas, quand je fais 256 ÷ 2³⁰, ça me donne 2,38… × 10⁻⁷, donc je retrouve grosso modo tes 239 Gio.

Mais ça, je le sais bien, que c'est pas vraiment 256 Go ; ma question ne portait pas sur ça, mais sur la différence entre les "256 Go" du SSD et les "256 Go" de la clé USB.

L'un est calculé en Go et l'autre en Gio?

C’est bien ce qu’indique mon calcul précédent (et si on veut faire les choses bien, il faudrait calculer la conversion Go → Gio 256 × 10⁹ ÷ 2³⁰, qui donne 238,42 en arrondissant). Mais ça n’explique pas en soi la différence de 6 Gio entre son SSD évalué à 239 Gio et sa clef à 233 Gio (à part peut-être des histoires de formatage, de qualité des puces mémoire, éventuellement une partition cachée…).

À noter que l'installation d'Arch Linux est assez rapide, ça ne devrait pas dépasser les 15 minutes,
 
si c'est une clé USB 3 alors ça peut valoir le coup d'installer Arch Linux dessus plutôt que de cloner une installation existante, le surcoût en terme de temps devrait être négligeable.
Avec pacman tu peux générer la liste des paquets installés sur ton PC, pour reproduire la même installation sur un autre PC, en donnant en entrée à pacman la liste des paquets que possède l'autre PC.
 
Tu pourras ensuite recopier le contenu de ton home vers le home de la clé USB.

Bon, j'ai trouvé un autre SSD M2 de 256 GO qui traînait dans un tiroir, du coup le clonage de SSD 256 Go à SSD 256 Go est passé. Par contre, le SSD est installé dans un adaptateur USB, mais impossible de booter dessus via un PC avec Windows 11. ReFind est pourtant installé sur le SSD en USB, mais l'UEFI ne le voit pas, si j'essaye de booter dessus ça me met l'écran de récupération de Windows...

tu as essayé avec le menu du bios au démarrage ? touche F12 sur mon dell.

Oui c'est pareil. Et j'ai désactivé Secureboot, aussi.

Il faut en général autoriser la détection des disques USB au boot non?

Le disque est détecté, je peux le mettre en priorité #1 dans le Bios, mais ça ne va pas jusqu'à Refind, ça me lance un écran de Recovery à la place.

Hello,
Je pense qu'il manque une entrée uefi dans le bios.
C'est chiant et constructeur dépendant, malheureusement,

Je vais chercher comment j'ai fait la dernière fois.

Depuis une mise à jour du bios de ma carte mère Gigabyte B650 Aorus Elite AX V2 je remarque qu'un port USB se déconnecte tout seul quand le PC met en veille l'écran,

quand je bouge ma souris je vois alors une notification de Plasma qui m'indique qu'un hub USB "Genesys Logic, Inc. Hub" a été détecté, dans dmesg je vois ceci :

ce qui correspond à ce hub USB integré :

Est-ce un bug du nouveau bios F37 ?

Il apporte cette version du bios AGESA :

En fait ce hub USB c'est celui intégré à mon écran, qui lui même est relié à un port USB de la carte mère  .

Ce qui est curieux c'est que cette notification apparaît que depuis la mise à jour du bios de la carte mère.
Ou alors ça vient d'une mise à jour d'un paquet lié à Plasma.

Cette notification apparaît donc dès que l'écran sort de veille.

Si je débranche le câble USB qui relie mon écran LCD à un port USB de la carte mère alors cette notification disparaît.

Quelle connectique, ton écran ? Parce que je sais qu’il y en a une (DisplayPort ou HDMI, je retiens jamais) où le fait de mettre en veille ou éteindre l’écran est considéré comme s’il avait été purement et simplement débranché. Ton manège avec l’USB vient sans doute de là : n’étant plus alimenté, le port de l’écran disparaît comme s’il avait été retiré.
 
Après, il y a eu une MAJ des « linux-firmwares » publiée vendredi. Ça peut avoir joué aussi, mais je sais pas quand tu as mis à jour ton UEFI.

L'écran est relié en HDMI sur la carte graphique, et il a un hub USB sur le coté de l'écran, avec un cable USB branché sur la carte mère du PC.

J'ai mis à jour le bios vendredi.

Quand j'éteins l'écran, puis que je le rallume j'ai la notification KDED qui apparait pour indiquer qu'un périphérique USB a été détecté.

Idéalement il faudrait qu'on puisse configurer KDED pour lui dire d'afficher la fenêtre de notification que pour les périphériques USB importants (clé USB, disque dur USB externe) et que ce n'est pas nécessaire d'afficher la pop-up lorsqu'il s'agit d'un hub USB d'un écran qui sort de veille.

Ça, j’avais compris dans ton message initial.
 

Et pour peu que tu aies MAJ ton système dans la foulée, il va être très difficile de déterminer à cause de quoi ton phénomène se produit, entre ça et la MAJ des firmwares.
 

Voir mon précédent message qui dit pourquoi.
 

Oui, sauf que côté ordi, ton hub n’est pas considéré comme ayant été mis en veille, mais débranché et rebranché, ce qui n’est pas la même chose.
 
Et y a pas de réglage dans les notifications pour en empêcher certaines d’apparaître, dans Plasma (comme on peut le faire par application dans Windows et même XFCE) ? Ça supprimerait celle-là, mais aussi celles signalant le montage des clefs USB et autres DD externes.

J'ai trouvé un réglage dans les paramètres de configuration de Plasma, qui permet de supprimer la notification sonore de KDED , quand un périphérique USB est déconnecté, puis rebranché,
 
c'est dans le menu "notifications, notifications du système", on peut alors décocher la case de l'option "jouer un son" :
 

 
on voit toujours la notification de KDED, mais il n'y a plus le bruit strident de notification, qui est le plus gênant,
 
il y a en fait 2 types de notification : celle de KDED, et une autre issue d'un autre composant de Plasma, qui n'apparaît que pour les périphériques amovibles USB (qui sert à les monter et à les démonter), quand je démonte et retire une clé USB il y a toujours la notification sonore, qui est donc distincte de celle de KDED.
 

 
La notification de KDED  pour les périphériques USB (autres que les clés USB et disques dur USB externes) semble être apparue depuis une mise à jour récente de Plasma, peut-être celle d'octobre ou septembre dernier, quand Plasma en version 6.5 est apparue.
 

Merci pour ta contribution Elbarto j'ai la même carte mère tu m'as convaincu de rester en F36
Je me fais plus chier à la mettre à jour pour l'instant

Je remarque un bug étrange depuis un récent "pacman -Syu" :
 
- l''écran parfois n'arrive plus à sortir de veille, l'écran affiche "no signal", je suis obligé de débrancher le cable HDMI, puis de le rebrancher pour voir le bureau Plasma,
 
peut-être un souci avec le dernier noyau Linux par rapport au pilote libre radeon (j'ai une carte graphique AMD RX 7600), mais je ne vois pas de message d'erreur dans dmesg.

Dans journalctl je peux voir ce message quand le bug se produit, cela vient donc très probablement de la version 6.5.4 de Plasma :
 

 
Le bug apparaît lorsqu'on laisse l'écran entrer en mode veille, si on attend ensuite 10 minutes, puis qu'on bouge la souris : on remarque alors que l'écran ne sort pas de veille, la seule manière de le faire sortir de veille est de débrancher le cable HDMI, puis de le rebrancher.
 
En rétrogradant les paquets Plasma vers la version 6.5.3 le bug disparaît.

Sortie de kwin 6.5.4-3 dans le dépôt officiel, cela résout le bug de sortie de mise en veille, le mainteneur a retiré le commit responsable du bug.

Et les auteurs de Plasma sont en train de pousser une nouvelle version qui devrait sortir bientôt.

KDE Neon
Dépôts à jour, installation en cours ... mais le reboot attendra la fin de compilation/installation du noyau 6.18.1

Attention si vous utilisez le paquet netctl pour configurer votre connexion réseau :
 
- netctl utilise le programme resolvconf si on a configuré des DNS personnalisés dans le fichier de configuration netctl :  
 

 
Le souci :
 
- si on met 2 DNS (un primaire et un secondaire) alors la récente version de resolvconf (sortie hier le 12 décembre) n'est pas compatible avec la syntaxe utilisée par netctl, ça génère une erreur quand je consulte le statut de netctl, et la connexion internet ne marche alors plus :
 

 
ici mon profil netctl s'appelle "dhcp2", et on voit que le programme resolvconf pense que la seconde adresse DNS "8.8.4.4" est un nom de commande, d'où l'erreur "commande introuvable".
 
Un moyen de contournement est de configurer qu'une seule adresse DNS dans le fichier de profil de netctl :
 

Pour les utilisateurs de Pamac, même blague qu'en mars 2024 (Voir les sujets), cassé lors de la mise à jour de Pacman:
1- Désinstaller Pamac
2- Réinstallation de Yay
3- Installation de Pamac  

Yay a justement été mis à jour hier (trois versions auront été nécessaires, quand même !).

Et avec l’arrivée future de Python 3.14 dans les dépôts stables, attendez-vous à une avalanche de recompilations dans les prochains jours.