TurnKey Linux Virtual Appliance Library

Upgrading Gitlab

Question one:

Should I be messing with upgrading Gitlab myself, or should i just wait for TKL to do this for me? 


And if the answer to that is yes, then how do i go about upgrading...
I have some problems following the instructions posted on the gitlab site:


Question two:

Should i follow an incremental upgrade path as described above, or should i go straight from 2.5 to 2.8?


Question three:

What is the best way of getting the upgrade down with git, do I run the git clone command directly on the folder that gitlab is installed in?

Some quick answers


1. Upgrade gitlab yourself. I don't think the TKL guys are going to keep the up with new versions of the gitlab, as they come out too quickly. And it's a good thing to keep gitlab upgraded.

2. You have to follow the incremental path. I'm not sure which version finally did it to the TKLAppliance, but you'll have to upgrade from there on.

3. You shouldn't run a clone command, instead you should pull, but I can't help you with this as I don't have the appliance running. Why don't you post the specific problems you're getting with the official upgrade instructions to see if I can help you a bit more?

Upgrading turnkey-gitlab gitlab

Hi, I am new to git and gitlab. Currently using turnkey-gitlab. The gitlab version is 2.5.0. There is no '.git' directory in '/home/gitlab/gitlab/' should I start with 'git remote add origin ...'? If yes, what is the correct command?

Jeremy's picture

Ok here's where I got to so far...

And it's close (I think) but I can't be sure.

I am using the instructions here: https://github.com/gitlabhq/gitlabhq/wiki/From-2.2-and-higher-to-2.9
as I figure that it probably the most reasonable way to go)

Ok so here is what I have which seems to work ok:

	service redis-server stop
service nginx stop
cd /home/gitlab/gitlab
sudo -u gitlab git init
sudo -u gitlab git remote add origin git://github.com/gitlabhq/gitlabhq.git
sudo -u gitlab git pull origin stable
sudo -u gitlab gem update --system
sudo -u gitlab cp config/gitlab.yml config/gitlab.yml.orig
sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml

But it all falls over when I run

(important bits in bold)

