Hitting eject on DVD drive does not result in media being unmounted. Putting in new DVD results in DVD read errors. Steps to reproduce: - enter DVD - eject DVD using drive eject button - put in different DVD - $mount |grep sr0 - $dmesg DVD playback of new disk will not work and errors issue in dmesg such as: [ 2348.391264] end_request: I/O error, dev sr0, sector 12134268 [ 2348.391267] Buffer I/O error on device sr0, logical block 3033567 Whilst I have seen it argued that a user should always unmount and eject using software and not via DVD drive optical button, to me it seems like a perfectly ordinary usage scenario to want to eject using the drive button, particularly in the case of ROM media. See discussion wrt Ubuntu: https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1168742 Archlinux: https://bbs.archlinux.org/viewtopic.php?pid=1459388#p1459388
This is not a kernel bug. We do use thelock options when we can, and userspace can hook the button events in some cases, but at the end of the day it expects unmount.
(In reply to Alan from comment #1) > This is not a kernel bug. > > We do use thelock options when we can, and userspace can hook the button > events in some cases, but at the end of the day it expects unmount. As I see it, there are two clear options: 1) allow eject button to work and gracefully handle it; 2) do not allow eject button to work. But right now we allow the drive to eject and read errors to ensue. "at the end of the day it expects unmount". This seems like an arbitrary case of 'computer says no' and rather a cop out; why should users be forced to unmount via software ROMs rather than having software gracefully handle an eject operation on a drive? Rather than gracefully handling an eject operation, the unwitting user is instead presented with horrible read errors on the next ROM. Is there anything preventing graceful handling of drive eject operations?
It depends whether the drive implements notifiers for the eject button. Most don't so the choices are 1. Lock the drive so you can't do anything unless you eject the disk in software. Users generally hated this! 2. Leave it unlocked so you can but might get spewage if you do silly things. for such devices.
3. Gracefully handle eject operations for those drives that do implement the notifiers, which is currently being done, and hence this bug report.
*not currently being done
For the drives with notifiers it should be done, but wht happens will depend upon your desktop GUI and how it chooses to handle the events.