Fun project: build LEDE using Bash on Ubuntu on Windows (WSL Windows Subsystem for Linux)

For Developers
1

Just for fun, I am trying to build LEDE using the Bash shell using the "built-in" windows services for Linux (WSL) in the latest Windows 10. For those who don't know what that is: Microsoft managed to run linux binaries directly on Windows, using an Ubuntu subsystem. See this page on how to install it: http://winaero.com/blog/how-to-enable-ubuntu-bash-in-windows-10/

In order to save me from creating a linux VM, I thought it was fun to try and build LEDE directly using this shell/subsystem. It looks remarkably like Ubuntu, and most things actually work, like apt-get to install all prerequisits for a LEDE build environment.

anton@windows10:/mnt/d/lede/source$ uname -a
Linux windows10 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
anton@windows10:/mnt/d/lede/source$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

Make menuconfig is a bit garbled, but it also works ok. Things start not to work when I actually want to "make"...

anton@windows10:/mnt/d/lede/source$ make -j1 V=s 2>&1 | tee build.log | grep -i error
anton@windows10:/mnt/d/lede/source$ cat build.log

make[1]: Entering directory '/mnt/d/lede/source'
make[2]: Entering directory '/mnt/d/lede/source'
+ mkdir -p /mnt/d/lede/source/staging_dir/target-mips_24kc_musl
+ cd /mnt/d/lede/source/staging_dir/target-mips_24kc_musl
+ mkdir -p bin lib include stamp
mkdir -p /mnt/d/lede/source/build_dir/target-mips_24kc_musl/stamp
touch /mnt/d/lede/source/staging_dir/target-mips_24kc_musl/.prepared
+ mkdir -p /mnt/d/lede/source/staging_dir/host
+ cd /mnt/d/lede/source/staging_dir/host
+ mkdir -p bin lib include stamp
mkdir -p /mnt/d/lede/source/build_dir/host/stamp /mnt/d/lede/source/staging_dir/host/include/sys
install -m0644 /mnt/d/lede/source/tools/include/*.h /mnt/d/lede/source/staging_dir/host/include/
install -m0644 /mnt/d/lede/source/tools/include/sys/*.h /mnt/d/lede/source/staging_dir/host/include/sys/
ln -sf lib /mnt/d/lede/source/staging_dir/host/lib64
touch /mnt/d/lede/source/staging_dir/host/.prepared
make[3]: Entering directory '/mnt/d/lede/source/tools/flock'
make[3]: Leaving directory '/mnt/d/lede/source/tools/flock'
make[3]: Entering directory '/mnt/d/lede/source/tools/sed'
make  -C /mnt/d/lede/source/build_dir/host/sed-4.4 SHELL="bash"
make[4]: Entering directory '/mnt/d/lede/source/build_dir/host/sed-4.4'
 cd . && bash /mnt/d/lede/source/build_dir/host/sed-4.4/build-aux/missing automake-1.99a --gnu Makefile
/mnt/d/lede/source/build_dir/host/sed-4.4/build-aux/missing: line 81: automake-1.99a: command not found
WARNING: 'automake-1.99a' is missing on your system.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'automake' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
Makefile:2167: recipe for target 'Makefile.in' failed
make[4]: *** [Makefile.in] Error 127
make[4]: Leaving directory '/mnt/d/lede/source/build_dir/host/sed-4.4'
Makefile:45: recipe for target '/mnt/d/lede/source/build_dir/host/sed-4.4/.built' failed
make[3]: *** [/mnt/d/lede/source/build_dir/host/sed-4.4/.built] Error 2
make[3]: Leaving directory '/mnt/d/lede/source/tools/sed'
tools/Makefile:148: recipe for target 'tools/sed/compile' failed
make[2]: *** [tools/sed/compile] Error 2
make[2]: Leaving directory '/mnt/d/lede/source'
tools/Makefile:146: recipe for target '/mnt/d/lede/source/staging_dir/target-mips_24kc_musl/stamp/.tools_compile_yynyyyyynyyyyynyynnyyyyyyyyyyyyyyyyyyyynyynynyyyynny' failed
make[1]: *** [/mnt/d/lede/source/staging_dir/target-mips_24kc_musl/stamp/.tools_compile_yynyyyyynyyyyynyynnyyyyyyyyyyyyyyyyyyyynyynynyyyynny] Error 2
make[1]: Leaving directory '/mnt/d/lede/source'
/mnt/d/lede/source/include/toplevel.mk:206: recipe for target 'world' failed
make: *** [world] Error 2

Automake is installed fine (same as on my actual Ubuntu VM). I tried to add "PKG_FIXUP:=autoreconf" to sed's Makefile, but no success either. Any other ideas how to get past this?

2

I have built LEDE in the Windows Linux subshell a year ago. I had no significant problems with that. So I expect that the current LEDE should be built ok.

But there are a few items you need to take care of. I am not sure if those could be behind your problems. In any case, link to my experience:
https://forum.openwrt.org/viewtopic.php?pid=336161#p336161

2 Likes
3

Hmm, looks like it was ownership... I created a new folder on my d-partition for LEDE, and I got this error. Even though I created that folder using my own account, the owner appeared as root:root. Now, using a folder in my homedir it works much better...

4

Yep, the subshell seems to handle mounted NTFS disks mostly as owned by root and permissions 777. The mounting does not allow quite similar ownership handling as native ext2/3/4 file systems, so some things related to file permissions in the build system will fail.

The solution is to use the new subshell rootfs that seems to be more native ext2-like. The drawback is that it is located in the Windows user profile in the main drive.

Quote from my old message that I linked above:

Native Windows NTFS disks are available in /mnt/c, /mnt/d etc. However, they have limitations for the allowed filenames: apparently ":" is a forbidden character, so cloning Openwrt sources to a native NTFS partition will fail due to e.g. wwan and usbmode packages that have files with : in the name. Similarly the file permissions defaults to chmod 777, which will not work for Openwrt buildroot.

The subsystem creates a new Linux rootfs in the Windows user's Appdata\local dir ( C:\Users<username>\AppData\Local\lxss ). There ":" is allowed for filenames as the filename handling seems to contain some conversion logic. Same goes also for file/dir permissions that work Linux-wise and allow other than 777.

In practice that means that the Openwrt buildroot needs to be created on the system drive into the user profile of the Windows user. That might be unwanted in some situations, e.g. depending on the backup strategies.

5

I sign up a account just want to say : Thanks for sharing.....

6

I re-tested using WSL windows Subsystem for Linux in Windows 10 x64 1809 to build the current Openwrt master.

Some observations:

  • Ubuntu 18.04 LTS can be installed from the app store and works ok.
  • I disabled the recent Intel microcode update by the older April version of mcupdate_GenuineIntel.dll (to leave myself vulnerable to Spectre2, but be faster...). See e.g. discussion at https://www.techpowerup.com/forums/threads/after-a-windows-10-update-today-overclocking-is-lost-wtf-microsoft-and-intel.247595/page-2#post-3904080
  • In addition to the normal prerequisites, also "sudo apt-get install unzip" is needed. Just like in 2016 as explained in https://forum.archive.openwrt.org/viewtopic.php?id=67204&p=1#p336161
  • I tried using another drive (as /mnt/v ) for the build, but got prerequisite warnings about non-case-sensitive drive, so I used the main emulated Linux rootfs in the end.
  • It is nowadays possible to move the Linux rootfs from C: to another drive with 3rd-party tools (although by default the emulated Linux filesystem still gets installed into user's local data directory in C: drive). I used LxRunOffline 3.3.0 to move the already installed Linux rootfs from C: to my V: drive (another SSD that is less full...), and everything seems to work ok. Link to the tool: https://github.com/DDoSolitary/LxRunOffline
  • I needed to exclude V:/wsl directory from virus scanning to keep performance reasonable. Otherwise my F-Secure virus scanner scanned each compiler process separately (or something like that) and performance was quite weak.

I did not observe any improvement in the compilation speed compared to Ubuntu in VirtualBox, so I do not yet see much benefits in using WSL directly. (But I did not try disabling WindowsDefender like some have suggested)

3 Likes