Vous n'êtes pas identifié(e).
À noter que la clé a pris le drapeau boot.
Essai avec gparted pareil, rien à faire pour réutiliser la cle, toutes les écritures sont fermées.
Même s'il y a un risque qu'on ne puisse plus réutiliser cette clé, là, elle est bonne pour la poubelle, une 64go tout de même...
À vos claviers les df !
Edit :
Éventuellement une solution avec un système windows pourrait être opérée.
Dernière modification par smolski (17-11-2016 12:18:34)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
En ligne
ThinkPad T530 - Debian - CoreBoot
Hors ligne
Dernière modification par anonyme (16-11-2016 12:37:06)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
si tu arrive a supprimer une partition normalement la clé fonctionne
ps: sous win a lancer dans une console administrateur
désolé , mais je suis toujours plus a l'aise avec windows que linux pour ce type de probleme , dans les cas désespérés peut etre utile
Dernière modification par anonyme (16-11-2016 12:53:01)
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
En ligne
En ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
umount /dev/sdf1
cfdisk: impossible d'ouvrir /dev/sdf: Système de fichiers accessible en lecture seulement
J'ai un peu de peine à croire que la réponse correspond à la commande : pas le même programme, pas le même périphérique.
Que retournent les commandes suivantes ?
(remplacer sdf par le nom de périphérique de la clé s'il a changé)
Dernière modification par raleur (16-11-2016 13:49:07)
Il vaut mieux montrer que raconter.
Hors ligne
@anonyme
Non, pas de verrou mecanique sur la cle.
Merci
Dernière modification par smolski (16-11-2016 14:28:37)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Dernière modification par otyugh (16-11-2016 14:53:21)
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
réponse :
La clé n'étant pas tout à fait neuve, ce pourrait être un problème de panne électronique/mécanique, reste que la lecture de ce qu'elle contient se fait de manière impeccable.
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Ceci dit, le 'Write Protect' passe de 'off' à 'on' :
edit: ajout commande avant l'extrait de sortie.
Dernière modification par èfpé (16-11-2016 15:44:44)
Hors ligne
Toujours pas d'accès en écriture...
Dernière modification par smolski (16-11-2016 15:58:16)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Une simulation pour voir. L'outil ntfsfix fourni par le paquet ntfs-3g.
Hors ligne
je sais pas combien tu a de partition sur cette clé
Dernière modification par anonyme (16-11-2016 16:49:42)
Après l'exécution de la commande
que redonne la commande
pour vérifier si ça a fait effet ? (ne pas débrancher la clé entretemps)
Tu pourrais aussi afficher tous les messages du noyau liés au branchement de la clé, et pas seulement ceux qui contiennent "sdf" ? Des informations utiles s'y trouvent peut-être.
devrait suffire.
Je suis moyennnement optimiste sur le succès de cette opération. Je vois deux raisons pour lesquelles la clé passe en lecture seule au branchement :
- une règle udev, mais ce serait spécifique à ce système or le problème affecte aussi Windows.
- ça vient de la clé elle-même, par exemple à cause d'un commutateur de protection contre l'écriture ; j'ai cru comprendre que ça pouvait se produire lorsque la clé est en fin de vie avec un risque d'erreur d'écriture, probablement pour préserver les données présentes.
- ou alors il y a un flag dans la table de partition ("write protect on" se produit après le listage des partitions) mais je n'ai jamais entendu parler de ça.
En tout cas à mon avis ça n'a rien à voir avec le système de fichiers NTFS et toute opération sur ce dernier (chkdsk, ntfsfix...) est vaine.
Dernière modification par raleur (16-11-2016 16:46:02)
Il vaut mieux montrer que raconter.
Hors ligne
bllkid
ceci est different sur la tienne
démarre a 8064 au lieu de 2048
j'ai trouvé ça
faut tout essayer => []
j'ai trouvé ceci aussi
premiere solution
avec diskpart
deuxieme solution
Certains constructeurs de clés USB proposent des programmes de formatage et nous vous conseillons d’abord d’essayer celui proposé par le fabricant de votre clé
Dernière modification par anonyme (16-11-2016 17:36:58)
démarre a 8064 au lieu de 2048
Oui, cette position de début est atypique. Les valeurs courantes pour le début de la première partition sont 63 (aligné sur des "pistes" de 63 secteurs, obsolète) et 2048 (aligné sur un bloc de 1 Mio pour compatibilité avec les disques au format avancé et la majorité des SSD). 8064 est égal à 128*63, c'est donc aligné à la fois sur des pistes (qui n'ont bien sûr aucune réalité physique sur une mémoire flash, peut-être pour compatibilité avec de vieux logiciels) et des blocs de 64 Kio qui correspondent peut-être à la taille de bloc d'écriture/effacement de cette mémoire flash.
Il vaut mieux montrer que raconter.
Hors ligne