PID file path discrepancy for the clamd service in Gentoo Linux

Back in December I noticed that the OpenRC init script for clamd in Gentoo Linux reported the clamd service status as ‘crashed’, when in fact it was still running (I raised Gentoo Linux Bug Report 921088 to report this).

The issue arises because the init script (/etc/init.d/clamd) installed by the clamav ebuild specifies the PID file as /run/clamd.pid whereas the clamd.conf created by the ebuild specifies the PID file as /run/clamav/clamd.pid (it does this by uncommenting a line in the example clamd.conf file extracted from the downloaded clamav source code tarball). In the aforementioned Gentoo Linux bug report I assumed that the init script is incorrect and should be changed to specify the path /run/clamav/clamd.pid specified in the clamd.conf file. However, Gentoo Linux developer Michael Orlitzky stated that the PID file path given in the init script is secure whereas the path given in the config file is not, so the config file should be changed, not the init script. To date, the discrepancy remains in both the Gentoo stable version (1.2.2) and testing version (1.3.1) of the clamav ebuild in the Gentoo Linux ebuild repositories.

Until the ebuild is modified, to avoid the problem occurring I created a script in /etc/local.d/ for OpenRC to run at shutdown to ensure the PID file path is the same in the init script and config file, in case I forget to check this whenever a new version of clamav is installed. The script makes the PID file path in the config file match the file path in the init script, whether that be /run/clamd.pid or /run/clamav/clamd.pid. Obviously, if the former path is secure then that would be preferable, but I have no control over what the ebuild maintainer does, so the script caters for both situations. Anyway, the script I created is listed below.

root # cd /etc/local.d
root # nano 20-clamav.stop
root # chmod +x 20-clamav.stop
root # cat 20-clamav.stop
#!/bin/bash
#
# See Gentoo Bugzilla Bug 921088 for app-antivirus/clamav-1.2.1
# According to Comment 1, the content of /etc/init.d/clamd is correct as: pidfile="/run/${RC_SVCNAME}.pid"
# and the content of /etc/clamav/clamd.conf should be: PidFile /run/clamd.pid
#
# However, (~)clamav-1.3.1 has the following:
# /etc/init.d/clamd contains: pidfile="/run/${RC_SVCNAME}.pid"
# /etc/clamav/clamd.conf contains: PidFile /run/clamav/clamd.pid
#
# Therefore cater for either situation:
if `grep "pidfile=" /etc/init.d/clamd | grep -q clamav`; then
    sed -i 's|PidFile /run/clamd.pid|PidFile /run/clamav/clamd.pid|' /etc/clamav/clamd.conf
elif `grep "pidfile=" /etc/init.d/clamd | grep -q -v clamav`; then
    sed -i 's|PidFile /run/clamav/clamd.pid|PidFile /run/clamd.pid|' /etc/clamav/clamd.conf
fi

Upgrading the Portage Profile to 23.0 in Gentoo Linux (OpenRC) and merging /usr

This week I finally had some spare time to upgrade the Gentoo Linux Portage Profile from 17.1 to 23.0 (see Gentoo Linux News item of 22 March 2024 titled ‘Profile upgrade to version 23.0 available‘) in my two Gentoo Linux installations: one Stable (amd64), the other Testing (~amd64). Both installations use OpenRC and therefore they had a split /usr directory structure, as shown below for my Testing installation:

fitzcarraldo@meshedgedx ~ $ cd /
fitzcarraldo@meshedgedx ~ $ tree -L 1
.
├── bin
├── boot
├── cgroup
├── dev
├── etc
├── home
├── install-data
├── lib
├── lib64
├── lost+found
├── media
├── mnt
├── opt
├── proc
├── restartkde.sh
├── root
├── run
├── sbin
├── sys
├── tmp
├── unlock.sh
├── usr
└── var

22 directories, 2 files

(Ignore the two shell scripts shown in the output above; they are scripts I created.)

I followed the instructions in the above-mentioned Gentoo Linux News item, and had no trouble upgrading the profile in both installations, although the final step of merging the world set using the ‘--emptytree‘ option took three days (painful!) to rebuild the 1742 packages in my Testing installation and 1845 packages in my Stable installation. Both installations initially used the Portage profile ‘default/linux/amd64/17.1/desktop/plasma (stable)‘, so I needed to upgrade them to ‘default/linux/amd64/23.0/split-usr/desktop/plasma (stable)‘. The outcome of each step specified in the news item was as expected, so I will not bother to describe them here other than to mention that one non-essential application package failed to build in Step 16 (‘emerge --ask --emptytree @world‘) during the upgrade of my Stable installation. I uninstalled that package and then used the command ‘emerge --emptytree --resume --skipfirst‘ in order to complete the process.

The purpose of this post is to describe how I migrated the installations from the split /usr directory structure to the merged /usr structure after I had completed upgrading the Portage profile to 23.0. The /usr merging procedure gets rid of the separation of directories /bin and /usr/bin, /sbin and /usr/sbin, /lib and /usr/lib, and /lib64 and /usr/lib64. All the files in the directories in / (root) are merged into their respective counterparts in /usr, and symlinks for the old directories are created instead:

/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64

It is not mandatory to have the merged /usr structure in installations that use OpenRC, therefore I could have left the two installations with the split /usr structure after I had upgraded the Portage profile. However, as Linux installations that use systemd now only support the merged /usr structure, and as packages in Linux distributions that use systemd will be coded to use the merged /usr structure and may possibly be ported to Gentoo Linux at some point, I decided to migrate my installations to use the merged /usr structure. Below I describe how I did that in my Gentoo Linux Testing installation (see also the Gentoo Linux Wiki article merge-usr). The procedure was essentially the same for my Gentoo Linux Stable installation.

1. Install the merge-usr package

meshedgedx /home/fitzcarraldo # cd /
meshedgedx / # emerge --ask sys-apps/merge-usr

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

Calculating dependencies... done!
Dependency resolution took 15.62 s (backtrack: 0/20).

[ebuild  N     ] sys-apps/merge-usr-6  PYTHON_SINGLE_TARGET="python3_11 -python3_10 -python3_12" 

Would you like to merge these packages? [Yes/No] Yes
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-apps/merge-usr-6::gentoo
>>> Installing (1 of 1) sys-apps/merge-usr-6::gentoo
>>> Recording sys-apps/merge-usr in "world" favorites file...
>>> Completed (1 of 1) sys-apps/merge-usr-6::gentoo
>>> Jobs: 1 of 1 complete                           Load avg: 1.49, 1.34, 0.82

 * GNU info directory index is up-to-date.

2. Perform a dry run of the merge-usr script to check if there would be any problems migrating to the new structure

meshedgedx / # merge-usr --dryrun
INFO: Migrating files from '/bin' to '/usr/bin'
INFO: Skipping symlink '/bin/awk'; '/usr/bin/awk' already exists
INFO: No problems found for '/bin'
INFO: Migrating files from '/sbin' to '/usr/bin'
ERROR: Conflict for symlink '/sbin/lspci': [Errno 2] No such file or directory: '/sbin/lspci'
ERROR: Leaving '/sbin' as a directory due to prior errors
INFO: Migrating files from '/usr/sbin' to '/usr/bin'
INFO: No problems found for '/usr/sbin'
INFO: Migrating files from '/lib' to '/usr/lib'
ERROR: Conflict for special file '/lib/rc/init.d/exclusive/localmount': Special files are not supported
ERROR: Conflict for special file '/lib/rc/init.d/exclusive/net.lo': Special files are not supported
ERROR: Conflict for special file '/lib/rc/init.d/exclusive/checkfs': Special files are not supported
ERROR: Conflict for special file '/lib/rc/init.d/exclusive/modules': Special files are not supported
ERROR: Conflict for special file '/lib/splash/cache/.splash': Special files are not supported
ERROR: Leaving '/lib' as a directory due to prior errors
INFO: Migrating files from '/lib64' to '/usr/lib64'
INFO: No problems found for '/lib64'

The output above showed there were several problems.

3. Resolve all problems identified in the dry run

The first reported error related to /sbin/lspci, so I checked that file:

meshedgedx / # ls -la /sbin/lspci
lrwxrwxrwx 1 root root 15 Mar 30  2010 /sbin/lspci -> /usr/sbin/lspci

Both /sbin/lspci and /usr/sbin/lspci in the above output on screen were highlighted in red and flashing, indicating that /usr/sbin/lspci did not exist, so I deleted the symlink:

meshedgedx / # rm /sbin/lspci

I then re-ran the script to check that the first error had been resolved:

meshedgedx / # merge-usr --dryrun
INFO: Migrating files from '/bin' to '/usr/bin'
INFO: Skipping symlink '/bin/awk'; '/usr/bin/awk' already exists
INFO: No problems found for '/bin'
INFO: Migrating files from '/sbin' to '/usr/bin'
INFO: No problems found for '/sbin'
INFO: Migrating files from '/usr/sbin' to '/usr/bin'
INFO: No problems found for '/usr/sbin'
INFO: Migrating files from '/lib' to '/usr/lib'
ERROR: Conflict for special file '/lib/rc/init.d/exclusive/localmount': Special files are not supported
ERROR: Conflict for special file '/lib/rc/init.d/exclusive/net.lo': Special files are not supported
ERROR: Conflict for special file '/lib/rc/init.d/exclusive/checkfs': Special files are not supported
ERROR: Conflict for special file '/lib/rc/init.d/exclusive/modules': Special files are not supported
ERROR: Conflict for special file '/lib/splash/cache/.splash': Special files are not supported
ERROR: Leaving '/lib' as a directory due to prior errors
INFO: Migrating files from '/lib64' to '/usr/lib64'
INFO: No problems found for '/lib64'

Next I tackled the ‘special file’ error messages:

meshedgedx / # ls -la /lib/rc/init.d/exclusive/localmount
prw-r--r-- 1 root root 0 Dec  5  2005 /lib/rc/init.d/exclusive/localmount
meshedgedx / # ls -la /lib/rc/init.d/exclusive/net.lo
prw-r--r-- 1 root root 0 Dec  5  2005 /lib/rc/init.d/exclusive/net.lo
meshedgedx / # ls -la /lib/rc/init.d/exclusive/checkfs
prw-r--r-- 1 root root 0 Dec  5  2005 /lib/rc/init.d/exclusive/checkfs
meshedgedx / # ls -la /lib/rc/init.d/exclusive/modules
prw-r--r-- 1 root root 0 Dec  5  2005 /lib/rc/init.d/exclusive/modules
meshedgedx / # ls -la /lib/splash/cache/.splash 
prwx------ 1 root root 0 May 25  2012 /lib/splash/cache/.splash

The file /lib/splash/cache/.splash dated 2012 was associated with splashutils, which is no longer installed. The package is not in the Portage tree anymore either. So it was safe to delete it:

meshedgedx / # rm /lib/splash/cache/.splash

The other error messages all related to very old files in the /lib/rc/init.d/exclusive/ directory:

meshedgedx / # file /lib/rc/init.d/exclusive/localmount
/lib/rc/init.d/exclusive/localmount: fifo (named pipe)
meshedgedx / # file /lib/rc/init.d/exclusive/net.lo
/lib/rc/init.d/exclusive/net.lo: fifo (named pipe)
meshedgedx / # file /lib/rc/init.d/exclusive/checkfs 
/lib/rc/init.d/exclusive/checkfs: fifo (named pipe)
meshedgedx / # file /lib/rc/init.d/exclusive/modules 
/lib/rc/init.d/exclusive/modules: fifo (named pipe)

Those pipes were not used any more, so I deleted them all:

meshedgedx / # rm /lib/rc/init.d/exclusive/localmount /lib/rc/init.d/exclusive/net.lo /lib/rc/init.d/exclusive/checkfs /lib/rc/init.d/exclusive/modules

Another re-run of the script showed no problems should occur with the migration:

meshedgedx / # merge-usr --dryrun
INFO: Migrating files from '/bin' to '/usr/bin'
INFO: Skipping symlink '/bin/awk'; '/usr/bin/awk' already exists
INFO: No problems found for '/bin'
INFO: Migrating files from '/sbin' to '/usr/bin'
INFO: No problems found for '/sbin'
INFO: Migrating files from '/usr/sbin' to '/usr/bin'
INFO: No problems found for '/usr/sbin'
INFO: Migrating files from '/lib' to '/usr/lib'
INFO: No problems found for '/lib'
INFO: Migrating files from '/lib64' to '/usr/lib64'
INFO: No problems found for '/lib64'

I was therefore happy to go ahead with the migration.

4. Perform the migration

meshedgedx / # merge-usr
INFO: Migrating files from '/bin' to '/usr/bin'
INFO: Skipping symlink '/bin/awk'; '/usr/bin/awk' already exists
INFO: Replacing '/bin' with a symlink to 'usr/bin'
INFO: Migrating files from '/sbin' to '/usr/bin'
INFO: Replacing '/sbin' with a symlink to 'usr/bin'
INFO: Migrating files from '/usr/sbin' to '/usr/bin'
INFO: Replacing '/usr/sbin' with a symlink to 'bin'
INFO: Migrating files from '/lib' to '/usr/lib'
INFO: Replacing '/lib' with a symlink to 'usr/lib'
INFO: Migrating files from '/lib64' to '/usr/lib64'
INFO: Replacing '/lib64' with a symlink to 'usr/lib64'

As can be seen in the output below, the script successfully changed the directory structure to the required merged /usr structure:

meshedgedx / # tree -L 1
.
├── bin -> usr/bin
├── boot
├── cgroup
├── dev
├── etc
├── home
├── install-data
├── lib -> usr/lib
├── lib64 -> usr/lib64
├── lost+found
├── media
├── mnt
├── opt
├── proc
├── restartkde.sh
├── root
├── run
├── sbin -> usr/bin
├── sys
├── tmp
├── unlock.sh
├── usr
└── var

22 directories, 2 files

5. Change the Gentoo Linux 23.0 profile from the split-usr profile to the merged-usr profile

meshedgedx / # eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/23.0/split-usr/desktop/plasma
meshedgedx / # eselect profile list | grep plasma
  [8]   default/linux/amd64/17.1/desktop/plasma (stable)
  [9]   default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr (stable)
  [27]  default/linux/amd64/23.0/desktop/plasma (stable)
  [28]  default/linux/amd64/23.0/desktop/plasma/systemd (stable)
  [48]  default/linux/amd64/23.0/split-usr/desktop/plasma (stable) *
meshedgedx / # eselect profile set 27
meshedgedx / # eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/23.0/desktop/plasma

6. Upgrade the Portage world set to take into account the new Portage profile with USE="-split-usr"

meshedgedx / # emerge -uDN @world
Calculating dependencies... done!
Dependency resolution took 153.98 s (backtrack: 0/20).

>>> Verifying ebuild manifests
>>> Emerging (1 of 12) sys-apps/baselayout-2.15::gentoo
>>> Emerging (2 of 12) dev-libs/lzo-2.10::gentoo
>>> Emerging (3 of 12) app-alternatives/bzip2-1::gentoo
>>> Emerging (4 of 12) app-alternatives/gzip-1::gentoo
>>> Emerging (5 of 12) app-alternatives/cpio-0::gentoo
>>> Installing (1 of 12) sys-apps/baselayout-2.15::gentoo
>>> Completed (1 of 12) sys-apps/baselayout-2.15::gentoo
>>> Installing (3 of 12) app-alternatives/bzip2-1::gentoo
>>> Completed (3 of 12) app-alternatives/bzip2-1::gentoo
>>> Installing (4 of 12) app-alternatives/gzip-1::gentoo
>>> Completed (4 of 12) app-alternatives/gzip-1::gentoo
>>> Installing (5 of 12) app-alternatives/cpio-0::gentoo
>>> Completed (5 of 12) app-alternatives/cpio-0::gentoo
>>> Installing (2 of 12) dev-libs/lzo-2.10::gentoo
>>> Completed (2 of 12) dev-libs/lzo-2.10::gentoo
>>> Emerging (6 of 12) app-alternatives/tar-0::gentoo
>>> Installing (6 of 12) app-alternatives/tar-0::gentoo
>>> Completed (6 of 12) app-alternatives/tar-0::gentoo
>>> Emerging (7 of 12) sys-apps/kmod-32-r1::gentoo
>>> Installing (7 of 12) sys-apps/kmod-32-r1::gentoo
>>> Completed (7 of 12) sys-apps/kmod-32-r1::gentoo
>>> Emerging (8 of 12) app-alternatives/awk-4::gentoo
>>> Installing (8 of 12) app-alternatives/awk-4::gentoo
>>> Completed (8 of 12) app-alternatives/awk-4::gentoo
>>> Emerging (9 of 12) sys-apps/coreutils-9.5::gentoo
>>> Installing (9 of 12) sys-apps/coreutils-9.5::gentoo
>>> Completed (9 of 12) sys-apps/coreutils-9.5::gentoo
>>> Emerging (10 of 12) sys-apps/systemd-utils-254.10-r1::gentoo
>>> Installing (10 of 12) sys-apps/systemd-utils-254.10-r1::gentoo
>>> Completed (10 of 12) sys-apps/systemd-utils-254.10-r1::gentoo
>>> Emerging (11 of 12) sys-libs/ncurses-6.4_p20240414::gentoo
>>> Installing (11 of 12) sys-libs/ncurses-6.4_p20240414::gentoo
>>> Completed (11 of 12) sys-libs/ncurses-6.4_p20240414::gentoo
>>> Emerging (12 of 12) sys-apps/shadow-4.14.6::gentoo
>>> Installing (12 of 12) sys-apps/shadow-4.14.6::gentoo
>>> Completed (12 of 12) sys-apps/shadow-4.14.6::gentoo
>>> Jobs: 12 of 12 complete                         Load avg: 2.01, 2.41, 2.39

 * GNU info directory index is up-to-date.
 * After world updates, it is important to remove obsolete packages with
 * emerge --depclean. Refer to `man emerge` for more information.
meshedgedx / # emerge --ask --depclean

 * Always study the list of packages to be cleaned for any obvious
 * mistakes. Packages that are part of the world set will always
 * be kept.  They can be manually added to this set with
 * `emerge --noreplace `.  Packages that are listed in
 * package.provided (see portage(5)) will be removed by
 * depclean, even if they are part of the world set.
 * 
 * As a safety measure, depclean will not remove any packages
 * unless *all* required dependencies have been resolved.  As a
 * consequence of this, it often becomes necessary to run 
 * `emerge --update --newuse --deep @world` prior to depclean.

Calculating dependencies... done!
>>> No packages selected for removal by depclean
>>> To see reverse dependencies, use --verbose
Packages installed:   1742
Packages in world:    323
Packages in system:   49
Required packages:    1742
Number removed:       0

7. Reboot to check that everything works as expected

meshedgedx / # reboot

Job complete.

The migration process in my Gentoo Linux Stable installation was essentially the same as for my Testing installation, except that the dry run of the merge-usr script did not flag any problems and therefore I was able to proceed with the migration without having to make any changes.

Migrating the ebuild repository locations in my Gentoo Linux installations to the current defaults

I installed Gentoo Linux on my two laptops in 2010 and 2015 respectively, long before the distribution’s developers changed the default locations of the repositories for ebuilds and packages in an installation. In 2023 I modified the two installations to use an eselect module instead of the superseded Layman overlay manager (see my earlier post ‘Layman overlay manager in Gentoo Linux superseded by eselect module‘), and the installations continued to function normally. In 2019 the distribution’s developers changed the default locations for the PORTDIR, DISTDIR, REPO_NAME and REPO_BASEDIR directories, although I do not recall seeing any notifications about the change or instructions on how to migrate the repository locations in existing installations. Anyway, today I decided to bite the bullet and migrate the repository locations in my two installations to the latest defaults specified by the developers. The old and new directories are listed in Gentoo Wiki article ‘Default Gentoo ebuild repository location change‘:

Old location
CODE Location before 2019-04-29

REPO_BASEDIR="/usr"
REPO_NAME="portage"
DISTDIR="/usr/portage/distfiles"
PORTDIR="/usr/portage"
TARGET_DISTDIR="/usr/portage/distfiles"
TARGET_PKGDIR="/usr/portage/packages"

New location
CODE Location as of 2019-04-29 and later

REPO_BASEDIR="/var/db/repos"
REPO_NAME="gentoo"
DISTDIR="/var/cache/distfiles"
PORTDIR="/var/db/repos/gentoo"
TARGET_DISTDIR="/var/cache/distfiles"
TARGET_PKGDIR="/var/cache/binpkgs"

The file /etc/portage/make.conf in one of my installations contained the following pertinent variables:

root # grep DIR /etc/portage/make.conf
PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages"
PORTDIR_OVERLAY="/usr/local/portage ${PORTDIR_OVERLAY}"
PORT_LOGDIR="/var/log/portage"

The repos.conf files contained:

root # cat /etc/portage/repos.conf/eselect-repo.conf
# created by eselect-repo

[guru]
location = /var/db/repos/guru
sync-type = git
sync-uri = https://anongit.gentoo.org/git/repo/proj/guru.git

[torbrowser]
location = /var/db/repos/torbrowser
sync-type = git
sync-uri = https://github.com/gentoo-mirror/torbrowser.git
root # cat /etc/portage/repos.conf/local_overlay.conf 
[local_overlay]
location = /usr/local/portage
masters = gentoo
auto-sync = no

I set about migrating the repository directories to the new default locations using the following steps:

1. I checked what was the current profile

root # eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/17.1/desktop/plasma

2. I commented out any PORTDIR, DISTDIR, PKGDIR, PORTDIR_OVERLAY and PORT_LOGDIR entries in /etc/portage/make.conf (man make.conf(5) states that PORTDIR, PORTDIR_OVERLAY and PORT_LOGDIR are deprecated anyway).

3. The directory /var/db/repos/ already existed, so I did not need to create it (I would have created it had it not already existed)

root # ls /var/db/repos/
guru  seden  torbrowser

4. I moved /usr/portage/distfiles/ to /var/cache/distfiles/

root # mv /usr/portage/distfiles /var/cache

5. There was no directory /usr/portage/packages/ in one of the installations, so I did not need to move it to /var/cache/binpkgs/ but I created the latter directory

root # mkdir /var/cache/binpkgs

In the other installation I moved /usr/portage/packages/ to /var/cache/binpkgs/

root # mv /usr/portage/packages /var/cache/binpkgs

6. I moved /usr/portage/ to /var/db/repos/gentoo/

root # mv /usr/portage /var/db/repos/gentoo

So now /var/db/repos/ contained directories with the ebuilds for the main Portage tree and for the third-party overlays:

root # ls /var/db/repos
gentoo  guru  seden  torbrowser

7. I moved /usr/local/portage/ to /var/db/repos/local/

root # mv /usr/local/portage /var/db/repos/local

The ebuild repositories for the main tree, third-party overlays and my local overlay have now all been moved:

root # ls /var/db/repos
gentoo  guru  local  seden  torbrowser

8. I edited the location variable in /etc/portage/repos.conf/gentoo.conf to contain ‘/var/db/repos/gentoo

root # grep location /etc/portage/repos.conf/gentoo.conf
location = /usr/portage
root # nano /etc/portage/repos.conf/gentoo.conf
root # grep location /etc/portage/repos.conf/gentoo.conf 
location = /var/db/repos/gentoo

9. I edited the location variable in /etc/portage/repos.conf/local_overlay.conf to contain ‘/var/db/repos/local

root # grep location /etc/portage/repos.conf/local_overlay.conf 
location = /usr/local/portage
root # nano /etc/portage/repos.conf/local_overlay.conf 
root # grep location /etc/portage/repos.conf/local_overlay.conf 
location = /var/db/repos/local

10. The location variable in the only other files in directory /etc/portage/repos.conf/ was already set to the correct location, otherwise I would have edited that too

root # ls /etc/portage/repos.conf/
eselect-repo.conf  eselect-repo.conf~  gentoo.conf  local_overlay.conf
root # grep location /etc/portage/repos.conf/eselect-repo.conf*
/etc/portage/repos.conf/eselect-repo.conf:location = /var/db/repos/guru
/etc/portage/repos.conf/eselect-repo.conf:location = /var/db/repos/torbrowser
/etc/portage/repos.conf/eselect-repo.conf~:location = /var/db/repos/guru
/etc/portage/repos.conf/eselect-repo.conf~:location = /var/db/repos/torbrowser

11. I edited any files that I found in /etc/portage/ and in its sub-directories that referenced the old locations

root # grep DIR /etc/portage/make.conf.catalyst
PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages"
root # nano /etc/portage/make.conf.catalyst
root # grep DIR /etc/portage/make.conf.catalyst
PORTDIR="/var/db/repos/gentoo"
DISTDIR="/var/cache/distfiles"
PKGDIR="/var/cache/binpkgs"
root # grep DIR /etc/portage/make.conf
#PORTDIR="/usr/portage"
#DISTDIR="${PORTDIR}/distfiles"
#PKGDIR="${PORTDIR}/packages"
#PORTDIR_OVERLAY="/usr/local/portage ${PORTDIR_OVERLAY}"
#PORT_LOGDIR="/var/log/portage"
root # nano /etc/portage/make.conf
root # grep DIR /etc/portage/make.conf
PORTDIR="/var/db/repos/gentoo"
DISTDIR="/var/cache/distfiles"
PKGDIR="/var/cache/binpkgs"
#PORTDIR_OVERLAY=""  <<<< Deprecated (see man make.conf)
#PORT_LOGDIR=""  <<<< Deprecated (see man make.conf)

12. I reinstated the profile symlink previously ascertained in Step 1 earlier

root # eselect profile list
realpath: /etc/portage/make.profile: No such file or directory
Available profile symlink targets:
  [1]   default/linux/amd64/17.1 (stable)
  [2]   default/linux/amd64/17.1/selinux (stable)
  [3]   default/linux/amd64/17.1/hardened (stable)
  [4]   default/linux/amd64/17.1/hardened/selinux (stable)
  [5]   default/linux/amd64/17.1/desktop (stable)
  [6]   default/linux/amd64/17.1/desktop/gnome (stable)
  [7]   default/linux/amd64/17.1/desktop/gnome/systemd (stable)
  [8]   default/linux/amd64/17.1/desktop/gnome/systemd/merged-usr (stable)
  [9]   default/linux/amd64/17.1/desktop/plasma (stable)
  [10]  default/linux/amd64/17.1/desktop/plasma/systemd (stable)
  [11]  default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr (stable)
  [12]  default/linux/amd64/17.1/desktop/systemd (stable)
  [13]  default/linux/amd64/17.1/desktop/systemd/merged-usr (stable)
  [14]  default/linux/amd64/17.1/developer (exp)
  [15]  default/linux/amd64/17.1/no-multilib (stable)
  [16]  default/linux/amd64/17.1/no-multilib/hardened (stable)
  [17]  default/linux/amd64/17.1/no-multilib/hardened/selinux (stable)
  [18]  default/linux/amd64/17.1/no-multilib/systemd (dev)
  [19]  default/linux/amd64/17.1/no-multilib/systemd/merged-usr (dev)
  [20]  default/linux/amd64/17.1/no-multilib/systemd/selinux (exp)
  [21]  default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr (exp)
  [22]  default/linux/amd64/17.1/systemd (stable)
  [23]  default/linux/amd64/17.1/systemd/merged-usr (stable)
  [24]  default/linux/amd64/17.1/systemd/selinux (exp)
  [25]  default/linux/amd64/17.1/systemd/selinux/merged-usr (exp)
  [26]  default/linux/amd64/17.1/clang (exp)
  [27]  default/linux/amd64/17.1/systemd/clang (exp)
  [28]  default/linux/amd64/17.1/systemd/clang/merged-usr (exp)
  [29]  default/linux/amd64/17.0/x32 (dev)
  [30]  default/linux/amd64/17.0/x32/systemd (exp)
  [31]  default/linux/amd64/17.0/x32/systemd/merged-usr (exp)
  [32]  default/linux/amd64/17.0/musl (dev)
  [33]  default/linux/amd64/17.0/musl/clang (exp)
  [34]  default/linux/amd64/17.0/musl/hardened (exp)
  [35]  default/linux/amd64/17.0/musl/hardened/selinux (exp)
root # eselect profile set 9
root # eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/17.1/desktop/plasma

13. I reinstalled Portage for the new repository locations

root # DISTDIR=/var/cache/distfiles PKGDIR=/var/cache/binpkgs emerge -1v portage

14. That completed the migration. I then rebooted and performed the usual ebuild repository update and package upgrade as shown in an earlier post.

Investigating an OpenVPN connection problem in Gentoo Linux and Lubuntu 22.04 but not in Android 13

Back in 2020 I successfully used OpenVPN to access a remote server from my laptop and from my smartphone. Fast forward to 2023 and I needed to use OpenVPN again to access the same remote server. I could again access the remote server when connecting from my smartphone, now running Android 13, using the OpenVPN client app. However, when I tried to use OpenVPN from my laptop running Gentoo Linux, and from my desktop machine running Lubuntu 22.04, VPN connection attempts always timed out. The OpenVPN client configuration file (referred to generically as ‘client.ovpn‘ in some articles, named ‘bsf1.ovpn‘ in my case) and the OpenVPN password were both correct, so I did not understand why a connection could not be established from the laptop and desktop machine to the remote server, especially as there was not a problem connecting from my smartphone running Android 13.

I use KDE in Gentoo Linux, and Lubuntu 22.04 uses LXQt. In both those Desktop Environments I used the relevant GUI front-end to NetworkManager to import the client.ovpn file and to try to connect to the VPN server. As these connection attempts had failed, I launched the OpenVPN client from the command line in Gentoo Linux to see if there were any error messages, and the output is shown below. (For privacy reasons I have annonimised my public IP address, domain, e-mail address, country, location and organisation in all the command line output shown in this post.)

root # openvpn --config bsf1.ovpn
2023-09-30 01:07:02 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-09-30 01:07:02 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2023-09-30 01:07:02 OpenVPN 2.6.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2023-09-30 01:07:02 library versions: OpenSSL 3.0.10 1 Aug 2023, LZO 2.10
2023-09-30 01:07:02 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Enter Private Key Password:
2023-09-30 01:08:57 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-09-30 01:08:58 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:08:58 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:08:58 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2023-09-30 01:08:58 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=fc150984 3a9d3b4f
2023-09-30 01:08:58 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:08:58 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:08:58 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:08:58 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:08:58 TLS Error: TLS handshake failed
2023-09-30 01:08:58 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:08:58 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:08:58 Restart pause, 1 second(s)
2023-09-30 01:08:59 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:08:59 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:08:59 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:08:59 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=00c193e4 f375c3df
2023-09-30 01:08:59 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:08:59 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:08:59 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:08:59 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:08:59 TLS Error: TLS handshake failed
2023-09-30 01:08:59 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:08:59 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:08:59 Restart pause, 1 second(s)
2023-09-30 01:09:00 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:00 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:00 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:00 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=415fddcd dc5faf65
2023-09-30 01:09:01 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:01 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:01 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:01 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:01 TLS Error: TLS handshake failed
2023-09-30 01:09:01 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:01 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:01 Restart pause, 1 second(s)
2023-09-30 01:09:02 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:02 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:02 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:02 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=1458e510 821d0c37
2023-09-30 01:09:02 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:02 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:02 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:02 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:02 TLS Error: TLS handshake failed
2023-09-30 01:09:02 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:02 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:02 Restart pause, 1 second(s)
2023-09-30 01:09:03 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:03 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:03 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:03 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=9ab3df76 86d3e81d
2023-09-30 01:09:03 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:03 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:03 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:03 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:03 TLS Error: TLS handshake failed
2023-09-30 01:09:03 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:03 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:03 Restart pause, 2 second(s)
2023-09-30 01:09:05 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:05 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:05 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:05 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=9f21e4f5 a4d9fecb
2023-09-30 01:09:05 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:05 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:05 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:05 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:05 TLS Error: TLS handshake failed
2023-09-30 01:09:05 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:05 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:05 Restart pause, 4 second(s)
2023-09-30 01:09:09 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:10 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:10 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:10 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=bb6d7166 52844953
2023-09-30 01:09:10 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:10 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:10 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:10 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:10 TLS Error: TLS handshake failed
2023-09-30 01:09:10 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:10 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:10 Restart pause, 8 second(s)
2023-09-30 01:09:18 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:18 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:18 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:18 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:19 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:19 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:19 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:19 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=099e3b11 8ddc87c1
2023-09-30 01:09:19 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:19 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:19 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:19 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:19 TLS Error: TLS handshake failed
2023-09-30 01:09:19 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:19 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:19 Restart pause, 16 second(s)
2023-09-30 01:09:35 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:35 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:35 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:35 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=38ffac21 50e59cc4
2023-09-30 01:09:35 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:35 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:35 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:35 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:35 TLS Error: TLS handshake failed
2023-09-30 01:09:35 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:35 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:35 Restart pause, 32 second(s)
^C

The error message ‘TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled.‘ made me suspect that the version of the OpenSSL package (which also provides TLS) in Gentoo Linux on my laptop is incompatible with the version of the OpenSSL package on the remote server.

The command line output in Lubuntu 22.04 on the desktop machine also showed there was a problem with TLS when I tried to launch the VPN client:

user $ sudo openvpn --config bsf1.ovpn
[sudo] password for fitzcarraldo: 
2023-10-03 14:00:43 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-10-03 14:00:43 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2023-10-03 14:00:43 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 14 2022
2023-10-03 14:00:43 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2023-10-03 14:00:43 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
🔐 Enter Private Key Password: ************            
2023-10-03 14:00:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-10-03 14:00:48 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:48 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:48 RESOLVE: Cannot resolve host address: bsfitzgerald.ddns.net:1194 (Temporary failure in name resolution)
2023-10-03 14:00:48 RESOLVE: Cannot resolve host address: bsfitzgerald.ddns.net:1194 (Temporary failure in name resolution)
2023-10-03 14:00:48 Could not determine IPv4/IPv6 protocol
2023-10-03 14:00:48 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2023-10-03 14:00:48 SIGUSR1[soft,init_instance] received, process restarting
2023-10-03 14:00:48 Restart pause, 5 second(s)
2023-10-03 14:00:53 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-10-03 14:00:53 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:53 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:55 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-10-03 14:00:55 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-10-03 14:00:55 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194 [nonblock]
2023-10-03 14:00:55 TCP connection established with [AF_INET]111.222.333.444:1194
2023-10-03 14:00:55 TCP_CLIENT link local: (not bound)
2023-10-03 14:00:55 TCP_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-10-03 14:00:56 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=c3ec9433 c4139af0
2023-10-03 14:00:57 VERIFY OK: depth=1, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:00:57 VERIFY OK: depth=0, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:00:58 OpenSSL: error:0A0C0103:SSL routines::internal error
2023-10-03 14:00:58 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-03 14:00:58 TLS Error: TLS object -> incoming plaintext read error
2023-10-03 14:00:58 TLS Error: TLS handshake failed
2023-10-03 14:00:58 Fatal TLS error (check_tls_errors_co), restarting
2023-10-03 14:00:58 SIGUSR1[soft,tls-error] received, process restarting
2023-10-03 14:00:58 Restart pause, 5 second(s)
2023-10-03 14:01:03 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-10-03 14:01:03 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:03 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:03 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:03 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-10-03 14:01:03 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194 [nonblock]
2023-10-03 14:01:03 TCP connection established with [AF_INET]111.222.333.444:1194
2023-10-03 14:01:03 TCP_CLIENT link local: (not bound)
2023-10-03 14:01:03 TCP_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:03 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=486e45aa bbf5d0b0
2023-10-03 14:01:05 VERIFY OK: depth=1, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:05 VERIFY OK: depth=0, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:05 OpenSSL: error:0A0C0103:SSL routines::internal error
2023-10-03 14:01:05 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-03 14:01:05 TLS Error: TLS object -> incoming plaintext read error
2023-10-03 14:01:05 TLS Error: TLS handshake failed
2023-10-03 14:01:05 Fatal TLS error (check_tls_errors_co), restarting
2023-10-03 14:01:05 SIGUSR1[soft,tls-error] received, process restarting
2023-10-03 14:01:05 Restart pause, 5 second(s)
2023-10-03 14:01:10 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-10-03 14:01:10 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:10 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:10 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:10 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-10-03 14:01:10 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194 [nonblock]
2023-10-03 14:01:10 TCP connection established with [AF_INET]111.222.333.444:1194
2023-10-03 14:01:10 TCP_CLIENT link local: (not bound)
2023-10-03 14:01:10 TCP_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:11 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=2523066e a7169e23
2023-10-03 14:01:12 VERIFY OK: depth=1, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:12 VERIFY OK: depth=0, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:13 OpenSSL: error:0A0C0103:SSL routines::internal error
2023-10-03 14:01:13 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-03 14:01:13 TLS Error: TLS object -> incoming plaintext read error
2023-10-03 14:01:13 TLS Error: TLS handshake failed
2023-10-03 14:01:13 Fatal TLS error (check_tls_errors_co), restarting
2023-10-03 14:01:13 SIGUSR1[soft,tls-error] received, process restarting
2023-10-03 14:01:13 Restart pause, 5 second(s)
^C

The version of OpenSSL currently running on the remote server is as follows:

user $ openssl version
OpenSSL 1.0.2l  25 May 2017

whereas the version of OpenSSL currently running in Gentoo Linux on the laptop is:

user $ openssl version
OpenSSL 3.0.10 1 Aug 2023 (Library: OpenSSL 3.0.10 1 Aug 2023)

and the version of OpenSSL currently running in Lubuntu 22.04 on the desktop machine is:

user $ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

The last time I successfully used the OpenVPN client on the laptop was in 2020, when the version of OpenSSL on the laptop was 1.1.1g, so my suspicion grew that the root cause of the problem is a version difference in OpenSSL between the client machine and the remote server.

I searched the Web and found OpenVPN bug report #348: ‘2.6 client cannot connect to old 2.2 and 2.1 server‘. Therefore I tried adding the following three lines to the client.ovpn file (bsf1.ovpn) in Gentoo Linux:

tls-cert-profile insecure
providers legacy default
compat-mode 1.1.1

Now the laptop can connect to the remote VPN server via the command line in a terminal window, as shown in the output below:

root # openvpn --config bsf1.ovpn
2023-09-30 03:13:26 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-09-30 03:13:26 OpenVPN 2.6.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2023-09-30 03:13:26 library versions: OpenSSL 3.0.10 1 Aug 2023, LZO 2.10
2023-09-30 03:13:26 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Enter Private Key Password:
2023-09-30 03:13:33 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-09-30 03:13:33 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 03:13:33 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 TCPv4_CLIENT link local: (not bound)
2023-09-30 03:13:33 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2023-09-30 03:13:33 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=4103e161 8493e221
2023-09-30 03:13:34 VERIFY OK: depth=1, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-09-30 03:13:34 VERIFY OK: depth=0, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-09-30 03:13:35 Control Channel: TLSv1, cipher SSLv3 DHE-RSA-AES256-SHA, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2023-09-30 03:13:35 [server] Peer Connection Initiated with [AF_INET]111.222.333.444:1194
2023-09-30 03:13:35 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-09-30 03:13:35 TLS: tls_multi_process: initial untrusted session promoted to trusted
2023-09-30 03:13:36 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2023-09-30 03:13:36 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-options DNS 8.8.8.8,route-gateway 10.10.1.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.10.1.4 255.255.255.0'
2023-09-30 03:13:36 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:2: dhcp-options (2.6.4)
2023-09-30 03:13:36 OPTIONS IMPORT: --ifconfig/up options modified
2023-09-30 03:13:36 OPTIONS IMPORT: route options modified
2023-09-30 03:13:36 OPTIONS IMPORT: route-related options modified
2023-09-30 03:13:36 Using peer cipher 'AES-128-CBC'
2023-09-30 03:13:36 net_route_v4_best_gw query: dst 0.0.0.0
2023-09-30 03:13:36 net_route_v4_best_gw result: via 192.168.96.245 dev wlp3s0
2023-09-30 03:13:36 ROUTE_GATEWAY 192.168.96.245/255.255.255.0 IFACE=wlp3s0 HWADDR=d8:fc:93:c5:f4:6d
2023-09-30 03:13:36 TUN/TAP device tun0 opened
2023-09-30 03:13:36 net_iface_mtu_set: mtu 1500 for tun0
2023-09-30 03:13:36 net_iface_up: set tun0 up
2023-09-30 03:13:36 net_addr_v4_add: 10.10.1.4/24 dev tun0
2023-09-30 03:13:36 net_route_v4_add: 111.222.333.444/32 via 192.168.96.245 dev [NULL] table 0 metric -1
2023-09-30 03:13:36 net_route_v4_add: 0.0.0.0/1 via 10.10.1.1 dev [NULL] table 0 metric -1
2023-09-30 03:13:36 net_route_v4_add: 128.0.0.0/1 via 10.10.1.1 dev [NULL] table 0 metric -1
2023-09-30 03:13:36 UID set to nobody
2023-09-30 03:13:36 GID set to nogroup
2023-09-30 03:13:36 Capabilities retained: CAP_NET_ADMIN
2023-09-30 03:13:36 Initialization Sequence Completed
2023-09-30 03:13:36 Data Channel: cipher 'AES-128-CBC', auth 'SHA256', compression: 'lzo'
2023-09-30 03:13:36 Timers: ping 10, ping-restart 12
[...]

and I can access the SMB shares on the remote server by entering ‘smb://192.168.0.10‘ in the Dolphin file manager’s window in KDE on the laptop.

However, if I terminate the openvpn client on the command line and then import the modified bsf1.ovpn file into NetworkManager using plasma-nm (the KDE GUI front-end to NetworkManager), connection attempts to the VPN still time out. The created NetworkManager connection file /etc/NetworkManager/system-connections/bsf1.nmconnection does not contain the settings in the additional three lines that I added to the client.ovpn file, as apparently they are meaningless to NetworkManager. When I use the plasma-nm GUI to import the client.ovpn file I assume plasma-nm or NetworkManager simply ignore the additional three lines when they parse the configuration file.

In Lubuntu 22.04 I edited bsf1.ovpn to add the three lines:

tls-cert-profile insecure
providers legacy default
compat-mode 1.1.1

and launched the openvpn client from the command line, but OpenVPN objected to the compat-mode line:

user $ sudo openvpn --config wjh1.ovpn
Options error: Unrecognized option or missing or extra parameter(s) in bsf1.ovpn:93: compat-mode (2.5.5)
Use --help for more information.

For the openvpn client command to execute successfully in Lubuntu 22.04 I had to omit the line ‘compat-mode 1.1.1‘, i.e. the two manually-added lines to bsf1.ovpn in Lubuntu 22.04 are:

tls-cert-profile insecure
providers legacy default

In my situation (i.e. the client is using OpenSSL 3.x.x in Lubuntu 22.04 and the remote server is using OpenSSL 1.x.x) the VPN connection still times out when attempting to connect using the GUI front-end (nm-tray or nm-applet) to NetworkManager in LXQt, so the work-around is still to launch the OpenVPN client from the command line as already explained:

user $ openvpn --conf bsf1.ovpn

and I can access the SMB shares on the remote server by entering ‘smb://192.168.0.10‘ in the PCManFM-Qt file manager’s window in LXQt on the desktop machine.

The remaining question I had was why my Samsung Galaxy Note 20 Ultra 5G running Android 13 can connect to the remote server via OpenVPN. I suspected that Android 13 uses an earlier version of OpenSSL that is compatible with the version on the remote server. A little research online showed me that Android 13 (and a couple of previous versions of Android) uses a Google fork of OpenSSL called BoringSSL. So, to find the version of OpenSSL/BoringSSL in Android 13, I cloned the BoringSSL repository on my laptop:

user $ git clone https://android.googlesource.com/platform/external/boringssl

and then I searched for the environment variable OPENSSL_VERSION_TEXT:

user $ grep -r OPENSSL_VERSION_TEXT boringssl/*
boringssl/include/openssl/crypto.h:// OPENSSL_VERSION_TEXT contains a string the identifies the version of
boringssl/include/openssl/crypto.h:#define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1 (compatible; BoringSSL)"
boringssl/src/include/openssl/crypto.h:// OPENSSL_VERSION_TEXT contains a string the identifies the version of
boringssl/src/include/openssl/crypto.h:#define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1 (compatible; BoringSSL)"
boringssl/src/crypto/crypto_test.cc:// Test that OPENSSL_VERSION_NUMBER and OPENSSL_VERSION_TEXT are consistent.
boringssl/src/crypto/crypto_test.cc:// Node.js parses the version out of OPENSSL_VERSION_TEXT instead of using
boringssl/src/crypto/crypto_test.cc:            std::string(OPENSSL_VERSION_TEXT).substr(0, strlen(expected)));

As I had surmised, OpenSSL (well, the fork BoringSSL) in Android 13 is Version 1.1.1. That is why the original bsf1.ovpn still works with the OpenVPN client on my phone to access the OpenVPN server running on the remote server.

By the way, in order to use OpenVPN in Lubuntu 22.04, you need to install the following three Ubuntu packages:

openvpn
network-manager-openvpn
network-manager-openvpn-gnome (despite Lubuntu using LXQt rather than GNOME)

The NetworkManager GUI front-end nm-tray does not support password asking, so you need to use the NetworkManager GUI front-end nm-applet to connect to the VPN (assuming both client and server have compatible versions of OpenSSL, that is). You can either type ‘nm-applet‘ on the command line or you can switch to using nm-applet instead of nm-tray by deselecting nm-tray in LXQt ‘Application Menu’ > ‘Preferences’ > ‘LXQt Settings’ > ‘Session Settings’ > ‘Autostart’ and adding nm-applet to the Autostart list. See Lubuntu Manual Appendix G Advanced Networking for further details. As already mentioned, in my situation the client is using OpenSSL 3.x.x and the server is using OpenSSL 1.x.x so the VPN connection still times out, therefore the work-around is still to launch openvpn from the command line:

user $ openvpn --conf bsf1.ovpn

To summarise my situation:

On my smartphone running Android 13 I simply use the OpenVPN client app for Android with the original client.ovpn configuration file (named ‘bsf1.ovpn‘ in my case) in order to connect to the VPN server on the remote server running OpenSSL 1.0.2l.

In Gentoo Linux currently running OpenSSL 3.0.10, I have to edit the original client.ovpn configuration file and add three lines, then launch the openvpn client from the command line in a terminal window in order to connect to the VPN server on the remote server running OpenSSL 1.0.2l.

In Lubuntu 22.04 currently running OpenSSL 3.0.2, I have to edit the original client.ovpn configuration file and add two lines, then launch the openvpn client from the command line in a terminal window in order to connect to the VPN server on the remote server running OpenSSL 1.0.2l.

The bottom line is: To avoid problems, check you have the same version of OpenSSL installed in the client and server devices when using OpenVPN.

Layman overlay manager in Gentoo Linux superseded by eselect module

Last week, when upgrading the world packages on my machines running Gentoo Linux, I noticed that the package for the Layman overlay manager app-portage/layman is masked for removal:

root # eix -I layman
[?] app-portage/layman
     Available versions:  [M]2.4.3^t [M]**9999*l^t {cvs darcs g-sorcery +git gpg mercurial sqlite squashfs subversion sync-plugin-portage test PYTHON_TARGETS="pypy3 python3_10 python3_11"}
     Installed versions:  2.4.3^t(00:28:13 04/05/23)(git sync-plugin-portage -cvs -darcs -g-sorcery -gpg -mercurial -sqlite -squashfs -subversion -test PYTHON_TARGETS="python3_11 -pypy3 -python3_10")
     Homepage:            https://wiki.gentoo.org/wiki/Layman
     Description:         Tool to manage Gentoo overlays


The ‘eselect repository’ eselect module supersedes layman and is now the way to manage ebuild repositories. So I needed to configure my machines to use the eselect module and to remove Layman.

First I checked which third-party Portage overlays were being managed by Layman in my installations:

root # layman -l

 * guru                      [Git       ] (https://anongit.gentoo.org/git/repo/proj/guru.git                                             )
 * seden                     [Git       ] (https://anongit.gentoo.org/git/user/seden.git                                                 )

root # ls /var/lib/layman/
cache_930c3ed4a5f89f74fd810585751a06e3.timestamp  cache_ac494f50f5736be7871962c0dec7b3bb.timestamp  guru           seden
cache_930c3ed4a5f89f74fd810585751a06e3.xml        cache_ac494f50f5736be7871962c0dec7b3bb.xml        installed.xml

The repos.conf directory on my machines each had three configuration files (one for the main Portage repository; one for the Layman-managed third-party overlays; one for my local overlay on the machine):

root # ls /etc/portage/repos.conf
gentoo.conf  layman.conf  local_overlay.conf

The layman.conf file contained the information on the third-party overlays:

root # cat /etc/portage/repos.conf/layman.conf 
[guru]
priority = 50
location = /var/lib/layman/guru
layman-type = git
sync-type = laymansync
sync-uri = https://anongit.gentoo.org/git/repo/proj/guru.git
auto-sync = Yes

[seden]
priority = 50
location = /var/lib/layman/seden
layman-type = git
sync-type = laymansync
sync-uri = https://anongit.gentoo.org/git/user/seden.git
auto-sync = Yes

There was also a directory /etc/layman/ containing more Layman files:

root # ls /etc/layman/
layman.cfg  overlays

The first thing I did was to use Layman to delete the two third-party overlays:

root # layman -d guru

 * Deleting selected overlay(s)...
 * Deleting directory "/var/lib/layman/guru"
 * Successfully deleted overlay(s) guru.

root # layman -d seden

 * Deleting selected overlay(s)...
 * Deleting directory "/var/lib/layman/seden"
 * Successfully deleted overlay(s) seden.

Then I installed the eselect-repository package:

root # emerge eselect-repository
Calculating dependencies... done!
Dependency resolution took 36.59 s.


!!! The following installed packages are masked:
- app-portage/layman-2.4.3::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# David Seifert  (2023-05-19)
# Abandoned, replaced by 'eselect repository', tons of open bugs.
# Removal on 2023-08-17. Bug #761199.

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

>>> Verifying ebuild manifests
>>> Emerging (1 of 1) app-eselect/eselect-repository-13::gentoo
>>> Installing (1 of 1) app-eselect/eselect-repository-13::gentoo
>>> Completed (1 of 1) app-eselect/eselect-repository-13::gentoo
>>> Jobs: 1 of 1 complete                           Load avg: 1.17, 0.62, 0.34

 * GNU info directory index is up-to-date.

Then I used the ‘eselect repository‘ command to re-add the two overlays:

root # eselect repository add guru git https://anongit.gentoo.org/git/repo/proj/guru.git
--2023-06-25 14:09:31--  https://qa-reports.gentoo.org/output/repos/repositories.xml
Resolving qa-reports.gentoo.org... 151.101.61.91, 2a04:4e42:82::347
Connecting to qa-reports.gentoo.org|151.101.61.91|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 253999 (248K) [text/xml]
Saving to: ‘/root/.cache/eselect-repo/repositories.xml’

repositories.xml                               100%[====================================================================================================>] 248.05K  --.-KB/s    in 0.06s   

2023-06-25 14:09:32 (4.19 MB/s) - ‘/root/.cache/eselect-repo/repositories.xml’ saved [253999/253999]

Adding guru to /etc/portage/repos.conf/eselect-repo.conf ...
Repository guru added
root # eselect repository add seden git https://anongit.gentoo.org/git/user/seden.git
Adding seden to /etc/portage/repos.conf/eselect-repo.conf ...
Repository seden added

Then I synchronised the two overlays with their respective repository:

root # emaint sync -r guru
>>> Syncing repository 'guru' into '/var/db/repos/guru'...
/usr/bin/git clone --depth 1 https://anongit.gentoo.org/git/repo/proj/guru.git .
Cloning into '.'...
remote: Enumerating objects: 9267, done.
remote: Counting objects: 100% (9267/9267), done.
remote: Compressing objects: 100% (8162/8162), done.
remote: Total 9267 (delta 1303), reused 7128 (delta 1010), pack-reused 0
Receiving objects: 100% (9267/9267), 6.53 MiB | 3.11 MiB/s, done.
Resolving deltas: 100% (1303/1303), done.
Updating files: 100% (7445/7445), done.
=== Sync completed for guru
!!! Section 'seden' in repos.conf has location attribute set to nonexistent directory: '/var/db/repos/seden'

Performing Global Updates
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  #='/var/db update'  @='/var/db move'
  s='/var/db SLOT move'  %='binary move'  S='binary SLOT move'
  p='update /etc/portage/package.*'
/var/db/repos/guru/profiles/updates/3Q-2020.
/var/db/repos/guru/profiles/updates/1Q-2020.
/var/db/repos/guru/profiles/updates/1Q-2021......
/var/db/repos/guru/profiles/updates/2Q-2022.........
/var/db/repos/guru/profiles/updates/4Q-2020...
/var/db/repos/guru/profiles/updates/1Q-2022....
/var/db/repos/guru/profiles/updates/2Q-2020..
/var/db/repos/guru/profiles/updates/3Q-2022.....
/var/db/repos/guru/profiles/updates/1Q-2023......
/var/db/repos/guru/profiles/updates/2Q-2021............
/var/db/repos/guru/profiles/updates/2Q-2023.........
/var/db/repos/guru/profiles/updates/4Q-2021...........
/var/db/repos/guru/profiles/updates/4Q-2022..


!!! Section 'seden' in repos.conf has location attribute set to nonexistent directory: '/var/db/repos/seden'

Action: sync for repo: guru, returned code = 0

root # emaint sync -r seden
>>> Syncing repository 'seden' into '/var/db/repos/seden'...
/usr/bin/git clone --depth 1 https://anongit.gentoo.org/git/user/seden.git .
Cloning into '.'...
remote: Enumerating objects: 160, done.
remote: Counting objects: 100% (160/160), done.
remote: Compressing objects: 100% (143/143), done.
remote: Total 160 (delta 16), reused 29 (delta 4), pack-reused 0
Receiving objects: 100% (160/160), 78.45 KiB | 1.40 MiB/s, done.
Resolving deltas: 100% (16/16), done.
=== Sync completed for seden

Action: sync for repo: seden, returned code = 0

I checked that the repositories are listed correctly (notice that the main Gentoo Linux repository and the third-party overlays have a hash symbol after the name, and my local overlay on the machine has the ‘@‘ symbol after the name):

root # eselect repository list
Available repositories:
  [1]   4nykey (https://github.com/4nykey/4nykey)
  [2]   AlexandreFournier (https://github.com/AlexandreFournier/gentoo-overlay)
  [3]   ArchFeh (https://github.com/ArchFeh/ArchFeh-overlay)
  [4]   AstroFloyd (https://cgit.gentoo.org/user/AstroFloyd.git/)
  [5]   CachyOS-kernels (https://github.com/Szowisz/CachyOS-kernels)
  [6]   Case_Of (https://codeberg.org/Case_Of/gentoo-overlay)
  [7]   Drauthius (https://cgit.gentoo.org/repo/user/Drauthius.git/)
  [8]   EmilienMottet (https://github.com/EmilienMottet/overlay)
  [9]   FireBurn (https://github.com/FireBurn/Overlay)
  [10]  HomeAssistantRepository (https://git.edevau.net/onkelbeh/HomeAssistantRepository)
  [11]  JRG (https://github.com/john-r-graham/jrg-overlay)
  [12]  KBrown-pub (http://sandino.araico.net/)
  [13]  Miezhiko (https://github.com/Miezhiko/Overlay)
  [14]  ROKO__ (https://github.com/sandikata/ROKO__)
  [15]  R_Overlay (https://cgit.gentoo.org/proj/R_overlay.git/)
  [16]  SarahMiaOverlay (https://gitlab.com/SarahMia/sarahmiaoverlay)
  [17]  SwordArMor (https://git.grifon.fr/alarig/SwordArMor-gentoo-overlay)
  [18]  Systole (https://github.com/SystoleOS)
  [19]  ace (https://github.com/ananace/overlay)
  [20]  activehome (https://cgit.gentoo.org/user/activehome.git/)
  [21]  adasss (https://github.com/AdamGiergun/adasss)
  [22]  ag-ops (https://gitlab.com/ILMostro/ag-ops)
  [23]  ago (https://cgit.gentoo.org/dev/ago.git/)
  [24]  ahyangyi-overlay (https://github.com/ahyangyi/ahyangyi-overlay)
  [25]  akater (https://gitlab.com/akater/ebuilds)
  [26]  alatar-lay (https://github.com/alatarum/alatar-lay)
  [27]  alesharik (https://github.com/alesharik/alesharik-overlay)
  [28]  alexxy (https://cgit.gentoo.org/dev/alexxy.git/)
  [29]  alxu (https://cgit.alxu.ca/gentoo-overlay.git/)
  [30]  amano-kenji (https://codeberg.org/amano.kenji/gentoo-overlay)
  [31]  ambasta
  [32]  amedeos (https://github.com/amedeos/amedeos-overlay)
  [33]  anarchy (https://cgit.gentoo.org/dev/anarchy.git/)
  [34]  anard (https://github.com/Anard/anard-overlay)
  [35]  anaximander (https://cgit.gentoo.org/user/anaximander.git/)
  [36]  anders-larsson (https://github.com/anders-larsson/gentoo-overlay)
  [37]  andrey_utkin (https://github.com/andrey-utkin/gentoo-overlay.git)
  [38]  anomen (https://github.com/anomen-s/anomen-overlay)
  [39]  antons-matrix-overlay (https://gitlab.com/anton.molyboha.group/gentoo/overlays/matrix)
  [40]  anyc (https://github.com/anyc/anyc-overlay)
  [41]  ap-overlay (https://gitlab.com/AbhinavPraveen/ap-overlay)
  [42]  apriluwu (https://github.com/apriluwu/gentoo-overlay)
  [43]  argent-main (https://gitlab.com/argent/argent-main)
  [44]  arx-libertatis (https://github.com/arx/ArxGentoo)
  [45]  audio-overlay (https://github.com/gentoo-audio/audio-overlay)
  [46]  average (https://github.com/AnAverageHuman/average)
  [47]  awesome (https://gitlab.awesome-it.de/overlays/awesome)
  [48]  barnowl (https://github.com/wthrowe/barnowl-overlay)
  [49]  beatussum-overlay (https://github.com/beatussum/beatussum-overlay)
  [50]  bell07
  [51]  benzene-overlay (https://github.com/Universebenzene/benzene-overlay)
  [52]  bes (https://github.com/bes-internal/gentoo-overlay-bes)
  [53]  bibletime (https://cgit.gentoo.org/user/bibletime.git/)
  [54]  binaryden (https://github.com/tkemmer/binaryden)
  [55]  bircoph (https://cgit.gentoo.org/dev/bircoph.git/)
  [56]  bitcoin (https://gitlab.com/bitcoin/gentoo.git)
  [57]  blackburn29 (https://github.com/blackburn29/blackburn29-overlay)
  [58]  bobwya (https://github.com/bobwya/miscellaneous_ebuilds)
  [59]  bombo82 (https://github.com/bombo82/bombo82-overlay)
  [60]  booboo (https://github.com/l29ah/booboo)
  [61]  bratishkaerik-overlay (https://git.sr.ht/~bratishkaerik/bratishkaerik-overlay)
  [62]  brave-overlay (https://gitlab.com/jason.oliveira/brave-overlay)
  [63]  brother-overlay (https://github.com/stefan-langenmaier/brother-overlay)
  [64]  broverlay (https://github.com/BROverlay/overlay)
  [65]  bubba (https://github.com/gordonb3/bubba-overlay)
  [66]  bumblebee (https://github.com/Bumblebee-Project/bumblebee-gentoo/)
  [67]  buzden (https://github.com/buzden/buzden-overlay)
  [68]  calculate (http://www.calculate-linux.org)
  [69]  calendulish (https://github.com/calendulish/Overlays)
  [70]  canutethegreat-overlay (http://gentoo.canutethegreat.com/)
  [71]  cdlp (https://codeberg.org/phranz/cdlp)
  [72]  ceamac (https://github.com/ceamac/overlay)
  [73]  certbot-dns-plugins (https://github.com/osirisinferi/certbot-dns-plugins-overlay)
  [74]  cg (https://github.com/brothermechanic/cg)
  [75]  chymeric (https://github.com/TheChymera/overlay)
  [76]  cj-overlay (https://github.com/junghans/cj-overlay)
  [77]  cosmicmod-overlay (https://github.com/cosmicoz/cosmicmod-overlay)
  [78]  cova (https://github.com/cova-fe/cova-overlay)
  [79]  crossdev (https://github.com/alphallc/crossdev/)
  [80]  dargor (https://github.com/dargor/dargor_gentoo_overlay)
  [81]  darkelf (https://cgit.gentoo.org/repo/user/darkelf.git)
  [82]  darthgandalf-overlay (https://github.com/DarthGandalf/gentoo-overlay)
  [83]  defiance (https://github.com/d3fy/defiance-overlay.git)
  [84]  dev1990-overlay (https://github.com/dev-0x7C6/dev1990-overlay.git)
  [85]  didos (https://github.com/prototype99/didos)
  [86]  dilfridge (https://cgit.gentoo.org/dev/dilfridge.git/)
  [87]  dinolay (https://github.com/TruncatedDinosour/dinolay)
  [88]  displacer (https://cgit.gentoo.org/user/displacer.git/)
  [89]  distros (http://www.calculate-linux.org)
  [90]  djc (https://github.com/djc/djc-overlay)
  [91]  dlang (https://github.com/gentoo/dlang)
  [92]  dm9pZCAq (https://notabug.org/dm9pZCAq/dm9pZCAq-overlay)
  [93]  dwfreed (https://bitbucket.org/dwfreed/dwfreed.gentoo/)
  [94]  dwosky (https://github.com/Dwosky/Dwosky-overlay)
  [95]  earshark (https://github.com/Chemrat/overlay)
  [96]  eclipse (https://github.com/gentoo/eclipse-overlay)
  [97]  edgets (https://github.com/BlueManCZ/edgets)
  [98]  eigenlay (https://gitlab.com/eigennet/eigenlay)
  [99]  einflay (https://github.com/EinstokFair/einflay)
  [100] ejabberd (https://github.com/rion-overlay/ejabberd-overlay)
  [101] electron (https://github.com/elprans/electron-overlay)
  [102] elementary (https://github.com/pimvullers/elementary)
  [103] emacs (https://wiki.gentoo.org/wiki/Project:Emacs/Overlay)
  [104] enlightenment-live (https://github.com/rafspiny/enlightenment-live)
  [105] equaeghe (https://github.com/equaeghe/gentoo-overlay/)
  [106] eras-overlay (https://github.com/erayaslan/eras-overlay)
  [107] erayd (https://github.com/erayd/overlay)
  [108] escpr2 (https://gitlab.com/at.gentoo.repo/epson-inkjet-printer-escpr2)
  [109] eugene-bright (https://github.com/eugene-bright/eugene-bright-overlay)
  [110] ext-devlibs (https://gitlab.com/extsidvind/ext-devlibs)
  [111] farmboy0 (https://github.com/farmboy0/portage-overlay)
  [112] fem-overlay (https://gitlab.fem-net.de/gentoo/fem-overlay)
  [113] feniksa (https://github.com/feniksa/gentoo-overlay)
  [114] ferki (https://github.com/ferki/gentoo-overlay)
  [115] fictitiousexistence (https://gitlab.com/fictitiousexistence-public/gentoo)
  [116] fidonet
  [117] flammie (https://github.com/flammie/flammie-overlay)
  [118] flavour (https://github.com/wimmuskee/flavour)
  [119] flewkey-overlay (https://git.sdf.org/flewkey/flewkey-overlay)
  [120] flexibeast-s6 (https://github.com/flexibeast/gentoo-s6-overlay)
  [121] flightsim (https://github.com/rafaelmartins/flightsim-overlay)
  [122] floppym (https://github.com/floppym/floppym)
  [123] flow (https://gitlab.com/Flow/flow-s-ebuilds)
  [124] flussence (https://repo.or.cz/flussence-overlay.git)
  [125] fol4 (https://gitlab.com/madsl/fol4)
  [126] foo-overlay (https://github.com/slashbeast/foo-overlay)
  [127] fordfrog (https://cgit.gentoo.org/dev/fordfrog.git/)
  [128] fortunelay (https://github.com/Alessandro-Barbieri/fortunelay)
  [129] fowlay (https://github.com/fowlay/fowlay-overlay)
  [130] foxiverlay (https://github.com/Pekkari/foxiverlay)
  [131] fritteli (https://github.com/fritteli/gentoo-overlay)
  [132] frr-gentoo (https://frrouting.org/)
  [133] fyn-overlay (https://github.com/qwe795138426/fyn-overlay)
  [134] gamerlay (https://cgit.gentoo.org/proj/gamerlay.git)
  [135] gbrlsnchs (https://sr.ht/~gbrlsnchs/ebuilds)
  [136] gentoo # (https://gentoo.org/)
  [137] gentoo-bootstrap (https://gitlab.com/stikonas/gentoo-bootstrap)
  [138] gentoo-linux-surface-overlay (http://gentoo.canutethegreat.com/)
  [139] gentoo-zh (https://github.com/microcai/gentoo-zh)
  [140] gentoobr (https://github.com/gentoobr/overlay)
  [141] gerislay (https://cgit.gentoo.org/repo/user/gerislay.git)
  [142] gig (https://github.com/Gig-OS/gig)
  [143] gitlab (https://gitlab.awesome-it.de/overlays/gitlab)
  [144] gnome (https://cgit.gentoo.org/proj/gnome.git/)
  [145] gnu-elpa (https://github.com/houseofsuns/gnu-elpa)
  [146] gnuradio (https://github.com/hololeap/gentoo-gnuradio)
  [147] gnustep (https://cgit.gentoo.org/proj/gnustep.git/)
  [148] goduck777 (https://github.com/goduck777/gentoo-overlay)
  [149] gogooverlay (https://github.com/GoGoOtaku/GoGoOverlay)
  [150] graaff (http://moving-innovations.com/blog/)
  [151] griffon_overlay (https://github.com/windfail/griffon_overlay)
  [152] gsview-overlay (https://github.com/uleysky/gsview-overlay)
  [153] guru # (https://wiki.gentoo.org/wiki/Project:GURU)
  [154] haarp (https://cgit.gentoo.org/user/haarp.git/)
  [155] hamari (https://github.com/hamarituc/gentoo-overlay/)
  [156] hamper-overlay (https://github.com/hamper/hamper-overlay)
  [157] han (https://github.com/hanmertens/han-overlay)
  [158] haskell (https://github.com/gentoo-haskell)
  [159] hep-forge (https://gitlab.com/APN-Pucky/gentoo-hep-forge)
  [160] hering-overlay (https://github.com/internethering/hering-overlay)
  [161] holgersson-overlay (https://git.holgersson.xyz)
  [162] hossie (https://wiki.hossie.de/projekte:gentoo-overlay)
  [163] hotstoast (https://github.com/TomHotston/hotstoast-overlay)
  [164] icinga (https://github.com/antonfischl1980/icinga)
  [165] inode64-overlay (https://github.com/inode64/inode64-overlay)
  [166] ixit (https://github.com/okias/ixit)
  [167] jabuxas (https://github.com/jabuxas/overlay)
  [168] java (https://cgit.gentoo.org/proj/java.git/)
  [169] jjakob (https://github.com/jjakob/gentoo-overlay)
  [170] jkolo (https://git.kolosowscy.pl/jurek/gentoo-overlay)
  [171] jl1990 (https://github.com/jl1990/gentoo-overlay)
  [172] jm-overlay (https://github.com/Jannis234/jm-overlay)
  [173] jmbsvicetto (https://cgit.gentoo.org/repo/dev/jmbsvicetto.git)
  [174] jsteward (https://github.com/KireinaHoro/jsteward)
  [175] junkdrawer (https://github.com/doctaweeks/junkdrawer-overlay)
  [176] kaa (http://www.kaa.org.ua)
  [177] kde (https://kde.gentoo.org)
  [178] khoverlay (https://gitlab.com/khumba/khoverlay)
  [179] konsolebox (https://github.com/konsolebox/overlay)
  [180] kostas-overlay (https://github.com/KostasEreksonas/kostas-overlay)
  [181] kripton-overlay (https://github.com/kripton/kripton-overlay)
  [182] kzd (https://gitlab.com/kzdixon/kzd-ebuilds)
  [183] lab-overlay (https://github.com/positivelab/lab-overlay)
  [184] lanodanOverlay (https://hacktivis.me/git/overlay)
  [185] ledgersmb (https://github.com/ledgersmb/lsmb-overlay)
  [186] leechcraft (https://github.com/0xd34df00d/leechcraft-overlay)
  [187] librepilot (https://github.com/paul-jewell/librepilot-overlay)
  [188] libressl (https://wiki.gentoo.org/wiki/Project:LibreSSL)
  [189] liftm
  [190] lilium (https://github.com/owl4ce/lilium)
  [191] linux-be (https://gitlab.com/linux-be)
  [192] linuxunderground-overlay (https://github.com/linuxunderground/gentoo.overlay)
  [193] lisp (https://cgit.gentoo.org/proj/lisp.git)
  [194] lmiphay (https://cgit.gentoo.org/user/lmiphay.git/)
  [195] loatchi (https://github.com/Loatchi/loatchi-overlay)
  [196] local_overlay @
  [197] loongson (https://github.com/xen0n/loongson-overlay)
  [198] lto-overlay (https://github.com/InBetweenNames/gentooLTO)
  [199] luke-jr (http://luke.dashjr.org)
  [200] maekke (https://cgit.gentoo.org/dev/maekke.git)
  [201] mate-de-gentoo (https://github.com/oz123/mate-de-gentoo)
  [202] megacoffee (http://gentoo-overlay.megacoffee.net)
  [203] melpa (https://github.com/houseofsuns/melpa)
  [204] melpa-stable (https://github.com/houseofsuns/melpa-stable)
  [205] menelkir (https://gitlab.com/menelkir/gentoo-overlay)
  [206] metahax (https://github.com/metafarion/metahax)
  [207] milos-rs (https://github.com/milos-rs/gentoo-overlay)
  [208] miramir (https://github.com/miramir/miramir-layman)
  [209] moexiami (https://github.com/Xiami2012/moexiami-ovl-dev)
  [210] moltonel (https://github.com/vincentdephily/moltonel-ebuilds/)
  [211] moulay (https://gitlab.com/yemou/moulay)
  [212] mrtnvgr (https://github.com/mrtnvgr/gentoo-overlay)
  [213] mschiff (https://cgit.gentoo.org/dev/mschiff.git/)
  [214] multilib-portage (https://cgit.gentoo.org/proj/multilib-portage.git/)
  [215] musl (https://cgit.gentoo.org/proj/musl.git/)
  [216] musl-clang (https://github.com/karlguy/musl-clang/)
  [217] mv (https://cgit.gentoo.org/user/mv.git)
  [218] mva (https://github.com/msva/mva-overlay/)
  [219] myov (https://gitlab.com/xgqt/myov.git)
  [220] myrvolay (https://github.com/myrvogna/myrvolay)
  [221] mysql (https://cgit.gentoo.org/proj/mysql.git/)
  [222] natinst (https://github.com/AndrewAmmerlaan/natinst)
  [223] nelson-graca (https://github.com/nelsongraca/gentoo-overlay)
  [224] nest (https://github.com/SpiderX/portage-overlay)
  [225] nez (https://codeberg.org/nezbednik/repo)
  [226] nico (https://cgit.gentoo.org/user/nico.git/)
  [227] nightfreedom-overlay (https://github.com/night-every/nightfreedom-overlay)
  [228] nitratesky (https://github.com/VTimofeenko/nitratesky)
  [229] nongnu-elpa (https://github.com/houseofsuns/nongnu-elpa)
  [230] nordvpn (https://gitlab.com/lahouari.dc/nordvpn/)
  [231] nymphos (https://github.com/neeshy/nymphos)
  [232] oddlama (https://github.com/oddlama/overlay)
  [233] odroidc4 (https://github.com/svoop/odroidc4-overlay)
  [234] okh (https://github.com/OlexiyKhokhlov/okh-overlay)
  [235] olifre (https://github.com/olifre/olifre-portage)
  [236] openclonk (http://www.openclonk.org/)
  [237] oubliette (https://github.com/nabbi/oubliette-overlay)
  [238] overseerr-overlay (https://github.com/chriscpritchard/overseerr-overlay)
  [239] oxen-overlay (https://github.com/xutaxkamay/gentoo-oxen)
  [240] palemoon (https://github.com/deu/palemoon-overlay)
  [241] pdilung (https://github.com/pdilung/gentoo-overlay/)
  [242] pentoo (http://www.pentoo.ch)
  [243] petkovich (https://github.com/jcpetkovich/overlay-petkovich)
  [244] pf4public (https://github.com/PF4Public/gentoo-overlay)
  [245] pg_overlay (https://gitlab.com/Perfect_Gentleman/PG_Overlay)
  [246] phackerlay (https://gitlab.phys-el.ru/gentoo/phackerlay)
  [247] phoenix591 (https://github.com/Phoenix591/gentoo-overlay)
  [248] pholthaus-overlay (https://github.com/pholthau/pholthaus-overlay)
  [249] php-overlay (https://github.com/gentoo-php-overlay/php-overlay)
  [250] pica-pica (https://github.com/antonsviridenko/pica-pica-gentoo-overlay)
  [251] pigfoot (https://cgit.gentoo.org/user/pigfoot.git/)
  [252] piniverlay (https://github.com/pinicarus/gentoo-overlay)
  [253] pinkbyte (https://github.com/Pinkbyte/pinkbyte-overlay)
  [254] pixlra (https://cgit.gentoo.org/user/carreira.git/)
  [255] pkalin (https://github.com/thinrope/pkalin)
  [256] plex-overlay (https://github.com/comio/plex-overlay)
  [257] powerman (https://github.com/powerman/powerman-overlay)
  [258] ppfeufer-gentoo-overlay (https://github.com/ppfeufer/gentoo-overlay)
  [259] pross (https://github.com/Pross/pross-overlay)
  [260] pyfa (https://github.com/ZeroPointEnergy/gentoo-pyfa-overlay)
  [261] pypi-sci (https://github.com/jiegec/gentoo-pypi-sci)
  [262] qemu-init (https://cgit.gentoo.org/dev/qiaomuf.git/)
  [263] qownnotes-overlay (http://www.qownnotes.org)
  [264] qsx (https://github.com/qsuscs/gentoo-overlay)
  [265] qt (https://github.com/gentoo/qt)
  [266] quarks (https://git.zero-downtime.net/quark)
  [267] r7l (https://github.com/r7l/r7l-overlay)
  [268] racket-overlay (https://gitlab.com/gentoo-racket/gentoo-racket-overlay)
  [269] raiagent (https://github.com/leycec/raiagent)
  [270] rasdark (https://github.com/rasdark/overlay)
  [271] rich0 (https://github.com/rich0/rich0-overlay)
  [272] rimio (https://github.com/rimio/gentoo-overlay)
  [273] rion (https://github.com/rion-overlay)
  [274] riru (https://github.com/pkulev/riru)
  [275] riscv (https://github.com/gentoo/riscv)
  [276] rnp (https://www.rnpgp.org/)
  [277] robert7k (https://github.com/robert7k/gentoo-overlay)
  [278] robertgzr (https://git.sr.ht/~robertgzr/portage)
  [279] roslin (https://gitlab.com/roslin-uberlay/roslin)
  [280] ruby (https://cgit.gentoo.org/proj/ruby)
  [281] ruixi-overlay (https://github.com/Ruixi-rebirth/ruixi-overlay)
  [282] rukruk (https://github.com/Atoms/rukruk)
  [283] ryans (https://github.com/bekcpear/ryans-repos)
  [284] sage-on-gentoo (https://github.com/cschwan/sage-on-gentoo)
  [285] salfter (https://gitlab.com/salfter/portage)
  [286] sam_c (https://github.com/thesamesam/overlay)
  [287] sattvik (https://cgit.gentoo.org/user/sattvik.git/)
  [288] science (https://wiki.gentoo.org/wiki/Project:Science)
  [289] scrill (https://github.com/scrill/scrill-overlay)
  [290] seden # (https://cgit.gentoo.org/user/seden.git/)
  [291] sergiotarxz (https://gitea.sergiotarxz.freemyip.com/sergiotarxz/sergiotarxz-overlay)
  [292] serioussam (https://github.com/tx00100xt/serioussam-overlay)
  [293] setkeh (https://github.com/setkeh/Portage-Overlay)
  [294] sevz (https://gitlab.com/sevz17/sevz-overlay)
  [295] sft (https://github.com/SFTtech/gentoo-overlay)
  [296] sgs (https://github.com/blackm0re/sgs-overlay)
  [297] shnurise (https://github.com/ArsenShnurkov/shnurise)
  [298] simonvanderveldt (https://github.com/simonvanderveldt/simonvanderveldt-overlay)
  [299] sinustrom (https://github.com/zpuskas/sinustrom-gentoo-overlay)
  [300] sk-overlay (https://github.com/scriptkitties/overlay)
  [301] slonko (https://slonko.net/portage)
  [302] smaeul (https://github.com/smaeul/portage-overlay)
  [303] snapd (https://github.com/zigford/snapd)
  [304] sogo-connector (https://cgit.gentoo.org/repo/user/sogo-connector.git/)
  [305] soltys (https://github.com/soltysek/soltys-overlay)
  [306] sorrow (https://gitlab.com/eternal-sorrow/gentoo-local)
  [307] spark-overlay (https://github.com/6-6-6/spark-overlay)
  [308] spikyatlinux (https://github.com/spikyatlinux/ebuilds_for_gentoo)
  [309] sping (https://github.com/hartwork/gentoo-overlay-sping)
  [310] spring (https://github.com/spring/gentoo-overlay)
  [311] src_prepare-overlay (https://gitlab.com/src_prepare/src_prepare-overlay.git)
  [312] ssnb (https://cgit.gentoo.org/repo/user/ssnb.git/)
  [313] sspreitz (https://github.com/sspreitzer/gentoo-repo)
  [314] steam-overlay (https://github.com/anyc/steam-overlay)
  [315] stefantalpalaru (https://github.com/stefantalpalaru/gentoo-overlay)
  [316] stephdewit (https://github.com/stephdewit/gentoo-overlay)
  [317] stha09 (https://github.com/stha09/gpo-stha09)
  [318] stowe-verlay (https://github.com/mwstowe/stowe-verlay)
  [319] strohel (https://github.com/strohel/strohel-overlay)
  [320] stuff (https://github.com/istitov/stuff)
  [321] sunset-repo (https://github.com/Anonymous1157/sunset-repo)
  [322] suntar (https://github.com/suntar/suntar-overlay)
  [323] superposition (https://cgit.gentoo.org/repo/user/superposition.git/)
  [324] supertux88 (https://github.com/SuperTux88/gentoo-overlay)
  [325] swegener (https://dev.gentoo.org/~swegener/)
  [326] tamiko (https://cgit.gentoo.org/repo/dev/tamiko.git/)
  [327] tarantool (https://github.com/tarantool/gentoo-overlay)
  [328] tastytea (https://schlomp.space/tastytea/overlay)
  [329] tatsh-overlay (https://github.com/Tatsh/tatsh-overlay)
  [330] telans (https://github.com/telans/EBUILDS)
  [331] tezeta (https://github.com/tezeta/tezeta-overlay)
  [332] tgbugs-overlay (https://github.com/tgbugs/tgbugs-overlay)
  [333] thegreatmcpain (https://gitlab.com/TheGreatMcPain/thegreatmcpain-overlay)
  [334] third-party-certbot-plugins (https://github.com/osirisinferi/third-party-certbot-plugins)
  [335] tmacedo (https://github.com/tmacedo/portage)
  [336] toniz4-overlay (https://github.com/toniz4/toniz4-overlay.git/)
  [337] toolchain (https://cgit.gentoo.org/proj/toolchain.git/)
  [338] torbrowser (https://github.com/MeisterP/torbrowser-overlay)
  [339] touchfish-os (https://github.com/CHN-beta/touchfish-os)
  [340] trolltoo (https://github.com/dallenwilson/trolltoo)
  [341] tryton (http://www.tryton.org/)
  [342] turret-overlay (https://git.turret.cyou/portage-overlay.git/about/)
  [343] ukui (https://www.ukui.org/)
  [344] ulm (https://cgit.gentoo.org/repo/dev/ulm.git/)
  [345] unc3nsored (https://github.com/xxc3nsoredxx/unc3nsored)
  [346] underworld (https://github.com/DakEnviy/underworld-overlay)
  [347] unity-gentoo (https://github.com/shiznix/unity-gentoo)
  [348] usenet-overlay (https://github.com/xartin/gentoo-overlay)
  [349] vGist (https://github.com/vgist/vgist-overlay)
  [350] vaacus (https://gitlab.com/plexvola/vaacus)
  [351] vapoursynth (https://github.com/4re/vapoursynth-portage)
  [352] vayerx (https://github.com/vayerx/vayerx-gentoo/)
  [353] vespa (https://github.com/thiagovespa/vespa-overlay)
  [354] vifino-overlay (https://github.com/vifino/vifino-overlay)
  [355] violet-funk (https://github.com/MagelessMayhem/violet-funk)
  [356] vklimovs (https://github.com/vklimovs/portage-overlay)
  [357] vmacs (https://cgit.gentoo.org/user/vmacs.git/)
  [358] vortex (https://github.com/nE0sIghT/vortex-overlay)
  [359] vowstar (https://github.com/vowstar/vowstar-overlay)
  [360] voyageur (https://cafarelli.fr/cgi-bin/cgit.cgi/voyageur-overlay/)
  [361] vulkano-edge (https://github.com/thequickfixer/vulkano-edge)
  [362] waebbl (https://github.com/waebbl/waebbl-gentoo)
  [363] waffle-builds (https://github.com/FlyingWaffleDev/waffle-builds)
  [364] wayland-desktop (https://github.com/bsd-ac/wayland-desktop)
  [365] wbrana (https://cgit.gentoo.org/user/wbrana.git/)
  [366] weuxel (https://github.com/Weuxel/portage-weuxel)
  [367] what4-java (https://github.com/kwhat/gentoo-what4-java-overlay)
  [368] wichtounet (https://github.com/wichtounet/wichtounet-overlay)
  [369] without-systemd (https://github.com/KenjiBrown/without-systemd)
  [370] x0rzavi (https://github.com/x0rzavi/x0rzavi-overlay)
  [371] x11 (https://cgit.gentoo.org/proj/x11.git)
  [372] xarblu-overlay (https://github.com/xarblu/xarblu-overlay)
  [373] xdch47 (https://github.com/xdch47/gpo-xdch47)
  [374] xelnor (http://overlay.xelnor.net)
  [375] xoreos (https://github.com/xoreos/gentoo-overlay)
  [376] xwing (https://gentoo.xwing.info)
  [377] yandex (https://github.com/yandex-gentoo/overlay)
  [378] yurij-overlay (https://github.com/yurijmikhalevich/yurij-overlay)
  [379] zGentoo (https://lab.retarded.farm/zappel/zGentoo)
  [380] zeldu (https://github.com/3elDU/gentoo-repository)
  [381] zerodaysfordays (https://git.sr.ht/~jakob/zerodaysfordays)
  [382] zozx-overlay (https://github.com/zozx/zozx-overlay)
  [383] zugaina (http://gpo.zugaina.org/Overlays/zugaina/)
  [384] zyrenth (https://github.com/kabili207/zyrenth-overlay)

These are easier to see by listing only the installed repositories:

root # eselect repository list -i
Available repositories:
  [136] gentoo # (https://gentoo.org/)
  [153] guru # (https://wiki.gentoo.org/wiki/Project:GURU)
  [196] local_overlay @
  [290] seden # (https://cgit.gentoo.org/user/seden.git/)

So, as everything looked correct, I then removed Layman from the installations:

root # emerge --ask --depclean layman

Calculating dependencies... done!
>>> Calculating removal order...

>>> These are the packages that would be unmerged:

 app-portage/layman
    selected: 2.4.3 
   protected: none 
     omitted: none 

All selected packages: =app-portage/layman-2.4.3

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

Would you like to unmerge these packages? [Yes/No] Yes
>>> Waiting 5 seconds before starting...
>>> (Control-C to abort)...
>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) app-portage/layman-2.4.3...
Packages installed:   1826
Packages in world:    254
Packages in system:   48
Required packages:    1826
Number removed:       1

 * GNU info directory index is up-to-date.
root # rm -rf /var/lib/layman
root # rm /etc/portage/repos.conf/layman.conf
root # rm -rf /etc/layman

Notice above that I also deleted all Layman directories and the Layman configuration file in the repos.conf directory.

For good measure I synced the main Portage tree and the two overlays again:

root # emaint sync -a
[...]
x11-misc/compose-tables/compose-tables-1.8.6.ebuild
x11-themes/Manifest.gz
x11-themes/QGnomePlatform/Manifest
x11-themes/QGnomePlatform/QGnomePlatform-0.9.1-r1.ebuild
x11-themes/QGnomePlatform/metadata.xml
x11-themes/numix-icon-theme-circle/Manifest
x11-themes/numix-icon-theme-circle/numix-icon-theme-circle-23.04.28.ebuild
x11-themes/numix-icon-theme/Manifest
x11-themes/numix-icon-theme/numix-icon-theme-23.04.26.ebuild
x11-wm/Manifest.gz
x11-wm/xpra/Manifest
x11-wm/xpra/xpra-4.4.6.ebuild

Number of files: 145,549 (reg: 118,735, dir: 26,814)
Number of created files: 600 (reg: 578, dir: 22)
Number of deleted files: 622 (reg: 600, dir: 22)
Number of regular files transferred: 5,382
Total file size: 190.75M bytes
Total transferred file size: 20.90M bytes
Literal data: 20.90M bytes
Matched data: 0 bytes
File list size: 3.70M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 131.96K
Total bytes received: 16.87M

sent 131.96K bytes  received 16.87M bytes  400.04K bytes/sec
total size is 190.75M  speedup is 11.22
 * Manifest timestamp: 2023-06-25 12:39:45 UTC
 * Valid OpenPGP signature found:
 * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
 * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
 * - timestamp: 2023-06-25 12:39:45 UTC
 * Verifying /usr/portage/.tmp-unverified-download-quarantine ...                                                                                                                    [ ok ]
=== Sync completed for gentoo
>>> Syncing repository 'seden' into '/var/db/repos/seden'...
>>> Syncing repository 'guru' into '/var/db/repos/guru'...
/usr/bin/git fetch origin --depth 1
/usr/bin/git fetch origin --depth 1
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
/usr/bin/git reset --merge refs/remotes/origin/master
=== Sync completed for seden
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
/usr/bin/git reset --merge refs/remotes/origin/master
=== Sync completed for guru

Action: sync for repo: gentoo, returned code = 0
Action: sync for repo: seden, returned code = 0
Action: sync for repo: guru, returned code = 0

And I made sure the eix and mlocate databases were up-to-date:

root # eix-update && updatedb

My installations have the elogind package installed, but the package could not be re-merged due to an error in the manifest of one of the packages in the seden overlay:

root # eix -I elogind
[U] sys-auth/elogind
     Available versions:  246.10-r3^t [M]~246.9999*l[1] ~252.9^t 252.9^t[1] **252.9999[1] {+acl audit +cgroup-hybrid debug doc efi +pam +policykit selinux test}
     Installed versions:  246.10-r3^t(02:47:54 14/05/23)(acl cgroup-hybrid doc pam policykit -audit -debug -selinux -test)
     Homepage:            https://github.com/elogind/elogind
     Description:         The systemd project's logind, extracted to a standalone package

[1] "seden" /var/db/repos/seden
root # emerge -1v elogind

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

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

[ebuild     U  ] sys-auth/elogind-252.9::seden [246.10-r3::gentoo] USE="acl doc pam (policykit) -audit -debug (-selinux) -test (-cgroup-hybrid%*)" 0 KiB

Total: 1 package (1 upgrade), Size of downloads: 0 KiB

>>> Verifying ebuild manifests

!!! A file listed in the Manifest could not be found: /var/db/repos/seden/sys-auth/elogind/elogind-239.9999.ebuild

Therefore I disabled the seden overlay:

root # eselect repository disable seden
Updating repos.conf ...
1 repositories disabled
root # ls /etc/portage/repos.conf
eselect-repo.conf  eselect-repo.conf~  gentoo.conf  local_overlay.conf
root # cat /etc/portage/repos.conf/eselect-repo.conf
# created by eselect-repo

[guru]
location = /var/db/repos/guru
sync-type = git
sync-uri = https://anongit.gentoo.org/git/repo/proj/guru.git

As can be seen above, the seden overlay is indeed now disabled.

I then rechecked the available packages for elogind:

root # eix-update
root # eix -I elogind
[I] sys-auth/elogind
     Available versions:  246.10-r3^t ~252.9^t {+acl audit +cgroup-hybrid debug doc +pam +policykit selinux test}
     Installed versions:  246.10-r3^t(02:47:54 14/05/23)(acl cgroup-hybrid doc pam policykit -audit -debug -selinux -test)
     Homepage:            https://github.com/elogind/elogind
     Description:         The systemd project's logind, extracted to a standalone package

I was then able to install the latest version of elogind available in the main Portage repository:

root # emerge -1v elogind

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

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

[ebuild   R    ] sys-auth/elogind-246.10-r3::gentoo  USE="acl cgroup-hybrid doc pam (policykit) -audit -debug (-selinux) -test" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-auth/elogind-246.10-r3::gentoo
>>> Installing (1 of 1) sys-auth/elogind-246.10-r3::gentoo
>>> Completed (1 of 1) sys-auth/elogind-246.10-r3::gentoo
>>> Jobs: 1 of 1 complete                           Load avg: 3.12, 2.63, 2.01

 * GNU info directory index is up-to-date.

There we have it. Both my machines with Gentoo Linux installations have been converted successfully from using Layman to using the ‘eselect repository’ module.

Further reading: Gentoo Linux Forums – Migrating from Layman to eselect-repository

Gentoo Linux: Building/rebuilding a kernel and Intel CPU microcode in an installation with initramfs

In a 2014 post I explained how to update the Intel CPU microcode in a Gentoo Linux installation with an initramfs (I use sys-kernel/genkernel to build the kernel in the installation on my Compal NBLB2 laptop, which is running the Testing Branch of Gentoo Linux although the branch is not important). The initscript method (Method 1 in that post) for updating the CPU microcode is no longer valid, and the behaviour of the tool sys-apps/iucode_tool for updating the CPU microcode (Method 2 in that post) has changed, hence this update.

Although not essential I normally perform the microcode upgrade procedure when I either rebuild or upgrade the Linux kernel, therefore I explain both procedures contiguously here.

These days the grub-mkconfig command edits the file /boot/grub/grub.cfg to add a line to the GRUB menu entries, to load the CPU microcode at boot, but nevertheless I prefer to follow a slightly different method that works reliably for me.

Below is the procedure I follow to build/rebuild the kernel and the Intel CPU microcode. Others may have a different approach, but this has always worked well for me, even if some of the steps are sometimes nugatory.

If they are not already installed, you need to merge a couple of packages before starting the main procedure:

root # emerge app-arch/lzma # Needed to build bzImage.
root # emerge iucode_tool

1. Mount the boot directory if it is on a separate partition

root # mount /dev/sda3 /boot

2. Check which kernel sources are installed and which of those sources is currently selected

root # eselect kernel list

3. Make a back-up configuration file for the current running kernel

root # zcat /proc/config.gz > /usr/src/config

4. Select the kernel sources I want to build

root # eselect kernel set <n>

5. Build the kernel image and the initramfs image

root # genkernel --kernel-config=/usr/src/config --clean --menuconfig --microcode=intel --no-splash --module-rebuild all

I have configured the following kernel options relating to the early loading of the Intel CPU microcode (see later):

root # grep CONFIG_BLK_DEV_INITRD /usr/src/linux/.config
CONFIG_BLK_DEV_INITRD=y
root # # grep CONFIG_MICROCODE /usr/src/linux/.config
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
# CONFIG_MICROCODE_OLD_INTERFACE is not set
# grep CONFIG_INITRAMFS_SOURCE /usr/src/linux/.config
CONFIG_INITRAMFS_SOURCE=""

6. Rebuild the X Windows Server and X Windows drivers

I always do this even though not always necessary. One less thing to think about (not rebuilding them has sometimes caused me problems).

root # emerge xorg-server xorg-drivers

7. Rebuild NetworkManager if it is installed

I always do this even though not always necessary. One less thing to think about (not rebuilding it has sometimes caused me problems).

root # emerge networkmanager

8. If there is a new version of the Intel CPU microcode, generate it and copy it to the boot directory

For several years updates to the package sys-kernel/linux-firmware have not resulted in a change to the version of Intel CPU microcode for the legacy Intel Core i7-720QM CPU in my Compal NBLB2 laptop, as Intel no longer supports that version of CPU. Nevertheless it does no harm to repeat the procedure.

root # emerge sys-firmware/intel-microcode
root # rm /boot/microcode.cpio
root # iucode_tool -S --write-earlyfw=/boot/microcode.cpio /lib/firmware/intel-ucode/*
root # rm /boot/intel-uc.img

(The fourth command is to stop the grub-mkconfig command (see Step 9.2) adding intel-uc.img to the initrd line in the grub.cfg file.)

Note the USE flags for that I have set and cleared for sys-firmware/intel-microcode:

root # equery uses intel-microcode
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for sys-firmware/intel-microcode-20210608_p20210830:
 U I
 - - hostonly    : only install ucode(s) supported by currently available (=online) processor(s) 
 - - initramfs   : install a small initramfs for use with CONFIG_MICROCODE_EARLY 
 + + split-ucode : install the split binary ucode files (used by the kernel directly) 
 - - vanilla     : install only microcode updates from Intel's official microcode tarball

9. Create a new grub.cfg file

9.1 First check the contents of /etc/default/grub to make sure it will be OK for the new version of the kernel

root # nano /etc/default/grub

Modify the contents of /etc/default/grub if necessary for the kernel version that has just been built.

9.2 Generate a new grub.cfg file

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

9.3 Check the new grub.cfg file includes the loading of the CPU microcode

root # nano /boot/grub/grub.cfg

The last line for each menu entry (i.e. the line before the closing curly bracket of the menu entry) should contain:

initrd /microcode.cpio /initramfs-<kernel version>-gentoo-x86_64.img

as shown in the example file excerpt below:

[...]
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-9db2f668-a682-4d6f-abc5-ed6f6c515b95' {
load_video
set gfxpayload=1024x768
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  597e8c88-8d50-443f-ae19-f510844f5d4e
else
search --no-floppy --fs-uuid --set=root 597e8c88-8d50-443f-ae19-f510844f5d4e
fi
echo	'Loading Linux 5.15.0-gentoo-x86_64 ...'
linux	/vmlinuz-5.15.0-gentoo-x86_64 root=/dev/sda6 ro BOOT_IMAGE=/kernel-genkernel-x86_64-5.15.0-gentoo root=/dev/ram0 ramdisk=8192 real_root=/dev/sda6 init=/linuxrc resume=swap:/dev/sda5 real_resume=/dev/sda5 intel_iommu=off net.ifnames=0 snd_hda_intel.power_save=0 radeon.modeset=1
echo	'Loading initial ramdisk ...'
initrd	/microcode.cpio /initramfs-5.15.0-gentoo-x86_64.img
}
submenu 'Advanced options for Gentoo GNU/Linux' $menuentry_id_option 'gnulinux-advanced-9db2f668-a682-4d6f-abc5-ed6f6c515b95' {
menuentry 'Gentoo GNU/Linux, with Linux 5.15.0-gentoo-x86_64' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.15.0-gentoo-x86_64-advanced-9db2f668-a682-4d6f-abc5-ed6f6c515b95' {
load_video
set gfxpayload=1024x768
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  597e8c88-8d50-443f-ae19-f510844f5d4e
else
search --no-floppy --fs-uuid --set=root 597e8c88-8d50-443f-ae19-f510844f5d4e
fi
echo	'Loading Linux 5.15.0-gentoo-x86_64 ...'
linux	/vmlinuz-5.15.0-gentoo-x86_64 root=/dev/sda6 ro BOOT_IMAGE=/kernel-genkernel-x86_64-5.15.0-gentoo root=/dev/ram0 ramdisk=8192 real_root=/dev/sda6 init=/linuxrc resume=swap:/dev/sda5 real_resume=/dev/sda5 intel_iommu=off net.ifnames=0 snd_hda_intel.power_save=0 radeon.modeset=1
echo	'Loading initial ramdisk ...'
initrd	/microcode.cpio /initramfs-5.15.0-gentoo-x86_64.img
}
menuentry 'Gentoo GNU/Linux, with Linux 5.15.0-gentoo-x86_64 (recovery mode)' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.15.0-gentoo-x86_64-recovery-9db2f668-a682-4d6f-abc5-ed6f6c515b95' {
load_video
set gfxpayload=1024x768
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  597e8c88-8d50-443f-ae19-f510844f5d4e
else
search --no-floppy --fs-uuid --set=root 597e8c88-8d50-443f-ae19-f510844f5d4e
fi
echo	'Loading Linux 5.15.0-gentoo-x86_64 ...'
linux	/vmlinuz-5.15.0-gentoo-x86_64 root=/dev/sda6 ro single BOOT_IMAGE=/kernel-genkernel-x86_64-5.15.0-gentoo root=/dev/ram0 ramdisk=8192 real_root=/dev/sda6 init=/linuxrc resume=swap:/dev/sda5 real_resume=/dev/sda5 intel_iommu=off net.ifnames=0 snd_hda_intel.power_save=0 radeon.modeset=1
echo	'Loading initial ramdisk ...'
initrd	/microcode.cpio /initramfs-5.15.0-gentoo-x86_64.img
}
}

### END /etc/grub.d/10_linux ###
[...]

10. Reboot

11. Rebuild VirtualBox if it is installed

root # emerge virtualbox

12. Check the current version of the Intel CPU microcode

Either:

root # dmesg | grep microcode

or:

root # grep microcode /proc/cpuinfo

For example:

root # dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0xa, date = 2018-05-08
[    0.127937] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    1.558008] microcode: sig=0x106e5, pf=0x10, revision=0xa
[    1.559335] microcode: Microcode Update Driver: v2.2.
root # grep microcode /proc/cpuinfo
microcode       : 0xa
microcode       : 0xa
microcode       : 0xa
microcode       : 0xa
microcode       : 0xa
microcode       : 0xa
microcode       : 0xa
microcode       : 0xa

Note from the output of the dmesg command that this specific CPU model is susceptible to the MDS (Microarchitectural Data Sampling) vulnerability.

13. Edit /var/lib/portage/world and add (or change) the specific kernel sources package version

I do this in order to ensure the command ‘emerge --depclean‘ does not remove a specific kernel’s source code during a world update. I want Portage always to install the latest version of gentoo-sources but not to delete the version of gentoo-sources that corresponds to the kernel my installation is currently using.

For example, let’s say I have just replaced a kernel built from gentoo-sources:5.15.11 with a kernel built from gentoo-sources:5.15.12. My world file would initially contain the following:

[...]
sys-kernel/gentoo-sources
sys-kernel/gentoo-sources:5.15.11
[...]

If, following a successful reboot with kernel 5.15.12, I want to delete the files for kernel 5.15.11 in /boot/ (initramfs-5.15.11-gentoo-x86_64.img, System.map-5.15.11-gentoo-x86_64 and vmlinuz-5.15.11-gentoo-x86_64) and to edit the file /boot/grub/grub.cfg to remove the menu entries for kernel 5.15.11, I would change the world file’s contents to:

[...]
sys-kernel/gentoo-sources
sys-kernel/gentoo-sources:5.15.12
[...]

On the other hand, if, following a successful reboot, I want to keep the files for both kernel 5.15.11 and kernel 5.15.12, I would change the world file’s contents to:

[...]
sys-kernel/gentoo-sources
sys-kernel/gentoo-sources:5.15.11
sys-kernel/gentoo-sources:5.15.12
[...]

Work-around if movie subtitles restart after the final subtitle is displayed

If I’m watching movies in a language I don’t understand, I want subtitles. On my computers this is possible as long as there is a subtitles file with the name suffix .srt and the same prefix name as the .mp4 video file in the same directory. I usually prefer to view movies on my TV with a bigger screen, so I copy the movie to a HDD that is normally connected to my TV (a FINLUX model 43-FUD-8020). However, the built-in media player in the TV does not show the subtitles in the .srt file, even when it is in the same directory as the .mp4 file. Therefore I use the MKVToolNix utility mkvmerge to put the movie and subtitles into a Matroska multimedia container (.mkv file), and the TV’s media player can play these .mkv files and does display the subtitles. In fact, so can my laptops and desktop running Linux (I have not tried on a machine running Windows 10, but I assume Windows 10 would have no trouble either).

To install in Lubuntu 20.10:

user $ sudo apt install mkvtoolnix

To install in Gentoo Linux:

root # emerge mkvtoolnix

To create a Matroska file containing the movie plus subtitles:

user $ mkvmerge -o movie_with_subtitles.mkv movie_without_subtitles.mp4 subtitles.srt

Normally the last subtitle in a movie does not occur at the very end of the movie. For example, there could be action without dialogue at the end of the movie, and/or final credits without dialogue. The media players on my laptops and desktop running Linux display the last subtitle and play the rest of the movie in the Matroska container as expected. However, the media player in my FINLUX TV displays the last subtitle and then displays the subtitles from the beginning again, at breakneck speed. Annoying to say the least. As the problem does not occur on my laptops and desktop with the same .mkv file, I assume the problem lies with the media player in the TV.

At first I suspected that the .srt file was the cause, but it correctly uses UTF-8 encoding and the syntax of the contents is correct. Anyway, just to be sure I ran it through an online cleaner for .srt files and re-generated the .mkv file, but that made no difference on the TV. Since there is no problem playing the .mkv file on my computers, I can only assume the TV’s media player is indeed at fault. I cannot do anything about the TV’s media player, so I came up with an acceptable work-around: I added a dummy subtitle at the end of the .srt file that is set to be displayed at the very end of the movie. For example, let’s say the movie duration is two hours, 12 minutes and twenty-two seconds but the last subtitle is at 01:56:38,201:

188
01:56:38,201 --> 01:56:40,286
The end justifies the means.

I edited the file and added a dummy subtitle at the end:

188
01:56:38,201 --> 01:56:40,286
The end justifies the means.

189
02:12:19,001 --> 02:12:21,999
THE END.

I then re-generated the .mkv file using the mkvmerge command and, lo and behold, after the subtitle displayed between at 01:56:38,201 and 01:56:40,286 the TV no longer displays any more subtitles until the very end of the movie when it displays ‘THE END’ and the video ends. Actually, in reality the movie must be very slightly longer than 02:12:21,999 because, after displaying ‘THE END’, the first six subtitles in the subtitle file are displayed in rapid succession before the media player stops playing, but that is no big deal.

I searched the Web quite a lot and was unable to find any mention of this particular problem, so I am posting my work-around here just in case it helps someone else experiencing the same problem.

Gentoo Linux: Building/rebuilding a kernel and Intel CPU microcode in an installation without initramfs

In a 2016 post I explained how to update the Intel CPU microcode in a Gentoo Linux Stable Branch installation without an initramfs (I do not use sys-kernel/genkernel to build the kernel in the installation on my Clevo W230SS laptop). The behaviour of the tool sys-apps/iucode_tool for updating the Intel CPU microcode has changed since that post, hence this update.

Although not essential I normally perform the microcode upgrade procedure when I either rebuild or upgrade the Linux kernel, therefore I explain both procedures contiguously here.

These days the grub-mkconfig command edits the file /boot/grub/grub.cfg to add a line to the GRUB menu entries, to load the CPU microcode at boot, but nevertheless I prefer to follow a slightly different method that works reliably for me.

Below is the procedure I follow to build/rebuild the kernel and the Intel CPU microcode. Others may have a different approach, but this has always worked well for me, even if some of the steps are sometimes nugatory.

1. Mount the boot directory if it is on a separate partition

root # mount /dev/sda1 /boot

2. Check which kernel sources are installed and which of those sources is currently selected

root # eselect kernel list

3. Make a back-up of the current kernel configuration file

root # cp /usr/src/linux-`uname -r`/.config /home/fitzcarraldo/kernel-config-`uname -r`

4. Select the kernel sources I want to build

root # eselect kernel set <n>

5. Change to the currently selected kernel sources directory

root # cd /usr/src/linux

6. If wanting to build a new version of the kernel, create a template configuration file

N.B. Do NOT do this if rebuilding the kernel version that is currently in use.

root # cp /usr/src/linux-`uname -r`/.config /usr/src/linux/.config

7. Remove any existing object files

Definitely needed if the ‘make‘ command (see further on) returns an error message mentioning an old version of the compiler. It does no harm to perform this step in any case, so I always do it.

root # make clean

8. If building a new version of the kernel, create a new configuration file

N.B. Do NOT do this if rebuilding the kernel version that is currently in use.

root # make olddefconfig

The command ‘make olddefconfig‘ will edit the existing /usr/src/linux/.config file, keeping all the existing options in the file and setting any new options to their recommended (i.e. default) values.

9. Display a TUI menu of the kernel options in the .config file and make any desired changes

root # make menuconfig

I have configured the following kernel options relating to the early loading of the Intel CPU microcode (see later):

root # grep CONFIG_BLK_DEV_INITRD /usr/src/linux/.config
CONFIG_BLK_DEV_INITRD=y
root # grep CONFIG_MICROCODE /usr/src/linux/.config
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
# CONFIG_MICROCODE_OLD_INTERFACE is not set
root # grep CONFIG_INITRAMFS_SOURCE /usr/src/linux/.config
CONFIG_INITRAMFS_SOURCE=""

10. Build the kernel and modules

root # make && make modules_install
root # make install

11. Rebuild any third-party packages containing kernel modules

These could include packages such as nvidia-drivers, for example.

root # emerge @module-rebuild

In my case, currently the @module-rebuild set only comprises the following two packages:

root # cat /var/lib/module-rebuild/moduledb
a:1:app-emulation/virtualbox-modules-6.1.24
a:1:x11-drivers/nvidia-drivers-470.63.01

12. Rebuild the X Windows Server and X Windows drivers

I always do this even though not always necessary. One less thing to think about (not rebuilding them has sometimes caused me problems).

root # emerge xorg-server xorg-drivers

13. Rebuild NetworkManager if it is installed

I always do this even though not always necessary. One less thing to think about (not rebuilding it has sometimes caused me problems).

root # emerge networkmanager

14. If there is a new version of the Intel CPU microcode, generate it and copy it to the boot directory

Updates to the package sys-firmware/intel-microcode in the last couple of years have not resulted in a change to the version of Intel CPU microcode for the fourth-generation Intel Core i7-4810MQ CPU in my Clevo W230SS laptop, so I assume Intel no longer supports that version of CPU. Nevertheless it does no harm to repeat the procedure.

root # rm /boot/microcode.cpio
root # iucode_tool -S --write-earlyfw=/boot/microcode.cpio /lib/firmware/intel-ucode/*
root # rm /boot/intel-uc.img

(The third command is to stop the grub-mkconfig command (see later) adding intel-uc.img to the initrd line in the grub.cfg file.)

15. If a different version of the kernel has just been built, or if this is the first time upgrading the CPU microcode, create a new grub.cfg file

15.1 First check the contents of /etc/default/grub to make sure it will be OK for the new version of the kernel

root # nano /etc/default/grub

Modify the contents of /etc/default/grub if necessary for the kernel that has just been built.

15.2 Generate a new grub.cfg file

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

15.3 Check the new grub.cfg file includes the loading of the CPU microcode

root # nano /boot/grub/grub.cfg

The last line for each menu entry (i.e. the line before the closing curly bracket of the menu entry) should contain only ‘initrd /microcode.cpio‘, as shown in the example file excerpt below:

[...]
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-525a90f1-8ad2-44a3-ade3-20f18a0a9595' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  f6ffc085-66fe-4bbe-b080-cec355749f85
else
search --no-floppy --fs-uuid --set=root f6ffc085-66fe-4bbe-b080-cec355749f85
fi
echo	'Loading Linux 5.10.61-gentoo ...'
linux	/vmlinuz-5.10.61-gentoo root=/dev/sda5 ro  locale=en_GB i965.modeset=1 rcutree.rcu_idle_gp_delay=1 acpi_enforce_resources=lax reboot=force raid=noautodetect resume=/dev/sda2
echo	'Loading initial ramdisk ...'
initrd	/microcode.cpio
}
submenu 'Advanced options for Gentoo GNU/Linux' $menuentry_id_option 'gnulinux-advanced-525a90f1-8ad2-44a3-ade3-20f18a0a9595' {
menuentry 'Gentoo GNU/Linux, with Linux 5.10.61-gentoo' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.61-gentoo-advanced-525a90f1-8ad2-44a3-ade3-20f18a0a9595' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  f6ffc085-66fe-4bbe-b080-cec355749f85
else
search --no-floppy --fs-uuid --set=root f6ffc085-66fe-4bbe-b080-cec355749f85
fi
echo	'Loading Linux 5.10.61-gentoo ...'
linux	/vmlinuz-5.10.61-gentoo root=/dev/sda5 ro  locale=en_GB i965.modeset=1 rcutree.rcu_idle_gp_delay=1 acpi_enforce_resources=lax reboot=force raid=noautodetect resume=/dev/sda2
echo	'Loading initial ramdisk ...'
initrd	/microcode.cpio
}
menuentry 'Gentoo GNU/Linux, with Linux 5.10.61-gentoo (recovery mode)' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.61-gentoo-recovery-525a90f1-8ad2-44a3-ade3-20f18a0a9595' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  f6ffc085-66fe-4bbe-b080-cec355749f85
else
search --no-floppy --fs-uuid --set=root f6ffc085-66fe-4bbe-b080-cec355749f85
fi
echo	'Loading Linux 5.10.61-gentoo ...'
linux	/vmlinuz-5.10.61-gentoo root=/dev/sda5 ro single
echo	'Loading initial ramdisk ...'
initrd	/microcode.cpio
}
}

### END /etc/grub.d/10_linux ###
[...]

16. Reboot

17. Rebuild VirtualBox if it is installed

root # emerge virtualbox

18. Check the current version of the Intel CPU microcode

Either:

root # dmesg | grep microcode

or:

root # grep microcode /proc/cpuinfo

For example:

root # dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x28, date = 2019-11-12
[    0.335631] microcode: sig=0x306c3, pf=0x10, revision=0x28
[    0.335730] microcode: Microcode Update Driver: v2.2.
root # grep microcode /proc/cpuinfo
microcode       : 0x28
microcode       : 0x28
microcode       : 0x28
microcode       : 0x28
microcode       : 0x28
microcode       : 0x28
microcode       : 0x28
microcode       : 0x28

19. Edit /var/lib/portage/world and add (or change) the specific kernel sources package version

I do this in order to ensure the command ‘emerge --depclean‘ does not remove a specific kernel’s source code during a world update. I want Portage always to install the latest (stable) version of gentoo-sources but not to delete the version of gentoo-sources that corresponds to the kernel my installation is currently using.

For example, let’s say I have just replaced a kernel built from gentoo-sources:4.19.57 with a kernel built from gentoo-sources:4.19.66. My world file would initially contain the following:

[...]
sys-kernel/gentoo-sources
sys-kernel/gentoo-sources:4.19.57
[...]

If, following a successful reboot with kernel 4.19.66, I want to delete the files for kernel 4.19.17 in /boot/ (System.map-4.19.17-gentoo, config-4.19.17-gentoo and vmlinuz-4.19.17-gentoo) and to edit the file /boot/grub/grub.cfg to remove the menu entries for kernel 4.19.57, I would change the world file’s contents to:

[...]
sys-kernel/gentoo-sources
sys-kernel/gentoo-sources:4.19.66
[...]

On the other hand, if, following a successful reboot, I want to keep the files for both kernel 4.19.17 and kernel 4.19.66, I would change the world file’s contents to:

[...]
sys-kernel/gentoo-sources
sys-kernel/gentoo-sources:4.19.57
sys-kernel/gentoo-sources:4.19.66
[...]

Browsing a WebDAV share in Linux and Windows 10

In this post I explain how I configured my machines running two Linux distributions (Gentoo Linux and Lubuntu 20.10) and my Windows 10 test machine to enable me to browse a shared folder on my file server (running ownCloud, in my case) that uses the WebDAV protocol. I cover two options for configuring Linux to browse WebDAV shares. Further options exist in Linux, but the two methods I give here are fine for my purposes.

I installed ownCloud on my Linux server in a slightly different way to the method in the ownCloud installation manual, and my examples in this post use the URI https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav rather than the usual https://fitzcarraldo.ddns.net/remote.php/webdav for ownCloud, so replace the URI in my examples with the appropriate URI in your case. The username of the user account on each client machine is ‘fitz’, and the ownCloud username (davusername) on the server is ‘bsf’. Obviously replace those with the usernames in your case.

PART 1 – LINUX

Unless I mention the distribution explicitly, the following steps apply to both Linux distributions. As my Gentoo Linux installations use KDE, the steps for Gentoo Linux assume the file manager is Dolphin. My Lubuntu installation uses the file manager PCManFM-Qt.

1. Install davfs2 if it is not already installed

Gentoo Linux:

root # emerge davfs2

That command installs three packages:

acct-group/davfs2
acct-user/davfs2
net-fs/davfs2

Lubuntu 20.10:

user $ sudo apt install davfs2

2. Lubuntu 20.10: Allow mounting by non-root users

user $ sudo dpkg-reconfigure davfs2

   Package configuration
   
    ┌──────────────────────────────────────────┤ Configuring davfs2 ├───────────────────────────────────────────┐
    │                                                                                                           │
    │ The file /sbin/mount.davfs must have the SUID bit set if you want to allow unprivileged (non-root) users  │
    │ to mount WebDAV resources.                                                                                │
    │                                                                                                           │
    │ If you do not choose this option, only root will be allowed to mount WebDAV resources. This can later be  │
    │ changed by running 'dpkg-reconfigure davfs2'.                                                             │
    │                                                                                                           │
    │ Should unprivileged users be allowed to mount WebDAV resources?                                           │
    │                                                                                                           │
    │                               <Yes>                                  <No>                                 │
    │                                                                                                           │
    └───────────────────────────────────────────────────────────────────────────────────────────────────────────┘

(Do not do anything in Gentoo Linux; the SUID bit should be set automatically.)

3. Check the SUID bit has been set (notice the ‘s’ in the file’s permissions)

Gentoo Linux:

user $ ls -la /sbin/mount.davfs
lrwxrwxrwx 1 root root 21 Sep 25 23:03 /sbin/mount.davfs -> /usr/sbin/mount.davfs
user $ ls -la /usr/sbin/mount.davfs
-rws--x--x 1 root root 130752 Sep 25 23:03 /usr/sbin/mount.davfs

If the SUID bit has not be set automatically, you can do it manually:

user $ sudo chmod u+s /usr/sbin/mount.davfs

Lubuntu 20.10:

user $ ls -la /sbin/mount.davfs
-rwsr-xr-x 1 root root 137464 Aug  8  2020 /sbin/mount.davfs

4. Add the user to the davfs2 group

user $ sudo usermod -aG davfs2 fitz

Logout and login again and check the user is a member of the group:

user $ groups | grep -q davfs2 && echo "OK"
OK

5. Leave the lines in the following files commented out (i.e. accept the defaults)

/etc/davfs2/davfs2.conf (system-wide)

~/.davfs2/davfs2.conf (user-specific)

6. Option 1 (simplest!) – Enter the URI in the file manager and bookmark it

6.1 Gentoo Linux with KDE

Enter the following URI on the Dolphin file manager’s address line and press Enter:

webdavs://fitzcarraldo.ddns.net/owncloud/remote.php/webdav

You will be prompted to enter the username and password for the WebDAV share.

Select ‘File’ > ‘Add to Places’ in Dolphin to bookmark the share. From then on, you can browse the share by clicking on the share in the Remote section in Dolphin’s Places pane. You can rename the bookmark if you wish (right-click and select ‘Edit…’).

Another way to do this in KDE is as follows:

  1. click on ‘Network’ in the Places pane;
  2. click on ‘Add Network Folder’ next to the address bar;
  3. select ‘WebFolder (webdav)’ and click ‘Next’;
  4. enter the fields as follows:
    • Name: webdav
    • User: bsf
    • Server: fitzcarraldo.ddns.net
    • Port: 443 (I use Port 443 but you may be using a different port)
    • Folder: owncloud/remote.php/webdav
  5. select ‘Create an icon for this folder’ and ‘Use encryption’;
  6. click ‘Save & Connect’;
  7. right-click on the webdav icon in the main Dolphin pane and select ‘Add to Places’.

6.2 Lubuntu 20.10

Enter the following URI on the PCManFM-Qt file manager’s address line and press Enter:

davs://fitzcarraldo.ddns.net/owncloud/remote.php/webdav

You will be prompted to enter the username and password for the WebDAV share.

Select ‘Bookmarks’ > ‘Add to Bookmarks’ in PCManFM-Qt to bookmark the share. From then on, you can browse the share by clicking on the share in the Bookmarks section in PCManFM-Qt’s Lists pane. You can rename the bookmark if you wish (Bookmarks > Edit Bookmarks).

7. Option 2 – Assign a mountpoint at boot:

Add the following credentials line in the file ~/.davfs2/secrets:

https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav <davusername> <davpassword>

and set the file permissions as follows:

user $ chmod 600 ~/.davfs2/secrets

Create a user directory onto which to mount the share:

user $ mkdir ~/webdav

Add a line in /etc/fstab to map the WebDAV share onto that directory at boot:

# <file system>                                            <mount point>       <type>  <options>        <dump>  <pass>
https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav   /home/fitz/webdav   davfs   noauto,user,rw   0       0

The options ‘auto‘ and ‘_netdev‘ do not mount the WebDAV share automatically at boot in my installations; I am prompted to enter the davuser and davpassword manually early in the boot process if I include those options. To avoid the latter I use the ‘noauto‘ option and do not bother including the ‘_netdev‘ option. There are ways to mount a WebDAV share automatically at boot whether your installation uses systemd, OpenRC or other rc systems. Nevertheless I prefer the WebDAV share not to be mounted auomatically at boot, especially in the case of my laptops.

Reboot to check everything works.

Lubuntu 20.10:

The share will be listed as ‘webdav’ (unmounted) in the Devices section under Lists in PCManFM-Qt. You can click on the unmounted share to mount it, and click on the Unmount icon to unmount it. Everything works as expected.

Gentoo Linux with KDE:

The share is not listed in the Places pane in Dolphin but the share can be mounted manually from the command line as follows:

user $ mount ~/webdav
/sbin/mount.davfs: warning: the server does not support locks

(The ‘user‘ option in /etc/fstab allows the non-root user to mount the share.)

The main pane displaying the contents of ~/webdav/ will only be populated with the contents of the remote folder after the share is mounted.

The share is browsable in Dolphin. I can perform all file and folder operations in KDE apart from one thing: I cannot copy files to the server (neither from the local machine nor from the server); Dolphin displays messages such as ‘There is not enough space on the disk to write file:///home/fitz/testfile.txt’. I suspect the problem is with KDE, because I can copy files to and on the share by using the command line (for example the commands ‘cp ~/test1.txt ~/webdav/‘ and ‘cp ~/webdav/test2.txt ~/webdav/test3.txt‘ work fine). I have yet to find a solution to this issue, so I use Option 1 for Gentoo Linux running KDE, which works fine. To create a bookmark in Dolphin’s Places pane, browse the share and select ‘File’ > ‘Add to Places’.
 
PART 2 – WINDOWS 10

There is a Map Network Drive Wizard, but it is not as straightforward for WebDAV shares as it is with SMB shares. See the thread Cannot connect to webdav service for the type of behaviour I experienced, althought in my case I could rarely establish a connection using either ‘Map network drive’ or ‘Add a network location’, and the mapping was always lost if I logged out or rebooted, despite selecting ‘Reconnect at sign-in’. I then discovered several invalid URIs in Registry keys. Presumably these were left in the Registry after my various unsuccessful configuration attempts using the wizard. To finally succeed in mapping the ownCloud WebDAV shared folder I had to search for the string ‘fitzcarraldo.ddns.net’ in the Registry (see Steps 1 & 2 below for how to open the Registry) and delete any existing strings similar or identical to ‘https://fitzcarraldo.ddns.net/ownloud/remote.php/webdav‘, as they seemed to interfere with successful mapping of the network directory.

After making sure the Registry no longer contained any incorrect-looking WebDAV URIs for my ownCloud server, I used the following steps:

  1. Right-click on Windows’ Start Menu icon on the left of the Task Bar and select ‘Run’.
  2. Enter ‘regedit’ in the Open box and click ‘OK’.
  3. Select Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
  4. If the value in BasicAuthLevel is not already 2, change it to 2.
  5. In the ‘Type here to search’ box on the Task Bar, enter ‘Services’ and press Enter.
  6. Click ‘Services App’.
  7. Scroll down to ‘WebClient’ in the Services window.
  8. Right-click ‘WebClient’ and select ‘Properties’.
  9. If ‘Startup type’ is not already set to ‘Automatic’, change it to ‘Automatic’ and click ‘Apply’.
  10. Launch File Explorer.
  11. Right-click ‘This PC’ and select ‘Map network drive…’.
  12. Select the drive letter (default is Z:).
  13. In the Folder box enter \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav and make sure only ‘Reconnect at sign-in’ is ticked.
  14. Click ‘Finish’.
  15. A network icon and the label ‘webdav (\\fitzcarraldo.ddns.net@SSL\owncloud\remote.php) (Z:)’ should appear under ‘My PC’. Clicking that icon displays the contents of the shared folder of my ownCloud account on my server.

The only Registry entries containing ‘fitzcarraldo.ddns.net’ found by ‘Edit’ > ‘Find…’ are now the following:

Computer\HKEY_CURRENT_USER\Network\Z
RemotePath     REG_SZ     \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav

Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
a     REG_SZ     \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav

Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##fitzcarraldo.ddns.net@SSL#owncloud#remote.php#webdav
LabelFromReg     REG_SZ     webdav (\\fitzcarraldo.ddns.net@SSL\owncloud\remote.php)

Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\PublishingWizard\AddNetworkPlace\AddNetPlace\LocationMRU
a     REG_SZ     https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav

Computer\HKEY_USERS\S-1-5-21-4039722433-590489090-552845671-1001\Network\Z
RemotePath     REG_SZ     \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav

Computer\HKEY_USERS\S-1-5-21-4039722433-590489090-552845671-1001\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
a     REG_SZ     \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav

Computer\HKEY_USERS\S-1-5-21-4039722433-590489090-552845671-1001\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##fitzcarraldo.ddns.net@SSL#owncloud#remote.php#webdav
LabelFromReg     REG_SZ     webdav (\\fitzcarraldo.ddns.net@SSL\owncloud\remote.php)

Computer\HKEY_USERS\S-1-5-21-4039722433-590489090-552845671-1001\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\PublishingWizard\AddNetworkPlace\AddNetPlace\LocationMRU
a     REG_SZ     https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav

 
CONCLUSION

There you have it. I can browse my ownCloud user account folders on my server from my machines running Linux and from my test machine running Windows 10.

Installing and configuring davfs2 in Linux, and using Option 1 to browse a WebDAV share is very easy in both Gentoo Linux running KDE and in Lubuntu 20.10. Using Option 2 is also very easy in Lubuntu 20.10 but is not easy in Gentoo Linux running KDE, and I still need to find out if there is a better approach for Option 2 in Gentoo Linux running KDE.

I found Windows 10 the most problematic, despite the apparent simplicity of the ‘Map network drive’ and ‘Add a network location’ wizards. I discovered that, if I didn’t get the format of the URI correct the first time, Windows 10 would leave ‘cruft’ in the Registry that apparently prevented further mapping attempts from working properly and consistently.

Anyway, everything works the way I want and I hope this post is of some help to others wanting to browse a share using WebDAV, be that a folder in ownCloud, Nextcloud or any other network service requiring the WebDAV protocol.

Removing PipeWire in Gentoo Linux

PipeWire, all the rage these days, was originally developed for video but was later enhanced to support audio as well, and is now an alternative to PulseAudio and JACK. My laptop running Gentoo Stable (amd64) with the KDE Plasma Desktop had been working fine with PipeWire for some time. The pulseaudio and screencast USE flags were both declared in the file /etc/portage/make.conf. Both audio playback and recording worked fine until a recent upgrade of the packages in my world file, when neither worked any more. The Audio Volume loudspeaker icon (the applet kde-plasma/plasma-pa) on the KDE Plasma panel had a red line through it, and the KMix loudspeaker icon (the applet kde-apps/kmix) on the panel was greyed out. Although I cannot be sure, I suspect the problem started when the first version of PipeWire that supported audio was released. The output of the command ‘ps -ef | grep pulse‘ showed me that both PulseAudio and PipeWire were running. At the time I did not know that PulseAudio is not supposed to be running at the same time as PipeWire. Sometimes when I booted the laptop and logged in, the loudspeaker icons on the Panel would appear correctly and audio output would work properly, but usually this was not the case. This behaviour made me wonder if there was some sort of race condition between the two applications at startup.

Anyway, I stopped PulseAudio being launched automatically at startup. I did this by editing the file /etc/pulse/client.conf to add the line ‘autospawn = no‘ (a comment in the as-installed file indicates that the default value for autospawn is ‘yes‘). That did indeed stop PulseAudio from being launched automatically, and left only PipeWire running. The loudspeaker icons were then displayed correctly on the Panel when I logged in to the KDE Plasma Desktop, and audio output then worked. However, PipeWire did not detect the laptop’s built-in microphone, and no Recording channel was displayed by KMix and Audio Volume. The troubleshooting chapter of the Arch Linux Wiki article on PipeWire has a section suggesting a couple of fixes for this problem (Microphone is not detected by PipeWire) but, even so, I decided to ditch PipeWire and revert to PulseAudio. As much as I dislike PulseAudio (see some of my previous posts on the various problems I have experienced with it), these days it is more or less stable on this laptop and I do not have to mess around too much with audio settings.

A few KDE packages in Gentoo Linux depend on PipeWire (they require the screencast USE flag to be set). I therefore added the following two entries to a file in the directory /etc/portage/package.use/ in order to stop PipeWire being required:

>=sys-apps/xdg-desktop-portal-1.8.1 -screencast
>=kde-apps/krfb-20.12.3 -wayland

I was then able to use the usual command ‘emerge -uvDN @world‘, followed by the command ‘emerge --ask --depclean‘, to rebuild the affected packages and remove PipeWire. I also deleted the line ‘autospawn = no‘ that I had previously added to the file /etc/pulse/client.conf, so that PulseAudio would again be launched automatically at startup. Audio playback and recording are now back to normal. I will probably try PipeWire again in the future but, for the moment, I don’t need it. According to the Gentoo Linux Wiki article on PipeWire:

Warning
As of mid 2021, PipeWire is still in active development and not everything is fully integrated, tested, or implemented – though the project is moving along. While replacing existing audio solutions on Gentoo is possible, the experience is currently not guaranteed to be perfect or free of issues and bugs.

I will therefore wait until the concensus amongst Gentoo Linux users is that PipeWire is trouble-free before I try it again.