Search:  
Gentoo Wiki

EINIT


Note: Einit has gone through a reworking and the project is now kyuba.

Contents

Introduction

What is eINIT?

eINIT is an “Init-System” for Unix operating systems. To figure out what this means, I’ll explain some things about how unices boot, and we’ll use Linux on an x86 as an example. Whenever you turn on your computer, the following happens:

The /sbin/init part is what eINIT does.

Really, what is eINIT?

eINIT is an "Init-System" for Unix operating systems. "Init" is the first program to be run by most Unix kernels after the kernel finishes initialization. Most Unixes these days use a package called "System V Init" for that purpose -- as the name suggests, this system was derived from how things were handled on System V Unix.

On *BSD, the actual initialization is done by a script located at /sbin/rc, and on Linux, the initialization is performed using scripts located at /etc/init.d. Both of these "regular" systems have their pros and cons -- BSD's single script approach puts relatively little strain on the system and is rather straightforward, the init.d approach is nice and could allow for parallelism, but that's hardly ever implemented and the use of a large number of scripts is quite a large overhead.

"eINIT" seeks to fix this overhead by integrating module management into the init system itself and make init.d scripts obsolete, and also to decrease overall boot time by using aggressive parallelism.

So why eINIT?

Yes, Good question. Most Linux Distributions put some clone of System-V's init in place. When this init is run by the kernel, it will read a file called "inittab" which contains information about what runlevel to boot, what scripts to run, etc. That usually results in an /sbin/rc or /etc/rc script to be run, which will in turn try to start a set of scripts. Then, upon completion of the rc-program, init will set up a set of ttys so that you can log-in and begin working.

All of this works great and tends to be very stable, but it has some drawbacks (even though most of these might be irrelevant on fast machines):

eINIT tries to address all these problems.

Installation

Warning: eINIT is fairly stable now and many people use it including me, still this is beta software, and should be used as such. You may have problems with it, such as random reboots, filesystem corruption, etc. It does cleanly unmount filesystems, and we've not seen a single case of actual filesystem corruption, but don't come crying if it sets your cat on fire. You've been warned.

Using the Official eINIT overlay

Portage

eInit is in portage, you just need to un-keyword it.

echo "sys-apps/einit" >> /etc/portage/package.keywords
echo "sys-apps/einit-modules-xml" >> /etc/portage/package.keywords
emerge einit einit-modules-xml  -av

Paludis

Paludis users can follow the following instructions. Paludis, a portage replacement, will use a repository configuration file similar to this one:

You can use the ebuild from the portage repository, and optionally add the jyujin repository:

playman -a jyujin
Note: einit-modules-xml from portage appears to conflict/be renamed by einit-modules-simple in jyujin

Configuring the Bootloader

To use eINIT, you will have to modify your bootloader configuration.

Be warned: If you get this wrong, your system may no longer boot.

When you create the new entry, to boot using eINIT, leave the old entry (booting using sysvinit) in the configuration file: eINIT is still in beta, and maybe somewhat unstable for you. If you can't boot, you will want to be able to boot using sysvinit, so you can change the eINIT configuration.

LILO

If you are using Lilo as your bootloader, you will need to create a new entry in /etc/lilo.conf. Open the file in a text editor, copy your existing entry (giving it a new name), and add the following line:

append = "init=/sbin/einit"

For example:

File: /etc/lilo.conf
# Working
image = /boot/kernel-2.6.11-gentoo-r9
   root = /dev/hda2
   label = Gentoo-2.6.11-r9
   read-only

# eINIT
image = /boot/kernel-2.6.11-gentoo-r9
   root = /dev/hda2
   label = Gentoo-2.6.11-r9-eINIT
   append = "init=/sbin/einit"
   read-only

GRUB

If you are using GRUB as your bootloader, you will need to create a new entry in /boot/grub/grub.conf. You may need to mount /boot first. Open the file in a text editor, copy your existing entry (giving it a new name), and add the following to the end of the "kernel" line:

init=/sbin/einit

For example:

File: /boot/grub/grub.conf
hiddenmenu
timeout 5
default 0
fallback 1
splashimage=(hd0,0)/grub/splash.xpm.gz

# Working
title   GNU/Linux 2.6.11-gentoo-r9
   root (hd0,0)
   kernel /kernel-2.6.11-gentoo-r9 root=/dev/hda2

# eINIT
title   GNU/Linux 2.6.11-gentoo-r9 (eINIT)
   root (hd0,0)
   kernel /kernel-2.6.11-gentoo-r9 root=/dev/hda2 init=/sbin/einit

Configuring eINIT

Basic Info

At this point there is no CLI, TUI or GUI to configure eINIT. So you need to manually edit the configuration XML files.

XML files aren't that hard once you get the hang of it though. And, of course, if you create a configuration tool yourself, feel free to tell the authors and they'll likely include it in the upstream release or provide links to it.

Files to edit

The very first thing we need to do is get a list of services einit currently supports.

einit -p -ls /services/all > ~/einitservices

We now have to figure out exactly what rc-scripts are loaded on startup.

rc-config show boot >> ~/rcservices
rc-config show default >> ~/rcservices

local.xml

Note: All the eINIT files to be edited are located in /etc/einit

First we need to edit:

/etc/einit/local.xml

