Upgrade Gitlab CE 8.14.3 to 9.1.10

ramilr 2020-08-03 09:23:50 UTC #1

Keywords: GitLab - Virtual Machines - How to - Upgrade
Description:
Hello,
I'm trying to upgrade our Gitlab CE 8.14.3 to 9.1.10 by following support's suggestion here:
https://community.bitnami.com/t/upgrade-bitnami-gitlab-ce-version/48641

I'm already in step 4 but could not startup the Gitlab Omnibus 9.1.10. I get this error:

ok: down: gitlab-workhorse: 0s, normally up
ok: down: logrotate: 0s, normally up
ok: down: nginx: 1s, normally up
ok: down: postgresql: 0s, normally up
ok: down: redis: 1s, normally up
ok: down: sidekiq: 0s, normally up
ok: down: unicorn: 0s, normally up
timeout: down: postgresql: 1s, normally up, want up
ok: run: redis: (pid 25298) 0s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1711s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1712s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1713s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1714s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1715s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1716s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1717s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1718s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1719s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1720s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1721s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1722s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1723s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1724s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1725s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1726s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1727s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1728s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1729s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1730s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1731s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1732s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1733s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1734s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1735s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1736s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1737s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1738s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1739s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1740s
Failed to start postgresql for migrations
dpkg: error processing package gitlab-ce (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.19-0ubuntu6.15) ...
Processing triggers for initramfs-tools (0.103ubuntu4.11) ...
update-initramfs: Generating /boot/initrd.img-3.13.0-105-generic
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for ca-certificates (20170717~14.04.2) ...
Updating certificates in /etc/ssl/certs... 17 added, 42 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.
Errors were encountered while processing:
 gitlab-ce
E: Sub-process /usr/bin/dpkg returned an error code (1)

I have already tried cleaning the package manager using these commands:

sudo apt-get clean
sudo dpkg --configure -a
sudo apt-get install -f
sudo apt-get autoremove

Also removing and rebuild the package list

sudo rm -rf /var/lib/apt/lists/*
sudo apt-get update
sudo apt-get clean

But still could not run postgresql.

Thanks!

ramilr 2020-08-03 09:29:28 UTC #2

Sorry the error message got messed up and don't know how to edit previous post. Error message here:

ok: down: unicorn: 0s, normally up
timeout: down: postgresql: 1s, normally up, want up
ok: run: redis: (pid 25298) 0s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1711s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1712s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1713s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1714s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1715s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1716s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1717s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1718s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1719s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1720s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1721s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1722s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1723s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1724s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1725s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1726s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1727s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1728s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1729s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1730s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1731s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1732s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1733s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1734s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1735s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1736s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1737s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1738s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1739s
down: postgresql: 0s, normally up, want up; run: log: (pid 17140) 1740s
Failed to start postgresql for migrations
dpkg: error processing package gitlab-ce (--configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.19-0ubuntu6.15) ...
Processing triggers for initramfs-tools (0.103ubuntu4.11) ...
update-initramfs: Generating /boot/initrd.img-3.13.0-105-generic
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for ca-certificates (20170717~14.04.2) ...
Updating certificates in /etc/ssl/certs... 17 added, 42 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.
Errors were encountered while processing:
gitlab-ce
E: Sub-process /usr/bin/dpkg returned an error code (1)

gongomgra 2020-08-04 09:08:06 UTC #3

Hi @ramilr,

According to the error message you sent us, it looks like there is an issue starting PostgreSQL. Can you run the next command to check the error messages in the logs?

sudo cat /var/log/gitlab/postgresql/current

ramilr 2020-08-10 06:44:01 UTC #4

Hello @gongomgra,

Here are the logs:

2020-08-10_06:31:47.54587 FATAL: could not create shared memory segment: Invalid argument
2020-08-10_06:31:47.54588 DETAIL: Failed system call was shmget(key=5432001, size=2166603776, 03600).
2020-08-10_06:31:47.54588 HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2166603776 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2020-08-10_06:31:47.54589 If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
2020-08-10_06:31:47.54589 The PostgreSQL documentation contains more information about shared memory configuration.
2020-08-10_06:31:48.55576 FATAL: could not create shared memory segment: Invalid argument
2020-08-10_06:31:48.55577 DETAIL: Failed system call was shmget(key=5432001, size=2166603776, 03600).
2020-08-10_06:31:48.55577 HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2166603776 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2020-08-10_06:31:48.55577 If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
2020-08-10_06:31:48.55577 The PostgreSQL documentation contains more information about shared memory configuration.
2020-08-10_06:31:49.56602 FATAL: could not create shared memory segment: Invalid argument
2020-08-10_06:31:49.56603 DETAIL: Failed system call was shmget(key=5432001, size=2166603776, 03600).
2020-08-10_06:31:49.56604 HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2166603776 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2020-08-10_06:31:49.56604 If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
2020-08-10_06:31:49.56604 The PostgreSQL documentation contains more information about shared memory configuration.
2020-08-10_06:31:50.57608 FATAL: could not create shared memory segment: Invalid argument
2020-08-10_06:31:50.57609 DETAIL: Failed system call was shmget(key=5432001, size=2166603776, 03600).
2020-08-10_06:31:50.57609 HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2166603776 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2020-08-10_06:31:50.57610 If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
2020-08-10_06:31:50.57610 The PostgreSQL documentation contains more information about shared memory configuration.

By the way, can you confirm the steps I am doing for this upgrade if this is how it is done?

Backup Bitnami Gitlab CE 8.14.3 Instance
Install Omnibus Gitlab CE 8.14.3
Restore Bitnami Gitlab CE 8.14.3 backup to Omnibus Gitlab CE 8.14.3
Upgrade Omnibus Gitlab CE 8.14.3 to 9.1.10
Delete Bitnami Gitlab CE 8.14.3 and use Omnibus Gitlab CE 9.1.10 moving forward?

Thanks!

gongomgra 2020-08-10 08:41:15 UTC #5

Hi @ramilr,

According to the error message you are getting, is it possible that you are using an small instance to run GitLab? Can you execute our support tool on the machine where the stack is running by following the steps described in the guide below?

Please note that you need to paste the code ID that is shown at the end.

Regarding the upgrade steps, I'm afraid we don't have any guide for updating GitLab. You will need to use the official steps linked below

https://docs.gitlab.com/omnibus/update/README.html#updating-gitlab-via-omnibus-gitlab

system 2020-08-24 08:41:18 UTC #6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

Bitnami provides free all-in-one installers, virtual machines and cloud images for popular open source applications. Get them now!