本文へスキップ

たけぞうBLOG

Ubuntu 26.04でRealtek RTL8156の公式LANドライバーを導入する方法【r8152・DKMS】

たけぞう

Thunderboltハブ経由で接続している2.5GbE LANアダプターに、Realtek公式のLinuxドライバーを導入しました。Ubuntu標準のドライバーでも通信できていましたが、今回はメーカー配布版のr8152 2.22.1へ切り替えています。途中でDKMSのビルドに失敗したため、その原因と修正方法も記録します。

以下は2026年10月23日に実機で確認した手順です。対象はUSB接続のRealtek RTL8156で、PC内蔵LANのRTL8125とは別の機器です。

目次

今回の環境と導入結果

  • OS:Ubuntu 26.04.1 LTS(x86_64)
  • カーネル:7.0.0-38-generic
  • 接続:Thunderboltハブ配下のUSB LANアダプター
  • チップ:Realtek RTL8156、USB ID:0bda:8156
  • 導入したドライバー:Realtek r8152 2.22.1
  • Secure Boot:無効の環境で検証
  • 適用後:2500Mbps・全二重でリンク確立

ハブ自体がThunderbolt接続でも、LANアダプターはUSBデバイスとして見えていました。ハブの名称だけでドライバーを選ばず、USB IDと使用中のドライバーを確認するのが出発点です。

1.LANアダプターと現在のドライバーを調べる

uname -r
cat /etc/os-release
lsusb
ip -br link

今回のUSB IDは 0bda:8156 でした。ネットワークインターフェース名は環境によって異なります。次のコマンドで一覧を確認できます。

ls /sys/class/net

以降は、調べたインターフェース名を変数に設定して確認します。enxXXXXXXXXXXXXは実際の名前に置き換えてください。

IFACE=enxXXXXXXXXXXXX
readlink -f "/sys/class/net/$IFACE/device/driver"
modinfo r8152
cat "/sys/class/net/$IFACE/operstate"
cat "/sys/class/net/$IFACE/speed"
cat "/sys/class/net/$IFACE/duplex"

導入前から標準の r8152 が読み込まれ、2.5Gbpsでリンクしていました。標準版はカーネルと一緒に管理されるため、メーカー版とバージョン番号だけで新旧を比較することはできません。今回の作業は、動作している標準版からメーカー配布版への切り替えです。メーカー版適用後の実測結果は後半に掲載しています。標準版との比較測定はしていません。

2.Realtek公式サイトからドライバーを取得する

Realtek USB Ethernetドライバーの公式配布ページを開き、「Unix (Linux)」の項目からダウンロードします。確認時点の最新版は 2.22.1(公開日:2026年6月10日)で、対応範囲はカーネル7.0までと記載されていました。

取得したファイル名は r8152-v2.22.1.tar.gz です。以下はこのアーカイブを ~/Downloads に保存した場合の例です。ブラウザーの保存先や実際のバージョンに合わせて読み替えてください。

3.ビルド環境を用意する

sudo apt update
sudo apt install build-essential dkms "linux-headers-$(uname -r)"
mokutil --sb-state

実機ではSecure Bootが無効でした。有効な環境では、署名に使う鍵のMOK登録などが別途必要になることがあります。ビルドに成功しても、鍵が信頼されていないとモジュールを読み込めないため、本記事の検証条件と区別してください。

4.ソースを配置してDKMSを設定する

まずアーカイブ内のファイル構成を確認し、展開します。以下は初回導入向けです。既に同じバージョンを登録している場合は、ソース配置と dkms add を繰り返さず、設定を確認してビルドから進めてください。

tar -tzf ~/Downloads/r8152-v2.22.1.tar.gz
sudo tar -xzf ~/Downloads/r8152-v2.22.1.tar.gz -C /usr/src
sudo mv /usr/src/r8152-v2.22.1 /usr/src/r8152-2.22.1

次に /usr/src/r8152-2.22.1/dkms.conf を作成します。ここが今回つまずいた箇所です。カーネルのビルドディレクトリを -C で指定し、モジュールのソースディレクトリを M= で渡します。

sudo tee /usr/src/r8152-2.22.1/dkms.conf > /dev/null <<'CONF'
PACKAGE_NAME="r8152"
PACKAGE_VERSION="2.22.1"
BUILT_MODULE_NAME[0]="r8152"
DEST_MODULE_LOCATION[0]="/updates/dkms"
AUTOINSTALL="yes"
MAKE[0]="make -C /lib/modules/$kernelver/build M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build modules"
CONF

ヒアドキュメントの終端を 'CONF' と引用しているのは、ファイル作成時に変数が展開されるのを防ぐためです。$kernelver などはDKMSが設定を読み込む際に使います。

5.ビルド・インストールと起動イメージの更新

