Description of problem:

When updating or reinstalling "microcode_ctl", the following stderr messages are often seen, which can confuse customers:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  Running scriptlet: microcode_ctl-4:20200609-2.20201027.1.el8_3.x86_64                                                       1/2 
/usr/bin/find: ‘standard output’: Broken pipe
/usr/bin/find: write error
/usr/bin/find: ‘standard output’: Broken pipe
/usr/bin/find: write error

...
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

The issue is due to having the following piece of code in /usr/libexec/microcode_ctl/check_caveats:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
631                         { /usr/bin/find "$MC_CAVEATS_DATA_DIR/$cfg" \
632                                 -path "$MC_CAVEATS_DATA_DIR/$cfg/$p" -print0;
633                           /bin/true; } \
634                             | /bin/grep -zFxq "$cpu_mc_path" \
635                             || continue
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

From above, a "find" command is piped to a "grep -q" command.
Due to using "grep -q", the command will exit as soon as there is a match of the pattern, not waiting for reading the rest of the content received from standard input (i.e. the "find" command output).

Due to this, when "find" sends more output, the write() syscall returns with EPIPE error and makes "find" print the error message.

I know it's harmless but this kind of messages should be avoided. The solution here is likely to redirect stderr for "find" to /dev/null.


Version-Release number of selected component (if applicable):

microcode_ctl-20200609-2.20201027.1.el8_3.x86_64


How reproducible:

90% of the time on a system with more than 1 kernel installed

Steps to Reproduce:

1. "yum -y reinstall microcode_ctl"


Expected results:

No "find" stderr messages


Additional info:

The reason for this is %postinstall scriptlet executes with SIGPIPE ignored, as seen in the strace excerpt below:

We have "find" (PID 1893564), forked by PID 1893562, forked by PID 1893547, forked by PID 1890437, the latter ignoring SIGPIPE:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
1893564 08:09:58.994098 execve("/usr/bin/find", ["/usr/bin/find", "/usr/share/microcode_ctl/ucode_with_caveats/intel", "-path", "/usr/share/microcode_ctl/ucode_with_caveats/intel/intel-ucode/*", "-print0"], ...
1893547 08:09:58.983373 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb051fc6a10) = 1893562 <0.000103>
1890437 08:09:58.849811 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fa283820a10) = 1893547 <0.000088>
1890437 08:09:21.144397 rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fa459938880}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fa45a460b20}, 8) = 0 <0.000015>
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

PID 1890437 being the shell script executing the %postinstall script:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
1890437 08:09:21.148698 execve("/bin/sh", ["/bin/sh", "/var/tmp/rpm-tmp.pphSgk", "2"], ...
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------