Bug 136551 - FreeWnn fails to upgrade with error in scriptlet
FreeWnn fails to upgrade with error in scriptlet
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: FreeWnn (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Lawrence Lim
:
Depends On:
Blocks: FC3Blocker
  Show dependency treegraph
 
Reported: 2004-10-20 17:12 EDT by Tom Duffy
Modified: 2014-03-25 20:51 EDT (History)
3 users (show)

See Also:
Fixed In Version: 1.10pl020-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-19 02:56:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tom Duffy 2004-10-20 17:12:56 EDT
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:
Comment 1 Jens Petersen 2004-10-24 08:25:27 EDT

*** This bug has been marked as a duplicate of 132637 ***
Comment 2 Jens Petersen 2004-10-24 08:27:05 EDT
Sorry that bug is for RHEL 3.
Comment 3 Jens Petersen 2004-10-27 09:22:42 EDT
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.
Comment 4 Tom Duffy 2004-10-28 13:35:42 EDT
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
Comment 5 Jens Petersen 2004-10-28 23:18:38 EDT
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

?
Comment 6 David Juran 2004-10-29 11:44:52 EDT
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... 
Comment 7 Tom Duffy 2004-10-29 12:55:39 EDT
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.
Comment 8 Jens Petersen 2004-11-01 06:23:00 EST
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. :)
Comment 9 Tom Duffy 2004-11-01 11:48:11 EST
Yeah, -5 installs now on my setup.

Thanks,

-tduffy
Comment 10 David Juran 2004-11-01 12:38:25 EST
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.

Note You need to log in before you can comment on or make changes to this bug.