Upgrading to systemd-utils and resolving systemd-tmpfiles soft blocking systemd-utils

main menu
News migrating to systemd-utils

Recently a new Gentoo package was added – sys-apps/systemd-utils, which should replace three separate packages sys-apps/systemd-tmpfiles, sys-boot/systemd-boot and sys-fs/udev. As the sys-fs/udev is one of the core packages in the OpenRC world and it can trigger multiple blocking errors and dependency problems.
The sys-apps/systemd-utils has three USE variables for the three replacing packages – udev, boot, and tmpfiles, so the user might add them in make.conf file.
It’s worth noting when upgrading to the sys-apps/systemd-utils, the sys-apps/systemd-tmpfiles and sys-boot/systemd-boot will be removed, but sys-fs/udev is staying in the system with version sys-fs/udev-250 and above. The sys-fs/udev-250 would always pull in sys-apps/systemd-utils[udev] as a dependency. Despite the names including systemd, these packages do not depend on systemd and are meant to be used in OpenRC system.
There is Gentoo news about this upgrade and it can be read with eselect. Check out the article ending for more information.
Here is what a blocking could look like:

root@srv ~ # emerge -vau world
......
......
[ebuild     U  ] dev-lang/php-8.0.27:8.0::gentoo [8.0.25:8.0::gentoo] USE="acl bcmath berkdb bzip2 calendar cli ctype curl enchant exif fileinfo filter flatfile fpm ftp gd gdbm gmp iconv imap intl ipv6 jit mhash mysql mysqli nls opcache pcntl pdo phar posix readline session session-mm sharedmem simplexml soap sockets sqlite ssl tidy tokenizer truetype unicode xml xmlreader xmlwriter xslt zip zlib -apache2 -apparmor -argon2 -cdb -cgi -cjk -coverage -debug -embed -ffi -firebird -inifile -iodbc -kerberos -ldap -ldap-sasl -libedit -lmdb -mssql -oci8-instant-client -odbc -phpdbg -postgres -qdbm (-selinux) -snmp -sodium -spell -systemd -sysvipc -test -threads -tokyocabinet -webp -xpm" 10549 KiB
[ebuild     UD ] sys-apps/man-pages-posix-2013a::gentoo [2017a::gentoo] 909 KiB
[ebuild     U  ] sys-apps/openrc-0.46::gentoo [0.45.2-r1::gentoo] USE="ncurses netifrc pam unicode -audit -bash -debug -newnet (-selinux) -sysv-utils" 242 KiB
[blocks B      ] sys-fs/eudev ("sys-fs/eudev" is soft blocking sys-apps/systemd-utils-251.10-r1)
[blocks B      ] sys-apps/systemd-utils[udev] ("sys-apps/systemd-utils[udev]" is soft blocking sys-fs/eudev-3.2.11-r3)

Total: 113 packages (97 upgrades, 1 downgrade, 15 new), Size of downloads: 554077 KiB
Conflict: 3 blocks (2 unsatisfied)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-fs/eudev-3.2.11-r3:0/0::gentoo, installed) pulled in by
    sys-fs/eudev required by @selected 

  (sys-apps/systemd-utils-251.10-r1:0/0::gentoo, ebuild scheduled for merge) pulled in by
    sys-apps/systemd-utils[tmpfiles] required by (sys-apps/systemd-tmpfiles-250:0/0::gentoo, ebuild scheduled for merge) USE="" ABI_X86="(64)"
    sys-apps/systemd-utils[tmpfiles] required by (virtual/tmpfiles-0-r3:0/0::gentoo, installed) USE="" ABI_X86="(64)"
    sys-apps/systemd-utils[udev] required by (virtual/udev-217-r5:0/0::gentoo, installed) USE="" ABI_X86="(64)"


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages
root@srv ~ # emerge -va sys-apps/systemd-utils


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

Calculating dependencies... done!
Dependency resolution took 0.84 s.

[ebuild  N     ] acct-group/audio-0-r1::gentoo  0 KiB
[ebuild  N     ] acct-group/cdrom-0-r1::gentoo  0 KiB
[ebuild  N     ] acct-group/dialout-0-r1::gentoo  0 KiB
[ebuild  N     ] acct-group/disk-0-r1::gentoo  0 KiB
[ebuild  N     ] acct-group/kmem-0-r1::gentoo  0 KiB
[ebuild  N     ] acct-group/lp-0-r1::gentoo  0 KiB
[ebuild  N     ] acct-group/sgx-0::gentoo  0 KiB
[ebuild  N     ] acct-group/tape-0-r1::gentoo  0 KiB
[ebuild  N     ] acct-group/tty-0-r1::gentoo  0 KiB
[ebuild  N     ] acct-group/video-0-r1::gentoo  0 KiB
[ebuild  N     ] sys-apps/systemd-utils-251.10-r1::gentoo  USE="acl kmod (split-usr) tmpfiles udev -boot (-selinux) -sysusers -test" ABI_X86="(64) -32 (-x32)" 11194 KiB
[blocks B      ] <sys-apps/systemd-tmpfiles-250 ("<sys-apps/systemd-tmpfiles-250" is soft blocking sys-apps/systemd-utils-251.10-r1)
[blocks B      ] sys-fs/eudev ("sys-fs/eudev" is soft blocking sys-apps/systemd-utils-251.10-r1)
[blocks B      ] sys-apps/systemd-utils[udev] ("sys-apps/systemd-utils[udev]" is soft blocking sys-fs/eudev-3.2.11-r3)

