Created attachment 1864419 [details]
output of 'journalctl -a | grep systemd-userdbd'
Description of problem:
On the first boot of Fedora-IoT-36-20220306.0 (any arch), systemd-userdbd.service fails to start. On subsequent boots, the service starts and runs OK.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Fedora-IoT-36-20220306.0 any arch
2. 'systemctl --all --failed'
3. View failed systemd-userdbd.service
See attached logs.
Created attachment 1864420 [details]
output of 'journalctl -a'
Proposed as a Blocker for 36-final by Fedora user coremodule using the blocker tracking app because:
Proposing as a possible violation of the following F36 Final criterion:
"All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present." 
Discussed during the 2022-03-07 blocker review meeting: 
The decision to classify this bug as a "RejectedBlocker (Final)" and an "AcceptedFreezeException (Beta)" was made as this seems to have no practical consequences and works on every boot after the first, so we decided it's not a sufficient violation of the criterion to block the release on. However it is confounding to see on first boot, so we grant an FE to fix that for Beta if possible.
Mar 07 11:18:32 fedora audit: BPF prog-id=61 op=LOAD
Mar 07 11:18:32 fedora systemd: Starting systemd-userdbd.service - User Database Manager...
Mar 07 11:18:32 fedora systemd: systemd-userdbd.service: Failed to set up mount namespacing: /run/systemd/unit-root/dev: Read-only file system
Mar 07 11:18:32 fedora systemd: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system
Mar 07 11:18:32 fedora systemd: systemd-userdbd.service: Main process exited, code=exited, status=226/NAMESPACE
Mar 07 11:18:32 fedora systemd: systemd-userdbd.service: Failed with result 'exit-code'.
Mar 07 11:18:32 fedora systemd: Failed to start systemd-userdbd.service - User Database Manager.
Looks similar to #1663040.
If you boot with selinux in permissive mode, does it work?
Zbigniew, just tested on Fedora-IoT-IoT-ostree-x86_64-36-20220318.0.iso. If I boot with SELinux in 'permissive' mode, the problem goes away. Running 'systemctl --all --failed' shows nothing when in 'permissive' mode.
It sounds like this is some variant of rhbz#1663040. It would make sense to check the selinux labels
on the image, see the extensive discussion there.
Somebody needs to do an analysis like in https://bugzilla.redhat.com/show_bug.cgi?id=1663040#c24