Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#20035 - [brasero] fails to eject the DVD after a successful burn

Attached to Project: Arch Linux
Opened by Johan Eriksson (Hund) - Wednesday, 30 June 2010, 21:58 GMT
Last edited by Jan de Groot (JGC) - Thursday, 08 November 2012, 09:22 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Ionut Biru (wonder)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

After a sucessfull burn of a ISO-file to a DVD, Brasero fails to eject the DVD and gives me this message: "The disc could not be ejected though it needs to be removed for the current operation to continue."

Im using brasero 2.30.2-1.
This task depends upon

Closed by  Jan de Groot (JGC)
Thursday, 08 November 2012, 09:22 GMT
Reason for closing:  Fixed
Comment by Alois Nespor (anespor) - Thursday, 01 July 2010, 07:26 GMT
confirm, same fails
Comment by Michael (SiD) - Sunday, 31 October 2010, 16:13 GMT
same problem here on i686 with brasero-2.32.0-3

also with cdrom-iso cdrom-data and dvd-data (other media types not teseted).
Comment by Dale Blount (dale) - Wednesday, 01 December 2010, 15:22 GMT
<aol>me too</aol>
Comment by mattia (nTia89) - Saturday, 15 January 2011, 19:20 GMT
Comment by Michael (SiD) - Saturday, 15 January 2011, 21:58 GMT
$ pacman -Qs eject
local/eject 2.1.5-4 [0.22 MB]

but brasero is not able to eject the media autmatically
Comment by Alois Nespor (anespor) - Saturday, 22 January 2011, 08:22 GMT
i thing also, brasero use "eject" for eject the media.
Comment by René Herman (rene) - Wednesday, 26 October 2011, 22:31 GMT
The recent upgrade to udev-174 may have provided a hint as to the cause of this bug?

udev-174 assigns optical drives to the "disk" group, which given that my user isn't in that group makes brasero fail to access the drive. Adding a user to the "disk" group isn't generally recommended since this implies access to hard drives as well, and I therefore reassign the drive to the "optical" group of which my user IS a member:

=== /etc/udev/rules.d/81-optical.rules
#
# udev-174 assigns optical drives to group "disk"; reassign to group "optical"
#

# Permissions for IDE CD devices
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"

# Permissions for SCSI CD devices
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"
===

