Description of problem: SSIA. Version-Release number of selected component (if applicable): dnf-plugin-system-upgrade-0.7.1-3.fc24.noarch How reproducible: Twice. Steps to Reproduce: dnf system-upgrade download --releasever=25 --allowerasing dnf system-upgrade reboot Actual results: 5.1G /system-update/ But the system boots as F-24 with no trace of an upgrade attempt. # dnf system-upgrade log The following boots appear to contain upgrade logs: -- no logs were found -- Even tried this with no change: # systemctl enable dnf-system-upgrade.service Created symlink from /etc/systemd/system/system-update.target.wants/dnf-system-upgrade.service to /usr/lib/systemd/system/dnf-system-upgrade.service. Expected results: F-25 running. Additional info: Going to use the old way of: dnf --releasever=25 distro-sync I also have no idea how 'dnf system-upgrade' should be different.
> # systemctl enable dnf-system-upgrade.service > Created symlink from /etc/systemd/system/system-update.target.wants/dnf-system-upgrade.service to /usr/lib/systemd/system/dnf-system-upgrade.service. That's actually a noop, dnf-plugin-system-upgrade already contains /usr/lib/systemd/system/system-update.target.wants/dnf-system-upgrade.service. > Actual results: > 5.1G /system-update/ > But the system boots as F-24 with no trace of an upgrade attempt. That's strange. Can you attach logs from the boot that should have cause the upgrade but didn't (journalctl -b X) where X is -1 or -2 or less.
Created attachment 1232560 [details] boot log.xz
I don't see anything interesting in the logs. If you still have the symlink, does this work: mkdir /tmp/x && SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/system-generators/systemd-system-update-generator /tmp/{x,x,x} && ls -l /tmp/x ? (It should say "... default.target -> /usr/lib/systemd/system/system-update.target")
total 0 lrwxrwxrwx 1 root root 44 Dec 16 16:32 default.target -> /usr/lib/systemd/system/system-update.target OK, it is because I always boot the system with parameter "3", otherwise it locks up trying to repeatedly unsuccessfully run X: # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.8.13-200.fc24.x86_64 root=LABEL=host2root ro rd.luks.options=discard rd.luks.uuid=luks-5b30fc63-6b52-4746-b883-394fbe23c3dd LANG=en_US.UTF-8 3 I think 'dnf system-upgrade reboot' should check /proc/cmdline and warn if there has been changed the default target to run.
I'm not even sure if this behaviour is a bug. The general rule is that the commandline has higher priority than /etc, which has higher priority than /usr/lib. But in this case this means that paradoxically, the override is overridden. This might be unexpected, but it seems to be right thing. So you're right, basically we should add a warning message. system-update-generator should do that.
BTW, thanks for debugging this. I didn't think about this case at all.
https://github.com/systemd/systemd/pull/5173
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.