Conversation with Gemini3
(kali㉿kali)-[~]
└─$ sudo fsck /dev/sdd
[sudo] password for kali:
fsck from util-linux 2.41.3
e2fsck 1.47.2 (1-Jan-2025)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdd
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
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>
or
e2fsck -b 32768 <device>
┌──(kali㉿kali)-[~]
Gemini said
Ouch. Seeing "Bad magic number" is usually a heart-sink moment, but it’s often just a case of the front door (the superblock) being jammed while the rest of the house is perfectly fine.
The superblock is a critical piece of metadata that tells the system where everything else is on the drive. If it's corrupted, Linux doesn't recognize the partition as a valid filesystem.
Step 1: Verify the Partition Name
Before you try to fix it, ensure /dev/sdd is actually the partition and not the whole drive. Usually, filesystems live on /dev/sdd1, /dev/sdd2, etc. If you run fsck on the raw disk (sdd) instead of the partition (sdd1), it will always return a "bad magic number" error.
Check your disk layout first:
lsblk
Step 2: Find the Backup Superblocks
Linux is smart enough to keep multiple copies of the superblock just in case the primary one dies. You need to find where those backups are located. Run this command:
sudo mke2fs -n /dev/sdd1
Note: The
-nflag is vital. It tells the system to "pretend" to format the drive, which displays where it would put the backup superblocks without actually touching your data.
Look for the section titled "Superblock backups stored on blocks:". You’ll see a list of numbers like 32768, 98304, 163840, etc.
Step 3: Restore from a Backup
Pick the first number from that list (e.g., 32768) and tell e2fsck to use it as the "source of truth":
sudo e2fsck -b 32768 /dev/sdd1
(Replace 32768 with the actual number from your output and sdd1 with your actual partition name).
If the first one fails, try the next number in the list.
Step 4: If the above doesn't work (The "Nuclear" Option)
If e2fsck still can't find a valid superblock, the partition table itself might be damaged. In this case, TestDisk is your best friend. It can scan the entire drive and "undelete" or repair partitions.
Install it:
sudo apt install testdiskRun it:
sudo testdiskSelect the drive, choose your partition type (usually
IntelorEFI GPT), and select Analyze.
A Quick Word of Caution
If this drive contains "once-in-a-lifetime" data, stop what you are doing. Every command you run on a failing drive carries a small risk. If you suspect hardware failure (clicking sounds, slow response), your best bet is to use ddrescue to clone the entire drive to an image file before trying to fix the filesystem.
Would you like me to walk you through the lsblk output to make sure we're targeting the right partition?
You said:
(kali㉿kali)-[~]
└─$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 2.7T 0 disk
├─sda1 8:1 0 512M 0 part /mnt/sdb1
├─sda2 8:2 0 2.7T 0 part /mnt/sdb2
└─sda3 8:3 0 977M 0 part
sdb 8:16 0 476.9G 0 disk
├─sdb1 8:17 0 512M 0 part
└─sdb2 8:18 0 475.5G 0 part /run/media/kali/8ff94f06-af00-45d7-8c5e-7cab38995640
sdc 8:32 0 465.8G 0 disk
├─sdc1 8:33 0 512M 0 part /boot/efi
├─sdc2 8:34 0 464.3G 0 part /
└─sdc3 8:35 0 976M 0 part
sdd 8:48 0 931.5G 0 disk
sde 8:64 0 2.7T 0 disk
├─sde1 8:65 0 260M 0 part
├─sde2 8:66 0 16M 0 part
├─sde3 8:67 0 147.4G 0 part /run/media/kali/Windows
├─sde4 8:68 0 136.7G 0 part /run/media/kali/New Volume
├─sde5 8:69 0 136.7G 0 part /run/media/kali/PHOTO
├─sde6 8:70 0 25G 0 part /run/media/kali/LENOVO
├─sde7 8:71 0 1000M 0 part
├─sde8 8:72 0 17.7G 0 part
├─sde9 8:73 0 1000M 0 part /run/media/kali/LRS_ESP
└─sde10 8:74 0 2.3T 0 part /run/media/kali/SGT
sdf 8:80 1 0B 0 disk
sdg 8:96 1 0B 0 disk
┌──(kali㉿kali)-[~]
└─$ sudo mke2fs -n /dev/sdd1
mke2fs 1.47.2 (1-Jan-2025)
The file /dev/sdd1 does not exist and no size was specified.
┌──(kali㉿kali)-[~]
└─$ sudo mke2fs -n /dev/sdd
mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 244190646 4k blocks and 61054976 inodes
Filesystem UUID: ecf84219-99ea-48aa-b41f-bb561799694e
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
(to be continued... awaiting command output... 1TB Hard Drive taking too long a time with "testdisk" command.)
![]() |
| Disks on Kali Linux OS |
![]() |
| 'testdisk' command on Kali Linux OS |
---------------------------------------------------------------------------
Here is a side conversation from another chat session on the same topic especially on 'testdisk' command.
"
While running testdisk on kali Linux on a hdd can I pause the progress midway to resume later?
Gemini said
In short: No, TestDisk does not have a native "pause and resume" feature for its scanning processes.
If you interrupt TestDisk midway (e.g., by pressing Ctrl+C or closing the terminal), you will have to restart the scan from the beginning next time.
Why you shouldn't pause/interrupt it
TestDisk operates by reading the raw data on the disk to map out partitions or recover files. Interrupting this process can lead to:
Lost Time: You lose all progress made during the scan.
Incomplete Results: If you are running a file recovery (
PhotoRec), you might end up with corrupted files if the writing process is interrupted unexpectedly.
What to do instead
If you are worried about the HDD spinning for too long or needing the computer for something else, here are the best practices:
Run it in a screen session: Use a terminal multiplexer like
screenortmux. This allows you to disconnect from the terminal session and let TestDisk run in the background without worrying about closing the terminal window.
Let it finish: Unfortunately, for HDD scanning, the best approach is to let it run to completion to ensure all data is analyzed properly.
Would you like me to show you how to use tmux to run TestDisk in the background?
Can I suspend kali Linux in midway to testdisk to resume later?
Gemini said
While suspending (going to sleep/standby) Kali Linux technically pauses the CPU and saves the RAM state, it is highly risky to do this while TestDisk is actively reading or writing to a disk.
Here is why you should avoid it:
Data Corruption: TestDisk works with raw data. If the drive is in the middle of a read/write operation when the power state changes, you risk corrupting the file system or the very files you are trying to recover.
Disk Timeout Issues: When the computer wakes up, the HDD may have spun down or lost its connection to the operating system, causing TestDisk to hang, crash, or report errors because it can no longer find the drive.
The Recommended Workflow
Instead of suspending the machine, let the scan run and use a terminal multiplexer to detach from the session.
Use
tmuxorscreen: Start atmuxsession, run TestDisk inside it, and then detach.Turn off Sleep: Ensure your Kali Linux power settings are set to never sleep while plugged in.
Turn off Monitor: It is perfectly safe to turn off your monitor to save power, but keep the computer running.
Would you like me to guide you through setting up tmux to keep TestDisk running safely in the background?
I need to transport my kali Linux machine PC to another room?
Gemini said
Moving the machine while TestDisk is actively scanning is dangerous for your data. Because TestDisk interacts directly with the hardware at a low level, physically moving the PC (which causes vibrations or temporary power interruptions) can cause the drive to fail or corrupt the data you are trying to recover.
The Best Approach
Stop the scan: Safely terminate the TestDisk process (
Ctrl+Cor quit).Shut down: Turn off the Kali Linux machine completely.
Move the PC: Transport it to the new room.
Restart: Power on and restart the TestDisk scan.
What if I must keep it running?
If you absolutely cannot stop the scan, you must move the machine extremely carefully (no jarring, no sudden movements) while it is running. Note that this still carries a high risk of hardware failure if the HDD head crashes due to movement.
Would you like me to explain how to save the TestDisk log file so you can quickly jump back to the same spot in the analysis after you restart?
Yes
Gemini said
Excellent choice. Saving the log file is the safest way to interrupt your work and resume later without starting entirely from scratch.
Here is how you can do it:
Stop the Scan: Press
Ctrl+Cin the terminal to stop TestDisk.Save the Log: TestDisk usually asks if you want to save the log file before exiting. Ensure you select Yes (or choose to write a log file in the advanced options if you are using PhotoRec).
Move the PC: Safely move your machine to the new room.
Resume: When you restart TestDisk in the new location, it will often detect the log file from the previous session and ask if you want to append to it or load it. This allows TestDisk to skip over areas it has already analyzed.
Would you like me to show you the specific command to run TestDisk so it automatically creates a log file?
Yes
Gemini said
To ensure TestDisk saves a detailed log file automatically, you can explicitly define the log file name when you launch it from the terminal.
The Command
Use the following syntax in your terminal to start TestDisk and specify a log file:
sudo testdisk /log
Alternatively, to specify a specific name and location for the log file:
sudo testdisk /log=/home/kali/Desktop/testdisk.log
What happens next
Run the scan: Proceed with your analysis as normal.
Move the machine: Shut down, move to the new room, and power back on.
Resume: Launch TestDisk again using the same log file path. TestDisk will read the existing log file and attempt to pick up where it left off, rather than scanning from the very beginning.
Would you like me to create a simple bash script that launches TestDisk with logging enabled automatically?
Yes
Gemini said
Here is a simple Bash script you can use to launch TestDisk with automatic logging.
The Bash Script
Copy the code below into a file named run_disk_scan.sh:
#!/bin/bash
# Define the log file location
LOGFILE="/home/kali/Desktop/testdisk_session.log"
echo "Starting TestDisk with log file: $LOGFILE"
echo "------------------------------------------------"
# Run TestDisk with the log option
sudo testdisk /log="$LOGFILE"
echo "------------------------------------------------"
echo "TestDisk session finished. Log saved at $LOGFILE"
How to use this script
Open your terminal.
Create the file:
nano run_disk_scan.shPaste the code above into the file.
Save and exit (Ctrl+O, Enter, Ctrl+X).
Make it executable:
chmod +x run_disk_scan.shRun the script:
./run_disk_scan.sh
This will ensure a log is created at /home/kali/Desktop/testdisk_session.log every time you run it.
Would you like me to explain how to interpret the log file to see exactly what TestDisk has already scanned?
Yes
Gemini said
Interpreting the log file is crucial to know if your progress was saved correctly. The log file (testdisk.log) is a plain text file that records every action TestDisk takes.
How to check the log
Open the file: You can use a text editor like
nanoorcatto view the log:Bash
cat /home/kali/Desktop/testdisk_session.logLook for progress markers:
Partition Scanning: Look for lines indicating the last cylinder or sector range scanned.
File Recovery: If using PhotoRec, look for the last files successfully recovered and the total count.
When you restart TestDisk in the new room, it will look at these entries to determine where to resume.
Would you like me to explain how to interpret specific error messages in the log file, just in case the scan ran into issues?
Yes
Gemini said
Analyzing the log file for errors is vital, especially if the scan is taking unusually long or seems stuck. The log will tell you if TestDisk is encountering physical issues with the HDD.
Common Error Messages to Watch For
If you see these errors frequently, it means the HDD is physically failing.
Would you like me to guide you through using the ddrescue tool, which is better designed to handle failing disks with many read errors?
Yes
Gemini said
Using ddrescue is a crucial next step if your HDD is failing. Unlike TestDisk, which tries to map file systems or recover files immediately, ddrescue is designed to copy data from a failing drive to a healthy one (or an image file) as safely as possible.
It works in passes, grabbing the easy data first and then focusing on the problematic areas without constantly resetting due to read errors.
The ddrescue Workflow
Identify your drives:
Bash
sudo ddrescue -d -r1 /dev/sdb /path/to/image.img /path/to/mapfile.logThis attempts to read the bad areas without giving up immediately.
Why use a Mapfile?
The mapfile.log is essential. It tells ddrescue which sectors are already copied, allowing you to stop, pause, move your computer, or even lose power without losing progress.
Would you like me to show you how to analyze the mapfile.log to see how much data was successfully recovered?
Yes
Gemini said
Analyzing the mapfile is the best way to understand the health of your drive and the success of the rescue operation.
How to Check the Mapfile Status
You can read the mapfile directly using cat to see a summary of the rescue attempt:
cat /path/to/mapfile.log
Alternatively, you can get a more detailed view of the status by running the ddrescue command again with the -v (verbose) flag, which will parse the mapfile for you:
sudo ddrescue -v /dev/sdb /path/to/image.img /path/to/mapfile.log
Interpreting the Output
Look for these key indicators in the output:
Percent Rescued: Shows the total percentage of data successfully copied.
Time Since Last Successful Read: Indicates if the drive is stuck trying to read a bad sector.
Errors: The number of bad sectors
ddrescueencountered.
If the Percent Rescued is high and the number of Errors is low, you are in good shape to try running TestDisk or PhotoRec on the image file you just created, rather than the failing physical drive itself.
Would you like me to show you how to mount the image file you created to see if the files are accessible?
Yes
Gemini said
Mounting the image file is a safe way to check for data integrity without risking the failing HDD further. Once you have created an image file (e.g., image.img) using ddrescue, you can map it to a loop device to make it readable by the operating system.
Steps to Mount the Image
Map the image to a loop device:
Bash
sudo mkdir -p /mnt/rescue sudo mount -o ro /dev/loop0p1 /mnt/rescueUsing the
-o roflag mounts the image as read-only, which is highly recommended to prevent accidental changes to your rescued data.Access your files: You can now navigate to
/mnt/rescuein your file manager or terminal to see if your files are intact.
Unmounting when finished
When you are done checking the files, be sure to unmount it safely:
sudo umount /mnt/rescue
sudo losetup -d /dev/loop0
Would you like me to guide you through using TestDisk or PhotoRec specifically on this mounted image file to recover files that might not be immediately visible?
Yes
Gemini said
Excellent, running TestDisk on the image file is the safest way to recover files without stressing the failing hardware further.
Steps to Run TestDisk on the Image
Launch TestDisk targeting the image file:
Bash
sudo testdisk /path/to/image.imgSelect the Disk: TestDisk should automatically select the image file. Choose Proceed.
Partition Table Type: Select the appropriate partition table type (usually Intel for older MBR disks or EFI GPT for modern disks). If unsure, let TestDisk detect it automatically.
Analyze and Search: Select Analyse -> Quick Search. TestDisk will scan the image file for partitions.
List Files: Once partitions are found, highlight the partition you want to recover files from and press
Pto List files.Copy Files: Navigate through the directories, select the files you want to recover, and press
Cto copy them to a different, healthy drive.
Would you like me to show you how to use PhotoRec on the image file if TestDisk cannot find the partition structure?
Yes
Gemini said
Using PhotoRec on the image file is the best approach if the partition table is too damaged for TestDisk to work. PhotoRec ignores the file system and looks directly for file signatures (headers) to recover raw data.
Steps to Run PhotoRec on the Image
Launch PhotoRec targeting the image file:
Bash
sudo photorec /path/to/image.imgSelect the Disk: Ensure the image file is selected and choose Proceed.
Select Partition/Area: Choose No partition (to scan the entire image) and press Enter.
File System Type: Select the file system type (usually Other for FAT/NTFS/EXT, or EXT2/3/4 if you know it was a Linux drive).
Scan for Files: Select Free (to look for deleted files) or Whole (to scan the entire image) and press Enter.
Choose Destination: Select a folder on a different, healthy drive where you want to save the recovered files. Press
Cto start the recovery.
Would you like me to show you how to organize the recovered files after PhotoRec has finished running?
Yes
Gemini said
Organizing the files recovered by PhotoRec is crucial because it tends to rename files to generic names (e.g., f12345.jpg) and loses folder structures.
How to Organize Recovered Files
Use
photorec_sort(if available): Some versions of PhotoRec include a tool to sort files based on their extensions.Use
findandmvcommands: You can use terminal commands to move files based on their extension into specific folders. For example, to move all.jpgfiles:Bash
mkdir -p /path/to/recovered_files/images find /path/to/recovered_files -name "*.jpg" -exec mv {} /path/to/recovered_files/images/ \;Check for Metadata: Use tools like
exiftoolto read the metadata inside images or documents to potentially rename them back to their original names based on dates or camera models.
Would you like me to show you how to use exiftool to rename files based on their metadata?
Yes
Gemini said
exiftool is incredibly powerful for renaming files based on the data contained inside them (like the date a photo was taken, or the artist name in a music file).
How to Use exiftool to Rename Files
Install
exiftool(if not already installed):Bash
exiftool "-FileName<${Model}_${Filename}" /path/to/recovered_files/
Why this is useful
This helps turn a pile of generic f12345.jpg files back into a logically organized set of photos, making it much easier to find specific memories or documents.
Would you like me to show you how to securely delete the image file and the failing HDD once you have successfully recovered your data?
Yes
Gemini said
Safely disposing of the old drive and the temporary image file is the final step to ensure your data is completely gone and cannot be recovered by someone else.
How to Securely Delete the Image File
Simply deleting the file (rm) does not erase the data from the disk; it just tells the file system that the space is free. To securely erase it, use shred:
shred -n 3 -z -u /path/to/image.img
-n 3: Overwrites the data 3 times with random patterns.-z: Adds a final overwrite with zeros to hide shredding.-u: Deallocates and removes the file after overwriting.
How to Securely Erase the Failing HDD
Before disposing of the physical hard drive, you must erase it securely. Assuming the drive is /dev/sdb:
sudo dd if=/dev/urandom of=/dev/sdb bs=4M status=progress
Warning: This command will destroy everything on the target drive (
/dev/sdb). Make absolutely sure you have the correct drive identifier.
Physical Destruction
For maximum security, especially with a failing drive, the most reliable method is physical destruction:
Drill holes through the platters.
Take it apart and smash the platters with a hammer.
Would you like me to guide you on how to check the SMART data of your new hard drive to monitor its health?
Yes
Gemini said
Monitoring your new hard drive's health is essential to prevent this data loss situation from happening again. You can use the SMART (Self-Monitoring, Analysis, and Reporting Technology) system built into most modern drives.
How to Check SMART Data in Kali Linux
Install
smartmontools(if not already installed):Bash
sudo smartctl -a /dev/sda
What to Look For
Overall Health Assessment: Should say "PASSED".
Reallocated Sector Count: Should be 0. If this number is increasing, the drive is beginning to fail.
Pending Sector Count: Should be 0. If not, the drive has found bad sectors and is waiting to map them out.
Would you like me to show you how to set up automatic email alerts if your drive's SMART status changes to "FAILING"?
You said
Yes
Gemini said
Setting up automatic email alerts ensures you are warned before a drive completely fails. This requires configuring smartd (the SMART daemon) to send emails via a mail transfer agent like postfix.
Steps to Set Up Email Alerts
Install necessary tools:
Bash
sudo nano /etc/smartd.conf
Add or modify a line to scan all devices and send an email to your address if any fail:
sudo systemctl restart smartd
How it works
smartd will run in the background. It periodically checks the SMART data of your drives. If it detects a failing status (like increasing reallocated sectors), it will automatically send you an email alert.
Would you like me to help you configure a daily cron job to run a smartctl check and log the results to a file for your review?"
sudo fdisk -l
Identify your failing drive (e.g., /dev/sdb) and your destination drive/file (e.g., /dev/sdc or a large image file on a healthy drive).
Run the first pass (Fast):
sudo ddrescue -n /dev/sdb /path/to/image.img /path/to/mapfile.log
This skips the bad areas to get the bulk of the data quickly.
Run the second pass (Scrape):
sudo losetup -Pf /path/to/image.img
The -P flag scans the partition table within the image, and -f finds the first available loop device (e.g., /dev/loop0).
Identify the partitions:
lsblk
Look for your loop device and its partitions (e.g., /dev/loop0p1, /dev/loop0p2).
Create a mount point and mount the partition:
sudo apt install libimage-exiftool-perl
Rename files based on date taken:
To rename files to YYYYMMDD_HHMMSS.extension based on their metadata:
exiftool "-FileName<CreateDate" -d "%Y%m%d_%H%M%S.%%e" /path/to/recovered_files/
Rename files based on camera model:
To rename files to ModelName_OriginalName.extension:
sudo apt install smartmontools
Identify your new drive:
lsblk
Look for the device name, for example, /dev/sda.
Run a short self-test:
sudo smartctl -t short /dev/sda
View the SMART report:
sudo apt install smartmontools postfix mailutils
(During postfix installation, select "Internet Site" when prompted).
Configure smartd:
Edit the smartd.conf file:
DEVICESCAN -m your-email@example.com -M exec /usr/share/smartmontools/smartd-runner
(Replace your-email@example.com with your actual email address).
Restart the service:
END OF SIDE CONVERSATION HERE
--------------------------------------------------------------------------------------
![]() |
| 'testdisk' command on Kali Linux OS |
'testdisk' progress on the same drive after a few hours is as shown in the image screenshot below:
![]() |
| 'testdisk' progress on the same drive after a few hours is as shown in the image |
Revisiting the earlier Gemini3 conversation of Seagate 1TB HDD troubleshooting and repair:
I had a conversation with you on trouble shooting my Seagate 1TB Hard Disk Drive, When I was logged out. I was not allowed to attach any files to the chat post because I was logged out. Furnishing the complete conversation now after login for your reference " (kali㉿kali)-[~]
└─$ sudo fsck /dev/sdd
[sudo] password for kali:
fsck from util-linux 2.41.3
e2fsck 1.47.2 (1-Jan-2025)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdd
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
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>
or
e2fsck -b 32768 <device>
┌──(kali㉿kali)-[~]
Gemini said
Ouch. Seeing "Bad magic number" is usually a heart-sink moment, but it’s often just a case of the front door (the superblock) being jammed while the rest of the house is perfectly fine.
The superblock is a critical piece of metadata that tells the system where everything else is on the drive. If it's corrupted, Linux doesn't recognize the partition as a valid filesystem.
Step 1: Verify the Partition Name
Before you try to fix it, ensure /dev/sdd is actually the partition and not the whole drive. Usually, filesystems live on /dev/sdd1, /dev/sdd2, etc. If you run fsck on the raw disk (sdd) instead of the partition (sdd1), it will always return a "bad magic number" error.
Check your disk layout first:
Bash
lsblk
Step 2: Find the Backup Superblocks
Linux is smart enough to keep multiple copies of the superblock just in case the primary one dies. You need to find where those backups are located. Run this command:
Bash
sudo mke2fs -n /dev/sdd1
Note: The -n flag is vital. It tells the system to "pretend" to format the drive, which displays where it would put the backup superblocks without actually touching your data.
Look for the section titled "Superblock backups stored on blocks:". You’ll see a list of numbers like 32768, 98304, 163840, etc.
Step 3: Restore from a Backup
Pick the first number from that list (e.g., 32768) and tell e2fsck to use it as the "source of truth":
Bash
sudo e2fsck -b 32768 /dev/sdd1
(Replace 32768 with the actual number from your output and sdd1 with your actual partition name).
If the first one fails, try the next number in the list.
Step 4: If the above doesn't work (The "Nuclear" Option)
If e2fsck still can't find a valid superblock, the partition table itself might be damaged. In this case, TestDisk is your best friend. It can scan the entire drive and "undelete" or repair partitions.
Install it: sudo apt install testdisk
Run it: sudo testdisk
Select the drive, choose your partition type (usually Intel or EFI GPT), and select Analyze.
A Quick Word of Caution
If this drive contains "once-in-a-lifetime" data, stop what you are doing. Every command you run on a failing drive carries a small risk. If you suspect hardware failure (clicking sounds, slow response), your best bet is to use ddrescue to clone the entire drive to an image file before trying to fix the filesystem.
Would you like me to walk you through the lsblk output to make sure we're targeting the right partition?
(kali㉿kali)-[~]
└─$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 2.7T 0 disk
├─sda1 8:1 0 512M 0 part /mnt/sdb1
├─sda2 8:2 0 2.7T 0 part /mnt/sdb2
└─sda3 8:3 0 977M 0 part
sdb 8:16 0 476.9G 0 disk
├─sdb1 8:17 0 512M 0 part
└─sdb2 8:18 0 475.5G 0 part /run/media/kali/8ff94f06-af00-45d7-8c5e-7cab38995640
sdc 8:32 0 465.8G 0 disk
├─sdc1 8:33 0 512M 0 part /boot/efi
├─sdc2 8:34 0 464.3G 0 part /
└─sdc3 8:35 0 976M 0 part
sdd 8:48 0 931.5G 0 disk
sde 8:64 0 2.7T 0 disk
├─sde1 8:65 0 260M 0 part
├─sde2 8:66 0 16M 0 part
├─sde3 8:67 0 147.4G 0 part /run/media/kali/Windows
├─sde4 8:68 0 136.7G 0 part /run/media/kali/New Volume
├─sde5 8:69 0 136.7G 0 part /run/media/kali/PHOTO
├─sde6 8:70 0 25G 0 part /run/media/kali/LENOVO
├─sde7 8:71 0 1000M 0 part
├─sde8 8:72 0 17.7G 0 part
├─sde9 8:73 0 1000M 0 part /run/media/kali/LRS_ESP
└─sde10 8:74 0 2.3T 0 part /run/media/kali/SGT
sdf 8:80 1 0B 0 disk
sdg 8:96 1 0B 0 disk
┌──(kali㉿kali)-[~]
└─$ sudo mke2fs -n /dev/sdd1
mke2fs 1.47.2 (1-Jan-2025)
The file /dev/sdd1 does not exist and no size was specified.
┌──(kali㉿kali)-[~]
└─$ sudo mke2fs -n /dev/sdd
mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 244190646 4k blocks and 61054976 inodes
Filesystem UUID: ecf84219-99ea-48aa-b41f-bb561799694e
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
"(kali㉿kali)-[~]
└─$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 2.7T 0 disk
├─sda1 8:1 0 512M 0 part /mnt/sdb1
├─sda2 8:2 0 2.7T 0 part /mnt/sdb2
└─sda3 8:3 0 977M 0 part
sdb 8:16 0 476.9G 0 disk
├─sdb1 8:17 0 512M 0 part
└─sdb2 8:18 0 475.5G 0 part /run/media/kali/8ff94f06-af00-45d7-8c5e-7cab38995640
sdc 8:32 0 465.8G 0 disk
├─sdc1 8:33 0 512M 0 part /boot/efi
├─sdc2 8:34 0 464.3G 0 part /
└─sdc3 8:35 0 976M 0 part
sdd 8:48 0 931.5G 0 disk
sde 8:64 0 2.7T 0 disk
├─sde1 8:65 0 260M 0 part
├─sde2 8:66 0 16M 0 part
├─sde3 8:67 0 147.4G 0 part /run/media/kali/Windows
├─sde4 8:68 0 136.7G 0 part /run/media/kali/New Volume
├─sde5 8:69 0 136.7G 0 part /run/media/kali/PHOTO
├─sde6 8:70 0 25G 0 part /run/media/kali/LENOVO
├─sde7 8:71 0 1000M 0 part
├─sde8 8:72 0 17.7G 0 part
├─sde9 8:73 0 1000M 0 part /run/media/kali/LRS_ESP
└─sde10 8:74 0 2.3T 0 part /run/media/kali/SGT
sdf 8:80 1 0B 0 disk
sdg 8:96 1 0B 0 disk
┌──(kali㉿kali)-[~]
└─$ sudo mke2fs -n /dev/sdd1
mke2fs 1.47.2 (1-Jan-2025)
The file /dev/sdd1 does not exist and no size was specified.
┌──(kali㉿kali)-[~]
└─$ sudo mke2fs -n /dev/sdd
mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 244190646 4k blocks and 61054976 inodes
Filesystem UUID: ecf84219-99ea-48aa-b41f-bb561799694e
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848 "
I tried "sudo e2fsck -b XXXXX /dev/sdd" (XXXXX substituted for each given alternate Superblock backup number given by the previous command) on all Superblock backup's stored on blocks given by the earlier mke2fs command on the same "/dev/sdd" drive. I get the same error as the "sudo fsck /dev/sdd" error initially mentioned. None of the Superblock backups block numbers are working as backups. So I tried step 4: TestDisk>>Selected the drive>>Selected partition type "EFI GPT". I am unable to attach screenshots of the TestDisk progress due to some technical issue from Gemini's side. It was progress status was some thing like "TestDisk 7.2, Data Recovery Utility, February 2024
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Analyse cylinder 913/121600: 00%
Read error at 271/72/59 (lba=4358209)" on February 18 2026 5:23 AM. Now it is "TestDisk 7.2, Data Recovery Utility, February 2024
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Analyse cylinder 4038/121600: 03%
Read error at 271/72/59 (lba=4358209)" at February 18, 2026, 10:10AM.
My testdisk.log file has the following details on it at February 18, 2026 10:16AM
"
Tue Feb 17 19:50:25 2026
Command line: TestDisk
TestDisk 7.2, Data Recovery Utility, February 2024
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
OS: Linux, kernel 6.18.5+kali-amd64 (#1 SMP PREEMPT_DYNAMIC Kali 6.18.5-1kali1 (2026-01-19)) x86_64
Compiler: GCC 14.2
ext2fs lib: 1.47.2, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none, curses lib: ncurses 6.5
/dev/sda: LBA, HPA, LBA48, DCO support
/dev/sda: size 5860533168 sectors
/dev/sda: user_max 5860533168 sectors
/dev/sda: native_max 5860533168 sectors
/dev/sda: dco 5860533168 sectors
/dev/sdb: LBA, HPA, LBA48 support
/dev/sdb: size 1000215216 sectors
/dev/sdb: user_max 1000215216 sectors
/dev/sdb: native_max 1000215216 sectors
/dev/sdc: LBA, HPA, LBA48, DCO support
/dev/sdc: size 976773168 sectors
/dev/sdc: user_max 976773168 sectors
/dev/sdc: native_max 976773168 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - 0 sectors, sector size=512
Hard disk list
Disk /dev/sda - 3000 GB / 2794 GiB - CHS 364801 255 63, sector size=512 - C02HD3T001014-, FW:A5C0
Disk /dev/sdb - 512 GB / 476 GiB - CHS 62260 255 63, sector size=512 - ZEB-SD52, FW:3A0
Disk /dev/sdc - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512 - MIS05GHD, FW:0A01
Disk /dev/sdd - 1000 GB / 931 GiB - CHS 121601 255 63, sector size=512 - 003-1ER162, FW:9128
Disk /dev/sde - 3000 GB / 2794 GiB - CHS 2861588 64 32, sector size=512 - 00969- 0, FW:9128
Partition table type defaults to Intel
Disk /dev/sdd - 1000 GB / 931 GiB - 003-1ER162
Partition table type: EFI GPT
Analyse Disk /dev/sdd - 1000 GB / 931 GiB - CHS 121601 255 63
Bad GPT partition, invalid signature.
Trying alternate GPT
Bad GPT partition, invalid signature.
Current partition structure:
Bad GPT partition, invalid signature.
Trying alternate GPT
Bad GPT partition, invalid signature.
search_part()
Disk /dev/sdd - 1000 GB / 931 GiB - CHS 121601 255 63
file_pread(7,16,buffer,4360178(271/104/12)) read err: Partial read
file_pread(7,16,buffer,4360194(271/104/28)) read err: Input/output error
file_pread(7,1,buffer,4360194(271/104/28)) read err: Input/output error
file_pread(7,1,buffer,4360195(271/104/29)) read err: Input/output error
file_pread(7,1,buffer,4360196(271/104/30)) read err: Input/output error
file_pread(7,1,buffer,4360197(271/104/31)) read err: Input/output error
file_pread(7,1,buffer,4360198(271/104/32)) read err: Input/output error
file_pread(7,1,buffer,4360199(271/104/33)) read err: Input/output error
file_pread(7,1,buffer,4360200(271/104/34)) read err: Input/output error
file_pread(7,16,buffer,4360201(271/104/35)) read err: Input/output error
file_pread(7,1,buffer,4360201(271/104/35)) read err: Input/output error
file_pread(7,16,buffer,4360202(271/104/36)) read err: Input/output error
file_pread(7,1,buffer,4360202(271/104/36)) read err: Input/output error
file_pread(7,16,buffer,4360203(271/104/37)) read err: Input/output error
file_pread(7,1,buffer,4360203(271/104/37)) read err: Input/output error
file_pread(7,1,buffer,4360204(271/104/38)) read err: Input/output error
file_pread(7,1,buffer,4360205(271/104/39)) read err: Input/output error
file_pread(7,1,buffer,4360206(271/104/40)) read err: Input/output error
file_pread(7,1,buffer,4360207(271/104/41)) read err: Input/output error
file_pread(7,1,buffer,4360208(271/104/42)) read err: Input/output error
file_pread(7,1,buffer,4360209(271/104/43)) read err: Input/output error
file_pread(7,16,buffer,4360210(271/104/44)) read err: Input/output error
file_pread(7,1,buffer,4360210(271/104/44)) read err: Input/output error
file_pread(7,16,buffer,4360211(271/104/45)) read err: Input/output error
file_pread(7,1,buffer,4360211(271/104/45)) read err: Input/output error
file_pread(7,16,buffer,4360212(271/104/46)) read err: Input/output error
file_pread(7,1,buffer,4360212(271/104/46)) read err: Input/output error
file_pread(7,1,buffer,4360213(271/104/47)) read err: Input/output error
file_pread(7,1,buffer,4360214(271/104/48)) read err: Input/output error
file_pread(7,1,buffer,4360215(271/104/49)) read err: Input/output error
file_pread(7,1,buffer,4360216(271/104/50)) read err: Input/output error
file_pread(7,1,buffer,4360217(271/104/51)) read err: Input/output error
file_pread(7,16,buffer,4360218(271/104/52)) read err: Input/output error
file_pread(7,1,buffer,4360218(271/104/52)) read err: Input/output error
file_pread(7,16,buffer,4360219(271/104/53)) read err: Input/output error
file_pread(7,1,buffer,4360219(271/104/53)) read err: Input/output error
file_pread(7,16,buffer,4360220(271/104/54)) read err: Input/output error
file_pread(7,1,buffer,4360220(271/104/54)) read err: Input/output error
file_pread(7,1,buffer,4360221(271/104/55)) read err: Input/output error
file_pread(7,1,buffer,4360222(271/104/56)) read err: Input/output error
file_pread(7,1,buffer,4360223(271/104/57)) read err: Input/output error
file_pread(7,1,buffer,4360224(271/104/58)) read err: Input/output error
file_pread(7,1,buffer,4360225(271/104/59)) read err: Input/output error
file_pread(7,16,buffer,4360226(271/104/60)) read err: Input/output error
file_pread(7,1,buffer,4360226(271/104/60)) read err: Input/output error
file_pread(7,16,buffer,4360227(271/104/61)) read err: Input/output error
file_pread(7,1,buffer,4360227(271/104/61)) read err: Input/output error
file_pread(7,16,buffer,4360228(271/104/62)) read err: Input/output error
file_pread(7,1,buffer,4360228(271/104/62)) read err: Input/output error
file_pread(7,1,buffer,4360229(271/104/63)) read err: Input/output error
file_pread(7,1,buffer,4360230(271/105/1)) read err: Input/output error
file_pread(7,1,buffer,4360231(271/105/2)) read err: Input/output error
file_pread(7,1,buffer,4360232(271/105/3)) read err: Input/output error
file_pread(7,1,buffer,4360233(271/105/4)) read err: Input/output error
file_pread(7,16,buffer,4360234(271/105/5)) read err: Input/output error
file_pread(7,1,buffer,4360234(271/105/5)) read err: Input/outpu"
Please help me." Also now Iam attaching my screenshots of Kali Linux Disks and testdisk command for your reference. Please help me.
Gemini said
This is a tough situation, but having the logs and screenshots helps immensely. Looking at the testdisk.log and your terminal output, we have a clear diagnosis, though it's likely not the news you want to hear.
The Situation
Your drive is experiencing physical hardware failure (specifically, bad sectors or a failing head).
Evidence: The constant
Input/output errorandRead errorat specific LBA addresses (like4358209) in TestDisk mean the computer is physically unable to read the data from those spots on the platters.The Superblock Issue: The reason
e2fsckfailed with every backup superblock is that the part of the disk where the partition table and superblocks live is physically damaged. You aren't just missing a "key"—the "paper" the key was written on has been torn.TestDisk Progress: It took 5 hours to move from 0% to 3%. At that rate, it would take roughly 7 days to finish, and every second it spends trying to read those "Bad GPT signatures" is wearing out the mechanical components even further.
Critical: Stop the Scan
Close TestDisk now. Every time the drive head hits a bad sector and "retries" (which is what those read errors are), it risks a total head crash, which would make the data permanently unrecoverable even for professionals.
Your Recovery Path
Since you are on Kali Linux, you have the best tool for this specific scenario: ddrescue. Unlike TestDisk, which tries to understand the data while reading, ddrescue simply tries to copy every healthy bit to a new drive, skipping the bad spots and coming back to them later.
1. What you need
A Destination Drive: You need another drive with at least 1TB of free space. (Looking at your
lsblk, maybe that 3TB/dev/sdaor/dev/sdehas room?)An Image File: We will save the failing drive as a
.imgfile.
2. The Recovery Command
Open a terminal and run this command (replace /path/to/backup/ with the actual path to your healthy 3TB drive):
sudo ddrescue -d -r3 /dev/sdd /path/to/backup/disk_copy.img /path/to/backup/recovery.log
Why this command?
-d: Uses direct disc access (ignores the kernel cache).-r3: Retries bad sectors 3 times before giving up.recovery.log: This is vital. If the computer crashes or the drive disconnects, you can run the command again, and it will pick up exactly where it left off.
3. After the image is created
Once ddrescue finishes (it might take a long time, but it's safer than TestDisk), you will have a file named disk_copy.img. You can then run TestDisk or fsck on that file instead of the failing physical hardware.
Summary of the "Disks" Screenshot
Your screenshot shows the drive as "1.0 TB Unknown" and "Assessment: Disk is OK." Do not trust that "OK" assessment. That is just a basic SMART check; your logs prove the drive is physically failing to read sectors.
Would you like me to help you identify the correct mount point for your 3TB drive so you can start the ddrescue process safely?
I would also like to mention that I had an Microsoft Windows (8 or 8.1 or 9, which I am not sure now) intstalled with Microsoft doing some disk encrytpion at bios level (I am not sure of that too) which requires Microsoft account authentication. Later from Windows I was trying to install Dual Boot Configuration Ubuntu Linux some 6 to 7 years back when the device had started showing issues and became unusable. Correct me if I am wrong with any of these details. Could these be the cause of Errors? Could selecting a different partition type other than Intel or EFI correct the testdisk errors? Could there be a conflict of MBR and GPT (while Dual boot configuration installation) which is causing errors? Please do intimate me if there could be any other cause too?
Gemini said
This adds a whole new layer of intrigue to the mystery. The short answer is: Yes, those factors could definitely be causing the "logical" confusion, but they cannot cause the "physical" errors you are seeing.
Let’s break down your specific questions based on that Windows history.
1. Could Windows Encryption (BitLocker) be the cause?
Partially. Windows 8.1 and later often come with BitLocker Device Encryption enabled by default if you sign in with a Microsoft account.
The Conflict: If the drive is encrypted, Linux tools like
fsckorTestDiskwill see "random noise" instead of a filesystem. This is exactly why you got the "Bad magic number" error—the encryption makes the superblock look like gibberish.The Reality: Encryption never causes
Input/output errororRead error. Encryption is a software lock; an I/O error is a broken bolt on the door. Your drive is physically struggling to provide data, regardless of whether that data is encrypted or not.
2. MBR vs. GPT Conflict?
Yes, this is very likely. When you tried to install Ubuntu 7 years ago, you might have been caught in the transition era between MBR (Old BIOS) and GPT (New UEFI).
If you have a "protective MBR" and a "corrupt GPT" on the same disk, TestDisk will get confused and report "Invalid Signature."
However, a conflict in partition tables would simply result in "Partition not found." It would not cause the drive to hang for 5 hours or report
file_pread... read err: Input/output error. Those errors are the drive firmware saying, "I tried to read this spot on the platter, and I failed."
3. Could selecting a different partition type fix it?
In TestDisk, switching from [EFI GPT] to [Intel] (MBR) might change what TestDisk looks for, but it won't fix the read errors.
The log you provided shows errors at
LBA 4358209. This is a physical address. No matter what "language" (partition type) you speak to the drive in, it still can't read that specific physical location.
The "Dual Boot" Theory
You mentioned the issues started during that Ubuntu installation 6-7 years ago. It is very common for a hard drive to have "silent" bad sectors that you never notice during normal use. When you perform a major operation—like shrinking a partition or installing a new OS—the computer tries to write to areas of the disk it hasn't touched in years. If those areas are physically degraded, the installation fails, and the drive suddenly appears "broken."
Revised Plan of Action
Because of the BitLocker/Encryption possibility, logical repair (fsck/TestDisk) is currently impossible. You cannot fix a filesystem that is locked behind encryption until you have a perfect bit-for-bit copy.
My recommendation remains the same, but with a new "Why":
Use
ddrescue: We need to get every possible bit off that failing hardware.The Goal: Once you have the
.imgfile, if it is BitLocker encrypted, we will use a Linux tool calleddislockeralong with your Microsoft Recovery Key to unlock it.
One quick check for you: Can you log into your Microsoft account on another device and check https://account.microsoft.com/devices/recoverykey? If you see a key for a device from 6-7 years ago, that is the "skeleton key" we will need once we've rescued the data.
Would you like me to help you find a safe place on your other drives to store that 1TB image file?
I don't have the Microsoft credentials now. I forgot them. I haven't written the details as I couldn't use them after installation and couldn't troubleshoot the issue.
Gemini said
That definitely complicates things, but let’s be realistic about the priority: we need to save the data first. Even if we don't have the key right now, having a digital copy of the drive is better than having a dead piece of metal in your hand.
The Reality Check
If the drive is indeed encrypted with BitLocker and we never find the recovery key, the data is essentially "mathematically shredded." However, there is a very good chance that not all partitions were encrypted, or that the encryption was never fully initialized before the drive started failing.
Given that you've lost the credentials, here is our strategy:
Phase 1: The "Emergency Room" (Stop the Bleeding)
You must stop trying to "fix" the drive. Every time you run fsck, TestDisk, or even lsblk, the drive head tries to read the damaged area. If it scratches the platter, the data is gone forever.
Your priority is to run ddrescue. I noticed in your lsblk output that /dev/sda and /dev/sde are both 3TB drives.
/dev/sde10(SGT) has 2.3TB of space./dev/sda2has 2.7TB of space.
You have plenty of room to store a 1TB image file.
Phase 2: How to run ddrescue correctly
Open your terminal in Kali and use this exact command. I have set it to skip the "bad" areas quickly so we can get the easy data first:
# 1. Create a folder for the recovery on your big drive
mkdir -p /run/media/kali/SGT/Seagate_Recovery
# 2. Run ddrescue to clone the drive to a file
# -n: skip bad areas first to save time/drive life
# -v: verbose (shows you what's happening)
sudo ddrescue -n -v /dev/sdd /run/media/kali/SGT/Seagate_Recovery/seagate_backup.img /run/media/kali/SGT/Seagate_Recovery/recovery.log
Phase 3: What if we can't find the Windows Key?
If we manage to get a 100% (or near 100%) image of the drive, we can try several things without the Microsoft account:
Direct Image Mounting: Sometimes Linux can see through a "broken" encryption header if it was only partially encrypted.
PhotoRec: This is the "brother" tool to TestDisk. Instead of looking for a partition table (which might be encrypted or broken), it looks for file signatures (like the headers for JPEGs, PDFs, or MP4s). If the files themselves aren't encrypted, PhotoRec can carve them out of the image file even if the OS is a total wreck.
The Ubuntu Partition: If you were installing Ubuntu, you might have created a non-encrypted EXT4 partition.
ddrescuewill grab that too, and we can mount it easily.
Summary of the Situation
The Input/output errors are the primary enemy right now. The lost Windows credentials are a secondary problem for later. If the drive dies completely while we worry about the password, the password won't matter anyway.
Would you like me to double-check the mount path for your 3TB drive to make sure the ddrescue command points to the right place?
You said
The Hard Disk Drive has no scratching or clicking noise till now during test disk execution. Please help.
Gemini said
That is actually a very good sign! The absence of clicking or grinding (the "Click of Death") suggests that the drive's mechanical arms and motors are still functioning. The Input/Output errors are likely coming from bad sectors—physical spots on the magnetic platters that have simply "worn out" or lost their magnetic charge over the last 7 years.
However, even without noise, the drive is clearly struggling. Since we can't use traditional "repair" tools due to the potential encryption and physical errors, we need to pivot to a rescue-first strategy.
Why TestDisk is "stuck"
TestDisk is trying to read the drive linearly. When it hits a bad sector, it waits for the drive to try and "re-read" that spot multiple times before moving on. This is why your progress moved so slowly.
The Plan: Use ddrescue
We are going to use ddrescue because it is "intelligent." It will copy all the easy, healthy parts of the drive first, then come back to the difficult areas later. This gives us the best chance of getting your data before the drive develops a more serious mechanical problem.
Based on your lsblk output, your 3TB Seagate (SGT) drive is mounted at /run/media/kali/SGT. We will use that as the destination.
Step-by-Step Instructions
1. Prepare the destination
We will create a folder on your healthy 3TB drive to hold the backup image.
mkdir -p /run/media/kali/SGT/Rescue_Seagate
2. Run the Rescue (Phase 1: The Fast Pass)
This command will copy everything it can read easily and skip the bad sectors for now.
sudo ddrescue -v -n /dev/sdd /run/media/kali/SGT/Rescue_Seagate/sdd_backup.img /run/media/kali/SGT/Rescue_Seagate/recovery.log
-v: Verbose mode (shows you what's happening).-n: Scrapes the healthy data first and skips the "scraping" of bad blocks to save time.recovery.log: This file is crucial. If you have to stop or the computer restarts,ddrescuewill read this log and pick up right where it left off.
3. Run the Rescue (Phase 2: The Deep Dive)
Once the first command finishes, if you still have missing data, run this to try and "force" a read of the bad sectors:
sudo ddrescue -v -d -r3 /dev/sdd /run/media/kali/SGT/Rescue_Seagate/sdd_backup.img /run/media/kali/SGT/Rescue_Seagate/recovery.log
What to do after the image is created
Once you have the sdd_backup.img file, you can disconnect the failing 1TB drive and put it in a drawer. We will then work on the file (the image):
If it's not encrypted: we can use
PhotoRecorTestDiskon the file to extract your photos and documents.If it is encrypted: we will try to identify the Ubuntu partition you mentioned, which likely isn't encrypted, and recover data from there.
Does your 3TB drive (SGT) currently have enough free space (about 1TB) to hold this backup file?
SGT partition has 743.6 GB free space left.
Gemini said
Since the SGT partition only has 743.6 GB free, it cannot hold a full image of your 931.5 GB (1TB) drive. If we try to run the recovery there, the process will fail once the destination drive fills up, which can be messy.
Looking at your lsblk output again, we have two other potential candidates:
/dev/sda2: It is 2.7TB in size and mounted at/mnt/sdb2./dev/sde4or/dev/sde10: You have multiple partitions on that 3TB drive.
Recommended Strategy: Use /dev/sda2
Based on your screenshots, /dev/sda2 seems to be your largest available space. Let's check exactly how much room is there first.
Step 1: Check free space on sda2
Run this command to see the actual free space in gigabytes:
df -h /mnt/sdb2
If it shows more than 950 GB available, we are good to go.
Step 2: The "Compressed" Recovery (The Workaround)
If you absolutely must use the SGT drive because the others are full, we can use a "sparse" image or pipe the recovery through compression, but this is riskier and slower.
However, the best way forward is to use the larger drive. Here is the command for /dev/sda2:
# 1. Create the recovery folder on the larger drive
sudo mkdir -p /mnt/sdb2/Seagate_Recovery
# 2. Start the recovery
# We use the logfile so we can stop and start without losing progress
sudo ddrescue -v -n /dev/sdd /mnt/sdb2/Seagate_Recovery/seagate_disk.img /mnt/sdb2/Seagate_Recovery/recovery.log
Important Notes for this Process:
The Logfile is Life: If the drive stops responding, you can just press
Ctrl+C, unplug/replug the drive, and run the exact same command again. It will skip everything it already finished.Don't Panic at Errors: You will likely see the "errsize" count go up in the terminal. This is normal for a failing drive.
ddrescueis designed to handle this.Time: This could take anywhere from a few hours to a day depending on how many bad sectors are clustered together.
What if the drive is smaller than 1TB?
If you realize none of your drives have 1TB of free space, you can tell ddrescue to only recover specific partitions if we knew where they were. But since your partition table is "Bad/Invalid," we have to treat the whole 1TB as one block of data to find your files.
Can you run df -h and tell me if /mnt/sdb2 has enough room?
You said
sdb2 has only 511GB free space left as of now. Also See this in /dev/sda2 "(kali㉿kali)-[~]
└─$ df -h /dev/sda2
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 2.7T 28K 2.6T 1% /mnt/sdb2
" Will that be good?, it is a failing drive too, but shows no issues as of now, Iam running this Kali Linux OS from it for past few weeks.
Gemini said
Wait, let's pause for a second. If /dev/sda2 is the partition you are currently running your Kali Linux OS from, we need to be very careful.
Your df -h output says /dev/sda2 has 2.6T available, which is more than enough room for the 1TB image. However, it's a bit unusual to have your OS drive mounted at /mnt/sdb2. Usually, the OS is mounted at /.
Check this first:
In your lsblk output earlier, /dev/sdc2 was mounted at / (your OS).
If /dev/sda2 is just a large, mostly empty storage drive that happens to be mounted at /mnt/sdb2, then yes, it is a perfect candidate.
Addressing the "Failing Drive" Concern
You mentioned /dev/sda is also a "failing drive."
If it has bad sectors: Writing a 1TB file to it might cause it to hang or fail.
The Risk: You would be trying to rescue data from one dying drive (
sdd) onto another dying drive (sda). This is like moving passengers from a sinking ship to a leaking boat.
However, if /dev/sda is the only drive with enough space, we don't have many other options. We just need it to hold together long enough to get the image file saved.
The Final Rescue Plan
Since /dev/sda2 (mounted at /mnt/sdb2) has 2.6TB free, let's use it. We will create a specific folder there to keep things organized.
Run these commands in order:
# 1. Create the directory on the large drive
sudo mkdir -p /mnt/sdb2/RECOVERY_ZONE
# 2. Start the rescue
# This will copy sdd (1TB) into a single file named 'seagate_rescue.img'
# The 'rescue.log' is vital so you can resume if either drive glitches.
sudo ddrescue -v -n /dev/sdd /mnt/sdb2/RECOVERY_ZONE/seagate_rescue.img /mnt/sdb2/RECOVERY_ZONE/rescue.log
What to watch for:
System Freezing: If the OS (on
sda) starts freezing because it's also failing, the terminal might stop responding. If this happens, you may need to rescue the data in smaller "chunks," but let's try the full pass first.Speed: If the speed drops to 0 B/s for a long time, the source drive (
sdd) has likely "stalled." You'll need to unplug it and replug it, then run the command again.
Why we aren't using TestDisk anymore
Just to reiterate: TestDisk's errors (Bad GPT partition, Invalid signature) are likely a result of that Windows encryption and MBR/GPT conflict you mentioned. But the Input/output errors mean we can't trust the hardware.
Once you have that seagate_rescue.img file on your 2.6TB drive, we can use a tool called PhotoRec on the file. PhotoRec doesn't care about "Bad Signatures" or "Encryption Headers"—it just looks for the raw data of your photos and files.
Would you like me to show you how to monitor the ddrescue progress once you start it?
┌──(kali㉿kali)-[~]
└─$ df -h /mnt/sda2
df: /mnt/sda2: No such file or directory
┌──(kali㉿kali)-[~]
└─$ df -h /dev/sda2
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 2.7T 28K 2.6T 1% /mnt/sdb2
┌──(kali㉿kali)-[~]
└─$ # 1. Create the directory on the large drive
sudo mkdir -p /mnt/sdb2/RECOVERY_ZONE
# 2. Start the rescue
# This will copy sdd (1TB) into a single file named 'seagate_rescue.img'
# The 'rescue.log' is vital so you can resume if either drive glitches.
sudo ddrescue -v -n /dev/sdd /mnt/sdb2/RECOVERY_ZONE/seagate_rescue.img /mnt/sdb2/RECOVERY_ZONE/rescue.log
[sudo] password for kali:
sudo: ddrescue: command not found
Gemini said
It looks like gddrescue (the package name for ddrescue) isn't installed on your Kali system by default. No worries, we can grab it quickly from the repositories.
Step 1: Install ddrescue
Run this command to install the utility:
sudo apt update && sudo apt install gddrescue -y
Step 2: Start the Rescue
Now that the tool is installed, run the recovery command again. I have double-checked your df -h output: /mnt/sdb2 is definitely the correct mount point for your large 2.6TB space.
# Ensure the directory exists
sudo mkdir -p /mnt/sdb2/RECOVERY_ZONE
# Run the rescue (Phase 1: Fast copy)
sudo ddrescue -v -n /dev/sdd /mnt/sdb2/RECOVERY_ZONE/seagate_rescue.img /mnt/sdb2/RECOVERY_ZONE/rescue.log
How to read the ddrescue screen
Once it starts, you will see a status screen. Here is what to watch for:
ipos (input position): Where it is currently reading on the failing 1TB drive.
opos (output position): Where it is writing in your
.imgfile.pct try (percentage): How much of the drive has been attempted.
errsize: This is the most important number. It tells you how much data is physically unreadable. A few megabytes of errors is usually fine for a 1TB drive; several gigabytes means the damage is extensive.
avg rate: If this drops to 0 B/s and stays there for more than a minute, the drive has "stuck." If that happens, you may need to
Ctrl+C, power cycle the drive, and restart the command.
A Note on your "Failing" /dev/sda
Since you mentioned the destination drive (sda) might also be failing, keep an eye on the system logs if the process feels like it's freezing. You can open a second terminal and type dmesg -w to see if the kernel is reporting errors on either sdd or sda.
Would you like me to explain how to interpret the dmesg logs if you start seeing a lot of text scrolling there?
yes, also can I keep the test disk running alongside this backup image generation?Gemini said
Actually, no—you should definitely stop TestDisk before starting the backup.
Running both at the same time is like having two people trying to drive the same car in different directions. Here is why:
Mechanical Stress: The drive head would have to jump back and forth between the area TestDisk is scanning and the area
ddrescueis copying. This "thrashing" significantly increases the heat and mechanical wear on a drive that is already failing.Contention for the "Bad" Spots: Both tools will be fighting to access the same damaged sectors. When a drive hits a bad sector, it often enters a "retry" loop at the firmware level. Having two programs trigger these loops simultaneously can cause the drive's controller to crash or lock up entirely.
Speed:
ddrescueworks best when it can read the disk linearly (in a straight line). TestDisk will interrupt that flow, making the rescue take much longer.
The Golden Rule of Data Recovery: Always prioritize the image (the copy) first. Once you have the image file on your healthy drive, you can run TestDisk on that file as many times as you want without ever touching the failing hardware again.
How to use dmesg -w
While ddrescue is running, open a second terminal window and run:
sudo dmesg -w
This will show you a live feed of "system events." Since you suspect both drives might be failing, keep an eye out for these specific keywords:
I/O errororcritical target error: This confirms physical bad sectors.sd 8:48 [sdd] ...: Any message starting withsddrefers to your failing 1TB drive.sd 8:0 [sda] ...: If you see messages aboutsda, it means the drive you are saving to is having trouble writing. This is much more serious because it means your backup might be getting corrupted as it's being made.resetting link: This means the drive connection dropped and the system is trying to "re-plug" it automatically.
Summary of next steps:
Close TestDisk (press
qorCtrl+Cin that terminal).Install ddrescue:
sudo apt update && sudo apt install gddrescue -y.Start ddrescue using the command we discussed.
Open a second terminal with
sudo dmesg -wto monitor the "health" of the process.
Would you like me to show you the command to run TestDisk on the image file once the backup is finished?
I pressed some key combination in my keyboard at the running 'testdisk'
command terminal. I think it might be Windows KEY + Insert/PrintScreen
KEY, as I wastrying to take a screenshot of the terminal. I wrongly
pressed the above combination instead of Fn(Funtion KEY) +
Insert/PrintScreen KEY for screenshot. I was given a 'STOP' prompt by
the 'testdisk' as shown in the attached screenshot for your reference. I
stopped the testdisk and got the following final output: "TestDisk 7.2,
Data Recovery Utility, February 2024
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Disk /dev/sdd - 1000 GB / 931 GiB - CHS 121601 255 63
The hard disk (1000 GB / 931 GiB) seems too small! (< 2000 GB / 1863 GiB)
Check the hard disk size: HD jumper settings, BIOS detection...
The following partition can't be recovered:
Partition Start End Size in sectors
> MS Data 1953523711 3907045374 1953521664
[ Continue ]
NTFS, blocksize=4096, 1000 GB / 931 GiB"
Gemini said
That "STOP" prompt was actually a blessing in disguise—it forced the process to halt safely and gave us a very important clue.
Decoding the TestDisk Output
The error message The hard disk... seems too small! combined with the partition it found is a "smoking gun" for your dual-boot history.
The Ghost Partition: TestDisk found a "MS Data" (Windows) partition that starts at sector
1953523711. However, your 1TB drive only has about1,953,525,168sectors in total.The Conflict: This partition is trying to exist at the very end of the disk and stretch far beyond the physical limit of the drive (it wants to go up to 2TB).
Why this happened: This usually happens when a drive was part of a "Storage Space" in Windows, a RAID setup, or if the partition table was severely corrupted during that Ubuntu install 7 years ago.
This confirms why fsck and your manual Superblock attempts failed: The "map" of the drive is pointing to places that don't physically exist.
Your Final Corrected Plan (Standard Operating Procedure)
Since we are moving to the image-based recovery, here is the complete sequence of commands for you.
1. Install the tool
sudo apt update && sudo apt install gddrescue -y
2. Create the destination folder
sudo mkdir -p /mnt/sdb2/RECOVERY_ZONE
3. Run the Rescue (The Complete Final Code)
Execute this command. It uses the logfile so that if you accidentally hit another key combination or the drive disconnects, you can just run it again and it will resume.
sudo ddrescue -v -n /dev/sdd /mnt/sdb2/RECOVERY_ZONE/seagate_rescue.img /mnt/sdb2/RECOVERY_ZONE/rescue.log
Why this is better than TestDisk
The "MS Data" partition TestDisk found is likely a "phantom" or a remnant of a deleted partition. If you had tried to "Restore" that, it would have written garbage to your partition table.
By creating the .img file with ddrescue, we can use PhotoRec (which you already have installed as part of TestDisk). PhotoRec ignores these "too small/too large" errors and just scans the raw bits for your files.
Next Step
Please run the ddrescue command above. Once it starts, it will give you a "Time Remaining" estimate.
Would you like me to show you how to check the seagate_rescue.img file size while it's growing to make sure your /dev/sda2 drive is handling the write correctly?
![]() |
| 'testdisk' before WIN KEY + Insert/Printscreen KEY pressing |
![]() |
| 'testdisk' after WIN KEY + Insert/Printscreen KEY pressing |
![]() |
| 'testdisk' after WIN KEY + Insert/Printscreen KEY pressing>> 'Yes' Option screen |
![]() |
| 'testdisk' after WIN KEY + Insert/Printscreen KEY pressing>> 'Yes' Option screen>>Disk Info Screen |
I forgot to attach the screenshots I mentioned earlier, here are they for your reference.













No comments:
Post a Comment