Looking at the context of those logs, I'm not super confident that EXT4-fs line is relevant. 
- Most operating systems go through automatic FS type detection
- And its possible that in this case ext2 was mounted by ext4 subsystem 
- There is no evidence that it would have caused an issue just because of the presence of this line
- We need to check when the ext4 subsystem was introduced. It could predate M61.

2017-08-21T18:51:34.068686+00:00 ERR kernel: [    1.407992] EXT4-fs (dm-0): couldn't mount as ext3 due to feature incompatibilities
2017-08-21T18:51:34.068687+00:00 INFO kernel: [    1.408193] EXT4-fs (dm-0): mounting ext2 file system using the ext4 subsystem
2017-08-21T18:51:34.068689+00:00 INFO kernel: [    1.409495] EXT4-fs (dm-0): mounted filesystem without journal. Opts: (null) 

Approving merge to M61 Chrome OS.

Hi Gwendal, can you check if the error message is of concern or not? We are seeing data lost causing unenrollment of CFM.

#3, this is expected: dm-0 (root partition) is using ext2, but we use ext4 as the driver in the kernel. It tries ext3 first and rollback to ext2.

Hi Bin,

We are trying to chase down enterprise enrollment issue, can you tell us who is the best engineer to discuss this?

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

i'm removing the launch blocker - imo, we have rooms that exhibit unexpected unenrollment issues already and we have no specific data that this is a specific regression 

other issues about losing stateful information seems to have been cleared up in other bugs (ie changing domains so changing file names of where data is stored)