Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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 did file-s /dev/sdc1 and dev/sdc2, it show it as only "data"
file -s /dev/sdc1
/dev/sdc1: data
file -s /dev/sdc2
/dev/sdc2: data
then I ran fsck on it
Code:
fsck -y -f /dev/sdc1
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext2: Superblock invalid, trying backup blocks...
Adding dirhash hint to filesystem.
Pass 1: Checking inodes, blocks, and sizes
Inode 2, i_blocks is 8, should be 6. Fix? yes
Inode 12, i_blocks is 162, should be 160. Fix? yes
Inode 4084, i_blocks is 2, should be 0. Fix? yes
Inode 4081, i_blocks is 4, should be 2. Fix? yes
Inode 4085, i_blocks is 4, should be 2. Fix? yes
Inode 4086, i_blocks is 4, should be 2. Fix? yes
Inode 4088, i_blocks is 18, should be 16. Fix? yes
Inode 4089, i_blocks is 18, should be 16. Fix? yes
Inode 4090, i_blocks is 16, should be 14. Fix? yes
Inode 4091, i_blocks is 16, should be 14. Fix? yes
Inode 4092, i_blocks is 18, should be 16. Fix? yes
Inode 4093, i_blocks is 16, should be 14. Fix? yes
Inode 4094, i_blocks is 22, should be 20. Fix? yes
Inode 4095, i_blocks is 16, should be 14. Fix? yes
Inode 4096, i_blocks is 16, should be 14. Fix? yes
Inode 4097, i_blocks is 20, should be 18. Fix? yes
Inode 4082, i_blocks is 114, should be 112. Fix? yes
Inode 4087, i_blocks is 210, should be 208. Fix? yes
Pass 2: Checking directory structure
i_file_acl for inode 2 (/) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4081 (/grub) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4082 (/grub/splash.xpm.gz) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4084 (/grub/menu.lst) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4085 (/grub/device.map) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4086 (/grub/stage1) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4087 (/grub/stage2) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4088 (/grub/e2fs_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4089 (/grub/fat_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4090 (/grub/ffs_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4091 (/grub/iso9660_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4092 (/grub/jfs_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4093 (/grub/minix_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4094 (/grub/reiserfs_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4095 (/grub/ufs2_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4096 (/grub/vstafs_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 4097 (/grub/xfs_stage1_5) is 4644, should be zero.
Clear? yes
i_file_acl for inode 12 (/message) is 4644, should be zero.
Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -4644
Fix? yes
Free blocks count wrong for group #0 (3549, counted=1).
Fix? yes
Free blocks count wrong for group #1 (7677, counted=7140).
Fix? yes
Free blocks count wrong for group #2 (7935, counted=7690).
Fix? yes
Free blocks count wrong for group #3 (7677, counted=2048).
Fix? yes
Free blocks count wrong for group #4 (7935, counted=0).
Fix? yes
Free blocks count wrong for group #5 (7677, counted=4844).
Fix? yes
Free blocks count wrong for group #6 (7935, counted=0).
Fix? yes
Free blocks count wrong for group #7 (7677, counted=4052).
Fix? yes
Free blocks count wrong (96790, counted=64503).
Fix? yes
Free inodes count wrong for group #0 (2029, counted=2021).
Fix? yes
Free inodes count wrong for group #2 (2040, counted=2023).
Fix? yes
Directories count wrong for group #2 (0, counted=1).
Fix? yes
Free inodes count wrong for group #3 (2040, counted=2021).
Fix? yes
Free inodes count wrong for group #5 (2040, counted=2036).
Fix? yes
Free inodes count wrong (26509, counted=26461).
Fix? yes
/boot: ***** FILE SYSTEM WAS MODIFIED *****
/boot: 59/26520 files (25.4% non-contiguous), 41305/105808 blocks
and now it shows
file -s /dev/sdc1
/dev/sdc1: Linux rev 1.0 ext3 filesystem data
but /dev/sdc2 still show any filesystem
Code:
# fsck -y -f /dev/sdc2
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdc2
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>
[root@vpnusa ~]# file -s /dev/sdc2
/dev/sdc2: data
[root@vpnusa ~]
havent tried anything else , wanted to get input first.
I trust that the "of=/dev/sdb" vs. subsequent examination of "/dev/sdc" is due to the drives being rearranged between those events.
I would have liked to see what the start of partition 1 looked like before fsck made changes, some of which were not the sort of errors one would expect to find on an image made while a filesystem was mounted. That repeated sector in the hex dump is also troubling. But, let's see what testdisk can find now. Again, it would probably be best to turn off the "Align partition" option.
At least that's consistent with your 60GB image on an 80GB disk. Those NTFS boot sectors that were found in cylinders 9724 and 9725 are just leftover junk at the end of the 80GB disk, well beyond the 60GB that was restored.
But, is that all that testdisk found? Did it not even report the current partitioning? Is sdc1 still in its post-fsck fixed-up state, or did you perhaps run the restore again? If the corrected superblock is there, I do not understand why testdisk did not see it. Did you go into the "Options" menu and turn off the "Align partitions" option?
It is really frustrating having to guess at what might have gone on to result in a given report. It is very unusual for testdisk not to pick up remnants of something, even if those detections turn out to be false hits. Even if the LVM header is totally destroyed, there should still be filesystems in there, and testdisk should still find those headers even if the rest of the filesystem is fragmented in the LVM structure.
go into the "Options" menu and turn off the "Align partitions" option?
No I did not, I will do as you suggest and then report again.Also, this is after post fsck, I did not run it again, after I ran it once, (dev/sd1)the disk was able to be mounted./dev/sdc2 is the issue.
Sorry if I asked this already, but I still dont understand why if its an LVM created partition, why is testdisk showing it as NTFS?
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
Current partition structure:
Partition Start End Size in sectors
1 * Linux 0 1 1 13 44 63 211617 [/boot]
Bad sector count.
No LVM or LVM2 structure
2 P Linux LVM 13 45 1 7295 254 63 116998560
2 P Linux LVM 13 45 1 7295 254 63 116998560
Bad relative sector.
Then it does a search and then cant find anything
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
The harddisk (80 GB / 74 GiB) seems too small! (< 119 GB / 111 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection...
The following partition can't be recovered:
Partition Start End Size in sectors
> HPFS - NTFS 9724 254 63 14587 254 62 78124095
[ Continue ]
NTFS, blocksize=4096, 39 GB / 37 GiB
Then I am brought to this screen after clicking continue for it to do a deeper search
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
Partition Start End Size in sectors
>* Linux 0 1 1 13 44 62 211616 [/boot]
Linux 20 68 49 6914 127 61 110755840
HPFS - NTFS 4862 0 1 9724 254 63 78124095
Linux 7836 1 1 7836 66 1 4096
Linux LVM 9142 1 1 9534 254 63 6313482
P FAT12 9725 0 1 9725 254 63 16065 [DOSBOOT]
Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
Enter: to continue
ext3 blocksize=1024 Sparse superblock, 108 MB / 103 MiB
I selected the NTFS partition and it searched and found nothing.So I go to this screen
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
The harddisk (80 GB / 74 GiB) seems too small! (< 143 GB / 133 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection...
The following partitions can't be recovered:
Partition Start End Size in sectors
> HPFS - NTFS 9724 254 63 14587 254 62 78124095
HPFS - NTFS 9725 254 63 17489 254 62 124728660
then I go back here
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
Partition Start End Size in sectors
> Linux 0 1 1 13 44 62 211616 [/boot]
HPFS - NTFS 13 0 1 7295 254 63 117001395
Linux 20 68 49 6914 127 61 110755840
Linux 22 143 58 6916 203 7 110755840
Linux 28 206 51 6923 10 63 110755840
HPFS - NTFS 1962 0 1 9725 254 63 124728660
HPFS - NTFS 4862 0 1 9724 254 63 78124095
Linux 7836 1 1 7836 66 1 4096
Linux LVM 9142 1 1 9534 254 63 6313482
FAT12 9725 0 1 9725 254 63 16065 [DOSBOOT]
Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
Enter: to continue
ext3 blocksize=1024 Sparse superblock, 108 MB / 103 MiB
I still dont understand why if its an LVM created partition, why is testdisk showing it as NTFS?
testdisk is just reading through the drive sector by sector looking for anything that might be the start of some data structure that it understands. When it sees a sector that it can identify as an NTFS boot sector, it will report a possible NTFS partition starting at that location. If you took the beginning of an NTFS partition and copied those blocks into a file in a Linux filesystem, testdisk would dutifully report that those blocks might be the start of an NTFS partition.
Quote:
Originally Posted by cbtshare
Then I am brought to this screen after clicking continue for it to do a deeper search
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
Partition Start End Size in sectors
>* Linux 0 1 1 13 44 62 211616 [/boot]
Linux 20 68 49 6914 127 61 110755840
HPFS - NTFS 4862 0 1 9724 254 63 78124095
Linux 7836 1 1 7836 66 1 4096
Linux LVM 9142 1 1 9534 254 63 6313482
P FAT12 9725 0 1 9725 254 63 16065 [DOSBOOT]
Something here makes absolutely no sense. What are the chances that a 60GB disk would have an NTFS boot sector located at exactly the right spot such that the 40GB filesystem it defines would extend right to the end of an 80GB disk? Is that really what is in that 60GB image file? Also, a previous run of testdisk found the corresponding NTFS backup header in its expected location at the end of the 80GB disk. This is starting to look like at least part of the 80GB disk got copied to the image file instead of the other way around.
Note: You can disregard the last 3 entries in that list. The 60GB image (60011642880 bytes) extends only to CHS 7295 255 63. Anything beyond that is just whatever was on the 80GB disk before you copied the image to it.
Try this: Run testdisk on the image file itself. I strongly suggest running testdisk as a non-privileged user who has read-only access to the file. In testdisk, the partition table type will default to "None", and you should leave it that way.
BTW, you realize that you are running a Beta version of testdisk, right? ("WIP" = "Work In Progress"). Version 7.0 is identified as "Beta" on the testdisk download site.
Ok,thank you.... Can you please give a example how youd want me to run testdisk on the backup img.? i am guessing the instruction about the partition type is for when running against the backup img file ,because on the hard disk i always chose 'intel'.
Can you please give a example how youd want me to run testdisk on the backup img.? i am guessing the instruction about the partition type is for when running against the backup img file
From a text command window, just run testdisk with the file name as an argument. You just need read permission on the file and don't have to have root privileges:
Code:
testdisk /path/to/backup_set_1.img
Yes, leaving the partition table type as "None" is for use with the image file. Actually, you can set it to "None" when using testdisk on a whole disk as well. That setting would just keep testdisk from trying to parse any existing partition table. It also blocks testdisk from trying to write a new partition table.
TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
TestDisk is free software, and
comes with ABSOLUTELY NO WARRANTY.
Select a media (use Arrow keys, then press Enter):
>Disk /media/New Volume/backup_set_1.img - 60 GB / 55 GiB
>[Proceed ] [ Quit ]
Code:
TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /media/New Volume/backup_set_1.img - 60 GB / 55 GiB - CHS 7296 255 63
Partition Start End Size in sectors
>P ext3 0 20 6 13 64 4 211616 [/boot]
P NTFS 13 0 1 7295 254 63 117001395
P ext3 16 205 22 6911 9 34 110755840
Structure: Ok.
TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /media/New Volume/backup_set_1.img - 60 GB / 55 GiB - CHS 7296 255 63
Partition Start End Size in sectors
>P ext3 0 20 6 13 64 4 211616 [/boot]
P NTFS 13 0 1 7295 254 63 117001395
P ext3 16 205 22 6911 9 34 110755840
Is that the result from the "Deeper Search"? I find it strange and disturbing that testdisk is finding that same NTFS header but at a different location than where it shows up on the 80GB disk. In fact, none of the entries match what was found on the disk despite reporting the same 255 head 63 sector geometry for both. Frankly, I'm no fan of testdisk, with its horrible UI and frequently incomprehensible behavior. I just don't know of any other tool that comes close to doing the same job.
Is this backup_set_1.img file still in the original location where you created it (i.e., this is not a copy of the original)? If so, what is the output from "ls -l backup_set_1.img"? Does the timestamp agree with when you originally created it?
Frankly, I'm somewhat at a loss for ways to proceed in the face of these inconsistent results. I suppose my next step would be to run hexedit (another program with a UI that caters only to those who use it regularly) and try to find the blocks containing the files that were in /etc/lvm/backups, then give that data to vgcfgrestore to try to rebuild the LVM structure. If you want to try that, the string I would search for is
Code:
description = "Created *after* executing
which, in the hex digits that hexedit needs, would be
Do you have parted? .. If you have parted installed, could you please run it on the image.. The ideea after this is to try and mount a partition from your image..
@Smokey_justme: You'll find quite a bit of that work back in the original thread. If you can spot something that was overlooked there, I'm sure your efforts will be appreciated.
Ahh, did not saw that.. I was quite wondering how none of you think of this earlier.. I'll take a look and if I see something or have some ideea, I'll get back to you.. Sorry for the interruption...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
I'll take a look and if I see something or have some ideea, I'll get back to you.. Sorry for the interruption...
