The continuing modconf saga
ref: http://bugs.debian.org/63269
I apologize for not having tracked this down earlier. When I test modconf I
usually do it in a chroot jail instead of building the entire boot-floppies
(takes about 30-40 minutes on my box :<) and testing it in real life, so
this bug was rather elusive.
As it turns out, modutils recently[1] started to rely a bash-specific
feature -- that $UID is set (to 0) in update-modules. Otherwise it will exit
immediately. Thus, even though modconf was calling it, it was exiting
immediately and not creating a modules.conf file. The one that most people
are copying and saying that it "fixed" their problems is the default one
written to the root disk during boot-floppies build. I suspect you will find
that if you added parameters for your hardware, your parameters won't get
written to the modules.conf file that you are copying.
I have filed a grave bug against modutils for this. I hope Wichert will fix
this very soon.
There were two other problems with update-modules/boot-floppies --
update-modules relied on the -f flag for cp, and being able to do tail -1.
Because of busybox limitations these also caused update-modules to fail.
I have patched up busybox to support cp -f and tail -1, as well as adding an
id command to busybox so that update-modules can use that instead of $UID. I
hope this will fix all the problems with update-modules and moconf, and I
will test it some more before 2.2.13 gets out the door.
the busybox changes are in CVS. There's also a *temporary* NMU of modutils at
http://samosa.debian.org/~tausq/modutils_2.3.11-1.1_i386.deb
This is mostly meant for people who are building/testing boot-floppies from
CVS. I suspect we won't release boot-floppies 2.2.13 officially until a
maintainer upload is done.
randolph
[1] On another system I found that modconf used to use $(id -u) instead of
$UID. I'm not sure why it was changed. This was in version 2.1.121-25
--
Debian Developer <tausq@debian.org>
http://www.TauSq.org/
Reply to: