Well, the first problem is that the error messages from rpm do not pass through to the user. This can be easily fixed (PR https://github.com/rpm-software-management/dnf/pull/1434). With this patch you will see actual transaction test error:

RPM: error: Unable to change root directory: Operation not permitted

So the rpm uses chroot() call which is not permitted for a normal user. I tried to add fakechroot to the call, but this leads to a bunch of other rpm errors:

$ fakechroot fakeroot dnf install --releasever=30 --installroot=`pwd`/f30 --forcearch=aarch64 --repo=fedora --repo=updates -v -y systemd passwd dnf fedora-release vim-minimal
<snip>
RPM: error: cannot open Basenames index using db5 - No such file or directory (2)
RPM: error: cannot open Group index using db5 - No such file or directory (2)
RPM: error: cannot open Requirename index using db5 - No such file or directory (2)
RPM: error: cannot open Providename index using db5 - No such file or directory (2)
RPM: error: cannot open Conflictname index using db5 - No such file or directory (2)
RPM: error: cannot open Obsoletename index using db5 - No such file or directory (2)
RPM: error: cannot open Triggername index using db5 - No such file or directory (2)
RPM: error: cannot open Dirnames index using db5 - No such file or directory (2)
RPM: error: cannot open Installtid index using db5 - No such file or directory (2)
RPM: error: cannot open Sigmd5 index using db5 - No such file or directory (2)
RPM: error: cannot open Sha1header index using db5 - No such file or directory (2)
RPM: error: cannot open Filetriggername index using db5 - No such file or directory (2)
RPM: error: cannot open Transfiletriggername index using db5 - No such file or directory (2)
RPM: error: cannot open Recommendname index using db5 - No such file or directory (2)
RPM: error: cannot open Suggestname index using db5 - No such file or directory (2)
RPM: error: cannot open Supplementname index using db5 - No such file or directory (2)
RPM: error: cannot open Enhancename index using db5 - No such file or directory (2)

With increased rpm verbosity level (--rpmverbosity debug) it says

D: running pre-transaction scripts
D: filesystem-3.10-1.fc30.x86_64: Header V3 RSA/SHA256 Signature, key ID cfc659b9: OK
D: filesystem-3.10-1.fc30.x86_64: Header SHA256 digest: OK
D: filesystem-3.10-1.fc30.x86_64: Header SHA1 digest: OK
D: %pretrans(filesystem-3.10-1.fc30.x86_64): running <lua> scriptlet.
fdio:       6 reads,  1109520 total bytes in 0.000169 secs
RPM: D: computing 20365 file fingerprints
RPM: D: opening  db index       /home/mblaha/f30/var/lib/rpm/Basenames (none) mode=0x42
RPM: D: opening  db index       /home/mblaha/f30/var/lib/rpm/Basenames 0x1 mode=0x42
RPM: error: cannot open Basenames index using db5 - No such file or directory (2)

which is strange as the file exists:
$ ls -la /home/mblaha/f30/var/lib/rpm/Basenames
-rw-r--r--. 1 mblaha mblaha 8192 Jul 17 07:47 /home/mblaha/f30/var/lib/rpm/Basenames


The culprit here is the pre-transaction scriptlet of filesystem package.

As a workaround, I tried to do the instalation in two steps - first install filesystem package with scriptlets disabled:
$ fakechroot fakeroot dnf install --releasever=30 --installroot=`pwd`/f30 --forcearch=aarch64 --repo=fedora --repo=updates -v -y --setopt=tsflags=noscripts filesystem
and then run the original command:
$ fakechroot fakeroot dnf install --releasever=30 --installroot=`pwd`/f30 --forcearch=aarch64 --repo=fedora --repo=updates -v -y systemd passwd dnf fedora-release vim-minimal

But this second command failed on scriptlets again (probably as a result of filesystem pre-trans scriptlet not had been ran).

Rpm folks, any thoughts about why the pre-transaction scriptlets are causing these failures?

"fakeroot" by itself (as in the initial report) wont stand a chance at working as rpm does an actual chroot which fakeroot, fakechroot is needed for that (as in the above comment).

I ran into this years ago when starting to build the rpm test-suite which relies on fakechroot, my memory is a bit fuzzy on the details but I think the culprit was essentially this: rpm expects to manage going in and out of the chroot by itself, whereas fakechroot (much like real chroot utility) actually puts it into such an environment to begin with, and because of this rpm can't find its stuff. So fakechroot and rpm's --root (and thus dnf/yum --installroot options too) are inherently incompatible.

Using rpm under fakechroot is possible if you drop --root / from rpm and let fakechroot take you to that root. The same will apply to dnf/yum, but I don't know if it can actually be made to work like that.

Oh and FWIW, in rawhide rpm has experimental support for userns-based chroot() so you don't actually need fakechroot for that, but there might be any number of other permission issues blocking the road.

(In reply to Panu Matilainen from comment #2)
> "fakeroot" by itself (as in the initial report) wont stand a chance at
> working as rpm does an actual chroot which fakeroot, fakechroot is needed
> for that (as in the above comment).
> 
> I ran into this years ago when starting to build the rpm test-suite which
> relies on fakechroot, my memory is a bit fuzzy on the details but I think
> the culprit was essentially this: rpm expects to manage going in and out of
> the chroot by itself, whereas fakechroot (much like real chroot utility)
> actually puts it into such an environment to begin with, and because of this
> rpm can't find its stuff. So fakechroot and rpm's --root (and thus dnf/yum
> --installroot options too) are inherently incompatible.
>
> Using rpm under fakechroot is possible if you drop --root / from rpm and let
> fakechroot take you to that root. The same will apply to dnf/yum, but I
> don't know if it can actually be made to work like that.

All useful information. The original bug report was about the error message
not appearing, not so much about the fact that it failed (it's much easier to
figure out if something should fail when you know why it failed ;)

Thanks Marek for patching that!