Comment formate tu le device, avec quel système de fichier.

L’arnaque courante de ces trucs là c’est un firmware qui ment sur la taille réelle.

Une clef USB de 8GB cachée dans un format SSD externe voir interne annonçant 6TB.

Pourquoi l’arnaque fonctionne ? C’est parce que dans beaucoup de cas le format utilisé est FAT32 et que contrairement à des systèmes de fichier comme ext4 ou xfs, c’est un format qui n’écris sa metadata qu’au debut et ne vérifie pas le reste du device outre mesure.
Le truc c’est que l’écriture va fonctionner pour les premiers 8GB et après commencer à corrompre la data.

Et pourquoi cette arnaque continue: Parce qu’il est souvent trop tard quand les gens s’en rendent compte si ils s’en rendent compte. De plus c’est souvent des clef achetées a des revendeurs peu scrupuleux ou des clef de publicités (oui oui) vers qui il est difficile de se retourner et ou ca ne vaut pas le coup (coût ?) de se lancer dans une procedure juridique.

Du coup il y a un moyen de savoir si c’est un vrai SSD de 6TB.
Formate en FAT32 et ensuite installe le programme f3 depuis les depots fedora.
Et ensuite teste la capacité du device.

https://fight-flash-fraud.readthedocs.io/en/latest/introduction.html#:\~:text=f3%20%2D%20Fight%20Flash%20Fraud,-f3%20is%20a&text=It%20fills%20the%20device%20with,Fraud%2C%20or%20Fight%20Fake%20Flash.

Dans sa demande Il précise n’avoir qu’un seul port nvme sur sa CM pour son ssd et a parlé d’échanger le ssd de 1To par celui de 4 To.
Il a mentionné de brancher le ssd sur un port pci-e sans parler d’adaptateur et ensuite parlé d’échanger les ssd.
Par manque de clareté j’avais donc considéré qu’il ne pouvais pas avoir les deux ssd nvme en même temps physiquement.

Je n’ai pas mentionné l’agrandissement du filesystem, manque de précision de ma part, mais c’est en effet une évidence.

Si c’est pour réinstaller exactement la même distro sur exactement le même matériel je trouve que cloner permet d’éviter de tout reconfigurer.

Je te conseille :
- Brancher un périphérique de backup (interne en sata, ou externe de + de 1 TB de libre)
- Live booter sur un Linux
- Faire une image (dd) du ssd complet vers un fichier image sur le périph de backup
- Reboot en remplaçant le ssd par le nouveau entre temps.
- dd de l’image de la backup vers le ssd
- Correction de l’emplacement de la table GPT de secours pour qu’elle aille à la fin du nouveau disque (souvent ça se fait tout seul en lançant fdisk sur le volume concerné et juste write)
- Enfin réagrandir la partition et tu reboot.

Après je ne sais pas ce que vaut clonezilla avec les systèmes fedora.

Modifier le fichier ne fait rien en tant que tel.

Cependant appliquer les changements en utilisant grub2-mkconfig, ça va en effet régénérer les entrées pour tout les noyaux à partir d’un template.

Il existe une solution pour donner des paramètres spécifiques à des entrées individuelles sans pour autant trifouiller manuellement dans les fichiers de grub : grubby.
N’hésite pas à te renseigner sur le fonctionnement de grubby.

Sinon, de manière générale, j’avoue être un peu surpris du caractère régressif d’une version de noyau par rapport à la précédente: comment les développeurs ne peuvent pas empêcher pareil bug sur une nouvelle version du noyau… pour une machine sous fedora, ou pour une rolling release, voir son système cassé et rendu inutilisable après une mise à jour du noyau, c’est plus que moyen.

Apparemment les problèmes sont vraiment aléatoires en fonction du matériel (parfois même n’impactent pas pareil certains mêmes modèles)
(Par exemple ça peut dépendre des dalles et Lenovo comme d’autres marques utilisent différents fournisseurs pour un même modèle).
Du coup c’est difficile de reproduire les bugs et tous les devs n’ont pas tout les types de matériel sous le coude.

En plus les drivers GPU sont parmi les drivers les plus complexes à développer, et avec parmi le plus de lignes de code dans le kernel.
Ces deux facteurs augmentent le risque de regression, (et c’est encore pire sur du matériel récent comme ceux dont on parle ici, pas encore éprouvés)

Ah et attention un autre type de crash peut arriver (à ne pas mélanger) en regardant des vidéos (firefox utilise le décodage gpu donc ça peut arriver) donc bien revérifier les logs à chaque crash.

Voir https://gitlab.freedesktop.org/drm/amd/-/issues/2220

Hello,

Je n’ai pas trop le temps de détailler plus, mais j’ai des soucis similaires sur mon thinkpad x13 gen3 amd avec une radeon 680M (APU).
Il y a déjà des gens sur le coup mais je ne sais pas si ça va aboutir, notamment https://gitlab.freedesktop.org/drm/amd/-/issues/2453

En gros sur certains modèles le panel self refresh (PSR) générait une sorte de flickering.
Un “mauvais” fix un peu random a été appliqué pour corriger ce problème, cependant, ce fix a amené des crash en 6.2.8 ou quelque chose dans le genre.

Temporairement un potentiel workaround peut être essayé: tenter de désactiver le PSR pour éviter que le kernel passe dans ce “code path”. (au coût d’une légère diminution de l’autonomie, mais c’est pas grand chose de ce que j’ai compris).

Pour cela tentez d’ajouter le paramètre suivant dans la conf grub.

amdgpu.dcdebugmask=0x10

J’ai participé sur différentes issues sur le gitlab de freedesktop dont celle là, mais je n’ai pas “encore” trouvé d’autre issues sur ce problème en particulier hormis celles déjà liées à celle-ci (mais j’ai plus trop le temps de chercher en ce moment).

AMD a tenté d’activer le panel self refresh par défaut à partir de rembrandt (gpu yellow carp) mais ils se prennent dans la tronche tous les problèmes que intel ont eu quand eux-même ont tentés d’ajouter cette feature. -> https://www.phoronix.com/news/AMDGPU-Linux-5.16-PSR#:\~:text=AMD Finally Enabling PSR By Default For Newer Hardware With Linux 5.16,-Written by Michael&text=With it getting late into,to instead on bug fixes.

Sur ma machine je n’avais pas le soucis avant le 6.0 (flickering) car les kernels d’avant avaient juste le module amdgpu qui crashait avant de se restorer/reset sans le PSR. Il y a également un très long fil sur le sujet pour les t14s et x13 sur le forum officiel de lenovo (en anglais). https://forums.lenovo.com/t5/Fedora/Random-screen-flickering-on-T14s-Gen-3-AMD-in-Fedora-37/m-p/5198472?page=8#5941992