[meta-swupdate][PATCH v3 0/1] swupdate-progress packages fixes

[Kyle Russell]

Here's an updated patch with the various fixes for systemd-progress.service
that have been discussed in the last couple of days.

I haven't tested this yet, but wanted to get it out to consolidate the discussion
and get other eyes on the complete fix. I have a double-copy implementation that
uses swupdate-progress.service in systemd that I will try this on tomorrow. I had
previously been focused on making swupdate-image reboot, which uses sysvinit as its
init manager, and just overlooked the consequence of the systemd package rename.

Again, sorry for missing this. I'll report back once I've verified on my double-copy
implementation using systemd.

Kyle Russell (1):
swupdate: reboot on update from initramfs recovery image

recipes-extended/images/swupdate-image.inc | 2 +-
recipes-support/swupdate/swupdate.inc | 27 ++++++++++++++--------
2 files changed, 18 insertions(+), 11 deletions(-)

--
2.25.1

[Kyle Russell]

Create swupdate-progress-sysvinit and swupdate-progress-systemd packages with
the necessary startup scripts for swupdate-progress to run correctly during
startup for both virtual/init managers. swupdate-image initramfs should RDEPEND
on swupdate-progress-sysvinit, which now adds a dependency on the swupdate-progress
binary (packaged in swupdate-progress-bin).

This allows swupdate-progress to simultaneously be installed in both a distro's
main rootfs which uses the systemd DISTRO_FEATURE, and the initramfs image which
uses sysvinit.

The old swupdate-progress package is now empty, and can still be used as an
RDEPENDS on the main rootfs image recipe, and swupdate will automatically
select the appropriate startup script based on DISTRO_FEATURES.

Signed-off-by: Kyle Russell <bkyler...@gmail.com>
---

recipes-extended/images/swupdate-image.inc | 2 +-
recipes-support/swupdate/swupdate.inc | 27 ++++++++++++++--------
2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/recipes-extended/images/swupdate-image.inc b/recipes-extended/images/swupdate-image.inc
index 795b4a2..928edad 100644
--- a/recipes-extended/images/swupdate-image.inc
+++ b/recipes-extended/images/swupdate-image.inc
@@ -12,7 +12,7 @@ IMAGE_INSTALL = "base-files \
libconfig \
swupdate \
swupdate-www \
- ${@bb.utils.contains('SWUPDATE_INIT', 'tiny', 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
+ ${@bb.utils.contains('SWUPDATE_INIT', 'tiny', 'virtual/initscripts-swupdate', 'initscripts sysvinit swupdate-progress-sysvinit', d)} \
util-linux-sfdisk \
"

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 0d382bd..c072f63 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -36,6 +36,9 @@ PACKAGES =+ " \
${PN}-client \
${PN}-lua \
${PN}-progress \
+ ${PN}-progress-bin \
+ ${PN}-progress-systemd \
+ ${PN}-progress-sysvinit \
${PN}-tools \
${PN}-tools-hawkbit \
${PN}-usb \
@@ -48,11 +51,12 @@ ALLOW_EMPTY_${PN}-tools = "1"

FILES_${PN}-client = "${bindir}/swupdate-client"
FILES_${PN}-lua += "${libdir}/lua/"
-FILES_${PN}-progress = " \
- ${bindir}/swupdate-progress \
- ${systemd_system_unitdir}/swupdate-progress.service \
- ${libdir}/swupdate/conf.d/90-start-progress \
-"
+
+ALLOW_EMPTY_${PN}-progress = "1"
+FILES_${PN}-progress-bin = "${bindir}/swupdate-progress"
+FILES_${PN}-progress-systemd = "${systemd_system_unitdir}/swupdate-progress.service"
+FILES_${PN}-progress-sysvinit = "${libdir}/swupdate/conf.d/90-start-progress"
+
FILES_${PN}-usb = " \
${sysconfdir}/udev/rules.d/swupdate-usb.rules \
${systemd_system_unitdir}/swupdate-usb@.service \
@@ -74,6 +78,9 @@ FILES_${PN}-www = " \
"

