Arch Linux

confirm, same fails

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).

<aol>me too</aol>

is related with this bug?

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

$ pacman -Qs eject
local/eject 2.1.5-4 [0.22 MB]

but brasero is not able to eject the media autmatically

i thing also, brasero use "eject" for eject the media.

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)

After making the above comment I noticed similar trouble from Thunar, so also see:

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

/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

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...

can you paste ck-list-sessions output?

[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?

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

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.

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'

Thanks for the information. Getting rid of slim will have to wait a bit until I have more time but I'll report back.

just to test, add now in ~/.xinitrc only this line

exec ck-launch-session xfce4-session

then startx

watch it work :)

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.

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'

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!

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).

Is this still a problem with 3.4.1? Or even the 3.6 one from gnome-unstable?

Pretty sure this worked last time I burnt a disk with 3.4.1. Will re-test if no one else confirms.

I can confirm the eject works in 3.4.1.