Bug 706099 - Write test cases for command-stubs commands
Summary: Write test cases for command-stubs commands
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Martin Gracik
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 743047
TreeView+ depends on / blocked
 
Reported: 2011-05-19 13:42 UTC by David Cantrell
Modified: 2013-07-04 12:55 UTC (History)
5 users (show)

Fixed In Version: anaconda-13.21.140-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 10:35:47 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1565 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2011-12-06 00:39:12 UTC

Description David Cantrell 2011-05-19 13:42:19 UTC
The command-stubs commands in the anaconda environment need test cases written that QE can integrate in to the RHEL test plans.  For broken commands, we need to either fix them or remove them if they are no longer relevant to the installation environment.

Comment 1 RHEL Program Management 2011-05-19 13:59:41 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Comment 3 David Cantrell 2011-06-13 19:15:45 UTC
I'm going to call the priority high on this bug as it is something we need to get fixed for 6.2.  mgracik has done the work for this already.

I have set the severity to high because the lack of these test cases did cause us a bad RC in the 6.1 cycle.

What we'd like to do is have the test case scripts integrated in to a kickstart %post script that can be used in the test environment so we can quickly see if these command stubs are broken or not.

Comment 5 Alexander Todorov 2011-08-08 11:10:52 UTC
Hi David and Martin,
can you point us to some documentation/howto? Where are the tests stored, how can we execute them?

Comment 6 Martin Gracik 2011-08-08 12:04:55 UTC
The test scripts are located in the same directory as the stubs, that's /usr/bin/.
All have a "<stub_name>-test" format, for example "list-harddrives-test" is a test script for "list-harddrives" stub.

You can execute them from the kickstart file. If the stub does not behave properly, the test script returns a non-zero value, which should cancel the installation.

Comment 7 Alexander Todorov 2011-08-09 09:12:55 UTC
Hi Martin,
with anaconda-13.21.126 I can't find these test scripts. They are not present in the anaconda/anaconda-runtime RPM packages nor in stage2 environment. 

Can you take a look and point me in the right direction?

Comment 8 Martin Gracik 2011-08-09 14:28:18 UTC
I made a mistake and forgot to include the files in the archive. I have a patch, will let you know, when it will be fixed.

Comment 10 Alexander Todorov 2011-08-17 13:07:32 UTC
Hi Martin,
with anaconda-13.21.128 there are several issues:

1) There is one more stub than test case, this is syslogd-stub:

# ls -1 /usr/lib/anaconda/*stub
/usr/lib/anaconda/list-harddrives-stub
/usr/lib/anaconda/loadkeys-stub
/usr/lib/anaconda/losetup-stub
/usr/lib/anaconda/mknod-stub
/usr/lib/anaconda/syslogd-stub

# ls -1 /usr/lib/anaconda/*-test
/usr/lib/anaconda/list-harddrives-test
/usr/lib/anaconda/loadkeys-test
/usr/lib/anaconda/losetup-test
/usr/lib/anaconda/mknod-test


2) In stage2 when executing the tests there seems to be errors:

# list-harddrives-test
Traceback (most recent call last):
  File "/usr/bin/list-harddrives-test", line 21, in <module>
    from subprocess import check_output, CalledProcessError
ImportError: cannot import name check_output
# echo $?
1


# loadkeys-test
/usr/bin/loadkeys: (2, 'No such file or directory')/usr/bin/loadkeys: missing operand
# echo $?
0


# losetup-test
Traceback (most recent call last):
  File "/usr/bin/losetup", line 70, in <module>
    main(prog=sys.argv[0], args=sys.argv[1:])
  File "/usr/bin/losetup", line 64, in main
    isys.losetup(loopdev, image)
  File "/usr/lib/anaconda/isys.py", line 86, in losetup
    targ = os.open(file, mode)
OSError: [Errno 2] No such file or directory: '/tmp/image-file'
# echo $?
1


# mknod-test
mknod: `/dev/test-block': File exists
mknod: `/dev/test-char': File exists
mknod: invalid device type `x'
Try `mknod --help' for more information.
mknod: missing operand
Try `mknod --help' for more information.
# echo $?
0


Moving back to ASSIGNED

Comment 11 Martin Gracik 2011-08-17 14:14:48 UTC
There is no test for the syslogd-stub, that's correct.

But it's strange that none of the tests is working, I'll look into that.

Comment 13 Alexander Todorov 2011-08-26 12:29:42 UTC
With anaconda-13.21.136

> 2) In stage2 when executing the tests there seems to be errors:
> 
> # list-harddrives-test
> Traceback (most recent call last):
>   File "/usr/bin/list-harddrives-test", line 21, in <module>
>     from subprocess import check_output, CalledProcessError
> ImportError: cannot import name check_output
> # echo $?
> 1
> 
> 


Same error.



> # loadkeys-test
> /usr/bin/loadkeys: (2, 'No such file or directory')
> /usr/bin/loadkeys: missing
> operand
> # echo $?
> 0
> 

Same result but I'm not sure if this is PASS or FAIL. 


# losetup-test
losetup: (16, 'Device or resource busy')
losetup: create new loop device test failed
# echo $?
1
 
Is this PASS or FAIL ?
 
> # mknod-test
> mknod: `/dev/test-block': File exists
> mknod: `/dev/test-char': File exists
> mknod: invalid device type `x'
> Try `mknod --help' for more information.
> mknod: missing operand
> Try `mknod --help' for more information.
> # echo $?
> 0
> 

