Some modules are not automatically loaded after dist-upgrade from 5.10 to 6.06 beta

[Kaur Männamaa]

After upgrading from 5.10 to 6.06 beta sound, mounting removable media and network adapter didn't work. I managed to get sound and network to work by adding the necessary modules to /etc/modules. These modules were:
8139too
snd-intel8x0
uhci_hcd
ehci_hcd
usbcore
usb_storage
usbhid
vfat

But of course these lines depend on the configuration of the machine.

My point is, that for some reason dapper is not automatically loading all the modules it should.

[Kaur Männamaa (kaurman)]

Usb is working somehow, but it doesn't automount

[Graham Crumb (gcrumb)]

I've confirmed this on two separate upgrades from 5.10 to 6.06. I've got dapper-security and dapper-updates enabled as well, so we can assume that the problem still exists as of today.

Testing a work-around now. Will post details if results merit.

[Graham Crumb (gcrumb)]

Manually editing the /etc/modules to include

snd-intel8x0

Gets sound working again.

Note that adding the following modules also seems to resolve (or at least render moot) issues (Bug #38336, Bug #41381 and some of Bug #40473) concerning wacom tablets as well:

uhci_hcd
ehci_hcd
usbcore
usb_storage
usbhid

Why these modules are not detected and added ( or at least preserved from the previous /etc/modules files remains to be determined, of course).

[Graham Crumb (gcrumb)]

It looks like the problem is from a missing file...

@emigre:~$ dpkg -S /sbin/update-modules
diversion by module-init-tools from: /sbin/update-modules
diversion by module-init-tools to: /sbin/update-modules.modutils
module-init-tools: /sbin/update-modules
@emigre:~$ dpkg -S /sbin/update-modules.modutils
diversion by module-init-tools from: /sbin/update-modules
diversion by module-init-tools to: /sbin/update-modules.modutils
@emigre:~$

On top of that the update-modules script doesn't report the error:

@emigre:~$ cat /sbin/update-modules
#!/bin/sh -e
if [ -x /sbin/update-modules.modutils ]; then
  exec /sbin/update-modules.modutils "$*"
fi
exit 0

So what appears to be happening is that after the kernel upgrade, /sbin/update-modules gets called to update /etc/modules, and it exits without reporting that anything went wrong. The explicit exit 0 is the wrong default value, and in the wrong place. I'd suggest:

#!/bin/sh -e
if [ -x /sbin/update-modules.modutils ]; then
  exec /sbin/update-modules.modutils "$*";
  exit 0
fi
exit 1

And also the module-init-tools tools needs to include /sbin/update-modules.modutils

[Scott James Remnant (Canonical) (canonical-scott)]

The problem is not that missing file, we do not use modutils in Ubuntu

Please attach your /var/log/udev file

[Graham Crumb (gcrumb)]

"The problem is not that missing file, we do not use modutils in Ubuntu"

Yep, I realised that after the fact. I tried to get confirmation on how /etc/modules gets populated on IRC (including #ubuntu-bugs) and the lists, but no one was available to answer that.

Attaching /var/log/udev as requested.

[Scott James Remnant (Canonical) (canonical-scott)]

There is no attachment...

/etc/modules is written by the installer and then never modified; it only contains those modules that we can't automatically load.

[Graham Crumb (gcrumb)]

Sorry, something must have got messed up. Internet here in Vanuatu is pretty flaky most of the time....

[Scott James Remnant (Canonical) (canonical-scott)]

This udev log clearly indicates that the listed modules *are* getting loaded

[Kaur Männamaa (kaurman)]

No they are not because lsmod didn't show them. I had to add the following lines: 8139too
snd-intel8x0
uhci_hcd
ehci_hcd
usbcore
usb_storage
usbhid
vfat
 to /etc/modules and then things started to work.

It seems that this is a rare bug and very few users face it, but it sure as hell does exist and shouldn't be rejected.

[Kaur Männamaa (kaurman)]

Probably it's a silly thought, but maybe the log was created after the ptoblem had been manually fixed and so the log seems normal now?

[Scott James Remnant (Canonical) (canonical-scott)]

The log only logs what udev does, and it clearly shows udev loading the modules

[Scott James Remnant (Canonical) (canonical-scott)]

For example:

UDEV [1155009313.317543] add@/module/8139too
UDEV_LOG=3
ACTION=add
DEVPATH=/module/8139too
SUBSYSTEM=module
SEQNUM=2331
UDEVD_EVENT=1

[Graham Crumb (gcrumb)]

Whatever udev may be showing is trumped by the fact that my stylus, sound card and other USB devices did not work until I added the relevant lines in /etc/modules. Given that it happened *immediately* after updating from Breezy to Dapper, it seems reasonable to assume a change in that upgrade caused the problem.

I'm a little disappointed with the implication that the problem doesn't exist because of the contents log file. Whatever udev *said* it was doing, it wasn't working properly.

It's also true that the /var/udev file attached was from the system with the work-around already applied.

Perhaps someone can suggest some further diagnostic tests. FYI, I've been programming professionally on Linux (though on RedHat-based systems) since 1999, so with a little guidance I might be able to offer some useful feedback.

[Scott James Remnant (Canonical) (canonical-scott)]

That log isn't udev _saying_ it's going to load the module, it's the kernel informing udev that the module has been loaded into the system.

I'm not trying to be awkward or shirk a bug here, if you really have a bug, I will take the time to diagnose it for you. However I'm saying that all of the evidence you have supplied indicates the system is working perfectly and you haven't provided a single piece of evidence that it isn't.

The next course of action is logical:

 - remove any changes you have made from the system (e.g. to /etc/modules) to try and force the loading of these modules

 - boot the system

 - attach /var/log/udev from that boot

 - attach "lsmod" from after booting

 - attach output of "uname -a"

 - attach your /lib/modules/`uname -r`/modules.alias file

If you could also run the following commands and attach output from those:

modprobe --first-time -v -n pci:v000010ECd00008139sv000010ECsd00008139bc02sc00i00

modprobe --first-time -v -n pci:v00008086d000024D5sv00008086sd0000E002bc04sc01i00

modprobe --first-time -v -n pci:v00008086d000024DDsv00008086sd00004C43bc0Csc03i20

[Kaur Männamaa (kaurman)]

Scott, you were probably right and everything works fine after deleting the modules from /etc/modules and rebooting the computer. Still, I guess the problem did exist, but propper updates have been released and so you can reject the bug in peace...

[Graham Crumb (gcrumb)]

"However I'm saying that all of the evidence you have supplied indicates the system is working perfectly and you haven't provided a single piece of evidence that it isn't."

I have done. It's called testimony. 8^)

I agree that *almost always* the witnesses are not as reliable as the physical evidence, but in this case, we seem to have an exception.

I've just experienced the same breakage after installing today's kernel update (2.6.15-26-386). Attached are the files you've requested.

Again, while I don't know a lot about udev, I do have some familiarity with Linux systems. If you can point me to some docs and suggest a few diagnostic steps, I'll be happy to help with the diagnosis, if not the fix.

[Graham Crumb (gcrumb)]

Er - what was I saying about unreliable witnesses?

That last post was, uh, unreliable. Ignore that attachment.

[Graham Crumb (gcrumb)]

I'll confirm K's report and views.

The 'breakage' I reported above resulted from grub not updating the boot menu to default to the most recent kernel, which caused me to boot to the 2.6.12-10-386 kernel instead.

Whatever the problem was, it was transient.

[Scott James Remnant (Canonical) (canonical-scott)]

Heh, that doesn't surprise me ... I doubt that anything in Ubuntu dapper or edgy works with a kernel that old :)