Erik Nordmark

Looks like you removed all pushing for release branches. Is that the case? Or does the release branch push happen somewhere else?

> We have an issue: we want to be able to debug kernel core dumps. I don't disagree that it is a "good thing" tm , but do we actually...

> Current: > > 1. We have a kernel panic > 2. Panic message and stack trace to console > 3. Device hangs @deitch in step 3 the device reboots....

> "panic=120" kernel command line from grub or to modify the CONFIG_PANIC_TIMEOUT (which is set to 0 now). So the "device hang" problem remains. Seems like we need to set...

> How will that capture it? By the time the kernel panics, you are long past any `kdump` having started and exited. And wouldn't you still need to run kexec...

Without the additional onboot container we cane up with (but not yet in the pr) it would start the service containers and @rouming tried to prevent that.

> onboot and service containers were launched way earlier (steps 4 and 5). Why would they launch again? Unless step 9 launches regular `init`? Why would it do that? My...

@giggsoff to avoid growing the aggegate heap, can't we still start zedbox first (e.g., from a new onboot container), and then have the other containers invoke their agent as they...

> I have a hard time seeing that. These `services` containers are meant to be long-lived and contain (at least) one process. Having it run just as as signaling mechanism...

> should not a service that needs a dir just do a `mkdir -p` (or equivalent, I guess `os.MkdirAll()` if in go)? If not, then it could be an onboot,...