iMac（Apple Broadcom Bluetooth USB Host Controller）で Debian GNOME を運用していると、ある日突然 Bluetooth がオンにならず、GUI でも CLI でもコントローラが「存在しない」扱いになることがある。本件は、GNOME のトグルや bluetooth.service の稼働状況だけを見ていると「上では動いているのに、なぜか使えない」ように見える。結論から言うと、ユーザ空間（GNOME / systemd / BlueZ）ではなく、カーネルドライバ（btusb）が Broadcom の HCI reset を完走できず、Bluetooth コントローラとして成立していない状態に落ちていた。症状が「No default controller available」や「BD Address 00:00:00:00:00:00」に収束する場合、切り分けの主戦場はユーザ空間ではなくカーネル初期化レイヤである。[1][2][3]
さらにやっかいなのは、このタイプの障害が「一度復旧しても再起動で戻る」点にある。つまり、手元の操作で復旧できたとしても、恒久化しない限り再発する。この記事では、導入からの観測、ログによる原因特定、応急復旧、恒久対策（modprobe 設定 + initramfs 反映 + 起動時ロード固定）、そして Magic Trackpad の接続までを、手順と判断軸の両方を残す形で整理する。
0. 前提とゴール
前提は「iMac 2015 + Debian 13 + GNOME + BlueZ」というデスクトップ構成で、Bluetooth デバイス（Magic Trackpad / Magic Keyboard 等）を安定して使いたい、という状況である。ゴールは 2 つある。
- 再起動しても Bluetooth コントローラが確実に初期化され、GNOME のトグルがオンになること。
- Magic Trackpad がペアリング・自動接続まで到達し、実運用で途切れないこと。
ここで重要なのは、Bluetooth の障害は大きく「遮断（rfkill）」「ユーザ空間（BlueZ/DBus）」「カーネル初期化（HCI/firmware/reset）」の 3 層に分かれる、という整理である。層を間違えると、無関係な場所を延々と触って時間を溶かす。今回の本題は 3 番目の「カーネル初期化」だった。[4]
Bluetooth 障害の 3 層モデル 一覧表
| 層 | 代表症状 | 確認ポイント | 典型原因 | 打ち手（優先度順） |
|---|---|---|---|---|
| 1. 遮断（rfkill） | Bluetooth をオンにできない／一瞬でオフに戻る、ただしコントローラ自体は見えることがある | Bluetooth が soft blocked / hard blocked になっていないか | 機内モード相当の遮断、物理スイッチ、プラットフォーム側の kill switch | 遮断解除（soft unblock）→ 物理遮断の解除（hard unblock）→ それでも復帰しない場合は次の層へ |
| 2. ユーザ空間（BlueZ / DBus） | コントローラは見えるが、ペアリングが不安定／接続が維持できない／GUI が反応しない | bluetooth.service が稼働しているか、bluetoothctl show が成立するか | BlueZ デーモン停止、DBus 側の問題、権限やポリシー、設定破損 | bluetooth.service 再起動 → bluetoothctl で状態確認 → 必要ならペアリング情報の整理（remove / trust 再設定） |
| 3. カーネル初期化（HCI / firmware / reset） | No default controller available、BD Address が 00:00:00:00:00:00、hci0 を up できない | USB デバイスは見えるのに HCI が成立していないか、dmesg に reset timeout が出ていないか | btusb 初期化での Broadcom HCI reset 失敗、firmware/初期化シーケンスの不整合、USB 電源管理（autosuspend）絡み | btusb 再ロードで応急復旧（modprobe -r / modprobe）→ btusb の reset 強制・autosuspend 回避を恒久化（modprobe.d）→ initramfs 反映 → 必要なら起動時ロード固定（/etc/modules 等） |
1. 症状と観測された事実
最初に現れる症状は単純で、GNOME の Bluetooth トグルがオンにならない、またはオンにしても戻る。CLI では次のような形で露出する。
1 2 | bluetoothctl power on |
ここで No default controller available が出る場合、BlueZ が「コントローラ（HCI デバイス）を 1 つも持てていない」状態である。つまり「ペアリング前」や「機内モード」以前の問題で、コントローラ自体が上がっていない。[2]
一方で、systemd 的には Bluetooth サービスは普通に動いていることが多い。
1 | systemctl status bluetooth |
この時点で Active: active (running) を見ても安心してはいけない。Bluetooth は「サービスが動いている」だけでは成立せず、「カーネルが HCI デバイスを提供できている」必要があるからだ。
次に、遮断系（rfkill）を確認する。
1 | rfkill list |
ここで hci0 が soft/hard block されていない（no）なら、「スイッチで殺されている」筋は薄い。今回も block は存在しなかった。
さらに、USB として見えているかを確認する。iMac 2015 の内蔵 Bluetooth は USB デバイスとして露出することがある。
1 | lsusb | grep -i bluetooth |
ここで Apple, Inc. Bluetooth USB Host Controller が見えていれば、少なくとも USB の enumeration は成功している。つまり「完全に死んだハード」ではなく、「見えているが初期化できない」可能性が高くなる。
決定的な観測が hciconfig -a だった。
1 | hciconfig -a |
問題状態では BD Address が 00:00:00:00:00:00 になり、DOWN のまま、MTU も 0 のまま、という形に落ちる。これは「HCI デバイスの初期化が完了しておらず、コントローラとして成立していない」ことを強く示唆する。rfkill が no で、bluetooth.service が running で、lsusb でデバイスが見えているのに、HCI として上がらない。この組み合わせが「初期化失敗型 Bluetooth 障害」の典型形である。[1][3]
観測を整理すると、次の表に収束する。
| 観測 | コマンド | 意味 |
|---|---|---|
| rfkill は unblock | rfkill list | 遮断（飛行機/物理スイッチ）ではない |
| サービスは稼働 | systemctl status bluetooth | ユーザ空間の常駐プロセス停止ではない |
| USB デバイスは存在 | lsusb | USB としては認識されている |
| Controller が無い扱い | bluetoothctl power on | BlueZ から見るとコントローラ不在 |
| BD Address がゼロ | hciconfig -a | HCI 初期化が失敗している |
この時点で「GNOME のトグル」や「bluetooth.service の restart」だけを繰り返しても、根本の HCI が存在しないので改善しない。次にやるべきはログで「なぜ初期化に失敗しているか」を見ることになる。
2. ログによる原因特定
Bluetooth の初期化失敗は、ユーザ空間のログよりも kernel log に本質が出る。Debian ではまず dmesg を絞るだけで十分だった。
1 | sudo dmesg | grep -i -E 'btusb|bluetooth|hci0|bcm|brcm|firmware' |
今回の決定打は次の 2 行だった。
1 2 | Bluetooth: hci0: command 0x0c03 tx timeout Bluetooth: hci0: BCM: Reset failed (-110) |
0x0c03 は HCI Reset に対応するコマンドで、初期化の最初期に送られる。ここで tx timeout が出て reset failed になるということは、ドライバがコントローラにリセットを送ったが、規定時間内に応答が返らず初期化を継続できなかった、という意味になる。以後、HCI が成立しないので BD Address がゼロのままになり、結果として BlueZ からもコントローラが見えない。症状の鎖は一貫している。[1][3]
同時に Wi-Fi 側の brcmfmac firmware 探索ログも出ていた。
1 | brcmfmac ... firmware: failed to load brcm/brcmfmac43602-pcie.Apple Inc.-iMac17,1.bin (-2) |
これは「Apple 機固有の名前で firmware を探すが、該当ファイルが見つからない」ことを示している。今回 Bluetooth の本丸は HCI reset 失敗だったが、Apple 機では Wi-Fi / Bluetooth が Broadcom 由来で絡むことが多く、firmware が不足していると別の症状も混ざり得る。したがって、ログに firmware 探索失敗が出ている場合は「OS 側が特定の名前を探している」という事実として押さえておく価値がある。[5][6]
このログから得られる実務的な結論は 1 つである。今回の問題は rfkill や systemd の restart で直る類ではなく、btusb の初期化を安定させる方向でしか解けない。
3. 切り分けの結論
ここまでの観測とログから、切り分けは次の 3 点で確定する。
- rfkill 問題ではない（soft/hard block が no）。
- bluetooth.service 問題ではない（サービスは稼働し、再起動しても controller が出ない）。
- HCI 初期化（reset/firmware/init sequence）の問題である（dmesg に reset failed、hciconfig で BD Address がゼロ）。
つまりユーザ空間ではなく、ドライバ初期化レイヤの問題である。対処は「btusb をどう初期化させるか」「起動時にもそれを再現できるか」に寄せる。
| 結論 | 根拠（観測） | 次に取るべき方向 |
|---|---|---|
| rfkill 問題ではない | soft blocked / hard blocked が no。遮断が原因ならここが yes になる | 遮断解除ではなく、次の層（ユーザ空間／カーネル初期化）へ進む |
| bluetooth.service（ユーザ空間）問題ではない | bluetooth.service は running。再起動しても controller が出ない | BlueZ の再インストールや service 再起動ではなく、HCI 初期化の可否を確認する |
| HCI 初期化（reset / firmware / init sequence）の問題である | dmesg に reset failed / timeout。hciconfig で BD Address が 00:00:00:00:00:00。controller が成立していない | btusb の初期化挙動（reset 強制、autosuspend 回避）と起動時再現性（initramfs・起動時ロード）へ寄せる |
4. その場復旧（応急処置）
恒久化の前に、まず「本当に btusb 初期化の問題か」を確認するために、最小の操作で挙動を変える。ここで重要なのは、パッケージの再インストールのような重い操作ではなく、モジュールの再ロードのような軽い操作で反応を見ることだ。
1 2 | sudo modprobe -r btusb sudo modprobe btusb |
これで復旧する場合がある。復旧すると hciconfig -a が以下のように変わる。
1 | hciconfig -a |
正常側の特徴は次の通り。
- BD Address が実値になり、ゼロではない。
- UP RUNNING が付く。
- MTU が 0 ではなくなり、Features が埋まる。
一方、sudo hciconfig hci0 up を試しても Connection timed out (110) で上がらないことがある。この場合も根は同じで、そもそも reset を越えられていないため、手で up しようが成立しない。応急処置として意味があるのは「再ロードで初期化のタイミングをずらす」方である。
ただし、応急処置で復旧しても再起動で戻ることがある。今回も「一度認識したが、再起動すると BD Address が 00:00… に戻る」という揺れが出た。したがって、次にやるべきは恒久化である。
5. 恒久対策
Broadcom USB Bluetooth では、起動時の reset sequence が不安定な個体・組み合わせがあり、btusb ドライバに reset を強制させることが有効な場合がある。また USB autosuspend が絡むと、初期化直後やアイドル時に妙な切れ方をすることがあるため、安定性優先なら autosuspend を無効化しておくのが安全側になる。ここでは「起動時に必ず同じ初期化を踏ませる」ことを目的に、3 点セットで固める。
5.1 btusb の reset を強制し、USB autosuspend を避ける
btusb はモジュールパラメータを持ち、環境依存の初期化失敗を吸収するためのノブが用意されている。今回の核心は reset=1 で、これにより初期化時に reset を強制し、タイミング問題を回避できる場合がある。あわせて enable_autosuspend=0 にして、USB 電源管理による不安定化要因を外す。[3][7]
設定は /etc/modprobe.d に置く。Debian ではこれがモジュールパラメータ設定の標準ルートである。[8]
1 2 3 4 | sudo tee /etc/modprobe.d/btusb.conf >/dev/null <<'EOF' options btusb reset=1 options btusb enable_autosuspend=0 EOF |
ここまでで「次に btusb がロードされるタイミング」からは設定が効く。ただし、起動のどの段階でロードされるかによっては、initramfs への反映が必要になる。
5.2 initramfs へ反映する
起動の早い段階でロードされるモジュールは、initramfs 内の設定と衝突したり、古い initramfs が残っていると期待通りにならないことがある。したがって、modprobe 設定を書いたら initramfs を再生成しておくのが実務的に安全である。Debian では次の 1 行で良い。
1 | sudo update-initramfs -u |
その後再起動する。
1 | sudo reboot |
ここまでで改善する場合もあるが、今回のケースでは「起動時ロードの確実性」をもう一段固める必要があった。
5.3 /etc/modules に btusb を追加して「起動時に確実に読む」
再起動で戻るタイプの障害では、「起動時に btusb がいつロードされるか」「その時点でどの状態の USB デバイスに当たるか」が揺れることがある。これを抑えるために、起動時に btusb を確実にロードさせる。Debian では古典的に /etc/modules を使えるし、systemd 系なら /etc/modules-load.d も選択肢になる。ここでは最小の変更で済む /etc/modules を採用する。[9]
1 | echo btusb | sudo tee -a /etc/modules |
この一行は「起動時に btusb をロード対象に含める」だけで、ドライバの挙動を勝手に変えるものではない。modprobe.d の options と組み合わせることで「起動時に btusb がロードされ、ロード時に reset=1 が効く」状態を作る。
追記後は、再度 initramfs を更新して再起動する。
1 2 | sudo update-initramfs -u sudo reboot |
この 3 点セット（modprobe 設定、initramfs 更新、/etc/modules 追記）により、起動時に BD Address がゼロへ落ちる再発が止まり、安定して HCI が UP する状態に入った。
5.4 恒久対策まとめ
| 対策 | 目的 | 設定内容 |
|---|---|---|
| btusb reset 強制 | 起動時の HCI reset 失敗回避 | /etc/modprobe.d/btusb.conf に reset=1 を設定 |
| USB autosuspend 無効化 | 初期化直後・アイドル時の不安定動作防止 | /etc/modprobe.d/btusb.conf に enable_autosuspend=0 を設定 |
| 起動時 btusb 読み込み固定 | ロード順序の揺れによる再発防止 | /etc/modules に btusb を追加し initramfs 更新 |
6. 復旧判定（正常状態の条件）
恒久復旧の判定は「GNOME のトグルがオン」ではなく、HCI が成立していることを機械的に確認して行う。順序は次の通り。
まず hciconfig -a を確認する。
1 | hciconfig -a |
チェックポイントは次の通り。
- BD Address が 00:00:00:00:00:00 ではなく実値になっている。
- UP RUNNING が付いている。
- Features が埋まり、MTU が 0 ではない。
- しばらく放置して再度見ても DOWN に戻っていない。
次にユーザ空間側の確認をする。BlueZ がコントローラを認識していれば、bluetoothctl show が成立する。[2]
1 2 | bluetoothctl power on bluetoothctl show |
ここで Powered: yes になっていれば、少なくとも「コントローラが存在する」レイヤはクリアしている。以後はデバイス側（Trackpad 等）の問題に移れる。
6.1 復旧判定チェックリスト
| 確認項目 | 判定基準 | 意味 |
|---|---|---|
| BD Address | 00:00:00:00:00:00 ではない | HCI 初期化が成功している |
| HCI 状態 | UP RUNNING | Bluetooth コントローラが動作中 |
| Features / MTU | 数値が埋まっている（0 ではない） | デバイス能力が正しく取得されている |
| 経過観察 | 一定時間後も DOWN に戻らない | 初期化後の安定性が確保されている |
| bluetoothctl show | Powered: yes | BlueZ がコントローラを認識している |
7. Apple Magic Trackpad が動かない場合の整理
Bluetooth コントローラが復旧しても、Magic Trackpad が動かないことがある。ここは「コントローラが見えるか」と「デバイスがペアリングされ、入力デバイスとして使えるか」を分ける。前者が不安定だと後者は絶対に安定しないので、まず 6 章の判定を満たしていることが前提になる。
7.1 スキャンでペアリング広告が見えるか
Trackpad をペアリングモード（LED 点滅）にしてからスキャンする。ペアリングモードが曖昧な場合は、電源を一度 OFF にして 10〜20 秒待ち、ON にして点滅を確認する。周囲にデバイスが多い環境では、RSSI の変動も含めて複数のデバイスが出るので、見えた事実と MAC を記録する。[2]
1 2 | bluetoothctl scan on |
ここで Trackpad が出ない場合は、次が疑い所になる。
- Trackpad がペアリングモードに入っていない。
- Trackpad が別ホストに強く接続されており、広告を出していない。
- コントローラ側が実は安定していない（復旧判定を満たしていない）。
7.2 ペアリング・信頼・接続
デバイスが見えたら、MAC を指定して pair / trust / connect を行う。ここで trust を付けないと「一度繋がるが次回以降は自動接続されない」という運用事故になりやすい。CLI は状態が見えるため、GNOME UI よりも切り分けに強い。[2]
1 2 3 | pair XX:XX:XX:XX:XX:XX trust XX:XX:XX:XX:XX:XX connect XX:XX:XX:XX:XX:XX |
以後、GNOME で入力デバイスとして認識され、カーソルが動くことを確認する。もし接続はできるが入力が動かない場合は、別途 libinput/gnome-settings-daemon 側の話になるが、今回のログと状況から見ると主因はそこではなかった。まずは「コントローラが安定して UP」「BlueZ が controller を持つ」「Trackpad が trust 済み」の 3 点を揃える。
7.3 Magic Trackpad 切り分けの要点
| 層 | 確認観点 | 典型症状 | 結論（次に寄せる場所） |
|---|---|---|---|
| 前提（コントローラ層） | HCI が成立し、BlueZ が controller を保持しているか | scan に何も出ない／出ても不安定、再起動で戻る、接続が切れ続ける | まず 6 章の復旧判定を満たす。ここが不安定だとデバイス側は絶対に安定しない |
| 発見（広告層） | Trackpad がペアリング広告を出しており、スキャンで見えるか | scan しても Trackpad が出ない（周囲の別デバイスは出る） | Trackpad を確実にペアリングモードへ（電源 OFF→待つ→ON→点滅確認）。別ホスト接続が強い場合は切り離す |
| 結合（ペアリング層） | pair / trust / connect が揃っているか | 一度は繋がるが次回自動接続されない、connect してもすぐ切れる | trust を必ず設定し、接続の恒常性を作る（運用事故を防ぐ） |
| 入力（HID/GUI 層） | 接続後に入力デバイスとして有効に動作するか | 接続はできるがカーソルが動かない | まず上 3 層を満たす。なお残る場合は libinput / gnome-settings-daemon 側の問題を疑う |
8. Magic Trackpad の電池残量を upower で確認する
Magic Trackpad は Bluetooth で接続されていても、GNOME の UI だけでは電池残量が分かりにくいことがある。Debian 13 では upower を使うと、UPower が把握している「Bluetooth 入力デバイスのバッテリー」を機械的に確認できる。ここでは「デバイス一覧を列挙して対象を特定し、詳細表示で percentage を読む」という 2 段構成で確認する。
1. 前提
まず Magic Trackpad が Bluetooth 接続済みで、実際にカーソルが動く状態になっていることを確認する。未接続のままだと upower にバッテリー項目が出ないことがある。また、upower が入っていない場合は導入する。
1 | sudo apt install upower |
2. バッテリーデバイスの一覧を列挙する
UPower が認識している電源デバイス一覧を出力する。ここで目的は「Magic Trackpad に対応する battery エントリのパスを見つける」ことにある。iMac 側の内蔵電源（AC / UPS 等）と並んで、Bluetooth デバイスの battery が現れる。
1 | upower -e |
出力例としては次のようなパスが並ぶ。Magic Trackpad の場合、アドレスらしき文字列を含む battery エントリが出ることが多い。
1 | /org/freedesktop/UPower/devices/battery_XX_XX_XX_XX_XX_XX |
3. 対象パスを指定して詳細を表示する
前項で見つけたパスを指定して詳細を表示する。確認したいのは percentage と state（充電中か、放電中か、満充電扱いか）である。まず percentage が読めれば運用上は十分だが、異常に急減する場合は time to empty 等も併せて観測しておくと切り分けが容易になる。
1 | upower -i /org/freedesktop/UPower/devices/battery_XX_XX_XX_XX_XX_XX |
出力の中に percentage が含まれる。ここが実際の電池残量である。
1 | percentage: 82% |
4. 出ない場合の整理
upower -e に Magic Trackpad が出ない場合、ほとんどは「Trackpad がまだ接続されていない」か「接続はできているが安定していない（Bluetooth コントローラ側が揺れている）」のどちらかである。まず 6 章の復旧判定（BD Address が実値、UP RUNNING、bluetoothctl show が成立）を満たしていることを確認し、その上で Trackpad をいったん切断して再接続すると登録されることがある。
1 2 | bluetoothctl disconnect XX:XX:XX:XX:XX:XX bluetoothctl connect XX:XX:XX:XX:XX:XX |
9. 今回の知見（重要ポイント）
今回のトラブルは典型的に次のパターンに該当する。
- Apple Broadcom Bluetooth USB controller を使う。
- Debian / Linux で運用する。
- hciconfig -a が BD Address = 00:00:00:00:00:00 に落ちる。
- dmesg に hci0: command 0x0c03 tx timeout と BCM: Reset failed (-110) が出る。
- lsusb ではデバイスが見えるのに、bluetoothctl では controller 不在になる。
この場合の本質原因は btusb 初期化シーケンスの reset failure であり、rfkill や bluetooth.service の再起動、firmware パッケージの追加だけでは解けない可能性が高い。もちろん firmware が不足していれば別の問題も起こり得るが、今回の「controller が成立しない」症状は reset 失敗の鎖で説明できた。だからこそ、対処の中心は btusb パラメータ（reset 強制、autosuspend 回避）と、起動時にそれを確実に適用するための initramfs と modules の整備になる。
10. 運用上のベストプラクティス
Apple Broadcom Bluetooth 機で Debian を安定運用するなら、初期導入時に次を標準化しておくと再発率が下がる。
- btusb の reset を強制する（reset=1）。
- USB autosuspend を無効化する（enable_autosuspend=0）。
- /etc/modules で btusb の起動時ロードを固定する（必要な場合）。
- 設定変更後は initramfs を更新し、再起動後の hciconfig -a を必ず確認する。
実務上は「一度直ったから OK」ではなく、「再起動後も BD Address が実値で UP のまま」をもって合格とするのが重要である。Bluetooth は周辺機器運用の入り口なので、ここが不安定だと入力系の切断が連鎖し、デスクトップ体験全体が崩れる。逆に言えば、今回のように層を分け、ログで原因を確定し、初期化パラメータと起動時適用を固めれば、以後は安定して運用できる。
参考文献
- Linux Bluetooth subsystem documentation. https://www.kernel.org/doc/html/latest/networking/bluetooth.html
- bluetoothctl(1) manual (BlueZ). https://manpages.debian.org/unstable/bluez/bluetoothctl.1.en.html
- Linux kernel btusb driver (source reference). https://github.com/torvalds/linux/blob/master/drivers/bluetooth/btusb.c
- rfkill(8) manual. https://man7.org/linux/man-pages/man8/rfkill.8.html
- brcmfmac driver documentation (wireless). https://wireless.docs.kernel.org/en/latest/en/users/drivers/brcm80211.html
- linux-firmware repository (Broadcom firmware distribution). https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
- USB power management (autosuspend) documentation. https://www.kernel.org/doc/html/latest/driver-api/usb/power-management.html
- modprobe.d(5) manual. https://man7.org/linux/man-pages/man5/modprobe.d.5.html
- Debian Wiki: Modules (startup module loading). https://wiki.debian.org/Modules