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.