Bonjour, depuis que j’utilise Debian Buster (stable donc), j’ai un sérieux problème avec le transfert de fichiers sur clé USB ou carte mémoire flash.
J’ai pu lire sur différents forum que c’était un problème connu, mais je n’ai absolument trouvé aucune solution au problème qui semble lié au kernel de Linux.
Comme pour beaucoup d’utilisateurs, lorsque je tente de copier un gros fichier, le gestionnaire de fichier (dans mon cas Nemo) affiche un état à 98% puis plus rien dans un temps infini. En revanche, cela fonctionne très bien lorsque je copie n’importe quel gros fichier sur un disque dur (partitionné en NTFS).
Mon problème avec le lecteur de cartes est différent, il s’agit d’un lecteur de cartes que je branche sur un port USB de l’ordinateur et lorsque j’insère ma carte mini SD, parfois il ne se passe rien ou brutalement le lecteur de cartes n’est plus alimenté… Je dois m’y reprendre plusieurs fois afin que Debian me permettent d’accéder et copier un fichier sur la carte mini SD. C’est un vrai problème dans mon cas, car j’ai besoin de copier rapidement des fichiers sur cette carte mini SD afin de tester mes programmes développés sur une machine des années 80 grâce à cette petite carte.
Je précise que tout fonctionnait parfaitement bien avant que je décide de migrer sur Debian il y a quelques mois. Je suis passé en testing puis en unstable afin d’avoir la dernière version du kernel, ce qui n’a pas du tout résolu le problème, alors je suis retourné sur stable, car je ne peux pas me risquer de tomber sur des paquets cassés, car j’ai vraiment besoin que tout fonctionne afin de continuer de programmer sur ma machine.
Puisque tu dis avoir déjà investigué du côté de ce bug connu, y compris en changeant de noyau, je ne reviens pas dessus, n’ayant pas d’expérience sur ce point précis.
Je te suggère par contre de bien vérifier que ce ne soit pas une coïncidence : j’ai eu à maintes reprises le cas de problèmes dûs apparemment à une migration ou autres changements récents alors que c’était tout autre chose !
Il y a un point qui me laisse penser que ça pourrait être le cas :
N’aurais-tu pas un bête problème de connectique ? La connectique USB est vraiment mal foutue et peu fiable, au point que j’ai des problèmes similaires une fois sur deux environ avec les disques externes alimentés via l’USB et que je n’utilise personnellement plus que des disques avec alimentation séparée.
Ça semble moins mauvais du côté de la connectique des cartes, mais attention quand même qu’avec les mini/micro SD, on a toujours plusieurs points de contact : les deux côtés de l’éventuel câble USB, la carte dans le lecteur, et parfois en plus un adaptateur mini/micro SD -> SD normale. Ça multiplie les chances de problèmes !
Donc, essaies si tu peux avec du matériel (câble, lecteur de carte, adaptateur) différent. Si tu as la chance d’en avoir ou de pouvoir t’en procurer avec des contacts plaqués or, le gain en fiabilité vaut souvent la dépense supplémentaire ! Et quand il ne se passe rien, essaies la commande lsusb
si tu ne vois pas ta carte, c’est très probablement un problème de connectique.
Merci, je vais regarder de ce côté là. Je me souviens aussi que depuis mon passage sur Debian, je dois systématiquement brancher le lecteur de carte sur un port à l’arrière de la tour plutôt qu’en façade, alors que sous Windows 7/10 aucun problème à ce niveau.
J’ai aussi oublié de mentionner que je dois recourir au paramètre iommu=soft afin d’obtenir le support des ports USB après le boot de GRUB.
Peut être que je devrais investir aussi dans un meilleur lecteur de cartes mini SD.
Autre piste à vérifier, d’après ce que tu me dis là : la version de ton bios. Il n’est pas impossible que le noyau actuel gère un bios plus récent que le noyau de Stretch…
Bonjour, j’ai installé le kernel 5.3 qui se trouve dans buster-backports, mais je n’ai pas vu d’améliorations après le redémarrage. De plus, mes jeux natifs Linux refusent de lancer, sauf si j’utilise le runtime de SteamPlay.
Cependant, je suis parti dans le bios et j’ai constaté que l’option IOMMU était activée. Je l’ai donc désactivée, mais j’ai toujours les mêmes problèmes.
Concernant le lecteur de cartes, j’avais une erreur sur la carte. J’ai dû retirer la carte SD à un mauvais moment et les données étaient corrompues. Je m’en suis rendu compte, car dès que j’accédais au contenu de la carte, tous les fichiers étaient en lecture seule. Lorsque j’essayais de flasher mon fichier binaire dans la mémoire flash, j’avais systématiquement une erreur.
J’ai formaté la carte SD, cela fonctionne mieux, mais par moment le lecteur de carte s’éteint quand j’insère la carte SD et je dois quelques secondes avant de pouvoir y accéder.
Concernant la copie de fichiers sur clé USB, c’est toujours le même constat. La dernière fois, j’ai copier un film dont la taille est inférieure à 1GO, la copie n’est pas allé plus loin que 98% pour ne pas changer.
Si c’est pour tenter de voir comme je le suggérais s’il s’agit d’un conflit entre le kernel et la version de bios, c’est raté : tu avais probablement un noyau 4.19 avec Stretch.
Tu parles de flasher quoi ? Ton BIOS ? Si tu as eu des erreurs, es-tu sûr (même si le fait que tu aies pu redémarrer est plutôt rassurant) que ton BIOS est bien correctement fonctionnel ? Je pense que tu ne peux être vraiment sûr de ça que si, au final, tu as réussi un flashage sans erreur, avec un fichier binaire dont tu as bien vérifié la somme de contrôle.
Je ne suis pas certain que ce soit forcément inquiétant : il faut bien le temps que le changement soit détecté et que tout soit mis en place. Ce n’est généralement vraiment pas immédiat (quelques secondes voire un peu plus).
Attention : la progression de la copie n’est pas vraiment significative. Souvent, le fichier source est mis en cache et, quand il est lu (donc quand le compteur indique 98% voire 100%), le cache est flushé sur la clé ou la carte, ce qui peut prendre du temps s’il y a un gros cache (1Go, c’est un peu long si tu es en USB 2 ! ). Assez en tous cas pour se demander si tout n’est pas planté… et éventuellement retirer la clé/carte trop tôt !
Sinon, et si tu est bien certain de tout ce que j’ai mentionné ci-dessus, je ne vois pas… Désolé : j’espère que quelqu’un de plus compétent pourra te venir en aide !
Avec Buster oui, c’était bien un kernel 4.19. J’ai migré vers sid, le problème est toujours présent avec le kernel 5.4.
Je n’ai pas flashé le BIOS, je suis développeur et je compile des fichiers binaires pour d’anciennes consoles de jeux vidéo. La ROM ou fichier binaire, est copier sur une carte SD que j’insère dans un flash cart, ce qui me permet de tester mon programme sur la console.
Je comprends, mais sa prend plus que quelques secondes il me semble. Parfois, il faut attendre et d’autre fois, il ne se passe absolument rien. Je dois recommencé l’opération pour que cela fonctionne. Ce qui me tracasse, c’est que le lecteur de cartes fonctionnait très bien sous Windows et le problème est apparu dès que j’ai migré vers Linux en installant Debian, mais bon, du moment que sa fonctionne ^^.
Disons que je ne trouve pas cela normal et pourtant j’ai cet ordinateur depuis 2013. J’ai quasiment que des ports USB que se soit à l’arrière ou en façade et j’utilise des clés USB relativement rapide. Un fichier de 700mo est assez rapide à copier généralement, mais depuis mon passage sous Debian, impossible de copier un fichier correctement. Pour preuve, cela fait plus de 10 minutes que j’attends que mon fichier de 733mo soit terminé d’être copié et il ne passe rien.
Je vais essayer de creuser le problème, en attendant je peux utiliser un disque dur externe pour copier mes fichiers via USB, dans cas de figure, la copie est très rapidement et ne bloque pas à 97%. Merci pour ton aide
J’ai peut être une piste en regardant ce que donne la commande kentosama@teradrive:~$ sudo dmesg -l warn
0.000000] secureboot: Secure boot could not be determined (mode 0)
[ 0.015956] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20190816/tbfadt-615)
[ 1.654157] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 1.809801] CRAT table not found
[ 2.183727] sdb: p2 size 2248864640 extends beyond EOD, enabling native capacity
[ 2.196303] sdb: p2 size 2248864640 extends beyond EOD, truncated
[ 16.206310] r8169 0000:03:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
[ 5820.720584] FAT-fs (sdh1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 6966.386512] kauditd_printk_skb: 12 callbacks suppressed
[10585.560417] kauditd_printk_skb: 313 callbacks suppressed
[13446.801038] sr 7:0:0:0: Power-on or device reset occurred
[13454.833214] sr 7:0:0:0: Power-on or device reset occurred
[27523.683185] FAT-fs (sdh1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[29982.279297] r8169 0000:03:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
[41817.146485] show_signal_msg: 312 callbacks suppressed
[42000.499169] r8169 0000:03:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
[42712.977200] FAT-fs (sdi): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Gagné ! J’ai installé le paquet firmware-realtek et tout fonctionne parfaitement bien maintenant pour la copie de fichier, mais le lecteur de cartes continue de faire le fou
Effectivement, “volume was not properly unmounted”, ce n’est pas normal surtout avec une carte que tu viens de reformater. Et comme je suppose que ce n’est pas toi qui, à chaque fois, la sors du lecteur sans la démonter proprement, ça veut dire très probablement que mes gros soupçons sur la connectique sont justifiés. Je suis un peu moins sûr sur ce point, mais je pense que les “Power-on or device restet occured” ne font que confirmer un problème de connectique.
Évidemment, si ça a commencé pile au moment du passage sous Buster, ça met un doute. Mais, curieusement, j’ai souvent vu ce genre de coïncidence assez vicieuse parce qu’effectivement, on va chercher ailleurs alors que le problème est bien là où on a peine à le croire.
Donc, essaie de trouver une solution pour résoudre ce(s) problème(s) de connectique, et je pense réellement que tout va rentrer dans l’ordre. Si ce n’est pas le cas, tu pourras toujours chercher ailleurs ensuite, au moins tu seras vraiment sûr sur ce point.
En installant le paquet firmware-realtek je n’ai plus de problème pour la copie de fichier. C’est rapide et va jusqu’à la fin sans problème. Il reste lecteur de cartes qui s’éteint quand je mets la carte SD puis se rallume au bout de 20 / 30 secondes et m’affiche le contenu de la carte.
Donc, je dirais que tu as un double problème : effectivement, je n’avais pas pensé au firmware, ça peut expliquer certaines choses. Mais si ton lecteur s’éteint toujours quand tu insères une carte, je maintiens que tu devrais vérifier la connectique.
Finalement ce n’est ni le hardware, le firmware ou le bios. C’est un problème connu et donc il n’y a pas de solution visiblement. En réalité, je me suis trompé, je viens de me rendre compte que j’avais formater la clé USB en NTSC aulieu de FAT32. Je viens de le remarquer en branchant la clé sur ma PlayStation 2 qui, forcément n’a pas reconnu la partition.
Lorsque j’ai formaté la clé USB en fat32 ce fut le retour de ce problème des 99%.
En réalité la copie va très vite vite, car le fichier est copié dans la mémoire tampon, mais même en attendant 1 heure, la copie ne se termine jamais. La solution qui est indiqué et que j’ai utilisé par hasard est d’utiliser une partition NTFS. La copie est très rapide et se termine sans encombre.
Hors mon problème est que je veux utiliser le fat32.
Je n’ai pas encore migré mes postes de travail sous Buster (faudrait bien que je m’y mette, pourtant !), et je ne me souviens plus si j’ai utilisé une clé FAT32 sur mon serveur ou pas… Ça me surprend quand même un peu, ce problème sans solution. Tu as un lien qui l’explique ?
Bon, je pense que ce n’est pas la peine de te suggérer de passer ta clé en Ext4, tu veux du FAT pour compatibilité avec d’autres appareils ? Perso, j’utilise Ext4 sauf si la clé ou carte doit être lue sur un système qui ne le reconnaît pas : ça me semble plus naturel avec GNU/Linux.
Mais tu es sur que le format NTFS ne passe pas sur ta playstation 2 ? C’est sensé fonctionner sur la 3.
Et ça vaudrait le coup de voir aussi ce que dit ta PS2 avec un format ext, sait on jamais (je n’ai pas trouvé la liste des formats disques supportés sur la PS2).
Oui, le fat32 me permet d’utiliser la clé USB sur différents appareils, mais en réalité, dans ce cas précis, c’est une clé que j’utilise pour la sauvegarde de mes données et transporter quelques outils. Donc une partition ext4 pourrait être une solution effectivement.
Un lien qui explique le problème :
C’est ce que la plupart des personnes expliquent sur différents fils de discutions. D’ailleurs, j’ai patienté un petit moment hier avant de copier un fichier de 1GO sur la clé USB et effectivement, le fichier fini par ce copier. J’ai d’ailleurs pu lancer un ISO depuis cette clé sur ma PlayStation 2.
Je n’ai pas dit ça.
J’ai dit que ça méritait d’être vérifié.
Sinon, je ne sait plus si on t’a demandé:
le blocage arrive aussi quand tu fais un bête cp ?
Parceque ton truc parle d’un bug de nautilus, donc autant ne pas utiliser nautilus, et ton probléme sear règlé, non ?
Oui, comme dit @mattotop, cp serait peut-être la solution. Sinon, as-tu tenté de réduire la taille du buffer, comme proposé dans le lien que tu donnes ? Ce n’est pas parce que quelqu’un dit que ça ne fonctionne pas sous Ubuntu que c’est pareil sous Debian ! Le test est assez vite fait, et si ce n’est pas concluant, tu remets la valeur d’origine.
