Clefs USB qui ne se montent pas sur Debian

Support Debian
Tags: #<Tag:0x00007fc9f245f0d8>
#1

Bonjour, j’ai tout un lot de clefs USB 64Go dont certaines qui fonctionnent parfaitement sous Windows 10 mais qui ne sont pas montés sous Debian 10.

Seul /dev/sdb est créé mais aucune partition n’apparait (pas de /dev/sdb1) et donc aucun montage n’est effectué.

La commande « parted /dev/sdb print » répond:

Model: VendorCo ProductCode (scsi)
Disk /dev/sdb: 62.9GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number  Start  End     Size    File system  Flags
 1      0.00B  62.9GB  62.9GB  ntfs

la clef semble normale

En revanche, lorsque je lance fdisk, la réponse n’est pas cohérente:

fdisk /dev/sdb

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdb: 58.6 GiB, 62914560000 bytes, 122880000 sectors
Disk model: ProductCode
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6c727443

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdb1       1970237472 3672215697 1701978226 811.6G 75 PC/IX
/dev/sdb2       1929382413 3883035520 1953653108 931.6G 72 unknown
/dev/sdb3                0          0          0     0B  0 Empty
/dev/sdb4         27394442   27394879        438   219K  0 Empty

Partition table entries are not in disk order.

Toutes les clefs qui buguent ont la même taille à l’octet pres: 62 914 555 904o , les autres du même fabriquant mais d’une taille tres légèrement différente ne posent aucun problème.

J’en conclus que fdisk (from util-linux 2.33.1) est bugué. Etes-vous du même avis que moi?
Et si gparted voit bien la partition, pourquoi n’est-elle pas vue par le système (pas de /dev/sdb1 créé)?

Pour info, il n’y a pas de message d’erreur dans les logs kernel concernant le device usb:

Sep  6 14:18:38 b-0009 kernel: usb 2-1: new high-speed USB device number 18 using ci_hdrc
Sep  6 14:18:39 b-0009 kernel: usb-storage 2-1:1.0: USB Mass Storage device detected
Sep  6 14:18:39 b-0009 kernel: scsi host0: usb-storage 2-1:1.0
Sep  6 14:18:40 b-0009 kernel: scsi 0:0:0:0: Direct-Access     VendorCo ProductCode      2.00 PQ: 0 ANSI: 4
Sep  6 14:18:40 b-0009 kernel: sd 0:0:0:0: [sdb] 122880000 512-byte logical blocks: (62.9 GB/58.6 GiB)
Sep  6 14:18:40 b-0009 kernel: sd 0:0:0:0: [sdb] Write Protect is off
Sep  6 14:18:40 b-0009 kernel: sd 0:0:0:0: [sdb] Mode Sense: 03 00 00 00
Sep  6 14:18:40 b-0009 kernel: sd 0:0:0:0: [sdb] No Caching mode page found
Sep  6 14:18:40 b-0009 kernel: sd 0:0:0:0: [sdb] Assuming drive cache: write through
Sep  6 14:18:40 b-0009 kernel: sd 0:0:0:0: [sdb] Attached SCSI removable disk

Cordialement

#2

« loop » est un type factice qui signifie qu’il n’y a pas de table de partition. Il est donc normal qu’il n’y ait pas de partition /dev/sdb1. D’après parted, le périphérique /dev/sdb est entièrement utilisé par un système de fichiers NTFS, à confirmer avec

file -s /dev/sdb
wipefs /dev/sdb
blkid /dev/sdb

Dans ce cas il ne devrait y avoir aucun problème pour le monter si ntfs-3g est installé.

mount /dev/sdb /mnt

fdisk affiche le contenu du MBR comme s’il s’agissait d’une table de partition DOS, mais le résultat est incohérent puisqu’il s’agit en fait d’un secteur d’amorce NTFS.

#3

Merci beaucoup Pascal,
En effet je comprends mieux. Je ne sais pas pourquoi , mais j’étais persuadé qu’il était nécessaire de créer au moins 1 partition pour formatter la clef avec le FS de son choix. Et la clef n’était pas monté car la règle udev qui réalise le montage automatique était conditionnée au fait qu’une partition soit déclarée.

Merci encore

#4

La tendance actuelle est de créer une table de partition sur les clés USB, comme les disques durs. Au début c’était plutôt l’inverse, comme les disquettes. Rien n’empêche de repartitionner et reformater ces clés si tu le souhaites.