RDEPENDS_${PN}-usb += "${PN}-client"
+RDEPENDS_${PN}-progress += "${@bb.utils.contains('DISTRO_FEATURES','systemd','${PN}-progress-systemd','${PN}-progress-sysvinit',d)}"
+RDEPENDS_${PN}-progress-systemd += "${PN}-progress-bin"
+RDEPENDS_${PN}-progress-sysvinit += "${PN}-progress-bin"

# The tools package is deprecated, it is an empty meta package for backward compatibility
RDEPENDS_${PN}-tools += "${PN}-client ${PN}-progress ${PN}-tools-hawkbit \
@@ -255,16 +262,16 @@ do_install () {
install -m 0644 ${WORKDIR}/tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf
install -d ${D}${sysconfdir}/udev/rules.d
install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
- else
- # in case of systemd there is a service file, for sysv init we need to start it as well
- install -m 0644 ${WORKDIR}/90-start-progress ${D}${libdir}/swupdate/conf.d/
fi
+
+ # in case of systemd there is a service file, for sysv init we need to start it as well
+ install -m 0644 ${WORKDIR}/90-start-progress ${D}${libdir}/swupdate/conf.d/
}

INITSCRIPT_NAME = "swupdate"
INITSCRIPT_PARAMS = "defaults 70"

-SYSTEMD_PACKAGES = "${PN} ${PN}-progress ${PN}-usb"
+SYSTEMD_PACKAGES = "${PN} ${PN}-progress-systemd ${PN}-usb"
SYSTEMD_SERVICE_${PN} = "swupdate.service swupdate.socket"
-SYSTEMD_SERVICE_${PN}-progress = "swupdate-progress.service"
+SYSTEMD_SERVICE_${PN}-progress-systemd = "swupdate-progress.service"
SYSTEMD_SERVICE_${PN}-usb = "swupdate-usb@.service"
--
2.25.1

[Stefan Herbrechtsmeier]

Hi Kyle,

Am 25.04.21 um 05:16 schrieb Kyle Russell:

> Here's an updated patch with the various fixes for systemd-progress.service
> that have been discussed in the last couple of days.
>
> I haven't tested this yet, but wanted to get it out to consolidate the discussion
> and get other eyes on the complete fix. I have a double-copy implementation that
> uses swupdate-progress.service in systemd that I will try this on tomorrow. I had
> previously been focused on making swupdate-image reboot, which uses sysvinit as its
> init manager, and just overlooked the consequence of the systemd package rename.
>
> Again, sorry for missing this. I'll report back once I've verified on my double-copy
> implementation using systemd.

Why do you need a special package for systemd and sysvinit? Why can't
you ship an swupdate-progress init script and systemd service file in
one package and remove the 90-start-progress file.

Regards
Stefan

[Kyle Russell]

I'm not sure I understand your question completely. 90-start-progress is how swupdate-progess gets exec'd by sysvinit. Are you suggesting moving the exec into swupdate.sh?

The problem with the current state is that swupdate-image.bb uses sysvinit unconditionally, but the main rootfs may set systemd in DISTRO_FEATURES. This would prevent swupdate-image.bb from supporting reboot.

The service and 90-start-progress could be combined into a single package that's installed into swupdate-image, but swupdate-progess.service would be unnecessary since swupdate-image doesn't use systemd. This change allows an image or distribution to only install the files it actually needs, and was the design agreed upon in the original thread.

--
You received this message because you are subscribed to the Google Groups "swupdate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/swupdate/b8a82c2a-4d81-da5f-612f-3fb0bf26bc00%40herbrechtsmeier.net.

[Stefan Herbrechtsmeier]

Hi Kyle,

Am 25.04.21 um 16:58 schrieb Kyle Russell:

> I'm not sure I understand your question completely. 90-start-progress is
> how swupdate-progess gets exec'd by sysvinit. Are you suggesting moving
> the exec into swupdate.sh?

No. I suggest to create a separate init script for swupdate-progress to
be consistent with the separate systemd service file. Maybe it is
possible to reuse the swupdate init script and replace DESC, NAME and
DAEMON with swupdate-progress.

> The problem with the current state is that swupdate-image.bb

> <http://swupdate-image.bb> uses sysvinit unconditionally, but the main

