Re: Would allowing preseed to be a tarball a good idea?
On Wed, Feb 16, 2022 at 05:32:23PM +0800, Glen Huang wrote:
> > On Feb 16, 2022, at 5:19 PM, Glen Huang <heyhgl@gmail.com> wrote:
> >
> > Hi,
> >
> > Currently, the preseed file needs to be a text file. I find it to
> > be a bit limiting, especially if you want to do some non-trivial
> > scripting in either early_command or late_command (let's call them
> > runners). There are basically four options to address it AFAIK:
> >
> > 1. Strictly use one-liners in runners.
> > 2. Bundle the scripts in the install media, to be called by the
> > runners.
> > 3. Make runners download the scripts and then run them.
> > 4. Embed the scripts in preseed and then make runners redownload it,
> > parse the scripts out and run them.
> >
> > All of them are flawed:
> >
> > 1. If done manually, this is really awkward, and since in-target
> > uses chroot under the hood, you can’t use redirects directly,
> > not without sh -c, also awkward.
> > 2. The official install media can no longer be used directly, and
> > for a lot environments using a custom install media is not an option.
> > 3. This means you need to set up a web server that the installer
> > can access, which is quite painful, and the installer might not have
> > access to the Internet.
> > 4. This is the approach I currently take. However, it’s also
> > quite awkward, since each line of the embedded content has to be
> > commented out, and you also have to invent ad hoc file delimiters,
> > and it doesn’t work for binary files (unless (en|de)coded by base64
> > of course).
> >
> > I think there are many cases that require non-trial scripting. A
> > strong one could be doing provisioning in late_command.
> >
> > I wonder if allowing preseed to be a tarball would be a good idea? It
> > could define a content structure like this:
> >
> > early_commands/ # run executables in it at the point of early_command
> > late_commands/ # run executables in it at the point of late_command
> > late_in_target_commands/ # run executables in it at the point of late_command, chrooted to /target
> > in_target_files/ # files in it are copied to /target after installation finishes, maybe before late_command
>
> Forgot a few things.
>
> 1. #4 also means the preseed file needs be downloaded twice, since
> the one downloaded by the installer is immediately removed once the
> preseed is loaded into debconf db, before early_command.
> 2. Files parsed out in #4 needs to be stored somewhere. No matter
> where you place them, there is no guarantee that (future versions of)
> d-i won’t touch them.
> 3. The tarball should contain a /preseed file to provide the preseed.
> >
> > Thoughts?
The initrd of d-i can indeed be extended / appended.
And in the "appendix" goes the desired extras. Then
d-i preseed/early_commands /myextras/early_script
Groeten
Geert Stappers
--
Silence is hard to parse
Reply to: