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.

Technical details of a default CentOS 8.0.1950 minimal installation

This article is for those of you who do not want to install a whole new operating system only to discover some technical details about the default installation like disk layout, packages included, software versions and so on. Here we are going to review in several sections what is like to have a default installation of CentOS 8.0.
Despite the kernel is 4.18 it detects successfully the new RYZEN/Threadripper AMD and the system is stable (we booted in UEFI mode).

Software

The CentOS 8.0 (8.0.1950) you can have

  • linux kernel – 4.18.0 (4.18.0-80.7.1.el8_0.x86_64)
  • Graphical User Interface
    • Xorg X server – 1.20.3
    • GNOME (the GUI) – 3.28.2
    • K Desktop Environment – NO, it’s depricated and not included in the release.
  • System
    • linux-firmware – version: 20190111, release: 92.gitd9fb2ee6.el8.
    • QT – 5.11.1
    • libc – 2.28
    • GNU GCC – 8.2.1
    • OpenSSL – 1.1.1
    • coreutils – 8.30
    • yum – Depricated and replaced with dnf
    • dnf – 4.0.9.2
    • cups – 2.2.6
    • rsyslog – 8.37.0
  • Servers
    • Apache – 2.4.37
    • Nginx – 1.14.1
    • MySQL server – 8.0.13
    • MariaDB server – 10.3.11
    • PostgreSQL – 10.6
  • Programming
    • PHP – 7.2.11
    • python – 2.7.15 and also includes 3.6.8
    • perl – 5.26.3
    • ruby – 2.5.3
    • OpenJDK – 11.0.4.11 and also includes 1.8.0.222.b10
    • Go – 1.11.5
    • Rust – 1.31.0
    • Subversion – 1.10.2
    • Git – 2.18.1

Note: Not all of the above software comes installed by default.
The installation procedure you can find here – How to do a network installation of CentOS 8 (8.0.1950) – minimal server installation Minimal install with “Standard” Addons selected.
Installed packages are 547 occupying 1.8G space:.

[root@srv ~]# dnf list installed|wc -l
547
[root@srv ~]# df -h /
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/cl_srv-root   50G  1.8G   49G   4% /

Note: if you do not select “Standard Addon” the installation occupies less space – 1.6Gbytes and installs only 397 packages.
Keep on reading!

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.

How to do a network installation of CentOS 8 (8.0.1950) – minimal server installation

Minimal net install is useful when a dedicated server is installed from a IPMI KVM or Dell iDRAC, HP iLO, IBM IMM or where the initial client side download of files need to be minimal.
For amd64 CentOS 8 BaseOS the net install bootable media is located here (now the current latest release is 8.0.1950, but you can check the last directory with 8. for the time you follow this howto):

http://mirror.leaseweb.com/centos/8/isos/x86_64/CentOS-8-x86_64-1905-boot.iso

Note there is no minimal CD for offline installation anymore. Boot CD is to just boot and make “netinstall” installation and a big fat DVD of 6.6Gbytes to install offline.
Software details of CentOS 8 minimal install could be found here – Technical details of a default CentOS 8.0.1950 minimal installation

Download it and put it on a cd or usb, the boot from it and follow the steps bellow:

STEP 1) Enter the BIOS of your machine (desktop or server) to change the boot order.

You can try F11 on most servers to have the boot menu. Here we use DEL to enter the UEFI BIOS.

main menu
Enter BIOS – change boot order

Keep on reading!

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.

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 /root directory.
Using git is the easiest method, but is the same with downloading and unpacking the tarball in the “/root”.

srv root # 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 root # 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!

SSD cache device to a software raid using LVM2

Inspired by our article – SSD cache device to a hard disk drive using LVM, which uses SSD driver as a cache device to a single hard drive, we decided to make a new article, but this time using two hard drives in raid setup (in our case RAID1 for redundancy) and a single NVME SSD drive.
The goal:
Caching RAID1 consisting of two 8T hard drive with a single 1T NVME SSD drive. Caching reads and writes, i.e. the write-back is enabled.
Our setup:

  • 1 NVME SSD disk Samsung 1T. It will be used for writeback cache device (you may use writethrough, too, to maintain the redundancy of the whole storage)!
  • 2 Hard disk drive 8T grouped in RAID1 for redundancy.

Keep on reading!