Summary: | baselayout-1.12.0_pre17-r1 breaks bluetooth hcid startup | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Neil Darlow <neil> |
Component: | [OLD] baselayout | Assignee: | Mobile Herd (OBSOLETE) <mobile+disabled> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | uberlord |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
trace-test output for baselayout-1.12.0_pre16-r3
trace-test output for baselayout-1.12.0_pre17-r1 |
Description
Neil Darlow
2006-04-12 09:51:21 UTC
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. |