Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
When I inserted a 1 TB-drive into my new Qnap NAS, it removed my partition on that drive without notifying me first. The partition was replaced with two small partitions and a swap:
Code:
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000934a8
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 66 530113+ 83 Linux
/dev/sdb2 67 132 530145 82 Linux swap / Solaris
/dev/sdb3 133 121538 975193695 83 Linux
/dev/sdb4 121539 121600 498015 83 Linux
The damaged partition is /dev/sdb3.
I'm trying to locate a backup super block on that partition so that I can restore the data, but all default backup superblock locations given by mke2fs didn't work:
Code:
michaeka@trillian:~$ sudo mke2fs -t ext2 -n /dev/sdb3
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
60956672 inodes, 243798423 blocks
12189921 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7441 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, 71663616, 78675968,
102400000, 214990848
The error I get when attempting to restore with these block locations is:
Code:
e2fsck 1.41.9 (22-Aug-2009)
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdb3
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>
Is there a way to retrieve the actual locations of the backup superblocks, or any other ways to guess their locations?
Are you implying that originally the drive had just one partition - that presumably started at cylinder 1 ?.
What you're attempting will only be valid if your original partition started at precisely cylinder 133. Not very likely, but possible.
Try using testdisk to scan the drive for deleted partitions.
Are you implying that originally the drive had just one partition - that presumably started at cylinder 1 ?.
What you're attempting will only be valid if your original partition started at precisely cylinder 133. Not very likely, but possible.
Try using testdisk to scan the drive for deleted partitions.
Yes, it contained only one partition that covered the entire disk. Do you mean that I should take the backup superblock location minus 133 to find the actual location?
I've tried using testdisk, but the tutorials didn't apply well to my case, so I fell off. I'll try a deep search again after making a backup image of the partition.
Ugh - better hope those partitions haven't had mkfs or mkswap run against (any of) them.
If it was simply a matter of your partition being deleted and those added - without any of them being formatted, simply delete all those partitions and redefine your big one. Then try the mke2fs -n, followed by mke2fs for real.
If any of those new partitions have been formatted - especially sdb1, then you've probably lost the needed metadata for your original filesystem.
Ugh - better hope those partitions haven't had mkfs or mkswap run against (any of) them.
If it was simply a matter of your partition being deleted and those added - without any of them being formatted, simply delete all those partitions and redefine your big one. Then try the mke2fs -n, followed by mke2fs for real.
So I can delete the new partitions and resize my old one to cover the whole disk. How do I redefine it? With gparted resize tool?
Quote:
Originally Posted by syg00
If any of those new partitions have been formatted - especially sdb1, then you've probably lost the needed metadata for your original filesystem.
The new partitions show up as ext3, so I guess they have to be formatted. The rest of the overwritten partition shows up as Unknown. So this means it is useless to recover its superblock?
Just delete and re-define from fdisk. Won't help if they've been formatted - if you run an fsck after that it'll work, but for the smaller size of that sdb1 filesystem, not the (newer) partition that would actually cover the whole disk.
Best bet might be to see if photorec can find your data - from the same people as testdisk (does more than just photos).
Don't use gparted - it will resize the filesystem as well, and obliterate even more of the underlying data.
Just delete and re-define from fdisk. Won't help if they've been formatted - if you run an fsck after that it'll work, but for the smaller size of that sdb1 filesystem, not the (newer) partition that would actually cover the whole disk.
I haven't done this before. Could you tell me the details of how you redefine with fdisk?
Quote:
Originally Posted by syg00
Best bet might be to see if photorec can find your data - from the same people as testdisk (does more than just photos).
I used photorec too. But I don't really know what to do with the recovered data. It was mostly music and movies on that disk, and all of it is just nameless bits and pieces of the original files.
Basically straight-forward - as root get into fdisk, and use the "m" command as it suggests to get a list of all the commands.
- "p" to printout the current partitions
- "d" to delete each in turn
- then "n" for a new partition - take the defaults for start and end cylinder; will give you the entire disk again.
- "w" to write the changes to disk.
- "q" to quit.
You may need to reboot to get the updates recognised - maybe not.
As I said, I suspect you'll find just the filesystem from the smaller sdb1, but no harm in trying.
Hmm, something happened. The file system was successfully modified by fdisk, and I then tried to search for superblocks at the backup location:
Quote:
michaeka@trillian:~$ sudo mke2fs -t ext3 -n /dev/sdb1
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
61054976 inodes, 244190000 blocks
12209500 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7453 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, 71663616, 78675968,
102400000, 214990848
This was the output of the attempt to use the first backup:
Quote:
michaeka@trillian:~$ sudo e2fsck -b 32768 /dev/sdb1
e2fsck 1.41.9 (22-Aug-2009)
/dev/sdb1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (32311, counted=23830).
Fix<y>? yes
Free blocks count wrong for group #1 (32317, counted=32183).
Fix<y>? yes
Free blocks count wrong for group #2 (28250, counted=28244).
Fix<y>? yes
Free blocks count wrong for group #3 (32317, counted=32300).
Fix<y>? yes
/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 150/33200 files (0.0% non-contiguous), 14932/132512 blocks
The output says something about 33200 files, which looks like a number that could be from my deleted partition. Tried to mount using that superblock, and got:
Quote:
michaeka@trillian:~$ sudo mount /dev/sdb1 /home/michaeka/underholdning/ -t ext3 -o sb=32768
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
I tried to run sudo e2fsck -y -f -v /dev/sdb1, which seemed to fix a bunch of things on the drive. The statistics at the end says:
Code:
/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
75585 inodes used (0.12%)
13057 non-contiguous files (17.3%)
53 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 53624/26784/5989
199118210 blocks used (81.54%)
0 bad blocks
37 large files
71715 regular files
3358 directories
129 character device files
161 block device files
101 fifos
4294967197 links
13 symbolic links (0 fast symbolic links)
98 sockets
--------
74980 files
When I try to mount the fixed file system with "sudo mount /dev/sdb1 /home/michaeka/underholdning/ -t ext2", I only see the lost+found folder. But the free space is only 125.4 GB, which is similar to the free space my old partition had.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.