Bug 906946 - eject -i on does not disable hardware button
Summary: eject -i on does not disable hardware button
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: udev-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-02 00:02 UTC by Grant
Modified: 2015-06-06 09:25 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-23 17:45:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Grant 2013-02-02 00:02:29 UTC
Description of problem:

"eject -i on" should disable the hardware eject button so it doesn't pop open in a laptop case or when pressed (repeatedly...all day long) by a toddler.  This functionality works fine in Ubuntu but does not work in Fedora 17 or 18.

Please help, my 18-month old is driving my nuts by constantly ejecting and pushing in the cdrom!

Version-Release number of selected component (if applicable): eject from util-linux 2.22.1

How reproducible:

Steps to Reproduce:
1. 'eject -i on'
2. eject says "eject: CD-Drive may NOT be ejected with device button"
3. press the hardware button to eject cdrom
  
Actual results:

Cdrom ejects

Expected results:

Cdrom does nothing

Additional info:

Comment 1 Grant 2013-02-02 00:49:46 UTC
OK, little more research has shed some light on this.  The udev rule /usr/lib/udev/rules.d/60-cdrom_id.rules hears the hardware button and makes it eject without caring what's in /proc/sys/dev/cdrom/lock or anywhere else. 

If you comment out the line

ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"

then everything seems to work as expected.  Cdrom still ejects when you want it to but responds to disabling as it should.  I don't know enough about udev to know what else it breaks to comment out this line, but it works for me.  Smarter udev behavior would be great.

Comment 2 Kamil Dudka 2013-02-02 01:03:49 UTC
eject works as expected.  I am switching the component to udev...

Comment 3 Fedora End Of Life 2013-12-21 11:04:49 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Grant 2013-12-21 22:43:16 UTC
This bug is still present in Fedora 20.

Comment 5 Kay Sievers 2014-02-23 17:45:33 UTC
eject -i locks an individual cdrom, /proc is an awkward global interface
acting for all cdroms on the system.

I don't see a way to query an individual cdrom for the eject -i setting.

I'm closing this bug, it is unlikely to get changed/fixed in the kernel, and
udev should not use the awkward /proc interface.

You can always, as a local customization, copy the udev rules file from
/usr/lib to /etc and edit it there. The one in /etc will entirely overwrite
the one in /usr/lib.


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