Total: 11 packages (11 new), Size of downloads: 11194 KiB
Conflict: 3 blocks (3 unsatisfied)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-apps/systemd-tmpfiles-249.9:0/0::gentoo, installed) pulled in by
    sys-apps/systemd-tmpfiles required by @selected 

  (sys-apps/systemd-utils-251.10-r1:0/0::gentoo, ebuild scheduled for merge) pulled in by
    sys-apps/systemd-utils

  (sys-fs/eudev-3.2.11-r3:0/0::gentoo, installed) pulled in by
    sys-fs/eudev required by @selected 


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages

A screenshot from the command line, which is colored properly.

main menu
Unresolved Soft blocking tmpfiles and eudev

To solve the soft blocking, first, deselect the old packages, which are soft blocking the sys-apps/systemd-utils. In the above example, the problematic packages are sys-fs/eudev and sys-apps/systemd-tmpfiles. Deselect the packages and try to build only sys-apps/systemd-utils:
Keep on reading!

Gentoo clang-15: error: does not contain a GCC installation

main menu
emerge firefox

Trying to build a package resulted in a building failure because a Clang could not find GNU GCC installation as the error shows.

Executing just x86_64-pc-linux-gnu-clang-15 the same error.

[root@srv ~]# x86_64-pc-linux-gnu-clang-15 
clang-15: error: '/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0' does not contain a GCC installation
clang-15: error: no input files

Apparently, because the latest upgrade of GNU GCC went from 12.2.0 to 12.2.1_p20221008 and the directory changed to /usr/lib/gcc/x86_64-pc-linux-gnu/12.
The Clang binaries read several configuration files and one of them was not updated when the GCC had been upgraded. The configuration file /etc/clang/gentoo-gcc-install.cfg has the wrong path, because the gcc-config version was an old one or the configuration file is generated only on GCC major version, not in the minor. But the last upgrade didn’t modified the Clang configuration file /etc/clang/gentoo-gcc-install.cfg

To resolve this issue, the user may edit the file manually or just use gcc-config to revert to the older and then to the new GCC version at once. List the currently installed GCC versions in the system and choose one.

[root@srv ~]# gcc-config -l
 [1] x86_64-pc-linux-gnu-8.2.0
 [2] x86_64-pc-linux-gnu-8.3.0
 [3] x86_64-pc-linux-gnu-9.2.0
 [4] x86_64-pc-linux-gnu-10.3.0
 [5] x86_64-pc-linux-gnu-11.3.0
 [6] x86_64-pc-linux-gnu-12 *
[root@srv ~]# gcc-config x86_64-pc-linux-gnu-11.3.0
 * Switching native-compiler to x86_64-pc-linux-gnu-11.3.0 ...
>>> Regenerating /etc/ld.so.cache...                                                                  [ ok ]
 * If you intend to use the gcc from the new profile in an already
 * running shell, please remember to do:

 *   . /etc/profile

[root@srv ~]#  gcc-config x86_64-pc-linux-gnu-12
 * Switching native-compiler to x86_64-pc-linux-gnu-12 ...
>>> Regenerating /etc/ld.so.cache...                                                                  [ ok ]
 * If you intend to use the gcc from the new profile in an already
 * running shell, please remember to do:

 *   . /etc/profile
[root@srv ~]# . /etc/profile

Check the sys-devel/gcc-config for available upgrades and do them if there are!
More Gentoo tips here.

Removing of kwayland-server and kwayland-server” is soft blocking kde-plasma/kwin-5.25.2

A big change for Plasma KDE happened two months ago – a “Merge kwayland-server into kwin“.
So after KDE Plasma 5.25, there is no kwayland-server any more (respectively no kwayland-server with version 5.25 and no package in Gentoo) and it may block a Gentoo update with the following error:

mydesktop root # emerge -va --verbose-conflicts --verbose --backtrack=300 $(qlist -IC|grep -i kde)
......
......
[ebuild     U  ] dev-util/kdevelop-php-22.04.2:5::gentoo [21.12.3:5::gentoo] USE="handbook -debug -test" 1,057 KiB
[ebuild     U  ] kde-apps/umbrello-22.04.2:5::gentoo [21.12.3:5::gentoo] USE="handbook php -debug -test" 5,544 KiB
[ebuild     U  ] kde-apps/kross-interpreters-22.04.2:5::gentoo [21.12.3:5::gentoo] USE="-debug" 149 KiB
[blocks B      ] kde-plasma/kwayland-server ("kde-plasma/kwayland-server" is soft blocking kde-plasma/kwin-5.25.2)

Total: 340 packages (329 upgrades, 5 new, 6 reinstalls), Size of downloads: 1,001,699 KiB
Conflict: 1 block (1 unsatisfied)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (kde-plasma/kwayland-server-5.24.5-r1:5/5::gentoo, ebuild scheduled for merge) pulled in by
    kde-plasma/kwayland-server
    kde-plasma/kwayland-server:5::gentoo required by @selected 
    kde-plasma/kwayland-server required by @selected 

  (kde-plasma/kwin-5.25.2:5/5::gentoo, ebuild scheduled for merge) pulled in by
    >=kde-plasma/kwin-5.25.2:5 required by (kde-plasma/plasma-desktop-5.25.2:5/5::gentoo, ebuild scheduled for merge) USE="handbook ibus kaccounts scim semantic-desktop -debug -emoji -telemetry -test" ABI_X86="(64)"
    >=kde-plasma/kwin-5.25.2:5[lock] required by (kde-plasma/plasma-meta-5.25.2:5/5::gentoo, ebuild scheduled for merge) USE="accessibility bluetooth browser-integration crash-handler crypt desktop-portal display-manager elogind gtk handbook kwallet legacy-systray networkmanager pulseaudio sddm smart wallpapers -colord -discover (-firewall) -grub -plymouth -sdk -systemd -thunderbolt" ABI_X86="(64)"
    >=kde-plasma/kwin-5.25.2:5 required by (kde-plasma/libkworkspace-5.25.2:5/5::gentoo, ebuild scheduled for merge) USE="-debug -test" ABI_X86="(64)"
    >=kde-plasma/kwin-5.25.2:5 required by (kde-plasma/plasma-workspace-5.25.2:5/5::gentoo, ebuild scheduled for merge) USE="calendar fontconfig geolocation handbook policykit semantic-desktop -appstream -debug -gps -screencast -telemetry -test" ABI_X86="(64)"

emerge could not continue with the upgrade to KDE Platform 5.25.2.

main menu
emerge error

kwayland-server is pulled by selected, but the last version of the package is from 5.24 release, which should immediately signal that there is something wrong with it, because the emerge command shows the latest KDE Plasma version to be 5.25 (with the exact version 5.25.2).

Solution – deselect/remove kde-plasma/kwayland-server

The solution is simple, just deselect it from the world slot to be sure it won’t be pulled again in the future. Remove the package manually if the error still persists, but only deselecting should work. Of course, it should not be selected in the command-line with emerge, neither. In general, such package won’t be available any more.
Always keep eye on the pulled versions and the versions you are trying to install, most of the time the problem is obvious and from a single “wrong/bad” package, which may generate e great deal of erroneous and frightening dependencies output.

mydesktop root # emerge --deselect kwayland-server
>>> Removing kde-plasma/kwayland-server from "world" favorites file...
>>> Removing kde-plasma/kwayland-server:5::gentoo from "world" favorites file...

And now the emerge command is OK and no problem with the dependencies and blocks:

mydesktop root # emerge -va --verbose-conflicts --verbose --backtrack=300 $(qlist -IC|grep -i kde|grep -v kwayland-server)
......
......
[ebuild  N     ] kde-plasma/kwin-5.25.2:5::gentoo  USE="accessibility (caps) handbook lock multimedia -debug -gles2-only -plasma -screencast -test" 6,468 KiB
[uninstall     ] kde-plasma/kwayland-server-5.24.3:5::gentoo  USE="-debug -doc -test" 
[blocks b      ] kde-plasma/kwayland-server ("kde-plasma/kwayland-server" is soft blocking kde-plasma/kwin-5.25.2)
[ebuild     U  ] kde-plasma/libkworkspace-5.25.2:5::gentoo [5.24.3:5::gentoo] USE="-debug -test" 0 KiB
......
......
[ebuild     U  ] kde-apps/akregator-22.04.2:5::gentoo [21.12.3:5::gentoo] USE="handbook -debug -speech -telemetry -test" 2,209 KiB

Total: 339 packages (328 upgrades, 5 new, 6 reinstalls, 1 uninstall), Size of downloads: 1,001,483 KiB
Conflict: 1 block (all satisfied)

More on Gentoo blocking – Gentoo update tips when updating packages with blocks and masked files

Building python 3.10.4 and possibly undefined macro: AC_MSG_ERROR

Emerging the new python 3.10 in Gentoo may lead to the following error, despite all the dependencies installed. This error might also occur in any other Linux distro! During the configure stage the autoconf tool outputs error:

