Fedup aborts during upgrade from FC20 to FC21
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 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 |
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 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. |
Quote:
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 |
Quote:
Quote:
Quote:
Cheers, Terry |
You'll have to reformat the root partition - I meant don't format the /home partition. But you obviously are aware of that already.
|
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 Code:
[ 356.552] (DD) fedup.upgrade:setup_transaction() ts.check() Cheers, Terry |
Quote:
Quote:
|
Do you have lots of third-party repository or packages?
I run cinnamon, and fedup worked for me as workstation. |
Quote:
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 |
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.
|
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).
|
Quote:
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 |
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? |
Quote:
Cheers, Terry |
All times are GMT -5. The time now is 04:05 AM. |