ubuntu-latest（Ubuntu 26.04）の /tmp で「disk quota exceeded」
ubuntu-latest は、2026年10月19日から11月19日にかけて Ubuntu 24.04 から 26.04 に移ります（ほかに変わること）。Ubuntu 自体が、いまは /tmp をメモリ上のファイルシステムである tmpfs にしています（Ubuntu 26.04 のリリースノート）。最初の 26.04 のランナーのイメージはこの既定のままだったので、/tmp に数 GB を書くジョブがそこで落ちました。/tmp がランナーのディスクにある 24.04 では、同じジョブが通っていました（runner-images #14777）。
どう見えるか
tmpfs の大きさはランナーのメモリの半分で約 7.8G（df では 7.9G）、ユーザーごとのクォータがあります。GitHub の測定では、runner ユーザーは約 6.3G でクォータに当たります。そのためエラーは「空きが無い」ではなくクォータのエラーで、まわりのディスクには十分な空きがあります：
compile: writing output: write $WORK/b4822/_pkg_.a: disk quota exceeded OSError: [Errno 122] Disk quota exceeded error: unable to write file projects/hipblaslt/library/src/... failed to write to /tmp/lez/target/debug/deps/...: Disk quota exceeded (os error 122)
順に、Go（ビルドのディレクトリと、lnd の場合は mktemp で作った GOCACHE）、大きな wheel を置く pip、一時ディレクトリへの git clone（ROCm）、/tmp の下での Rust のビルドです。pip は incomplete-download と出すこともあります。大きさと関係の無い症状もあります。/opt/hostedtoolcache から /tmp へのハードリンクはファイルシステムをまたぐので、EXDEV: cross-device link not permitted で失敗します。
どのイメージか
GitHub は10月20日にイメージを変え、24.04 と同じく /tmp をルートのディスクに置くようにしました（runner-images #14814。tmp.mount を止め、/tmp が tmpfs でないことを確かめるテストを足しています）。10月30日には、起動時に /tmp を前と同じく空にするようにしました（#15185）。読んだ報告では、落ちたジョブはイメージ 20261012.163.1 と 20261018.50.1 で動き、同じジョブが 20261025.179.1 では通っていました。新しいイメージがすべてのランナーに行き渡るには数日かかるので、移行の間は古いものに当たることもあります。
直し方：一時ファイルをランナーのディスクに置く
ジョブの最初のステップにします：
- run: echo "TMPDIR=$RUNNER_TEMP" >> "$GITHUB_ENV"
RUNNER_TEMP はどのランナーでも作業用のディスクにあり、ジョブごとに空になります。Python の tempfile（つまり pip と uv）・Go の os.TempDir・Rust の std::env::temp_dir・Node の os.tmpdir()・mktemp は、どれも TMPDIR に従います。Go のビルドのディレクトリは GOTMPDIR でも動かせます。/tmp/... と名前で書き込むスクリプトは、$TMPDIR か $RUNNER_TEMP を使うように直す必要があります。
直ったイメージでも、このステップは残す価値があります。費用はかからず、Ubuntu 26.04 のセルフホストランナーや開発者の機械では、同じ tmpfs が既定だからです。EXDEV には、リンクに失敗したらコピーするか、リンクを同じ一時ディレクトリの中で作ります。
見分け方
- 「Set up job」の Runner Image の欄に、イメージとその版が出ます。11月19日までは、再実行が 24.04 に当たって通ることがあるので、再実行が緑でも何も確かめたことになりません。
df -hT /tmpのステップを置くと、当てはまるイメージではtmpfsと約 7.9G、ほかではルートのファイルシステムが出ます。- ルートのディスクでの「No space left on device」は別の問題です。ランナーのディスクがいっぱいなので、使わないツールや Docker のイメージを消して空けるのが直し方です。
ほかの 26.04 の失敗
- Ubuntu 26.04 の libpcre3 と libpcre3-dev：Ubuntu 26.04 には PCRE1 が無いので、apt から
libpcre3-devが消え、24.04 向けのプログラムはlibpcre.so.3を読み込めません。ソフトウェアが対応していればlibpcre2-devを入れます。 - Ubuntu 26.04 の setup-beam の「not found in version list」：26.04 向けの Erlang/OTP のビルドの一覧は OTP 26.0 からなので、OTP 24 と 25 はセットアップで止まり、v1.24.1 より古い setup-beam はどの OTP でも落ちます。
- Ubuntu 26.04 の GCC 15 で通らなくなった C と C++ のビルド：既定の gcc が 13 から 15 に上がるので、C は C23 としてコンパイルされ、古い警告の6つがエラーになり、C++ のヘッダーは
<cstdint>を読み込んでくれなくなります。 - Ubuntu 26.04 の「cannot open shared object file」：libxml2 は
libxml2.so.16、ICU は 78 なので、24.04 で保存したキャッシュや 24.04 向けのバイナリがlibxml2.so.2やlibicudata.so.74を見つけられません。 - Ubuntu 26.04 の「client version ... is too old」：Docker 29 は API 1.40 より古いクライアントを断るので、古い Testcontainers は「Could not find a valid Docker environment」で落ちます。
- 「coreutils: unknown program」：基本のコマンドのほとんどが uutils です。
失敗したジョブを IntelliJ IDEA から見るなら
Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べ、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。
GitHub と GitHub Actions は GitHub, Inc. の商標、Ubuntu は Canonical Ltd. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・Canonical・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：「The ubuntu-latest label will migrate to Ubuntu 26」 · Ubuntu 26.04 の GCC 15 で通らなくなった C と C++ のビルド · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English