How to simulate a factory reset (device failure)

1

Hi, I am trying to test recovering my device from a factory reset. The kind that happens when something keeps failing to the point where legato decides to reset itself?

I want to prove that my app I built into a CWE and flashed to the device does indeed remain and all other apps/files etc are removed.

PS I have a FX30/WP85 with R14, pressing and holding the reset button on startup for > 10secs, does not seem to have the desired effect, it does some sort of reset as the keys are changed… but it does not remove the apps I manually added ?

Thanks
Karl

2

I believe that the factory reset occurs when firmware has been marked bad, and there is no other known good firmware.

Perhaps you can manually mark the firmware as bad and reset the device? The startup procedure will handle the factory reset for you when it finds no other good firmware.

3

Hmmm that was a good idea… but “update -b” or “update --mark-bad” seems to have not effect on the status reported by “legato status”

Despite if being listed here as an option.

----UPDATED-----
Ahhh this would be why

“The command has no effect if the current system has already been marked good.”

4

in sysStatus.h there is the function sys_MarkBad(void);

You could try including sysStatus.h and calling that?
sysStatus_MarkBad contains the following:

static const char* CurrentStatusPath = CURRENT_SYSTEM_PATH "/status";

//--------------------------------------------------------------------------------------------------
/**
 * Mark the system "bad".
 */
//--------------------------------------------------------------------------------------------------
void sysStatus_MarkBad
(
    void
)
//--------------------------------------------------------------------------------------------------
{
    file_WriteStrAtomic(CurrentStatusPath, "bad", 0644 /* rw-r--r-- */);
}
5

I should have mentioned… I got it to mark it bad, by applying a new update. Which is then in probation for a short while. This is when you can either mark it good or bad. It did a reboot, however it then recovered to the previous “marked good” system. Which is not the original FW uploaded and includes the app I installed manually.

6

When you do an update it stores a number of previously good systems. By doing another update and marking it bad it will only revert the latest update.

The update daemon has no way of marking an existing good system as bad unless you recompile it - this shouldn’t be that hard to do btw, just comment out the check for an existing good system.

Knowing how sysStatus_MarkBad works, you can write a simple script to scp a file status with the contents “bad” to /legato/systems/current. But you can always ssh in and do it manually with:
echo "bad" > /legato/systems/current/status

7

I just tested with the following:

fwupdate download firmware.spk 192.168.2.2
update app.update 192.168.2.2

ssh root@192.168.2.2
echo bad > /legato/systems/current/status
reboot

I can confirm that the system was marked bad, and after rebooting only the master firmware was installed.

8

Ahh yes that makes sense in your example there is no “good” system other than the original FW.

Is it possible that in my example… it reverts to the previous “good” system, but then puts it into probation as well… So the thing that is making my new FW fail is also causing the older “good” system to be marked bad etc… until it gets to the initial FW?

I ask as that might explain what I am seeying?

Thanks,

9

A system is only put in probation after an update. If it reverts to a previous good system then that system is still good.

The only way (that I can think of) to get it to revert from a good system to a previous good system is to manually mark it bad.

Your original question was oriented around proving that your app bundled with a new master firmware could not be removed when it is marked as bad. I believe following this procedure proves this.

  1. install master firmware with bundled app
  2. apply update with second app
  3. mark system bad and reset
  4. wait for rollback
  5. mark system bad and reset
  6. wait for rollback

After step 4 you will see the system has rolled back to your master firmware. This step proves that the system is rolling back after being manually marked bad.
After step 6 you will see that the system is still on the master firmware with your bundled app. This proves that your bundled app is part of the master firmware and will never be removed in a rollback.

10

Thanks, that makes sense.

11

Hi,
I have also tried to simulate a roll-back of the “golden system”, but I cannot mark a “good system” as bad. (with the updat -b comand ) only if it’s “an tried 1”. Do you know how to mark a “good system” as bad?
Thank you

12

It has been quite a while since I have played with this, but this was my solution:

1 Like
13

Ok Shib, thank you.
I’m going to try with echo bad command.
regards

14

This thread has some more info about how I came up with that solution.
Basically, that is what the sysStatus_MarkBad command is doing.
Echo bad just lets you execute that from the command line.

15

Sorry, Which thread do you said? the previous link or have you forgotten attach the link?
regards

16

I mean the thread we are currently in.
If you read through the discussion you can see how I came to the “echo bad” solution.

17

OK,
Echo bad is the solution for me. Thank you!