Description of problem: When trying to update fedora 35 system. Recent update of MATE desktop seems to have a conflict with systemd-oomd-defaults package. Version-Release number of selected component (if applicable): mate-desktop-configs-1.26.0-4.fc35.noarch How reproducible: Steps to Reproduce: 1. Try to update system with mate-desktop via "dnf update" 2. Notice there is a conflict. 3. adding "--best --allowerasing" wants to remove systemd-oomd-defaults. Which seems unsafe. Actual results: [root@computron2 ~]# dnf update Last metadata expiration check: 3:18:23 ago on Sat 23 Apr 2022 10:12:19 AM EDT. Dependencies resolved. Problem 1: package mate-desktop-configs-1.26.0-4.fc35.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-249.11-1.fc35.noarch - cannot install the best update candidate for package systemd-oomd-defaults-249.11-1.fc35.noarch - cannot install the best update candidate for package mate-desktop-configs-1.26.0-2.fc35.noarch Problem 2: problem with installed package systemd-oomd-defaults-249.11-1.fc35.noarch - package mate-desktop-configs-1.26.0-4.fc35.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-249.11-1.fc35.noarch - package mate-desktop-1.26.0-4.fc35.x86_64 requires mate-desktop-configs = 1.26.0-4.fc35, but none of the providers can be installed - cannot install the best update candidate for package mate-desktop-1.26.0-2.fc35.x86_64 ================================================================================ Package Arch Version Repository Size ================================================================================ Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): mate-desktop-configs noarch 1.26.0-4.fc35 updates 11 k Skipping packages with broken dependencies: mate-desktop x86_64 1.26.0-4.fc35 updates 82 k Expected results: Packge would update without conflicts. Additional info:
See https://bugzilla.redhat.com/show_bug.cgi?id=2068699 and https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Should_spins_that_don.27t_put_processes_in_separate_cgroups_be_excluded_from_this_change.3F and https://bugzilla.redhat.com/show_bug.cgi?id=1933494 for more infos. Using systemd-oomd is dangerous for mate-desktop because it can kill the whole X-session because of missing cgroups support. When system runs out of memory X-session will be kiiled by systemd-oomd, reported by a users in reports. Mate desktop will step back to original `earlyoom` memory management implementation, which was used before f34 in fedora. So removing systemd-oomd-defaults will simply disable systemd-oomd unit, and earlyoom service will be installed by the update and is enabled by default. I've tested the update process several times and it works smoothly. Maybe a restart is needed..... Don't worry, everything works as expected and like it should. Sorry, there was no other way to revert systemd changes for f34. I will leave this report open to inform other users.
Thanks so much for thed updated info!
Problem exists on F36 as well.
Again, please read previous postings. There is no problem. Mate desktop use earlyoom.
Link to the confirmed issue with MATE desktop: https://github.com/mate-desktop/mate-desktop/issues/519
(In reply to Wolfgang Ulbrich from comment #4) > Again, please read previous postings. > There is no problem. > Mate desktop use earlyoom. OK, well, after installing earlyoom, the command "dnf groupinstall mate-desktop-environment" STILL wants to install systemd-oomd-defaults and downgrade mate-desktop, mate-desktop-configs and mate-desktop-libs from 1.26.0-5.fc36 to 1.26.0-3.fc36. It's impossible to simultaneously have the mate-desktop-environment group fully installed (including systemd-oomd-defaults) AND have the latest version of all packages.
Can the mate-desktop-environment group be redefined so as to pull in earlyoom instead of systemd-oomd-defaults?
(In reply to Andre Robatino from comment #7) > Can the mate-desktop-environment group be redefined so as to pull in > earlyoom instead of systemd-oomd-defaults? Thanks for reporting this. I never put systemd-oomd-defaults to mate-desktop-environment group for myself. I will investigate.
*** Bug 2082901 has been marked as a duplicate of this bug. ***
I should mention that I periodically rerun the groupinstall command for all installed groups, since the group definitions can change. I don't remember exactly what happened, but I may have initially had earlyoom automatically installed, then after updating and running the groupinstall command again, noticed the conflict. Most people will only run the groupinstall command once and may not notice it.
systemd-oomd-defaults is in core comps group, ihmo systemd maintainer needs to change that. https://pagure.io/fedora-comps/blob/main/f/comps-f36.xml.in#_640 But i posted it already in another report. https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c38 Maybe a serparate report against systemd helps?
(In reply to Wolfgang Ulbrich from comment #11) > systemd-oomd-defaults is in core comps group, ihmo systemd maintainer needs > to change that. > https://pagure.io/fedora-comps/blob/main/f/comps-f36.xml.in#_640 > But i posted it already in another report. > https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c38 > Maybe a serparate report against systemd helps? Comps is unfortunately maintained separately. Please open an issue (or a pull request) under the comps repo. I don't know how to make this work. The docs say: > 'optional' are not automatic but can be checked > 'default' are, but can be unchecked in a gui tool It seems 'default' is too much, but 'optional' not enough. So maybe it'd be necessary to move 'systemd-oomd-defaults' out of @core into other top-level groups.
@Andre Robatino Can you please file out another report against comps package group? To get responsible maintainers involved. And link it here. (In reply to Zbigniew Jędrzejewski-Szmek from comment #12) > (In reply to Wolfgang Ulbrich from comment #11) > > I don't know how to make this work. The docs say: > > 'optional' are not automatic but can be checked > > 'default' are, but can be unchecked in a gui tool > > It seems 'default' is too much, but 'optional' not enough. So maybe it'd be > necessary to move 'systemd-oomd-defaults' > out of @core into other top-level groups. Where can i find the docs about comps features?
(In reply to Wolfgang Ulbrich from comment #13) > @Andre Robatino > Can you please file out another report against comps package group? > To get responsible maintainers involved. > And link it here. I'm sorry, I don't know how or where to do that. In https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c38 you were able to exactly reproduce what I see, and you obviously understand it better.
https://pagure.io/fedora-comps/issues
(In reply to Andre Robatino from comment #14) > (In reply to Wolfgang Ulbrich from comment #13) > > @Andre Robatino > > Can you please file out another report against comps package group? > > To get responsible maintainers involved. > > And link it here. > > I'm sorry, I don't know how or where to do that. In > https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c38 you were able to > exactly reproduce what I see, and you obviously understand it better. You're using an email from fedoraproject.org and don't know to file out a new bugreport? I am so sorry too, i am complete bussy with work, i do not have the time to do this very small work for you. I mean you're are the person you like to do the groupinstall command very often.....
Ok, reassign this report to comps to fixing the remaining issue. Dear, comps maintainer currently the groupinstall command generates a conflict betweeen mate-desktop-configs and systemd-oomd-defaults ``` [root@f36 rave]# dnf groupinstall mate-desktop-environment --disablerepo results Last metadata expiration check: 0:16:37 ago on Mon May 9 20:53:45 2022. No match for group package "xorg-x11-drv-armsoc" Dependencies resolved. Problem: package mate-desktop-1.26.0-5.fc36.x86_64 requires mate-desktop-configs = 1.26.0-5.fc36, but none of the providers can be installed - package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.3-8.fc36.noarch - cannot install the best candidate for the job - conflicting requests ================================================================================ Package Arch Version Repository Size ================================================================================ Installing group/module packages: systemd-oomd-defaults noarch 250.3-8.fc36 fedora 27 k Downgrading: mate-desktop x86_64 1.26.0-3.fc36 fedora 82 k mate-desktop-configs noarch 1.26.0-3.fc36 fedora 10 k mate-desktop-libs x86_64 1.26.0-3.fc36 fedora 644 k Installing Environment Groups: MATE Desktop Installing Groups: Administration Tools base-x Core Dial-up Networking Support Fonts Guest Desktop Agents Hardware Support Input Methods MATE Multimedia Common NetworkManager Submodules Printing Support Standard Transaction Summary ================================================================================ Install 1 Package Downgrade 3 Packages ``` This is because systemd-oomd-defaults is in comps core group marked as default. ``` <group> <id>core</id> <_name>Core</_name> <_description>Smallest possible installation</_description> <default>false</default> <uservisible>false</uservisible> <packagelist> <packagereq type="mandatory">audit</packagereq> <packagereq type="mandatory">basesystem</packagereq> <cut> <packagereq type="default">systemd-oomd-defaults</packagereq> <cut> </packagelist> </group> ``` What can i do to fix the problem? IHMO systemd-oomd-defaults should be optional in comps core group or moved to another group, otherwise the option in wiki page for not using systemd-oomd for spins doesn`t work. https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Should_spins_that_don.27t_put_processes_in_separate_cgroups_be_excluded_from_this_change.3F
https://pagure.io/fedora-comps/issue/737
Fixed in https://pagure.io/fedora-comps/pull-request/750
This does not seem to be fixed. I am trying this on a freshly-upgraded F35->F36 system that doesn't have MATE and still getting the conflict error: sudo dnf groupinstall "MATE Desktop" --best --allowerasing Last metadata expiration check: 1:32:48 ago on Sat 17 Dec 2022 04:34:04 PM PST. No match for group package "xorg-x11-drv-armsoc" Error: Problem: package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.8-1.fc36.noarch - package mate-desktop-1.26.0-5.fc36.x86_64 requires mate-desktop-configs = 1.26.0-5.fc36, but none of the providers can be installed - cannot install the best candidate for the job (try to add '--skip-broken' to skip uninstallable packages) I have another F35 system that already has MATE Desktop installed and I can't find a clean path to upgrade: sudo dnf system-upgrade download --releasever=36 . . . Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): mate-desktop-configs noarch 1.26.0-5.fc36 updates 11 k sudo dnf system-upgrade download --releasever=36 --best --allowerasing . . . Error: Problem 1: cannot install the best update candidate for package mate-desktop-configs-1.26.0-4.fc35.noarch - problem with installed package mate-desktop-configs-1.26.0-4.fc35.noarch - package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.8-1.fc36.noarch - cannot install the best candidate for the job - mate-desktop-configs-1.26.0-4.fc35.noarch does not belong to a distupgrade repository Problem 2: cannot install the best update candidate for package imsettings-gsettings-1.8.3-1.fc35.x86_64 - problem with installed package imsettings-gsettings-1.8.3-1.fc35.x86_64 - package imsettings-gsettings-1.8.3-6.fc36.x86_64 obsoletes imsettings-systemd < 1.8.3-6 provided by imsettings-systemd-1.8.3-2.fc36.x86_64 - cannot install the best update candidate for package imsettings-systemd-1.8.3-1.fc35.x86_64 - problem with installed package imsettings-systemd-1.8.3-1.fc35.x86_64 - imsettings-systemd-1.8.3-1.fc35.x86_64 does not belong to a distupgrade repository - imsettings-gsettings-1.8.3-1.fc35.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages)
Confirmed still broken in F36 and F37: Problem 1: package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.8-1.fc36.noarch - cannot install the best update candidate for package systemd-oomd-defaults-250.8-1.fc36.noarch - cannot install the best update candidate for package mate-desktop-configs-1.26.0-3.fc36.noarch Problem 2: problem with installed package systemd-oomd-defaults-250.8-1.fc36.noarch - package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.8-1.fc36.noarch - package mate-desktop-1.26.0-5.fc36.x86_64 requires mate-desktop-configs = 1.26.0-5.fc36, but none of the providers can be installed - cannot install the best update candidate for package mate-desktop-1.26.0-3.fc36.x86_64 ================================================================================================================================================================================== Package Architecture Version Repository Size ================================================================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): mate-desktop-configs noarch 1.26.0-5.fc36 updates 11 k Skipping packages with broken dependencies: mate-desktop x86_64 1.26.0-5.fc36 updates 82 k Transaction Summary ================================================================================================================================================================================== Skip 2 Packages
The conflict with systemd-oom-defaults should likely just be removed. mate-desktop-configs does not be marked as directly conflicting with systemd-oom-defaults. One can used mate-desktop with systemd-oom or with earlyoom, or for that matter, no out-of-memory manager at all. And that's just the run-time decision. Whether either or both systemd-oom (and systemd-oom-defaults) and earlyoom packages are installed together also is not a problem by itself. A system owner may choose to decide to run systemd-oom or earlyoom and may change that choice at any time as desired for particular situations. I have read the various comments about experiences with systemd-oom killing more than it really needs to perhaps - entire desktop sessions (or tmux sessions) instead of killing whatever memory hog with finer granularity. The desire to have improved out-of-memory handling is understandable. And when MATE grows cgroup support, it may be a better experience with systemd-oom on the occasion that memory pressure necessitates OOM manager to take action. But for one thing, it should be rare that OOM is needed - it should be the infrequent exception that a particular system is hitting OOM events regularly (if not it's a system configuration problem in most cases - or possibly a software bug with runaway memory consumption). Examples of some reports of the problem: https://bugzilla.redhat.com/show_bug.cgi?id=1933494#c22, https://www.reddit.com/r/Fedora/comments/u9xb1s/issue_having_matedesktop_conflicts_with/. It's up to the system owner whether they choose to use systemd-oom or earlyoom or neither. And they may have very good reasons for choosing one of those options. It should not be up to the mate-desktop-configs package to dictate that choice. A recommendation is fine - as in the 'Recommends: earlyoom' clause currently in mate-desktop.spec. That recommendation makes sense at this time - until such time as MATE adds cgroup support to play better with systemd-oom. But marking the systemd-oomd as a package installation conflict is the wrong scope for handling any issues with dueling OOM managers. It just causes headaches and confusion for unsuspecting users who want to update their systems - and possibly results in decisions that should not be necessary, such as deleting MATE because of the headaches. See the proposed pull request: https://src.fedoraproject.org/rpms/mate-desktop/pull-request/2
Changes to comps groups are only working for new released fedora versions started with rawhide. So you will never see that change in f36. After moving systemd-oom-defaults to supporting c-groups environments in comps with that commit https://pagure.io/fedora-comps/c/01ba068318ee0bd4f0cc5f5bff4f23c15cf95fd9?branch=main the situation is different. But i agree to remove the conflict marker from spec file for f37/38 and rawhide. See this PR https://src.fedoraproject.org/rpms/mate-desktop/pull-request/2# Now it's sure that a new MATE standard default installation comes without systemd-oom-defaults.
(In reply to Wolfgang Ulbrich from comment #23) > Changes to comps groups are only working for new released fedora versions > started with rawhide. > So you will never see that change in f36. I understand your remark. I actually bumped into the dnf update problem (most recently) while belatedly updating an old f33 host to f34 (which from there will update to newer versions as local conditions dictate). I know that an old problem going from f33 -> f34 is outside the scope of support, so I'm not too concerned about that. The pull request is for newer supported fedora versions that can still potentially hit the dnf conflict. > After moving systemd-oom-defaults to supporting c-groups environments in > comps with that commit > https://pagure.io/fedora-comps/c/ > 01ba068318ee0bd4f0cc5f5bff4f23c15cf95fd9?branch=main the situation is > different. > But i agree to remove the conflict marker from spec file for f37/38 and > rawhide. See this PR > https://src.fedoraproject.org/rpms/mate-desktop/pull-request/2# > Now it's sure that a new MATE standard default installation comes without > systemd-oom-defaults. One problem is that there exist systems in the world that are more than just a "MATE standard default install". We have systems where some users will use MATE, others might use XFCE or GNOME, etc., sometimes concurrently. So moving systemd-oom-defaults out of the core comps group may not help avoid the dnf failure since dnf installing other desktop environment groups can still pull in systemd-oom-defaults. Thanks for considering the removal of the conflict marker. MATE just seems like the wrong scope in which to adjudicate OOM manager choices.
FEDORA-2023-2a193c0384 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-2a193c0384
FEDORA-2023-2a193c0384 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-2a193c0384 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-82251ee7c9 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-82251ee7c9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-82251ee7c9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-82251ee7c9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-82251ee7c9
FEDORA-2023-82251ee7c9 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
I am thinking about to change `Recommends: earlyoom` to `Recommends: systemd-oomd-defaults` for f40, to get closer to common fedora. In the end only one user was affected by this issue and more users was to use systemd-oomd-defaults. And it is possible to uninstall systemd-oomd-defaults after it was removed from core group.
(In reply to Wolfgang Ulbrich from comment #31) > In the end only one user was affected by this issue and more users was to > use systemd-oomd-defaults. It's not clear where that comment (only one user) comes from. Just in this thread, more than one user spoke up who was affected. As far as I can tell, MATE has not added cgroup support yet (although I may have missed it).
(In reply to John Hein from comment #32) > (In reply to Wolfgang Ulbrich from comment #31) > > In the end only one user was affected by this issue and more users was to > > use systemd-oomd-defaults. > > It's not clear where that comment (only one user) comes from. Just in this > thread, more than one user spoke up who was affected. > > As far as I can tell, MATE has not added cgroup support yet (although I may > have missed it). Please read careful posts. In this report users like you complains only about the previous package conflict issues when updating. In the other origin linked report only the reporter was affected.