GitLab fails on install and/or reconfigure

Greetings everyone,
For a collage assignment I had to configure gitlab on my virtual machine that’s hosted on google cloud engine and is currently running Ubunut 20.04.
I tried to install gitlab twice but the install fails (first it got stuck for at least 5 minutes on Unpacking github-ce (13.10.2-ce.0) then it failed.
Reconfiguring gets me the same message but without any context, I don’t know where the error is, what is causing it and how to fix it.

I did research this error but the only thing that I found out is that it’s probably releated with the config file. Only line in my config line that’s not commented out is the external url and it has a value so I have no idea what to do.


I hope that someone can help me, I don’t know what logs do I need to provide so please tell me and they will be attached.

Thanks in advance!

Please show us the external_url change that you made in the config fie.

What is the spec of the virtual machine in terms of cpu/ram etc

Config file URL:
external_url “” (already has a gitea installed so I guess that it works fine, certificates are also okay)

Ubuntu 20.04
g1-small (1 vCPU, 1.7 GB memory)

Gitlab needs at least 4gb of ram, and 4cpu - so I expect your problems are due to having a VM that doesn’t meet the minimum hardware requirements for running Gitlab.

Upgrade your VM to meet the required specs.

You could probably get away with 2cpu, but you will definitely need at least 4gb ram.

1 Like

Failed to see that, but neither way it won’t work.

I added a little bit of extra power to be safe:
4 cpu

Tried to reinstall and again got stuck for over 15 minutes on
Unpacking gitlab-ee (13.10.3-ee.0) …

And again same Chef Infra Client error

EDIT: I had some doubts that it was because of the Intel CPU, tried it with AMD 4cpu 16gb ram, same thing

How are you installing the package? Did you follow the instructions using the bash script? Or did you manually download the deb package and attempt it with dpkg -i gitlab-ce?

If so, perhaps you have a corrupted/incomplete download of the package.

This link has always worked for me when installing this way:

unfortunately, from this link: gitlab/gitlab-ce - Packages · there are no md5sums or sha256sums to verify if the downloaded deb is correct or not, but considering you are having issues, it might be worth completely uninstalling the gitlab-ce package that is installed:

apt purge gitlab-ce
apt-get clean all

the first command will purge gitlab-ce, including the configuration. The second will clear the apt cache to remove the package that was downloaded previously which may be incorrectly/incompletely downloaded. Then follow the instructions from the link above to get it cleanly installed again.

Yep, did the purge and clean, following the simple Ubuntu setup with bash scripts, literallty copy paste and replace external URL.

Install got stuck again and it doesen’t work. Ill try another VM or operating system because the errors that I get are really not that much helpful. I actually noticed that I have to type something in the console in order for it to proceed to Setting up gitlab step, I don’t know why is that happening.

Thank you for your assistance.

Try Debian 10 Buster. Then use normal su to root access to install Gitlab. I never use sudo on Ubuntu, I treat it like Debian, eg: su to root and then do all the commands without sudo. Might work better, than attempting a reinstall. But if reinstalling, I recommend Debian 10.

And if you want https to work, make sure your server is publicly available on the hostname/domain name configured under external_url, so that letsencrypt can activate the SSL certs.

I would wait for it to unpack. I would say 15 minutes could not be enough for a 1G big package. You can watch whats happening on another terminal using ps or top.

you can also look in /var/log/syslog or /var/log/apt for any clues.

@balonik considering the errors it has unpacked and attempted running the scripts, when I upgrade, it does the entire process in 5 minutes. So I doubt this is the problem. Without knowing what are the partition sizes (maybe /opt is too small) or the / partition if /opt is not separate. Because this just normally works. So there is most likely a server issue here or possibly corrupted deb download. Could be wrong, but I’ve just done an install and provided the cpu/ram/disk requirements are met it always works without error.

EDIT: you can try sudo -E also as this has also come up before on other posts, when attempting to do things with sudo not passing environment variables. But as my other post, I never use sudo, but one other thing to consider also.

@iwalker I agree that 15 minutes should be more than enough. Then I have experience that even on VMs with fibre-channel SAN in the background it is unpacking for 7-9 minutes. I’ve also seen a deployment on VM with better-to-no-name-vendor antivirus (yes, on Linux server) which caused it to be over 30 minutes…
So really the best option is to look what processes are running and why its taking it so long :slight_smile:

According to our documentation:

This error is thrown when /etc/gitlab/gitlab.rb configuration file contains configuration that is invalid or unsupported. Double check that there are no typos or that the configuration file does not contain obsolete configuration.

As @iwalker pointed out, you’ll definitely want at minimum 2 CPU and 4Gb ram, ideally 4CPU and 8Gb ram. 1 CPU and 1.7Gb RAM is not sufficient to install and run a GitLab server.

external_url “” (already has a gitea installed so I guess that it works fine, certificates are also okay)

If you’re trying to install GitLab on a domain that is currently serving HTTPS websites on port 443 , I suspect this may be causing a problem.

Passing an EXTERNAL_URL variable that begins with https:// will automatically trigger GitLab’s letsencrypt integration to reach out and request a certificate for the domain. For that domain, it appears you already have a certificate set up.

I suggest using a separate VM to host GitLab (not one with Gitea or a different web server running), and point a subdomain or different domain name to your GitLab instance.