You are not logged in.
Hello.
I've this really obscure problem and was wondering if you've any idea. I have netfs and samba listen in my /etc/rc.conf's DAEMONS array. They both fail to start with the following error messages:
samba:
/etc/rc.d/samba: line 8: 3772 Aborted /usr/sbin/smbd -D
/etc/rc.d/samba: line 8: 3773 Aborted /usr/sbin/nmbd -D
netfs:
mount.smbfs: gconv_db.c:232: __gconv_release_step: Assertion `step->__end_fct == ((void *)0)' failed.
mount.smbfs: gconv_db.c:232: __gconv_release_step: Assertion `step->__end_fct == ((void *)0)' failed.
The weird thing is that when I start them manually they work. I've tried placing them in different positions in the DAEMONS array, I've also tried starting them through /etc/rc.local, but it didn't work. Only when the system was up entirely I could start these daemons, it seems.
I thought this might be a kernel issue, but I've tested with both the Beyond and the stock kernel and got the same results.
I'm pretty clueless. Any ideas?
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
do you run testing? if so, chances are you've been bitten by this:
http://archlinux.org/news.php#236
file a bug.
James
Offline
These issues have started several days ago, I'm not sure testing is to blame.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
Anyway, I've filed for it here: http://bugs.archlinux.org/task/4732
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
I'm also getting this exact same error
xfmedia: gconv_db.c:232: __gconv_release_step: Assertion `step->__end_fct == ((void *)0)' failed.
when I try to run xfmedia. I've rebuilt it against the latest version of everything from testing, and the error is still there.
I realise this doesn't help you directly, but it does show that the problem is more fundamental, as it is affecting widely differing applications.
xfmedia is from the AUR, so I wouldn't expect the devs to be concerned about it, but I'll add a comment to your bug report anyway, in case it helps.
Offline
ok, yeah, might be a good one to report, try recompiling glibc against the new db, it's a problem within glibc.
James
edit: oh, you've opened it, good users 8)
Offline
ok, yeah, might be a good one to report, try recompiling glibc against the new db, it's a problem within glibc.
James
edit: oh, you've opened it, good users 8)
glibc doesn't do anything with BDB installed on your system, glibc is almost self-contained (it only needs a compiler toolchain to build)
What happens here is an internal assertion failure in glibc.
Offline