Bonjour,
Lorsque je branche mon dd, il s’affiche, mais n’est pas accessible.
La solution suivante, que j’ai trouvée sur un forum, marche, mais j’aimerais m’en passait :
sudo ntfsfix -d /dev/sda1
Bonjour,
Lorsque je branche mon dd, il s’affiche, mais n’est pas accessible.
La solution suivante, que j’ai trouvée sur un forum, marche, mais j’aimerais m’en passait :
sudo ntfsfix -d /dev/sda1
J’ai sûrement une question stupide: la partition est-elle formatée en ntfs ?
Que dit ceci:
ls /dev/disk/by-id/ -l | sed 's/[^:]*...//'
pitié sans être orthonazi, il faut arrêter de nous faire saigner les yeux.
j’ajouterais à @Verner un simple lsblk -f
Je n’ai jamais vu lsblk -f fournir l’identité d’un disque, sinon je l’aurais demandé.
Comme il n’y a pas besoin d’être 50 sur ce genre de sujet que j’ai pris parce-que personne le prenait, pas besoin de moi ici. Good luck.
Je crois que si, lsblk est puissant:
lsblk -O -A -P
exemple:
[/tmp]$ lsblk -A -P -o ID,MODEL,KNAME,MOUNTPOINTS | while IFS= read -r line; do eval "$line"; printf '%s | %s | %s | %s\n' "$ID" "$MODEL" "$KNAME" "$MOUNTPOINTS"; done
SAMSUNG_MZVL41T0HBLB-00B07_S762NX0X601603 | SAMSUNG MZVL41T0HBLB-00B07 | nvme0n1 |
SAMSUNG_MZVL41T0HBLB-00B07_S762NX0X601603-part1 | | nvme0n1p1 | /boot/efi
SAMSUNG_MZVL41T0HBLB-00B07_S762NX0X601603-part2 | | nvme0n1p2 | /
SAMSUNG_MZVL41T0HBLB-00B07_S762NX0X601603-part3 | | nvme0n1p3 | [SWAP]
SAMSUNG_MZVL41T0HBLB-00B07_S762NX0X601603-part4 | | nvme0n1p4 | /home
[/tmp]$
mais effectivement ça n’est pas le pbm ici
Je ne vois décidemment absolument pas en quoi une simple commande ‹ ls › pose problème plutôt que de chercher des complications inutiles pour juste défricher un peu et identifier un disque et son block device dans un premier temps, avant d’aller plus loin.
En quoi ces diversions futiles résolvent quoi que ce soit pour @RG88 ?
Un sujet qui commence aussi mal par des diversions est mal barré. Quelle perte de temps.
@RG88
Pour te dépanner un peu quand-même, je te suggère ce qui suit.
Je suppose (à vérifier) que ton disque a été utilisé sous windows (à vérifier) et mal démonté à l’arrache (à vérifier).
Le filesystem ntfs est dans un état perdu ou en protection, et devrait être facilement réparé en remontant et démontant proprement ce disque (non occupé) sous windows si les hypothèses précédentes sont bonnes.
C’est le même outil utilisé pour montage/démontage sur le même système (windows) qui doit pemettre la réparation, afin que l’outil de vérification de partition comprenne l’état, et puisse réparer.
Il peut y avoir un problème de signature de partition.
Donc, si système cassé sous windows, une tentative de réparation avec ‹ ntfsfix › a peut-être déjà compliqué encore plus la situtation.
C’est tout ce que je peux dire au doigt mouillé, sans aucun retour d’info.
@josephtux
Tu te trompes visiblement de sujet et je ne vois pas en quoi ça peut aider @RG88
(-> message à supprimer).
@RG88
Ton problème est probablement déjà résolu, mais informer de ta solution est potentiellement utile à d’autres.
Sinon dans mon message précédent, les « (à vérifier) » s’adressent bien sûr à toi.
simplement pour répondre à TA question qui est « la partition est-elle formatée en ntfs ? »
lsblk -f donne la réponse , pas ls /dev/disk/by-id/ -l | sed 's/[^:]*...//'
Mon intention était premièrement d’identifier le disque sans aucune ambiguïté, le plus simplement possible. Ce n’est pas parce-qu’il y a une première investigation qu’il n’y aura pas une suite.
Ma question sur le ntfs était en fait superflue puisque ‹ ntfsfix › y répond, à moins d’une grosse bourde trouvée sur un autre forum, ça peut arriver aussi.
La question plus précise serait plutôt:
→ la partition ntfs a-t-elle été dégradée à partir de windows ou linux.
Ce qui est bien dans ces sujets et que @RG88 n’a même pas besoin d’en placer une, une boule de cristal suffit.
Voir mon 3ième message pour plus de détails, et d’hypothèses à confirmer.
mes excuses à tous pour cette bévue. Je retire cette intervention pour la mettre à sa place
Sous Windows, mon dd est reconnu et je peux y acceder.
Je l’ai éjecté proprement, et lancer linux ensuite mais toujours le meme pb…
Les questions de Verner sont bonnes: Quels sont les disques
`ls /dev/disk/by-id/ -l | sed 's/[^:]*...//'`
Je rajouterais quelles sont les types des partitions
fdisk -l
et que dit dmesg lorsque tu essayes de monter le disque
ls /dev/disk/by-id/ -l | sed 's/[^:]*...//'
ata-TOSHIBA_MQ01ABB200_14TNTD8OT -> ../../sda
ata-TOSHIBA_MQ01ABB200_14TNTD8OT-part1 -> ../../sda1
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q -> ../../nvme0n1
nvme-BC711_NVMe_SK_hynix_512GB__FYB1N060112301S3Q -> ../../nvme0n1
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q_1 -> ../../nvme0n1
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q_1-part1 -> ../../nvme0n1p1
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q_1-part2 -> ../../nvme0n1p2
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q_1-part3 -> ../../nvme0n1p3
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q_1-part4 -> ../../nvme0n1p4
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q_1-part5 -> ../../nvme0n1p5
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q_1-part6 -> ../../nvme0n1p6
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q_1-part7 -> ../../nvme0n1p7
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q_1-part8 -> ../../nvme0n1p8
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q-part1 -> ../../nvme0n1p1
nvme-BC711_NVMe_SK_hynix_512GB__FYB1N060112301S3Q-part1 -> ../../nvme0n1p1
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q-part2 -> ../../nvme0n1p2
nvme-BC711_NVMe_SK_hynix_512GB__FYB1N060112301S3Q-part2 -> ../../nvme0n1p2
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q-part3 -> ../../nvme0n1p3
nvme-BC711_NVMe_SK_hynix_512GB__FYB1N060112301S3Q-part3 -> ../../nvme0n1p3
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q-part4 -> ../../nvme0n1p4
nvme-BC711_NVMe_SK_hynix_512GB__FYB1N060112301S3Q-part4 -> ../../nvme0n1p4
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q-part5 -> ../../nvme0n1p5
nvme-BC711_NVMe_SK_hynix_512GB__FYB1N060112301S3Q-part5 -> ../../nvme0n1p5
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q-part6 -> ../../nvme0n1p6
nvme-BC711_NVMe_SK_hynix_512GB__FYB1N060112301S3Q-part6 -> ../../nvme0n1p6
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q-part7 -> ../../nvme0n1p7
nvme-BC711_NVMe_SK_hynix_512GB__FYB1N060112301S3Q-part7 -> ../../nvme0n1p7
nvme-BC711_NVMe_SK_hynix_512GB____FYB1N060112301S3Q-part8 -> ../../nvme0n1p8
nvme-BC711_NVMe_SK_hynix_512GB__FYB1N060112301S3Q-part8 -> ../../nvme0n1p8
nvme-nvme.1c5c-202020465942314e303630313132333031533351-4243373131204e564d6520534b2068796e6978203531324742-00000001 -> ../../nvme0n1
nvme-nvme.1c5c-202020465942314e303630313132333031533351-4243373131204e564d6520534b2068796e6978203531324742-00000001-part1 -> ../../nvme0n1p1
nvme-nvme.1c5c-202020465942314e303630313132333031533351-4243373131204e564d6520534b2068796e6978203531324742-00000001-part2 -> ../../nvme0n1p2
nvme-nvme.1c5c-202020465942314e303630313132333031533351-4243373131204e564d6520534b2068796e6978203531324742-00000001-part3 -> ../../nvme0n1p3
nvme-nvme.1c5c-202020465942314e303630313132333031533351-4243373131204e564d6520534b2068796e6978203531324742-00000001-part4 -> ../../nvme0n1p4
nvme-nvme.1c5c-202020465942314e303630313132333031533351-4243373131204e564d6520534b2068796e6978203531324742-00000001-part5 -> ../../nvme0n1p5
nvme-nvme.1c5c-202020465942314e303630313132333031533351-4243373131204e564d6520534b2068796e6978203531324742-00000001-part6 -> ../../nvme0n1p6
nvme-nvme.1c5c-202020465942314e303630313132333031533351-4243373131204e564d6520534b2068796e6978203531324742-00000001-part7 -> ../../nvme0n1p7
nvme-nvme.1c5c-202020465942314e303630313132333031533351-4243373131204e564d6520534b2068796e6978203531324742-00000001-part8 -> ../../nvme0n1p8
usb-TOSHIBA_External_USB_3.0_2014010916302-0:0 -> ../../sda
usb-TOSHIBA_External_USB_3.0_2014010916302-0:0-part1 -> ../../sda1
wwn-0x5000039541b0a55b -> ../../sda
wwn-0x5000039541b0a55b-part1 -> ../../sda1
fdisk -l
bash: fdisk : commande introuvable
fdisk -l
bash: fdisk : commande introuvable
Et en root ? 
D’où l’intérêt de citer la commande en intégralité !
fdisk -l
Disque /dev/nvme0n1 : 476,94 GiB, 512110190592 octets, 1000215216 secteurs
Modèle de disque : BC711 NVMe SK hynix 512GB
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 59411498-59FC-4003-81E6-0B630573D757
Périphérique Début Fin Secteurs Taille Type
/dev/nvme0n1p1 2048 206847 204800 100M Système EFI
/dev/nvme0n1p2 206848 239615 32768 16M Réservé Microsoft
/dev/nvme0n1p3 239616 427415329 427175714 203,7G Données de base Microsoft
/dev/nvme0n1p4 427415552 427579391 163840 80M Système EFI
/dev/nvme0n1p5 999098146 1000214716 1116571 545,2M Environnement de récupérati
/dev/nvme0n1p6 427579392 447111167 19531776 9,3G Système de fichiers Linux
/dev/nvme0n1p7 447111168 458829823 11718656 5,6G Partition d'échange Linux
/dev/nvme0n1p8 458829824 999096319 540266496 257,6G Système de fichiers Linux
Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
Disque /dev/sda : 1,82 TiB, 2000398934016 octets, 3907029168 secteurs
Modèle de disque : External USB 3.0
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x9b097169
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 2048 3907027119 3907025072 1,8T 7 HPFS/NTFS/exFAT
Hum, bon, donc pas de risque de confusion et /dev/sda1 a bien une partition déclaré en NTFS. De ce coté c’est bon. Théoriquement un ntfsfix -d ou une réparation sous windows remet la partiton en état. De ce que tu dis, tu as monté et ejecté proprement le disque sous windows et ça a resignalé l’erreur sous linux.
Tu as juste mis le disque sous windows, accédé dessus et ejecté ou bien tu as lancé une réparation du disque sous windows avant de l’ejecter?
En tout état de cause «ntfsfix -d » sous linux et «réparation» (graphique) ou «chkdsk»/commande sous windows font la même chose.
Confirmes tu que après avoir fait cette réparation, si tu démontes proprement le disque sous linux et que tu redémarres, remet le disque, il y a une erreur de nouveau?
$ ls -l /dev/disk/by-id/ | sed -n '/sd/s/[^:]*...//p'
ata-TOSHIBA_MQ01ABB200_14TNTD8OT -> ../../sda
ata-TOSHIBA_MQ01ABB200_14TNTD8OT-part1 -> ../../sda1
usb-TOSHIBA_External_USB_3.0_2014010916302-0:0 -> ../../sda
usb-TOSHIBA_External_USB_3.0_2014010916302-0:0-part1 -> ../../sda1
wwn-0x5000039541b0a55b -> ../../sda
wwn-0x5000039541b0a55b-part1 -> ../../sda1
Première commande qui permet de lever toute ambiguïté de block device sdX.
C’est un bon début, bien qu’anormalement laborieux.
Pour commencer, petite vérification:
→ as-tu bien le noyau 7 de backports que je t’ai fait installer précédemment ?
uname -r
/sbin/modinfo ntfs3 | grep filename
lsmod |grep ntfs
uname -r
7.0.10+deb13-amd64
/sbin/modinfo ntfs3 | grep filename
filename: /lib/modules/7.0.10+deb13-amd64/kernel/fs/ntfs3/ntfs3.ko.xz
lsmod |grep ntfs
‹ RIEN… ›
Le lsmod, l’as tu fait en ayant mis avant ton disque? Je pense que Verner veut savoir si le module se charge bien. DOnc tu mets le disque, tu le montes (jusqu’au message d’erreu éventuel) et tu fais le lsmod
@RG88 / Pour voir:
sudo modprobe -v ntfs3
lsmod |grep ntfs
udisksctl info -b /dev/disk/by-id/wwn-0x5000039541b0a55b-part1 | awk '/Id|Type|UUID/'
→ débranche rebranche ton disque
findmnt -l |grep -q '/sd' || udisksctl mount -t ntfs3 -b /dev/disk/by-id/wwn-0x5000039541b0a55b-part1
findmnt -l |grep '/sd'