Q_WEBENGINECORE_EXPORT QWebEngineFindTextResult has initializer but incomplete type

In addition to one of the cstdlib fix here – Gentoo building qtgui error – g++-v8/cstdlib:75:15: fatal error: stdlib.h: No such file or directory we were unable to to build “dev-qt/qtwebengine-5.14.1“.

It appeared the problem was a wrong order of header includes just like the cstdlib and if you have used the fix with QMAKE_CFLAGS_ISYSTEM in /usr/lib64/qt5/mkspecs/common/gcc-base.conf you would encounter this error. Revert back the original value in /usr/lib64/qt5/mkspecs/common/gcc-base.conf (and probably it is a good idea to rebuild the entire system with “emerge -e”):

QMAKE_CFLAGS_ISYSTEM = -isystem

and continue the build from the point you’ve stopped with something like:

ebuild /usr/portage/dev-qt/qtwebengine/qtwebengine-5.14.1.ebuild compile
ebuild /usr/portage/dev-qt/qtwebengine/qtwebengine-5.14.1.ebuild install
ebuild /usr/portage/dev-qt/qtwebengine/qtwebengine-5.14.1.ebuild qmerge
rm -Rf /var/tmp/portage/dev-qt/qtwebengine-5.14.1/

Keep on reading!

env python3.5: no such file or directory

The dependency conflicts may require a lot of time to resolve. On the contrary, uninstalling old software is easy, but it might lead to multiple broken programs and strange errors. Here is one of them, after removing the old python 3.4 and 3.5 (or whatever version it prints in your case) under Gentoo despite the rebuilding all dependencies as required by the emerge command for the new python 3.6 an error occurred trying to emerge the “app-misc/geoclue-2.5.3-r2

[20/75] /usr/lib/python-exec/python3.6/meson --internal exe --unpickle /var/tmp/portage/app-misc/geoclue-2.5.3-r2/work/geoclue-2.5.3-build/meson-private/meson_exe_glib-mkenums_af4feac41c42ec7289410f8b20070c0528a3a7c0.dat
FAILED: public-api/gclue-enum-types.c 
/usr/lib/python-exec/python3.6/meson --internal exe --unpickle /var/tmp/portage/app-misc/geoclue-2.5.3-r2/work/geoclue-2.5.3-build/meson-private/meson_exe_glib-mkenums_af4feac41c42ec7289410f8b20070c0528a3a7c0.dat
/usr/bin/env: âpython3.5â: No such file or directory
ninja: build stopped: subcommand failed.
 * ERROR: app-misc/geoclue-2.5.3-r2::gentoo failed (compile phase):
 *   ninja -v -j15 -l14 -C /var/tmp/portage/app-misc/geoclue-2.5.3-r2/work/geoclue-2.5.3-build failed
 * 
 * Call stack:
 *     ebuild.sh, line  125:  Called src_compile
 *   environment, line 2847:  Called meson_src_compile
 *   environment, line 1904:  Called eninja '-C' '/var/tmp/portage/app-misc/geoclue-2.5.3-r2/work/geoclue-2.5.3-build'
 *   environment, line 1274:  Called die
 * The specific snippet of code:
 *       "$@" || die "${nonfatal_args[@]}" "${*} failed"
 * 

Despite the lines starting with “/usr/lib/python-exec/python3.6/meson”, there is an error for missing “python 3.5“.

Here is another example, just trying to execute the distcc-config and it immediately throws the error for missing “python 3.5“.

root@srv ~ # distcc-config 
/usr/bin/env: ‘python3.5’: No such file or directory

The python script distcc-config starts with:

root@srv ~ $ head /usr/bin/distcc-config
#!/usr/bin/env python3.5
# Copyright 1999-2018 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

import os, re, signal, subprocess, sys

options=[
        '--get-hosts',
        '--set-hosts',
        '--get-verbose',

Apparently, multiple programs use this technic to explicitly put a specific version of python in the header of the python script to be used. Thus grantees the version in the header will be used even you change the system or user-preferred Python interpreter.

But uninstalling this python version all these programs will stop working till you rebuild them with emerge.
Keep on reading!

gentoo emerge resume – Invalid resume list and clean the list

Under Gentoo and emerge it will eventually end up using “–resume” paired with “–skipfirst” emerge command, which should resume last list of packages to build without the first one. Each execution of emerge command should reset the list but apparently it might not be the case (in fact two lists are kept – resume and resume_backup, read below).
The command just reads a list of packages and emerges them – it’s fast and it does not go through the whole process of dependancy check! But sometimes the list could be old or get corrupted or it just throws errors for “Invalid resume list“:

dekstop ~ # emerge --resume --skipfirst

These are the packages that would be merged, in order:

Calculating dependencies... done!
 * Invalid resume list:
 * 
 *   ('ebuild', '/', 'kde-frameworks/kpty-5.66.0', 'merge')
 *   ('ebuild', '/', 'kde-plasma/libkscreen-5.17.5', 'merge')
 *   ('ebuild', '/', 'kde-apps/kmbox-19.12.1', 'merge')
 *   ('ebuild', '/', 'kde-frameworks/kdesignerplugin-5.66.0', 'merge')
 *   ('ebuild', '/', 'kde-plasma/kwayland-integration-5.17.5', 'merge')
 *   ('ebuild', '/', 'kde-plasma/xembed-sni-proxy-5.17.5', 'merge')
 *   ('ebuild', '/', 'net-libs/accounts-qml-0.7-r1', 'merge')
 *   ('ebuild', '/', 'kde-apps/akonadi-notes-19.12.1', 'merge')
....
....
 * One or more packages are either masked or have missing dependencies:
 * 
 *   dev-lang/python:3.4[xml(+)] pulled in by:
 *     (dev-python/setuptools-40.6.2:0/0::gentoo, installed)
 * 
 *   dev-lang/python:3.5[xml(+)] pulled in by:
 *     (dev-python/setuptools-40.6.2:0/0::gentoo, installed)
 * 
 *   dev-lang/python:3.4 pulled in by:
 *     (dev-python/certifi-2018.8.24:0/0::gentoo, installed)
 * 
 *   dev-lang/python:3.5 pulled in by:
 *     (dev-python/certifi-2018.8.24:0/0::gentoo, installed)
 * 
 *   dev-libs/openssl:0/0= pulled in by:
 *     (dev-lang/python-2.7.17-r1:2.7/2.7::gentoo, installed)
 * 
 *   dev-lang/python:3.5 pulled in by:
 *     (dev-util/glib-utils-2.56.2:0/0::gentoo, installed)
 * 
 *   dev-lang/python:3.4 pulled in by:
 *     (sys-apps/file-5.35:0/0::gentoo, installed)
 * 
 *   dev-lang/python:3.5 pulled in by:
 *     (sys-apps/file-5.35:0/0::gentoo, installed)
 * 
 *   >=dev-libs/icu-58.1:0/60.2= pulled in by:
 *     (dev-lang/spidermonkey-52.9.1_pre1:52/52::gentoo, installed)
....
....
 *   dev-lang/python:3.4 pulled in by:
 *     (virtual/python-enum34-1:0/0::gentoo, installed)
 * 
 *   dev-lang/python:3.5 pulled in by:
 *     (virtual/python-enum34-1:0/0::gentoo, installed)
 * 
 *   dev-libs/openssl:0/0= pulled in by:
 *     (dev-lang/python-3.7.6:3.7/3.7m::gentoo, installed)
 * 
 * The resume list contains packages that are either masked or have
 * unsatisfied dependencies. Please restart/continue the operation
 * manually, or use --skipfirst to skip the first package in the list and
 * any other packages that may be masked or have missing dependencies.

Not all packages are included above, but it is clear that the list includes packages not only from the last emerge command. The list includes multiple old packages and dependencies about python:3.4, python:3.5, openssl:0/0.
The list is located in the binary file: /var/cache/edb/mtimedb and to clean the list you should execute:

desktop ~ # emaint --fix cleanresume
Emaint: fix cleanresume    100% [============================================>]

It is safe to the directory, too:

rm -Rf /var/cache/edb/

emaint is part of the sys-apps/portage package, so the program should always be available in the system.

*Bonus 1 – old packages

There is one more problem in the above example! In fact, you may clear the resume list with emaint or remove the whole directory “/var/cache/edb”, but still to receive such errors let’s say resuming log lists like KDE, gnome, qt packages (packages with many dependencies).

This problem persists not only with “–resume”, but also with “–keep-going” option!

When using “–keep-going” option you’ll get the same errors after the line “One or more packages are either masked or have missing dependencies”. So it is not an option, which may replace the “–resume” option.

Even all dependencies were resolved when the emerge list was generated when resuming a list of packages may throw errors for packages, which pull old packages because they had not been rebuilt against the updated of some of their dependencies. For example, simple enough from the above emerge resume command:
Some packages of our KDE resume list depends on the “dev-python/setuptools”, which has not been rebuilt against the new python (or after a removed old version python 3.4 and 3.5 or even another [old] package depends on the old python 3.5 and dev-python/setuptools, which has not been rebuilt after the python 3.4/3.5 removal!) and now this is a problem to resume the emerge list.

The solution is to take all those packages (after the line “One or more packages are either masked or have missing dependencies”) and rebuild or remove them.

Keep on reading!

meson.build – ERROR: Dependency “x11” not found, tried pkgconfig and cmake

Another day and another major update exposed an error of missing the “x11” library. Apparently, the pkg-config got corrupted for X11 library. Most of the time the error is self-explanatory, but sometimes it is too generic like:

Run-time dependency x11 found: NO (tried pkgconfig and cmake)

meson.build:412:2: ERROR: Dependency "x11" not found, tried pkgconfig and cmake

The name “x11” is a part of multiple libraries:

srv ~ # pkg-config --list-all |grep x11

gdkglext-1.0                               GdkGLExt - OpenGL Extension to GDK (x11 target)
gdk-2.0                                    GDK - GTK+ Drawing Kit (x11 target)
gtk+-2.0                                   GTK+ - GTK+ Graphical UI Library (x11 target)
gdkglext-x11-1.0                           GdkGLExt - OpenGL Extension to GDK (x11 target)
x11-xcb                                    X11 XCB - X Library XCB interface
gdk-x11-3.0                                GDK - GTK+ Drawing Kit
gdk-x11-2.0                                GDK - GTK+ Drawing Kit (x11 target)
gtkglext-1.0                               GtkGLExt - OpenGL Extension to GTK+ (x11 target)
x11                                        X11 - X Library
xkbcommon-x11                              xkbcommon-x11 - XKB API common to servers and clients - X11 support
scim-x11utils                              scim-x11utils - X11 Utilities for Smart Common Input Method platform
clutter-x11-1.0                            Clutter - Clutter Core Library
gtk+-x11-3.0                               GTK+ - GTK+ Graphical UI Library
libva-x11                                  libva-x11 - Userspace Video Acceleration (VA) x11 interface
gtkglext-x11-1.0                           GtkGLExt - OpenGL Extension to GTK+ (x11 target)
gtk+-x11-2.0                               GTK+ - GTK+ Graphical UI Library (x11 target)

The above example is of working x11 library pkg-config. In our broken system the 10th line was missing.
Keep on reading!

libselinux – undefined reference to pcre_version

Emerging the “sys-libs/libselinux-2.9-r1” failed with this link errors of undefined references

/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_version':
regex.c:(.text+0x30): undefined reference to `pcre_version'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_writef':
regex.c:(.text+0x95): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0xf6): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_data_free':
regex.c:(.text+0x1eb): undefined reference to `pcre_free'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0x200): undefined reference to `pcre_free_study'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_prepare_data':
regex.c:(.text+0x26d): undefined reference to `pcre_compile'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0x28f): undefined reference to `pcre_study'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_load_mmap':
regex.c:(.text+0x385): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0x3ed): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_match':
regex.c:(.text+0x494): undefined reference to `pcre_exec'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_cmp':
regex.c:(.text+0x502): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0x51a): undefined reference to `pcre_fullinfo'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:148: libselinux.so.1] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9-abi_x86_32.x86/src'
make: *** [Makefile:44: all] Error 1
 * ERROR: sys-libs/libselinux-2.9-r1::gentoo failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info '=sys-libs/libselinux-2.9-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-libs/libselinux-2.9-r1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9-abi_x86_32.x86'
 * S: '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9'

>>> Failed to emerge sys-libs/libselinux-2.9-r1, Log file:

>>>  '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/build.log'

 * Messages for package sys-libs/libselinux-2.9-r1:

 * ERROR: sys-libs/libselinux-2.9-r1::gentoo failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info '=sys-libs/libselinux-2.9-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-libs/libselinux-2.9-r1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9-abi_x86_32.x86'
 * S: '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9'

The solution was to rebuild the dev-libs/libpcre and dev-libs/libpcre2 libraries.

emerge -va dev-libs/libpcre dev-libs/libpcre2

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U  ] dev-libs/libpcre-8.43:3::gentoo [8.42:3::gentoo] USE="bzip2 cxx jit pcre16 readline recursion-limit (split-usr%*) (static-libs) (unicode) zlib -libedit -pcre32" ABI_X86="32 (64) (-x32)" 1540 KiB
[ebuild     U  ] dev-libs/libpcre2-10.34::gentoo [10.32::gentoo] USE="bzip2 jit pcre16 pcre32* readline recursion-limit (split-usr%*) unicode zlib -libedit -static-libs" ABI_X86="32 (64) (-x32)" 1676 KiB

Total: 2 packages (2 upgrades), Size of downloads: 3216 KiB

if you encounter the error above even you are not using Gentoo probably the problem is your libpcre/libpcre2 library and try to rebuild it or include the proper path to the library and its headers.

aplty – unable to find control.tar.gz part in package – change deb package compression from xz to gzip

We upgraded to a new version of Ubuntu and our CI (continuous integration) scripts began to throw errors when uploading packages to out aptly repository:

"Report":{"Warnings":["Unable to read file /srv/aptly/.aptly/upload/mysoft/mysoft-6.15-pk19.deb: unable to find control.tar.gz part in package /srv/aptly/.aptly/upload/mysoft/mysoft-6.15-pk19.deb"],"Added":[],"Removed":[]}}

But if the same command:

dpkg-deb --build $PKGNAME

is executed on our older Ubuntu 16 everyhting is perfect and no error when uploading the package in the repository.

It turns out the new version of dpkg 1.19.0 the dpkg-deb will compress the deb file with XZ by default. Before version 1.19 the default compression is gzip.

You may upgrade your aptly installation to 1.20 and above or just fix your script to use “-Zgzip” with dpkg-deb

dpkg-deb -Zgzip --build $PKGNAME

This command will force the dpkg-deb to use gzip to compress the debian package.

Change the compression of existing deb package

Thanks to the aptly bug report – https://github.com/aptly-dev/aptly/issues/655 (hopes this link stays forever) you may have a workarround to decompress and comrpess an existing package with antoher algorythm

dpkg-deb -R package.deb tmp
rm package.deb
fakeroot dpkg-deb -Zgzip -b tmp package.deb
rm -rf tmp

docker mysql – Fatal error: Please read “Security” section of the manual to find out how to run mysqld as root!

Pulling the official MySQL image from the docker registry https://hub.docker.com/r/mysql/mysql-server to start a MySQL instance with your configuration file (and MySQL binary files). Adding the “–volume” option for the configuration directory (or file) and MySQL binary files and you stumble on the error:

2019-12-03 01:13:38 0 [Note] mysqld (mysqld 5.6.46-log) starting as process 67 ...
2019-12-03 01:13:38 67 [ERROR] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!

2019-12-03 01:13:38 67 [ERROR] Aborting

2019-12-03 01:13:38 67 [Note] Binlog end
2019-12-03 01:13:38 67 [Note] mysqld: Shutdown complete

Apparently, the server option is not configured to run properly as a root user and you do not want to run it, but why it keeps insisting to run it as root?

Because of the entry point script will execute only “mysqld” as a command, which expects to have a “user” option in the “[mysqld]” section of your my.cnf configuration file!

Do not miss the user option in my.cnf! This is how the MySQL server will be using the “mysql” username not the root!

user=mysql

Typical error, because it is not so common to include the username in my.cnf configuration file of the mysqld process to run as. If you use the official docker MySQL image to create your configuration file you would not encounter the above error, but if you use an existing (probably old and from non virtualized environment) my.cnf make sure to include the username, which should be used to run the mysqld process as.

Here is our command to execute the container:

docker run --privileged -d -v /mnt/storage/docker/mysql-slave/files:/var/lib/mysql -v /mnt/storage/docker/mysql-slave/etc/my.cnf:/etc/my.cnf mysql/mysql-server:5.6

Gentoo – UnicodeEncodeError: ‘ascii’ codec can’t encode character ‘\xc4’ in position 83: ordinal not in range(128)

Recently emerging package =dev-lang/go-1.13.4 under Gentoo failed on one of our virtual servers with:

--- /usr/lib/go/test/fixedbugs/issue27836.dir/
Traceback (most recent call last):
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/_MergeProcess.py", line 234, in _spawn
    prev_mtimes=self.prev_mtimes, counter=counter)
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 1788, in wrapper
    return f(self, *args, **kwargs)
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 5385, in merge
    counter=counter)
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 4548, in treewalk
    rval = self._merge_contents(srcroot, destroot, cfgfiledict)
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 4828, in _merge_contents
    self.settings["EPREFIX"].lstrip(os.sep), cfgfiledict, mymtime):
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 5225, in mergeme
    encoding=_encodings['merge'])
  File "/usr/lib64/python3.6/site-packages/portage/util/movefile.py", line 256, in movefile
    selinux.rename(src, dest)
  File "/usr/lib64/python3.6/site-packages/portage/__init__.py", line 246, in __call__
    rval = self._func(*wrapped_args, **wrapped_kwargs)
  File "/usr/lib64/python3.6/site-packages/portage/_selinux.py", line 71, in rename
    os.rename(src, dest)
UnicodeEncodeError: 'ascii' codec can't encode character '\xc4' in position 83: ordinal not in range(128)

>>> Failed to install dev-lang/go-1.13.4, Log file:

>>>  '/var/tmp/portage/dev-lang/go-1.13.4/temp/build.log'

The above log shows that the emerge fails in the installation phase when moving the files to the proper path in the system. The problem there is a non-ASCII character in the file name or path, but the environment is set to use ASCII as language.

The solution is to check if the environment LANG is set and what it contains. In this case, we should set the LANG environment to utf8.

export LANG=en_US.UTF-8

Most of the cases this kind of error could occur with virtual servers, docker (or the other kind of containers like lxc, podman and so on) containers and chroot jails or screens with changed user with su or sudo! In our case, the LANG just got missed because of a switch user procedure in a container and the emerge failed with the above error. When the LANG is missing probably the default value is “C”. In fact, check not only LANG but also the “LC_ALL” environment variable (it may have different value, which is wrong!), which also should be “en_US.UTF-8”:

export LC_ALL=en_US.UTF-8

Or try removing it at all with

unset LC_ALL

Keep on reading!

Build docker image with custom Dockerfile name – docker build requires exactly 1 argument

Docker uses the Dockerfile to build docker images, but what if you want to change the name and (or) the path of this file?
By default “docker build” command uses a file named Dockerfile on the same directory you execute the “docker build“. There is an option to change the path and name of this special file:

  -f, --file string             Name of the Dockerfile (Default is 'PATH/Dockerfile')

And the “-f” may include path and file name but it is mandatory to specify the path at the end “docker build” usually the current directory (context by the docker terminology) by adding “.” (the dot at the end of the command)

So if you want to build with a docker file mydockerfile in the current directory you must execute:

docker build -f mydockerfile .

If your file is in a sub-directory execute:

docker build -f subdirectory/mydockerfile .

The command will create a docker image in your local repository. Here is the output of the first command:

root@srv:~/docker# docker build -f mydockerfile .
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM ubuntu:bionic-20191029
bionic-20191029: Pulling from library/ubuntu
7ddbc47eeb70: Pull complete 
c1bbdc448b72: Pull complete 
8c3b70e39044: Pull complete 
45d437916d57: Pull complete 
Digest: sha256:6e9f67fa63b0323e9a1e587fd71c561ba48a034504fb804fd26fd8800039835d
Status: Downloaded newer image for ubuntu:bionic-20191029
 ---> 775349758637
