[OE-core] useradd.bbclass question

[Mark Hatle]

On 5/2/13 10:18 AM, Andreas Müller wrote:
> On Thu, May 2, 2013 at 5:09 PM, Mark Hatle <mark.hatle at 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.hatle at 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.

Hmm.. are either of the hosts 32-bit/64-bit multilib installs?  If so, you need 
to ensure that pseudo is enabled to build both a 32-bit and 64-bit wrapper, 
otherwise you can end up running native software that won't be wrapper properly. 
  (It's fairly rare, but can occur.)

--Mark

> Andreas
>