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

["Walter Dnes" <waltdnes@waltdnes.org>]

On Mon, May 27, 2013 at 10:36:41AM +0000, Duncan wrote

> 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).

  That is still adding unnecessary complexity to the systems, and an
additional possible point of failure.

> 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.

  What does this accomplish that could not be accomplished by...
* placing a switcher script in /sbin
* booting to single-user mode, and running the switcher script

> 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.

  It waddles like single-user mode
  It quacks  like single-user mode
  It flies   like single-user mode
  It *IS*         single-user mode

  Why bother re-inventing the wheel.  Use single-user mode, already.

> 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.

  I repeat, all this can be handled in single-user mode right now.

> 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,

  Oh boy... a second 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.

  What you're talking about is rescue-CD functionality.  I don't know if
it's possible, but it would be very nice as a standalone rescue CD
(actually USB stick nowadays).  If so, I would much rather prefer it on
as rescue CD/USB-stick than as a boot option.  If a system is really
screwed up, you can't even assume that it'll boot to single-mode from
the hard drive.

> 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!"

  I think you've just re-invented the bootloader (lilo/grub).  It can
boot Gentoo, Fedora, BSD, any special-purpose kernel you wish, and even
Windows 7 for that matter.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications