FUM rework discussion

[PLangowski]

The problem you're addressing (if any)

Firmware Update Mode is a useful feature, as it, among other things, unlocks the Flash Descriptor, which is difficult to do otherwise. However, it proceeds with the update automatically, which does not allow enrolling DPP credentials and therefore updating to DPP firmware. There are solutions that allow working around this, but I think it's worth discussing if this behavior should be changed. If FUM only prepared firmware for flashing and booted DTS without performing the update automatically, it could become a more universal feature.

Describe the solution you'd like

No response

Where is the value to a user, and who might that user be?

No response

Describe alternatives you've considered

No response

Additional context

No response

[miczyg1]

However, it proceeds with the update automatically, which does not allow enrolling DPP credentials and therefore updating to DPP firmware.

It makes the FUM close to useless in such case. We release more DPP than community releases recently.

I think DTS could ask for credentials if it detects that DPP update is possible and DPP credentials have not yet been provided in the main menu,

[m-iwanicki]

Probably duplicate of: #712

About FUM I think automatic update didn't work between 2.0.0 (kernel change) and 2.1.0 (fix).

To disable automatic update we could just remove this if: https://github.com/Dasharo/dts-scripts/blob/143964b9955ee7978f9fabf4a8d94f214ce9f78b/scripts/dts-boot#L49 and only keep else part

[krystian-hebel]

To disable automatic update we could just remove this if

It was added on demand after one of our clients asked for it specifically. I think it would be better to move $SBIN_DIR/dts outside of else, and allow $SBIN_DIR/dasharo-deploy update fum to return if the timeout is aborted.

[PLangowski]

@krystian-hebel Unfortunately, after interrupting the update, dts-boot is executed again. A different approach is needed.

[PLangowski]

The problem is that for some reason the dts script catches an exit signal and dts-boot is launched again.

+[11:43:29.922]:/usr/sbin/dts:29:main: show_header
+[11:43:29.922]:/usr/sbin/dts-functions.sh:1292:show_header: local _os_version
++[11:43:29.923]:/usr/sbin/dts-functions.sh:1293:show_header: grep VERSION_ID /etc/os-release
++[11:43:29.923]:/usr/sbin/dts-functions.sh:1293:show_header: cut -d = -f 2-
+[11:43:29.924]:/usr/sbin/dts-functions.sh:1293:show_header: _os_version=2.1.3
+[11:43:29.925]:/usr/sbin/dts-functions.sh:1294:show_header: printf '\ec'
++[11:43:29.925]:/usr/sbin/dts-functions.sh:1:show_header: wait_for_input
++[11:43:29.926]:/usr/sbin/dts:16:wait_for_input: code=0
++[11:43:29.927]:/usr/sbin/dts:17:wait_for_input: [[ 0 -ne 0 ]]
++[11:43:29.927]:/usr/sbin/dts:20:wait_for_input: exit 0
+[11:43:29.987]:/usr/sbin/dts-boot:35:main: start_logging

We don't know why that happens