Architecture for a Soft Reset

[sansyrox]

Is your feature request related to a problem? Please describe.

Currently. the factory reset architecture is broken in SUSI Linux.

Describe the solution you'd like

A possible architecture for the soft reset

1. There should be a stable version of the of our image on say "downloads.susi.ai" uploaded maybe manually to somehow distinguished from normal updates.

2. As soon as the installer starts, it should download the latest image along with the latest most stable image.

3. We then create a script that fetches update from the download.susi.ai to check if a new more stable image is available or not and if there is one, we download it if the internet is available and after a successful download(will be successful if say the size on disk is same the size info provided on the downloads website), we delete the previous backup image.

4. We can obviously connect the permissions and take those into account for auto-download of the stable images but I believe we should implement that afterward.

5. We now map the RPi button with a factory reset script and run the factory reset for more than say 7-second press and a sound warning(also a stretch feature) being played. Which will delete the latest version and extract from the backup we downloaded earlier.

And a solution in my mind to remove the excess/ faulty Debian packages that might occur, we can freeze a list of all the packages while building the stable image and get a diff between those packages and remove the diff.

[norbusan]

Hi @stealthanthrax

I agree we can do better with respect to reset features, but I propose the following

• first we check whether the current factory reset works (in the old and new images)
• we use a factory reset method that only uses data on the device, so it can be done offline
• we can offer soft (configuration remains) and hard (configuration is removed) reset

Separately, we provide update of firmware, which is a different issue then factory reset.

Eg, my Kobo reader comes with a factory reset, but that does not check for newer versions but installs what is on the device prepared for.

[sansyrox]

@norbusan , do you mean that we check for the new backup images in an update daemon?

[norbusan]

I wouldn't as daemon, but as a systemctl based Cron like job, better than having another job running.

[sansyrox]

Oh okay. That makes sense.

[hongquan]

systemctl based Cron like job

It is systemd timer.

[norbusan]

Yeah that one ;-)

[norbusan]

With the latest changes supporting soft and hard reset, we are a bit better off now. @stealthanthrax do you think we need more functionality then what is provided by now? If not, we can close this issue

[sansyrox]

@norbusan , I think we can close it now.