After upgrading my laptop to 4.2, my existing sys-tailscale works, but I can not create another one. I just did a fresh install on a second computer, librem mini v2, to test if it was something that went wrong when I upgraded. I am also not able to get a tailscale login to persist across reboots on the mini when I follow the exact method I had for my sys-tailscale qube I have been using for over a year.
I also decided to create a standalone VM to see if that would work. This is where it gets kind of interesting. I have tailscale installed and working. I can ping my phones tailscale IP, and I can visit the tailscale IP for the standalone within its own browser, I spun up a nextcloud instance for testing that. On my phone, I can not get a connection to the standalpne VM. I tried connecting the VM to sys-net directly to see if it was the firewal, and the issue still persists.
Maybe there are some firewall rules.
Also the firewall was changed from iptables to nftables and you need to adapt the firewall rules accordingly.
More info here:
The thing that is tripping me up is my existing sys-tailscale still functions. I have the same bind-dirs and commands in rc.local in the new attempts, I even went as far as copying and pasting in case I was making a spelling or syntaxt error somewhere. But I did not look into the firewall script on my working qube, I will have to check that when I get off work tonight.
Anyone with a good knowledge of nftables able to help me understand what the change over may have caused to fail?
Maybe I will back up my working sys-tailscale and bring it over to the other computer with a fresh install of 4.2 to see if it still works there.
Did you use the same template for new sys-tailscale?
What if you clone the old sys-tailscale and name it sys-tailscale2? Will it work?
I guess you need to check all the files in /rw in sys-tailscale to see what additional files compared to newly created noo-working sys-tailscale are there.
I used both actuallt, on my laptop that I upgraded I still have Debian 11 and Fedora 38 as my templates. On that laptop I tried using the Debian 11 template. On the fresh install on my other computer I used the Debian 12 template.
Ill do some process of elimination on that tonight. I will attempt that clone you suggest, as well as backing it up and moving it to the other computer to see if it works there. I will also add the Debian 11 template to the fresh install to see if it will work with that.
Cloning my working sys-tailscale on my laptop works when I start the clone, it is automatically connected to my tailnet with no issues.
I checked my firewall script as you suggested and it is default with no changes:
user@sys-tailscale2:~$ cat /rw/config/qubes-firewall-user-script
#!/bin/sh
# This script is called at AppVM boot if this AppVM has the qubes-firewall
# service enabled. It is executed after the empty chains for the Qubes firewall
# are created, but before rules for attached qubes are processed and inserted.
#
# It is a good place for custom rules and actions that should occur when the
# firewall service is started.
#
# Executable scripts located in /rw/config/qubes-firewall.d are executed
# immediately before this qubes-firewall-user-script.
I also double checked my rc.local and it has only the two commands I anticipated there:
user@sys-tailscale2:~$ cat /rw/config/rc.local
#!/bin/sh
# This script will be executed at every VM startup, you can place your own
# custom commands here. This includes overriding some configuration in /etc,
# starting services etc.
# Example for overriding the whole CUPS configuration:
# rm -rf /etc/cups
# ln -s /rw/config/cups /etc/cups
# systemctl --no-block restart cups
systemctl start tailscaled
tailscale up
In my non-functional sys-tailscale on my second system, my firewall script is also at default with no entries. My commands in rc.local on the non-working sys-tailscale are identical to those on my working sys-tailscale on my laptop
This was different from my other system where it isn’t working, so I thought that was it, but when I updated it to have those binds as well and logged back in to tailscale, the login did not persist. So that did not fix it.
I am now backing up my working sys-tailscale and its template from my laptop and will move them over to my other system and see if it still works. I will update once I finish that
My sys-tailscale from my laptop works on my other system. I backed it up and its template and brought it over and restored it on the other machine. Made no changes, and it was logged into tailscale on boot.
I am going to try to create a new sys-tailscale off that template and see if that works. If that is the case then it is almost certainly something I did in that template that made it work that I did not do in the new one.
Well… I am out of ideas. I made a new sys-tailscale using the template that works for my working sys-tailscale. I did everything the same way as the working one, and triple checked it. And the login is not persisting across reboots. So crazy, I thought for sure it would work when I used the working template.
Check the content of the files configured in your working sys-tailscale bind-dirs. Specifically the /etc/default/tailscaled. Try to copy /etc/default/tailscaled from your old sys-tailscale to the new sys-tailscale. Maybe there is some non-default configuration in these files that is not in the newly created sys-tailscale.
Sorry about the delay, work was very busy the rest of the week.
I just checked the directories you mentioned and tried copying. I found that /var/lib/tailscale has a file and a directory that persist in my working sys-tailscale, but not in my non-working one. The directory is bound in both, and I copied the bind-dirs conf directly over. A file named derpmap.cached.json does not persist. And the directory /var/lib/tailscale/files does not persist, even though /var/lib/tailscale is bound. In the files directory it has my authentication it looks like. The only file is named for my username with the service I use to authenticate tailscale with. I added that directory to bind.dirs even though it is a sub directory of a /var/lib/tailscale that is already bound just to see if that would do it, but the file and directory are missing on reboot.
At this point I am about 99.99% certain that the issue is that /var/lib/tailscale is not persisting even though it is bound in /rw/config/qubes-bind-dirs.d/50_user.conf
Any idea why that might be or what I could do to remedy it?
No, I have it in my /rw/conf/qubes-bind-dirs.d/50_user.conf file. I did not realize that was an option to have it that way. To I just create that directory? Or copy the existing directory over to that path?
Well, evidently I knew I was supposed to do that at some point because it is under there in my working sys-tailscale. Or is that done by the conf file?
OK, I did that, and I rebooted, and it persisted. /rw/bind-dirs/tailscale is still there, and the sub directories within it are there, all of it is there as it should be. But tailscale login did not persist. Checking /var/lib/tailscale it is missing the derpmap file and the files directory