package microcode.ctl 1.17-1 failed to install: subprocess post-installation script returned error exit status 128

This is happening for me as well on Gutsy Tribe 2, and I have a P4. I believe it occurred under Tribe 1 as well. It appears that the microcode module is not loaded when the package installs. The software is installed, it's just not functional. If you manually run the program, you get:

microcode_ctl: writing microcode (length: 293888)
microcode_ctl: cannot open /dev/cpu/microcode for writing errno=2 (No such file or directory)

I noticed the module was not loaded, so I ldid a " modprobe microcode" before running it, and got:

microcode_ctl: writing microcode (length: 293888)
microcode_ctl: microcode successfuly written to /dev/cpu/microcode

But in the syslog, a different error is coming up after the modprobe is done

Jul 8 20:00:19 localhost kernel: [ 3580.303452] IA-32 Microcode Update Driver: v1.14a <email address hidden>
Jul 8 20:00:19 localhost firmware_helper[13116]: main: error loading '/lib/firmware/intel-ucode/0f-02-04' for device '/class/firmware/microcode' with driver '(unknown)'

Also, in the past I thought the program would report the version of microcode that it updated upon a successful update. I'm not seeing that now. But it looks like two issues are present, the kernel driver is not loading, and the firmware helper seems confused on what it is supposed to do.

The first issue should be corrected in Debian 1.17-2: I do better error checking and I handle better debconf

The cause: the device was not found (no module loaded?) so postinst calls MAKEDEV, and MAKEDEV prints an error. debconf doesn't like console output (in particolar when debconf helper script are called in the wrong place (to late)).

Anyway Debian 1.17-2 is correct.

The second report is not an issue ;-):

The first part: If you run it manually, you should have also kernel/hardware support. The init.d script load the module, but I think it is not task of the program to load module (see devfsd vs. udev discussions). But then it would be an other question: should udev load the module (hardware found) at boot timet?. Maybe I will add some more info on man page.

The second part: it is correct. the microcode kernel driver have two loading methods: the "old" method with special device /dev/cpu/microcode and a loader "microcode.ctl";and a new method, using firmware kernel infrastructure (which print the warning). Unfortunately the second method is still in development. I think Intel will release it this summer. Anyway, maybe firmware_helper should be improved, because it should be a warning and not an error, and the "driver '(unknown)" is not correct ;-)

Note:
this bug affect only 1.16-1 and 1.17-1 microcode.ctl version
The new kernel microcode loading infrastructure is include only in kernels 2.6.18 and later.

This still happens with 1.17-1 in the release version of Gutsy on EM64T.

Debian 1.17-2 fix this problem

Up tp date Ubuntu Gutsy (final) on IA-32 (T2400) still has the same problem.
You have to manually load the module first, then you can run the microcode.ctl tool.
The dmesg doesn't show any error message, though.

> Debian 1.17-2 fix this problem

Debian testing already has 1.17-6. Still 1.17-1 in Ubuntu Gutsy. Does anybody care about bug fixes in Ubuntu?(see no reaction about NFS race condition, sefaulting knetstats and microcode.ctl faulting to install)

Hardy has version 1.17-2. To fix this issue in Gutsy (and other releases as well), please follow https://wiki.ubuntu.com/StableReleaseUpdates.