Bug 1349664

The convert-to-edition.lua script has this function, which is called by convert_to_edition, which is called by install_edition:

-- Remove preset files for other editions
-- This should never be necessary, but it's best to be safe
local function clear_presets()
  local path = "/usr/lib/systemd/system-preset"
  for file in posix.files(path) do
    if file:match("^80-.*%.preset$") then
      os.remove(path .. "/" .. file)
    end
  end
end

It's obviously intended to do, basically, `rm -f /usr/lib/systemd/system-preset/80-*.preset` . The problem is, the pattern's wrong.

What it actually does is more like `rm -f /usr/lib/systemd/system-preset/8*.preset`. This is because '-' is a special character in lua patterns. See http://lua-users.org/wiki/PatternsTutorial:

- Match the previous character (or class) zero or more times, as few times as possible.

so the '-' effectively negates the 0 character that precedes it. The pattern will match 80-foo.preset , but it will also match 85-foo.preset , or 8aaaaa.preset .

The %post scriptlets for all fedora-release subpackages call install_edition, and there's a fedora-release %posttrans scriptlet which also calls install_edition. The upshot is that 8*.preset will be wiped at some point during *any* Fedora 24+ install - if any 'edition' is installed, they'll be wiped during the %post of that package install; if you do a non-edition install (e.g. a minimal install), they'll be wiped in %posttrans.

Notably, this affects /usr/lib/systemd/system-preset/85-display-manager.preset , whose job is to ensure that display managers are enabled by default.

It happens (fortunately...I guess?) that in a network install of Workstation, for e.g., gdm is installed before fedora-release-workstation - so when gdm's %post runs, 85-display-manager.preset is present, and gdm gets enabled (gdm's %post calls `systemctl --no-reload preset gdm.service`). And in an install of any other graphical environment, no 'edition' package will be installed, so the preset file will only be wiped in %posttrans and again the display manager will be enabled properly.

But if you install without a graphical environment, then install one and do `systemctl set-default graphical.target` then reboot, you don't get a graphical boot - because the display manager will not be enabled.

I noticed this because it affects the openQA upgrade test disk images: we build those by (effectively) doing a minimal install and then installing the desktop package group and enabling graphical.target , but I still wasn't getting a graphical boot after doing that, whereas it worked just fine on F23. Turns out, this is the cause.

The fix for this is trivial - we just have to escape the '-' with a '%'. I'm attaching a patch.