On Thu, May 2, 2013 at 5:09 PM, Mark Hatle <mark.ha...@windriver.com> wrote:
> 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.
These are OK and as mentioned above (cleansstate/rebuild) definitely
prepared before do_install.
>
> 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.
>
I will check that - still strange to me is that I have different
behaviour for two hosts - both with gdm user/group.
Andreas
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
