[Linux-bruxelles] Oups ! Perte de connexion avec Iomega HDD externe usb = Perte des données archivées !
Jean-Marie GODFRAIND
godfraind_jm at hotmail.com
Dim 19 Aou 19:27:58 CEST 2018
Oups ! Perte de connexion avec Iomega HDD externe usb = Perte des données archivées !
Un Linuxien aurait-il une bonne idée afin de pouvoir lire et récupérer les données de ce disque ? Merci d'avance pour toute suggestion.
Voir ci-après les manoeuvres tentées, hélas, sans résultat ...
1/ Il s'agit d'un Iomega Disque Dur HDD externe USB
P/N=31819700, model=GDHDV, S/N=u7ak45d351
Cet Iomega est connecté à ordinateur sous Debian
2/ Avant de l'utiliser avec Rsync, un test s'est révélé malencontreux : copier un fichier de l'ordinateur vers le Iomega avec commande terminal : cp instal-asus3.txt /dev/sdb (hélas en root, et sans cp -i interaction ...).
3/ Plus moyen d'accéder à l'Iomega, même avec autre ordinateur Debian8.
Alors que sur ce même ordinateur, d'autres périphériques tels des sticks USB et un autre HDD externe (formaté ext4) sont tout de suite reconnus et accessibles sans difficulté, sans commande de mount en terminal. Midnight commander ne permet pas non plus d'accéder au Iomega.
4/ Le Disque Iomega est repéré par Debian comme sdb, sdb1 (check avec mise en tension et hors tension du disque). Avec fdisk -l, on note la présence de /dev/sdb1, mais le system est HPFS/NTFS ! Et donc, à la commande mount, il est demandé de préciser le système. Or ni HPFS, ni NTFS ne sont reconnus (et Vfat pas plus) :
mount -t ntfs /dev/sdb1 /media/clefB
mount -t ntfs-3g /dev/sdb1 /media/clefB : ne fonctionne pas non plus
5/ grâce à lsusb, on obtient l'ID du disque :
ID = 059b:0475 Iomega Corp.
Mais même si cet ID est attribué à clefB= 059b:0475, la commande mount n'est pas acceptée.
Même échec avec point de montage /mnt/clefA
6/ Lors de la recherche d'un driver sur le web, il semblerait qu'il existe un driver Iomega pour W10 ou Mac pour cet Iomega HDD. Pensez-vous que tester l'accès avec un système windows serait possible ? Dans la mesure où aucune solution alternative ne se présente.
Un essai avec W10 = pas de connexion, alors qu'un stick USB est reconnu immédiatement.
7/ comme pas possible de faire un mount point, cela serait-il dû à un problème du boot sector.
Question : faut-il tenter de faire un Boot repair avec Testdisk ?
Ou bien, faut-il faire appel à un spécialiste du crash ? Mais lequel ?
Bien merci d'avance,
Jean-Marie
PS : Iomega a été repris en partie par Lenovo et Dell
= = = =
root at new-host-Asus2:~# blkid /dev/sdb1
root at new-host-Asus2:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 149,1G 0 disk
├─sda1 8:1 0 333M 0 part /
├─sda2 8:2 0 1K 0 part
├─sda5 8:5 0 8,4G 0 part /usr
├─sda6 8:6 0 2,8G 0 part /var
├─sda7 8:7 0 3,9G 0 part [SWAP]
├─sda8 8:8 0 380M 0 part /tmp
└─sda9 8:9 0 133,3G 0 part /home
sr0 11:0 1 1024M 0 rom
sdb 8:16 0 1,4T 0 disk
└─sdb1 8:17 0 1,4T 0 part
root at new-host-Asus2:~# fdisk -l
Disk /dev/sda: 160 GB, 160039272960 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 43 345366 83 Linux
Warning: Partition 1 does not end on cylinder boundary.
/dev/sda2 43 19458 155950987 5 Extended
Warning: Partition 2 does not end on cylinder boundary.
/dev/sda5 43 1137 8787555 83 Linux
Warning: Partition 5 does not end on cylinder boundary.
/dev/sda6 1137 1502 2931862 83 Linux
Warning: Partition 6 does not end on cylinder boundary.
/dev/sda7 1502 2007 4056412 82 Linux swap
Warning: Partition 7 does not end on cylinder boundary.
/dev/sda8 2008 2056 385560 83 Linux
Warning: Partition 8 does not end on cylinder boundary.
/dev/sda9 2056 19458 139781565 83 Linux
Warning: Partition 9 does not end on cylinder boundary.
Disk /dev/sdb: 1500 GB, 1500299297280 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 182401 1465136001 7 HPFS/NTFS
root at new-host-Asus2:~#
- - - -
root at new-host-Asus2:~# mount -t hpfs /dev/sdb1 /mnt/clefA
mount : type de système de fichiers « hpfs » inconnu
root at new-host-Asus2:~# mount -t ntfs /dev/sdb1 /mnt/clefA
ntfs-3g: Failed to access volume '/dev/sdb1': Aucun fichier ou dossier de ce type
ntfs-3g 2012.1.15AR.5 external FUSE 29 - Third Generation NTFS Driver
Configuration type 7, XATTRS are on, POSIX ACLS are on
Copyright (C) 2005-2007 Yura Pakhuchiy
Copyright (C) 2006-2009 Szabolcs Szakacsits
Copyright (C) 2007-2011 Jean-Pierre Andre
Copyright (C) 2009 Erik Larsson
Usage: ntfs-3g [-o option[,...]] <device|image_file> <mount_point>
Options: ro (read-only mount), remove_hiberfile, uid=, gid=,
umask=, fmask=, dmask=, streams_interface=.
Please see the details in the manual (type: man ntfs-3g).
Example: ntfs-3g /dev/sda1 /mnt/windows
News, support and information: http://tuxera.com
root at new-host-Asus2:~# mount -t ntfs /dev/sdb1 /mnt/clefA
NTFS signature is missing.
Failed to mount '/dev/sdb1': Argument invalide
The device '/dev/sdb1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
root at new-host-Asus2:~#
root at new-host-Asus2:~# man ntfs-3g
root at new-host-Asus2:~# ntfs-3g /dev/sda1 /mnt/clefA
Mount is denied because the NTFS volume is already exclusively opened.
The volume may be already mounted, or another software may use it which
could be identified for example by the help of the 'fuser' command.
root at new-host-Asus2:~#
- - - - -
root at new-host-Asus2:~# modprobe fuse
root at new-host-Asus2:~# mkdir /mnt/ntfs
root at new-host-Asus2:~# mount -t ntfs-3g /dev/sdb1 /mnt/ntfs
NTFS signature is missing.
Failed to mount '/dev/sdb1': Argument invalide
The device '/dev/sdb1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
root at new-host-Asus2:~#
- - - - -
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://listes.domainepublic.net/pipermail/linux-bruxelles/attachments/20180819/f915a72d/attachment-0001.html>
Plus d'informations sur la liste de diffusion Linux-bruxelles