Additionally, I see the following output in the `dmesg` output after a fresh boot. I have no idea if it's related, but I guess it could be, given that the modinfo command comes from the kmod package, and the previous rawhide issue was fixed with an update to the selinux-policy package:

Unable to fix SELinux security context of /run/tmpfiles.d/kmod.conf: Invalid argument

Also, I tried upgrading to the newer selinux-policy package that's in updates-testing to see if that would help, but hit this:

https://bodhi.fedoraproject.org/updates/FEDORA-2019-3f20be4d52#comment-955601

(In reply to Gerard Ryan from comment #2)
> Also, I tried upgrading to the newer selinux-policy package that's in
> updates-testing to see if that would help, but hit this:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-3f20be4d52#comment-955601

Can you do "setenforce 0" then restart firewalld to verify it's selinux blocking. Don't forget to reenable when done. :)

(In reply to Eric Garver from comment #3)
> (In reply to Gerard Ryan from comment #2)
> > Also, I tried upgrading to the newer selinux-policy package that's in
> > updates-testing to see if that would help, but hit this:
> > 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-3f20be4d52#comment-955601
> 
> Can you do "setenforce 0" then restart firewalld to verify it's selinux
> blocking. Don't forget to reenable when done. :)

Thanks for the tip, it does indeed seem to be selinux blocking it. When I "setenforce 0" and restart firewalld it works fine. If I then "setenforce 1" again and try to restart firewalld, I get the original error here.

Given that, I've changed the component here to be selinux-policy.

Does the error message I pasted above look relevant ("Unable to fix SELinux security context of /run/tmpfiles.d/kmod.conf: Invalid argument")? Would deleting that file and rebooting be a good idea or bad idea (asking in case it could break my ability to boot or something)?

(In reply to Gerard Ryan from comment #4)
[..] 
> Does the error message I pasted above look relevant ("Unable to fix SELinux
> security context of /run/tmpfiles.d/kmod.conf: Invalid argument")? Would
> deleting that file and rebooting be a good idea or bad idea (asking in case
> it could break my ability to boot or something)?

I don't know. Maybe someone from selinux can answer.

(In reply to Eric Garver from comment #5)
> (In reply to Gerard Ryan from comment #4)
> [..] 
> > Does the error message I pasted above look relevant ("Unable to fix SELinux
> > security context of /run/tmpfiles.d/kmod.conf: Invalid argument")? Would
> > deleting that file and rebooting be a good idea or bad idea (asking in case
> > it could break my ability to boot or something)?
> 
> I don't know. Maybe someone from selinux can answer.

Out of desperation I tried deleting the file to see if it would help anything. Unfortunately this had no effect, as it seems to just get created on each boot if it's not there.

HI All, 

Could anybody try the broken scenario and then attach output of: 

# ausearch -m AVC -m USER_AVC -m SELINUX_ERR -ts recent 

THanks,
Lukas.

(In reply to Lukas Vrabec from comment #7)
> HI All, 
> 
> Could anybody try the broken scenario and then attach output of: 
> 
> # ausearch -m AVC -m USER_AVC -m SELINUX_ERR -ts recent 
> 
> THanks,
> Lukas.

Hi Lukas, here it is from my system:

$ sudo ausearch -m AVC -m USER_AVC -m SELINUX_ERR -ts recent
----
time->Wed Jun 12 22:18:28 2019
type=AVC msg=audit(1560374308.332:350): avc:  denied  { unlink } for  pid=11453 comm="systemd-user-ru" name=".containerenv" dev="tmpfs" ino=154249 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:container_file_t:s0:c16,c632 tclass=file permissive=0
----
time->Wed Jun 12 22:18:28 2019
type=AVC msg=audit(1560374308.332:351): avc:  denied  { unlink } for  pid=11453 comm="systemd-user-ru" name="hostname" dev="tmpfs" ino=154248 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:container_file_t:s0:c16,c632 tclass=file permissive=0
----
time->Wed Jun 12 22:18:28 2019
type=AVC msg=audit(1560374308.332:352): avc:  denied  { unlink } for  pid=11453 comm="systemd-user-ru" name="hosts" dev="tmpfs" ino=154247 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:container_file_t:s0 tclass=file permissive=0
----
time->Wed Jun 12 22:18:28 2019
type=AVC msg=audit(1560374308.332:353): avc:  denied  { unlink } for  pid=11453 comm="systemd-user-ru" name="resolv.conf" dev="tmpfs" ino=154242 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:container_file_t:s0 tclass=file permissive=0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.146:135): avc:  denied  { execute } for  pid=1100 comm="iptables" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.151:136): avc:  denied  { execute } for  pid=1103 comm="ip6tables" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.164:137): avc:  denied  { execute } for  pid=1107 comm="ebtables" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.186:138): avc:  denied  { execute } for  pid=1114 comm="iptables" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.189:139): avc:  denied  { execute } for  pid=1118 comm="ip6tables" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.190:140): avc:  denied  { getattr } for  pid=1021 comm="firewalld" path="/usr/bin/kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.341:149): avc:  denied  { execute } for  pid=1156 comm="firewalld" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.565:153): avc:  denied  { execute } for  pid=1166 comm="iptables" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:iptables_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.571:154): avc:  denied  { execute } for  pid=1168 comm="ip6tables" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:iptables_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.598:155): avc:  denied  { execute } for  pid=1173 comm="iptables" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:iptables_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:10 2019
type=AVC msg=audit(1560374350.606:156): avc:  denied  { execute } for  pid=1175 comm="ip6tables" name="kmod" dev="dm-1" ino=2498764 scontext=system_u:system_r:iptables_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:kmod_exec_t:s0
----
time->Wed Jun 12 22:19:24 2019
type=AVC msg=audit(1560374364.350:195): avc:  denied  { read } for  pid=1372 comm="geoclue" name="modules" dev="dm-1" ino=664098 scontext=system_u:system_r:geoclue_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0 trawcon=system_u:object_r:pkcs11_modules_conf_t:s0
----
time->Wed Jun 12 22:19:30 2019
type=AVC msg=audit(1560374370.168:200): avc:  denied  { execute } for  pid=2669 comm="(m-helper)" name="flatpak-system-helper" dev="dm-1" ino=2494466 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon=system_u:object_r:flatpak_helper_exec_t:s0


Thanks,
Gerard.

Hi, 

Could you please run following command: 

# restorecon -Rv /

It should if labels on your system. Feel free to re-open this ticket if the issue occurs again. 

Thanks,
Lukas.

Hi Lukas,

I ran that command, and it relabeled a bunch of stuff, but unfortunately that has had a very bad effect: I now can't boot my system.

I should have known something was not right after the command completed: The power-off button disappeared from the settings menu in the dropdown from the top right of GNOME Shell, and `systemctl reboot` was also failing with some error message. Eventually I just ran `sudo reboot -f`.

Could this unintended behaviour be because I'm using Silverblue instead of Workstation? Was that `restorcon` command maybe a bad idea on Silverblue? I actually thought that problems like this were solved by Silverblue, since it would allow me to boot into the previous working ostree, but that also doesn't boot now.

In case it's of any use, the boot message that it seems to be getting stuck on (in both my latest and previous ostree options), is:

"Starting Manage, Install and Generate Color Profiles...ice...kbd_backlight...6853...."

Any ideas?

I'll try to get attention of some Silverblue folks on this, otherwise I'll likely have to reinstall tomorrow since this is my work machine and I'll need it for Monday.

Thanks,
Gerard.

Thanks to the suggestion by refi64, I can successfully boot by adding `enforcing=0` to the kernel boot command:

https://discussion.fedoraproject.org/t/i-cant-boot-into-either-my-latest-or-previous-ostree-after-running-restorecon/1906

As mentioned there, I'm also able to `sudo setenforce 1` after booting and everything works so far for that session. Unfortunately the underlying issue is still there, since if I reboot I hit the same issue again if I don't continue to add `enforcing=0`.

Now that I don't need to reinstall in a hurry, any suggestions on how to proceed from here?

Thanks,
Gerard.

Here are some "avc: denied" messages that I found in the boot logs with `journalctl -b | grep "avc" -B3`, in case it's useful:

Jun 16 13:15:10 silverblue-t580 crond[1105]: (CRON) INFO (running with inotify support)
Jun 16 13:15:10 silverblue-t580 systemd[1119]: pam_unix(systemd-user:session): session opened for user gryan by (uid=0)
Jun 16 13:15:10 silverblue-t580 audit[1119]: USER_START pid=1119 uid=0 auid=1000 ses=1 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:session_open grantors=pam_selinux,pam_selinux,pam_loginuid,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="gryan" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 16 13:15:10 silverblue-t580 audit[1119]: AVC avc:  denied  { transition } for  pid=1119 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="dm-1" ino=2511540 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=1
Jun 16 13:15:10 silverblue-t580 audit[1119]: AVC avc:  denied  { entrypoint } for  pid=1119 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="dm-1" ino=2511540 scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=1
--
Jun 16 13:15:13 silverblue-t580 audit[1466]: USER_ROLE_CHANGE pid=1466 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0 selected-context=unconfined_u:unconfined_r:unconfined_t:s0 exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 16 13:15:13 silverblue-t580 audit[1466]: USER_START pid=1466 uid=0 auid=42 ses=2 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:session_open grantors=pam_selinux,pam_selinux,pam_loginuid,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="gdm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 16 13:15:13 silverblue-t580 systemd[1466]: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Jun 16 13:15:13 silverblue-t580 audit[1466]: AVC avc:  denied  { transition } for  pid=1466 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="dm-1" ino=2511540 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=1
Jun 16 13:15:13 silverblue-t580 audit[1466]: AVC avc:  denied  { entrypoint } for  pid=1466 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="dm-1" ino=2511540 scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=1
--
Jun 16 13:15:20 silverblue-t580 systemd-logind[1044]: New session 3 of user gryan.
Jun 16 13:15:20 silverblue-t580 systemd[1]: Started Session 3 of user gryan.
Jun 16 13:15:20 silverblue-t580 gdm-password][1834]: pam_unix(gdm-password:session): session opened for user gryan by (uid=0)
Jun 16 13:15:20 silverblue-t580 audit[1854]: AVC avc:  denied  { transition } for  pid=1854 comm="gdm-session-wor" path="/usr/bin/gnome-keyring-daemon" dev="dm-1" ino=2647907 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=1
Jun 16 13:15:20 silverblue-t580 audit[1854]: AVC avc:  denied  { entrypoint } for  pid=1854 comm="gdm-session-wor" path="/usr/bin/gnome-keyring-daemon" dev="dm-1" ino=2647907 scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=1

FEDORA-2019-9da5c35472 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9da5c35472

selinux-policy-3.14.3-39.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-9da5c35472

selinux-policy-3.14.3-39.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Hi Lukas,

Unfortunately that package update doesn't fix this issue on Fedora Silverblue. Sorry I wasn't able to mention that before it went out and caused the issue to be closed. I was having issues because of the restorecon command (it seems to currently be a bad idea to run that on Silverblue: https://discussion.fedoraproject.org/t/i-cant-boot-into-either-my-latest-or-previous-ostree-after-running-restorecon/1906/5?u=grdryn).

I've got the new version of selinux-policy:

$ rpm -q selinux-policy
selinux-policy-3.14.3-39.fc30.noarch

I've manually loaded the nf_conntrack mod:

$ lsmod | egrep -v  "\s0" | grep nf_conntrack
nf_conntrack_netbios_ns    16384  1
nf_conntrack_broadcast    16384  1 nf_conntrack_netbios_ns
nf_conntrack          147456  5 xt_conntrack,nf_nat,nf_conntrack_netbios_ns,nf_conntrack_broadcast,xt_CT
nf_defrag_ipv6         24576  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
libcrc32c              16384  2 nf_conntrack,nf_nat

With selinux enforcing, I get the same issue as before:

$ sudo setenforce 1
$ sudo systemctl reload-or-restart firewalld
$ systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2019-06-20 19:36:38 IST; 5s ago
     Docs: man:firewalld(1)
  Process: 8184 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=exited, status=1/FAILURE)
  Process: 8464 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 8184 (code=exited, status=1/FAILURE)

Jun 20 19:28:24 silverblue-t580 systemd[1]: Starting firewalld - dynamic firewall daemon...
Jun 20 19:28:24 silverblue-t580 systemd[1]: Started firewalld - dynamic firewall daemon.
Jun 20 19:36:38 silverblue-t580 systemd[1]: Reloading firewalld - dynamic firewall daemon.
Jun 20 19:36:38 silverblue-t580 systemd[1]: Reloaded firewalld - dynamic firewall daemon.
Jun 20 19:36:38 silverblue-t580 firewalld[8184]: WARNING: modinfo command is missing, not able to detect conntrack helpers.
Jun 20 19:36:38 silverblue-t580 firewalld[8184]: ERROR: Failed to load nf_conntrack module:
Jun 20 19:36:38 silverblue-t580 systemd[1]: firewalld.service: Main process exited, code=exited, status=1/FAILURE
Jun 20 19:36:38 silverblue-t580 systemd[1]: firewalld.service: Failed with result 'exit-code'.

With selinux not enforcing, it starts fine:

$ sudo setenforce 0
$ sudo systemctl reload-or-restart firewalld
$ systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-06-20 19:38:10 IST; 2s ago
     Docs: man:firewalld(1)
 Main PID: 8577 (firewalld)
    Tasks: 2 (limit: 4915)
   Memory: 23.7M
   CGroup: /system.slice/firewalld.service
           └─8577 /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid

Jun 20 19:38:09 silverblue-t580 systemd[1]: Starting firewalld - dynamic firewall daemon...
Jun 20 19:38:10 silverblue-t580 systemd[1]: Started firewalld - dynamic firewall daemon.

Hi, 

I pushed some changes to the selinux-policy sources:

commit f3ce58c3685d95ceb969b841d74af08217adf29e
Author: Lukas Vrabec <lvrabec>
Date:   Mon Jul 22 19:27:58 2019 +0200

    Allow systemd to load kernel modules during boot process.
    
    The netfilter kernel modules can't be autoloaded and must be loaded
    explicitly. Since nspawn and systemd-networkd make use of iptables via
    libiptc we load the module from systemd during the boot. This is a
    commit which introduced the change:
    https://github.com/systemd/systemd/commit/1d3087978a8ee23107cb64aa55ca97aefe9531e2

Fix should be included in the next selinux-policy build. 

Thanks,
Lukas.

*** Bug 1700739 has been marked as a duplicate of this bug. ***

Hi Lukas,

Sorry it took me so long to get back to this -- the workaround of just doing things manually after every boot has been sufficient for me up to now.

I've currently got selinux-policy-3.14.3-43.fc30.noarch, which if I'm reading the build changelog correctly, should contain the fix. I still experience this though, and the other issue around libvirtd failing because of the missing "tun" module.

I'm not sure if any of it is useful for you, but in the "journalctl -b" output, I see the following:

Sep 04 19:33:21 localhost systemd[1]: Switching root.
Sep 04 19:33:21 localhost systemd-journald[307]: Journal stopped
Sep 04 19:33:22 silverblue-t580 systemd-journald[307]: Received SIGTERM from PID 1 (systemd).
Sep 04 19:33:22 silverblue-t580 kernel: printk: systemd: 28 output lines suppressed due to ratelimiting
Sep 04 19:33:22 silverblue-t580 kernel: SELinux:  policy capability network_peer_controls=1
Sep 04 19:33:22 silverblue-t580 kernel: SELinux:  policy capability open_perms=1
Sep 04 19:33:22 silverblue-t580 kernel: SELinux:  policy capability extended_socket_class=1
Sep 04 19:33:22 silverblue-t580 kernel: SELinux:  policy capability always_check_network=0
Sep 04 19:33:22 silverblue-t580 kernel: SELinux:  policy capability cgroup_seclabel=1
Sep 04 19:33:22 silverblue-t580 kernel: SELinux:  policy capability nnp_nosuid_transition=1
Sep 04 19:33:22 silverblue-t580 systemd[1]: Successfully loaded SELinux policy in 423.861ms.
Sep 04 19:33:22 silverblue-t580 systemd[1]: Unable to fix SELinux security context of /run/tmpfiles.d/kmod.conf: Invalid argument
Sep 04 19:33:22 silverblue-t580 systemd[1]: Relabelled /dev, /dev/shm, /run, /sys/fs/cgroup in 20.181ms.
Sep 04 19:33:22 silverblue-t580 systemd[1]: systemd v241-10.git511646b.fc30 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)

