Thomas Schmidt wrote:
> Hi Eric,
>
> first thanks for the fast response.
Welcome (just don't count on it!).
> ls -l shows the same result as yours (-rwxr-xr-x 2 root root 19628 13. Aug
> 2006 /opt/qtp-sandbox/usr/bin/id).
Ok, so the id program appears to be ok.
> I have chrooted to /opt/qtp-sandbox and executed the /usr/bin/id commands on
> the commandline.
Good.
> The check for groups (/usr/bin/id -g nofiles and /usr/bin/id -g qmail)
> returns the error "no such user". The check for users (/usr/bin/id -u alias)
> returns the userid for the user.
Interesting. Somehow these groups got hosed on your system.
> So the script will try to create the groups nofiles and qmail but they
> already exist. To check this I have created a bash script with the complete
> if-commands and executed it in the chroot. It says the groups nofiles and
> qmail does already exist, as expected. If I understand the id command right,
> with the -g option, it will return the group id of the given username. It
> will not check if a group exist.
You're right on, Thomas. When I check my toaster, there is no *user* qmail
or nofiles, so of course the id command fails. This isn't right. The id
command can't be used to check if a group exists or not, at least not
according to the man page for CentOS4.4. In any case, the -z test would
always be true, in which case the groupadd command(s) would always be
executed. This isn't right, but it's apparently not harmful. This is
confirmed by the:
groupadd: group nofiles exists
groupadd: group qmail exists
messages I now see in my build log.
So the group check isn't quite right. It shouldn't be causing your failure
though, I wouldn't think. On the other hand, you didn't receive the groupadd
errors I see (and you apparently did too in your script), and since that's
the first thing done in the %pre process, this leads me to believe that, for
whatever reason, this is what's choking on your system. Strange, because I'm
running CentOS4.4 too (upgraded from 4.3 though).
I any case, let's fix up the tests for the existence of groups, and see if
that doesn't work for you. I don't see a command that can be used to check
for groups, so let's use grep. In the spec file, we need to change:
if [ -z "`/usr/bin/id -g nofiles 2>/dev/null`" ]; then
to
if [ -z "`grep '^nofiles:.*:2107:' /etc/group`" ]; then
and likewise, change
if [ -z "`/usr/bin/id -g qmail 2>/dev/null`" ]; then
to
if [ -z "`grep '^qmail:.*:2108:' /etc/group`" ]; then
Be careful with those quotes! ;)
Then build yourself another source rpm (rpmbuild -bs), and try again. If you
put your modified source rpm in /opt/qtp-sandbox/usr/src/qtp-upgrade/SRPMS/
and remove the binary RPM from /opt/qtp-sandbox/usr/src/redhat/RPMS/i686/,
you can simply rerun qtp-newmodel (w/out rebuilding the sandbox) and it'll
pick up the new srpm and rebuild the binary. If you want to rebuild the
sandbox, put your new source rpm in /usr/src/qtp-upgrade/SRPMS/.
Let us know if this fixes your problem or not. This bug should have a
flyspray task for it if it doesn't already. Can you take care of that,
Thomas? (After all, you discovered it!)
--
-Eric 'shubes'
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
