Usb Przestal Sie Mountowac

[Bob3k]

Witam, mam nastepujacy problem z pendrivem.

Dzialal normalnie - automatycznie sie montowal, nie bylo problemow z zapisem i odczytem.

Nie wiem co sie wydarzylo, ale teraz pen nie montuje sie ani automatycznie, ani recznie.

Probowalem go odpalic w Windzie, system stwierdza ze nie jest sformatowany.

 

Reczne montowanie zwraca nastepujacy komunikat:

[root@localhost /]# mount -t vfat /dev/sdb /media/usb
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Zapis z logu i dmesg:

ot@localhost /]# tail -f var/log/messages
Jan  7 17:11:51 localhost kernel: sd 7:0:0:0: [sdb] Write Protect is off
Jan  7 17:11:51 localhost kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
Jan  7 17:11:51 localhost kernel:  sdb: sdb1
Jan  7 17:11:51 localhost kernel: sd 7:0:0:0: [sdb] Attached SCSI removable disk
Jan  7 17:11:51 localhost kernel: sd 7:0:0:0: Attached scsi generic sg2 type 0
Jan  7 17:12:30 localhost acpid: received event "thermal_zone TZ 00000081 00000000"
Jan  7 17:12:30 localhost acpid: notifying client 2274[68:68]
Jan  7 17:12:30 localhost acpid: notifying client 2467[0:0]
Jan  7 17:12:30 localhost acpid: completed event "thermal_zone TZ 00000081 00000000"
Jan  7 17:16:18 localhost kernel: usb 1-1: USB disconnect, address 7
Jan  7 17:17:21 localhost kernel: usb 1-1: new full speed USB device using ohci_hcd and address 8
Jan  7 17:17:21 localhost kernel: usb 1-1: configuration #1 chosen from 1 choice
Jan  7 17:17:21 localhost kernel: scsi8 : SCSI emulation for USB Mass Storage devices
Jan  7 17:17:26 localhost kernel: scsi 8:0:0:0: Direct-Access     Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 2
Jan  7 17:17:26 localhost kernel: sd 8:0:0:0: [sdb] 7823296 512-byte hardware sectors (4006 MB)
Jan  7 17:17:26 localhost kernel: sd 8:0:0:0: [sdb] Write Protect is off
Jan  7 17:17:26 localhost kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Jan  7 17:17:26 localhost kernel: sd 8:0:0:0: [sdb] 7823296 512-byte hardware sectors (4006 MB)
Jan  7 17:17:26 localhost kernel: sd 8:0:0:0: [sdb] Write Protect is off
Jan  7 17:17:26 localhost kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Jan  7 17:17:26 localhost kernel:  sdb: sdb1
Jan  7 17:17:26 localhost kernel: sd 8:0:0:0: [sdb] Attached SCSI removable disk
Jan  7 17:17:26 localhost kernel: sd 8:0:0:0: Attached scsi generic sg2 type 0

[root@localhost /]# dmesg|tail
sd 8:0:0:0: [sdb] Write Protect is off
sd 8:0:0:0: [sdb] Mode Sense: 65 44 09 30
sd 8:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 8:0:0:0: [sdb] Attached SCSI removable disk
sd 8:0:0:0: Attached scsi generic sg2 type 0
FAT: invalid media value (0x00)
VFS: Can't find a valid FAT filesystem on dev sdb.
FAT: bogus logical sector size 65535
VFS: Can't find a valid FAT filesystem on dev sdb1.

 

Z tego co udalo mi sie ustalic to to ze informacja o systemie plikow na USB zostala uszkodzona albo nadpisana. (tak przypuszczam)

Czy da sie cos z tym zrobic i uratowac dane na pendrivie?

 

Dzialam na Fedorze 8

USB : Kingston DT100 4GB

 

Pozdrawiam

Bob3k

[@WalDo]

Załóż od nową partycję, filesystem i powinno być po kłopocie chyba. Jako root:

