Red Hat Bugzilla – Bug 37724
autoeject always on
Last modified: 2013-03-13 00:45:46 EDT
I have an IDE CDROM attached as the secondary master drive (/dev/hdc).
Since upgrading to Red Hat 7.1, the drive ejects every time the disc is
unmounted. The autoeject feature has not been enabled locally:
$ cat /proc/sys/dev/cdrom/autoeject
Additionally, autoclose is not working, but:
$ cat /proc/sys/dev/cdrom/autoclose
Clearly, something is weird, so I tried reversing the value of autoeject (since
that's the one that's iritating me):
# echo 1 > autoeject
That didn't fix it, so I tried changing it back:
# echo 0 > autoeject
Now, autoeject is off, like it should be. So, the following are true:
1) The system was originally behaving as if autoeject was "1", but reading
autoeject indicated that it as "0"
2) Changing the value of autoeject didn't turn off the autoeject behavior
3) Changing the value of autoeject back to "0" *did* turn off the autoeject
What has me confused is #1. Doesn't reading from the files in /proc return
values from kernel memory? Why would autoeject say 0 when it behaved like 1?
Both the magicdev and autorun programs are known to cause these effects.
The /proc variables are "global" defaults, and can be overridden per device.
My bet is that "rpm -e magicdev" will fix this.
I disabled autorun/magicdev in the GNOME control panel and the problem hasn't
come back yet. Since there's no indication that this will happen in the GNOME
control panel, should this be considered a bug? Is there a way to turn it off?
If not, then I'll just carry on without them. (I use automount for my removable
I consider changing this behavior a bug. I'll assign to the magicdev package
to see if it can be fixed in that package.
Magicdev doesn't touch the autoeject flags. It copied code from
autorun that did turn autoeject off, but I disabled that as
of the version in 7.1.
So, I don't think this explains the problem.
There were some fairly serious non-workingness in the autoeject
functionality at one point. I sent a patch to Alan and Jens,
but I'm not sure if it made it in or not.
The autoeject bug mentioned above is filed as #50627. Looking at
it again, it doesn't seem to be related. (Except as pretty good
evidence that autoeject isn't always on for most people with
magicdev, because with the bug in 50627, if you turn on
autoeject, you can't even close your drive door with magicdev
My only guess on this bug is that the version of magicdev being
tested here isn't actually the one from 7.1. (0.3.5-3)
What are the results when you:
rpm -q magicdev
rpm -q kernel
I can't tell you what version it was, unfortunately. I am *currently* running
Ximian's GNOME, but I thought that I was not at the time. If I thought the
problem was GNOME related, then I wouldn't have sent a bug report to you. I
disabled autorun functions in the GNOME control panel, reset the global flags,
and haven't had the problem since.
I can't see bug 50627, but when you say "you can't even close your drive door
with magicdev running", it sounds like a symptom of the problem I had. I could
manually close the CDROM tray, but not with software. Neither 'eject -t' nor
'mount' would cause it to close. IIRC.
BTW, is there a way to view the auto(eject|close) flags for individual devices?
Seems like the kind of thing that should show up under
/proc/ide/ide1/hdc/settings for hdc...
Closing bug. Magicdev has been removed in favor of
gnome-volume-manager in the development branch.