VMWare Workstation 17.5, 17.6でTPMを使うと、Ubuntu 24.04 LTSの起動が遅くなる。
堀江誠一もともとはWindowsとLinuxをデュアル・ブートさせる実験過程で気づいた問題。
VMware Workstation ProでTPMを使うと、Linuxの起動に1分以上の遅延が入る。
検証した以下の構成で問題の再現を確認。
- VMWare Workstation
- 17.5.2
- 17.6.4
- Distro
- Ubuntu 24.04.2
- Kubuntu 25.04
- Kubuntu 24.10
堀江誠一起動が遅い
Kubuntuインストール後、Kubuntuの起動がやけに遅いことに気付いた。Kubuntuのスプラッシュスクリーンの表示まで1分半近くかかる。VMware Workstation上の別のVM(UEFI)では、10秒程度で表示される。
調べたところ、GRUBからKubuntuを起動した際、数十秒沈黙した後に以下のメッセージが表示されていた。
EFl stub: WARNING: Failed to measure data for event 1: 0x800000000000000b
EFI stub: Loaded initrd from Linux_EFI_INITRD_MEDIA_GUID device path
これれに関していくつもの質問がネット上にある。説明としては
「セキュア・ブートのキーが変更されたときにこのメッセージが出る」
と言うことだが、Secure bootをオフにしていてもこのエラーが出るという報告が多い。私の場合も同じ。
対症療法として
というものがある。
いずれもVMware Workstation 17.5では不可能だ。Linuxカーネルが修正されるまで待つしかない模様。不可解な話。
堀江誠一Kubuntuのブートが遅い問題にはTPMが関係している
Windowsとのデュアルブート
このVMからTPMを削除したところ、Kubuntuがするするとブートした。問題解決。ただし、Windows 11を使う以上、TPMを削除することはできない。
Kubuntuのシングルブート
以前から使っているKubuntuのシングルブートVMがある。問題なく快適に使っている。ブートの問題はない。
このVMにTPMを追加したところ、ブート時間が非常に長くなった。デュアルブートVMで起きた問題と同じ。
実機でのシングルブート
FMV Lifebook u939でKubuntu 25.04を使っている。ブートの問題はない。TPMはイネーブル状態。
まとめ
Kubuntu 25.04とVMware Workstation 17.5, 17.6のTPMの間には何かがある。それが何かはわからない。この何かがブートを大きく遅延させている。
堀江誠一EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
このメッセージを出力しているのは、drivers/firmware/efi/libstub/efi-stub-helper.cだ。なので、この関数が呼び出す関数群にデバッグ用のefi_info()を仕込めば、問題の範囲を狭めることができるかもしれない。
堀江誠一この問題はDebian 12.11では再現しない(Kernel 6.1.0-37-amd64)。
Kubuntu 24.04だと、現時点でカーネルは6.14.0-24であり、Debianよりずっと先に進んでいる。
堀江誠一Ubuntu 24.04のカーネルを6.15にアップデートしたが、やはりTPMを使うとブートに非常に長い時間かかる。
堀江誠一メモ
Kernel 6.9のビルド方法の解説。
ポイントとしては、
- 現在使っていないモジュールをビルド対象から外す。
- Secure BootのためのCertificateを使わない設定にする。
堀江誠一各ディストリビューションの挙動
| ディストリビューション | カーネル | 起動開始までの時間(*) |
|---|---|---|
| ubuntu-22.04.4-desktop-amd64.iso | 6.5.0 | 70 |
| ubuntu-24.04-desktop-amd64.iso | 6.8.0-31 | 70 |
- (*) dmesgに残るメッセージが表示されるまでの時間。単位は秒。
堀江誠一Kernel 6.8での実験
Ubuntu Server 24.04のカーネルを自分でビルドしたKernel 6.8-debugに差し替えた。
GRUBでUbuntuを選んでから30秒ほど沈黙した後、Loaded initrd from ... まで一気に表示される。そして10秒ほど経過した後、ここに表示されている最後の行までが一気に表示される。さらに10秒ほど経過すると、syslogに残るカーネル・メッセージが表示されはじめる。
不可解なことに、GRUBを使っているにもかかわらずEFI stubが動作している。
堀江誠一じゃあ、どうするの
さあ困った。
上のメッセージのefi_pe_entry()は、EFI Stubのエントリ・ポイントである。つまり、これよりも遡れない。症状的には、「efi_pe_entry()が呼び出されるまで30秒かかっている。つまりVMware WorkstationのEFIの実装が悪い」となりそうだ。
ところがどっこい、このシステムはGRUBから起動している。GRUBから起動しているのに、EFI Stubが動作している。なんで？
ここまで問題を深掘りしたが、自分の能力を超えていると思う。が、じゃぁどのコミュニティにポストすればいいのだろうか。
ブートローディングは複雑な仕組みだ。ここで言えば、EFIと、GRUBと、Linuxカーネルの動作を全部把握していないとこの問題は掘り下げられない。おそらくはGRUBの動作は問題には絡んでいなくて、Linuxカーネルの動作がトリッキーなんだと思う。
Ubuntuのコミュニティかなぁ。
堀江誠一以前の記憶（補足）
2021年ごろに、Ubuntuを全ディスク暗号化するKaiten-Yakiというツールを作ったことがある。
通常のUbuntu インストーラーはLinuxのルート・ボリュームしか暗号化しないのでカーネル・イメージは平文で保存している。しかしKaiten-Yakiはカーネル・イメージも暗号化する。残念ながらUbuntuがインストーラを変更したため、Kaiten-Yakiは最新のUbuntuでは使えない。
ともかく、そのときにBitLocker暗号化したWindowsとLUKS暗号化したUbuntuのデュアルブート実験をしている。
当時使っていた環境は、
- VMware Workstation 15.5
- Ubuntu 20.04
で、この時はTPMをイネーブルにしてもUbuntuの起動は遅くなかった（BitLockerを使うのでTPMは必須）。
堀江誠一TPMに関しては、各種問題があるとのこと。