[gentoo-dev] Re: Re: eselect init
On Thu, Jun 20, 2013 at 03:48:29PM -0500, William Hubbs wrote: On Thu, Jun 20, 2013 at 06:10:27PM +0100, Steven J. Long wrote: Fabio Erculiani wrote: - only init is currently handled by eselect-init, which is now using a very small wrapper POSIX shell script to redirect the calls to the currently running init How does say, switching inittab format, work under this setup? I think this is a separate issue -- if busybox init's inittab is a different format than sysvinbb's inittab, it should also use a different file name, e.g. bb-inittab or something similar. bb could fall back to inittab, but I think it should look for something liike bb-inittab first. That way eselect init wouldn't have to worry about it at all. You're missing the point, because of your usual monomania for specific rather than general use-cases. 'Say' meant it was an example. I asked the question, because AFAICT from reading the code, the proposed approach keeps an indication of the running init, from startup, and then traps every call to that init, to check whether eselect has in the interim changed the symlink to point elsewhere. If einit instead simply checked whether there was a 'switchto' file at startup, it would be able to handle the more general problem, as well as running more efficiently and robustly, with no need to mess around with symlinks. The complexity would then be in eselect confirming, eg that the 'to' init is installed and configured, before setting the file for the next reboot. And optionally in the switcher when starting the new init at boot, if it should need anything tricky carried out, which might interact badly with a currently running init. That's a re-iteration of Duncan's idea, ofc. I'm also curious as to how an initramfs fits into the schema, given that there may be things that need to be done before pid 1 is started (or if not, I have nfc what all the discussion about replacing the kernel mechanism was in aid of.) -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Re: eselect init
Hi Luca, On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote: Again you should read the whole thread, please do, the whole eselect init stuff should stay opt-in for the time being so all this discussion is close to pointless. Can we please make this remain opt-in always? I too would rather not see this become mandatory for gentoo. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Re: eselect init
El lun, 03-06-2013 a las 00:35 +0200, Luca Barbato escribió: [...] To not make this a waste of time here a summary of the whole thing: - eselect init will be opt-in for the time being, people can be left on their own tools if the want it - the default init will stay sysvinit. Discussion ongoing if is better to have it installed in a secondary fallback path is open (e.g. /bin/init). - I still need to send patches to busybox and sysvinit upstream to add a command line switch to locate the inittab. - people wanting to switch init or enable/disable init addons using eselect init might have to refer to /sbin/einit or such custom path (assuming we fail to come to an agreement regarding /bin/init) The wrapper in /sbin/init is mostly needed to get to the point of a clean reboot. The first time you boot on a new system it is executed picking the new init and just that. For addons such as bootchart2 and e4rat it would do slightly more. Assuming upstream doesn't accept custom paths for the inittab, for my specific usecase I might bake something that would remount r/w and pivot the inittabs. Anybody willing to do something more extreme could even consider having /sbin/init as a symlink and have the boot-time configuration switch the symlink, thus making the whole script run just a single boot per switch. Not necessary but surely feasible. lu Thanks for the summary :)
Re: [gentoo-dev] Re: Re: eselect init
On 06/03/2013 02:37 AM, Walter Dnes wrote: On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote - eselect init will be opt-in ***FOR THE TIME BEING***, people can be left on their own tools if the want it This statement should bring the same reaction as the posting that udev source was being rolled into the systemd tarball. It implies that eselect init will eventually become mandatory. Let me restate: As long there isn't a strict necessity the whole machinery should not impact the normal systems with the default init. Your situation is a special use-case, i.e. a developer who wants to switch between a production init system, and a test init system, possibly multiple times a day. You're a developer, you know which files to change, put together your own scripts, and run them as necessary. Set up your own overlay and write your own eselect init ebuild. No problem. But why should this eventually be a part of mainstream Gentoo? e4rat, bootchart and other addons might be more mainstream than gdb-as-init indeed. BTW, I'm a bigger fan of busybox than most Gentoo users. Remember the announcement of systemd/udev tarball integration, and supposed deprecation of a separate /usr? I was the -disturber who started up the https://wiki.gentoo.org/wiki/Mdev wiki page on how to replace udev with mdev. I also did a page on automounting at... https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount Having said that, I don't see how busybox development justifies an additional layer of complexity for everybody's bootup. It isn't every bootup =) lu
Re: [gentoo-dev] Re: Re: eselect init
On Sun, 2 Jun 2013 20:37:57 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote - eselect init will be opt-in ***FOR THE TIME BEING***, people can be left on their own tools if the want it This statement should bring the same reaction as the posting that udev source was being rolled into the systemd tarball. It implies that eselect init will eventually become mandatory. How does it imply that? Do you see anyone pursuing it to be mandatory? Your situation is a special use-case, i.e. a developer who wants to switch between a production init system, and a test init system, possibly multiple times a day. You're a developer, you know which files to change, put together your own scripts, and run them as necessary. Set up your own overlay and write your own eselect init ebuild. No problem. But why should this eventually be a part of mainstream Gentoo? Because most Gentoo users are developers. BTW, I'm a bigger fan of busybox than most Gentoo users. Remember the announcement of systemd/udev tarball integration, and supposed deprecation of a separate /usr? I was the -disturber who started up the https://wiki.gentoo.org/wiki/Mdev wiki page on how to replace udev with mdev. I also did a page on automounting at... https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount Having said that, I don't see how busybox development justifies an additional layer of complexity for everybody's bootup. Great, but that's mostly irrelevant to this ML thread; the need for such articles is a result of not being able to do it in a more proper way. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: Re: eselect init
On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote: On 06/01/2013 11:23 AM, Steven J. Long wrote: That's not an argument for using a symlink switcher or the equivalent across the board, by any means. Your opinion. That's not an argument for it either. Firstly, we should be recommending people install Gentoo with enough flexibility to configure and use their system how they choose. In the UEFI arena, why not simply recommend something like rEFIt instead of making everyone go through a load of development effort, to restrict us all to a crippled use-case? Beside rEFIt being deprecated and rEFInd being in early stage of development (thus working great on some platforms and not working at all on some other) and with a good chunk of documentation to read before being able of deploying it? The typical thing Gentoo users get told is this is a new thing, it will take some time to work out, bear with us as their production servers go tits-up around them. So in this case too, work with upstream to implement better solutions you, and the wider ecosystem, can all use. And in the meantime: NOTE: If you still wish to pursue a fixed config, then it's easy enough to build it with init=/sbin/einit since presumably you want that setup for your users. Had been considered And STILL the best interim solution till your EFI setup has a bootloader. Your opinion of rejection is just that: your opinion. You're free to work on whatever you want. You just haven't made any case for why the rest of the ecosystem should be crippled to allow for a use-case that would be better served by an existing, far more robust solution. All I'm saying is: can we please stop trying to reinvent the kernel, which accepts a bootloader parameter from initramfs as well, and focus instead on the difficult part: making sure the system is in a fit state to switch in the first place. ... That's where the development effort is needed, if you are to provide a mechanism to switch. The symlink and hooks etc is a total dead-end, imo. It's simply reinventing the wheel using octagons instead of circles. IMHO you hadn't read enough about it. Believe me I've read lots. And you _still_ are not presenting any arguments. There are 6 options to hook in an init, and to fallback in case of error, already. There's nothing to stop systemd being the default init, should you want to put the install together like that. Because let's be honest: someone has to put this install together, irrespective of how incapable the end-user is of editing a file by themselves. And just because the user can do it simply, that's no reason to make our method to do it any more complex (I've never heard such a bizarre argument.) Just edit the file via script. I do not care about systemd. Then it can be runit or whatever else takes your fancy. You are ignoring the point of that paragraph though: someone has to put the install together. Or it isn't a Gentoo install. So given that you're putting it together, or it's an automated script to do the same, you can hook in an init wrapper or alternative wherever you want, without needing anything from anyone else. FOCUS on getting the system safe to switch. Not on reinventing init/main.c, badly. You should read the whole thread before commenting like this that late. I have actually. I responded to WilliamH a while back, CC'ed to him since he prefers that, but the mail didn't get through to the list. It was marked TLDNR so no doubt it hit a filter somewhere, and I didn't see the point in reiterating it. I've seen two weeks of discussion about how to reimplement init/main.c with ooh it needs to be early in init and what about fallbacks, interleaved with less and less discussion of the actual problem: making sure the system is safe to switch in the first place; sine qua non. Wrt to the first, funnily enough the kernel developers have been here before, just like they had with ethN and wlanN. It's a basic requirement for developing an OS that you be able to switch init and fallback to other options. You should consider the points made, and whether you really need to implement this part of the setup at all. Your premise is still flawed, however long you've been discussing the implications of working round it. Stuff happens. Honestly, my goal is a saving of time so people can focus on making the eselect module work properly, and be of real value to an end-user who wants to switch init. The whole symlink/boot/fallback thing is simply a waste of technical effort. And blanket your opinion and you didn't comment a week ago, so I don't have to deal with the substance of your points don't change that. Please, make a better case next time. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Re: eselect init
On Sun, Jun 2, 2013 at 8:20 PM, Steven J. Long sl...@rathaus.eclipse.co.uk wrote: [...] The whole symlink/boot/fallback thing is simply a waste of technical effort. And blanket your opinion and you didn't comment a week ago, so I don't have to deal with the substance of your points don't change that. Waste? We have multiple use cases for that as stated in several places (here, bugzilla, IRC, etc). If such use cases are of no interest for you, then you shouldn't be bothered. Please, make a better case next time. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-) -- Fabio Erculiani
Re: [gentoo-dev] Re: Re: eselect init
On 06/02/2013 08:20 PM, Steven J. Long wrote: On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote: On 06/01/2013 11:23 AM, Steven J. Long wrote: That's not an argument for using a symlink switcher or the equivalent across the board, by any means. Your opinion. That's not an argument for it either. Had been explained in the thread, please read it. Firstly, we should be recommending people install Gentoo with enough flexibility to configure and use their system how they choose. In the UEFI arena, why not simply recommend something like rEFIt instead of making everyone go through a load of development effort, to restrict us all to a crippled use-case? Beside rEFIt being deprecated and rEFInd being in early stage of development (thus working great on some platforms and not working at all on some other) and with a good chunk of documentation to read before being able of deploying it? The typical thing Gentoo users get told is this is a new thing, it will take some time to work out, bear with us as their production servers go tits-up around them. So in this case too, work with upstream to implement better solutions you, and the wider ecosystem, can all use. I'm afraid you never used those nor you are in one of those situation in which you have less options. And STILL the best interim solution till your EFI setup has a bootloader. Again you should read the whole thread, please do, the whole eselect init stuff should stay opt-in for the time being so all this discussion is close to pointless. Consider this email a friendly warning, please do not pollute the Gentoo media with pointless email when you had been already politely told that your concern had been addressed in the previous email in the thread. You're free to work on whatever you want. You just haven't made any case for why the rest of the ecosystem should be crippled to allow for a use-case that would be better served by an existing, far more robust solution. Had it been the case we wouldn't had spent some weeks picking our brains on it. Then it can be runit or whatever else takes your fancy. You are ignoring the point of that paragraph though: someone has to put the install together. Or it isn't a Gentoo install. And you seem to miss the point that all you are telling had been discussed, taken in consideration and in some part agreed with already... Wrt to the first, funnily enough the kernel developers have been here before, just like they had with ethN and wlanN. It's a basic requirement for developing an OS that you be able to switch init and fallback to other options. Again you didn't ready or you forgot. I said already I don't care about systemd many times, yet you failed to remember that. My specific use-case would require a trip to single mode and a second reboot, the way I want to do spares that. On an EFI-stub only system it would require at least a kernel rebuild or a trip to the efi shell if available. Honestly, my goal is a saving of time so people can focus on making the eselect module work properly, and be of real value to an end-user who wants to switch init. To not make this a waste of time here a summary of the whole thing: - eselect init will be opt-in for the time being, people can be left on their own tools if the want it - the default init will stay sysvinit. Discussion ongoing if is better to have it installed in a secondary fallback path is open (e.g. /bin/init). - I still need to send patches to busybox and sysvinit upstream to add a command line switch to locate the inittab. - people wanting to switch init or enable/disable init addons using eselect init might have to refer to /sbin/einit or such custom path (assuming we fail to come to an agreement regarding /bin/init) The wrapper in /sbin/init is mostly needed to get to the point of a clean reboot. The first time you boot on a new system it is executed picking the new init and just that. For addons such as bootchart2 and e4rat it would do slightly more. Assuming upstream doesn't accept custom paths for the inittab, for my specific usecase I might bake something that would remount r/w and pivot the inittabs. Anybody willing to do something more extreme could even consider having /sbin/init as a symlink and have the boot-time configuration switch the symlink, thus making the whole script run just a single boot per switch. Not necessary but surely feasible. lu
Re: [gentoo-dev] Re: Re: eselect init
On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote - eselect init will be opt-in ***FOR THE TIME BEING***, people can be left on their own tools if the want it This statement should bring the same reaction as the posting that udev source was being rolled into the systemd tarball. It implies that eselect init will eventually become mandatory. Your situation is a special use-case, i.e. a developer who wants to switch between a production init system, and a test init system, possibly multiple times a day. You're a developer, you know which files to change, put together your own scripts, and run them as necessary. Set up your own overlay and write your own eselect init ebuild. No problem. But why should this eventually be a part of mainstream Gentoo? BTW, I'm a bigger fan of busybox than most Gentoo users. Remember the announcement of systemd/udev tarball integration, and supposed deprecation of a separate /usr? I was the -disturber who started up the https://wiki.gentoo.org/wiki/Mdev wiki page on how to replace udev with mdev. I also did a page on automounting at... https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount Having said that, I don't see how busybox development justifies an additional layer of complexity for everybody's bootup. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Re: eselect init
On Sun, Jun 2, 2013 at 8:37 PM, Walter Dnes waltd...@waltdnes.org wrote: On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote - eselect init will be opt-in ***FOR THE TIME BEING***, people can be left on their own tools if the want it This statement should bring the same reaction as the posting that udev source was being rolled into the systemd tarball. It implies that eselect init will eventually become mandatory. I don't get why it would ever become mandatory, or why people are worried about this. The only packages that tend to touch anything like inittab are the packages that implement init in the first place. I'm not aware of any init packages that would require otherwise. That being the case, there isn't going to be any tight coupling here. If you want a simple config just point your grub/etc to the init implementation of your choice and it is hard-coded. Or, install the fancy switcher script/initramfs/whatever and use it. People get way to panicky every time somebody posts a new idea on -dev. Half of these ideas never get implemented, and 90% of those which are don't become defaults. Heck, the intent was always to make OpenRC the default and it took YEARS for that to happen on stable. When you see two random developers post a crazy idea on -dev, keep in mind that we're a distro that fosters innovation by letting any developer start a project based solely on personal initiative. Generally things don't become defaults until it becomes fairly obvious that this is the appropriate course of action. Rich
