🤖

WSL2上のUbuntuでYoctoを試してみる（QEMU使用）

2020/09/29に公開

Linux

WSL

Yocto

tech

概要

WSL2で実行しているUbuntu上で、QEMUを使用してYocotoを起動してみました。
WSL2でってところ以外はほぼYoctoクイックスタートを実行しているだけなので特に参考になる情報もないかもしれません。WSL2でもお試しできるよってことが伝わるだけも良いかと思い記事にしました。

なお、環境はMacBookのBootCampでデュアルブートにしているWindows10上のWSLで試しました。

WSLとは

Windows Subsystem for Linuxの略で、Windows 10上でLinuxを動作させるための仕組みです。
WSLにはバージョン1とバージョン2(WSL2)があり、WSL2ではHyper-Vを利用してLinuxカーネルの完全なエミュレーションが実現されています。Yoctoのビルドを実行するためにはWSL2が必要です。
本記事では導入方法などは省略しますが、以下ページやGoogle検索すれば簡単にできると思います。

Yoctoとは

公式ページのGoogle翻訳によると以下の通りです。

Yocto Projectは、製品のハードウェアアーキテクチャに関係なく、組み込み製品用に設計されたカスタムLinuxベースのシステムを開発者が作成するのに役立つオープンソースのコラボレーションプロジェクトです。Yocto Projectは、柔軟なツールセットと開発環境を提供し、世界中の組み込みデバイス開発者が、これらのカスタマイズされたLinuxイメージを作成するために使用される共有テクノロジー、ソフトウェアスタック、構成、およびベストプラクティスを通じてコラボレーションできるようにします。

Yoctoを使えば組み込み機器用にカスタマイズしたLinuxを構築できるイメージです。
実際にYoctoを使ってビルドしたカーネルを起動するには、ターゲットとなる組み込み機器が必要ですが（Raspberry Piなどでも可能）、QEMUという機器をエミュレーションするソフトウェアを使用すれば、実際の機器がなくてもカーネルの起動を試すことができます。

YoctoのビルドからQEMUでの実行まで

YoctoをビルドしてQEMUで実行するまでの流れを記載します。

必要なパッケージのインストール

$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \
build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
pylint3 xterm

pokyをクローン

$ git clone http://git.yoctoproject.org/git/poky
$ cd poky
$ git checkout tags/yocto-3.1.2 -b my-yocto-3.1.2

ブランチは最新のyocto-3.1.2にしました。

環境セットアップスクリプトの実行

$ source oe-init-build-env

ビルド実行

$ bitbake core-image-minimal

core-image-minimalは最小構成のイメージになります。他にもGUIありのイメージとして、core-image-satoなどもデフォルトで用意されています。

上記の通りビルドが実行されますが、初回実行時に以下WARNINGが表示されるかもしれません。（上の図は2回目の実行だったので表示されていない？と思われます）

WARNING: You are running bitbake under WSLv2, this works properly but you should optimize your VHDX file eventually to avoid running out of storage space

Google翻訳：
WSLv2でビットベイクを実行しています。これは正しく機能しますが、ストレージスペースが不足しないように、最終的にVHDXファイルを最適化する必要があります。

yocotoをビルドすると非常に大きい容量を使用しますが（30GB程度）、WSLで使用されるディスクサイズは自動で調整されるため、肥大化します。
WSL2は一度確保したディスクをホストに返さないらしいので、最適化を実行してあげる必要があります。この方法については後述します。

ビルドは私の環境だと3時間くらいかかりました。

QEMUでビルドしたイメージを実行

$ runqemu qemux86-64

上記を実行したところ、以下エラーになってしまいました。

runqemu - ERROR - Failed to run qemu: Could not initialize SDL(x11 not available) - exiting

検索して調べてみると、以下がヒットしました。

どうやらnographicをつければいけるとのことです。

$ runqemu qemux86-64 nographic

無事起動できました！
ログインはrootのパスなしで入れます。
また、QEMUを終了したいときは"shutdown -h now"などで終了すればOKです。

VHDXファイルを最適化してディスクを開放する

まず、WSL2のUbuntu上で以下ディレクトリを見てみるとものすごい巨大なサイズになっています。

$ du -sm poky/build
48899   poky/build

上記だと50GB程になっています。（私はGUI版のビルドも実行してみたのでちょっとサイズが大きめです）
buildディレクトリにはbitbake実行中にダウンロードしてきたファイルや、ビルドしたカーネルイメージが入っています。
なお、ビルドが終了したら自動でworkファイルを消す設定にしておくこともできます。

このbuildディレクトリごと削除します。

$ rm -rf build

ホストOS(Windows側)でVHDXファイルのサイズを確認してみます。
VHDXファイルは環境により違いはありますが、以下などに配置されています。

C:\Users\[ユーザ名]\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState

サイズは以下の通りでした。Ubuntu上でファイルを削除しても、ディスクサイズは開放されていません。

ディスク開放するため、VHDXファイルを最適化します。
まずwslをシャットダウンするため、PowerShellから以下を実行します。

> wsl --shutdown

続いて、PowerShellから以下コマンドを実行します。

> Optimize-VHD -Path .\ext4.vhdx -Mode full

もう一度サイズを確認してみるとサイズが小さくなっています。

なお、Optimize-VHDが実行できないようであれば先に以下を実行してOptimize-VHDを有効にしておく必要があります。

> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All