/usr/lib/modules-load.d systemd affecting openrc

[josephg]

i have virtualbox installed, used rarely. default virtualbox install has all vbox modules autoload at boot. on one of my usual iterations of cutting & pruning my gentoo, i decided that i will load virtualbox modules manually only when i want to run virtualbox.

digging a bit deeper, i find gentoo is automagically loading modules from systemd location /usr/lib/modules-load.d/, even though systemd is masked.

Provided by: systemd_232-7_amd64 bug

have i misconfigured something.. why is my gentoo running systemd bits n bobs? i now have to use systemd workarounds to stop this.

resolved: either of two workarounds (till openrc decides to fix/kill itself)
(a) systemd method
(b) gentoo/openrc method

update: latest version of openrc loads modules from systemd locations. now the systemd method (a) works, openrc method (b) does not work. i was using (b), and am now using (a).

moral of the story: when openrc breaks while trying to emulate systemd, look for systemd solutions as workarounds.

[NeddySeagoon]

josephg,

Things that provide systemd unit files will still install them but they should not be used.

I have systemd in package.mask and USE=-systemd
I also have

Code: Select all

INSTALL_MASK="${INSTALL_MASK} /usr/lib/systemd *.la"

in make.conf so that anything that goes in /usr/lib/systemd is thrown away.

The *.la is irrelevant now. Gentoo used to install Linker Archve (*.la) files which play havoc with cross compiling.
That's no longer the case, so I can drop that.

I'm told its a horrible hack and that I'll regret it if I ever want to move to systemd.
Its more likely I'll move to BSD than systemd, so right now, it works for me.

[Tony0945]

Its more likely I'll move to BSD than systemd, so right now, it works for me.

Amen!

[josephg]

Its more likely I'll move to BSD than systemd, so right now, it works for me.

Amen!

me too!
i've been using openbsd off and on for the past few years, less so since i moved to gentoo. i'm looking at freebsd, which allows you to stay on an older release and continue getting security updates, without upgrading everything all the time or be damned!

Things that provide systemd unit files will still install them but they should not be used.

well, i want to agree but my gentoo without systemd autoloads those four modules, and i have to use systemd workarounds to stop them.

to stop /usr/lib/modules-load.d/virtualbox.conf from autoloading at boot, i created that directory in /etc, and did "ln -s /dev/null /etc/modules-load.d/virtualbox.conf" duh!

i don't even know how this automagic happens. there's a service modules-load, but it's not enabled nor listed on any openrc runlevels.

[Josef.95]

Oh no, the systemd haters...

