User Tools

Site Tools


The changes that took place

Beginning with 66, version 0.4 and above, you are able to utilize this enormous ability to fine tune your machine for your specific use(s) and how quickly you can switch the machine's nature from one utility to the next.

After installing 66-0.4 (or above) and running 66-update (from this version onward you will no longer need to run 66-update. 0.4 was a transitional stage of 66 development to prepare the transition of traditional services to modules) you will see a difference in your /etc/66/conf.

Configuration files are now versioned. For example you will see /etc/66/conf/connmand/0.2.0/connmand instead of /etc/66/conf/connmand. Previously /etc/66/conf housed the environment part of each service's configuration.

Inside this directory you will notice a symlink called @version. This symlink points to the current configuration file used by the service (in this case 0.2.0/connmand). 0.2.0 pertains to the version of service/front-end file versioning, unrelated to the 66 version.

So, when a new version of service file comes from upstream, 66 will take care of the version@ symlink and update it according to the new version. Therefore from this point onward the user will not have to manually configure anything, unless the user wants to change something in their system, unrelated to updates.

Expect service versions to come in the near future. This structure is mandatory so we will be able to have a correct 66-backup tool. Not yet available, but in the future when 66 and services change and 66-update produces an outcome that is undesirable, it will be simple to roll back to a backup of the structure and utility of 66 trees and services.

This change, of /etc/66/conf is the only visible part for the user, which is also why boot.conf vanished from /etc/66.

The boot@ module

Assuming you have already read the “introduction to modules” the following document is meant as a continuation and more specific to the boot@ module.

Note that boot-66serv and boot@-66serv are very different. They are both sets of many different services and type of services, sometimes referred to as a bundle of services. The primary difference is that where boot (0.1.xx) was a fixed set of services, some of which can be disabled and not utilized, or enabled, if they weren't by default, while with boot@ module the unutilized services are not just disabled but eliminated from the booting process all together. In other words, booting doesn't process all the services listed in the group, as in the earlier boot service, and marks some as disabled and goes to the next, but only processes those that are configured as needed. This speeds up the booting process significantly, whether it is a very simple desktop system or a complex server; they can both benefit by this change.

You will find the service front-end file as any other service at /usr/lib/66/service. As any other service you can make a copy of that service at /etc/66/service. As any other service you will find its configuration file at /etc/66/conf/boot@<name>. As any other service you can enable, disable, start, stop the service with the classic 66 tools: 66-enable, 66-disable, 66-start, 66-stop

A service of type “module” works in conjunction to a directory located at /usr/lib/66/module/boot@. This directory should not concern the user. Users do not need to take care of this directory. This directory will be handled by the package manager and various 66 tools.

How to handle this kind of service?

Previously to enable the boot service set you did:

66-enable -t boot boot

The first boot was the name of the tree, which remains as default but can be changed if you wish at /etc/66/init.conf, and the second was a service bundle (a service directory that incorporated many services pertaining to booting) that was necessary to boot a linux system.

This is exactly the same command used for the module, except that you need to handle it as any other instantiated service (a dedicated module type of service), so:

66-enable -t boot boot@system

(where system is an arbitrary name, you can give it your own, as long as a name to differentiate it from others is given, boot@ alone will not work, it is pointing to nothing)

Previously when you wanted to enable again the boot service set (usually after reconfiguring it), you did:

66-enable -F -t boot boot

This is exactly the same thing with the “module”:

66-enable -F -t boot boot@system

Previously when you wanted to configure your boot sequence you did:

$EDITOR /etc/66/boot.conf

and you rebooted.

The difference here, you need to edit the configuration file AND to enable again the service, so:

$EDITOR /etc/66/conf/boot@system/<version>/boot@system

If an editor is set in your shell environment you can skip this long command and use this:

66-env boot@system

(see the documentation for 66-env)

With this tool you don't need to know, or look for, the exact location of the configuration file. It knows the version used and points to the correct configuration file, currently used by the service boot@system, to modify.

This is valuable for any services or service bundles, like boot@. Alternatively you can use 66-inservice and the output for the particular service shows which configuration file it is using.

So, now you have changed the configuration of your boot, you need to enable it again to apply this change like this:

