Bug 622376
| Summary: | KeyError: <pyanaconda.yuminstall.AnacondaYumRepo object at 0x7f0edfb98390> | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jens Petersen <petersen> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | bblaskov, benedictus, christoferbertonha, cra, dmach, fred.new2911, jlaska, jonathan, liebundartig, linux, poelstra, rct+redhat, redhat, richardfearn, rvykydal, smooge, tflink, vanmeeuwen+fedora, zcerza |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | anaconda_trace_hash:a7ab76ad320a303faded54897632dbd3b25cfc4937144bd90c6d14d4f7f751f0 | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-08-03 19:25:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
Created attachment 437526 [details]
Attached traceback automatically from anaconda.
This seems similar to bug #505189 only that now the stale repo references after going back and forth in repo UI (through reposetup step) would come not from user edited/added repo but from elsewhere (failed updates/testing repo?). Jens, are you able to reproduce the issue? My suspicion is that it is related to going back in repo UI and failure of Updates Testing repository. Can you also describe the actions in repo UI you did (enabling/disabling/adding/editing repositiories) and error messages you were seeing (if there were any). What media did you use? DVD? Yes that is basically right: currently F14 anaconda enables testing repo by default - but it had broken deps. So Back, disable testing repo and forward and anaconda made this backtrace. I have a hacky patch for this one: https://www.redhat.com/archives/anaconda-devel-list/2010-August/msg00140.html To deal with "go back after creating of transaction and then disable a repo in UI" situation cleanly, big parts of repositories handling would need to be rewritten. Basically it would mean moving tasksel (which is also repo edit) UI step before reposetup step. I want to look at it, but it seems tough. Created an attachment (id=441103) Attached traceback automatically from anaconda. I added the F14-Alpha x86_64 repo at first. This reported dependency problems. So I went BACK and unselected F14-Alpha x86_64 which left just the original Installation Repo selected. This then resulted in the crash. Created an attachment (id=441460) Attached traceback automatically from anaconda. Created an attachment (id=446825) Attached traceback automatically from anaconda. Created attachment 450702 [details]
Attached traceback automatically from anaconda.
This is still here in the F14 Beta. It's a major inconvenience since this was a hard disk installation. The iso image is still on the hard disk, but with /boot formatted, there's no way to boot the installation again. (Grumbly message about having to use Windows to download and create a CD.) I'm thinking this should have a little higher priority, if not blocking status. I don't think you can guarantee that this won't happen after the repositories are sorted out. With regard to the sequence of events, the gnome-panel package was lacking the dependency lib<maybe-something>ui<something>. I didn't think I wanted to install gnome-panel without this dependency, so I went back and turned off the testing-updates repository. Did you try Radek's patch from comment 5? No, this was my first pass. I assume you're asking me to rebuild the ISO. Never done that before. I would be willing to experiment if you gave me some pointers (like in the Fedora Project wiki). (In reply to comment #13) > No, this was my first pass. I assume you're asking me to rebuild the ISO. > Never done that before. I would be willing to experiment if you gave me some > pointers (like in the Fedora Project wiki). Hold on, I'll post updates image for F14 beta. (In reply to comment #14) > > Hold on, I'll post updates image for F14 beta. It is here: http://rvykydal.fedorapeople.org/updates.conflict_back.img You can use it by adding: updates=http://rvykydal.fedorapeople.org/updates.conflict_back.img to boot parameters. See http://fedoraproject.org/wiki/Anaconda/Updates if you are interested in details. Unfortunately, we don't have any broken dependencies in updates-testing today and my system started installing without having to go back to uncheck the bad repository. I can try again Monday. By the way, since GRUB starts my hard disk installation, it was easy to copy and paste that long updates= line to the boot parameters in grub.conf. I'm still waiting for updates-testing to be broken. Maybe this problem isn't as serious as I thought it was. I was mostly concerned about ending up with a non-booting computer, but people who run hard-disk installations like I do probably know how to recover. Perhaps rather than being able to go back to turn off repositories, the final installation process could use a --skip-broken parameter. Created attachment 453544 [details]
Attached traceback automatically from anaconda.
I ran a couple installations today and it looks like the patch mentioned in comment 5 and comment 15 works. During the first installation I learned where the last point was where I could start going "back". During the second installation, I went back to the repositories page several times without any problems. My system still got installed without leaving me with a non-bootable hard disk like I originally complained about. This is an acceptable result. The only problem I had after going back all those times was that "Customize now" was ignored. That is, the system started installing without allowing me to customize which packages I wanted to install. Customize now was still marked; I didn't try turning it off and turning it on. Created attachment 471720 [details]
Attached traceback automatically from anaconda.
My attempt to solve the issue in bigger scope instead of the hack haven't got attention. Perhaps its time (or time for repository UI rewrite) is yet to come. (In reply to comment #21) > My attempt to solve the issue in bigger scope instead of the hack haven't got > attention. Perhaps its time (or time for repository UI rewrite) is yet to come. Oh, here is the patchset for the record: http://www.redhat.com/archives/anaconda-devel-list/2010-September/msg00181.html Created attachment 479762 [details]
Attached traceback automatically from anaconda.
Created attachment 481610 [details]
Attached traceback automatically from anaconda.
Created attachment 489259 [details]
Attached traceback automatically from anaconda.
*** Bug 679466 has been marked as a duplicate of this bug. *** *** Bug 733213 has been marked as a duplicate of this bug. *** *** Bug 740666 has been marked as a duplicate of this bug. *** The code this bug resulted from is no longer present as of anaconda-18.3. Please test with F18 and if you see similar problems, open a new bug. Thanks. |
The following was filed automatically by anaconda: anaconda 14.15 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 233, in _sql_MD cache = getattr(self.sack, MD + 'db')[self.repo] File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 46, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 388, in returnPrco cur = self._sql_MD('primary', sql, (self.pkgKey,)) File "/usr/lib/python2.7/site-packages/yum/packageSack.py", line 868, in _delPackageFromIndex for (n, fl, (e,v,r)) in obj.returnPrco('obsoletes'): File "/usr/lib/python2.7/site-packages/yum/packageSack.py", line 888, in delPackage self._delPackageFromIndex(obj) File "/usr/lib/python2.7/site-packages/yum/transactioninfo.py", line 300, in remove self._inSack.delPackage(txmbr.po) File "/usr/lib/python2.7/site-packages/yum/transactioninfo.py", line 697, in remove TransactionData.remove(self, pkgtup) File "/usr/lib64/python2.7/site-packages/pyanaconda/sortedtransaction.py", line 87, in remove SortableTransactionData.remove(self, pkgtup) File "/usr/lib64/python2.7/site-packages/pyanaconda/yuminstall.py", line 1332, in resetPackageSelections self.ayum.tsInfo.remove(txmbr.pkgtup) File "/usr/lib64/python2.7/site-packages/pyanaconda/backend.py", line 294, in doBasePackageSelect anaconda.backend.resetPackageSelections() File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 212, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 131, in gotoNext self.moveStep() File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1174, in nextClicked self.anaconda.dispatch.gotoNext() KeyError: <pyanaconda.yuminstall.AnacondaYumRepo object at 0x7f0edfb98390>