Everything works out of the box, void as already packaged s6/66 software. It miss the boot-66serv. So cloning it -> configure -> make install and that it

We need to change the options at 66-boot command into the /usr/bin/init file to be able to boot properly. The initramfs from void mount the run directory with noexec as option which avoid to execute program. Obviously this option block the boot because 66 use /run/66 to store and run the necessary program

Well simply edit the /usr/bin/init like this:
# !/usr/bin/execlineb -P
66-boot -m /run
This will umount the /run directory and remount it without the noexec option
So far so good



So, boot-66serv seem really portable :p
That is REALLY impressive. Now I should really look into making the changes necessary to package it...
I don't want to brag but with my unorthodox ways I had void-66 since 66 was in beta [66] but it was a pain in the neck keeping up and trying to juggle between two pkg-managers. The bare essentials came from obarun and dependencies came from void, except I think 2-3 pkgs that arch repackaged specially to fit the needs of pacman (curl and something else). But this was plastering the binaries from one to the other, not real void. Arch kernel with mkinitcpio not dracut.

I can't wait to get void-musl and 66 married, to me that would be the ultimate system.
The obarun community will not lose me, don't worry. I am not after a personal system, I am looking for a system that has the potential to send systemd and its supporters back to the jar of the evil ginis. The big corporate people have been winning for so long and in every battle I think it takes a little victory somewhere to turn the moral around. I see a system based on musl, with s6 and 66 being of weapon grade.
You would have to admit, with void as a base you can sleep easier. With arch you never know what will be thrown at you, when you wake up, and have things breaking faster than you rebuild them. Am I wrong? You can be Platini but they can keep moving the goal posts around.
@ Am I wrong?
nope
by the way, inside the dracut space of void, there is this thing called systemd-udev, is this part of eudev?
welcome to the next problem on Archlinux: the use of dracut.
Anyway, eudev should replace systemd-udev in other world eudev was created to avoid systemd-udev use
HHHhhmmmm.... :)
I think unintentionally, trying to get the damn thing to boot I discovered some area of the system I had no idea existed, but it made some sense. Of course things can make sense, like falling inside a lagoon full of water, knowing how to swim and climb rocks to get out is another story :)
fungalnet wroteby the way, inside the dracut space of void, there is this thing called systemd-udev, is this part of eudev?
dracut in voidlinux uses eudev (see the depends array in the template).
Yes I know it is eudev, but inside that dracut pre-booting area there is label systemd-udev :)
a year later
Hello:
This is my first post here. The reason I'm posting is because I've been using S6 on obarun (s66) and artix. It's a while since I moved to void musl (well, to be honest, I'm using a bedrock mix yet), and I was trying https://www.reddit.com/r/voidlinux/comments/cqck5d/change_runit_to_s6_is_possible/ and also this https://sysdfree.wordpress.com/2019/12/15/291/ (which is basically the same).

In this step:
./configure --bindir=/usr/bin --shebangdir=/usr/bin --with-system-service=/usr/share/66/service
./configure: unknown option --shebangdir=/usr/bin
creating config.mak...
  ... done.
So looking inside the configure file, it seems that option does not exist.
Tried with:
./configure --bindir=/usr/bin –HOSTNAME=66 –TZ=Europe/Madrid –KEYMAP='!us' --with-system-service=/usr/share/66/service
make install
Now I'm seeing that the /etc/66/boot.conf file does not exist (but there's a init.conf file), don't know if it's a typo.

I can create the : 66-tree -n boot
But when I try to enable:
66-enable -t boot boot
66-enable: fatal: unable to resolve source path of: boot
Looking here: https://wiki.obarun.org/doku.php?id=from-arch-install

I have tried:
66-enable -t boot boot@ system
I can see many enable /disable and finally:
boot@ system: info: successfully configured
66-enable: fatal: unable to parse service file: /usr/share/66/service/boot@ system: or its dependencies
But I understand that something is wrong.
When I also do a : 66-intree , I can see that the tree is not enabled.


I'm a bit lost. Can you help me? I know it's probably a dumb question and I understand this is void with obarun's init (but that's also the magic of the open source)

Sorry for my engrish. Thanks in advance
Welcome.
Those posts you refer to reddit and sysdfree are outdated now, because boot-66serv has really become boot@ -66serv and is a module service. See the obarun wiki on modules and boot module in specific.

