Bug 1052274 - incomplete update but fedup exits cleanly
Summary: incomplete update but fedup exits cleanly
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-13 14:44 UTC by Orcan Ogetbil
Modified: 2015-06-30 00:50 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-06-30 00:50:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
fedup.log (3.49 MB, text/plain)
2014-01-14 01:56 UTC, Orcan Ogetbil
no flags Details
upgrade.log (1.44 MB, text/x-log)
2014-01-14 02:00 UTC, Orcan Ogetbil
no flags Details
fedup.log (864.62 KB, text/plain)
2014-11-03 09:28 UTC, Petr Schindler
no flags Details

Description Orcan Ogetbil 2014-01-13 14:44:41 UTC
Fedora 19 to Fedora 20 with fedup-0.8.0-3.fc19.noarch left the system at a partially upgraded state. After the reboot, no Fedora 20 kernels show up. But

root@desitter ~ # cat /etc/fedora-release 
Fedora release 20 (Heisenbug)

root@desitter ~ # uname -r
3.12.5-200.fc19.x86_64

root@desitter ~ # rpm -q kernel rpm yum fedup
kernel-3.12.5-200.fc19.x86_64
kernel-3.12.6-200.fc19.x86_64
rpm-4.11.1-3.fc19.x86_64
rpm-4.11.1-7.fc20.x86_64
yum-3.4.3-128.fc19.noarch
yum-3.4.3-129.fc20.noarch
fedup-0.8.0-3.fc19.noarch

root@desitter ~ # tail /var/log/fedup.log
[   248.798] (II) fedup:<module>() /bin/fedup exiting cleanly at Mon Jan 13 00:53:40 2014
[     0.368] (II) fedup:<module>() /usr/bin/fedup starting at Mon Jan 13 02:59:40 2014
[     0.464] (II) fedup.sysprep:remove_cache() removing /var/tmp/system-upgrade
[     0.809] (II) fedup.sysprep:remove_cache() removing /var/lib/system-upgrade
[    34.466] (II) fedup.sysprep:remove_cache() removing /var/tmp/system-upgrade
[    34.466] (II) fedup.sysprep:remove_cache() removing /var/lib/system-upgrade
[    34.466] (II) fedup.sysprep:misc_cleanup() removing symlink /system-upgrade
[    34.466] (II) fedup.sysprep:misc_cleanup() removing /system-upgrade-root
[    34.474] (II) fedup.sysprep:misc_cleanup() removing /lib/systemd/system/system-upgrade.target.requires
[    34.475] (II) fedup:<module>() /usr/bin/fedup exiting cleanly at Mon Jan 13 03:00:14 2014


Is there a way to fix this system?

Comment 1 Will Woods 2014-01-13 17:47:25 UTC
This is very likely the same as bug 904112, except for F19→F20.

Could you attach /var/log/fedup.log and /var/log/upgrade.log?

Comment 2 Orcan Ogetbil 2014-01-14 01:56:53 UTC
Created attachment 849697 [details]
fedup.log

Comment 3 Orcan Ogetbil 2014-01-14 02:00:20 UTC
Created attachment 849698 [details]
upgrade.log

Acccording to the upgrade.log, it looks like the upgrade failed during the lpf package update %post scriptlet. Is fedup expected to fail when a $post scriptlet fails?

More importantly, how do I recover from this situation?

Comment 4 Will Woods 2014-01-14 16:43:37 UTC
According to fedup.log, at the end of the 'fedup' run it printed the following warning:

Packages without updates:
  a52dec-0.7.4-18.fc19.x86_64
  [...29 lines removed...]
  kernel-3.12.5-200.fc19.x86_64
  kernel-devel-3.12.5-200.fc19.x86_64
  kernel-devel-3.12.6-200.fc19.x86_64
  [etc.]

So the reason it didn't install a *kernel* is because the F19 kernel package was (at the time) newer than the F20 kernel package, like I said in comment #1.


As for the upgrade itself crashing: no, obviously a non-fatal scriptlet error is supposed to be non-fatal. RPM only considers errors in %prein, %preun, or %pretrans scripts fatal; everything else is a warning.

fedup-dracut/system-upgrade-fedora.c just logs the error and continues with the upgrade; there's no "exit()" or anything there, and as far as I can tell there's no reason that the rpm library would cause an exit/abort. There's also no message about system-upgrade-fedora crashing in the log.

So: I'm really not sure why it ended there. This will require further investigation. Ideally, if the problem is reproduceable, running with 'rd.upgrade.debug=1' would be very helpful.


Finally, fixing the system: since your system appears to at least let you log in, and 55% of the packages already got installed (including fedora-release, rpm, and yum) you could probably just clean any duplicates (e.g. with `package-cleanup --cleandupes`) and then `yum update` to finish the upgrade.

Comment 5 Orcan Ogetbil 2014-01-14 19:41:25 UTC
Thanks. I have one more F-19 machine with a similar setup. I'll try that one with rd.upgrade.debug=1. Where do I set this option again?

