[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: preseeding in auto mode URL syntax without hardcoding directory of release name



john doe <johndoe65534@mail.com> writes:

> On 8/15/25 09:51, Philip Hands wrote:
>> john doe <johndoe65534@mail.com> writes:
>> 
>>> At [1, B.2.3] says that if an URL has no slash in it
>>> "d-i/trixie/./preseed.cfg" the default path will be used.
>>>
>>> Is there a way to have that same path for an other file than preseed.cfg
>>> (E.G: "url=example.com/alternative.cfg" would translate to
>>> "d-i/bookworm|trixie/./alternative.cfg")?
>> 
>> What you probably ought to be doing instead is specifying the option you
>> want via the `classes` setting (an alias for `auto-install/classes`),
>> and then implementing the behaviour you want by setting `preseed/run` in
>> a minimal preseed.cfg, and having a script do whatever you want in
>> response to the classes= setting you specified.
>> 
>> So your preseed.cfg would just be:
>> =-=-=-=
>> d-i	preseed/run	string start.sh
>> =-=-=-=
>> 
>> and your start.sh would be something like:
>> =-=-=-=
>> #!/bin/sh
>> . /usr/share/debconf/confmodule
>> 
>> db_get auto-install/classes
>> db_set preseed/include "${RET:-default}".cfg;;
>> =-=-=-=
>> (you might want to check that the value of $RET makes sense before using
>> it)
>> 
>> Then the real configs go in `default.cfg` and `alternative.cfg`
>> (assuming you're planning on specifying `classes=alternative`)
>> 
>
> Appreciate the detailed explanation and the example. With the provided 
> example everything works as desired provided that "classes=default" is 
> set as kernel boot parameter.
>
> Before I can contribute to your repo, I first need to better understand 
> how everything works.

Ah, when I said MRs welcome, I was referring to MRs for the general D-I
documentation.

Of course, if you have contributions to the hands-off preseeding
framework, that's great, but I don't think that's a good place to
document the use of classes & preseed/run simply because the people that
would benefit from that documentation are unlikely to find it if it's
hidden in my repo.

So, instead, I was hoping that you might have some idea where it would
have helped you most to have come across such documentation.

> E.G: what is the best way to test the start.sh SCR..

If you want to play further with hands-off, just try doing an automatic
install using url=hands.com (which should result in you being prompted
with "Here you can specify a list of classes ..." that can be seen in
start.sh, which will demonstrate that you're running start.sh).

The thing that's perhaps not immediately obvious is the filter scripts.

If a class has a filter script, it is used to filter the current set of
classes, which gives one the chance to add dependencies, or remove
conflicting classes from the set that is finally used.

Mostly these scripts are implemented via a script called filter_classes
that's part of the framework.  It allows one to add classes by simply
listing them, and remove classes by prefixing them with a '-'.

The framework pipes the set of classes through all of those classes'
filters, and repeats that action until the output matches the input.

After that, one (hopefully) has a consistent set of classes that then
get used to assemble the preseed snippets into a configuration, and
early and late scripts to be run.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Attachment: signature.asc
Description: PGP signature


Reply to: