Running Manjaro, My Samsung 840 pro SSD seems unrecognized by BIOS or Ubuntu live USB on different machine
It was working fine prior to Changing/Updating Nvidea drivers - this caused grub to break but BIOS still recognized a drive during boot.
Moving on.
Plugging the SSD into a USB to SATA in a Live Ubuntu USB env
sudo dmesg
usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
usb 2-1: Product: ASM1351
usb 2-1: Manufacturer: SABRENT
scsi host1: uas
scsi 1:0:0:0: Direct-Access SABRENT ASM1351 0 PQ: 0 ANSI: 6
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 1:0:0:0: [sdb] Spinning up disk...
..................................................................................................not responding...
sd 1:0:0:0: [sdb] Read Capacity(16) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
sd 1:0:0:0: [sdb] Sense Key : Not Ready [current]
sd 1:0:0:0: [sdb] Add. Sense: Logical unit is in process of becoming ready
sd 1:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
sd 1:0:0:0: [sdb] Sense Key : Not Ready [current]
sd 1:0:0:0: [sdb] Add. Sense: Logical unit is in process of becoming ready
sd 1:0:0:0: [sdb] 0 512-byte logical blocks: (0 B/0 B)
sd 1:0:0:0: [sdb] 0-byte physical blocks
sd 1:0:0:0: [sdb] Test WP failed, assume Write Enabled
sd 1:0:0:0: [sdb] Asking for cache data failed
sd 1:0:0:0: [sdb] Assuming drive cache: write through
sd 1:0:0:0: [sdb] Preferred minimum I/O size 512 bytes not a multiple of physical block size (0 bytes)
sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (0 bytes)
sd 1:0:0:0: [sdb] Attached SCSI disk
sudo fdisk -l
/dev/sdb 0 bytes
Any suggestions where to go from here, I hope all data is not lost.
Can you still read/test the disk with smartctl? If so, what does it say?
EDIT: If it fails, try to connect the disk directly without USB.
EDIT2: I have two SSDs connected via USB, and neither reports “Spinning up disk…”
I’m afraid that model was known for precisely this. Samsung released firmware updates to improve reliability. Did you ever update the firmware, or is it the same one that came with the hard drive?
@pwx I will update you when I am back home regarding smartctl etc
Thanks for your EDIT2, I also thought it was weird to see Spinning up disk for a ssd, assumed it was just old linux code
Research also shows it maybe stuck in a frozen/protective/busy state
I’m wondering if a firmware upgrade will still be possible with the drive in this state, and whether it would actually fix it now, or permanently destroy any data on the device.
Assuming a firmware issue, this could well have damaged the data structure.
If the data is really important, then I’m afraid the only option might be to send it to a data recovery lab, but that isn’t exactly cheap.
Changed live iso to systemrescue as it has more progs readily suited.
sudo hdparm -I /dev/sda
hangs for around 6 seconds and prints
/dev/sdb:
sudo smartctl -a /dev/sda
Read Device Identity failed: scsi error device will be ready soon If this is a USB connected device, look at the various --device=TYPE variants...
`
@BG405
I don’t mind not updating the firmware, I really need to just get the data off and onto a new SSD.
I do have a hot air rework station + soldering iron + amscope, do you think I could buy an identical same model drive and swap the controller or nand chips over?
You did boot a live image from that same system, as the first step, right? (I just see: doesn’t boot, try in USB enclosure.)
Just to have it in two completely different systems doing the exact same thing.
If you’ve done this small before, I still think it would be still considered advanced.
I’ve only heard there can be issues, as there is so much SSDs do now:
So if you do swap them perfectly there can be problems with:
Data is tied to the controller (and firmware)
You mess up wear leveling, mapping tables, etc.
The drive may not recognize the chip at all
But these are just random posts I’ve seen. May matter how old the drive is too, identical models over time often get new insides. But that might not even matter, they are so advanced there is no telling what it may do with something unexpected.
I didnt boot the live iso’s from the same system, no, I did it from a laptop.
Is that an issue? I could try from the same system if you think so.
The original ssd system was a manjaro ssd.
Ive now tried ubuntu live iso, and systemrescue iso.
Both give the same dmesg results - spinning up… no response, sdb 0 bytes etc.
Also worth noting, I haven’t used this SSD much at all over the years, very little usage despite its age, IE very low NAND wear.
I am now about to try an apparent power trick, which is to apply the Power cable to the SSD for 30+mins but not the SATA data cable.
Connect only the SATA power cable (no data cable) to the SSD using a desktop PSU or adapter, then power on for 30-60 minutes—this triggers an internal firmware reset that clears corrupted cache/metadata without erasing user data. Power off for 30 seconds, repeat once, then reconnect the data cable and test
Why It Works for 840 Pro
Samsung 840 Pro SSDs (like the 840 EVO series) had widespread firmware > issues causing sudden “brickage” due to corrupted translation tables or NAND mapping. The power-only cycle grants idle time for the controller’s self-repair (like a built-in chkdsk), often succeeding where smartctl shows errors but data is intact.
Step-by-Step Guide
Use a desktop PC or external PSU—plug power only (wider SATA connector).
Power on; leave idle 30-60 min (BIOS if needed, no OS load).
Power off 30 sec; repeat cycle.
Add data cable; boot and run smartctl -a /dev/sdX to verify.
Backup data immediately, then update firmware if possible.
Success rate: Anecdotal (works for many 840/860 users), but not guaranteed—fails on severe NAND wear. If no spin-up or power draw, it’s likely hardware-dead (pro recovery needed).
Modern SSD drives self-encrypt data. They store cryptographic keys in the controller and when you perform a “Secure Erase” all that they do is deleting those cryptographic keys so data becomes unrecoverable. Be careful if you separate chips (encrypted data) and controller (encryption keys).
I will try in another machine to confirm the 0 byte status.
Ai provides.
The smartctl -a /dev/sdc error “read device identity failed: scsi error device will be ready soon” confirms your Samsung 840 Pro 512GB SSD is likely in a “busy” (BSY) state, a known firmware/microcode failure mode where the controller gets stuck during initialization and rejects commands like SMART queries.
The smartctl -i /dev/sdc --device=auto command failing with the same “read device identity failed: scsi error device will be ready soon” confirms your Samsung 840 Pro 512GB SSD’s controller is stuck in a Busy (BSY) or non-Ready (RDY) state—a classic firmware/microcode failure in this model where it can’t complete initialization, blocking all ATA/SCSI commands including identity reads.
Looks like the 2nd paragraph is sure its stuck in BSY or RDY state…
now to find if I can buy another SSD and swap controllers…
EDIT : smartctl -a /dev/sda -d test
/dev/sdb [SAT]: Device of type 'sat' [ATA] detected
/dev/sdb [SAT]: Device of type 'sat' [ATA] opened
This exact pattern—initial SAT detection/open success followed by a hang or timeout—is the hallmark of the 840 Pro’s BSY (Busy) firmware failure. The controller passes basic SCSI handshakes but locks up during deeper ATA commands (like ATA IDENTIFY DEVICE), preventing SMART reads due to incomplete firmware loading or NAND translation table corruption
Immediate Actions
Data-critical: Ship to a specialist (e.g., Data Clinic, Kroll Ontrack) for safe-mode pin-short + chip-off recovery (ÂŁ400-ÂŁ1000). Stop all power cycles/tests now.
The data for encryption and mapping is stored not only on the controller but also, in part, in the memory chips themselves. A new controller would not be able to process the encryption or the specific mapping tables because it only knows part of the mapping.
I’m no expert; I’ve just watched too many data recovery videos.
If this particular model encrypts data internally…the thing belongs in the trash bin. Otherwise a controller swap or reflashing its firmware through serial port communication or chip flasher after desoldering may fix it.
I guess this is now the couple of hundred bucks (for a specialist to fiddle with the controller chip) question. Try to find info on this. And decide if the data is worth the money at all, even if decrypted. I guess contacting a specialist asking if this model/revision is salvageable and how much will it cost ist most meaningful thing you can do.
If the SSD is fried, in any of the ways described so far or any other way, the only sure way to get the data back is if you made a backup. Replacing the failed hardware with good hardware and restoring form backup is the only SURE way and the least expensive. Regular and generational (tested and verified)) backups are the traditional best answer. It is still the best answer. If you have no backups you will have to soldier on, and hope. Best of luck!
% an inaccessible disk in two systems. (And completely eliminate the chance the enclosure is causing the 0 byte device.)