blog.lobraun.de Lothar Braun

GitLab: The project you were looking for could not be found.

After setting up my first repository on my GitLab instance, I received the following error message when pushing to my first repo:

remote: GitLab: The project you were looking for could not be found.

Turned out that I had a symlink in the path of to my data repository:

/var/opt/gitlab/git-data --> /data/gitlib

GitLab cannot deal with this and will then show this error message. The correct way to change the data directory is to change the config in /etc/gitlab/gitlab.rb to

git_data_dirs({ "default" => { "path" => "<YOUR_DATA_PATH>", 'gitaly_address' => 'unix:/var/opt/gitlab/gitaly/gitaly.socket' } })

Afterwards, you should be able to push / pull to your repositories.

Enabling Serial Console

Serial console output can be generated for grub messsages, for the kernel boot process, and the access to the system. Different configuration changes need to be done in order to do that.

Grub boot messages

If you want to see boot messages through the console, you need to pass additional arguments to the kernel through kernel arguments. This can be done via the grub config. Simply add the following to your default arguments:

GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --speed=38400 --unit=0 --word=8 --parity=no --stop=1"

into your grub config (e.g. /etc/conf.d/grub on gentoo or /etc/default/grub on Debian)

Then regenerate your grub.cfg by running your update grub:

 grub-mkconfig -o /boot/grub/grub.cfg

or

update-grub

or

update-grub2

depending on the distro.

Kernel Boot Messages

If you want to see boot messages through the console, you need to pass additional arguments to the kernel through kernel arguments. This can be done via the grub config. Simply add the following to your default arguments:

  GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,38400n8"

System

Without systemd

For systems without systemd, you simply edit the /etc/inittab by adding a new getty process to the serial terminal:

s0:12345:respawn:/sbin/agetty -L 115200 ttyS0 vt100

If the file /etc/securetty exists, then add the following to the end of it

S0

This allows root to login through the serial console.

With systemd

While old Linux systems were configured using /etc/inittab most new systems now use systemd as their init system. Systemd does not use the old inittab, but uses systemctl to start a getty process on a the serial port. In order to start a getty only ones, you need to run

systemctl start serial-getty@ttyS0.service

In order to run it at boot time, you need enable by running:

systemctl enable serial-getty@ttyS0.service

CIFS

Most Linux distributions provide their pre-compiled kernels with most options enabled as kernel modules. When self-compiling the kernel, you sometimes miss modules because you did not care to enable all available modules. That can sometimes lead to problems, such as when mounting SMB shares:

# mount -t cifs //<myhost>/<myshare> /mnt/myshare
mount error: cifs filesystem not supported by the system
mount error(19): No such device
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

These problems can be overcome by providing and loading the CIFS kernel module under:

File Systems ---> 
    Network File Systems --->
       <M> CIFS support (advanced network filesystems, SMBFS successor)

Compile and install your kernel and kernel modules. The kernel module should be loaded when trying to mount a share. If it is not loaded automatically on mount, then load the module manually:

# modprobe cifs

Hibernate/Suspend with Nvidia Drivers on Gentoo

The proprietary Nvidia drivers from x11-drivers/nvidia-drivers contain the closed-sources drivers from Nvidia for Linux. On my laptop, the current version show problems when hibernating/suspending. Several people found that the resume operations do not properly bring up the X-sessions. The same problem occurs on my GTX 1060 laptop. None of the helpful tips found on the Internet would allow me to hibernate/resume when the drivers are loaded.

The only solution that worked for me, is to unload the drivers before going into hibernate and to load them after the resume operation is completed. If you configured your hibernate using this tutorial, and are using sys-power/pm-utils and sys-power/upower-pm-utils, then you can place the following script in /etc/pm/sleep.d/ to unload and load the drivers:

#!/bin/sh
#
# 01nvidia_drivers: unloads and loads nvidia drivers before and after suspend operations

function unload_if_loaded() {
    MODULE=$1
    if lsmod | grep "$MODULE" &>/dev/null; then
        rmmod $MODULE
    fi
}

case "$1" in
   hibernate|suspend)
       unload_if_loaded nvidia_drm
       unload_if_loaded nvidia_modeset
       unload_if_loaded nvidia
   ;;
   thaw|resume)
       modprobe nvidia_drm
   ;;
   *) exit $NA
   ;;
esac

You can place the script to /etc/pm/sleep.d/01nvidia_drivers and make sure it is executable.

chmod +x /etc/pm/sleep.d/01nvidia_drivers

Afterwards, you should be able to hibernate/resume properly.

Silent startup failure for MongoDB on Raspberry Pi (and other systems)

Yesterday I tried to install mongodb on my Raspberry Pi. Raspbian Jessie ships with a default mongo 2.4 package, so the installation should be pretty straightforward:

apt-get install mongodb

However, after the installation finished, the service did not start:

service mongodb start

did not result in a started mongod process. No log files in /var/log/mongodb were produced, indicating that the process stops before the logging is initialized. If the mongodb server is started manually, a very early crash can be observed:

sudo -u mongodb /usr/bin/mongod  --config /etc/mongodb.conf
Sun Mar 27 07:48:45.296 terminate() called, printing stack (if implemented for platform):
 0x664160 0x16d954 0x767ea9a0
 /usr/bin/mongod(_ZN5mongo15printStackTraceERSo+0x1c) [0x664160]
 /usr/bin/mongod(_ZN5mongo11myterminateEv+0x54) [0x16d954]
 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6(+0x4a9a0) [0x767ea9a0]
Sun Mar 27 07:48:45.299 Got signal: 6 (Aborted).
 
Sun Mar 27 07:48:45.302 Backtrace:
0x664160 0x16e370 0x765be180 0x765bcf70
 /usr/bin/mongod(_ZN5mongo15printStackTraceERSo+0x1c) [0x664160]
 /usr/bin/mongod(_ZN5mongo10abruptQuitEi+0x2a0) [0x16e370]
 /lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer_v2+0) [0x765be180]
 /lib/arm-linux-gnueabihf/libc.so.6(gsignal+0x38) [0x765bcf70]

Stracing the syscalls shows that the error is generated shortly after mongod tries to load locales:

munmap(0x76f24000, 4096)                = 0
open("/usr/lib/locale/en_GB.UTF-8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_GB.utf8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_GB/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.UTF-8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en.utf8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
gettimeofday({1459065376, 950211}, NULL) = 0
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f24000
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"..., 4096) = 118
_llseek(4, -6, [112], SEEK_CUR)         = 0
read(4, "\nUTC0\n", 4096)               = 6
close(4)                                = 0
munmap(0x76f24000, 4096)                = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f24000
write(1, "Sun Mar 27 07:56:16.950 ", 24Sun Mar 27 07:56:16.950 ) = 24
write(1, "terminate() called, printing sta"..., 65terminate() called, printing stack (if implemented for platform):) = 65
write(1, "\n", 1
)                       = 1
futex(0x7667e5d8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(1, "0x664160 0x16d954 0x7679a9a0 \n", 300x664160 0x16d954 0x7679a9a0
) = 30
write(1, " /usr/bin/mongod(_ZN5mongo15prin"..., 65 /usr/bin/mongod(_ZN5mongo15printStackTraceERSo+0x1c) [0x664160]
) = 65
write(1, " /usr/bin/mongod(_ZN5mongo11myte"..., 59 /usr/bin/mongod(_ZN5mongo11myterminateEv+0x54) [0x16d954]
) = 59
write(1, " /usr/lib/arm-linux-gnueabihf/li"..., 68 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6(+0x4a9a0) [0x7679a9a0]
) = 68

It turns out that I did not change the default locale on my installation (which was en_GB.UTF-8), and did not make sure a proper locale was generated for this setting.

To fix the error, first make sure you pick the right locale. This can be changed by running

dpkg-reconfigure locales

There, you can first pick the locales that should be generated:

Afterwards, you can pick the locale that should be used on the system:

dpkg-reconfigure will then generate the locales that are supported. The changes will be applied after the next reboot. Make sure they are actually used in your current session by running

export LANG=*<YOUR_LOCALE_SELECTION>*

Afterwards, mongodb should start just fine.

If you are not on a debian system, you can make sure that the proper locales are generated by editing

/etc/locale.gen

and uncommenting all locales that you need. Afterwards you need to generate

locale-gen

which will generate the locale files. Setting the LANG environment variable is something that is distribution specific. Check your manual on where you can find the proper place to configure the locale. On debian-based systems, you can find it in

/etc/default/locale

on Gentoo, check your

/etc/env.d/02locale
Older Posts