On 06/22/2013 01:23 PM, Jason A. Donenfeld wrote:
> and nobody is forced to install eselect-init
That was already demanded earlier in this discussion, but I don't see
any response from the initiators of this idea (possible I just missed it).
Anyway... if they do such a global change without discu
If we're to support sysvinit and systemd at the same time, let each use
their upstream paths. This means sysvinit gets /sbin/init.
This also means that business can continue as usual, and nobody is forced
to install eselect-init. The current system works for users who don't care
or aren't aware of
On 06/22/2013 03:27 AM, Ulrich Mueller wrote:
>> On Fri, 21 Jun 2013, Luca Barbato wrote:
>
>> /bin/init
>
> Why /bin? It shouldn't be in users' PATH.
"users' PATH", a joyful blast from the past, if I'm allowed to say that.
But it's all /usr/bin now [1].
Off topic -- I always have sbins in m
> On Fri, 21 Jun 2013, Luca Barbato wrote:
> /bin/init
Why /bin? It shouldn't be in users' PATH.
Ulrich
On 06/21/2013 06:50 PM, William Hubbs wrote:
> On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote:
>> On 21 June 2013 16:29, Michał Górny wrote:
>>> Dnia 2013-06-21, o godz. 10:16:10
>>> William Hubbs napisał(a):
>>>
On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
On 06/21/2013 05:23 PM, Fabio Erculiani wrote:
> Fix the reason why the wrapper got broken then.
> If the wrapper broke, it is most likely a symptom of a bigger problem.
>
> I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
> (or /bin/sysvinit?), anyway...
>
/bin/init
lu
On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote:
> On 21 June 2013 16:29, Michał Górny wrote:
> > Dnia 2013-06-21, o godz. 10:16:10
> > William Hubbs napisał(a):
> >
> >> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
> >> > > If eselect-init installs the wrapper as
On Fri, Jun 21, 2013 at 05:23:51PM +0200, Fabio Erculiani wrote:
> I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
> (or /bin/sysvinit?), anyway...
Feel free to file a request with sysvinit upstream to see if they will
do this; I don't think we should be randomly renaming fi
On 21 June 2013 16:29, Michał Górny wrote:
> Dnia 2013-06-21, o godz. 10:16:10
> William Hubbs napisał(a):
>
>> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
>> > > If eselect-init installs the wrapper as /sbin/einit, we don't have to
>> > > touch /sbin/init at all, then, the only
El vie, 21-06-2013 a las 09:36 -0500, William Hubbs escribió:
[...]
> No, he has his own versions of the systemd and sysvinit ebuilds which
> move some of the installation to non-standard places as part of this
> machinery, so it is not opt-in.
>
> Also, there was an email on this thread showing t
Fix the reason why the wrapper got broken then.
If the wrapper broke, it is most likely a symptom of a bigger problem.
I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
(or /bin/sysvinit?), anyway...
--
Fabio Erculiani
Dnia 2013-06-21, o godz. 10:16:10
William Hubbs napisał(a):
> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
> > > If eselect-init installs the wrapper as /sbin/einit, we don't have to
> > > touch /sbin/init at all, then, the only thing someone would have to do
> > > is to add an e
On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
> > If eselect-init installs the wrapper as /sbin/einit, we don't have to
> > touch /sbin/init at all, then, the only thing someone would have to do
> > is to add an entry to their boot loader with init=/sbin/einit on the kcl
> > to use
On Fri, Jun 21, 2013 at 01:50:02PM +0200, Luca Barbato wrote:
> On 06/21/2013 01:26 PM, Pacho Ramos wrote:
> > Thanks for the explanation. But I think that, currently, the only
> > remaining "objection" is whether play with /sbin/init (that needs
> > sysvinit to be changed if I don't misremember) o
On 06/21/2013 01:26 PM, Pacho Ramos wrote:
> Thanks for the explanation. But I think that, currently, the only
> remaining "objection" is whether play with /sbin/init (that needs
> sysvinit to be changed if I don't misremember) or with /sbin/einit.
> Looks like mgorny has shown some problems on rel
El vie, 21-06-2013 a las 13:19 +0200, Fabio Erculiani escribió:
> For me, the big selling points of eselect-init are:
>
> 1. as release engineer, i can prepare images that use either systemd
> or openrc (at present time these are the two supported options) and do
> it reliably, programmatically.
>
For me, the big selling points of eselect-init are:
1. as release engineer, i can prepare images that use either systemd
or openrc (at present time these are the two supported options) and do
it reliably, programmatically.
2. as distro maintainer, i can roll out a migration path from openrc
to sys
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/21/2013 04:39 AM, Michał Górny wrote:
> Dnia 2013-06-20, o godz. 15:56:09 William Hubbs
> napisał(a):
>
>> On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
>>> There is a new version of eselect-init in the systemd-love
>>> ove
Dnia 2013-06-20, o godz. 23:16:00
William Hubbs napisał(a):
> On Fri, Jun 21, 2013 at 04:39:59AM +0200, Michał Górny wrote:
> > Dnia 2013-06-20, o godz. 15:56:09
> > William Hubbs napisał(a):
> >
> > > On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
> > > > There is a new versi
On Fri, Jun 21, 2013 at 04:39:59AM +0200, Michał Górny wrote:
> Dnia 2013-06-20, o godz. 15:56:09
> William Hubbs napisał(a):
>
> > On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
> > > There is a new version of eselect-init in the systemd-love overlay to
> > > play with.
> > >
Dnia 2013-06-20, o godz. 15:56:09
William Hubbs napisał(a):
> On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
> > There is a new version of eselect-init in the systemd-love overlay to play
> > with.
> > The new version saw the following major changes:
> >
> > - the /sbin/init (
On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
> There is a new version of eselect-init in the systemd-love overlay to play
> with.
> The new version saw the following major changes:
>
> - the /sbin/init (aka the symlink that eselect-init handles) can be
> changed to whatever on
There is a new version of eselect-init in the systemd-love overlay to play with.
The new version saw the following major changes:
- the /sbin/init (aka the symlink that eselect-init handles) can be
changed to whatever one wants through make.conf [1] (this is a compile
time option, as documented in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/05/13 12:43 AM, Luca Barbato wrote:
> On 5/28/13 6:19 AM, Michał Górny wrote:
>> And you actually make the boot depend on:
>>
>> 1) valid /bin/sh
>
> If it doesn't exist you have a few order of magnitude bigger
> problem.
>
>> 2) valid /etc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/05/13 12:43 AM, Luca Barbato wrote:
OK -- so, given how very simple this wrapper is, and likewise how
simple the switcher script would probably be to write, what's the goal
of this whole thread, exactly? It doesn't sound like this is
someth
On 5/28/13 6:19 AM, Michał Górny wrote:
And you actually make the boot depend on:
1) valid /bin/sh
If it doesn't exist you have a few order of magnitude bigger problem.
2) valid /etc/switch-init which would not interfere with boot process.
I guess if you want to switch init system you need
On Tue, 28 May 2013 05:55:39 +0200
Luca Barbato wrote:
> On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
> > 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 configurati
On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
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 t
On 5/26/13 4:13 PM, Ian Stakenvicius wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/05/13 03:08 PM, Matthew Thode wrote:
On 05/25/13 05:25, Peter Stuge wrote:
Luca Barbato wrote:
- init gets effectively switched only at boot/reboot
Please not on reboot, because an unclean shut
On 5/27/13 12:58 AM, William Hubbs wrote:
From what I just read, the difference is that busybox init ignores the
runlevels specified in sysvinit inittab.
Nope, it interprets the numbers in a different way.
If that's the only difference, do we really need to modify the inittab
at all?
Yes, I
On Sun, May 26, 2013 at 06:55:45PM +0200, Michał Górny wrote:
> On Sun, 26 May 2013 11:48:30 -0500
> William Hubbs wrote:
>
> > On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote:
> > > On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
> > > > Openrc is small, but the wrapp
On Sun, 26 May 2013 11:48:30 -0500
William Hubbs wrote:
> On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote:
> > On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
> > > Openrc is small, but the wrapper really needs to know which is which and
> > > worst case switch initta
On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote:
> On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
> > Openrc is small, but the wrapper really needs to know which is which and
> > worst case switch inittab.
>
> Please explain why this wrapper would need to switch initt
On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
> Openrc is small, but the wrapper really needs to know which is which and
> worst case switch inittab.
Please explain why this wrapper would need to switch inittab. Inittab is
only used by sysvinit and has no uses in any other init sy
On Sun, 26 May 2013 16:52:27 +0200
Luca Barbato wrote:
> On 5/26/13 1:58 PM, Tom Wijsman wrote:
> > On Sun, 26 May 2013 12:57:42 +0200
> > Michał Górny wrote:
> >
> > > Switch inittab? Now you added really dangerous behavior to the
> > > wrapper code. I can hardly even express this in words.
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/05/13 08:59 AM, J. Roeleveld wrote:
> On Sat, May 25, 2013 21:55, Tom Wijsman wrote:
>> On Sat, 25 May 2013 21:09:47 +0200 "J. Roeleveld"
>> wrote:
>>
>>> How will the stop/start part of services/init-scripts/... be
>>> done?
>>
>> Not sure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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
On 5/26/13 1:58 PM, Tom Wijsman wrote:
On Sun, 26 May 2013 12:57:42 +0200
Michał Górny wrote:
Switch inittab? Now you added really dangerous behavior to the wrapper
code. I can hardly even express this in words.
It doesn't need to be in the wrapper, inittab is something read at boot
only as
On Sun, May 26, 2013 at 10:07 AM, Tom Wijsman wrote:
> On Sun, 26 May 2013 15:15:26 +0200
> Michał Górny wrote:
>
>> Cc: tom...@gentoo.org
>
> Please don't CC me, this causes duplicate mails; one of both does not
> include reply-to. Nobody else that has responded to me did this before.
>
> Unless
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/05/13 03:08 PM, Matthew Thode wrote:
> On 05/25/13 05:25, Peter Stuge wrote:
>> Luca Barbato wrote:
>>> - init gets effectively switched only at boot/reboot
>>
>> Please not on reboot, because an unclean shutdown shouldn't leave
>> the system
On Sun, 26 May 2013 15:15:26 +0200
Michał Górny wrote:
> Cc: tom...@gentoo.org
Please don't CC me, this causes duplicate mails; one of both does not
include reply-to. Nobody else that has responded to me did this before.
Unless you can give me an awesome procmail rule to process these... :)
>
On Sun, 26 May 2013 14:59:28 +0200
"J. Roeleveld" wrote:
> As an example. Lets say I want to test a new init-system. [SNIP]
> If I then, accidentally, type "/etc/init.d/xyz start" when "xyz"
> hasn't been started by any means yet. What will happen?
> I would assume that openrc will try to start
On Sat, 25 May 2013 21:55:20 +0200
Tom Wijsman wrote:
> On Sat, 25 May 2013 21:09:47 +0200
> "J. Roeleveld" wrote:
>
> > +1 for wrapper, from my understanding, symlinks for init-systems
> > can't be altered on a running system without risking strange
> > behaviour.
>
> Exactly...
>
> # shutd
On Sat, May 25, 2013 21:55, Tom Wijsman wrote:
> On Sat, 25 May 2013 21:09:47 +0200
> "J. Roeleveld" wrote:
>
>> How will the stop/start part of services/init-scripts/... be done?
>
> Not sure what you mean here; if you keep init function the same as the
> init you boot with, this should continue
On 5/26/13 2:08 PM, Michał Górny wrote:
You could've asked me that when I was still using OpenRC. I don't
really want to grep the 40 scripts right now, and I don't think I have
the worse cases installed here.
Worth investigation, not by you, but those that loathe systemd should
have a look and
On Sun, 26 May 2013 12:01:19 +0200
Robert David wrote:
> Newer say that wrapper will grow openrc size, and also dont know why
> it would be bad.
That's what I'd like to know from him, I was quoting both of you,
> I really dont know how many user will switch inits and how many of
> them will do
On Sun, 26 May 2013 13:40:03 +0200
Luca Barbato wrote:
> On 5/26/13 12:57 PM, Michał Górny wrote:
> > Switch inittab? Now you added really dangerous behavior to the wrapper
> > code. I can hardly even express this in words.
>
> I need it for my purpose, bb-init syntax isn't the same as sysv.
Th
On Sun, 26 May 2013 13:45:43 +0200
Tom Wijsman wrote:
> On Sun, 26 May 2013 12:09:21 +0200
> Michał Górny wrote:
>
> > > Easy isn't always good. It's not atomic since you can't reboot and
> > > because of that I wouldn't call it smooth either.
> >
> > Can't you? How come?
>
> Because it expec
On Sun, 26 May 2013 12:57:42 +0200
Michał Górny wrote:
> Switch inittab? Now you added really dangerous behavior to the wrapper
> code. I can hardly even express this in words.
It doesn't need to be in the wrapper, inittab is something read at boot
only as far as I am aware and therefore eselect
On Sun, 26 May 2013 12:09:21 +0200
Michał Górny wrote:
> > Easy isn't always good. It's not atomic since you can't reboot and
> > because of that I wouldn't call it smooth either.
>
> Can't you? How come?
Because it expects the init system you boot with to be present.
> > > > I think that safe
On 5/26/13 12:57 PM, Michał Górny wrote:
On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato wrote:
On 5/26/13 8:43 AM, Michał Górny wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato wrote:
- /sbin/init (or whatever linux currently calls by default with top
priority) should be either a sy
On 05/26/2013 12:11 PM, Rich Freeman wrote:
> That means that this whole thing only impacts those who
> install it, which is the best way to implement something experimental
> in the first place.
>
+1
I and probably a lot of other people have zero interest in this
approach, so we should not be b
On Sun, 26 May 2013 11:45:38 +0200
Tom Wijsman wrote:
> On Sun, 26 May 2013 11:20:25 +0200
> Michał Górny wrote:
>
> > It is *easy*.
> >
> > ln -s /sbin/newinit /sbin/init.new
> > mv /sbin/init.new /sbin/init
> >
> > Easy and atomic. The inconsistency potential is similar to one given
> >
On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato wrote:
> On 5/26/13 8:43 AM, Michał Górny wrote:
> > On Sat, 25 May 2013 11:54:48 +0200
> > Luca Barbato wrote:
> >
> >> - /sbin/init (or whatever linux currently calls by default with top
> >> priority) should be either a symlink to the actual imp
On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato wrote:
> Openrc is small, but the wrapper really needs to know which is which
It doesn't need to, it just needs to kick off the right init process.
If you think it does need to, please elaborate.
> and worst case switch inittab.
You could keep t
Rich Freeman schrieb:
> Granted, I don't know the limitations of the EFI bootloaders that are
> out there, but this still seems like something better solved via grub
> configuration. When I implemented systemd in one of my VMs I just
> added a grub line to boot back to openrc.
EFI stub kernels ju
On Sun, May 26, 2013 at 6:01 AM, Robert David
wrote:
> Newer say that wrapper will grow openrc size, and also dont know why it
> would be bad. The point is somewhere else. I really dont know how many
> user will switch inits and how many of them will do this regularly.
> But the wrapper will be ex
On Sun, 26 May 2013 11:21:25 +0200
Tom Wijsman wrote:
> On Sun, 26 May 2013 10:58:23 +0200
> Robert David wrote:
>
> > > Increased complexity is never safer. And a wrapper means the
> > > additional complexity gets there every boot. And considering how
> > > the discussion goes, the wrapper wil
On 5/26/13 8:43 AM, Michał Górny wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato wrote:
- /sbin/init (or whatever linux currently calls by default with top
priority) should be either a symlink to the actual implementation or a
wrapper such as our gcc one. I like better the latter since
On Sun, 26 May 2013 11:20:25 +0200
Michał Górny wrote:
> It is *easy*.
>
> ln -s /sbin/newinit /sbin/init.new
> mv /sbin/init.new /sbin/init
>
> Easy and atomic. The inconsistency potential is similar to one given
> by init upgrades. Yet we don't do anything magical to defer init
> upgrade u
On Sun, 26 May 2013 11:20:25 +0200
Michał Górny wrote:
> On Sun, 26 May 2013 10:58:23 +0200
> Robert David wrote:
>
> > On Sun, 26 May 2013 08:43:32 +0200
> > Michał Górny wrote:
> >
> > > On Sat, 25 May 2013 11:54:48 +0200
> > > Luca Barbato wrote:
> > >
> > > > - /sbin/init (or whatever l
On Sun, 26 May 2013 10:58:23 +0200
Robert David wrote:
> > Increased complexity is never safer. And a wrapper means the
> > additional complexity gets there every boot. And considering how
> > the discussion goes, the wrapper will grow openrc-size in a few
> > months..
>
> I agree with this. But
On Sun, 26 May 2013 10:58:23 +0200
Robert David wrote:
> On Sun, 26 May 2013 08:43:32 +0200
> Michał Górny wrote:
>
> > On Sat, 25 May 2013 11:54:48 +0200
> > Luca Barbato wrote:
> >
> > > - /sbin/init (or whatever linux currently calls by default with top
> > > priority) should be either a s
On Sun, 26 May 2013 08:43:32 +0200
Michał Górny wrote:
> On Sat, 25 May 2013 11:54:48 +0200
> Luca Barbato wrote:
>
> > - /sbin/init (or whatever linux currently calls by default with top
> > priority) should be either a symlink to the actual implementation
> > or a wrapper such as our gcc one.
On Sun, 26 May 2013 04:02:56 +0200
Peter Stuge wrote:
> By take effect I mean that the filesystem should be modified in such
> a way that the next boot will use what I selected. No further action
> which could fail should be required beyond the eselect command.
>
> Unless the eselect command has
On Sat, 25 May 2013 21:52:28 -0400
"Walter Dnes" wrote:
> On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote
> It has to be done *VERY* early at boot, or else we're back to the
> problem you described above.
Not sure what you mean with very early, you don't really have control
over this
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato wrote:
> - /sbin/init (or whatever linux currently calls by default with top
> priority) should be either a symlink to the actual implementation or a
> wrapper such as our gcc one. I like better the latter since it is
> overall safer. The former mig
Tom Wijsman wrote:
> > I would actually expect the change to take effect immediately.
>
> Then how would you be able to shutdown / reboot your system in a clean
> way? The premise here is that when you boot with an init system you
> must shutdown with that same init system, you can't just start on
On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote
> On Sat, 25 May 2013 12:25:03 +0200
> Peter Stuge wrote:
>
> > I would actually expect the change to take effect immediately.
>
> Then how would you be able to shutdown / reboot your system in a clean
> way? The premise here is that wh
On Sat, 25 May 2013 16:07:51 -0400
Alex Xu wrote:
> On 25/05/13 03:55 PM, Tom Wijsman wrote:
> >> > I don't have "init=" set on my machines and it seems to
> >> > start /sbin/init. So that should be correct.
> > Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
> >
>
> https:/
On 25/05/13 03:55 PM, Tom Wijsman wrote:
>> > I don't have "init=" set on my machines and it seems to
>> > start /sbin/init. So that should be correct.
> Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
>
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init
On Sat, 25 May 2013 21:09:47 +0200
"J. Roeleveld" wrote:
> I was thinking of a "default" option in the "eselect init" part that
> would remove "init=/sbin/einit" from the kernel boot parameters.
With the different boot loaders, it's not easy to do this consistently
everywhere; lilo != grub != gr
Sergei Trofimovich schrieb:
> I guess EFI allows you to set bootargs via EFI UI.
If you have an EFI shell, then you can pass additional kernel command line
parameters via that. Passing parameters via the UI is not possible with any
of the UEFI systems that I have come across.
Best regards,
Chí-T
On Sat, May 25, 2013 15:38, Tom Wijsman wrote:
> On Sat, 25 May 2013 11:54:48 +0200
> Luca Barbato wrote:
>
>
> there's one option we forget about
> here though, EFI users can build a second smaller minimally adjusted
> defconfig kernel that ends up loading the default init system if they
> wish
On 05/25/13 05:25, Peter Stuge wrote:
> Luca Barbato wrote:
>> - init gets effectively switched only at boot/reboot
>
> Please not on reboot, because an unclean shutdown shouldn't leave the
> system in limbo.
>
> On boot could work, except that it does add more steps (= more
> fragility) to the b
> > I'd go for init=/sbin/gentoo-init and make all the messy stuff there.
> > Otherwise by breaking /sbin/init it would be hard to find proper
> > name of, say, SYSVs /sbin/init. How would you call it?
>
> /bin/init is my idea (second in the list in linux fallback), otherwise
> we can just make th
On 05/25/2013 02:13 PM, hasufell wrote:
> Isn't eselect for cases where I might want to reconfigure something or
> add configuration values such as for bash-completion, do testing with
> java-vm or python implementations during development, switch opengl
> implementation depending on the graphics d
On 05/25/2013 01:13 PM, Pacho Ramos wrote:
> El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió:
>> Hi, since the whole discussion got somehow sidetracked on where and if
>> to install for everybody the rc system specific files for everybody
>> (that should be an implementation detail for
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato wrote:
> since the whole discussion got somehow sidetracked [SNIP], I'm back
> to the other part of it: switching the actual init implementation.
Thank you very much.
> Since efi at least some people started to put in the kernel the
> bootargs and
On 05/25/2013 01:29 PM, Sergei Trofimovich wrote:
> If you can't change options at boot time it's very simple to get
> unbootable system. Just curious, who does such systems and
> how root filesystem (+ it's mount options) is expected to be
> found there?
You write your bootargs in the kernel, if
El sáb, 25-05-2013 a las 14:03 +0200, Tom Wijsman escribió:
> On Sat, 25 May 2013 13:13:36 +0200
> Pacho Ramos wrote:
>
> > I use e4rat and, for that, I need to add
> > init=/sbin/e4rat-preload
> >
> > to my grub.conf, I guess this wouldn't change with this, no? :/
> >
> > Thanks for the info!
On Sat, 25 May 2013 14:29:12 +0300
Sergei Trofimovich wrote:
> If you can't change options at boot time it's very simple to get
> unbootable system.
https://bugs.gentoo.org/show_bug.cgi?id=465236#c34
In above Bug #465236 at Comment #34 the suggestion has been made to
maybe call the wrapper /sbi
Isn't eselect for cases where I might want to reconfigure something or
add configuration values such as for bash-completion, do testing with
java-vm or python implementations during development, switch opengl
implementation depending on the graphics driver loaded and whatnot.
I don't see any of th
On Sat, 25 May 2013 13:13:36 +0200
Pacho Ramos wrote:
> I use e4rat and, for that, I need to add
> init=/sbin/e4rat-preload
>
> to my grub.conf, I guess this wouldn't change with this, no? :/
>
> Thanks for the info!
That instead of the default will first load e4rat-preload and only
after tha
On Sat, 25 May 2013 12:25:03 +0200
Peter Stuge wrote:
> I would actually expect the change to take effect immediately.
Then how would you be able to shutdown / reboot your system in a clean
way? The premise here is that when you boot with an init system you
must shutdown with that same init syst
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato wrote:
> Hi, since the whole discussion got somehow sidetracked on where and if
> to install for everybody the rc system specific files for everybody
> (that should be an implementation detail for the specific dohelper
> IMHO), I'm back to the other
El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió:
> Hi, since the whole discussion got somehow sidetracked on where and if
> to install for everybody the rc system specific files for everybody
> (that should be an implementation detail for the specific dohelper
> IMHO), I'm back to the o
Luca Barbato wrote:
> - init gets effectively switched only at boot/reboot
Please not on reboot, because an unclean shutdown shouldn't leave the
system in limbo.
On boot could work, except that it does add more steps (= more
fragility) to the boot process, which I think everyone wants to
avoid.
Hi, since the whole discussion got somehow sidetracked on where and if
to install for everybody the rc system specific files for everybody
(that should be an implementation detail for the specific dohelper
IMHO), I'm back to the other part of it: switching the actual init
implementation.
# WHY (no
89 matches
Mail list logo