root@srv ~ # cat /var/tmp/portage/dev-lang/python-3.10.5/temp/autoconf.out 
***** autoconf *****
***** PWD: /var/tmp/portage/dev-lang/python-3.10.5/work/Python-3.10.5
***** autoconf --force

configure.ac:59: warning: The macro `AC_CONFIG_HEADER' is obsolete.
configure.ac:59: You should run autoupdate.
./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from...
configure.ac:59: the top level
configure.ac:911: warning: AC_LINK_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
./lib/autoconf/specific.m4:364: AC_USE_SYSTEM_EXTENSIONS is expanded from...
configure.ac:911: the top level
configure.ac:2214: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:2214: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:2214: the top level
configure.ac:4250: warning: The macro `AC_HEADER_TIME' is obsolete.
configure.ac:4250: You should run autoupdate.
./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from...
configure.ac:4250: the top level
configure.ac:18: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation

It appears a dependency is missing! First, build the package sys-devel/autoconf-archive and then the building of python-3.10.5 will finish successfully.

root@srv ~ # emerge -va autoconf-archive

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

Calculating dependencies... done!
[ebuild  N     ] sys-devel/autoconf-archive-2022.02.11::gentoo  660 KiB

Total: 1 package (1 new), Size of downloads: 660 KiB

Would you like to merge these packages? [Yes/No] yes

Emerging the dev-lang/python-3.10.5::gentoo outputs the error and the building process stops. The error output in emerge command is so informative. The actual error is in the /var/tmp/portage/dev-lang/python-3.10.5/temp/autoconf.out.
Keep on reading!

Change found sources for kernel version when packages need the kernel sources to compile

Multiple Gentoo packages may need kernel sources to compile. There are packages, which are external modules such as virtualbox-modules or video drivers or wifi drivers or more. All these packages expect the current loaded kernel sources are present and to use them when compiling the external kernel module. But sometimes the proper kernel sources are missing, those needed to compile the kernel module in such a way to load it in the currently loaded kernel.

This article is valid not only for Gentoo Linux distribution but any Linux and kernel sources. So, if the user needs to have properly configured kernel sources for the currently loaded kernel, this is one way to do it right.

Here is an example: Updated kernel, but no sources are kept and then the VirtualBox needs to update to a newer version, but with the missing kernel sources of the currently loaded kernel updating the VirtualBox will cause the VirtualBox to stop working!

root@srv ~ # uname -a
Linux srv 5.15.5-gentoo #2 SMP Tue Nov 30 16:08:49 EET 2021 x86_64 Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz GenuineIntel GNU/Linux
root@srv ~ # emerge -va app-emulation/virtualbox-modules

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

[ebuild     U  ] app-emulation/virtualbox-modules-6.1.32:0/6.1::gentoo [6.1.26:0/6.1::gentoo] USE="dist-kernel -pax-kernel" 660 KiB

Total: 1 packages (1 upgrades), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] yes

>>> Verifying ebuild manifests

>>> Running pre-merge checks for app-emulation/virtualbox-6.1.32-r1

>>> Emerging (1 of 1) app-emulation/virtualbox-modules-6.1.32::gentoo
 * Fetching files in the background.
 * To view fetch progress, run in another terminal:
 * tail -f /var/log/emerge-fetch.log
 * vbox-kernel-module-src-6.1.32.tar.xz BLAKE2B SHA512 size ;-) ...                                                                                                                   [ ok ]
 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux
 * Found sources for kernel version:
 *     5.14.2-gentoo-x86_64-genkernel-NEW2
 * Checking for suitable kernel configuration options...                                                                                                                              [ ok ]
>>> Unpacking source...
>>> Unpacking vbox-kernel-module-src-6.1.32.tar.xz to /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work
>>> Source unpacked in /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work
>>> Preparing source in /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work ...

Here is the problem: the currently loaded kernel is version 5.15.5-gentoo and the emerge system finds only sources for 5.14.2-gentoo-x86_64-genkernel-NEW2, which will use to produce modules for the 5.14.2-gentoo-x86_64-genkernel-NEW2. It is obvious enough the modules compiled against kernel sources of 5.14.2-gentoo-x86_64-genkernel-NEW2 version won’t be possible to be loaded under the currently load kernel with version 5.15.5-gentoo.
Here is how to fix this:

  1. Get the kernel sources for 5.15.5-gentoo in /usr/src/linux
  2. Save the currently loaded kernel config in /usr/src/linux/.config
  3. Load the configuration and prepare the kernel sources. No need to compile the kernel sources.

STEP 1) Get the kernel sources for 5.15.5-gentoo

emerge -v =gentoo-sources-5.15.5
rm -f /usr/src/linux
ln -s /usr/src/linux-5.15.5-gentoo /usr/src/linux

These commands will install the needed kernel version and a link to the kernel sources will be created.
Of course, change the kernel version to the proper version if needed.

STEP 2) Save the currently loaded kernel config in /usr/src/linux/.config

zcat /proc/config.gz > /usr/src/linux/.config

