Alpine Linux

[zippaaa]

Excuse me, did anyone install Alpine Linux?
Please write a solution if you know.
I'm interested to see it.
Installation from https://github.com/RoliSoft/WSL-Distribution-Switcher does not work. Bash cant't run.

[therealkenc]

Couldn't tell you about WSL-Distribution-Switcher, but Alpine proper seems okay as far as syscalls go (at least to a first order). From stock WSL Xenial (Legacy Edition™):

cd somewhere
sudo su
mkdir alpine-chroot
cd alpine-chroot
MIRROR="http://dl-cdn.alpinelinux.org/alpine/"
ROOT=$PWD/alpine-root
mkdir alpine-root
wget $MIRROR/latest-stable/main/x86_64/apk-tools-static-2.7.2-r0.apk
tar xvf apk-tools-static-2.7.2-r0.apk 
./sbin/apk.static -X $MIRROR/latest-stable/main -U --allow-untrusted --root $ROOT --initdb add alpine-base
cd alpine-root
mount -t proc proc ./proc
mount -t sysfs sysfs ./sys
mount -o bind /dev ./dev
cp /etc/resolv.conf etc/
echo "$MIRROR/edge/main" > ./etc/apk/repositories
echo "$MIRROR/edge/community" >> ./etc/apk/repositories
cd ..
chroot ./alpine-root /bin/sh -l

apk update
apk add alpine-sdk bash util-linux

I got a No space left on device on package isl but I think that might have been something spurious on my end. After apk install isl again it took.

Tried a few of the usual suspects with no immediately obvious faceplants. Nice to see musl up on WSL.

# bash --version
GNU bash, version 4.3.48(1)-release (x86_64-alpine-linux-musl)
[... blah blah]
# ldd --version
musl libc (x86_64)
Version 1.1.16
Dynamic Program Loader
Usage: ldd [options] [--] pathname
# gcc --version
gcc (Alpine 6.4.0) 6.4.0
[... blah blah]

[zippaaa]

Thanks for the answer. I'll definitely try. Now I'm afraid to break the working WSL.
Can I make a copy of the rootfs? If I mess things up, will it save me?

[ghost]

I can not answer your questions; I do remember the BashOnWindows team having said that side-by-side installations should work fine.

I have not known about https://github.com/RoliSoft/WSL-Distribution-Switcher yet. Being cautious myself, I'll gladly let others test out things, so I thumbs up to your effort Line117! Please keep others also notified, the more heroes first went through the path, the easier it may be for others to follow. :)

[zippaaa]

