3

My hard drive got corrupted at some point after mounting an mtpfs system. I would ask how to fix that, but I'm not confident about the partition and file system types.

My OS is new Fedora Core 23, but the partition was originally created under FC 20, likely as whatever it defaults to. 

cat /proc/version
Linux version 4.2.3-300.fc23.x86_64            
[email protected]) 
(gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) 
(GCC) ) #1 SMP Mon Oct 5 15:42:54 UTC 2015

The fdisk program reports the following partitions as below. As one might imagine, I'm most interested in /dev/sdb3, but that's the most corrupted. I'm not sure why /dev/sdb2 reports "Microsoft basic data", but at least it can be mounted and read, whereas the /dev/sdb3 partition cannot be mounted.

sudo fdisk /dev/sdb
Welcome to fdisk (util-linux 2.27).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 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
Disklabel type: gpt
Disk identifier: 59CA4127-4BEE-40F4-A514-9DA368C81665

Device       Start        End    Sectors   Size Type
/dev/sdb1     2048     411647     409600   200M EFI System
/dev/sdb2   411648    1435647    1024000   500M Microsoft basic data
/dev/sdb3  1435648 1953523711 1952088064 930.8G Linux filesystem

sudo mount /dev/sdb3 /mnt/sdb3
mount: /dev/sdb3 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/sdb3,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.

I didn't see anything related to mounting, partitions or related in dmesg or the systemd log via journalctl.

Apparently, the superblock couldn't be found:

sudo dumpe2fs /dev/sdb3
dumpe2fs 1.42.13 (17-May-2015)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb3
Couldn't find valid filesystem superblock.

My questions are: What filesystem is /mnt/sdb3 really? How could I find out (is there a magic number or eyecatcher I could locate and dump somewhere)?

Once I know this, I could probably change the partition type accordingly. The TestDisk utility would be more helpful if I could only know what the filesystem is, such as a dos partition scheme with /dev/sdb3 being ext4 for example.

Update: I think I encrypted it back when I set it up. I viewed the /dev/sdb3 partition in a hex editor and also piped a good portion of it through strings and didn't recognize anything. There's a bunch of what looks like repeating patterns. Also, my old grub.cfg has these lines:

linuxefi /vmlinuz-3.19.8-100.fc20.x86_64 root=/dev/mapper/fedora_ralph-root ro rd.lvm.lv=fedora_ralphdfl/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora_ralphdfl/root rd.luks.uuid=luks-a0d2613e-ce2a-4a6b-96cf-b999b3a36ab8  rhgb quiet LANG=en_US.UTF-8

Unfortuantely, it's not being recognized as an encrypted drive: cryptsetup -v luksDump /dev/sdb3 Device /dev/sdb3 is not a valid LUKS device. Command failed with code 22: Invalid argument

Getting the old passphrase is doable though. At this point, would I be better off taking it to a data recovery company? I can take a loss of much of it, but there's a few key files I'd really like to get back.

Thank you in advance.

2
  • This article talks about finding and using the copies of superblocks. cyberciti.biz/tips/surviving-a-linux-filesystem-failures.html 4am here, so you will excuse me into not writing a more lengthy reply.
    – Rui F Ribeiro
    Dec 1, 2015 at 4:32
  • You can use file command as well: # file -Ls /dev/system_vg/tmp_lv /dev/system_vg/tmp_lv: Linux rev 1.0 ext4 filesystem data (needs journal recovery) (extents) (large files) (huge files)
    – Alberto
    Dec 1, 2015 at 7:50

3 Answers 3

Reset to default
2

If the first sector of the filesystem is undamaged, start with the file command. Pass the -s option so that it looks at the device content instead of just saying “it's a device”.

file -s /dev/sdb3

The database used by file isn't the same as the database used by the kernel when mounting, so it can happen that file doesn't recognize a filesystem that the kernel does or vice versa, but in common situations file should recognize what the kernel supports.

If that doesn't help because it's an exotic filesystem or volume type that file doesn't recognize, try head -c 1024k /dev/sdb3 | strings | less and see if that yields a clue.

If you can't figure it out, try forensic tools such as TestDisk. You don't need to know the type of filesystem to run: you can use it to explore the damaged disk, that's kind of the point. If you suspect that the partition table is damaged, TestDisk can try to guess it too.

3
  • Sadly, more mining needs to be done. file -s returns "data" and I didn't see anything obvious from the first 1024k of /dev/sdb3 string-wise. TestDisk scanned it, but can't find anything usable.
    – Id Rathernotsay
    Dec 3, 2015 at 2:01
  • @IdRathernotsay Are you sure that the partition table is undamaged? There's almost always something recognizable at the start of a partition, but not in the middle, so if the location of the partition start is wrong, you're unlikely to find anything interesting there. AFAIR TestDisk includes tools to look for likely partition starts.
    – Gilles 'SO- stop being evil'
    Dec 3, 2015 at 10:15
  • I'm not fully certain, but I'd be surprised. Also, I believe it may have been an encrypted partition.
    – Id Rathernotsay
    Dec 5, 2015 at 4:12
1

By default, Fedora Installer creates LVM group, called like "fedora" or else. Try:

# lvdisplay

or 

# ls /dev/mapper/

Ones, you have lvm, you can't mount partition directly

2
  • lvdisplay returns nothing and ls /dev/mapper returns control
    – Id Rathernotsay
    Dec 3, 2015 at 1:58
  • you have no lvm
    – shcherbak
    Dec 7, 2015 at 9:37
0

"fsck" maybe helpful. for example:

[root@master dtb]# fsck /dev/sdb1
fsck，come from  util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sdb1: clean, 11/2560 files, 1445/10240 blocks
[root@master dtb]# fsck /dev/sdb5
fsck，come from  util-linux 2.20.1
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).

It would show you which filesystem family the hard driver are using.

1
  • "e2fsck" means ext2,ext3 or ext4 filesystem. You could use that command line tool to fix the filesystem.
    – Zhengyuan Liu
    Dec 1, 2015 at 6:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .