summaryrefslogtreecommitdiffstats
path: root/meta/classes/sanity.bbclass
diff options
context:
space:
mode:
authorAlejandro Hernandez Samaniego <alhe@linux.microsoft.com>2020-03-14 23:13:11 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2020-04-06 14:25:52 +0100
commit26da8460345d1e9e82cd0c25df307ed75518eda2 (patch)
treed6f2a97c784ddea4cbb0719cdd5e4a6a4b57ab7a /meta/classes/sanity.bbclass
parentc94ce416607e180fd7d6261726225e4ade9fdfb9 (diff)
downloadpoky-26da8460345d1e9e82cd0c25df307ed75518eda2.tar.gz
Windows: Enable Windows builds under WSLv2 and warn accordingly
Due to the architectural changes between Windows Subsystem for Linux v2, and WSL v1 it should now be possible to run bitbake on the several distros offered through the Microsoft Store. WSLv2 is available on Windows 10 build number > 18917 The current build number may be checked by opening a cmd prompt on Windows and running: C:\Users\myuser>ver Microsoft Windows [Version 10.0.19041.113] If a distro has already been installed via the Microsoft Store, then we can check which WSL version its using by opening a Windows Powershell (notice this is a powershell and not a cmd prompt): C:\WINDOWS\system32> wsl -l -v NAME STATE VERSION * Ubuntu Running 2 Debian Stopped 1 In this case it shows two distros installed, Ubuntu running WSLv2 and Debian running WSLv1 To change the version of WSL being used by a certain distro run: C:\WINDOWS\system32> wsl --set-version <Distro> 2 e.g C:\WINDOWS\system32> wsl --set-version Debian 2 For more information on installing WSLv2 please look at: https://docs.microsoft.com/en-us/windows/wsl/wsl2-install There are some caveats related to the way storage is handled by WSLv2 though, and at this point these have to be managed by the user manually, the storage space used by WSL is not reflected immediately and since bitbake heavily uses storage, after several builds this can prove to be a bit of an issue. WSLv2 uses a VHDX file for storage, this issue can be easily avoided by optimizing this file every now and then, this can be done via the following: 1.- Find the location of your VHDX file: - Get the distro app package directory. - Open Windows Powershell as Administrator and run: Get-AppxPackage -Name "*<DISTRO>*" | Select PackageFamilyName e.g.: PS C:\WINDOWS\system32> Get-AppxPackage -Name "*Ubuntu*" | Select PackageFamilyName PackageFamilyName ----------------- CanonicalGroupLimited.UbuntuonWindows_79abcdefgh Replace the PackageFamilyName (and your user) on the following path: C:\Users\<user>\AppData\Local\Packages\<PackageFamilyName>\LocalState\ e.g. ls C:\Users\<user>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ Mode LastWriteTime Length Name -a---- 3/14/2020 9:52 PM 57418973184 ext4.vhdx The VHDX file path is: C:\Users\<user>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx 2.- Optimize your VHDX file (Also on Powershell): - Make sure WSL is shutdown wsl --shutdown - Optimize it optimize-vhd -Path C:\Users\<user>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx -Mode full A progress bar should be shown while optimizing the VHDX file. As an example, after building core-image-sato, removing the TMPDIR did not reflect any changes on Windows Explorer for storage space being used, after optimizing the VHDX file, 14 extra GB were shown as free. So, as long as the the user optimizes its storage, the builds should run smoothly. This patch warns the user that is running bitbake under WSLv2, that they should optimize the VHDX file eventually to avoid storage issues. The same check previoulsy used for WSLv1 works for WSLv2, checking for the kernel version: WSLv1: Linux version 4.4.0-19041-Microsoft (Microsoft@Microsoft.com) WSLv2: Linux version 4.19.84-microsoft-standard (oe-user@oe-host) Builds have been tested under Ubuntu and Debian distros offered and installed through the Microsoft Store, and other distros should be able to run builds just as fine. Performance wise, using the same hardware, and same configuration a comparison between builds using native Linux vs WSLv2 for the following targets has been performed: - core-image-minimal - core-image-sato - core-image-sato-sdk - meta-toolchain No real evidence of any performance changes could be found, with WSLv2 builds running even faster in some cases. Running a recently built image can be done just as smoothly, if using "nographic" as argument for runqemu, or if its a graphical image, installing an X server and running runqemu runs just as fine. Happy bitbaking. (From OE-Core rev: c42cec0c1c57c4e67dc7cdb07c5e4aba14a847d3) Signed-off-by: Alejandro Hernandez Samaniego <alejandro@enedino.org> Signed-off-by: Alejandro Hernandez Samaniego <alhe@linux.microsoft.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/classes/sanity.bbclass')
-rw-r--r--meta/classes/sanity.bbclass12
1 files changed, 9 insertions, 3 deletions
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 9b97b462e4..9e87101738 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -511,14 +511,20 @@ def check_make_version(sanity_data):
511 return None 511 return None
512 512
513 513
514# Check if we're running on WSL (Windows Subsystem for Linux). Its known not to 514# Check if we're running on WSL (Windows Subsystem for Linux).
515# work but we should tell the user that upfront. 515# WSLv1 is known not to work but WSLv2 should work properly as
516# long as the VHDX file is optimized often, let the user know
517# upfront.
518# More information on installing WSLv2 at:
519# https://docs.microsoft.com/en-us/windows/wsl/wsl2-install
516def check_wsl(d): 520def check_wsl(d):
517 with open("/proc/version", "r") as f: 521 with open("/proc/version", "r") as f:
518 verdata = f.readlines() 522 verdata = f.readlines()
519 for l in verdata: 523 for l in verdata:
520 if "Microsoft" in l: 524 if "Microsoft" in l:
521 return "OpenEmbedded doesn't work under WSL at this time, sorry" 525 return "OpenEmbedded doesn't work under WSLv1, please upgrade to WSLv2 if you want to run builds on Windows"
526 elif "microsoft" in l:
527 bb.warn("You are running bitbake under WSLv2, this works properly but you should optimize your VHDX file eventually to avoid running out of storage space")
522 return None 528 return None
523 529
524# Require at least gcc version 5.0. 530# Require at least gcc version 5.0.