All other non-persistent dynamically loaded firmware goes in to /lib/firmware (ie for usb tv tuners and such). Shouldn't microcode-ctl also keep microcode.dat here for tidiness? Reproducible: Always Steps to Reproduce: emerge microcode-ctl Actual Results: microcode.dat ended up in /etc instead of /lib/firmware Expected Results: microcode.dat should technically go in to /lib/firmware with other firmwares
The Intel website says the microcode should go to /etc/firmware see http://downloadcenter.intel.com/Detail_Desc.aspx?ProductID=942&DwnldID=14303&lang=eng
And why should this matter? Intel don't maintain the microcode_ctl application, and all other firmwares are kept in /lib/firmware. Why keep multiple locations for firmwares, throwing things all over the FS in a disorderly fashion just because one vendor suggests a specific location that makes no difference to anyone using gentoo apart from being messy?
And for what it's worth, the microcode.dat ISN'T ending up in /etc/firmware anyway. It's ending up in /etc directly as /etc/microcode.dat...
Why is the microcode supplied with the tool anyways? The most recent version can be publically downloaded from the intel website. And microcode-ctl does not currently include the most recent version. There is a package micocode-data which points to an outdated version on urbanmyth.org. Shouldn't microcode-ctl be installed without any firmware at all, and microcide-data point to the intel website?
(In reply to comment #4) > Why is the microcode supplied with the tool anyways? > > The most recent version can be publically downloaded from the intel website. > And microcode-ctl does not currently include the most recent version. > > There is a package micocode-data which points to an outdated version on > urbanmyth.org. Shouldn't microcode-ctl be installed without any firmware at > all, and microcide-data point to the intel website? > Only microcode-ctl-1.17 supplies the microcode. microcode-ctl-1.17-r1 (unstable) pulls in microcode-data which pulls in the latest microcode from intel. As to the rest of the bug; I tend to agree with Wes. CPU firmware should move to /lib/firmware, preferably named better e.g. intel_cpu_microcode.dat. Also fwiw, I've been using the unstable microcode-{ctl,data} packages for quite a long time now and think they would be good stable candidates (after firmware move). Would probably also be good to make the RDEP in microcode-ctl version-specific for the sake of upgrades. base-system, if I you'd like me to lend my hands on this one I'll be happy to run with it.
Putting the microcode in /etc has an annoying consequence: an update triggers the CONFIG_PROTECT feature of portage. After an update of the microcode, emerge reports that "1 file changed in /etc" and doing dispatch-conf on the microcode takes a long time and is not really needed; the microcode is not a configuration file. So yes, I think it should be moved away from /etc.
Created attachment 176427 [details, diff] microcode-data-20080910.ebuild.patch Here is the patch for microcode-data-20080910.ebuild to use /lib/firmware instead of /etc.
Created attachment 176429 [details, diff] microcode_ctl.rc.patch Here is the patch for /etc/init.d/microcode_ctl (sys-apps/microcode-ctl/files/microcode_ctl.rc in portage) to use /lib/firmware/microcode.dat instead of /etc/microcode.dat.
Is there any update on this out of interest?
Fixed.
