Bug 26974 - Isodumper crashes when it tries to "eject" a usb flash drive at the end of the process
Summary: Isodumper crashes when it tries to "eject" a usb flash drive at the end of th...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: papoteur
QA Contact:
Depends on:
Reported: 2020-07-20 01:49 CEST by Thomas Andrews
Modified: 2020-07-21 03:12 CEST (History)
1 user (show)

See Also:
Source RPM: isodumper-1.19-1.mga7.src.rpm
Status comment:


Description Thomas Andrews 2020-07-20 01:49:47 CEST
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.
Comment 1 Dave Hodgins 2020-07-20 03:13:48 CEST
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) => davidwhodgins
Assignee: bugsquad => geiger.david68210

Comment 2 Thomas Andrews 2020-07-20 04:01:48 CEST
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.
Comment 3 Dave Hodgins 2020-07-20 05:12:35 CEST
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

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.
David GEIGER 2020-07-20 07:46:27 CEST

Assignee: geiger.david68210 => yves.brungard_mageia

Comment 4 papoteur 2020-07-20 08:29:31 CEST
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.
Comment 5 papoteur 2020-07-20 09:43:39 CEST
Release 1.20 should do the trick.
Comment 6 Thomas Andrews 2020-07-20 15:07:58 CEST
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.
Comment 7 papoteur 2020-07-20 17:45:12 CEST
Version 1.20 should arrive now.
I have asked to neoclust to withdraw 1.19 and 1.17.
Comment 8 Thomas Andrews 2020-07-20 19:26:08 CEST
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!
Comment 9 Thomas Andrews 2020-07-21 03:12:03 CEST
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.

Note You need to log in before you can comment on or make changes to this bug.