[Linux-bruxelles] Oups ! Perte de connexion avec Iomega HDD externe usb = Perte des données archivées !

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>