[OE-core] [PATCH 1/4] systemd: Remove items that made this machine (qemu) specific

Mark Hatle mark.hatle at windriver.com
Sat Oct 20 16:14:53 UTC 2018


On 10/20/18 3:41 AM, Richard Purdie wrote:
> On Wed, 2018-10-17 at 12:43 -0400, Mark Hatle wrote:
>> Create a new systemd-conf recipe to contain the specific
>> system/machine
>> configuration items.  This new package is now machine specific.
>>
>> Without doing this trying to create a single system with multiple
>> BSPs,
>> one of which was qemu based, would result in the systemd -and-
>> everything that
>> dependend upon systemd to have their hash changed.  The hash changing
>> means
>> lots of rebuilds, but worse if it's a package based system each
>> different
>> machine ends with a new PR value and a newly generated package.
>>
>> Signed-off-by: Mark Hatle <mark.hatle at windriver.com>
>> ---
>>  meta/recipes-core/systemd/systemd-conf.bb     | 51
>> +++++++++++++++++++
>>  ...ange-the-default-device-timeout-to-2.patch | 35 -------------
>>  meta/recipes-core/systemd/systemd_239.bb      | 28 ++++------
>>  3 files changed, 60 insertions(+), 54 deletions(-)
>>  create mode 100644 meta/recipes-core/systemd/systemd-conf.bb
>>  delete mode 100644 meta/recipes-core/systemd/systemd/0001-core-
>> device.c-Change-the-default-device-timeout-to-2.patch
> 
> Something in -next is causing:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/35/builds/92/steps/7/logs/step7c
> 
> which is a systemd boot timeout. 
> 
> Note that I fixed up the selftest issue with the patch, I also added a
> maintainers entry for systemd-conf to avoid another problem so please
> use the patch in -next for any further revisions. We're going to need
> more investigation to merge this though...

I'll work on this hopefully this week, and try to figure out why it's failing.
I suspect the issue is the original purpose of the workaround.  I suspect the
timeout is staying at the default.

In my limited testing, I didn't experience this -- but I'm not exactly sure what
the test configuration I should be using is to verify it.

--Mark

> Cheers,
> 
> Richard
> 
> 
> 




More information about the Openembedded-core mailing list