On Sat, 2022-10-08 at 11:13 -0400, Duncan Gibson wrote: > The problem wasn't mounting the system extension automatically. That > worked > just fine. It was that systemd would try to start the service before > the > system extension mounted, which would fail, for obvious reasons. This > weekend I think I'm going to try the BindReadOnlyPaths option and see > if I > can get that to work. Don't do that. system-wide extensions are not supposed to add units, and it will not work. Portable services are for distributors - for locally built extensions, you can simply use a normal service with ExtensionImages= that points to your extension, and it will be overlayed with the rootfs. > On Fri, Oct 7, 2022 at 3:35 PM David Anderson <dave@xxxxxxxxxxx> > wrote: > > > Yeah, so far we (tailscale) haven't found a good way to run on the > > Steam > > Deck at bootup, and also survive the A/B OS updates. Systemd system > > extensions _can_ be activated during bootup, if you place the > > extension in > > one of the well-known locations (/var/lib/extensions would be the > > one to > > use on Deck, as iirc it survives A/B upgrades), and the systemd- > > sysext > > service is enabled. > > > > I would check if systemd-sysext.service is enabled on the deck, and > > if > > not, file a request with Valve to enable that service in a future > > update. > > You should present it as enabling further customization of their > > platform. > > > > Another possible reason that sysexts aren't working for you, is > > that the > > Deck's /etc/os-release doesn't define a SYSEXT_LEVEL, and the > > VERSION_ID > > changes with every OS update. Because of this, the system extension > > will > > refuse to activate after every update (either SYSEXT_LEVEL or > > VERSION_ID > > must match exactly), until you rebuild a new image with the right > > OS > > metadata. Asking Valve to set SYSEXT_LEVEL to a stable value would > > make it > > even easier to provide Deck OS extensions reliably :) > > > > - Dave > > > > On Thu, Oct 6, 2022, at 12:08, Arian van Putten wrote: > > > > Afaik Portable services run in an isolated root and dont have > > access to > > the hosts rootfs. You'd have go include iptables and all its > > dependencies > > in the portable services directory. If you don't want to do that > > you'd have > > to use BindReadOnlyPaths= to give the service access to the > > required host > > paths or you'd have to use a system extension. > > > > That's probably why they advice running as a system extension. > > > > I think there are mechanisms for setting up system extensions on > > startup > > but I'm not familiar enough with the details. Maybe someone else in > > the > > list knows. > > > > > > > > > > On Thu, 6 Oct 2022, 20:21 Duncan Gibson, <legowerewolf@xxxxxxxxx> > > wrote: > > > > Hi, everyone. > > > > The high-level overview: I'm trying to install Tailscale as a > > portable > > service on my Steam Deck. > > > > Tailscale is a point-to-point VPN service, essentially a wrapper > > around > > Wireguard that helps with network setup and management. The Steam > > Deck is > > Valve's handheld PC running SteamOS 3, which is derived from Arch. > > It uses > > an A/B partition system for system files, meaning you can't install > > a > > service the normal way. > > > > There *is* a guide to do this, posted on their own blog, but it > > uses > > system extensions which aren't good for services that you want to > > run on > > startup. Indeed, following that guide puts me in a state where I > > have to > > manually start the daemon every time I reboot my Deck, even with > > the > > service enabled. > > > > Let's move on to how I've started to do this. > > > > Tailscale is available through most package managers, but they also > > publish static binaries with systemd unit files. > > > > This script grabs that binary, extracts it, and moves it into a > > portable > > service directory structure. > > > > # download and extract Tailscale > > tarball="$(curl -s 'https://pkgs.tailscale.com/stable/?mode=json' | > > jq -r > > .Tarballs.amd64)" > > version="$(echo ${tarball} | cut -d_ -f2)" > > tar_dir="$(echo ${tarball} | cut -d. -f1-3)" > > curl -s "https://pkgs.tailscale.com/stable/${tarball}"; -o > > tailscale.tgz > > tar xzf tailscale.tgz > > test -d $tar_dir > > > > # Set up our target directory structure > > mkdir -p > > tailscaled/{usr/{bin,sbin,lib/systemd/system},etc,proc,sys,dev,run, > > /var/tmp} > > > > # Copy tailscale-distributed files to the right place > > cp -rf $tar_dir/tailscaled tailscaled/usr/sbin/tailscaled > > cp -rf $tar_dir/systemd/tailscaled.service > > tailscaled/usr/lib/systemd/system/tailscaled.service > > > > # Write service os-release file > > source /etc/os-release > > cp -rf /etc/os-release tailscaled/etc/os-release > > > > Not automated yet is patching the provided unit file - you need to > > remove > > the EnvironmentFile line and "--port $PORT $FLAGS" options, and add > > [Exec] > > Environment="PATH=/usr/bin" > > > > Attach the portable service: sudo portablectl attach ./tailscaled > > --profile=trusted > > and try starting it: sudo systemctl start tailscaled > > > > It fails, leaving this in the logs: > > > > logtail started > > Program starting: v1.30.2-t24c524c78-gc399ae6fa, Go 1.19.1- > > tsb13188dd36: > > []string{"/usr/sbin/tailscaled", > > "--state=/var/lib/tailscale/tailscaled.state", > > "--socket=/run/tailscale/tailscaled.sock"} > > LogID: > > 0f59ed267a2b19cc28aac9ee7119914000ca478234af8d56893a025ae72cc647 > > logpolicy: using $STATE_DIRECTORY, "/var/lib/tailscale" > > wgengine.NewUserspaceEngine(tun "tailscale0") ... > > wgengine.NewUserspaceEngine(tun "tailscale0") error: creating > > router: > > could not get iptables version: fork/exec /usr/bin/iptables: no > > such file > > or directory flushing log. > > logger closing down > > createEngine: creating router: could not get iptables version: > > fork/exec > > /usr/bin/iptables: no such file or directory > > > > iptables is, in fact, at /usr/bin/iptables, so what am I missing? > > Before I > > added the Environment line, I was getting errors that iptables > > wasn't on > > the PATH, so I suspect that now tailscaled can *see* iptables, but > > systemd isn't letting tailscaled run it. > > > > Thanks for having a look at this. > > > > > > -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part
