Bug 1336960

fedora-release does not call systemctl enable but does tell the presets to take effect. you do not give enough infomration to redirect or fix the issue. at the least we need to see the full output of the transaction to try and determine what is happening.

I could not find a component for the package 'fedora-release-workstation', hence I selected 'fedora-release'.
The error message led me to believe 'systemctl enable' is used.

Steps to reproduce can be simplified:
1. reinstall computer with Fedora 24 using installation group 'minimal'
2. after installation and reboot in terminal: su -c 'dnf install -y fedora-release-workstation'


Actual results:
su -c 'dnf install -y fedora-release-workstation'
Failed to set locale, defaulting to C
Last metadata expiration check: 0:57:36 ago on Wed May 18 19:23:28 2016.
Dependencies resolved.
================================================================================================
 Package                                     Arch     Version           Repository         Size
================================================================================================
Installing:
 NetworkManager-config-connectivity-fedora   x86_64   1:1.2.2-1.fc24    updates-testing   104 k
 fedora-release-workstation                  noarch   24-0.16           fedora             23 k

Transaction Summary
================================================================================================
Install  2 Packages

Total download size: 126 k
Installed size: 1.9 k
Downloading Packages:
(1/2): fedora-release-workstation-24-0.16.noarch.rpm            390 kB/s |  23 kB     00:00    
(2/2): NetworkManager-config-connectivity-fedora-1.2.2-1.fc24.x 469 kB/s | 104 kB     00:00    
------------------------------------------------------------------------------------------------
Total                                                           146 kB/s | 126 kB     00:00     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : NetworkManager-config-connectivity-fedora-1:1.2.2-1.fc24.x86_64             1/2 
  Installing  : fedora-release-workstation-24-0.16.noarch                                   2/2 
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
  Verifying   : fedora-release-workstation-24-0.16.noarch                                   1/2 
  Verifying   : NetworkManager-config-connectivity-fedora-1:1.2.2-1.fc24.x86_64             2/2 

Installed:
  NetworkManager-config-connectivity-fedora.x86_64 1:1.2.2-1.fc24                               
  fedora-release-workstation.noarch 24-0.16

I guess it's systemctl preset misbehaving. It shouldn't print the hint with -q.

https://github.com/systemd/systemd/pull/3295

I'm not really comfortable just papering over this; we should really try to figure out which preset has been specified for a unit with no install section. That's got to be a bug.

The odd thing is that in this situation, only sshd.socket and sshd.service should be getting the `systemctl preset -q` treatment, and both of those have [Install] sections.

Beyond that, we shouldn't even be calling systemctl preset at all here, because convert_to_edition.lua should be skipping it when we're adding fedora-release-workstation after initial installation.

Zbigniew, is it possible there's a file trigger or something happening that's calling the presets, rather than actually the %post scripts?

And if that's the case, is it just calling `systemctl preset` for all presets? Because that's unexpected behavior. I wrote the convert_to_edition.lua script explicitly for the purposes of not changing the configured services just because you installed a new package. If file-triggers are causing all of the presets to be re-processed, that's going to cause problems.

There's two sides to this:
- from fedora-release point of view, units which have no [Install] section should indeed not be specified in presets, because it has a curated whitelist.
- from systemd point of view, we want to allow people to add units to presets which cannot be enabled, but potentially might be in the future, etc.

So we probably want to do both, i.e. fix -q, and maybe remove some units from presets in fedora-presets.

>  is it possible there's a file trigger or something happening that's calling the presets

I don't think so.

fedora-release-workstation-24-0.16.noarch.rpm has no scripts, triggers, or filetriggers, and systemd has filetriggers, but they only call daemon-reload. fedora-release-* remains as the likely culprit.

Oh, wait, it's a bug in systemd after all. It is fixed in git (there was a bunch of work in this area), but not in F24, so I missed that. So yeah, all is fine with fedora-relase.

... the bug is that "systemctl preset sshd.socket sshd.service" prints a warning. It shouldn't because both of those files have good [Install] sections.

OK, but there's still a bug in fedora-release-workstation somewhere, because it shouldn't actually be calling `systemctl preset sshd.socket sshd.service`. (Changing the default presets just because someone installed this package later is unexpected).

The convert_to_edition.lua package should be reading /usr/lib/variant, seeing that it's already "nonproduct" and then making no changes. (The only time that it should actually apply the preset is if it's called during initial installation of the system, since we don't set /usr/lib/variant until %posttrans.

My best guess is that for some reason, /usr/lib/variant isn't getting set in %posttrans of the fedora-release package, and so the later installation of fedora-release-workstation is unintentionally changing the system from nonproduct to Workstation.

The bug is easily reproducible:

$ sudo dnf -y --releasever=24 --installroot=/var/lib/machines/fedora-24 --disablerepo='*' --enablerepo=fedora --enablerepo=updates install @"Minimal install"
$ sudo systemd-nspawn -M fedora-24 passwd -d root
$ sudo systemd-nspawn -M fedora-24 -b
# dnf install -y fedora-release-workstation

Yeah, I've confirmed there's a bug in the %posttrans script of the fedora-release package. I'm working up a patch right now.

Patches for fedora-release submitted to pagure.io.

https://pagure.io/fedora-release/pull-request/47
https://pagure.io/fedora-release/pull-request/48

I am honored to learn from your comments. Thanks for the fix :)

systemd-229-9.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-47bda25e7a

systemd-229-9.fc24 has been pushed to the Fedora 24 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-2016-47bda25e7a

systemd-229-9.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.