+++ This bug was initially created as a clone of Bug #739944 +++ Description of problem: Fedora 16 always locks media, and relies on eject request events to invoke the unlock/eject sequence from udev. But when booting the install image (I tried rescue mode), the polling interval is not set by udev, and the tray remains locked. Version-Release number of selected component (if applicable): 16.14.6 (F16-alpha) How reproducible: 100% Steps to Reproduce: 1. Boot a Fedora 16 netinst CD in rescue mode 2. Initialize rescue mode (I chose not to start network interfaces) and enter a shell. 3. Try to eject the CD. Actual results: CD is locked and doesn't eject. Expected results: CD is locked, but udev sees the eject_request event, unlocks it and ejects it. Additional info: The problem is that polling CD-ROM drives is not enabled. From BZ739944: > Kay, how does this behavior of udev-172 work exactly, when there are no async > events and polling is disabled? > > $ cat /sys/block/sr0/events_async > $ cat /sys/block/sr0/events > media_change eject_request > $ cat /sys/block/sr0/events_poll_msecs > -1 > $ cat /sys/module/block/parameters/events_dfl_poll_msecs > 0 > > --- Additional comment from kay on 2011-09-20 18:14:04 EDT --- > > It relies on a recent kernel, polling will be enabled > by default by udev rules: > # grep . /sys/module/block/parameters/* > 2000 > > --- Additional comment from pbonzini on 2011-09-21 04:56:40 EDT --- > > > polling will be enabled by default by udev rules: > > Apparently this doesn't work when booting the rescue image. Cloning the bug.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19