Following an update to baselayout-1.12.0_pre17-r1 I noticed that hcid no longer starts at boot. I was alerted to this by KDE informing me that my device class was 0 while I know that it's set explicitly in hcid.conf. Performing an /etc/init.d/bluetooth stop then /etc/init.d/bluetooth start does start hcid correctly and KDE no longer complains. My bluez-utils and bluez-libs are version 2.24 Portage 2.1_pre7-r5 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.5-r3, 2.6.16-gentoo-r1 i686) ================================================================= System uname: 2.6.16-gentoo-r1 i686 AMD Athlon(tm) XP 2200+ Gentoo Base System version 1.12.0_pre17 ccache version 2.4 [enabled] dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LC_ALL="en_GB.utf8" LINGUAS="en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X a52 aac acl acpi alsa apache2 arts asf audiofile bash-completion berkdb bitmap-fonts blas bluetooth bzip2 cairo caps cddb cdparanoia cdr cli crypt ctype cups curl dba dbus dga directfb djbfft dri dts dv dvd dvdr dvdread emacs encode esd exif expat fam fame fastbuild fbcon ffmpeg fftw flac font-server foomaticdb force-cgi-redirect fortran ftp gd gdbm gif gimpprint ginac gmp gphoto2 gs gtk2 gtkhtml hal iconv idn ieee1394 imagemagick imlib innodb ipv6 isdnlog ithreads jpeg kde lcms ldap libg++ libwww lm_sensors lzo mad mailwrapper memlimit mhash mikmod mjpeg mmx mng motif mp3 mpeg musicbrainz mysql ncurses nls nptl nsplugin ogg openexr opengl pam pcre pdf pdflib perl perlsuid pic plotutils png posix postgres povray ppds pppd python qhull qt quicktime readline real ruby samba sasl scanner sdl session shared simplexml slp sndfile soap sockets sox speex spell spl sqlite sse ssl svg tcltk tcpd tetex theora threads tidy tiff tokenizer truetype truetype-fonts type1-fonts udev unicode usb v4l vcd vorbis wifi win32codecs xine xml xpm xsl xv xvid zeroconf zlib elibc_glibc kernel_linux linguas_en_GB userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS
Does rc-status or /etc/init.d/bluetooth status report that it's started? Does downgrading to baselayout-1.12.0_pre16 help? What was the last baselayout version that worked?
Both rc-status and /etc/init.d/bluetooth status return "started" so they don't seem to check that all daemons are correctly running. baselayout-1.12.0_pre16-r3 appears to be the last correctly functioning version. Vesions above pre16-r3 show, at boot: Starting bluetooth ... Starting hcid ... [!!] Starting sdpd ... [ok] Starting rfcomm ... [ok] and hcid definitely isn't runnung under those versions but for pre16-r3 it is.
Is bluetooth in your boot or default runlevel? And this only happens at boot time yes? Could you download http://dev.gentoo.org/~uberlord/baselayout/trace-test to /etc/init.d/, chmod +x it and then start it. Attach the output to this bug. Thanks.
Created attachment 84557 [details] trace-test output for baselayout-1.12.0_pre16-r3 This is the trace-test output for a working configuration.
Created attachment 84558 [details] trace-test output for baselayout-1.12.0_pre17-r1 This is the trace-test output for a failing configuration.
(In reply to comment #3) > Is bluetooth in your boot or default runlevel? And this only happens at boot > time yes? I generally follow the Gentoo advice of installing services into the default runlevel. As you'll see from my trace-test output there are exceptions but they are made after careful consideration. Yes, hcid only fails to start at boot. Executing /etc/init.d/bluetooth restart after boot does result in a running hcid. > Could you download http://dev.gentoo.org/~uberlord/baselayout/trace-test to > /etc/init.d/, chmod +x it and then start it. Attach the output to this bug. Done. I've attached the output for both pre16-r3 and pre17-r1. Probably overkill but you can never have too much information.
I can see nothing wrong with either trace test as bluetooth is always after the slighty re-arranged services. Not sure what todo with this myself as hcid works on boot for me and a few others I contacted in IRC using baselayout-1.12.0_pre17-r2 so I don't think this is necessarily a baselayout issue. Maybe the sleep isn't long enough now on line 30? Maybe it's udev related? Is there anything in your logs about hcid dying? Does it work if you remove the start-stop-daemon call on line 37 & 38 of the bluetooth init script to do this? /usr/sbin/hccd -f $HCID_CONFIG Re-assigning to mobile, adding myself to CC
I have a solution for this problem which I have posted in Enhancement Request #130235.
