From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 1B4791381F3 for ; Mon, 27 May 2013 22:40:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 091AAE0AE7; Mon, 27 May 2013 22:40:27 +0000 (UTC) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by pigeon.gentoo.org (Postfix) with ESMTP id 1EA60E0ADF for ; Mon, 27 May 2013 22:40:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFFpY2X/2dsb2JhbABEvw4Xc4IeAQEEATocKAsLIRMSDwUlEAEmiAsGwS2NBoMjYQONfogOhX6IcIFegxM X-IPAS-Result: Av8EABK/CFFFpY2X/2dsb2JhbABEvw4Xc4IeAQEEATocKAsLIRMSDwUlEAEmiAsGwS2NBoMjYQONfogOhX6IcIFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="14716266" Received: from 69-165-141-151.dsl.teksavvy.com (HELO waltdnes.org) ([69.165.141.151]) by ironport2-out.teksavvy.com with SMTP; 27 May 2013 18:40:16 -0400 Received: by waltdnes.org (sSMTP sendmail emulation); Mon, 27 May 2013 18:40:21 -0400 From: "Walter Dnes" Date: Mon, 27 May 2013 18:40:21 -0400 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init Message-ID: <20130527224021.GA18963@waltdnes.org> References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> <51A1DC0C.2070706@gentoo.org> <20130526125742.4584d094@gentoo.org> <51A1F493.90101@gentoo.org> <51A22310.70202@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: fcf461d9-f532-417d-a111-430c3af1b354 X-Archives-Hash: 549399114a3e4d5a3914a37f7b36ca8c 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 I don't run "desktop environments"; I run useful applications