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
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
Dnia 2013-06-20, o godz. 23:16:00
William Hubbs willi...@gentoo.org 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 willi...@gentoo.org napisał(a):
On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
-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
willi...@gentoo.org 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
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
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.
2.
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 relying
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) or with
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 it.
Dnia 2013-06-21, o godz. 10:16:10
William Hubbs willi...@gentoo.org 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
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
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 that
On 21 June 2013 16:29, Michał Górny mgo...@gentoo.org wrote:
Dnia 2013-06-21, o godz. 10:16:10
William Hubbs willi...@gentoo.org 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
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
On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote:
On 21 June 2013 16:29, Michał Górny mgo...@gentoo.org wrote:
Dnia 2013-06-21, o godz. 10:16:10
William Hubbs willi...@gentoo.org napisał(a):
On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
If eselect-init
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 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 mgo...@gentoo.org wrote:
Dnia 2013-06-21, o godz. 10:16:10
William Hubbs willi...@gentoo.org napisał(a):
On Fri, Jun 21, 2013 at 12:23:28PM +0200,
On Fri, 21 Jun 2013, Luca Barbato wrote:
/bin/init
Why /bin? It shouldn't be in users' PATH.
Ulrich
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 my non-root
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
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 one
Dnia 2013-06-20, o godz. 15:56:09
William Hubbs willi...@gentoo.org 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
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 willi...@gentoo.org 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
-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
-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/switch-init
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
On Tue, 28 May 2013 05:55:39 +0200
Luca Barbato lu_z...@gentoo.org 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
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
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org 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.
On Sat, 25 May 2013 21:52:28 -0400
Walter Dnes waltd...@waltdnes.org 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
On Sun, 26 May 2013 04:02:56 +0200
Peter Stuge pe...@stuge.se 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
On Sun, 26 May 2013 08:43:32 +0200
Michał Górny mgo...@gentoo.org wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:
- /sbin/init (or whatever linux currently calls by default with top
priority) should be either a symlink to the actual implementation
or a
On Sun, 26 May 2013 10:58:23 +0200
Robert David robert.david.pub...@gmail.com wrote:
On Sun, 26 May 2013 08:43:32 +0200
Michał Górny mgo...@gentoo.org wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:
- /sbin/init (or whatever linux currently calls by
On Sun, 26 May 2013 10:58:23 +0200
Robert David robert.david.pub...@gmail.com 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
On Sun, 26 May 2013 11:20:25 +0200
Michał Górny mgo...@gentoo.org wrote:
On Sun, 26 May 2013 10:58:23 +0200
Robert David robert.david.pub...@gmail.com wrote:
On Sun, 26 May 2013 08:43:32 +0200
Michał Górny mgo...@gentoo.org wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato
On Sun, 26 May 2013 11:20:25 +0200
Michał Górny mgo...@gentoo.org 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
On 5/26/13 8:43 AM, Michał Górny wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org 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
On Sun, 26 May 2013 11:21:25 +0200
Tom Wijsman tom...@gentoo.org wrote:
On Sun, 26 May 2013 10:58:23 +0200
Robert David robert.david.pub...@gmail.com wrote:
Increased complexity is never safer. And a wrapper means the
additional complexity gets there every boot. And considering how
On Sun, May 26, 2013 at 6:01 AM, Robert David
robert.david.pub...@gmail.com 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.
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 just
On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato lu_z...@gentoo.org 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.
On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 5/26/13 8:43 AM, Michał Górny wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:
- /sbin/init (or whatever linux currently calls by default with top
priority) should be either a
On Sun, 26 May 2013 11:45:38 +0200
Tom Wijsman tom...@gentoo.org wrote:
On Sun, 26 May 2013 11:20:25 +0200
Michał Górny mgo...@gentoo.org wrote:
It is *easy*.
ln -s /sbin/newinit /sbin/init.new
mv /sbin/init.new /sbin/init
Easy and atomic. The inconsistency potential is
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
On 5/26/13 12:57 PM, Michał Górny wrote:
On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 5/26/13 8:43 AM, Michał Górny wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:
- /sbin/init (or whatever linux currently calls by default
On Sun, 26 May 2013 12:09:21 +0200
Michał Górny mgo...@gentoo.org 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
On Sun, 26 May 2013 12:57:42 +0200
Michał Górny mgo...@gentoo.org 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
On Sun, 26 May 2013 13:45:43 +0200
Tom Wijsman tom...@gentoo.org wrote:
On Sun, 26 May 2013 12:09:21 +0200
Michał Górny mgo...@gentoo.org 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?
On Sun, 26 May 2013 13:40:03 +0200
Luca Barbato lu_z...@gentoo.org 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
On Sun, 26 May 2013 12:01:19 +0200
Robert David robert.david.pub...@gmail.com 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
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
On Sat, May 25, 2013 21:55, Tom Wijsman wrote:
On Sat, 25 May 2013 21:09:47 +0200
J. Roeleveld jo...@antarean.org 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
On Sat, 25 May 2013 21:55:20 +0200
Tom Wijsman tom...@gentoo.org wrote:
On Sat, 25 May 2013 21:09:47 +0200
J. Roeleveld jo...@antarean.org wrote:
+1 for wrapper, from my understanding, symlinks for init-systems
can't be altered on a running system without risking strange
behaviour.
On Sun, 26 May 2013 14:59:28 +0200
J. Roeleveld jo...@antarean.org 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
On Sun, 26 May 2013 15:15:26 +0200
Michał Górny mgo...@gentoo.org 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
-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 in limbo.
On Sun, May 26, 2013 at 10:07 AM, Tom Wijsman tom...@gentoo.org wrote:
On Sun, 26 May 2013 15:15:26 +0200
Michał Górny mgo...@gentoo.org 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
On 5/26/13 1:58 PM, Tom Wijsman wrote:
On Sun, 26 May 2013 12:57:42 +0200
Michał Górny mgo...@gentoo.org 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
-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 is
-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
jo...@antarean.org wrote:
How will the stop/start part of services/init-scripts/... be
done?
Not sure
On Sun, 26 May 2013 16:52:27 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 5/26/13 1:58 PM, Tom Wijsman wrote:
On Sun, 26 May 2013 12:57:42 +0200
Michał Górny mgo...@gentoo.org wrote:
Switch inittab? Now you added really dangerous behavior to the
wrapper code. I can hardly even
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
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 inittab.
On Sun, 26 May 2013 11:48:30 -0500
William Hubbs willi...@gentoo.org 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
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 willi...@gentoo.org 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
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,
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
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
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.
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
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org 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
On Sat, 25 May 2013 12:25:03 +0200
Peter Stuge pe...@stuge.se 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
On Sat, 25 May 2013 13:13:36 +0200
Pacho Ramos pa...@gentoo.org 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
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
On Sat, 25 May 2013 14:29:12 +0300
Sergei Trofimovich sly...@gentoo.org 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
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 pa...@gentoo.org 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
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 you
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org 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
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 the
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
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 the
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 boot
On Sat, May 25, 2013 15:38, Tom Wijsman wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:
SNIPPED
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
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,
On Sat, 25 May 2013 21:09:47 +0200
J. Roeleveld jo...@antarean.org 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 !=
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.
On Sat, 25 May 2013 16:07:51 -0400
Alex Xu alex_y...@yahoo.ca 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.
On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote
On Sat, 25 May 2013 12:25:03 +0200
Peter Stuge pe...@stuge.se 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
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 one
89 matches
Mail list logo
