Comment 6 for bug 1742903

On Mon, 26 Mar 2018, Dimitri John Ledkov wrote:
> Something like:
>
> [[ `iucode_tool -s $(sudo iucode_tool --scan-system=2 2>&1 | sed
> 's/.*\(0x.*\)$/\1/') -l /lib/firmware/intel-ucode/ | sed -n 's/.* rev
> \(0x....\),.*/\1/p'` -eq `sudo cat
> /sys/devices/system/cpu/cpu0/microcode/version` ]] || echo 'Trigger
> reboot'
>
> should be good enough.... with bashism... as the kernel file is 0x1f,
> yet the tool reports 0x001f.

Bashisms aren't a problem, as long as the script declares to be a bash
script. Those numbers have to be properly parsed, so using bash is a good
solution. They are guaranteed to be 32-bit, too, which doesn't get in
the way (bash math is 32-bit).

The use of --scan-system=2 is a problem (slow when there are many CPUs,
requires a kernel module to be loaded), and I don't understand why the
whole dance to feed its output to iucode-tool -s. Looks like just
"iucode_tool -S" would do what is required *and* handle systems in
mixed stepping configurations better...

> There will be false negatives, and false positives, but overall should
> be better than the current behavior.

There are a lot of corner cases. Also, I am worried that it would have
*both* false positives and false negatives. False positives are
annoying and cause extra downtime (needlessly request a reboot), but
false negatives are *bad* once people start trusting the package to
request a reboot when one would be required.

For example, one has to consider whether it should be checking the
initrds as well or not. Note that while fortunately, the iucode_tool
-tr loader option can read the initrd directly, the intel-microcode and
iucode-tool packages have no idea where the initrd is, since this
knowledge belongs to other layers (initramfs-tools/dracut, bootloader).

Anyway, the script must learn to deal with the cases where the microcode
update disappeared as well, or it will break badly.

> Obviously, no need for sudo, if inside the postinst.

Indeed...

--
  Henrique Holschuh