On 5/2/13 9:55 AM, Andreas Müller wrote:
On Thu, May 2, 2013 at 4:50 PM, Mark Hatle <mark.ha...@windriver.com> wrote:
On 5/2/13 9:34 AM, Paul Eggleton wrote:
On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
On 5/2/13 2:49 AM, Andreas Müller wrote:
on one of my build machines useradd.bbclass seem to use the UID/GID of
build host. On other machines useradd works correct.
I have the follwing in gdm:
<snip>
do_install_append() {
...
chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
chmod 0750 ${D}${localstatedir}/lib/gdm
}
...
USERADD_PACKAGES = "${PN}"
USERADD_PARAM_${PN} = "--system --no-create-home --home
${localstatedir}/lib/gdm --user-group gdm"
<snip/>
I don't know how ipk and deb handle this. But with the RPM system it
captures the uname/gname (not uid/gid) and uses that when installing the
file(s). This way the USERADD is processed before the install and the right
value is used during the install.
We may have a problem here where we need to also process the useradd
-before- the do_install runs so that it's available for pseudo to use for
deb/ipk. (But if deb/ipk capture uid/gid vs uname/gname.. unless we set a
static value we could still have a problem.)
1. gdm's log.do_install starts with so I assume the useradd stuff is
performed before do_install.
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
'common']
| DEBUG: Executing shell function useradd_sysroot
| Running useradd commands...
| DEBUG: Shell function useradd_sysroot finished
| DEBUG: Executing shell function do_install
Ahh yes, there it is.. I forgot as well.
ok, so the obvious problems are resolved. The only place I can suggest you
start looking would be in the sysroot's etc/passwd and etc/group files. If they
are not correct -- then this indicates a failure in the easy case and could lead
to incorrect values.
The other thing you can do is add debugging to your script and see what uid and
such it's looking for.. Dumping out the environment variables that start with
'PSEUDO_' may help. I believe the value is PSEUDO_PASSWD for the path. If it's
not set it falls back to the chroot (which you won't be in) and then back to the
system file --- so if PSEUDO_PASSWD isn't set this could be a clue as to the fault.
--Mark
2. I did a cleansstate + rebuild for gdm to ensure that user/groups
are in sysroot - but the same I get host's IDs
Andreas
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
