error | Any IT here? Help Me!

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!

Cobbler web – AppRegistryNotReady – Apps aren’t loaded yet

If you happen to use Cobbler 2.6 (even the last release of 2.6 – 2.6.11) you may encounter the following error when you try loading the Cobbler web interface:

AppRegistryNotReady at /distro/list

Apps aren't loaded yet.

Request Method: 	GET
Request URL: 	https://192.168.0.25/cobbler_web/distro/list
Django Version: 	1.8.7
Exception Type: 	AppRegistryNotReady
Exception Value: 	

Apps aren't loaded yet.

Exception Location: 	/usr/lib/python2.7/dist-packages/django/apps/registry.py in check_apps_ready, line 124
Python Executable: 	/usr/bin/python
Python Version: 	2.7.12
Python Path: 	

['/usr/local/share/cobbler/web/cobbler_web',
 '/usr/local/share/cobbler/web',
 '/usr/lib/python2.7',
 '/usr/lib/python2.7/plat-x86_64-linux-gnu',
 '/usr/lib/python2.7/lib-tk',
 '/usr/lib/python2.7/lib-old',
 '/usr/lib/python2.7/lib-dynload',
 '/usr/local/lib/python2.7/dist-packages',
 '/usr/lib/python2.7/dist-packages']

Server time: 	Sun, 13 Oct 2019 21:24:30 -0400

The Cobbler web does not work properly. The Django application is not started properly.

It is a known error and it is easily fixable by editing the Cobbler web source file “/usr/local/share/cobbler/web/cobbler.wsgi” (or /usr/share/cobbler/web/cobbler.wsgi) and replacing the two lines:

    import django.core.handlers.wsgi
    _application = django.core.handlers.wsgi.WSGIHandler()

With the code:

    from django.core.wsgi import get_wsgi_application
    _application = get_wsgi_application()

Note the “_application” variable starts with underline.

In fact, Cobbler 2.4 has the same issue, but the variable is “application” without underline in the start and there is no return line at the end of the file (in 2.6 there is a return clause and you must leave it there!)

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

replace with

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

It is highly unlikely to use Cobbler 2.4, but still, if you need it and you come across this page this is the fix for the Cobbler web and be careful with the variable name _application – application for the various Cobbler versions.

nano – Error opening terminal: unknown under chroot or (docker) container

A quick tip for GNU Nano – the text editor. Ever receiving the terminal error when using nano?

[root@srv ~]# nano                                                        
Error opening terminal: unknown.
[root@srv ~]#

Under chroot or container (like docker) environment try exporting the TERM environment:

export TERM=linux

And then execute nano the chances are you will enter nano normally and do your work (faster than vim 🙂 )?

You may use it without exporting to your shell, but just the for the nano:

TERM=linux nano

cobbler import – stderr file: No such file or directory

What a miss here in our docker Cobbler instance! When trying to import a new distro in Cobbler the import finished with failed task and multiple errors of:

running: /usr/bin/file /var/www/cobbler/ks_mirror/ubuntu-18.04.3-server-amd64-x86_64/dists/bionic/Release.gpg
received on stdout: 
received on stderr: /bin/sh: /usr/bin/file: No such file or directory

running: /usr/bin/file /var/www/cobbler/ks_mirror/ubuntu-18.04.3-server-amd64-x86_64/dists/bionic/main/binary-i386/Release
received on stdout: 
received on stderr: /bin/sh: /usr/bin/file: No such file or directory

The “file”? Apparently, the Linux file command is missing and it is just possible because it is a docker container with the minimum installation of packages and dependencies.

Without the “file” command import will fail with “No signature matched” even you have synced with the latest signature just before the execution of the import command.

Install the package “file” in your server.
CentOS 7/Fedora:

yum install -y file

Ubuntu

apt install -y file

Keep on reading!

cobbler – The SECRET_KEY setting must not be empty.

When installing cobbler (in our case 2.6.11, but it might happen with other versions) from source, because they do not offer binary packages anymore, the web showed this error:

[Tue Oct 08 07:41:00.680646 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] mod_wsgi (pid=8770): Exception occurred processing WSGI script '/usr/local/share/cobbler/web/cobbler.wsgi'.
.....
.....
[Tue Oct 08 07:41:00.687544 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] ImproperlyConfigured: The SECRET_KEY setting must not be empty.

The solution is simply to add value to the variable SECRET_KEY in file “/usr/local/share/cobbler/web/settings.py” (this file might be in /usr/share/cobbler/web/settings.py)

root@srv:~# grep -n SECRET_KEY /usr/local/share/cobbler/web/settings.py
39:SECRET_KEY = ''

The 39th line put a randomly generated text. You may use openssl to generate the random text like:

root@srv:~# openssl rand -base64 32
NVb09/5TWmCcqfDBLsvyCppza9lJ5Eyb0HWW4HTlSfo=

Edit the cobbler web setting file and put the string there:

root@srv:~# grep SECRET_KEY /usr/local/share/cobbler/web/settings.py
SECRET_KEY = 'NVb09/5TWmCcqfDBLsvyCppza9lJ5Eyb0HWW4HTlSfo='

The whole output error in the apache logs

The error could be seen in Cobbler web installed in Ubuntu 16 when installing cobbler 2.6.11.

[Tue Oct 08 07:41:00.680646 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] mod_wsgi (pid=8770): Exception occurred processing WSGI script '/usr/local/share/cobbler/web/cobbler.wsgi'.
[Tue Oct 08 07:41:00.680724 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] Traceback (most recent call last):
[Tue Oct 08 07:41:00.680764 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/local/share/cobbler/web/cobbler.wsgi", line 27, in application
[Tue Oct 08 07:41:00.681890 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     return _application(environ, start_response)
[Tue Oct 08 07:41:00.682025 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 170, in __call__
[Tue Oct 08 07:41:00.683222 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     self.load_middleware()
[Tue Oct 08 07:41:00.683380 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 49, in load_middleware
[Tue Oct 08 07:41:00.685006 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     for middleware_path in settings.MIDDLEWARE_CLASSES:
[Tue Oct 08 07:41:00.685168 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in __getattr__
[Tue Oct 08 07:41:00.686783 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     self._setup(name)
[Tue Oct 08 07:41:00.687047 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in _setup
[Tue Oct 08 07:41:00.687111 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     self._wrapped = Settings(settings_module)
[Tue Oct 08 07:41:00.687133 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 113, in __init__
[Tue Oct 08 07:41:00.687472 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")
[Tue Oct 08 07:41:00.687544 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] ImproperlyConfigured: The SECRET_KEY setting must not be empty.

emerge – ERROR: 17.1 migration has not been performed – upgrade from 13 to 17.1

When upgrading to 17.1 profile you need to perform additional steps to get to a healthy Gentoo portage system using profile 17.1.
Here what we stumbled when we tried to upgrade from 13 to 17.1:

>>> Emerging (1 of 3) dev-libs/elfutils-0.177::gentoo
 * Fetching files in the background.
 * To view fetch progress, run in another terminal:
 * tail -f /var/log/emerge-fetch.log
 * elfutils-0.177.tar.bz2 BLAKE2B SHA512 size ;-) ...                                                                                                                [ ok ]
 * Please follow the instructions in the news item:
 * 2019-06-05-amd64-17-1-profiles-are-now-stable
 * or choose the 17.0 profile.
 * ERROR: dev-libs/elfutils-0.177::gentoo failed (setup phase):
 *   ERROR: 17.1 migration has not been performed!!
 * 
 * Call stack:
 *        ebuild.sh, line 591:  Called __source_all_bashrcs
 *        ebuild.sh, line 410:  Called __try_source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc'
 *        ebuild.sh, line 467:  Called __qa_source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc'
 *        ebuild.sh, line 112:  Called source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc'
 *   profile.bashrc, line   6:  Called die
 * The specific snippet of code:
 *              die "ERROR: 17.1 migration has not been performed!!"
 * 
 * If you need support, post the output of `emerge --info '=dev-libs/elfutils-0.177::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/elfutils-0.177::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-libs/elfutils-0.177/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-libs/elfutils-0.177/temp/die.env'.
 * Working directory: '/var/tmp/portage/dev-libs/elfutils-0.177/homedir'
 * S: '/var/tmp/portage/dev-libs/elfutils-0.177/work/elfutils-0.177'

As you can see there is news, which consists of 12 steps to perform a successful upgrade to profile 17.1.
You can read the news with (the news output is included at the end of this article, just for completeness):

eselect news read 28

Specific note for our upgrade – in fact, our Gentoo installation was a chroot and it had not been updated for three years. The profile was 13.0 and portage supported only EAPI 5, which is a real problem. The new portage tree (we installed the latest) has no profile 13.0 and our emerge was half broken. We have preliminary steps described in Failed to install sys-apps/portage – Called pkg_preinst – portage._compat_upgrade.default_locations

Because we upgrade from 13.0 to 17.1, first, we need to perform the 17.0 upgrade (check the original steps here – https://gentoo.org/support/news-items/2017-11-30-new-17-profiles.html)

STEP 1) Select the previous profile 17.0 temporarily.

srv ~ # eselect profile set default/linux/amd64/17.0

You won’t be able to build any GNU GCC and you cannot continue with the next step.

STEP 2) Upgrade to GNU GCC 6.4.0 or later.

Our current GNU GCC is really old – 4.9.3. The latest version is gcc-9.2.0-r1 and we are going to use it.
Keep on reading!

cobbler – DisallowedHost: Invalid HTTP_HOST header: ”. You may need to add u” to ALLOWED_HOSTS.

Cobbler web (probably not the latest) uses Django and since version 1.5 (IIUC) if your IP is not in an allowed host directive – ALLOWED_HOSTS you will get 400 and the following apache errors:

[Mon Jan 14 13:44:27.805290 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] mod_wsgi (pid=5897): Exception occurred processing WSGI script '/usr/share/cobbler/web/cobbler.wsgi'.
.....
.....
[Mon Jan 14 13:44:27.805743 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] DisallowedHost: Invalid HTTP_HOST header: '192.168.0.25'. You may need to add u'192.168.0.25' to ALLOWED_HOSTS.

The solution is simple enough – add your host in the ALLOWED_HOSTS.

But where? In which cobbler configuration file?

Find the cobbler web setting file and add a line for ALLOWED_HOSTS.

In Ubuntu the file is “/usr/share/cobbler/web/settings.py” and add the following:

DEBUG = True
TEMPLATE_DEBUG = DEBUG

ALLOWED_HOSTS = '*'

ADMINS = (
    # ('Your Name', 'your_email@domain.com'),
)

This will instruct Django to accept requests from all IPs. Now Cobbler web will work.

The whole output error in the apache logs

The error could be seen in Cobbler web installed in Ubuntu 16 with the latest package cobbler-web 2.4.1-0ubuntu2.

[Mon Jan 14 13:44:27.805290 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] mod_wsgi (pid=5897): Exception occurred processing WSGI script '/usr/share/cobbler/web/cobbler.wsgi'.
[Mon Jan 14 13:44:27.805360 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] Traceback (most recent call last):
[Mon Jan 14 13:44:27.805381 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 189, in __call__
[Mon Jan 14 13:44:27.805420 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     response = self.get_response(request)
[Mon Jan 14 13:44:27.805429 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 207, in get_response
[Mon Jan 14 13:44:27.805442 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return debug.technical_500_response(request, *sys.exc_info(), status_code=400)
[Mon Jan 14 13:44:27.805449 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/views/debug.py", line 97, in technical_500_response
[Mon Jan 14 13:44:27.805463 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     html = reporter.get_traceback_html()
[Mon Jan 14 13:44:27.805470 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/views/debug.py", line 384, in get_traceback_html
[Mon Jan 14 13:44:27.805480 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return t.render(c)
[Mon Jan 14 13:44:27.805487 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 210, in render
[Mon Jan 14 13:44:27.805499 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return self._render(context)
[Mon Jan 14 13:44:27.805505 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 202, in _render
[Mon Jan 14 13:44:27.805516 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return self.nodelist.render(context)
[Mon Jan 14 13:44:27.805523 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 905, in render
[Mon Jan 14 13:44:27.805533 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     bit = self.render_node(node, context)
[Mon Jan 14 13:44:27.805551 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/debug.py", line 79, in render_node
[Mon Jan 14 13:44:27.805563 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return node.render(context)
[Mon Jan 14 13:44:27.805569 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/defaulttags.py", line 329, in render
[Mon Jan 14 13:44:27.805582 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return nodelist.render(context)
[Mon Jan 14 13:44:27.805589 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 905, in render
[Mon Jan 14 13:44:27.805602 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     bit = self.render_node(node, context)
[Mon Jan 14 13:44:27.805609 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/debug.py", line 79, in render_node
[Mon Jan 14 13:44:27.805621 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return node.render(context)
[Mon Jan 14 13:44:27.805627 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/debug.py", line 89, in render
[Mon Jan 14 13:44:27.805639 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     output = self.filter_expression.resolve(context)
[Mon Jan 14 13:44:27.805647 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 648, in resolve
[Mon Jan 14 13:44:27.805657 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     obj = self.var.resolve(context)
[Mon Jan 14 13:44:27.805663 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 789, in resolve
[Mon Jan 14 13:44:27.805673 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     value = self._resolve_lookup(context)
[Mon Jan 14 13:44:27.805679 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 849, in _resolve_lookup
[Mon Jan 14 13:44:27.805689 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     current = current()
[Mon Jan 14 13:44:27.805696 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/http/request.py", line 152, in build_absolute_uri
[Mon Jan 14 13:44:27.805708 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     host=self.get_host(),
[Mon Jan 14 13:44:27.805714 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/http/request.py", line 102, in get_host
[Mon Jan 14 13:44:27.805725 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     raise DisallowedHost(msg)
[Mon Jan 14 13:44:27.805743 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] DisallowedHost: Invalid HTTP_HOST header: '192.168.0.25'. You may need to add u'192.168.0.25' to ALLOWED_HOSTS.

Failed to install sys-apps/portage – Called pkg_preinst – portage._compat_upgrade.default_locations

Recently there was a problem with one compute node servers, which Gentoo (in fact, the chroot environment had not been updated for 3 years) could not emerge the new portage because it kept failing in the pkg_preinst with:

srv ~ # USE="-rsync-verify" emerge -va '=sys-apps/portage-2.3.76::gentoo'
.....
.....
>>> Installing (1 of 1) sys-apps/portage-2.3.76::gentoo
 * checking 1999 files for package collisions
1000 files checked ...
^[[B>>> Merging sys-apps/portage-2.3.76 to /
/usr/bin/python2.7: No module named _compat_upgrade
 * ERROR: sys-apps/portage-2.3.76::gentoo failed (preinst phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line 133:  Called pkg_preinst
 *   environment, line 3238:  Called die
 * The specific snippet of code:
 *       env -u DISTDIR -u PORTAGE_OVERRIDE_EPREFIX -u PORTAGE_REPOSITORIES -u PORTDIR -u PORTDIR_OVERLAY PYTHONPATH="${D%/}${PYTHON_SITEDIR}${PYTHONPATH:+:${PYTHONPATH}}" "${PYTHON}" -m portage._compat_upgrade.default_locations || die;
 * 
 * If you need support, post the output of `emerge --info '=sys-apps/portage-2.3.76::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-apps/portage-2.3.76::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-apps/portage-2.3.76/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-apps/portage-2.3.76/temp/environment'.
 * Working directory: '/var/tmp/portage/._portage_reinstall_.RKkxLW/pym'
 * S: '/var/tmp/portage/sys-apps/portage-2.3.76/work/portage-2.3.76'
!!! FAILED preinst: 1

>>> Failed to install sys-apps/portage-2.3.76, Log file:

>>>  '/var/tmp/portage/sys-apps/portage-2.3.76/temp/build.log'

Note this is the installation phase, where everything from the build process passes smoothly, but it fails to install it with some vague error of a dying line with a couple of python and portage environments. The problem is the current portage does not support EAPI 6 and 7 and some packages were unable to be installed!

And we fixed the issue by just using the method described in our previous article – Fix your broken or old portage in Gentoo, fix the emerge command
Cloning a new portage software and using it to emerge (install) a newer (or reinstall the current) portage in the system to fix the system’s portage and the emerge command:

cd /root
git clone https://anongit.gentoo.org/git/proj/portage.git
/root/portage/bin/emerge --sync
eselect profile set default/linux/amd64/17.1
/root/portage/bin/emerge -v portage

Now the latest and stable Gentoo profile is 17.1, so we set it to be sure we use it (in future this may change).
Keep on reading!

Fix your broken or old portage in Gentoo, fix the emerge command

Using Gentoo for servers and chroots it might happen to deal with old and not regularly updated Gentoo environment, which in some cases is completely non-updatable using the regular process with emerge command. And no emerge means no installs from the Gentoo packaging system. Or you maybe have a broken portage after failed update with missing emerge command or missing or broken portage modules

In general, this article is for those, who cannot update their “sys-apps/portage” or even the emerge command exits with errors and is of no use.

In cases such as:

Missing portage files (broken portage)
Broken emerge command (broken portage)
no update of new portage is possible – very very old portage, which does not support EAPI of all current “sys-apps/portage” (now is EAPI=5) and you do not have old portage ebuild files
Easy update the portage to the newest in an old Gentoo system.

A real world errors are included at the bottom for each case above.

You need just a working python 2.7.x and git to clone “https://anongit.gentoo.org/git/proj/portage.git” or at least some tool to download the portage package.

Unpack to a globally accessible directory, DO NOT USE “/root“, because emerge changes user to non-privileges and needs execute permission for other for the all the path to the directory of emerge. Look below for more details.

Our example is to repair a completely broken portage with error:

srv ~ # emerge -va portage
Traceback (most recent call last):
  File "/usr/lib/python-exec/python2.7/emerge", line 42, in <module>
    import portage
ImportError: No module named portage

STEP 1) Clone the portage package from the git or download the portage tarball.

If you do not have a git client you can always check the URL in the sys-app/portage ebuild and download the URL. Still, if you cannot find the tarball’s URL, you can just simply get a mirror such as https://mirror.leaseweb.com/gentoo/distfiles, wait for the loading of the page (12Mbytes, it’s huge, all Gentoo tarball files’ names are here) and grep in it by the name “portage”. Or you can check here https://dev.gentoo.org/~zmedico/portage/archives/. Download the latest tarball and unpack it in the /opt directory.
Using git is the easiest method, but it is the same with downloading and unpacking the tarball in the “/opt”.

srv opt # git clone https://anongit.gentoo.org/git/proj/portage.git
Cloning into 'portage'...
remote: Enumerating objects: 151654, done.
remote: Counting objects: 100% (151654/151654), done.
remote: Compressing objects: 100% (39915/39915), done.
remote: Total 151654 (delta 112542), reused 149864 (delta 111349)
Receiving objects: 100% (151654/151654), 22.38 MiB | 550.00 KiB/s, done.
Resolving deltas: 100% (112542/112542), done.
srv opt # cd portage/
srv portage # ls -al
total 232
drwxr-xr-x. 11 root root  4096 Oct  6 04:52 .
drwx------.  4 root root  4096 Oct  6 04:51 ..
drwxr-xr-x.  6 root root  4096 Oct  6 04:52 bin
drwxr-xr-x.  5 root root  4096 Oct  6 04:52 cnf
-rw-r--r--.  1 root root  1840 Oct  6 04:52 COPYING
-rw-r--r--.  1 root root  6646 Oct  6 04:52 DEVELOPING
drwxr-xr-x.  5 root root  4096 Oct  6 04:52 doc
-rw-r--r--.  1 root root   200 Oct  6 04:52 .editorconfig
drwxr-xr-x.  7 root root  4096 Oct  6 04:52 .git
-rw-r--r--.  1 root root    80 Oct  6 04:52 .gitignore
drwxr-xr-x.  4 root root  4096 Oct  6 04:52 lib
-rw-r--r--.  1 root root 18092 Oct  6 04:52 LICENSE
-rwxr-xr-x.  1 root root  1272 Oct  6 04:52 make.conf.example-repatch.sh
drwxr-xr-x.  3 root root  4096 Oct  6 04:52 man
-rw-r--r--.  1 root root   290 Oct  6 04:52 MANIFEST.in
drwxr-xr-x.  2 root root  4096 Oct  6 04:52 misc
-rw-r--r--.  1 root root 17845 Oct  6 04:52 NEWS
-rw-r--r--.  1 root root     0 Oct  6 04:52 .portage_not_installed
-rw-r--r--.  1 root root  2246 Oct  6 04:52 README
-rw-r--r--.  1 root root 68122 Oct  6 04:52 RELEASE-NOTES
drwxr-xr-x.  6 root root  4096 Oct  6 04:52 repoman
-rwxr-xr-x.  1 root root  4889 Oct  6 04:52 runtests
-rwxr-xr-x.  1 root root 19743 Oct  6 04:52 setup.py
drwxr-xr-x.  2 root root  4096 Oct  6 04:52 src
-rwxr-xr-x.  1 root root    81 Oct  6 04:52 tabcheck.py
-rw-r--r--.  1 root root  1864 Oct  6 04:52 TEST-NOTES
-rw-r--r--.  1 root root   571 Oct  6 04:52 testpath
-rw-r--r--.  1 root root   348 Oct  6 04:52 tox.ini
-rw-r--r--.  1 root root   584 Oct  6 04:52 .travis.yml

This is the latest portage with working emerge command in the bin sub-directory.
Keep on reading!

genkernel – ERROR: Unable to generate splash, ‘splash_geninitramfs’ was not found!

If you tried recently to build your kernel with genkernel (4.0.0_beta17, but you will have the same problem with 3.x) you may end up with the following error:

* ERROR: Unable to generate splash, 'splash_geninitramfs' was not found!

The splash_geninitramfs was part of the removed Gentoo ebuild package – “media-gfx/splashutils“. The software in the package splashutils had not been maintained for a really long time and eventually, it was removed. At present, there is no package offering the splash_geninitramfs. Still, the same functionality could be archived with “sys-boot/plymouth“, but the genkernel does not have the option to use it.
The genkernel command option, which triggers the error is “–splash” you must remove it. And check whether the following option in “/etc/genkernel.conf” is set to “no” (at least, in genkernel version 3.x is the default set to “yes”):

SPLASH="no"

When you instruct the genkernel not to add boot splash using splashutils the error will be gone and the kernel build will be successful.

The output error

We include the output error when using “–splash” with genkernel and the last part of genkernel.log.

livecd ~ # genkernel --splash --install --clean --no-mrproper --menuconfig all
* Gentoo Linux Genkernel; Version 4.0.0_beta17
* Using genkernel configuration from '/etc/genkernel.conf' ...
* Running with options: --splash --install --clean --no-mrproper --menuconfig all

* Working with Linux kernel 5.3.1-gentoo for x86_64
* Using kernel config file '/usr/share/genkernel/arch/x86_64/generated-config' ...
* 
* Note: The version above is subject to change (depends on config and status of kernel sources).

* kernel: >> Initializing ...
*         >> Running 'make clean' ...
*         >> --no-mrproper is set; Skipping 'make mrproper' ...
*         >> Running 'make oldconfig' ...
*         >> Invoking menuconfig ...
*         >> Re-running 'make oldconfig' due to changed kernel options ...
*         >> Kernel version has changed (probably due to config change) since genkernel start:
*            We are now building Linux kernel 5.3.1-gentoo-x86_64 for x86_64 ...
*         >> Compiling 5.3.1-gentoo-x86_64 bzImage ...
*         >> Compiling 5.3.1-gentoo-x86_64 modules ...
*         >> Installing 5.3.1-gentoo-x86_64 modules (and stripping) ...
*         >> Generating module dependency data ...
*         >> Saving config of successful build to '/etc/kernels/kernel-config-5.3.1-gentoo-x86_64' ...

* initramfs: >> Initializing ...
*         >> Appending devices cpio data ...
*         >> Appending base_layout cpio data ...
*         >> Appending auxilary cpio data ...
*         >> Appending blkid cpio data ...
*         >> Appending busybox cpio data ...
*         >> Appending mdadm cpio data ...
*         >> Appending modprobed cpio data ...
*         >> Appending splash cpio data ...
* ERROR: Unable to generate splash, 'splash_geninitramfs' was not found!
* Please consult '/var/log/genkernel.log' for more information and any
* errors that were reported above.
* 
* Report any genkernel bugs to bugs.gentoo.org and
* assign your bug to genkernel@gentoo.org. Please include
* as much information as you can in your bug report; attaching
* '/var/log/genkernel.log' so that your issue can be dealt with effectively.
* 
* Please do *not* report kernel compilation failures as genkernel bugs!

livecd ~ # cat /var/log/genkernel.log
.....
.....
*         >> Appending splash cpio data ...

* ERROR: Unable to generate splash, 'splash_geninitramfs' was not found!
* Please consult '/var/log/genkernel.log' for more information and any
* errors that were reported above.
* 
* Report any genkernel bugs to bugs.gentoo.org and
* assign your bug to genkernel@gentoo.org. Please include
* as much information as you can in your bug report; attaching
* '/var/log/genkernel.log' so that your issue can be dealt with effectively.
* 
* Please do *not* report kernel compilation failures as genkernel bugs!
* 

* mount: >> '/boot' is not a mountpoint; Nothing to restore ...
>>> Ended on: 2019-09-30 18:11:20 (after 0 days 0 hours 08 minutes 06 seconds)