[OE-core] useradd.bbclass question

[Andreas Müller]

On Thu, May 2, 2013 at 5:53 PM, Mark Hatle <mark.hatle at windriver.com> wrote:
> On 5/2/13 10:31 AM, Andreas Müller wrote:
>>
>> On Thu, May 2, 2013 at 5:18 PM, Andreas Müller
>> <schnitzeltony at googlemail.com> 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.
>>
>> [andreas at 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.
Yes the path is correct and contains both files with correct IDs

> 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.)

I think both are multilib - have /lib and /lib64 and found same libs
in both. How do I ensure that both wrappers are build?

Andreas