6

Yesterday I started setting up my Raspberry Pi 2 (with Raspbian Jessie) to run my own server for some things. Amongst others I want to run GitLab on my Pi. I connected to my Pi through SSH (using PuTTY on Windows) and tried following this guide, but it didn't work out for me.

When running:

sudo apt-get install gitlab-ce

It downloads just fine but then hangs on:

Unpacking gitlab-ce (8.2.2+20151202180254-ce.0) over (8.2.2+20151202180254-ce.0) ...

I tried removing it with sudo apt-get purge gitlab-ce but that doesn't work either:

dpkg: error processing package gitlab-ce (--purge):
 package is in a very bad inconsistent state; you should
 reinstall it before attempting a removal
Errors were encountered while processing:
 gitlab-ce
E: Sub-process /usr/bin/dpkg returned an error code (1)

I tried a few more things that I found scattered over the internet, but nothing seems to quite do it for me. So if anyone can please help me out here, that would be awesome. If any additional information is required I'll provide it as quick as I can.

3

The unpacking message does note that you are installing the same version as was previously in place - which I guess is not surprising if you are trying to reinstall it. Given that this package is not vital for normal operation of the Pi I'd suggest:

sudo apt-get --fix-broken --reinstall install gitlab-ce

this does assume that nothing else is broken. If there ARE other issues I'm a great fan of using aptitude rather than apt-get; its interactive mode (uses ncurses-type screen and is the default if no command line arguments given) can be a help in working out what is/or will be going on when you type g (for "Go") to make the changes selected - in case it is not clear how to start there use Ctrl+t to access the menu line at the top.


EDIT: The OP reported that this was not enough, so I will suggest a "bigger-hammer":

sudo dpkg --force-depends --remove gitlab-ce

The first argument tells dpkg (the underlying package manager that apt-get and aptitude talk with) to remove the package even if there are things that depend on it and that would be broken if it was taken away - this should be OK as we are aiming to put it back shortly.

Now we could try and remove the local copy of the package - just in case there was something funky about it - I would expect it to be located in the /var/cache/apt/archives directory. You would be looking for a file called gitlab-ce-XXX.deb where XXX is a version code of some sort.

Finally we can try again from scratch:

sudo apt-get install gitlab-ce

The following may be of help, in order they do:

  • sudo apt-get update - ensure we have an updated list of packages
  • sudo apt-get check - check the system for broken/missing packages
  • sudo apt-get -f install - repair anything reported by the previous check

Note: Reviewing the OP's link to the gitlab site - the step by step instructions talk about "2. Add the GitLab package server and install the package" however the command they provide creates a gitlab_ce.list file in the correct /etc/apt/sources.list.d/ directory with a reference to wheezy not jessie as the distribution version - I cannot help thinking that is an issue here considering the OP's assertion they are using Jessie - I'd follow that up with the package creators!

  • I just tried the command you suggested, but it got stuck at the same thing as before: Unpacking gitlab-ce (8.2.2+20151202180254-ce.0) over (8.2.2+20151202180254-ce.0) ... I'll gladly use aptitude if that helps me any further, but I have no experience with it neither would I know what to do with it to fix this. – Rien Heuver Dec 24 '15 at 20:23
  • I tried the bigger-hammer-move but encountered the following message: dpkg: error processing package gitlab-ce (--remove): package is in a very bad inconsistent state; you should reinstall it before attempting a removal Errors were encountered while processing: gitlab-ce So starting from scratch doesn't work out just yet. – Rien Heuver Dec 24 '15 at 22:03
  • 1
    There are other --force-XXXX options try dpkg --force-help to see what they are without making any changes. --force-remove-reinstreq might be the one... – SlySven Dec 24 '15 at 22:21
1

I was in the same situation, so I confirm SlySven --force-remove-reinstreq is correct.

However, the true solution to this problem is simply to wait. Apparently, there is a buffer problem when using some types of virtualization (or in your case, terrible hardware perf) and the unpacking will work "fast" for the first 100 MB, then slow down by 99%. Iotop and perf confirm the process is still going on, just very, very slowly. I also confirm this doesn't happen on x86 "metal" (without VMs). In my case, it took an hour, but eventually finished with success.

I am posting this mostly because it is the first hit on Google and this problem is not related to the RPi, but due to the very large size of the .deb.

0

Have you tried to re-run sudo apt-get install gitlab-ce again before the purge? This might allow you to properly install it before removing it again.

It doesn't hurt to check if your disk isn't full. You can check with by running the following command:

 df -lh
  • 1
    I tried re-running the install a variety of times already, but it hangs every time. I have 5.6 GB available according to df -lh, so that shouldn't make a difference either. – Rien Heuver Dec 24 '15 at 15:42
  • have you tried with apt-get --reinstall install gitlab-ce ? – Havnar Dec 28 '15 at 8:15
  • My installation (unpacking) took 3 hours on a Pi 3. Have you waited that long? – brainray Feb 26 '17 at 23:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.