> rootfs may set systemd in DISTRO_FEATURES. This would prevent

> swupdate-image.bb <http://swupdate-image.bb> from supporting reboot.

The problem is the inconsistent between systemd and sysvinit to start
the swupdate-progress. The current solution with 90-start-progress for
sysvinit looks like a hack because it is impossible to stop or restart
swupdate-progress.

> The service and 90-start-progress could be combined into a single
> package that's installed into swupdate-image, but
> swupdate-progess.service would be unnecessary since swupdate-image
> doesn't use systemd.

How do you install the swupdate init script only? I assume you install
the swupdate package with sysvinit and systemd support.

The real problem is the 90-start-progress file which will start
swupdate-progress as part of the swupdate init script / service.

> This change allows an image or distribution to only
> install the files it actually needs, and was the design agreed upon in
> the original thread.

But this isn't a common approach and should be avoided if possible.

Regards
Stefan

> <mailto:swupdate%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/b8a82c2a-4d81-da5f-612f-3fb0bf26bc00%40herbrechtsmeier.net

> <https://groups.google.com/d/msgid/swupdate/b8a82c2a-4d81-da5f-612f-3fb0bf26bc00%40herbrechtsmeier.net>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com

> <mailto:swupdate+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/CAFrQVPP1CKG-sfpKqzzHKq65L2Ebg66CsFWTL6xki7QRQT3Jcg%40mail.gmail.com
> <https://groups.google.com/d/msgid/swupdate/CAFrQVPP1CKG-sfpKqzzHKq65L2Ebg66CsFWTL6xki7QRQT3Jcg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Kyle Russell]

Hi Stefan,

I think your suggestion would work since my configuration uses both systemd and sysvinit (via backfill) in DISTRO_FEATURES.  However, I wasn't really looking to change the current design (90-start-progress).

Replacing 90-start-progress with an init script would require both systemd and sysvinit in DISTRO_FEATURES, since without sysvinit, systemd.bbclass would remove files in /etc/init.d from the swupdate-progress package making swupdate-image again lose reboot functionality, but I think requiring sysvinit in DISTRO_FEATURES if you use swupdate-image makes sense.  The packaging approach this patch suggests would not require sysvinit in your DISTRO_FEATURES, however.

For example, if someone enabled systemd in DISTRO_FEATURES but listed sysvinit in DISTRO_FEATURES_BACKFILL_CONSIDERED, then the progress init script would be removed from the swupdate-progress package.  I think you could argue that configuration is invalid though, since swupdate-image requires sysvinit.

I don't know if there are any compatibility concerns that need to be addressed before converting 90-start-progress to an init script.  I'm willing to try the approach you suggest if this is what the maintainers would prefer.

Kyle

To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/swupdate/d6256a0e-627a-4f08-a010-da8fbec6cdfe%40herbrechtsmeier.net.

[Stefano Babic]

Hi Kyle,

On 25.04.21 16:58, Kyle Russell wrote:
> I'm not sure I understand your question completely. 90-start-progress is
> how swupdate-progess gets exec'd by sysvinit. Are you suggesting moving
> the exec into swupdate.sh?
>

Well, this is really the weird thing. At the beginning, there were just
one service even in systemd, and the unit starting swupdate had started
the progress, too. Later it was moved out and swupdate-progress has its
own service unit, but this was not done for SystemV. Here there is a
hack and swuupdate itself starts via exec (in the 90-start-progress) the
progress. But then restart and stop the service is not prossible.

> The problem with the current state is that swupdate-image.bb

> <http://swupdate-image.bb> uses sysvinit unconditionally,

This image is thought to be just a rescue - and as rescue, I have to
shrink it to fit it in a smaller flash (currently 16MB, I did once with
8MB flash, but with an older and smaller kernel). swupdate-image is
built with DISTRO having SystemV (or nothing....) as init. That is, if
the rootfs of a product runs with systemd, I use two different distros
for production and rescue.

> but the main
> rootfs may set systemd in DISTRO_FEATURES. This would prevent

> swupdate-image.bb <http://swupdate-image.bb> from supporting reboot.

With the same distro.

