During various reasons (specifically, due to being called at various
stags of mirocode_ctl installation/upgrade) it is possible that some
directories do not exist, which is problematic, as find exits
with non-zero exit code if being called on them. Avoid that by wrapping
find calls in a function that checks that the first find argument
is indeed an existing directory before calling find itself.
* update_ucode (find_d): New function.
Convert find calls that are not prefixed with $cmd into find_d calls.
* microcode_ctl.spec (Release): Bump to 4.
(%changelog): Mention it.
Resolves: #2225681
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
The scripts are not expected to work with locale-sensitive data,
and since unusual locales may let them go haywire, try to avoid
it by forcing locale to C at the beginning of the scripts.
* check_caveats: Export LC_ALL=C.
* reload_microcode: Likewise.
* update_ucode: Likewise.
* microcode_ctl.spec (Release): Bump to 3.
(%changelog): Mention it.
Resolves: #2218104
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
Microcode is not supposed to be removed during updates,
so there are several possible code paths/situations when
it is possible that symlinks are not completely cleaned up;
as a result, when such a case occurs (for example, when
there is a microcode, that is not supposed to be OS-loadable
in the first place, added end then removed) a dangling symlinks
may appear during updates; the most straightforward way to deal
with it, it seems, is to just treat the microcode directories
as being owned by the package (which they de-facto are) and simply
cleanup all the dangling symlinks during an update.
* update_ucode: Remove all the dangling symlinks at the end of common
microcode removal phase; remove all the dangling symlinks in the
kernel-specific directories at the end of the update process.
* microcode_ctl.spec (Release): Bump to 2.
(%changelog): Add an entry.
Resolves: #2213022
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>