[OE-core] [PATCH v3 0/5] systemd patches

[Jonas Bonn]

On 28/01/2019 18:26, Richard Purdie wrote:
> On Mon, 2019-01-28 at 14:31 +0000, Richard Purdie wrote:
>> On Mon, 2019-01-28 at 15:26 +0100, Jonas Bonn wrote:
>>> Hi,
>>>
>>> On 28/01/2019 14:55, Richard Purdie wrote:
>>>> Unfortunately this series failed in testing:
>>>>
>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/226
>>>>
>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/167
>>>>
>>>> so it looks like it may need some tweaks before we can merge it.
>>>
>>> OK.  You'll have to bear with me here as I'm not familiar with
>>> looking at the buildbot output.  From what I can see, the failure
>>> is
>>> when it attempts to boot the image... is that correct?  In what way
>>> does it fail... where do I find that?
>>
>> Yes, these tests are trying to boot images under qemu. You can see
>> the
>> output from boot process and it looks like it starts an interactive
>> dialog with the user (or attempts to) for setup. The key piece in the
>> various logs would appear to be:
>>
>>   DEBUG: Last 25 lines of text:
>>>           Starting First Boot Wizard...
>>>           Starting Rebuild Hardware Database...
>>>           Starting Apply Kernel Variables...
>>>           Mounting NFSD configuration filesystem...
>>>
>>> Welcome to your new installation of Poky (Yocto Project Reference
>> Distro) 2.6+snapshot-20190126 (master)!
>>> Please configure a few basic system settings:
>>>
>>> -- Press any key to proceed --[[0;32m  OK  [0m] Started Journal
>> Service.
>>
>> (from
>> https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/257192/raw)
>>
>>
>>> When I build locally this all runs fine.  So what should I be
>>> building locally in order to see a failure like buildbot sees?
>>
>> Add INHERIT += "testimage" to local.conf and then
>>
>> "bitbake core-image-sato -c testimage"
>>
>> You'll need a tun/tap device setup so that "runqemu <machine>
>> <imagename>"works.
> 
> FWIW testing narrowed it down to the machine id patch causing this.

Thanks.  The reason for the prompt is that systemd-firstboot runs; 
systemd detects whether it's a "first boot" based on the existence of 
the machine-id file.  Since the machine-id file is absent now (by 
design), this service runs.  The question is why systemd-firstboot is 
being included in the build at all given that it should have been 
configured out.  I'll poke at it when I get a moment.

/Jonas

> 
> Cheers,
> 
> Richard
>