
opkgは楽しい。でも入れすぎ注意|LN6001-JPで追加パッケージを安全に使う【OpenWrt集中連載024】
診断ツールやLuCIの追加画面を足せる opkg。導入前に、用途、現在のファームウェアとの互換性、空き容量、依存関係、戻し方を確認します。
対象はメーカー提供のOpenWrtベースのOS、ファームウェア1.2.0.15です。別のOpenWrt環境と配布元・パッケージ形式が同じとは限りません。
この連載では、Linksys Velop WRT Pro 7(LN6001-JP)を使いながら、家庭・小さなオフィス・店舗でOpenWrtルーターを現実的に使う方法をまとめています。
連載目次: LN6001-JPで始めるOpenWrtルーター実践ガイド
最初に覚えるのは五つだけ
パッケージ管理では、似た名前の操作を区別します。

opkg update
opkg list | grep -i '<keyword>'
opkg install <package>
opkg list-installed
opkg remove <package>
opkg update は、配布元からパッケージ一覧を取り直す操作です。インストール済みパッケージを一括更新する opkg upgrade とは意味が違います。
この連載では、ルーター上の opkg upgrade による全体更新を勧めません。LN6001-JPの基本システムは公式ファームウェアとして整合性を保って提供されます。必要な更新は公式ファームウェアを基準にし、追加パッケージはその環境へ合わせて管理します。
入れる前に六つ確認する
インストールより、事前確認のほうが重要です。

何を解決するために入れるか
LN6001-JPの現在のファームウェアに対応するか
配布元は信頼できるか
/overlay に十分な空きがあるか
依存パッケージと通信への影響は何か
削除または復旧する手順があるか
空き容量は読み取り専用で確認できます。
df -h
/overlay が逼迫すると、設定保存や更新に影響します。表示された空き容量とパッケージ本体の大きさだけで判断せず、依存関係、ログ、一時ファイル、将来の設定増加にも余裕を残します。
feedは「同じCPUなら使える」では選ばない
feedは、インストールするパッケージの配布元です。CPUの種類が合っていても、対象ファームウェア、ライブラリ、kernelとの組み合わせが違えば、そのバイナリが動くとは限りません。ABIは、コンパイル済みプログラムとライブラリなどがやり取りする際の互換性のことです。
現在のメーカー製ファームウェア用feedを、名前が似ているupstreamのリリース用やsnapshot用へ書き換えて「新しくする」ことは避けます。パッケージが見つからない時は、配布元の対応条件を確認し、無関係なfeedを足して解決しないようにします。all と付くパッケージでも、依存するコマンドや設定形式まで全環境で同じという意味ではありません。
導入元URL、パッケージの版、対象ファームウェア、依存関係を一緒に記録します。違いが分からない場合は、003のメーカー製ファームウェアとupstreamの説明に戻って前提をそろえてください。
導入前の状態を保存する
追加前と追加後を比べられるようにします。

date
ubus call system board
df -h
opkg list-installed
ifstatus wan
ifstatus wan6
ip route show
ip -6 route show
LuCIの System → Backup / Flash Firmware から設定バックアップも作ります。
特に、Adblock、DNS、VPN、Firewall、IPv4 over IPv6に関係する機能を追加する前は、通常のIPv4・IPv6通信、DNS名前解決、LuCIへの管理アクセスが正常なことを確認します。
安全な導入は一本道にする
一度に複数入れると、問題が起きた時に原因を分けられません。

用途を一つ決める
バックアップと状態記録を取る
opkg update を実行する
パッケージ名、説明、依存関係を確認する
一つだけインストールする
service、LuCI、通信を確認する
結果と戻し方を記録する
検索例です。
opkg list | grep -i 'tcpdump'
実際のパッケージ名や提供状況は、ファームウェアとfeedによって変わります。検索結果を確認してから、表示された正しい名前を指定します。
opkg install <package>
インストール成功の表示だけで終わりにしません。目的の機能が動き、通常通信や管理画面に副作用がないことを確認します。
最初に向くもの・慎重に扱うもの
追加機能は、影響範囲で分けると判断しやすくなります。

比較的限定的: 通信診断、HTTP確認、ログ閲覧の補助
管理画面の追加: luci-app-*。本体パッケージとの組み合わせを確認
DNS関連: 名前解決全体へ影響するため慎重に
Firewall・経路関連: 有線の管理経路とバックアップを確保
VPN関連: service、interface、route、外部承認まで確認
kmod-*: kernelとの互換性が必須
「人気がある」ことと、「このLN6001-JPへ今入れて安全」は同じではありません。目的がなく、影響範囲を説明できないものは入れないほうがよいです。
kmodはkernelとの組み合わせを見る
kmod-* はkernel moduleです。kernelの版やビルド構成と合わなければ導入できない、または正しく動かないことがあります。

現在のkernelは次で確認できます。
uname -r
uname -r の表示が一致することだけでは十分ではありません。kernel moduleはビルド構成にも依存するため、対象ファームウェア向けに提供された組み合わせで確認します。
エラーに kernel、architecture、incompatible、cannot satisfy dependencies などが出た時は、強制インストールで突破しないでください。
インターネット上で見つけた .ipk を、出所や対象バージョンを確認せず手動導入するのも危険です。公式feedまたはLinksysが案内する信頼できる配布経路を優先します。
公式モジュールがある機能は先に確認する
LN6001-JPには、Linksysが案内している機能と導入経路があります。

たとえば、WireGuard・Tailscale向けのVPN Assistantや、日本のIPv4 over IPv6環境向けのオートIPoEがあります。
同じ目的の一般パッケージを探す前に、次を確認します。
Linksysの案内に対象機能があるか
現在のファームウェアに対応しているか
LuCIから管理できる公式の導入経路があるか
既存モジュールと競合しないか
公式モジュールなら絶対に問題が起きない、という意味ではありません。しかし、LN6001-JP向けに案内された構成を基準にしたほうが、導入手順とサポートの境界が明確になります。
削除する時も先に依存関係を見る
不要になったパッケージは整理します。ただし、名前だけを見て削除しないでください。

確認することです。
そのパッケージを必要とする機能がないか
LuCIアプリと本体パッケージの関係
削除後も設定ファイルが残るか
service、DNS、Firewall、routeが元へ戻るか
再導入に必要な設定と記録があるか
削除前にも opkg list-installed と設定バックアップを残します。対象を確認したうえで削除します。
opkg remove <package>
削除後はLuCIへ入れるか、IPv4・IPv6、DNS、関係するserviceが正常かを確認します。
削除しても通信が戻らない時は、残ったDNS・Firewall・経路設定を導入前の記録と比較します。依存パッケージまで推測で消さず、復旧範囲を一つずつ確かめます。設定を戻す判断は023のバックアップと復元を参照してください。
ファームウェア更新の前後で棚卸しする
追加パッケージは、ファームウェア更新後に本体がなくなったり、再導入が必要になったりする場合があります。

更新前は「導入前の状態を保存する」のコマンドと設定バックアップに、用途・外部承認・正常時の確認結果を添えます。
更新後は、古い一覧をそのまま自動再導入しません。新しいファームウェアで必要性と互換性を確認し、一つずつ入れ直してテストします。新しいファームウェアに標準搭載された機能を、重複して追加しないことも大切です。
upstreamへ移行したら、パッケージ管理も確認し直す
upstream OpenWrtでは、25.12からパッケージマネージャーが opkg から apk へ変わっています。これはOpenWrt側の変更で、現在のLN6001-JPのメーカー製ファームウェアに apk を追加すれば移行できる、という意味ではありません。
移行先の版に合わせ、管理コマンド、パッケージ形式、feed、追加モジュールの対応を確認します。本記事の opkg コマンドや手元の .ipk が、そのまま移行後も使えるとは考えないでください。通常のメーカー更新との違いは020の更新前チェックにまとめています。
エラーは強制せず意味を分ける
よくある失敗は、原因ごとに次の確認へ進みます。

opkg update 失敗: WAN、DNS、時刻、feed URL
packageが見つからない: 一覧更新、名前、対応feed
dependency不足: kernel、architecture、ファームウェアとの組み合わせ
No space left on device: /overlay、不要パッケージ、ログ
LuCIへ表示されない: 本体とLuCIアプリ、Web画面の再読込
導入後に通信異常: DNS、Firewall、route、直前の変更
依存関係の無視や強制オプションは、問題を先送りするだけです。理由が分からない時は止まり、状態とエラー全文を保存します。共有する場合は、IP、MAC、SSID、feed認証情報などを伏せます。
パッケージ台帳を作る
追加した理由が分からなくなると、削除も更新もできません。

最低限、次を残します。
パッケージ名とバージョン
導入日とファームウェア版
目的
設定ファイルとLuCI画面
通信への影響
正常確認の方法
削除・復旧手順
店舗や小規模オフィスでは、導入者だけでなく、次の管理者が読んで判断できる表現にします。「必要そうだったから」ではなく、「Guest Wi-FiのDNS広告ブロックに使用。通常DNSとGuest通信を確認」のように残します。
必要な機能を説明できる状態にする
一つずつ導入し、動作と通常通信を確認して台帳へ残します。更新後は古い一覧を一括投入せず、新しい環境で必要なものだけを選び直してください。