I use Ubuntu for development on an HP Victus 15 with 16 GB of RAM and a 512 GB SSD. Ubuntu has about 100 GB allocated, with roughly 43 GB still free. After switching from the Docker CLI to Docker Desktop, RAM and swap usage suddenly reached 100%, causing the system to freeze. I forced the laptop to shut down, and afterward the BIOS began showing "Boot Device Not Found."
The laptop briefly booted after I moved it, but the problem returned. While investigating, I found a kernel error indicating an NVMe I/O failure: "nvme0n1: I/O Cmd... LBA 996971552 I/O Error Critical Medium Error." I removed and reseated the SSD and cleaned its contacts, but the boot error continued.
I also connected the SSD to an older laptop, which detected it well enough to display a Windows recovery message saying that a required device was missing or inaccessible. I'm trying to determine whether the SSD itself is failing, whether the M.2 slot is defective, or whether the Docker-related memory pressure caused another issue. What is the most likely root cause, and what tests should I perform before replacing hardware?
2 Answers
Docker Desktop may have triggered the freeze by consuming memory and swap, but it is unlikely to create a hardware-level NVMe medium error. The high memory usage was probably a separate issue or simply exposed an already failing drive when the system became unstable.
The recovery screen on the older laptop does not prove that the SSD is healthy; it may only mean that the firmware could read enough of the drive to find the Windows boot information. A drive can be partially detectable while still having serious unreadable sectors. Also, physically shaking or moving the laptop should not be treated as a repair—it may only change pressure on a marginal connection temporarily.
The “Critical Medium Error” is the strongest clue here. It usually means the NVMe drive reported an unreadable or failed area of its flash media, rather than a RAM problem. The boot failure and the fact that the drive behaves inconsistently after being moved also fit a failing SSD, although a bad connector or M.2 slot is still possible.
If the drive is detected at all, boot from a Linux live USB and immediately copy any important files. Then check its health with `smartctl` or a graphical tool such as GSmartControl. Look for critical warnings, media/data integrity errors, error-log entries, and the overall SMART/NVMe health status. Avoid filesystem repair or stress tests until your data is backed up, since those can make a failing drive worse.
After backing up, test the SSD in a known-good NVMe enclosure or another compatible computer. If it shows the same errors there, replace the SSD. If another SSD works reliably in the HP’s slot while this drive fails elsewhere, that confirms the original drive is bad. If multiple known-good drives fail in the HP slot, then investigate the slot or motherboard.
I can’t boot into either operating system now, so I wasn’t sure how to run the health check. I’ll try using a live USB and focus on backing up the files first.