Bug 1262534

Summary: system upgrade didn't complete successfully
Product: [Fedora] Fedora Reporter: Giulio 'juliuxpigface' <juliux.pigface>
Component: dnf-plugin-system-upgradeAssignee: Will Woods <wwoods>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: juliux.pigface, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 17:51:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
'dnf.log' containing details about a failed upgrade
none
output of 'journalctl -b -5' (failed upgrade boot) none

Description Giulio 'juliuxpigface' 2015-09-12 11:27:26 UTC
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.

Comment 1 Will Woods 2015-09-14 16:43:22 UTC
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?

Comment 2 Giulio 'juliuxpigface' 2015-09-15 19:32:19 UTC
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 :) ).

Comment 3 Giulio 'juliuxpigface' 2015-09-15 19:33:31 UTC
Created attachment 1073827 [details]
'dnf.log' containing details about a failed upgrade

Comment 4 Will Woods 2015-09-15 20:51:44 UTC
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.)

Comment 5 Giulio 'juliuxpigface' 2015-09-17 11:22:21 UTC
Created attachment 1074403 [details]
output of 'journalctl -b -5' (failed upgrade boot)

Comment 6 Fedora End Of Life 2016-07-19 17:51:56 UTC
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.