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