What if Block Group Descriptors Table are corrupt?
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
What if Block Group Descriptors Table are corrupt?
Hi!
A few days ago one of my disks was lost. It was in dns-320 NAS (linux).
I tryed to recover filesystem using testdisk. It hasn't recovered. The filesystem is corrupt despite superblock was fine.
As I'd explored, my disk lost one sector (4096 bytes) in the Descriptors Table. Nothing more, but it was enough to fail the file system and to fool testdisk.
Photorec didn't restore all files too.
However, I restored important files in manual mode (dd, hex-editor, calc, ext4.wiki.kernel.org and patience).
My question is:
Is it possible to recover this kind of bug automaticaly?
May be I missed some section in testdisk documentation?
Thanks for reading!
Double thanks for future answering!
A few days ago one of my disks was lost. It was in dns-320 NAS (linux).
I tryed to recover filesystem using testdisk. It hasn't recovered. The filesystem is corrupt despite superblock was fine.
As I'd explored, my disk lost one sector (4096 bytes) in the Descriptors Table. Nothing more, but it was enough to fail the file system and to fool testdisk.
Photorec didn't restore all files too.
However, I restored important files in manual mode (dd, hex-editor, calc, ext4.wiki.kernel.org and patience).
My question is:
Is it possible to recover this kind of bug automaticaly?
May be I missed some section in testdisk documentation?
Thanks for reading!
Double thanks for future answering!
- cgrenier
- Site Admin
- Posts: 5432
- Joined: 18 Feb 2012, 15:08
- Location: Le Perreux Sur Marne, France
- Contact:
Re: What if Block Group Descriptors Table are corrupt?
Was it an ext4 Block Group Descriptor ?
fsck.ext4 should have been able to deal with it.
fsck.ext4 should have been able to deal with it.
Re: What if Block Group Descriptors Table are corrupt?
Yes, it was.
Unfortunately, it didn't help.
Maybe, I should pass additional parameters.
I used fsck with "-nv" parameters with/without additional "-b". I used the value for -b parameter which I got from the testdisk diagnostic message.
Tonight, I will reproduce error message from fsck and write it here.
Unfortunately, it didn't help.
Maybe, I should pass additional parameters.
I used fsck with "-nv" parameters with/without additional "-b". I used the value for -b parameter which I got from the testdisk diagnostic message.
Tonight, I will reproduce error message from fsck and write it here.
Re: What if Block Group Descriptors Table are corrupt?
device D-Link 320, pair WD 1Tb installed.
message from fsck
linux ver
testdisk analitics screen
reading descriptor table
message from fsck
Code: Select all
fsck.ext4 -nv -b 32768 -B 4096 /dev/sdb
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb
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>
fsck.ext4 -nv -b 8193 -B 4096 /dev/sdb
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb
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>
Code: Select all
# uname -a
Linux sssssss 2.6.22.18 #23 Wed May 25 15:48:30 CST 2011 armv5tejl GNU/Linux
Code: Select all
Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Partition Start End Size in sectors
P Linux Swap 2040 2055 16
P MS Data 1062912 2086991 1024080
>P MS Data 2088960 1951430655 1949341696
Disk /dev/sdb - 1000 GB / 931 GiB - CHS 121601 255 63
Partition Start End Size in sectors
MS Data 2088960 1951430655 1949341696 [Linux/Windows data]
superblock 0, blocksize=4096 []
superblock 32768, blocksize=4096 []
superblock 98304, blocksize=4096 []
superblock 163840, blocksize=4096 []
superblock 229376, blocksize=4096 []
superblock 294912, blocksize=4096 []
superblock 819200, blocksize=4096 []
superblock 884736, blocksize=4096 []
superblock 1605632, blocksize=4096 []
superblock 2654208, blocksize=4096 []
To repair the filesystem using alternate superblock, run
fsck.ext4 -nv -b 32768 -B 4096 /dev/sdb
Code: Select all
dd if=/dev/sdb of=/mnt/HD/HD_a2/dns/desc-table-b-512-1 bs=512 skip=2088968 count=240
ok!
dd if=/dev/sdb of=/mnt/HD/HD_a2/dns/desc-table-b-512 bs=512 skip=2089208 count=8
error!
dd if=/dev/sdb of=/mnt/HD/HD_a2/dns/desc-table-b-512-2 bs=512 skip=2089216 count=217
ok!
total: 240 + 8 + 217 = 465 blocks or 465*8 = 3720 block group descriptors. farther - zeros.
- cgrenier
- Site Admin
- Posts: 5432
- Joined: 18 Feb 2012, 15:08
- Location: Le Perreux Sur Marne, France
- Contact:
Re: What if Block Group Descriptors Table are corrupt?
Can you run fsck on the partition instead of the whole disk ?
Re: What if Block Group Descriptors Table are corrupt?
I'm sorry for my misunderstanding.
How can I point this partition in fsck command?
/dev/sdb1 ?
I tried to run fdisk. It pointed me, that my disk has GPT partition. Does it mean?
How can I point this partition in fsck command?
/dev/sdb1 ?
I tried to run fdisk. It pointed me, that my disk has GPT partition. Does it mean?
Re: What if Block Group Descriptors Table are corrupt?
here it goes
GPT
and, for whole disk
I've read about "mke2fs -S", but it seems little scary...
If descriptor table has unreadable sector, does this command help?
Code: Select all
fdisk -l /dev/sdb2
Disk /dev/sdb2: 998.1 GB, 998062948352 bytes
255 heads, 63 sectors/track, 121340 cylinders, total 1949341696 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 /dev/sdb2 doesn't contain a valid partition table
Code: Select all
gdisk -l /dev/sdb2
GPT fdisk (gdisk) version 0.6.13
Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present
Creating new GPT entries.
Disk /dev/sdb2: 1949341696 sectors, 929.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): F68F34F9-3B77-4549-93E1-44AE8560E306
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1949341662
Partitions will be aligned on 2048-sector boundaries
Total free space is 1949341629 sectors (929.5 GiB)
Number Start (sector) End (sector) Size Code Name
Code: Select all
gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.6.13
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 41612D9F-0977-4692-A48D-9EA794381F79
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2099101 sectors (1.0 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 1062271 517.7 MiB 8200 Linux swap
2 2088960 1951430655 929.5 GiB 0700 Linux/Windows data
4 1062912 2086991 500.0 MiB 0700 Linux/Windows data
If descriptor table has unreadable sector, does this command help?
- cgrenier
- Site Admin
- Posts: 5432
- Joined: 18 Feb 2012, 15:08
- Location: Le Perreux Sur Marne, France
- Contact:
Re: What if Block Group Descriptors Table are corrupt?
Try fsck /dev/sdb2 and fsck /dev/sdb4
Re: What if Block Group Descriptors Table are corrupt?
I'm sorry for delay.
Here is out from fsck
for sdb2:
and for sdb4:
Now '/dev/sb4' is mounted as 'HD_b4' and all its files in place.
But thing is, that I need files from '/dev/sb2'.
Here is out from fsck
for sdb2:
Code: Select all
# fsck /dev/sdb2 -y
fsck from util-linux 2.20
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext3: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb2
Could this be a zero-length partition?
Code: Select all
# fsck /dev/sdb4 -y
fsck from util-linux 2.20
e2fsck 1.41.14 (22-Dec-2010)
Error reading block 246017 (Attempt to read block from filesystem resulted in short read). Ignore error? yes
Force rewrite? yes
Superblock has an invalid journal (inode 8).
Clear? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Superblock has_journal flag is clear, but a journal inode is present.
Clear? yes
/dev/sdb4 was not cleanly unmounted, check forced.
Error writing block 246017 (Attempt to write block from filesystem resulted in short write). Ignore error? yes
Pass 1: Checking inodes, blocks, and sizes
Journal inode is not in use, but contains data. Clear? yes
Error reading block 246016 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error? yes
Force rewrite? yes
Error writing block 246016 (Attempt to write block from filesystem resulted in short write) while getting next inode from scan. Ignore error? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create? yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(246017--253952) -(254209--254497)
Fix? yes
Free blocks count wrong for group #30 (0, counted=7936).
Fix? yes
Free blocks count wrong for group #31 (7647, counted=7936).
Fix? yes
Free blocks count wrong (480561, counted=488786).
Fix? yes
Recreate journal? yes
Creating journal (8192 blocks): Error writing block 246017 (Attempt to write block from filesystem resulted in short write). Ignore error? yes
Error writing block 246018 (Attempt to write block from filesystem resulted in short write). Ignore error? yes
Error writing block 246019 (Attempt to write block from filesystem resulted in short write). Ignore error? yes
Done.
*** journal has been re-created - filesystem is now ext3 again ***
/dev/sdb4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb4: 781/128016 files (0.6% non-contiguous), 31479/512040 blocks
But thing is, that I need files from '/dev/sb2'.
Re: What if Block Group Descriptors Table are corrupt?
A couple minutes ago I've started fsck with alternate superblock.
Waiting for results...
Waiting for results...
Code: Select all
# fsck.ext4 /dev/sdb2 -y -f -b 32768
e2fsck 1.41.14 (22-Dec-2010)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sdb2: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Error reading block 1034 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error? yes
Force rewrite? yes