Bug 1446432

This is most likely an issue with the Fedora comps, so reassigning.

Where did you get the install media? Which version was it? The Workstation Edition netinstall? The Server Edition installer?

We need more information on exactly what you did. For example, what does "Select the minimal install option" mean?

(In reply to Stephen Gallagher from comment #2)
> Where did you get the install media? Which version was it? The Workstation
> Edition netinstall? The Server Edition installer?
> 
> We need more information on exactly what you did. For example, what does
> "Select the minimal install option" mean?

Hi Mr. Gallagher, I took the media from the fedora page https://getfedora.org/workstation/prerelease/ and download the 64bit version of the workstation net install.

With minimal installation I mean when you are in the installer and selects "SOFTWARE SELECTION" then in the section "Base Environment" select the radio button "Minimal Install" or "Fedora Custom Operating System", from Fedora 15 to 25 when you select the minimal install only gets the basic stuff and you can from there install a desktop or whatever you want.

Reassigning to Anaconda. Looks to me like what is happening is that when you select a different environment group under "SOFTWARE SELECTION", it's actually adding the packages for that environment group to the list, rather than replacing the list that's already enqueued for installation.

In my test just now, I intentionally tried installing on a VM with too little disk space to install Workstation. I set the selection to "Fedora Custom Operating System" and it told me that I needed 1.1GiB more space to install. I then switched to "Fedora Server" and it suddenly needed 1.5GiB more space. Back to "Fedora Custom" and it again needs 1.5GiB.

I tried with "Development and Creative Workstation" and it needs 5.96GiB. Back to "Fedora Custom" and it still needs 5.96GiB.

Proposed as a Blocker for 26-beta by Fedora user sgallagh using the blocker tracking app because:

 "When installing with the generic network install image, interactively selecting a package set other than the default must work... "Work" means that the mechanism for selecting different package sets must work: the packages in the set chosen must actually be correctly selected for installation."

Can confirm this - in fact openQA hits it, just doesn't notice there's a problem:

https://openqa.fedoraproject.org/tests/88501

that's the 'minimal package set' test, run from the Server DVD (so the default selected package set was Server, but the test changes it to "Fedora Custom Operating System", i.e. minimal). It completes and boots fine so openQA thinks it's fine, but if you look at the installed packages log file:

https://openqa.fedoraproject.org/tests/88501/file/_collect_data-rpms.log

it's got lots of stuff that's clearly from Server, not minimal, like abrt and cockpit. You can compare to the list from a *real* minimal install (from the Everything netinst):

https://openqa.fedoraproject.org/tests/88462/file/_collect_data-rpms.log

I guess I'll file an issue for openQA to make the 'minimal package set' test somehow try and check it was *really* the 'minimal package set' that got installed...

+1 blocker per the criterion sgallagh cited. Thanks for catching this.

Discussed during the 2017-05-01 blocker review meeting: [1]

The decision to classify this bug as an AcceptedBlocker was made as it violates the following blocker criteria:

"When installing with the generic network install image, interactively selecting a package set other than the default must work..."

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-05-01/f26-blocker-review.2017-05-01-16.02.txt

I'm wondering if the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1404158 - "Fix partial kickstart software selection in GUI (#1404158)", commit 012fe32eff1d3291a1f36a24f5a906f12ba01141 on f26-devel, 59bf385a9250c883f4acb81140fefe6d4f62e82b on master - could be related here? jkonecny?

No this is not related. That code is not even present on F26 alpha.

I'm not aware of any change in Anaconda which can cause this. I'll try to dig deeply and find what is causing this.

It looks to me like a bug in the DNF API, more precisely the 'reset()' method.

When an environment is changed we are calling 'Base.reset(goal=True)' and it should remove the selected packages, if I understand it correctly. However, from pdb it looks like Base.transaction.install_set is still full of packages after this call.

I'm switching this to DNF. Could you please look on that and verify if this is really an issue of DNF 2.3.0?

Please can you confirm that the problem appears with dnf-2.x? According my first look, the base.transaction object is filled after resolve() and it is not empty  after Base.reset(), because it deletes goal but the goal was already transformed into transaction therefore it doesn't change already filled transaction (two in depend objects).

Here is the PR that should solve a problem: https://github.com/rpm-software-management/dnf/pull/803

Tested, the patch should work properly.

Nice co-operation Jaroslav, good work.

dnf-2.4.1-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-e0fa49ff81

dnf-2.4.1-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e0fa49ff81

dnf-2.4.1-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Looks like we can confirm the fix for this from openQA testing: the post-install package list for the openQA 'minimal package set install' test now *does* look like the minimal package set (and not the Server package set, as it was before due to this bug).