What keeps a non managed Chromebook from rolling back

[david....@gmail.com]

I have used Canary on my Chromebooks for the past 6 or 7 years. Maybe once or twice a year I need to wipe and go back to stable or beta to wait out an update that fixes a really unstable release. In these situations, it would be nice to roll back to yesterday. and skip an update or two until something is updated. I usually post bugs or watch existing so I do have a clue when it is safe to go back into the water. It doesn't take much more than 20 minutes to do a powerwash and get back to where you were and running a recover image repair doesn't add a whole lot of time but it would be really nice to be able to just go back. Does anyone know a way to tweak some file or whatever to enable a rollback?

Thanks for listening.

[Nom De Plume]

I didn't even try that command. On previous Chromebooks update_engine_client --rollback always gave me "unavailable". I was under the impression, rollback was only available to enterprise or managed devices. Rollback does appear to be available to me. I think my new CB a Spin 713 comes with an Enterprise license so that may be why. Thanks for making me look. Unfortunately, I ran the rollback without the --nopowerwash flag so I am committed to going through a powerwash. Twenty minutes isn't too much time to give up to test this great find.  Thanks again

On Wed, Jul 21, 2021 at 4:18 PM Michael Siejak <msie...@gmail.com> wrote:

There's a crosh command for that. I think you may also be able to use update_engine_client but I'm not aure

On Wed, Jul 21, 2021, 5:03 PM david....@gmail.com <david....@gmail.com> wrote:

I have used Canary on my Chromebooks for the past 6 or 7 years. Maybe once or twice a year I need to wipe and go back to stable or beta to wait out an update that fixes a really unstable release. In these situations, it would be nice to roll back to yesterday. and skip an update or two until something is updated. I usually post bugs or watch existing so I do have a clue when it is safe to go back into the water. It doesn't take much more than 20 minutes to do a powerwash and get back to where you were and running a recover image repair doesn't add a whole lot of time but it would be really nice to be able to just go back. Does anyone know a way to tweak some file or whatever to enable a rollback?

Thanks for listening.

--
--
Chromium OS Discussion mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-discuss
---
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

[Nom De Plume]

I did a reset_status and then ran the rollback again and the nopowerwash flag took effect.

[Michael Siejak]

There's a crosh command for that. I think you may also be able to use update_engine_client but I'm not aure

On Wed, Jul 21, 2021, 5:03 PM david....@gmail.com <david....@gmail.com> wrote:

I have used Canary on my Chromebooks for the past 6 or 7 years. Maybe once or twice a year I need to wipe and go back to stable or beta to wait out an update that fixes a really unstable release. In these situations, it would be nice to roll back to yesterday. and skip an update or two until something is updated. I usually post bugs or watch existing so I do have a clue when it is safe to go back into the water. It doesn't take much more than 20 minutes to do a powerwash and get back to where you were and running a recover image repair doesn't add a whole lot of time but it would be really nice to be able to just go back. Does anyone know a way to tweak some file or whatever to enable a rollback?

Thanks for listening.

--

[david....@gmail.com]

I will update this just in case someone else comes looking. 

The update_engine_client --rollback has always given me an "unavailable" response so I wasn't expecting anything different on my new Chromebook. To my surprise, I got an immediate restart message but was accompanied by a powerwash notification. I ran a update_engine_client --reset_status and then a update_engine_client --rollback --nopowerwash and it indicated that the rollback would be performed without powerwash. Unfortunately, it seems the first rollback command took and the second was ignored. An extra 20 minutes signing in and getting set up wasn't a huge hardship. I successfully did a rolback. I am only speculating here, because I don't know this for certain, but I was under the impression that only managed devices could rollback. The Acer Spin 713 either comes with an Enterprise License or can come with the same so that may be the reason I was successful. Just a guess. At any rate, when I tried to update, I was met with "updates have been blocked by the administrator" message. Since my Chromebook is not a managed device, I have no way to unblock updates. I could see nothing in available flags with update_engine_client that would reset the block. Not wanting to wait to figure things out, I did a recovery image. I was a little worried that the blocked condition would remain, much like the enrolled condition can't be undone but the recovery restore was successful and I am back to normal. Overall, I learned a lot about the process and the loss of an hour wasn't too bad for some lessons. I still have some questions if anyone from the Chromium team is available.
Is there a way to cancel a rollback attempt?

Is there a way to unblock the update in an unmanaged device?

If there isn't a way to unblock, why not?

[DennisLfromGA]

In dev mode you can use `update_client_engine` options like '--rollback --nopowerwash' to boot the alternate boot pair with the last version installed, as you mention above but with a couple of `cgpt` commands you can do the same thing. See the screenshot below and the two `cgpt` commands near the bottom -

( the screenshot above is from a script I wrote but that shows what the current/alternate boot pairs contain for reference )

The only semi-tricky part is figuring out which boot kernel partition is active (`rootdev -s`) and then switching to the non-active boot kernel.

[david....@gmail.com]

That sounds like a much simpler approach. Would you mind sharing your script? May I ask how it deals with updates. Do you need to switch boot partitions again to get updates again?

[DennisLfromGA]

david,

Here is a link to the script: 'priority'

It would probably be more aptly named as 'bootpairs' or something more creative I guess.

It's a script I kludged together and I do not guarantee that it will work flawlessly so just be forewarned.

Please take a look at the script source and be sure it's something you want to run.

When an update arrives, the update process sets a flag to prevent the alternate boot kernel from mounting, if I encounter this I throw a warning:

    "Cannot mount '/var/$ALT_ROOT_NODEV', perhaps a new update is waiting."

    "No alternate releases, milestones, or track info. is available at the moment."

If you see that message it often means that an update is downloading or ready so it's best to wait for an update notice and reboot. Then if you want/need to re-prioritize the boot kernel you can run the script.

[david....@gmail.com]

Dennis,

Thank you so much, Sir. You have imparted much wisdom over the years and I truly thank you for that and now for this script. Just to help my brain, when I revert to an earlier boot pair, an update will be applied to the newer boot pair. If things are still broken in the update, I can run the script again and revert to the old boot pair again.

Many many thanks

[DennisLfromGA]

David,

> Just to help my brain, when I revert to an earlier boot pair, an update will be applied to the newer boot pair. If things are still broken in the update, I can run the script again and revert to the old boot pair again.

Exactly, in fact, I've had to do that roundabout cycle a few times to keep a sane system.

I usually test a new version and if it's giving me issues I'll run the script and revert/rollback to the previously installed version.

There used to be a flag, shown below, that would continually check for new updates but I don't see that flag in the dev channel anymore. :-(

[david....@gmail.com]

Thanks for the clarification. Your script is a simple straightforward way to swap back and forth. Using update_engine doesn't seem to make sense since there doesn't appear to be a way to reverse the rollback. The fact that you are in developer mode certainly indicates someone has taken the risk but blocking further updates makes no sense. 

On my old ARM-based Chromebook, anytime I tried the rollback with update_engine, I got an "unavailable". I was surprised I was able to use update_engine on my new CB. Do you know why the difference?

[DennisLfromGA]

David,

Earlier, you mentioned a couple of things ...

> "... but I was under the impression that only managed devices could rollback."

You may be aware of this but you can perform a powerwash & revert/rollback from the sign-in screen, see below:

• Power on the device and wait for the sign-in screen.
• Press Ctrl + Alt + Shift + R to bring up the Powerwash option. 
• Press Ctrl + Alt + Shift + R again, then select Powerwash and Revert and follow the on-screen prompts.
  The Powerwash will start and roll back your Chromebook to the previously installed build.

And you said ...

> "... it would be nice to roll back to yesterday. and skip an update or two until something is updated."

There is/was a 'Metered network' option available, behind a flag, see below:

And a companion toggle in Settings, see below:

When this is toggled on it prevents system updates until you explicitly request them, see below:

I know it wasn't designed for this purpose on a home network but it served the purpose.

Unfortunately, I no longer find the flag in the dev channel nor the Setting in Networks. :-(

[david....@gmail.com]

Thanks, and yes I was aware of the 4 finger salute ;-). There is a rollback in crosh too. I like the nopowerwash capability. I powerwash a lot. I report bugs and I often want to do a powerwash just to make sure what I am seeing isn't just some corruption. Any time I don't have the time, I would rather just get myself back to yesterday if something is wonky. I have my pre and post PW routine fairly well practiced at this point and it doesn't usually take more than 20 minutes. Apps install in the background as well as the Linux restore, but I can be working away again, while that happens. Anyway, your script eliminates all of that and makes swapping back and forth a simple operation and it is exactly what I want.

[david....@gmail.com]

Dennis,

What an absolute treat your script is. I have been switching back and forth on my ARM CB 
So many anomalies with Canary are resolved the next day or two later. I usually wait for at least one update before reporting a bug. In most cases once reported and gets acknowledged, it may take a few days (months once) for the fix to be pushed out. Your script makes the wait time doable. WOW!!!!

Thank you so much, sir.