The drive used to be in the "storage" group though, of which my user was also a member, and upon seeing no devices in /dev being owned by the "storage" group anymore, I deleted my user from that group (# gpasswd -d rene storage). At this point, burning a CD/DVD with brasero works fine, but brasero fails at the end with the here mentioned eject trouble:

===
The disc in "PLEXTOR DVDR PX-820SA" cannot be ejected
Not Authorized
===

Adding my user BACK to the "storage" group (# gpasswd -a rene storage) fixes the issue. As said, no device in /dev is owned by group "storage" anymore so this might imply some hardcoding-trouble going on somewhere?

Quite unsure that it would be in brasero though. This seems to be an interaction between archlinux permissions-policy (if there is such a thing...), udev-174, brasero and, perhaps, things like thunar trying to butt in.

(the trouble itself IS specific to brasero though: ejecting through the "eject" comand line utility or through right-clicking the icon on my XFCE desktop works fine)
Comment by René Herman (rene) - Wednesday, 26 October 2011, 23:14 GMT
After making the above comment I noticed similar trouble from Thunar, so also see:

https://bugs.archlinux.org/task/26640
Comment by Ionut Biru (wonder) - Thursday, 27 October 2011, 06:40 GMT
/etc/udev/rules.d/81-optical.rules

custom rule

use consolekit to allow your user access to devices

exec ck-launch-session yoursession or use gdm/kdm/lxdm
Comment by René Herman (rene) - Thursday, 27 October 2011, 12:37 GMT
Not completely sure what you mean in detail but I do already use ck-launch-session.

It seems Thunar installs a policykit rule that wants the storage group. See

https://bugs.archlinux.org/task/26640

Although I'm not all that sure how all this, ehm, "stuff" is supposed to interact that feels like it might be something that Thunar should not in fact do...
Comment by Ionut Biru (wonder) - Wednesday, 02 November 2011, 13:25 GMT
can you paste ck-list-sessions output?
Comment by René Herman (rene) - Wednesday, 02 November 2011, 13:40 GMT
[rene@e600 ~]$ id
uid=1000(rene) gid=100(users) groups=100(users),7(lp),10(wheel),50(games),91(video),92(audio),93(optical),94(floppy),95(storage),96(scanner),97(camera),98(power)
[rene@e600 ~]$ ck-list-sessions
Session1:
unix-user = '1000'
realname = ''
seat = 'Seat2'
session-type = ''
active = FALSE
x11-display = ':0.0'
x11-display-device = ''
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2011-11-02T11:26:32.697950Z'
login-session-id = ''
Session2:
unix-user = '1000'
realname = ''
seat = 'Seat3'
session-type = ''
active = FALSE
x11-display = ':0.0'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = FALSE
on-since = '2011-11-02T11:26:32.811067Z'
login-session-id = ''

I use slim as a display manager, have in /etc/slim.conf:

"login_cmd exec ck-launch-session /bin/bash -login ~/.xinitrc %session"

(and exec "xfce4-session" from ~/.xinitrc)

EDIT: Where's the option to have this bugzilla not strip leading spaces when displaying?
Comment by Ionut Biru (wonder) - Wednesday, 02 November 2011, 13:44 GMT
ok, as you see your username is not authorized right to consolekit.

either slim is really broken or you have some pacnew files inside /etc/pam.d
Comment by René Herman (rene) - Wednesday, 02 November 2011, 13:47 GMT
I don't actually see that. What should've been the output? I don't even have a clue why that command is listing 2 sessions instead of 1.

There are no unmerged changes in /etc/pam.d. My /etc/pam.d/slim is:

===
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_env.so
auth required pam_unix.so nullok
account required pam_unix.so
password required pam_unix.so
session required pam_limits.so
session required pam_unix.so
session optional pam_loginuid.so
session optional pam_ck_connector.so
===

(only) the "nullok" is a local tweak; otherwise it's vanilla slim.
Comment by Ionut Biru (wonder) - Wednesday, 02 November 2011, 13:51 GMT
important is /etc/pam.d/login. is listing 2 sessions because slim is really really broken and doesn't support ck.

The right output should have active and is-locale TRUE. After you managed to have this output you can get rid of all groups and have only users

Session2:
unix-user = '1000'
realname = 'ioni'
seat = 'Seat1'
session-type = ''
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2011-11-01T01:53:16.858361Z'
login-session-id = '2'
Comment by René Herman (rene) - Wednesday, 02 November 2011, 13:54 GMT
Thanks for the information. Getting rid of slim will have to wait a bit until I have more time but I'll report back.
Comment by Ionut Biru (wonder) - Wednesday, 02 November 2011, 13:56 GMT
just to test, add now in ~/.xinitrc only this line

exec ck-launch-session xfce4-session

then startx

watch it work :)
Comment by René Herman (rene) - Tuesday, 08 November 2011, 02:04 GMT
Thanks again. I've replaced SLiM with LXDM and things are working flawlessly.

This is an old bug (and not reported by me) but it can probably be closed. The originally reported problem is the experience you get without a correct ConsoleKit setup.
Comment by Diego Xirinachs (dxiri) - Wednesday, 09 November 2011, 07:00 GMT
I have this issue also, using Gnome 3 with gdm, and apparently my consolekit setup is correct:

Session2:
unix-user = '1000'
realname = 'lookatmynameonbugcomment'
seat = 'Seat1'
session-type = ''
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2011-11-09T05:39:28.420368Z'
login-session-id = '2'
Comment by René Herman (rene) - Wednesday, 09 November 2011, 16:37 GMT
Lovely. Instead of commenting, I'll just wait for someone to recompile the arch repos without consolekit support so that I get to uninstall that horrendous piece of horseshit. With it gone, maybe somebody will have a change of debugging something again. Thanks in advance!
Comment by René Herman (rene) - Saturday, 12 November 2011, 03:51 GMT
Now, given how much I like to rant, I should also post a link to the solution to (my) original problem in this thread:

https://bbs.archlinux.org/viewtopic.php?id=130154

(as to Diego's problem... no idea).
Comment by Greg (dolby) - Monday, 15 October 2012, 03:12 GMT
Is this still a problem with 3.4.1? Or even the 3.6 one from gnome-unstable?
Comment by Dale Blount (dale) - Monday, 15 October 2012, 12:23 GMT
Pretty sure this worked last time I burnt a disk with 3.4.1. Will re-test if no one else confirms.
Comment by misko herko (heroin) - Tuesday, 06 November 2012, 21:22 GMT
I can confirm the eject works in 3.4.1.

Loading...