I know of bedrock but haven't tried it, with void I am a bit more familiar.
The basic configuration different between obarun and void in terms of services is where they are placed, /usr/lib/66 in obarun /usr/share/66 in void. With boot, as I found out, if you just copy obarun's to /usr/share/66/service it fails because within it there is a use of the script module.sh which is directed to /usr/lib instead of /usr/share, otherwise it is identical with what void's teldra has created.

https://github.com/teldra/void-packages/tree/66-boot/srcpkgs/boot-66serv

You can build it into an xbps package or just copy the stuff from the git to the appropriate locations. I've used it for glibc and musl. It works great. Read the contents of the 66 script and try to understand what it does. This is teldra's solution so you don't have to remove anything runit related from void and it would be easy to switch back. Basically it moved the runit powerfunctions out of the way and makes room for the s6 functionality and you can revert if you didn't like s6/66. Basically he is trying to make it into a compatible pkg within void, so there would be no conflicts.

https://github.com/mobinmob/void-66-services

The 2nd link is by mobinmob
and has services that work on void without modification, they are a bit simplified compared to Obarun's to blend better with runit simplicity.

The configuration of the boot@ module is just the same as in the Obarun wiki, but if you have the old boot-66serv (non-module) make sure to remove it before using this. Also tty@ -66serv is required because on the new module tty12 becomes tty@ tty12 using that script, while the rest of the tty is defined within the module as tty-rc@ tty*** and in the module script you can define between 0 and 11 ttys.

Monbinmob is the void expert and I have to admit I have avoided void lately, after getting 66 to work, just the presence of elogind in the repository and its link to a whole load of crap averts me :) But I don't use consolekit either, so it doesn't change anything from me, just the feelings from void were hurt.

I do admit to using xbps on arch and pacman to void with a few things I can control their dependency conflicts, or little script packages, but there are strict religious people who scream "policy" to me about such things, so I'll be quiet.
Thanks a lot for the very nice answer. I'll have a look at both resources

I've been looking at xbps-src packages. There's no systemd references for dracut.

In fact:
dracut/template:	# We don't need the systemd stuff.
dracut/template:	rm -rf ${DESTDIR}/usr/lib/dracut/modules.d/*systemd*
dracut-network/template:	# We don't need the systemd stuff.
dracut-network/template:	rm -rf ${DESTDIR}/usr/lib/dracut/modules.d/*systemd*
dracut-uefi/template:	# We don't need the systemd stuff.
dracut-uefi/template:	rm -rf ${DESTDIR}/usr/lib/dracut/modules.d/*systemd*
But there's the elogind stuff there with systemd references. I'm a bit surprised since void has in his blood not to use systemd

On the other hand, a musl based linux, seems to me the correct way to go...
Void has in its blood a history. Void had systemd before debian did, correct me if I am wrong. Void has been eager in taking down content that connects it with its past. Its forum is gone ... now the wiki is discontinued and replaced by a workmanual. For all I know their perceived forum reddit../r/void might be gone, serving as a support forum. Nowhere in void's official documents does it say "we will not utilize systemd AGAIN!". Like we say here, don't put too many eggs in your basket. Ok, realistically I don't expect it to. But I didn't expect or could understand this "removal" of ck2 and converting all ck dependencies to elogind, or its continuous support for Gnome.

Ataraxia I think was musl based and non systemd, and it is now patching systemd to use in musl! Just 3 months ago the author was asking me why I didn't add it to the new list of linux without systemd, and I did, then took it out again! :)

I like kiss-linux k1ss.org declaration, front page, right in the middle, no systemd no elogind! Clear and loud commitment.
I need to admit that you are right. There's runit (s6 and s66), xbps-src, musl and many good things but well...
To each his own ... I suppose. Since they started dancing in that rhythm they will be chasing their tail everytime some gui/DE gadget utilizes YET another feature of systemd ... patching and redirecting .. and more. All this because it was meant to save them work from upstream stuff asking for logind and libsystemd.

The virus will keep crawling deeper and deeper.
5 months later
Is an old thread but I consider interesting to say that it seems that void supports now seatd. You don't need elogind anymore (that's the theory, of course).
I think this works complimentary to systemd/elogind I don't think it is a replacement for logind. I haven't read much about it, I wonder if it is a biproduct of a BSD effort to port wayland to their environments.

Powered by Obarun