Tried that, back to 203/Exec error. It's like ExecStart wants me to specify a program to launch it, and bash clearly isn't it.
Yep, more specifically I tried sudo systemctl enable --now daemon.service
. Gives the same error, and maybe that's because it's some kind of binary.
sudo /bin/bash /path/to/daemon
throws the same error, but sudo /path/to/daemon
does not. However, if I drop , /bin/bash
from the service file, it throws a 203 error instead.
Private Internet Access
Foiled by autocorrect! There's no space in the original file, and I've edited my post to reflect that.
Thanks, I verified that it's in the correct place. Still throwing a 126 (see the modifications in the edit).
I added the relevant user and group, and it's still throwing a 126. I checked the daemon itself, and it looks like it's a pre-compiled binary. Manually running /bin/bash /path/to/daemon
gives the same error, but sudo /path/to/daemon
starts the daemon.
It's an autocorrect typo. It's actually WantedBy
in the file.
The service is in that folder, but it's not automatically assuming to run as root. Maybe it's an SELinux thing, since this is on Bazzite...?
Either way, I tried adding
[Service]
User=root
Group=root
ExecStart=...
And it's still throwing that 126. It's definitely executable, but maybe it's not a bash script, though I dunno what else you'd use to run it. To manually start it, you just type sudo /path/to/daemon
(no file extension).
Edit: definitely not a bash script. Kate can't read it. It looks like it's some kind of pre-compiled binary.
The latter. Autocorrect got that one.
Sorry I didn't get back sooner, but I made some progress.
What do you mean with "work in progress"?
Their words (second video, I think), and more in reference to how they are still working out how they haven't yet covered all of the use cases (like maybe my needs can't currently be met by rpm-ostree
or bootc
). rpm-ostree
has functional limitations, and bootc
is still being developed. Obviously, both are still useable and useful, and Universal Blue has been using them for quite a while. I may have been reading too much into it with the "depreciation" comment.
So, did you try the following methods when installing the
.run
file? If so, how did it go?
It can't work on its own. Running with sh
or making it executable runs the script, but it fails when it tries to write its icon and .desktop
entry to /usr
(it also doesn't take an --appimage-extract
argument). You can use sudo rpm-ostree usroverlay
to create a temporary FS overlay for /usr, but it's wiped on the next boot. Still, that allowed the installation to complete.
I discovered that it's installing all of the necessary components to /opt
, and they remain functional. I was able to manually run the daemon script required and get a WireGuard tunnel established in the client.
Now, I'm trying to get a .service
module to work so it can run automatically as root on a reboot with systemd
. So far, it's giving me a 126 exit code, so I still haven't figured out how to escalate its privileges automatically, but this is the most progress I've made to date.
The Microsoft support forums are pitifully hilarious, too.
"Hi, I need help with N. I've tried X, Y, and, Z."
"Hello, sorry to hear that you're having trouble with N. Have you tried X, Y, or Z?"
"Yes."
"I'm sorry to hear that it's still not working. Please refer to this thread, and feel free to contact Microsoft Support with any future questions. Have a nice day."
"But my problem still isn't solved. Hello?"
Omg, adding
/usr/bin/env
worked. Launched the daemon, and the client is able to launch and connect a WireGuard tunnel.systemctl show-environment
lists/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
on the PATH, so maybe that's why that worked...? (I'm going to have to go read up onenv
).Either way, I did a reboot to verify, and it's definitely running. Now I just need to tweak it a bit so it tries to reconnect if the network drops out, but holy shit, I appreciate the help.