This file is an overlay for /lib/einit/einit.xml. Settings you change here override what is in that file. The first thing we are going to do is set our timezone. You can find your previous setting in /etc/conf.d/clock

<system>
  <timezone s="America/New_York"/>
</system>

Next we are going to configure the kernel modules that need to be automatically loaded at boot. Take a look at /etc/modules.autoload.d/kernel-2.6 to see what is currently loading at startup. The actual module declarations can be done in different ways.

You can have one tag that lists all of the modules you need to load:

<kernelmodules s="nvidia:e1000:iwl4965:uvcvideo" />

Or you can have multiple lines that group your modules:

<nvidia s="nvidia" />
<network s="e1000:iwl4965" />
<webcam s="uvcvideo" />

So the end result with method one is this:

<kernel>
 <modules>
  <kernelmodules s="nvidia:e1000:iwl4965:uvcvideo" />
 </modules>
</kernel>

And the end result with method two is this:

<kernel>
 <modules>
  <nvidia s="nvidia" />
  <network s="e1000:iwl4965" />
  <webcam s="uvcvideo" />
 </modules>
</kernel>

Both methods are equivalent in function.

Note: It does not matter what you put after the < in your module declarations. <foo is the same as <carrot

Now we will define some service groups. Service groups are useful because they allow you to group together services that einit provides into one neat little group. To find your services, look in the ~/einitservices file we created earlier. Those exact names can be used in the service groups. Here is an example:

<alias>
 <audio group="alsa:kern-alsa" seq="all" />
 <bluetooth group="bluetooth-hci:bluetooth-sdp:bluetooth-rfcomm" seq="all" />
</alias>

As you can see, the name of the service group is the first thing after the <. This is what you will later put into modes.xml. After that is the group= attribute. Inside the "" are the services that belong to that group separated by a :. The last attribute, seq, indicates that all services in the group should be started when that group is started.

Note: In the audio group, alsa is the service that restores mixers while kern-alsa is the service that auto-detects kernel modules

modes.xml

The runlevels, their actions and the services in them are defined in the file:

/etc/einit/modes.xml

To add a service to a runlevel, edit modes.xml. For example:

<mode id="default" base="boot">
 <enable services="network:ntp-client:audio:dbus:hal:displaymanager:mount-remote:ipc-dbus" />
 <overrides>
  <ttys s="tty1-regular:tty2-regular:tty3-regular:tty4-regular:tty5-regular:tty6-regular" />
 </overrides>
</mode>

This is the default runlevel. The boot runlevel is the <mode> without an id=.

To add a service, find the service that you wish to add in the ~/einitservices and add it to the services attribute, separating services with a :.

For example if you want to add acpid the line

<enable services="network:ntp-client:audio:dbus:hal:displaymanager:mount-remote:ipc-dbus:bluetooth" />

should become

<enable services="network:ntp-client:acpid:audio:dbus:hal:displaymanager:mount-remote:ipc-dbus:bluetooth" />

Notice how the audio group is used as a service here. The audio group will launch all services that are defined in the local.xml file for that group. The same is true of bluetooth. The displaymanager is optional. You can also explicitly define your display manager by adding it as a service with a v- in front. For example, kdm would be v-kdm:

<enable services="network:ntp-client:audio:dbus:hal:displaymanager:mount-remote:ipc-dbus:bluetooth:v-kdm" />

You are going to want to add all services found in ~/rcservices to the appropriate runlevel in modes.xml. einit does the filesystem checking for you, so you don't need to worry about localmount, checkfs, checkroot, etc.

If you add local to your default runlevel, you are going to need to either copy /etc/conf.d/local.* over to /etc/einit/conf.d or symlink them. I recommend symlinking them so that way both sysv and einit can see all changes made to the files.

ln -s /etc/conf.d/local.* /etc/einit/conf.d/

network.xml

The network configuration is done through the file

/etc/einit/network.xml

Please see this article on how to properly configure advanced networking

Service Configuration

The configurable services have the configuration files in /etc/einit/conf.d. The XML files here are just like the config files in /etc/conf.d/.

fstab.xml

einit can use either /etc/fstab or /etc/einit/fstab.xml for mounting your drives. The file itself is commented on its usage. Most people will want to leave this file alone and allow einit to use /etc/fstab.

Check configuration

Now that we have finished configuring einit, we need to run one more command to ensure that we have not made an error.

einit --wtf

This command will check our configuration files and tell us where problems in the configuration files occur. If a problem is reported, go back and fix it and then recheck for errors. Do so until einit --wtf reports no problems are found.

You can go ahead and delete ~/einitservices and ~/rcservices.

Usage

All einit services are enabled and disabled via the einit program. To initialize a service:

einit -e <service>

To stop a service that is already loaded:

einit -d <service>

You can also enable and disable einit modules on the the fly.

einit -em <module>

will enable a module while

einit -dm <module> 

will disable a module.

Type

einit --help

for all options.

Logging

During Boot and shutdown eINIT logs the info to /var/log/einit.log while logging daemon is not up when it is up it will push the logs to the logging Daemon.

See also

Help is available at the eINIT forum and the IRC channel.

Retrieved from "http://www.gentoo-wiki.info/EINIT"

Last modified: Thu, 11 Sep 2008 16:20:00 +0000 Hits: 8,190