On Thu, Jan 5, 2012 at 6:40 PM, Dave Reisner wrote:

Hey all,

I've just dropped kmod-3 into testing as a replacement for module-init-tools. This is still a young project, but it has a lot of support from active people, and I (as well as Tom) have been working closely with upstream to flesh out and fix bugs.

For the most part, you should not notice any difference. kmod was designed as a drop-in replacement for m-i-t, and all the binaries should exist with the (mostly) the same options. Whenever possible, options or features marked deprecated in m-i-t were removed, such as:

- parsing of depmod/modprobe config for files not ending in .conf - modprobe's -l, --list options

IMPORTANT: In line with the first change, it needs to be pointed out that we will no longer package /etc/modprobe.d/modprobe.conf. This means that if you wrote to that file, it will be .pacsave'd on removal of m-i-t and you must rename it. We will continue to ship what used to be called /etc/depmod.d/depmod.conf, but rename it /lib/depmod.d/search.conf. This will be a read only file -- users should put their own tweaks in /etc/depmod.d.

One other thing you might notice is that kmod doesn't currently include man pages. I don't consider this a loss -- the m-i-t manpages did not provide full coverage, nor did the command line help. kmod's binaries all currently have full coverage of options via -h, --help.

Lastly, there's an accompanying mkinitcpio update to account for some extra verbosity of kmod's modprobe and depmod tools. You do *not* need to regenerate your initramfs images unless you feel so inclined.

Have fun!

Or don't. Not to rain on Dave's parade (this isn't his fault), but unless you want to sit at your initrd shell for a half hour un-breaking stuff, I'd recommend steering clear of this package and sticking with the old but proven module-init-tools. This package causes modprobe when called by udev to randomly not load modules or something; first noticable with uhci_hcd and my mouse (trivial), later with ahci on boot (not cool, not having disk drives). **Tip**: if you get screwed, call `udevadm trigger` a few times, it seems to knock some sense into the system. You can do this in the initrd environment too. -Dan

Am Thu, 5 Jan 2012 19:40:47 -0500 schrieb Dave Reisner :

Hey all,

I've just dropped kmod-3 into testing as a replacement for module-init-tools. This is still a young project, but it has a lot of support from active people, and I (as well as Tom) have been working closely with upstream to flesh out and fix bugs.

For the most part, you should not notice any difference. kmod was designed as a drop-in replacement for m-i-t, and all the binaries should exist with the (mostly) the same options. Whenever possible, options or features marked deprecated in m-i-t were removed, such as:

- parsing of depmod/modprobe config for files not ending in .conf - modprobe's -l, --list options

IMPORTANT: In line with the first change, it needs to be pointed out that we will no longer package /etc/modprobe.d/modprobe.conf. This means that if you wrote to that file, it will be .pacsave'd on removal of m-i-t and you must rename it. We will continue to ship what used to be called /etc/depmod.d/depmod.conf, but rename it /lib/depmod.d/search.conf. This will be a read only file -- users should put their own tweaks in /etc/depmod.d.

Such thing should be brought up to our lists before they hit the repo. All files in /etc/depmod.d/ and /etc/modprobe.d/ are ignored here. So module blacklisting doesn't work there for users/admins. We need to fix https://bugs.archlinux.org/task/27846 to allow admins to blacklist modules again. The only place that works here is /lib/modprobe.d/foo.conf Should we rebuild all packages that right now put files into /etc/modprobe.d/ ? Can somebody with a full svn checkout do a grep to get a list? -Andy

Hi Dave, On Fri, Jan 6, 2012 at 1:40 AM, Dave Reisner wrote:

I've just dropped kmod-3 into testing as a replacement for module-init-tools. This is still a young project, but it has a lot of support from active people, and I (as well as Tom) have been working closely with upstream to flesh out and fix bugs.

As kmod is installed in /usr/bin, the symlinks from /sbin/modprobe et al means that users with a separate /usr will be out in the cold. Once the usr hook is out, this is all good, but in the meantime I guess this is a bit too harsh? Maybe best to keep m-i-t until usr-hook is ready, and install kmod without the symlinks? Alternatively, we could move kmod to /, but then we'd have to make sure there are no new deps we also need to move, and people would cry when we move it back, so I'm sort of against that. I guess the order of doing things should be: kmod-3 (without symlinks) util-linux (2.21 or backporting to 2.20, i guess we'll backport if this is how we end up doing it) mkinitcpio (with usr hook) kmod-* (with symlinks, drop m-i-t) udev-176 If possible I'd like to drop m-i-t in good time before udev-176, so we can clear up any bugs from that transition before they get muddled together with the new udev release. What do you think? If you agree I'll push a new util-linux today (if you also remind me which patches you need backported ;-) ). Cheers, Tom