Bug 824139
Summary: | ejected data DVD fails to fully clean up after itself, subsequently inserted DVD fails to mount | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jonathan Kamens <jik> |
Component: | udisks2 | Assignee: | David Zeuthen <davidz> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | davidz, mclasen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-05-22 21:54:02 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jonathan Kamens
2012-05-22 20:01:39 UTC
I've seen this but I'm not sure it's a udisks2 bug. Please try reproducing without udisks2 (by e.g. mounting it manually at e.g. /mnt/cdrom) and then running eject(1) without unmounting the device. Actually I just tried to reproduce this and failed - it works fine for me (I'm using Linux 3.3.4-5.fc17.x86_64). When putting in the new disc, please capture the following information - the output of 'udisksctl monitor' - the output of 'gvfs-mount -oi' captured from the desktop session as the user (not root) - the output of 'udevadm monitor --udev --property' (as root) as well as whatever lines are logged (e.g. 'tail -f /var/log/messages' or similar) and paste it here. Also attach the output of 'udisksctl dump' as a text file. I am now unable to reproduce the issue on demand with or without udisks2. I'm sure I've seen it before, and I suspect I'll see it again, but I don't know specifically what is causing it or how to reproduce it. (In reply to comment #3) > I am now unable to reproduce the issue on demand with or without udisks2. > > I'm sure I've seen it before, and I suspect I'll see it again, but I don't > know specifically what is causing it or how to reproduce it. Looking more closely at the issue, I think something inside the kernel [1] is holding the device open: May 22 15:51:27 jik2 kernel: [106279.960842] VFS: busy inodes on changed media or resized disk sr0 This means that when we try to handle the 'change' uevent in udev (on media change), cdrom_id fails because it cannot open /dev/sr0 with O_EXCL. This causes subsequent udev rules to conclude there is no medium and then we don't run blkid(8) at all. This then bubbles up the stack.... So, yeah, this looks like a bug in the kernel that is causing user space to be confused as described in the paragraph above... feel free to reopen and reassign to the kernel if you can reproduce. [1] : or something in userspace ... but nothing opens with O_EXCL by default ... and we have nothing opening the device file by default. |