ここでは以下のような環境を前提にしている。

• ホスト OS: Debian 13 (trixie)
• Kernal: 6.18.5 (trixie-backports)

参考: 2026年のローカルLLM事情を整理してみた

Ollama は手軽にオープンソース大規模言語モデル（LLM）を起動・管理できるプラットフォーム

オフィシャルの Docker image を使ってもいいし GitHub に置いた ollama-docker を使ってもいい

私は GLM-OCR を試すために Ollama を使ってみたが、非常に簡単に使うことができた
ollama-docker を使うならば以下のようにすればすぐに使える

$ docker compose exec ollama ollama run glm-ocr

llama.cpp

llama.cpp は Ollama よりは使い勝手が良くないが、 チューニングをすることで Ollama よりも高速にオープンソース大規模言語モデル（LLM）を実行できる

オフィシャルの Docker image に ROCm 版があるのでそのまま使うこともできるが、 多少使い勝手を改善したものを GitHub の llama-cpp-docker に置いた

Ollama では GPU の VRAM 容量により実行できるモデルに制限を受けるが、 llama.cpp は CPU MeE Offloading により限られた VRAM でも大規模 MoE モデルを実用的な速度で動かすことができる
ローカルLLMを試す に NVIDIA GPU を使った例が出ている

私も同様のことを試したが、自分の環境は APU と dGPU の両方が搭載されており、ちょっと違う状況がになった

元々 APU は VRAM ではなく CPU 側のメモリを扱えるようになっているため、 --cpu-moe や --n-cpu-moe を指定するとかえって効率が落ちてしまう結果となった
--split-mode を none にして dGPU だけで処理するようにすると想定した動きをしているように見える

試行回数が少ないので性能的なところははっきりしないが、 MoE を使わず遅い APU 側の負荷が大きくなっても遜色ない性能が出ているようには見える
ここで試したモデルは gpt-oss-20b なので、もっと大容量の VRAM を必要とするモデルならば差が出てくるかもしれない

MoE 関連パラメタ無し

[ Prompt: 188.9 t/s | Generation: 25.1 t/s ]

| memory breakdown [MiB] | total    free     self   model   context   compute       unaccounted |
|   - ROCm0 (RX 6600M)   |  8176 =  2118 + ( 5760 =  3454 +    1030 +    1276) +            297 |
|   - ROCm1 (680M)       | 15683 = 12867 + (10491 =  7495 +    2060 +     935) + 17592186036740 |
|   - Host               |                   1628 =   586 +       0 +    1041                   |

--cpu-moe (LLAMA_ARG_CPU_MOE=1)

[ Prompt: 105.9 t/s | Generation: 17.9 t/s ]

| memory breakdown [MiB] | total    free     self   model   context   compute       unaccounted |
|   - ROCm0 (RX 6600M)   |  8176 =  6146 + ( 1734 =   245 +    1031 +     456) +            295 |
|   - ROCm1 (680M)       | 15683 = 18944 + ( 3453 =   996 +    2058 +     398) + 17592186037701 |
|   - Host               |                  11218 = 10949 +       0 +     268                   |

--n-cpu-moe 12 (LLAMA_ARG_N_CPU_MOE=12)

[ Prompt: 99.6 t/s | Generation: 19.7 t/s ]

| memory breakdown [MiB] | total    free    self   model   context   compute       unaccounted |
|   - ROCm0 (RX 6600M)   |  8176 =  6174 + (1705 =   218 +    1030 +     456) +            296 |
|   - ROCm1 (680M)       | 15683 = 16112 + (8335 =  5877 +    2060 +     398) + 17592186035651 |
|   - Host               |                  6036 =  5768 +       0 +     268                   |

--split-mode none --main-gpu 0 --n-cpu-moe 12
(LLAMA_ARG_SPLIT_MODE=none LLAMA_ARG_MAIN_GPU=0 LLAMA_ARG_N_CPU_MOE=12)

[ Prompt: 198.3 t/s | Generation: 29.9 t/s ]

| memory breakdown [MiB] | total   free    self   model   context   compute    unaccounted |
|   - ROCm0 (RX 6600M)   |  8176 =  930 + (6950 =  6095 +     456 +     398) +         295 |
|   - Host               |                 5817 =  5768 +       0 +      49                |

追試

やはりモデルによっては圧倒的に dGPU で MoE を使った方が速い

最初に試した Qwen3-30B-A3B:Q8_0 では:

• MoE 無し: モデルロード時にエラー
• --cpu-moe : モデルロードには成功するが、プロンプト入力後システムが激重になって動作不能
  恐らく MoE も APU も同じメモリ資源をピンポンしていて swap 出まくりになったと思われる (--cpu-moe を調べる価値は無さそう)

     model      |                   no MoE                     | --split-mode none --main-gpu 0 --n-cpu-moe 12
Qwen3-8B:Q8_0   | [ Prompt: 215.1 t/s | Generation:  9.0 t/s ] |          モデルロード時にエラー
Qwen3-8B:Q4_K_M | [ Prompt: 196.7 t/s | Generation: 13.2 t/s ] | [ Prompt: 427.8 t/s | Generation: 34.5 t/s ]
Qwen3-4B:Q8_0   | [ Prompt: 266.6 t/s | Generation: 16.3 t/s ] | [ Prompt: 864.0 t/s | Generation: 40.5 t/s ]

PyTorch on ROCm

