potential rollback issue

Powerwashing the device is OK - main question is, does 'p2p_update enable' clear the NVRAM/H1 flags that take the device out of FRE?

If device is still subject to FRE, then this is Working As Intended.

I don't think we clear the VPD in any case. Can you describe what exactly is running 'p2p_update enable' then 'rollback' mean? Can the students in schools to that?

I don't know what it does, but anyone who can access crosh can run that command (I just ran it on my enrolled, verified-boot chromebook).

I guess what we need is someone to try to repro this. This seems like a P0 if this is an enrollment escape. Igor/Marcus - can you guys try to repro this, and either close the bug if no-repro, or escalate as a P0 if so?

I tried to repro on edgar device, but rollback command fails with error "Rollback request failed" in update_engine_client.

Also the documentation for rollback states that it is available only for non-enrolled devices. So, if it succeeds then that's the first problem that needs to be fixed.
https://cs.corp.google.com/chromeos_public/src/platform2/crosh/crosh?type=cs&sq=package:&g=0&l=1301

contacted datachaz10@gmail.com for further details

This is not the enterprise rollback we're working on, but when you're falling back to the other partition after an update.

It checks whether the device is enterprise enrolled, and the command shouldn't succeed if it's enrolled:

http://cs/chromeos_public/src/aosp/system/update_engine/update_attempter.cc?l=705&rcl=0d6922092d04c4690af07b18d5d24a1893b82eba

to address several questions:
I have only been able to repro this on a CTL model J5 Chromebook. it doesn't look like the device is subject to FRE after the rollback, but on another Chromebook i've tried (Dell Chromebook 11), the rollback fails even with p2p_update enabled, and returns the same error as described by igorcov@chromium.org in Comment 7. i don't know if this is a configuration difference between the two devices or not. 

in summary, this seems to only work on CTL Model J5 Chromebooks via crosh. but on these machines, rollback is succeeding even with enterprise enrollment, but only if the user runs p2p_update enable. the devices do not seem to be subject to FRE after the rollback. trying to repro this on a CTl Model J5 Chromebook might help.

i'm not very experienced with Chromebooks or Chromium, so I can only help in a limited capacity. I will try to get a screen recording of this bug as soon as possible.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.