[gentoo-dev] Switchup-mode and boottime selector? Was: eselect init

[Duncan <1i5t5.duncan@cox.net>]

Ian Stakenvicius posted on Sun, 26 May 2013 10:58:24 -0400 as excerpted:

> On 26/05/13 07:40 AM, Luca Barbato wrote:
>> On 5/26/13 12:57 PM, Michał Górny wrote:
>>> You are telling me that a wrapper, a thing that gets executed *every*
>>> boot needs to do some random magic to know which init system was in
>>> use and which one is supposed to be in use, and then conditionally
>>> move around configuration files necessary for it to run. This is just
>>> *INSANE*.
>> 
>> I like to think it normal and the wrapper doesn't need to run every
>> time but only when a switch had been requested. And only if you prefer
>> doing the switch at boot time instead than at shutdown.
>> 
>> 
> The way it's being proposed (and please correct me if i'm wrong), the
> wrapper is a direct replacement binary (small C program) for all init
> systems, and would based on some configuration file or whatnot determine
> and exec the init system it's supposed to -- and make any other
> necessary changes too, such as switching /etc/inittab)
> 
> I don't know (outside of a script in the initramfs) how this would
> otherwise be handled to cover all cases.  I am curious though, if you
> see a way to do this otherwise, what the implementation would look like?

Here's an idea I've not seen proposed yet.

Make the wrapper function something like a cross between a simple 
bootloader and traditional single-user-mode.

Normal mode, like the bootloader for many users, would be a default 
choice with (configurable) either a timeout of a couple seconds, or (say 
shift) key-held-down detection, thus no boot delay as if the key isn't 
down at the moment of detection, boot proceeds using the existing config.

In the event of an init switchup, the user either sets an option before 
shutdown (much like the run-once defaults of grub, etc, set pre-
shutdown), or selects switchup mode with the appropriate boot-time 
trigger (using the above mentioned timeout or key-down sensing).

The special switchup mode would then operate much like single-user in 
terms of available functionality and the fact that it's a special mode 
used for system maintenance, but would (normally, with a drop-to-shell 
option as well) be rather more guided, presumably using a menu, again 
much like a bootloader, except that it's PID-1 instead of pre-kernel.

Critical point #1 is that much like single-user mode, switchup mode would 
NOT run normally, but would be specifically selected, with either a 
reboot or simply starting the new init system at switchup mode exit.

That gives switchup mode a lot more flexibility in terms of what's 
allowed, since it's no longer in the time-critical every-boot path, and 
because it's its own mode, it can mount / rw to make changes as 
necessary, with either a reboot to start the selected init-system or 
simply starting it normally, at switchup mode exit.  And if anything goes 
wrong, simply select switchup mode at the next boot once again, and 
either revert to previous, for fix it.

Critical point #2 is that the actual normal-mode wrapper would be very 
small both in terms of boot-time and code, thus both easy to debug, and 
not increasing boot time by much at all, particularly in key-down-
detection mode where there'd be no timeout delay to tick down.  A small 
binary that simply either runs the timout or detects key-down, before 
execing the normal init, is all that would run in a normal bootup.  The 
complex functionality would only be invoked if switchup mode is chosen, 
as entirely separate functionality execed place of the normal init it 
would have otherwise execed.

Meanwhile, switchup mode (again, a separate binary execed only if chosen 
from the tiny one designed to run inline at each boot) would have a menu 
with options to invoke scripts for each of the init-system choices 
offered, and a further fall-back to shell option.

Each init-system package would then depend (perhaps conditionally based 
on an init-switcher USE flag) on the init-switcher package, and would 
ship one gentoo specific file, the switcher script, thus putting each 
switcher script under the control of the gentoo maintainers for that init-
system package, who could set it up to be as simple or as complex as 
necessary for their init system.  Those who needed a rw root to switch 
out various files could arrange for their switcher script to handle that, 
while those who could do without, possibly handling things later with 
their own native init-service, could do without the rw root bit.  
Similarly, switchup mode exit-time behavior, presumably either simply 
triggering a reboot, or starting the selected init-system directly, would 
be entirely under the control of the individual init-system package 
maintainers, via the switch-script they maintain.

As a first bonus, even people who aren't interested in more than one init-
system might find setting the init-switcher USE flag useful, especially 
on EFI systems, since it would give them the advantages of switchup mode, 
namely a drop to shell option as yet another alternative to single user 
mode, AND perhaps even MORE importantly, access to a more or less 
automated init-system restore option, triggered via selection of the same 
switcher script that would otherwise be run to switch between init-
systems.  Again, the contents of that init-system-specific switcher-
script would be entirely under the control of the gentoo maintainers for 
that package, so they could do whatever fancy working-condition checks 
and restores from backup that they wanted.

As a second bonus, switchup mode would be extremely flexible and 
extensible via these scripts, and I'd envision people writing extension 
scripts for all sorts of additional functionality.  Backups while the 
system is quiesced?  Hook for boot-chart and similar modes?  A fast-boot 
special media-player mode?  Something else exotic in mind?  No problem!  
Hack up a special purpose switchup-mode script for it, and "the world's 
your oyster!"
 
-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman