Description of problem: Trying to get beaker to provision a RHEL5.7 system fails with an anamon backtrace in console.log after the reboot: Starting beah-fwd-backend: [ OK ] beah-fwd-backend running as process 4986 Running RHTS-Compatibility Service... NOTE: This process runs if foreground. Use 'service rhts-compat stop' from another terminal to stop it. Traceback (most recent call last): File "/usr/local/sbin/anamon", line 275, in ? anamon_loop() File "/usr/local/sbin/anamon", line 224, in anamon_loop wf.update() File "/usr/local/sbin/anamon", line 121, in update self.uploadWrapper() File "/usr/local/sbin/anamon", line 106, in uploadWrapper if session.upload_log_data(name, self.alias, sz, offset, data): File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib64/python2.4/xmlrpclib.py", line 1129, in request self.send_content(h, request_body) File "/usr/lib64/python2.4/xmlrpclib.py", line 1243, in send_content connection.endheaders() File "/usr/lib64/python2.4/httplib.py", line 804, in endheaders self._send_output() File "/usr/lib64/python2.4/httplib.py", line 685, in _send_output self.send(msg) File "/usr/lib64/python2.4/httplib.py", line 652, in send self.connect() File "/usr/lib64/python2.4/httplib.py", line 620, in connect socket.SOCK_STREAM): socket.gaierror: (-3, 'Temporary failure in name resolution') [-- MARK -- Wed Apr 27 04:05:00 2011] [-- MARK -- Wed Apr 27 04:10:00 2011] [-- MARK -- Wed Apr 27 04:15:00 2011] [-- MARK -- Wed Apr 27 04:20:00 2011] [-- MARK -- Wed Apr 27 04:25:00 2011] [-- MARK -- Wed Apr 27 04:30:00 2011] [-- MARK -- Wed Apr 27 04:35:00 2011] ... Version-Release number of selected component (if applicable): 0.6.9 How reproducible: Seemingly 100% Steps to Reproduce: 1. Reserve a machine using x86_64 and rhel5.7 server as requirements 2. Wait Actual results: JobID: 77766 Status: Aborted Result: Warn <https://beaker.engineering.redhat.com/jobs/77766> RecipeSetID: 132162 RecipeID: 159460 Arch: x86_64 System: dell-pe1855-02.rhts.eng.bos.redhat.com Distro: RHEL5.7-Server-20110413.1 OSVersion: RedHatEnterpriseLinuxServer5.7 Status: Aborted Result: Warn TaskID: 1740821 TaskName: /distribution/install StartTime: 2011-04-27 08:27:34 Duration: 0:50:35.469932 Status: Aborted Result: Warn TaskID: 1740822 TaskName: /distribution/reservesys StartTime: None Duration: None Status: Aborted Result: Warn Expected results: Success
5.7 works just fine, but the recipe uses xen distro because of distro_virt specified in your recipe. I may be wrong but think distro_virt is only for virtual guests.
Hm ok that sounds a bit odd as the recipe was created by the beaker website using the "Reserve" page. I tried a custom xml recipe using <distro_virt op="=" value="False"/> but it seems to have picked a distro with virt=True. Strange.
I guess you have picked the given distro with xen suffix manually. I believe if you try it again with distro without xen suffix it will work. If so close as NOTABUG, please.
There is also Bug 638215 to not show these distros in the lists.
I did not choose a xen distro manually. Perhaps you could look at https://beaker.engineering.redhat.com/jobs/77872 - Comparing the job xml with the distro chosen by beaker, it shows that <distro_virt op="=" value="False"/> was specified but a virt=True distro was chosen by beaker.
Even if I pick the xen distro on reserveworkflow page it does pick the regular one. The distro_virt should be: <distro_virt op="=" value=""/> How was the job xml created?
It was cloned from a previous job which required virt and I changed "True" to "False" in the distro_virt tag. It seemed like the logical thing to do. Anyway, it seems to work with <distro_virt op="=" value=""/> so my problem is solved, thanks :)