How to update Gitlab CE 11.8 to 12.4 — to renew Let’s Encrypt

It may sometimes happen that you have to make several updates to catch up the latest version and reconfigure some files to deal with it. It can take some time to find out the best way to deal with it, and you might encounter unexpected errors you need to spend extra time.
Why did I need to do this?
I received an email from “Let’s Encrypt Staging Expirary Bot”, and it gave me a quite lovely reminder. This email was to make sure that the certification was renewed and good to go. Cron can automate the process of renewal, and I guess that’s preferable to prevent from letting it expire, but I didn’t set it up. So, I logged in the server and ran the following command to renew it.
$ gitlab-ctl renew-le-certs
However, I received errors like;
letsencrypt_certificate[git.test] (letsencrypt::http_authorization line 3) had an error: Acme::Client::Error::Unauthorized: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: Acme::Client::Error::Unauthorized: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.The message above was a transient warning from Let’s Encrypt and required newer version (> 12.1) of Gitlab
Now the time to update Gitlab from 11.8 to 12.4.
Environment details
- Amazon Linux AMI, version 2018.03
- Gitlab Community Edition 11.8
- psql (10.9, server 9.6.11)
- chef_version=14.13.11
- ruby=ruby 2.6.3p62 (2019–04–16 revision 67580) [x86_64-linux]
- program_name=/opt/gitlab/embedded/bin/chef-client
- executable=/opt/gitlab/embedded/bin/chef-client
Update Gitlab to 11.11.5
Official page has detailed description of how to update Gitlab.
So first thing first. Making a backup file. It was saved at /var/opt/gitlab/backups as tar archive format.
$ sudo gitlab-rake gitlab:backup:create STRATEGY=copy
Then install latest version of Gitlab
$ sudo yum install -y gitlab-ce
At this point, the install failed, and it said;
gitlab preinstall: It seems you are upgrading from 11.x version series
gitlab preinstall: to 12.x series. It is recommended to upgrade
gitlab preinstall: to the last minor version in a major version series first before
gitlab preinstall: jumping to the next major version.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-recommendations
gitlab preinstall: and upgrade to 11.11 first.As the error said, the details of the upgrade recommendation were at the official documentation. It needed to update from 11.8 to 11.11 then 11.11 to 12.4 separately.
That being said, the first thing I needed to do was updating to 11.11. The command for the installation was not described in the official page, but there was a discussion about this.
Additionally, you can see which is the last release in the same major version from yum repository by the following command.
$ sudo yum list — showduplicates gitlab-ce | less
OK, so now I go ahead and install version 11.11.5.
$ sudo yum install gitlab-ce-11.11.5-ce.0.el6
I didn’t expect another error message at this point which was the same error I had in the previous step.
letsencrypt_certificate[git.test] (letsencrypt::http_authorization line 3) had an error: Acme::Client::Error::Unauthorized: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: Acme::Client::Error::Unauthorized: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for detailsDue to this error, the update failed and needed to be executed again.
So, opened up /etc/gitlab/gitlab.rb and commented out the following part to disable Let’s Encrypt renewal while updating gitlab;
#letsencrypt[‘enable’] = true
#letsencrypt[‘contact_emails’] = [‘info@[domain]’]
#letsencrypt[‘auto_renew_hour’] = “12”
#letsencrypt[‘auto_renew_minute’] = “30”
#letsencrypt[‘auto_renew_day_of_month’] = “*/26”Now you can install version 11.11 and see if the update was successful.
$ sudo yum install gitlab-ce-11.11.5-ce.0.el6
..._______ __ __ __
/ ____(_) /_/ / ____ _/ /_
/ / __/ / __/ / / __ `/ __ \
/ /_/ / / /_/ /___/ /_/ / /_/ /
\____/_/\__/_____/\__,_/_.___/
Upgrade complete! If your GitLab server is misbehaving try running
sudo gitlab-ctl restart
before anything else.
If you need to roll back to the previous version you can use the database
backup made during the upgrade (scroll up for the filename).
Verifying : gitlab-ce-11.11.5-ce.0.el6.x86_64 1/2
Verifying : gitlab-ce-11.8.0-ce.0.el6.x86_64 2/2
Updated:
gitlab-ce.x86_64 0:11.11.5-ce.0.el6
Complete!
can show you which version is currently running in the server.

It may take a while to see the page. If you get 502 Bad Gateway error too long, you may want to refer the community. In my case, I reconfigured the gitlab using the command below and hopefully received the page shown above.
$ sudo gitlab-ctl reconfigure
Update Gitlab to latest version
Next step was pretty much same as previous. Install the latest version of gitlab.
$ sudo yum install -y gitlab-ce
You need to be careful when you are running PostgreSQL 9.6.x to avoid an issue.
Danger: If you are using PostgreSQL 9.6.x and are updating to any version of GitLab 12.1 or newer, please disable the automatic upgrade temporarily. If you have any questions or concerns, please contact support. This is because we discovered an issue that affects the automatic upgrade of PostgreSQL from version 9.6.x to 10.x and can lead to an unsuccessful upgrade of a secondary server.
If it is the case for you, run
$ sudo touch /etc/gitlab/disable-postgresql-upgrade
to disable automatic upgrade of PostgreSQL, then you can upgrade to gitlab 12.1 or newer.
Once the upgrade was successful, uncomment the gitlab.rb file for Let’s Encrypt renewal which was done during the first step.
To reflect the edit, you need to run
$ sudo gitlab-ctl reconfigure
If your browser has “Whoops, GitLab is taking too much time to respond”, it is not surprising to see this. Again, it may take a while. So run the command above and come back later if the upgrade was successful.
