[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: OpenRC as Init System for Debian

On Sat, 2012-04-28 at 02:29 +0200, Vincent Bernat wrote:
> OoO Vers la  fin de l'après-midi du vendredi 27  avril 2012, vers 16:29,
> Svante Signell <svante.signell@telia.com> disait :
> > Apparently it can today ... with init scripts, which _new_ features will
> > be brought in for the _boot_ process. udev takes care of the events,
> > already today, right? More secure boot, faster boot (coreboot), better
> > debugging, simple ways of logging the boot massages, etc? Don't talk
> > about plug-and-p{r}ay, that is not interesting for _boot_: Found new
> > hardware, eh?
> But that's the whole point : new hardware pops up while booting. See for
> example a server that will need  a 3G connection. The 3G connection will
> be done  by some  classic USB key.  When the  USB key is  detected, udev
> triggers a script  asking the USB key (which defaults  to a mass storage
> device) to  switch to  "modem mode".   Once it becomes  a modem,  the 3G
> connection  can be initialized.   Turning the  USB key  into a  modem is
> taking   some  time.   The   USB  key   will  be   "disconnected",  then
> "reconnected". SO, "found new  hardware".  ifupdown scripts were already
> run and filed with "interface not found".

Nice description, thanks. However, this is not necessarily part of the
_boot_ process!! This could/should happen _after_ the computer is up and
running, e.g. when starting X. You are not able to use your USB modem
until then anyway, and boot times should be as short as possible, not
having to wait for a dongle to connect to the wireless network. So, the
real problem is: How do you define the boot process of a computer. For
me it is when the kernel has been loaded by the boot media, memory,
graphics card, etc initialized. Some modules are needed for boot, other
modules can be loaded later. The only case I can see when you need a
network during the boot process is when booting from the network, and
for that you can predefine which modules to load.

> udev can run simple actions when a device appears but cannot run a chain
> of dependencies  (start the  3G connection, run  some daemon  that needs
> Internet  which in  turn  will trigger  some  client to  this daemon  to
> run). The solution is an event-based init. We want a reliable boot.

Then the functionality of udev should be extended, not dragging the
init scripts into this udev<->Linux kernel interaction. I think it
would be much better to isolate these two instead of having a third
(potentially buggy) software included. 

> We are in 2012 and if a non-essential daemon blocks the boot (no working
> network), we have no way to get a getty to be run.

See the reply from Thomas Goirand.

Reply to: