This can be due to libdnf, libdnf-0.47.0-1.fc33 was built on Apr 1.
Also anaconda-33.6-1.fc33 was built close to this date.

The screenshot shows that rpm-ostree does variable substitution for basearch.
I'm not saying this is the root cause, but why there's a '$basearch' directory in the compose?
https://kojipkgs.fedoraproject.org/compose/iot/Fedora-IoT-33-20200401.0/work/$basearch/

I know I'm asking for a lot, because the compose process is not simple and cannot be simply run anywhere, but is there any chance to narrow down the problem and provide a reproducer we could run by ourselves?

Hmm, I doubt rpm-ostree and libdnf can be linked into the same process (since rpm-ostree embeds a different libdnf).

Likely the simplest thing is to move the basearch substition anaconda is doing via rpm-ostree out-of-process, because all of the rest of the rpm-ostree usage is out-of-process.

BTW, to avoid confusion - the 20200407.0 compose failed due to a qemu dep issue on brlapi. This is a wider issue that failed all Rawhide composes that day, and is being resolved elsewhere. But the composes between 0401.0 and 0406.0 failed on this crash, which does seem IoT-specific. Notably we did get Silverblue installer images in the main Rawhide composes during that period, so this doesn't seem to be 'just' an ostree or ostree installer image bug, it really has some IoT-specific element. The $basearch thing does seem a likely candidate, @mohanboddu any idea why we're getting that?

So the last two days have worked since the mainline rawhide started moving, @adamwill happy to close this out?

Sure. Do we know what got fixed?