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

[Walter Dnes]

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@××××××××.org>
I don't run "desktop environments"; I run useful applications