Same result.




Moving back to ASSIGNED. 


Martin, 
what is the expected output/exit code from these tests?

Comment 14 Martin Gracik 2011-08-26 12:54:16 UTC
The expected result is return code 0. The error messages you see are generated by the actual commands and are expected. If the return code is 0, the test passed.

So the mknod and loadkeys tests are OK.

Comment 15 Martin Gracik 2011-08-26 12:54:55 UTC
The other two I will need to fix.

Comment 17 Martin Banas 2011-09-14 13:20:13 UTC
Hi Martin,
Retested on RHEL6.2-20110912.n.0, anaconda-13.21.139-1.el6:

sh-4.1# list-harddrives-test 
Traceback (most recent call last):
  File "/usr/bin/list-harddrives-test", line 53, in <module>
    list_harddrives_test()
  File "/usr/bin/list-harddrives-test", line 41, in list_harddrives_test
    devices.add(dev.path[5:], dev.getSize())
TypeError: add() takes exactly one argument (2 given)

sh-4.1# echo $?
1



sh-4.1# loadkeys-test 
loadkeys: load non-existing keymap test failed

sh-4.1# echo $?
1



sh-4.1# losetup-test 
losetup: (16, 'Device or resource busy')
losetup: missing operand
Usage: losetup [-d] <loopdev> [file]

Options:
  -h, --help    show this help message and exit
  -d, --detach  

sh-4.1# echo $?
0



sh-4.1# mknod-test
mknod: `/dev/test-block': File exists
mknod: `/dev/test-char': File exists
mknod: invalid device type `x'
Try `mknod --help' for more information.
mknod: missing operand
Try `mknod --help' for more information.
Usage: mknod [OPTION]... NAME TYPE [MAJOR MINOR]
Create the special file NAME of the given TYPE.

Mandatory arguments to long options are mandatory for short options too.
  -m, --mode=MODE    set file permission bits to MODE, not a=rw - umask
  -Z, --context=CTX  set the SELinux security context of NAME to CTX
      --help     display this help and exit
      --version  output version information and exit

Both MAJOR and MINOR must be specified when TYPE is b, c, or u, and they
must be omitted when TYPE is p.  If MAJOR or MINOR begins with 0x or 0X,
it is interpreted as hexadecimal; otherwise, if it begins with 0, as octal;
otherwise, as decimal.  TYPE may be:

  b      create a block (buffered) special file
  c, u   create a character (unbuffered) special file
  p      create a FIFO

NOTE: your shell may have its own version of mknod, which usually supersedes
the version described here.  Please refer to your shell's documentation
for details about the options it supports.

Report mknod bugs to bug-coreutils
GNU coreutils home page: <http://www.gnu.org/software/coreutils/>
General help using GNU software: <http://www.gnu.org/gethelp/>
For complete documentation, run: info coreutils 'mknod invocation'

sh-4.1# echo $?
0

Moving back to ASSIGNED

Comment 19 Pavel Holica 2011-10-25 12:15:35 UTC
With anaconda-13.21.146-1.el6:
# for TEST in /usr/bin/*-test; do echo $TEST; $TEST; echo $?; echo =============; done

list-harddrives-test
0
=============
loadkeys-test
/usr/bin/loadkeys: missing operand
0
=============
losetup-test
losetup: (16, 'Device or resource busy')
losetup: missing operand
Usage: losetup [-d] <loopdev> [file]

Options:
  -h, --help    show this help message and exit
  -d, --detach  
0
=============
mknod-test
mknod: `/dev/test-block': File exists
mknod: `/dev/test-char': File exists
mknod: invalid device type `x'
Try `mknod --help' for more information.
mknod: missing operand
Try `mknod --help' for more information.
Usage: mknod [OPTION]... NAME TYPE [MAJOR MINOR]
Create the special file NAME of the given TYPE.

Mandatory arguments to long options are mandatory for short options too.
  -m, --mode=MODE    set file permission bits to MODE, not a=rw - umask
  -Z, --context=CTX  set the SELinux security context of NAME to CTX
      --help     display this help and exit
      --version  output version information and exit

Both MAJOR and MINOR must be specified when TYPE is b, c, or u, and they
must be omitted when TYPE is p.  If MAJOR or MINOR begins with 0x or 0X,
it is interpreted as hexadecimal; otherwise, if it begins with 0, as octal;
otherwise, as decimal.  TYPE may be:

  b      create a block (buffered) special file
  c, u   create a character (unbuffered) special file
  p      create a FIFO

NOTE: your shell may have its own version of mknod, which usually supersedes
the version described here.  Please refer to your shell's documentation
for details about the options it supports.

Report mknod bugs to bug-coreutils
GNU coreutils home page: <http://www.gnu.org/software/coreutils/>
General help using GNU software: <http://www.gnu.org/gethelp/>
Report mknod translation bugs to <http://translationproject.org/team/>
For complete documentation, run: info coreutils 'mknod invocation'
0
=============


So moving to verified:

Comment 20 errata-xmlrpc 2011-12-06 10:35:47 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1565.html


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