Fedup aborts during upgrade from FC20 to FC21

terry-duell · 01-12-2015, 03:38 PM

Hello All,
I have run into a problem whilst upgrading from FC20 to FC21 using Fedup-0.9.1-1.fc20.
I run Cinnamon desktop and followed advice (don't have link) to go about it as follows:

Code:

yum update
reboot
yum install fedup
fedup --network 21 --product=nonproduct --nogpgcheck --reboot

After all the packages were downloaded it commenced "Testing upgrade transaction", and part way through that fedup crashed.
I chose "report" in the notification, and a dialog box (Abrt?) advised that a lot of data would need to be downloaded to produce a stack trace, so chose not to do that.
The dialog said the most common reason were...
network connection problems
corrupted problem data
invalid configuration
I was then advised that I could go to "Preferences" and apply the configuration changes, then click Repeat button.
This advice is a bit obtuse...reconfigure what?
Any ideas, other than downloading all the data necessary to produce a stack trace, which I would like to avoid if I can, my internet isn't fast (over 5 hours to get the upgrade files).

Cheers,
Terry

unSpawn · 01-12-2015, 04:34 PM

Do you have a "/var/log/fedup.log"? If not, did you try "--debuglog" from reading 'man fedup' and see what that shows? And if that doesn't work check https://fedoraproject.org/wiki/FedUp...th_upgrades.3F for anything that may help or applies to your situation.
*BTW, you do have a backup, right?

syg00 · 01-12-2015, 05:26 PM

I would have thought Cinnamon was just an pakage install, not a full spin; so --product=workstation would have been appropriate.

I've always considered (version) upgrades as a weak link in any distro. So if I try fed-up (I usually avoid it altogether), I always do so on the understanding there is a fair chance I'll have to resort to a full re-install anyway. So ...
Create a separate /home partition if you aren't already in that situation, and download the DVD. And yes, I feel your pain about long downloads - I live in the donga, and suffer likewise. Do a clean install using that /home partition and the same user/password - don't format it. If you can't get an installed package list from your munged system (chroot might work), you'll have to rely on memory, or wait till you want to use a particular package, and reinstall.
I've never found abrt to be much use, but the fed-up devs might like to know what went wrong in your case. Up to you.

As unSpawn said, a backup might have saved a lot of angst, although I've always been able to just re-install using the separate /home after a fed-up fiasco.

terry-duell · 01-12-2015, 11:52 PM

Quote:

Originally Posted by unSpawn

Do you have a "/var/log/fedup.log"? If not, did you try "--debuglog" from reading 'man fedup' and see what that shows? And if that doesn't work check https://fedoraproject.org/wiki/FedUp...th_upgrades.3F for anything that may help or applies to your situation.
*BTW, you do have a backup, right?

I tried --debuglog, and as an aside the man page is a bit out of kilter as it won't default to /var/log/fedup.log...it must be specified; and that shows that there are a number of self built packages that have dependencies that are being upgraded. Nothing else obvious in the log.
That hasn't turned out to be the source of the problem though (I don't think) as I have erased all of these packages, rebooted and re-run the process. It picks up the cache does some checking, then crashes.
Not reasonable behaviour.
Yes, I do have a good backup.

Cheers,
Terry

terry-duell · 01-13-2015, 12:02 AM

Quote:

Originally Posted by syg00

I would have thought Cinnamon was just an pakage install, not a full spin; so --product=workstation would have been appropriate.

Yes, that crossed my mind as well, and reran using "workstation", which added a few packages to the cache, but still crashed.

Quote:

Create a separate /home partition if you aren't already in that situation, and download the DVD. And yes, I feel your pain about long downloads - I live in the donga, and suffer likewise. Do a clean install using that /home partition and the same user/password - don't format it. If you can't get an installed package list from your munged system (chroot might work), you'll have to rely on memory, or wait till you want to use a particular package, and reinstall.

I always use a /home, so a clean install is the solution when all else fails. I always start this sort of process by capturing an installed package list, to simplify getting a clean install set up as I would like. I have never had any success doing a clean install without a reformat...I'm sure there is supposed to be a way to do it, but blowed if I have ever been able to wrestle it into submission.

Quote:

As unSpawn said, a backup might have saved a lot of angst, although I've always been able to just re-install using the separate /home after a fed-up fiasco.

I have decided to have one more try before resorting to a clean install, so deleted the cache and re-running fedup. In a few hours I'll know if it really can work.

Cheers,
Terry

syg00 · 01-13-2015, 12:15 AM

You'll have to reformat the root partition - I meant don't format the /home partition. But you obviously are aware of that already.

terry-duell · 01-13-2015, 03:39 PM

Another attempt at the upgrade also went belly-up, but this time no notification of a crash, it just appears to have ceased at 44% through the testing.

Here is the first and the last few lines from the fedup command

Code:

[terry@localhost ~]$ sudo fedup --network 21 --product=workstation --debuglog /var/log/fedup.log --reboot
...
testing upgrade transaction
rpm transaction 44% [============================================================                                                                              ]
[terry@localhost ~]$

Here are the last few lines of /var/log/fedup.log

Code:

[   356.552] (DD) fedup.upgrade:setup_transaction() ts.check()
[   357.759] (DD) fedup.upgrade:setup_transaction() ts.order()
[   358.030] (DD) fedup.upgrade:setup_transaction() ts.clean()
[   358.094] (DD) fedup.upgrade:setup_transaction() transaction is ready
[   358.095] (DD) fedup.upgrade:run() ts.run()

I probably should make a bug report, but this lot doesn't seem to provide much useful information.

Cheers,
Terry

unSpawn · 01-13-2015, 05:51 PM

Quote:

Originally Posted by terry-duell

I probably should make a bug report,

Please do!

Quote:

Originally Posted by terry-duell

but this lot doesn't seem to provide much useful information.

IIRC everything that gets syslogged (apart from possibly any /root/*anaconda* ?) should be in /tmp. So you could inspect logs there, create a tar ball and if that's not enough let devs point you to what they would like to see additionally?

GaWdLy · 01-14-2015, 10:34 PM

Do you have lots of third-party repository or packages?

I run cinnamon, and fedup worked for me as workstation.

terry-duell · 01-14-2015, 11:38 PM

Quote:

Originally Posted by GaWdLy

Do you have lots of third-party repository or packages?

I run cinnamon, and fedup worked for me as workstation.

Yes, I have a few 3rd party repos, Dropbox, VirtualBox, and all the free and non-free rpmfusion repos.
I didn't see any messages in the log that there was any problem with keys or related stuff for these repos, but even if there were one would expect fedup to report the problems instead of crashing or aborting.
I have reported the behaviour I am seeing as a bug, but don't expect a rapid response.
I think I will give up on fedup and will do clean install, unless you have some Really Useful advice as to how to make it work.

Cheers,
Terry

GaWdLy · 01-15-2015, 12:50 AM

I consume fedup, I don't have much more involvement in it than that. I don't know where to start, without the report finishing. I know it would have barfed on the rpmfusion repository and packages and would have required temporary removal.

syg00 · 01-15-2015, 01:10 AM

No, it (now) works fine with rpmfusion - in my case I hadn't imported the key, and that stopped fed-up. But once I fixed that up, it re-ran fine (32-bit system).

terry-duell · 01-15-2015, 03:38 AM

Quote:

Originally Posted by GaWdLy

I consume fedup, I don't have much more involvement in it than that. I don't know where to start, without the report finishing. I know it would have barfed on the rpmfusion repository and packages and would have required temporary removal.

I haven't quite given up...had another try, and it downloaded a few more 21 updates, and then used the cache, but it did fail again.
This time the log file is a bit more helpful.
There are a number of packages that it can't update, previously there were just some warnings, but this time it has added more detail at the end of the log which indicates that these are problems. These packages are local builds of hugin and enblend from current default source so one can't expect there to be a package in the 21 repos.
I can remove these and rebuild in 21 from the src.rpm, but will this change be taken into account by fedup, or does fedup simply use an existing list of installed packages it already has in the cache?
If it is using a list in the cache is there a way of getting it to regenerate an installed package list for 20? i.e. is there a file in the cache that I could remove to force a new current package list?
I have already tried removing these packages, suspecting that hugin and enblend would cause problems, but it didn't seem to help...fedup still failed, so suspect it is using a list of installed packages it generated on the first run through.
I have had to re-install hugin and enblend again to do some work, but they can easily go.
It would be a real bugger to have to delete the whole cache to account for changes in installed packages.

Cheers,
Terry

GaWdLy · 01-15-2015, 10:02 AM

Try removing your custom packages, and then doing a deletion of the yum cache, and a # yum clean all. That should regenerate everything (packages, headers, and metadata). The cache is in /var/cache/yum/*.

Why such a bugger to delete the cache? A bandwidth limitation?

terry-duell · 01-15-2015, 03:10 PM

Quote:

Originally Posted by GaWdLy

Why such a bugger to delete the cache? A bandwidth limitation?

...because it will take about 5 hours to regenerate it!

Cheers,
Terry