Изпечатай

[runtime]

Здравейте,
 Бях на почивка и с ужас установих, че една SD карта леко е умряла, на която имах едни файлчета, които естествено не съм копирал никъде ( в случая сам съм си за е**е ама както и да е ).
На картата е записан едник Arch от който бутва OLinuxino. Пробелма е, че има умрели сектори, като в началото след като я монтирах видях до някаква степен структурата на дървото. Успях да направя един имидж с dd и уж всичко е наред, но за съжаление не мога да го монтирам тъй като не разпознава файловата система.

sudo mount -o loop -t ext2 sdcard.img /media/sdcard
mount: wrong fs type, bad option, bad superblock on /dev/loop2

Ясна е, че файловата система се е счупила.
Образа го създадох с dd
dd if=/dev/sdc2 of=sdcard.img bs=2048 conv=noerror

Има ли вариант някакъв за извличане на данните от образа без да се монтира тъй както казах файловата система е счупена? Някакъв софтуер за манипулиране на данните в образа или нещо от сорта на isobuster.

Пробвах с testdisk да фиксна файловата система ама удрям пак на дърво
Сега пробвам fsck да видим дали няма да оправи нещо ама си иска доста чакане.

Поне имам образ и мога да си го клонирам на флашка и да тествам колкото е нужно, та за това всякакви идеи и мнения биха ми били от полза!

Спам от сорта на да беше си направил архив не желая - знам го, но човек допуска от време на време грешки 



П.С. SD картата вече е умряла тотално за това, че разполагам само с образа, който е ресторнат на 3 флашки, като с cfdisk виждам партишъна и като големина ми пасва, а и казва, че има заети 4 Gb за това предполагам данните трябва да са там или поне по-голямата част. Проблема е, че не познава fs-a

[go_fire]

fsck какво казва по въпроса? Ей за туй обичам Райзър и само него ползвам, защото такива проблеми се оправят винаги на сто процента.

[runtime]

Код:

Disk sdcard.img: 7931 MB, 7931678720 bytes
255 heads, 63 sectors/track, 964 cylinders, total 15491560 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk sdcard.img doesn't contain a valid partition table

Код:

e2fsck 1.42 (29-Nov-2011)
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open sdcard.img

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Пуснах e2fsck ама бая чакане си е Имам съмнение, че ако то не оправи нещата май май няма да е друго

[shoshon]

Моят съвет е, преди да правиш каквото и да е, да копираш изображението някъде за да имаш работна версия и оригинална версия.
Не е трябвало да пускаш dd на /dev/sdc2 а на /dev/sdc

Първото нещо, трябва да направиш е да сравниш размера на диска ти ( /dev/sdc2 ) със размера на файла, който си създал. Ако има съществена разлика, файловата система е заминала, но може да използваш testdisk - програмата следи за файлови сигнатури и извлича всичко намерено. Доста полезна е, защото не зависи от файловата система (май).

Ако двата файла са еднакви по размер, тогава може да пробваш:
losetup -f /dev/loop9 image.img

Arch-a използва ли LVM? Не си упоменал дали това на флашката е инсталирана OS или се стартира live
# dumpe2fs /dev/loop9 | grep -i "OS type"
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem OS type:       Linux
[root@ivan-laptop ivan]#

Ако ти разпознае типа на файловата система би трябвало да може да се монтира. Ако не, пробва ли да използваш backup на суперблок-а ( то това са ти го написали хората за fsck-то?

[root@ivan-laptop ivan]# dumpe2fs /dev/loop9  | grep -i superblock
dumpe2fs 1.41.14 (22-Dec-2010)
  Primary superblock at 1, Group descriptors at 2-2
  Backup superblock at 8193, Group descriptors at 8194-8194
  Backup superblock at 24577, Group descriptors at 24578-24578
  Backup superblock at 40961, Group descriptors at 40962-40962
  Backup superblock at 57345, Group descriptors at 57346-57346
  Backup superblock at 73729, Group descriptors at 73730-73730
[root@ivan-laptop ivan]#

Тези числа би трябвало да са еднакви с твоите.

[runtime]

sudo losetup /dev/loop0
/dev/loop0: [0807]:551650 (sdcard.img)


sudo dumpe2fs /dev/loop0 | grep -i "OS type"
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Bad magic number in super-block while trying to open /dev/loop0


sudo dumpe2fs /dev/loop0  | grep -i superblock
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Bad magic number in super-block while trying to open /dev/loop0
Couldn't find valid filesystem superblock.

Образа ми е: 7,931,678,720 bytes
Картата: Disk /dev/sdc - 7963 MB / 7595 MiB

Сега пуснах testdisk ама ми спича на определено място (56%) и си чакам ли не чакам... Ама имам търпение де, да видим.

[shoshon]

Здравей пак,

Нещо ми стана любопитно. Може ли изхода на:

hexdump /dev/loop0 | grep -i ef53 | head 

[runtime]

sudo hexdump /dev/loop0 | grep -i ef53 | head
01ef530 07d7 0000 07d8 0000 07d9 0000 07da 0000
03c6120 1000 e594 ef53 ebff 1000 e594 0006 e1a0
03ef530 2070 6974 696b c474 7397 7700 6968 656c
03ff270 2adb a1db ef53 167a 540e d9c7 c5d9 dd6d
040d540 7825 ef53 6a8a 65d3 4a5e 6564 171d 626b
05ef530 bbbb 8ae5 e7a1 a1ae 81e9 0093 7073 7761
06ef530 b0af 20e6 b3bc a4c1 c620 c0c4 c0cf 20c7
0736b20 6997 387e 8e67 5ba1 e576 ef53 0dfb cd60
07775b0 986c 701d 39b3 ef53 e392 f8ff 24dc 8d1b
07ef530 6273 6976 6564 5f6f 6554 7473 6150 7474

Това вече нищо не ми говори на мен :-D 

[ddantgwyn]

Моят съвет е, преди да правиш каквото и да е, да копираш изображението някъде за да имаш работна версия и оригинална версия.

да, това е добър съвет

Първото нещо, трябва да направиш е да сравниш размера на диска ти ( /dev/sdc2 ) със размера на файла, който си създал. Ако има съществена разлика, файловата система е заминала, но може да използваш testdisk - програмата следи за файлови сигнатури и извлича всичко намерено. Доста полезна е, защото не зависи от файловата система (май).

само за протокола -- мисля, че програмата, която му трябва е photorec, която идва с пакета testdisk:

NAME
       photorec - Recover lost files from harddisk, digital camera and cdrom

а testdisk е способна на това:

DESCRIPTION
          TestDisk checks and recovers lost partitions
          It works with :
          - BeFS (BeOS)
          - BSD disklabel (FreeBSD/OpenBSD/NetBSD)
          - CramFS, Compressed File System
          - DOS/Windows FAT12, FAT16 and FAT32
          - HFS and HFS+, Hierarchical File System
          - JFS, IBM's Journaled File System
          - Linux ext2/ext3/ext4
          - Linux Raid
            RAID 1: mirroring
            RAID 4: striped array with parity device
            RAID 5: striped array with distributed parity information
            RAID 6: striped array with distributed dual redundancy information
          - Linux Swap (versions 1 and 2)
          - LVM and LVM2, Linux Logical Volume Manager
          - Mac partition map
          - Novell Storage Services NSS
          - NTFS (Windows NT/2K/XP/2003/Vista/...)
          - ReiserFS 3.5, 3.6 and 4
          - Sun Solaris i386 disklabel
          - Unix File System UFS and UFS2 (Sun/BSD/...)
          - XFS, SGI's Journaled File System

          It can undelete files from
          - DOS/Windows FAT12, FAT16 and FAT32
          - Linux ext2
          - NTFS (Windows NT/2K/XP/2003/Vista/...)


аз лично съм ползвал единствено photorec -- наистина възстановява много неща. единствения недостатък е, че дава на възстановените файлове някакви нейни имена, което предполага последващо преименуване.

по останалото, което казваш, нямам какво да добавя

[runtime]

Все още чакам testdisk да свърши, после ще пробвам и с photorec Образа съм го копирал!
За промяна на името въобще не ми пука, важно е само 2 файла да извадя, че съм писал 200 реда на пърл и вече не помня какво съм писал. Идеята е, че ползвах платчицата да ми следи температурата в един слънчев колектор и си пазех данните за да си следя ефективността през сезоните. Ползвах owfs + едно скрипче което си бях направил на perl да тъпче в текстови файлове отчетените стойности. После тия файлове си ги теглих на копа през ftp и ги парсвах и ги тъпчех в една база данни Базата данни и стойностите си е жива и здрава на моето PC, обаче пърл скрипта дето четеше данните и ги тъпчеше в текстови файлчета е на sd картата :-D
Проблем е, че не направих бекъп   

Не е жизнено важно и мога пак да си поиграя ( въпреки че вече ме мързи ) ама... ако се спаси ще да е добре

[runtime]

photorec май ще свърши работата 

[ddantgwyn]

photorec май ще свърши работата 

ами дано имаш този късмет. всъщност, ако самите файлове не са повредени нещо, photorec ще ги извади със сигурност. а моя опит с него сочи, че nautilus се ориентира добре за типа на файловете, така че може би ще ги намериш и сравнително бързо, ако са възстановени.

и имам да те питам разни неща, че и аз имам два колектора на покрива

[runtime]

Ами пиши на ЛС с каквото мога ще помогна.
Файловете се възстановиха, но точно този ми е на части във 200 файла Явно там е имало умрели сектори и го е разделило карай поне една не малка част от него се е запазила и ще я сглобя отново 

Въпреки това ще тествам още някоя друга програма.

[shoshon]

Образа ти е:
7,564.23828125  MB
A картата:
7963 MB
Искрено се надявам някои във форума да обясни липсата на ~ 400 MB. Но ако си инсталирал Linux на флашка, това направо СМЪРДИ на boot дял + LVM disk? Ти как точно го сложи тоя Arch на flash-а?

Знам че звучи абсурдно, но все пак...
# dd if=/dev/loop0 count=1 bs=1024 2> /dev/null | strings
LABELONE
LVM2 001BfWFFVOBcdpbQcC5GuNj9BdipuOZC4U6

# pvs
 PV                                                    VG       Fmt  Attr PSize   PFree
  /dev/loop0                                        --         ---   ---     ---        ---

Да не излезе нещо такова?



//off

Това вече нищо не ми говори на мен :-D 

На теб ти казва:

# dumpe2fs /dev/loop2 | grep -i magic
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem magic number:  0xEF53

dumpe2fs: Bad magic number in super-block while trying to open /dev/loop0

0x53 0xEF е magic number ( някаква сигнатура, по която се разпознава, за какъв файл говорим ) за ext2/3/4. Трабва да седи на позиция 1080/1081. Ако го няма, значи един бог знае кво си dump-ил и как. Ако го има с някакво отместване... е тогава може да измислим нещо.. . поне на теория де.

Ето как излгежда при мен:

# hexdump /dev/loop2 | grep -i ef53 | head -1
0000430 fba0 503d 0018 0023 ef53 0001 0001 0000

-> точно по план.

Но при тебе това липсва.

[runtime]

крено се надявам някои във форума да обясни липсата на ~ 400 MB. Но ако си инсталирал Linux на флашка, това направо СМЪРДИ на boot дял + LVM disk? Ти как точно го сложи тоя Arch на flash-а?

http://archlinuxarm.org/platforms/armv5/olinuxino#qt-platform_tabs-ui-tabs2

[shoshon]

крено се надявам някои във форума да обясни липсата на ~ 400 MB. Но ако си инсталирал Linux на флашка, това направо СМЪРДИ на boot дял + LVM disk? Ти как точно го сложи тоя Arch на flash-а?

http://archlinuxarm.org/platforms/armv5/olinuxino#qt-platform_tabs-ui-tabs2

Sorry брат. тука нещата вече не са ми ясни.

Според линка който си дал, на флашката трябва да има два дяла, първият от който 16 MB a не 400MB..

Можеш ли да ми дадеш fdisk -l /dev/sdc? В случая когат SD картата е вкарана разбира се...

Ако си следвал ТОЧНО процедурата, която ми прати, можем да сметнем точно от къде започва счупения дял и да пробваме да ги издъмпим на ново.