@therealkenc: Aah, understood. I thought this was a Linux replacement.
Yes, I launch Alpine, as in your solution. But I wanted it to be independent. :(

Chroot: One of the main uses for chrooting is to create a separate Linux system on top of a the current one for the purpose of testing or software compatibility. Chroot is often seen as a lightweight alternative to virtualization because it is able to run without the overhead of a hypervisor.

I will look for other solutions.

[benhillis]

If the Alpine folks are interested in having their distribution in the store they should reach out to @bitcrazed, we'd love to have another distro in the store.

[therealkenc]

Rather than the "reach out" system, it would be nice to see a blog post detailing the exercise involved.

Its Linux. Since the beginning, all you have needed to create a Linux distribution fork is a Desktop UX grudge and some bandwidth. And now you guys have volunteered the bandwidth part. Interesting times.

[zippaaa]

Posted by forum: https://forum.alpinelinux.org/forum/general-discussion/wsl-windows
I do not know if they will answer or not.

[zippaaa]

bash:

cd /home/<user>/
wget -O alpine.tar.xz https://github.com/gliderlabs/docker-alpine/blob/c6cb2bbffbc92d4c35cdaf584dd1c43a860104ea/versions/library-3.6/rootfs.tar.xz?raw=true
mkdir rootfs
tar -C rootfs -Jxf alpine.tar.xz (or in MC extract to rootfs)
exit (from bash)

cmd

cd %localappdata%\lxss\
rename rootfs rootfs.bak (your current linux here "rootfs.bak")
move .\home\<user>\rootfs .\
lxrun

Error: 0x80070002 :(

[benhillis]

@therealkenc - That's a good idea for a blog post, perhaps something @bitcrazed is already considering.

[therealkenc]

@therealkenc - That's a good idea for a blog post, perhaps something @bitcrazed is already considering.

I think we mostly just need one bit. What is the accepted mechanism for putting files with the WSL extended attributes into an NTFS directory from WinRT? WSL-Distribution-Switcher does it by hand, but you guys wouldn't expect the Ubuntu, SUSE, Redhat, people to code that up themselves in duplicate. So what is the tool, library, or source code that performs this task?

[therealkenc]

@benhillis - It looks like the problem with Alpine is that WSL init is dynamic linked against glibc. There is no guarantee that Linux user space depends on GNU; and, in the case of Alpine, it doesn't. [Neither, ironically, does Android.] We need a static linked init if you want to be distro agnostic.

Ubuntu/SUSE:

ken@WinDev1612Sys:~> ldd /init
        linux-vdso.so.1 (0x00007fffdc529000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f43e3420000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f43e3a00000)

Alpine in a chroot on WSL:

WinDev1612Sys:/# ldd /sbin/init
        /lib/ld-musl-x86_64.so.1 (0x7fc60ba00000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7fc60ba00000)

Goes without saying Alpine's init does different things than WSL's init, but the fundamental fail is WSL's init won't run in the first place. I believe this is the source of the Error: 0x80070002 flameout. I have a work-around in my head that doesn't involve inviting glibc to the party, but you know, effort.

[benhillis]

@therealkenc - statically linking the init binary is something we want to do, the only limitation is a legal / licensing one. We need approval from the owners of libraries that we statically link against, we're in the middle of that conversation.

[therealkenc]

@benhillis - Thanks. Yeah I almost edited my post to say that explicitly; in my head I took as given you can't use glibc. Maybe fire an email off to legal with the musl license to get it on your team's approved list. It is standard MIT. Musl is very static link friendly.

In the mean time an intermediate step that is doable without the "meetings" is to make WSL init POSIX clean. Doing this might even get us there without going static, but I haven't investigated enough to confirm that. This is effort (but not much effort) that will be necessary anyway. [edit *] You can probably just put () around the function names to avoid the offensive macro substitutions.

This is the full list of missing symbols.

__snprintf_chk: symbol not found
__read_chk: symbol not found
__dprintf_chk: symbol not found
__fprintf_chk: symbol not found
gnu_dev_makedev: symbol not found

[*] ...or some renaming, or something. You get my drift.

[therealkenc]

What is the accepted mechanism for putting files with the WSL extended attributes into an NTFS directory from WinRT?

Eight days of crickets on this pretty straightforward question. An even more basic question: how are you getting ubuntu.exe and opensuse-42.exe into the Store in the first place, since that isn't going to pass the UWP API checker.

[RoliSoft]

you guys wouldn't expect the Ubuntu, SUSE, Redhat, people to code that up themselves in duplicate. So what is the tool, library, or source code that performs this task?

@therealkenc Based on reverse engineering the ubuntu.exe and opensuse-42.exe binaries, vendors get a code sample which has a MyLinuxDistroLauncher class, inheriting from BaseLinuxDistroLauncher. The functions implemented there will just load wslapi.dll and call WslRegisterDistribution(const wchar_t *distributionName, const wchar_t *tarGzFilename). The target directory is not accepted as an argument, instead, the location of the calling exe (or app package) will be used to determine where to store the rootfs directory.

WslRegisterDistribution will create registry entries for that distribution and extract the specified .tar.gz. From there, you can just call wsl.exe {guid} ~ from wherever to launch that extracted rootfs.

So in the end, the setting of the extended attributes is abstracted away to whichever process WslRegisterDistribution will use for extraction. I'm guessing they reimplemented .tar.gz extraction, since when you request an installation, the .tar.gz file will be ungzipped to windows\temp and the .tar file is processed from there. tar xz would stream the extraction, without needing to extract the whole tar file first. Furthermore, another giveaway is that WslRegisterDistribution could not handle .tar files whose root directory is ., e.g. ./usr/bin/bash, which is how most Docker archives have it. I have to first recreate archives to be in the usr/bin/bash format, for the installation to succeed.

[therealkenc]

@RoliSoft - Much appreciated. It was pretty clear they were working off a source template but I didn't pick it apart; great work.

I started down the path of forking libarchive and transplanting in your ntfsea bits. Which is pretty straightforward because they've already isolated the cross-platform sensitive bits. But then I started looking at the UWP APIs at my disposal and realised the resulting code can never make it into the MS Store. LoadLibrary() is also verboten, as is diddling the registry. Which was the direct motivator for my follow up question above.

[benhillis]

Now that init is statically linked I've verified that alpine Linux works on WSL. Going to go ahead and close this out as a duplicate of #229.

[bitcrazed]

@therealkenc et. al.

Building a store-delivered distro for WSL isn't rocket science, but nor is it trivial. We now have a relatively well tested process having run through it several times with Canonical, SUSE and Fedora, and would like to expand the range of distro's available via the store in the coming months. This does require a relationship with our team, however, due to WSL store packages being Centennial and having a couple of small hoops that publishers need to jump through.

We're already talking with a couple of distro vendors, and hope to have news by years' end. Keep your eyes on our blog and my Twitter account :)

[marcthe12]

@bitcrazed Just incase, Could we get a specifications. Atleast enough to side load our distros. This could help for obscure distros.

[bitcrazed]

We will be publishing details of how to create distros, but ask for your patience while we work through the process with our current partners. This will help make sure that the process is solid and reliable, before broadening access.

[DDoSolitary]

It seems that both bash.exe and WslLauchInteractive depends on /bin/bash. Even if I pass /bin/ash as WslLauchInteractive's second argument, it returns silently if bash is not installed. This forces me to extract the .tar.gz file, chroot into it and run apk add bash before being able to install Alpine Linux.

PS. I'm on Win10 build 17093.

[DDoSolitary]

And the documentation of WslLaunchInteractive is confusing.

command [in, optional]
Command to execute. If no command is supplied, launches the default shell.

But bash is executed regardless of the default shell specified in /etc/passwd.

[therealkenc]

But bash is executed regardless of the default shell specified in /etc/passwd.

this and this

[DDoSolitary]

Thanks for the information. But commands executed via wsl.exe still relies on /bin/bash.

And may I ask if this feature of wsl.exe will be available to WslLaunch and WslLaunchInteractive?

[benhillis]

@DDoSolitary Good call, we should switch that API over to using /bin/sh.

[therealkenc]

we should switch that API over to using /bin/sh.

After the switch, the documentation for WslLaunch* should be updated to say it uses /bin/sh when the second argument is NULL. "Default shell" means something different.

[Worth observing as an aside, again, that /bin/sh doesn't exist on the most popular Linux distribution. It's /system/bin/sh.]

[Brian-Perkins]

The default shell issue should be addressed in the Skip-ahead 17627 build.

[ghost]

Thanks for respecting user freedom to chose their shell: dash (new ubuntus), csh (netbsd), ash (alpine) or the best sh (everywhere!). There is a new emerging option pwsh by the dint of https://github.com/powershell/powershell.

imo, Alpine Linux is worth adding in Windows Store as officially recognized distribution: https://docs.microsoft.com/en-us/windows/wsl/install-win10. .NET Core team has worked hard to support Alpine Linux end to end for the upcoming version of .NET Core dotnet/core#1076. PowerShell team is working on it as we speak to achieve zero-glibc'ism. WSL team can chime into the effort and make it visible in Windows Store so it is clicks away to become default Linux distro.

[zippaaa]

I did not even expect that my simple question will add to you so much work.
I just read the messages, because I do not understand anything about it.
Thank you very much for your work.
I'm using a licensing windows :)

[therealkenc]

PowerShell team is working on it as we speak to achieve zero-glibc'ism.

I like musl a lot. But heads up on #830 (message) since it came up recently.

On WSL with Alpine, strtod("4398046511105",0) will return 4398046511104, and you don't want that. The .NET Core and Powershell teams are going to be doing their work on the Real Thing™ so they won't see the ABI issue.

[ghost]

Thanks for the heads up. If i am to venture a guess, I'd say the guys who are fixing strtod et al. on Alpine and WSL side are not the same guys who look after the Windows Store packaging stuff. Both efforts can go along concurrently. :)

[zippaaa]

About Alpine.

• Run > cmd > wslconfig /l (Ubuntu 18.04)

• Download from https://github.com/yuk7/WSL-DistroLauncher (size 5M)

• Unzip to "C:\Alpine"

• Alpine.exe Run as administrator

• Run > cmd > wslconfig /l (Ubuntu 18.04; Alpine)

• Run Alpine.exe

• apk update

• apk upgrade

• apk add nano

• nano /etc/apk/repositories

http://dl-cdn.alpinelinux.org/alpine/v3.7/main
http://dl-cdn.alpinelinux.org/alpine/v3.7/community
@edge http://dl-cdn.alpinelinux.org/alpine/edge/main
@edgecommunity http://dl-cdn.alpinelinux.org/alpine/edge/community

• apk update
• nano /etc/network/interfaces

auto lo
iface lo inet loopback

nginx 1.14.0 / mariadb 10.2 / php 7.2

apk add openrc@edgecommunity --no-cache
apk add nginx@edge
apk add mariadb@edge mariadb-client@edge
apk add php7@edgecommunity php7-gd@edgecommunity php7-mysqli@edgecommunity php7-pdo@edgecommunity php7-xml@edgecommunity php7-json@edgecommunity php7-curl@edgecommunity php7-fpm@edgecommunity php7-openssl@edgecommunity php7-mysqlnd@edgecommunity

rc-update add mariadb default
rc-update add nginx default
rc-update add php-fpm7 default

chown mysql:mysql /var/lib/mysql 
rc-service mariadb start
rc-service nginx start
rc-service php-fpm7 start

top
service Nginx working.
service Mysql working.
seervice php-fpm7 :(
service php-fpm7 working

I can't solve two problems so far:

1. After the restart, the folder /run/openrc is lost and the services do not start. I made a copy of this folder, and every time I copy it into place.
   2. php-fpm7 can not start as service. And I do not know where the error is.

I know that this is not a Alpine forum. I just wrote to those who are interested.

[Biswa96]

That silmilar problem also occurs in NixOS. When I chrooted NixOS from Ubuntu it creates a folder /run/current-system. But when I install NixOS with wsl* function and run it, the folder does not automatically created. WSL may not support runtime data storage.

[therealkenc]

That silmilar problem also occurs in NixOS. When I chrooted NixOS from Ubuntu it creates a folder /run/current-system> folder /run/current-system

That's basically #39 (a rare two-digits), where the expected (and missing) filesystem skeleton was /var/run/screen. I don't have an Alpine chroot handy atm, but presumably there is a workaround somewhere here along the lines of systemd-tmpfiles (Alpine doesn't use systemd). This is a good illustration of why #2530 isn't well formed.

[zippaaa]

php-fpm service works. I made a error in the configuration file and did not see it.

I solved the problem with "/run/openrc":
/var/run.sh

ln -s /var/lib/openrc /run/openrc
service nginx start
service php-fpm7 start
service mariadb start

For the test:

Main UbuntuWSL
/etc/mysql/my.cnf
bind-address = 127.0.0.1

/etc/nginx/conf.d/site.conf

server {
    server_name site1.loc
    listen 127.0.0.1:80;

AlpineWSL
/etc/mysql/my.cnf
bind-address = 127.0.0.2

/etc/nginx/conf.d/site.conf

server {
    server_name site2.loc
    listen 127.0.0.2:80;

Windows hosts

127.0.0.1 site1.loc
127.0.0.2 site2.loc

Super :)

[gavenkoa]

At the moment there is built-in Alpine distro:

wsl --install Alpine

Also you can import OCI/Docker or LXC rootfs as WSL 1/2 distro:

wsl --import alpine-edge 'd:\srv\wsl\alpine-edge' alpine-edge-rootfs.tar.gz --version 2

[xwiz]

At the moment there is built-in Alpine distro:

wsl --install Alpine

Also you can import OCI/Docker or LXC rootfs as WSL 1/2 distro:

wsl --import alpine-edge 'd:\srv\wsl\alpine-edge' alpine-edge-rootfs.tar.gz --version 2

The first one didn't work, had to install from Store and there's a weird network issue where network calls don't work the first time.