| View previous topic :: View next topic |
| Author |
Message |
ReEkd
n00b
Joined: 23 Aug 2014
Posts: 12
|
 Posted: Sat Aug 23, 2014 3:32 pm Post subject: [SOLVED] can't mount partition |
 |
|
Hi;-)
I have a couple months old HDD, today I had to unplug it to get to another disk and after couple of hours later (it was plugged back in ofc)
I wanted to copy new backup to one of the partitions (ext4) on it...
| Quote: | # mount /dev/sdb8 /mnt/backup/
mount: wrong fs type, bad option, bad superblock on /dev/sdb8,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
|
It worked fine this morning but now I can't mount it:
dmesg output:
| Quote: | | EXT4-fs (sdb8): bad geometry: block count 36647426 exceeds size of device (36647162 blocks) |
fsck:
| Quote: | # fsck.ext4 /dev/sdb8
e2fsck 1.41.12 (17-May-2010)
The filesystem size (according to the superblock) is 36647426 blocks
The physical size of the device is 36647162 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes
|
In cfdisk I noticed a tiny bit of free space, which origin I don't recall but might have been there the whole time... ;__;
| Quote: | sdb8 NC Logical ext4 150106.78 *
Logical Free Space 1.09 *
|
parted output:
| Quote: |
Disk /dev/sdb: 976773168s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number Start End Size Type File system Flags
1 40s 33203127s 33203088s primary
2 33203128s 111328127s 78125000s primary
3 111328128s 156249999s 44921872s primary
4 156250000s 976771055s 820521056s extended lba
5 156250008s 156347655s 97648s logical
6 156347664s 449316407s 292968744s logical ext4
7 449316416s 683593751s 234277336s logical ntfs
8 683593760s 976771055s 293177296s logical ext4
|
I've read resize2fs manual (google pointed me into that direction), but since I wasn't making any changes to the partition,
never resized any and don't want to loose my backup files stored on that partition,
I'd like to ask for help, maybe someone else had a similar problem:-?
Last edited by ReEkd on Mon Aug 25, 2014 6:39 pm; edited 1 time in total |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54244
Location: 56N 3W
|
| Posted: Sat Aug 23, 2014 4:25 pm Post subject: |
|
|
ReEkd,
Welcome to Gentoo.
Lets see if its your superblock that corrupt. You have some backup superblocks, so lets try one
| Code: | | mount -o ro sb=131072 /dev/sdb8 /mnt/backup |
Thats your first backup superblock. Read man mount
The -o ro is important. You must not write to a filesystem that may be damaged.
fsck makes all sorts of assumptions and changes the filesystem if you let it. It often makes a bad situation worse.
Its usual to have some unallocated space at the end of the drive but it depends on the partitioning tool you used.
fdisk until recently, perpertrated the myth of cylinders, so you often had a part cylinder unallocated at the end of the drive.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ReEkd
n00b
Joined: 23 Aug 2014
Posts: 12
|
| Posted: Sat Aug 23, 2014 5:00 pm Post subject: |
|
|
| Code: | # mke2fs -n /dev/sdb8
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=1 blocks, Stripe width=0 blocks
9166848 inodes, 36647162 blocks
1832358 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
1119 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872 |
then tried every single of the presented blocks, like:
| Code: | | mount -o ro,sb=229376 /dev/sdb8 /mnt/backup/ |
the first, fourth block on that list (and few others after it) generated this in my dmesg:
| Code: | | EXT4-fs (sdb8): VFS: Can't find ext4 filesystem |
mount in all cases presented the same output:
| Code: | # mount -o ro,sb=2654208 /dev/sdb8 /mnt/backup/
mount: wrong fs type, bad option, bad superblock on /dev/sdb8,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so |
But with the added options without the "bad geometry" message in dmesg (like the one in my previous post, only block 131072 caused it to show up) :-s
EDIT:
the entire disk was partitioned using "parted -a minimal" |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54244
Location: 56N 3W
|
| Posted: Sat Aug 23, 2014 8:11 pm Post subject: |
|
|
ReEkd,
These blocks are filesystem blocks.Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
The mount sb= is in disk blocks. The two are not the same. mount can only know the filesystem block size by reading a superblock.
Disk blocks are 1k. On your filesystem | Code: | | Block size=4096 (log=2) |
There is a factor of 4 between thew so 32768 becomes sb=131072
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ReEkd
n00b
Joined: 23 Aug 2014
Posts: 12
|
| Posted: Sat Aug 23, 2014 8:53 pm Post subject: |
|
|
| NeddySeagoon wrote: |
Disk blocks are 1k. On your filesystem | Code: | | Block size=4096 (log=2) |
There is a factor of 4 between thew so 32768 becomes sb=131072 |
ohh, right, sorry:-'
So I tried again, and as for syslog:
the fifth (sb=1179648), sixth (sb=3276800), seventh (sb=3538944):
| Code: | | EXT4-fs (sdb8): bad geometry: block count 36647426 exceeds size of device (36647162 blocks) |
for all others there's nothing...
Does that help in any way, or maybe should I look for some kernel options to try make it more verbose? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54244
Location: 56N 3W
|
| Posted: Mon Aug 25, 2014 4:45 pm Post subject: |
|
|
ReEkd,
| ReEkd wrote: | | for all others there's nothing... |
Nothing is good. In Linux, it usually means that it worked.
You only get feedback if something went wrong.
Try one of the ones that gives no response and see if the filesystem mounted.
You should be able to read your files.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ReEkd
n00b
Joined: 23 Aug 2014
Posts: 12
|
| Posted: Mon Aug 25, 2014 5:14 pm Post subject: |
|
|
| NeddySeagoon wrote: |
Nothing is good. In Linux, it usually means that it worked.
You only get feedback if something went wrong.
|
What I meant by "for all others there's nothing..." was that there was no error popping to the console other than from the mount command:
| Code: |
# mount -o ro,sb=95551488 /dev/sdb8 /mnt/backup/
mount: wrong fs type, bad option, bad superblock on /dev/sdb8,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
|
and that since it didn't mount that maybe I could make it somehow more verbose to see why it didn't:-s
But now I just realized (by checking it again) by running dmesg after each mount attempt that
I was checking for error messages the wrong way, that I thought would work ;__;
I ran:
| Code: |
tail -f /var/log/kernmsg.log &
|
and then tried mount one superblock after another not realizing until now that not all messages were logged in /var/log/kernmsg.log...
For example at the moment kermsg.log looks like:
| Code: |
Aug 25 18:59:53 gentamd64 kernel: [ 2412.400724] EXT4-fs (sdb8): bad geometry: block count 36647426 exceeds size of device (36647162 blocks)
Aug 25 19:00:00 gentamd64 kernel: [ 2419.135891] EXT4-fs (sdb8): bad geometry: block count 36647426 exceeds size of device (36647162 blocks)
Aug 25 19:01:05 gentamd64 kernel: [ 2484.468360] EXT4-fs (sdb8): bad geometry: block count 36647426 exceeds size of device (36647162 blocks) |
while dmesg gives me:
| Code: |
[ 2412.400724] EXT4-fs (sdb8): bad geometry: block count 36647426 exceeds size of device (36647162 blocks)
[ 2419.135891] EXT4-fs (sdb8): bad geometry: block count 36647426 exceeds size of device (36647162 blocks)
[ 2425.343779] EXT4-fs (sdb8): bad geometry: block count 36647426 exceeds size of device (36647162 blocks)
[ 2484.468360] EXT4-fs (sdb8): bad geometry: block count 36647426 exceeds size of device (36647162 blocks) |
my bad for for relying on that log file... So after all I do get the same error in all of the cases ;__; |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54244
Location: 56N 3W
|
| Posted: Mon Aug 25, 2014 6:07 pm Post subject: |
|
|
ReEkd,
OK lets assume that your filesystem is good and your partition table is corrupt. We can test this theory quite safely with another variant of the mount command.
Parted tells us | Code: | Disk /dev/sdb: 976773168s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number Start End Size Type File system Flags
4 156250000s 976771055s 820521056s extended lba
8 683593760s 976771055s 293177296s logical ext4 |
Oops - I clicked the wrong button
Partition 8 ends at the end of the extended partition. That looks correct, so maybe the partition table is correct after all.
Anyway to the test. You can mount a filesystem without actually using the partition table ... but you need to know where it starts
So we know that sdb8 starts at sector 683593760 and we know that each sector is 512 bytes
Then 683593760 * 512 is the start in bytes. You need to work that sum out then try
| Code: | | mount -o ro offset=... /dev/sdb /some/mountpoint |
Put whatever 683593760 * 512 works out as in place of the ...
Read man mount to see what offset does.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ReEkd
n00b
Joined: 23 Aug 2014
Posts: 12
|
| Posted: Mon Aug 25, 2014 6:35 pm Post subject: |
|
|
| Code: | | mount -o ro,offset=350000005120 /dev/sdb /mnt/backup/ |
| Code: | | [ 7841.490455] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null) |
worked like a charm! It's mounted and data is accessible, thank you! :-)
Now I'm wondering is there any safe way to fix the partition, or is it better to copy the data elsewhere and reformat? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54244
Location: 56N 3W
|
| Posted: Mon Aug 25, 2014 9:45 pm Post subject: |
|
|
ReEkd,
Copy the data out and reformat the filesystem.
All we know is that the same parameters from two different places differ.
Maybe they are both wrong :)
That mount avoided the check.
Data at the end of the filesystem may be missing or corrupt.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ReEkd
n00b
Joined: 23 Aug 2014
Posts: 12
|
| Posted: Tue Aug 26, 2014 5:11 am Post subject: |
|
|
| ok; thanks again:-) |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
