OpenRC & eudev on Arch

patroclo7 · 2012-11-12 10:13:31

I would add a personal suggestion of mine: use this thread as a source of information about openrc as an alternative initsystem for archlinux without a DE, and not for boring rants against systemd or for supefluous comparisons between init systems. Otherwise the moderator will be forced to close it and we will loose a nice cognitive occasion to deepen our knowledge of openrc.

x33a · 2012-11-12 10:16:17

@ patroclo7,

that has already been discussed, see a few posts down in the first page.

patroclo7 · 2012-11-12 16:20:19

@x33a Thanks for the pointer, but I intended to raise a slightly different point (in particular about the cognitive occasion).

Anyway, for anyone interested, a cool thing in the setup resulting from the openrc packages in the AUR is that you can simply duplicate your bootloader entries jumping from openrc (with init=/sbin/init-openrc) to systemd (with init=/bin/systemd) with a reboot. Do not omit init= instead, because in that way you use plain sysvinit without any init system attached.

So, if you meet any issue, it is quite easy to check if the init system is to be blamed or not.

anonymous_user · 2012-11-13 03:56:29

BTW if one chooses to use OpenRC on Arch, would he/she still need ConsoleKit for automounting/shutdown/etc permisssions?

WonderWoofy · 2012-11-13 04:02:51

@anonymous_user, I think this too was also discussed at the beginning of the thread. There was mention that because of this, there would have to be a repo of all packages that rely on consolekit (as well as consolekit of course).

patroclo7 · 2012-11-13 09:17:12

You need consolekit (and stuff recompiled against it) if you needed it in the past. If you use (say) autofs for automounting (or pmount for user mounting) and sudo to get shutdown permissions, you do not need consolekit (I am running happily without it and I had never used in the past).

Earnestly · 2012-11-13 11:50:10

There is no wiki package for OpenRC yet, why not start one?
This way you can provide advise, instructions and tips without digging through forum posts.

patroclo7 · 2012-11-13 13:26:51

@ Kaustic Nice idea. In the case you start this effort, I suggest to limit the instructions to what is specific to the aur packages and to link to the gentoo documentation for anything else. Openrc is actively developed by gentoo developers and, if we provide independent documentation, it risks becoming outdated quite soon. Moreover we should say that if you use a DE or rely on consolekit/systemd for authentication and other stuff, then you are basically on your own: the only purpose of those packages is to provide openrc as vanilla as possible, in a way suitable for minimal desktops with a WM or for a server.

I will be happy to contribute in the next weeks (not much time ATM).

x33a · 2012-11-14 07:14:55

I have created the page on the wiki.

https://wiki.archlinux.org/index.php/OpenRC

It is not yet complete, please feel free to add to it.

Last edited by x33a (2012-11-15 15:56:12)

artoo · 2012-11-14 16:59:14

apg wrote:

net-tools has nothing to do with networkmanager... My system is networkmanager free and the network comes up just fine.

Right, I had no problem setting up wired connection, but wireless.
However, I have reinstalled from git all 3 packages, and now a auto wireless script appeared which solved it.
Also, gentoo openrc sources just removed what I was missing, I read in the portage message after upgrading openrc on gentoo.

apg wrote:

As for udev, openrc is intended to work just fine without udev (although I have not personally tested this) and I have linked on the package page to the Gentoo wiki that shows how to enable udev.

It does work fine without udev.
The suggestion was to provide in arch-openrc-services udev and udev-mount in runlevel.
so just a symlink in sysinit runlevel.

apg wrote:

I'm not sure what you mean by paths in my pkgbuild... there are none related to dbus or ifconfig. If you're referring to the scripts, everything looks fine to me, but if you see problems feel free to post them or, if they're in one of the service files in the openrc-arch-services package, file an issue and a fix for it on the github page: https://github.com/andrewgregory/openrc-arch-services

Paths in scripts of /libexec/rc/sh/

To my mind, the init.sh and init-early.sh need to be patched from gitsource to match the altered path in /etc, so from /etc/rc.conf to /etc/openrc/rc.conf.
Otherwise functions and service depends may not work properly.
I can submit patches if you want.

If you plan to use dbus, eg for desktop, the dbus init script in /etc/openrc/init.d/dbus needs to be patched to /var/run/dbus/pid. Provided by the arch-openrc-services.

I would also suggest adding a vbox service. The gentoo one work if the binary name is changed to Arch's one.

patroclo7 wrote:

You need consolekit (and stuff recompiled against it) if you needed it in the past. If you use (say) autofs for automounting (or pmount for user mounting) and sudo to get shutdown permissions, you do not need consolekit (I am running happily without it and I had never used in the past).

