Hello, FWIW, I am considering changing the way *Debian* handles this (Ubuntu might or not want to follow suit). Since Debian does not support late- loading of microcode anymore, I am considering to change intel-microcode to ship *only* a /usr/share/misc/intel-ucode_<date>.bin file. There would be *nothing* in /ib/firmware/intel-ucode/ anymore [*]
This takes care of the duplication caused by microcode data files with extended microcode signature tables. There is an alternative: one could replace identical data files with symlinks or hardlinks at package build time. It is also on the table. [*] anyone that needs late-loading of microcode should be capable enough to run iucode-tool -K to recreate /lib/firmware/intel-ucode, or I could have that as a configurable item of low priority, default disabled. But it doesn't seem worth the effort at first glance. Alternatively, I can finish and ship the next iucode_tool version, which can detect "late- loading allowed" metadata Intel introduced sometime ago, and create /lib/firmware entries only for those. Any thoughts on this ? -- Henrique de Moraes Holschuh <h...@debian.org> -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2104539 Title: About 35% of intel-microcode firmware are duplicate files by disk usage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/2104539/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
