Hello,
je vous soumets un pb :
-j'ai une clé usb avec des données dessus, mais je n'arrive plus à lire
ces dernières. Que ce soit sous winchose (xp) ou linux (xubuntu 8.04),
le système ne reconnaît pas la clé (en visuel) et ne la monte pas.quand
je fais un lsusb, voici ce que linux me dit :
> Bus 004 Device 005: ID 13fe:3123 Kingston Technology Company Inc.
> Bus 004 Device 001: ID 0000:0000
> Bus 003 Device 001: ID 0000:0000
> Bus 002 Device 001: ID 0000:0000
> Bus 001 Device 003: ID 15d9:0a4c
> Bus 001 Device 001: ID 0000:0000
quand je fais un dmesg, voici ce qu'il m'écrit, à la fin de sa diatribe :
> [129183.587957] usb-storage: device found at 5
> [129183.587961] usb-storage: waiting for device to settle before scanning
> [129188.588568] usb-storage: device scan complete
> [129188.634571] scsi 4:0:0:0: Direct-Access Verbatim STORE N GO 5.00 PQ: 0 ANSI: 0 CCS
> [129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk
> [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
mais ne la monte pas et ne la montre pas.
Que faire pour pouvoir récupérer les données et les mettre sur une autre
clé ? des idées ? est-ce un pb de secteur de démarrage de la clé qui est
corrompu ?
merci en tout cas pour les éventuelles réponses et maux de tête que cela
engendrera ;-)
grostophe
--
linux user #375006 sur http://counter.li.org
AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits
les plus précieux de l'homme ; tout citoyen peut donc parler, écrire,
imprimer librement, sauf à répondre de l'abus de cette liberté dans les
cas déterminés par la loi."
article 11 de la déclaration de droits de l'homme et du citoyen du 26
août 1789.
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
grostophe
Doug713705 a tapoté sur son clavier:
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un : sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
idem pour sdb. je ne comprends pas
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits les plus précieux de l'homme ; tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l'abus de cette liberté dans les cas déterminés par la loi." article 11 de la déclaration de droits de l'homme et du citoyen du 26 août 1789.
Doug713705 a tapoté sur son clavier:
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un :
sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
idem pour sdb.
je ne comprends pas
--
linux user #375006 sur http://counter.li.org
AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits
les plus précieux de l'homme ; tout citoyen peut donc parler, écrire,
imprimer librement, sauf à répondre de l'abus de cette liberté dans les
cas déterminés par la loi."
article 11 de la déclaration de droits de l'homme et du citoyen du 26
août 1789.
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un : sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
idem pour sdb. je ne comprends pas
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits les plus précieux de l'homme ; tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l'abus de cette liberté dans les cas déterminés par la loi." article 11 de la déclaration de droits de l'homme et du citoyen du 26 août 1789.
grostophe
grostophe a tapoté sur son clavier:
Doug713705 a tapoté sur son clavier:
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un : sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
idem pour sdb. je ne comprends pas
autre chose : dans /dev/disk/by-id/ la clé apparaît :usb-Verbatim_STORE_N_GO_078B08820658-0:0 dans les propriétés, le volume est de 10Go alors que la clé est (normalement) de 8Go. C'est grave, docteur ?
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits les plus précieux de l'homme ; tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l'abus de cette liberté dans les cas déterminés par la loi." article 11 de la déclaration de droits de l'homme et du citoyen du 26 août 1789.
grostophe a tapoté sur son clavier:
Doug713705 a tapoté sur son clavier:
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un :
sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
idem pour sdb.
je ne comprends pas
autre chose : dans /dev/disk/by-id/
la clé apparaît :usb-Verbatim_STORE_N_GO_078B08820658-0:0
dans les propriétés, le volume est de 10Go alors que la clé est
(normalement) de 8Go. C'est grave, docteur ?
--
linux user #375006 sur http://counter.li.org
AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits
les plus précieux de l'homme ; tout citoyen peut donc parler, écrire,
imprimer librement, sauf à répondre de l'abus de cette liberté dans les
cas déterminés par la loi."
article 11 de la déclaration de droits de l'homme et du citoyen du 26
août 1789.
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un : sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
idem pour sdb. je ne comprends pas
autre chose : dans /dev/disk/by-id/ la clé apparaît :usb-Verbatim_STORE_N_GO_078B08820658-0:0 dans les propriétés, le volume est de 10Go alors que la clé est (normalement) de 8Go. C'est grave, docteur ?
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits les plus précieux de l'homme ; tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l'abus de cette liberté dans les cas déterminés par la loi." article 11 de la déclaration de droits de l'homme et du citoyen du 26 août 1789.
Doug713705
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un : sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
Ton système lit-il sans difficulté d'autres clefs usb ?
que donne ls -ail /dev/sdb* ?
Si ça te sort autre chose qu'une erreur, essaye de lire la table de partition avec fdisk : fdisk -l /dev/sdb
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un :
sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
Ton système lit-il sans difficulté d'autres clefs usb ?
que donne ls -ail /dev/sdb* ?
Si ça te sort autre chose qu'une erreur, essaye de lire la table
de partition avec fdisk : fdisk -l /dev/sdb
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un : sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
Ton système lit-il sans difficulté d'autres clefs usb ?
que donne ls -ail /dev/sdb* ?
Si ça te sort autre chose qu'une erreur, essaye de lire la table de partition avec fdisk : fdisk -l /dev/sdb
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
grostophe
Doug713705 a tapoté sur son clavier:
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un : sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
Ton système lit-il sans difficulté d'autres clefs usb ?
que donne ls -ail /dev/sdb* ?
Si ça te sort autre chose qu'une erreur, essaye de lire la table de partition avec fdisk : fdisk -l /dev/sdb
Hello, sur la première question, oui, le système lit sans souci d'autres clés usb, lecteurs de disques usb, clés bluetooth, .... pour le ls -ail /dev/sdb* : 17370 brw-rw---- 1 root disk 8, 16 2010-02-01 19:26 /dev/sdb comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ? j'avoue que mes compétences en la matière sont un peu limitées. il semblerait que je ne puisse pas récupérer les données, ce qui est fort dommage. en tout cas, merci pour l'aide, et jamais une autre idée surgissait, je suis preneur et essaierai ! à plus, grostophe
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits les plus précieux de l'homme ; tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l'abus de cette liberté dans les cas déterminés par la loi." article 11 de la déclaration de droits de l'homme et du citoyen du 26 août 1789.
Doug713705 a tapoté sur son clavier:
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un :
sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
Ton système lit-il sans difficulté d'autres clefs usb ?
que donne ls -ail /dev/sdb* ?
Si ça te sort autre chose qu'une erreur, essaye de lire la table
de partition avec fdisk : fdisk -l /dev/sdb
Hello,
sur la première question, oui, le système lit sans souci d'autres clés
usb, lecteurs de disques usb, clés bluetooth, ....
pour le ls -ail /dev/sdb* : 17370 brw-rw---- 1 root disk 8, 16
2010-02-01 19:26 /dev/sdb
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb,
cela donne : Ne peut ouvrir /dev/sdb
il semblerait que ce soit la table de partition qui soit corrompu, isn't
it ?
j'avoue que mes compétences en la matière sont un peu limitées.
il semblerait que je ne puisse pas récupérer les données, ce qui est
fort dommage.
en tout cas, merci pour l'aide, et jamais une autre idée surgissait, je
suis preneur et essaierai !
à plus,
grostophe
--
linux user #375006 sur http://counter.li.org
AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits
les plus précieux de l'homme ; tout citoyen peut donc parler, écrire,
imprimer librement, sauf à répondre de l'abus de cette liberté dans les
cas déterminés par la loi."
article 11 de la déclaration de droits de l'homme et du citoyen du 26
août 1789.
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
[129191.403414] sd 4:0:0:0: [sdb] Attached SCSI removable disk [129191.403480] sd 4:0:0:0: Attached scsi generic sg2 type 0
en résumant et si je comprends tout, le système sait que la clé existe,
As tu essayé de monter la clef à la main ?
oui en faisant un : sudo mount /dev/sdb1 /media/disk
mount: périphérique spécial /dev/sdb1 n'existe pas
Ton système lit-il sans difficulté d'autres clefs usb ?
que donne ls -ail /dev/sdb* ?
Si ça te sort autre chose qu'une erreur, essaye de lire la table de partition avec fdisk : fdisk -l /dev/sdb
Hello, sur la première question, oui, le système lit sans souci d'autres clés usb, lecteurs de disques usb, clés bluetooth, .... pour le ls -ail /dev/sdb* : 17370 brw-rw---- 1 root disk 8, 16 2010-02-01 19:26 /dev/sdb comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ? j'avoue que mes compétences en la matière sont un peu limitées. il semblerait que je ne puisse pas récupérer les données, ce qui est fort dommage. en tout cas, merci pour l'aide, et jamais une autre idée surgissait, je suis preneur et essaierai ! à plus, grostophe
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits les plus précieux de l'homme ; tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l'abus de cette liberté dans les cas déterminés par la loi." article 11 de la déclaration de droits de l'homme et du citoyen du 26 août 1789.
moi-meme
Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ?
proposition : fsck (man fsck pour voir ou plutôt fsck.vfat ). Demander les conseils d'un gourou si tu veux récupérer les données.
Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb,
cela donne : Ne peut ouvrir /dev/sdb
il semblerait que ce soit la table de partition qui soit corrompu, isn't
it ?
proposition : fsck (man fsck pour voir ou plutôt fsck.vfat
).
Demander les conseils d'un gourou si tu veux récupérer les données.
Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ?
proposition : fsck (man fsck pour voir ou plutôt fsck.vfat ). Demander les conseils d'un gourou si tu veux récupérer les données.
Dominique MICOLLET
> Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ?
Il me semble que si la table de partition était corrompue, /dev/sdb pourrait être accédé par fdisk : la table serait vide ou contiendrait des données incohérentes.
Si la clef n'a jamais été partitionnée mais qu'elle a été formaté directement en /dev/sdx, il est possible que fsck y retrouve ses petits, surtout si des copies du superbloc existent
Demander les conseils d'un gourou si tu veux récupérer les données.
Je ne suis pas un gourou, mais je peux faire une suggestion : faire une copie brute des données : dd if=/dev/sdb of=copie_de_clef ça générera une erreur : - soit en fin de copie parce que la clef aura été lue en totalité, et qu'on tente d'aller au delà de la fin : ça veut dire que la clef est physiquement fonctionnelle et qu'on peut alors faire joujou avec la copie pour essayer d'y retrouver des données (ce que je ne sais pas faire) : la commande file sur cette copie peut donner des informations intéressantes; noter que recopier un grosse clef prend beaucoup de temps. - soit en début de copie : il est alors à craindre que la clef soit physiquement atteinte et je crains qu'il ne faille organiser des funérailles.
Cezpendant, si c'était _*ma*_ clef, avant de la jeter, j'essaierai déjà d'écrire des zéros dedans : j'ai déjà récupéré par ce moyen des supports illisibles, _*au prix évidemment de la perte des données*_ : mais je décline toute responsabilité dans la mise en oeuvre de cette méthode.
Cordialement. -- Dominique MICOLLET Adresse email : enlever deux francs
> Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb,
cela donne : Ne peut ouvrir /dev/sdb
il semblerait que ce soit la table de partition qui soit corrompu, isn't
it ?
Il me semble que si la table de partition était corrompue, /dev/sdb pourrait
être accédé par fdisk : la table serait vide ou contiendrait des données
incohérentes.
Si la clef n'a jamais été partitionnée mais qu'elle a été formaté
directement en /dev/sdx, il est possible que fsck y retrouve ses petits,
surtout si des copies du superbloc existent
Demander les conseils d'un gourou si tu veux récupérer les données.
Je ne suis pas un gourou, mais je peux faire une suggestion : faire une
copie brute des données :
dd if=/dev/sdb of=copie_de_clef
ça générera une erreur :
- soit en fin de copie parce que la clef aura été lue en totalité, et qu'on
tente d'aller au delà de la fin : ça veut dire que la clef est physiquement
fonctionnelle et qu'on peut alors faire joujou avec la copie pour essayer
d'y retrouver des données (ce que je ne sais pas faire) : la commande file
sur cette copie peut donner des informations intéressantes; noter que
recopier un grosse clef prend beaucoup de temps.
- soit en début de copie : il est alors à craindre que la clef soit
physiquement atteinte et je crains qu'il ne faille organiser des
funérailles.
Cezpendant, si c'était _*ma*_ clef, avant de la jeter, j'essaierai déjà
d'écrire des zéros dedans : j'ai déjà récupéré par ce moyen des supports
illisibles, _*au prix évidemment de la perte des données*_ : mais je
décline toute responsabilité dans la mise en oeuvre de cette méthode.
Cordialement.
--
Dominique MICOLLET
Adresse email : enlever deux francs
> Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ?
Il me semble que si la table de partition était corrompue, /dev/sdb pourrait être accédé par fdisk : la table serait vide ou contiendrait des données incohérentes.
Si la clef n'a jamais été partitionnée mais qu'elle a été formaté directement en /dev/sdx, il est possible que fsck y retrouve ses petits, surtout si des copies du superbloc existent
Demander les conseils d'un gourou si tu veux récupérer les données.
Je ne suis pas un gourou, mais je peux faire une suggestion : faire une copie brute des données : dd if=/dev/sdb of=copie_de_clef ça générera une erreur : - soit en fin de copie parce que la clef aura été lue en totalité, et qu'on tente d'aller au delà de la fin : ça veut dire que la clef est physiquement fonctionnelle et qu'on peut alors faire joujou avec la copie pour essayer d'y retrouver des données (ce que je ne sais pas faire) : la commande file sur cette copie peut donner des informations intéressantes; noter que recopier un grosse clef prend beaucoup de temps. - soit en début de copie : il est alors à craindre que la clef soit physiquement atteinte et je crains qu'il ne faille organiser des funérailles.
Cezpendant, si c'était _*ma*_ clef, avant de la jeter, j'essaierai déjà d'écrire des zéros dedans : j'ai déjà récupéré par ce moyen des supports illisibles, _*au prix évidemment de la perte des données*_ : mais je décline toute responsabilité dans la mise en oeuvre de cette méthode.
Cordialement. -- Dominique MICOLLET Adresse email : enlever deux francs
grostophe
Dominique MICOLLET a tapoté sur son clavier:
Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ?
Il me semble que si la table de partition était corrompue, /dev/sdb pourrait être accédé par fdisk : la table serait vide ou contiendrait des données incohérentes.
Si la clef n'a jamais été partitionnée mais qu'elle a été formaté directement en /dev/sdx, il est possible que fsck y retrouve ses petits, surtout si des copies du superbloc existent
Demander les conseils d'un gourou si tu veux récupérer les données.
Je ne suis pas un gourou, mais je peux faire une suggestion : faire une copie brute des données : dd if=/dev/sdb of=copie_de_clef ça générera une erreur : - soit en fin de copie parce que la clef aura été lue en totalité, et qu'on tente d'aller au delà de la fin : ça veut dire que la clef est physiquement fonctionnelle et qu'on peut alors faire joujou avec la copie pour essayer d'y retrouver des données (ce que je ne sais pas faire) : la commande file sur cette copie peut donner des informations intéressantes; noter que recopier un grosse clef prend beaucoup de temps. - soit en début de copie : il est alors à craindre que la clef soit physiquement atteinte et je crains qu'il ne faille organiser des funérailles.
Cezpendant, si c'était _*ma*_ clef, avant de la jeter, j'essaierai déjà d'écrire des zéros dedans : j'ai déjà récupéré par ce moyen des supports illisibles, _*au prix évidemment de la perte des données*_ : mais je décline toute responsabilité dans la mise en oeuvre de cette méthode.
Cordialement.
Merci pour pour les suggestions. pour le moment, pas de funérailles en vue ;-) , je vais tester les propositions faites. je vais voir ça ce soir et je vous tiens au courant. merci encore
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits les plus précieux de l'homme ; tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l'abus de cette liberté dans les cas déterminés par la loi." article 11 de la déclaration de droits de l'homme et du citoyen du 26 août 1789.
Dominique MICOLLET a tapoté sur son clavier:
Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb,
cela donne : Ne peut ouvrir /dev/sdb
il semblerait que ce soit la table de partition qui soit corrompu, isn't
it ?
Il me semble que si la table de partition était corrompue, /dev/sdb pourrait
être accédé par fdisk : la table serait vide ou contiendrait des données
incohérentes.
Si la clef n'a jamais été partitionnée mais qu'elle a été formaté
directement en /dev/sdx, il est possible que fsck y retrouve ses petits,
surtout si des copies du superbloc existent
Demander les conseils d'un gourou si tu veux récupérer les données.
Je ne suis pas un gourou, mais je peux faire une suggestion : faire une
copie brute des données :
dd if=/dev/sdb of=copie_de_clef
ça générera une erreur :
- soit en fin de copie parce que la clef aura été lue en totalité, et qu'on
tente d'aller au delà de la fin : ça veut dire que la clef est physiquement
fonctionnelle et qu'on peut alors faire joujou avec la copie pour essayer
d'y retrouver des données (ce que je ne sais pas faire) : la commande file
sur cette copie peut donner des informations intéressantes; noter que
recopier un grosse clef prend beaucoup de temps.
- soit en début de copie : il est alors à craindre que la clef soit
physiquement atteinte et je crains qu'il ne faille organiser des
funérailles.
Cezpendant, si c'était _*ma*_ clef, avant de la jeter, j'essaierai déjà
d'écrire des zéros dedans : j'ai déjà récupéré par ce moyen des supports
illisibles, _*au prix évidemment de la perte des données*_ : mais je
décline toute responsabilité dans la mise en oeuvre de cette méthode.
Cordialement.
Merci pour pour les suggestions. pour le moment, pas de funérailles en
vue ;-) , je vais tester les propositions faites. je vais voir ça ce
soir et je vous tiens au courant.
merci encore
--
linux user #375006 sur http://counter.li.org
AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits
les plus précieux de l'homme ; tout citoyen peut donc parler, écrire,
imprimer librement, sauf à répondre de l'abus de cette liberté dans les
cas déterminés par la loi."
article 11 de la déclaration de droits de l'homme et du citoyen du 26
août 1789.
Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ?
Il me semble que si la table de partition était corrompue, /dev/sdb pourrait être accédé par fdisk : la table serait vide ou contiendrait des données incohérentes.
Si la clef n'a jamais été partitionnée mais qu'elle a été formaté directement en /dev/sdx, il est possible que fsck y retrouve ses petits, surtout si des copies du superbloc existent
Demander les conseils d'un gourou si tu veux récupérer les données.
Je ne suis pas un gourou, mais je peux faire une suggestion : faire une copie brute des données : dd if=/dev/sdb of=copie_de_clef ça générera une erreur : - soit en fin de copie parce que la clef aura été lue en totalité, et qu'on tente d'aller au delà de la fin : ça veut dire que la clef est physiquement fonctionnelle et qu'on peut alors faire joujou avec la copie pour essayer d'y retrouver des données (ce que je ne sais pas faire) : la commande file sur cette copie peut donner des informations intéressantes; noter que recopier un grosse clef prend beaucoup de temps. - soit en début de copie : il est alors à craindre que la clef soit physiquement atteinte et je crains qu'il ne faille organiser des funérailles.
Cezpendant, si c'était _*ma*_ clef, avant de la jeter, j'essaierai déjà d'écrire des zéros dedans : j'ai déjà récupéré par ce moyen des supports illisibles, _*au prix évidemment de la perte des données*_ : mais je décline toute responsabilité dans la mise en oeuvre de cette méthode.
Cordialement.
Merci pour pour les suggestions. pour le moment, pas de funérailles en vue ;-) , je vais tester les propositions faites. je vais voir ça ce soir et je vous tiens au courant. merci encore
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
"La libre communication des pensées et des opinions est un des droits les plus précieux de l'homme ; tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l'abus de cette liberté dans les cas déterminés par la loi." article 11 de la déclaration de droits de l'homme et du citoyen du 26 août 1789.
grostophe
grostophe a tapoté sur son clavier:
Dominique MICOLLET a tapoté sur son clavier:
Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ?
Il me semble que si la table de partition était corrompue, /dev/sdb pourrait être accédé par fdisk : la table serait vide ou contiendrait des données incohérentes.
Si la clef n'a jamais été partitionnée mais qu'elle a été formaté directement en /dev/sdx, il est possible que fsck y retrouve ses petits, surtout si des copies du superbloc existent
Demander les conseils d'un gourou si tu veux récupérer les données.
Je ne suis pas un gourou, mais je peux faire une suggestion : faire une copie brute des données : dd if=/dev/sdb of=copie_de_clef ça générera une erreur : - soit en fin de copie parce que la clef aura été lue en totalité, et qu'on tente d'aller au delà de la fin : ça veut dire que la clef est physiquement fonctionnelle et qu'on peut alors faire joujou avec la copie pour essayer d'y retrouver des données (ce que je ne sais pas faire) : la commande file sur cette copie peut donner des informations intéressantes; noter que recopier un grosse clef prend beaucoup de temps. - soit en début de copie : il est alors à craindre que la clef soit physiquement atteinte et je crains qu'il ne faille organiser des funérailles. Cezpendant, si c'était _*ma*_ clef, avant de la jeter, j'essaierai déjà d'écrire des zéros dedans : j'ai déjà récupéré par ce moyen des supports illisibles, _*au prix évidemment de la perte des données*_ : mais je décline toute responsabilité dans la mise en oeuvre de cette méthode.
Cordialement.
Merci pour pour les suggestions. pour le moment, pas de funérailles en vue ;-) , je vais tester les propositions faites. je vais voir ça ce soir et je vous tiens au courant. merci encore
hello, je reviens, après avoir essayé les pistes ci-dessus. pour "sudo fsck.vfat -a /dev/sdb [sudo] password for xxxx: dosfsck 2.11, 12 Mar 2005, FAT32, LFN open /dev/sdb:No medium found" bon, là, ça sent le sapin (j'ai aussi essayé "fsck.vfat -a /dev/disk/by-id/usb-Verbatim_STORE_N_GO_078B08820658-0:0", sans plus de succès) puis j'ai testé "dd if=/dev/sdb of=copie_de_clef" et là, la ligne qui annihile mes espoirs : "dd: ouverture de `/dev/sdb': Aucun medium trouvé" je crois que désormais, je vais pouvoir organiser des funérailles à cette "foutue" clé usb. au fait, comment peut-on écrire des zéros (ou autre chose) dans une clé qui n'apparaît pas dans le système (mis à part en faisant lsusb, dmesg ou dans le dossier /dev/disk/xxxx mais pas dans le dossier /media) en tout cas, merci pour toutes ces pistes qui m'auront permis d'apprendre un peu plus ... cordialement
ps : je vais attendre un peu pour des funérailles de première classe, des fois que ...
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
grostophe a tapoté sur son clavier:
Dominique MICOLLET a tapoté sur son clavier:
Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb,
cela donne : Ne peut ouvrir /dev/sdb
il semblerait que ce soit la table de partition qui soit corrompu,
isn't
it ?
Il me semble que si la table de partition était corrompue, /dev/sdb
pourrait
être accédé par fdisk : la table serait vide ou contiendrait des données
incohérentes.
Si la clef n'a jamais été partitionnée mais qu'elle a été formaté
directement en /dev/sdx, il est possible que fsck y retrouve ses petits,
surtout si des copies du superbloc existent
Demander les conseils d'un gourou si tu veux récupérer les données.
Je ne suis pas un gourou, mais je peux faire une suggestion : faire une
copie brute des données :
dd if=/dev/sdb of=copie_de_clef
ça générera une erreur : - soit en fin de copie parce que la clef
aura été lue en totalité, et qu'on
tente d'aller au delà de la fin : ça veut dire que la clef est
physiquement
fonctionnelle et qu'on peut alors faire joujou avec la copie pour essayer
d'y retrouver des données (ce que je ne sais pas faire) : la commande
file
sur cette copie peut donner des informations intéressantes; noter que
recopier un grosse clef prend beaucoup de temps. - soit en début de
copie : il est alors à craindre que la clef soit
physiquement atteinte et je crains qu'il ne faille organiser des
funérailles.
Cezpendant, si c'était _*ma*_ clef, avant de la jeter, j'essaierai déjà
d'écrire des zéros dedans : j'ai déjà récupéré par ce moyen des supports
illisibles, _*au prix évidemment de la perte des données*_ : mais je
décline toute responsabilité dans la mise en oeuvre de cette méthode.
Cordialement.
Merci pour pour les suggestions. pour le moment, pas de funérailles en
vue ;-) , je vais tester les propositions faites. je vais voir ça ce
soir et je vous tiens au courant.
merci encore
hello,
je reviens, après avoir essayé les pistes ci-dessus.
pour "sudo fsck.vfat -a /dev/sdb
[sudo] password for xxxx:
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
open /dev/sdb:No medium found"
bon, là, ça sent le sapin (j'ai aussi essayé "fsck.vfat -a
/dev/disk/by-id/usb-Verbatim_STORE_N_GO_078B08820658-0:0", sans plus de
succès)
puis j'ai testé "dd if=/dev/sdb of=copie_de_clef" et là, la ligne qui
annihile mes espoirs : "dd: ouverture de `/dev/sdb': Aucun medium trouvé"
je crois que désormais, je vais pouvoir organiser des funérailles à
cette "foutue" clé usb.
au fait, comment peut-on écrire des zéros (ou autre chose) dans une clé
qui n'apparaît pas dans le système (mis à part en faisant lsusb, dmesg
ou dans le dossier /dev/disk/xxxx mais pas dans le dossier /media)
en tout cas, merci pour toutes ces pistes qui m'auront permis
d'apprendre un peu plus ...
cordialement
ps : je vais attendre un peu pour des funérailles de première classe,
des fois que ...
--
linux user #375006 sur http://counter.li.org
AbulEduLive (basée sur Xubuntu)
Le Mon, 01 Feb 2010 19:44:36 +0100, grostophe a écrit :
comme pas de message visible d'erreur, j'ai fait le fdisk -l /dev/sdb, cela donne : Ne peut ouvrir /dev/sdb il semblerait que ce soit la table de partition qui soit corrompu, isn't it ?
Il me semble que si la table de partition était corrompue, /dev/sdb pourrait être accédé par fdisk : la table serait vide ou contiendrait des données incohérentes.
Si la clef n'a jamais été partitionnée mais qu'elle a été formaté directement en /dev/sdx, il est possible que fsck y retrouve ses petits, surtout si des copies du superbloc existent
Demander les conseils d'un gourou si tu veux récupérer les données.
Je ne suis pas un gourou, mais je peux faire une suggestion : faire une copie brute des données : dd if=/dev/sdb of=copie_de_clef ça générera une erreur : - soit en fin de copie parce que la clef aura été lue en totalité, et qu'on tente d'aller au delà de la fin : ça veut dire que la clef est physiquement fonctionnelle et qu'on peut alors faire joujou avec la copie pour essayer d'y retrouver des données (ce que je ne sais pas faire) : la commande file sur cette copie peut donner des informations intéressantes; noter que recopier un grosse clef prend beaucoup de temps. - soit en début de copie : il est alors à craindre que la clef soit physiquement atteinte et je crains qu'il ne faille organiser des funérailles. Cezpendant, si c'était _*ma*_ clef, avant de la jeter, j'essaierai déjà d'écrire des zéros dedans : j'ai déjà récupéré par ce moyen des supports illisibles, _*au prix évidemment de la perte des données*_ : mais je décline toute responsabilité dans la mise en oeuvre de cette méthode.
Cordialement.
Merci pour pour les suggestions. pour le moment, pas de funérailles en vue ;-) , je vais tester les propositions faites. je vais voir ça ce soir et je vous tiens au courant. merci encore
hello, je reviens, après avoir essayé les pistes ci-dessus. pour "sudo fsck.vfat -a /dev/sdb [sudo] password for xxxx: dosfsck 2.11, 12 Mar 2005, FAT32, LFN open /dev/sdb:No medium found" bon, là, ça sent le sapin (j'ai aussi essayé "fsck.vfat -a /dev/disk/by-id/usb-Verbatim_STORE_N_GO_078B08820658-0:0", sans plus de succès) puis j'ai testé "dd if=/dev/sdb of=copie_de_clef" et là, la ligne qui annihile mes espoirs : "dd: ouverture de `/dev/sdb': Aucun medium trouvé" je crois que désormais, je vais pouvoir organiser des funérailles à cette "foutue" clé usb. au fait, comment peut-on écrire des zéros (ou autre chose) dans une clé qui n'apparaît pas dans le système (mis à part en faisant lsusb, dmesg ou dans le dossier /dev/disk/xxxx mais pas dans le dossier /media) en tout cas, merci pour toutes ces pistes qui m'auront permis d'apprendre un peu plus ... cordialement
ps : je vais attendre un peu pour des funérailles de première classe, des fois que ...
-- linux user #375006 sur http://counter.li.org AbulEduLive (basée sur Xubuntu)
Doug713705
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
au fait, comment peut-on écrire des zéros (ou autre chose) dans une clé qui n'apparaît pas dans le système (mis à part en faisant lsusb, dmesg ou dans le dossier /dev/disk/xxxx mais pas dans le dossier /media)
dd if=/dev/zero of=/dev/sdb
Cela ne remplira pas vraiment de zéros mais plutôt de "caractères nuls".
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
au fait, comment peut-on écrire des zéros (ou autre chose) dans une clé
qui n'apparaît pas dans le système (mis à part en faisant lsusb, dmesg
ou dans le dossier /dev/disk/xxxx mais pas dans le dossier /media)
dd if=/dev/zero of=/dev/sdb
Cela ne remplira pas vraiment de zéros mais plutôt de "caractères nuls".
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.os.linux.configuration grostophe nous expliquait:
au fait, comment peut-on écrire des zéros (ou autre chose) dans une clé qui n'apparaît pas dans le système (mis à part en faisant lsusb, dmesg ou dans le dossier /dev/disk/xxxx mais pas dans le dossier /media)
dd if=/dev/zero of=/dev/sdb
Cela ne remplira pas vraiment de zéros mais plutôt de "caractères nuls".
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
