Re: useradd.bbclass question

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

On 5/2/13 10:31 AM, Andreas Müller wrote:
> On Thu, May 2, 2013 at 5:18 PM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Thu, May 2, 2013 at 5:09 PM, Mark Hatle <mark.hatle@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@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.
> [andreas@oe-core]$ bitbake -e gdm | grep ^PSEUDO_PASSWD
> PSEUDO_PASSWD="/home/andreas/tmp/oe-core-eglibc/sysroots/overo"

Check that path contains 'etc/passwd' and 'etc/group'.  If not, that would be 
the issue.. if it does contain them -- then something else is happening.

--Mark

>>>
>> I will check that - still strange to me is that I have different
>> behaviour for two hosts - both with gdm user/group.
>>
>> Andreas