How to update to the latest Tailscale version?
-
@mightykong @CarlMRoss Looks like you might be experiencing https://github.com/tailscale/tailscale/issues/17793
I also have a 6100 + Tailscale 1.90.6 so I will test mine now.
update: I don't seem to be having this problem, which is odd because I'm usually that one guy in a thousand who has the strange bug that nobody else can reproduce.
Have you tried deleting the contents of
/usr/local/pkg/tailscale/state? -
@luckman212 I had a nice chat with Netgate Support Bot, https://www.netgate.com/support. I added some highlights below:
"Netgate Support Bot
This is a known issue reported by multiple users: enabling Tailscale with sysrc tailscaled_enable="YES" does not always auto-start Tailscale after a pfSense reboot. The current workaround is to run the following after each reboot manually:
service tailscaled stop && tailscale logout || true && service tailscaled start && tailscale up""Netgate Support Bot
Based on all available Netgate forum reports, there is no conclusive evidence that the failure to auto-start Tailscale after reboot when using sysrc tailscaled_enable="YES" is specifically due to Tailscale’s state being stored in a RAM disk. The root cause is still under investigation by the community. Most users confirm that a manual restart is required post-boot regardless of RAM disk settings."I will check the RAM Disk settings to learn more, but given others' lack of success, I will not experiment with it at this time. Here's what the Chatbot has to say:
"Netgate Support Bot
Yes, you can disable the RAM disk for /var to test if it helps persist Tailscale's state across reboots. Disabling the RAM disk for /var moves log files, RRD graph data, DHCP leases, and package data storage back to disk instead of volatile memory.
Impacts and considerations:
The firewall will write these files directly to disk, so settings and logs will persist through reboots and power losses.
Packages that write to /var, including Tailscale and packages like pfBlockerNG, Snort, or Squid, will have better persistence.
However, disk write activity will increase, especially for logging, RRD data, and DHCP leases.
Disabling the RAM disk reduces the risk of data loss after an improper shutdown, but you may lose some of the benefits (e.g., lower disk wear) intended for devices with fragile storage (e.g., low-cost flash or SD cards).
Some packages may behave differently on disk vs RAM disk and should be tested after reboot.
To disable the RAM disk: Go to System > Advanced > Miscellaneous > RAM Disk Settings in pfSense. Uncheck 'Use RAM Disks' for /var, then Save and Reboot.
If you use logging or packages that need persistent state (like VPNs, reporting, DHCP), disabling the RAM disk usually increases reliability but may wear storage more."""Netgate Support Bot
There is no direct evidence in available Netgate forum discussions that deleting the contents of /usr/local/pkg/tailscale/state resolves Tailscale's reboot persistence issue. Most reports focus on restarting the Tailscale service or re-running the 'tailscale up' command after reboot, rather than deleting state files. Deleting this directory could clear a corrupted state or force a fresh authentication. Still, it may also remove valid connections or authentication data, requiring you to re-authenticate Tailscale after reboot.This approach might temporarily resolve glitches caused by a stale state. It is still not an established solution for reboot persistence, and you should only try it with the expectation that re-authentication will likely be required afterward. Always back up any config or state you plan to remove, just in case."
-
I never reboot my appliance except for pfSense version upgrades or patches which require reboot. it's supposed to be a 24/7/365 always on device.
-
@elvisimprsntr Great in theory, not in practice. I'm the same, but there are unforseen events. Power outages, crashes, etc. And yes, I'm running a UPS.
-
@elvisimprsntr I agree and only reboot after upgrades and Patches that require it, or in a rare, desperate attempt to fix a persistent problem. As I see it, for now, Version 25.x requires a different workflow for Tailscale updates than CE versions; we have an update workflow that doesn't require a reboot unless it coincides with applying Patches, which I did a few days ago. And we also have a workflow for restarting Tailscale after a reboot that doesn't require creating a new Authentication Code, as I did a couple of times when it all started.
Thank you for keeping us up to date with Tailscale and all the good advice.
-
@luckman212, Thanks for your suggestion. I will check what I have in /usr/local/pkg/tailscale/state, and also the RAM disk settings others have brought up. I could learn more about where Tailscale and pfSense store system files. If I find anything worth sharing, I will let you know.
-
Updated CE 2.8.1 to 1.90.6_1.
pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.90.6_1.pkg -
Updated 25.07.1 to 1.90.6_1, copied and pasted from @elvisimprsntr's post:
pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.90.6_1.pkg
(Why it worked this time and not on previous updates:
Over the last couple of days, I ran into the "Shared object "libutil.so.10, not found..." error that triggered the version 25.07.1 update issues some of us have been having. After I fixed that error, I decided to go back to the usual update method, and it worked.) -
@CarlMRoss said in How to update to the latest Tailscale version?:
Updated 25.07.1 to 1.90.6_1, copied and pasted from @elvisimprsntr's post:
pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.90.6_1.pkg
(Why it worked this time and not on previous updates:
Over the last couple of days, I ran into the "Shared object "libutil.so.10, not found..." error that triggered the version 25.07.1 update issues some of us have been having. After I fixed that error, I decided to go back to the usual update method, and it worked.)How did you fix it?
-
@msurg
After the error message > ld-elf.so.1: Shared object "libutil.so 10" not found, required by "pkg" > The following were the commands that fixed it. (I left out a few commands that themselves had error messages):pkg-static clean -ay certctl rehash pkg-static -d update -f pfSense-upgrade -c env IGNORE_OSVERSION=yes pkg-static update -f env IGNORE_OSVERSION=yes pkg-static install -fy pkg pfSense-repo pfSense-upgrade
