Upgrading from 14.x to 15.x
If your upgrade failed or you are starting the upgrade, follow these steps:
1015301 has more details
Check for any batched background migrations that failed.
root@git:~# sudo -u gitlab psql gitlab_production could not change directory to "/root": Permission denied psql (13.5 (Debian 13.5-0+deb11u1)) Type "help" for help. gitlab_production=> select id,status,job_class_name, table_name, column_name, job_arguments from batched_background_migrations where status <> 3; id | status | job_class_name | table_name | column_name | job_arguments ----+--------+--------------------------------------------------+--------------+-------------+--------------- 15 | 4 | BackfillIntegrationsTypeNew | integrations | id | [] 16 | 4 | BackfillUserNamespace | namespaces | id | [] 17 | 4 | BackfillNamespaceIdForNamespaceRoute | routes | id | [] 18 | 4 | BackfillIssueSearchData | issues | id | [] 19 | 4 | BackfillMemberNamespaceForGroupMembers | members | id | [] 20 | 4 | MigratePersonalNamespaceProjectMaintainerToOwner | members | id | [] 21 | 4 | NullifyOrphanRunnerIdOnCiBuilds | ci_builds | id | [] 23 | 4 | BackfillGroupFeatures | namespaces | id | [10000] (8 rows) gitlab_production=>
Retry them from /admin/background_migrations relative url from Web UI. Now you can install gitlab 15.0.x.
Gitlab Common Errors
If you have this kind of error
Cloning into'public-test-project-ssh'... Received disconnect from YOUR_SERVER_IP port 22:2: Too many authentication failures Disconnected from YOUR_SERVER_IP port 22 fatal: Can't read distant repository.
on an ssh clone
git clone gitlab@ssh.your-gitlab-instance.org:public-test-group/public-test-project.git public-test-project-ssh
Note : In your command line host should match your ssh hostname for gitlab as group and project name.
To be sure you should find a line like the following in /var/log/auth.log
User gitlab from YOUR_CLIENT_IP not allowed because not listed in AllowUsers
You may have to allow gitlab user in /etc/ssh/sshd_config
AllowUsers user1 user2 gitlab AllowGroups user1 group2 gitlab
Note : user1, user2, group2 are here for the example adapt to your setup.
Do not forget to restart the service
service ssh restart
Debug installation and configuration
Gitlab is composed of several parts. As always logs (/var/log/gitlab), debian specific documentation (/usr/share/doc/gitlab/) and (official) documentation provide lots of information.
gitlab-rake is convenience script to easily run rake commands provided by gitlab in debian environment.
# gitlab-rake gitlab:check # gitlab-rake gitlab:env:info
gitlab-rails-console is another convenience script to launch a rails console in gitlab debian environment.
# gitlab-rails-console
Just make sure you don't have any gems installed from rubygems.org conflicting with debian packaged versions of the gems required by gitlab. /var/lib/gems/<ruby_version> (/var/lib/gems/2.5.0 or /var/lib/gems/2.7.0) should not have any gems.
rake aborted errors during installation
If your update failed for some reason (usually when dependencies are not satisfied for bundle install --local), and you retry installation after fixing dependencies, you may see errors like
rake aborted! NameError: uninitialized constant Gitlab::Patch::ActiveRecordQueryCache /usr/share/gitlab/config/initializers/active_record_query_cache.rb:3:in `<top (required)>'
You will have to manually remove problem creating initializers from /etc/gitlab/initializers. A list of such initializers can be found from gitlab source package or from https://salsa.debian.org/ruby-team/gitlab in debian/maintscript` file.
All lines starting with rm_conffile and corresponding versions are what you need to check.
Additionally, if there is any extra files present in your system at /etc/gitlab/initializers that is not installed by the current package as shown in dpkg -L gitlab | grep '/etc/gitlab/initializers', you need to remove that. We usually try to remove obsolete initializers automatically, but sometimes we miss some files.
The following command returns the list of obsolete initializer files:
for fname in /etc/gitlab/initializers/*; do dpkg -L gitlab | grep -qFx "$fname" || echo "$fname"; done
manually installing ruby dependencies
These commands should be run as root users and runuser will switch to gitlab user for gem and bundle commands. Running gem and bundle commands directly as root without runuser can create permission issues in future. In case of any permission issues, /var/lib/gitlab/.gem can be removed, this will be recreated during package configuration.
For example, to install openssl 3.0.2,
# export GEM_HOME=/var/lib/gitlab/.gem
# export GEM_PATH=$(gem env gempath)
# gitlab_user=gitlab
# runuser -u ${gitlab_user} -- sh -c "gem install -v 3.0.2 openssl"When ruby dependencies are installed (or uninstalled) manually using gem command, we need to update gitlab and gitaly's Gemfile.lock to use the recently installed version. See 944698 for details.
# gitlab_user=gitlab # use the gitlab username instead of gitlab if you changed it
# cd /usr/share/gitlab
# truncate -s0 Gemfile.lock
# runuser -u ${gitlab_user} -- bundle install --local
# cd /usr/share/gitaly/ruby
# truncate -s0 Gemfile.lock
# runuser -u ${gitlab_user} -- bundle install --local
remote: GitLab: 401 Unauthorized
If you got this error after a purge and reinstall when trying git push, then it is because the old .gitlab_shell_secret was not cleaned up during purge. So you need to purge again and remove this file manually before you reinstall
# rm /usr/share/gitlab-shell/.gitlab_shell_secret
TODO: Clean this in purge
your account is awaiting approval from your GitLab administrator
If you saw this message after creating an account for the first time,
You have signed up successfully. However, we could not sign you in because your account is awaiting approval from your GitLab administrator.
You can approve the user and grant Administration access by using gitlab-rails-console command. The steps are documented in /usr/share/doc/gitlab/README.Debian.gz.