Opened 5 years ago
Last modified 2 years ago
Reported by: jengelh Assigned to: pmatilai
Priority: major Milestone:
Component: rpm Version: RPM Development
Keywords: Cc:
Installation with rpm --root yields:
/srv/nfs/base32# linux32 rpm --root $PWD -Uhv cups-client-1.3.11-4.5.1.i586.rpm Preparing... ########################################### [100%]
1:cups-client warning: user lp does not exist - using root( 26%)
warning: group lp does not exist - using root ########################################### [100%]
And that despite lp existing in both /etc/{passwd,group} and /srv/nfs/base32/etc/{passwd,group}. Looks non-trivial. Any idea what could be done?
strace.log (139.0 kB) - added by jengelh on 05/18/10 12:33:21.
ts.spec (173 bytes)
Basically that means getpwnam() is failing for whatever reason. Rpm (tries to) preload nss libraries before chroot() to ensure working name services inside chroots but maybe there's a new catch here or something...
Try to get a strace log of the thing, that should provide some clues to what's going on.
It is reproducible using one's own system root itself, i.e.
rpm --root / -Uhv ts.rpm
FWIW I can't reproduce this. ts.spec does complain about user sys not existing but rightfully so as on Fedora there's no such user (only group called "sys"), and using other user/group names doesn't change the situation. Need to dig into the strace...
Looking at the strace log, this has to do with the host being configured to use LDAP for user information and the system not falling back to /etc/{passwd,group} when not found in LDAP.
This is likely to be the same issue as the one reported here: http://lists.rpm.org/pipermail/rpm-maint/2014-January/003652.html and should be fixed by this: https://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=abbf4897db217b4977b4c21eb09929c797ee015d