Perhaps use builddir?

Confirmed same issue here.

'builddir' is ok for this. I will fail in second step - mounting loopback device. systemd-nspawn doesn't provide '/dev/loop*' by default. It needs

• allowed mknod in mock config config_opts['nspawn_args'] = ['--capability', 'CAP_MKNOD', '--property', 'DeviceAllow=/dev/loop0 rwm']...
• created those nodes (probably also with loop-control to safely found unused one)

I'm not happy about that as it involves not only koji changes, but probably additional package in buildroot which will create these nodes. Or do you think, that it should be done by koji?

new chroot is default in latest mock. We should probably take steps in koji if we want to continue to default of old chroot

400 brought per-tag settings. https://pagure.io/koji/pull-request/400#comment-27878

Do you think, that we want to set --old-chroot behaviour as default, or should we leave it on users?

See also https://bugzilla.redhat.com/show_bug.cgi?id=1471282

I recommend to use usual /mnt directory.

@tkopecek why do you need /dev/loopX ?

Ah, you are not bind-mounting that directory. You simply wrote to that directory prior running mock. Ok. then writing to /builddir is better. But even better is to bind mount that directory, you do not need loopback device then.
See my comment https://bugzilla.redhat.com/show_bug.cgi?id=1471282#c5

With --new-chroot you might also hit:

https://github.com/rpm-software-management/mock/issues/108

(For some reason I had to fix that before I hit this problem... may have to do with exact kojid settings.)

@msuchy /dev/loop is required by livemedia-creator for mounting image being created, it is not something what koji do.

mock PR providing loop devices: https://github.com/rpm-software-management/mock/pull/107

As solving loop devices within mock seems not to be near future, I would say, that PR #602 should be sufficient for now (I've not found any other problems, so only image builds are affected).

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/531

Please continue any further discussion there.