Hello. I am cloning this bug as it still exists. Please let me know if this is the appropriate way to update existing bugs which have been closed due to a patch window. +++ This bug was initially created as a clone of Bug #1198660 +++ Description of problem: Had three environment groups istalled: Fedora Workstation, LXDE Desktop and MATE Desktop. Decided I didn't like MATE, so wanted to remove the latest tried group "MATE Desktop". dnf group remove "MATE Desktop" dnf removed lots of packages which belong essentially to "Fedora Workstation" and "LXDE Desktop" groups. System came unusable. Only way to fix it was to ssh in from a tablet and do manual install of all essential packages "Fedora Workstation" group and its subgroups have. Version-Release number of selected component (if applicable): dnf-0.6.4-1.fc21.noarch How reproducible: Assumely always. Steps to Reproduce: 1. # dnf -y group install "MATE Desktop" 2. # dnf -y group remove "MATE Desktop" Actual results: Removes all packages belonging to said group, not caring if they are essential on some other groups which stay installed. Expected results: Should remove only those rpm-packages not needed in some other groups. Additional info: Also if trying to re-install some group, dnf behaves weirdly: # dnf group list Using metadata from Tue Mar 3 16:16:12 2015 Available environment groups: Fedora Server Fedora Cloud Server ... Installed environment groups: Fedora Workstation LXDE Desktop Installed groups: Administration Tools C Development Tools and Libraries Fedora Eclipse LibreOffice Available groups: 3D Printing Audio Production ... # # dnf group install "LXDE Desktop" Using metadata from Tue Mar 3 16:16:12 2015 Warning: Group 'LXDE Desktop' does not exist. Dependencies resolved. Is this ok [y/N]: y Complete! It doesn't find group "LXDE Desktop"?! It could of course tell, you have already installed group "LXDE Desktop". And there could be "group reinstall" subcommand in dnf also just in these cases, but the "dnf group remove" command currently can break the OS totally. See also: http://forums.fedoraforum.org/showthread.php?t=303291 From /var/log/dnf.rpm.log I can see specific rpm-packages it installed and removed, if needed, but it is obvious "dnf group remove" just didn't look at all what other installed groups need. --- Additional comment from Honza Silhan on 2015-03-17 06:13:39 EDT --- Thanks for the report, during removal of the group it should remove all mandatory packages from all groups installed. --- Additional comment from Fedora End Of Life on 2015-11-04 10:21:34 EST --- This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. --- Additional comment from Fedora End Of Life on 2015-12-02 04:44:01 EST --- Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I investigate the issue and I believe that the problem is that "Fedora Workstation" group was not marked as installed. To see installed group just run "dnf group list". It could be solved using command 'dnf group install "Fedora Workstation"' or 'dnf group mark install "Fedora Workstation"'. Please could you verify my suggestion?
The issue must be resolved by delivery athe new installed system with marked environmental group like Fedora workstation as installed. According to discussion with Anaconda group the issue in data that are passed to installer. I believe that responsible component is comps.
Proposed as a Blocker for 31-beta by Fedora user jmracek using the blocker tracking app because: The problem experience every user that alternatively installs an environment group that later on is remove. Due to missing information about installed original environmental group, nothing from original environmental group is protected from removal (even group core can be removed).
(In reply to Jaroslav Mracek from comment #1) > I investigate the issue and I believe that the problem is that "Fedora > Workstation" group was not marked as installed. To see installed group just > run "dnf group list". It could be solved using command 'dnf group install > "Fedora Workstation"' or 'dnf group mark install "Fedora Workstation"'. > Please could you verify my suggestion? I am not quite sure, if the machine/host I am now repoting about is the same where originally I found the bug which made system broken with "dnf group remove MATE Desktop". However, fresh install has been done back in F26 or something. The machine doesn't show "Fedora Workstation" environment group would be installed, but shows "GNOME Desktop Environment" is installed. (Also another newer host, which has had F27, F28, F30 does not show "Fedora Workstation" would be installed, although I assume I am using just that and originally installed it.) dnf program doesn't show anymore "Installed environment groups:" where before were those installed "LXDE Desktop" and "MATE Desktop" systems shown in the listing. Maybe because it thinks no environment groups are installed. I have been upgrading this machine from since fc26 and it is currently running Fedora 30 I am currently happy with configuration, installed software. Can use GNOME, Firefox, Thunderbird, Eclipse, Me-TV, ... ; don't feel like or haven't noticed missing anything. # rpm -qa | wc 2999 2999 107137 # rpm -qa "*release*" fedora-release-common-30-4.noarch rpmfusion-free-release-30-1.noarch fedora-release-workstation-30-4.noarch rpmfusion-nonfree-release-30-1.noarch # dnf group list Last metadata expiration check: 0:11:25 ago on Thu 27 Jun 2019 02:17:55 PM EEST. Available Environment Groups: ... Fedora Workstation ... Installed Groups: C Development Tools and Libraries Development Tools LibreOffice GNOME Desktop Environment Fonts Hardware Support Available Groups: ... ... If I would now install group "Fedora Workstation", it would install these: # dnf group install "Fedora Workstation" --skip-broken Last metadata expiration check: 0:18:34 ago on Thu 27 Jun 2019 02:17:55 PM EEST. No match for group package "libva-vaapi-driver" No match for group package "xorg-x11-drv-omap" No match for group package "totem-nautilus" No match for group package "xorg-x11-drv-armsoc" No match for group package "powerpc-utils" No match for group package "lsvpd" Dependencies resolved. Problem: problem with installed package fedora-chromium-config-1.1-2.fc30.noarch - installed package fedora-chromium-config-1.1-2.fc30.noarch obsoletes fedora-user-agent-chrome < 0.0.0.5 provided by fedora-user-agent-chrome-0.0.0.4-6.fc30.noarch - package fedora-chromium-config-1.1-2.fc30.noarch obsoletes fedora-user-agent-chrome < 0.0.0.5 provided by fedora-user-agent-chrome-0.0.0.4-6.fc30.noarch - conflicting requests ================================================================================ Package Arch Version Repo Size ================================================================================ Installing group/module packages: NetworkManager-ppp x86_64 1:1.16.2-1.fc30 updates 33 k google-noto-sans-cjk-ttc-fonts noarch 20190416-2.fc30 updates 85 M google-noto-serif-cjk-ttc-fonts noarch 20190416-2.fc30 updates 109 M podman x86_64 2:1.4.2-1.fc30 updates 11 M virtualbox-guest-additions x86_64 6.0.8-2.fc30 updates 1.3 M gamemode x86_64 1.2-4.fc30 fedora 38 k gnome-photos x86_64 3.32.0-1.fc30 fedora 762 k gstreamer1-plugins-bad-freeworld x86_64 1.16.0-1.fc30 rpmfusion-free-updates 192 k Installing dependencies: containernetworking-plugins x86_64 0.7.5-1.fc30 updates 14 M containers-common x86_64 1:0.1.37-0.gite079f9d.fc30 updates 47 k google-noto-cjk-fonts-common noarch 20190416-2.fc30 updates 19 k intel-gmmlib x86_64 19.1.2-1.fc30 updates 102 k runc x86_64 2:1.0.0-93.dev.gitb9b6cc6.fc30 updates 2.5 M dleyna-renderer x86_64 0.6.0-4.fc30 fedora 56 k libbsd x86_64 0.9.1-3.fc30 fedora 100 k libnet x86_64 1.1.6-17.fc30 fedora 61 k gstreamer-ffmpeg x86_64 0.10.13-21.fc30 rpmfusion-free 2.8 M libde265 x86_64 1.0.3-4.fc30 rpmfusion-free 309 k intel-media-driver x86_64 19.1-2.fc30 rpmfusion-nonfree-updates 4.3 M Installing weak dependencies: container-selinux noarch 2:2.106-1.gitfc7111d.fc30 updates 47 k criu x86_64 3.12-11.fc30 updates 476 k fuse-overlayfs x86_64 0.3-10.dev.gita7c8295.fc30 updates 50 k libvarlink-util x86_64 18-1.fc30 updates 47 k podman-manpages noarch 2:1.4.2-1.fc30 updates 174 k slirp4netns x86_64 0.3.0-2.git4992082.fc30 updates 82 k Installing Environment Groups: Fedora Workstation Installing Groups: base-x Container Management Core Firefox Web Browser Fonts GNOME Desktop Environment Guest Desktop Agents Hardware Support LibreOffice Multimedia Common NetworkManager Submodules Printing Support Fedora Workstation product core Transaction Summary ================================================================================ Install 25 Packages Total download size: 232 M Installed size: 458 M Is this ok [y/N]: n Operation aborted. And as suggested, with mark group install: # dnf group mark install "Fedora Workstation" Last metadata expiration check: 0:47:48 ago on Thu 27 Jun 2019 02:17:55 PM EEST. Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Installing Environment Groups: Fedora Workstation Installing Groups: base-x Container Management Core Firefox Web Browser Fonts GNOME Desktop Environment Guest Desktop Agents Hardware Support LibreOffice Multimedia Common NetworkManager Submodules Printing Support Fedora Workstation product core Transaction Summary ================================================================================ Is this ok [y/N]: n Operation aborted. I do not want to commit those right now, afraid something would go broken. And anyway, then still would need to do those ie. 'group install "MATE Desktop"' and 'group remove "MATE Desktop"' to know if it fixed the problem
So I've been looking into how we handle this in Anaconda a bit. I've started a graphical Rawhide network installation, went to the software spoke and selected the xfce desktop from the environment on the left and xfce office from the group list on the rigth. Then I have started the installation. Checking the logs (/tmp/packaging.log) this is what ends up in the transaction include list we send to DNF via the install_specs() method of Base: ['@core','@xfce-desktop-environment','@xfce-office','kernel','e2fsprogs','grub2','lvm2','chrony','grub2-tools','authselect','langpacks-en'] The @core groups & all the packages (the strings without @) are added automatically by Anaconda by for every installation. That leaves us with: @xfce-office - which corresponds to the xfce office group I have selected in the GUI @xfce-desktop-environment - which seems to match the environment I have selected, but is just a regular group (?) I've looked how it gets there and Anaconda simply takes the environment name, puts a @ in front and adds it to the transaction include list: https://github.com/rhinstaller/anaconda/blob/be86b849d46aef72a29acb50b7cbe8533a71de52/pyanaconda/payload/dnfpayload.py#L499 Then I've waited for the installation to finish, rebooted the machine, logged in and run "dnf group list". There is: Installed Environment Groups: Xfce Desktop So I guess things already work as expected, at least in this case ? BTW, other things might be broken, as: Installed Groups: Administration tools And that's it - Xfce Office is nowhere to be found, even in the Available Groups list. :)
For fresh installation of Fedora 30 from iso dnf. It only marks as installed dnf group list Installed Groups: LibreOffice dnf group list --hidden Installed Groups: Anaconda tools base-x Core Firefox Web Browser Fonts GNOME Guest Desktop Agents Hardware Support LibreOffice Multimedia Common NetworkManager Submodules Printing Support Fedora Workstation product core In both case no environmental group installed.
It looks like that the issue in live media, therefore changing the component. The solution will be to add environmental group to each set for particular media. Like for: Fedora Workstation just add @workstation-product-environment KDE Plasma Workspaces just add @kde-desktop-environment ...
I am not sure that solution is going to work without a lot of churn. Basically the environment and kickstarts are different. In some cases thats because the kickstart wanted to be smaller, so not installing everything that the comps group has, in other cases it's just divergence as something was added to one and not the other. It would probibly be best if the comps was up to date with what people wanted and the kickstarts just used that, but thats going to take some carefull tweaking and testing by each group. Adding AdamW here for his thoughts from QA.
I believe to make installation of environmental group small is still possible, just set group or packages as excluded. According to my simple test, the difference between live deployment of Fedora workstation and Fedora Workstation Env. group is only podman and its dependencies. The usage of excludes in kikstatart set would be the first approach how to delivery it. The second could be to add possibility to mark group or env. group as an installed. This will be less transparent approach but possible (requires new functionality in kikstart, anaconda, dnf).
While I think this is a very interesting and complex bug, I don't think software *removal* is covered by our release criteria (nor do I think it should be). I'm -1 to block on this.
Discussed during the 2019-07-15 blocker review meeting: [1] The decision to classify this bug as a "RejectedBlocker" was made as this is established behaviour and we don't believe it violates any of the criteria as it stands. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-07-15/f31-blocker-review.2019-07-15-16.05.txt
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.