There is a topic I posted in a different thread and instead of hyjacking that thread, I have posted here in a new thread.
After updating my VirtualBox test system to the latest Dragonfish, updating 3 or 4 apps without issue, I updated my secondary system and ran into an issue updating one of the apps. I found that installed Apps may not behave entirely properly during the update process. This may have been a one off issue with this particular system, I may have not read or missed mention of the procedure to update apps after the latest Dragonfish update, or maybe it affects others, so this is why I’m creating this thread. to see if this may be a common issue or not.
Of my three apps (filebrowser, Rsyncd, Tailscale and no VM’s) installed on the secondary system, Tailscale would not update successfully at first. I did eventually get it to update so if someone has issues with an app not updating give the following a try.
What I found was the Selected App to upgrade (Tailscale) was missing some data needed to fully update.
I went to Tailscale >> Details >> Containers >> docker. io/ tailscale /tailscale: v1.66.3 which showed it wanted an update. The app itself in the details showed it was on the current updated version.
By selecting the “View Logs” icon I opened the Choose Pod popup. In the popup the “Containers*” dropdown while it is a required field was not populated and had nothing in the dropdown to select and so the update would fail. The existing installed app would deploy if manually started and again want an update.
This is what I did to get the Tailscale app to update. This is on my secondary system listed in my sig and I was logged in as Root user, but I think the Admin user would may work too.
- Clear browser cache (ctl-F5)
- Discover apps >> Manage Catalogs >> Refresh All
- Discover Apps >> Refresh Charts
- Discover Apps >> Manage installed apps
- Selected the App (Tailscale) to upgrade Details >> Update
- App updated but did not start so update is not complete.
- Manually started the app from the Installed Apps screen
Upgrade then proceeded to deploy and complete successfully changing to green “Running”
I don’t know if this just happens on some systems and not others or I failed to refresh the apps Charts and Apps after the Dragonfish update and before updating the apps.
Tonight I get home and I have an email alert for an app update from both Truenas systems I run…
The app was tailscale (the one found in the apps catalog) and I tried updating app. Both systems failed to update the app and the app had to be rolled back to the 1.66.3_1.0.39 version on both systems. The 1.66.3_1.0.39 is the version that had issues I mention in the above post.
I pulled the following from the GUI for the app.
New alerts:
An update is available for “tailscale” application.
tailscale 1.66.3_1.0.39
Version to be upgraded to:1.66.4_1.0.40
Name:tailscale 1.66.3_1.0.39
App Version: 1.66.3
Chart Version:1.0.39
Version to be upgraded to:1.66.4_1.0.40
Containers
docker .io/tailscale/tailscale:v1.66.3
Up to date
Related Kubernetes Events
2024-06-03 18:49:56 Back-off restarting failed container tailscale in pod tailscale-5576d7b7d7-v8hw8_ix-tailscale(e6b3ce43-dd60-4904-a166-29a18eeef9ae)
I looked at the debug file and pulled a couple lines out of the k3s_logs.txt file. It appears that a database table (dbstat) is missing and causing the update to fail. If it requires this table, then the update should include creating the table if it is missing from the database.
Jun 03 18:39:46 owen k3s[13148]: {“level”:“warn”,“ts”:“2024-06-03T18:39:46.512-0500”,“logger”:“etcd-client”,“caller”:“v3@v3.5.7-k3s1/retry_interceptor.go:62”,“msg”:“retrying of unary invoker failed”,“target”:“etcd-endpoints://0xc000851500/kine.sock”,“attempt”:0,“error”:“rpc error: code = Unknown desc = no such table: dbstat”}
Jun 03 18:39:43 owen k3s[13148]: E0603 18:39:43.456290 13148 pod_workers.go:965] “Error syncing pod, skipping” err=“failed to "StartContainer" for "tailscale" with CrashLoopBackOff: "back-off 2m40s restarting failed container=tailscale pod=tailscale-8d8ddff6-8qpkf_ix-tailscale(1ee70241-435e-4b97-953e-540cd8b40870)"” pod=“ix-tailscale/tailscale-8d8ddff6-8qpkf” podUID=1ee70241-435e-4b97-953e-540cd8b40870
Hi @PhilD13, it would help if we could look at the container logs for this issue. Can you use the “Report a bug” link above to submit a bug report? After you submit it a comment will be added with a link to securely upload a debug file from the system so we can investigate it.
Hi @DjP-iX I submitted a report - NAS-129405
I also submitted a report through the Truenas GUI before I saw the email from the forum post.
havent been able to get nextcloud fresh install to come up after a single reboot, ive had to attempt to rebuild it 5 times last week, im thinking ill roll back and try the version from before. since that one worked perfectly up until the latest updates
No, I have not tried any method that may corrupt the system as both systems are in production in the office. It’s my office, but still don’t want any issues.
I do have a Virtualbox with a Truenas VM for for testing and any major change or change that may break something goes through the VM first. I always wait a few days after an update comes out to see if there are major issues, then decide if I wish to upgrade/update or not. I then run any updates on the VM first. Run it a few days, wait until any apps I use want an update (usually some will on a new update) and see if there are any issues with the apps I use and if there is figure out why before I update the production servers. This time all went well on the VM including updating the apps I use. So I updated the secondary server, then the primary server the next day. Then apps (filemanager, rsyncd tailscale) on both production servers wanted updates. which I updated the secondary server. The only app that failed to update was Tailscale. I managed to get it after numerous tries to update. Then tried the same on the main server, where after numerous tries and trying things, it finally updated to .39. It appeared to be a container update issue according to the logs. A day or so later it was back to requesting an update on both systems supposedly to .40 version which totally fails and has to be rolled back to .39 release. It appears to be a database table issue this time.
Of course it is possible it is some permissions issue with the new admin levels and the admin and root users (yes I re-enabled root when I was on Cobia) not being applied correctly during the update from 24.04.0 to 24.04.1 to 24.04.1.1
New info from pod logs in the Application setup details GUI
2024-06-05 16:40:12.012807-05:00 Error: changing settings via ‘tailscale up’ requires mentioning all
2024-06-05 16:40:12.012935-05:00 non-default flags. To proceed, either re-run your command with --reset or
2024-06-05 16:40:12.012971-05:00 use the command below to explicitly mention the current value of
2024-06-05 16:40:12.013006-05:00 all non-default settings:
I don’t know what non default settings the log entries above are talking about. Except for the Tailscale key info and having checked host network, (which I unchecked) all the entries are default. A bit further down there is a log entry with a bunch of setup flag options along with the key and user of Tailscale.
I just updated the Virtualbox Truenas VM’s Tailscale app to the current version as it wanted an update and all went well. The basic settings are the same between all three machines and they are all on the same Truenas version.
hello, i cannot use tailscale, why would i add the advertised route, and it deploying for a whole day, how could i solve it?
I finally gave up trying to figure out what the issue actually was and created/installed a new instance of Tailscale. The new instance of the current version (current at time of reinstall: App Version: 1.66.4, Chart Version:1.0.41) installed on both machines and deployed properly. I deleted the old version that would not update.
