[Buildroot] [PATCH] Makefile: Update mtime of $(TARGET_DIR)/usr

Chris Lesiak chris.lesiak at licor.com
Mon Apr 16 21:27:09 UTC 2018


On 04/16/2018 03:18 PM, Yann E. MORIN wrote:

> Chris, All,
>
> On 2018-04-16 10:33 -0500, Chris Lesiak spake thusly:
>> For the systemd-update-done.service to function, updates to /usr
>> must be followed by an update of the modification time of /usr.
>> If updates were always created with a clean build, the mtime of
>> /usr would automatically be newer than in the old build; but
>> especially during development, that may not always be the case.
>> So touch $(TARGET_DIR)/usr as the last step of target-finalize.
>>
>> For more details, see:
>> http://0pointer.de/public/systemd-man/systemd-update-done.service.html
> I'm not sure I folowed corretly.. So let me try to rephrase with my own
> understanding of the issue.
>
> If /usr it not mtime-newer than /var and /etc, then the laters will not
> be correctly populated with vendor-provided resources (aka factory
> settings).

That is correct except in detail.  The mtime of /usr is compared to the 
mtime of /etc/.updated and /var/.updated, not the /etc and /var 
directories themselves.

The systemd-update-done.service transfers the mtime of /usr to 
/etc/.updated and /var/.updated.  Other services that want to run when 
the system has been updated will arrange themselves to run before 
systemd-update-done.service and condition themselves on 
ConditionNeedsUpdate=/etc and/or ConditionNeedsUpdate=/var.

> This is especially critical after a build, so that the
> first-boot condition get correctly detected, so that populating /var
> and /etc gets triggered.
>
> So, we touch /usr so that the first-boot condition is correctly
> detected.

It isn't the ConditionFirstBoot I'm concerned with here, but 
ConditionNeedsUpdate.

ConditionFirstBoot will be true only if /etc is not populated.  If 
/etc/machine-id exists, then /etc is considered to be populated.

> Subsequent updates to /usr at runtime are not covered by this trick,
> obviously.
>
> Right?

Maybe you have some data to refute this, but without a package manager, 
I suspect that most buildroot users do updates of a device by replacing 
the entire contents of /usr and maybe even /.  In my particular case I 
use fwup to replace /usr with a ping/pong scheme alternating between two 
partitions.

Updating using rsync -t (and without -O) would also benefit from 
touching /usr at build time.

Other update mechanisms might need to touch /usr at runtime.

>
> Regards,
> Yann E. MORIN.
>
>> Signed-off-by: Chris Lesiak <chris.lesiak at licor.com>
>> ---
>>   Makefile | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Makefile b/Makefile
>> index 957ba6634a..12a53840c0 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -761,6 +761,8 @@ endif
>>                $(call MESSAGE,"Executing post-build script $(s)"); \
>>                $(EXTRA_ENV) $(s) $(TARGET_DIR) $(call qstrip,$(BR2_ROOTFS_POST_SCRIPT_ARGS))$(sep))
>>
>> +     touch $(TARGET_DIR)/usr
>> +
>>   .PHONY: target-post-image
>>   target-post-image: $(TARGETS_ROOTFS) target-finalize
>>        @$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_IMAGE_SCRIPT)), \
>> --
>> 2.14.3
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
>

-- 
Chris Lesiak
Principal Design Engineer, Software
LI-COR Biosciences
chris.lesiak at licor.com

Any opinions expressed are those of the author and
do not necessarily represent those of his employer.



More information about the buildroot mailing list