Final update, hopefully. Here's a gist with a script, service unit, and readme. <https://gist.github.com/legowerewolf/1b1670457cfac9201ee9d67840952147>
On Sun, Oct 9, 2022 at 11:10 AM Duncan Gibson <legowerew...@gmail.com> wrote: > After doing some more looking, it seems like the /etc folder is overlaid > with /var/lib/overlays/etc/upper, meaning that changes to /etc/ get saved > in the overlay, which should survive updates. I've added the service > definition there and the binaries to my home directory (and updated the > service definition to point there), and it seems to just work. I might look > into putting the binaries in a system extension, and update the service > definition to require the extension be running, but it seems to work as-is. > Time to wait for the next system update and see if it breaks. > > On Sat, Oct 8, 2022 at 2:02 PM Luca Boccassi <bl...@debian.org> wrote: > >> On Sat, 8 Oct 2022 at 18:51, Duncan Gibson <legowerew...@gmail.com> >> wrote: >> > >> > Hm. Actually, no, I don't think it will. Services installed the normal >> way won't survive the A/B update system. >> >> I don't know what that is and how it works. >> >> > On Sat, Oct 8, 2022 at 12:23 PM Duncan Gibson <legowerew...@gmail.com> >> wrote: >> >> >> >> Oh, now that's a new way of doing it. I'll definitely give that a >> shot. That sounds like it has the best chance of working. >> >> >> >> On Sat, Oct 8, 2022 at 12:20 PM Luca Boccassi <bl...@debian.org> >> wrote: >> >>> >> >>> 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 <d...@natulte.net> >> >>> > 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, <legowerew...@gmail.com> >> >>> > > 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 >> >
