error trying to use ddru_ntfsbad with Basic data partition
LINUX based utility for use with gnuddrescue to aid with data recovery
Brought to you by:
maximus57
Menu
▾
▴
Hi
I tried to run
ddru_ntfsfindbad -i 659554304 /dev/sda mapfile
ddru_ntfsfindbad 1.5 20150109
Reading the logfile into memory...
Reading partition boot sector...
ERROR! This program only allows for 8 sectors per MFT record, and this partition boot sector reports 1968
ERROR! Unable to correctly process the partition boot sector
based on
fdisk -lu /dev/sda
Disk /dev/sda: 1.82 TiB, 2000398933504 bytes, 3907029167 sectors
Disk model: BUP Ultra Touch
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: 8BB1F33B-CBFA-4A6D-AF91-B4EABE93FF50
Device Start End Sectors Size Type
/dev/sda1 2048 1026047 1024000 500M EFI System
/dev/sda2 1026048 1288191 262144 128M Microsoft reserved
/dev/sda3 1288192 1925378047 1924089856 917.5G Microsoft basic data
/dev/sda4 1925378048 1927122943 1744896 852M Windows recovery environment
/dev/sda5 1927122944 1953523711 26400768 12.6G Windows recovery environment
Not sure if someone could help me understand what I am doing wrong?
The mapfile I'm using looks like this
0xA39DA3FE00 + 3
pos size status
0x00000000 0xA39D7A8000 +
0xA39D7A8000 0x00001000 -
0xA39D7A9000 0x0014A000 +
0xA39D8F3000 0x00001000 -
0xA39D8F4000 0x0014B000 +
0xA39DA3F000 0x00001000 -
0xA39DA40000 0x4543376000 +
Last edit: df 925 2021-12-28
Please provide the output from the following commands:
sudo fdisk -lu /dev/sda
sudo lsblk -f /dev/sda
sudo xxd -s 659554304 -l 512 /dev/sda
fdisk is to verify it is still the same disk from your post
lsblk should show the partition types and verify the targeted one is ntfs
xxd will provide a hex dump of the partition boot sector to verify that it is a valid ntfs boot sector
The error indicates it is not a valid ntfs boot sector.
Hi Maximus,
Thank you so much for helping, I super appreciate it.
sudo fdisk -lu /dev/sda
sudo lsblk -f /dev/sda
sudo xxd -s 659554304 -l 512 /dev/sda
I think I can see what is happening, but it shouldn't happen. A signed
character with a value of 0xF6 is being considered positive when it
should be considered a negative value by the system. It would seem your
system is defaulting to an unsigned character.
What OS are you using, and what is your computer architecture? I am
curious about the system and why it is like this. Can you run the
following command and provide me the dmesg.txt file?
dmesg > dmesg.txt
In the source file "makefile" you can make a change to hopefully fix
this. Line 5 reads as follows:
CFLAGS = -Wall -WChange it to:
CFLAGS = -Wall -W -fsigned-charThe run the following commands from within the source folder to remake
the program and reinstall it:
make clean
make
sudo make install
Regards,
Scott
The original hdd is from a dell xps.
I used gddrescue from systemrescue to clone it to a USB drive on the same machine.
Then I used a Raspberry PI 3 with Rasbian to run ddrutility on that same USB.
Attached is the dmesg from the Rasberry PI to run ddrutility.
I used apt install to get ddrutility, so I'll need to figure out how to run a make, or maybe do it on another OS?
Thanks again!
DF
To branch this discussion, is there anyway to use the MFT and the mapfile to do the same? That way I wouldn't have to connect the USB to anything?
Thx
DF
How did you install ddrutility on Rasbian in the first place? If you followed the standard instructions, you already ran make during the installation process. You need to do that again but with a modified makefile edited as described.
I do not know of any way to do anything with just the MFT and mapfile, even though that is all that is required. Your only options are try to to recompile ddrutility with the modified makefile, or use something other than a Raspberry Pi that does not have an ARM processor. If there are not too many errors, you could try to run the regular ddru_findbad, but it requires other dependencies to be installed, plus it is real slow.
again greatly appreciate the insight.
On Rasbian, I just used apt install ddrutility. I'll play around with the makefile today and hopefully that will be it.
excellent tool, and appreciate the work you put into it!
Not too many errors, only 3 errors 4k in size, but last time I ran ddru_findbad on the same raspberry pi, it locked up, so I gave up.
With so few errors you could look into using ntfscluster to find what if any files are in those sectors. Here is a link for how to do that. FYI your cluster size is 4096. Ntfscluster also has a sector option which would then use 512 for a dividing number.
https://radagast.ca/linux/how-to-find-the-ntfs-filename-associated-with-a-bad-block-using-linux.html
https://www.unix.com/man-page/linux/8/ntfscluster/
Just for anyone that tries this on RPI3 and Raspian:
Its a 1TB partition, and my RPI3 only has 1GB RAM. I bumped Raspbian to 2G swap, but it appears to still run out of memory running ntfscluster.
With the larger memory I'm trying to run ddru_findbad /dev/sda mapfile -Q
this worked, however yielded one line that strikes me as odd
results_summary.txt shows :
0 sectors were in partitions that were able to be processed
I'm hoping that just means that there were no files, but not sure if it actually means it wasn't able look at the partition.
however results_info.txt
So close, but I'm hoping that the bad sectors didnt have files on them
thx
DF
Last edit: df 925 2022-01-02
Hi
just wanted to close this out.
I was able to use an old Dell E6420 laptop, and use Ubuntu 18.04 trial, and install ddrutility.
ddru_ntfsfindbad /dev/sdc mapfile reported an error about unknown partition, but I think thats because I did not use the -i option to specify the correct partition.
I was able to use ddru_findbad /dev/sdc mapfile and that was successful
Scott, so thankful for your excellent tool and your help
Best,
DF