[arch-general] Kmod testing
Fisrt Kmod experience, which spit out a lot of udevd messages, logged in, startx, openbox starts, then one locked up box. I was going to Ctrl Alt F2, log in, and do some work with udevadm but I had no keyboard of mouse control. I turned the box off then on to reboot, pacman -Rdd kmod pacman -S module-init-tools then reboot. I've examined the boot log from the previous run and here is a sample. Fri Jan 6 01:03:19 2012: udevd[310]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:LNXCPU:': No such file or directory Fri Jan 6 01:03:19 2012: Fri Jan 6 01:03:19 2012: udevd[393]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0C04:': No such file or directory Fri Jan 6 01:03:19 2012: Fri Jan 6 01:03:19 2012: udevd[334]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0C02:': No such file or directory Fri Jan 6 01:03:19 2012: Fri Jan 6 01:03:19 2012: udevd[324]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0401:': No such file or directory I went back and read the messages from Dave and Dan to see if I'd missed anything and hadn't. After the install of Kmod, before I rebooted, I read the help message from kmod --help and there were commands listed for compatibilty mod with modprobe. I've already been triggering the udev rules after I boot to find my audio card but that wont work for this behavior because triggering the rules will simply look for /sbin/modprobe again. The kernel update came in at the same time, so the initrd images were rebuilt prior to rebooting. For know I've put kmod in my ignore packages line in pacman.conf. Do the udevd rules need to be written to point to kmod with it's compatibility mode or is there another solution? Thanks for any assistance. Myra -- Life's fun when your sick and psychotic!
On Fri, Jan 6, 2012 at 01:38, Myra Nelson <myra.nelson@hughes.net> wrote:
Fisrt Kmod experience, which spit out a lot of udevd messages, logged in, startx, openbox starts, then one locked up box. I was going to Ctrl Alt F2, log in, and do some work with udevadm but I had no keyboard of mouse control. I turned the box off then on to reboot, pacman -Rdd kmod pacman -S module-init-tools then reboot. I've examined the boot log from the previous run and here is a sample.
Fri Jan 6 01:03:19 2012: udevd[310]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:LNXCPU:': No such file or directory Fri Jan 6 01:03:19 2012: Fri Jan 6 01:03:19 2012: udevd[393]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0C04:': No such file or directory Fri Jan 6 01:03:19 2012: Fri Jan 6 01:03:19 2012: udevd[334]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0C02:': No such file or directory Fri Jan 6 01:03:19 2012: Fri Jan 6 01:03:19 2012: udevd[324]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv acpi:PNP0401:': No such file or directory
I went back and read the messages from Dave and Dan to see if I'd missed anything and hadn't. After the install of Kmod, before I rebooted, I read the help message from kmod --help and there were commands listed for compatibilty mod with modprobe. I've already been triggering the udev rules after I boot to find my audio card but that wont work for this behavior because triggering the rules will simply look for /sbin/modprobe again. The kernel update came in at the same time, so the initrd images were rebuilt prior to rebooting.
For know I've put kmod in my ignore packages line in pacman.conf. Do the udevd rules need to be written to point to kmod with it's compatibility mode or is there another solution?
Thanks for any assistance.
Myra -- Life's fun when your sick and psychotic!
I left the complete message in on purpose. I've managed to solve(?) part of the problem. I did miss one item in the messages from Dave and Dan, to rename/move depmod.conf then put it back after the update. However the blacklist files ending in conf don't get parsed. My bad. Sorry for the noise but may me being an idiot and dumping noise on the mailing list will help others that don't read well either. Mya -- Life's fun when your sick and psychotic!
Today when updating, module-init-tools was replaced by kmod, everything went smoothly and my machine boots fine, however I have a doubt, where should module configuration files be placed, /etc/modprobe.d or /lib/modprobe.d? Will both directories be supported in the long run or is this a temporary thing not to break most systems? Mauro
On Sat, Jan 21, 2012 at 9:08 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
Today when updating, module-init-tools was replaced by kmod, everything went smoothly and my machine boots fine, however I have a doubt, where should module configuration files be placed, /etc/modprobe.d or /lib/modprobe.d?
Will both directories be supported in the long run or is this a temporary thing not to break most systems?
Mauro
http://mailman.archlinux.org/pipermail/arch-dev-public/2012-January/022330.h... Tom Gundersen wrote: 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.
On 21-01-2012 20:13, Karol Blazewicz wrote:
On Sat, Jan 21, 2012 at 9:08 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
Today when updating, module-init-tools was replaced by kmod, everything went smoothly and my machine boots fine, however I have a doubt, where should module configuration files be placed, /etc/modprobe.d or /lib/modprobe.d?
Will both directories be supported in the long run or is this a temporary thing not to break most systems?
Mauro
http://mailman.archlinux.org/pipermail/arch-dev-public/2012-January/022330.h... Tom Gundersen wrote: 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.
Exactly what I wanted to know, thanks :) -- Mauro Santos
participants (3)
-
Karol Blazewicz
-
Mauro Santos
-
Myra Nelson