install/60939: installer: Pre-seed answers?

["jbglaw%lug-owl.de@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60939
>Category:       install
>Synopsis:       installer: Pre-seed answers?
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    install-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 29 19:45:00 +0000 2026
>Originator:     Jan-Benedict Glaw
>Release:        current
>Organization:
>Environment:
>Description:
I'm doing a lot of test builds and also install these into VMs (Qemu, SIMH), kind of similar to anita, though I'm using plain expect scripts.

In the past, I noticed that new questions showed up, or some are only asked sometimes, ...  The result in anita is visible: It's guesstimating its way through the questions, trying to keep the installation running based on the "large topics" by looping through all current possible questions.

It seems the current menu system doesn't offer to tie a config key to every dialog, so that it could be pre-seeded easily. However, it would be nice to have! There could be an early-on approach to bring up NICs through DHCP and download a seed file, or enter into some menu as early as choosing the installation language where seeds could be placed. Any approach would be welcomed.
>How-To-Repeat:
Just run the installation and observe differences due to unplanned factors. I've seen questions about missing entropy, or setting a time, but only:

#ifdef BUILD_TIMESTAMP
static void
check_todr_sanity(void)
{
        time_t now = time(NULL);

        if (now >= BUILD_TIMESTAMP - 2*86400)
                return;

        do_time_and_date_setup(MSG_todr_old);
}
#endif


I'd love to just push in answers for anything, without actually having to care for (most of) the expect'ed questions.
>Fix:
Introduce some technical key to any question that is asked and have a way to pre-seed those. Keep in mind that yes-no questions that are now implemented as _one_ dialog need to be split on their actual purpose.

This PR shall just be about discussing IF that's something that should be implemented in some way or another. Or if I better learn to deal with it in expect. ;-)