[0] https://packages.ubuntu.com/en/artful/amd64/intel-microcode/...
[1] https://lists.debian.org/debian-devel/2017/06/msg00309.html
This recently came to my attention while debugging some increasingly frequent lockups, which took me a solid week of eliminating all seemingly more likely causes (VirtualBox, nVidia driver, faulty RAM, etc). In the end I found the culprit while digging into the Intel Specification updates: my Core i7-5820K (and most other Haswell-E and Broadwell processors) has a bug when leaving package C-states, and the only workaround is to disable C-states above level 1. Timely updated microcode, which applies this workaround, would have saved me my week.
[1] https://launchpad.net/ubuntu/xenial/+source/intel-microcode [2] https://launchpad.net/ubuntu/+source/intel-microcode/+change...
By ancient, perhaps you mean the version that was current at the time 16.04 shipped?
> I cannot understand why they left out 16.04 there. So much for LTS, it seems.
See https://wiki.ubuntu.com/StableReleaseUpdates. The point of an LTS (or any stable release, for that matter) is that it doesn't change by default. For those who want to keep everything up-to-date, Ubuntu ships a new release on a six month cadence. If you choose not to use that, then you shouldn't be surprised when things aren't updated, since that's exactly what you opted in to.
The microcode package may warrant an exception, however, and we have a bug to track that. It's tricky because without the source we cannot pick apart what changed, or determine whether any changes meet our update policy. We have to be careful. Sooner or later some user will inevitably come along to tell us that a microcode update broke things, and ask why we didn't fulfill our LTS promise by not changing it.
You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect, does it? Precisely because Ubuntu cannot pick it apart, what is it that they're trying to decide in the bug? Why is Ubuntu second guessing Intel in deciding which microcode update to apply and which to skip? How would Ubuntu know that better than the manufacturer? The Intel specification updates list tons of processor bugs including some very critical ones, so we know the microcode updates do help with some of those. When was the last time that an Intel microcode update brought a new bug or made something worse? I'm not aware of any such instance, and although that may indeed happen sometime it doesn't seem as likely as facing existing known bugs, right?
I think it could be argued that it is up to the user to decide (say, a warning during installation), or that Ubuntu could choose to apply all microcode updates by default and let the user opt out. Ubuntu might impose a certain delay, say a month or two at most, in order to see if a microcode update gets withdrawn or ends up too buggy. But I don't think Ubuntu could reasonably choose to skip all microcode updates for 1.7 years like it did in my case, or to choose which ones to apply and which ones to skip, like it seems to be trying to. Microcode should be treated like other propietary software, but with special dilligence due to its criticality. If nVidia says a particular driver release is very buggy and should be updated, Ubuntu promptly updates it. Why would Ubuntu sit on known critical microcode updates then? If, and it's really a big if, eventually some microcode update brings a new bug and Ubuntu deployed it, it would be Intel's fault and not Ubuntu's.
> I think it's a fair and tame adjective considering this is processor microcode we're talking about...
Processor microcode updates haven't, to my knowledge, ever automatically been applied by distributions in the past. In light of that, I don't see how it's reasonable to have an expectation otherwise.
> You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect, does it?
By being careful before pushing out an update to millions of users? I'd say that's a positive effect.
> ...what is it that they're trying to decide in the bug?
Whether to continue to let users have a choice, or by taking that choice away by doing things automatically for them. There are also packaging-based regressions to consider; not just the microcode ones. For example: if the wrong microcode is applied to the wrong processor because of a packaging error, who would you be blaming? Intel or Ubuntu?
> But I don't think Ubuntu could reasonably choose to skip all microcode updates for 1.7 years like it did in my case...
Ubuntu didn't "choose to skip" all microcode updates. Ubuntu didn't choose at all; pushing an update requires a specific effort.
In light of this issue, Ubuntu is now considering what to do about it, responsibly, for all users. Both for this particular issue, and for microcode updates going forward.
I wasn't aware of this, thanks. Though I searched, and I found that they've been causing their users problems by doing so: https://rhn.redhat.com/errata/RHBA-2017-0028.html
I think this backs up my point: care must be taken.
The whole point of an LTS release is that they will keep a stable baseline for all the packages they're distributing and apply a certain amount of integration testing. If you believe upstream knows best (and I'm not saying you're wrong to do so) then why use LTS in the first place?
I think you're confusing an objective (LTS) with a tactic (keeping a stable baseline). Certainly the whole point of LTS is not to keep a stable baseline, but to provide long-term support. And that is clearly violated when Ubuntu chooses to not provide support when it is known to be needed (e.g., listed in an Intel Spec update) and a solution is available by a vendor (e.g., Linux-specific microcode update being made available by Intel). The whole point of LTS is to avoid the bleeding edge while fixing known bugs. Microcode updates is not bleeding edge, it's just patches for known bugs.
No, you've got it backwards. If you just wanted long-term support you'd use a rolling release distribution, of which there are any number (yes some rolling release options are "bleeding edge", but there are stable options too). The whole point of LTS releases is that they are stable baselines that are supported in the long term.
The costumer or user of LTS wants, well, Support (fixes) for some extended time (Long Term) and avoiding problems (less bugs), perhaps at the cost of getting less new features. The whole point of LTS is self-explanatory.
Keeping a stable baseline is a tactic used to try to provide long-term support by reducing the amount of new bugs at the cost of less new features. But keeping a stable baseline does not attain the key word, the substantive in LTS: Support. Support is provided only by introducing fixes, and that is exactly what has been omitted in the case of the Intel microcode bugs.