Description of problem: I've completed two upgrades on two qemu-kvm guests. None of these performed an automatic regeneration of grub's conf file. Version-Release number of selected component (if applicable): dnf-plugin-system-upgrade-0.4.0-1.fc22.noarch python2-dnf-plugin-system-upgrade-0.4.0-1.fc22.noarch dnf-plugins-core-0.1.11-1.fc22.noarch dnf-1.1.1-2.fc22.noarch grubby-8.40.1.fc22.x86_64 How reproducible: Always Steps to Reproduce: 1. Upgrade a stable Fedora to Fedora 23 via dnf-plugin-system-upgrade 2. system-upgrade reboot 3. Wait until the completion of the process and the automatic reboot Actual results: 1. Grub's conf isn't regenerated and doesn't list the new F23 kernel. Expected results: 1. Grub's conf should be regenerated and should contain the new F23 kernel. Additional info: these are BIOS guest, UEFI isn't involved.
What kernel version(s) were installed during the upgrade? (This information should be in /var/log/dnf.log and/or the system journal) Did the upgrade complete successfully? (There should be a message that says "Upgrade complete! Cleaning up and rebooting..." if so) If a kernel package was installed successfully, this is probably a grubby bug. Either way, could you please attach your grub.cfg?
You are right: I checked dnf's log and the upgrade did not complete successfully. This virtual guest has got lots of duplicates, so the process didn't work perfectly. I've also tested another upgrade on another guest: it succeeded and grub now lists the new kernel. I'm sorry for the confusion I generated. But, before closing this ticket, I'd like to attach dnf's log (from the failing guest). There is what might be an unhandled exception, which probably made the upgrade fail. The cause for the failure might actually be one of the following I let you judge if dnf had a right behavior, perhaps I used the software improperly: 1) A temporary network problem. 2) An undersized disk. I've accidentally used a virtual hard disk which is only 10.00gb large, probably not sufficient for a system upgrade (er.. consider it as exploratory testing :) ).
Created attachment 1073827 [details] 'dnf.log' containing details about a failed upgrade
hrrrrm. It looks like 'dnf -v makecache timer' might have tried to run in the middle of your upgrade, but it's hard to tell without seeing the full system logs from the upgrade. Could you please use 'journalctl' to retrieve the log from the failed upgrade? You can use 'journalctl --list-boots' to list the boots. Once you find the correct one, just do: journalctl -b [UPGRADE-BOOT-ID] > upgrade.log and attach upgrade.log, if possible. (If you can't get the log, my guess is that PackageKit messed up and rebooted the system mid-upgrade.. as in bug 1252500.)
Created attachment 1074403 [details] output of 'journalctl -b -5' (failed upgrade boot)
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.