Incorporate vm-scripts.git goodies into the early_patch machinery
segfault's vm-scripts.git
contains things that can improve the developer experience and should be available directly in Tails' Git:
-
copy-new-includes
: on !1440 (merged) there is a discussion on how making it possible to run this code afterearly_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
: 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
, but I'm not sure why we want this when we havemount-new-includes
so probably we skip this one (?) -
install-packages
seems useful (BTW, if we do we should just temporarily disabledauto-update
to retain normal behavior) -
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 easilyapt 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 (unlessrootpw=
was explicitly set on the kernel commandline) likea
or whatever? Seems convenient, and something that otherwise easily could be forgotten and require a reboot. - Personally I think
early_patch
should default tomount-new-includes
, and only run thehook
script if told so explicitly, e.g. something likeearly_patch=hook
. At least for me that (and the default root password) would cover 99% of what I useearly_patch
for without having to mess with thehook
script. - Maybe it would be nice to make a nice library one can source in one's
hook
script to get convenient functions likebind
that bind-mounts a file fromconfig/chroot_local-includes/
and similar? My currenthook
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 argumentumount
:-
bind
:mount-new-includes
, this one is assumed unlesscopy
,link
orhook
are explicitly enabled, and should raise an error ifumount
is enabled, or if combined withcopy
/link
(same applies for them). -
copy
:copy-new-includes
, which is assumed ifumount
is enabled andbind
,link
orhook
are not passed. -
link
:symlink-new-includes
if we want it (doubtful). -
hook
: the only way to run thehook
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 beforecopy
/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 thetarget
dir=
totails.git
. I sometimes have other filesystem shares I want to mount (like my host'ssrc
dir, which I used to callsrc
for a decade beforeearly_patch
came along😠 ), and then a subdir under/mnt
is convenient. If we want to importinstall-packages
they could be sourced from a filesystem share mounted on/mnt/tails.debs
withtarget
dir=
astails.debs
. - Maybe just rename it to
patch
which is easier to type? Maybe evenp
can be an alias?
Edited by anonym