Gobolinux boot with S6 init and 66 tools

Hello everybody

I’m Yann-Kaelig and I would like to show you the result of a week of works to boot Gobolinux with S6 init and the 66 tools. There is still a lot of work to be done to get something usable in production.

I am having some problems during the execution of the boot which only allows me for the moment to have access to tty12 to accomplish debugging tasks.

I will see with my knowledge what I can fix but whatever happens I intend to share in the coming days all of my work, my notes, Recipes, Build logs, Packages and Issues :slight_smile:

It looks pretty promising overall, it puts me in a good mood and I wanted to share this exciting moment with you.

Some links to start with S6 and 66:
Skarnet Softwares docs ( S6 - S6-rc … )
Obarun (Eric) Softwares docs ( 66 - 66-tools … )

66 Git Source files
66-tools Git Source files
Oblibs Git Source files

Back to work now.

1 Like

Well, it’s better now, I can get a login from tty1.

Fixed sysctl crash at boot looking for /etc/sysctl.conf which is not available on Gobolinux.
A quick fix was to create this file.

Since things seem to be going in the right direction now it’s time to share all my work and I also intend to offer a vdi and a raw image as a bonus. A common base to work on for debugging and improvements.

Gobolinux boot with S6 init and 66 tools


Rather calm on this Sunday in my work. New discoveries, BootScripts and BootOptions which are no longer useful now, however their content allows me to understand a little better how the system works.

Finally I have remote ssh access, something that didn’t work with StartTask. I created the Ssh service and it works now as you can see on the screenshots. On this first screenshot, I created a new system tree with the command line

66-tree -nEc system

then I enabled the service

66-enable -t system sshd

and finally I started the service

66-start -t system sshd

The -t system option is not mandatory in our case because the tree during its creation has been defined as being the Current tree we are working on, and the last two commands can be summed up with

66-enable -S sshd

On this second screenshot you can see how the symbolic links look like for each services and how a service file ( here sshd ) look like.

The issues I face now:

  • Symbolic links need to be created manually, at compile time I have to pass the option –symlink no because otherwise there is a strange behavior, given that different programs and services share the same path /usr/share/66/service

  • Service file ( here for example with sshd ) contains the path with the version number of the software which mean at each update or removal the service file must be updated and re-enabled to apply the change.

Note that sixtysix will first search for service in /etc/66/service and then in /usr/share/66/service.
For example, I want to modify a service provided by upstream packagers, I just need to copy it from /usr/share/66/service to /etc/66/service with my modification and re-enable it to take the changes into account.

That’s all for today, have a nice day/night.

1 Like

Good job!

SymlinkProgram should take care of creating symlinks for you under /System/Index/share/66/service – as long as Compile installs the program files under /Programs/Foo/Version/share/66/service. Could you clarify the installation process that requires a manual symlink creation?

Hello lucasvr and everybody.

I took some time this week to learn more about Gobolinux reading the wiki. English is not my native language, so I still have a lot of things to understand and for now I mainly help myself with existing recipes to roughly understand the thing.

I am now sharing part of my work, a number of services are still missing from the git repository which allow the system to boot but before finishing this work I would like to solve my issues.

Gobolinux S6init, 66Tools and Services Recipes

So let’s get to the facts with some screenshot to help to understand the issues.

This first screenshot is how /Programs/Service-Boot looks like after a compilation and installation.

This second screenshot is how /Programs/Service-ConsoleTracker looks like after a compilation and installation with the issue I’m going to explain.

The wrong thing here is the lack of /Programs/Service-ConsoleTracker/0.2.1/share folder and should contains 66/service/console-tracker@

The thing I understand is because share/66 is linked to the program Service-Boot everything that should have been in /Programs/Service-ConsoleTracker/0.2.1/share/66/service is now under /Programs/Service-Boot/2.3.1/share/66/service and this is not good.

Which introduces another issue when removing Service-ConsoleTracker with RemoveProgram as you can see on this third screenshot. Program Service-ConsoleTracker has been removed but the service file still exist in /Programs/Service-Boot/2.3.1/share/66/service and it’s not good.

This is why in my first test I had to use –symlink no during the compilation of Service-Boot and Service-ConsoleTracker, next manually create the folders /System/Index/share/66/{module,script,service} and finally manually create the symlinks for:

Service-Boot program like that:

ln -s /Programs/Service-Boot/2.3.1/share/66/module/boot@ /System/Index/share/66/module/
ln -s /Programs/Service-Boot/2.3.1/share/66/script/crypt.awk /System/Index/share/66/script/
ln -s /Programs/Service-Boot/2.3.1/share/66/script/modules.sh /System/Index/share/66/script/
ln -s /Programs/Service-Boot/2.3.1/share/66/script/tmpfiles.sh /System/Index/share/66/script/
ln -s /Programs/Service-Boot/2.3.1/share/66/service/boot@ /System/Index/share/66/service/

Service-ConsoleTracker like that:

ln -s /Programs/Service-Consoletracker/0.2.1/share/66/service/console-tracker@ /System/Index/share/66/service/

I’m pretty sure it should be possible to fix this issue in the recipe, maybe using pre_link () ? but right now I have no idea how to do it.