Bug 1077203 - distribution/install fails with modprobe.log: No such file or directory
Summary: distribution/install fails with modprobe.log: No such file or directory
Keywords:
Status: CLOSED DUPLICATE of bug 875543
Alias: None
Product: Beaker
Classification: Retired
Component: tests
Version: develop
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-17 13:06 UTC by Alois Mahdal
Modified: 2018-02-06 00:41 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-03-18 22:01:34 UTC
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.