segfault's [`vm-scripts.git`](https://gitlab.tails.boum.org/segfault/vm-scripts/) contains things that can improve the developer experience and should be available directly in Tails' Git: * [`copy-new-includes`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/copy-new-includes): on tails!1440 there is a discussion on how making it possible to run this code after `early_patch` time, when Tails is up an running, would be an improved `--late-patch` handling stuff like removed files, ownership/permissions etc. So also less code duplication. * [`mount-new-includes`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/mount-new-includes): enabling this in a development VM booting Tails enables rapid development loops since the files you are changing in the Git tree on your host are bind-mounted to the corresponding places inside the running Tails guest. Again, it would be nice to be able to run this after Tails has booted to update the bind mounts, in case you start changing new files. * [`symlink-new-includes`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/symlink-new-includes), but I'm not sure why we want this when we have `mount-new-includes` so probably we skip this one (?) * [`install-packages`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/install-packages) seems useful (BTW, if we do we should just temporarily disabled `auto-update` to retain normal behavior) * [`apply-updated-package-lists`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/apply-updated-package-lists) could be useful, but it seems inconvenient to not get the computed `$ADDED_PACKAGES` somehow available on the host so one can easily `apt download` them. From the top of my head the only solution I could think of is if there also is a read-write filesystem share where the Tails guest can dump `$ADDED_PACKAGES` to on the host. Actually, such a share is useful for times when one wants to extract other stuff to the host, so why not? * There's a bunch more that I haven't look at yet. While we're at it, I think there are some general improvements for `early_patch` itself that fits into this work: * As mentioned above, being able to run it the `early_patch` machinery (or parts of it?) after booting has many uses. If it was enable on the kernel commandline this could be done without admin privileges, otherwise (without thinking too much about it) I think it's safest that admin privileges are required. * Perhaps `early_patch` should always set a default root password (unless `rootpw=` was explicitly set on the kernel commandline) like `a` or whatever? Seems convenient, and something that otherwise easily could be forgotten and require a reboot. * Personally I think `early_patch` should default to `mount-new-includes`, and only run the `hook` script if told so explicitly, e.g. something like `early_patch=hook`. At least for me that (and the default root password) would cover 99% of what I use `early_patch` for without having to mess with the `hook` script. * Maybe it would be nice to make a nice library one can source in one's `hook` script to get convenient functions like `bind` that bind-mounts a file from `config/chroot_local-includes/` and similar? My current `hook` script has like a hundred lines of functions like that there's no reason we all re-implement individually. * Other arguments to `early_patch=` beyond the current only argument `umount`: * `bind`: `mount-new-includes`, this one is assumed unless `copy`, `link` or `hook` are explicitly enabled, and should raise an error if `umount` is enabled, or if combined with `copy`/`link` (same applies for them). * `copy`: `copy-new-includes`, which is assumed if `umount` is enabled and `bind`, `link` or `hook` are not passed. * `link`: `symlink-new-includes` if we want it (doubtful). * `hook`: the only way to run the `hook` script given the new default. Runs after (?) `copy`/`bind`/`link` if they are explicitly enabled. * `debs`: `install-packages` if we want it. Packages are installed before `copy`/`bind`/`link`/`hook` so they can override or use the package contents. * `pkgs`, `packages`: `apply-updated-package-lists` if we want it. * If `early_patch` fails due to an unknown argument, write the complete help when dropping to the rescue shell so the developer quickly can see what their error was and correct it when rebooting. Similarly, if the required filesystem share isn't present (`mount`ing it fails) it should tell the developer to add the required filesystem share and dump the required XML. Mentioning the docs might be worth it even if the text can only by read by Human Eyeball™ and not copied/clicked. * Let's move the mount point to `/mnt/tails.git` and change the `target` `dir=` to `tails.git`. I sometimes have other filesystem shares I want to mount (like my host's `src` dir, which I used to call `src` for a decade before `early_patch` came along :angry:), and then a subdir under `/mnt` is convenient. If we want to import `install-packages` they could be sourced from a filesystem share mounted on `/mnt/tails.debs` with `target` `dir=` as `tails.debs`. * Maybe just rename it to `patch` which is easier to type? Maybe even `p` can be an alias?