Description of problem: DNF upgrade from F29 to F30 has not worked since 2018-12-24. In a previous bug, I reported that, after system-upgrade reboot, grub would fail with no config, showing only the grub prompt. Then, system-upgrade download failed with conflicts for many weeks. Now, download seems to succeed, but after system-upgrade reboot, system boots, says "System upgrade starting. This will take a while...", and then reboots. Steps to Reproduce: 1. dnf system-upgrade download --releasever=30 --setopt=module_platform_id=platform:f30 2. dnf system-upgrade reboot Actual results: System upgrade crashes/reboots Additional info: See bug 1661955.
Hi, I cannot reproduce this on a fresh system with the latest system-upgrade from our copr repo (as was recommended in the previous bug: sudo dnf copr enable rpmsoftwaremanagement/dnf-nightly). So, can you please attach /var/log/dnf.log and the output of "sudo dnf system-upgrade log --number=-1"?
Created attachment 1544896 [details] DNF log
Created attachment 1544897 [details] dnf systemupgrade log --num=-1
I just tried this again, today, and got exactly the same behavior. I did not see the previous comment regarding copr for dnf-nightly. I'm only trying this so I can be prepared for upgrading to F30. If there is a reason why system-upgrade is not supposed to be working at this time, just say that; I can wait. I'm trying to avoid a future problem by being proactive. I'm trying to be helpful; but, if this is a known issue, that's fine. Unless you really want me to try dnf-nighly for you, then I can do that. But, I'll wait until F29 dnf is fixed, otherwise.
The issue should be fixed by python3-dnf-plugin-system-upgrade-0:4.0.4-1.fc29.noarch (available from updates-testing repository). Please if you can reproduce the bug with the version or later, please don't hesitate to reopen the bug report. *** This bug has been marked as a duplicate of bug 1656509 ***
Thanks! Sounds good.
Still having issues. I upgraded my test system to plugin version 4.0.4-1.fc29 and, again, after system-upgrade download and reboot, and after the system upgraded itself, I found the system at the grub prompt.
Well, maybe something is different this time. The upgrade seemed to start running. Before, the crash would occur almost immediately after system came up after the system-upgrade reboot command. System may have gone through more upgrading than that this time. But, result is the same. I will try dnf systemupgrade log again.
Wait, could be a space problem...
I extended the VM disk and started the upgrade again. It has made it through to the cleanup phase without problems. So, definitely not crashing at the very beginning anymore. If it is at the grub prompt when I get back, I'll let you know.
Dang it! got the grub prompt again. Sorry, I don't know what to do or how to troubleshoot this.
Can you please attach the logs again? /var/log/dnf.log and the output of "sudo dnf system-upgrade log --number=-1". Thanks. Oh, and just to be clear, the option --setopt='module_platform_id=platform:f30' is still required. So the steps are: 1. dnf upgrade --refresh 2. dnf system-upgrade download --releasever=30 --setopt='module_platform_id=platform:f30' 3. dnf system-upgrade reboot
I think so. I cannot boot the system, though. So, the only think I can do is restore the VM snapshot and run the log command *before* I run the system-upgrade reboot command. Is that what you mean? Is that good enough? Got it, I am still using the setopt option.
Ok, I didn't realize that. It would be good to know if the problem is in the system-upgrade plugin or in grub. Could you perhaps try the upgrade again, but using dnf directly: 1. dnf upgrade --releasever=30 --setopt='module_platform_id=platform:f30' 2. reboot Note: this is not a recommended way to upgrade the system, so please, do this only in the VM (and using console, not any gui). If the problem is there as well, I'll reassign this bug to grub.
Okay, I'll try...
I followed your procedure and still ended up at the grub prompt.
Thank you for trying that. I am reassigning this to grub as the issue is probably there.
*** This bug has been marked as a duplicate of bug 1652806 ***