pyTorch もオフィシャルで ROCm 対応 が進んでいるので、割といろんなものが動かせるようになっている

オフィシャルの Docker image を使う手もあるが、 このイメージでは pyTorch が /opt/venv という扱いにくい場所にインストールされている（pip で Python パッケージを追加インストールする際にも Docker インスタンス内の /opt/venv 配下に入れることになる）ため、 以前書いた ROCm-docker 上で pyTorch をインストールする方がベター

ROCm-docker を使う場合には以下のようにして pyTorch をインストールする

$ docker compose run --rm devterm

$ ROCM_VER=7.1
$ GFX_ARCH=gfx103X-dgpu
$ python3 -m venv torch
$ . torch/bin/activate
(torch) $ pip install uv
(torch) $ uv pip install torch torchvision torchaudio \
        --index-url https://download.pytorch.org/whl/rocm${ROCM_VER} \
        --extra-index-url https://rocm.nightlies.amd.com/v2/${GFX_ARCH}

【追記】 現在の私の ROCm-docker はマルチステージ Dockerfile に変更するとともに uv コマンドを devterm service のコンテナイメージに含めている
uv を使う場合には以下のようにすればいい

$ ROCM_VER=7.1
$ GFX_ARCH=gfx103X-dgpu
$ uv venv torch
$ . torch/bin/activate
(torch) $ uv pip install torch torchvision torchaudio \
        --index-url https://download.pytorch.org/whl/rocm${ROCM_VER} \
        --extra-index-url https://rocm.nightlies.amd.com/v2/${GFX_ARCH}

ROCM_VER と GFX_ARCH はバージョンや環境に合わせて変更する
GFX_ARCH はオフィシャルの pyTorch でサポートしていない GPU のために追加するコンポーネントであり、 どういう種類のものがあるかは https://rocm.nightlies.amd.com/v2/ を参照
自分の環境の AMD GPU のアーキが何であるかは rocminfo コマンドで確認できる

$ rocminfo | grep gfx
  Name:                    gfx1031                            
      Name:                    amdgcn-amd-amdhsa--gfx1031       

オフィシャルの pyTorch でサポートしている GPU アーキであれば GFX_ARCH の指定や --extra-index-url の指定は必要ない
そうでない場合は表示されたものに近い GPU アーキのものを指定する

Jemm Loadable Module (JLM) という 32bit protected-mode のデバイスドライバや TSR を拡張メモリにロードできるようになった。 この JLM 実装の例として CD/DVD ドライバが同梱された。 今まで SATA 接続の CD/DVD ドライブ用ドライバは安定的に動くものがほとんど無く、特に私のような AMD の Chipset で動くものは皆無だった。 そこに新たに JLM 版の AHCICD ドライバが登場したことで、ようやく安定的に SATA 接続 CD/DVD にアクセスできるようになった。

例によって修正後の自分の FreeDOS/V 環境を晒しておく。

FreeDOS 1.3 リリースに関する記事 や kernel と FreeCOM アップデートの記事 から少し構成を変更し、 \FDOS\JP ディレクトリへ DBCS 版 FreeCOM 以外に日本語関連のドライバ (FDCONFIG.SYS の中から呼ぶもの) を入れるようにした。 本当は FDCONFIG.SYS から呼ぶドライバは全部 \FDOS\BIN から別のディレクトリに移したかったが、とりあえず他はそのまま。

Jemm Releases の v5.83 に同梱されている AHCICD.DLL と XCDROM32.DLL を \FDOS\JLM ディレクトリに格納。

A:\
|  KERNEL.SYS
|  COMMAND.COM
|  AUTOEXEC.BAT
|  FDCONFIG.SYS
|  
\--FDOS
   +--BIN
   |  ...
   |     
   +--XMSSWAP
   |     COMMAND.COM
   |     
   +--JP
   |     COMMAND.COM
   |     FONTN.INI
   |     FONTNX.EXE
   |     04GZN16X.FNT
   |     GURI16X.FNT
   |     GURI19X.FNT
   |     PANSI.SYS
   |     
   \--JLM
         AHCICD.DLL
         XCDROM32.DLL

ディスクスペースに余裕が無くなってきたため DISPVB.EXE 等いくつかファイルを削っている。

 Directory of A:\FDOS\BIN

[.]            [..]           ATTRIB.COM     CHEJ.EXE       CHKDSK.EXE     
COUNTRY.SYS    CP437UNI.TBL   CP932UNI.TBL   CPUID.EXE      CPUSTAT.EXE    
CWSDPMI.EXE    DELTREE.COM    DEVLOAD.COM    DISPV.EXE      DISPVA.EXE     
DOSLFN.COM     DSP4U.COM      DSPVV.COM      EIDL.COM       EMSSTAT.EXE    
FDAPM.COM      FDISK.EXE      FDISK.INI      FDISKPT.INI    FORMAT.EXE     
JEMMEX.EXE     JLOAD.EXE      KEYB.EXE       KEYBOARD.SYS   LABEL.EXE      
MEM.EXE        MEMSTAT.EXE    MI.COM         MODE.COM       MORE.EXE       
MOVE.EXE       MOVEXBDA.EXE   NANSI.SYS      SETVER.SYS     SHSUCDX.COM    
SYS.COM        TREE.COM       UMBM.EXE       V.COM          VASK.COM       
VCHKBOX.COM    VCHOICE.COM    VCLS.COM       VCPI.EXE       VCURSOR.COM    
VDELAY.COM     VDELETE.COM    VEACH.COM      VECHO.COM      VERRLVL.COM    
VFDUTIL.COM    VFONT.COM      VFRAME.COM     VGOTOXY.COM    VINFO.COM      
VINSERT.COM    VLINE.COM      VMATH.COM      VMODE.COM      VPAUSE.COM     
VPCSPKR.COM    VPROGRES.COM   VREADKEY.COM   VSTR.COM       VVER.COM       
VVIEW.COM      XCOPY.EXE      XMSSTAT.EXE    
        71 file(s)        669,028 bytes
         2 dir(s)          48,128 bytes free