then some sections like the following, where it says that it failed to load kernel modules:

Sep 04 19:33:23 silverblue-t580 systemd-modules-load[910]: Failed to lookup module alias 'fuse': Function not implemented
Sep 04 19:33:23 silverblue-t580 audit[910]: AVC avc:  denied  { read } for  pid=910 comm="systemd-modules" name="modules.softdep" dev="dm-1" ino=2405526 scontext=system_u:system_r:systemd_modules_load_t:s0 tcontext=system_u:object_r:modules_dep_t:s0 tclass=file permissive=0
Sep 04 19:33:23 silverblue-t580 audit[910]: AVC avc:  denied  { read } for  pid=910 comm="systemd-modules" name="modules.dep.bin" dev="dm-1" ino=2510507 scontext=system_u:system_r:systemd_modules_load_t:s0 tcontext=system_u:object_r:modules_dep_t:s0 tclass=file permissive=0
Sep 04 19:33:23 silverblue-t580 audit[910]: AVC avc:  denied  { read } for  pid=910 comm="systemd-modules" name="modules.dep.bin" dev="dm-1" ino=2510507 scontext=system_u:system_r:systemd_modules_load_t:s0 tcontext=system_u:object_r:modules_dep_t:s0 tclass=file permissive=0
Sep 04 19:33:23 silverblue-t580 audit[910]: AVC avc:  denied  { read } for  pid=910 comm="systemd-modules" name="modules.alias.bin" dev="dm-1" ino=2393984 scontext=system_u:system_r:systemd_modules_load_t:s0 tcontext=system_u:object_r:modules_dep_t:s0 tclass=file permissive=0
Sep 04 19:33:23 silverblue-t580 systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
Sep 04 19:33:23 silverblue-t580 systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
Sep 04 19:33:23 silverblue-t580 systemd[1]: Failed to start Load Kernel Modules.

then later:

Sep 04 19:33:26 silverblue-t580 audit[1137]: AVC avc:  denied  { execute } for  pid=1137 comm="firewalld" name="kmod" dev="dm-1" ino=2359947 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon="system_u:object_r:kmod_exec_t:s0"
Sep 04 19:33:26 silverblue-t580 firewalld[1003]: ERROR: Failed to load nf_conntrack module:
Sep 04 19:33:26 silverblue-t580 firewalld[1003]: ERROR: Raising SystemExit in run_server

Hi Gerrard, 

I tried the latest version of selinux-policy for Fedora 30. 

# rpm -q selinux-policy                                        
selinux-policy-3.14.3-45.fc30.noarch

# audit2allow -i avc    


#============= systemd_modules_load_t ==============

#!!!! This avc is allowed in the current policy
allow systemd_modules_load_t modules_dep_t:file read;


Related to your latest SELinux denial: 


Sep 04 19:33:26 silverblue-t580 audit[1137]: AVC avc:  denied  { execute } for  pid=1137 comm="firewalld" name="kmod" dev="dm-1" ino=2359947 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon="system_u:object_r:kmod_exec_t:s0"

This looks like mislabeled system. 

Please run:
# restorecon -Rv / 

To fix labels on your system. 

Thanks,
Lukas

Hi Lukas,

Thanks for the reply. I apparently can't run `restorecone -Rv /` since I'm on a Silverblue system (see earlier comments in this bug for where that didn't go well).

Given that nobody else seems to see these problems that I do, I presume this is something specific to my system, is it?

I can try doing a clean install, but it'll be a while before I've got time to do that, since this is my work machine.

Thanks,
Gerard.

FEDORA-2019-d68c9e27f8 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d68c9e27f8

selinux-policy-3.14.3-50.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d68c9e27f8

FEDORA-2019-f83217e2bf has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f83217e2bf

selinux-policy-3.14.3-51.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f83217e2bf

I've moved on to F31 now, so I don't have the ability to check if the new update fixes this on F30. The good news is that on a fresh F31 Silverblue install with selinux-policy-3.14.4-37.fc31.noarch I don't see the issue.

Thanks!
Gerard.

FEDORA-2019-70d80ad4bc has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-70d80ad4bc

selinux-policy-3.14.3-52.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-70d80ad4bc

selinux-policy-3.14.3-52.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.