Bug 37724
Summary: | autoeject always on | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Gordon Messmer <gordon.messmer> |
Component: | magicdev | Assignee: | John (J5) Palmieri <johnp> |
Status: | CLOSED WONTFIX | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | jkeck |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-08-25 17:14:22 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gordon Messmer
2001-04-26 04:34:08 UTC
Additionally, autoclose is not working, but: $ cat /proc/sys/dev/cdrom/autoclose 1 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 behavior 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 media, anyway...) 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 running.) 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. |