fdisk /dev/sdb 
#usun istniejące partycje, załóż na nowo, zapisz
mkfs.vfat /dev/sdb1

A może wystarczy

fsck -f /dev/sdb1

[Arabski]

Brakuje numerków panowie! Wszędzie poza fdiskiem powinno być

 

/dev/sdb1

 

a jak widać nie jest.

[@WalDo]

Brakuje numerków panowie!

Ech... tak mi czasem mózg zatyka

 

[Arabski]

No i jeszcze:

 

Z tego co udalo mi sie ustalic to to ze informacja o systemie plikow na USB zostala uszkodzona albo nadpisana. (tak przypuszczam)

Czy da sie cos z tym zrobic i uratowac dane na pendrivie?

 

Załóż od nową partycję, filesystem i powinno być po kłopocie chyba.

 

I po danych również

 

Kolego autorze - musisz sięgnąć po program do odzyskiwania danych. Tylko obawiam się, że będziesz musiał się w tym celu posłużyć Windą, bo ja osobiście nie znam programów do naprawy/odzyskiwania danych dla nielota.

 

(proszę nie bić za sugestię)

 

Frywolne fsck tego pendriva może spowodować pożegnanie się z danymi na stałe. (Że o zakładaniu partycji i fs'a nie wpomnę).

[@WalDo]

I po danych również

O cholera... Za to muszę przeprosić - mam nadzieję, że nie po fakcie. Nie zwróciłem uwagi na "uratowac dane na pendrivie".

W ramach przeprosin proponuję skorzystać z testdisk - jest w repozytoriach Fedory, a tu kilka słów o programie → http://www.cgsecurity.org/wiki/TestDisk

Dodam, że przy jego pomocy odtworzyłem jakiś czas temu partycje i dane ze sformatowanego dysku (przed ponownym zapisem danych po sformatowaniu). Mam nadzieję, że jakby co to się przyda.

[Bob3k]

Hmm.. no po fakcie...

Szczesliwie nic strasznego sie nie stalo, bo pen jest nowy i dopiero poprzerzucalem na niego rozne dokumenty z dotychczas uzywanych flashow.

Backup jest wiec nie trzeba niczego odzyskiwac.

W kazdym badz razie i tak dzieje sie dziwna rzecz.

Przeprowadzilem zgodnie z instrukcjami

 

fdisk -> usuniecie , nowa partycja,zapis

mkfs.vfat (nota bene wymusil uzycie parametru -I)

 

Dysk sie automatycznie montuje, ale wolne miejsce 3,7 GB zamiast 4

A fdisk pokazuje teraz brak partycji.

 

Zapis na dysku jest mozliwy

 

I jeszcze jedna rzecz:

Zmienila sie chyba "struktura dysku", w sensie zmienily sie liczby cylindrow, heads,sectors,

Np dla cylindrow 3880 na 1017 . Czy to jakos wplywa na szybkosc zapisu/odczytu?

[Arabski]

Dysk sie automatycznie montuje, ale wolne miejsce 3,7 GB zamiast 4

A fdisk pokazuje teraz brak partycji.

...

Zmienila sie chyba "struktura dysku", w sensie zmienily sie liczby cylindrow, heads,sectors,

Np dla cylindrow 3880 na 1017 . Czy to jakos wplywa na szybkosc zapisu/odczytu?

 

A wcześniej było więcej? Może chodzi o oszukane gigabajty?

 

Co do struktury - czasami się tak miesza. Nie ma się czym przejmować. Żeby wyjaśnić do końca, mógłbyś dać wyniki

 

df -k

df -h

fdisk -l /dev/jaki_tam_ten_pen_ma_sd

[Bob3k]

Szczerze to glowy sobie nie dam uciac za te 4 GB, bo nie mam tego na papierze.

Ale wydaje mi sie ze jednak byly pelne 4.

 

A to wyniki z komend:

[root@localhost /]# df -k
System plików      bl.  1K B        użyte dostępne %uż. zamont. na
/dev/sda2              9920624   3873444   5535112  42% /
/dev/sda5             17786848  10261408   6607328  61% /home
tmpfs                   111392        12    111380   1% /dev/shm
/dev/sr0               3344482   3344482         0 100% /media/Fedora 8 i386 DVD
/dev/sdb               3904004         8   3903996   1% /media/disk

[root@localhost /]# df -h
System plików         rozm. użyte dost. %uż. zamont. na
/dev/sda2             9,5G  3,7G  5,3G  42% /
/dev/sda5              17G  9,8G  6,4G  61% /home
tmpfs                 109M   12K  109M   1% /dev/shm
/dev/sr0              3,2G  3,2G     0 100% /media/Fedora 8 i386 DVD
/dev/sdb              3,8G  8,0K  3,8G   1% /media/disk

[root@localhost /]# fdisk -l /dev/sdb

Disk /dev/sdb: 4005 MB, 4005527552 bytes
124 heads, 62 sectors/track, 1017 cylinders
Units = cylinders of 7688 * 512 = 3936256 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
[root@localhost /]#

[@WalDo]

Z polecenia "fdisk -l /dev/sdb" wynika, że znowu jest tak jak napisałem początkowo (ŹLE!!!) i na co zwrócił mi uwagę Arabski: /dev/sdb zamiast /dev/sdb1. Poprawiłem to w swoim pierwszym poście.

 

Powinieneś założyć partycję /dev/sdb1 typu - o ile się nie mylę - "b" (FAT32) na dysku /dev/sdb.

Wtedy nie będzie potrzebna również opcja "-I" przy tworzeniu filesystemu, bo będzie on tworzony na partycji a nie na całym dysku. W szczególnym przypadku oczywiście partycja może zajmować cały dysk i najlepiej tak właśnie zrób. Od razu struktura się pewnie zmieni.

 

Pojemność jest ewidentnie oszukana 4005527552 bajtów (widoczne w fdisk) liczą jako 4GB czyli tak naprawdę to w przybliżeniu jest 3,7GB. Dość istotna różnica między 1024*1024*1024 a 1000*1000*1000

Znany numer również - a może przede wszystkim - z fałszowaniem pojemności dysków twardych.

[InIrudeBwoy]

Do odzyskiwania danych mozna użyć http://www.cgsecurity.org/wiki/TestDisk_Download

Jest w repo.

[thof]

Z tą pojemnością to sytuacja całkiem normalna od zawsze dla producentów dysków podstawą w obliczaniu pojemności była 10, a nie 2. Na 90% z dyskiem twardym masz taką samą sytuację. Tylko oczywiście im większa pojemność tym strata jest mniej odczuwalna. Mnie na pendrive 4gb okradli na 70MB

[Arabski]

Jako efekt tego "oszustwa" Seagate swego czasu udostępniło Acronis True Imge do zassania za darmo (link).

 

Tylko oczywiście im większa pojemność tym strata jest mniej odczuwalna.

 

Wręcz przeciwnie. Im większy dysk, tym większa strata Popatrz na ile mnie okradli

 

/dev/hda1             699G  374G  325G  54% /export/vol75a
/dev/hdb1             699G  670G   30G  96% /export/vol75b
/dev/hdc1             699G  670G   29G  96% /export/vol75c
/dev/hdd1             187G  185G  1.7G 100% /export/vol20a
[root@nodezero ~]# fdisk -l | grep Disk
Disk /dev/hda: 750.1 GB, 750156374016 bytes
Disk /dev/hdb: 750.1 GB, 750156374016 bytes
Disk /dev/hdc: 750.1 GB, 750156374016 bytes
Disk /dev/hdd: 400.0 GB, 400088457216 bytes

 

Po 51GB z każdego :lammer:

[@WalDo]

Do odzyskiwania danych mozna użyć

Mówiłem...

 

[InIrudeBwoy]

OMG Arabski co Ty trzymasz tych dyskach?

 

Przynaję się WalDo, nie czytałem całego wątku. To już ostatni raz