Bug 1077203

Summary: distribution/install fails with modprobe.log: No such file or directory
Product: [Retired] Beaker Reporter: Alois Mahdal <amahdal>
Component: testsAssignee: beaker-dev-list
Status: CLOSED DUPLICATE QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: developCC: aigao, asaha, dcallagh, llim, rmancy
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-18 22:01:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alois Mahdal 2014-03-17 13:06:55 UTC
Almost every job I started with recent RHEL7 snapshots fails with errors like this:

    /bin/cat: /mnt/testarea/modprobe.log: No such file or directory
    'ffebc9a3-5d3d-4c50-b5ae-c0d6284be826'
    /distribution/install/Sysinfo result: FAIL


This seems to come from /distribution/install2 (7fe6e17):

    ...
    63:sysmodprobe=$(/bin/cat /etc/modprobe.conf > $FILEAREA/modprobe.log)
    ...
    109:/bin/cat $FILEAREA/modprobe.log                 >> $OUTPUTFILE
    ...

I'm not sure when this is executed and if it's a real error that this file does not exist (I haven't found anything in Bugzilla).   Note that even after this failure, my tests are still able to succeed.


Example of such job:
  https://beaker.engineering.redhat.com/jobs/612277

Comment 2 Dan Callaghan 2014-03-18 00:26:25 UTC
(In reply to Alois Mahdal from comment #0)
>     /bin/cat: /mnt/testarea/modprobe.log: No such file or directory

This error message is not fatal, it's just careless code in that task. The file is indeed not always expected to exist.

The actual reason for the Fail result is the AVC denials it found:

******** SElinux AVC Failures ********
[    5.803429] type=1400 audit(1394809016.096:4): avc:  denied  { write } for  pid=565 comm="systemd-sysctl" name="shmmax" dev="proc" ino=1222 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
[    5.824992] type=1400 audit(1394809016.116:5): avc:  denied  { write } for  pid=565 comm="systemd-sysctl" name="shmall" dev="proc" ino=1223 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
[    5.846524] type=1400 audit(1394809016.139:6): avc:  denied  { write } for  pid=565 comm="systemd-sysctl" name="sysrq" dev="proc" ino=1224 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
[    5.867962] type=1400 audit(1394809016.159:7): avc:  denied  { write } for  pid=565 comm="systemd-sysctl" name="core_uses_pid" dev="proc" ino=1225 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
[    5.890121] type=1400 audit(1394809016.182:8): avc:  denied  { write } for  pid=565 comm="systemd-sysctl" name="rp_filter" dev="proc" ino=1229 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
[    5.911918] type=1400 audit(1394809016.203:9): avc:  denied  { write } for  pid=565 comm="systemd-sysctl" name="accept_source_route" dev="proc" ino=1230 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
[    5.934609] type=1400 audit(1394809016.226:10): avc:  denied  { write } for  pid=565 comm="systemd-sysctl" name="protected_hardlinks" dev="proc" ino=1232 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
[    5.957386] type=1400 audit(1394809016.250:11): avc:  denied  { write } for  pid=565 comm="systemd-sysctl" name="protected_symlinks" dev="proc" ino=1233 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file

These are most likely a distro bug.

The fact that /distribution/install is reporting these in a different (and much less obvious) way than other tasks is bug 875543. The reason why it behaves that way is because it is checking for AVC denials which happened earlier during the installation, not just during the task itself.

Comment 3 Alois Mahdal 2014-03-18 09:55:03 UTC
Thank you for explanation, Dan.

As I can see now, later jobs succeeded and still print this modprobe.log error so it's not fatal.  The TESTOUT is pretty confusing though, especially because of this "Info: No AVC messages found.", which reliably put a virtual check mark "AVC: OK" into my mind, leaving the modprobe error as "obvious" cause of failure.  (Unless I'm more familiar with Beaker so I know I have to look at the sub-task "Sysinfo" -> "Test log" (not "AVC log")).

Feel free to close this bug.

Comment 4 Dan Callaghan 2014-03-18 22:01:34 UTC
Yes, I agree that the way those AVC failures are reported in /distribution/install can be confusing. So let's call this a dupe of bug 875543.

*** This bug has been marked as a duplicate of bug 875543 ***