Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Gentoo on windows subsystem for linux
View unanswered posts
View posts from last 24 hours

Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures
View previous topic :: View next topic  
Author Message

Joined: 27 Mar 2013
Posts: 5
Location: Tokyo, Japan

PostPosted: Fri Jun 03, 2016 6:47 am    Post subject: Gentoo on windows subsystem for linux Reply with quote

Gentoo on windows subsystem for linux

any idea?

looks like they already did for fedora
Back to top
View user's profile Send private message

Joined: 05 Aug 2006
Posts: 2151
Location: Berlin, Germany

PostPosted: Fri Jun 03, 2016 12:37 pm    Post subject: Reply with quote

I looked a bit into it. Deleting all the Ubuntu stuff and replacing it with a stage3 (akin to what Fedora did) is one possibility.

The Ubuntu on Windows development unfortunately was done in secret. And despite promises of technical details, not much has been released publicly yet.
Dustin Kirkland wrote:
So as part of the engineering work, I needed to wrap the stock Ubuntu root filesystem into a Windows application package (.appx) file for suitable upload to the Windows Store. That required me to use Microsoft Visual Studio to clone a sample application, edit a few dozen XML files, create a bunch of icon .png's of various sizes, and so on.
I searched, but I could not find any documentation which describes how to perform these steps.
Back to top
View user's profile Send private message

Joined: 12 Jul 2016
Posts: 1

PostPosted: Tue Jul 12, 2016 7:10 pm    Post subject: Reply with quote

I actually had a go at this.

You can do the swapping of the root's pretty much, install WSL, run 'bash', install its ubuntu base, unarchive the stage 3 into a directory (i called /s3) and basically swap the file systems over.

You have some problems because of what I presume is the way windows implements file locking... I think you can specify what command to 'start' as a parameter to 'the windows 'bash' executable', so something like "bash /s3/bin/busybox etc etc" might be useful

Essentially mv everything from / into /old, rm -rf sensibly whatever's left (ignore sys proc mnt dev), you'll need to use busybox probably to do this because of the static linking. rm -rf any 'safe' folders that remain (usr, bin, sbin etc), it might complain about purging some parts of /usr or /bin but persistence paid off (!)

Once done you can mv or cp the stage3 from /s3 into the root. You'll need to move "init" from the old install back into the root. (dont know what happens if you dont, actually).

Set your /etc/locale.gen and locale-gen ... resolver doesn't seem to matter thus far (or is auto configured, i didn't even look). ICMP doesn't work.

You might need to use "lxrun /setdefaultuser root" (or may just find this useful).

None of the above is particularly of note, it's a bit fudgy but i've actually done this on real linux machines recently (swapping remote operating systems), it's a little more fudgey for reasons of windows locking i guess but it works still.

I suggest you "su -" after you run bash, i dont think the default init thing properly sets up bits of the environment, i get locale errors sometimes etc etc.

The reason I'm making this post, aside from having the time while my machine does some building, was to share the next "hurdle" I came across and it's resolution.

The problem is emerging anything fails pretty early on (after the unpacking of the source) with some error about "ebuild-ipc daemon process not detected". At first I was worried there was some limitation in the filesystem implementation that was being tripped, but I manually compiled bash (as a test package) so it seemed like in theory trying to build stuff oughta be possible.

The problem comes down to a file called "". this is located on my system at /usr/lib64/portage/python3.5/ , though your lib directory may change, as may your python version directory (python 2.7 on my other machines mostly)...

In here you can find "def _daemon_is_alive(self)" which 'tries' to do something to do with locking, which fails miserably (i guess). If you delete this entire try/except/else and just replace it with "return True" (with the correct level of indentation, cant remember but python cares I believe), then ebuild commands run and complete.

I'm no gentoo expert, and worry a bit about the problem being to do with locking, since such things are sometimes used as guards, but if I look at this segment of code, not only is it only supposed to "check if something is running", which presumably it is since the builds succeed, and thus its just the check thats defective....
but also the whole check is centered around trying to FAIL to do something - it tries to get the lock, and if it fails, it assumes the daemon has the file open and says "all good here!". if the lock succeeds, it unlocks it again and says the daemon isn't running..... so i guess the locking code doesn't properly enforce something in microsoft's implementation here...

anyone know if this is likely to be an issue somewhere? I'm pretty sure bodging this check is fine, but are there any well known problems with locking not functioning properly and always returning the "OK" state? I know this is a bit of an old gripe for unix anyway as various NFS setups have 'struggled' with this and caused issues for things like MTAs (i think, its been a long time since i did nfs-root work, and i imagine the support/code has progressed in the decade gone by).

Mostly just sharing progress, I'm currently updating world, and i'll probably do an 'emerge -e @world' at some point for lulz, and to see what breaks.
Back to top
View user's profile Send private message

Joined: 01 Feb 2006
Posts: 178
Location: /world/Italy/Torino

PostPosted: Mon Nov 14, 2016 6:00 pm    Post subject: Reply with quote

The problem comes down to a file called "". this is located on my system at /usr/lib64/portage/python3.5/ , though your lib directory may change, as may your python version directory (python 2.7 on my other machines mostly)...

Thanks to floppym from gentoo irc channel, I found a way to sort this out in a "clean" way:

As described here
You can temporary replace _default_lock_fn = fcntl.lockf to _default_lock_fn = fcntl.flock in /usr/lib/python2.7/site-packages/portage/

Then, as this bug is solved in keyword-masked portage version 2.3.2, you can unmask it and go like a charm!

P.s: Instead of moving the whole rootfs from inside the bash environment, just replace the rootfs directory with the gentoo one in windows (cmd or explorer)
Back to top
View user's profile Send private message

Joined: 15 May 2013
Posts: 34
Location: versailles

PostPosted: Sat Nov 19, 2016 11:07 am    Post subject: Reply with quote


I actually doing some experiments with WSL and Gentoo.
The "_default_lock_fn = fcntl.lockf to fcntl.flock" trick have not solved the problem for me.
When using stage3 and basically follows install handbook this allows you to pass "emerge --config sys-libs/timezone-data" but the first "real" emerge fails with another IPC relative error ...
File "/usr/lib/portage/python2.7/", line 282, in <module>
  File "/usr/lib/portage/python2.7/", line 279, in ebuild_ipc_main
    return ebuild_ipc.communicate(args)
  File "/usr/lib/portage/python2.7/", line 136, in communicate
    lock_obj = portage.locks.lockfile(self.ipc_lock_file, unlinkfile=True)
  File "/usr/lib64/python2.7/site-packages/portage/", line 113, in lockfile
    raise PermissionDenied(func_call)
portage.exception.PermissionDenied: open('/var/tmp/portage/app-eselect/eselect-vi-1.1.7-r1/.ipc_lock'

I have totally turned off IPC by setting _enable_ipc_daemon to False in /usr/lib64/python2.7/site-packages/_emerge/ ( ) This have solved my problem but I don't understand all consequences. May be there is a more tricky, clean and efficient solution ?

When you first log with bash.exe in a new rootfs a init executable file is created and fired to start linux scripts. Some usefull directories (/dev and few others)are also created and populated. I suppose this tree and processes started by init are mainly Debian distributions compliant. Workarounds will certainly be necessaries to have a more operational and performant Gentoo system ported to WSL.

While installing I have found many others bugs relative to network stack, FS or MS kernel API, for which you can find, most of the time, a workaround or a little patch available somewhere, I have compiled some in french forum.
For the moment, the only real problem I found is with
timer_create: Function not implemented
not implemented in MS kernel API.
GHC and (if you install it in binary mode) all compilations based on Haskell seems impossibles but with Gentoo what is really impossible ?

PS : my install proc
- as root or sudo untar stage3 tarbal ( tar xvjpf stage3-*.tar.bz2 --xattrs ) in an ubuntu bash in a /root/gentoo directory
(seen from Windows root directory is outside rootfs but from ubuntu bash is /root)
- exit bash
- rename rootfs in rootfs_ubuntu in windows explorer (MS key+R => %localappdata%\lxss + enter)
- in cmd (admin mode)
cd %localappdata%\lxss
C:\Users\Toto\AppData\Local\lxss> move root\gentoo .\rootfs

then run
lxrun /setdefaultuser
to set a user for this new rootfs.
Use root as default user
and start bash.exe
ensure user and setuid bits are what and where they must be (by example /bin/su -rws--x--x root root ) ...
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum