Gentoo Packages

Dracut is an initramfs generation tool. It may be invoked via the installkernel mechanism or manually after building custom kernels.

What changed? =============

In version 111 of sys-kernel/dracut the default for the hostonly_cmdline setting changed from enabled to disabled.

When enabled, this setting causes Dracut to attempt to detect which parameters are required on the kernel command line to boot the system. Examples are the root= parameter or parameters controlling partition decryption. These parameters are then included in the generated initramfs and appended to the kernel command line during boot.

Why has this setting been changed? ==================================

When enabled, Dracut's hostonly_cmdline setting may use the kernel command line of the running kernel (/proc/cmdline) to construct the kernel command line that will be embedded in the initramfs.

This can cause problems when Dracut is being executed from a live or rescue environment. In such cases an incorrect root= could be included in the embedded kernel command line which could lead to boot failure.

To prevent this behaviour from causing such unpleasant surprises, a check was added to sys-kernel/installkernel to detect whether the kernel was being installed from chroot and if Dracut was configured to include an embedded kernel command line (hostonly_cmdline=yes).

While this check prevents boot failures, it also has the unfortunate side effect of creating a hard error that is triggered by default on new Gentoo installs. This has proven to be a significant stumbling block that new users often trip over. For this reason it was decided to disable the hostonly_cmdline setting in Gentoo's default settings for Dracut.

User Action Required (all users) ================================

With >=sys-kernel/dracut-111, users need to perform a sanity check described in this news item.

This sanity check will ensure that kernel parameters required to boot successfully are still present in the kernel command line. When in doubt, ensure system rescue media is close at hand.

More specific instructions for various setups follow below, ordered from the specific to the more general as listed here:

• Systemd GPT Auto Generator
• Generic Unified Kernel Image
• Unified Kernel Image with Secure Boot
• GRUB
• systemd-boot
• rEFInd
• other/general

For each option a summarised list of relevant files that should be double checked is provided first. In general the 'lsinitrd' tool provided by sys-kernel/dracut can be used to obtain the current embedded kernel command line, these kernel parameters will be absent after (re)generating an initramfs with version 111 of dracut.

As always, do not hesitate to use our support channels to ask for clarification or assistance.

> User Action Required (Systemd GPT Auto Generator)

=================================================
Files to double check:

• /dev/gpt-auto-root (symlink must be valid)
• If absent then the auto generator is not being used.

Systems that utilise the systemd GPT Auto Generator mechanism to automatically detect and find the root partition at boot should not require any manual intervention. Though, before rebooting, users should verify that the auto generator is actually being used and is working properly. To do so, check that /dev/gpt-auto-root currently exists and points to your root partition. For example:

$ ls -l /dev/gpt-auto-root

Should produce an output similar to the below if /dev/nvme0n1p1 is the root partition:

"""Output:
lrwxrwxrwx 1 root root 4 May  2 10:33 /dev/gpt-auto-root -> nvme0n1p1
"""

If this is not the case then proceed with the instructions below that best match the setup to ensure that the root partition is set on the kernel command line using an alternative method.

> User Action Required (Generic Unified Kernel Image: "generic-uki")

==================================================================
Files to double check:

• none

Users booting with the generic Unified Kernel Image (USE=generic-uki) functionality provided by the distribution kernels (dist-kernel) do not have to take any action as the hostonly_cmdline is already disabled in these builds:

• sys-kernel/vanilla-kernel[generic-uki]
• sys-kernel/gentoo-kernel[generic-uki]
• sys-kernel/gentoo-kernel-bin[generic-uki]

> User Action Required (Unified Kernel Image with Secure Boot)

============================================================
Files to double check:

• /etc/kernel/cmdline and/or /etc/kernel/uki.conf (ukify)
• /etc/dracut.conf and/or /etc/dracut.conf.d/*.conf (dracut)

Booting a Unified Kernel Image (UKI) with Secure Boot enabled is a special case because in this situation the kernel command line supplied by the bootloader or the firmware is ignored and the built-in UKI command line, along with the parameters embedded in the initramfs, take precedence. The instructions below are also relevant if no kernel command line is set by the bootloader or the firmware.

Verify whether Secure Boot is enabled with dmesg, for example:

$ dmesg | grep -i secure
"""Output:
[    0.012418] Secure boot enabled
"""

An easy way to check the built-in kernel command line of an UKI is to use the lsinitrd tool provided by sys-kernel/dracut. For example:

$ lsinitrd /efi/EFI/Linux/gentoo-x.y.z-gentoo-dist.efi

This command will produce an output that could contain for example:

"""Output:
<snip>
Command line:
quiet
splash
root=PARTUUID=7ae430c6-07e8-3b4e-a796-b2a28706b3fb
<snip>
dracut cmdline:
ro
"""

Showing that the built-in kernel command line for this UKI contains "quiet", "splash" and sets the root partition to the partition that has the partition UUID "7ae430c6-07e8-3b4e-a796-b2a28706b3fb". Additionally, the kernel command line embedded in the initramfs contains "ro".

If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in the "Command line" section then user intervention is required. In that case please adjust the configuration of the UKI generator to include the appropriate kernel parameters in the built-in UKI command line.

If Ukify (sys-apps/systemd[ukify] or sys-apps/systemd-utils[ukify]) is generating the UKI then adjust the "Cmdline=" setting in /etc/kernel/uki.conf. If that setting is not present in the uki.conf then adjust the kernel command line in /etc/kernel/cmdline.

If Dracut itself is generating the UKI then please set or adjust the "kernel_cmdline=" setting in a dracut configuration file in /etc/dracut.conf.d/.

If unsure which tool is generating the UKI then please inspect the current value of "uki_generator" in /usr/lib/kernel/install.conf and /etc/kernel/cmdline.

> User Action Required (GRUB)

===========================
Files to double check:

• /etc/default/grub

Users booting with GRUB should compare the GRUB_CMDLINE_LINUX setting in /etc/default/grub against the kernel command line embedded in the initramfs or Unified Kernel Image (UKI). The lsinitrd utility provided by sys-kernel/dracut can be used for this purpose. For example, in the case of a plain initramfs:

$ lsinitrd /boot/initramfs-x.y.z-gentoo-dist.img

Or, in the case of an Unified Kernel Image:

$ lsinitrd /boot/vmlinuz-x.y.z-gentoo-dist.efi

The final lines of the output of these commands show which kernel parameters are embedded in the Dracut initramfs. For example:

"""Output:
<snip>
dracut cmdline:
ro
"""

If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in /etc/default/grub then user intervention is required. In that case please adjust the GRUB_CMDLINE_LINUX setting in /etc/default/grub to include the missing kernel parameters. After adjustments don't forget to update the grub.cfg. For example:

$ grub-mkconfig -o /boot/grub/grub.cfg

Note that when Secure Boot is enabled the grub.cfg might reside in a different directory, for example: /efi/EFI/Gentoo/grub.cfg.

> User Action Required (systemd-boot)

===================================
Files to double check:

• /etc/kernel/cmdline

Users booting with systemd-boot should compare the contents of /etc/kernel/cmdline against the kernel command line embedded in the initramfs or Unified Kernel Image (UKI).

If Unified Kernel Images are used and the /etc/kernel/cmdline file is empty or missing then no kernel command line is set by systemd-boot, in this case please refer to the "Unified Kernel Image with Secure Boot" section above, even if Secure Boot is not enabled.

The lsinitrd utility provided by sys-kernel/dracut can be used to inspect the kernel parameters embedded in an initramfs or UKI. For example, in the case of a plain initramfs:

$ lsinitrd /efi/gentoo/x.y.z-gentoo-dist/initrd

Or, in the case of an Unified Kernel Image:

$ lsinitrd /efi/EFI/Linux/gentoo-x.y.z-gentoo-dist.efi

The final lines of the output of these commands show which kernel parameters are embedded in the Dracut initramfs. For example:

"""Output:
<snip>
dracut cmdline:
ro
"""

If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in /etc/kernel/cmdline then user intervention is required. In that case please adjust /etc/kernel/cmdline to include the missing kernel parameters.

> User Action Required (rEFInd)

=============================
Files to double check:

• refind_linux.conf

Users booting with rEFInd should compare kernel command line set in the refind_linux.conf file against the kernel command line embedded in the initramfs or Unified Kernel Image (UKI).

The refind_linux.conf configuration file usually resides in /boot but may also be found elsewhere.

If Unified Kernel Images are used and the refind_linux.conf configuration file is empty or missing then no kernel command line is set by rEFInd, in this case please refer to the "Unified Kernel Image with Secure Boot" section above, even if Secure Boot is not enabled.

The lsinitrd utility provided by sys-kernel/dracut can be used to inspect the kernel parameters embedded in an initramfs or UKI. For example, in the case of a plain initramfs:

$ lsinitrd /boot/initramfs-x.y.z-gentoo-dist.img

Or, in the case of an Unified Kernel Image:

$ lsinitrd /boot/vmlinuz-x.y.z-gentoo-dist.efi

The final lines of the output of these commands show which kernel parameters are embedded in the Dracut initramfs. For example:

"""Output:
<snip>
dracut cmdline:
ro
"""

If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in the refind_linux.conf then user intervention is required. In that case please adjust refind_linux.conf to include the missing kernel parameters.

> User Action Required (other/general)

====================================

For other setups please refer to the wiki page or manual of your bootloader and find where the kernel command line is set. Then compare this setting with the kernel parameters embedded in the initramfs.

If essential parameters are present in the later but not in the former, then please move those parameters to your bootloader's configuration.

When Unified Kernel Images are used then also consider the built-in UKI command line set by the UKI generator. Note that when Secure Boot is disabled, the bootloader may override the built-in UKI command line. However, when Secure Boot is enabled then any parameters set by the bootloader are ignored and the built-in UKI command line is always used.

See Also ========

[1] https://github.com/dracut-ng/dracut-ng/pull/2399 [2] https://bugs.gentoo.org/971572

Newer versions of Portage are making two changes to how binary packages work: 1) binary package signatures are now verified by default [0]; 2) fetched binary packages are stored separately from locally-built binaries

 (this change is already in a recent Portage release) [1].

 Remote binary packages are now cached in /var/cache/binhost/NAME where
 NAME is given by the configuration item in /etc/portage/binrepos.conf. This
 allows clean separation of locally built binary packages vs. those with
 remote provenance, and to allow verification of fetched packages without
 forcing signing to be set up for local binpkgs.

 The cache location can be customised by setting `location` in binrepos.conf.
 gentoolkit has been updated to handle these cache locations too.

This news item only applies if you use or produce binary packages.

Official binhost users ======================

Fetched binary packages are now stored at /var/cache/binhost/gentoo (or a similar path, depending on contents of /etc/portage/binrepos.conf/*).

No action is required, for two reasons: 1) all of the documentation included FEATURES="binpkg-request-signature", and 2) attempts to install a binpkg that is signed without any configuration

 would fail early.

The only impact is that future binary package installs will need less setup. Setting FEATURES="binpkg-request-signature" is no longer needed for this case.

Users may need to run `eclean-pkg` to cleanup old binary packages in the old, mixed location.

Users of just the official binary host can stop reading at this point.

Custom binhosts ===============

Users who host their own binary packages and redistribute them to their machines will need to either: 1) start signing their binpkgs [2], or 2) set `verify-signature = false` in /etc/portage/binrepos.conf/* for

 the relevant configuration file for your binhost.

Otherwise, fetched binpkgs will fail verification.

To set up signing for binpkgs, a signing keyring must reside (by default) at /root/.gnupg and a verification keyring must reside (by default) at /etc/portage/gnupg. The verification keyring must mark the signing key as trusted. Signing is toggled by FEATURES="binpkg-signing".

You can opt-in to this change early by setting `verify-signature = true` in /etc/portage/binrepos.conf/* for each binary repository configured, or under the special '[DEFAULT]' section.

Users may need to run `eclean-pkg` to cleanup old binary packages in the old, mixed location.

This does not apply if your binhost uses the old XPAK binary package format, but we encourage switching to BINPKG_FORMAT="gpkg" if that is the case.

[0] https://bugs.gentoo.org/945384 [1] https://bugs.gentoo.org/945385 [2] https://wiki.gentoo.org/wiki/Binary_package_guide#Binary_package_OpenPGP_signing

What Changed ============

The SELinux policy packages have all been bumped to EAPI 8.

POLICY_TYPES, which used to be an environment variable, is now a USE expand named SELINUX_POLICY_TYPES. The use of USE_EXPAND fixes some longstanding bugs and allows users to switch policy types more easily.

Whilst the POLICY_TYPES environment variable is considered deprecated going forward, it is still necessary to keep it set (and in sync with SELINUX_POLICY_TYPES) until you are certain that all installed policy packages on your system have been updated.

Please read on for further instructions.

For Users ========= Set SELINUX_POLICY_TYPES in your package.use to match what POLICY_TYPES is currently set to. To get the current value of POLICY_TYPES:

$ portageq envvar POLICY_TYPES

And to set SELINUX_POLICY_TYPES:

# echo 'SELINUX_POLICY_TYPES="mcs"' >>/etc/portage/make.conf

OR

# echo "sec-policy/* SELINUX_POLICY_TYPES: mcs" >>/etc/portage/package.use/selinux-policy

Then, update the system to install the updated policy packages:

# emerge --verbose --ask --update --deep --newuse @world

DO NOT unset POLICY_TYPES until you are certain that all of the policy packages installed have been updated to use EAPI 8 (or above). You can use this command to find all outdated installed policy packages that have not been updated yet:

$ qgrep -eNJ 'EAPI="\?7"\?' 'sec-policy/*'

If the above command returns an empty list, then it is safe to remove the POLICY_TYPES variable.

For Overlay Maintainers ======================= In your SELinux policy packages, bump the EAPI variable to EAPI=8. If your packages have any form of dependency on another policy package, it is neccessary to constrain their USE flags with the new eclass variable SELINUX_POLICY_USEDEP. See selinux-policy-2.eclass(5) for more details.

We are planning to switch the default Python target of Gentoo systems on 2026-06-01, from Python 3.13 to Python 3.14. If you have not changed the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will have immediate effect on your system and the package manager will try to switch automatically on the next upgrade following the change.

Most users do not need to do anything and it is best to wait until the switch date, as packages are still being ported.

If you did change the values, prefer to have more control over when the switch occurs, or have problems with the update, read on.

Please note that the default upgrade method switches packages to the new Python versions as they are rebuilt. This means that all interdependent packages have to support the new version for the upgrade to proceed, and that some programs may temporarily fail to find their dependencies throughout the upgrade (although programs that are already started are unlikely to be affected).



If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared in make.conf, please remove these declarations as they will interfere with the package.use samples provided below. Using make.conf for Python targets is discouraged as it prevents package defaults from applying when necessary. This news item assumes using /etc/portage/package.use or your package manager's equivalent file for configuration.



At this point, you have a few configuration options to choose from:

1. If you wish Python upgrades to apply automatically, you can remove

 PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations.  When
 the defaults change, your package manager should handle the upgrade
 automatically.  However, you may still need to run the update
 commands if any problems arise.

2. If you wish to defer the upgrade for the time being, you can

 explicitly set the old values in package.use.

3. If you wish to force the upgrade earlier, you can explicitly set

 the new values and run the upgrade commands.

4. If you wish to use a safer approach (i.e. less likely to temporarily

 break packages during the upgrade), you can perform a multi-step
 upgrade as outlined below.

5. Finally, you can use an arbitrary combination of PYTHON_TARGETS

 and PYTHON_SINGLE_TARGET.

Deferring the upgrade ===================== To defer the upgrade, explicitly set the old targets:

  */* PYTHON_TARGETS: -* python3_13
  */* PYTHON_SINGLE_TARGET: -* python3_13

This will enforce Python 3.13 and block any future updates. However, please note that this is only a temporary solution and you will eventually need to perform the migration.



Forcing the upgrade =================== To force the upgrade earlier, explicitly select the Python 3.14 targets:

  */* PYTHON_TARGETS: -* python3_14
  */* PYTHON_SINGLE_TARGET: -* python3_14

However, it is important to remember to remove this after the defaults change, as it will interfere with the automatic switch to the next Python version in the future.



Safer upgrade procedure ======================= A safer approach is to add Python 3.14 support to your system first, and only then remove Python 3.13. However, note that this involves two rebuilds of all the affected packages, so it will take noticeably longer.

First, enable both Python 3.13 and Python 3.14, and then run the upgrade commands:

  */* PYTHON_TARGETS: -* python3_13 python3_14
  */* PYTHON_SINGLE_TARGET: -* python3_13

Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades:

  */* PYTHON_TARGETS: -* python3_13 python3_14
  */* PYTHON_SINGLE_TARGET: -* python3_14

Finally, switch to the final version and upgrade:

  */* PYTHON_TARGETS: -* python3_14
  */* PYTHON_SINGLE_TARGET: -* python3_14

You may wish to remove the target overrides after the defaults switch. Alternatively, you can keep them to block the next automatic upgrade to Python 3.15, and upgrade manually then.



Upgrade commands ================ The Python 3.13 cleanup requires that Python 3.13 is removed from the complete dependency trees in batch. If some of the installed packages using an older Python version are not triaged for the upgrade, the package manager will throw dependency conflicts. This makes it important that the upgrade is carried via a --deep --changed-use @world upgrade, as well as that any stray packages are removed prior to it, e.g.:

  emerge --depclean
  emerge -1vUD @world
  emerge --depclean

Other Python implementations ============================ At the same time, we are also going to remove the target support for Python 3.11 (python3_11) and PyPy 3.11 (pypy3_11). Since there are no plans to release a Python 3.12-compatible PyPy version yet, Gentoo will be removing PyPy support for the time being.

# Varnish Renamed to Vinyl-Cache

As of version 9.0.0, www-servers/varnish has been renamed to www-servers/vinyl-cache in line with upstream's change of name[0][1][2][3]. The name change also affects binaries, directories, init scripts, configuration and the user and group used by the server daemon.

If you are upgrading from a previous version of www-servers/varnish you will need to update your configuration as described in "Upgrading" below.



# Changes

All varnish* binaries have been renamed to their vinyl* equivalents:

varnishd -> vinyld varnishlog -> vinyllog varnishncsa -> vinylncsa varnishadm -> vinyladm varnishhist -> vinylhist varnishstat -> vinylstat varnishstat_help_gen -> vinylstat_help_gen varnishstatdiff -> vinylstatdiff varnishtest -> vinyltest varnishtop -> vinyltop

This name change also affects all related conf.d/* files, init scripts, systemd service files, logrotate etc.

The api library has been renamed: libvarnishapi.so -> libvinylapi.so

In these conf.d files, all VARNISH* options are now VINYL* and you will need to update your configuration accordingly:

/etc/conf.d/varnishd -> /etc/conf.d/vinyld /etc/conf.d/varnishlog -> /etc/conf.d/vinyllog /etc/conf.d/varnishncsa -> /etc/conf.d/vinylncsa

The configuration directory has been moved: /etc/varnish/ -> /etc/vinyl-cache/

Other varnish directories have also been renamed:

/usr/include/varnish -> /usr/include/vinyl-cache /usr/lib/varnish -> /usr/lib/vinyl-cache /usr/lib64/varnish -> /usr/lib64/vinyl-cache /usr/share/varnish -> /usr/share/vinyl-cache /var/lib/varnish -> /var/lib/vinyl-cache /var/log/varnish -> /var/log/vinyl-cache



# Upgrading

To upgrade from varnish 8.x to 9.x:

0) Take a backup of your existing configuration files 1) Stop all running varnish services 2) emerge --oneshot www-servers/vinyl-cache 3) Update and install your VCL files in /etc/vinyl-cache/

You can now start the new vinyld, vinyllog and vinylncsa services, remembering to add them to the appropriate runlevels as usual. Ditto systemd services.

For more details of the changes, you are encouraged to read the upstream announcement[0].



# Refs

[0] https://vinyl-cache.org/docs/9.0/whats-new/upgrading-9.0.html [1] https://vinyl-cache.org/organization/20-years.html [2] https://vinyl-cache.org/organization/new-identity.html [3] https://vinyl-cache.org/organization/on_vinyl_cache_and_varnish_cache.html

The default local database type in mail-mta/postfix has been hash for local files and btree for caches and both file types depend on sys-libs/db. However, BerkeleyDB has not been developed sufficiently in recent years and the licensing change in 2013 made using the latest versions of BerkeleyDB problematic. Consequently, we are stuck with using ancient versions of BerkeleyDB and there is a general tendency in the Linux ecosystem to sunset BerkeleyDB support.

Postfix made switching database types easier with its latest release. We will be changing the default database type in postfix for both local databases and caches to lmdb starting with mail-mta/postfix-3.11.0.

# Timeline:

• mail-mta/postfix-3.11.0: March 2026. Both lmdb and berkdb USE flags are on by default. BerkeleyDB is still supported but the default database and cache type changes to lmdb.

• mail-mta/postfix-3.12.0: Expected Q1 2027. BerkeleyDB support will be off by default. You will need to turn it on manually if still needed. mail-mta/postfix will continue supporting BerkeleyDB until it is sunsetted in Gentoo.

Changing the default database and cache types in postfix-3.11.0 requires migration for the entries in main.cf and master.cf that do not specify a database type.

It is almost always a good idea to specify database type in main.cf and master.cf and in your postmap commands. As you are always specifying the database type, the default database and cache type settings do not come into play.

Option 1: Accept the new defaults and migrate to lmdb. The default USE flags take effect and lmdb becomes the new default when >=mail-mta/postfix-3.11.0 is installed. All local database files without a specified type and, optionally, caches need to be migrated to lmdb.

If your configuration is simple or if you are familiar with Postfix configuration, a few "grep" commands will find all the problems, and a few edits will be easy to make.

Read https://www.postfix.org/NON_BERKELEYDB_README.html#manual for a complete walk through and the commands you can run to find instances of BerkeleyDB usage in your postfix configuration.

Option 2: If your configuration is too complex for the manual migration step above or if you are not familiar with the details of your postfix configuration, postfix provides enable-redirect[1] and enable-reindex[2] options. Read the documentation for the details and their caveats. They provide valuable help in migration, especially for an operating system that do not have BerkeleyDB support anymore - which is NOT the case for Gentoo. However, these options still help in complex configuration cases.

Option 3: Turning off lmdb USE flag is not recommended but is possible. The default stays the same as previous versions of postfix, namely hash for local files and btree for caches. No further action is necessary until BerkeleyDB support is sunsetted in Gentoo when you will have to do the above migration.

For more details, please read: https://www.postfix.org/NON_BERKELEYDB_README.html



[1] https://www.postfix.org/NON_BERKELEYDB_README.html#enable-redirect [2] https://www.postfix.org/NON_BERKELEYDB_README.html#enable-reindex

www-client/chromium is now available as a slotted package, allowing multiple versions to be installed simultaneously.

The new slots are:

• www-client/chromium:stable - the latest 'stable' channel release
• www-client/chromium:beta - the latest 'beta' channel release
• www-client/chromium:unstable - the latest 'dev' channel release

Upstream are inconsistent with `dev` channel naming, so we've gone with 'unstable' to match www-client/google-chrome* packaging.

The biggest change to end-users is that various Chromium versions will no longer share a single profile directory, instead each slot (channel) will have its own profile directory as e.g. the various www-client/google-chrome packages work now.

This change is particularly useful for developers who need to test their applications against different versions of Chromium, and protects against incompatible profile downgrades when switching between versions.

Users on stable should not expect to see any major change, however any Progressive Web Applications (PWAs) may need to be "reinstalled" after the upgrade to update the desktop files.

Users on ~arch may wish to select a specific slot to use, as due to the nature of Chromium releases, the latest ~arch version will switch between the stable and beta slots depending on where we are in the release cycle.

The same advice applies to users of the dev/unstable channel (unkeyworded) as well - they may end up unexpectedly upgraded to beta if the dev channel is delayed during a promotion.

Impacted users should explicitly select the appropriate slot(s) to use, e.g. by selecting www-client/chromium:stable or www-client/chromium:beta:

  emerge --deselect www-client/chromium
  emerge --noreplace www-client/chromium:stable

sssd now runs as its own user, rather than root, and uses file capabiltites for its helpers. Although it had this functionalilty for a while, it wasn't completely usable until 2.10.

sssd-2.12.0 will be the first keyworded version in Gentoo with this change, made available shortly.

Because of the user change, the sssd database, logs, and configuration files must have their ownership changed.

== Systemd users == After upgrading sssd to >=2.10, stop the sssd service. Then execute the following commands:

chown -R sssd:sssd /var/lib/sss chown -R sssd:sssd /var/log/sssd

Then restart the sssd service and verify it launched succesfully.

== openrc users ===

After upgrading sssd, stop the sssd service. Then execute the following commands:

chown -R sssd:sssd /var/lib/sss chown -R sssd:sssd /var/log/sssd chown -R root:sssd /etc/sssd

Then restart the sssd service and verify it launched succesfully.