Reprise du message précédent :
Et la mienne date de janvier 2010
Pour le coup, tu as raison avec ce nom là : /usr/lib/systemd/system/plocate-updatedb.timer je l'ai aussi et il est activé.
 
Par contre il est pas au démarrage:
OnCalendar=daily
RandomizedDelaySec=1h
AccuracySec=6h
 
Je me suis donc empressé de le masquer aussi, j'ai l'habitude de lancer updatedb moi même les rares fois où j'ai besoin de locate...
Merci pour l'info du coup.
 

On peut aussi éditer le fichier de configuration /etc/updatedb.conf pour demander à updatedb de ne pas scanner certains points de montage, ainsi que certains types de fichiers,
 
ça peut être un moyen de réduire le temps d'exécution de updatedb, par exemple si on ajoute le chemin /home dans PRUNEPATHS alors ça exclura toute tentative de scan de fichiers dans ce chemin.
 

 
Es-tu sûr qu'il n'y a aucun processus qui a mis un verrou sur un fichier ?
 
Cela peut être un éditeur de texte ouvert sur un fichier présent sur le disque.
 
La commande lsof permet de connaitre les processus en train d'accéder à la partition qu'on veut démonter :
 

 
Il y a la commande fuser si on veut démonter de force un disque, mais il y a un risque de perte de données :
https://www.cyberciti.biz/tips/how- [...] ition.html
 
voir aussi ce message :
https://unix.stackexchange.com/ques [...] ile-system

Tu as regardé les liens que j’ai mis ? On dirait pas…
 
Et si c’est un processus qui a fait ça (l’AppImage de Double Commander, a priori), ça fait bien longtemps qu’il a été fermé !
 

S’il est (rarement) arrivé que j’oublie de fermer un logiciel (c’était plutôt MPV, dans ces cas-là) qui avait un fichier du disque ouvert, la boîte de dialogue dont j’ai mis la capture dans les liens me le disait. Là, non seulement j’avais tout fermé, mais la liste est vide quand elle apparaît lorsque je demande le démontage !
 

Merci, mais j’ai essayé ça, et plus d’une fois, d’ailleurs :
 

(Oui, Mikan est le nom du disque et de sa partoche)
 
Et je te le donne en mille : aucune info à propos d’un processus mobilisant ce disque ! Et pourtant, il serait toujours en cours d’utilisation par l’un d’eux, mais j’ai apparemment affaire à un processus fantôme sans PID ! Fort, non ? Va le kill, comme ça !
 

Risque de perte de données ? Alors, c’est non.

Aléas agaçant n'est-il pas ?  
findmnt ou findmnt /dev/sdXX pour possiblement quelques détails supplémentaires sur les causes.
udisks installé, à jour (tenter une réinstallation)? https://wiki.archlinux.org/title/Udisks
VeraCrypt m'a déjà posé ce genre de soucis, (redémarré n'est pas un problème pour moi).
Partition en NTSF? LUKS?  Partition qui se remonte en automatique?
 

Je note, mais je peux plus le faire pour le moment : j’ai éteint l’ordi avant d’aller me coucher, et c’est le noyau qui a forcé le démontage (de manière propre, je sais pas comment il a fait) avant de couper le jus.

Et ce matin, pas de problème de démontage avant retrait.

C’est aussi rare qu’aléatoire, donc je peux pas reproduire sur commande non plus. Faudra attendre la prochaine fois, et franchement, j’ai pas hâte que ça arrive à nouveau (même si je sais que ça recommencera).

Bah… Oui, à jour.

J’utilise pas de chiffrement.

Là, c’est du NTFS en GPT d’origine (via ntfs-3g). La partition se monte toute seule avec GVFS quand le gestionnaire de fichiers (Thunar) est ouvert, ou quand il a un processus lancé en mode « daemon », ou quand je demande à accéder au contenu du disque s’il est détecté mais pas monté (icône transparente).

