On Feb 16, 2022, at 5:19 PM, Glen Huang <heyhgl@gmail.com> wrote:it AFAIK:
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
1. Strictly use one-liners in runners.coded by base64 of course).
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)
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
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:
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?
On Feb 16, 2022, at 5:48 PM, Philip Hands <phil@hands.com> wrote:
Glen Huang <heyhgl@gmail.com> writes:
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:
You can do rather complicated stuff actually, as seen in my (somewhat
rusty) example here:
https://hands.com/d-i/
On Feb 16, 2022, at 5:50 PM, Geert Stappers <stappers@stappers.nl> wrote:
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
@Philip
On Feb 16, 2022, at 5:48 PM, Philip Hands <phil@hands.com> wrote:
Glen Huang <heyhgl@gmail.com> writes:
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:
You can do rather complicated stuff actually, as seen in my (somewhat rusty) example here:
https://hands.com/d-i/
I learned a few tricks, thanks for sharing it.
I didn’t know about preseed/run, somehow missed it when reading
the doc for the first time. It does #3 in a pretty elegant way, and
with pressef_fetch, they basically allow me to treat the web server
as a tarball.
@Geert
On Feb 16, 2022, at 5:50 PM, Geert Stappers <stappers@stappers.nl> wrote:
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
If I’m not wrong, this requires repackaging the installer media?
I do still think a direct tarball support would be icing on the
cake. You can upload it to some public service and maybe shorten the
url and then directly use it, obviating the needs for setting up a web server.
But I agree the current utilities provided by the installer
already make things a breeze, so I wouldn’t complain. :)
Regards,
Glen
On Feb 16, 2022, at 5:50 PM, Geert Stappers <stappers@stappers.nl> wrote: >>>
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
If I’m not wrong, this requires repackaging the installer media?
Nope, append is append, not repackaging.
On Feb 18, 2022, at 4:48 AM, Geert Stappers wrote:
On Feb 16, 2022, at 5:50 PM, Geert Stappers wrote:
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
If I’m not wrong, this requires repackaging the installer media?
Nope, append is append, not repackaging.
The ideas sounds very interesting, but due to my limited knowledge
with regard to initrd, I have no idea what it means to “append”
to it. Googling “debian initrd append” or "initrd append” or
"initrd appendix” revealed nothing useful AFAICS. I wonder if you
could point me to some documents/manuals where I’d have a better
chance understanding it?
My current mental model is like this: initrd bundles a temporary fs to facilitate the startup process. You can change the files it contains
using a tool like cpio. So shouldn't appending files to it mean changing
the initrd file? If initrd file needs to be changed, shouldn’t the installer media also be changed to incorporate the changed initrd file?
Regards,
Glen
On Fri, Feb 18, 2022 at 03:55:30PM +0800, Glen Huang wrote:
On Feb 18, 2022, at 4:48 AM, Geert Stappers wrote:
On Feb 16, 2022, at 5:50 PM, Geert Stappers wrote:
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
If I’m not wrong, this requires repackaging the installer media?
Nope, append is append, not repackaging.
The ideas sounds very interesting, but due to my limited knowledge
with regard to initrd, I have no idea what it means to “append”
to it. Googling “debian initrd append” or "initrd append” or
"initrd appendix” revealed nothing useful AFAICS. I wonder if you
could point me to some documents/manuals where I’d have a better
chance understanding it?
https://wiki.debian.org/DebianInstaller/NetbootFirmware#The_Solution:_Add_Firmware_to_Initramfs
My current mental model is like this: initrd bundles a temporary fs to facilitate the startup process. You can change the files it contains
using a tool like cpio. So shouldn't appending files to it mean changing the initrd file? If initrd file needs to be changed, shouldn’t the installer media also be changed to incorporate the changed initrd file?
On Fri, Feb 18, 2022 at 03:55:30PM +0800, Glen Huang wrote:
On Feb 18, 2022, at 4:48 AM, Geert Stappers wrote:
On Feb 16, 2022, at 5:50 PM, Geert Stappers wrote:
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
If I’m not wrong, this requires repackaging the installer media?
Nope, append is append, not repackaging.
The ideas sounds very interesting, but due to my limited knowledge
with regard to initrd, I have no idea what it means to “append”
to it. Googling “debian initrd append” or "initrd append” or
"initrd appendix” revealed nothing useful AFAICS. I wonder if you
could point me to some documents/manuals where I’d have a better
chance understanding it?
https://wiki.debian.org/DebianInstaller/NetbootFirmware#The_Solution:_Add_Firmware_to_Initramfs
The installer already supports tar (via busybox) if I'm not mistaken.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 299 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 71:02:07 |
| Calls: | 6,694 |
| Calls today: | 4 |
| Files: | 12,228 |
| Messages: | 5,346,452 |
| Posted today: | 1 |