Yocto よもやま話 第 20 回 「Yocto 6.0 Wrynose リリース」

2026 年 10 月 05 日   Yocto Project よもやま話

2026年5月にYocto Projectとして4番目のLTSとなる 6.0 Wrynose のリリースがアナウンスされました。2030年まで4年間のサポートが提供されることになっています。

名前の由来はイギリスのウェールズ地方のカンブリアにある峠の名前です。「種馬の峠」という古ノルド語に由来しており、急勾配のため登るのが大変な峠であることを示す名称となっています。

前回のLTSは2024年4月にリリースされたYocto Project 5.0 Scarthgapなので、Wrynoseは2年ぶりのLTSとなります。この2年間で、大きな変化がありました。Wrynoseはその名の通り、踏破するには急峻な峠となりそうです。

目次

• ホストマシンの要件の変化について

1. Yocto 6.0で新規に追加・拡張された機能
   
2. 既存のプロジェクトを移行するにあたって
   
3. 今後のサポートに関して
   
4. 本リリース情報の参照元
   

ホストマシンの要件の変化について

5.0 Scarthgap から　6.0 Wrynoseに至るまで、多くの変更がありました。WrynoseのRelease note の冒頭にはセキュリティ対応などの機能追加が目玉としてうたわれています。それらの機能追加に伴って、ホストマシンの要件には大きな変更がありました。Yocto Project に取り組む皆様にとっては、Wrynoseという険しい峠の最初の登坂がこの要件変更への対応になるのではないかと思います。以下に要件変更の経緯を表にまとめました。Yocto Projectはホスト要件の変化についてLLVMの変化も理由に挙げているため、最右列にはLLVMのバージョンを示しています。

ディスク容量とRAMの要件が大きく変わっています。特にRAMは4倍増です。SSDもメモリも高騰している時節、要件変更は厳しく感じる方もおられるのではないでしょうか。

そこで今回は、メモリ要件を満たさないマシンで Wrynose を構築するとどうなるのかを試してみました。16GBytesRAM搭載マシンでcore-image-minimalとcore-image-satoを構築した経緯をレポートします。ディスク容量まで足りないと失敗原因が絞れなくなるため、あらかじめディスク容量は200GBytes以上空けてあります。

環境作成

git cloneでbitbake 環境を取得

ここでは、Wrynose 用の bitbake 環境を取得しています。以後の操作は、Yocto 6.0 ブランチを前提に進めます。

Yocto5.3WhinlatterでPokyリポジトリのマスターブランチが停止し、環境構築方法が大きく変わっています。今回はbitbake-setupツールを使ってセットアップしています。Pokyの変更についての詳細は、前回のブログを参照ください。

$git clone https://git.openembedded.org/bitbake -b yocto-6.0

bitbake-setupコマンドの実行

$bitbake-setup init

実行例では6.0を指定したり対話形式を避けるためにオプションを入れています。

init-build-envの実行

$source ./{pokyディレクトリ}/{buildディレクトリ}/init-build-env

core-image-minimalの環境設定と構築、実行

bitbake-config-build でパスワードなしを許可

bitbake core-image-minimalの実行

上記の手順で、Core-image-minimalは問題なく構築されました。

runqemu の実行

これにより立ち上がったqemuコンソールが以下になります。

core-image-minimal は、16GB RAM環境でも問題なく構築でき、QEMUでの起動まで確認できました。

core-image-satoの環境作成と構築、実行

さて、次はcore-image-satoです。Yoctoのドキュメントに書かれたホスト要件はcore-image-satoかcore-image-x86の構築時の条件ですので、メモリ16GBの環境では構築は厳しいことが予想されますが、まずはそのままbitbakeを実行します。

core-image-satoを構築する

以下、bitbake 実行時画面です。スレッドが複数走っているのが見て取れます。

結果から言いますと、この構築は失敗しました。bitbake実行画面にはうまくエラー要因が表示されなかったため、/var/log/syslogで得たのが以下の出力です。Systemd-oomd killed 233 Processes in this unit.とあり、メモリが不足したため落ちたことが分かります。

なお、構築時エラーが分かりやすく表示される場合もあります。以下はMACHINE=x86_64に設定してbitbakeを実行し、失敗したときのbitbake の出力画面です。do_compileタスク中にllvm_git.bbのレシピで失敗したことが示されています。

この MACHINE=x86_64時のエラーのdmesgの該当部分は以下でした。

リリースノートにはメモリ量での失敗はbitbake 実行画面には原因が出力されず、dmesgに出力される、との記載があります。実際には出力はケースバイケースのようで、取れたり取れなかったりしました。Bitbake実行画面、dmesg、syslog、いろいろ試してみてください。

ここからは、メモリ不足を解消する手段を試していきます。
以下のコマンドでSWAP領域を充てます。

$ sudo fallocate -l 64G /swapfile
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile

swapを割り当て、core-image-satoのBitbakeは成功しました。そこでqemu を実行します。

MACHINE名でエラーが出て止まってしまいました。core-image-minimalの時と、MACHINE=qemuarm64は変えていないのですが、イメージ名がminimalからsatoに変わったため、違うものとして認識されるようです。以下のコマンドで解消します。

$ bitbake-config-build disable-fragment machine/qemuarm64

再度qemuで起動します。

Qemuが立ち上がり、成功しました。しかし、MACHINE=qemuarm64のGUIの挙動は大変遅く、動作検証に使うにはかなり厳しい状況でした。

他方、別途構築したMACHINE=qemux86-64は同じ環境で軽快に動きました。構築条件やホスト環境にも依存すると考えられますが、本稿の環境ではqemux86_64のほうがはるかに快適でした。これについてはYocto Project Development Tasks Manualの40.8 QEMU Performanceにも記載があります。

Intelベースの32ビット（x86）ホストマシン上でエミュレータのqemux86イメージを使用した際はターゲットとホストのアーキテクチャが一致しているため、高速に動作します。一方、同じIntelベースのホストで「qemuarm」イメージを使用すると、処理速度が低下する可能性があります。

以上のように、SWAPの割り当てにより、16GBRAMの環境でもcore-image-satoが構築、qemuで起動できることが確認できました。この方法による回避は一時的な応急処置であり、恒久的な対策ではありませんが、メモリ価格が高騰している現状を乗り切るための有効な手段の一つと考えております。また、SWAP割り当てをしてもMACHINE=qemuarm64のQEMUは挙動が遅く動作検証には使い難い印象を受けました。実機がない状態でQEMUによる動作検証まで行うことを想定する場合は、ビルド完了を基準に環境を考えるのではなく、検証作業まで含めて十分な余裕を持った環境を検討する必要がありそうです。

YoctoProjectは要件が上がる要因の一つとしてLLVMの要求を挙げています。実際にLLVM関連のdo_compileタスクでメモリ不足が起きる現象もみられました。LLVMはYoctoProject外のプロジェクトですので、要件が上がれば影響を回避するのは難しいと考えられます。

Wrynoseのサポート期間は2030年までです。次期LTSは2028年にリリース予定です。ホストマシン環境整備は長い目で見ることをお勧めします。

ここまでホスト要件の変化と実際の構築結果を見てきました。ここからは、Wrynoseで追加・変更された主な機能についてRelease NoteとMigration Guideから機能追加などを列記していきます。

1.Yocto 6.0で新規に追加・拡張された機能

1.1 基本ソフト

kernel

カーネルは Linuxx-6.18（LTS）。

OLDEST_KERNEL は 5.15で、Scarthgapから変わっていません。

gcc2

gcc 15.2

glibc

glibc 2.43

LLVM

LLVM 22.1

Go

Go 1.26

Rust

Rust 1.94

その他

300 以上のレシピがアップグレードされた。

1.2 機能拡張

CVEチェックツールがsbom-cve-checkに統合

cve-check クラスが削除され、sbom-cve-check クラスに置き換えられました。

現在 cve-check クラスを使用しているユーザーに対して、sbom-cve-check への切り替えが推奨されています。

以下の設定を削除して

INHERIT += "cve-check"

以下に置き換えることで切り替えられます。

OE_FRAGMENTS += "core/yocto/sbom-cve-check"

これにより、sbom-cve-check クラスが推奨設定とともに有効になります。

2. SBOM生成ツールのサポートがSPDX 3のみに

create-spdx-2.2 クラスによる SPDX 2.2 ドキュメントの生成サポートが削除されました。

ユーザーに対して、create-spdx クラスが提供する SPDX 3.0 への切り替えが推奨されています。

3. 新しいbitbake-setupツールに対する改善

デフォルトでのビルド間sstate共有、ローカル変更を維持したままレイヤーをアップグレードする機能、より明確な用語および設定ファイル、VSCodeとのIDE統合の強化などが行われました。

4. initシステムがsystemdに変更

defaultsetup.conf ファイル内の INIT_MANAGER のデフォルト定義が、none から systemd に変更されました。
これによりsystemd がデフォルトの init システムとなりました。

Poky ディストリビューションのデフォルトの init マネージャーには影響しないため、Pokyを利用する場合は引き続き SysVinit が使用されます。

この変更の理由としては、Systemd UpstreamがSysV互換機能をメンテナンスしなくなったため、追従すると説明されています。

openssl 1.0、1.1のサポートが無効化応

openssl TLS 1.0 および 1.1 のサポートがデフォルトで無効化されています。

2. 既存のプロジェクトを移行するにあたって

2.1　変数の変更

OpenEmbedded ビルドシステムによるデフォルトの DISTRO_FEATURES および MACHINE_FEATURES の提供方法が変更されました。。

DISTRO_FEATURES_DEFAULT→DISTRO_FEATURES_DEFAULTS

DISTRO_FEATURES_DEFAULT（既存の変数）は非推奨になり、DISTRO_FEATURES_DEFAULTS（末尾のSが違います）に置き換えられました。

何もしなかった場合、DISTRO_FEATURES_DEFAULTSの値がDISTRO_FEATURESにそのまま入ります。

使用しない機能はDISTRO_FEATURES_OPTED_OUT に追加することで除外されます。

過去にDISTRO_FEATURES_BACKFILLで変更をしていた人は、DISTRO_FEATURES_OPTED_OUT変数に切り替えてください。

MACHINE_FEATURES_DEFAULT→MACHINE_FEATURES_DEFAULTS

MACHINE_FEATURES_DEFAULT（既存の変数）は非推奨になり、MACHINE_FEATURES_DEFAULTS（末尾のSが違います）に置き換えられました。

何もしなかった場合、MACHINE_FEATURES_DEFAULTSの値がMACHINE_FEATURESにそのまま入ります。

使用しない機能はMACHINE_FEATURES_OPTED_OUT に追加することで除外されます。

過去にMACHINE_FEATURES_BACKFILLで変更をしていた人は、MACHINE_FEATURES_OPTED_OUT変数に切り替えてください。

2.2　U-Boot の設定フローの変更

従来の設定方法は今のところ引き続きサポートされていますが、次回のリリースで廃止される予定です。

以下の方法への移行が推奨されています。

UBOOT_CONFIG ??= "foo bar"
UBOOT_CONFIG[foo] = "config"
UBOOT_CONFIG[bar] = "config2"

UBOOT_CONFIG_IMAGE_FSTYPES[bar] = "fstype"

UBOOT_CONFIG_BINARY[foo] = "binary"

UBOOT_CONFIG_MAKE_OPTS[foo] = "FOO=1"
UBOOT_CONFIG_MAKE_OPTS[bar] = "BAR=1"

UBOOT_CONFIG_FRAGMENTS[foo] = "foo.fragment"

3.今後のサポートに関して

LTSとして4年間、2030 年 4 月までサポートされる。

4. 本リリース情報の参照元

Migration notes for 6.0 (wrynose)