I just upgraded from F9 to the latest preview (9.93?) via preupgrade. After the upgrade, yum is deeply confused- it can't find anything in the repos because it is looking for releasever '9.93' when, AFAICT from the servers, the release directories are actually '10-preview' or things along those lines. So it looks to me like releasever needs to be set to something more useful (possibly less 'correct'?) so that yum continues to work. marking severity high because it breaks upgrades, making it difficult to fix for the lay-ish person (though obviously the lay-ish person shouldn't be upgrading to a preview release.) Also, packagekit 'helpfully' reminds me every 30 minutes or so that my repos are broken, in language that can't possibly be useful to any lay-ish person to help diagnose or fix the problem. (I realize that's a different bug to file, just venting.) This may not strictly be a preupgrade bug, but I'm not sure where else it would go right now; please reassign if I'm running around blind here. Thanks!
Which fedora-release do you have? AFAIK, for 9.93 you should have rawhide enabled in /etc/yum.repos.d/fedora-rawhide.repo and it doesn't use releasever. Can you confirm this? What do "yum repolist" say? From the rawhide repo it will in turn get an updated fedora-release package which sets releasever to 10.
fedora-release 9.93. I don't have rawhide enabled; I do have fedora enabled. Flipping both those stops the error. I would have expected that using preupgrade to move to a preview release would 'do the right thing' with regards to making sure that yum worked. Downgrading severity and changing title, since this apparently isn't the recommended way to upgrade to a preview release. Still, since preupgrade does offer to take you to a preview release, it would be great if it knew enough to leave yum functional afterward ;)
The 9.93 rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=68191 has rawhide enabled and fedora disabled. Could it be that its .repo files for some reason has been placed as .repo.rpmnew, and you thus don't get the repos enabled you were supposed to? Can you confirm this? And does it work as expected if you move them in place? If so: yes, it seems to be something that preupgrade could be expected to handle ...
I accidentally deleted the .rpmnew files in the directory by accident, but ISTR that I checked the timestamps before deletion and that they predated the upgrade. Can't confirm now, unfortunately.
First, you can verify if you have the .repo files you "should" have: rpm -qV fedora-release I assume it will show "something" Then you can download fedora-release-9.93-1.noarch.rpm from koji, and for example rpm -e fedora-release --nodeps rpm -ihv fedora-release-9.93-1.noarch.rpm
Unfortunately, this got updated yesterday after I fixed the problem (along with several hundred other packages that I would have expected to have been upgraded during preupgrade, but that is another problem.) [louie@towel ~]$ rpm -q fedora-release fedora-release-10-1.noarch [louie@towel ~]$ rpm -qV fedora-release S.5....T c /etc/yum.repos.d/fedora-updates-testing.repo .......T c /etc/yum.repos.d/fedora-updates.repo S.5....T c /etc/yum.repos.d/fedora.repo After deleting 10-1 and installing 9.93: [louie@towel ~]$ rpm -q fedora-release fedora-release-9.93-1.noarch [louie@towel ~]$ rpm -qV fedora-release [louie@towel ~]$ After deleting 9.93 and installing 10-1: [louie@towel ~]$ sudo rpm -e fedora-release --nodeps[louie@towel ~]$ sudo rpm -ivh fedora-release-10-1.noarch.rpm Preparing... ########################################### [100%] 1:fedora-release ########################################### [100%] [louie@towel ~]$ rpm -qV fedora-release [louie@towel ~]$
Well ... not much evidence left ... I think that was is left is a feature request: preupgrade should handle the situation where the user has edited his .repo files. Right now it silently doesn't do what the user expects it to do.
preupgrade does not modify your repository data at any point. This is entirely handled by anaconda upgrading the 'fedora-release' package. The repo files, like all configuration files, are left alone if user-modified. Possibly anaconda could check if those files have been modified and offer to either a) replace them with the new repo files, or b) leave them as-is (and create .rpmnew files, which is the current default behavior). Preupgrade would default to the former. Reassigning to anaconda, although I'm almost sure bug this has been filed before..
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 454472 has been marked as a duplicate of this bug. ***
Since we have moved the conversation on this one here, I am wondering if this is related to bug 452724. where there are some comments about the update process not stopping for or mentioning errors in rpms and so not installing things that it says are being installed. Could this problem be in some way the fedora-release rpm not being processed or failing part way thought the process of installing and leaving the system in a "unique" state without giving any notice of this fact. Just this thought. As for my bug report as I mentioned, I mainly was reporting it as a way to have anyone else also having problems have a place to start in tracking and repairing those problems. Unless we got a bunch of people saying "yes that is also me" I was expecting it to be closed without a lot of work on it.
No. It's not an error. RPM is behaving exactly as configured - files marked as %config(noreplace) are not replaced automatically. Whether the fedora repo files *should* be marked 'noreplace' is a different matter entirely.
I believe that the files are marked to be replaced in the vast majority of cases this certainly appears to be what is happening. However; what appears to have happened is that in a few cases they are not being replaced, and this is causing problems. As an example my upgraded system slowly deupgraded itself because while the upgrade completed with no other apparent errors, the repos were still the ones for the previous version so all yum updates were run against this previous version. The referenced other bug is one where some other rpm's experienced some form of temporary error during the upgrade process and not completing, and did so without the installer indicating that there was an error. I am postulating (and only postulating) that during my install and this same temporary error problem occurred while processing the fedora-release rpm, which is what is causing these problems. But the rpms themselves seem to be OK, and when these errors don't occur they are processed correctly.
*** Bug 473793 has been marked as a duplicate of this bug. ***
I run into this problem (or very similar) during F10 -> rawhide (in beta freeze) preupgrade. On F10 I had updates-testing repo enabled. After upgrade, updates-testing was still enabled and made some mess, as updates-testing at the moment contained few packages in version newer than rawhide. I think updates-testing is special case and should be disabled by preupgrade.
As mentioned in comment #8, preupgrade does not (and will not) modify your yum config files. This problem is not specific to preupgrade - it would happen the same way if you upgraded using the rawhide boot.iso, or the F11 Beta installer images. If there's going to be special handling for whether or not to replace repo config files, it needs to happen in anaconda or in a %post script in the fedora-release package itself.
Not going to happen. Once you've locally modified your repos, we're hands off. Must not trample local configs, period.
I guess I'll reopen when preupgrading to F11 inevitably breaks then?
Look, you modified your local config files, enough of them to really hurt yourself. The fedora-release in rawhide and alpha/beta are setup so that the fedora and updates repos are disabled, while the rawhide repo is enabled. It sounds like your repo files are modified enough so that neither of those settings are written due to honouring your local repo configs. If your repos had not been modified, the new repo enables/disables would have been put in place and you wouldn't have seen this issue. At the most, I would think this should be a release notes or just general documented issue, that when you change config files, your changes prevail upon upgrades, for better or for worse.