| Summary: | Isodumper crashes when it tries to "eject" a usb flash drive at the end of the process | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Thomas Andrews <andrewsfarm> |
| Component: | RPM Packages | Assignee: | papoteur <yvesbrungard> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, fri |
| Version: | 7 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | isodumper-1.19-1.mga7.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Thomas Andrews
2020-07-20 01:49:47 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 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.
David GEIGER
2020-07-20 07:46:27 CEST
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 =>
RESOLVED |