0

I have an amd64 server that ran Ubuntu 22.04 with GitLab Omnibus installed. I upgraded GitLab to v18.0.0-ce.0, and then upgraded Ubuntu to 24.04. Everything worked well, except that the external package sources were disabled during the upgrade (as expected), so I cleared the folder /etc/apt/sources.list.d and added the new package sources, including the ones for GitLab:

curl -sSL "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash

This created /etc/apt/sources.list.d/gitlab_gitlab-ce.list:

# this file was generated by packages.gitlab.com for # the repository at https://packages.gitlab.com/gitlab/gitlab-ce deb [signed-by=/usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg] https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ noble main deb-src [signed-by=/usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg] https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ noble main

Now when I run apt update and apt list --upgradable, it shows:

gitlab-ce/noble 18.0.0-ce.0 amd64 [upgradable from: 18.0.0-ce.0]

This seems… weird? I am on that package version, but it now shows an architecture. I couldn't find any similar issues when doing a web search, only this Reddit post without any answer.

I asked ChatGPT, and it told me that "this may cause apt upgrade to always want to reinstall gitlab-ce", which is obviously not what I want.

What should I do?

(I can obviously just do a backup, attempt to perform the upgrade, and see what happens, but an authoritative answer would be nice, so that when people search for this issue in the future, they'll get a good solution.)

Improve this question
2
  • Packages for 'noble' and 'jammy' are different packages. You can probably get away by replacing the distribution name in your gitlab_gitlab-ce.list. Commented May 16 at 10:16
  • The distribution source is the right one for noble. It doesn't make sense for me to revert it. I do want to keep getting updates for the right Ubuntu version. So it tries to update to the distribution-specific package with the same name? (The amd64 suffix is what threw me off.) Commented May 16 at 11:23

1 Answer 1

Reset to default
1

Before the upgrade, you had the package installed from a repository for jammy, but now your gitlab_gitlab-ce.list points to a different repository, for noble. Both repositories contain a package gitlab-ce, but these packages are different, with different content, different URLs, different sizes and checksums, compiled for different systems.

When you changed the gitlab repository from jammy to noble, apt is unable to match the locally installed gitlab-ce package to any remote repository and gives it priority 100 while the package from the noble repository gets priority 500 and is candidate for upgrade (see section APT's Default Priority Assignments in man 5 apt_preferences). You can see priorities in the apt policy gitlab-ce output:

gitlab-ce: Installed: 18.0.0-ce.0 Candidate: 18.0.0-ce.0 Version table: 18.0.0-ce.0 500 500 https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu noble/main amd64 Packages *** 18.0.0-ce.0 100 100 /var/lib/dpkg/status

To avoid upgrade, either revert back to jammy repository in your gitlab_gitlab-ce.list and you'll see the following priorities:

gitlab-ce: Installed: 18.0.0-ce.0 Candidate: 18.0.0-ce.0 Version table: *** 18.0.0-ce.0 500 500 https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status

Or you can pin the package:

Package: gitlab-ce Pin: release a=now Pin-Priority: 1000

and get the following priorities

gitlab-ce: Installed: 18.0.0-ce.0 Candidate: 18.0.0-ce.0 Version table: 18.0.0-ce.0 500 500 https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu noble/main amd64 Packages *** 18.0.0-ce.0 1000 100 /var/lib/dpkg/status
Improve this answer
3
  • Thanks for the explanation. I don't understand why one would want to avoid an update though? As soon as, say, 18.0.1 is released, I'd want to upgrade to that anyway. FWIW, I went through with an apt dist-upgrade and the upgrade procedure from GitLab went fine, even though it was migrating to the same version. I think in terms of security and best practices, it's probably a better recommendation not to pin/hold the package? Commented May 17 at 17:39
  • Your question made an impression that you want to avoid the upgrade, which apt offers you, from the package for jammy to the package for noble. Commented May 17 at 17:48
  • Sorry for the confusion, that's not what my intent was. Commented May 18 at 18:05

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.