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