>
> The service and 90-start-progress could be combined into a single
> package that's installed into swupdate-image, but
> swupdate-progess.service would be unnecessary since swupdate-image
> doesn't use systemd. This change allows an image or distribution to only
> install the files it actually needs, and was the design agreed upon in
> the original thread.

You're right, but this was my mistake because I have not thought enough
about and lead to revert them when I realized it was in the wrong
direction. OE provide support for packages that supports both SystemV
and systemd, and splitting them is against OE's rules.

Best regards,
Stefano Babic

> <mailto:swupdate%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/b8a82c2a-4d81-da5f-612f-3fb0bf26bc00%40herbrechtsmeier.net

> <https://groups.google.com/d/msgid/swupdate/b8a82c2a-4d81-da5f-612f-3fb0bf26bc00%40herbrechtsmeier.net>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com

> <mailto:swupdate+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/CAFrQVPP1CKG-sfpKqzzHKq65L2Ebg66CsFWTL6xki7QRQT3Jcg%40mail.gmail.com
> <https://groups.google.com/d/msgid/swupdate/CAFrQVPP1CKG-sfpKqzzHKq65L2Ebg66CsFWTL6xki7QRQT3Jcg%40mail.gmail.com?utm_medium=email&utm_source=footer>.


--

=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Stefano Babic]

Hi Stefan, Kyle,

On 25.04.21 19:23, Stefan Herbrechtsmeier wrote:
> Hi Kyle,
>

> Am 25.04.21 um 16:58 schrieb Kyle Russell:
>> I'm not sure I understand your question completely. 90-start-progress
>> is how swupdate-progess gets exec'd by sysvinit. Are you suggesting
>> moving the exec into swupdate.sh?
>
> No. I suggest to create a separate init script for swupdate-progress to
> be consistent with the separate systemd service file. Maybe it is
> possible to reuse the swupdate init script and replace DESC, NAME and
> DAEMON with swupdate-progress.

Yes - it is quite redundant, but it is the correct way to have two
distinct services. And I confess, it was not done due to lazyness.

>
>
>> The problem with the current state is that swupdate-image.bb
>> <http://swupdate-image.bb> uses sysvinit unconditionally, but the main
>> rootfs may set systemd in DISTRO_FEATURES. This would prevent
>> swupdate-image.bb <http://swupdate-image.bb> from supporting reboot.
>
> The problem is the inconsistent between systemd and sysvinit to start
> the swupdate-progress. The current solution with 90-start-progress for
> sysvinit looks like a hack

You are right, this is a hack - yes, it worked since now, but with
limitations (no restart / stop of swupdate-progress) and it remains a hack.

> because it is impossible to stop or restart
> swupdate-progress.

Absolutely agree.

>
>
>> The service and 90-start-progress could be combined into a single
>> package that's installed into swupdate-image, but
>> swupdate-progess.service would be unnecessary since swupdate-image
>> doesn't use systemd.
>
> How do you install the swupdate init script only? I assume you install
> the swupdate package with sysvinit and systemd support.
>
> The real problem is the 90-start-progress file which will start
> swupdate-progress as part of the swupdate init script / service.
>
>
>> This change allows an image or distribution to only install the files
>> it actually needs, and was the design agreed upon in the original thread.
>
> But this isn't a common approach and should be avoided if possible.

Right, and I am sorry I have not paid enough attention. When I did, I
reverted the patches.

Best regards,
Stefano Babic

[Stefano Babic]

Hi Kyle,

On 25.04.21 22:52, Kyle Russell wrote:
> Hi Stefan,
>
> I think your suggestion would work since my configuration uses both
> systemd and sysvinit (via backfill) in DISTRO_FEATURES.  However, I
> wasn't really looking to change the current design (90-start-progress).
>

Feel free to do it when you note that design was bogus - it is here. The
90-start-progress is a hack.

