FWIW, the user experience here is pretty awful, it's not clear what the fix is (re-image the device?). Removing an enterprise account is probably unusual so I didn't make it a P0, but it's still pretty concerning.

Can you grab chrome log and kernel log for the re-adding step?

It is not a development device. I can log in after an attempt with a guest account and file a feedback report if that will help?

That should work. The interesting logs are in system logs.

Here's the feedback report filed from a Guest login after attempting to add a new @google.com user, looping through the UI twice (i.e. I entered my email and password + security key touch twice):

https://listnr.corp.google.com/product/208/reports?searchText=772940&filter=1&dateRange=All

+apronin

Ext4 fs corruption has prevented the account's cryptohome being removed. We hit this line [1]. And we stuck in this state. apronin@, thoughts?

2017-10-09T11:36:00.396023-07:00 WARNING cryptohomed[1992]: No valid keysets on disk for 0844960f9653aabba6c8de921e28bef3931c93c8
2017-10-09T11:36:00.396065-07:00 ERR cryptohomed[1992]: Failed to decrypt any keysets for 0844960f9653aabba6c8de921e28bef3931c93c8
2017-10-09T11:36:00.396082-07:00 ERR cryptohomed[1992]: Error, cryptohome must be re-created because of fatal error.
2017-10-09T11:36:00.725079-07:00 CRIT kernel: [   53.394142] EXT4-fs error (device sda1): ext4_lookup:1593: inode #3407917: comm MountThread: deleted inode referenced: 3408842
2017-10-09T11:36:00.737065-07:00 CRIT kernel: [   53.406574] EXT4-fs error (device sda1): ext4_lookup:1593: inode #3407917: comm MountThread: deleted inode referenced: 3408842
2017-10-09T11:36:00.737163-07:00 ERR cryptohomed[1992]: Fatal decryption error, but unable to remove cryptohome.

[1] https://cs.corp.google.com/chromeos_public/src/platform2/cryptohome/mount.cc?rcl=c4c4b3027670c8bddd1d52ecd603edbb84c03eb4&l=439

+gwendal, can it be dup of issue 766347 /  issue 760007 ? The bug is seen on M61, 9765.79.0. And as I understand this part of the fix (https://crrev.com/c/690438) was not picked to M61.

Or issue 693439? There we suspected issues with a particular SSD model, right?

As a side note, there's this CL https://crrev.com/c/475030 that makes cryptohomed a bit more resilient: if it fails to remove user directory, it moves it to a special 'stale' directory instead (and attempts deleting later). There are pros and cons associated with this approach, so we focused on dealing with root causes of those filesystem errors, and this CL was abandoned.

In the current state, if cryptohomed consistently fails to remove a particular user directory (even after reboots, e.g. due to filesystem errors), the only recovery is powerwash.

Why is this restrict view?

I linked a feedback report. The links are internal but... paranoia. Also we don't have to be as careful about pasting output from the feedback report here. So far I don't see anyhing concerning if you want to switch it back.

RVG has been getting SERIOUSLY overused lately so I'm trying to police it.

We link to feedback reports all the time, so in this case I'm going to unrestrict.

In the log at #6 [Report ID: 75682347995], I see stateful is not happy:
[    1.390464] EXT4-fs (sda1): warning: mounting fs with errors, running e2fsck is recommended

#1: Does it happen after you re-image the machine?
#8: https://crrev.com/c/690438 is a cleaner version of the fix, can expand beyond flash. 760007 is taken care of: it guarantees no new corruption will happen, but existing corruption are not fixed. Running fsck can be dangerous, you may lose files.

samus SSD [Kingston] has its own problem, we are power cycle it at reboot when we should not and it can lead to lost data. Looking in the event log, recovery button was pressed on 4/10/2017. I am wondering if a file system corruption happened at that time.

Removing Enterprise Component for now because I assume this is not related to Enterprise management. Feel free to re-add it if you think otherwise.

rkc@ is there actionable work remaining on this bug?

I am not sure if this even repros.

If this still repros, please re-open.