Re: [oe-core][PATCHv6 0/5] Display manager proposal for x11 and wayland

[Randolph Sapp <rs@ti.com>]

On Wed Jun 4, 2025 at 7:12 PM CDT, Randolph Sapp wrote:
> On Wed May 28, 2025 at 6:53 AM CDT, Mathieu Dubois-Briand wrote:
>> On Wed May 28, 2025 at 12:16 AM CEST, Randolph Sapp wrote:
>
> [snip]
>
>>> Ah, the auth failures persist. Normally this is caused when the user attempts to
>>> login before the user account was created or something unusual like that. I
>>> don't suppose there's any way this could be happening on the test machines?
>>>
>>> I'm not able to reproduce this locally, but my build config is different. I tend
>>> to use oe-core and nodistro instead of poky. They aren't playing around with the
>>> reproducible build date stuff or anything like that are they?
>>>
>>> Well, I mean I did see this on occasion. The first login attempt almost always
>>> failed, but the subsequent attempts were fine. Bumping the attempt count back up
>>> the default (2) was enough to resolve it on my end, but evidently it's not
>>> enough here.
>>>
>>> This is not happening on hardware from what I'm seeing.
>>
>> Hi Randolph,
>>
>> I was able to reproduce it locally, with the following configuration:
>> - https://git.yoctoproject.org/poky-ci-archive on tag
>>   autobuilder.yoctoproject.org/valkyrie/a-full-1630.
>> - template local.conf, with the following modifications:
>>   MACHINE = "qemux86"
>>   DISTRO = "poky-altcfg"
>>   SDKMACHINE = "x86_64"
>>   PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
>>   INHERIT += 'image-buildinfo'
>>   IMAGE_BUILDINFO_VARS:append = ' IMAGE_BASENAME IMAGE_NAME'
>>   PACKAGE_CLASSES = 'package_ipk package_rpm package_deb'
>>   IMAGE_ROOTFS_EXTRA_SPACE:append = '${@bb.utils.contains('IMAGE_FEATURES', 'package-management', ' + 262144', '', d)}'
>>   IMAGE_INSTALL:append = ' ssh-pregen-hostkeys'
>>   SANITY_TESTED_DISTROS = ''
>>   OE_FRAGMENTS += 'core/yocto-autobuilder/autobuilder core/yocto-autobuilder/autobuilder-resource-constraints'
>>   # (Plus my own sstate cache and downloads dir).
>> - bitbake core-image-sato
>> - bitbake core-image-sato:do_testimage
>>
>> Of course using the tag from poky-ci-archive is not mandatory, you
>> should see the same behaviour with master branch and your patches.
>>
>> I saw some oe-selftest was also failing on the autobuilder, with an
>> error related to emptty. You can reproduce it with:
>>
>> oe-selftest -r sstatetests.SStateHashSameSigs3.test_sstate_sametune_samesigs
>
> Status report, since it's been a little bit.
>
> Seems this some i386/x86 fault only exposed in this specific environment. I was
> unable to reproduce it on Archlinux32. I've traced it back to a SEGFAULT when we
> attempt to execute mcookie as the target user. Odd stuff. Delve and gdb aren't
> helping me here. Running some more tests to see if I can corner this some other
> way.
>
> - Randolph

Well, I managed to determine this is specifically an issue after loading libpam
and attempting to authenticate.

Seems like loading both common-auth and common-account before calling
pam_acct_mgmt results in the above described segfault.

There are 3 pam interactions made after the initial auth.
	1. pam_acct_mgmt
	2. pam_set_item
	3. pam_setcred

Loading only common-account reports that pam_acct_mgmt fails with the PAM_SILENT
flag set.

Removing that flag makes the later pam_setcred fail, but allows pam_acct_mgmt
and pam_set_item to work correctly. Removing the call to pam_acct_mgmt
altogether seems to allow pam_setcred to work.

Removing the call to pam_acct_mgmt also allows both common-auth and
common-account to be loaded without triggering the segfault.

Very unusual. Everything points at the obvious "arch specific problems with the
go pam wrapper", but other distributions don't seem to have this issue and
nothing seems particularly wrong with the wrapper itself. Could be a
manifestation of multiple issues though, considering how much the behavior
changes depending on what pam modules are loaded.

Guess I have some reading to do this weekend.

- Randolph