On 26 March 2018 at 13:07, Henrique de Moraes Holschuh <[email protected]> wrote: > 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... >
$(--scan-system) -> find the current processor signature e.g. 0x000306a9 Pass that as the selector, to the listing of all microcodes: iucode_tool -s 0x000306a9 -l /lib/firmware/intel-ucode Thus find me the available revision of ucode on disk. Compare that with currently loaded revision of ucode, as reported via kernel sysfs: cat /sys/devices/system/cpu/cpu0/microcode/version if the two do not match (on-disk vs loaded onto the cpu) -> request reboot. This will bring up cases, of any missmatch, eg. older/newer/dowgrade/upgrade. Thus I am comparing runtime - what the cpu is reporting as loaded (via sysfs), versus what I could have loaded from disk, if I reboot with a fresh initramfs generated from the ucode on disk. Note this will run only at postinst of intel-microcode package. Thus if there is a false positive, this will only be triggered once, not at like every call to `update-initramfs -u`. (for the cases of multiple cpus / different cpu ids / etc). I guess we can run above for every cpuX in the /sys/devices/system/cpu/ directory, to catch ucode updates to all cores. >> 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. > I am not worried about that. One is expected to reboot approximately every three week on Ubuntu anyway, due to full kernel updates. > 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). > I am checking currently loaded, versus what is available on disk. I believe this is sufficient, and there should be no need to parse initrds. Please note, this doesn't force a reboot, only shows generic notification that reboot is suggested in MOTD / GUI popups, etc. > Anyway, the script must learn to deal with the cases where the microcode > update disappeared as well, or it will break badly. > Comparing ondisk with running, does this already. Empty does not equal to something. -- Regards, Dimitri. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1742903 Title: Microcode updates require a reboot to apply, but package postinst doesn't touch /run/reboot-required To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1742903/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
