GitlapEE not more possible to Update after enable ESM

I have enabled UA Infra: Extended Security Maintenance (ESM). Now after enter apt-get update, gitlab will not more update.

In my administration account i can see update are available.

Auswahl_001

Hi @Joulindo
please specify whats the Ubuntu version.

Ubuntu 16.04.7 LTS (GNU/Linux 4.4.0-213-generic x86_64)

Latest version of GitLab Omnibus package for Ubuntu 16 (Xenial) is 13.12.9 released 10 hours ago. At the time of your post the latest version of GitLab Omnibus package for Ubuntu Xenial was 13.12.8.

Ubuntu Xenial is not supported anymore for GitLab 14.x. See docs.

The GitLab UI shows update available, but that does not take any prerequisites into consideration.

I need Upgrade to Ubuntu 18 or GitLab 15?

You need to upgrade to Ubuntu 18 or 20.

Hi @Joulindo, welcome to the GitLab Community forum!

As others have noted, GitLab stopped building and releasing new packages for Ubuntu 16.04 prior to the 14.x release.

Here are your upgrade options:

Upgrade Options

Option A: Migrate GitLab from Ubuntu 16.04 server new Ubuntu 18/20.04 server

  1. Backup GitLab on 16.04 server
  2. Spin up new Ubuntu 18.04 or 20.04 server on seperate box
  3. Install GitLab on 18/20.04 box using same GitLab version installed on Ubuntu 16.04 box
  4. Copy backup to new 18/20.04 server
  5. Restore backup on new 18/20.04 server

Option B: In-place OS upgrade

  1. Upgrade to the latest version of available packages. OS upgrade will fail unless you’re running the latest version of 16.04 packages. sudo apt-get dist-upgrade
  2. Initiate OS upgrade: sudo do-release-upgrade (ensure you’ll be available and attentive, this process will require user interaction and shouldn’t be stopped once it’s started)
  3. Follow prompts, select to not change configuration if in doubt.
  4. Reboot
  5. Add GitLab package repository for your new OS version
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
  1. sudo apt update

(good additional resource: How To Upgrade to Ubuntu 18.04 Bionic Beaver | DigitalOcean)

If you encounter any problems, there are some troubleshooting steps here.

2 Likes

@gitlab-greg Thanks for the thorough reply. A few follow-up questions

  1. Is either Option recommended over the other or should both work equally as well (in theory)?

  2. Is the answer basically the same for gitlab-ce (aside from a slightly different omnibus URL in step #5)?

  3. In Option B will step #5 just update the existing apt repository to reference bionic or focal instead of xenial?

Hi @fleish :wave: , welcome to the GitLab Community forum! :tada:

  1. Is either Option recommended over the other or should both work equally as well (in theory)?

I’ve tested both options extensively and in my experience they both work equally well. Option A is zero-risk, Option B carries some risk.

I suggest migration (Option A) instead of in-place upgrade (Option B) because it mitigates the risk of data loss or downtime. In-place upgrades work great 99% of the time, but there’s a slight chance that if system crashes during the OS upgrade it could block SSH connections and/or leave the system in a non-bootable state. Recovery from this state without a filesystem snapshot could require physical (Keyboard + Monitor) access to the server - so unless you’re running GitLab on an on-prem server, an in-place upgrade carries above-zero chance of “bricking” your machine.

  1. Is the answer basically the same for gitlab-ce (aside from a slightly different omnibus URL in step #5)?

Exactly! If you’re running gitlab-ce instead of gitlab-ee, simply replace -ee with -ce in these examples.

  1. In Option B will step #5 just update the existing apt repository to reference bionic or focal instead of xenial?

That’s correct! With Option B (in-place OS upgrade), the xenial repository sources get commented-out in /etc/apt/sources.list.d/. Until the apt repository source for gitlab-[c,e]e is updated to reference bionic or focal, no upgraded versions will show as available via apt package manager. The one-liner in Option B step 5 adds appropriate repository source your system’s apt sources.

Alternatively, one could un-comment the xenial repository source in your /etc/apt/sources.list.d/gitlab_gitlab-[c,e]e.list file and change xenial to bionic or focal following the upgrade, then run apt update to have apt fetch the latest package versions.

Thanks for the welcome, @gitlab-greg!

I went ahead with Option B and wanted to note a few things.

First is after apt update in step #6 it is also necessary to run apt upgrade additional wrinkle.

Another is gitlab could not upgrade itself from version 13.12.10 to the latest version 14.2.3 directly. I had to first do an intermediate install to the latest 14.0.x version. From there I was able to goto 14.2.3, although that is not specifically covered in Upgrading GitLab | GitLab

I also ran into an issue where the DB updates failed somewhere and I had to run a command manually to get them to complete and then re-run apt upgrade for things to finish up.

All in all, things seem to have gone fairly smoothly other than those items. Hopefully others will see this and be prepared for those possible exceptions.

1 Like

@fleish yes it is configured in the upgrade guide: Upgrading GitLab | GitLab

 latest 13.12.Z -> latest 14.0.Z -> 14.1.Z -> latest 14.Y.Z

it shows exactly the upgrade path to go from 13.12.10 to latest 14.0.x latest 14.1.x and then to 14.2.x You missed a couple of in-between upgrades, so I hope you won’t have any issues due to potentially missed migrations.