> I believe (have not yet tested) that I can relatively simply create
the
maintenance system on the fly by copying a subset of the root fs into a
ramdisk, so it doesn't take any space until it's needed.
The problem with that approach is that your maintenance system now
depends on your
"Laurent Bercot" writes:
> That said, I'm not sure your goal is as valuable as you think it is.
> If you have a running system, by definition, it's running. It has
> booted,
> and you have access to its rootfs and all the tools on it; there is
> nothing to gain by doing something fragile such
This may be a weird question, maybe: is there any way to persuade
s6-svscan (as pid 1) to restart _without_ doing a full hardware reboot?
The use case I have in mind is: starting from a regular running system,
I want to create a small "recovery" system in a ramdisk and switch to it
with
d...@telent.net said on Fri, 17 Nov 2023 22:20:32 +
>I was thinking I could use the .svscan/finish script to check for the
>existence of the "maintenance mode" ramfs, remount it onto /
>and then `exec /bin/init` as its last action, though it seems a bit
>cheesy to have a file called `finish`
Quoting d...@telent.net (2023-11-17 14:20:32)
> I was thinking I could use the .svscan/finish script to check for the
> existence of the "maintenance mode" ramfs, remount it onto /
> and then `exec /bin/init` as its last action, though it seems a bit
> cheesy to have a file called `finish` that
This may be a weird question, maybe: is there any way to persuade
s6-svscan (as pid 1) to restart _without_ doing a full hardware reboot?
The use case I have in mind is: starting from a regular running system,
I want to create a small "recovery" system in a ramdisk and switch to it
with
