Argh! Historically 500 errors with GitLab have been something of an ongoing issue with GitLab (our appliance in particular, but also other users). However we thought that we had fixed it for v18.0!? FWIW I personally tested v18.0 - using the password 'TurnKey12?' - and it seemed to be working ok!? Although it was VERY slow to start...

In my experience, it takes ages to be ready to login, up to 10 minutes before it's ready to log in. Before it starts properly it will throw a 500. Although your note that it gives an incorrect password error if you use the wrong password, makes me wonder if that's actually the problem here?

As per your note about wrong password errors, I don't think this is the issue. But just to be sure, you are using the username 'root' too, right? Note that's not the Linux root user & password, it's the GitLab root user & password. As

Also, does your VM meet the minimum system requirements, particularly RAM? Perhaps it's running out of resources and crashing when you get the password right and it logs you in? Also, as noted above, did you give it plenty of time to start up?

The GitLab docs note that the general production minimum requirements are 8GB (16GB recommended. Although the "constrained environment" docs (e.g. personal use/small teams) say that it should work with only 2GB & 1GB swap (2.5GB & 1GB swap recommended min). So I'd take that to mean 3-3.5GB minimum without swap - FWIW I used 4GB & 2x vCPUs with no swap in my test env and whilst it was slow to start and sluggish to use, it worked.

After doing a bit of reading online, some users have reported that if they don't set a password with enough complexity, they get 500 errors. AFAIK our GitLab firstboot config script requirements should be enough to allow login, but if your password isn't very complex, perhaps it's worth trying to set it again with something more complex? I.e.:

/usr/lib/inithooks/bin/gitlab.py

Keep a look out for any error messages that occur after that script exits too.

If all that checks out, then perhaps there are some hints in the GitLab logs? According to the docs, this should show the most recent log entries:

gitlab-ctl tail

FYI we use the "omnibus install" but sudo is not required when running as the root Linux user.

There should also be a collection of log files in /var/log/gitlab. I forget which service is most likely responsible, but I'd try 'gitlab-rails' first or perhaps 'puma'. Perhaps it might also be worth checking Nginx logs too? Although my guess is that they will just note that the backend didn't respond appropriately (i.e. 500 error) and nothing particularly useful.

FWIW the inithook (firstboot script), uses the documented rake task:

gitlab-rake "gitlab:password:reset[root]"

Although if you run out of things to try/test, then perhaps it's worth trying to run that directly yourself. And/or the interactive rails console. Although I would expect the same result from that as the rake command would give above.

Either way, please let me know how you go. If you continue to have issues, I'll try again myself and see if I can reproduce the issue.

And thanks for your report. Whilst it's frustrating, I'd rather know.