What were you trying to do that didn't work?

Basically, DNF checks whether the command is run as root, and if not it ends with an explicit error.

Trying to workaround this with `fakeroot` from Fedora/EPEL allows to move forward but an error occurs later with `rpm` which cannot chroot.

Trying to combine both fakechroot + fakeroot (another utility available on EPEL) does not help much, lots of packages cannot be extracted (cpio errors) and some other fails while executing their scriptlets.

Running DNF through `unshare -r` allows chrooting, but ends with similar errors than the previous combination. Nevertheless, it can work this way on an already "deployed" installroot where some core packages are already installed (at least filesystem/glibc/util-linux/systemd/dbus-broker).

What is the impact of this issue to you?

It is blocking their migration of an internal software distribution mechanism.

Please provide the package NVR for which the bug is seen:

dnf-4.14.0-9.el9.noarch

How reproducible is this bug?:

Always

Steps to reproduce

1. $ dnf --releasever=9.4 --installroot=$(pwd)/inst install dnf

Expected results

To be able to install a base OS on a user writeable directory.

Actual results

Blocked by the dnf software.