| Summary: | Optical media ejected by pressing optical device button is not unmounted (audio cds are not affected) | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Strangiato <bugseforuns> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | REOPENED --- | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | bugs, lynx.light0 |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | other | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | [PATCH] Check if cdrom drive has media on cleanup | ||
|
Description
Strangiato
2013-12-01 18:48:57 UTC
Created attachment 92238 [details] [review] [PATCH] Check if cdrom drive has media on cleanup When cleanup is run, it is supposed to remove lingering mounts. That probably works fine for card readers etc. since there's a partition exposed for the drive but fails for optical media. As a result, when mounted and user presses the drive eject button, tray is ejected but mounts lives on. This patch adds a special check for CDROM drives and looks for active media. -- The test is highly cdrom-specific and should not break anything else. On the other hand, not sure if there are e.g. card readers not exposing the "partition" device type, only presenting itself as a "disk". Haven't tested that, my concern was a flash medium having no partition table, used directly. Or, a ZIP drive (ATAPI vs. floppy mode) and such... Hmm, I'm not sure this is the right fix so please don't commit it. I'll try to reproduce this... (In reply to comment #2) > Hmm, I'm not sure this is the right fix so please don't commit it. I'll try > to reproduce this... Reproducing this is easy: 1. Insert CD/DVD media 2. Let Gnome/gvfs automount it (clean system, defaults) 3. Press the eject button on the drive 4. Watch the mount staying alive Note that udisks cleanup routine properly registers the event, it's all about matching the cleanup conditions. I have the same problem. Can you solve please? Thanks. Yes. This needs to be fixed. See: https://bugs.archlinux.org/task/42071 *** Bug 84374 has been marked as a duplicate of this bug. *** (In reply to Tomas Bzatek from comment #3) > (In reply to comment #2) > > Hmm, I'm not sure this is the right fix so please don't commit it. I'll try > > to reproduce this... > > Reproducing this is easy: > 1. Insert CD/DVD media > 2. Let Gnome/gvfs automount it (clean system, defaults) > 3. Press the eject button on the drive > 4. Watch the mount staying alive > > Note that udisks cleanup routine properly registers the event, it's all > about matching the cleanup conditions. Thomas: can you not commit your patch? This is a much needed fix, and, even if your fix is not perfect, there has been no movement towards improvement in over 6 months. This was discussed recently on the systemd (udev) mailing list: http://lists.freedesktop.org/archives/systemd-devel/2015-January/026948.html http://lists.freedesktop.org/archives/systemd-devel/2015-January/027403.html After a lot of back and forth, it was decided that the most robust fix under systemd is http://lists.freedesktop.org/archives/systemd-devel/2015-January/027577.html For the record, for distros without systemd it is easiest to adjust /lib/udev/rules.d/60-cdrom_id.rules like this: -ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end" +ENV{DISK_EJECT_REQUEST}=="?*", RUN+="/usr/bin/eject $devnode", GOTO="cdrom_end" Fixed in upstream git, will be in 219: http://cgit.freedesktop.org/systemd/systemd/commit/?id=06e97888883e http://cgit.freedesktop.org/systemd/systemd/commit/?id=3b48ce4ec This problem is back in Fedora 23 64 bits. This problem is back in Arch linux with systemd 229 too. Any progress with this annoying and old bug? This is still present on Arch running with systemd 231. Any comment about this report? This problem is still happening with systemd 233 on Arch. This is not a systemd bug. I am testing a distro without systemd (it uses OpenRC) and the same problem happens. Can anyone tell me where is the problem? Can it be a kernel bug? |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.