Hm no, systemd and OpenRC loads module automatically from /etc/modules-load.d/*
or OpenRC from /etc/conf.d/modules to, if you have it configured.
Without configuration it would not load modules automatically.

Remove the modules from /etc/modules-load.d/* and /etc/conf.d/modules should help.

[josephg]

Oh no, the systemd haters...

shall we call you openrc haters? i don't hate you or label you just because you want systemd! just don't impose it on us..

yes i can remove those conf files from /usr/lib/modules-load.d/, but emerge will create them again.

[Josef.95]

[...]

yes i can remove those conf files from /usr/lib/modules-load.d/, but emerge will create them again.

No, I meant /etc/ not /usr/

From /usr/lib/modules-load.d/virtualbox.conf it would not load automatically (on Gentoo).

[josephg]

From /usr/lib/modules-load.d/virtualbox.conf it would not load automatically (on Gentoo).

/usr/lib/modules-load.d/virtualbox.conf does load automatically on this gentoo. i manually created /etc/modules-load.d/* to stop auto load.

i don't have any vbox modules listed anywhere in /etc..

[NeddySeagoon]

Josef.95,

I'm not a systemd hater. I'm a retired avionics systems engineer and I recognise poor/lacking design when I see it.
Such examples of shoddy engineering are to be avoided, wherever they occur. Systemd just happens to be a very visible example.

[Josef.95]

From /usr/lib/modules-load.d/virtualbox.conf it would not load automatically (on Gentoo).

Supplement:
This is not right :-/
sorry, ignore this please.

Yes, this new automatically load behavior is added from Bug 490988
for systemd and OpenRC.

[josephg]

Yes, this new automatically load behavior is added from Bug 490988
for systemd and OpenRC.

thanks for digging this so this is what started it! i see that bugfix is specifically for systemd, but i don't use systemd. this shouldn't impact systems without systemd.

+ 17 Nov 2013; Pacho Ramos <pacho@gentoo.org> +files/virtualbox.conf,
+ virtualbox-modules-4.3.2.ebuild:
+ Install a modules-load.d file to load modules automatically on systemd
+ (#490988 by Rafal Rzepecki)
+

openrc method of auto loading modules is different: http://wiki.gentoo.org/wiki/Kernel_Modu ... ic_loading

has openrc been broken by systemd? that systemd method works on my gentoo without systemd. and i have to use a systemd fix to stop it, which also works.

[i4dnf]

openrc has unfortunately been "broken" by its current "developer" to behave like systemd in this and a couple of other cases.
https://github.com/OpenRC/openrc/commit ... 9f72b6f284
https://github.com/OpenRC/openrc/commit ... es-load.in

On my system I have commented out the line triggering this in /etc/init.d/modules

Code: Select all

depend()
{
        use isapnp
        #want modules-load
        keyword -docker -lxc -openvz -prefix -systemd-nspawn -vserver
}

[NeddySeagoon]

i4dnf,

A few users have stayed with openrc-0.17 or older too. I'm an openrc-0.17.

[Josef.95]

josephg,
a empty file in /etc/modules-load.d/ should work.

Example for virtualbox modules:

Code: Select all

mkdir /etc/modules-load.d
touch /etc/modules-load.d/virtualbox.conf

(reboot)
This override the /usr/lib/modules-load.d/virtualbox.conf file with the same name.

This works fine on my OpenRC System :)
/edit
and systemd systems to.

[josephg]

openrc has unfortunately been "broken" by its current "developer" to behave like systemd

A few users have stayed with openrc-0.17 or older too. I'm an openrc-0.17.

what's the purpose of staying on the train, if it's not going where you want to go? if i want systemd behaviour, i'd just use systemd rather than try make openrc behave like systemd.

[i4dnf]

Maybe there should be more noise on this bug:
https://bugs.gentoo.org/show_bug.cgi?id=609312

[NeddySeagoon]

josephg,

I suppose I got to where I wanted to be, so I got off the train.

[josephg]

so I got off the train.

please don't when good people leave.. not good for the world.
you're one of the best things that happened to me in gentoo!

[BT]

This "feature" can also cause kernel modules to be loaded twice: https://github.com/OpenRC/openrc/issues/98.

[krinn]

What is the point of loading modules in openrc from systemd's locations?

- first openrc is not systemd
- second, openrc handling of module is superior to systemd, both can just load module if you ask them to load a module (!) but openrc have conditional loading of module (modules_3.4="this" will load "this" only with a kernel 3.4)
- third, if i want to always load a module, i have no use of a module, that autoload module config file in an ebuild is a stupidity (and both for openrc and systemd). The main purpose of a module is to not load it, but load it when you want and need it.

You can also see in https://gitweb.gentoo.org/repo/gentoo.g ... .40.ebuild
Because systemd users are too braindead to handle this?

Code: Select all

 elog "If you are using systemd, please add \"vboxdrv\", \"vboxnetflt\","
	elog "\"vboxnetadp\" and \"vboxpci\" to:"
	elog "  /usr/lib/modules-load.d/virtualbox.conf"

For me, i don't care that much about /usr/lib/modules-load.d support in openrc as long as /etc/conf.d/modules remains (as long as williamh have no plans to remove it)
The real problem is virtualbox ebuild and any ebuild that per default install files to autoload the module.
With that mentality:
- ebuild will have <rc-update add "any initscript"> just because you have an init script in the ebuild
- any ebuild for an X application will just add it to autostart with X (you will really love autostart of libreoffice!)

[NeddySeagoon]

josephg,

Not the Gentoo train, the OpenRC train. I did Old Fashioned Gentoo in response to udev being assimilated by systemd and the announcement that udev without systemd would be unsupported.
That hasn't happened yet. I think the existence of eudev and its popularity has delayed that but its unlikely to have stopped it altogether.

My main desktop runs Old Fashioned Gentoo with OpenRC-0.17.
All my x86/amd64 installs use OpenRC-0.17 and my Aarch64 install follows the tree. There is enough to fiddle with on 64 bit Raspberry Pi anyway.

[josephg]

Not the Gentoo train, the OpenRC train.

*whew*

but i thought openrc was gentoo

My main desktop runs Old Fashioned Gentoo with OpenRC-0.17.
All my x86/amd64 installs use OpenRC-0.17 and my Aarch64 install follows the tree.

may i ask why 0.17 specifically? i'm a bit late to this party.

and if not openrc, what else? i've looked at runit, even before gentoo. i like voidlinux.. a bit like arch, but better and more efficient imho. i tried runit on gentoo for a while but eventually gave up. some others talk up s6.. haven't really looked at it.

[mv]

The whole issue is just a simple a bug in the ebuild:
The pkg_postinst() message is plainly false, because users of current openrc are not suppossed to add anything to /etc/conf.d/modules for this ebuild.
I suggest to file a bug for this ebuild that this message be removed (or at least reformulated in a sense like: "If you use <sys-apps/openrc-0.21.7 ..." [The version number is just a guess - it would need to be looked up in which version the modules.d support was added]).

@krinn: You have to see it from the viewpoint of developers who write a general package, not for a particular distribution or init system. Just like in dozens of other cases like /etc/X11/xorg.conf.d, /etc/X11/ld.sd.conf.d, /etc/cron.d, /etc/xinet.d, /etc/pam.d/, ... they can just drop the corresponding file in the matching location instead of requiring the user to manually manipulate dozens config files. As an upstream developer, I can say that I am very happy that these standard locations have meanwhile been extended to modules. This is a sane standard and has nothing to do with systemd. For this reason, I also strongly doubt that /etc/conf.d/modules will ever go away from openrc: This is the way to install user modules in openrc (in constrast to modules.d which is as mentioned above is meant for upstream packages to drop in the modules required to function properly.)

@NeddySeagoon:

I also have

Code: Select all

INSTALL_MASK="${INSTALL_MASK} /usr/lib/systemd *.la"

in make.conf so that anything that goes in /usr/lib/systemd is thrown away.

I'm told its a horrible hack

I agree with the opinion that it is a horrible hack. Unless you need every byte of disk space you have to admit that the reason for this hack is an expression of a political protest and not a technical matter: Nothing else but systemd will ever access the files in .../systemd/... (that's why this directory is called this way, isn't it?).
Of course, you are free to choose. Anyway, if you decide for it, I would also add /etc/systemd and /lib/systemd to this list (gentoo is about moving to the standard location /lib/systemd instead of the special gentoo-only variant /usr/lib/systemd).

I strongly suggest to remove the *.la from INSTALL_MASK: There are some packages which really do require the *.la files. Previously, I had removed the unneeded files on a per-package basis in /etc/portage/env. Meanwhile, I call this function from my /etc/portage/bashrc (the latter happens automatically if you install portage-bashrc-mv, e.g. from the mv overlay).

[NeddySeagoon]

@josephg,

I was using openrc-0.17 at the time the addition of the nofail option was being discussed on the -dev ML.
The default was to be that if a local filesystem failed no mount, the boot would fail.
This default made a lot of people who missed the news item, OpenRC-0.18 localmount and netmount changes very unhapy when their remote servers failed to reboot.
Sometime later, the default "fail" option, introduced by OpenRC-0.18 was reverted to nofail, which was original behavior before the option existed.

I was unhappy about the design decision to break backwards compatibility, so stayed with openrc-0.17. Once the change was reverted, I could have updated to a more recent version.
However, there have been other questionable systems design decisions since that time, which means I would need to pick my version carefully.
I might do that when I'm forced to update for some reason.

@mv,

Removing *.la files was a response many years ago to the cross build system using them for linking. Since that time, Gentoo started to remove *.la fles that are not required anyway.
They contain absolute paths to the build hosts native libraries, which is a very bad thing when the intent is to link against an arm lib.
It was only ever intended to be a temporary fix. Heh, there is nothing as permanent as a temporary solution :)

I'm not sure I see the merger of systemd and openrc file locations as benignly as you. I agree with the upstream benefits. A single location for all these things.
Given the systemd appetite for assimilating things, the cynic in me sees this as the first step to systemd assimilating then destroying openrc.
Embrace ... expand ... extinguish ... . Where have I heard that before.
That's another reason for staying with an openRC version prior to this merger. There is no technical basis for this decision ... yet.

I'm less paranoid about systemd being snuck in behind my back than I was, so I am more likely to remove the /usr/lib/systemd from INSTALL_MASK= that to clean up the other small files its left on my system.



I like your script for only keeping required *.la files. Thank you.

[josephg]

i thought the USE=systemd was for this very reason.. ie to add/remove any systemd stuff (files/locations/behaviour). why aren't gentoo devs using this for all affected packages?