Recently, I've encountered a bug where the desktop freezes.

The main suspect (From top and iotop) is a kworker: top iotop.

The system starts normally, than completely freezes shortly thereafter (Like < 1 minute) every time.

I'm saving the @ directory on my hard drive just in case someone wants to check it out later, but I'm restoring from a backup for now to restore functionality.

The thing is that this happened to me previously, and I had to restore the @ directory before.

I figured that it was some weird one off thing, but it's back again. So this is something more serious.

Has this bug been reported before? Is there a fix/workaround for it? It doesn't appear to be kernel related because I used the new 15.0.0-13 kernal provided by the new release and the old 4.15 kernel that I used in 18.04 before the upgrade.

HardInfo Report (Hardware Specs): Make/Model: HP ENVY 17 (It's a bit old) HTML Report: https://www.dropbox.com/s/hi04u0a09h7l3ai/hardinfo_report.html?dl=0

EDIT 0: More Information Surfaces:

I've tried to isolate the source of the error further. I've isolated it to my hard drive configuration. My HP ENVY 17 has two hard drive bays and I'm using both of them. My OS is on the SSD (500GB Samsung 860 EVO) and the other is an OEM 1TB traditional HDD.

From my post on HP forums asking for more information:

When I powered off, I discovered that I couldn't use the linux live USBs (Basically another OS that you can do maintaince for your everyday OS that resides on a USB). They would just load forever.

I made a few posts online to try and diagnose the issue and was recommended to check the ribbon cables.

My OS resides on the SSD, and I lifted the connectors and pulled out the ribbons and re-placed them back in position.

No luck, but then I tried pulling out the SSD and letting GRUB (The Grand Unified Bootloader) try and boot from the USB now.

This was effective, but I did more testing. I tried putting in the SSD and pulling out the traditional HDD. This did not work. I tried using the SSD but with the other HDD connector on the motherboard, no dice. I retried various configurations of HDD and connector matching hoping to get something to work, but it seems that every time the SSD is in a connector, the live USB's will not boot and that every time the SSD is not in one of the connectors, the USBs will boot.

The strange thing is that this SSD is not new. I've been using it for a while (2-3 Months) with no issues. Then I did the upgrade from Kubuntu 18.04 to 19.04 and everything went fine. Then the next week everything is unbootable. I didn't even take the computer with me anywhere or open it up. Just software changes. I didn't touch the BIOS at all in this time period.

But the SSD isn't the end of the story. If the SSD was the problem, then wouldn't this have been a binary "It just doesn't work for X reason"?

Why was it working for a few months and then suddenly it just kicks the bucket? Why can't I boot from a live USB when it's connected?

The most proximal cause of this (The only change I made to the system, software or otherwise) is the upgrade from 18.04 -> 19.04.

How does a software upgrade trigger a hardware fault (Assuming this is the cause), and can it be compensated for?


I removed the SSD and attached it using a USB cable. The filesystem was unmountable. I tried using btrfs recover, but it wasn't worth it as I had a backup the day before. I tried it anyway initially and discovered that every folder from @home was missing except for the Desktop.

I don't know why this happened, but after totally formatting the drive using btrfs, and installing a fresh Kubuntu 19.04, hopefully things will be better. The SMART test and long form SMART tests both passed, and I didn't see any errors.

I also confirmed that the SSD will boot again (Using the fresh Kubuntu 19.04) while using the ribbon cable internally. I think that the no-boot incident was due to the damaged nature of the filesystem on the SSD, although I don't know why this negatively effected the ability to boot a live USB.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.