public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
* [PATCH] expand-on-first-boot: really only do that once - reverted back
@ 2023-02-01 15:53 roberto.foglietta
  2023-02-02  8:14 ` Henning Schild
  0 siblings, 1 reply; 2+ messages in thread
From: roberto.foglietta @ 2023-02-01 15:53 UTC (permalink / raw)
  To: isar-users; +Cc: roberto.foglietta

From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>

The proper solution is to wait that udev settle ends and then try to
access to the disk that in some architectures are down to a bus not
initialised at boot time because the boot happens from a separate
partition usually internal to the PCB/SoC.

After all, this script is supposed to run just one single time at the
first boot and thus the time spent on it has no impact on the every-day
performances. Moreover, in case of failure - which is more probable in
small embedded systems - the system goes in production without the full
disk capacity for which has been designed for. Small embedded systems
those usually unsupervised or remotely supervised, thus introducing a
potential source of nasty failures which could hard to detect expecially
if the disk becames overloaded or complete full.

To avoid all these risks the only reasonable approach is to set these
systems in such a way that they will reboot continously until they are
not provided with the full disk capacity. In such a way they will fail
at the day zero and this will be easily catch by the deployment tests.

This patch affects also this setting and definetely should be reverted

Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com>
---
 .../expand-on-first-boot/files/expand-on-first-boot.service      | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service b/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
index 90c92a39..fda50016 100644
--- a/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
+++ b/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
@@ -15,7 +15,6 @@ ConditionPathIsReadWrite=/etc
 Type=oneshot
 ExecStart=/usr/share/expand-on-first-boot/expand-last-partition.sh
 ExecStartPost=-/bin/systemctl disable expand-on-first-boot.service
-ExecStopPost=-/bin/systemctl disable expand-on-first-boot.service
 
 [Install]
 WantedBy=sysinit.target
-- 
2.34.1


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] expand-on-first-boot: really only do that once - reverted back
  2023-02-01 15:53 [PATCH] expand-on-first-boot: really only do that once - reverted back roberto.foglietta
@ 2023-02-02  8:14 ` Henning Schild
  0 siblings, 0 replies; 2+ messages in thread
From: Henning Schild @ 2023-02-02  8:14 UTC (permalink / raw)
  To: roberto.foglietta; +Cc: isar-users, roberto.foglietta

NACK

Am Wed,  1 Feb 2023 16:53:35 +0100
schrieb roberto.foglietta@linuxteam.org:

> From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
> 
> The proper solution is to wait that udev settle ends and then try to
> access to the disk that in some architectures are down to a bus not
> initialised at boot time because the boot happens from a separate
> partition usually internal to the PCB/SoC.
> 
> After all, this script is supposed to run just one single time at the
> first boot and thus the time spent on it has no impact on the
> every-day performances. Moreover, in case of failure - which is more
> probable in small embedded systems - the system goes in production
> without the full disk capacity for which has been designed for. Small
> embedded systems those usually unsupervised or remotely supervised,
> thus introducing a potential source of nasty failures which could
> hard to detect expecially if the disk becames overloaded or complete
> full.
> 
> To avoid all these risks the only reasonable approach is to set these
> systems in such a way that they will reboot continously until they are
> not provided with the full disk capacity. In such a way they will fail
> at the day zero and this will be easily catch by the deployment tests.
> 
> This patch affects also this setting and definetely should be reverted
> 
> Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com>
> ---
>  .../expand-on-first-boot/files/expand-on-first-boot.service      | 1
> - 1 file changed, 1 deletion(-)
> 
> diff --git
> a/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
> b/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
> index 90c92a39..fda50016 100644 ---
> a/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
> +++
> b/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
> @@ -15,7 +15,6 @@ ConditionPathIsReadWrite=/etc Type=oneshot
> ExecStart=/usr/share/expand-on-first-boot/expand-last-partition.sh
> ExecStartPost=-/bin/systemctl disable expand-on-first-boot.service
> -ExecStopPost=-/bin/systemctl disable expand-on-first-boot.service
> [Install] WantedBy=sysinit.target


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-02-02  8:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-01 15:53 [PATCH] expand-on-first-boot: really only do that once - reverted back roberto.foglietta
2023-02-02  8:14 ` Henning Schild

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox