Arch Linux

Not sure why this is set as low severity, but it is breaking functionality for me. Virtualbox has completely started to fail for me. Not only that, but since systemd-modules-load.service fails due to inconsistent configuration, other modules end up affected as well.

Either put a notice (Wiki or main page) that VirtualBox is permanently changed and should be configured in a certain way, or please remove the breaking changes. Otherwise I am stuck with editing this file after every update.

This should be in a service file, so that loading the modules or not is left to the user, while not being too cumbersome. This is how it is done for the guest modules I believe, and Virtualbox has the /usr/bin/vboxreload executable to load the necessary modules.

Doug, I'm conforming to others ootm packages which use systemd-load-modules to autoload kernel modules.

With the systemd logic, you can override module loading by putting an empty file in /etc/modules-load.d, so there is clean way to disable that.

That said, you need these modules to use vbox. I don't see the point to request users to go root to load modules in order to start vbox when they need it.

There is no need to go root and load modules to start vbox. I still use the old fashioned way by creating my own configuration file under /etc/modules-load.d with the modules I need to run vbox. That is also the way described at https://wiki.archlinux.org/index.php/VirtualBox in section "Load the VirtualBox kernel modules":

| To load the VirtualBox module at boot time, refer to Kernel modules#Automatic module handling and create a *.conf file (e.g. virtualbox.conf) in /etc/modules-load.d/ with the line:
|
| /etc/modules-load.d/virtualbox.conf
| vboxdrv

Thats all we did so far, and it worked well. I can't see any benefit to add a (still malformed) configuration file during installation at /usr/lib/modules-load.d/.

$ pacman -Fl|grep 'modules-load.d/.*.conf'
zfs-dkms usr/src/zfs-0.6.5.4/etc/modules-load.d/zfs.conf.in
zfs-utils usr/lib/modules-load.d/zfs.conf
nfs-utils usr/lib/modules-load.d/nfs-utils.conf
capi4hylafax usr/lib/modules-load.d/capi4hylafax.conf
ossp usr/lib/modules-load.d/osspd.conf
x2goserver usr/lib/modules-load.d/x2goserver.conf
acpi_call usr/lib/modules-load.d/acpi_call.conf
acpi_call-lts usr/lib/modules-load.d/acpi_call-lts.conf
cdemu-daemon usr/lib/modules-load.d/cdemu.conf
cdrtools usr/lib/modules-load.d/cdrecord.conf
drbd-utils usr/lib/modules-load.d/drbd.conf
espeakup usr/lib/modules-load.d/espeakup.conf
tp_smapi usr/lib/modules-load.d/tp_smapi.conf
tp_smapi-lts usr/lib/modules-load.d/tp_smapi-lts.conf
usbip usr/lib/modules-load.d/usbip.conf

Martin, the bug of the config will be fixed in the next release. It's building ATM, a few minutes of patience.

The benefit is that you don't need to do it anymore manually, as the package is providing it... We moving from opt-in to opt-out.

Tanks to remember me the the wiki, I will update it.

Sébastien, the difference here is that 3 of the modules are completely optional. While I disagree with a number of the other packages including these files, this one is much more of a user choice issue. What's next, adding all users to the group?

If I get your point correctly, you would prefer I only add vboxdrv and let users create another file for optional modules?

Despite the fact they are optional, is there any reason to not include them? They slow down the system / create security flaw?
vboxreload, load them since the beginning. You and other never find that insane. I never imagine that people have not added the 3 of them in their module loading.

In contract to your sarcastic proposal of "adding all users to the group", this is not removing feature from users.

I think with the info in the wiki and the option to blacklist the modules individually, we can still keep the modules customizable and simplify the installation. I for one think this should work. I was just unhappy with the breaking changes being made without any sort of notification or explanation.

What change broke something without notification? What was broken?

'systemd-modules-load.service' - That was my first comment.

That's not the change which broke that, it a bug ( FS#48551 ). If I didn't fuck up with \n, the change didn't break a thing.

Anyway, I added a post_upgrade note to warn users that we now rely on modules-load.d and we load all modules by default.

Well, the message I got was something of the sort - 'failed to load vbox* as it is already loaded'. And then the service failed. I've adjusted my config and now it's all good.

Ok, systemd-modules-load is not as elegant as I thought. Thanks for pointing this to me.
A lot of people will have to adjust their config.

What I can do to minimize the burden, is to rename the s-m-l.d file to virtualbox.conf, so if users followed the wiki, their file in /etc/ will take the precedence over my file in /usr. This will even only load vboxdrv if they originally put only this one.

What's do you think?

I miss to mention that I didn't do it originally because this would require a conflict between guest and host modules and prevent you to run an host inside a guest. Which is theoretically possible.

Well, that's bad news then. Stripping users from a valid functionality is not acceptable, I think. Keep it as is and as long as there is a notification at upgrade to adjust the conf, I don't see a problem. Maybe other people can chime in on this, but I am now happy with the way it's setup.

I share that with you, stripping this not a good idea.

But I checked what you said earlier and systemd-modules-load didn't fail because you have the same module specified twice (even in different file).
So, there is no really need to name the file virtualbox.conf and conflict, and, so far, there is no breakage linked to that change.

I don't know what to tell you but I even get it on my guest when I have two config files with overlapping modules. Look attached.

EDIT: Sorry, my bad. This is possibly another bug on the guest package itself. I get error - systemd-modules-load[149]: Failed to find module 'vboxnetadp'. This module should not be loaded on the guest I think.

Konstantin: That bug has already been reported at  FS#48566 

Martin is correct, vboxnetadp is an host module, not a guest one (I forgot to replace it by vboxvideo). The error is linked to the bug pointed, not to the duplication.
So we are on the same line.

since virtual-host-dkms 5.0.16-3 I get these errors :

mars 15 15:35:44 ultima-dbr systemd[1]: Failed to start Load Kernel Modules.
mars 15 15:35:44 ultima-dbr systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
mars 15 15:35:44 ultima-dbr systemd-modules-load[206]: Failed to find module 'vboxdrv'
mars 15 15:35:44 ultima-dbr systemd-modules-load[206]: Failed to find module 'vboxpci'
mars 15 15:35:44 ultima-dbr systemd-modules-load[206]: Failed to find module 'vboxnetadp'
mars 15 15:35:44 ultima-dbr systemd-modules-load[206]: Failed to find module 'vboxnetflt'

it seems that Sébastien Luttringer wants to force the load of these virtualbox kernel modules even if the user doesn't want this

in my case I don't use very often virtualbox, so I don't want an automatic load of kernel modules at each boot

@patrick, I don't want to force you to load anything at boot.

If you don't want these modules loaded at boot, drop an empty file in /etc/module-load.d/virtualbox-host-dkms.conf as it's explain in the upgrade message.

@Sébastien : I tried another workaround : I deleted the file /usr/lib/systemd/systemd-modules-load/virtualbox-host-dkms.conf,

a better solution would be to create a systemd service for loading virtualbox kernel modules, users who want an automatic load at boot will simply activate this systemd service,

in archlinux packages like apache, tomcat, the systemd service is never activated by default, I think virtualbox packages should also follow this rule

@patrick : yes, this is what I was thinking about since the top of the comments. Virtualbox even has an executable to load the correct modules (vboxreload), should they ever change or something.

Perhaps it makes sense to load some of the other modules by default but in the case of virtualbox, which I rarely use but still need every so often, I'd rather not have the modules loaded all the time. Even upstream considers them to be of rather poor quality — loading them marks the kernel as tainted.
IMHO, we should follow the no-enabled-services-by-default "policy" here as well and leave it up to the user to decide what they want and don't want to run, no need to babysit them.