Why create the blacklist in /dev like that, only to have it symlinked repeatedly if it doesn't exist. Wouldn't it make more sense to create it directly in /etc/modprobe.d/ ?

Also, this is going to parse the kernel cmdline twice. Not sure of a good way around that, though, except to just skip it in rc.sysinit... but then if someone does not use mkinitcpio, they don't get that feature.

And a third point: we should put big "### DO NOT EDIT THIS FILE" type guards on that autogenerated thing.

All in all, I like this. It should make boot faster, and it makes more sense now that modprobe can handle things like this.

/etc/modprobe.d could be readonly (e.g. in rc.sysinit before fsck was run), but /dev is always writeable, because it's on tmpfs.

Hi, I don't know if you guys are still working on this, but in case you are, I have a question/suggestion:
Is there any reason why the generation of the blacklisting file can not be done at shutdown rather than at boot? That would avoid having to create files in /dev. Furthermore, one could also create a file in /etc/modules.d/ for the modules that should be loaded, in order to avoid parsing the MODULES array at boot.
Any thoughts?

A very simple solution would be: Place a hand-written blacklist file in /etc/modprobe.d and use MODULES only for loading modules, not for blacklisting them.

@Waldteufel:

I used your idea in systemd's Arch support (but at shutdown rather than at boot) <https://github.com/teg/initscripts-systemd/commit/1e0b6aec1e4e8729336338bb5805156f9f5c9de6>. Seems to be working well. Killing /lib/udev/load-modules.sh speeds up boot considerably.

Is there anything in particular preventing these patches being applied? If there is interest, I could prepare patches to avoid generating files in /dev (by writing them at shutdown instead).

I have an updated version of the original patch that I want to push to initscripts. That is, the blacklist file is created in /run/initscripts/ (which is always rw) and a symlink is placed in /etc/mod-probe.d/ to the autogenerated file.

Before I push this, I'd like to know if this truly would make load-modules.sh obsolete? Is the blacklisting we get by adding an install line to mod-probe.conf equivalent to blacklisting a module in rc.conf?

Okay, this is what I think:

1) Make sure we have a config file in /etc/modprobe.d/ that has an include statement for /run/initscripts/blacklist.conf
2) Make sure we regenerate the blacklist after we moved from mkinitcpio to initscripts.
3) Make sure udev uses modprobe -b!

This should take care of everything. Can you update the mkinitcpio packages as well.

Note: This is possible now because a) we don't have /etc/modprobe.conf anymore, only /etc/modprobe.d, b) we have /run. In this context, I like this idea much more than before.

As far as I understand the manpage, with the -b switch "blacklist foo" should be sufficient instead of "install foo /bin/false".

@Thomas,Benjamin: Thanks for the input (I did not know about the "modprobe -b"/blacklist combo).

I suggest adding the attached file to udev (/lib/udev/arch-blacklist-modules) and then patch mkinitcpio and initscripts to call this before starting udev. I would also add a symlink to the udev package /etc/modprobe.d/arch-modules-blacklist.conf -> /run/initscripts/modules-blacklist.conf.

I have quite some patches for our udev package (including this one), where is the best place to post them for review? <arch-projects@archlinux.org>?

1) udev uses modprobe -b by default these days. load-modules.sh should actually emulate that behaviour right now.
2) Haven't looked at the blacklist stuff, but it must be different in initramfs than in initscripts: initscripts has rc.conf and uses bash, busybox ash doesn't have rc.conf and doesn't understand array syntax.
3) Symlink vs. config file with include statement - does any have an advantage over the other?
4) About udev - you should talk to tpowa, maybe you could even take over udev maintenance. I think tpowa wouldn't mind if his workload was reduced.

1) yes, this is the default, so it works out really well.
2) doh', yes you are right I forgot about the difference. might as well include this in initscripts straight away then, would make coordination easier.
3) what is the include syntax? i guess it will not make a difference one way or the other, I just could not find the include syntax in the modprobe.d man page.
4) I'd be happy to take over udev if tpowa doesn't want it, I'll talk to him about it.

The initscripts part is now in git.

It uses the "blacklist <module>" syntax and only reads the MODULES array in rc.conf.

Allowing blacklisting via kernel parameters is useful if you are unable to boot your system due to a module. However, it should be enough to support this in mkinitcpio as this should allow you to edit your rc.conf and blacklist the module there.

Could you please also add the kernel command line code? This doesn't take much time in bash and may solve real problems.

@brain0: We could do. I am looking into it now (trying to see what others are doing and asking on #udev).

The reason I didn't is that I'm struggling to understand the use-case. If your system is unbootable after an upgrade, then you'll have to somehow access your system to be able to figure out what module causes the problem. This can be done by booting with "init=/bin/bash", in which case udev will not be run. We should probably also fix single-user mode to not start udev, in which case that could also be used. Either way, you'll need to log on to your box, and once you are there you can just add the offending module to rc.conf, rather than rebooting and adding it to your kernel parameters.

My concern is that this code path would be so seldomly used that bugs could easily creep in.

(I'm routinely messing up my modprobe/udev/initscripts to make my system unbootable, but have never used anything but "init=/bin/bash" to fix it).

That said, I'm not strongly opposed to adding it, so will do if you think it is needed.

If a module stalls at boot, you can easily just add the disablemodules= statement and omit it.

It is also important for consistency between early and late userspace: If I blacklist a module using disablemodules=, I except that it is not loaded. When you ignore this setting, it will just be loaded later.

@brain0: yeah, it makes sense. I think there is a nicer way to do it though (after discussing on #udev). This could and should be added upstream to module-init-tools.

The functionality would then be something like this:
modprobe.blacklist=mod1,mod2,...

Also, it would make sense for modprobe to read the autogenerated files in /run rather than having a symlink.

I'm waiting for the maintainer to tell me if he would accept these kind of patches, if so, I'll submit them.

In the meantime (as I guess it could take some time), I'll add this to the modprobe-blacklist generator script as you suggested.