It's reproducible in Chrome OS 9765.39.0, 61.0.3163.62 on caroline, pyro, reks, celes, but not reproducible on link, falco. 

Able to reproduce this issue on M62 build 9901.5.0

Able to reproduce this issue on candy M62-9901.13.0

Able to reproduce this issue on M64 build 10176.4.0 
Tested on Ultima,Banjo,Wizpig and Candy

Able to reproduce this issue on M65 build 10323.2.0

Reproducible on EVE with M66 build 10452.1.0

my guess is that powering off during normal to delevloper mode could count as a critical error.  Is the expected behavior (repair screen) documented anywhere (to confirm it is expected)?

shchen@ has looked at screen transitions in the past so she might be equipped to triage or find the right owner

Observed the same on Relm with build version 10575.3.0/67.0.3396.0

Is the expected behavior (repair screen) documented anywhere (to confirm it is expected)?

assigning to Grace to triage and find an owner.  jwerner@ or dlaurie@ probably have the right background here (e.g. background on what constitutes a critical error and how critical errors are determined)

Looks like this is caused by https://chromium-review.googlesource.com/535846. Previously, the dev mode transition would wipe the whole stateful partition volume start to finish, so as soon as that started the partition would become unmountable. The new code will instead just delete some specific files containing encryption keys, then twiddle its thumbs for 5 minutes to enforce the minimum dev mode delay, and then zero out the file system header as the last step before fully booting into dev mode. If you forcefully reboot during those 5 minutes, the partition is still mountable and the /mnt/stateful_partition/factory_install_reset file that was used to kick off the to-dev wipe is still accessible, now misinterpreted by chromeos_startup as a request to powerwash.

If we want to fix this, an easy way would be to explicitly delete that file early in clobber-state. But whether that's really desirable behavior, I don't know... the behavior exercised by this "test" isn't something you're normally supposed to do anyway, so I'm not sure why we care about the outcome other than that it doesn't open any security holes. The code is technically correct in that a certain kind of wipe (keepimg but not fast) was requested and not fully completed, so it makes sense from that point of view that it would attempt to redo that wipe at the next opportunity. But if we want to explicitly care about allowing the "oh crap I didn't mean to make my device useless for 5 minutes" path for users, I don't see a problem with changing it either.

I'm happy to help analyze issues, but I was not involved in landing the code that changed this and this is not my bug.

i agree that this isn't an "important" bug as it isn't breaking behavior (wrt correctly clearing the stateful), and with the point that you're not really supposed to reboot in the middle of the transition, so lets lower the priority.

looking at the code in chromeos_startup and how it handles RESET_FILE, i think we can rework the code such that it's more robust and happens to not tickle this behavior.

currently, chromeos_startup will create RESET_FILE in the stateful partition if it detects a dev<->verified transition so those args get passed to `clobber-state`, but from what i can tell, we don't need to do it this way.  we could set $ARGS explicitly in the shell script and avoid this file entirely.  we rely on nvram state and files in the stateful partition being coherent with each other already to make sure things don't get out of sync.

i've posted an (untested) CL here:
  https://chromium-review.googlesource.com/1067157

Seeing in M71 as well. 

Seeing this in M72. Vapier@ any update on this based on comment #18.

i haven't tested the CL yet.  if someone else wants to verify it ;) ...