> > Please note, though, that we think that the mirror issue is a > > legitimate bug, either caused by dnf stack, or anaconda. Jan > > reported it yesterday here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1196164 > > > > If this turns out to be true, it would also mean that OpenQA helped > > us uncover quite an interesting bug, which would be much harder to > > spot without the massive number of installations executed regularly. > > So there is also some value in using closest mirror as installation > > source. > > Yep, that's an interesting one for sure, and sorry, I should've been > clearer: I was talking only about the tests where the actual test > involves specifying a particular repository URL (via the GUI or a > kickstart or on the cmdline or whatever), and we're currently using > 'download.fedoraproject.org' in those URLs.
OK, in that case, it completely makes sense. Moreover, I believe that using inst.repo=download.fp.o is explicitly forbidden and unsupported by anaconda (I would have to dig into past bug reports to find it). The problem is that anaconda does not resolve that once and then provide it to yum/dnf, but it uses it verbatim. Therefore that URL resolves itself on every request, potentially leading to different mirrors being used for metadata and packages, which can utterly break everything. At least that's what I remember from the past, maybe now with dnf it might work a bit differently. In any case, we should avoid using inst.repo=download.fp.o by any means. It's potentially very error-prone. _______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
