A while back I was dabbling in using Runit within a Slackware system as a replacement for sysvinit, and can actually say, I have the first set of bootscripts created and somewhat tested.

A lot of effort was done to port the Runit-for-LFS bootscripts into Slackware, but I doubt this effort is completed, but it is near ready to be released.

For now, the traditional startup of Slackware will take place, though a few customizations had to be added in and around /etc/rc.d/rc.M to work more fluidly with the system. This means that for temporary measures using the rc.sysvinit for standard system v scripts is not included. To be honest, I left it out due to the fact it uses runlevel detection, of which Runit uses differently than sysvinit. Also, /etc/rc.d/rc.4 which housed the display manager login system was migrated into a script renamed rc.X. If I can find a way to get rc.sysvinit able to work without a problem, I'll re-add it.

The traditional startup files customized for the Runit boot, have been migrated out of /etc/rc.d into a special compatibility folder dubbed /etc/runit/rc.d to focus the bootscripts solely into Runit.

The remaining system boot scripts will still function, though one bootscript has been excised from this process due to the fact that finding a way to accurately call it in Runit, proved somewhat problematic as how it mounted a few file systems became a headache. This was rc.udev. Rather than have a script to handle udev, udev is now tucked into the boot sequence as a set of calls, and /dev is mounted with the other kernel virtual filesystems. The traditional script is there and part of the udev package, but I do not advise using it, but instead use the actual commands in a tty terminal to load, reload, or exit udev. Most of this problem centers on the /dev mount.

So what does Runit actually replace? Mostly just the sysvinit tools and a few files like inittab, but other than that, everything is roughly 95-99% the same. The Runit stage 2 script /etc/runit/2 in essence functions similar to inittab loading the getties, executing a maintenance script adapted and derived from the Runit-For-LFS to handle triggering updates to the system cache for gdk, gtk, pango, fonts, etc. As an Runit service, these process run quietly in the background, and then the service script goes into a holding state using a utility imported from Runit-For-LFS, the pause applet.

Pause functions to hold the execution state of a script in the state of being executed until the session is closed or the script is told to stop.

The halt utility duplicates the function of the sysvinit halt utility which functions to poweroff, halt, and reboot the system. The shutdown utility is replaced by a special script to duplicate the function of sysvinit shutdown.

We even have a small script to duplicate the function of sysvinit's runlevel which checks the runlevel of the system. Changes to the runlevel, however, are made with runsvdir.

Does this mean you have to use the Runit service scripts? No. In essence I've taken great care to preserve the init sequence and scripts of Slackware as much as possible. If you wish to use the Runit service scripts, you will have to chmod the appropriate service script to not be read from rc.M, and install the appropriate service script set (most of the runit-for-lfs scripts should work). I actually advise against doing this as the standard rc.M service start up is 100% foolproof.

I'm still working on getting the SlackBuild ready to use and install all the appropriate scripts. This SlackBuild will be fundamentally different from the Runit SlackBuild up on SlackBuilds.org currently, and will be aptly named, runit-boot to focus on the fact this implementation is different and aimed at booting the system.

I wanted to find an init system Slackware could use without it being problematic, a headache, or incompatible with the traditions Patrick has used for so many years. Runit comes about as close as we could or can get to a proper successor to sysvinit that allows tradition to stay alive while allowing optional abilities to promote future endeavors. It's probably not the best solution, although the best solution is still sysvinit using Slackware BSD-like stylization, but it is an init system only, and allows for a great deal of customization, tradition, and compatibility I've yet to see in other init systems.

This is change that says, "you have options" rather than "there is no option", and I, personally, see that as truly positive change.

This project is, as it's parent project is, licensed under the MIT license, but I am providing a special provision that will allow the Official Slackware Team to clone and fork the project if they see fit to do so, and re-license the clone and fork as needed.

The sources for the script set are here, and should be added to the SlackBuild soon when I get time this week.

https://code.google.com/p/runit-for-...Slackware_port

The sources in the SVN can be installed manually.

The initial SlackBuild without the bootscripts from the SVN is here:

https://code.google.com/p/runit-for-...it-boot.tar.gz

This package may conflict with:

sysvinit
sysvinit-scripts

Nice work, ReaperX7! Good to know folks like you are doing things like this to spit in the eye of monolithic monsters such as systemd. Thanks for your efforts.

One fundamental change is one I had to make in /etc/fstab thanks to my usage of eudev.

Slackware normally mounts tmpfs to /dev/shm, but this has changed. Due to the way Runit works in my implementation, and how eudev expects it unfortunately, /dev/shm is a link to /run/shm so when you use this, change the tmpfs mountpoint in /etc/fstab to /run.

Also, make sure to check this file:

/lib/udev/rules.d/69-libmtp.rules and make sure the first line is actually commented out, or else it won't load the input modules correctly.

I actually am using the new init system right now by the way... screenshot included.

One other issue right now is procps package.

My implementation is based on using pkill from procps-ng, not the original procps package, so you may want to consider updating to that package. Yes, I know it's a fork of procps, but the script was developed using procps-ng... if I can find a work around I'll use it, otherwise, just remove package procps and psmisc and manually install them back in (not entirely recommended, but until I can edit the procps.SlackBuild to do so otherwise, just install manually and hold back any complaints.) You may want to look into eudev as well.

Be forewarned, this does NOT solve the issue with dismount and remount of the /(root) filesystem at shutdown. I have reason to believe there is another issue at hand.

I will warn you all ahead of time. This project is roughly pre-Alpha to Alpha stage and it does have some issues I'm still sorting out heavily. Most of these deal with Slackware's package differences between the port pulled in from LFS, and the fact some of the packages used by Slackware are older or versions from different forks. Don't cry if you break your system.

Good luck! Just curious, why all the extra work? IOW, would the regular runit setup be appalling to Slackware users? I genuinely don't know the answer to this question, but I'll take the runit source code home and queue it behind installing GRUB and building a kernel using Clang.

Slackware does a lot differently from standard sysvinit, fhs, and lsb systems which complicates things. It's not a bad thing, but it slowed down my work a bit.

Ah. Understood. Thanks!

GRUB is installed, and I'll see if I can answer your btrfs question from another thread. The Clang-built kernel failed to boot on x86. While my mailing list question is being answered, I'll build a fresh Clang and get to looking at runit, catch up, and take in your work once I'm thoroughly stuck.