Re: useradd.bbclass question

[Mark Hatle <mark.hatle@windriver.com>]

On 5/2/13 9:55 AM, Andreas Müller wrote:
> On Thu, May 2, 2013 at 4:50 PM, Mark Hatle <mark.hatle@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
>