I have been experimenting with consolekit. Lets leave behind any discussion on CK here.
As far as I have checked on my testbox, CK is only needed if you plan to use apper and networkmanager at the moment, plus the kdeworkspace-consolekit package, while there is currently no apper-consolekit in AUR.
Besides that, if a consolekit service is added and running, the NM works.

Last edited by artoo (2012-11-14 17:26:29)

apg · 2012-11-14 17:58:50

artoo wrote:

It does work fine without udev.
The suggestion was to provide in arch-openrc-services udev and udev-mount in runlevel.
so just a symlink in sysinit runlevel.

I understood what you meant. I just don't want to enable services by default that are neither absolutely necessary nor enabled by default upstream.

artoo wrote:

Paths in scripts of /libexec/rc/sh/
To my mind, the init.sh and init-early.sh need to be patched from gitsource to match the altered path in /etc, so from /etc/rc.conf to /etc/openrc/rc.conf.
Otherwise functions and service depends may not work properly.
I can submit patches if you want.

You are correct, those paths need to be fixed upstream. I'll submit a patch.

artoo wrote:

If you plan to use dbus, eg for desktop, the dbus init script in /etc/openrc/init.d/dbus needs to be patched to /var/run/dbus/pid. Provided by the arch-openrc-services.

Fixed.

artoo wrote:

I would also suggest adding a vbox service. The gentoo one work if the binary name is changed to Arch's one.

If you write/copy a service file, verify that it works, and send it to me (preferably on Github) I'll include it.

artoo · 2012-11-14 18:32:47

apg wrote:

If you write/copy a service file, verify that it works, and send it to me (preferably on Github) I'll include it.

Currently, I do service for consolekit, vbox, displaymanager.
I will submit to github.

Last edited by artoo (2012-11-14 20:14:00)

artoo · 2012-11-14 20:14:50

Re: consolekit
Apper appears to be running properly if consolekit service is started under OpenRC.
Just tested it, and privileges do the job.

apq, just in case, I have created a git account(udeved) and I am about to commit to a fork? Right?

On the possible todo list:

lm_sensors
wpa_supplicant
gpm
cpupower
laptop-tools
lvm
lvm-monitoring
mdadm
git-daemon
svnserve

Last edited by artoo (2012-11-14 23:07:26)

coques · 2012-11-14 20:59:44

Uau, this thread made me really happy. I was just giving up with systemd, but now it seems I'll give Arch one more chance before switching somewhere else. Good job guys!

apg · 2012-11-14 22:36:38

artoo wrote:

apq, just in case, I have created a git account(udeved) and I am about to commit to a fork? Right?

Yes. You'll commit to your fork and make a pull request.

artoo · 2012-11-14 23:53:40

apg wrote:

artoo wrote:
apq, just in case, I have created a git account(udeved) and I am about to commit to a fork? Right?
Yes. You'll commit to your fork and make a pull request.

I just had a thought while doing lm_sensors.

Would it be feasible to use the already existing /etc/conf.d directory, replacing all conf files, put init.d also in /etc, and let the pkgbuild replace /etc/rc.conf?
In other words, to get rid of the /etc/openrc directory, and make the pkgbuild conflict with initscripts and iirc sysvinit?
I'd avoid altering or patching gentoo sources.

I admit, it is currently useful to have initscripts and openrc installed and bootable.

To ease the transition, initscripts support will remain in the official repositories for the time being, unless otherwise stated. As of January 2013, we will start removing initscripts support (e.g., rc scripts) from individual packages without further notice.

I'd also help systemd migration, and OpenRC, in the hope official Arch packages remove the mentioned directory /etc/conf.d and /etc/rc.conf is already remoced by removing sysvinit/initscripts.

I also thought about eventually splitting the opemrc-arch-service package into at least two packages, say base and desktop services depending on base. Possibly a filesystem package with lvm, crypt & mdadm, dmraid? Kind of meta package allowing user selection?

Last edited by artoo (2012-11-15 01:11:37)

x33a · 2012-11-15 04:10:54

artoo wrote:

Would it be feasible to use the already existing /etc/conf.d directory, replacing all conf files, put init.d also in /etc, and let the pkgbuild replace /etc/rc.conf?
In other words, to get rid of the /etc/openrc directory, and make the pkgbuild conflict with initscripts and iirc sysvinit?
I'd avoid altering or patching gentoo sources.
I admit, it is currently useful to have initscripts and openrc installed and bootable.

I feel till initscripts is totally removed from the arch repos, and the openrc packages are ironed out a bit more, for a wider audience, we should stick with /etc/openrc directory. That is, maybe a month or two.

