Bug 1620301
| Summary: | s390x: Fail to eject cdrom /tmp/orig.iso when executing test type_specific.io-github-autotest-qemu.eject_media.force_eject | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Karen Mezick <kmezick> |
| Component: | qemu-kvm-ma | Assignee: | Thomas Huth <thuth> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.6 | CC: | cohuck, crosa, dhildenb, jen, kmezick, ldoktor, mdeng, micai, michen, qzhang, thuth, wainersm, xianwang, xuma, yhong, yihyu, ymankad |
| Target Milestone: | rc | ||
| Target Release: | 7.7 | ||
| Hardware: | s390x | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-12-07 07:58:23 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
Karen Mezick
2018-08-22 22:32:49 UTC
The test type_specific.io-github-autotest-qemu.eject_media.eject is also failing with the same error. To run test, execute the command: avocado run type_specific.io-github-autotest-qemu.eject_media.eject --vt-type qemu --vt-guest-os RHEL.7.devel --vt-machine-type s390-virtio --vt-extra-params nettype=bridge skip_cluster_leak_warn=yes Log files are attached. Hi Karen, I've tried to reproduce the problem multiple times now, but so far I've failed: $ avocado --version Avocado 62.0 $ uname -r 4.14.0-87.el7a.s390x $ /usr/libexec/qemu-kvm --version QEMU emulator version 2.12.0 (qemu-kvm-ma-2.12.0-11.el7) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers $ avocado run type_specific.io-github-autotest-qemu.eject_media --vt-type qemu --vt-guest-os RHEL.7.devel --vt-machine-type s390-virtio --vt-extra-params skip_cluster_leak_warn=yes JOB ID : 0d27e139158f733ab4b247a9165eb9c5c2cd4e6f JOB LOG : /home/thuth/avocado/job-results/job-2018-08-27T08.53-0d27e13/job.log (1/2) type_specific.io-github-autotest-qemu.eject_media.force_eject: PASS (117.73 s) (2/2) type_specific.io-github-autotest-qemu.eject_media.eject: PASS (122.77 s) RESULTS : PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 I think my environment is pretty close to yours, except for the "nettype=bridge" which I had to skip since I prefer to run avocado as normal user. Can you also reproduce the problem without "nettype=bridge" ? If so, what else could be related here? Which file system type (XFS? ext4?) are you using? Does the problem also reproduce after you've restarted the host machine? FWIW, I just downgraded my QEMU to qemu-kvm-ma-2.12.0-7.el7, but I was also not able to reproduce the problem with that version. Hi Thomas, Sorry for the delay in responding. I have not been able to re-run this test without "nettype=bridge" because we are having some issues with unattended install on our s390x system which we have not yet resolved. The file system is ext4. Avocado 63.0 (not 62.0) was installed. We are actively pursuing resolving the unattended install issue so as soon as we have things up and running on our s390x, I will try this again and let you know the results. Hi Thomas! Unfortunately currently I have limited access to a s390x machine where I can install RHEL-8. That said, I do have daily access to a s390x machine that has the following installed: Red Hat Enterprise Linux Server release 7.6 (Maipo) qemu-kvm-ma-2.12.0-18.el7.s390x kernel-4.14.0-115.el7a.s390x I just executed the test case multiple times on that machine and I am unable to reproduce the error so I think we can close this issue as resolved! Thanks, Karen Hello guys, I just tried it on RHEL.8 "dnf update" ran on 2018-12-06 using kernel-4.18.0-9.el8.s390x, qemu-kvm-2.12.0-42.module+el8+2173+537e5cb5.s390x and it seems to be fixed: ``` avocado run --vt-guest-os RHEL.7.devel eject_media.force_eject -m /tmp/a.yaml JOB ID : 9e5e9f44c28775d6f9902add7caa6e181aac1fdb JOB LOG : /root/avocado/job-results/job-2018-12-07T01.19-9e5e9f4/job.log (01/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;1-8e3f: PASS (43.44 s) (02/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;2-a70f: PASS (42.95 s) (03/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;3-5109: PASS (43.15 s) (04/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;4-de69: PASS (42.53 s) (05/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;5-dbfe: PASS (50.13 s) (06/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;6-71e6: PASS (43.62 s) (07/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;7-c658: PASS (43.37 s) (08/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;8-90e6: PASS (49.67 s) (09/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;9-b351: PASS (50.20 s) (10/10) type_specific.io-github-autotest-qemu.eject_media.force_eject;z-0d52: PASS (42.47 s) RESULTS : PASS 10 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 JOB TIME : 453.81 s JOB HTML : /root/avocado/job-results/job-2018-12-07T01.19-9e5e9f4/results.html ``` I also tried the "eject" version (5/5 pass) and it also looks good. I think you can close this as next-release. Thanks to both of you for checking it again! Closing now... |