Il est peu probable que cette boite de dialogue mente (sauf énorme bug d'un paquet),
rien de suspect dans la liste des processus montrés par htop, top (utilisation CPU importante) ?

La consultation des journaux systèmes peut aider à y voir plus clair (dmesg, journalctl), en recherchant tout message d'avertissement, d'erreur, qui mettrait sur la piste du coupable,

peut-être quelque chose lié à ton environnement de bureau,

le problème est apparu suite à une mise à jour, un changement dans ta configuration ?

Avec le noyau LTS le problème disparaît ?

Si ce n'est pas un problème logiciel : peut-être la carte électronique du boitier externe USB qui a un souci, surtout si tu n'as pas le souci avec une clé USB et un autre boitier externe USB.
Tu peux consulter aussi les infos SMART du disque dur externe, pour voir s'il n'y a rien de suspect.

L'alimentation électrique est souvent le point faible des boîtiers externes pour disque dur, certains n'ont pas de bloc d'alimentation et c'est alors le port USB qui doit délivrer l'alimentation, ça peut être limite pour certains disques durs et SSD.
J'ai un disque dur 2 To externe 2.5 pouces capricieux qui ne marche pas si je le branche sur le port USB de mon écran, je suis obligé d'utiliser le port USB du PC.

Le problème n’est pas qu’elle mente, mais dise qu’un processus occupe le volume sans indiquer lequel (et lsof non plus pour la version CLI).
 
Et non : conso CPU normale. Il y a cependant eu un précédent où j’avais en effet un processus zombie de Thunar (gestionnaire de fichiers de XFCE, mais aussi responsable de l’affichage des icônes sur le Bureau). Pas cette fois : aucun zombie repéré, aucun processus signalé pour /dev/sdb1 quand j’ai fait mes « sudo lsof ».
 
Non : la seule chose anormale, vendredi, c’était la fonction de démontage qui refusait de s’effectuer. La seule.
 

À voir la prochaine fois, donc.
 

XFCE 4.20 ? Ça m’étonnerait. Mais que ce soit gvfs, fuse ou ntfs-3g qui est bugué, ce serait déjà plus plausible.
 

Pas de changement de config sur un PC portable où, à l’exception du disque dur et d’une vis de maintien de ce dernier, tout est d’origine.
 
La première fois ? M’en souviens plus, mais je me demande si ça n’arrive pas quand je demande à démonter le disque trop vite après avoir fait une copie de fichiers dessus avec la version AppImage en GTK de Double Commander (les deux dernières fois en date, en tout cas, ça pourrait avoir été ça). Mais je fais des copies vers ce disque tous les jours (enfin, toutes les nuits) avec, et ça ne bloque jamais le démontage après, que DC soit encore ouvert ou non à ce moment-là, à part ces quelques fois aléatoires.
 

Il faudrait que je redémarre pour passer sur le noyau LTS, ce qui provoquerait le démontage forcé (mais propre) juste avant le réamorçage et ferait donc disparaître le problème pour cette fois. Donc impossible à vérifier.
 

Le disque externe est un WD Elements, un 2,5" 1 To (soit 931 Gio) autoalimenté.
 
Je peux pas vraiment tester avec d’autres supports, à cause du caractère aléatoire du problème que je peux pas reproduire sur demande.
 

L’ordi est un PC portable, donc les ports USB sont directement reliés à la carte-mère (j’utilise pas de rallonge, seulement le câble reliant le port proprio du disque au port USB de l’ordi).

Attention si vous mettez à jour Arch Linux :
 
suite à un pacman -Syu fait samedi soir je remarque que des programmes comme libreoffice, okular ne fonctionnent plus, il manque un fichier système :
 

En réinstallant le paquet gpgmepp ça a résolu le problème, ce qui est bizarre c'est que durant la réinstallation j'ai vu ce message :

Il y avait un problème de nommage de version, j'avais la version 16.08.3-1 de ce paquet, installée depuis 2016, considérée comme plus récente que la version présente dans le dépot officiel d'Arch Linux.

Peut-être que la version 16 était devenue un paquet orphelin après 2016, puis il a été réintégré dans les dépôts en juin 2025 avec un numéo de version égal à "2", au lieu d'un numéro de version supérieur à 16, le mainteneur de ce paquet n'a pas mis de conflit de version avec la 16 dans le PKGBUILD de ce paquet, il a juste mis ceci :

or ça ne couvre pas le cas de la précédente version du paquet qui avait un numéro de version "16".

@Elbarto
J'ai regardé par curiosité, mon installation a 4 ans, et je n'avais pas le paquet gpgmepp d'installé. Le paquet gpgme l'était, et a été mis à jour simultanément avec l’installation de gpgmepp.  
Comme remarqué, gpgmepp est en conflit avec gpgme < 2.

Je sais pas d’où vient ton gpgmepp 16, mais il ne semble exister ni dans le GitLab d’Arch, ni dans les archives d’AUR (vu que l’historique de mises à jour reste disponible, même pour les paquets supprimés).

En tout cas, moi non plus, je l’ai pas (il est décrit comme un split de gpgme, mais je sais pas ce qu’il était censé être avant). Mais j’attends la sortie de Mesa 25.1.3-3 (version du paquet corrigeant un bug de corruption d’affichage des applis GTK4 avec Vulkan) et, idéalement, le noyau 6.15.1, pour mettre mes Arch à jour (histoire de pas avoir à faire deux fois de suite une MAJ pour un même paquet, et ne pas installer des versions foireuses/déjà obsolètes alors que la version corrigée/à jour existe déjà dans Testing).

Oui je pense à un truc dans ce gout là.
Mais j'aurais supposé que pacman t'aurais avertit que ton package local était plus "récent" que le distant depuis tout ce temps ?
C'est la faute du mainteneur de pas avoir utilé le champ epoch
(Bon si le package a été réintroduit en 2025, ça fait potentiellement des années, on peut l'excuser et toi tu aurais pu le voir et le supprimer. Perso je scrute régulièrement pacman -Qm et je vire les packages orphelins)

Mon historique confirme le tien et aussi mon hypothèse car visiblement je l'ai supprimé en 2017 (orphelin ? consigne d'arch.org ? je sais évidemment plus) et réinstallé récemment:

J’ai des soucis de Wi-Fi depuis deux semaines avec mon PC portable (mon HP Pavilion DV6 1140-EF que j’ai depuis la mi-juillet 2009) : au bout d’un moment après le premier démarrage du matin, le module cesse juste de répondre et ne fonctionne plus du tout (et donc, plus de connexion active). Pire : quand je redémarre/éteins et rallume (en débranchant la prise ou non), le module n’est même plus détecté. Ce n’est qu’en le rallumant le matin, après une nuit éteint et débranché, qu’il se remet à marcher, mais seulement pour un moment (variable entre quelques minutes et une heure, en gros) avant de retomber en panne.
 
J’ai pensé à faire un copie de dmesg peu après qu’il a lâché ce matin (j’ai laissé que les lignes le concernant) :
 
Au démarrage, après une bonne nuit de sommeil (éteint, débranché), le module se connecte bien :
https://shelter.mahoro-net.org/~trit/wifi_ok.txt
 
Mais après une durée variable (moins d’une heure, en général), ça déconne et l’OS ne peut plus le réinitialiser :
https://shelter.mahoro-net.org/~trit/wifi_ko.txt
 
On est d’accord que c’est parce que le module interne est mort après presque 16 ans de fonctionnement quotidien ? Parce qu’avec un dongle USB ou en RJ-45, tout va bien.

Peut-être, peut-être pas.
Reviens à un ancien kernel (ou firmware?) pour confirmer si c'est une cause HW déjà

--- Message original (14/6/2025 à 15:47:32) ---
 
Je pense pas que ce soit lié au noyau, car c’est pas arrivé juste après la mise à jour de ce dernier (y en avait pas : on était dans la période d’attente de l’arrivée du 6.15 dans Core, ce qui a traîné pendant bien deux semaines), mais seulement comme ça, un beau jour (le 29 mai dernier, exactement), et le lendemain, et tous les jours suivants.
 
Enfin, j’essaierai de voir comment ça se passera demain, avec le 6.12 TLS.
 
--- Suite du 16/6 ---
 
Alors, hier, j’ai démarré sur le noyau LTS vers 9h10, et le module a tenu… jusqu’à 20h35 (d’après le log de Dmesg ; au passage, protip appris récemment : pour afficher les dates et heures au lieu du décompte des secondes et microsecondes, il faut faire la commande « [sudo] dmesg -T »).
 
Ce matin, retour sur le 6.16.2 dès 9h et là, il a lâché à 9h59.

Si c'est la puce Wifi qui est devenue défectueuse alors tu as 3 options :
 
- si le PC portable se démonte facilement alors tu peux essayer de vérifier si la puce Wifi est en réalité une carte mini PCI-express, qui serait facilement remplaçable, un peu comme ce modèle :
https://www.cdiscount.com/informati [...] IENT&gQT=1
 
- utiliser une carte PCMCIA contrôleur Wifi si le PC portable possède ce type de slot, la plupart des PC portables depuis 2010 n'ont plus ce type de connectique :
https://www.amazon.fr/Intel-WPC2011 [...] B00006BBT8
 
- utiliser une clé USB Wifi
 
edit : d'après ce manuel de réparation le module Wifi est remplaçable facilement par l'utilisateur (page 67), mais ce n'est pas tout à fait le même modèle de PC portable, celui-ci est sorti en 2011, mais ça reste un modèle de la série HP Pavilion DV6 :
https://www.hp.com/ctg/Manual/c02842252.pdf
 

Dans l’ordre, donc :
 

Oui, ça se démonte facilement avec un simple tournevis cruciforme de précision : j’ai qu’à ouvrir la trappe d’accès au disque dur, débrancher celui-ci et le module devient accessible.
 
Et non, il ressemble pas à ça, de souvenir (j’ai plus démonté depuis que j’ai arrêté d’échanger les disques avec celui de Windows, fin 2022).
 

Nan, pas de PCMCIA sur mon modèle. Mais j’ai un lecteur CompactFlash en plus de celui des cartes SD.
 

La solution la plus simple, en fait. J’en ai justement acheté une, le jour où ça a flanché, reçue le lendemain. Coup de bol : prise en charge nativement, j’ai eu qu’à la brancher et configurer son accès.
 
Mais bon, ça mobilise un port USB et j’en ai que trois. Or, j’en ai un qui est mobilisé par la souris, un autre où je branche un DD externe et le troisième, c’est un peu le « polyvalent » où je mets soit une clef USB pour y copier les vidéos que je regarde ensuite sur ma télé au salon, ou un clavier externe quand celui du portable se met à faire des caprices (certaines lettres qui s’affichent en plusieurs fois lors d’une seule frappe ou ne réagissent au contraire pas et n’affichent rien). Si je branche le dongle, ce sera sur celui-là, mais faudra pas que j’en aie besoin pour autre chose (même si je peux me passer de connexion pendant une copie de fichiers sur une clef USB).
 
Alternative : passer plutôt par un câble RJ-45, mais la disposition des pièces et les emplacements respectifs de la box (dans le salon) et de l’ordi (dans ma chambre, de l’autre côté d’un couloir) fait que c’est pas forcément l’idéal, visuellement parlant (en plus de m’empêcher de fermer la porte.
 

Merci pour la recherche.

J'ai une question : comment s'appelle le paquet pacman de libdw-dev  
 
Sur les debian based on a :  

Sur Arch ? Ça s’appellerait « libdwarf-git », a priori, et c’est sur AUR (donc à compiler).

pour le futur, au cas où :
https://github.com/morrownr/USB-WiFi

Oh, pas mal ! Merci !
 
La mienne est une Asus AC53 Nano, mais je l’ai pas trouvée dans la liste.

Attention il y a une faille de sécurité sur le paquet udisks2 :

https://www.it-connect.fr/linux-fai [...] 6018-6019/

La version du paquet udisks2 n'est pas à jour sur le dépot officiel d'arch linux, il a le statut "flagged out-of-date on 2025-06-18".
https://archlinux.org/packages/extra/x86_64/udisks2/

Pas de bol, que le mainteneur du paquet soit en vacances et qu’il faille donc attendre son retour pour avoir une version qui empêchera un énième scénario d’attaques en local exploitable en vrai uniquement les 30 février d’années impaires, soir de Pleine Lune avec éclipse totale à 23:45:67,890 très exactement et après avoir sacrifié trois licornes dans la seconde précédente…

Oui, ce serait bien que la MAJ arrive vite, mais n’empêche que nos PC à nous, chez nous, ils risquent rien du tout (surtout que je suis pas sur OpenSUSE, ce qui élimine déjà la première faille mentionnée).

Pas mieux

udisks2 à jour:  [2025-06-22T08:39:10+0200] [ALPM] upgraded udisks2 (2.10.1-5 -> 2.10.1-6)
 
J'ai eu des messages "d'erreurs" à la mise à jour de ce matin concernant linux-firmware.
La solution ici: https://archlinux.org/news/linux-fi [...] ervention/

Oui, il y a eu une modification sur le paquet linux-firmware, et il faut donc d’abord le désinstaller avant de le réinstaller en même temps qu’on fait la MAJ générale :

(Ils mettent sur deux lignes, mais je pense qu’on peut tout enchaîner d’un coup avec un « (sudo) pacman -Rdd linux-firmware && (sudo) pacman -Syu linux-firmware »…)

ah merci, j'ai eu la meme blague, sur une machine arch ou j'ai pas de nvidia

J’ai pas (ou plus) de Nvidia sur mes machines Arch, et j’ai quand même dû laisser s’installer un paquet dont le nom évoque un « nvcontrolcenter », parce qu’il est une dépendance obligatoire d’un autre.

 
En fait cela concerne la structure du dossier et des fichiers "linux-firmware" qui sont maintenant séparés par fournisseurs. Linux-firmware est maintenant vide.
"we split our firmware into several vendor-focused packages. linux-firmware is now an empty package depending on our default set of firmware."
Cette mise à jour posait un problème particulier pour NVIDIA avec une réorganisation simultanée des liens symboliques.
"Unfortunately, this coincided with upstream reorganizing the symlink layout of the NVIDIA firmware, resulting in a situation that Pacman cannot handle."
 
  Nouvelle mise à jour cette après midi. Ce que cela donne chez moi, et pourtant je n'ai pas d'amd sur cette machine, ni de NVIDIA...
[2025-06-22T16:52:49+0200] [ALPM] upgraded linux-firmware (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:49+0200] [ALPM] upgraded linux-firmware-realtek (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:49+0200] [ALPM] upgraded linux-firmware-radeon (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:49+0200] [ALPM] upgraded linux-firmware-other (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:49+0200] [ALPM] upgraded linux-firmware-nvidia (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:49+0200] [ALPM] upgraded linux-firmware-mediatek (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:48+0200] [ALPM] upgraded linux-firmware-intel (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:48+0200] [ALPM] upgraded linux-firmware-broadcom (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:48+0200] [ALPM] upgraded linux-firmware-atheros (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:48+0200] [ALPM] upgraded linux-firmware-amdgpu (20250613.12fe085f-5 -> 20250613.12fe085f-6)
[2025-06-22T16:52:48+0200] [ALPM] upgraded linux-firmware-whence (20250613.12fe085f-5 -> 20250613.12fe085f-6)
 

 
Merci pour le tuyau, c'est passé crême  

Chez moi aussi, sur les deux machines, mais je cache pas que j’ai quand même pas mal balisé quand j’ai vu la première passe de mkinitcpio (après la suppression du paquet qui l’a déclenché, donc) indiquer qu’il manquait maintenant plein de firmwares pour certains modules noyau (dont ceux des pilotes vidéo amdgpu et radeon)…
 
Heureusement, après le combo MAJ + réinstallation de tous les nouveaux paquets LF, tout est rentré dans l’ordre à la régénération suivante des initramfs (et zéro souci à l’allumage, ce matin, vu que j’ai fait tout ça avant d’éteindre pour la nuit).

C'est une bonne idée de s'abonner aux flux RSS de leur news qui est exclusivement dédié à ce genre d'infos importantes : https://archlinux.org/feeds/news/
Je crois que c'est conseillé dans leur wiki d'ailleurs

(drapal caché, je savais pas qu'il y avait un TU dédié à Arch )

Pour tout t’avouer, j’ai découvert ça totalement par hasard, en allant sur le site pour voir si le noyau 6.15.3 avait enfin quitté la phase Testing ; et… je me suis dit la même chose : que ce serait pas mal de rajouter leur fil d’actus à mes RSS (ce que j’avais pas fait, vu qu’en temps normal, il y a une nouvelle actu seulement une fois tous les 36 du mois).
 
Mais j’aurais pas regardé s’il y avait pas eu ce noyau en attente, et je me serais sûrement fait avoir, oui.

Je le suis (mailling list) et je le conseille, pas besoin de compte, un e-mail valide suffit, 4 ou 5 messages par an. Pour ceux que cela intéresse: https://lists.archlinux.org/mailman [...] linux.org/
Sauf que  dans ce cas, l’e-mail est tombé à 1h10 du matin, et toi tu fait la mise à jour le temps de chauffer le café, et évidement sans avoir regardé tes mails  

J’ai aussi ajouté l’abonnement dans mes flux rss pensais que c’était bidon les news  

  j'ai vu l’info sur le discord CachyOS ils ont ping tout le monde pour le coup.  

Fait amusant, avec ma 9070xt, le reboot après cette manip me donnait un bel écran noir, je ne pouvais avoir un affichage (y compris tty) qu'en nomodeset dans grub.

J'ai remis ma 5070Ti (que j'avais mise dans le PC de mon fils parce qu'il a un seul écran et qu'au moins lui il peut voir grub au boot), et ça marche.

Le monde à l'envers, un peu.

Ah ça me rassure je suis pas le seul, ils ont sûrement oublié les 9070XT dans les nouveaux firmware amd
 
En attendant je suis repassé sur l'ancienne version du paquet linux-firmware (avant le split) et tout fonctionne correctement.

Sur mon nouveau PC j'ai conservé le SSD SATA qui me permet de démarrer sur Arch Linux, mais en mode "bios legacy" avec Grub, car mon installation d'Arch Linux date de 2013 et avait été faite sur une carte mère ne supportant pas le mode UEFI à l'époque.

J'ai installé récemment un SSD NVMe de 1 To, je compte y transférer mon installation actuelle de Arch Linux, mais en mode UEFI, en procédant de cette manière, pouvez-vous me dire si cette stratégie va fonctionner ? :

Etape 1 : création des partitions sur le SSD NVMe depuis Arch Linux :

- je créé une table de partition GPT
- une partition EFI en FAT32 de 512 Mo
- une partition / en ext4 de 200 Go (qui contient aussi /boot)
- une partition /home en ext4 qui occupera le reste de l'espace disque

Etape 2 : depuis une clé USB de boot

- je redémarre le PC pour démarrer sur une clé USB contenant le programme "CloneZilla", qui permet de recopier le contenu d'une partition vers une autre
- je recopie avec CloneZilla le contenu de la partition du SSD SATA contenant mon installation d'Arch Linux (la partition "/" ) vers la partition "/" du SSD NVMe
- je recopie aussi la partition "/home" de mon SSD SATA vers la partition "/home" du SSD NVMe avec CloneZilla

Etape 3 : réinstallation de Grub, mais en mode UEFI

- je rédémarre le PC avec l'ISO d'installation d'Arch Linux depuis une clé USB
- je fais un chroot pour monter les partitions du SSD NVMe et pouvoir accéder à l'installation clonée d'Arch Linux du SSD NVMe
- je recherche avec l'utilitaire blkid le numéro UUID de chaque partition présente sur le SSD NVMe
- je réinstalle GRUB, mais en mode UEFI et en utilisant la partition EFI du SSD NVMe
- je modifie le fichier /etc/fstab pour mettre à jour les numéros UUID des partitions
- j'éteins le PC et je débranche le SSD SATA contenant mon installation actuelle d'Arch Linux

Etape 4 : configuration du bios UEFI pour démarrer sur le SSD NVMe

- j'entre dans le setup du bios UEFI pour m'assurer que le boot se fera bien sur le SSD NVMe et pas sur le SSD SATA

est-ce que tout cela vous semble cohérent, est-ce que ça peut marcher ?
Mon objectif est d'éviter d'avoir à installer Arch Linux sur le SSD NVMe, je veux cloner mon installation actuelle vers le SSD NVMe et passer du mode de démarrage "bios legacy" vers le mode démarrage "UEFI".

En fait à ce que j'ai compris le morcellement des paquets linux-firmware ont coincidé avec un update côté nVidia qui a mis le souk. Un nouveau commit a mis de l'ordre dans les heures ont ont suivi, eonc on a pas eu de bol.

Perso je voulais remettre ma 5070Ti parce que je fais bcp de LLM/SD (intérêt pro) et j'ai simplement pas réussi à avoir des performances autres qu'abyssales avec la 9070XT (je dois en être à ma 16è compilation de torch et torchvision) mais en soit, ça a réglé le problème.

Après en vrai je suis pas trop à ma place ici, j'attends juste Debian 13, parce que ça fait 20 ans que je suis utilisateur Deb et je suis sur Arch parce que je viens de changer les PC de la famille. Donc possible que je m'y prenne juste comme un pied.