[KDE] gnome-disk-utility causes desktop to freeze up

[Jerry]

Hello,

I have a fairly new install of Kubuntu-18.04.2 64 bit on my Lenovo X140e netbook.

It runs and looks good, but I have this one issue. Every time I use gnome-disk-utility to write an .iso image to a USB flash drive the KDE desktop freezes up when the process is finished. When I close out the gnome-disk-utility window, nothing else on the desktop responds. The mouse still works, so I can move the cursor around and click on things, but nothing responds. If I wait, the desktop returns to normal in about four minutes.

Just wondering if anyone else has experienced this problem, and if there's a fix for it.

Also, I was wondering of there's a KDE way of doing the same task.

My machine:

[jcig@kubuntu ~]$ inxi
CPU~Quad core AMD A4-5000 APU with Radeon HD Graphics (-MCP-) speed/max~864/1500 MHz Kernel~4.15.0-46-generic x86_64 Up~7:38 Mem~3180.9/7245.2MB HDD~628.3GB(18.6% used) Procs~186 Client~Shell inxi~2.3.56

Thanks!

[Rainmaker]

I have the same problem with gnome-disk-utility. Total desktop freeze.
For partition tasks, I now use partitionmanager. And for writing .isos to usb, I either use usb-creator-kde, which is in the repos, or my preferred writer is mkusb:
https://help.ubuntu.com/community/mkusb

[Jerry]

I have the same problem with gnome-disk-utility. Total desktop freeze.
For partition tasks, I now use partitionmanager. And for writing .isos to usb, I either use usb-creator-kde, which is in the repos, or my preferred writer is mkusb:
https://help.ubuntu.com/community/mkusb

Rainmaker -- Thank you for these tips. I read the description for mkusb and it looks pretty good, I think I'll install it and give it a try.

[jlittle]

Two disparate points:

• 
  The slowness may be a Linux I/O scheduler issue.
  <discussion=possibly irrelevant>These problems have hit only some systems for a long time, but were sufficiently rare that the Linux devs seemed to deny the problems' existence for years, and there was an underground community of people patching their kernels to avoid it. When I struck a problem about 5 years ago it was just like you report, the desktop becoming unresponsive until I/O to the USB device completes several minutes later; some brain dead scheduling and caching would result in the rest of the system, including the pager (WTF?), being starved of I/O and physical memory. When SSDs became common the problems became mainstream and action was taken, but I'm not sure if the tweaks (f.ex. echo deadline | sudo tee /sys/block/sdX/queue/scheduler) are useful with USB sticks. My hardware with the problem died some years ago.</discussion>
• The multiboot USB approach is far simpler and can be much faster.

[Jerry]

I have mkusb installed and working. I guess I'll just go with that for now. Since that's not a real solution, but only a workaround, I'm leaving the thread open for now.

[oshunluvr]

If you're just burning images to USB, try Etcher. Works great and I've never had it lock up my system.