sudo -u gitlab bundle install --without development test
Fetching gem metadata from http://rubygems.org/.
Error Bundler::HTTPError during request to dependency API
Fetching full source index from http://rubygems.org/
Fetching https://github.com/gitlabhq/grit.git
remote: Counting objects: 5135, done.
remote: Compressing objects: 100% (2802/2802), done.
remote: Total 5135 (delta 2453), reused 4878 (delta 2250)
Receiving objects: 100% (5135/5135), 1.99 MiB | 212 KiB/s, done.
Resolving deltas: 100% (2453/2453), done.
Fetching https://github.com/gitlabhq/grack.git
remote: Counting objects: 149, done.
remote: Compressing objects: 100% (85/85), done.
remote: Total 149 (delta 59), reused 134 (delta 50)
Receiving objects: 100% (149/149), 26.44 KiB | 14 KiB/s, done.
Resolving deltas: 100% (59/59), done.
Fetching https://github.com/gitlabhq/omniauth-ldap.git
remote: Counting objects: 154, done.
remote: Compressing objects: 100% (93/93), done.
remote: Total 154 (delta 51), reused 132 (delta 32)
Receiving objects: 100% (154/154), 76.00 KiB | 15 KiB/s, done.
Resolving deltas: 100% (51/51), done.
Fetching https://github.com/gitlabhq/yaml_db.git
remote: Counting objects: 333, done.
remote: Compressing objects: 100% (144/144), done.
remote: Total 333 (delta 193), reused 296 (delta 161)
Receiving objects: 100% (333/333), 44.06 KiB | 20 KiB/s, done.
Resolving deltas: 100% (193/193), done.
Using rake ( 
Installing i18n (0.6.1) 
Installing multi_json (1.3.6) 
Installing activesupport (3.2.8) 
Installing builder (3.0.2) 
Installing activemodel (3.2.8) 
Using erubis (2.7.0) 
Installing journey (1.0.4) 
Using rack (1.4.1) 
Using rack-cache (1.2) 
Using rack-test (0.6.1) 
Using hike (1.2.1) 
Using tilt (1.3.3) 
Using sprockets (2.1.3) 
Installing actionpack (3.2.8) 
Installing mime-types (1.19) 
Using polyglot (0.3.3) 
Using treetop (1.4.10) 
Using mail (2.4.4) 
Installing actionmailer (3.2.8) 
Using arel (3.0.2) 
Using tzinfo (0.3.33) 
Installing activerecord (3.2.8) 
Installing activeresource (3.2.8) 
Using bundler (1.1.4) 
Using rack-ssl (1.3.2) 
Installing json (1.7.5) with native extensions 
Using rdoc (3.12) 
Installing thor (0.16.0) 
Installing railties (3.2.8) 
Installing rails (3.2.8) 
Installing acts-as-taggable-on (2.3.1) 
Using bcrypt-ruby (3.0.1) 
Using blankslate ( 
Installing bootstrap-sass ( 
Using carrierwave (0.6.2) 
Using charlock_holmes (0.6.8) 
Installing chosen-rails ( 
Installing coffee-script-source (1.3.3) 
Installing execjs (1.4.0) 
Using coffee-script (2.2.0) 
Using coffee-rails (3.2.2) 
Using colored (1.2) 
Using daemons (1.1.8) 
Installing orm_adapter (0.3.0) 
Installing warden (1.2.1) 
Installing devise (2.1.2) 
Using diff-lcs (1.1.3) 
Installing draper (0.17.0) 
Using escape_utils (0.2.4) 
Using eventmachine (0.12.10) 
Installing multipart-post (1.1.5) 
Installing faraday (0.8.4) 
Installing ffaker (1.14.0) 
Installing sass (3.1.19) 
Installing sass-rails (3.2.5) 
Installing font-awesome-sass-rails ( 
Installing foreman (0.47.0) 
Installing gemoji (1.1.1) 
Using git (1.2.5) 
Using posix-spawn (0.3.6) 
Installing yajl-ruby (1.1.0) with native extensions 
Installing pygments.rb (0.3.1) 
Installing github-linguist (2.3.4) 
Installing github-markup (0.7.4) 
Installing gitlab_meta (3.0) 
Installing gratr19 ( 
Using grit (2.5.0) from https://github.com/gitlabhq/grit.git (at 7f35cb9) 
Installing hashery (1.5.0) 
Installing gitolite (1.1.0) 
Using grack (1.0.0) from https://github.com/gitlabhq/grack.git (at master) 
Using hashie (1.2.0) 
Using multi_xml (0.5.1) 
Installing rack-mount (0.8.3) 
Installing grape (0.2.1) 
Installing haml (3.1.6) 
Using haml-rails (0.3.4) 
Using httparty (0.8.3) 
Installing httpauth (0.1) 
Installing jquery-atwho-rails (0.1.6) 
Using jquery-rails (2.0.2) 
Installing jquery-ui-rails (0.5.0) 
Installing jwt (0.1.5) 
Installing kaminari (0.14.0) 
Using kgio (2.7.4) 
Using libv8 ( 
Installing modernizr (2.5.3) 
Using mysql2 (0.3.11) 
Using net-ldap (0.2.2) 
Installing oauth (0.4.7) 
Installing oauth2 (0.8.0) 
Using omniauth (1.1.0) 
Installing omniauth-oauth2 (1.1.0) 
Installing omniauth-github (1.0.3) 
Installing omniauth-google-oauth2 (0.1.13) 
Using pyu-ruby-sasl ( 
Using rubyntlm (0.1.1) 
Using omniauth-ldap (1.0.2) from https://github.com/gitlabhq/omniauth-ldap.git (at f038dd8) 
Installing omniauth-oauth (1.0.1) 
Installing omniauth-twitter (0.0.13) 
Installing pg (0.14.0) with native extensions 
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

        /usr/local/bin/ruby extconf.rb 
checking for pg_config... no
No pg_config... trying anyway. If building fails, please try again with
checking for libpq-fe.h... no
Can't find the 'libpq-fe.h header
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

provided configuration options:

Gem files will remain installed in /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/pg-0.14.0 for inspection.
Results logged to /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/pg-0.14.0/ext/gem_make.out
An error occured while installing pg (0.14.0), and Bundler cannot continue.
Make sure that `gem install pg -v '0.14.0'` succeeds before bundling.

I tried

sudo -u gitlab gem install pg -v '0.14.0' --without-pg


sudo -u gitlab gem install pg -v '0.14.0' --without-pg_config

in the hope that it wasn't really needed (from what I gather the pg gem is to do with PostgreSQL - and the TKL appliance is built with MySQL backend from what I can gather... But they both return "invalid option" errors...

Interestingly enough though, I started playing with this upgrade from another instance, documenting as I went and got past this (but ran into troubles later so I started again). Not sure what that's about...? I'll try again another time...

[update] I think there is a bug and I just had poor timing... The repo has been updated (to v3.0.1) and I think the first time (when it got past this bit) was back with v2.9. I have just posted on the GitLab mailing list and we'll wait to see what happens...

And i seems like the issue I was having before (on my original server) was to do with the SSH key. I just read about it on the GitLab mailinglist.

Me too

I've been having similar trouble upgrading the GitLab 2.5 distro from TKL.  It's frustrating because the TKL distro is really convenient for setting up but upgrading seems impossible.

Jeremy's picture

Ok some progress...

When I get this sorted I'll post the lot together as a clean post - or perhaps in the wiki or maybe as a TKLPatch 

So I posted on the GitLab mailing list and found out that things have changed a little...

Instead of 

sudo -u gitlab bundle install --without development test

you need to run

sudo -u gitlab bundle install --without development test postgres sqlite

which has got me further, but still not quite there, now I am stuck at the final step

sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production
Starting diagnostics
/home/git/repositories/ is writable?............YES 
remote: Counting objects: 24, done. 
remote: Compressing objects: 100% (17/17), done. 
remote: Total 24 (delta 2), reused 0 (delta 0) 
Receiving objects: 100% (24/24), done. 
Resolving deltas: 100% (2/2), done. 
Can clone gitolite-admin?............YES 
UMASK for .gitolite.rc is 0007? ............YES 
/home/git/.gitolite/hooks/common/post-receive exists? ............NO 

rake aborted! unexpected return Tasks: TOP => gitlab:app:status 
(See full trace by running task with --trace)

But it's definately there (I copied it there and chowned it to git:git as per instructions)

ls -la /home/git/.gitolite/hooks/common/

total 32
drwxr-xr-x 2 git git 4096 Oct 23 21:03 .
drwxr-xr-x 4 git git 4096 Aug 11 14:54 ..
-rw-r--r-- 1 git git    0 Aug 11 14:54 gitolite-hooked
-rw-r--r-- 1 git git  288 Aug 11 14:54 gl-pre-git.hub-sample
-rwxr-xr-x 1 git git  471 Oct 23 21:03 post-receive
-rwxr-xr-x 1 git git  825 Aug 11 14:54 post-receive.mirrorpush
-rwxr-xr-x 1 git git 4348 Aug 11 14:54 update
-rw-r--r-- 1 git git 1405 Aug 11 14:54 update.secondary.sample

I have posted again on the GitLab mailing list but if anyone here has any bright ideas, I'd love to hear them....

[update] I have fixed this issue too now (it is to do with the permissions). Unfortunately I don't have my notes handy, but it's pretty straight forward. Unfortunately it still isn't working... :( It passes all the tests but the GitLab server still refuses to start... I think I'll start again on a fresh TKL GitLab appliance when I get a chance and see how we go from there...

Thanks for your efforts

Just wanted to say thanks to Jeremy for your efforts on this issue, much appreciated. :)

Jeremy's picture

No worries...

Just wish that I had something better to report back... I tried again with a fresh GitLab instance (number 5...!) and can now complete all the steps right through to the last - a successful result from "sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production" but unfortunately GitLab still won't start. :(

The error I get is:

Starting Gitlab service: master failed to start, check stderr log for details

The contents of log/unicorn.stderr.log are:

I, [2012-10-24T12:25:51.925647 #4279]  INFO -- : listening on addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket fd=5
I, [2012-10-24T12:25:51.937718 #4279]  INFO -- : Refreshing Gem list
I, [2012-10-24T12:26:15.584286 #4279]  INFO -- : master process ready
I, [2012-10-24T12:26:15.661607 #4321]  INFO -- : worker=0 ready
I, [2012-10-24T12:26:15.677125 #4324]  INFO -- : worker=1 ready
E, [2012-10-24T21:33:18.737564 #10926] ERROR -- : adding listener failed addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket (in use)
E, [2012-10-24T21:33:18.737796 #10926] ERROR -- : retrying in 0.5 seconds (4 tries left)
E, [2012-10-24T21:33:19.238471 #10926] ERROR -- : adding listener failed addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket (in use)
E, [2012-10-24T21:33:19.238562 #10926] ERROR -- : retrying in 0.5 seconds (3 tries left)
E, [2012-10-24T21:33:19.738984 #10926] ERROR -- : adding listener failed addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket (in use)
E, [2012-10-24T21:33:19.739079 #10926] ERROR -- : retrying in 0.5 seconds (2 tries left)
E, [2012-10-24T21:33:20.239533 #10926] ERROR -- : adding listener failed addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket (in use)
E, [2012-10-24T21:33:20.241067 #10926] ERROR -- : retrying in 0.5 seconds (1 tries left)
E, [2012-10-24T21:33:20.741482 #10926] ERROR -- : adding listener failed addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket (in use)
E, [2012-10-24T21:33:20.741582 #10926] ERROR -- : retrying in 0.5 seconds (0 tries left)
E, [2012-10-24T21:33:21.241942 #10926] ERROR -- : adding listener failed addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket (in use)
/home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/socket_helper.rb:140:in `initialize': Address already in use - /home/gitlab/gitlab//tmp/sockets/gitlab.socket (Errno::EADDRINUSE)
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/socket_helper.rb:140:in `new'
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/socket_helper.rb:140:in `bind_listen'
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:224:in `listen'
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:741:in `block in inherit_listeners!'
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:741:in `each'
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:741:in `inherit_listeners!'
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:123:in `start'
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/bin/unicorn_rails:209:in `'
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/bin/unicorn_rails:23:in `load'
	from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/bin/unicorn_rails:23:in `'

I haven't had a really close look and so perhaps I'm missing something obvious, but I have no idea what the error is about (I know nothing about Ruby...) and I've had no response so far from my post on the GitLab mailing list. If I get time I may try one more time and if I get the same result and get no reponse from the mailing list, then I think I will try posting it as an 'issue' against GitLab on the GitLab GitHub...

Anyway here is the code that I am using:

service gitlab stop
cd /home/gitlab/gitlab
sudo -u gitlab git init
sudo -u gitlab git remote add origin git://github.com/gitlabhq/gitlabhq.git
sudo -u gitlab git pull origin stable
sudo -u gitlab cp config/gitlab.yml config/gitlab.yml.orig
sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml
sudo -u gitlab bundle install --without development test postgres sqlite
sudo -u gitlab bundle exec rake db:migrate RAILS_ENV=production
cp lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive
chown git:git /home/git/.gitolite/hooks/common/post-receive
chmod g+rwx /home/git/.gitolite
sudo -u git -H sed -i "s/\(GIT_CONFIG_KEYS\s*=>*\s*\).\{2\}/'\.\*'/g" /home/git/.gitolite.rc
sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production

If anyone else has any bright ideas I'd love to hear...

[update] Just updated the code & comments a little. Nothing major, just realised that the redis-server doesn't need to be stopped, just gitlab...

Here's cheering you on. I'll

Here's cheering you on. I'll buy you a beer with paypal if you get it! :D

On Oct 24, 2012, at 6:00 PM, TurnKey Linux <admin@turnkeylinux.org> wrote:

Found that it wasn't able to

Found that it wasn't able to start resque. You can try running resque and it is missing some additional config in gitlab.yml

> resque.sh

which I found it over here




  host: localhost
  port: 80
  https: false
  default_projects_limit: 10
  # backup_path: "/vol/backups"   # default: Rails.root + backups/
  # backup_keep_time: 604800      # default: 0 (forever) (in seconds)
  # disable_gravatar: true        # default: false - Disable user avatars from Gravatar.com
Jeremy's picture

Yep that's it; Resque not starting...

Thanks for the input.

'./resque.sh' returns the same error for me as 'service gitlab start' except it mentions that a trace can be done for full output. I tried that but not sure what the go is there, it ran exactly the same (maybe it saves to a file somewhere cause there was no on screen trace).

Also I double checked the config file but the updated format seems to be covered in my code with the line:

sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml

Jeremy's picture

Still no progress...

I just saw that GitLab has been updated to 3.0.3 so I tried again to update this appliance from a clean install (#6)... Still no joy though... :(

I just tweaked the code I am using to do this update in the above forum post. It is so frustrating that this doesn't work cause I can't figure out why. Also FYI after reading the above error I posted it seemed that the socket was the problem, with naive optimism I deleted the .socket in #5 but still errors.

The errors I get now (in #6) are:

cat log/unicorn.stderr.log 
I, [2012-10-28T03:04:46.430091 #4095]  INFO -- : listening on addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket fd=5
I, [2012-10-28T03:04:46.430805 #4095]  INFO -- : Refreshing Gem list
I, [2012-10-28T03:05:08.422747 #4095]  INFO -- : master process ready
I, [2012-10-28T03:05:08.479913 #4135]  INFO -- : worker=0 ready
I, [2012-10-28T03:05:08.495342 #4138]  INFO -- : worker=1 ready
I, [2012-10-28T03:11:11.930897 #4095]  INFO -- : reaped # worker=0
I, [2012-10-28T03:11:11.931046 #4095]  INFO -- : reaped # worker=1
I, [2012-10-28T03:11:11.931136 #4095]  INFO -- : master complete
I, [2012-10-28T03:46:36.162472 #6040]  INFO -- : unlinking existing socket=/home/gitlab/gitlab//tmp/sockets/gitlab.socket
I, [2012-10-28T03:46:36.192208 #6040]  INFO -- : listening on addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket fd=5
I, [2012-10-28T03:46:36.192752 #6040]  INFO -- : Refreshing Gem list
/home/gitlab/gitlab/app/models/event/push_trait.rb:2:in `': undefined method `as_trait' for Event::PushTrait:Module (NoMethodError)
from /home/gitlab/gitlab/app/models/event/push_trait.rb:1:in `'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `block in require'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:236:in `load_dependency'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:359:in `require_or_load'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:313:in `depend_on'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:225:in `require_dependency'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:439:in `block (2 levels) in eager_load!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:438:in `each'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:438:in `block in eager_load!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:436:in `each'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:436:in `eager_load!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/application/finisher.rb:53:in `block in '
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `instance_exec'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `run'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:55:in `block in run_initializers'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `each'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `run_initializers'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/application.rb:136:in `initialize!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/railtie/configurable.rb:30:in `method_missing'
from /home/gitlab/gitlab/config/environment.rb:5:in `'
from config.ru:4:in `require'
from config.ru:4:in `block in '
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/builder.rb:51:in `instance_eval'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/builder.rb:51:in `initialize'
from config.ru:1:in `new'
from config.ru:1:in `'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn.rb:44:in `eval'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn.rb:44:in `block in builder'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/bin/unicorn_rails:139:in `call'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/bin/unicorn_rails:139:in `block in rails_builder'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:696:in `call'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:696:in `build_app!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:136:in `start'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/bin/unicorn_rails:209:in `'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/bin/unicorn_rails:23:in `load'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/bin/unicorn_rails:23:in `'

So still no idea what is going on...

Missing gem: modularity

Seems like the modularity gem is missing. I got one step further by just adding it to the Gemfile:

gem "modularity"

Remember to update your gems:

bundle update

Jeremy's picture

Another way to skin this cat...

Another way to go may be to use the unofficial GitLab Debian repo. See here.

Obviously it is not signed, nor is a known quantity (ie I have no idea who hosts it and/or how legit they are) but I assume (perhaps naively?) that it should be ok...!?

It seems to get regularly updated too which may be a handy thing...

Only thing is whether it may be best to try to install to the GitLab appliance, or to install to Core... Either way TKLBAM will need a bit of tweaking to make it work right (to make sure all the repos etc are backed up).

Gitlab team paid support

So we are still at a standstill on this whole upgrade issue?

Just one thing i noticed, that GitlabHq offers paid support on upgrading Gitlab.  http://blog.gitlabhq.com/support/index.html#comment-615483834

I could be interested in helping out with a few buck$ if anyone else was interested on chipping in on this to help make the TKL Gitlab appliance upgradable.

Jeremy's picture

Yep... Ground to a halt...

I've hit a wall with the upgrade. I have no idea why GitLab won't start, have recieved no response from my post on the GitLab mailing list and have no time currently to play more.

One thing that has occurred to me is that perhaps an incremental path may be the way to go. The benefit of that is that it can be built on. I have an idea of how we could do that but as I say I just don't have any spare time for it at the moment.

Whilst it would be nice to have the appliance upgradable, for the moment I am using it inhouse (ie only accessable via LAN) so I don't really need it updated (but it would be nice) so beyond investing time when I have it I am not (yet) willing to invest cash. If we were then perhaps Adrian (Moya) may be another option. I know that he is not involved lots here at TKL these days but he has been a wonderful assistance in the past and may be willing to help out the TKL community again?

I'll take a look soon

Hi guys, sorry for not helping right away, I'm just full right now, but I talked last week to Alon about this thread. He commented that Gitlab is being installed from a tarball, so it won't be upgradable like it is. I think he knows that this may not have been the best way to install for the appliance, considering the awesome rhythm of releases the gitlab team is able to produce. 

Anyway, I would need time to play with this which I don't have this week but I think I'll be able next week to take a look. Meanwhile, you can take a look at my original TKLPatch for this appliance (used as a base for the official one):


I hope it helps, if not download tkl-core and apply the patch. Once finished, the result should be upgradable using the official docs. If it goes well, I'll see if I can convince the TKL guys to change this particular appliance.

Jeremy's picture

Awesome Adrian

Thanks for your input mate.

I assumed that seeing as the tarball would've been simply a snapshot of the stable repo; that creating it as a git repo (git init) and adding the gitlab repo as the origin that it would in effect be the same as installing straight from git... But perhaps not?

If I have time I'll test you idea out with your patch.

If we switch to a new instance

As always, many thanks for your efforts.

So it seems that it will remain unlikely that we will be able to upgrade our existing instance of TKL Gitlab from 2.5, and we will probably end up with either a new TKL Core instance with Adrians patch, or a future release of TKL Gitlab.

It is something of a nuisance if we will lose the stuff we have stored in Gitlab so far, would it be difficult to transfer the data from our existing installation of Gitlab 2.5 to a new installation in the future?

Jeremy's picture

Sorry for slow response

I'm not 100% sure what we'll end up. It's probably more likely we'll end up with a patch. I still personally hold out for an upgrade path for the TKL appliance. But unfortunatly that is beyond my current ability. And I just don't have time to bang my head against the TKL Gitlab wall anymore...

As for your data, there is no reason to think that migrating the data should be any issue. It is highly likely that migrating the data using TKLBAM will still be possible (even from TKL GitLab to a custom TKL Core with GitLab installed). Failing that I have seen data migration discussions/instructions on the GitLab mailing list so that should be a worst case scenario.

Jeremy's picture

Ok peeps...

I have done it (sort of...)!

It's perhaps a dirty way of doing it, and I'm certainly not saying it's the best way - but it works! It basically reinstalls GitHub from scratch (with a fresh DB as well). I have included some lines that backup the old GitHub install folder and DB as as I have intention to try to update my GitLab server (that includes data) but haven't got there yet. I also thought then at least if someone doesn't read all this and does it on their existing server (with data) then all wouldn't be lost...

Ideally it'd be nice to create a TKLPatch of this, or at least a nice script that you can download and run, but until then...

Note: I am yet to try this on a server that already includes data. I hope to refine this so it will work with existing data, but for now (unless you want to build on my work) I suggest that if you have existing data, run this on a clean install and then migrate your data across (I haven't tried it but I have read about it on the GitLab wiki).

What it does:

  • updates package lists and upgrades all GitLab dependancies
  • backs up the DB
  • deletes (drops) the DB and recreates an emplty one
  • backs up the github folder (actually renames it)
  • Then does a more-or-less clean install (from the stable GitLab GitHub repo)

You will need your MySQL root password handy (and put it in the 3 times you will be asked).

apt-get update
apt-get install -y wget curl gcc checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libreadline6-dev libc6-dev libssl-dev libmysql++-dev make build-essential zlib1g-dev libicu-dev redis-server openssh-server git-core python-dev python-pip libyaml-dev postfix libpq-dev
mysqldump -uroot -p -c --add-drop-table --add-locks --all --quick --lock-tables gitlab_production > gitlab_sql_dump.sql
mysqladmin -uroot -p drop gitlab_production
mysqladmin -uroot -p create gitlab_production
cd /home/gitlab
sudo -u gitlab mv gitlab gitlab-old
sudo gem install charlock_holmes --version '0.6.8'
sudo gem install bundler
sudo -u gitlab git clone -b stable https://github.com/gitlabhq/gitlabhq.git gitlab
cd /home/gitlab/gitlab
sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml
sudo -u gitlab cp /home/gitlab/gitlab-old/config/database.yml config/database.yml
sudo -u gitlab bundle install --without development test sqlite postgres  --deployment
sudo -u gitlab bundle exec rake gitlab:app:setup RAILS_ENV=production
sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production
sudo -u gitlab cp config/unicorn.rb.example config/unicorn.rb

And that should do it...!

Now start GitLab:

service gitlab start

And log in... Note that when logging into the WebUI you will need to use the default GitLab login credentials:


Warning: DO NOT RERUN THE FIRSTBOOT SCRIPTS! It will break GitLab!

The next thing I plan to try is just migrating the DB (rather than dumping it and recreating it). It would also be nice to preserve the intial log in details (that you already set up). It'd be super nice to get it working with existing data... (which will rely on not destroying the DB). I'd also like to adjust the firstboot script so it's not destructive.


Gonna get a new VM up and running an try this out. :)

Had to do some other

Had to do some other things:



sudo gem install charlock_holmes --version '0.6.8'

	root@gitlab gitlab/gitlab# sudo cp ./lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive
root@gitlab gitlab/gitlab# sudo chown git:git /home/git/.gitolite/hooks/common/post-receive
root@gitlab gitlab/gitlab# chmod 750 /home/git/.gitolite
root@gitlab gitlab/gitlab# sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production

I meant to write    sudo gem

I meant to write 


sudo gem install charlock_holmes --version '0.6.9'

It is up and running, but......

Update 1:

Seems to be related to those pesky special norwegian characters again, this time the ø in my first name.



Thanks to the command listing from Jeremy and the last lines from andrew


sudo cp ./lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive
sudo chown git:git /home/git/.gitolite/hooks/common/post-receive
chmod 750 /home/git/.gitolite
sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production
(removed the path which could confuse some)
I got it to run on a new VM that i set up for testing.
But, when i log in with the standard credentials Jeremy provided and try to insert a new user i get a 500 error in my browser. 
I tried tailing some log files and got this:
tail -f production.log
Processing by Admin::UsersController#create as HTML
  Parameters: {"utf8"=>"â", "authenticity_token"=>"l7GAssmqupnOtLBy2AAOpf5KLw2a9Q2GqTu4RDHetoY=", "user"=>{"name"=>"Bjørn Otto Vasbotten", "email"=>"myemail@gmail.com", "force_random_password"=>"[FILTERED]", "skype"=>"", "linkedin"=>"", "twitter"=>"", "projects_limit"=>"10", "admin"=>"1"}}
Completed 500 Internal Server Error in 224ms
Redis::InheritedError (Tried to use a connection from a child process without reconnecting. You need to reconnect to Redis after forking.):
  app/observers/user_observer.rb:5:in `after_create'
  app/controllers/admin/users_controller.rb:67:in `block in create'
  app/controllers/admin/users_controller.rb:66:in `create'
Any thoughts?

Migrating data from 2.5 to 3.1

So, now that we have a new server up and running, its time to start migrating.

Found this thread which should help me:


Thanks for the instructions, it almost worked!

Hi there,

I followed Jeremy's instructions and Andrew's updates and got an almost working 3.1 system. What didn't work for me was pushing code to the repository using ssh (I haven't tried http yet).

Users could add their ssh keys through the web interface, but when pushing code to the repositories, git@gitlab was demanding a password. There are loads of reports about this condition, but I think this could be the issue (it is currently being worked on):


I tried to update the keys using gitlab:gitolite:update_keys, but my particular problem (I think) was a configuration issue in /home/.gitolite.rc . There is a hint in the link above about GIT_CONFIG_KEYS and a solution over at http://stackoverflow.com/questions/13190443/gitlab-not-interacting-with-gitolite further mentions:

[...] When I checked if /home/git/.gitolite.rc for GIT_CONFIG_KEYS I found out that the variable had the value empty string. I had to change it manually:


(I changed the variable names to their v3 conterpart and to reflect what I did).

After that, repositories got created for all my projects (/home/git/repositories/ only had gitolab-admin.git and testing.git subfolders) and the users' public keys were all copied from /home/git/.gitolite/keydir/ into /home/git/.ssh/authorized_keys

Of course it could have been something entirely different that did the trick.......

Never did the upgrade after all

Hi all, it turns out that I ended up with never doing this upgrade, we have now set up a new VM with the current TKL build, where I could actually follow Gitlabs standard upgrade path so that i now have a fully working Gitlab 6.1 installation running on TKL. :)


Great! but...

but how can I update my current appliance with all projects inside?

Jeremy's picture

I assume that you are coming from the v12.0 appliance?

AFAIK the v12.1 has an updated version of GitLab and was designed to be easier to upgrade (although I suggest that you test rather than just take my recollection for granted).

So you may be better off migrating your data to a new server, rather than trying to upgrade your server with your data in there...

Yeah, that was my conclusion

Yeah, that was my conclusion also. So far, we have only used Gitlab itself for administrivia like creating users and repos, as well as browsing repos and commits.

So we simply migrated all git repos to the new server, and since we are using the same email addresses and keys for users, all important history is preserved.

So with our 30 repos it was a bit of work to get everyting moved, but nothing that couldnt be handled.

Security upgrade.

I hope nobody missed this security upgrade:




Jeremy's picture

Thanks for the heads up! :)

Thanks for the heads up! :)

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account, used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <strike> <caption>

More information about formatting options

Leave this field empty. It's part of a security mechanism.
(Dear spammers: moderators are notified of all new posts. Spam is deleted immediately)