Hi Primož,
On 7/8/26 08:01, Primož Fišer wrote:
> Hi,
>
> As a workaround, I now do exactly this:
>
> {
> filename = "customer-test-image-@@MACHINE@@.rootfs.ext4.verity";
> path = "/data/swu-rootfs.ext4.verity";
> sha256 = "$swupdate_get_sha256(customer-test-image-
> @@MACHINE@@.rootfs.ext4.verity)";
> },
>
> and install the image via the script's postinst function like so:
>
> dd if=/data/swu-rootfs.ext4.verity of=/dev/mapper/inactive_crypt
> bs=16K conv=fsync
>
> And it works just fine!
>
> After rebooting, I can successfully boot into the flashed slot.
>
> I am puzzled why it doesn't work with the original concept.
>
I read the logs and I am not sure about the cause, but definitely it is
related to something in the environment or your update concept. Which is
the reason for set-bootstate-slot1.sh and are you sure this is not
changing the behavior ? Do you have cryptsetup commands there ?
From SWUpdate point of view, there is no difference to write into the
underlying mmc block device or into the device mapper. They are both
block devices and the same handler is used ("raw"). My feeling is that
you are doing something with cryptsetup in the preinst, and as Ayoub
suggested, dm-mapper is not ready when SWUpdate starts to write. Think
about that, while with scripts you are adding implicitly pauses, this
does not happen with SWUpdate and it starts to write.
And again, as already said a lot of times on the ML: do not use shell
scripts but Lua hooks. You are using a pre-install shell script. This is
part of the SWU, and it can be at any place in the SWU itself. Even at
the end. It is not mandatory to package the script before the artifacts.
That means: SWUpdate installs *FIRST* all artifacts with the
"installed-directly" flag set, and then it will run scripts (also
pre-inst script, that aren't pre- anymore) after that. It cannot do in
another way, the stream is coming and artifact must be installed as it
comes.
So your pre-inst is running after SWUpdate has already started to write
into inactive_crypt, and then fails (maybe because you are setting the
dm-mapper).
Your concept is wrong.
- do not use shell script - SWUpdate can determine automatically where
rootfs is mounted, see "getroot". This can be called inside Lua hooks as
swupdate.getroot()
- set up just once the encrypted partitions when you are booting, that
is both active and inactive dm-mapper.
- if you still need something to be done before installing, use
"embedded-script" inside sw-description and add a hook to the image.
Best regards,
Stefano Babic
> <mailto:
ayoub...@googlemail.com>' via swupdate
> <
swup...@googlegroups.com <mailto:
swup...@googlegroups.com>> napisala:
>
> this is defintely not an issue related to swupdate:
>
> test it this way :
>
> dd if=/patht/to/customer-test-image-imx93-customer-
> gw.rootfs.ext4.verity of=/dev/mapper/inactive_crypt bs=1M
>
> and try then to mount it:
>
> mount /dev/mapper/inactive_crypt /mnt
>
>
>
> On Tuesday, July 7, 2026 at 1:22:44 PM UTC+2 Primož Fišer wrote:
>
> Here is full output:
>
> _Verify sha256:_
>
> root@imx93-customer-gw:/data/swu_extract# cpio -idmv < ../
> customer-test-swupdate-image-imx93-customer-gw.rootfs.swu
> set-bootstate-slot1.sh
> set-bootstate-slot2.sh
> customer-test-image-imx93-customer-gw.rootfs.ext4.verity
> imx-boot
> fitImage-customer-image-initramfs-imx93-customer-gw-imx93-
> customer-gw
> 976335 blocks
> root@imx93-customer-gw:/data/swu_extract# sha256sum customer-
> test-image-imx93-customer-gw.rootfs.ext4.verity
> *16025a1ef9649ce8affc676647730901c0129269a13d76879058ae45b46e267c*
> root@imx93-customer-gw:/swu_extract# cat sw-description | grep
> 16025a1ef9649ce8affc676647730901c0129269
> sha256 =
> "*16025a1ef9649ce8affc676647730901c0129269a13d76879058ae45b46e267c*";
>
> _SWUpdate error:_
> *16025a1ef9649ce8affc676647730901c0129269a13d76879058ae45b46e267c* <--> 7c5879f8641abcc3d7d7e04d6dbedf88cbc99e3c554e63138e91e
> 07c4cb42595
> [TRACE] : SWUPDATE running : [install_single_image] : Installer
> for raw not successful !
> [ERROR] : SWUPDATE failed [1] Installation failed !
> [TRACE] : SWUPDATE running : [__run_cmd] : /tmp/scripts/set-
> bootstate-slot1.sh postfailure command returned 0
> [ERROR] : SWUPDATE failed [0] ERROR install_from_file.c :
> endupdate : 55 : SWUpdate *failed* !
> [TRACE] : SWUPDATE running : [unlink_sockets] : unlink socket /
> tmp/sockinstctrl
> [TRACE] : SWUPDATE running : [unlink_sockets] : unlink socket /
> tmp/swupdateprog
> <
https://groups.google.com/d/topic/swupdate/v39HFdUO4qM/
> unsubscribe>.
> dc16a5182f2fn%
40googlegroups.com <
https://groups.google.com/
> d/msgid/swupdate/d666ec27-f487-44ea-993b-
> dc16a5182f2fn%
40googlegroups.com?
> utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "swupdate" group.
> To unsubscribe from this topic, visit
https://groups.google.com/d/
> topic/swupdate/v39HFdUO4qM/unsubscribe <
https://groups.google.com/d/
> topic/swupdate/v39HFdUO4qM/unsubscribe>.
> <mailto:
swupdate+u...@googlegroups.com>.
> swupdate/18a86bcf-8e5d-4960-9787-d2c4ef6237e6n%
40googlegroups.com
> <
https://groups.google.com/d/msgid/swupdate/18a86bcf-8e5d-4960-9787-
> d2c4ef6237e6n%
40googlegroups.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+u...@googlegroups.com>.
> swupdate/CAP4a-mmSNJozpQer6%2B1G4Hmgu0i-
> VPS5WPELx6YiY_R_eJDy_w%
40mail.gmail.com <
https://groups.google.com/d/
> msgid/swupdate/CAP4a-mmSNJozpQer6%2B1G4Hmgu0i-
> VPS5WPELx6YiY_R_eJDy_w%
40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel:
+49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail:
sba...@nabladev.com