PR: Genie for Fedora33 distro. Is there some chance to get it?

[PavelSosin-320]

I have Fedora33 WSL distro installed on my machine with all genie dependencies, i.e
dotnet-sdk 5.0,
unshare from util-linux 2.36.1
daemonize, version 1.7.7.
systemctl --version
systemd 246 (v246.7-2.fc33)
Does any chance to have genie systemd installable using DNF as I have for Ubuntu Groovy using apt-get?
I see a merged pull requested that says that it already works for "remix" version.
It will be very helpful because Podman 3.0 is just released for Fedora33 but can't work without its group manager - systemd

[cerebrate]

I'd very much like to have a dnf/yum/rpm package available for Fedora, et al., but unfortunately for me the problem is time - I'm not familiar with that packaging method or its tools, and so far, I just don't have enough of it to learn all the tools and test against all the distros that people want. ☹️

I'm still hoping to find volunteer maintainers for all the non-apt package types out there!

I've attached an rpm package...

systemd-genie-1.32-2.x86_64.rpm.gz

...translated from the apt package using alien(1p) , which should work on Fedora in theory. If that doesn't work for you, manually copying the files from the .tar.gz package into place or using the build-it-yourself option are probably the easiest approaches for now.

Good luck!

[PavelSosin-320]

No problem! I have genie in Fedora.
1st of all - install dotNet 5.0 runtime in Fedora33
Using my Ubuntu distro I downloaded the Genie's deb file, extracted its content using dpkg-deb extract
and t

hen I copied the "essential" files to the Windows Program files, made them executable chmod+x and add my new "Genie Windows directory to the Windows PATH.
Then I created Desktop shortcut with wsl -d Fedora33 -u root genie -s. Now I can run Fedora 33 distro clicking on the "Fedora" icon.

[gbraad]

The install on F33 can be done as follows.

M<ake sure your system is up-to-date and has the needed packages

$ dnf update -y
$ dnf groupinstall -y "Basic Desktop"
$ dnf install -y systemd-container daemonize

To build genie you need:

$ sudo dnf install make dotnet-sdk-5.0 git-core
$ git clone https://github.com/arkane-systems/genie.git
$ cd genie/genie
$ make
$ sudo make install
$ sudo ln -s /usr/libexec/genie/genie /usr/sbin/genie

Ater this you can start

$ genie -i

Which will let you wait for 180 seconds before timing out:

Waiting for systemd....!!!!!!!!` 

After this do:

$ genie -s
$ sudo systemctl disable auditd
$ sudo systemctl mask systemd-modules-load

Will work on a package and a specific wsl.target for this.

ref gist

[gbraad]

@cerebrate Will create an RPM package for this. Will you re-open?

Want to see what can be done about the timeout, as at the moment it won't return. Have to modify:

$ sudo vi /etc/genie.ini

[genie]
systemd-timeout=5

---

$ sudo systemctl mask systemd-modules-load

did the trick to get rid of the degraded state (disabling didn't work).

[cerebrate]

@gbraad I'd certainly like to have an RPM package available, especially if it can generalize across popular RPM-based distros.

Before I action this - are you looking at creating a one-time RPM package for this, or effectively volunteering as tribute RPM maintainer? Or somewhere in between?

[gbraad]

A package, automated setup at fedora and hopefully can maintain it long-term (but there has been interest, so likely can find maintainers from the community too).

---

Update: I have set up a basic copr project: https://copr.fedorainfracloud.org/coprs/gbraad/genie/ and will first enable this for Fedora 33 (and 34). Might have a look at CentOS-based installs later

[PavelSosin-320]

@gbraad I installed genie "cross-distro" in the following way: I downloaded the genie apt package to the Ubuntu distro and unpacked it.
Then I copied the 'essential" genie files, i.e. genie executive and all scripts to the Windows' Program Files\genie and added them to the Widows' Path. Every distro inherits Windows's path and it makes genie available for every Linux distro. Microsoft itself distributes DotNet. It is not a dependency that resolved by apt or dnf. Hopefully, genie has no distro-specific dependencies than Systemd already installed with distro installation, DotNet, and kernel. The problem is that I need to repeat this procedure for every genie update using 2 distros. What I need is the zip or tar that can be extracted directly into Program Files \ genie.
In all cases, WSL distros share the same Microsoft's Kernel by default. Also, .wslconfig is shared by all distros unless a custom Kernel is used. It will be perfect to provide a .wslconfig [wsl] section that covers the most common scenario with few lines of documentation.

[gbraad]

Using alien or ar x is a bad practice as when a binary is dynamically linked this can cause issues. Luckily for .net they get statically compiled.

[gbraad]

Other dependencies are machinectl and daemonize. The former is not a regular installed package; it only comes with the nspawn package.

[cerebrate]

@gbraad Great stuff!

I don't think we need to reopen in this issue, but if you let me know the details when you're ready, and I'll add them to the installation README so people know where to go to get it. Or just send me a PR, either way.

[cerebrate]

@PavelSosin-320 Impressed as I am that you got genie to work that way, I confess to being a mite horrified at the thought of having to support it, and distro differences are definitely one reason.

(And while .NET is shipped by Microsoft, it's shipped as an apt package, so apt is certainly useful when it comes to managing that dependency, even if it doesn't resolve it without user intervention.)

[gbraad]

@cerebrate I created a .spec file to create an RPM package. The PR is here:

• Initial Fedora spec file #112

I published a test version of this RPM at:

• https://github.com/gbraad/fedora-wsl-genie/releases/tag/1.34

Still some minor changes that can be made, but works as-is.

[milesbuckton]

 [genie]
 systemd-timeout=5

@gbraad, thanks for the additional info. 😄 I had to set the timeout to a minimum of 90 seconds, otherwise genie-s failed.

[milesbuckton]

@gbraad, I now have a Gnome 3 WSL2 desktop on Fedora thanks to your superb instructions above! 🎉 See the Fedora screenshots on my comment: WhitewaterFoundry/Fedora-Remix-for-WSL#82 (comment)

[gbraad]

@milesbuckton

Please check with

$ genie -s
$ systemctl list-units --failed

what didn't work. Sometimes it is easy to solve, or otherwise I can mask them beforehand in an updated package

[gbraad]

I also compiled the RunInGenie app to allow easy WSL invocation from PowerShell. I put up a PR for a containerized build here: arkane-systems/RunInGenie#1

[milesbuckton]

systemctl list-units --failed

@gbraad, this is the error I get if I use a timeout of 30 seconds for example.

[gbraad]

Did you install the RPM ?
It seems you are perhaps missing the machinectl command. This is provided by systemd-container. Can you verify?

[milesbuckton]

@gbraad, yes - I did install the systemd-container rpm package. The strange thing is...if I close the WSL2 terminal after genie -s fails, then open it again it's fine?

[cerebrate]

@milesbuckton Can we get a ps aux after the failed startup? Let's see what's actually running in there.

[gbraad]

the no bus would indicate it tries to look for a dbus endpoint, which is not there...
has other things been changed on this WSL install before to make things work?

[milesbuckton]

@milesbuckton Can we get a ps aux after the failed startup? Let's see what's actually running in there.

@cerebrate, this is what I get before the fail and after it works:

[gbraad]

what is the target you are using... graphical? I do not run plymouth for instance... as this looks VERY bare (like nothing actually started).
the second image is when you start the second session and things worked?

[milesbuckton]

the no bus would indicate it tries to look for a dbus endpoint, which is not there...
has other things been changed on this WSL install before to make things work?

Not really. It only happens if the timeout is less than what is "comfortable" for my PC.

[milesbuckton]

what is the target you are using... graphical? I do not run plymouth for instance... as this looks VERY bare (like nothing actually started).
the second image is when you start the second session and things worked?

I don't know. Fedora Remix was installed via the Windows Store:

Yes, the second image is after I close the tab, and reopen another tab (session).

[gbraad]

for me it takes about ~2s on a cold start, but I am on an SSD and a well specced machine.
Though I would wonder, for starting you might need to wait a lot longer... or perhaps one of the units times out before starting the rest?

[gbraad]

in the second tab, what is the output of systemctl list-units --failed or it also fails there?

[milesbuckton]

for me it takes about ~2s on a cold start, but I am on an SSD and a well specced machine.
Though I would wonder, for starting you might need to wait a lot longer... or perhaps one of the units times out before starting the rest?

My laptop is an Intel i9 with 32GB of RAM, and an SSD: so it shouldn't be the laptop specs.
It could be the units, I'm not sure.

[milesbuckton]

in the second tab, what is the output of systemctl list-units --failed or it also fails there?

[cerebrate]

The second tab isn't a success either, FYI: look at the pid of systemd (69, not 1). You're still outside the bottle.

Also, yes, that looks like a very minimalist startup, with maybe... 3 services running? None of which is systemd-machined, which is why genie -s is failing.

[cerebrate]

You can manually get into the bottle with sudo nsenter -t 69 -m -p /bin/bash . (Use the systemd pid instead of 69 if it's changed.) That should give you more reliable access to systemctl and other systemd-requiring things. Once there, since you have systemd-container installed, you should be able to systemctl enable systemd-machined.

Having done that, then if you shutdown and restart WSL and genie, it should work properly. Hopefully.

[milesbuckton]

@cerebrate, this is what I got after I ran the commands.

[gbraad]

The second and last image look as expected:

Can you do:

$ sudo systemctl disable auditd
$ sudo journalctl -u dbus-daemon

Besides... what is the different between these images... just waiting? Sorry, just glanced and didn't notice the comment.

[gbraad]

BTW @milesbuckton what is the systemctl get-default ? Not sure why machined wasn't started on your machine

[milesbuckton]

[gbraad]

Do perform the command from within the bottle (genie -s)

$ sudo systemctl disable auditd

else it will fail with the error you see.

[milesbuckton]

Ok, that worked now for disabling the auditd service:

[gbraad]

For me it would show the same if I start it:

$ sudo systemctl start dbus-daemon
$ journalctl -u dbus-daemon
-- Logs begin at Sat 2021-02-13 23:07:36 CST, end at Fri 2021-02-19 15:56:52 CST. --
Feb 19 15:56:52 WinT14-wsl systemd[1]: Started D-Bus System Message Bus.
Feb 19 15:56:52 WinT14-wsl dbus-daemon[509]: Failed to start message bus: No socket received.
Feb 19 15:56:52 WinT14-wsl systemd[1]: dbus-daemon.service: Main process exited, code=exited, status=1/FAILURE
Feb 19 15:56:52 WinT14-wsl systemd[1]: dbus-daemon.service: Failed with result 'exit-code'.

might have a look at this as I am not sure why it would fail.

[milesbuckton]

Yes, I get the same:

Thanks for all your help guys. 👍

[gbraad]

BTW, the reason why auditd does not work

-- Reboot --
Feb 14 00:03:46 WinT14-wsl systemd[1]: Starting Security Auditing Service...
Feb 14 00:03:46 WinT14-wsl auditd[129]: Error - audit support not in kernel
Feb 14 00:03:46 WinT14-wsl auditd[129]: Cannot open netlink audit socket
Feb 14 00:03:46 WinT14-wsl auditd[129]: The audit daemon is exiting.
Feb 14 00:03:46 WinT14-wsl auditd[127]: Cannot daemonize (Success)
Feb 14 00:03:46 WinT14-wsl auditd[127]: The audit daemon is exiting.
Feb 14 00:03:46 WinT14-wsl systemd[1]: auditd.service: Control process exited, code=exited, status=1/FAILURE
Feb 14 00:03:46 WinT14-wsl systemd[1]: auditd.service: Failed with result 'exit-code'.
Feb 14 00:03:46 WinT14-wsl systemd[1]: Failed to start Security Auditing Service.
Feb 14 00:10:27 WinT14-wsl systemd[1]: Starting Security Auditing Service...
Feb 14 00:10:27 WinT14-wsl auditd[129]: Error - audit support not in kernel
Feb 14 00:10:27 WinT14-wsl auditd[129]: Cannot open netlink audit socket
Feb 14 00:10:27 WinT14-wsl auditd[129]: The audit daemon is exiting.
Feb 14 00:10:27 WinT14-wsl auditd[127]: Cannot daemonize (Success)
Feb 14 00:10:27 WinT14-wsl auditd[127]: The audit daemon is exiting.
Feb 14 00:10:27 WinT14-wsl systemd[1]: auditd.service: Control process exited, code=exited, status=1/FAILURE
Feb 14 00:10:27 WinT14-wsl systemd[1]: auditd.service: Failed with result 'exit-code'.
Feb 14 00:10:27 WinT14-wsl systemd[1]: Failed to start Security Auditing Service.

Which states:
Feb 14 00:10:27 WinT14-wsl auditd[129]: Error - audit support not in kernel
so this would never work with the current kernel.

[gbraad]

I am not an expert for this, but I believe dbus.socket should result in an fd that should be handed to the dbus-daemon.service; hence the Failed to start message bus: No socket received. No idea why this happens, as there is a /var/run/dbus/system_bus_socket active.

[gbraad]

I see:

$ systemctl status dbus
● dbus-broker.service - D-Bus System Message Bus
     Loaded: loaded (/usr/lib/systemd/system/dbus-broker.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2021-02-19 15:52:14 CST; 48min ago
TriggeredBy: ● dbus.socket
       Docs: man:dbus-broker-launch(1)
   Main PID: 147 (dbus-broker-lau)
      Tasks: 2 (limit: 30555)
     Memory: 4.0M
     CGroup: /system.slice/dbus-broker.service
             ├─147 /usr/bin/dbus-broker-launch --scope system --audit
             └─164 dbus-broker --log 4 --controller 9 --machine-id f60cfac8d6864901a41d26b835fedf19 --max-bytes 536870912 --max-fds 4096 --max-matches 131072 --audit

Feb 19 15:52:14 WinT14-wsl systemd[1]: Starting D-Bus System Message Bus...
Feb 19 15:52:14 WinT14-wsl systemd[1]: Started D-Bus System Message Bus.
Feb 19 15:52:14 WinT14-wsl dbus-broker-lau[147]: Ready

while:

$ systemctl status dbus-daemon
● dbus-daemon.service - D-Bus System Message Bus
     Loaded: loaded (/usr/lib/systemd/system/dbus-daemon.service; disabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Fri 2021-02-19 16:29:10 CST; 12min ago
       Docs: man:dbus-daemon(1)
    Process: 765 ExecStart=/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only (code=exited, status=1/FAILURE)
   Main PID: 765 (code=exited, status=1/FAILURE)

Feb 19 16:29:10 WinT14-wsl systemd[1]: Started D-Bus System Message Bus.
Feb 19 16:29:10 WinT14-wsl dbus-daemon[765]: Failed to start message bus: No socket received.
Feb 19 16:29:10 WinT14-wsl systemd[1]: dbus-daemon.service: Main process exited, code=exited, status=1/FAILURE
Feb 19 16:29:10 WinT14-wsl systemd[1]: dbus-daemon.service: Failed with result 'exit-code'.
$                                                                                     

Anyone any ideas around this?

[cerebrate]

It's getting a bit beyond my knowledge, I'm afraid, but what does systemctl status dbus.socket - i.e., for the socket rather than the service it triggers - look like? Mine shows:

● dbus.socket - D-Bus System Message Bus Socket
     Loaded: loaded (/lib/systemd/system/dbus.socket; static)
     Active: active (running) since Fri 2021-02-19 11:39:54 CST; 12min ago
   Triggers: ● dbus.service
     Listen: /run/dbus/system_bus_socket (Stream)
     CGroup: /system.slice/dbus.socket

Feb 19 11:39:54 athena-wsl systemd[1]: Listening on D-Bus System Message Bus Socket.

but hopefully any problems systemd is having with the socket itself should show up there.

[tjehlar]

It's getting a bit beyond my knowledge, I'm afraid, but what does systemctl status dbus.socket - i.e., for the socket rather than the service it triggers - look like? Mine shows:

● dbus.socket - D-Bus System Message Bus Socket
     Loaded: loaded (/lib/systemd/system/dbus.socket; static)
     Active: active (running) since Fri 2021-02-19 11:39:54 CST; 12min ago
   Triggers: ● dbus.service
     Listen: /run/dbus/system_bus_socket (Stream)
     CGroup: /system.slice/dbus.socket

Feb 19 11:39:54 athena-wsl systemd[1]: Listening on D-Bus System Message Bus Socket.

but hopefully any problems systemd is having with the socket itself should show up there.

I am having the same issue as the other user, and unfortunately that would not seem to be providing useful information:
`
● dbus.socket - D-Bus System Message Bus Socket
Loaded: loaded (/usr/lib/systemd/system/dbus.socket; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-02-26 23:26:27 PST; 5min ago
Triggers: ● dbus-broker.service
Listen: /run/dbus/system_bus_socket (Stream)
CGroup: /system.slice/dbus.socket

Feb 26 23:26:27 TRISTAN-MACBOOKPRO-wsl-wsl systemd[1]: Listening on D-Bus System Message Bus Socket.
`

[PavelSosin-320]

@tjehlar I currently use Fedora34 distro installed following Fedora magazine recommendations with genie 1.35.Everything looks OK except degraded status due to systemd-oomd.service startup failure. But the last looks as known Fedora34 issue. Fedora bug 1926373.. Podman 3.0 still has some problem in the rootless mode.

[gbraad]

@tjehlar what is the usecase that the dbus-service unit is started?
I noticed that a generic headless setup has no issues, hence the 'report' that it works for F34.