Red Hat Bugzilla – Bug 1264948
On reboot after dnf-system-upgrade - the process or upgrading kicks in on selecting the previous F22 kernel aswell
Last modified: 2015-10-21 08:18:45 EDT
Description of problem:
Previously with fedup - on reboot after running fedup - one can choose the following on the grub menu - with the corresponding actions:
- 'System Upgrade' [or equivalent option]. Here fedup continues with system upgrade
- 'Older kernel option'. Here fedup is not in the loop - so the machine boots to the currently installed linux - ignoring the upgrade process.
However - with dnf-plugin-system-upgrade - even if the 'Older kernel option' is selected - it chuggs along with the upgrade process.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. fedup --network 23
2. dnf system-upgrade reboot
3. on reboot select 'System Upgrade (fedup)'
4. Error! https://bugzilla.redhat.com/show_bug.cgi?id=1264942
5. Reboot - and select ''Fedora (4.1.7-200.fc22.x86_64) 22 (Twenty Two)'
Get the message:
'Started system upgrade. This will take a while'
And then upgrade to F23 beta completes successfully]
Boot to F22 without starting the upgrade process.
1. /var/lib/system-upgrade was not cleaned.
2. The grub entry ''System Upgrade (fedup)' still persists in grub menu
(In reply to Satish Balay from comment #0)
> Description of problem:
> Previously with fedup - on reboot after running fedup - one can choose the
> following on the grub menu - with the corresponding actions:
> - 'System Upgrade' [or equivalent option]. Here fedup continues with system
dnf system-upgrade does not modify your boot options, so there's no special boot option to start it.
The upgrade only runs if you do "dnf system-upgrade reboot" to start the upgrade. It will then run regardless of which kernel you chose.
> However - with dnf-plugin-system-upgrade - even if the 'Older kernel option'
> is selected - it chuggs along with the upgrade process.
Only if you ran "dnf system-upgrade reboot" to start the upgrade. If you didn't do that, then this would just start your system normally.
> Version-Release number of selected component (if applicable):
> How reproducible:
> tried once.
> Steps to Reproduce:
> 1. fedup --network 23
> 2. dnf system-upgrade reboot
> 3. on reboot select 'System Upgrade (fedup)'
...why did you have a 'fedup' entry at all? This should not happen unless you ran the old fedup tool, which shouldn't be on your system anymore.
It sounds like what really happened was that you did:
fedup --network 23 (old fedup, which crashed)
dnf install dnf-plugin-system-upgrade (removed old fedup without cleanup)
fedup --network 23 (new plugin, which worked)
dnf system-upgrade reboot
tried "fedup" boot entry again (crashed)
tried normal boot entry (upgrade worked)
> Additional info:
> 1. /var/lib/system-upgrade was not cleaned.
/var/lib/system-upgrade is not used by dnf system-upgrade, so it doesn't clean that up.
> 2. The grub entry ''System Upgrade (fedup)' still persists in grub menu
That was created by the old fedup tool. You can remove it manually, if you like:
sudo new-kernel-pkg --remove fedup
It sounds like the dnf-plugin-system-upgrade package needs to clean up any existing fedup data / boot entries when it is installed. Probably we should check that in the package scriptlets.
Yes - I had attempted to run previous fedup.
[ mentiond at https://bugzilla.redhat.com/show_bug.cgi?id=1264942 ]
I assumed "fedup --resetbootloader" removed the 'Fedup' entry - I guess i should have verified.
Wrt /var/lib/system-upgrade - I thought /var/cache/* was used by fedup - and noticed dnf system upgrade populate stuff in /var/lib/system-upgrade. So I copied stuff over from the first location to the second - to aovid redownloading these files.. [which I thought worked - as I noticed only a few files were downloaded after that..]
Now I'm not sure where /var/lib/system-upgrade came from. I've deleted it after the upgrade.
And I've now deleted the fedup grub entry.
Fedup is now really gone (package is retired), and the /usr/bin/fedup is just a thin wrapper around the plugin. Nothing will touch the boot menu anymore, so this issue should not be possible to hit anymore.