Headless build (inc LXC container) inithooks hang if only partially preseeded

[JedMeister]

Split from #1071

@Dude4Linux wrote:

I discovered another issue related to pre-seeding containers. bt-container sets REDIRECT_OUTPUT=true in /etc/default/inithooks. If any of the firstboot.d scripts prompt for user input, the process hangs. I'm not sure if it will ever timeout as I don't have the patience to wait. I got bit be the recent addition of /usr/lib/inithooks/firstboot.d/85secalerts which prompts the user for an email address. I had to add export SEC_ALERTS=SKIP to the pre-seeded /etc/inithooks.conf.

IIRC that should only apply if the user partially preseeds. The way it's meant to work for all "headless" builds (and the way it did work for v14.x bt-container builds, at least on Proxmox) was that the inithooks run twice, once self-preseeded (which is what brings up the fence). Then they re-run interactively, and sit there waiting for the user to log in

Regardless, it's a good point and I think we should make things better, although TBH, I'm not exactly sure of the best approach. AFAIK it won't time out, so we should perhaps consider something like that, at least when REDIRECT_OUTPUT=true is set.

FWIW I'm pretty sure that SEC_ALERTS was added for v14.0 (~3 years ago), so I'm not sure why you haven't hit that previously?!

I do try to keep the inithooks Readme up to date (although in fairness, I only finalised it for v14.2 a few months ago).

Regardless, I think this issue deserves some consideration and conversation. Either some code to check that all required preseed values have been set, or alternatively, some timeout mechanism is REDIRECT_OUTPUT=true.

[OnGle]

I think a timeout would be easy, it still presents a tricky problem in that we need 2 tasks running concurrently. 1 to sit and wait on the dialog subprocess waiting for input and another to manage the timeout. I think there might be a way to avoid this and handle both in the same thread but I'm not sure and either way it's more an inconvenience than a real challenge.

The other thing you could do is simply error very early on if the preseeds file is incomplete, I might be a shock to some users but IMO a failure with explicit error message is far more useful than an indefinite hang. If you errored early this would probably be even easier than a timeout.

[JedMeister]

a failure with explicit error message is far more useful than an indefinite hang

Agreed! That may be the ideal way to go.

Whilst a timeout would be another option, actually I think a "clean" failure is probably better. On reflection, a timeout on a preseeded deployment isn't actually going to achieve anything (because it's never going to get any further input).

Thinking aloud here; perhaps use a default value, but also log an error?