> Replacing 90-start-progress with an init script would require both
> systemd and sysvinit in DISTRO_FEATURES, since without sysvinit,
> systemd.bbclass would remove files in /etc/init.d from the
> swupdate-progress package making swupdate-image again lose reboot
> functionality, but I think requiring sysvinit in DISTRO_FEATURES if you
> use swupdate-image makes sense.  The packaging approach this patch
> suggests would not require sysvinit in your DISTRO_FEATURES, however.
>
> For example, if someone enabled systemd in DISTRO_FEATURES but listed
> sysvinit in DISTRO_FEATURES_BACKFILL_CONSIDERED, then the progress init
> script would be removed from the swupdate-progress package.  I think you
> could argue that configuration is invalid though, since swupdate-image
> requires sysvinit.

virtual/init is a central point in OE. As swupdate-image is thought to
be a rescue, that is running outside the production image, I generally
split it and I add a separate DISTRO configuration for it without
systemd (and without a lot of other things...).

>
> I don't know if there are any compatibility concerns that need to be
> addressed before converting 90-start-progress to an init script.

No, rescue is often project specific and anyone tunes it to reduce the
size or to add own tools. It is ok to convert it.

>  I'm
> willing to try the approach you suggest if this is what the maintainers
> would prefer.

Yes, it is, this is the right approach.

Best regards,
Stefano Babic

>
> Kyle
>
>
> On Sun, Apr 25, 2021 at 1:23 PM Stefan Herbrechtsmeier

> <ste...@herbrechtsmeier.net <mailto:ste...@herbrechtsmeier.net>> wrote:
>
> Hi Kyle,
>

> Am 25.04.21 um 16:58 schrieb Kyle Russell:
> > I'm not sure I understand your question completely.
> 90-start-progress is
> > how swupdate-progess gets exec'd by sysvinit. Are you suggesting
> moving
> > the exec into swupdate.sh?
>
> No. I suggest to create a separate init script for swupdate-progress to
> be consistent with the separate systemd service file. Maybe it is
> possible to reuse the swupdate init script and replace DESC, NAME and
> DAEMON with swupdate-progress.
>
>
> > The problem with the current state is that swupdate-image.bb
> <http://swupdate-image.bb>

> > <http://swupdate-image.bb <http://swupdate-image.bb>> uses

> sysvinit unconditionally, but the main
> > rootfs may set systemd in DISTRO_FEATURES. This would prevent
> > swupdate-image.bb <http://swupdate-image.bb>

> <http://swupdate-image.bb <http://swupdate-image.bb>> from

> supporting reboot.
>
> The problem is the inconsistent between systemd and sysvinit to start
> the swupdate-progress. The current solution with 90-start-progress for
> sysvinit looks like a hack because it is impossible to stop or restart
> swupdate-progress.
>
>
> > The service and 90-start-progress could be combined into a single
> > package that's installed into swupdate-image, but
> > swupdate-progess.service would be unnecessary since swupdate-image
> > doesn't use systemd.
>
> How do you install the swupdate init script only? I assume you install
> the swupdate package with sysvinit and systemd support.
>
> The real problem is the 90-start-progress file which will start
> swupdate-progress as part of the swupdate init script / service.
>
>
> > This change allows an image or distribution to only
> > install the files it actually needs, and was the design agreed
> upon in
> > the original thread.
>
> But this isn't a common approach and should be avoided if possible.
>
> Regards
>    Stefan
>
>
> > On Sun, Apr 25, 2021, 10:00 AM Stefan Herbrechtsmeier
> > <ste...@herbrechtsmeier.net <mailto:ste...@herbrechtsmeier.net>

> <mailto:ste...@herbrechtsmeier.net

> >     <mailto:swupdate%2Bunsu...@googlegroups.com
> <mailto:swupdate%252Buns...@googlegroups.com>>.

> >     To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/swupdate/b8a82c2a-4d81-da5f-612f-3fb0bf26bc00%40herbrechtsmeier.net
> <https://groups.google.com/d/msgid/swupdate/b8a82c2a-4d81-da5f-612f-3fb0bf26bc00%40herbrechtsmeier.net>
> >
>  <https://groups.google.com/d/msgid/swupdate/b8a82c2a-4d81-da5f-612f-3fb0bf26bc00%40herbrechtsmeier.net <https://groups.google.com/d/msgid/swupdate/b8a82c2a-4d81-da5f-612f-3fb0bf26bc00%40herbrechtsmeier.net>>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com

