Description of problem: dnf system-upgrade does not upgrade system from f25 to f26 Version-Release number of selected component (if applicable): dnf-plugin-system-upgrade-0.7.1-4.fc25.noarch How reproducible: every time Steps to Reproduce: 1. dnf --refresh makecache 2. dnf distro-sync 3. dnf --best --allowerasing system-upgrade download --releasever=26 4. dnf system-upgrade reboot Actual results: all packages downloaded, transaction check succeeded, transaction test succeeded, but modifications to start upgrade not made, reboots to f25, upgrade does not start Expected results: upgrade from f25 to f26 Additional info:
Please paste the the logs from the failed boot (the one that should have performed the upgrade, but didn't). You can look at the list of boots with 'journalctl --list-boots' and if e.g. -3 is the interesting one, capture the logs to a file with 'journactl -b-3 >file'.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > Please paste the the logs from the failed boot (the one that should have > performed the upgrade, but didn't). You can look at the list of boots with > 'journalctl --list-boots' and if e.g. -3 is the interesting one, capture the > logs to a file with 'journactl -b-3 >file'. Well, this is strange, the output of 'journalctl --list-boots' is: Failed to determine boots: No data available Although, there is output from 'journactl -b-x', but it only shows a normal unmodified boot sequence(s). Isn't dnf system-upgrade supposed to modify grub or something in /boot to trigger the upgrade upon reboot? I don't know, I'm certainly not an expert on dnf, but, I think it used to. It doesn't look like *anything* in the /boot directory has been created, updated or deleted by dnf system-upgrade. Nothing has changed in /boot since I updated/installed kernel*-4.11.9-200.fc25.x86_64 about five days ago.
I doesn't. You're thinking about the previous fedup mechanism which booted into a separate initramfs to do the upgrade. Please try to access --list-boots as root.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > I doesn't. You're thinking about the previous fedup mechanism which booted > into a separate initramfs to do the upgrade. > > Please try to access --list-boots as root. I did access 'journalctl --list-boots' as root. Any other ideas? I guess I could re-run dnf system-upgrade, and get the log from 'journalctl -b-0' and hope for the best, although there is a lot of privacy and/or security related information contained in the log that is not pertinent to this issue and that I really don't want to upload to a public forum like bugzilla. Is there a subset that would be helpful? If I knew what dnf system-upgrade was supposed to be accomplishing, maybe I could be more helpful.
I didn't know what else to do, so I did this: 1. I booted into single user mode and ran 'systemctl start dnf-system-upgrade.service'. It appeared to complete successfully. 2. touch /.autorebel 3. systemctl reboot 4. dnf repoquery --unsatisfied (no errors) 5. dnf --refresh makecache 6. dnf distro-sync 7. dnf list --extras 8. cleaned up any extras I still don't know why 'dnf system-upgrade download' followed by 'dnf system-upgrade reboot' failed to work as advertised, but after my convoluted attempt, I *appear* to be running f26. This system is using the 'Fedora Custom Operating System' environment group and is a hybrid Workstation/Server system (I still don't agree with the decision to split the installation, but my opinion counts for nothing) that is running some unsupported software - notably VMware (although f26 breaks VMware again, still looking for a workaround that actually works) and the proprietary nVidia driver, and has had both the hardware, firmware, and software upgraded *many* times, so there *may* be (OK, there probably is) some cruft leftover from previous incarnations of Fedora that *may* be (again, probably is) causing problems.
I see the same problem. fedup upgrade hangs after reboot with reached target System Upgrade I have to append rd.break to grub boot entry and remove the sym link to /system-update in /sysroot.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Hi, please upgrade to latest dnf-plugins-extras, which (from Fedora 26 onwards) provides system-upgrade plugin. This issue should be already fixed. In case of any problems, don't hesitate to reopen the bug.