I wasn't quite sure which bit of this behaviour to identify as the bug, but I took a shot. Recently, a check was added to yum: http://yum.baseurl.org/gitweb?p=yum.git;a=commit;h=ff5416b1532fe43c68bf51ae30751504885a501a "Give same non-exist msg. for install @foo as group install foo. BZ 1018833." From the bug report and the log message, it reads like it was expected that this check would only be hit and the error message only displayed if the user ran something like: "yum install @non-existent-group" However, the check actually appears to be hit on other operations. It at least appears to happen on any 'yum upgrade' operation. I see it on my system: [root@adam yum]# yum upgrade Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit side | 2.9 kB 00:00 Warning: group cinnamon-desktop does not exist. No packages marked for update [root@adam yum]# I know it's hitting this particular check, because if I comment this specific check out of __init__.py (and none of the dozen or so similar checks in that file and cli.py...), then I no longer see it. Quite a lot of people have reported seeing these 'group foo does not exist' errors - for some people, quite a lot of them - since yum -120 went stable, and I'm pretty sure this is the culprit in a lot of the cases. But I think there are other bugs going on in the area of groups and group checks and groups-as-objects too, and I haven't really nailed 'em all down yet. The group that is identified as 'non-existent' for me, cinnamon-desktop, is listed in /var/lib/yum/groups/installed . Anyone who's had a Fedora system installed for a while will likely have groups listed in that file which no longer exist, as group names change in comps relatively often. There's another element in play here, too. My /var/lib/yum/groups/installed contains several other non-existent cinnamon 'groups': [adamw@adam comps (master %)]$ grep cinn /var/lib/yum/groups/installed cinnamon-desktop cinnamon cinnamon-control-center cinnamon-screensaver but I only get the error for 'cinnamon-desktop'. I think the difference is the 'cinnamon-desktop' group actually *does* exist, but is hidden. The other groups don't exist at all. So my best guess at characterising this issue is... Somehow, this check is run and fails for groups that: * are listed in /var/lib/yum/groups/installed * exist as normal (not environment) groups in comps, but have 'uservisible' set false when you run 'yum update'.
*** Bug 1039348 has been marked as a duplicate of this bug. ***
This bug affects both F19 and F20, as they both got the updated yum.
So some of my diagnosis is wrong - I was reading /var/lib/yum/groups/installed wrong. It's not a list of groups, one per line, it lists a group, then a count of packages installed that are associated with it, then the package names (more or less). I'm trying to figure out why the check actually fails for cinnamon-desktop on my system, and it seems rather odd. But I'll file a new bug for that to avoid confusing this one. It is definitely the case that the check is being hit on 'yum upgrade', when I don't think it was intended to.
I've filed #1043207 for the part of the bug you can describe as 'this check fails for a group that really does exist'.
As to why this code path is being hit when you do 'yum update'...well, the check is in the function _at_groupinstall in __init__.py . There is a large chunk of code at the top of the function install in the same file which I don't grok at all, but the comment above it is rather interesting: # This is kind of hacky, we really need a better way to do errors than # doing them directly from .install/etc. ... but this is easy. *sigh*. # We are only using this in "groupinstall" atm. ... so we don't have # a long list of "blah already installed." messages when people run # "groupinstall mygroup" in yum-cron etc. and that function is the only other place in all of yum where I see _at_groupinstall: if 'pattern' in kwargs: if kwargs['pattern'] and kwargs['pattern'][0] == '-': return self._minus_deselect(kwargs['pattern']) if kwargs['pattern'] and kwargs['pattern'][0] == '@': return self._at_groupinstall(kwargs['pattern']) I'm really not sure how the hell all of this works, but...that seems like it's possibly relevant. It may be that this part - this codepath being hit on running 'yum update' - is not actually a bug, and the only bug is #1043207 , which I'm pretty sure now is as simple as "yum install @installed-group claims installed-group does not exist".
I think the real bug here is https://bugzilla.redhat.com/show_bug.cgi?id=1043207 , "the check in _at_groupinstall is broken for installed groups", not this bug, "_at_groupinstall is being run on yum update". It kinda makes sense to call one of the 'group install' functions on "yum update", I presume that's how yum looks for new packages in installed groups and adds them. So I think I'll close this one.