Hi,
Paul Wise <p...@debian.org> writes:
> On Sat, 2018-01-13 at 14:20 +0100, Thomas Liske wrote:
>
>> during adding the feature in needrestart I've looked more closely at the
>> uicode-tool stuff. I don't think we need to examine the initrd since
>> the following command should give already the required informations:
>>
>> # iucode_tool -Sl /lib/firmware/intel-ucode/
>
> That would give false positives when the system has disabled adding the
> microcode to the initrd, since rebooting will not give the new ucode.
> This could happen if the sysadmin experienced issues with new ucodes.
wouldn't the microcode updates included into the initrd automaticly? I
don't find any config option in intel-microcode or initramfs-tools to
disable adding the microcode updates. I would expect that
intel-microcode is removed in such cases.
In case the initrd is build manually it will be still possible to
disable the microcode feature in needrestart 3.0 by an configuration
option. So the sysadmin needs to consciously decide to ignore them.
>> For the check in needrestart it should be enough to compare the current
>> running microcode signature with the latest available one. This would
>> also handle outdated initrd images gracefuly.
>
> I think on Debian at least, outdated microcode in the initrd could only
> be intentional on the part of the sysadmin.
Maybe some postinst problems like running out of disk space.
I still prefere to ignore the initrd completly since it is not provided by
Debian but build on the host and so it can be broken or outdated or
isn't used at all. It is hard to find the correct initrd file,
especially for 3rd party or self-build kernels not using the kernel-package.
Regards,
Thomas
--
:: WWW: https://fiasko-nw.net/~thomas/ ::
::: Jabber: xmpp:tho...@jabber.fiasko-nw.net :::
:: flickr: https://www.flickr.com/photos/laugufe/ ::
