Makefile: Update mtime of $(TARGET_DIR)/usr
PATCH 1/1 Makefile: Update mtime of $(TARGET_DIR)/usr
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
--- Makefile | 2 ++ 1 file changed, 2 insertions(+)
Makefile +2 -0
@@ -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)), \
Signature · 1 line
2.14.3
PATCH 1/1 Makefile: Update mtime of $(TARGET_DIR)/usr
Chris, All,
On 2018-04-16 10:33 -0500, Chris Lesiak spake thusly:
Quoted 9 lines
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). 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.
Subsequent updates to /usr at runtime are not covered by this trick, obviously.
Right?
Regards,
Yann E. MORIN.
Quoted 25 lines
Signed-off-by Chris Lesiak <[email protected]>--- Makefile | 2 ++ 1 file changed, 2 insertions(+)Makefile +2
-0@@ -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)), \Signature · 6 lines
2.14.3 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 Makefile: Update mtime of $(TARGET_DIR)/usr
Quoted 10 lines · Yann E. MORIN
Chris, All,
On 2018-04-16 10:33 -0500, Chris Lesiak spake thusly:
Quoted 7 lines
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.
Quoted 8 lines
Quoted 2 lines
For more details, see:
http://0pointer.de/public/systemd-man/systemd-update-done.service.htmlI'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.
Quoted 6 lines
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.
Quoted 4 lines
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.
Quoted 37 lines
Regards,
Yann E. MORIN.Quoted 21 lines
Signed-off-by Chris Lesiak <[email protected]>--- Makefile | 2 ++ 1 file changed, 2 insertions(+)Makefile +2
-1@@ -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
Quoted 4 lines
_______________________________________________
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. |'------------------------------^-------^------------------^--------------------'
Signature · 7 lines
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.
PATCH 1/1 Makefile: Update mtime of $(TARGET_DIR)/usr
Chris, All,
On 2018-04-16 16:27 -0500, Chris Lesiak spake thusly:
Quoted 22 lines · Yann E. MORIN
Quoted 8 lines
On 2018-04-16 10:33 -0500, Chris Lesiak spake thusly:
Quoted 7 lines
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.
Quoted 8 lines
Quoted 2 lines
For more details, see:
http://0pointer.de/public/systemd-man/systemd-update-done.service.htmlI'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/.updatedand/var/.updated, not the /etc and /var directories themselves.
Quoted 5 lines
The systemd-update-done.service transfers the mtime of /usr to
/etc/.updatedand/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.
OK, thanks.
Quoted 4 lines
Quoted 4 lines
This is especially critical after a build, so that the first-boot condition get correctly detected, so that populating /var and /etc gets triggered.
Quoted 8 lines
Quoted 2 lines
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-idexists, then /etc is considered to be populated.
ACK.
Quoted 9 lines
Quoted 4 lines
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.
I even think that most use a read-only filesystem, so they update by just dumping the new image onto the raw device (either with a dual-bank, or a main vs. rescue sytems).
Quoted 4 lines
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.
OK, so I eventually understood what it is good for. In fact, it is not usefull for the first system one builds, but for the next versions.
The mtime of /usr of (say) version 2 will be more recent than the mtime of /etc/.updated and/or /var/.updated of a system running version 1.
Then, when the /usr version 2 is dumped into a /usr of the running system, the /etc/.updated and/or /var/.updated will be older than /usr, which would kick the update mechanism.
Correct?
If so, I see a very big issue with this mechanism. For example:
date what
0 build version 1
1 version is flahes onto a device, boxed and shipped
2 build version 2
3 the device with version 1 is received, unboxed and booted
4 that device downloads version 2 and updates to itAs you can see, the /etc/.updated and/or /var/.updated will dated '3' but the mtime of /usr version 2 will be 2 (because touched at build time).
Thus, when the system eventually updates to version 2, the mtime does not trigger an update.
So, if you want to be able to correctly trigger the update mchanism, I think the touch should be done by your extractor at runtime, right after extracting the content of /usr.
Unless I missed something (very likely), in which case I'm ready to be lectured. ;-)
Regards,
Yann E. MORIN.
Quoted 46 lines
Quoted 36 lines
Regards,
Yann E. MORIN.Quoted 21 lines
Signed-off-by Chris Lesiak <[email protected]>--- Makefile | 2 ++ 1 file changed, 2 insertions(+)Makefile +2
-1@@ -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
Quoted 4 lines
_______________________________________________
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. |'------------------------------^-------^------------------^--------------------'
Signature · 7 lines
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.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 Makefile: Update mtime of $(TARGET_DIR)/usr
Quoted 63 lines · Yann E. MORIN
Chris, All,
On 2018-04-16 16:27 -0500, Chris Lesiak spake thusly:
Quoted 21 lines · Yann E. MORIN
Quoted 8 lines
On 2018-04-16 10:33 -0500, Chris Lesiak spake thusly:
Quoted 7 lines
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.
Quoted 8 lines
Quoted 2 lines
For more details, see:
http://0pointer.de/public/systemd-man/systemd-update-done.service.htmlI'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/.updatedand/var/.updated, not the /etc and /var directories themselves.Quoted 5 lines
The systemd-update-done.service transfers the mtime of /usr to
/etc/.updatedand/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.OK, thanks.
Quoted 11 lines
Quoted 6 lines
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-idexists, then /etc is considered to be populated.ACK.
Quoted 8 lines
Quoted 4 lines
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.
I even think that most use a read-only filesystem, so they update by just dumping the new image onto the raw device (either with a dual-bank, or a main vs. rescue sytems).
Quoted 4 lines
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.
OK, so I eventually understood what it is good for. In fact, it is not usefull for the first system one builds, but for the next versions.
Quoted 8 lines
The mtime of /usr of (say) version 2 will be more recent than the mtime of
/etc/.updatedand/or/var/.updatedof a system running version 1.Then, when the /usr version 2 is dumped into a /usr of the running system, the
/etc/.updatedand/or/var/.updatedwill be older than /usr, which would kick the update mechanism.Correct?
Yes.
Quoted 10 lines
If so, I see a very big issue with this mechanism. For example:
date what 0 build version 1 1 version is flahes onto a device, boxed and shipped 2 build version 2 3 the device with version 1 is received, unboxed and booted 4 that device downloads version 2 and updates to it
Quoted 3 lines
As you can see, the
/etc/.updatedand/or/var/.updatedwill dated '3' but the mtime of /usr version 2 will be 2 (because touched at build time).
Not quite.
If systemd-update-done if working correctly, then on date 3, /etc/.updated and /var/.updated will get created with mtime 0, not mtime 3.? Then on date 4, /etc/.updated and /var/.updated will get updated (because 0 is less than 2) to mtime 2.
When /etc/.updated and /var/.updated are originally created and then again when they are updated, their mtime will match the mtime of /usr, not the current time when systemd-update-done runs.
Quoted 10 lines
Thus, when the system eventually updates to version 2, the mtime does not trigger an update.
So, if you want to be able to correctly trigger the update mchanism, I think the touch should be done by your extractor at runtime, right after extracting the content of /usr.
Unless I missed something (very likely), in which case I'm ready to be lectured. ;-)
Thanks for reviewing this and asking questions.? It caused me to dig a little deeper and find a systemd-update-done regression in v234 that will be fixed in v239.? See: https://github.com/systemd/systemd/issues/8806
Regards,
Chris Lesiak
Quoted 57 lines
Regards,
Yann E. MORIN.Quoted 36 lines
Quoted 30 lines
Regards,
Yann E. MORIN.Quoted 21 lines
Signed-off-by Chris Lesiak <[email protected]>--- Makefile | 2 ++ 1 file changed, 2 insertions(+)Makefile +2
-1@@ -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
Quoted 4 lines
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot--
.-----------------.--------------------.------------------.--------------------.Quoted 6 lines
| 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. |'------------------------------^-------^------------------^--------------------'
Quoted 9 lines
--
Chris Lesiak
Principal Design Engineer, Software
LI-COR Biosciences
chris.lesiak at licor.comAny opinions expressed are those of the author and do not necessarily represent those of his employer.
--
.-----------------.--------------------.------------------.--------------------.| 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. |'------------------------------^-------^------------------^--------------------'
Signature · 7 lines
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.
PATCH 1/1 Makefile: Update mtime of $(TARGET_DIR)/usr
Chris, All,
On 2018-04-24 13:56 -0500, Chris Lesiak spake thusly:
Quoted 13 lines
Quoted 10 lines
date what 0 build version 1 1 version is flahes onto a device, boxed and shipped 2 build version 2 3 the device with version 1 is received, unboxed and booted 4 that device downloads version 2 and updates to itAs you can see, the
/etc/.updatedand/or/var/.updatedwill dated '3' but the mtime of /usr version 2 will be 2 (because touched at build time).Not quite.
Quoted 8 lines
If systemd-update-done if working correctly, then on date 3,
/etc/.updatedand/var/.updatedwill get created with mtime 0, not mtime 3.? Then on date 4,/etc/.updatedand/var/.updatedwill get updated (because 0 is less than
2) to mtime 2.When
/etc/.updatedand/var/.updatedare originally created and then again when they are updated, their mtime will match the mtime of /usr, not the current time when systemd-update-done runs.
OK, makes sense. Thanks for the clraification.
So, this touch is eventually mostly usefull for a read-only rootfs, in fact (for a read-only rootfs, the touch could be done by the update mechanis).
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 1/1 Makefile: Update mtime of $(TARGET_DIR)/usr in target-finalize
In reply to Chris LesiakThe systemd ConditionNeedsUpdate option is useful when offline updates of the vendor operating system resources in /usr require updating of /etc or /var on the next following boot.
Two examples of services making use of this option are systemd-hwdb-update.service and systemd-sysusers.service.
ConditionNeedsUpdate=/etc will be true if the mtime of /etc/.updated is older than the mtime of /usr. After services conditional on ConditionNeedsUpdate have run, systemd-update-done.service will synch the mtime of /usr to /etc/.updated so that the condition will be false on subsequent boots.
For systems with writable /usr partitions where updates are done to the running system, the update program will touch /usr as a final step. But with Buildroot, where updates are often done by dumping a new image onto the device, and where /usr is on a filesystem mounted read-only, touching /usr as part of the update process is not practical. Instead, it should be done a build time.
For testers, please note that systemd-update-done in v234 added a regression where the mtime of /etc/.updated is set to the current time instead of the mtime or /usr. This will be fixed in v239.
For more details, see:
http://0pointer.de/public/systemd-man/systemd.unit.html
http://0pointer.de/public/systemd-man/systemd-update-done.service.html
---
Changed v1 --> v2
- Provide a more detailed commit message.
--- Makefile | 2 ++ 1 file changed, 2 insertions(+)
Makefile +2 -0
@@ -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)), \
Signature · 1 line
2.14.3
Thomas Petazzoni
AppliedPATCH v2 1/1 Makefile: Update mtime of $(TARGET_DIR)/usr in target-finalize
Hello,
Quoted 28 lines · Chris Lesiak
The systemd ConditionNeedsUpdate option is useful when offline updates of the vendor operating system resources in /usr require updating of /etc or /var on the next following boot.
Two examples of services making use of this option are systemd-hwdb-update.service and systemd-sysusers.service.
ConditionNeedsUpdate=/etc will be true if the mtime of
/etc/.updatedis older than the mtime of /usr. After services conditional on ConditionNeedsUpdate have run, systemd-update-done.service will synch the mtime of /usr to/etc/.updatedso that the condition will be false on subsequent boots.For systems with writable /usr partitions where updates are done to the running system, the update program will touch /usr as a final step. But with Buildroot, where updates are often done by dumping a new image onto the device, and where /usr is on a filesystem mounted read-only, touching /usr as part of the update process is not practical. Instead, it should be done a build time.
For testers, please note that systemd-update-done in v234 added a regression where the mtime of
/etc/.updatedis set to the current time instead of the mtime or /usr. This will be fixed in v239.For more details, see:
http://0pointer.de/public/systemd-man/systemd.unit.html
http://0pointer.de/public/systemd-man/systemd-update-done.service.html
Quoted 8 lines
Signed-off-by Chris Lesiak <[email protected]>Reviewed-by "Yann E. MORIN" <[email protected]>---
Changed v1 --> v2
- Provide a more detailed commit message.--- Makefile | 2 ++ 1 file changed, 2 insertions(+)
Applied to master, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH v2 1/1 Makefile: Update mtime of $(TARGET_DIR)/usr in target-finalize
In reply to Chris LesiakQuoted 30 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Chris" == Chris Lesiak <[email protected]> writes:
The systemd ConditionNeedsUpdate option is useful when offline updates of the vendor operating system resources in /usr require updating of /etc or /var on the next following boot.
Two examples of services making use of this option are systemd-hwdb-update.service and systemd-sysusers.service.
ConditionNeedsUpdate=/etc will be true if the mtime of
/etc/.updatedis older than the mtime of /usr. After services conditional on ConditionNeedsUpdate have run, systemd-update-done.service will synch the mtime of /usr to/etc/.updatedso that the condition will be false on subsequent boots.For systems with writable /usr partitions where updates are done to the running system, the update program will touch /usr as a final step. But with Buildroot, where updates are often done by dumping a new image onto the device, and where /usr is on a filesystem mounted read-only, touching /usr as part of the update process is not practical. Instead, it should be done a build time.
For testers, please note that systemd-update-done in v234 added a regression where the mtime of
/etc/.updatedis set to the current time instead of the mtime or /usr. This will be fixed in v239.For more details, see:
http://0pointer.de/public/systemd-man/systemd.unit.html
http://0pointer.de/public/systemd-man/systemd-update-done.service.html
Quoted 5 lines
Signed-off-by Chris Lesiak <[email protected]>Reviewed-by "Yann E. MORIN" <[email protected]>---
Changed v1 --> v2
- Provide a more detailed commit message.
Committed to 2018.02.x, thanks.
Signature · 1 line
Bye, Peter Korsgaard