On Wed, Feb 16, 2022 at 05:32:23PM +0800, Glen Huang wrote: > > On Feb 16, 2022, at 5:19 PM, Glen Huang <hey...@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
