[gentoo-dev] Switchup-mode and boottime selector? Was: eselect init
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
Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init
Funny. This is starting to sound familiar... almost like some other software that runs at boot, every boot. Hm, what was the name... Oh, a *bootloader*! Something that *loads* different *boot* configurations! But seriously. For people that can install a bootloader, is there really any reconfiguration needed to reboot into a different init system? Just add configuration items as needed for different init systems. We've never automatically added bootloader options if sys-kernel/* is updated; why start now? For those who are on EFI with direct load of Linux, either install a bootloader or use efibootmgr or similar to add entries into the native boot selector (really another bootloader). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init
On Mon, May 27, 2013 at 10:36:41AM +, 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
