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 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 might or might work since linux has some
fallback capabilities but hadn't been tested.
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...
Openrc is small, but the wrapper really needs to know which is which and
worst case switch inittab.
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.
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.
Did anyone notice already that moving stuff around actually requires
rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit
of init/RC work.
Noticed and known issue, I merely stated which are the options on the
plate, keep in mind that init addons people use and we distribute do
even more evil stuff.
And what will happen if moving the files fail? What if half of
configuration belongs to old init, and half to new? And it all happens
automagically on boot, on an incomplete system without any console
started, without Internet connection established and without any
serious mean of help.
You can:
- consider rolling back
- drop to a shell
Nothing so terrible.
And did you? You keep repeating this and jumping straight to developing
work-arounds without even waiting for an answer. And I think William
has already spoken that the code supports it.
I read the code up to do_exec, given for me it would require have a
roundtrip to the efi shell I was hoping those proposing that would do
that basic homework =)
In any case, I've just tested it. Replaced /sbin/init with a dangling
symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh
as a fallback.
That's all I wanted everybody knows, thanks for helping.
OpenRC relies on a few layers of various tools plus a lot of init
scripts written by different people. Those init scripts include tasks
such as parsing configuration files (well, more of grepping them)
and manipulating runtime files. The complexity of OpenRC is the sum
of all that.
I read it as "as complex as the user wants".
To make this point cleaner to you: what if the fallback ran systemd
instead? As in, init gets broken somehow and kernel falls back to
starting systemd on your unprepared OpenRC system. Is this a behavior
you'd like?
I would expect any sane init would get me at least to their single mode.
What I'm telling is: if user uses A as init system (and wanted to switch
to B), last thing he'd expect is C being started. Configuration for
OpenRC may be long unmaintained, may start services which are not
supposed to be started anymore and so on.
The safest would be dropping to a shell in your scenario.
As I stated from start the "switch on boot" would work so the wrapper
checks a switch had been requested, it knows the current init, that must
work since worked the previous boot, the next init, that supposedly
should work, does the pivoting, shuffling and such and the next boot it
just hands over to the current init.
The wrapper could even install and uninstall itself.
Again, my object of interest is being able to use bb-init and runit.
We're not talking about percentages here. A *single* fragile script is
enough to cause trouble. Ten good ones won't revert it.
A single fragile script can be fixed I guess, which is the one you have
in mind that is concerning?
What are you talking about now? I was just saying that *if* you
link /sbin/init to systemd, and you're running sysvinit, 'init foo'
will be passed through to telinit.
But now I see that I was wrong and it actually happened when
'systemctl' was symlinked to 'init'. Nevermind then.
In any case, keeping all the tools like 'telinit' should be *enough* to
keep the current init running and rebooting.
You are focused on systemd, I'm focused on bb-init among the rest, it
uses a different syntax for the inittab, so if you want to switch from
one or another you either prepare a least-action script that switch the
inittab on reboot or a first-action script that does that on boot.
For your needs probably just pivoting a symlink should work almost fine,
as long your stay sysvinit compatible, yet doing that as early init or
as post kill-all should work better even in your case.
lu