コミュニティソリューション

ZimaOS 1.6.1のbtopでeth0しか表示されない:内蔵モニターとDockerネットワーク名前空間

An April-May 2026 thread where a user with motherboard 1GbE plus a 10GbE expansion NIC could see eth1 in ZimaOS but not in their btop environment. Other users showed the built-in host btop cycling through eth0, eth1, libvirt, docker0, and veth interfaces. Community replies attributed the difference to host versus Docker network visibility, but the original poster never confirmed a working fix.

ソースはbtopの設定問題のように見えますが、実際には2つの異なる実行環境が混在しています。ZimaOSにはv1.3.3以降、組み込みのbtopパフォーマンスパネルがあります。一方、ユーザーはApp Storeからbtopコンテナをインストールすることもできます。コンテナからは通常、コンテナ自身のネットワーク名前空間しか見えませんが、ホスト上のbtopからはホストに公開されているインターフェースを確認できます。

この違いから、ある参加者が切り替えて表示できた理由が説明できます。 eth0, eth1, virbr0, docker0、および複数の veth インターフェースを示す一方、元の投稿者のbtopが表示できたのは lo および eth0。スレッドは依然として、投稿者の正確な構成に対する確認済みの修復方法が示されないまま終わりました。

ZimaOS自体は10GbEインターフェースを使用していた

10GbE拡張インターフェース上でeth1がアクティブであることを示すZimaOSのネットワークウィジェット
問題は、ZimaOSが2つ目のNICを認識できなかったことではありません。

btopはZimaOSの組み込みパフォーマンスパネルとして追加された

IceWhaleはZimaOS 1.3.3で組み込みbtopパネルを導入しました。そのため、現在のユーザーは基本的なシステム監視だけのために別のbtopコンテナをインストールする必要があると考えるべきではありません。

公式の組み込みbtopの機能範囲を参照してください。

ホスト上のbtopで複数の物理・仮想インターフェースを表示した例

システムプロセス、ディスク、ホストのネットワークインターフェースセレクターを表示するZimaOSの組み込みbtop
別のユーザーの組み込みbtopでは、ホストNIC、libvirt、Docker、vethインターフェースを切り替えて表示できました。

Docker上のbtopは、割り当てられたネットワーク名前空間しか認識しない

コミュニティの返信では、App Storeのbtopコンテナからはコンテナ自身のネットワークしか見えない場合があると説明されていました。これは通常のDockerの動作です。アプリケーションは、自身の名前空間に公開されていないホストインターフェースを監視できません。

btopのインターフェースセレクターを変更しても、存在しないインターフェースは作成できない

開始時のネットワークインターフェース選択設定を示すbtopのオプション画面
btopの設定では、すでに認識できるインターフェースから選択できますが、Dockerに隠れたホストNICを公開させることはできません。

Dockerホストネットワークを選択すると、ソースのアプリがクラッシュまたは停止した

元の投稿者は、App Storeのbtopコンテナをホストネットワークに切り替えても問題は解決せず、btopが動作しなくなったと述べています。また、追加することも検討していました。 SYS_PTRACE または SYS_ADMIN.

スレッドではこれらの権限変更の有効性は検証されていないため、1つの統計パネルを表示するためだけに推奨すべきではありません。

ホストのbtopバイナリは存在していたが、ソースでは動作しないとされていた

どのbtopが返されるかを示すZimaOSのSSHターミナル(/usr/bin/btop)
ホストのバイナリは存在していましたが、元の投稿者は依然として起動や使用に問題があると報告していました。

スレッドには確認済みの最終的な修正方法がない

ソース内のIceWhaleスタッフの返信では、投稿者の組み込みbtopが破損していたのか、以前の手動インストールの影響を受けていたのか、それとも別の1.6.1のバグに遭遇していたのかは確定していません。

より安全な現在のアプローチ

  1. まず、組み込みのZimaOS btopパネルを使用してください。
  2. 現在のホストネットワークツールでNICの存在を確認してください。
  3. コンテナ化された監視ツールを使用する場合は、そのネットワーク名前空間を理解してください。
  4. メトリクスのためだけにprivileged/SYS_ADMINへ昇格するのは避けてください。
  5. 組み込みbtopが機能しない場合は、2つ目のbtopパッケージを繰り返し再インストールするのではなく、現在のバージョンとCLIの直接的なエラーを収集してください。

真っ黒なbtopページとeth1が表示されない問題は、別々の症状です

スレッドの初期段階で、元の投稿者は組み込みダッシュボードのbtopを開くと画面が真っ黒になると述べました。その後、動作はするものの lo および eth0。これらを1つの原因としてまとめてはいけません。

組み込みパネルの障害にはホスト側のbtop/ttydセッションが関係している可能性があり、Docker監視ツール内にホストのインターフェースがないのは、名前空間の分離として想定される動作です。

btopのポートが高い、または変化するからといって、それが自動的に根本原因になるわけではない

ZimaOSでは、一部のターミナル形式のツールがWebセッション経由で起動します。ブラウザーにポートエラーや接続エラーが表示されても、物理NICの設定ミスだとは限りません。まずホスト上でコマンドを直接実行し、正確なエラーを記録してください。

監視のためにコンテナ権限を増やしても、無償の解決策にはならない

追加 SYS_ADMIN、広範なデバイスアクセス、または完全な特権モードを使うと、btopに必要な範囲をはるかに超えてホストを公開する可能性があります。さらに network_mode: host コンテナの分離モデルを変えてしまいます。

システムテレメトリには、すべてのインターフェースを列挙するためだけにApp Storeのコンテナへホストに近い権限を付与するより、ホストに統合された正常動作する監視機能を使うほうが望ましいです。

btopを疑う前にホストでeth1を検証する

現在のZimaOSネットワークページまたはホストのネットワークコマンドを確認し、10GbEインターフェースが起動していて、想定されるアドレスを持ち、トラフィックを処理していることを確認してください。ソースではこれが正常に行われ、ZimaOS自体が表示して使用しました。 eth1.

ホストネットワークからインターフェースが見えるのに、コンテナからだけ見えない場合、境界となっているのは監視環境であり、NICドライバーではありません。

現行ZimaOSで組み込みbtopが壊れている場合は、新たなリグレッションとして扱う

ソースは1.6.1上でのもので、現在のZimaOSは1.7.1です。現在も組み込みパネルが真っ黒なら、現在のバージョン、CPUアーキテクチャ、直接 btop 出力、ブラウザーコンソール/セッションエラー、そして復旧や再インストールで変化するかどうかを記録してください。2026年4月のスレッドですでに現在の障害が説明されていると決めつけないでください。

btopネットワークFAQ

eth1がその名前空間から見えない場合、btopでeth1を選択できますか?

いいえ。セレクターは、実行中のプロセスから見えるインターフェースの間でのみ切り替わります。

別のユーザーは、組み込みのbtopでeth1を確認できると認めましたか?

はい。Jamesは、ホストのbtopでeth0、eth1、libvirt、Docker、vethインターフェースを順に切り替えて確認したと報告しました。

ソースでは、安全なDocker権限修正が確認されていましたか?

いいえ。ホストネットワークと追加のケイパビリティについては議論されましたが、最終的に動作する構成は検証されていません。