As for this machine, when I do
   yum update
it is trying to install Fedora 19 packages instead of Fedora 20 packages. How does yum decide which Fedora release it is using for updates? I thought yum was just looking at /etc/fedora-release

Comment 6 Will Woods 2014-01-15 19:04:40 UTC
(In reply to Orcan Ogetbil from comment #5)
> Thanks. I have one more F-19 machine with a similar setup. I'll try that one
> with rd.upgrade.debug=1. Where do I set this option again?

Add it to the boot arguments - either edit your grub(2).cfg or edit it in the bootloader menu.

> As for this machine, when I do
>    yum update
> it is trying to install Fedora 19 packages instead of Fedora 20 packages.
> How does yum decide which Fedora release it is using for updates? I thought
> yum was just looking at /etc/fedora-release

Actually, no - it looks at the RPM database for that. It looks up 'system-release' and uses the version number provided by the *first* package it finds.
So if you have two 'fedora-release' packages installed, it might find the F19 one first.

The simplest solution is probably to add '--releasever=20' to your yum commandline. You could also try removing the offending package first (`yum erase fedora-release-19`, or `rpm -e --nodeps fedora-release-19` if that doesn't work).

I'm working on reproducing the original problem now. Sorry for the trouble!

Comment 7 Orcan Ogetbil 2014-01-16 03:44:39 UTC
Thanks, figured it out. "package-cleanup --cleandupes" was hitting maximum number of iterations before failing. So I had to uninstall certain packages manually. Afterwards I ran "yum --releasever=20 distro-sync", and things seem fixed now.

Comment 8 W. Smith 2014-03-07 02:26:55 UTC
I am experiencing this exact same issue, however I'm unable to update my system when running steps in comments 4-7

[root@blackstar yum.repos.d]# package-cleanup --cleandupes
Loaded plugins: fs-snapshot, versionlock
No duplicates to remove
[root@blackstar yum.repos.d]# yum update
Loaded plugins: fs-snapshot, versionlock
No packages marked for update
[root@blackstar yum.repos.d]# yum --releasever=20 update
Loaded plugins: fs-snapshot, versionlock
No packages marked for update

My fedora-release package is fedora-release-20-1.noarch also.

My repos are configured to the following:

[root@blackstar yum.repos.d]# yum repolist
Loaded plugins: fs-snapshot, versionlock
repo id                                                          repo name                                                                  status
PlexRepo/x86_64                                                  PlexRepo                                                                       12
SABnzbd/20                                                       SABnzbd for Fedora 20 - x86_64 - Base                                           2
fedora/20/x86_64                                                 Fedora 20 - x86_64                                                         38,597
rpmfusion-free/20/x86_64                                         RPM Fusion for Fedora 20 - Free                                               468
rpmfusion-free-updates/20/x86_64                                 RPM Fusion for Fedora 20 - Free - Updates                                     222
rpmfusion-nonfree/20/x86_64                                      RPM Fusion for Fedora 20 - Nonfree                                            203
rpmfusion-nonfree-updates/20/x86_64                              RPM Fusion for Fedora 20 - Nonfree - Updates                                  151
updates                                                          Fedora 20 - x86_64 - Updates                                               17,912
repolist: 57,567


Any idea how I might get my system fully to f20?

Comment 9 W. Smith 2014-03-07 02:57:01 UTC
Comment 8 can be disregarded. I've resolved the issue.

Comment 10 Petr Schindler 2014-11-03 09:28:24 UTC
Created attachment 953033 [details]
fedup.log

I'm experiencing this bug with fedup-0.9.0-1.fc19 when upgrading to Fedora 21 Beta RC 4.

command I run before rebooting:
fedup --network 21 --product workstation --instrepo http://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC4/Server/x86_64/os/

You can find fedup.log attached.

Comment 11 Petr Schindler 2014-11-03 09:34:45 UTC
Oh. I should give more information about what exactly happened:
I fully updated f19. Then I used the newest version of fedup from updates-testing. Gathering of packages ended well. After restart and booting fedup entry the installation started properly.

The installation of packages went well but at the end the computer is powered down instead of restarted. After I boot again, there is no f21 entry in grub. After booting to f19 the system seems to work, but gdm doesn't start, but I can log in console.

In the system there are some packages upgraded (for example yum, rpm and kernel), release-notes says f21 too.

Comment 12 Petr Schindler 2014-11-03 09:42:27 UTC
Maybe I just reproduced bug 1159292 I'm not sure.

Comment 13 Will Woods 2014-11-03 14:30:04 UTC
If the system powered down, then you hit bug 1159292.

Comment 14 Fedora End Of Life 2015-05-29 10:28:57 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 '20'.

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 20 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.

Comment 15 Fedora End Of Life 2015-06-30 00:50:52 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.


Note You need to log in before you can comment on or make changes to this bug.