From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041012 Epiphany/1.4.4 Description of problem: This error pops up when FreeWnn is updating useradd: group wnn exists - if you want to add this user to that group, use -g. error: %pre(FreeWnn-1.10pl020-3.x86_64) scriptlet failed, exit status 9 error: install: %pre scriptlet failed (2), skipping FreeWnn-1.10pl020-3 Version-Release number of selected component (if applicable): 1:1.10pl020-3 How reproducible: Always Steps to Reproduce: 1. I have 1.11-42.1 installed 2. yum upgrade FreeWnn 3. error Additional info:
*** This bug has been marked as a duplicate of 132637 ***
Sorry that bug is for RHEL 3.
Tom, are you using NIS too? I really still don't understand how the system gets into a state where there is a local wnn group, but not a wnn user. And why this (only?) happens for wnn. Anyway for now I'll add a workaround to remove any stray wnn group in FreeWnn-1.10pl020-4.
Yeah, I am using NIS. And it is still failing on the latest package: groupdel: cannot remove user's primary group. useradd: group wnn exists - if you want to add this user to that group, use -g. error: %pre(FreeWnn-1.10pl020-4.x86_64) scriptlet failed, exit status 9 error: install: %pre scriptlet failed (2), skipping FreeWnn-1.10pl020-4
Ok, in FreeWnn-1.10pl020-5 the group (and user) are no longer removed before upgrading but modified instead to have id 49, etc. Does this work for you: if grep -q "^wnn:" /etc/group 2> /dev/null ; then /usr/sbin/groupmod -g 49 -n wnn wnn else /usr/sbin/groupadd -g 49 wnn fi if grep -q "^wnn:" /etc/passwd 2> /dev/null ; then /usr/sbin/usermod -s /sbin/nologin -c "GNU Mailing List Manager" -d /var/lib/wnn -u 49 -g 49 wnn else /usr/sbin/useradd -s /sbin/nologin -c "Wnn Input Server" -d /var/lib/wnn -u 49 -g 49 -M -r wnn fi ?
Actually this last %pre script seems to work. And I also have a theory what the issue actually might be (-: In NIS we do not have a group with a clashing name but we do have one with a clashing GID. Might this be the cause, that the client is not allowed to remove this NIS group? If so we maybe just can consider the system to be misconfigured and close the bug...
doh! [tduffy@duffman ~]$ ypcat group | grep :49: insight:*:49: Is there an rule that NIS should not define groups in a certain range? BTW, having the package fail to upgrade is bad, maybe putting an || true after would be better.
David, this was also my feeling that this is probably so kind of interoperability problem... So FreeWnn-1.10pl020-5 works for you? Tom, is -5 any better for you? Yes, I suppose adding a || for good measure can't do any harm. :)
Yeah, -5 installs now on my setup. Thanks, -tduffy
Yes, -5 works for me as well.. Though do note that this is on RHEL3, so I would appreciate this script to be included in the next errata there as well.