If the /proc/config.gz is missing, copy the configuration from the /boot for the currently loaded kernel:

cat /boot/config-5.15.5-gentoo > /usr/src/linux-5.15.5-gentoo/.config

STEP 3) Load the configuration and prepare the kernel sources.

No need to compile the whole kernel source tree. Just to commands to configure and prepare the kernel sources:

cd /usr/src/linux-5.15.5-gentoo
make oldconfig
make prepare

The commands take Here is the output of the last commands:

root@srv1 ~ # cd /usr/src/linux-5.15.5-gentoo
root@srv1 linux # make oldconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
root@srv1 linux # make prepare
  SYNC    include/config/auto.conf.cmd
  HOSTCC  arch/x86/tools/relocs_32.o
  HOSTCC  arch/x86/tools/relocs_64.o
  HOSTCC  arch/x86/tools/relocs_common.o
  HOSTLD  arch/x86/tools/relocs
  HOSTCC  scripts/selinux/genheaders/genheaders
  HOSTCC  scripts/selinux/mdp/mdp
  HOSTCC  scripts/bin2c
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/sorttable
  HOSTCC  scripts/asn1_compiler
  HOSTCC  scripts/extract-cert
  UPD     include/config/kernel.release
  UPD     include/generated/utsrelease.h
  CC      scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/modpost.o
  CC      scripts/mod/devicetable-offsets.s
  HOSTCC  scripts/mod/file2alias.o
  HOSTCC  scripts/mod/sumversion.o
  HOSTLD  scripts/mod/modpost
  CC      kernel/bounds.s
  UPD     include/generated/bounds.h
  CC      arch/x86/kernel/asm-offsets.s
  UPD     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  DESCEND objtool
  HOSTCC  /usr/src/linux-5.15.5-gentoo/tools/objtool/fixdep.o
  HOSTLD  /usr/src/linux-5.15.5-gentoo/tools/objtool/fixdep-in.o
  LINK    /usr/src/linux-5.15.5-gentoo/tools/objtool/fixdep
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/exec-cmd.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/help.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/pager.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/parse-options.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/run-command.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/sigchain.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/subcmd-config.o
  LD      /usr/src/linux-5.15.5-gentoo/tools/objtool/libsubcmd-in.o
  AR      /usr/src/linux-5.15.5-gentoo/tools/objtool/libsubcmd.a
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/arch/x86/special.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/arch/x86/decode.o
  LD      /usr/src/linux-5.15.5-gentoo/tools/objtool/arch/x86/objtool-in.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/weak.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/check.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/special.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/orc_gen.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/orc_dump.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/builtin-check.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/builtin-orc.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/elf.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/objtool.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/libstring.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/libctype.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/str_error_r.o
  CC      /usr/src/linux-5.15.5-gentoo/tools/objtool/librbtree.o
  LD      /usr/src/linux-5.15.5-gentoo/tools/objtool/objtool-in.o
  LINK    /usr/src/linux-5.15.5-gentoo/tools/objtool/objtool

And from now on whenever the kernel sources are needed to compile modules or libraries against, the proper kernel sources will be used of the currently loaded kernel.
The Gentoo emerge command from the begging of this article, but this time with the properly configured kernel sources. The VirtualBox modules are compiled against the loaded kernel, so loading them is not an issue anymore!

root@srv ~ # uname -a
Linux srv 5.15.5-gentoo #2 SMP Tue Nov 30 16:08:49 EET 2021 x86_64 Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz GenuineIntel GNU/Linux
root@srv ~ # emerge -va app-emulation/virtualbox-modules

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

[ebuild     U  ] app-emulation/virtualbox-modules-6.1.32:0/6.1::gentoo [6.1.26:0/6.1::gentoo] USE="dist-kernel -pax-kernel" 660 KiB

Total: 1 packages (1 upgrades), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] yes

>>> Verifying ebuild manifests

>>> Running pre-merge checks for app-emulation/virtualbox-6.1.32-r1

>>> Emerging (1 of 1) app-emulation/virtualbox-modules-6.1.32::gentoo
 * Fetching files in the background.
 * To view fetch progress, run in another terminal:
 * tail -f /var/log/emerge-fetch.log
 * vbox-kernel-module-src-6.1.32.tar.xz BLAKE2B SHA512 size ;-) ...                                                                                                                   [ ok ]
 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux
 * Found sources for kernel version:
 *     5.15.5-gentoo-gentoo
 * Checking for suitable kernel configuration options...                                                                                                                              [ ok ]
>>> Unpacking source...
>>> Unpacking vbox-kernel-module-src-6.1.32.tar.xz to /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work
>>> Source unpacked in /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work
>>> Preparing source in /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/app-emulation/virtualbox-modules-6.1.32/work ...
....
....
root@srv ~ # modprobe vboxdrv
Feb 15 14:15:10 www kernel: vboxdrv: loading out-of-tree module taints kernel.
Feb 15 14:15:10 www kernel: vboxdrv: Found 4 processor cores
Feb 15 14:15:10 www kernel: vboxdrv: TSC mode is Invariant, tentative frequency 2394461773 Hz
Feb 15 14:15:10 www kernel: vboxdrv: Successfully loaded version 6.1.32 r149290 (interface 0x00320000)
Feb 15 14:15:10 www kernel: VBoxNetFlt: Successfully started.

Kernel building failure – unable to initialize decompress status for section .debug_info

Upgrading the Gentoo system may lead to some glitches especially if not emerge the world slot very often!
In fact, leaving older packages living with the new one using slots may also lead to glitches of the same type! Here is one example, where leaving old packages may prevent the user to build some packages or the Linux kernel itself.

.....
.....
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o lib/slub_kunit.ko lib/slub_kunit.o lib/slub_kunit.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o lib/ts_bm.ko lib/ts_bm.o lib/ts_bm.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o lib/ts_fsm.ko lib/ts_fsm.o lib/ts_fsm.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o lib/ts_kmp.ko lib/ts_kmp.o lib/ts_kmp.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o mm/kfence/kfence_test.ko mm/kfence/kfence_test.o mm/kfence/kfence_test.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/6lowpan.ko net/6lowpan/6lowpan.o net/6lowpan/6lowpan.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_dest.ko net/6lowpan/nhc_dest.o net/6lowpan/nhc_dest.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_fragment.ko net/6lowpan/nhc_fragment.o net/6lowpan/nhc_fragment.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_ext_dest.ko net/6lowpan/nhc_ghc_ext_dest.o net/6lowpan/nhc_ghc_ext_dest.mod.o;  true
x86_64-pc-linux-gnu-ld.bfd: mm/kfence/kfence_test.o: unable to initialize decompress status for section .debug_info
x86_64-pc-linux-gnu-ld.bfd: mm/kfence/kfence_test.o: unable to initialize decompress status for section .debug_info
x86_64-pc-linux-gnu-ld.bfd: mm/kfence/kfence_test.o: unable to initialize decompress status for section .debug_info
x86_64-pc-linux-gnu-ld.bfd: mm/kfence/kfence_test.o: unable to initialize decompress status for section .debug_info
mm/kfence/kfence_test.o: file not recognized: file format not recognized
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_ext_frag.ko net/6lowpan/nhc_ghc_ext_frag.o net/6lowpan/nhc_ghc_ext_frag.mod.o;  true
make[3]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15/scripts/Makefile.modfinal:59: mm/kfence/kfence_test.ko] Error 1
make[3]: *** Waiting for unfinished jobs....
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_ext_hop.ko net/6lowpan/nhc_ghc_ext_hop.o net/6lowpan/nhc_ghc_ext_hop.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_ext_route.ko net/6lowpan/nhc_ghc_ext_route.o net/6lowpan/nhc_ghc_ext_route.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_icmpv6.ko net/6lowpan/nhc_ghc_icmpv6.o net/6lowpan/nhc_ghc_icmpv6.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_udp.ko net/6lowpan/nhc_ghc_udp.o net/6lowpan/nhc_ghc_udp.mod.o;  true
make[2]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15/scripts/Makefile.modpost:140: __modpost] Error 2
make[1]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15/Makefile:1783: modules] Error 2
make[1]: Leaving directory '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/build'
make: *** [Makefile:219: __sub-make] Error 2
 * ERROR: sys-kernel/gentoo-kernel-5.15.5::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=sys-kernel/gentoo-kernel-5.15.5::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-kernel/gentoo-kernel-5.15.5::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15'
 * S: '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15'

>>> Failed to emerge sys-kernel/gentoo-kernel-5.15.5, Log file:

>>>  '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/temp/build.log'

 * Messages for package sys-kernel/gentoo-kernel-5.15.5:

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

The problem appears to be leaving multiple old sys-devel/binutils:

 sys-devel/binutils
    selected: 2.31.1-r3 2.32-r1 2.34 2.35.2  
   protected: none 
     omitted: 2.37_p1-r1

Removing the old versions of sys-devel/binutils 2.31.1-r3 2.32-r1 2.34 2.35.2 and leaving only the latest one solves the problem with the above error “unable to initialize decompress status for section .debug_info”.

emerge -vaC "<sys-devel/binutils-2.37_p1-r1"

Of course, an older version of sys-devel/binutils or a buggy one could lead to such an error! Update the sys-devel/binutils or change the version if the above error is hit.

Gentoo emerge virtualbox- Mesa / GLU: Mesa not found at, Mesa headers not found

Emerging the package app-emulation/virtualbox the following error occurs:

Checking for Mesa / GLU: 
  Mesa not found at -L/usr/X11R6/lib -L/usr/X11R6/lib64 -L/usr/local/lib -lXext -lX11 -lGL -I/usr/local/include or Mesa headers not found
  Check the file /var/tmp/portage/app-emulation/virtualbox-6.1.18/work/VirtualBox-6.1.18/configure.log for detailed error information.
