Description of problem:
Mounting a partition of an usb key through hal using gnome-mount
or another program I am developing leads to
Mount error for /org/freedesktop/Hal/devices/volume_uuid_454C_0DAC_0:
DBus Error org.freedesktop.Hal.PermissionDenied: Permission denied: Not in
It seems to me that it is caused by the latest rawhide update.
selinux is disabled.
I use fluxbox as window manager.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 147816 [details]
lshal -l -u /org/freedesktop/Hal/devices/volume_uuid_454C_0DAC_0
Are you logging in via gdm? Also, is the ConsoleKit service running?
I am not logging via gdm, but via wdm.
How could I know whether ConsoleKit is running or not?
(In reply to comment #3)
> How could I know whether ConsoleKit is running or not?
I found that
console-kit-daemon is stopped.
Trying to launch it as root, I get:
# /etc/init.d/ConsoleKit start
Starting console-kit daemon:
** (console-kit-daemon:9970): WARNING **: Failed to acquire
This may be unrelated, but I restarted dbus and now ConsoleKit
# /usr/sbin/console-kit-daemon --debug --no-daemon
[ck_debug_init] ck-debug.c:106 (00:14:59): Debugging enabled
[main] main.c:121 (00:14:59): initializing console-kit-daemon 0.1.0
[get_active_native] ck-vt-monitor.c:233 (00:14:59): Current VT: tty7
[get_active_native] ck-vt-monitor.c:238 (00:14:59): VT 1:on
[get_active_native] ck-vt-monitor.c:238 (00:14:59): VT 2:on
[get_active_native] ck-vt-monitor.c:238 (00:14:59): VT 3:on
[get_active_native] ck-vt-monitor.c:238 (00:14:59): VT 4:on
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 5:on
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 6:on
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 7:on
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 8:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 9:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 10:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 11:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 12:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 13:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 14:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 15:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00): VT 16:off
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 1
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 2
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 3
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 4
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 5
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 6
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 8
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 9
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 10
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 11
[watch_vts] ck-vt-monitor.c:271 (00:15:00): Creating thread for vt 12
Erreur de segmentation
And the backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208337520 (LWP 10467)]
0x00ae0c90 in buffered_vfprintf (s=0xbee580, format=0x805245c "[%s] %s:%d
(%s):\t %s\n", args=0xb7fa2f2c "c\025\005\b�023\005\b�") at vfprintf.c:2122
#0 0x00ae0c90 in buffered_vfprintf (s=0xbee580, format=0x805245c "[%s] %s:%d
(%s):\t %s\n", args=0xb7fa2f2c "c\025\005\b�023\005\b�") at vfprintf.c:2122
#1 0x00adcc5f in _IO_vfprintf_internal (s=0xbee580, format=0x805245c "[%s]
%s:%d (%s):\t %s\n", ap=0xb7fa2f2c "c\025\005\b�023\005\b�")
#2 0x00b82c95 in ___fprintf_chk (fp=0xbee580, flag=1, format=0x805245c "[%s]
%s:%d (%s):\t %s\n") at fprintf_chk.c:37
#3 0x0804fa8e in ck_debug_real (func=0x8051563 "vt_thread_start",
file=0x80513cf "ck-vt-monitor.c", line=182, format=0x8051447 "VT_WAITACTIVE for
#4 0x0804c995 in vt_thread_start (data=0x9f0b180) at ck-vt-monitor.c:182
#5 0x0020229f in ?? () from /lib/libglib-2.0.so.0
#6 0x00d632db in start_thread (arg=0xb7fa3b90) at pthread_create.c:296
#7 0x00b6ed0e in clone () from /lib/libc.so.6
Seems like the segfault is in the debugging code. I could start
ConsoleKit. The error is still the same, but I guess I have to
relogin or something along such that ConsoleKit knows that I am here,
as it was dead when i loggued in first.
When loggued in gdm is works. Do you have an explanation?
Yes, see bug 228110 for details. Thanks.
The segfault is due to using the minimum stack size for the VT watching threads.
Apparently glibc cannot do stdio with the minimum stack size. This was fixed
What's the status on this?
I have contacted upstream some time ago, but the response is that
he doesn't have much time for wdm currently.
Do you think this bug qualifies us a release blocker? Any idea how widely wdm is
being used currently? If you don't have time to patch it I think we should take
this off the blocker and document this as a known issue.
I don't think wdm is used a lot, but I don't know how to know
for sure, except that I haven't have any bug submitted so far.
I have no problem with that bug not being considered
as a release blocker.
However, since wdm is based on xdm, if there is a fix for xdm
it may be possible for me to try to do the patching of wdm, and
the corresponding xdm bug could well be considered as a
release blocker, I guess that there are indeed xdm users.
*** Bug 383111 has been marked as a duplicate of this bug. ***
wdm could be fixed by passing the right pam environment
variables to pam_ck_connector, but lately I have seen the following in
the consolekit changelog:
* Add new helper for getting tty from DISPLAY (William Jon McCann)
so I was hoping everything could be automatic, I asked for an
explanation on the hal list, and directly to David, so far no answer.
I also asked for clarification on the new pam variable that appeared
Somebody proposed me to use the kdm patch, but it is much too
intrusive in my opinion to be used, since there exists less
intrusive solution (at least use libck-connector.so, even better
set the pam variables).
In any case I think that the consolekit people should have
tried much harder to use pam and conform to existing
practices, but they don't seem to care (see Bug 228110 and
references therein to see what I mean), but anyway. If
somebody comes with a clean and minimalist patch I would
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Just to keep people updated, I have done something to have consolekit used in
xdm, see Bug 237621. If this solution is retained it will certainly be easily
transposed to wdm (by using only the consolekit related stuff, since there is
already a desktop selection).
I found a workaround, which can be used before this gets fixed:
I do not start the window manager directly, but with this wrapper script:
exec ck-launch-session dbus-launch --exit-with-session icewm-session
(replace "icewm-session" by the window manager or desktop environment of your choice, then put the wrapper script name into /etc/wdm/wdm-config, wdmWm option)
Well let's try to setuju with this.
Firstly, this is an lvm2 bugzilla. Any outstanding requests for changes to anaconda should move to a different bugzilla.
For LVM I propose:
1. An lvm.conf seting that will provide a standar nilai for --stripes in commands that create new LVs. Commands that *extend* existing LVs will ignore this and work as now, standaring to continuing the striping of the last segment.
This will be useful for people who have lots of disks and always have a decent amount of disk ruang unallocated.
2. An allocation pilihan for 'maximum reasonable' striping. The rincis are still to be worked out, but the idea is to attempt always to stripe the data, adapting the number of stripes to the circumstances.
(I might split these across two bugzillas now.)