GitLab Update - After fresh install

Hello GitLab,

I’m using GitLab for 5 years, and one of the most problems is updating GitLab to the latest version.
Firs I was using Ubuntu and in the last 2 years, CentOS but there are some problems in the installation if my GitLab hosted app refuses to finish the update.

I get error:
[root@git ~]# yum -y update
gitlab_gitlab-ee 368 B/s | 862 B 00:02
gitlab_gitlab-ee-source 384 B/s | 862 B 00:02
Dependencies resolved.

Package Architecture Version Repository Size

gitlab-ee x86_64 13.3.6-ee.0.el8 gitlab_gitlab-ee 819 M

Transaction Summary

Upgrade 1 Package

Total download size: 819 M
Downloading Packages:
gitlab-ee-13.3.6-ee.0.el8.x86_64.rpm 93 MB/s | 819 MB 00:08

Total 93 MB/s | 819 MB 00:08
Running transaction check
The transaction check succeeded.
Running transaction test
The transaction test succeeded.
Running transaction
Preparing: 1/1
Running scriptlet: gitlab-ee-13.3.6-ee.0.el8.x86_64 1/2
gitlab preinstall: Automatically backing up only the GitLab SQL database (excluding everything else!)
2020-09-16 08:17:14 +0200 – Dumping database …
Dumping PostgreSQL database gitlabhq_production … [DONE]
2020-09-16 08:17:18 +0200 – done
2020-09-16 08:17:18 +0200 – Dumping repositories …
2020-09-16 08:17:18 +0200 – [SKIPPED]
2020-09-16 08:17:18 +0200 – Dumping uploads …
2020-09-16 08:17:18 +0200 – [SKIPPED]
2020-09-16 08:17:18 +0200 – Dumping builds …
2020-09-16 08:17:18 +0200 – [SKIPPED]
2020-09-16 08:17:18 +0200 – Dumping artifacts …
2020-09-16 08:17:18 +0200 – [SKIPPED]
2020-09-16 08:17:18 +0200 – Dumping pages …
2020-09-16 08:17:18 +0200 – [SKIPPED]
2020-09-16 08:17:18 +0200 – Dumping lfs objects …
2020-09-16 08:17:18 +0200 – [SKIPPED]
2020-09-16 08:17:18 +0200 – Dumping container registry images …
2020-09-16 08:17:18 +0200 – [SKIPPED]
rake aborted!
Errno::ENOENT: No such file or directory - tar
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/popen.rb:38:in popen_with_detail' /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/popen.rb:14:in popen’
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:172:in tar_version' /opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:259:in backup_information’
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:21:in block (2 levels) in write_info' /opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:20:in open’
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:20:in block in write_info' /opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:19:in chdir’
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:19:in write_info' /opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:20:in block (3 levels) in <top (required)>’
/opt/gitlab/embedded/bin/bundle:23:in load' /opt/gitlab/embedded/bin/bundle:23:in
Tasks: TOP => gitlab:backup:create
(See full trace by running task with --trace)
gitlab preinstall:
gitlab preinstall: Database backup failed! If you want to skip this backup, run the following command and try again:
gitlab preinstall:
gitlab preinstall: sudo touch /etc/gitlab/skip-auto-backup
gitlab preinstall:
error: %prein(gitlab-ee-13.3.6-ee.0.el8.x86_64) scriptlet failed, exit status 1

Error in PREIN scriptlet in rpm package gitlab-ee
Verifying : gitlab-ee-13.3.6-ee.0.el8.x86_64 1/2
Verifying : gitlab-ee-13.3.5-ee.0.el8.x86_64 2/2

gitlab-ee-13.3.5-ee.0.el8.x86_64 gitlab-ee-13.3.6-ee.0.el8.x86_64

Error: Transaction failed

For the first time I installed GitLab on MariaDB and behind the router (as Virtual Machine), now I have a server dedicated to GitLab, with dedicated resources, IP and so + I installed it as the default installation.

What is the problem with the upgrade process…

Thanks for the help and assistance in the advance :slight_smile:

In case anyone else runs into this specific error:

Turns out, what it’s actually complaining about is that the ‘tar’ command is missing. I was surprised that even a minimal OS install (CentOS 8, in my case) could succeed without including something as basic as tar. At any rate I installed it and reran the upgrade, which then succeeded. (The upgrade performs a backup automatically by default unless you suppress it, and the backup process uses tar to generate its archive file.)

I suppose the error message would be more intuitive if it said something like “command not found” rather than “no such file or directory”.

well, taris not core OS functionality; OS will be fine without tar