Dnf system-upgrade fails with wrong errors

Ask Fedora
, ,
1

On one of my servers I am still running Fedora 42 and wanted to upgrade to F43.

I am using a self hosted repo, where I keep packages I create. Before upgrading I always make sure that the packages (or newer ones) are available for the new release as well. In this case Fedora 43.
This worked forever. But on Fedora 42, I get the following messages:

dnf system-upgrade download --releasever=43
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem 1: problem with installed package
  - rustypaste-0.16.1-1.fc42.x86_64 does not belong to a distupgrade repository
  - nothing provides group(rustypaste) needed by rustypaste-0.16.1-1.fc43.x86_64 from evermeet
  - nothing provides user(rustypaste) needed by rustypaste-0.16.1-1.fc43.x86_64 from evermeet
 Problem 2: problem with installed package
  - gotify-server-2.6.2-1.fc42.x86_64 does not belong to a distupgrade repository
  - nothing provides group(gotify) needed by gotify-server-2.6.2-1.fc43.x86_64 from evermeet
  - nothing provides user(gotify) needed by gotify-server-2.6.2-1.fc43.x86_64 from evermeet
 Problem 3: problem with installed package
  - atuin-server-18.9.0-1.fc42.x86_64 does not belong to a distupgrade repository
  - nothing provides group(atuin) needed by atuin-server-18.9.0-1.fc43.x86_64 from evermeet
  - nothing provides user(atuin) needed by atuin-server-18.9.0-1.fc43.x86_64 from evermeet
 Problem 4: problem with installed package
  - package vaultwarden-1.34.3^20251021.a85b4851-1.fc43.x86_64 from evermeet requires group(vaultwarden), but none of the providers can be installed
  - package vaultwarden-1.34.3^20251021.a85b4851-1.fc43.x86_64 from evermeet requires user(vaultwarden), but none of the providers can be installed
  - package vaultwarden-1.34.3^20251101.9017ca26-2.fc43.x86_64 from evermeet requires group(vaultwarden), but none of the providers can be installed
  - package vaultwarden-1.34.3^20251101.9017ca26-2.fc43.x86_64 from evermeet requires user(vaultwarden), but none of the providers can be installed
  - package vaultwarden-1.34.3^20251101.9017ca26-3.fc43.x86_64 from evermeet requires group(vaultwarden), but none of the providers can be installed
  - package vaultwarden-1.34.3^20251101.9017ca26-3.fc43.x86_64 from evermeet requires user(vaultwarden), but none of the providers can be installed
  - package vaultwarden-1.34.3^20251101.9017ca26-4.fc43.x86_64 from evermeet requires group(vaultwarden), but none of the providers can be installed
  - package vaultwarden-1.34.3^20251101.9017ca26-4.fc43.x86_64 from evermeet requires user(vaultwarden), but none of the providers can be installed
  - vaultwarden-1.34.3^20251101.9017ca26-4.fc42.x86_64 does not belong to a distupgrade repository
  - package vaultwarden-1.33.2-3.fc43.x86_64 from fedora is filtered out by exclude filtering

I have no idea what the problem is. All the required packages are available in my f43 repo. Btw, at one point in the past (around F37) I didn’t have a repo for the new release at the time of the upgrade, but the upgrade still ran through w/o error messages.

So these error messages make no sense. I have been using this method since the dnf system plugin became stable and never ran into such a problem.

Please help.

P.S.: I create the users/groups in the .spec as follows:

%pre
getent group %{pkg_name} >/dev/null || groupadd -r %{pkg_name}
getent passwd %{pkg_name} >/dev/null || useradd -r -g %{pkg_name} -d %{_sharedstatedir}/%{pkg_name} -s /sbin/nologin -c "user for %{pkg_name}" %{pkg_name}
exit 0
2

Changes/RPMSuportForSystemdSysusers - Fedora Project Wiki

3

Thanks, once again I was bitten by the lack of proper documentation.

The link you mentioned and the subsequent links do not tell me that a packager must use the sysusers.d framework or new macros . As a matter of fact, they don’t, even though it seems to be encouraged.

But what packagers must do is adding provides: directives all of a sudden.

After I had added the following to my .spec files and built new packages, all was good:

Provides:   user(%{pkg_name})
Provides:   group(%{pkg_name})

Of course I could also use the sysusers.d method, which just adds more lines to the spec files. If I were to use it, I’d have to add 10 more lines to my spec files.
Not really a problem, but extremely annoying when it worked before without those lines.

5

Yes, but this means you have to use it. My point was that I didn’t but the upgrade required packages with provides: user(x) and provides: group(x) directives.

That is, if you want a static file and user info.

I want the file to be named according to the package name and the user as well.
This means I have to create it like this (in the %prep section):

cat >%{_builddir}/%{pkg_name}-%{version}/%{pkg_name}.sysusers.conf <<EOF
u %{pkg_name} - "user for %{pkg_name}" %{_sharedstatedir}/%{pkg_name} /sbin/nologin
EOF

Either way, I added 2 lines and all good. In the future I might use sysusers.d, but currently I am too annoyed to do it.