FDCONFIG.SYS

ディレクトリ構成変更に追従して若干変更。 JEMMEX 使用を前提として UMBPCI.SYS は完全に外す。

;!SWITCHES=/F
!COUNTRY=081,,\FDOS\BIN\COUNTRY.SYS
!LASTDRIVE=Z
!BUFFERS=20
!FILES=40

!MENUCOLOR=7,1
MENU  FreeDOS
MENU ----------------------------------------------------------------------
MENU   0 - Safe Mode (don't load any drivers)
MENU   1 - XMS
MENU   2 - XMS + EMS
MENU   3 - Japanese + XMS
MENU   4 - Japanese + XMS + EMS
MENU   5 - Japanese + XMS + DPMI
MENU ----------------------------------------------------------------------
MENUDEFAULT=3,10

0? ECHO Warning: basic stuff only!

12345? DOS=HIGH
12345? DOS=UMB
12345? DOSDATA=UMB
135? DEVICE=\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST
24?  DEVICE=\FDOS\BIN\JEMMEX.EXE X=TEST I=TEST
345? DEVICEHIGH=\FDOS\JP\FONTNX.EXE
;12?  DEVICEHIGH=\FDOS\BIN\NANSI.SYS /S
;345? DEVICEHIGH=\FDOS\JP\PANSI.SYS
0?   SHELL=A:\COMMAND.COM A:\ /E:1024 /P=A:\AUTOEXEC.BAT
12?  SHELLHIGH=A:\FDOS\XMSSWAP\COMMAND.COM A:\FDOS\XMSSWAP /E:1024 /P=A:\AUTOEXEC.BAT
345? SHELLHIGH=A:\FDOS\JP\COMMAND.COM A:\FDOS\JP /E:1024 /P=A:\AUTOEXEC.BAT

AUTOEXEC.BAT

Safe mode 以外ではどの CD/DVD ドライバを使うかを選択するように変更。 SATA 接続の場合には AHCICD を、仮想マシンも含め ATA/IDE 接続する場合には XCDROM を選択する。 日本語ディスプレイドライバの選択とは異なり、実際にドライバをロードしてみてエラーしたら再度 CD/DVD ドライバ選択画面に戻る。

@echo off
SET LANG=
SET TZ=JST-9

SET DOSDIR=A:\FDOS
SET PATH=%DOSDIR%\BIN
if not exist C:\FDOS\BIN\HELP.EXE goto FDONLY
SET DOSDIR=C:\FDOS
SET PATH=%DOSDIR%\BIN;%PATH%

if exist %DOSDIR%\NLS\CHOICE.EN SET NLSPATH=%DOSDIR%\NLS
if exist %DOSDIR%\HELP\COMMAND.EN SET HELPPATH=%DOSDIR%\HELP
SET TEMP=%DOSDIR%\TEMP
SET TMP=%TEMP%
:FDONLY

if "%CONFIG%"=="0" goto END

loadhigh FDAPM ADV:REG
loadhigh KEYB JP,932,%DOSDIR%\BIN\KEYBOARD.SYS

if "%CONFIG%"=="1" goto CDROM
if "%CONFIG%"=="2" goto CDROM
if not "%CONFIG%"=="5" goto JP

:DPMI
loadhigh CWSDPMI -p
if exist %DOSDIR%\djgpp\bin\cat.exe SET PATH=%PATH%;%DOSDIR%\djgpp\bin

:JP
vframe /x14 /y8 /h10 /w52 /fBlack /bGray Single Shadow
vecho
vecho /fBlue "  Which driver do you want to use for Japanese?"
vline hidden
vecho "  V: DSPVV"
vecho "  D: DISPV"
vecho "  A: DISPVA"
vecho "  No display driver to load for now."
vchoice /fLightGreen /bBlack /t10 /d1
set choice=%errorlevel%
vgotoxy eot
verrlvl %choice%
set choice=
if errorlevel 4 goto CDROM
if errorlevel 3 goto DISPVA
if errorlevel 2 goto DISPV

:DSPVV
loadhigh DSPVV
goto JP2

:DISPV
loadhigh DISPV /HS=on
goto JP2

:DISPVA
loadhigh DISPVA /HS=on
goto JP2

:JP2
CHEJ JP
rem loadhigh DSP4U /VD=71

:CDROM
if not exist %DOSDIR%\BIN\JLOAD.EXE goto COMMON
if not exist %DOSDIR%\BIN\SHSUCDX.COM goto COMMON
vframe /x14 /y8 /h9 /w52 /fBlack /bGray Hidden Shadow
vecho
vecho /fBlue "  Which driver do you want to use for CD/DVD?"
vline hidden
vecho "  A: AHCICD"
vecho "  X: XCDROM"
vecho "  No CD/DVD driver to load for now."
vchoice /fLightGreen /bBlack /t10 /d3
set choice=%errorlevel%
cls
verrlvl %choice%
set choice=
if errorlevel 3 goto COMMON
if errorlevel 2 goto XCDROM32

:AHCICD
if not exist %DOSDIR%\JLM\AHCICD.DLL goto CDROM
DEVLOAD /H /Q %DOSDIR%\BIN\JLOAD.EXE %DOSDIR%\JLM\AHCICD.DLL /D:AHCICD$$ /R
if errorlevel 1 goto CDROM
goto CDLETTER

:XCDROM32
if not exist %DOSDIR%\JLM\XCDROM32.DLL goto CDROM
DEVLOAD /H /Q %DOSDIR%\BIN\JLOAD.EXE %DOSDIR%\JLM\XCDROM32.DLL /D:XCDROM$$
if errorlevel 1 goto CDROM

:CDLETTER
rem SHSUCDX /QQ /D3
SHSUCDX /QQ /~ /D:?AHCICD$$,Q /D:?XCDROM$$,Q

:COMMON
rem loadhigh DOSLFN
rem loadhigh RDISK /S80 /:R
rem loadhigh CTMOUSE

:END
SET DIRCMD=/P /OGN /Y
rem SET COPYCMD=/-Y
alias reboot=fdapm warmboot
alias reset=fdisk /reboot
alias halt=fdapm acpioff
alias shutdown=fdapm acpioff

なお、ドキュメント上は XCDROM32.DLL のドライバ名のディフォルトは XCDROM$$ と書かれているが、実際には /D: で指定しないとドライバがロードされずエラーとなる。

これは今のディストリビューション (Debian bullseye や Ubuntu 22.04 LTS など) ならば問題ないはず。 非セキュアブート状態で EFI インストールし、後からセキュアブートに変えても起動する。

DKMS ドライバ

以前の記事 でも書いたようにディストリビューション側で用意していない (センサー等の) ドライバを DKMS でインストールすることがある。 DKMS でインストールされるモジュールは自環境でコンパイルするためそのままでは署名はされておらず、セキュアブート環境ではロードされない。

参考

• debian Wiki SecureBoot
• UEFI Secure Boot, Debian, DKMS and the R8125B
• Debian Bug #1019425
• Ubuntu 20.04 その74 - UbuntuとUEFIセキュアブート
• How to sign your own UEFI binaries for Secure Boot

MOK (Machine Owner Key) というマシンの所有者用のキーを作成して UEFI に登録することで、そのキーを使って署名したカーネルモジュール（ドライバ）はセキュアブート環境でも使えるようになる。

大筋は決まっているものの、セキュアブート自体が比較的新しいものということもあり、ディストリビューションによってやり方は異なる。 まずは共通の手順として (まだインストールしていなければ) dkms パッケージをインストールする。

$ sudo apt install dkms

Debian 11 (bullseye)

bullseye の dkms はセキュアブートに関してはあまりやってくれないので、ほとんど手作業で…

MOK の作成

適当な作業ディレクトリで OpenSSL を使用して MOK を作成する

$ openssl req -new -x509 -nodes -days 36500 -subj "/CN=DKMS module signing key" -newkey rsa:2048 -keyout mok.priv -outform DER -out mok.der

bullseye の dkms では /root 配下に MOK が置かれていることを想定しているので移動してパーミッションを変更する

$ sudo mv mok.priv mok.der /root
$ sudo chown root:root /root/mok.priv /root/mok.der

DKMS の設定

DKMS でモジュールをインストールする際に自動的に証明する際には /etc/dkms/sign_helper.sh が使われる。 ただし、デフォルトでは自動署名処理は有効となっていないため設定を変更する。

/etc/dkms/framework.conf の一番下のコメントを外して有効にする。

## Script to sign modules during build, script is called with kernel version
## and module name
sign_tool="/etc/dkms/sign_helper.sh"    ★ コメントを外す

これを見てもわかるように、もし /etc/dkms/sign_helper.sh のやり方が気に入らない (MOK を /root に置くのがイヤ等) ならば、自前でツールを書いてそのツールの場所を指定してもいい。 ^[1]

この後に DKMS でカーネルモジュールをインストールすればあとは自動的にモジュールが署名される。

MOK の UEFI への登録

MOK の UEFI への登録方法にはいくつかあるが mokutil を使用するのが一番簡単。

$ sudo mokutil --import /root/mok.der
input password:          ★ 実際に MOK を Enroll する際に使う一過性のパスワードを指定
input password again:
$ sudo mokutil --list-new
[key 1]
SHA1 Fingerprint: xx:xx:....
Certificate:
    Data:
...
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=DKMS module signing key
        Validity
            Not Before: Mar  5 09:42:50 2023 GMT
            Not After : Feb  9 09:42:50 2123 GMT
        Subject: CN=DKMS module signing key
...
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
...

次回 PC の再起動時に実際の MOK を UEFI に登録する画面が表示されるので Enroll MOK を選択し、先程入力したパスワードを入れれば登録される。 具体的な画面は PC により異なるが Ubuntu の例 を参考に…

再起動後に mokutil --list-enrolled コマンドを実行すると登録済みの MOK が表示され sudo mokutil --list-new では何も表示されなくなる。

Debian 12 (bookworm) 以降

dkms のアップストリームに合わせてやり方が変わっている。

• 事前に MOK を作成する必要はなく、その時点で MOK が存在しなければ DKMS が MOK を自動的に作成
• MOK はデフォルトでは /var/lib/dkms/ 配下に作成
  ※ /etc/dkms/framework.conf か /etc/dkms/framework.conf.d/ 配下のファイルで mok_signing_key や mok_certificate を設定すれば変更可
• 特に設定をしなくても DKMS が自動的にモジュールを署名

ただし MOK を UEFI に登録するところまではやってくれないので bullseye と同様に mokutil で enroll してやる必要がある。

$ sudo mokutil --import /var/lib/dkms/mok.pub
input password:
input password again:

なお、 bullseye からのアップグレードで既に作成済みの MOK をそのまま流用する場合には、上記のように新しい MOK を登録せずに以下のように旧 MOK を移動した方がいいかもしれない。 ただし、アップグレードの際に既に DKMS の管理下になっていたモジュールは dkms により自動的に作成された MOK で署名されている可能性があるので、その場合には dkms でモジュールを再インストールする必要がある。

$ sudo mv /root/mok.der /var/lib/dkms/mok.pub
$ sudo mv /root/mok.priv /var/lib/dkms/mok.key

Ubuntu

Ubuntu (20.04 以降？) では Debian とは異なる独自のやり方をしている。 (恐らく Debian より先行してセキュアブートに取り組んでいたため) Ubuntu では kmodsign というコマンドを使いカーネルモジュールを署名するようになっているが、 Debian にはそのようなコマンドは無い。 また update-secureboot-policy というコマンドは Debian にも Ubuntu にも存在するが、できることが全く異なり別物と考えたほうが良い。

Ubuntu では DKMS でカーネルモジュールをインストールする際に以下のことをする。

• (MOK が存在しなければ) update-secureboot-policy --new-key により MOK を /var/lib/shim-signed/mok/ 配下に生成
• (MOK が登録されていなければ) update-secureboot-policy --enroll-key コマンドで MOK を UEFI に登録
• kmodsign コマンドでモジュールを署名

以降は DKMS でモジュールがインストールされる度に自動的に署名してくれる。

VMware

Windows とのデュアルブート環境とはいえ、実際に Windows 側を立ち上げるのは GPU 等のハードリソースを使うケースに限られ、単に Windows のソフトを使いたい場合には VMware Player を使って Windows VM を立ち上げている。
VMware を動かす際に vmmon.ko と vmnet.ko という２つのドライバが必要となるが、これらは署名されていないためにセキュアブート観葉ではロードされない。 これらのドライバに対しても署名してやる必要がある。

MOK は前述の DKMS 用に作成したものを使う。

• Debian 11 (bullseye)

  $ sudo /lib/modules/$(uname -r)/build/scripts/sign-file sha512 /root/mok.priv /root/mok.der $(sudo modinfo -n vmmon)
  $ sudo /lib/modules/$(uname -r)/build/scripts/sign-file sha512 /root/mok.priv /root/mok.der $(sudo modinfo -n vmnet)
  

• Debian 12 (bookworm)

  $ sudo /lib/modules/$(uname -r)/build/scripts/sign-file sha512 /var/lib/dkms/mok.key /var/lib/dkms/mok.pub $(sudo modinfo -n vmmon)
  $ sudo /lib/modules/$(uname -r)/build/scripts/sign-file sha512 /var/lib/dkms/mok.key /var/lib/dkms/mok.pub $(sudo modinfo -n vmnet)
  

• Ubuntu

  $ sudo kmodsign sha512 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der $(sudo modinfo -n vmmon)
  $ sudo kmodsign sha512 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der $(sudo modinfo -n vmnet)
  

DKMS とは違って新しい Kernel がインストールされる度に自動でやってくれることはないので、 VMware や kernel のアップデートの度にこの作業をする必要がある。

参考

• VMware KB #2146460

rEFInd

Debian 13 (trixie) 【2025/08/14追記】

Debian trixie ではパッケージの rEFInd を使っても問題がなくなった。 既に次項の bookworm で rEFInd をインストールした環境からのアップグレードなら Uninstalling rEFInd from Linux で既存の rEFInd を削除後にパッケージをインストールする。

その後以下のようにして MOK をインポートする。

$ sudo mokutil --import /boot/efi/EFI/refind/keys/refind_local.cer

あとは MOK の UEFI への登録 を参照。

Debian 12 (bookworm)

実はこれが一番厄介な代物で、この記事を書こうと思ったのもこのため。 結論から言うと Debian や Ubuntu のリポジトリにあるパッケージは使うな。 パッケージの rEFInd を使う限りはうまくいかない。
※ これはたまたま rEFInd の新しい版数 0.14.0 がリリースされ、問題が解決しただけかもしれないが…

まずは、カスタマイズ済みの /boot/efi/EFI/refind/refind.conf を退避したら、パッケージをアンインストールして /boot/efi/EFI/refind ディレクトリごとバッサリ削除する。 ただし rEFInd で必要なパッケージ (sbsigntool) はインストールしたままにしておくこと。

次に rEFInd のサイト からダウンロードした binary zip ファイルを適当な作業ディレクトリに展開し、そのディレクトリに移動する。

$ unzip refind-bin-0.14.0.zip
$ cd refind-bin-0.14.0

続いてインストール済みの shim をディレクトリごとワークディレクトリ下にコピーし、署名されたバイナリを扱うように削除・リネームする。

$ cp -a /usr/lib/shim .
$ cd shim
$ rm fbx64.efi mmx64.efi shimx64.efi
$ mv fbx64.efi.signed fbx64.efi
$ mv mmx64.efi.signed mmx64.efi
$ mv shimx64.efi.signed shimx64.efi
$ cd ..

先程コピーした署名付き shim を指定して rEFInd をインストールする。

$ sudo ./refind-install --shim shim/shimx64.efi

これで rEFInd の MOK の import も済んでいるので、再起動時に MOK の Enroll をすれば rEFInd がブートローダとして動くようになる。

/boot/efi/EFI/refind/refind.conf をカスタマイズしていた場合には、再起動前に新たにインストールされた refind.conf にカスタマイズ内容を反映させることを忘れずに。

参考

• A solution to rEFInd unable to load using shim when Secure Boot is enabled

[1]: 個人的には bookworm と同じディレクトリ構成にしたスクリプトに変更することをお薦めする。その方がアップグレードに伴うトラブルが少ない。

しかしながら AI 関連ソフトは GPU を使うものが多く、コンテナ上で GPU を扱ったり GUI (X アプリ) を使えるようにするには工夫が必要なのでここにメモしておく。

なお、ここでは以下のような環境を前提にしている。

• ホスト OS: Debian 11 (bullseye)
• Kernel: 5.18.16 (bullseye-backports)
• コンテナイメージベース OS: Ubuntu 18.04 or 20.04 or 22.04

他の OS 環境でもある程度参考にはなるでしょう。

LXD はコンテナといっても Kernel 以外の OS 環境を構築する軽量 VM のようなもののため単に GUI を使うだけならあまり困らない。 xrdp と任意のデスクトップパッケージをインストールすればリモートデスクトップクライアントを使って GUI は表示できる。 ここではそのようなやり方ではなく、 GPU を使ったり vulkan のようにホスト OS 上の X server にアクセスすることを想定する。

LXD の環境構築 (lxd グループに所属する等) については他のサイトでも詳しく書かれているのでここでは触れない。 以下 Ubuntu 20.04 のコンテナを作成して動かすものとし、コンテナ名を ubuntu2004 と仮定する。 バージョンやコンテナ名については適宜読み替えて欲しい。

コンテナの作成

タグに Ubuntu のバージョン 20.04 を指定し ubuntu2004 という名のコンテナを立ち上げる

host$ lxc launch ubuntu:20.04 ubuntu2004

続いてコンテナ内で shell を起動し必要なパッケージをインストールして GUI を使える状態にする

host$ lxc exec ubuntu2004 -- bash

以下はインストールするパッケージの一例 (実際にインストールパッケージはお好きなように…)

root@ubuntu2004# apt update
root@ubuntu2004# apt install x11-apps dbus-x11
root@ubuntu2004# exit

コンテナ内ユーザとホストユーザのマッピング

Ubuntu のコンテナイメージにはデフォルトで ubuntu というユーザが UID=1000 で定義されているので、これをホスト側のユーザ ID とマップする

host$ lxc config set ubuntu2004 raw.idmap "both ${UID} 1000"

これはホスト側で GID=UID のユーザの GID/UID 両方をコンテナ内の UID=GID=1000 としてマップすることを示す
複数の ID をマップする必要がある場合 (例えば src グループをコンテナ内でも継承する場合) には以下のように改行で区切って指定する

host$ echo -en "both ${UID} 1000\ngid 40 40" | lxc config set ubuntu2004 raw.idmap -

こうすることでコンテナ内でもホスト側のファイルを共用してアクセスしても問題なくなる

コンテナ内から GPU をアクセスできるようにする

GPU をコンテナ内からアクセスできるようにする方法は LXD のドキュメント に書かれている通り

host$ lxc config device add ubuntu2004 gpu gpu gid=$(getent group video | cut -d: -f3)

デフォルトでは GPU のコンテナ内 GID が 0 (root) に設定されてしまうので ubuntu ユーザでもアクセス可能な video グループの GID を割り振る

コンテナ内からホストの X サーバにアクセスできるようにする

ホスト側の /tmp/.X11-unix/ 配下のソケットをコンテナにも見えるようにすればいいのだが、実はこれが厄介。 通常であればコンテナの設定でディレクトリをマウントさせればいいが、 LXD コンテナ起動時のマウント後にコンテナ内の X11 の初期化が行われることによりクリアされてしまう。 このため、ひとまずコンテナ内の別の場所にマウントさせ、実際にコンテナ内で使う際に /tmp/.X11-unix/ にシンボリックリンクさせることにする。 ここでは X11 ソケットをコンテナ内の /mnt/x11/ 配下にマウントする。

host$ lxc config device add ubuntu2004 x11 disk source=/tmp/.X11-unix path=/mnt/x11

コンテナ内のシンボリックリンクについては後述

コンテナ内の ubuntu ユーザのログインスクリプトを変更

ログインスクリプトを一部変更することで GUI が使えるようにする。 一旦以下のように ubuntu ユーザでログインしてログインスクリプトを書き換える。

host$ lxc exec ubuntu2004 -- sudo --user=ubuntu --login bash

スクリプトの意図は:

• 同じコンテナを GUI を使わないで使用する場合には余計なことをしない
• ホスト側の X11 ソケットの番号は固定とは限らないため config に埋め込まずに shell 起動時に DISPLAY 環境変数で指定する
• dbus を使う GUI アプリも多いので dbus が扱えるようにしておく

~/.profile

...
if [ -r "$HOME/.profile-x11" ]; then
    . "$HOME/.profile-x11"
fi

次項の ~/.profile-x11 ファイルがあればそれを読み込むようにする

~/.profile-x11

[ -n "$DISPLAY" -a -z "$XDG_RUNTIME_DIR" ] || return

setup_x11 ()
{
    local xsock_dir x_id x
    xsock_dir=/mnt/x11
    [ -d $xsock_dir ] || return
    x_id=
    x=${DISPLAY#:}
    for f in ${xsock_dir}/X*; do
        if [ -O "$f" -a "${f##${xsock_dir}/X}" = "$x" ]; then
            x_id=$x
        fi
    done
    [ -n "$x_id" ] || return
    if [ ! -h /tmp/.X11-unix/X${x_id} ]; then
        ln -s ${xsock_dir}/X${x_id} /tmp/.X11-unix/
    fi

    export XDG_RUNTIME_DIR=/run/user/${UID}
    if [ ! -d ${XDG_RUNTIME_DIR} ]; then
        sudo mkdir -p ${XDG_RUNTIME_DIR}
        sudo chown ${UID}:$(id -g) ${XDG_RUNTIME_DIR}
        sudo chmod 700 ${XDG_RUNTIME_DIR}
    fi

    exec dbus-launch --exit-with-session bash
}

setup_x11
unset setup_x11

ちょっと複雑なため少し解説

• DISPLAY 環境変数が設定されていない場合や既にこの処理が済んでいる場合には何もせず抜ける
• /mnt/x11/ 配下にあるソケットの中から DISPLAY 環境変数の番号と一致するものを探してそれが ubuntu の UID と同じ場合に /tmp/.X11-unix/ 配下にシンボリックリンクする
• dbus 環境を設定してサブシェルを起動する
• 何らかのエラーでサブシェルを起動できなかった場合は setup_x11 関数定義自体を消して後始末をする

コンテナへのログイン

LXD コンテナに ubuntu ユーザでログインする

host$ lxc exec ubuntu2004 -- sh -c "DISPLAY=$DISPLAY exec sudo --user=ubuntu --login bash"

このシェルから X アプリを実行すればホスト上のデスクトップに表示されるはず

ubuntu@ubuntu2004$ xeyes &

参考

• LXDのコンテナからGPUを利用する
• LXDコンテナとホストの間でファイルを共有する方法
• LXD で作る仮想化 GUI 環境 - Ubuntu 22.04 LTS 版
• Bindmount for .X11-unix only works when done if container is running

Docker

Docker は LXD と違ってアプリケーションコンテナであり、基本的には単一のアプリを実行するための環境を作成する。 このため systemd や init のような初期化ルーチンが走るわけではないので LXD のようなすれ違い (X11 ソケットの初期化等) が起こらない点は楽になる。 しかしながら逆に systemd や init により自動的に起動される初期化ルーチンや daemon が無いため、必要なものは全て自前で整えなければいけない。

正直なところ GUI を動かすには LXD の方が確実だが LXD には面倒なところがあり あまり多くのバリエーションのコンテナを用意するのは難しい。 Docker でも GPU を扱うのは比較的容易であり、ある程度なら GUI も動かせるのでその方法を示す。

元々 AMD の ROCm を動かす環境を用意しその上で Upscayl のような GUI も動かせたら…という目論見で試行錯誤したもの ^[1] なので、その詳細は Git Hub の ROCm-docker の方を参照されたい。 ここではエッセンスのみ示す。 基本線は LXD で示したこととほぼ同じ。 ただし LXD は UID/GID のマッピングを行うのに対し Docker では ID マッピングせずにそのままコンテナに見せている点に注意。

【2024/07/01 追記】
このあたりのことがオフィシャルドキュメントの Running ROCm Docker containers にも書かれるようになった。 ただし X サーバへのアクセスについては触れられていないので以下の内容はまだ有意義。

Dockerfile

Docker コンテナイメージを build するための Dockerfile を用意する

FROM ubuntu:20.04
ARG UID
ARG RENDER_GID

RUN UID_ADD=; [ -z "$UID" ] || UID_ADD="-u $UID"; \
    if [ -z "$RENDER_GID" ]; then \
      useradd --create-home $UID_ADD -G sudo,video --shell /bin/bash docker-user; \
    else \
      groupadd -g $RENDER_GID render; \
      useradd --create-home $UID_ADD -G sudo,video,render --shell /bin/bash docker-user; \
    fi

RUN apt-get update \
  && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends apt-utils \
  && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
  x11-apps \
  dbus-x11
RUN apt-get clean \
  && rm -rf /var/lib/apt/lists/*

COPY start-dbus.sh /usr/local/bin
RUN chmod +x /usr/local/bin/start-dbus.sh

USER docker-user
WORKDIR /home/docker-user

CMD ["/bin/sh", "/usr/local/bin/start-dbus.sh" ]

• ホスト OS のユーザと同じ UID のユーザを作成する
• ホスト OS で /dev/dri/render* デバイスのグループが render である場合には同じ GID の render グループを作成し、前述で作成したユーザもそのグループに入れる
  オリジナルの ROCm-docker はコンテナの OS が Ubuntu 20.04 以降の場合に render グループを決め打ちの GID で設定しているが、実際にはホスト OS 側のデバイスのパーミッションがそのまま見えるためホスト側の GID を継承する必要がある
• コンテナイメージに含めるパッケージはご随意に…
• スタートアップスクリプトを /usr/local/bin 配下にコピーし、コンテナ起動時には前述で作成したユーザ権限でそのスクリプトを実行するようにする

スタートアップスクリプト

LXD のログインスクリプトと同じような処理をする。 LXD と違うのは /tmp/.X11-unix/ 配下の X11 ソケットは起動時には使える状態になっているため特別な対処が不要という点。

#!/bin/sh

UID=${UID:-$(id -u)}
GID=$(id -g)
export XDG_RUNTIME_DIR=/run/user/${UID}
[ -d ${XDG_RUNTIME_DIR} ] || sudo mkdir -p ${XDG_RUNTIME_DIR} \
    && sudo chown ${UID}:${GID} ${XDG_RUNTIME_DIR} \
    && sudo chmod 700 ${XDG_RUNTIME_DIR}
exec dbus-launch --exit-with-session bash -l

docker-compose.yml

docker コマンドに引数を指定して build / 実行することも可能だが docker-compose を使うことで面倒な引数を指定せずに定型処理ができる

version: '3'

services:
  xshell:
    image: ubuntu-20.04-xshell
    build:
      context: .
      dockerfile: Dockerfile
      args:
        UID: ${UID}
        RENDER_GID: ${RENDER_GID}
    environment:
      - DISPLAY
    cap_add:
      - SYS_ADMIN
    security_opt:
      - apparmor:unconfined
    devices:
      - /dev/kfd
      - /dev/dri
      - /dev/fuse
    tmpfs:
      - /tmp
    volumes:
      - /tmp/.X11-unix:/tmp/.X11-unix
      - ~:/home/docker-user/host-home

• 前述の Dockerfile を使って build する
• UID や RENDER_GID はホスト側の値を環境変数で渡す
• GUI / GPU を扱う場合に必要なセキュリティ関連の指定 (cap_add / security_opt) をする
• ホスト側の X11 や GPU へのアクセスに必要なデバイスやディレクトリをコンテナから見えるようにする

.env

build の際に引き渡す環境変数を以下のようにして .env ファイルに格納する

$ cat >.env <<EOF
UID=${UID:-$(id -u)}
RENDER_GID=$(getent group render | cut --delimiter ':' --fields 3)
EOF

build

$ docker-compose build xshell

実行

$ docker-compose run --rm xshell

このシェルから X アプリを実行すればホスト上のデスクトップに表示されるはず

docker-user@xxxxxxxxxxxx$ xeyes &

参考

• DockerでGUIを表示するときの仕組みについて
• Dockerコンテナ上でGUIアプリを表示する
• Docker privileged オプションについて
• (docker) XRDP + Ubuntu image with Japanese input
• The mount --bind command fail in Docker container on Ubuntu

[1]: 実際には Upscayl はある程度までは動くが完全には動いていない

なお、以下はホスト環境として Debian (bullseye) や Ubuntu (22.04 LTS) を想定している。
空き容量のあるストレージが /srv 配下にマウントされていることを想定しているが、自身の環境に合わせて別のディレクトリ (/home 配下等) に読み替えて欲しい。

VM イメージは通常 default ストレージプール (/var/lib/libvirt/images) に作成される。この格納先を変更する。

1. まずは全ての仮想マシンを停止

2. default ストレージプールを編集

$ sudo virsh pool-edit default
<pool type='dir'>
  <name>default</name>
  <uuid>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</uuid>
  <capacity unit='bytes'>nnnnnnnnnnn</capacity>
  <allocation unit='bytes'>mmmmmmmmmmm6</allocation>
  <available unit='bytes'>aaaaaaaaaaa</available>
  <source>
  </source>
  <target>
    <path>/srv/libvirt/images</path>
    <permissions>
      <mode>0711</mode>
      <owner>0</owner>
      <group>0</group>
    </permissions>
  </target>
</pool>

3. libvirted サービスを停止

$ sudo systemctl stop libvirtd.service

※ Warning が出るが気にしない

4. 移行先ディレクトリを作成

$ sudo mkdir -p /srv/libvirt/images

5. libvirted サービスを開始

$ sudo systemctl start libvirtd.service

6. 各 VM イメージファイルを移行先ディレクトリに移動

$ sudo mv /var/lib/libvirt/images/vm1.qcow2 /srv/libvirt/images

7. 各 VM ディスクイメージのパスを変更

$ sudo virsh edit vm1
...
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/srv/libvirt/images/vm1.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </disk>
...

$ sudo systemctl restart libvirtd.service

$ sudo mkdir -p /srv/docker

$ sudo cat >/etc/docker/daemon.json <<EOF
{
  "data-root": "/srv/docker"
}
EOF

$ sudo systemctl restart docker.service

$ sudo snap stop lxd

$ sudo systemctl stop snapd.service

$ sudo mkdir -p /srv/snap

$ sudo mv /var/snap/* /srv/snap

$ sudo vi /etc/fstab
...
/srv/snap       /var/snap   none        bind    0 0

$ sudo mount /var/snap

$ sudo systemctl stat snapd.service