Setting priority, since we expect to want to debug some M54 issues with this.

woaaaaah nelly, hold up.  don't go doing this.

#3: OK, but are there any good alternatives? At the moment, the best I can think of is to get someone to repro issues in dev mode and collect dumps manually from there.

BTW, my description is misleading: devcoredump is partially text, but mostly binary.

sorry, needed time to find history ... wanted to make sure no one started flipping any bits before a good talking over :)

see  issue 464872  and the linked design docs (and to a lesser degree, issue 465513).  long story short -- we can't launch this w/out design & sign off by teams due to the PII aspect.  and i'm not sure that can happen considering the nature of these dumps.

we might be able to do a subset it if we restrict things as described in issue 465513.

Ah, I see there's an opt-in crosh `upload_devcoredumps [enable | disable]`. And pstew suggested this feature is available here:

https://bugs.chromium.org/p/chromium/issues/detail?id=465513

So if specific users want to opt in, is that sufficient? That might handle our needs.

Well, I haven't been able to get an answer to #7 outside this bug (and it's not for lack of trying, really; though maybe lack of time). It looks like the crosh command does NOT on its own enable devcoredumps. My best guess now seems like there's some kind of policy decision on the server backend, but I haven't completely ruled out all client issues.

Anyway, lowering priority, since I'm getting along OK without it.

I'm not looking at this. But it's also not Untriaged really.