Description of problem: I downloaded https://dl.fedoraproject.org/pub/fedora/linux/development/29/Server/x86_64/iso/Fedora-Server-netinst-x86_64-29-20181021.n.0.iso and attempted to install from it. Upon completion and reboot, I discovered that I had no network. Further investigation led to the D-BUS daemon not having started properly which was caused by having installed a version of the dbus package from updates-testing that was badly broken instead of the dbus package from the stable repository. This compose includes a fedora-repos package with the updates-testing repo disabled (which I confirmed by booting another VM from this netinst and checking /etc/anaconda.repos.d. The packaging.log from the installation clearly shows Anaconda asking mirrormanager for the updates-testing (but, interestingly *not* updates-modular-testing) repository, which it then uses in the transaction. Version-Release number of selected component (if applicable): anaconda-29.24.3-2.fc29 How reproducible: Every time Steps to Reproduce: 1. Start a VM, booting from https://dl.fedoraproject.org/pub/fedora/linux/development/29/Server/x86_64/iso/Fedora-Server-netinst-x86_64-29-20181021.n.0.iso 2. Run the installation. 3. After reboot, examine /var/log/anaconda/packaging.log Actual results: The installation used the updates-testing repo, which may contain untested and unsafe packages. Expected results: Only the stable repository should be used unless the user has added updates-testing manually. Additional info: (See also https://bodhi.fedoraproject.org/updates/FEDORA-2018-1eff1712c2 for the D-BUS issue that helped identify this).
Proposed as a Blocker and Freeze Exception for 29-final by Fedora user sgallagh using the blocker tracking app because: "Release-blocking network install images must default to a valid publicly-accessible package source." -- Basic Release Criteria I contend that including updates-testing by default in the installer is in violation of "valid" here. It might have been valid during Beta and earlier, but as of Final we must not be installing packages from updates-testing.
This may have been introduced as a side-effect when resolving https://bugzilla.redhat.com/show_bug.cgi?id=1636739
I also run into an installation with no network when I was preparing a minimal kickstart file for bug 1642013. I thought that I had missed some packages - thanks for finding the problem. About updates-testing: I thought that updates-testing is enabled by default on pre-releases, and will be disabled on release images.
(In reply to Edgar Hoch from comment #3) > I also run into an installation with no network when I was preparing a > minimal kickstart file for bug 1642013. I thought that I had missed some > packages - thanks for finding the problem. > > About updates-testing: I thought that updates-testing is enabled by default > on pre-releases, and will be disabled on release images. We disable it once we enter Final Freeze to ensure that we can test it before the release. That happened a couple weeks ago, so this is definitely unexpected behavior at this time.
I'm also "blocker +1" on this - we need to make sure only stable repositories are enabled on release image and should not release without that.
I'm +1 blocker, we do not want everyone using netinst to get testing repos. ;(
I'm also +1 blocker, just to record that clearly.
Voted on in-bug on 2018-10-23. The decision to accept this bug as a blocker was made as it violates the following blocker criteria: "Release-blocking network install images must default to a valid publicly-accessible package source."
Reproduced with 20181022 compose
After further investigation and discussion with Fedora QA, it turns out this is most likely not a bug as no RC compose has yet been run. Therefore Anaconda reporting pre-release & using updates testing is the correct behavior. So closing the bug, feel free to reopen if the same behavior (pre-release warning & enabled updates-testing) can be reproduced on an actual RC compose image.
Reopening This cannot be made to wait for an RC compose as it means that no valid testing of the netinst media can be performed prior to a Release Candidate, which is generally only produced once we believe we have discovered and fixed all major issues. This needs to be changed in such a way that updates-testing can be disabled as soon as we enter Final Freeze.
I’d like to take this one step further, actually. I don’t understand under what conditions we would want updates-testing to be used in the install process at all. It means that we cannot actually consider any testing done on the netinst installation as valid, since it’s not using the stable set of packages. I understand the value of having u-t enabled for updates after install during the pre-release period, but I strongly feel that it should not be included in the install process unless a user manually elects to do so (such as by adding the updates-testing repo to the software sources).
(In reply to Stephen Gallagher from comment #11) > Reopening > > This cannot be made to wait for an RC compose as it means that no valid > testing of the netinst media can be performed prior to a Release Candidate, > which is generally only produced once we believe we have discovered and > fixed all major issues. > > This needs to be changed in such a way that updates-testing can be disabled > as soon as we enter Final Freeze. And you are right! :) After even further investigation it turns out this is happening: 1) the fedora-repos package (29.1) has the correct updates testing repo file with enabled=0 for updates-testing 2) the file is present on the image and Anaconda parses it 3) then a piece of code in the DNF payload sets the updates-testing repo as enabled if isFinal=False in bootstamp The strange thing is that this piece of code has been there since ~2016, but is seems like it had no effect in at least F28 and possibly other older releases. So we will try to drop 3) and see if it helps. :)
PR implementing the F29 hotfix from comment 13: https://github.com/rhinstaller/anaconda/pull/1671 Updates image with the change against Anaconda 29.24.7-1: https://m4rtink.fedorapeople.org/anaconda/update_images/fedora/f29/updates-testing-hotfix.img For F30+ we should discuss the intended behavior and come up with something better - but to keep things sane that should be discussed in a new & separate rawhide bug.
I have tested Fedora-Server-netinst-x86_64-28-1.1.iso with IsFinal=False in the .buildstamp file and Anaconda enables the updates-testing repo. I wonder if disabling of this repo has ever worked on pre-releases.
We've requested RC1 compose without any fix in anaconda. After looking at the code and consulting anaconda devs, everything should just work fine when we create RCs with the current anaconda, i.e. updates-testing should be disabled. The code change is only needed to make *nightlies* *also* disable updates-testing. And that is of course not preventing us from doing an RC1 compose. If RC1 turns out to behave correctly, the blocker can be lifted and we can use this for a discussion how to fix this long term (for F30).
This is working fine with RC1.2 compose. Updates-testing is disabled (tested Everything netinst and Server netinst). I don't think this qualifies as a blocker, at this point. Re-proposing for discussion.
blocker or not, it does not matter too much for fc29 since RC fixed it. We can leave it as is for now, and discuss about the intended behaviour for F30
Discussed during the 2018-10-25 Fedora 29 Final Go/No-Go meeting: The decision to classify this bug as a “RejectedBlocker” was made as this bug is fixed in RC composes any only affected pre-release images.
I have created a ticket for fedora-qa to figure out how updates-testing should be handled throughout the cycle: https://pagure.io/fedora-qa/issue/567 I'll close this bug for the moment, and reopen it once we have a concrete request for the anaconda team.
I have asked for the changes in a new ticket, see bug 1670091.