[solved] udev fails to register anything on boot after kmod

usagi · 2012-01-06 23:50:03

Hello,

After yesterday's kmod upgrade, i can't seem to get udev to modprobe anything on boot. Udev throws about two dozen errors during boot complaining about "no such file or directory", but /sbin/modprobe exists, and seems to work fine with udev after the boot process is complete. i know this because i can remove and replace the USB cables to the computer, and udev picks up and modprobes the correct drivers. The same devices (keyboard, mouse) fail to load during boot.

I would throw in the errors, but dmesg doesn't seem to catch them. Most are of the form "udev: error: /sbin/modprobe "/sbin/modprobe [some "dash arguments"] usb:*huge alphanumeric string*" This is from memory, so excuse any probable inaccuracies.

Any ideas or starting points?

Thanks,
--Aaron

Last edited by usagi (2012-01-07 00:58:47)

karol · 2012-01-07 00:15:32

This has been discussed on the ML, which I'm sure you've read.
http://mailman.archlinux.org/pipermail/ … 22324.html
http://mailman.archlinux.org/pipermail/ … 23874.html

Last edited by karol (2012-01-07 00:17:04)

usagi · 2012-01-07 00:17:22

To be quite honest, I didn't even know there was a mailing list. I'll post back up when I'm better versed.

karol · 2012-01-07 00:18:36

usagi wrote:

To be quite honest, I didn't even know there was a mailing list. I'll post back up when I'm better versed.

Why are you using [testing] w/o being subscribed to the ML?
https://wiki.archlinux.org/index.php/Te … testing.5D

usagi · 2012-01-07 00:27:43

karol wrote:

usagi wrote:
To be quite honest, I didn't even know there was a mailing list. I'll post back up when I'm better versed.
Why are you using [testing] w/o being subscribed to the ML?
https://wiki.archlinux.org/index.php/Te … testing.5D

Because i don't read directions, apparently. Subscribing now. thanks for the tip.

Found my issue too. According to the mailing list, the /sbin/modprobe is a symlink to /usr/bin (which, imho, is an asinine thing to do. what's the point of /bin and /sbin if you're just symlinking to /usr?). Since i have a seperate /usr partition (actually, a seperate /usr DRIVE), it's not mounted on boot.

So, now my query becomes: is there a way to mount an arbitrary drive before boot commences?

Last edited by usagi (2012-01-07 00:29:19)

falconindy · 2012-01-07 00:51:09

usagi wrote:

So, now my query becomes: is there a way to mount an arbitrary drive before boot commences?

Expect support for this (mounting /usr) in mkinitcpio "soon". If you want to help speed along the process, here's an untested patch. Zero assumptions are made about the partition -- you will need to include any modules necessary for creating the partition in MODULES= (if it differs at all from your / partition).

Last edited by falconindy (2012-01-07 00:51:29)

usagi · 2012-01-07 00:57:59

many thanks falconindy. marking as solved, as the original issue is, sort of. anyhow, just as an academic measure, is there any way to do this with a mkinitcpio hook or similar?

ewaller · 2012-01-07 01:11:06

And, as most newbies aren't using testing, this post is being moved to a more appropriate sub-forum.

falconindy · 2012-01-07 03:33:24

falconindy wrote:

usagi wrote:
So, now my query becomes: is there a way to mount an arbitrary drive before boot commences?
Expect support for this (mounting /usr) in mkinitcpio "soon". If you want to help speed along the process, here's an untested patch. Zero assumptions are made about the partition -- you will need to include any modules necessary for creating the partition in MODULES= (if it differs at all from your / partition).

I should point out that it's actually a little more involved than just "apply the patch".

1) make sure you have util-linux>=2.20.1-2
2) add 'shutdown' and 'fsck' to your initramfs hooks in /etc/mkinitcpio.conf. shutdown only needs to be somewhere after base. 'fsck' should go after autodetect if your /usr is the same FS as root, before autodetect if its different.
3) apply said patch.
4) in /etc/fstab, set passno to 0 for your /usr partition (it'll be checked in the initramfs)
5) regenerate your initramfs.

Thanks to usagi for testing this and providing valuable feedback.

Last edited by falconindy (2012-01-07 13:43:38)

horrovac · 2012-01-12 15:58:15

Quick and dirty solution to this issue:

copy /usr/bin/kmod to /sbin/modprobe
copy /usr/lib/libz.so.1 to /lib/libz.so.1 (required by kmod)

It's of course not a solution at all, rather a hack, but it works for me, for now. When kmod or libz are updated one would need to copy them again manually, and once the /usr mounting issue is fixed, restore the old config (remove /lib/libz.so.1 and make /sbin/modprobe a symlink to /usr/bin/kmod again).

I have to agree with the previous comment that there isn't lot of point installing kmod in /usr and then symlinking it from /sbin, there is a reason why there is a /bin and /sbin to begin with. I have no knowledge about the rationale of doing it this way, but it is a rather bad idea and asking for trouble (q.e.d.). Putting it in /sbin, statically linked, would be better, if at all possible.

rolis · 2012-01-13 05:00:09

falconindy wrote:

falconindy wrote:
usagi wrote:
So, now my query becomes: is there a way to mount an arbitrary drive before boot commences?
Expect support for this (mounting /usr) in mkinitcpio "soon". If you want to help speed along the process, here's an untested patch. Zero assumptions are made about the partition -- you will need to include any modules necessary for creating the partition in MODULES= (if it differs at all from your / partition).
I should point out that it's actually a little more involved than just "apply the patch".
1) make sure you have util-linux>=2.20.1-2
2) add 'shutdown' and 'fsck' to your initramfs hooks in /etc/mkinitcpio.conf. shutdown only needs to be somewhere after base. 'fsck' should go after autodetect if your /usr is the same FS as root, before autodetect if its different.
3) apply said patch.
4) in /etc/fstab, set passno to 0 for your /usr partition (it'll be checked in the initramfs)
5) regenerate your initramfs.
Thanks to usagi for testing this and providing valuable feedback.

the patch worked for me. my /usr is ext4 on lvm.

Arch Linux

#1 2012-01-06 23:50:03

[solved] udev fails to register anything on boot after kmod

#2 2012-01-07 00:15:32

Re: [solved] udev fails to register anything on boot after kmod

#3 2012-01-07 00:17:22

Re: [solved] udev fails to register anything on boot after kmod

#4 2012-01-07 00:18:36

Re: [solved] udev fails to register anything on boot after kmod

#5 2012-01-07 00:27:43

Re: [solved] udev fails to register anything on boot after kmod

#6 2012-01-07 00:51:09

Re: [solved] udev fails to register anything on boot after kmod

#7 2012-01-07 00:57:59

Re: [solved] udev fails to register anything on boot after kmod

#8 2012-01-07 01:11:06

Re: [solved] udev fails to register anything on boot after kmod

#9 2012-01-07 03:33:24

Re: [solved] udev fails to register anything on boot after kmod

#10 2012-01-12 15:58:15

Re: [solved] udev fails to register anything on boot after kmod

#11 2012-01-13 05:00:09

Re: [solved] udev fails to register anything on boot after kmod

Board footer