# Upgrades via UI uitgeschakeld - en worden niet opnieuw ingeschakeld na SSH-upgrade
**URL:** https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016
**Category:** Self-hosting
**Created:** [26 januari 2022 om 00:58 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016 "2022-01-26T00:58:35Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [26 januari 2022 om 00:58 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/1 "2022-01-26T00:58:35Z")
I’ve got this message pop up when I try and upgrade via the UI:
After several git pulls and rebuilds I’m still getting the same message. Any tips?
I wonder if I need to do this:
> [@Manually update Discourse and Docker image to latest](https://meta.discourse.org/t/manually-update-discourse-and-docker-image-to-latest/23325/1):
>
> Due to the way docker packaging has changed you may also have to update your docker from lxc-docker or docker-engine packages. One way to do that is via the Docker script here (it will warn about an existing install but should upgrade ok):
>
> ```plaintext
> wget -qO- https://get.docker.com/ | sh
>
> ```
>
> This will now use the docker-ce main versions.
This is for an old, well established forum.
Cc @pacharanero
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [26 januari 2022 om 11:31 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/2 "2022-01-26T11:31:57Z")
> [@nathank](#):
>
> This is for an old, well established forum
Was this a [standard install](https://meta.discourse.org/t/142537?silent=true)? Could it be something like running the upgrade on the wrong server? Did the rebuild fail and you restarted the old container? I don’t have any better guesses.
You should keep your os to date as recommended in the topic you linked, but that’s unrelated to the problem you describe.
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [26 januari 2022 om 14:07 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/3 "2022-01-26T14:07:51Z")
It has puzzled me on occasion when the GUI update doesn’t seem to be reset and it directs us to SSH in, even when this has just literally been done.
It was a [standard install](https://meta.discourse.org/t/142537?silent=true), but the original install was way back in 2014, in the very early days when Discourse was not long out of public beta.
```plaintext
user@server:/var/discourse$ docker -v
Docker version 19.03.13, build 4484c46d9d
```
There is a more recent version of Docker, but it’s common for the version in Ubuntu to lag a little behind the latest.
OS is fully and regularly updated.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [26 januari 2022 om 14:12 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/4 "2022-01-26T14:12:07Z")
> [@pacharanero](#):
>
> It has puzzled me on occasion when the GUI update doesn’t seem to be reset and it directs us to SSH in, even when this has just literally been done.
Hmm. There is a lag after update before Discourse checks to see if the container has been rebuilt, though I have never known it to affect docker-manager.
You could try this:
```
docker exec app bash -c 'rails runner AdminDashboardGeneralData.refresh_stats
```
But it’s been long enough now, that I don’t think this is your problem. It can’t hurt, though.
I can’t remember the minimum version of docker supported, but I don’t think that’s the issue either, at least if you’re not on Ubuntu 16.04.
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [26 januari 2022 om 14:22 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/5 "2022-01-26T14:22:15Z")
Is there any way it could be about the branch we’re running?
In `containers/app.yml` we are explicitly selecting `tests-passed`
But of course that’s what’s running INSIDE the container. Would it matter what the default branch is outside the container?
```plaintext
user@server:/var/discourse# git status
On branch master
Your branch is up to date with 'origin/master'.
```
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [26 januari 2022 om 14:22 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/6 "2022-01-26T14:22:44Z")
Back in the day `master` was the default in GitHub. Now it’s `main`.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [26 januari 2022 om 14:44 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/7 "2022-01-26T14:44:11Z")
RIght. I guess you could try
```plaintext
cd /var/discourse
git checkout main
```
But I didn’t think you needed to do that explicitly.
What about
```plaintext
cd /var/discourse
./launcher enter app
cd /var/www/discourse
git status
```
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [26 januari 2022 om 14:55 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/8 "2022-01-26T14:55:54Z")
> [@pacharanero](#):
>
> ```plaintext
> user@server:/var/discourse# git status
> On branch master
> Your branch is up to date with 'origin/master'.
>
> ```
This relates to discourse\_docker, of course:
```bash
:/var/discourse# git remote -v
origin https://github.com/discourse/discourse_docker.git (fetch)
origin https://github.com/discourse/discourse_docker.git (push)
```
The branch was switched over in August 2021 and is 49 commits behind main at time of writing:
[GitHub - discourse/discourse\_docker at master · GitHub](https://github.com/discourse/discourse_docker/tree/master)
So you definitely want to switch to main branch?
However, I’ve agree with @pfaffman have never explicitly done that, so there must’ve been some script that did it. Perhaps it will occur with the next rebuild?
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [26 januari 2022 om 20:48 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/9 "2022-01-26T20:48:15Z")
> [@pfaffman](#):
>
> ```plaintext
> cd /var/discourse
> ./launcher enter app
> cd /var/www/discourse
> git status
>
> ```
returns
```plaintext
user@inside-container-app:/var/www/discourse# git status
Refresh index: 100% (30949/30949), done.
On branch tests-passed
Your branch is up to date with 'origin/tests-passed'.
```
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [26 januari 2022 om 20:50 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/10 "2022-01-26T20:50:00Z")
That looks like you’re up to date. And you’re still getting the Upgrades Disabled page?
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [26 januari 2022 om 21:11 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/11 "2022-01-26T21:11:22Z")
Yep. I had a look on another Discourse I run which dates back a bit, and is similarly on `master` and that also has the same Upgrades Disabled page.
That said, another Discourse I set up in mid-2022 is also on `master` and presents the update screen as normal!
If we can get any confirmation that changing the branch of `discourse_docker` to track `main` will fix it then I’m prepared to give it a go. Perhaps on a site that only I use.
> [@merefield](#):
>
> The branch was switched over in August 2021
That would roughly coincide with when I started to get weird behaviour on some Discourses around update time. (Because of this I ended up just updating them all via SSH every time, using Ansible).
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [26 januari 2022 om 21:31 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/12 "2022-01-26T21:31:00Z")
> [@pacharanero](#):
>
> (Because of this I ended up just updating them all via SSH every time, using Ansible).
That’s pretty much what I always do as well, though increasingly, I crank up the Ansible upgrade script with [https://www.pfaffmanager.com/](https://www.pfaffmanager.com/).
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [26 januari 2022 om 21:34 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/13 "2022-01-26T21:34:32Z")
Ok so I switched to track `main` on a Discourse that I only use as a personal notebook and journal etc.
Prior to the switch, I was tracking `master` and the Admin Upgrade page was indeed disabled.
At switching to track `main`, and rebuilding, I can confirm the Admin Upgrade UI is back to functioning normally.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [26 januari 2022 om 23:42 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/14 "2022-01-26T23:42:16Z")
Hmmm. I wonder if that means that all of those old installations need to change their branch. @Falco, maybe you want to see this.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [26 januari 2022 om 23:45 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/15 "2022-01-26T23:45:34Z")
Launcher changes the branch to main from master automatically. Sounds like something was blocking the automatic switch, like pending stash changes.
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [27 januari 2022 om 03:04 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/16 "2022-01-27T03:04:33Z")
> [@Falco](#):
>
> Sounds like something was blocking the automatic switch, like pending stash changes.
How likely is that on so many instances?
And what on earth are stash changes?
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [27 januari 2022 om 03:49 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/17 "2022-01-27T03:49:03Z")
> [@nathank](#):
>
> How likely is that on so many instances?
How many are we talking? There are thousands of Discourse out there, and I don’t see dozens of reports of this problem. At least not yet 😅
If someone has a server that is currently reproducing this bug and can keep it that way for another day, please reply here so we can investigate further.
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [27 januari 2022 om 13:01 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/18 "2022-01-27T13:01:20Z")
> [@Falco](#):
>
> pending stash changes.
Hmmmm. This _might_ be something to do with it on our instance @nathank
I have a couple of operational files (which are nothing to do with the Discourse codebase) in the same directory as the Discourse Git repo. If `./launcher` attempted to change branch Git **would** error, requiring me to stash these changes (or commit them).
Thanks @Falco I will do some further investigation. It may be that the only Discourse instances which would be affected are ones in which Git throws an error for whatever reason on attempting to change branch.
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [28 januari 2022 om 18:33 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/19 "2022-01-28T18:33:10Z")
Update: I think this issue with some untracked files \*may have been the problem.
I removed the files and made sure that the command `git checkout main` succeeded.
Then I ran `./launcher rebuild app` and it seems to have worked.
AFAICT, as per what @Falco states above, I don’t think it is _actually_ necessary to track `main` in the Discourse repo. When you run `./launcher rebuild app` the script itself will check out the correct branch.
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [30 januari 2022 om 19:12 UTC](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016/20 "2022-01-30T19:12:58Z")
I did have a few older Discourses which still showed the Upgrades Disabled page despite having ensured that
`git checkout main`
`git pull`
`git checkout master`
worked without errors.
And for these I simply left those instances tracking `main` and `./auncher rebuild app` and it was fine.
[Volgende pagina](https://meta.discourse.org/t/upgrades-via-ui-disabled-and-not-being-re-enabled-after-ssh-upgrade/216016.md?page=2)