Hide Forgot
Description of problem: 'dnf system-upgrade reboot' gets stuck in an infinite reboot loop when selinux is enforcing. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: On Fedora 24: dnf system-upgrade download --releasever 25 dnf system-upgrade.reboot Actual results: The upgrade never starts. Infinite reboot loop. Expected results: Upgrade to Fedora 25 Additional info: After booting to an emergency shell, examination of journalctl -b -1 uncovered the following relevant bits: Nov 25 09:51:55 thinkpenguin.email-scan.com systemd[1]: Starting Bluetooth service... Nov 25 09:51:55 thinkpenguin.email-scan.com bluetoothd[803]: Bluetooth daemon 5.43 Nov 25 09:51:55 thinkpenguin.email-scan.com audit[1]: AVC avc: denied { open } for pid=1 comm="systemd" path="/var/lib/dnf/system-upgrade/.dnf-system-upgrade" dev="dm-1" ino=1181602 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0 Nov 25 09:51:55 thinkpenguin.email-scan.com systemd[1]: dnf-system-upgrade.service: Failed to load environment files: Permission denied Nov 25 09:51:55 thinkpenguin.email-scan.com systemd[1]: dnf-system-upgrade.service: Failed to run 'start' task: Permission denied Nov 25 09:51:55 thinkpenguin.email-scan.com systemd[1]: Failed to start System Upgrade. Nov 25 09:51:55 thinkpenguin.email-scan.com systemd[1]: dnf-system-upgrade.service: Unit entered failed state. Nov 25 09:51:55 thinkpenguin.email-scan.com systemd[1]: dnf-system-upgrade.service: Failed with result 'resources'. Nov 25 09:51:55 thinkpenguin.email-scan.com systemd[1]: Rebooting as result of failure. This triggered a reboot, which simply failed the same way, etc... Setting SELINUX=permissive in /etc/selinux/config, and rebooting, allowed the upgrade to 25 to succeed.
After additional investigation: # ls -alZd /var/lib/dnf/system-upgrade drwxr-xr-x. 2 root root unconfined_u:object_r:user_tmp_t:s0 233472 Nov 25 ↩ 10:31 /var/lib/dnf/system-upgrade After rmdir-ing and mkdir-ing the now-empty directory, its context is now: drwxr-xr-x. 6 root root unconfined_u:object_r:rpm_var_lib_t:s0 4096 Nov 25 10:47 /var/lib/dnf which seems to be what it should be. It appears that the original selinux context was wrong. It's unclear why the context was wrong, but 'system-upgrade reboot' didn't complain, and just forged ahead. I'm thinking that 'system-upgrade reboot' should sanity-check the selinux context of all files, or at least the selinux context of the directory, before pulling the trigger.
*** Bug 1403601 has been marked as a duplicate of this bug. ***
> I'm thinking that 'system-upgrade reboot' should sanity-check the selinux context of all files, or at least the selinux context of the directory, before pulling the trigger. Nah, system-upgrade is rather simple. SELinux is just too complicated, I don't think we can check if things will work without running the reboot. In https://github.com/systemd/systemd/commit/953bf4604f I added an additional unit which should guard against reboot loops. So in principle you should just get a double reboot and boot back into the old system, where you can look at logs and maybe adjust selinux permissions or whatever and restart the upgrade.
*** This bug has been marked as a duplicate of bug 1349721 ***