Description of problem: Isodumper frequently (not always) crashes after it is finished checking the target drive, but before telling the user the drive can be removed. When run from a gui menu, the isodumper window simply disappears. If run from the command line as a non-root user, the following message appears in the terminal window: g-io-error-quark: GDBus.Error:org.freedesktop.UDisks2.Error.DeviceBusy: Cannot eject drive in use: Device /dev/sdd1 is mounted (36) When this happens, the log in the user's .isodumper folder is empty. Running as root makes no difference. It doesn't seem to affect the integrity of the newly-created flash drive, as it doesn't happen until after the verification process is complete. If it happened earlier, I would call it a "major" bug. Affected DE/hardware: 64-bit Plasma system on an i5-2500, 16GB RAM, Intel video, usb2.0 drive in a usb2.0 port. This motherboard does have usb3.0 ports, but I'm not using them for this. Other DEs/hardware may be affected, but I have not tried isodumper on other hardware lately. Version-Release number of selected component (if applicable): isodumper-1.19-1.mga7 While I am citing the version currently waiting to be pushed as an update, I have also seen it in previous versions. How reproducible: It does it more often than it doesn't. Steps to Reproduce: 1. run isodumper 2. dump an iso to a usb drive 3. wait for it to say it is OK to remove the drive. When you hit the bug, it will simply crash.
When I manually run dd to copy an iso image to a usb drive, I've learned that dd may exit and return to the shell prompt. I use htop sorted by state, which shows ... 102 root 20 0 0 0 0 D 0.0 0.0 0:00.11 kworker/u16:10 5089 root 20 0 0 0 0 D 0.0 0.0 0:00.04 kworker/2:1 The D (device wait) in the S (state) column indicates it hasn't finished copying yet. Note that the sync command only works for file systems, but since the usb stick is a block device, not a file system, the sync command has no affect. isodumper may need to be modified to wait until all kworker threads have stopped showing a state of device wait for a few seconds. Assigning to daviddavid who has made the most recent changes.
CC: (none) => davidwhodginsAssignee: bugsquad => geiger.david68210
Hmmm. Since starting to use this machine, with twice the RAM and cores/threads of any of my others, I've noticed that often Plasma will indicate a large copy has finished, when in reality it has not. The larger the copy, the more time there seems to be before Plasma will signal that the device can be removed. I've always thought the data was being buffered into the unused RAM until the target device was ready to accept it. If that is what's happening here, that means that the verification phase isn't reading just what's actually on the device, but what's still in the buffer as well. And that would mean the actual contents of the device haven't been properly verified after all.
That's my understanding too, in the case where the writing has not yet completed that the kernel will read the unwritten sectors from the buffer rather then waiting for them to be on the physical device. The isodumper program should be modified to wait for the kworker threads to finish writing, before it starts reading for verification. I have no idea why dd sometimes exits before the device has been fully written, and sometimes does wait. I just know that it does that thanks to the usb stick having a light that indicates the activity is still in progress, and finding problems when not waiting for that light to stop flashing. The annoying part is that the kworker threads will at times show a state of sleeping for a second or so, and then go back to a device wait state, so it isn't just a matter of waiting for the thread to exit from the device wait state. The wait has to be such that the threads are in a sleeping state for several seconds. Also, if others tasks are writing on other devices, there will be kworker threads showing device waits. I don't know how to tell which kworker thread is writing to which device, or if that's how the kernel uses kworker threads. One relatively simple alternative would be to put the eject command in a loop until it succeeds with a sleep command in that loop too, though that would make verification impossible.
Assignee: geiger.david68210 => yves.brungard_mageia
Hello, Thanks Thomas for reporting. > g-io-error-quark: GDBus.Error:org.freedesktop.UDisks2.Error.DeviceBusy: Cannot eject drive in use: Device /dev/sdd1 is mounted (36) TMB said that the only way to know if the write ahs ended is to command the ejection, what isodumper does now. As you can say, in the mean time, the EFI partition is automatically mounted, and that the problem. Thus, there is only two ways: - prevent the automatic mounting - unmount the partition before the eject. I will try something.
Release 1.20 should do the trick.
If it's been put into updates_testing, it hasn't hit my mirror yet. qarepo only finds version 1.17 and 1.19. (1.19 has been validated, and is waiting for an advisory so it can be pushed. 1.17 should be removed from testing.) While I'm waiting for it, I was going to offer that I tried 1.19 this morning on an older machine (Dell Dimension e520, Core 2 Quad Q6600, 4GB RAM) and I did not see the problem. I only tried two isos, but that would have been enough on the newer system.
Version 1.20 should arrive now. I have asked to neoclust to withdraw 1.19 and 1.17.
In for lunch, so I thought I'd take a look. At the moment, 1.17 is gone, but 1.19 is still there. Updated from 1.19 without issues. Tried a couple of Mageia 8 isos, one CI, one Live, so that it tried different sizes. In the past, one of them would have triggered the bug. Both trials were successful. Two are all I have time for now, and not really a thorough enough test, but I will try more this evening. For now, it's looking very promising. Good job!
I think we have a winner here. I tried three more isos, and all were successful. I don't think I've had that many in a row on this machine before this.
I see 1.20 in core/updates/ , and highest lower version is 1.16 Ready to close as fixed?
CC: (none) => fri
Yes. This problem was fixed as part of final update version in Bug 26776.
Status: NEW => RESOLVEDResolution: (none) => FIXED