ce disque USB n’est plus reconnu, ni par blkid, ni par sfdisk.
la commande hdparm indique:
$sudo hdparm -I /dev/sdb
ATA device, with non-removable media
Standards:
Likely used: 1
Configuration:
Logical max current
cylinders 0 0
heads 0 0
sectors/track 0 0
--
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 0 MBytes
device size with M = 1000*1000: 0 MBytes
cache/buffer size = unknown
Capabilities:
IORDY not likely
Cannot perform double-word IO
R/W multiple sector transfer: not supported
DMA: not supported
PIO: pio0
et la commande gpart:
#gpart /dev/sdb
Begin scan...
* Warning: read error (EIO) near sector(62), skipping...
End scan.
Checking partitions...
Ok.
Guessed primary partition table:
Primary partition(1)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(2)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(3)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(4)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
/dev/sdb:
ATA device, with non-removable media
Standards:
Likely used: 1
Configuration:
Logical max current
cylinders 0 0
heads 0 0
sectors/track 0 0
--
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 0 MBytes
device size with M = 1000*1000: 0 MBytes
cache/buffer size = unknown
Capabilities:
IORDY not likely
Cannot perform double-word IO
R/W multiple sector transfer: not supported
DMA: not supported
PIO: pio0
et gparted la désigne (/dev/hdb) mais mouline en vain.
Ce disque est-il récupérable? (j’en doute car fdisk et sfdisk échouent à le reconnaître). Mais mon ignorance abyssale m’incite à vous poser la question avant de le jeter.
Merci pour votre compréhension
Bizarre , le disque répond aux commandes de smartctl et n’indique pas de souci. Premier candidat au problème, le cable de connexion USB, essaye un autre cable voir un autre boitier USB, mais ces p…ns de disque WD sont je crois complètement soudés au controleur SATA/USB. Essaye qd même un cable différent.
Sinon regarde ce que disait dmesg et autre, en clair
En revanche dmesg délivre les informations suivantes (juste après la connexion USB):
[756069.945596] input: Logitech Pebble Mouse as /devices/virtual/misc/uhid/0005:046D:B021.0011/input/input51
[756069.945991] hid-generic 0005:046D:B021.0011: input,hidraw1: BLUETOOTH HID v0.07 Mouse [Logitech Pebble] on a4:f9:33:f1:65:ca
[759497.739014] usb 3-2: new high-speed USB device number 11 using xhci_hcd
[759498.037325] usb 3-2: New USB device found, idVendor=8564, idProduct=7000, bcdDevice=80.00
[759498.037336] usb 3-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[759498.037339] usb 3-2: Product: StoreJet Transcend
[759498.037342] usb 3-2: Manufacturer: StoreJet Transcend
[759498.037344] usb 3-2: SerialNumber: 00000000000000000000
[759498.041696] scsi host1: uas
Je suppose que le numéro de série 00000000000000000 confirme le parfum de sapin reniflé par Zargos…
→ Bon, pas de bruit particulier donc sans doute pas de problème physique.
Du coup je suggèrerais dans l’ordre
→ essai avec un autre cable (c’est le plus grand espoir)
→ si ça rate, essai pour démonter le disque en espérant que c’est un disque avec connecteur sata sur un controleur intégré au boitier ce qui permettrait de récupérer le disque et de le mettre dans un nouveau boitier.
Malheureusement je crois que les disques WD ont directement un controleur USB donc ce dernier point n’est sans doute pas possible. Il y aurait peut être la possibilité de changer le controleur USB mais je n’ai jamais fait.
Ok, alors essaye le choc thermique en le mettant 5 minutes au congélateur puis tu le branches sur ton ordinateur. Attention si ça marche, c’est du «one shot», i.e si tu le débranches et le rebranches ça coincera et il n’est pas dit que tu arrivera à le refaire marcher. Donc il faut prévoir en le branchant avoir de quoi stocker tout ce que tu as pu récupérer
Salut,
Si le disque est vraiment en train de rendre l’ame, la priorite c’est de sauvegarder les donnees importantes avant tout. Monte-le en lecture seule si possible : mount -o ro /dev/sdXN /mnt/recovery
Ensuite, tu peux utiliser ddrescue pour faire une image du disque. C’est plus fiable que dd classique car il retente les secteurs defectueux : ddrescue /dev/sdX /mnt/backup/image.img /mnt/backup/logfile.log Si le disque fait des bruits bizarres (cliquetis), arrete tout et ne le remonte plus. C’est potentiellement un probleme mecanique et chaque seconde compte pour les donnees.
Apres la recuperation, smartctl -a /dev/sdX te donnera les infos SMART pour confirmer l’etat du disque. Ce n’est que mon avis après tout.
est-ce que 1 clic toutes les 5 secondes correspond à ce que vous appelez cliquetis, car il y en a déja eu des centaines depuis que j’ai tenté d’utiliser ce disque?
Oui c’est de ça que je parlais, 1 clic toutes les 5 secondes, c’est exactement ça. Surtout si ça fait des centaines de fois, c’est pas bon du tout. C’est la tête de lecture qui tente de se repositionner et qui n’y arrive pas elle repart et recommence en boucle.Arrête le disque immédiatement. Plus tu le laisses tourner, plus tu risques d’aggraver les dégâts. Un cliquetis régulier comme ça, c’est souvent le début de la fin mécanique. À ce stade souvent, chaque seconde compte. Si t’as des données importantes dessus et que tu n’as encore rien sauvegardé , ne le remonte pas en lecture-écriture. Si tu peux le monter en read-only juste le temps de récupérer l’essentiel, fais-le, mais honnêtement même ça c’est risqué. La meilleure approche c’est ddrescue en mode très conservateur mais il faut un disque de destination de taille égale ou supérieure Si les données sont vraiment critiques c’est à dire (pro, fiscal, etc.) arrête tout et passe par un pro de la récupération. Ça coûte un peu cher mais au moins t’as des chances de récupérer.J’ai déjà vu des disques cliqueter pendant des heures et finir par ne plus être reconnus du tout par le BIOS. Une fois que ça arrive, c’est game over sans matériel spécialisé.Dans tous les cas, n’essaie pas de fsck ou de réparation dessus. Ça ne fera qu’accélérer la casse. J’espère que cela te sera utile.
Le problème est que la taille rendue est de 0 octets, donc il ne peut pas le monter en lecture/ecriture ou lecture seule. ddrescue va lire 0 octets (taille déclarée) sauf miracle (toujours possible)
Ouais t’as raison, je n’avais pas pensé à ce cas. Si la taille renvoyée est 0, clairement ddrescue en mode normal il va rien faire du tout il se base sur la taille déclarée par le système. Par contre on peut forcer la taille avec "--size=" . Mais bon, si le disque répond plus à aucune commande de lecture, ça sert à rien non plus hein. C’est vraiment au cas par cas.
lsblk veut dire ‹ list block devices ›, au plus bas niveau du système.
Il est impossible pour ne pas dire absurde qu’un disque ne soit pas vu par lsblk, mais vu en tant que sdb par une commande, et hdb (???) par une autre. C’est du n’importenawak.
Model Family: Western Digital Blue Mobile (SMR)
Device Model: WDC WD20SPZX-00UA7T0
Serial Number: WD-WX71E191H3JX
Product: StoreJet Transcend
Manufacturer: StoreJet Transcend
SerialNumber: 00000000000000000000
Est-ce après être passé au congélateur que le disque ‹ Western Digital › est devenu ‹ StoreJet Transcend › ? A moins d’un choc thermique extrêmement violent, je ne vois pas.
Avant d’aller plus loin, peux-tu vérifier précisément quel disque est censé être en panne, celui qui fait ‹ clic,clic › ou ‹ cloc,cloc › ?
Pourquoi as-tu omis de préciser le ‹ clic,clic › ou ‹ cloc,cloc › dans ton premier message ?
La panne est arrivée quand et comment ?
Subitement, sans aucun signe précurseur ? (j’ai du mal à y croire)
Après un essai de chute de 1m50 pour vérifier sa robustesse ?
Après un bricolage approximatif des paramètres du disque avec hdparm ?
Pour le moment, il n’y a pas de certitude absolue que le disque soit en panne, il reste quelques vérifications à faire.
smartctl interroge le disque dur, visiblement il répond correctement de ce coté là. C’est le disque Western Digital.
lspci et donc le code product vendor qui est ici
est celui du controleur USB. Je ne vois pas de contradiction: produit controleur USB transcend avec un disque Western Digital.
Sinon, j’ai eu il y a un mois un disque qui n’a pas redémarré après un arrêt. C’était un serveur, le disque était soumis à un script journalier
#!/bin/bash
# Disque à surveiller (à adapter si ce n’est pas /dev/sda)
DISK="/dev/sda"
# Adresse mail d’alerte
MAIL="monemail@chez.moi"
# Fichier temporaire pour stocker l'état
TMPFILE="/tmp/smartcheck.txt"
# Récupération des infos SMART
/sbin/smartctl -a "$DISK" > "$TMPFILE"
# Vérifications simples sur les attributs critiques
ERRORS=""
# Vérifie secteurs réalloués
if grep -q "Reallocated_Sector_Ct" "$TMPFILE"; then
REALLOC=$(grep "Reallocated_Sector_Ct" "$TMPFILE" | awk '{print $10}')
if [ "$REALLOC" -gt 0 ]; then
ERRORS="$ERRORS Reallocated sectors: $REALLOC"
fi
fi
# Vérifie secteurs en attente
if grep -q "Current_Pending_Sector" "$TMPFILE"; then
PENDING=$(grep "Current_Pending_Sector" "$TMPFILE" | awk '{print $10}')
if [ "$PENDING" -gt 0 ]; then
ERRORS="$ERRORS Pending sectors: $PENDING"
fi
fi
# Vérifie erreurs irrécupérables
if grep -q "Offline_Uncorrectable" "$TMPFILE"; then
UNC=$(grep "Offline_Uncorrectable" "$TMPFILE" | awk '{print $10}')
# attention mise à 1 à cause du disque accidenté
if [ "$UNC" -gt 1 ]; then
ERRORS="$ERRORS Uncorrectable sectors: $UNC"
fi
fi
FAIL=$(grep "FAILED" "$TMPFILE" | grep -v "WHEN_FAILED RAW_VALUE")
# Vérifie si un test SMART a échoué
if [ -n "$FAIL" ] ; then
ERRORS="$ERRORS SMART test reports failure"
fi
# Envoie un mail si problème
if [ -n "$ERRORS" ]; then
ERR=$(echo $ERRORS)
echo "Problème détecté sur $DISK : $ERR"
/usr/local/bin/smsFB "Problème détecté sur $DISK : $ERR" # envoi SMS
echo -e "Problème détecté sur $DISK : $ERRORS" | mail -s "Alerte SMART $DISK" "$MAIL"
fi
qui n’avait rien détecté à ma grande deception. Le disque a fait clic clic et est à coté de moi avant de partir à la benne.
Je ne pense pas qu’il se soit trompé de disque mais bon
La question est de savoir qui est ‹ il ›.
S’il n’est pas vu par lsblk, c’est strictement impossible.
Pour blkid, c’est un peu plus compliqué, ce pourquoi j’insiste sur lsblk.
Donc soit c’est un autre disque, soit lsblk voit bien le disque contrairement à ce qui est rapporté. lsblk a besoin de quelques secondes pour détecter un nouveau block device.
Le nom d’un block device n’est pas prédictif lors de connexion/déconnexion sur un même port usb.
La vérification du nom du block device par lsblk est indispensable à chaque rebranchement, plutôt que de deviner au doigt mouillé que ce sera /dev/sdb ou /dev/hdb (???) selon la commande. Enorme erreur à conséquences XXL.
C’est bien pour ça qu’on utilise soit UUID ou LABEL pour identifier une partition de manière prédictible.
Un block device name de périphérique ne change pas d’une application à l’autre (faut pas déconner quand-même).
Quand un sujet commence par un tel niveau de confusion et d’omissions suspectes (clac clac non signalé, contexte de l’arrivée de la panne) on commence par clarifier point par point, plutôt que de rebondir d’hypothèses en hypothèses.
Il faut laisser du temps à @josephtux pour répondre à quelques questions préliminaires, si possible sans circonvolutions.
Ensuite, on reprend méthodiquement l’analyse à zéro pour vérifier des incohérences flagrantes et savoir de quoi on parle.
Il y a un intérêt technique général à faire cette analyse, sauf si l’auteur considère être satisfait du sujet en l’état, chacun n’ayant pas le même niveau d’intérêt.
S’il y a confusion entre 2 disques et qu’il n’y a pas d’étiquette d’origine de la marque sur le disque, il faut mettre une étiquette sur ce disque qui fait clac clac pour bien le repérer, et retrouver le ,modèle sur un site de vente pour retrouver sa marque/modèle.
New USB device found,
Product: StoreJet Transcend
SerialNumber: 00000000000000000000
Un contrôleur de disques est détecté au démarrage système, et pas à chaque connexion de disque. C’est bien la non détecion du SerialNumber qui avait été à l’origine de la conclusion: ‹ le disque est mort ›
Le Westerm montre bien son SerialNumber, et ne serait donc pas mort selon la même logique.
Pour info, Transcend fait bien des disques:
$lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1,8T 0 disk
└─sda1 8:1 0 1,8T 0 part
je ne comprends pas comment j’ai pu ne pas le voir (sinon par l’âge du bonhomme…), à moins que le choc thermique créé hier ai eu cet effet.
donc je tente:
$sudo mount /dev/sda1 /mnt/sda1
mount: /mnt/sda1: impossible de lire le superbloc à l’adresse /dev/sda1.
dmesg(1) peut avoir plus d'informations après un échec de l'appel système du montage