sudo dkms add -m r8152 -v 2.22.1
sudo dkms build -m r8152 -v 2.22.1 -k "$(uname -r)"
sudo dkms install -m r8152 -v 2.22.1 -k "$(uname -r)"
sudo depmod -a "$(uname -r)"
sudo update-initramfs -u -k "$(uname -r)"

各コマンドが成功したことを確認してから、次に進みます。今回のインストール先は /lib/modules/7.0.0-38-generic/updates/dkms/r8152.ko.zst でした。DKMSに登録することで、対応する将来のカーネルに対しても自動再ビルドされます。ただし、新しいカーネルとの互換性まで保証されるわけではありません。

6.ドライバーを切り替える

ローカルの端末で次を実行します。r8152を使う有線LANが一時的に切断されるため、そのLAN経由のSSHセッションでは行わないようにします。

sudo modprobe -r r8152
sudo modprobe r8152

取り外しに失敗するなど、その場で再読み込みできない場合は、インストール成功を確認したうえで再起動して切り替える方法もあります。今回は再読み込みに成功し、再起動は不要でした。

7.メーカー版の適用とリンク速度を確認する

cat /sys/module/r8152/version
modinfo -F version r8152
modinfo -F filename r8152
dkms status -m r8152
cat "/sys/class/net/$IFACE/operstate"
cat "/sys/class/net/$IFACE/speed"
cat "/sys/class/net/$IFACE/duplex"

実機では次の結果を確認できました。/sys/module/r8152/version は現在読み込まれているモジュールの情報なので、ファイルのインストールだけでなく切り替えまでできたか確認できます。

v2.22.1 (2026/06/03)
/lib/modules/7.0.0-38-generic/updates/dkms/r8152.ko.zst
r8152/2.22.1, 7.0.0-38-generic, x86_64: installed (Original modules exist)
up
2500
full

ドライバー内部の日付は 2026/06/03 で、公式サイトの公開日 2026/06/10 とは異なりますが、どちらも今回取得した2.22.1の情報です。2500 はリンク速度が2500Mbpsという意味で、インターネットやファイル転送の実効速度を測定した値ではありません。

トラブル対処:DKMSで「No rule to make target modules」が出た場合

最初は次の設定でビルドしようとして失敗しました。

MAKE[0]="make KERNELDIR=/lib/modules/$kernelver/build modules"

ログには、次のようなエラーが出ていました。

/bin/sh: 1: test: -lt: unexpected operator
/bin/sh: 1: test: -eq: unexpected operator
make: *** No rule to make target 'modules'.  Stop.

DKMSはmakeコマンドに KERNELRELEASE を付け加えます。一方、このメーカー配布Makefileは KERNELRELEASE の有無で処理を分岐するため、上記の呼び出しでは想定と異なる分岐に入りました。第4節のようにカーネルのビルドディレクトリから M= を使って呼び出す設定へ変更すると、ビルドとインストールに成功しました。

同じ症状では、まず次のログを確認します。署名鍵の案内や binary package ... not found という表示だけで原因を判断せず、make.log内の実際のエラーを読みます。

sudo cat /var/lib/dkms/r8152/2.22.1/build/make.log

既にDKMSへ追加済みで、ビルドだけが失敗している場合は、dkms.confを修正してから第5節の dkms build 以降を再実行します。

標準ドライバーへ戻す場合

メーカー版を外す場合は、DKMSから削除して依存関係と起動イメージを更新します。以下は今回の登録名とバージョンに対する復旧用の手順例です。今回の実機ではロールバック自体は実施していません。

sudo dkms remove -m r8152 -v 2.22.1 --all
sudo depmod -a
sudo update-initramfs -u -k "$(uname -r)"
modinfo -F filename r8152

標準版のパスが表示されることを確認したら、ローカル端末でモジュールを再読み込みするか、再起動します。updates/dkms のパスが残る場合は、他のDKMS登録や別途導入したモジュールがないか確認してください。

実測:メーカー版適用後の転送速度

2026年10月23日(日本時間)に、r8152 2.22.1適用後の実効速度を測定しました。下りはPCが受信、上りはPCから送信する方向です。有線LANインターフェースを明示して測定し、Wi-Fiの通信と区別しています。標準ドライバーでの同条件測定は行っていないため、この結果だけでドライバー変更による速度向上は判断できません。

LAN内:Proxmoxとiperf3でTCP転送

Ubuntuをサーバー、LAN内のProxmoxをクライアントにして測定しました。Ubuntuの有線IPで待ち受け、ポートは15202を使用しています。各回はウォームアップ2秒を除外した10秒間です。下りはProxmoxからUbuntuへの受信、上りはUbuntuからProxmoxへの送信で、表はUbuntu側のログに記録された値です。上りは送信側の値であり、Proxmox側の受信値との厳密な一致は検証していません。

