Description of problem: Version-Release number of selected component (if applicable): probably hal-0.5.11-2.fc9.i386 from F9 testing repo, build date 12-Jun-2008, and/or udev-124-1.fc9.i386 from same source How reproducible: when ejecting CD/DVD medium - by "eject /dev/sr0" cmd or by Nautilus - then immediately after is ejected is dragget back into drive. No matter when it is blank, valid iso or damaged iso medium. Additionaly, device permission are 0640 (root:disk) even for blank media, and k3b then cannot access to it. Steps to Reproduce: 1. Update to hal & udev from F9 testing repo 2. try burn with k3b or mount some CD/DVD 3. eject these with Nautilus or eject command Actual results: medium is after ejection immediately reinserted into drive. Expected results: medium stay ejected Additional info:
(In reply to comment #0) > Additionaly, device permission are 0640 (root:disk) even for blank media, > and k3b then cannot access to it. What's the output of 'getfacl /dev/sr0'?
Sorry, this output I should add to report first. After computer reboot and user (hanzlik) log-in, "getfacl /dev/sr0" print: getfacl: Removing leading '/' from absolute path names # file: dev/sr0 # owner: root # group: disk user::rw- user:hanzlik:rw- group::r-- mask::rw- other::--- But after inserting media, no matter when blank or with ISO image, "getfacl /dev/sr0" output is: getfacl: Removing leading '/' from absolute path names # file: dev/sr0 # owner: root # group: disk user::rw- user:hanzlik:rw- #effective:r-- group::r-- mask::r-- other::--- user rights are thus stripped by effective rights mask, which was changed. Blank medium is at desktop properly displayed as blank, and ISO medium is properly automounted. While changing mask for ISO image probably isn't too constrictive (but what if I will wish add another session to multisession CD?), it perhaps disable burn to blank media.
As the output says you have an RW ACL for /dev/sr0 ... the "#effective:r--" _comment_ is misleading because of the fact that /dev/sr0 is a read only device (but you can still do ioctl's on it, that's the way cd burning works). So I believe this is simply a bug in cdrkit (that is used in n-c-b and other burning tools). So reassigning; cdrkit maintainers: Feel free to assign back if you can explain I'm wrong. Thanks. Frantisek: For the reinsertion issue please file a new bug report against hal (and in the future please don't report multiple bugs in a single bug report).
After some fiddling I thing problem is definitely in udev-124-1.fc9.i386. Dowgrading hal to previous version (hal-libs-0.5.11-1.fc9, hal-0.5.11-1.fc9, hal-info-20080508-1.fc9, hal-devel-0.5.11-1.fc9) not solved problem. But after dowgrading udev-124-1.fc9.i386 to original udev-120-5.20080421git.fc9.i386 all works fine (even I upgrade hal-* again) - when I eject medium, then it stay ejected, effective rights mask is always "rw-", k3b startup environment test is satisfied too (with effective rights mask "r--" k3b at start write: No write access to device /dev/sr0 K3b needs write access to all the devices to perform certain tasks. Without it you might encounter problems with TSSTcorp - CDDVDW SH-S203P Solution: Make sure you have write access to /dev/sr0. In case you are not using devfs or udev K3bSetup is able to do this for you. ) It really appear as some udev-124 problem.
Frantisek: why did you reassign the bug to me? Please stop doing that.
I too am experiencing this problem, and can certainly pinpoint it to the udev-124 release. Starting with a stick F9 system just updating udev will cause this problem to show up. David had me change the timing of the pam_console rules from 95 to 89, but that change had no apparent effect upon the problem. Triggering the issue is as simple as booting (to GNOME), then inserting media, or removing already inserted media. The permissions of the device will resort back to rw-r-- which imposes a permission mask upon the ACLs preventing the user from doing anything.
Reassigning back to HAL until we finds the culprit.
Looks like this is the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=453095
well, what sets mode 660 to /dev/sr0 ?? udev sets 0640 initially. and in udev-124 the "change" event is also processed, which resets /dev/sr0 to 0640.
pam_console does not cover cdrom anymore, btw
see also http://thread.gmane.org/gmane.linux.hotplug.devel/12758
I'm not sure what sets it to 660, but that's what it needs to be. When it's not 660, if group only has read access, that sets a mask upon any file system ACLs that might get set, by the likes of policykit. The net results is that non-root users are unable to write to the device for things like CD burning. So maybe the bug here is that the change processing is finally setting things to what udev thinks they should be, but we've been operating on an assumption that udev 'thought' it should be 660, and we need to reflect that assumption now.
Created attachment 310962 [details] Don't reset permissions on media change The attached patch fixes it by reverting the upstream change that broke it .. it isn't the cleanest solution but better than breaking cd burning for everybody. Please consider adding this to an update until a "real" solution is found upstream.
(In reply to comment #13) > Created an attachment (id=310962) [edit] > Don't reset permissions on media change > > The attached patch fixes it by reverting the upstream change that broke it .. > it isn't the cleanest solution but better than breaking cd burning for > everybody. Please consider adding this to an update until a "real" solution is > found upstream. NAK. This is going to break DeviceKit-disks (soon to land in Rawhide) and other things. The real fix is to not mess around with the permissions on 'change' events.
back to udev btw
the fix is wrong, because we need "change" events for other devices
and vol_id
*** Bug 454066 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > back to udev btw hmm, udev upstream wants the app, which applied 0660, to apply it again on change events... so? hal/consolekit?
The options are: make udev not to change permissions on "change" events, or let the stuff that applies ACL's do the same thing on "change" as on "add" events. I think the second option is the right thing to do, because "change" could mean anything in a device context, including a making a different decision for granting device access to users. But I'm open any reasonable argument. Let me know. Thanks!
*** Bug 454082 has been marked as a duplicate of this bug. ***
udev-124-1.fc9.2 has been submitted as an update for Fedora 9
https://admin.fedoraproject.org/updates/F9/pending/udev-124-1.fc9.2
*** Bug 453591 has been marked as a duplicate of this bug. ***
udev-124-1.fc9.2 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Okay, the new update fixes the problem with the permissions for reading cd and dvd media. But the problem with the closing tray is the same. When ejecting CD/DVD medium, then immediately after is ejected is dragget back into drive.
> When ejecting CD/DVD medium, then immediately after is ejected is dragget back > into drive. The happens here. I do not know how to remove the disk out of the computer... Paul
I'm also still seeing the problem with the disk tray closing immediately after eject. Occurs with DVD-Video, DVD-ROM, blanks, etc, regardless of if I use the eject button on the front of the drive, use the eject command from Nautilus desktop, or use the umount and eject commands in sequence from the console. It does seem to eject correctly immediately following a successful burn by gnomebaker.
Oh, and it also ejects normally if there's nothing current in the drive. It only ejects and then immediately closes again (after reaching its full extension briefly) if there is some media in the drive. Does seem to duplicate bug 453095 but there seems to be more information on this entry.
I am having a problem - I cannot mount and open my camera (a Nikon D300). If I try to do so (using USB-PTP), mount it, and then try to open it (with gThumbImageViewer of FSpot), I get the error: An error occurred in the io-library ('Could not lock the device'): Camera is already in use. This started happening yesterday. Coincidentally, that was the same date that udev was upgraded from 124-1.fc9.1 to 124-1.fc9.2 .
*** Bug 454122 has been marked as a duplicate of this bug. ***
(In reply to comment #29) > Oh, and it also ejects normally if there's nothing current in the drive. It > only ejects and then immediately closes again (after reaching its full extension > briefly) if there is some media in the drive. The same problem happens on my machine. I've tested a little bit with different versions of the hal daemon and udev and it looks like that the problem is triggered definitively by udevd: - installing different versions of hal daemon: no change - installing F9 release version of udev (udev-120-5.20080421git.fc9.i386.rpm): problem does _not_ happen any more
I think this bug should be closed as permissions are fixed in latest udev update. The separate bug 453095 is about tray beiing closed immediately.
I am currently running F9 with the latest updates and am seeing this issue. I do not believe it is fixed.
I may actually be seeing this (https://bugzilla.redhat.com/show_bug.cgi?id=423641 ) bug or these may be related bugs somehow.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.