> <mailto:swupdate%2Bunsu...@googlegroups.com>
> > <mailto:swupdate+u...@googlegroups.com

> <mailto:swupdate%2Bunsu...@googlegroups.com>>.
> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/swupdate/CAFrQVPP1CKG-sfpKqzzHKq65L2Ebg66CsFWTL6xki7QRQT3Jcg%40mail.gmail.com
> <https://groups.google.com/d/msgid/swupdate/CAFrQVPP1CKG-sfpKqzzHKq65L2Ebg66CsFWTL6xki7QRQT3Jcg%40mail.gmail.com>
>
> >
> <https://groups.google.com/d/msgid/swupdate/CAFrQVPP1CKG-sfpKqzzHKq65L2Ebg66CsFWTL6xki7QRQT3Jcg%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/swupdate/CAFrQVPP1CKG-sfpKqzzHKq65L2Ebg66CsFWTL6xki7QRQT3Jcg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to swupdate+u...@googlegroups.com
> <mailto:swupdate%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/d6256a0e-627a-4f08-a010-da8fbec6cdfe%40herbrechtsmeier.net
> <https://groups.google.com/d/msgid/swupdate/d6256a0e-627a-4f08-a010-da8fbec6cdfe%40herbrechtsmeier.net>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/CAFrQVPOE5TNgd-i4dLvXST%2BKEYTNfSrrrN63zgpGGtLJQsYEkg%40mail.gmail.com
> <https://groups.google.com/d/msgid/swupdate/CAFrQVPOE5TNgd-i4dLvXST%2BKEYTNfSrrrN63zgpGGtLJQsYEkg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Stefan Herbrechtsmeier]

Hi Kyle,

Am 25.04.2021 22:52 schrieb Kyle Russell <bkyler...@gmail.com>:

Hi Stefan,

I think your suggestion would work since my configuration uses both systemd and sysvinit (via backfill) in DISTRO_FEATURES.  However, I wasn't really looking to change the current design (90-start-progress).

Replacing 90-start-progress with an init script would require both systemd and sysvinit in DISTRO_FEATURES,

Why? The recipe will provide an sysinit script and/or systemd service.

since without sysvinit, systemd.bbclass would remove files in /etc/init.d from the swupdate-progress package making swupdate-image again lose reboot functionality,

Why? The recipe provide a systemd service for swupdate-progress. Does you lose swupdate start functionality at the moment?

but I think requiring sysvinit in DISTRO_FEATURES if you use swupdate-image makes sense.  The packaging approach this patch suggests would not require sysvinit in your DISTRO_FEATURES, however.

A recipe should not install sysinit scripts if the distro does not support sysinit. You should use multiconfig or enable both init systems.

For example, if someone enabled systemd in DISTRO_FEATURES but listed sysvinit in DISTRO_FEATURES_BACKFILL_CONSIDERED, then the progress init script would be removed from the swupdate-progress package.  I think you could argue that configuration is invalid though, since swupdate-image requires sysvinit.

Yes. See above.

Regards

  Stefan

To view this discussion on the web visit https://groups.google.com/d/msgid/swupdate/CAFrQVPOE5TNgd-i4dLvXST%2BKEYTNfSrrrN63zgpGGtLJQsYEkg%40mail.gmail.com.

[Kyle Russell]

Stefan,

I don't understand your questions, but I think we're all in agreement.  I was just pointing out that both init systems will need to be enabled to correctly support your suggestion on my configuration, which I agree is correct.

I'll try to send out a different patch later today or tomorrow.

Kyle

To view this discussion on the web visit https://groups.google.com/d/msgid/swupdate/9d91ec3f-dc61-4265-9787-d253ff45a5cb%40email.android.com.

[Kyle Russell]

I finally got back around to revisiting this, and just posted an update patch on the group that replaces 90-start-progress with an init script that allows the swupdate-progress package to be easily added to swupdate-image to enable auto reboot functionality.

[meta-swupdate][PATCH] swupdate: add swupdate-progress init script for recovery image (https://groups.google.com/g/swupdate/c/HUxRqghuZMk)

Please try the new patch out when you get a chance and provide feedback.

Thanks,

Kyle