FS#30044 - [linux] Update to 3.3.7 leads to modules load fail

Attached to Project: Arch Linux
Opened by Michael Kogan (Photon) - Monday, 28 May 2012, 13:07 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 23 July 2012, 18:16 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

After the upgrade from 26.05.2012 my keyboard stopped reacting on input. Unplugging the keyboard and plugging it in again doesn't help, so in fact I can't even log in - had to chroot into the system for diagnostics. At boot I get a [FAIL] at "Loading user-specified modules". It seems as if not only the USB modules would fail to load but also cpufreq, fglrx and others.

Downgrading linux and linux-headers to 3.3.6-1 made the problem disappear, another update to 3.3.7 reproducibly leads to the problem again, so it's obviously a problem introduced by the kernel update to 3.3.7.

The pacman output during the kernel update is attached (though I don't see anything suspicious there), the MODULES array from /etc/rc.conf is:

MODULES=(fuse powernow-k8 cpufreq_ondemand)

See also this thread: https://bbs.archlinux.org/viewtopic.php?pid=1107516

If you need any further information, let me know.
   pacman.log (2.4 KiB)
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Monday, 23 July 2012, 18:16 GMT
Reason for closing:  Not a bug
Comment by Dave Reisner (falconindy) - Monday, 28 May 2012, 19:21 GMT
Working as intended: https://bugs.archlinux.org/task/28778

cpufreq_ondemand is the default, and no longer exists as a module.
Comment by Michael Kogan (Photon) - Friday, 01 June 2012, 23:11 GMT
  • Field changed: Percent Complete (100% → 0%)
Same problem appears even after removing powernow-k8 and cpufreq_ondemand from the MODULES array. Also, do the bare minimum and compare the dates of the bugs: My problem appeared after the update of 26.05 while the bug that you linked in your comment is marked as fixed at 26.03, two months before...
Comment by Tom Gundersen (tomegun) - Friday, 01 June 2012, 23:13 GMT
The bug report is mixing two things (the module load fail warning, and the broken input). AFAIK, you don't need any of these modules in your MODULES array as of 3.4. I'd suggest emptying your array and trying again with that kernel.

My best guess at what is going wrong is that your kerenl in /boot and your modules in /lib/modules do not match, and that somehow you upgraded the modules but not the kernel, or something like that.
Comment by Tom Gundersen (tomegun) - Friday, 01 June 2012, 23:14 GMT
BTW, the linked bug was actully a feature request, it would explain why cpufreq_ondemand is no longer needed. So the fact that this is older than your report is not surprising.
Comment by Michael Kogan (Photon) - Saturday, 02 June 2012, 07:34 GMT
Tom, thanks for reopening, I've almost lost the hope that the bug will ever be reopened again. :)

Well, of course it's not surprising that the bug report is older than mine, but since my report was closed by Dave with a link to this bug report, I thought that he supposed the no longer existing cpufreq_ondemand module in my MODULES array would be the cause of the problem. So I argued that the cpufreq_ondemand module was removed two months ago, but my problem didn't appear until the 3.3.7 update, 3.3.6 worked correctly with the same MODULES array.

But, back to topic: I already tried to remove everything besides fuse and it still failed, I'll try to remove fuse as well and report back.

It might be that there are two things mixed up here, but both of them appear and disappear if I upgrade or downgrade the kernel.

As you see in the pacman output, there were no errors when updating the kernel to 3.3.7. So how do I find out if something went wrong? I can chroot into the updated system with 3.3.7 kernel and make some diagnostics but I don't really know what to do. :)
Comment by Michael Kogan (Photon) - Saturday, 02 June 2012, 08:31 GMT
Here's what happened when I booted with an empty MODULES array: The [FAIL] on "Loading user-specified modules" is now gone, but there's another one instead: "Interface eth0 does not exist". So some network module seems to be missing when booting without fuse.

Beside of that, the keyboard still didn't work and I couldn't log in to check if other modules like cpufreq or fglrx could be loaded...
Comment by Michael Kogan (Photon) - Tuesday, 12 June 2012, 16:38 GMT
The bug still appears with 3.3.8. Another observation: It does _not_ appear on another installation. The main differences between the installations: The working installation is installed on an HDD and is 32Bit, the broken installation is installed on an SSD and is 64Bit. /etc/rc.conf is almost identical on both installations though, at least concerning the MODULES and DAEMONS arrays they are identical. If you need any informations for finding the cause of the problem, please let me know!
Comment by Michael Kogan (Photon) - Saturday, 07 July 2012, 09:55 GMT
Problem persists on 3.4.4-2.
Comment by Michael Kogan (Photon) - Tuesday, 17 July 2012, 10:47 GMT
The update of kmod from 9-1 to 9-2 also results in the described error. Using

glibc 2.16.0-1
kmod 9-1
linux 3.3.6-1
linux-headers 3.3.6-1

is a workaround.
Comment by Michael Kogan (Photon) - Saturday, 21 July 2012, 11:12 GMT
I could successfully upgrade glibc and kmod, so the move from /lib to /usr/lib is completed on my machine. Still, as of kernel 3.4.5-1 each attempt to update the kernel results in all modules being not found. So I have to stick to kernel 3.3.6 for now. Any advice on how to diagnose the problem is greatly appreciated.

Loading...