[SOLVED] SSD Drive Disappeared

[smokey01]

I was experimenting with QEMU when suddenly my drive icon disappeared from the desktop.

Rebooting didn't help

I was playing with drive switches.
It appears the file system has been corrupted. Below is from testdisk.log.

Code: Select all

Fri Jan 10 09:04:02 2025
Command line: TestDisk

TestDisk 7.2, Data Recovery Utility, February 2024
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
OS: Linux, kernel 6.10.2 (#4 SMP PREEMPT_DYNAMIC Sun Aug 11 02:22:58 AEST 2024) x86_64
Compiler: GCC 12.2
ext2fs lib: 1.47.0, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none, curses lib: ncurses 6.4
/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/sdb: LBA, HPA, LBA48 support
/dev/sdb: size       5860533168 sectors
/dev/sdb: user_max   5860533168 sectors
/dev/sdb: native_max 5860533168 sectors
/dev/sdc: LBA, HPA, LBA48, DCO support
/dev/sdc: size       468862128 sectors
/dev/sdc: user_max   468862128 sectors
/dev/sdc: native_max 468862128 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop10 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop11 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop12 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop13 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop14 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop15 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop2 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop3 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop4 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop5 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop6 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop7 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop8 - 0 B - 0 sectors, sector size=512
Warning: can't get size for Disk /dev/loop9 - 0 B - 0 sectors, sector size=512
Hard disk list
Disk /dev/sda - 3000 GB / 2794 GiB - CHS 364801 255 63, sector size=512 - TOSHIBA DT01ACA3, FW:ABB0
Disk /dev/sdb - 3000 GB / 2794 GiB - CHS 364801 255 63, sector size=512 - WDC WD3001FAEX-0, FW:1L01
Disk /dev/sdc - 240 GB / 223 GiB - CHS 29185 255 63, sector size=512 - WDC WDS240G1G0A-, FW:1000
Disk /dev/sdd - 123 GB / 114 GiB - CHS 14959 255 63, sector size=512 - SanDisk 3.2Gen1, FW:1.00
Disk /dev/mdev.seq - 4 B - CHS 1 255 63, sector size=512
Disk /dev/loop0 - 161 MB / 154 MiB - 315680 sectors (RO), sector size=512
Disk /dev/loop1 - 481 MB / 459 MiB - 941056 sectors, sector size=512

Partition table type (auto): Intel
Disk /dev/sdc - 240 GB / 223 GiB - WDC WDS240G1G0A-
Partition table type: Intel

Analyse Disk /dev/sdc - 240 GB / 223 GiB - CHS 29185 255 63
Geometry from i386 MBR: head=255 sector=63
check_part_i386 failed for partition type 83
Current partition structure:
No ext2, JFS, Reiser, cramfs or XFS marker
 1 * Linux                    0  32 33 29185  61 60  468858880
 1 * Linux                    0  32 33 29185  61 60  468858880

search_part()
Disk /dev/sdc - 240 GB / 223 GiB - CHS 29185 255 63

block_group_nr 1

recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=1/1788, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 58607360
recover_EXT2: part_size 468858880
Filesystem created: Sun Jul 29 17:50:08 2018
     Linux                    0  32 33 29185  61 60  468858880
     ext4 blocksize=4096 Large_file Sparse_SB Backup_SB, 240 GB / 223 GiB

Results
   * Linux                    0  32 33 29185  61 60  468858880
     ext4 blocksize=4096 Large_file Sparse_SB Backup_SB, 240 GB / 223 GiB

Hint for advanced users: dmsetup may be used if you prefer to avoid rewriting the partition table for the moment:
echo "0 468858880 linear /dev/sdc 2048" | dmsetup create test0

interface_write()
 1 P Linux                    0  32 33 29185  61 60  468858880
write!

write_mbr_i386: starting...
write_all_log_i386: starting...
No extended partition
Need to fix
 1 P Linux                    0  32 33 29185  61 60  468858880
     ext4 blocksize=4096 Large_file Sparse_SB Backup_SB, 240 GB / 223 GiB
You will have to reboot for the change to take effect.
SIGHUP detected! PhotoRec has been killed.
SIGTERM detected! PhotoRec has been killed.

Gparted can see the drive but doesn't recognize the filesystem.

Code: Select all

lsblk /dev/sdc1
NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sdc1   8:33   0 223.6G  0 part 
# 

There is a lot of information on this drive I would like to recover.

Does anyone have a reliable solution in restoring this SSD drive please?

Thanks

[wizard]

@smokey01

In Gparted, try right clicking the "unknown" partition and choose "check".

You might also try MS Windows, chkdsk. Have recovered several USB HDD drives with that.

How was the drive partitioned and formatted? GPT or MSDOS partition table?

wizard

[smokey01]

@wizard it's a Linux partition ext4. It's not a USB drive. It's an internal SSD 240GB drive.

Thanks

[wizard]

@smokey01

Afraid that was the case, my recovers were on NTFS drives that were used for file storage. Will think on it and let you know.

wizard

[Clarity]

Hello @smokey01

Sorry for this loss. Can I see the QEMU stanza you were using? I think I've seen this before in my past.

[smokey01]

Hello @smokey01

Sorry for this loss. Can I see the QEMU stanza you were using? I think I've seen this before in my past.

Thanks.

I've been using Qemu this way for years without a problem.

Everything is gone including stanza's. I will try and recreate it.

[Clarity]

Did the problem surface after running in a VM with this drive mounted in the host system as well as mounted in the VM?

[smokey01]

Did the problem surface after running in a VM with this drive mounted in the host system as well as mounted in the VM?

Yes. That's when I noticed the drive icon on the desktop disappeared.

[smokey01]

@smokey01

Afraid that was the case, my recovers were on NTFS drives that were used for file storage. Will think on it and let you know.

wizard

Thanks

[Clarity]

'Ah'. And I will assume you had this disk define in QEMU as "RAW'. So the file table at the front of the drive is mangled by the 2 different OSes interacting with the same drive ... unaware of each other. There 'may' be a partition-table copy at the end of the partition-drive. And this is what @wizard/@bigpup were hinting at via GParted.

The only resolution I am aware of is via TESTDISK. But you must research this on the web. I seem to remember, too, that I never was able to resolve, so I quickly gave up BEFORE seeing someone on the web posting a TESTDISK resolution to this very issue. But at that point I have already goofed-up my drive. Cant find my notes on this phenom (I should have saved it).

FYI

[smokey01]

I don't use a virtual disk. Maybe I should.
I extract the initrd and vmlinuz and load them directly in the QEMU Virtual Manager. See image.
Gparted won't let me check the partition as it's greyed out.

[Clarity]

I am unfamiliar with the utility that you show: "Editing FD903" Where does this come from?

[smokey01]

I am unfamiliar with the utility that you show: "Editing FD903" Where does this come from?

It's the Qemu virtual manager in Fatdog64. It's actually located in the Devx.

[Clarity]

The DEVX. That's why I've never seen it before. I'm guessing its a FD exclusive to replace PUP's "qemu_gui" utility.

[smokey01]

Correct. Written by James himself.

[p310don]

BUGGER

Do you have spare drives to copy data to?

A few suggestions....

Run testdisk to copy files - it's good, but gives jibberish file names
I think photorec is better for recovering the files themselves

Perhaps you can use dd to create an image of the drive, and then try to recover the image, rather than the original drive.

[p310don]

Grant, try the details here:

https://rajind.dev/2017/04/27/recoverin ... /#more-710

It is for recovering an accidentally formatted drive, but it may have a similar solution

[smokey01]

Grant, try the details here:

https://rajind.dev/2017/04/27/recoverin ... /#more-710

It is for recovering an accidentally formatted drive, but it may have a similar solution

Thanks for that @p310don it did the trick.

Code: Select all

fsck -v /dev/sdc1

When it ask to fix it, I said yes.

Next time I'm in Brisvegas it's my shout.

Thanks again.

[p310don]

Awesome that it worked. Now, make back ups

[smokey01]

Awesome that it worked. Now, make back ups

I had backups but they were a a few weeks old. The new back ups were done within 5 mins of recovery.
I didn't think fsck would work because the drive wasn't visible.
Thanks again.