接続数・方向 測定値(Gbps) 回数 中央値
1接続・下り 1.491 1 1.491 Gbps
1接続・上り 2.348 / 2.351 2 2.350 Gbps
4接続・下り 1.640 / 1.908 / 1.788 3 1.788 Gbps
4接続・上り 2.353 / 2.352 / 2.354 3 2.353 Gbps

接続できずタイムアウトした試行は帯域測定として数えず、表は転送が完了した試行を掲載しています。測定中にオフロードやフロー制御の設定は変更していません。下りと上りの差は観測事実ですが、ドライバー、USB経路、対向機器のどこが制約かは今回の測定だけでは断定できません。

# Ubuntu側:有線IPを指定して起動
iperf3 -s -B UBUNTU_WIRED_IP -p 15202

# Proxmox側:下り(Proxmox → Ubuntu)
iperf3 -c UBUNTU_WIRED_IP -p 15202 -P 4 -t 10 -O 2

# Proxmox側:上り(Ubuntu → Proxmox)
iperf3 -c UBUNTU_WIRED_IP -p 15202 -P 4 -t 10 -O 2 -R

# 1接続測定では -P 1 に変更する

最初は双方の測定ポートへの接続がタイムアウトしました。UbuntuでUFWが有効だったため、ProxmoxのIPから有線インターフェースのTCP 15202番への通信だけを一時許可したところ接続できました。この一時許可は測定後に削除しています。ファイアウォール全体の無効化は行っていません。

インターネット経由:CloudflareへのHTTPS転送

21時11分台にCloudflareの測定用エンドポイントへ、下りはGET、上りは生成したゼロ埋めデータのPOSTで転送しました。1接続あたり50,000,000バイトを送り、1接続と4接続同時転送をそれぞれ上下3回ずつ実施しています。これはcurlによる独自の固定サイズ転送テストで、Cloudflareのブラウザー版Speed Testと同じ集計方法ではありません。

接続数・方向 1回目 2回目 3回目 中央値
1接続・下り 0.941 Gbps 0.975 Gbps 0.839 Gbps 0.941 Gbps
1接続・上り 0.506 Gbps 0.312 Gbps 0.566 Gbps 0.506 Gbps
4接続・下り 1.518 Gbps 0.056 Gbps 1.412 Gbps 1.412 Gbps
4接続・上り 0.933 Gbps 0.949 Gbps 1.604 Gbps 0.949 Gbps

速度は「実際に転送できた総バイト数×8÷全転送の完了までの実時間」で計算しました。接続確立、TLS、サーバー応答待ち、curlの起動時間も含むため、持続的な大容量転送の上限値を表すものではありません。全リクエストはHTTP 200で完了しています。

4接続・下りの2回目は完了まで約28.45秒かかり、約0.056Gbpsまで低下しました。この値も除外せず掲載しています。遅延がNIC、経路、測定先のどこで起きたかは、この測定だけでは特定できません。インターネット経由の数値にはISPや測定先の影響も含まれるため、LANアダプター単体の性能とは分けて読みます。

有線経路を指定したダウンロード例:

curl --interface YOUR_WIRED_INTERFACE   --fail --max-time 40 --output /dev/null   --write-out 'bytes=%{size_download} time=%{time_total} speed=%{speed_download}\n'   'https://speed.cloudflare.com/__down?bytes=50000000' 

speed_download の単位はバイト/秒です。4接続の集計では、各接続の速度を単純に足さず、同時開始から最後の接続が完了するまでの時間と合計転送量から計算しました。

測定用エンドポイントの出典:Cloudflare公式Speed Testエンジン。

今回確認できたこと

Realtek RTL8156のUSB LANアダプターにメーカー版r8152 2.22.1を導入し、Ubuntu 26.04.1 LTS・カーネル7.0.0-38-genericで読み込めました。適用後も2.5Gbps・全二重でリンクし、LAN内TCPの4並列測定では下り中央値1.788Gbps、上り中央値2.353Gbpsでした。これはメーカー版適用後の測定結果で、標準版からの改善幅を示すものではありません。DKMSを使う際は、メーカーMakefileの分岐を踏まえてカーネルビルドシステムを直接呼び出す設定にすることが、今回のポイントでした。

参考情報

この記事をシェア

この記事を書いた人: たけぞう

熊谷に住みながら都内のIT企業でエンジニアをしています。このブログでは、実際に使い込んだガジェットやアウトドア用品をエンジニアの視点でレビュー。良い点も気になる点も正直にお伝えするので、モノ選びの参考にしていただければ嬉しいです。 趣味はスポーツジムでのトレーニングとジョギング。ランニングギアやトレーニング関連のアイテムも、実際に使った印象をレビューしていきます。