[arch-dev-public] kmod-3 in [testing]
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! Regards, Dave
On Thu, Jan 5, 2012 at 6:40 PM, Dave Reisner <d@falconindy.com> 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
On Thu, Jan 5, 2012 at 9:41 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Jan 5, 2012 at 6:40 PM, Dave Reisner <d@falconindy.com> 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.
Update- because Dave is awesome, he whipped up some patches and I tested them that appear to fix the above problem, so the latest kmod package in [testing] should be safe to test. Thanks Dave! -Dan
Am Thu, 5 Jan 2012 19:40:47 -0500 schrieb Dave Reisner <d@falconindy.com>:
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
On Fri, Jan 6, 2012 at 11:29 AM, Andreas Radke <andyrtr@archlinux.org> wrote:
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.
This is a packaging bug, Dave is rebuilding with a fix.
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?
In general, and regardless of kmod, packages should install their config files in /lib/modprobe.d, and leave /etc/modprobe.d to admins. This works (in module-init-tools, as well as in kmod) in the same way as with udev's rule files. If a file foo.conf exists in both /etc and in /lib, the version in /etc is used and the one in /lib is ignored. This means the admin can easily override the standard config files supplied by the packages, and the package updating the config file does not create .pacnew/.pacsave files. I'll be looking at making a todo with packages to be updated, but there should be no hurry. Cheers, Tom
Hi Dave, On Fri, Jan 6, 2012 at 1:40 AM, Dave Reisner <d@falconindy.com> 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
On Fri, Jan 06, 2012 at 01:17:37PM +0100, Tom Gundersen wrote:
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
Let's leave kmod as is for now. We'll get the /usr mount functionality ready for mkinitcpio and roll that out for testing after you repackage u-l 2.20.1 for me.
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.
Well, the "possible" part is only made possibly by kmod-3 not throwing any show stoppers. It hasn't... yet.
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 ;-) ).
14f66ad6^..46c59b51: fixes bugs that Gerardo pointed out about mount not behaving properly with regard to attempting canonicalization of pseudofs mount sources. This is visible in the form of /run being mounted with a source of /run (rather than just run). It also crops up in a few other situations [1] and is is varying degrees of annoying, but isn't fatal. d466c6a1: alters the -s, --fstab option of findmnt -- allows an optarg to point to an arbitrary fstab. I'd like to leverage this for mounting /usr from early userspace. d [1] http://mailman.archlinux.org/pipermail/arch-projects/2011-December/002297.ht...
participants (4)
-
Andreas Radke
-
Dan McGee
-
Dave Reisner
-
Tom Gundersen