Builds for ARM64 #203
Assignees
Labels
Comments
|
Added to the list for future releases. No ETR as yet. |
|
I'm looking at implementing this for 2.3, now that the Python rewrite has made doing so substantially easier (in theory, all that should be necessary to do is cross-compile the setuid wrapper executable). As I don't have access to an ARM64 machine currently, would you be able to test this for me? After installing genie 2.2 in the normal way, if you swap out and reset its ownership to If this works, I'll set about adding ARM64 to the packages for 2.3. |
|
Will do, get back to you over the weekend :) |
|
Seems to work-ish. Couldn't install the package through the repo (complained about a bunch of amd64 packages as dependencies) or by downloading the release, but just unpacked it and placed the files in their respective folders. After removing the |
|
Changing the target doesn't do much It never starts though, this is a few minutes later It does though, after a long time, but you can consider |
|
Well this seems to be the culprit: After |
|
So, a long time (9 to 10 minutes, don't have the exact mark) after starting the SyslogBut the container has lost network connection, and systemd is in degraded state. I see that I forgot to remove a link for the I could try fixing |
|
Timed the start-up time this time: Starting Tailing Which does show the correct start-up time, and seems right on the mark with Anyways, disabling |
|
Confirmed working! What's taking so long is that (1) After both attempts fail / timeout, systemd is started and works. This seems to be more of a Ubuntu-issue than a It seems that it's (limited to) the following:
After that, |
|
Wow, that's a lot of research done while I was away --
Oops. My bad - that really should have occurred to me.
Yeah, that message is there as a warning because the default target on several WSL distros is set to I haven't seen the problem with cloud-init myself. (Debian doesn't ship with it, and apparently my Ubuntu test distro didn't either.) I'm honestly not even sure what cloud-init would do under WSL that's useful, seeing as a WSL distro isn't a cloud image; I suspect just removing the cloud-init package might actually be the easiest fix here, given that. systemd-networkd, that one I've seen (and thought I'd written up, but I guess not). This is a case where what you want to do depends a lot on your network configuration. For the default WSL setup, I just edited the configuration file covering the regular adapter, in my case Quite similarly to your file, which works fine for me. These days, though, I'm using the new bridged-networking-for-WSL experimental feature, which needs a somewhat more complex config, which I document here: https://randombytes.substack.com/p/bridged-networking-under-wsl |
|
(Also, apparently, cloud-init can be disabled with |
|
Nice! I think Ubuntu might've changed their default container image with cloud-init - or at least so for arm64, that's probably more thrown together / copied for WSL2 usage than the amd64 image. It effectively doesn't do much, so I'll disable it indeed, nice to know that workaround! |
|
As of 2.3, ARM64 now ships in .deb package form. Others are coming. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Currently it is only possible to run Genie on x86_64 platforms using the builds. It would be nice if builds for ARM64 / AARCH64 are also available, as there's a huge use-case for Windows on ARM users to use WSL2 with SystemD (considering there's no docker-desktop support).
Describe the solution you'd like
Packages built for AARCH64
Describe alternatives you've considered
Building yourself, possible but a real hassle
Additional context
The text was updated successfully, but these errors were encountered: