cerebrate
commented
3 years ago Added to the list for future releases. No ETR as yet.
Closed maxboone closed 2 years ago
cerebrate
commented
3 years ago Added to the list for future releases. No ETR as yet.
cerebrate
commented
2 years ago 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 /usr/bin/genie for the ungzipped attached file:
and reset its ownership to root:root and permissions to 6755, that should let genie work normally on an ARM64 system.
If this works, I'll set about adding ARM64 to the packages for 2.3.
maxboone
commented
2 years ago Will do, get back to you over the weekend :)
maxboone
commented
2 years ago 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 themultipathd symlinks and sudo e2label /dev/sdc cloudimg-rootfs
# genie -i
genie: WARNING: systemd default target is default.target; targets other than multi-user.target may not work
genie: WARNING: if you wish to use a different target, this warning can be disabled in the config file
genie: WARNING: if you experience problems, please change the target to multi-user.target
Waiting for systemd....!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
genie: systemd did not enter running state (initializing) after 240 seconds
genie: this may be due to a problem with your systemd configuration
genie: information on problematic units is available at https://github.com/arkane-systems/genie/wiki/Systemd-units-known-to-be-problematic-under-WSL
genie: a list of failed units follows:
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.Changing the target doesn't do much
root@TABLET-QSFVRLF5:~# genie -sv
genie: starting shell
genie: starting bottle
genie: generating new hostname
genie: external hostname is TABLET-QSFVRLF5
genie: setting new hostname to TABLET-QSFVRLF5-wsl
genie: updating hosts file
genie: unmounting binfmt_misc filesystem before proceeding
genie: AppArmor not available in kernel; attempting to continue without AppArmor namespace
genie: starting systemd with command line:
daemonize /usr/bin/unshare -fp --propagation shared --mount-proc -- systemd
Waiting for systemd....!!!!!!!!!!
genie: systemd did not enter running state (initializing) after 10 seconds
genie: this may be due to a problem with your systemd configuration
genie: information on problematic units is available at https://github.com/arkane-systems/genie/wiki/Systemd-units-known-to-be-problematic-under-WSL
genie: a list of failed units follows:
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.It never starts though, this is a few minutes later
root@TABLET-QSFVRLF5:~# ps wwaux | grep systemd | grep -v grep
root 51 0.0 0.0 6672 540 ? Ss 23:17 0:00 /usr/bin/unshare -fp --propagation shared --mount-proc -- systemd
root 52 0.1 0.1 25860 10728 ? Ss 23:17 0:00 systemd
root 104 0.0 0.1 34836 12888 ? S<s 23:17 0:00 /lib/systemd/systemd-journald
root 134 0.0 0.0 19096 4476 ? Ss 23:17 0:00 /lib/systemd/systemd-udevd
root@TABLET-QSFVRLF5:~# genie -s
genie: systemd is starting up, please wait....It does though, after a long time, but you can consider genie compatible IMO!
root@TABLET-QSFVRLF5:~# genie -s
genie: WARNING: systemd is in degraded state, issues may occur!Well this seems to be the culprit:
root@TABLET-QSFVRLF5-wsl:~# journalctl -u systemd-networkd-wait-online.service
...
Mar 16 23:22:11 TABLET-QSFVRLF5-wsl systemd[1]: Starting Wait for Network to be Configured...
Mar 16 23:24:11 TABLET-QSFVRLF5-wsl systemd-networkd-wait-online[280]: Event loop failed: Connection timed out
Mar 16 23:24:11 TABLET-QSFVRLF5-wsl systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Mar 16 23:24:11 TABLET-QSFVRLF5-wsl systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Mar 16 23:24:11 TABLET-QSFVRLF5-wsl systemd[1]: Failed to start Wait for Network to be Configured.After genie considers itself done and it does start the shell in degraded mode, the network configuration is vanished and the WSL2 machine doesn't have network configuration anymore. I'll just refrain from using networkd at the moment, and see if it works that way.
maxboone
commented
2 years ago So, a long time (9 to 10 minutes, don't have the exact mark) after starting the genie -s it has actually started systemd (with errors).
But the container has lost network connection, and systemd is in degraded state. I see that I forgot to remove a link for the systemd-networkd.socket so I'll try again after that, but - it feels like it's not actually hanging on that.
I could try fixing networkd's config but I don't feel like overwriting networking stuff that WSL sets dynamically.
maxboone
commented
2 years ago Timed the start-up time this time:
Starting genie:
root@TABLET-QSFVRLF5:~# date & genie -s
[1] 39
Thu Mar 17 00:03:30 CET 2022
Waiting for systemd....!!!!!!!!!!Tailing syslog, I see systemd is done at 00:10:35, entries start at 00:10:34:
Mar 17 00:10:35 TABLET-QSFVRLF5-wsl systemd[1]: Startup finished in 7min 3.995s.
Mar 17 00:10:35 TABLET-QSFVRLF5-wsl systemd[1]: dmesg.service: Succeeded.Which does show the correct start-up time, and seems right on the mark with genie - however, even though systemd has started as degraded, genie is not starting.
Anyways, disabling networkd is seemingly no bueno for systemd and it don't. I'll look into fixing networkd tomorrow
maxboone
commented
2 years ago Confirmed working!
What's taking so long is that (1) dhclient is started through cloud-init to get an IP for eth0 and thereafter (2) networkd tries the same thing.
After both attempts fail / timeout, systemd is started and works. This seems to be more of a Ubuntu-issue than a genie issue, even though it is nice to add it to the wiki. When I have a simple workaround I'll add it in there!
It seems that it's (limited to) the following:
It is almost undoable to stop dhclient from being used by cloud-init somehow, so just adjust the dhclient timeout in /etc/dhcp/dhclient.conf to 1 (other DHCP will be done using networkd or netplan anyways).
Add a file /etc/system/network/10-eth0.network with:
[Match]
Name=eth0[Link] Unmanaged=yes
[Network] DHCP=no
[DHCP] UseDNS=false
After that, `genie` starts within seconds on my Surface Pro X SQ2 and I have a full init system running in WSL2 ❤️ https://github.com/arkane-systems/genie/wiki/Systemd-units-known-to-be-problematic-under-WSL#systemd-networkdservice <- added above to the wiki 😄
cerebrate
commented
2 years ago Wow, that's a lot of research done while I was away --
Couldn't install the package through the repo (complained about a bunch of amd64 packages as dependencies)
Oops. My bad - that really should have occurred to me.
Changing the target doesn't do much
Yeah, that message is there as a warning because the default target on several WSL distros is set to graphical.target (as it is on the as-regular-Linux distros), which is pretty much guaranteed to fail under WSL/genie without a whole lot of extra manual hackery.
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 /etc/systemd/network/wired.network in the same way as yours.
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
cerebrate
commented
2 years ago (Also, apparently, cloud-init can be disabled with touch /etc/cloud/cloud-init.disabled .)
maxboone
commented
2 years ago 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!
cerebrate
commented
2 years ago As of 2.3, ARM64 now ships in .deb package form. Others are coming.
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