Description of problem: After dist-upgrading to Fedora 30 and issueing a fixfiles onboot on Raspberry Pi 3, the installation will no longer have functional networking among other issues due to issues with /dev not being labelled. NetworkManager, DBus and other services will refuse to work with SELinux enabled. This will effectively take the device offline after dist-upgrade and filesystem relabelling. Auditing this issue brings the following result: type=AVC msg=audit(1555082275.639:82): avc: denied { mounton } for pid=696 comm="(r-launch)" path="/run/systemd/unit-root/dev" dev="mmcblk0p4" ino=7634 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1 It seems that the installer labels the filesystem devtmpfs in mounted on /dev and so the /dev mountpoint gets no label. Fixed by: mount --bind / /mnt && chcon system_u:object_r:device_t:s0 /mnt/dev umount
So a number of things here: 1) a dist upgrade is completely unrelated to arm-image-installer. 2) which process did you use to "dist-upgrade"? 3) You'd be better off doing a complete relabel if you see issues with SELinux by doing the following: "touch /.autorelabel; reboot"
Pity that this one is closed as NOTABUG. I believe it is one - seems that dist upgrading from some previous versions of fedora results in some mountpoints being mislabeled, which is now set as issue in Fedora 30. It seems to affect the mountpoints, which are normally mounted during boot, so things like "touch /.autorelabel; reboot" or "fixfiles onboot" wont help. See other related bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1706451 https://bugzilla.redhat.com/show_bug.cgi?id=1708991 https://bugzilla.redhat.com/show_bug.cgi?id=1663040
(In reply to Michal Ambroz from comment #2) > Pity that this one is closed as NOTABUG. I believe it is one - seems that It's unrelated to arm-image-installer, and hence isn't a bug in the component you've filed it under. > See other related bugs: > https://bugzilla.redhat.com/show_bug.cgi?id=1706451 This is a bug against selinux-policy-targeted (probably the right component for you to file a bug) > https://bugzilla.redhat.com/show_bug.cgi?id=1708991 This is against snapd which is a containerisation technology. Not sure how that relates to /dev/ issues on upgrade > https://bugzilla.redhat.com/show_bug.cgi?id=1663040 And lorax is a component used as part of the compose process making in the installer. The bug should probably be filed against the dist-upgrade component, or possibly selinux-policy-targeted, and it should be nothing to do specifically with the Raspberry Pi as we handle all HW the same in that regard.