patroclo7 · 2012-11-15 09:38:20

artoo wrote:

I just had a thought while doing lm_sensors.
Would it be feasible to use the already existing /etc/conf.d directory, replacing all conf files, put init.d also in /etc, and let the pkgbuild replace /etc/rc.conf?
In other words, to get rid of the /etc/openrc directory, and make the pkgbuild conflict with initscripts and iirc sysvinit?
I'd avoid altering or patching gentoo sources.

My guess is that openrc upstream should welcome your patches: there is no good reason why the path should be hardcoded in their sources. After all they aim to portability.
For what concerns archlinux, it seems to me that the present setup with everything into /etc/openrc is a very clean way to provide as self-contained an alternative init system for a distribution. Moreover, also when the official support for initscripts is dropped there will be people still using initscripts and trying different alternatives: avoiding conflicts with every alternative at disposal is an advantage.

Last edited by patroclo7 (2012-11-15 09:41:40)

artoo · 2012-11-15 10:06:02

patroclo7 wrote:

artoo wrote:
I just had a thought while doing lm_sensors.
Would it be feasible to use the already existing /etc/conf.d directory, replacing all conf files, put init.d also in /etc, and let the pkgbuild replace /etc/rc.conf?
In other words, to get rid of the /etc/openrc directory, and make the pkgbuild conflict with initscripts and iirc sysvinit?
I'd avoid altering or patching gentoo sources.
My guess is that openrc upstream should welcome your patches: there is no good reason why the path should be hardcoded in their sources. After all they aim to portability.
For what concerns archlinux, it seems to me that the present setup with everything into /etc/openrc is a very clean way to provide as self-contained an alternative init system for a distribution. Moreover, also when the official support for initscripts is dropped there will be people still using initscripts and trying different alternatives: avoiding conflicts with every alternative at disposal is an advantage.

Valid points.
I was just thinking in terms of maintenance of services.
With vanilla path, the porting of openrc should work even better with less fiddling of openrc scripts.

