Description of problem: Dnf has the following traceback when the comps file isn't quite right. [root@localhost ~]# dnf groupinstall basic-desktop-environment Last metadata expiration check: 1:44:13 ago on Fri 27 Jul 2018 03:39:28 AM EDT. Traceback (most recent call last): File "/usr/bin/dnf", line 58, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main errcode = main(args) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main return cli_run(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run cli.run() File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1041, in run return self.command.run() File "/usr/lib/python3.7/site-packages/dnf/cli/commands/group.py", line 423, in run self.base.conf.strict) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 1662, in env_group_install cnt += self.environment_install(env_id, types, strict=strict) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 1590, in environment_install strict) File "/usr/lib/python3.7/site-packages/dnf/comps.py", line 93, in install_or_skip return install_fnc(grp_or_env_id, types, exclude, strict) File "/usr/lib/python3.7/site-packages/dnf/comps.py", line 564, in _environment_install for comps_group in comps_env.optional_groups: File "/usr/lib/python3.7/site-packages/dnf/comps.py", line 262, in optional_groups return [self._build_group(gi) for gi in self.option_ids] File "/usr/lib/python3.7/site-packages/dnf/comps.py", line 262, in <listcomp> return [self._build_group(gi) for gi in self.option_ids] File "/usr/lib/python3.7/site-packages/dnf/comps.py", line 249, in _build_group raise ValueError(msg % (grp_id.name, self.id)) ValueError: no group 'hawaii-desktop' from environment 'basic-desktop-environment' [root@localhost ~]# Version-Release number of selected component (if applicable): dnf-3.0.4-1.fc29.noarch How reproducible: always Additional info: See https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/4GQ7UYUJRANWHSC4VDW33CA5VSG5D45O/ .
*** Bug 1609292 has been marked as a duplicate of this bug. ***
Note, I'd say there are/were three problems here. 1) The 'bad' entry in comps 2) dnf CLI not catching the exception and failing with a user-friendly error, but just crashing on the exception 3) dnf backend raising an exception at all, when the "missing" group is in <optionlist> We have fixed 1) already. This bug should be for 2). https://bugzilla.redhat.com/show_bug.cgi?id=1609292 is the bug for 3). So, the fix for this bug should be that - when the dnf backend *does* raise an exception like this - the CLI should catch it and error out more gracefully and in a more readable way, not just die on the exception.
Fixed by https://github.com/rpm-software-management/dnf/pull/1152
is *this* part of the bug really fixed by that? I'm thinking of the case where a *default* (not *optional*) group is missing from an environment group, as that case should still probably be a fatal error: would DNF CLI error out gracefully in that case, or would it just die on a traceback?
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
It looks like that the problem is fixed in dnf-4.0.9-1. Please if you can still reproduce it, don't hesitate to reopen the bug report.