add a mechanism for reasonably diagnosing early boot issues

[q66]

Right now if there is an unexpected case or error in early boot, dinit will dump a whole lot of stop messages, obscuring what actually failed. There is no way to get the output; there is a good chance that it failed before root could even mount read-write yet, and --log-file expects starts-log service to have started already so it's pretty useless without doing hacky interventions in the system.

So best users can do is something like init=/bin/sh and then run like mount -t tmpfs none /somewhere and dinit --system|tee /somewhere/log.txt and see what went wrong to fix it and be able to boot the normal way.

Either making the output less uselessly dumpy (do we really need to know 20 services have stopped?) would help, or some kind of pager, or ...

[davmac314]

Still thinking about this. I agree that some solution is needed, not sure what the best option is yet.

[q66]

making --log-file not require starts-log would be a start (what's even the reasoning behind that requirement? i can see it for syslog, but...)

i'm thinking perhaps an service file option to make it "quiet" (i.e. no start/stop messages, only errors) would also help some, to declutter early boot

[davmac314]

making --log-file not require starts-log would be a start (what's even the reasoning behind that requirement? i can see it for syslog, but...)

The man page is actually out of date, it requires starts-rwfs rather than starts-log. Even this isn't perfect of course, it probably would be better to attempt opening the log file at the very beginning (and only if that fails, try again when root is writable).

[q66]

starts-rwfs is still no good, as it's perfectly reasonable that one may be writing the early log in a tmpfs

[davmac314]

Yep, hence:

it probably would be better to attempt opening the log file at the very beginning

[davmac314]

Recent commits aebcd39 and 7f1a0d1 also address this