Once initscripts were completely removed from repos, the /etc/conf.d path becomes obsolete, and apparently the containing files do not differ much from the /etc/openrc/conf.d/*
Some shell scripts of the openrc core package form gentoo upstream were patched to match the altered path.
It is unfortunately not done by changing install path in the pkgbuilds.
I think an additional directory causes more headache than good.

Making it a dependency choice of either initscripts or openrc as init system seems an acceptable shortcoming to me, since initscripts won't provide arch services any more for eg say cpupower, These packages will increasingly go systemd units.

I set up some testing repo and I think I will do in parallel some tests with unaltered /etc path.

https://github.com/udeved/openrc-pkgbuilds

Last edited by artoo (2012-11-15 16:51:15)

apg · 2012-11-15 17:58:26

artoo wrote:

Valid points.
I was just thinking in terms of maintenance of services.
With vanilla path, the porting of openrc should work even better with less fiddling of openrc scripts.

OpenRC files have to stay in /etc/openrc. The conflicting files in /etc/conf.d do not belong to initscripts; they belong to the individual packages for those services.

Edit: In order to merge the two you would have to check every service file copied from Gentoo for compatibility with Arch's conf.d files, which would be a higher burden than fixing the odd service file that improperly references a file in conf.d

artoo wrote:

Some shell scripts of the openrc core package form gentoo upstream were patched to match the altered path.
It is unfortunately not done by changing install path in the pkgbuilds.
I think an additional directory causes more headache than good.

I'm not sure what you mean here. If you're saying that my openrc and openrc-git packages patch anything in openrc, that is incorrect. The only customizations they provide are the build flags. If you're talking about modifying service files that reference their own configuration files, those service files are probably poorly written in the first place and need to changed.

Last edited by apg (2012-11-15 18:08:23)

artoo · 2012-11-15 19:04:57

apg wrote:

artoo wrote:
Some shell scripts of the openrc core package form gentoo upstream were patched to match the altered path.
It is unfortunately not done by changing install path in the pkgbuilds.
I think an additional directory causes more headache than good.
I'm not sure what you mean here. If you're saying that my openrc and openrc-git packages patch anything in openrc, that is incorrect. The only customizations they provide are the build flags. If you're talking about modifying service files that reference their own configuration files, those service files are probably poorly written in the first place and need to changed.

No, I mean init.sh and init-early.sh in /libexec/rc/sh.
I already posted that services may not run properly, since these two scripts reference /etc/rc.conf.
I see no way besides patching these two scripts, provided by openrc-git to match the /etc/openrc install path.

Just have a look at these two scripts.

I am aware the files in /etc/conf.d/* are from individual packages, similarly are the openrc ones, and the equivalent are systemd units.

The thought was to be even able to make use of some systemd service compat package, theoretically.

Atm, I am playing with openrc-git build depending on plain sysvinit. The advantage, no kernel init param needed, just for systemd.

Last edited by artoo (2012-11-15 19:25:41)

artoo · 2012-11-16 11:25:04

Small update on openrc and sysvinit.

My test pkgbuild of openrc-git with sysvinit dependency, /etc path and initscripts conflict seem to work well so far.

If anyone wants to test the package, the build can be found here:

https://github.com/udeved/openrc-pkgbui … svinit-git

I have split the services into 3 builds.
-base services
-net-services
-desktop services

Please post service suggestions currently missing, see git source for available services.

https://github.com/udeved/openrc-pkgbuilds

One note, you need to comment out possible dependencies to the base services as long as the build are not available in AUR.

Keep in mind, these builds conflict with initscripts.

A small question:

Does the backup statement in the pkgbuild know wildcards?

eg for base services:

backup=('etc/conf.d/*')

Last edited by artoo (2012-11-16 22:35:23)

artoo · 2012-11-16 23:27:50

Does anybody know how to set up a local abs repo?

repo-add doesn't seem to do it with pkgbuilds?

Do I need a local webserver for this?

Edit:

Nevermind...

http://ushi.wurstcase.net/local-repo/

Last edited by artoo (2012-11-17 00:25:03)

artoo · 2012-11-17 02:12:34

The openrc-sysvinit-git packages and dependencies are available in AUR for testing.

https://aur.archlinux.org/packages/openrc-sysvinit-git/

https://aur.archlinux.org/packages/open … vices-git/

Packages should make the system boot out-of-the-box without kernel init parameter.

If you want to use systemd, add to kernel

init=/usr/lib/systemd/systemd

Aha, I just noticed, meta packages won't work in AUR.
The AUR can't deal with virtual interfaces, but the meta pkg works fine in local repo.

I made the switch to openrc from initscripts on my real box, and it works out-of-the-box so far.

A note for root-on-LVM users, make sure you add udev and udev-mount to sysinit runlevel to activate lvm (root or /usr) volume.

Last edited by artoo (2012-11-17 14:07:41)

patroclo7 · 2012-11-18 19:34:14

For the future, I would suggest to avoid duplication of aur packages for paths and other minimal packages differences. A very small community of openrc users in arch can not afford to maintain dozens of different packages in the long term. Apg original packages are IMO very clean and anybody is free to modify them locally as desired without committing his variation to the AUR.

Arch Linux

#26 2012-11-12 10:13:31

Re: OpenRC & eudev on Arch

#27 2012-11-12 10:16:17

Re: OpenRC & eudev on Arch

#28 2012-11-12 16:20:19

Re: OpenRC & eudev on Arch

#29 2012-11-13 03:56:29

Re: OpenRC & eudev on Arch

#30 2012-11-13 04:02:51

Re: OpenRC & eudev on Arch

#31 2012-11-13 09:17:12

Re: OpenRC & eudev on Arch

#32 2012-11-13 11:50:10

Re: OpenRC & eudev on Arch

#33 2012-11-13 13:26:51

Re: OpenRC & eudev on Arch

#34 2012-11-14 07:14:55

Re: OpenRC & eudev on Arch

#35 2012-11-14 16:59:14

Re: OpenRC & eudev on Arch

#36 2012-11-14 17:58:50

Re: OpenRC & eudev on Arch

#37 2012-11-14 18:32:47

Re: OpenRC & eudev on Arch

#38 2012-11-14 20:14:50

Re: OpenRC & eudev on Arch

#39 2012-11-14 20:59:44

Re: OpenRC & eudev on Arch

#40 2012-11-14 22:36:38

Re: OpenRC & eudev on Arch

#41 2012-11-14 23:53:40

Re: OpenRC & eudev on Arch

#42 2012-11-15 04:10:54

Re: OpenRC & eudev on Arch

#43 2012-11-15 09:38:20

Re: OpenRC & eudev on Arch

#44 2012-11-15 10:06:02

Re: OpenRC & eudev on Arch

#45 2012-11-15 17:58:26

Re: OpenRC & eudev on Arch

#46 2012-11-15 19:04:57

Re: OpenRC & eudev on Arch

#47 2012-11-16 11:25:04

Re: OpenRC & eudev on Arch

#48 2012-11-16 23:27:50

Re: OpenRC & eudev on Arch

#49 2012-11-17 02:12:34

Re: OpenRC & eudev on Arch

#50 2012-11-18 19:34:14

Re: OpenRC & eudev on Arch

Board footer