Check /var/tmp/portage/app-emulation/virtualbox-6.1.18/work/VirtualBox-6.1.18/configure.log for details
 * ERROR: app-emulation/virtualbox-6.1.18::gentoo failed (configure phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line  125:  Called src_configure
 *   environment, line 5504:  Called doecho './configure' '--with-gcc=x86_64-pc-linux-gnu-gcc' '--with-g++=x86_64-pc-linux-gnu-g++' '--disable-dbus' '--disable-kmods' '--disable-alsa' '--disable-docs' '--disable-devmapper' '--disable-pulse' '--disable-python' '--enable-webservice' '--enable-vnc'
 *   environment, line 1538:  Called die
 * The specific snippet of code:
 *       "$@" || die

The configure script reports the mesa is missing, but the package media-libs/mesa is installed. Reinstalling does not fix the problem.
Farther investigation in the logs by checking the configure.log reveals the real problem:

srv ~ # tail -n 16 /var/tmp/portage/app-emulation/virtualbox-6.1.18/work/VirtualBox-6.1.18/configure.log
***** Checking Mesa / GLU *****
compiling the following source file:
#include <cstdio>
#include <X11/Xlib.h>
#include <GL/glx.h>
#include <GL/glu.h>
extern "C" int main(void)
{
  return 0;
}
using the following command line:
x86_64-pc-linux-gnu-g++  -fPIC -g -O -Wall -o /var/tmp/portage/app-emulation/virtualbox-6.1.18/work/VirtualBox-6.1.18/.tmp_out /var/tmp/portage/app-emulation/virtualbox-6.1.18/work/VirtualBox-6.1.18/.tmp_src.cc "-L/usr/X11R6/lib -L/usr/X11R6/lib64 -L/usr/local/lib -lXext -lX11 -lGL -I/usr/local/include"
/var/tmp/portage/app-emulation/virtualbox-6.1.18/work/VirtualBox-6.1.18/.tmp_src.cc:4:10: fatal error: GL/glu.h: No such file or directory
    4 | #include <GL/glu.h>
      |          ^~~~~~~~~~
compilation terminated.

The glu part of mesa is missing. In Gentoo, the glu (https://gitlab.freedesktop.org/mesa/glu) is not included in the media-libs/mesa and it is a separate package media-libs/glu.

The solution is to emerge media-libs/glu and then the app-emulation/virtualbox.

emerge -v media-libs/glu

Another Linux distribution may include glu in the main mesa package.

Here, the conclusion is to always check the configure.log, because it reports the exact error and not to trust the generic output of the configure script.

VBoxManage: error: Failed to initialize COM! NS_ERROR_FILE_TARGET_DOES_NOT_EXIST (0x80520006)

What an error! And the VirtualBox stopped loading anymore! This error:

myuser@srv ~ $ VBoxManage list vms
VBoxManage: error: Failed to initialize COM! (hrc=NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)

and here with the GIU, which offers a little bit more information about the error ID:
This error occurs despite the successfully loaded VirtualBox kernel modules!

main menu
VBoxManage: error: Failed to initialize COM! NS_ERROR_FILE_TARGET_DOES_NOT_EXIST (0x80520006)

The two errors are the same and hint there is a file missing (or files?)? In our case, after upgrading from virtualbox-bin (a binary package) to a virtualbox (a package, which actually builds the VirtualBox on the system) under Gentoo, but apparently, this error could occur to everyone, who tries to build yourself the VirtualBox bundle.

The solution is simple: just DO NOT CHANGE the installation path of the Virtualbox software, which by default is /opt/VirtualBox.

The path is hardcoded in the sources and cannot be changed! At present version 6.1.16, we could not find a build option to change it! Of course, the linking /opt/VirtualBox would do the trick to move the installation physically away from the /opt, but the path must be valid /opt/VirtualBox.

In Gentoo, the emerge default installation goes to “/usr/lib64/virtualbox“, so the maintainer of the package changed the path and Virtualbox stopped working! Or a user build it and install it in any other location should link the /opt/VirtualBox to the installation directory. For example, in Gentoo, the fix will be:

root@srv ~ $ ln -s /usr/lib64/virtualbox /opt/VirtualBox
root@srv ~ $ exit
myuser@srv ~ $ VBoxManage list vms
"gentoo_raw" {55346caf-04db-4d88-831a-111111111111}
"diskless" {44346caf-c952-5555-b8a3-111111111111}
"diskless-linux" {44346caf-424f-487f-ae8d-111111111111}
"centos7-netinstall" {44346caf-4e86-441b-8d1e-111111111111}

A simple link would bring back Virtualbox to live.

Bonus

Probably, there is a configuration file “xpti.dat” in two or more locations: ~/.config/VirtualBox/xpti.dat and ~/.VirtualBox/xpti.dat, which is generated on every start of a VirtualBox. In the file there are configuration lines like:
Keep on reading!

gentoo network interface with hyphen in the name

Using the OpenRC (i.e. init system) and network names with special symbols like hyphen in the name may lead to errors of “command not found” and “No such file or directory

The hyphen in the network interface name must be replaced in the configuration file with an underline and the init name file should be with the hyphen.

Proper configuration for network interface name with hyphen mv-eth0

  • In the configuration file /etc/conf.d/net:
    config_mv_eth0="
    192.168.0.202/24
    "
    routes_mv_eth0="
    default via 192.168.0.1
    "
    
  • The network interface init file is with hyphen:
    root@srv /etc/init.d # ln -s net.lo net.mv-eth0
    

And starting the network is successful:

root@srv ~ # /etc/init.d/net.mv-eth0 start
 * Caching service dependencies ...                                                                                                                                                     [ ok ]
 * Bringing up interface mv-eth0
 *   Caching network module dependencies
 *   192.168.0.202/24 ...                                                                                                                                                               [ ok ]
 *   Adding routes
 *     default via 192.168.0.1 ...                                                                                                                                                      [ ok ]
 *   Waiting for tentative IPv6 addresses to complete DAD (5 seconds) ..

Virtualization software may include to the network interface name not so typical alphabets. For example, systemd-nspawn will give name to the guest’s macvlan network with mv-{host_network_name} and iv-{host_network_name} for ipvlan.

Wrong configuration with a hyphen in the network interface name.

The configuration file /etc/conf.d/net:

config_mv-eth0="
192.168.0.202/24
"
routes_mv-eth0="
default via 192.168.0.1
"

Starting the network with such configuration will result in multiple errors:

root@srv ~ # /etc/init.d # /etc/init.d/net.mv-eth0 start
 * Caching service dependencies ...
/etc/init.d/../conf.d/net: line 3: config_mv-eth0=
192.168.0.202/24
: No such file or directory
/etc/init.d/../conf.d/net: line 6: $'routes_mv-eth0=\ndefault via 192.168.0.1\n': command not found
/etc/init.d/../conf.d/net: line 3: config_mv-eth0=
192.168.0.202/24
: No such file or directory
/etc/init.d/../conf.d/net: line 6: $'routes_mv-eth0=\ndefault via 192.168.0.1\n': command not found                                                                                  [ ok ]
/etc/init.d/../conf.d/net: line 3: config_mv-eth0=
192.168.0.202/24
: No such file or directory
/etc/init.d/../conf.d/net: line 6: $'routes_mv-eth0=\ndefault via 192.168.0.1\n': command not found
 * net.mv-eth0: error loading /etc/init.d/../conf.d/net
 * ERROR: net.mv-eth0 failed to start

Patch and resume compilation of a failed package in Gentoo – ebuild, local repository or ctrl+Z

A dependency package failed to compile throwing error and existing the emerge of a queue with a hundred and more packages. Or worse you installed a new version of a package and multiple rebuilds are pulled, but one of the dependencies fails and you may end up with a broken system? What can you do? There is no new version of the failed package and yes, there is a bug in the Gentoo’s Bugzilla – https://bugs.gentoo.org/. And there is a solution with a patch, which has not made its way to the production and in Gentoo portage yet.
The package in the portage is broken, no new fixed package is released, but there is a patch to fix your issue. Here is what you can do:

  • Make your own package with the fixed version of the original package and put it in your local repository (not the official one, because on every emerge –sync it will be deleted). You should make a local repository and put the ebuild and all necessary files.
  • Or just download the patch and patch the source in the directory, which still holds the source of the failed package and resume the compilation manually. Then install it. Using this tutorial – Resume installation after a package build error, when emerging firefox under Gentoo
  • Just after the uncompress operation of the emerge press CTRL+Z to put the operation in the background and download and patch. Then bring back the emerge from the background with “fg” command.

The second and third options are not permanent solutions, but they are fast enough to be used in some situations.
Here are steps for the first and second option you may have:

OPTION 1) Make your own package.

Create a local repository (for details Simple steps to create Gentoo custom repository and add a package):

root@srv ~ # mkdir -p /var/db/repos/my-local-portage/{metadata,profiles}
root@srv ~ # cat  << 'EOF' > /var/db/repos/my-local-portage/metadata/layout.conf
masters = gentoo
auto-sync = false
EOF
root@srv ~ # cat  << 'EOF' > /etc/portage/repos.conf/my-local-portage.conf
[my-local-portage]
location = /var/db/repos/my-local-portage 
EOF
root@srv ~ # cat  << 'EOF' > /var/db/repos/my-local-portage/profiles/repo_name
my-local-portage
EOF

Copy the ebuild file of the package you want to modify in the custom repository directory created above (it’s a good idea to copy all the sub-directories, too):
Keep on reading!