Created attachment 641404 [details] screencast Description of problem: When I set invalid NFS installation source and later want to change to closest mirror, it has a lot of glitches and breaks package selection screen. See video. Version-Release number of selected component (if applicable): anaconda 18.27 (smoke 16) How reproducible: always Steps to Reproduce: 1. boot netinst, let it download metadata from closest mirror 2. set invalid NFS installation source (valid server, invalid path) 3. set closest mirror back Actual results: 1) installation source icon is grayed out even when it works correctly (installation source) 2) package selection screen is completely broken
Created attachment 641419 [details] anaconda.log
Created attachment 641422 [details] packaging.log
Created attachment 641423 [details] program.log
Created attachment 641424 [details] storage.log
Created attachment 641425 [details] syslog
Proposing as Beta blocker, one error when specifying installation source is seriously breaking the software selection screen. Also please note that there might be more ways to break the software selection screen, it doesn't have to be only "closest mirror -> nfs -> closest mirror". This is just the one I found by accident. Maybe all "closest mirror -> something broken -> closest mirror" works the same.
What are your boot options? Where is stage2 coming from? I'm having difficulty reproducing this reliably. I can't see making this a blocker if it doesn't happen every time for everybody.
I just checked, it happens also with Beta TC8 and anaconda 18.28. I can reproduce it 100%. You don't have to provide invalid NFS repo, invalid HTTP repo causes it as well. Just put http://aaaa as a repo and then set it back to closest mirror. (In reply to comment #7) > What are your boot options? Where is stage2 coming from? Default netinst boot.
Verified on Beta TC8 netinst with anaconda 18.28 and default boot options. I can reproduce it reliably. After providing an invalid repo, if you go back and set Installation Source to "Closest mirror", it seems to still try whatever was originally entered in (regardless of the fact that the text is now grayed out). If you delete the text pointing to the invalid repo location and then select "Closest mirror", all should work. Probably not the most ideal behavior though.
Discussed at 2012-11-12 QA meeting acting as a blocker review meeting. Rejected as a blocker: "While an annoyance, this does not seem to be likely or severe enough to justify blocker or NTH status. A relatively painless workaround exists."
This behavior does not seem to appear in rawhide. Try installing off of a nightly build and let me know if that works for you.
(In reply to comment #11) > This behavior does not seem to appear in rawhide. Try installing off of a > nightly build and let me know if that works for you. Sorry, what do you mean? Anaconda 18.28 is the most recent anaconda. Nightly composes [1] are built from Branched, not Rawhide, and they are built from a stable repo only, so they can contain older anaconda, not newer. [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/ EDIT: I see anaconda 18.29 appeared, downloading smoke18 to try it out.
No change in smoke18 and anaconda 18.29. I cannot make the workaround mentioned in comment 9 get to work. I haven't found any way to fix the package selection screen (provided I want to revert to Closest Mirror) other than rebooting.
After my initial comment, I've been unable to reproduce this bug reliably. I did mistakenly leave one piece out of the workaround in comment 9 though, so I do apologize for that: -- After providing an invalid repo, go back and set Installation Source. Delete invalid repo address and set to "Closest mirror" -- At this point, the "Software selection" spoke will still have the warning sign displayed next to it. Click and pick a DE other than Gnome (default). -- After depsolving, the warning sign should be gone. If you reset "Software selection" to Gnome after that, there shouldn't be anymore problems. Again, still not really ideal behavior, but it doesn't necessitate a reboot to correct the errors.
Created attachment 652117 [details] reclaim dialog after providing invalid repo No matter what I did, I was unable to fix the broken package selection screen. Furthermore I've found out that many other dialogs are broken as well, see attachment. From my experience the best "workaround" here is to reboot completely.
was rejected as a blocker. funnily, I don't see this one, even though I've done the 'reproduction' steps before.
(In reply to comment #16) > was rejected as a blocker. funnily, I don't see this one, even though I've > done the 'reproduction' steps before. Ditto; aside from my first couple of attempts when this was initially reported, I've been unable to reproduce this ever again, despite going over the reproduction steps many times. Is this really a Common Bug? I don't recall anyone else having reported it, and it seems difficult to reproduce at best. Kamil, what version of anaconda were you running in comment 15? That looks to be entirely unrelated to this bug, at least. Since you seem to be the only person able to reproduce the issue reported here, have you tried with F18-beta?
I have done about 10 more runs, all with F18 Beta (anaconda 18.29.2). I have seen this bug manifest 9 times, once it worked OK (the UI was still shrunk, but enlarged almost immediately after opening install source/package selection screen) - that was bare metal with x86_64 pxeboot. But other runs with the same setup manifested the bug. So this is a race condition. I seem be lucky to trigger race conditions. That's why you don't always see it (but Samantha confirmed he saw that a few times as well). To reproduce this bug, I can recommend VM + Spice + qxl + i386 netinst, because that is the setup where I've always seen this bug, without exception.
i almost always test with x86_64, so I'll give it a shot with i386 if I remember.
Hey, first time I tried i386 netinst, I could reproduce this. Maybe it's arch-specific? Or just the arch affects the race, I guess. but yeah, I definitely confirm using the scenario kamil outlines, kvm/spice/qxl/i386 netinst.
(In reply to comment #20) > Hey, first time I tried i386 netinst, I could reproduce this. Maybe it's > arch-specific? Or just the arch affects the race, I guess. but yeah, I > definitely confirm using the scenario kamil outlines, kvm/spice/qxl/i386 > netinst. Same here; I can finally reproduce it. Unless specifically noted, I always test with x86_64 also. Ah well. Now to look into fixing this.
Kamil: was this ever fixed? Or is it still present in final?
This seems to be fixed in F18 Final.