66-enable -t boot -F boot@system

“Hum, this is a little more “complicated” than just changing the boot.conf file”.

Right, but the benefit overshadows by far this additional command complexity. Once it is set as you like it to be, you don't have to do it again unless you want to change something.

“I really don't see the benefit!”

In a few words, the famed fastest booting linux machine (Obarun) just got a little faster, whether it is a lean plain system or a complex one, they both got faster!


Previously your boot sequence included all services even if you didn't use them.

For example, you set ZFS=!no (in /etc/66/boot.conf) but the service ZFS was included inside your boot sequence. At start the ZFS service checked your configuration file (/etc/66/boot.conf) to see if it needs to start it or not.


Now, the service is not included at all on your boot sequence. So, yes you have to issue an additional command when you want to change something or your boot process, but the boot sequence will not check additional services every time the system starts.

So, a little more for you (once) but much less for your machine during “every” boot.

"An additional twist"

You can have many different boot sequences for the same machine: boot@container, boot@tz_delhi, boot@tz_hawai, boot@full_of_tty, boot@with_firewall You may have a default boot tree and each of the additional boot modules can have their own separate tree. The system will boot what is specified as the boot tree in /etc/66/init.conf The rest can alternatively be manually specified at bootloading as follows:

To do so, at kernel command line that begins with the term linux (grub, syslinux, lilo,…) you can add: TREE=<tree to boot from> at the end of that line, no need to edit your /etc/66/init.conf each time and reboot.

This is the only difference from a user's point of view. The rest is made “under the hood”, inside 66. You don't have to worry about it, but you can if you like since it is open and free code.

For other specific use of modules, as boot-user@ go to document 3

To see the procedure on how to make the transition from boot (service bundle) to boot@ see the Quick Reference section below (based on the obnews 10-26-2020 document):

Quick Reference to boot@ module

(as seen in the bulletin of obnews 10-26-2020)

The “boot-66serv” was “renamed” as “boot@-66serv” and became a module type of service, like boot-user@-66mod. Also, “boot-user@-66mod” was “renamed” as “boot-user@-66serv”.

As a side effect, the “” was used previously to configure a module. This program does “not exist” anymore. The functionalities of the “” program was directly integrated to the “66-enable” since the “” 66 version.

The “/etc/66/boot.conf” file does “not exist” anymore. As the “boot@-66serv” is now a module, it will be configured by the “66-env” program (see below).

In addition, the boot@-66serv package installs its corresponding man page to your system. So:

console help

% man boot@

to see the documentation of the boot@ module from terminal/console

Rebuild the boot tree

Five steps

First you must disable the services of your boot tree:

Note: all following commands must be issued as root


# 66-disable -t boot tty12 All

After the successful execution of this command, you “should” get an empty boot tree.

Make sure that the boot tree IS EMPTY before proceeding.

Now enable the new version:


# 66-enable -F -t boot boot@system

“Note:” a module type of service is also an instantiated service. So you can name it what you want at enable time, e.g boot@my_system, boot@container and so on…

You need now to configure the boot@system service. To edit its configuration file use the 66-env program:


# 66-env -t boot boot@system

Your preferred editor should display the contents of the configuration file. Change what you need inside, save it and exit.

“Note: Be sure when enabling certain services within the boot@ module that the dependencies are satisfied or booting will fail.”

To apply your changes you need to re-enable the service:


# 66-enable -F -t boot boot@system

Your boot tree is ready for your next boot but a supplementary change is needed concerning the tty@ service.

Previously, you needed to enable the tty@ service/s outside the boot tree, in an another tree (generally root on Obarun). The tty-rc@ service is now a part of the boot@ service and the number of tty to start at boot time is set with the “TTY=” variable at the boot@ service configuration file. To avoid conflict between the tty enabled with the boot tree and other tty enabled outside this tree, you need to disable every tty@ service on any tree. For example:


# 66-disable -t root tty@tty1 tty@tty2

If you don't know where the tty@ service was enabled, use the “66-intree” program to find the tree and how many were enabled.

boot-user@ module

Furthermore boot-user@ module, if chosen, to use user level services, see how to configure in the dedicated document.

boot.txt · Last modified: 2021/02/20 08:02 by wikiman