Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [Tracker] Dinit support (Read 8351 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: [Tracker] Dinit support

Reply #1 –
Is there a way to enable service via adding/editing some file? Dinit socket does not exist in chroot, also it will be hard to add proper serial tty script running on different arch
ARMtix

Re: [Tracker] Dinit support

Reply #2 –
Dinit works with ZFS, though I've added a script locally for "zfs mount -a" to make sure all my datasets are mounted

Re: [Tracker] Dinit support

Reply #3 –
Have been running dinit testing ISO with dwm for a couple of hours now. Everything works just fine. Thanks @konimex  for the excellent work.

Have a few questions,

1. Seems that dinit doesn't support run levels and cgroups. At least in current implementation in Artix.

2. How can we measure the time & order that dinit uses to bring the services up? Noticed some messages printed on tty1. Maybe we can also log them in a dedicated log?

Re: [Tracker] Dinit support

Reply #4 –
Quote from: phoenix_king_rus – on
Is there a way to enable service via adding/editing some file? Dinit socket does not exist in chroot, also it will be hard to add proper serial tty script running on different arch

You can do it like this: ln -s ../service_name /etc/dinit.d/boot.d/

Quote from: calvinh – on
Have been running dinit testing ISO with dwm for a couple of hours now. Everything works just fine. Thanks @konimex  for the excellent work.

Have a few questions,

1. Seems that dinit doesn't support run levels and cgroups. At least in current implementation in Artix.

2. How can we measure the time & order that dinit uses to bring the services up? Noticed some messages printed on tty1. Maybe we can also log them in a dedicated log?

  • Support on CGroups are crude, like it is on runit (i.e. just mounting the cgroups filesystem). Full support for cgroups are currently on dinit's plans post 1.0 (See https://github.com/davmac314/dinit/blob/master/TODO)
  • The time? For now, I can't really say since I don't test that part myself. The order? We can look at the depends-on and waits-for in the services. As for the logging, we only log the services for now (see /var/log/dinit). But perhaps we can use bootlogd for overall boot process. As for the some messages printing, the tty service started messages should be the last one (i.e. if wpa_supplicant or mysql runs, it won't spam the screen).
now only the dinit guy in artix

Re: [Tracker] Dinit support

Reply #5 –
Quote from: konimex – on
You can do it like this: ln -s ../service_name /etc/dinit.d/boot.d/
Thanks, that partially solved the problem

Quote from: konimex – on
The order? We can look at the depends-on and waits-for in the services.
But this appeared to be a new one. When i tried to add new tty service to boot.d (i copied tty2 and replaced all its tty references to ttyAMA0 to test in qemu) i got cycling dependency error on boot. So, where is "entrypoint" (if any) for dinit from which it builds service tree? Or maybe /etc/dinit.d/boot can be backuped so that user can modify it and doesn't lose changes after update?
ARMtix

Re: [Tracker] Dinit support

Reply #6 –
Quote from: phoenix_king_rus – on
But this appeared to be a new one. When i tried to add new tty service to boot.d (i copied tty2 and replaced all its tty references to ttyAMA0 to test in qemu) i got cycling dependency error on boot. So, where is "entrypoint" (if any) for dinit from which it builds service tree? Or maybe /etc/dinit.d/boot can be backuped so that user can modify it and doesn't lose changes after update?

The entry point is, of course boot. boot waits for loginready which in turn waits for boot.d (I made it this way originally to reduce the printing messages on tty1, but it only partially works).

It's a cyclic dependency because ttyAMA0 depends on loginready, which in turn waits for.. boot.d, which contains ttyAMA0. Anyway, I can either do what you suggested, or create a dedicated internal getty folder (/etc/dinit.d/getty.d), so that boot depends on getty, and people can add whatever tty they want in /etc/dinit.d/getty.d/. Let me know what you think.
now only the dinit guy in artix

Re: [Tracker] Dinit support

Reply #7 –
Quote from: konimex – on
create a dedicated internal getty folder (/etc/dinit.d/getty.d), so that boot depends on getty, and people can add whatever tty they want in /etc/dinit.d/getty.d/. Let me know what you think.
This one sounds even better

UPD: ARMtix dinit rootfs is uploaded now
ARMtix

Re: [Tracker] Dinit support

Reply #8 –
Subject: runit and dinit conflict during Arix-runit installation from base ISO

1. Problem: Some conflicts arise between runit and dinit packages during Artix-runit installation from base ISO.

2. Description: Trying to install Artix-runit from the base ISO:

artix-base-runit-20210726-x86_64.iso  846 MB  2021-07-25 15:16:15

Doing installation by strictly following Artix Wiki Installation article:

https://wiki.artixlinux.org/Main/Installation

Everything works fine until runit and elogind-runit packages installation.  basestrap returns the error about runit and dinit being in conflict and refuses to install two packages.

(typed in by hand on another computer):
Code: [Select]
artixlinux:[artix]:~$ sudo basestarp /mnt runit elogind-runit
==> Creating install root at /mnt
  -> Installing packages to /mnt
:: Syncronizing package databases...
 system is up to date
 world is up to date
 galaxy is up to date
resolving dependencies...
looking for conflicting packages...
:: runit and dinit are in conflict (svc-manager).  Remove dinit? [y/N]
error: unresolvable package confliicts detected
error: failed to prepare transaction (conflicting dependencies)
:: runit and dinit are in conflict
==> ERROR: Failed to install packages to new root
artixlinux:[artix]:~$

Artix Wiki Installation guide doesn't describe this situation.

Actually, there are two more conflicts between runit and dinit.  They are shown below.

3. Solution: run basestrap with auto-confirmation disabled and two overwrites

By default, basestrap runs with auto-confirmation enabled.  So it auto-responds with N to "Remove dinit? [y/N]" question.

Add -i switch to run basestrap command with auto-confirmation disabled and to reply with y to the question (the command still fails, for other reasons):
Code: [Select]
sudo basestrap -i /mnt runit elogind-runit
(typed in by hand on another computer):
Code: [Select]
artixlinux:[artix]:~$ sudo basestarp -i /mnt runit elogind-runit
==> Creating install root at /mnt
  -> Installing packages to /mnt
:: Syncronizing package databases...
 system is up to date
 world is up to date
 galaxy is up to date
resolving dependencies...
looking for conflicting packages...
:: runit and dinit are in conflict (svc-manager).  Remove dinit? [y/N] y
:: elogind-runit and elogind-dinit are in conflict (init-elogind).  Remove elogind-dinit? [y/N] y
:: dbus-runit and dbus-dinit are in conflict (dbus-dinit).  Remove dbus-dinit? [y/N] y
warning: dependency cycle detected:
warning: runit-rc will be installed before its runit dependency

Packages (10):

bootlogd-2.89-2
dbus-dinit-20211104-1 [removal]
dbus-runit-202104-27-1
dinit-0.12.0-4 [removal]
elogind-dinit-20211030-1 [removal]
logrotate-3.18.1-1
popt-1.18-1
runit-rc-20210122-1
elogind-runit-20210413-1
runit-2.1.2-28

Total Download Size:   0.50 MiB
Total Installed Size:  2.06 MiB
Net Upgrade Size:      1.79 MiB

:: Proceed with installation? (Y/n) Y
:: Retrieving packages...
 popt-1.18-1-x86_64
 logrotate-3.18.1-1-x86_64
 bootlogd-2.89-2-x86_64
 runit-rc-20210122-1-x86_64
 runit-2.1.2-28-x86_64
 dbus-runit-202104-27-1-any
 elogind-runit-20210413-1-any
 Total (7/7)
(7/7) checking keys in keyring
(7/7) checking package integrity
(7/7) loading package files
(7/7) checking for file conflicts
error: failed to commit transaction (conflicting files)
runit-rc: /mnt/usr/bin/modules-load exists in filesystem (owned by dinit-rc)
runit-rc: /mnt/usr/share/man/man8/modules-load.8.gz exists in filesystem (owned by dinit-rc)
Errors occurred, no packages were upgraded.
==> ERROR: Failed to install packages to new root
artixlinux:[artix]:~$

runit and elogind-runit are about to be installed, but they conflict with dinit files already existing in filesystem.

Run basestrap with auto-confirmation disabled and two pacman's-style --overwrite options to overwrite existing files and avoid conflicts.  The full command is:

Code: [Select]
sudo basestrap -i /mnt runit elogind-runit --overwrite /mnt/usr/bin/modules-load --overwrite /mny/usr/share/man/man8/modules-load.8.gz

The command successfully installs runit and elogind-runit packages.

Other encountered problems (all solved) are not related to runit and dinit.  Installation arrives up to the end.  Installed DE behaves as expected.


With respect

Re: [Tracker] Dinit support

Reply #9 –
Quote from: phoenix_king_rus – on
This one sounds even better

UPD: ARMtix dinit rootfs is uploaded now
Pushed dinit-rc 0.0.21

Quote from: just – on
[...] (post too long to be quoted)
Someone changed the installation instructions entirely, causing the problem in the first place. The inits should've been installed together with the base, so the command should've been something like this:
sudo basestrap -i /mnt base elogind-runit

Installing elogind-runit will automatically pull the init package, so you won't have to reinstall the init package anymore, causing the conflict.
now only the dinit guy in artix

Re: [Tracker] Dinit support

Reply #10 –
Quote from: konimex – on
You can do it like this: ln -s ../service_name /etc/dinit.d/boot.d/

  • The time? For now, I can't really say since I don't test that part myself. The order? We can look at the depends-on and waits-for in the services. As for the logging, we only log the services for now (see /var/log/dinit). But perhaps we can use bootlogd for overall boot process. As for the some messages printing, the tty service started messages should be the last one (i.e. if wpa_supplicant or mysql runs, it won't spam the screen).

I was trying to see how dinit handles the dependencies in runtime. A boot log like /var/log/rc.log in OpenRC should be simple enough to provide both the time and order information for the boot process. Given dinit in Artix is still in early testing stage, we can add more little pieces in the future.

BTW all Calamare installers in weekly builds are broken. Need to update them...

Re: [Tracker] Dinit support

Reply #11 –
Quote from: calvinh – on
I was trying to see how dinit handles the dependencies in runtime. A boot log like /var/log/rc.log in OpenRC should be simple enough to provide both the time and order information for the boot process. Given dinit in Artix is still in early testing stage, we can add more little pieces in the future.
Try to install and enable bootlogd-dinit. The bootlog location will be in /var/log/boot, but it works partially as it needs access to /dev/console (i.e. this means pseudofs will never show up on startup).

Quote from: calvinh – on
BTW all Calamare installers in weekly builds are broken. Need to update them...
We'll need to wait for the ISO guys it seems.
now only the dinit guy in artix

Re: [Tracker] Dinit support

Reply #12 –
Quote from: konimex – on
...
Someone changed the installation instructions entirely, causing the problem in the first place. The inits should've been installed together with the base, so the command should've been something like this:
sudo basestrap -i /mnt base elogind-runit
...
TLDR:  there are no runit and dinit conflits anymore.  The issue is solved.

Re-installed Artix-runit base ISO from scratch, following restored old Installation guide (the current one).  Though not as complete and useful as removed guide, it hits the main goal - helps to completely avoid any conflict between runit and dinit.

Artix-runit Gnome is installed from base ISO and runs very smoothly.

A mix of best parts from removed Installation guide and the current one would be great.

The subtopic "runit and dinit conflict" is solved and closed.  Thanks.

Re: [Tracker] Dinit support

Reply #13 –
I have got the following error messages booting dinit with nfs-server and haveged enabled:
Code: [Select]
dinit: rpcbind: execution failed - setting up standard input/output descriptors: No such file or directory
[FAILED] rpcbind
[FAILED] statd
[FAILED] nfs-server
dinit: haveged: execution failed - setting up standard input/output descriptors: No such file or directory
[FAILED] haveged
nfs-server (and its deps) is started right after pseudofs which seemd to be too early. The problem with haveged is completely unclear to me
ARMtix

Re: [Tracker] Dinit support

Reply #14 –
Quote from: phoenix_king_rus – on
I have got the following error messages booting dinit with nfs-server and haveged enabled:
Code: [Select]
dinit: rpcbind: execution failed - setting up standard input/output descriptors: No such file or directory
[FAILED] rpcbind
[FAILED] statd
[FAILED] nfs-server
dinit: haveged: execution failed - setting up standard input/output descriptors: No such file or directory
[FAILED] haveged
nfs-server (and its deps) is started right after pseudofs which seemd to be too early. The problem with haveged is completely unclear to me
There should be a log in /var/log/dinit for both rpcbind and haveged. Anyway, moved rpcbind and haveged to be started after setup.
Should be in the newest package now.
now only the dinit guy in artix