Apt

自宅ネットワークのRaspberry Piを全部まとめて更新した。 TL;DR Pi 8台を full-upgrade して、カーネルを揃えた。 台数分のダウンロードが重かったので、apt-cacher-ng を1台立てた。上流から落としたのは1台目の約268MBが中心で、2台目以降は0〜1MBだった。 一番手こずったのは、資料に全部bookwormと書いてあったのに、実機の1台だけbullseyeだったこと。ここから連鎖的にハマった。 構成 8台とも自宅NWで動いてる。 役割 台数 備考 ゲートウェイ 2 Keepalived（MASTER/BACKUP）、Tailscale GW DNS/DHCP 1 dnsmasq WiFi AP 2 hostapd、ブリッジ構成 監視ホスト 1 Pi 5 予備 2 Pi3, Pi4 apt update は、各ノードが週1のsystemd timerで勝手に実行する設定にしてある。upgrade のほうは、月次で手動にしたかった。 資料は全部bookworm、実機は違った 更新の前に、まず各ノードのOSを確認した。自分で作った資料には全部bookwormと書いてあったので一応調査。 実機を見たら、DNS用の1台だけがbullseye（32bit）だった。 資料には、OSの版だけでなく、IP、WiFiのチャンネル、ドメインまで食い違いがあったので都度修正した(Claudeが) ちまちま修正したりファイル化もいいけど少し前からclaudeのコネクタ機能を使ってNotionにガリガリ書いたり読んだりしてる。かなり便利 なおbullseyeは、Debian公式の告知では2026年8月31日にLTSも含めてサポートが終了している。 DNS用ノードをin-placeでbullseyeからbookwormへ 前節に書いたとおり、このノードのbullseyeはすでにサポートが切れていた。 bullseyeからbookwormへのin-placeアップグレードは公式は勧めていない。 Raspberry Piの公式ニュース記事にはメジャーバージョンの更新はSDカードを焼き直すのが基本と書いてある。 それでも今回は、再インストールではなくin-placeで上げた。 できないわけではないし自宅NWには迂回路があって失敗しても致命傷にはならないと判断した。 落とし穴は4つあった。 1. /boot が /boot/firmware に変わる bookwormのRaspberry Pi OSでは起動パーティションのマウント先が /boot から /boot/firmware に変わった。そのため、fstabを直す必要があった。 Raspberry Pi公式のconfig.txtのドキュメントに、Bookwormより前は起動パーティションは /boot/ にあったという趣旨の注記がある（出典参照）。bullseyeからのアップグレード手順をまとめた個人のgistにも、同じ内容の手順が載っていた。実機でも、fstabを直さないと起動パーティションの扱いがおかしくなった。 2. 旧カーネルパッケージが止まっている 旧体系の raspberrypi-kernel は、更新が止まっていた。 新しい体系（raspi-firmware と linux-image-rpi-v7）を、明示的にinstallして切り替えた。 ...