Update udev and remove hotplug

[chris@…]

Section 8.3 of the LFS book recommends building a completely non-modular kernel. However, the LFS bootscripts assume that you have a kernel with module support - otherwise there are a bunch of errors every time you boot. I don't think it's a problem that breaks anything (I'm pretty sure it's just the bootscript that loads kernel modules, but I haven't really checked much) but errors are bad. Perhaps the kernel installation section of the book should say that you should compile module support even if you don't build anything in the kernel as a module.

[alexander@…]

1) Please specify the exact error text. It's a bug that should be fixed.

2) The text about building a completely non-modular kernel is a remnant from the times where udev and hotplug were just introduced into the book. I wanted to explain which modules can be autoloaded in this setup and which can't, but this wasn't welcomed. Since a module won't be loaded at all if a user doesn't know which script loads it (and why), the recommendation for newbies to build a kernel without support for modules was added to the book.

Of course it would be better to point readers to the README.modules in the hotplug package, but this package is going away.

[chris@…]

(In reply to comment #1)

1) Please specify the exact error text. It's a bug that should be fixed.

"Because of the complications with Hotplug, Udev, and modules, we strongly recommend starting with a completely non-modular kernel configuration, especially if this is the first time using Udev."

Maybe just add to that text, and say that even if you build a kernel with no modules you should still enable module support in the kernel because the LFS bootscripts assume that you have module support.

[alexander@…]

You misunderstood me. The text in the book is correct. The bootscripts must work even if no module support exists in the kernel. If they don't, it's their bug. Please specify the error message from the bootscripts.

[chris@…]

Sorry, I wasn't really thinking. Here's the error output (if modules are disabled), caused by the hotplug bootscript, though it looks like the problem is in hotplug itself, not the LFS bootscripts...

./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory Opening /proc/modules: No such file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory Opening /proc/modules: No such file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or directory Opening /proc/modules: No such file or directory ./hotplug.functions: line 113: /lib/modules/2.6.15-rc4/modules.isapnpmap: No suc h file or di[ OK ]

[alexander@…]

Try this patch:

--- hotplug-2004_09_23/etc/hotplug/pnp.rc 2004-09-24 00:12:49.000000000 +0600 +++ hotplug-2004_09_23/etc/hotplug/pnp.rc.fixed 2005-12-07 15:43:08.000000000 +0500 @@ -101,7 +101,9 @@

# See how we were called. case "$1" in

start)

• isapnp_boot_events

+ if [ -r $MAP_CURRENT ] ; then + isapnp_boot_events + fi

;; stop) # echo $"isapnp stop -- ignored"

[chris@…]

Made that change, and it seems to have worked - a kernel without module support booted with no error messages.

[Matthew Burgess]

Well, with the work on udev-076 and dropping hotplug completely, I think we should hold off on applying the patch for the time being. I'll leave this bug open until the udev changes go in though.

[alexander@…]

Dropping Hotplug depends on either linux-2.6.15 or the standalone "uevent" patch: ​http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=112828738301128&w=2

In the first case, the release date is not known, so this bug can stay open for unknown period of time. I don't like that. Please include the hotplug pnp.rc patch if linux-2.6.15 doesn't come out on the next week.

In the second case, the bug can be fixed and closed without us waiting for external events, but a recommendation to build input drivers as non-modules is needed.

[Matthew Burgess]

(In reply to comment #8)

Dropping Hotplug depends on either linux-2.6.15

I realise that, as evidenced in the recent lfs-dev discussions.

In the first case, the release date is not known, so this bug can stay open for unknown period of time. I don't like that. Please include the hotplug pnp.rc patch if linux-2.6.15 doesn't come out on the next week.

But this bug has been present ever since we introduced hotplug in the book 18 months ago. The fact that only 1 person has triggered it in all that time suggests that rushing to apply a temporary fix for it is hardly a sensible use of limited resources. In addition, I'm not willing to put another patch in the book that isn't going to be accepted upstream. I'd imagine upstream's response will be a very strong NACK on 2 counts: a) hotplug is unmaintained/unsupported and b) it's not useful on a non-modular kernel

[alexander@…]

Hotplug is not only for module loading! Agents in /etc/hotplug.d can do anything. The stock ones load modules.

But hotplug is useful (with linux < 2.6.14) even with completely non-modular hernel, e.g. you absolutely need it in order to adjust scanner and camera permissions in /proc/bus/usb or to start userspace USB ADSL modem drivers. The package drops its handlers in /etc/hotplug.d/usb. Of course that's obsolete with 2.6.15.

[Chris Staub]

Renaming this bug to reflect the source of the original reported problem. There is a "udev-update" branch that is working on getting the udev setup updated for the removal of hotplug.

[Matthew Burgess]

As Chris mentions, this is now fixed in the udev-update branch as hotplug has been removed. Any regressions caused by the new udev configuration should be raised in their own tickets.