Systemd-oomd and systemd-pstore never enabled after Fedora 43 KDE live install (preset gap between live image and Anaconda)

Ask Fedora
,
1

Summary

Systems installed from the Fedora 43 KDE live ISO end up with systemd-oomd.service, systemd-oomd.socket, and systemd-pstore.service disabled, even though Fedora’s preset says they should be enabled (Changes/EnableSystemdOomd):

$ systemctl status systemd-oomd
○ systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer
     Loaded: loaded (/usr/lib/systemd/system/systemd-oomd.service; disabled; preset: enabled)
     Active: inactive (dead)

I installed on 2026-04-19 and only noticed three months later, when a runaway process froze the whole desktop under memory pressure and nothing was there to kill it. My retained journal covers all 67 boots back to install day: Listening on systemd-oomd.socket appears in none of them. It was never enabled, and I never disabled it.

Root cause (reconstructed from install-day logs)

The enablement symlinks are not baked into the live image’s /etc. They get created at boot time by systemd’s first-boot preset application (Changes/Preset_All_Systemd_Units_on_First_Boot), which fires in the live environment because the live image boots with an uninitialized machine-id. The live session’s journal, preserved in /var/log/anaconda/journal.log, shows PID 1 doing exactly that:

Apr 19 14:17:57 fedora systemd[1]: Created symlink '/etc/systemd/system/dbus-org.freedesktop.oom1.service' → '/usr/lib/systemd/system/systemd-oomd.service'.
Apr 19 14:17:57 fedora systemd[1]: Created symlink '/etc/systemd/system/multi-user.target.wants/systemd-oomd.service' → '/usr/lib/systemd/system/systemd-oomd.service'.
Apr 19 14:17:57 fedora systemd[1]: Created symlink '/etc/systemd/system/sockets.target.wants/systemd-oomd.socket' → '/usr/lib/systemd/system/systemd-oomd.socket'.
Apr 19 14:17:57 fedora systemd[1]: Listening on systemd-oomd.socket - Userspace Out-Of-Memory (OOM) Killer Socket.
Apr 19 14:17:59 fedora systemd[1]: Starting systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer...

But that Change explicitly does not apply to Anaconda installs: Anaconda copies the pristine image to disk and commits a machine-id, so on the installed system’s first boot the first-boot path is skipped and preset-all never runs:

Apr 19 14:46:38 fedora systemd[1]: systemd-firstboot.service - First Boot Wizard was skipped because of an unmet condition check (ConditionFirstBoot=yes).
Apr 19 14:46:38 fedora systemd[1]: first-boot-complete.target - First Boot Complete was skipped because of an unmet condition check (ConditionFirstBoot=yes).

On that first boot, grep -c 'Created symlink' over the journal returns 0. So the live image relies on first-boot presets to enable these units, Anaconda assumes the image already has the right state, and the result falls between the two.

systemd-pstore.service shows the same disabled; preset: enabled state, so kernel crash dumps are not collected either. Some other units also differ from preset (sshd, systemd-networkd, systemd-timesyncd, systemd-homed), but those look like deliberate spin choices since NetworkManager and chronyd are active. oomd and pstore look unintentional.

Install details

  • Fedora 43 KDE live ISO (VARIANT_ID=kde), Anaconda 43.44-3.fc43
  • Installed 2026-04-19, since upgraded to Fedora 44 (systemd 259.7-1.fc44); the state persists through upgrades because dnf never re-runs presets for already-installed packages
  • Not reproducible in a VM by me at the moment, but easy to check on any existing KDE live install: systemctl is-enabled systemd-oomd returning disabled on a system where the admin never touched it means affected

Workaround

sudo systemctl enable --now systemd-oomd.socket systemd-oomd.service
sudo systemctl enable --now systemd-pstore.service

Questions

Is this known? And if it should go to Bugzilla, which component is the right one: the KDE live kickstart, Anaconda, or systemd? Happy to provide full logs.

4

You have a good analysis of the problem.

I see that my test f43 kde VM matches what you see.
But it looks like it was fixed for f44 as my test f44 kde VM has this fixed.

It might be worth logging a a bug with a view to how a system upgrade might have fixed the problem. See Making sure you're not a bot!

5

Thanks for testing, that is a really useful data point, and good news that the F44 media is fixed.

The catch is the existing installs: a release upgrade does not heal this. My laptop is direct evidence. It was installed from the F43 KDE ISO, has since been upgraded to F44 (systemd 259.7-1.fc44), and systemd-oomd was still disabled until I enabled it by hand yesterday. dnf only applies presets when a package is first installed, so systems installed from the F43 KDE media are likely still running without OOM protection today whether or not they have upgraded.

I will file the Bugzilla with two parts: the F43 media gap itself (fixed in F44 media per your VM test), and the question of whether an update can heal already-affected systems, since the fix that landed in the F44 images does nothing for them. The mechanics of that are probably best discussed on the bug.

One question before I file: which component would you put it against? The media-side fix happened somewhere between the F43 and F44 image builds, but an upgrade-path fix would have to land in a package scriptlet, so I am unsure whether anaconda, the KDE spin kickstart, or systemd packaging is the right home.

6

I’d file against systemd and let them reassign if that the wrong guess.