Step 2/3 : MAINTAINER test@example.com
 ---> Running in 5fa42bca749c
Removing intermediate container 5fa42bca749c
 ---> 0a1ffa1728f4
Step 3/3 : RUN apt-get update && apt-get upgrade -y && apt-get install -y git wget
 ---> Running in 2e35040f247c
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
Get:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
.....
.....
Processing triggers for ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Removing intermediate container 2e35040f247c
 ---> 2382809739a4
Successfully built 2382809739a4

Here is the image:

REPOSITORY                            TAG                 IMAGE ID            CREATED              SIZE
root@srv:~# docker images
<none>                                <none>              2382809739a4        About a minute ago   186MB

Build command with custom name and registry URL and TAG

root@srv:~# docker build -t gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1 -f mydockerfile .
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM ubuntu:bionic-20191029
 ---> 775349758637
Step 2/3 : MAINTAINER test@example.com
 ---> Using cache
 ---> 0a1ffa1728f4
Step 3/3 : RUN apt-get update && apt-get upgrade -y && apt-get install -y git wget
 ---> Using cache
 ---> 2382809739a4
Successfully built 2382809739a4
Successfully tagged gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1
root@srv:~# docker push gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1
The push refers to repository [gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base]
7cebba4bf6c3: Pushed 
e0b3afb09dc3: Pushed 
6c01b5a53aac: Pushed 
2c6ac8e5063e: Pushed 
cc967c529ced: Pushed 
v0.1: digest: sha256:acf42078bf46e320c402f09c6417a3dae8992ab4f4f685265486063daf30cb13 size: 1364

the registry URL is “gitlab.ahelpme.com:4567” and the project path is “/root/ubuntu-project/” and the name of the image is “ubuntu18-manual-base” with tag “v0.1“. The build command uses the cache from our first build example here (because the docker file is the same).

Typical errors with “-f”

Two errors you may encounter when trying the “-f” to change the name of the default Dockerfile name:

$ docker build -t gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1 -f mydockerfile subdirectory/
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /builds/dev/docker-containers/mydockerfile: no such file or directory

$ docker build -t gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1 -f subdirectory/mydockerfile
"docker build" requires exactly 1 argument.
See 'docker build --help'.

Usage:  docker build [OPTIONS] PATH | URL | -

First, you might think the -f would take the path and file name and this should be enough, but the errors above appears!

Our example Dockerfile

This is our simple example docker file:

FROM ubuntu:bionic-20191029
MAINTAINER test@example.com

RUN apt-get update && apt-get upgrade -y && apt-get install -y git wget

We are using the official docker image from Ubuntu. Always use official docker images!

bonding – write error – device or resource busy – operation not permitted

Recently, there was a little bit of confusion when following the article about activating network bonding without ifenslave – How to enable Linux bonding without ifenslave. At first, there were couple of errors:

livecd ~ # echo balance-alb > /sys/class/net/bond0/bonding/mode
-bash: echo: write error: Device or resource busy
livecd ~ # echo "+enp129s0f0" > /sys/class/net/bond0/bonding/slaves
-bash: echo: write error: Operation not permitted

Or similar error when changing the bonding mode:

livecd ~ # echo 4 > /sys/class/net/bond0/bonding/mode
-bash: echo: write error: Directory not empty
livecd ~ # echo 802.3ad > /sys/class/net/bond0/bonding/mode
-bash: echo: write error: Directory not empty

The server just booted in rescue live cd and there is no active network configuration:

SCREENSHOT 1) Apparently, the /sys/class/net/bond0/bonding/mode and /sys/class/net/bond0/bonding/slaves are in read only state.

No writes means no new configuration could be installed and the bonding cannot be configured (reconfigured).

main menu
device or resource busy – operation not permitted

Bonding mode could be changed only when the bonding device is in DOWN state.

Network interfaces could be added to the boding device only if they were in DOWN state, too.

In addition, changing bonding mode could only happen if there were no network interfaces added to the bonding interface.

Keep on reading!