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.
Regards, Glen > On Feb 16, 2022, at 5:19 PM, Glen Huang <[email protected]> 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 > > Thoughts? > > Regards, > Glen
